doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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 and Dr. Bill Shvodian Company: Broadcom, Corp. and XtremeSpectrum, Inc. 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 for comment resolution of LB12 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 /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 2 Simplification of EPS Mechanism for MAC

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 3 Background 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

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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

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

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 6 TIM element in Beacon 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 Octets Start Device Address 1 Octet Traffic Indication Map (TIM) 1 Octet Element ID 1 Octet Length = (2 to 33)

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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.

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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

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

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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

doc.: IEEE /384r2 Submission Aug 2001 Dr. Rajugopal Gubbi, BroadcomSlide 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