doc.: IEEE /yyyr0 Submission Aug 2001 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE : Power Save Proposal. Date Submitted: 30 July, 2001 Source: Dr. Rajugopal Gubbi Company: Broadcom, Corp Address: 400, E-Caribbean Drive, Sunnyvale, CA Voice: , FAX: , Re: [ Power save mechanism in TG3-MAC ] Abstract: This provides an overview of proposed power save mechanism for TG3-MAC. Purpose: To provide information and solicit comments on proposed power save mechanism Notice:This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 2 Overview of MAC Power Save Proposal

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 3 Changes from 292/293r1 to the current Made a separate doc with just the power-save mechanism Add traffic indication from PNC in the Beacon

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 4 Salient features Two possible power save states –Snooze state for both DEV and PNC: locally managed –Sleep state for DEV only: cooperation from PNC Traffic indication in Beacon to allow max power save when no traffic is pending for the DEV that is in Sleep state

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 5 Snooze state Operation PNC can also use this state Stay awake for –Beacon –CAP –Broadcast GTS, if allocated –Assigned receive slot –Assigned tx slot with activity Contention Access Period Beacon Contention Free Period Assigned Slot Assigned Slot Period of Reduced Power Opportunity

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 6 Sleep state operation Sleep state req by DEV, permit/reject by PNC with indication of max-sleep-time Skipped super-frames Traffic indication in Beacon for support of Sleep state and sleep-cycles Repeater service for sleep state Association timeout

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 7 Sleep state Operation – skipped superframes Beacon Contention Free Period Assigned Slot Beacon Opportunity to reenter EPS Beacon PNC Generated Superframes Wake to beacon – no traffic Indicated Wake to beacon at the end of sleep-cycle - Traffic Indicated Indicate active state Receive/ack data

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 8 Beacon Content for Support of Sleep State Power-save information element (new) –each DEV in sleep state need at-most ONE bit information and that too if there is traffic pending for them –PNC creates a traffic indication blocks (TIB) PNC does NOT send data unless the DEV has indicated the “Active- state” PNC can buffer even the MCAST and BCAST data for the sleeping DEV 1 Octet Start Device Address 1 Octet Traffic Indication 1 Octet Element ID 1 Octet Length = (n*2) 2 Octets TIB 2 Octets TIB Power save information element Traffic indication block (TIB)

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 9 Association Timeout Operation Based on aAssociationTimeoutPeriod parameter (7.3.5 in 0.4 draft). Communicated to PNC by all devices during association DEVs must choose sleep times shorter than association timeout If active state indication is not received by the PNC before this timeout, the DEV will be disassociated by the PNC Applies to ALL DEVs

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 10 Repeater Considerations Use repeater in normal manner as piconet coverage enhancer. Add use of repeater as part of support to Sleep state Either the sender or the dest-DEV can request the repeater service

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 11 Operation over multiple super frames Beacon CAP CFP Active State Indication ACK at end of SIFS Sleep State Request ACK at end of SIFS Sleep State Permit ACK at end of SIFS Beacon CAP CFP Sleep-cycle of multiple super-frames Wakeup, rx beacon No traffic indication or zero traffic pending Sleep-cycle of multiple super-frames Beacon CAP CFP Wakeup, rx beacon traffic pending Receive frames

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 12 Need for Sleep-state request and permission commands Without the indication from the DEV that it is going into or coming out of sleep state –The slot allocations for the Sleep-state DEV must always be made even when it is asleep –The DEV must wakeup for every beacon (no deep sleep or skipping multiple superframes). If not, the PNC might indicate “traffic pending” when the dev is asleep and the tx of frames in that frames will be lost. This causes the retry limit on the frames to be reached faster. Worse, MCAST/BCAST and frames with no response will be lost forever. Missed beacons at the DEV also cause the same problem. –With the command exchange the DEV can wakeup near the end of this time and hence saving more power than the case of waking up every Beacon and still be assured the frames are not lost because it was asleep. –As a modification to the proposal, the sleep-state response from PNC can be made as an imm-response to the sleep-state-request command.

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 13 Need for repeater service and traffic indication in Beacon Sender need not keep track of frames sent v/s the indicated traffic state PNC has to do this anyway for one or the other reason in both the proposals Traffic indication, needs one bit (best case) in this proposal where it needs two bytes in the proposal in 262r0. Hence the best case overhead in this proposal is nearly 8-times better. No need for sender-PNC communication on traffic indication Hence no concern of sync issues between what is indicated in the Beacon and what goes on in the slot.

doc.: IEEE /yyyr0 Submission Aug 2001 Slide 14 Conclusions Emphasis on lowest power use for “no op” wake cycles. Beacon provides –traffic indication necessary for low power operation during no-traffic states MCAST/BCAST are also handled No sync issues between the PNC, sender and the receiver Direct data transfer between the Sender and receiver is possible by extending the sleep/active state indications to the sender from the rx-dev PNC provides repeater service