1 / 17

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: A simplified and unified power save scheme Date Submitted: 1 July, 2002 Source: Knut Odman Company: XtremeSpectrum Inc. Address: 8133 Leesburg Pike, Suite 700, Vienna, VA 22182

Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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: 1 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 identifies and solves problems with the current handover process. 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. Problem 1 – Subrate -I SF 4 DEV 1 has a sub-rateevery 25000 SF SF 3 SF 2 SF 1 DEV 2 wants this GTSevery beacon. Is itavailable? CTR

  3. Problem 1 – Subrate -II scheduler GTS2 ATS1 GTS1 GTS ATS superframe Treat sub-rate as hi-priority ATS Possible but complicated. Interval not guaranteed. What is the purpose?

  4. Problem 2 – APS Not related to transmission needs No synchronized wakeup. When should it read PCTM? PNC would have to buffer CTR that may be of no interest once they are allocated. What is the purpose?

  5. Problem 3 – SPS -I GTS1 SF 2 GTS1 SF 1 What does PNC do with a passive GTS? It cannot reallocate it.

  6. SF1 SF5 SF4 SF3 Problem 3 – SPS - II DEV1 DEV2 DEV4 SF2 How do I broadcast? How does DEV4 send to DEV1? How is handover done?

  7. Problem 3 – SPS - III Suspend/ revoke GTS… Join/leave SPS… No global sync… CTRI, SPSI, Active, AWAKE, Sleep… The complexity is prohibitive What is the purpose?

  8. Experiences from other protocols Other protocols not using PNC forwarding either have announcement beacons where the PNC wakes up dest. DEV, or announcement slots where the source DEVswake up their destination. What makes us so special?

  9. Experiences from research There is a tradeoff between communication and computation. If the algorithm is distributed, computation gets smaller but the control overhead increases. Rule of thumb: Keep it simple.

  10. QoS in the sleep? Don’t expect QoS to be perfectly maintained in sleep mode. Responsiveness: Does it matter if you get the slot in 10sor 10.00124s? Throughput: If you need full QoS, why not wake up, establish a stream, send data, kill stream and go back to bed? The overhead isn’t bigger than the current SPS. Jitter: Can’t be guaranteed anyway. If it doesn’t happen all the time it’s asynchronous!

  11. Solution - I Remove subrate, APS and SPS from standard. Introduce PNC regulated wake beacons. The PNChas a down counter to count down to the nextwake beacon. In increased traffic, wake beaconscan come more often. DEVs join and leave sleep mode. PNC sets bitmapin all beacons. Use ATS reservation. If dest. in PS, CTA will notcome until next (or a following) wake beacon.

  12. Destination Dev2 PNC asleep Set Dev2 bit in beacon PS bitmap Terminate streamsto and from DEV2

  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) No isochronous data to PS DEVs

  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 awake Reset Dev2 bit in beacon PS bitmap

  16. octets :1 1 1 0-8 Information IE length = 1-9 wake-beaconcountdown PS bitmap Beacon elements

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

More Related