1. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh Notice: This document has been prepared to assist IEEE 802.11. 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 grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2008-05-12 Authors: NameAddressCompanyPhoneEmail Mathilde Benveniste 233 Mt Airy Road Basking Ridge, NJ 07920, US Avaya Labs-Research973-761-6105benveniste@ieee.or g

2. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh networks Mathilde Benveniste Avaya Labs

3. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Introduction Currently the service period is triggered –If a power-saving MP does not have traffic to send, it must send a NULL frame –This gives rise to additional transmissions, which are not necessary under a different specification of the peer service period: the Scheduled Service Period –Scheduled service periods reduce transmissions Currently the Awake period is defined to start at the beacon –This may require an MP to wake up more than once per beacon period –A more flexible definition can increase battery life The number of frames it will receive at any time should be controlled by the power-saving MP

4. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Max PSP Length An MP may limit the duration of a service period by setting the Max PSP Length field The field value may vary over time –It can be updated through the MP’s beacon

5. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Rationale for expanding the Awake Window specification Currently the Awake period specified through the beacon element is restricted to start at the beacon –This may require an MP to wake up more than once per beacon period –A more flexible definition can increase battery life A longer awake period consumes power Waking up multiple times consumes power

6. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Current: Light Sleep Mode Suppose all three MPs are in LS mode and that MP2 has as peers MP1 and MP3. MP2 cannot hear the TIM from MP1 and MP3 If traffic travel both directions, the Awake Period must start before the beacon if one wants to avoid waking up more than once per period or extending the awake period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

7. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Current: Light Sleep Mode Suppose all three MPs are in LS mode and that MP2 has as peers MP1 and MP3. MP3 and MP2 cannot hear the TIM from MP2. To be able to do so, they must wake up twice in a period If traffic travel both directions, the Awake Period must start before the beacon if one wants to avoid waking up more than once per period or extending the awake period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

8. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Current: Light Sleep Mode Suppose all three MPs are in LS mode and that MP2 has as peers MP1 and MP3. MP2 cannot hear the TIM from MP1, and MP3 cannot hear the TIM from MP2. To be able to do so, it must wake up twice in a period If traffic travel both directions, the Awake Period must start before the beacon if one wants to avoid waking up more than once per period or extending the awake period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

9. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Awake period Proposed: Light Sleep Mode Traffic can be retrieved by all three MPs in a single Awake Period per beacon period Shortens Awake time or number of Awake periods – saves battery life Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3

10. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Proposed Awake Window Element Awake Window: duration of awake window Awake Window End: tine awake window ends relative to beacon time Max PSP Length : maximum length of Peer Service Period

11. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Awake Period An MP in power save mode shall remain awake for the duration of the Awake Window The start time of the Awake period is set relative to the beacon following the beacon with an Awake Window IE at {Awake Window End Time – Awake Window} Ps-MP1 Awake period Awake Period End

12. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Rationale for Proposed Peer Service Periods Currently the service period is triggered –If a power-saving MP does not have traffic to send, it must send a NULL frame to use as a ‘trigger’ for a service period –This gives rise to additional transmissions, which are not necessary under a different specification of the peer service period: the Scheduled Service Period –Scheduled service periods reduce power consumption

13. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Assumptions 1.An MP in Light Sleep mode is in Awake state for the beacons of its peers 2.An MP is Deep Sleep is not required to wake up for any beacons

14. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Proposed Peer Service Periods A peer service period is initiated in two ways: Triggered Service Period: A peer service period may be initiated by an MP with frames buffered for a peer MP in power save mode upon receipt of a peer trigger frame, which is a data frame or a QoS-Null frame that requires acknowledgement sent by the peer MP –[Necessary for MPs in Deep Sleep mode] Scheduled Service Period: A MP with frames buffered for a peer MP in light sleep mode many initiate a peer service period following the transmission of its beacon and before the Awake Window End time of the peer MP –[Eliminates the need for triggers to be sent to start a service period]

15. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Operation with Scheduled PSP An MP in Light Sleep mode must be in Awake state for the beacons of its peers –Exactly when is indicated in the Awake Window element in its beacon Since a buffering MP knows when its peers will be awake, it can send buffered traffic subject to the constraint of the Max PSP length A buffering MP will send buffered frames to their peer MPs that are still in Awake state An MP in LS mode must stay awake until the Awake Window End time if it is not receiving, or until it receives a frame with the EOSP bit set

16. doc.: IEEE 802.11-08/0619r0 Submission May 2008 M. Benveniste (Avaya Labs) Conclusions Allowing the Awake Period to start before the beacon increases battery life Scheduled service periods eliminate the need for NULL trigger frames; hence they conserve battery Restricting the length of the service period gives control to the MP on the number of frames it will receive at any time