Aug 2001 doc IEEE 802 15 01yyyr 0

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE 802. 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 TG 3 -MAC ] Abstract: This provides an overview of proposed power save mechanism for TG 3 -MAC. Purpose: To provide information and solicit comments on proposed power save mechanism Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15 Submission 1 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Overview of MAC Power Save Proposal Submission 2 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Changes from 292/293 r 1 to the current • Made a separate doc with just the power-save mechanism • Add traffic indication from PNC in the Beacon Submission 3 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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 Submission 4 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Period of Reduced Power Opportunity Slot Contention Access Period Assigned Contention Free Period Assigned Slot Beacon Snooze state Operation • PNC can also use this state • Stay awake for – – – Submission Beacon CAP Broadcast GTS, if allocated Assigned receive slot Assigned tx slot with activity 5 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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 Submission 6 <Dr. Rajugopal Gubbi> <Broadcom>

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

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Beacon Content for Support of Sleep State 1 Octet Element ID 1 Octet 2 Octets TIB Length = (n*2) Power save information element 1 Octet Start Device Address Traffic Indication Traffic indication block (TIB) • 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 “Activestate” PNC can buffer even the MCAST and BCAST data for the sleeping DEV • Submission 8 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Association Timeout Operation • Based on a. Association. Timeout. Period 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 Submission 9 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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 Submission 10 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 Operation over multiple super frames Sleep State Request ACK at end of SIFS Sleep State Permit ACK at end of SIFS Submission Receive frames Beacon CAP Sleep-cycle of multiple super-frames CAP CFP Beacon CAP Sleep-cycle of multiple super-frames CFP Wakeup, rx beacon No traffic indication or zero traffic pending 11 CFP Wakeup, rx beacon traffic pending Active State Indication ACK at end of SIFS <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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. Submission 12 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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 262 r 0. 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. Submission 13 <Dr. Rajugopal Gubbi> <Broadcom>

Aug 2001 doc. : IEEE 802. 15 -01/yyyr 0 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 Submission 14 <Dr. Rajugopal Gubbi> <Broadcom>