Aug 2001 doc IEEE 802 15 01384 r

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 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 and Dr. Bill Shvodian Company: Broadcom, Corp. and Xtreme. Spectrum, Inc. 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 for comment resolution of LB 12 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/384 r 2 Simplification of EPS Mechanism for 802. 15. 3 MAC Submission 2 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 Background • 802. 15. 3 has two possible power save mechanisms – Reduced power save (RPS) mechanisms for both DEV and PNC: locally managed. NO change proposed for this mechanism – Extended power save (EPS) mechanism for multi-superframe long sleep • Traffic indication in Beacon to allow max power save when no traffic is pending for the DEV that is in EPS state Submission 3 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 EPS operation (1) • EPS state req by DEV, permit/reject by PNC with indication of max-sleep-time • If permitted, the DEV can go to sleep only at the end of current superframe • If permitted to sleep, DEV can sleep through multiple super-frames • Traffic indication in Beacon, allows DEVs to either request new Sleep time or remain awake • Optional Repeater service during sleep • max-sleep time is smaller than Association timeout • PNC does NOT allocate GTS unless both the tx and rx DEVs of that GTS are known to be awake Submission 4 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 EPS Operation (2) Beacon PNC Generated Superframes Wakeup at the end of sleep-time. Wait for beacon if traffic Indicated, wait for traffic using RPS else, request new sleep time DEVs may Wake to beacon during sleep-time to check for traffic indication. DEVs shall inform PNC that they are awake by sending any frame (incl. Command frame with no payload) directed to PNC Submission 5 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 TIM element in Beacon 1 Octet Element ID • • 1 Octet Length = (2 to 33) 1 Octet 1 -32 Octets Start Device Address Traffic Indication Map (TIM) 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 map based on the GTS-requests received Bit-pos corresponding to AD-AD of 0 x. FF is used for BC traffic indication Bit-pos corresponding to AD-AD of 0 x. FD is used for MC traffic indication Bits corresponding to reserved AD-AD values shall be set to zero upon tx and ignored upon rx If this element is not present in the beacon, it shall be interpreted as all the DEVs being awake in the current superframe. On the other hand if this element is present, then the DEVs indicated in the TIM are currently asleep. In the case of AD-AD of 0 x. FF and ox. FD being set, it shall be interpreted as atleast one DEV in the piconet being asleep during the current superframe. If PNC does not have any pending GTSs or BC/MC traffic but it knows that atleast one DEV is asleep, this element shall be sent in beacon with TIM of zeros. Submission 6 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 TIM construction at PNC • When a GTS is ongoing, the dest-DEV can detect no traffic coming in and hence request to go to EPS state. When PNC permits it, the PNC shall remove the GTS allocated with the current DEV as rx-DEV. • A new GTS-request from a src-DEV at PNC results in the TIM-bit corresponding to the dest-DEV to be set in the beacon • If src-DEV enters EPS state, all the pending GTSrequest from that DEV are cancelled and hence the TIM-bits corresponding to those GTS-requests. When the DEV comes out of sleep state it has to send new request for GTS. Submission 7 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 BC/MC traffic management (1) • DEV: When a src-DEV has BC/MC traffic to send it has two options (a) the src-DEV can see the presence of Tim-element in beacon and defer the transmission of BC/MC traffic or (b) simply request repeater request for BC/MC traffic • PNC: PNC shall indicate BC/MC traffic pending in beacon is there is a pending GTS-request for BC/MC traffic or a pending BC/MC frame at PNC. Under such conditions, PNC shall issue new sleep-permission to any requesting DEV to be smaller (or equal) than the max of remaining sleep times of all the currently sleeping DEVs Submission 8 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 BC/MC traffic management (2) Beacon PNC Generated Superframes GTSs for BC/MC allocated Different DEVs ending sleep-time Max remaining sleep time Max permitted sleep time New request BC/MC traffic indicated in beacon Submission 9 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 Optional 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 • DEVs can request and avail repeater service only when they are entering sleep state. When they are awake they can simply cancel the repeater service for direct communication Submission 10 Dr. Rajugopal Gubbi, Broadcom

Aug 2001 doc. : IEEE 802. 15 -01/384 r 2 Conclusions • Emphasis on lowest power use for “no op” wake cycles. • Emphasis on simple EPS mechanism • 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 Submission 11 Dr. Rajugopal Gubbi, Broadcom