May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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 <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 <stuart.kerry@philips.com> 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 <patcom@ieee.org>.

Date: 2008-05-12

Authors:Name Address Company Phone Email

Mathilde Benveniste 233 Mt Airy Road

Basking Ridge, NJ 07920, US

Avaya Labs-Research 973-761-6105 benveniste@ieee.org

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

Scheduled service periods in wireless mesh networks

Mathilde Benveniste

Avaya Labs

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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.12.7.1

– 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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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-MP1 Ps-MP2 Ps-MP3

Awakeperiod

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

Awakeperiod

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-MP1 Ps-MP2 Ps-MP3

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

Awakeperiod

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-MP1 Ps-MP2 Ps-MP3

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

AwakeWindow

AwakePeriod EndTime

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

Rationale for Proposed Peer Service Periods

Currently the service period is triggeredA. 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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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.

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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

May 2008

M. Benveniste (Avaya Labs)

doc.: IEEE 802.11-08/0619r1

Submission

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