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 and Dr. Bill Shvodian Company: Broadcom, Corp. and XtremeSpectrum, 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 TG3-MAC ] Abstract: This provides an overview of proposed power save mechanism for TG3-MAC. Purpose: To provide information for comment resolution of LB12 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. Simplification of EPS Mechanism for 802.15.3 MAC Dr. Rajugopal Gubbi, Broadcom

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

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

5. EPS Operation (2) PNC Generated Superframes Beacon Beacon 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 Dr. Rajugopal Gubbi, Broadcom

6. TIM element in Beacon 1 Octet 1 Octet 1 Octet 1-32 Octets Element ID Length = (2 to 33) 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 0xFF is used for BC traffic indication • Bit-pos corresponding to AD-AD of 0xFD 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 0xFF and oxFD 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. Dr. Rajugopal Gubbi, Broadcom

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

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

9. BC/MC traffic management (2) PNC Generated Superframes Beacon Beacon GTSs for BC/MC allocated Different DEVs ending sleep-time Max remaining sleep time Max permitted sleep time BC/MC traffic indicated in beacon New request Dr. Rajugopal Gubbi, Broadcom

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

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