1 / 20

Simplified and Unified Power Save Scheme

This presentation proposes a basic power save scheme to replace APS and SPS, focusing on power-saving for receive time and transmit time. It also highlights the importance of isochronous streams and synchronization between devices.

howardmarks
Download Presentation

Simplified and Unified Power Save Scheme

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: A simplified and unified power save scheme Date Submitted: 24 July,2002 Source: Knut Odman Company: XtremeSpectrum Inc. Address: 8133 Leesburg Pike, Suite 700, Vienna, VA 22182 Voice: 703-269-3058, FAX: 703-269-3092, E-Mail: kodman@xtremespectrum.com Re: Draft P802.15.3/D10 Abstract: This presentation presents a basic power save scheme to replace APS and SPS. Purpose: For implementation in standard. 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.

  2. Fundamentals:Power-save • Declaration of power save settings is only usefulfor potential destinations. • Why? • Nothing stops a sleeping source DEV from sending to an awake destination DEV • Nothing stops a sleeping DEV from sending request commands to the PNC • The sole purpose of sleep declarations is to inform other DEVs that this sleeping DEV will not listen. • Conclusion: PS only related to receive time.

  3. Fundamentals: streams • Declaration of transmit interval is only interestingfor senders. • Why? • All streams initiated by the sender, not by the destination DEV(s). • A DEV has one sleep need but potentially many streams. The two are not interchangeable. • Conclusion: CTR only related to transmit time

  4. Fundamentals: CTA awareness Isochronous data is only useful between peers whoknow about each other and where the destination isawake. If we can make sure the destination knows about the CTA, it can wake up for just the GTS, andit doesn’t matter if the destination is in sleep mode. A sleeping DEV may get data from unknown senders.All such traffic is Asynchronous. Conclusion: Isochronous streams useful for wake destination DEVs.

  5. Synchronization A sender may want to send data to many or all DEVs,of which some may be asleep. All senders need to know two things:- is the destination awake? - if not, when will it be awake? The PNC may also need to do system changes and thenneed to inform all DEVs about them. Announcement of changes should be done when all DEVs are known to be awake. Conclusion: Have globally known wake times.

  6. Streams for sleeping destination - I • Can Isochronous data be used when the destinationis asleep? Yes, if the destination knows about the CTA. • PNC can help achieving this by only: • introducing new stream CTAs in a wake beacon • making modifications to CTAs in a wake beacon • The only thing missing in the current draft to make this possible is that the CTR-interval for subrates is notconveyed to the destination. This could be done in the beacon as an IE for new/changed streams.

  7. Streams for sleeping destination - II How would it work? 1) Source makes CTR 2) PNC approves 3) PNC creates first CTA and “interval IE” in wake beacon From this time on, a sleeping destination knows to wakeup for the beacon before next incoming GTS Again, a sleeping DEV can always wake up and transmitduring its own GTS, assuming that the destination DEVis awake. Consequently, the problem is only relevant for GTSs where the destination DEV is sleeping.

  8. Streams for sleeping destination - III Power save impact? If sleeping DEV is source: no problem, DMEdoesn’t allocate streams that violates the sleepingsource DEV’s PS criteria.If the sleeping DEV is a unicast destination: The destination DEV may send a CTR command toterminate unwanted incoming streams. If the stream is multicast or broadcast, a DEV alreadyhas the right to ignore it. There is no guaranteeddelivery of non directed data.

  9. Wake beacon - I As indicated above, all CTA changes, system changesand asynchronous data to sleeping DEVs should bedone in a global wake beacon and its superframe. PNC should be able to “chain” wake beacons if moretraffic needs to be sent than would fit within the available“PS traffic area” in one superframe.All DEVs should be able to synchronize to the wakebeacon regardless when they wake up. Every beaconshould have a down counter to the next wake beacon.

  10. Wake beacon - II • PNC should balance its own needs for synchronizedsystem information against each source DEVs need for reasonable asynchronous data latency, and each sleeping DEVs need not to wake up too often. • The best way for PNC to make an educated decisionis to collect requests from DEVs when they wish togo into sleep mode. This is similar to current SPS, withthe difference being: The PNC makes the final decision.Possible policies: • The interval of the first DEV to request will be used. • The shortest requested interval will be used, down to some minimum- Find a reasonable average, one size fits all

  11. Solution Introduce PNC regulated wake beacons. The PNChas a down counter to count down to the nextwake beacon. During increased traffic, wake beaconscan come more often. When DEVs join or leave sleep mode, the PNC updates a bitmap in its beacons indicating which DEVs are asleep. When using asynchronous GTS channel time reservation, if the destination DEV is asleep, the CTA will not come until the next (or a following) wake beacon.

  12. Potential destination(any power save DEV) Dev2 PNC PSMode (PSAVE, req_wake_ival) Set Dev2 bit in beacon PS bitmap

  13. Source Dev1 PNC CTR (DEV2, stream 0) DEV2 in PS? true false No PCTM needed.The CTA will be therein the wake beacon Enqueue (PSQ, data) Enqueue (AsynchQ, data) Implementation example. A longer timeout may beneeded if destination sleeps(longer to next wake beacon) No special action neededto send asynchronousdata to sleeping destination.Normal CTR exchange.

  14. SF1 SF5 SF4 SF3 Wakebeacon PNC CTA1->2 SF2 CTA with Dev2as Destination PNC can chain more than one wake- beacon after each other if needed

  15. Destination Dev2 PNC PSMode(ACTIVE, ) Reset Dev2 bit in beacon PS bitmap

  16. octets :1 1 1 1-32 Information IE length = 2-33 Start DEVID PS bitmap Beacon elements - I Power save bitmap This bitmap replaces current PCTM, 7.4.15 A traffic map is not needed in a TDMA protocol,since the CTA is the traffic map. The prerequisiteis that all DEVs know when to read the CTA(in the wake beacon) Every DEV has a bit. 1=PSAVE, 0=ACTIVE

  17. bits :b0 B1-b7 Wake beacon Countdown Beacon elements - II Countdown field. This field is a one octet member if thepiconet synchronization field. Wake beacon: 1 if the current beacon is a wake beacon Countdown: counts down to the next wake beacon. Whenthe wake beacon is sent, the countdown to the next wakebeacon is put in this field (in stead of number 0) Chaining: If Countdown is set to 0 in a wake beacon, thenext beacon is also a wake beacon.

  18. octets :1 1 1 1 4 Information IE length = 6 Stream Index CTR-interval Start beacon number Stream Interval IE Even if new streams, or modifications to existingstreams, are only introduced in the wake beacon,there are currently no way to inform the destinationsabout the interval between subrate CTAs.This could be added to the CTA field but wouldwaste beacon space. A better method is to introducethe Stream CTR Interval IE for aMinBeaconInfoRepeat beacons, starting with the wake beacon. The IEwould contain a new or modified stream CTR-intervaland start beacon number.

  19. Wake beacon rules If you miss the wake beacon, listen to the nextbeacon. The next beacon may be another wakebeacon, or if not, the count down counter in the beaconwill indicate when the next wake beacon will occur. If the PNC issues a system change, it shall put thepiconet change IE into at least 4 beacons startingwith a wake beacon. Suitable wake beacon intervals? 802.11 has max 16. Suggest for 802.15.3: Minimum 4. Maximum 32. TBD

  20. That’s it! Do we really have to make it more complicated than that?

More Related