doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh Notice: This document has been prepared to assist IEEE 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors: NameAddressCompanyPhone Mathilde Benveniste 233 Mt Airy Road Basking Ridge, NJ 07920, US Avaya g

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Scheduled service periods in wireless mesh networks Mathilde Benveniste Avaya Labs

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Introduction Currently the service period is triggered –It is not clear how the triggered service periods between peer power- saving MPs will terminate –If a power-saving MP does not have traffic to send, it must send a NULL frame –This gives rise to additional transmissions, which would not be 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 stay awake longer or 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

doc.: IEEE /0619r1 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 PSP length field will be in the Awake Window Element transmitted in the beacon The field value may vary over time –It can be updated through the MP’s beacon

doc.: IEEE /0619r1 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 –The present draft, D2.0 requires an MP in LS mode to stay awake longer than would be otherwise necessary “The MP in light sleep mode may return to the Doze state after the Beacon reception from a peer MP, if the peer MP did not indicate buffered unicast, broadcast or multicast frames.” 11s D2.0, Sub-clause 11A –Alternatively the MP in LS mode may have to wake up more than once per beacon period –A more flexible definition allowing the Awake Window to start before the MPs own beacon can increase battery life A longer awake period consumes battery power Waking up multiple times consumes battery power

doc.: IEEE /0619r1 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 For MP2 to hear the TIM from MP1 and MP3, it must stay awake for most of the beacon period, according to requirement in D2.0 Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 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. For MP3 and MP1 to hear the TIM from MP2, they must stay awake for most of the beacon period, according to requirement in D2.0 Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 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. For MP2 to hear the TIM from MP1, and for MP3 to hear the TIM from MP2, they must stay awake for most of the beacon period, according to requirement in D2.0 Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Modified Light Sleep Mode Suppose that the MP in LS mode can go to sleep before it hears all the beacons of its peers 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 unless it wakes up twice in a beacon period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Modified Light Sleep Mode Suppose that the MP in LS mode can go to sleep before it hears all the beacons of its peers 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, they must wake up twice in a beacon period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Modified Light Sleep Mode Suppose that the MP in LS mode can go to sleep before it hears all the beacons of its peers Suppose all three MPs are in LS mode and that MP2 has as peers MP1 and MP3. MP3 and MP1 cannot hear the TIM from MP2. To be able to do so, they must wake up twice in a beacon period Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3 Awake period

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Awake period Proposed for Light Sleep Mode Proposal: Allow the Awake Window to occur any time as long as beacon is included Buffered traffic can be retrieved by all three MPs in a single short Awake Period per beacon period This feature shortens Awake time and/or lowers the number of Awake periods; both save battery life Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Awake period Proposed for Deep Sleep Mode Proposal: Allow the Awake Window to occur any time Buffered traffic can be retrieved by all three MPs in a single short Awake Period per beacon period This feature shortens Awake time and/or lowers the number of Awake periods; both save battery life Ps-MP1 Ps-MP2 Ps-MP3 Ps-MP1Ps-MP2Ps-MP3

doc.: IEEE /0619r1 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

doc.: IEEE /0619r1 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 Window Awake Period End Time

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Rationale for Proposed Peer Service Periods Currently the service period is triggered A.Unnecessary traffic is generated, which uses up power –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 B.Triggered service periods between two peer power-saving MPs cannot be terminated –A frame with an EOSP=1, which terminates a service period in one direction, serves as a trigger of a service period in the opposite direction –A triggered service must be terminated; thus the peer MP receiving the trigger must also send a frame with an EOSP=1 –This can lead to an infinite exchange of NULL frames with EOSP=1 exchanged between two peer power saving MPs sent to terminate the triggered service periods initiated by these frames

doc.: IEEE /0619r1 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

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Proposed Peer Service Period Scheduled Service Period: A MP with frames buffered for a peer MP in power save mode many initiate a peer service period following the start of an Awake Window and before the Awake Window End time of the peer MP

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Operation with Scheduled PSP Exactly when the MP will awaken is indicated in the last Awake Window element sent in a beacon by the MP An MP in Light Sleep mode must be in Awake state for the beacons of its peers 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 may send buffered frames to its peer MPs that are still in Awake state –At least the first buffered frame in a service period must be acknowledged –If no acknowledgment is received for the first frame in a scheduled service period, the buffering MP re-transmits once. No further attempts are made until the next beacon period.

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Return to Doze State with Scheduled PSP An power-saving MP must stay awake during the Awake Window until its Awake Window End time if it is not receiving, or until it receives a frame with the EOSP bit set if it is receiving, whichever occurs later An MP in LS mode can go to sleep before the Awake Window End time once it has listened to the TIMs of all its peers and its AID is not indicated in any of the TIMs

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Conclusions Allowing the Awake Period to start any time increases battery life Scheduled service periods conserve battery Peer power-saving MPs can use only scheduled peer service periods between them Restricting the length of the service period gives the MP control over the number of frames it will receive at any time

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Comparison of two PS modes Light Sleep Advantage: The power-saving MP can go to sleep sooner if there are frames buffered Disadvantage: The MPs must awaken to hear all beacons Awake periods must have significant overlap More collisions than in Deep Sleep mode for the same time spent awake The buffering MP must send MTIM on the beacons

doc.: IEEE /0619r1 Submission May 2008 M. Benveniste (Avaya Labs) Comparison of two PS modes Deep Sleep Advantage: Less overlap between Awake Windows along a multi-hop path, as the power- saving MP need not hear all beacons The buffering MP need not send MTIM on the beacons Fewer collisions for the same time in Awake state Disadvantage: The power-saving MP must stay awake for the entire Awake Window