Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE802.15.3: Power Save Proposal. Date Submitted: 30 July, 2001 Source: Dr. Rajugopal Gubbi Company: Broadcom, Corp Address: 400, E-Caribbean Drive, Sunnyvale, CA 95070 Voice: 408-543-3470 , FAX: 408-543-3470 , E-Mail: rgubbi@broadcom.com 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 P802.15. 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 <Dr. Rajugopal Gubbi> <Broadcom>

2. Overview of MAC Power Save Proposal <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>

5. PNC can also use this state Stay awake for Beacon CAP Broadcast GTS, if allocated Assigned receive slot Assigned tx slot with activity Snooze state Operation Contention Access Period Contention Free Period Assigned Slot Beacon Assigned Slot Period of Reduced Power Opportunity <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>

7. Sleep state Operation – skipped superframes PNC Generated Superframes Wake to beacon – no traffic Indicated Beacon Beacon Contention Free Period Beacon Wake to beacon at the end of sleep-cycle - Traffic Indicated Indicate active state Receive/ack data Opportunity to reenter EPS Assigned Slot <Dr. Rajugopal Gubbi> <Broadcom>

8. Beacon Content for Support of Sleep State 1 Octet 1 Octet 2 Octets 2 Octets • 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 Element ID Length = (n*2) TIB TIB Power save information element 1 Octet 1 Octet Start Device Address Traffic Indication Traffic indication block (TIB) <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>

11. Operation over multiple super frames Sleep-cycle of multiple super-frames Sleep-cycle of multiple super-frames Receive frames CFP CFP CFP CAP CAP CAP Beacon Beacon Beacon Sleep State Request ACK at end of SIFS Wakeup, rx beacon No traffic indication or zero traffic pending Wakeup, rx beacon traffic pending Sleep State Permit ACK at end of SIFS Active State Indication ACK at end of SIFS <Dr. Rajugopal Gubbi> <Broadcom>

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. <Dr. Rajugopal Gubbi> <Broadcom>

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. <Dr. Rajugopal Gubbi> <Broadcom>

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 <Dr. Rajugopal Gubbi> <Broadcom>