May 2008
doc.: IEEE 802.11-08/0619r0
Scheduled service periods in wireless mesh
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
[email protected]
g
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
<[email protected]> 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 <[email protected]>.
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Scheduled service periods in wireless mesh
networks
Mathilde Benveniste
Avaya Labs
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Current: Light Sleep Mode
Ps-MP1
Ps-MP2
Ps-MP3
Ps-MP1
Ps-MP2
Ps-MP3
Awake
period
•
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Current: Light Sleep Mode
Ps-MP1
Ps-MP2
Ps-MP3
Ps-MP1
Ps-MP2
Ps-MP3
Awake
period
•
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Current: Light Sleep Mode
Ps-MP1
Ps-MP2
Ps-MP3
Ps-MP1
Ps-MP2
Ps-MP3
Awake
period
•
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Proposed: Light Sleep Mode
Ps-MP1
Ps-MP2
Ps-MP3
Ps-MP1
Ps-MP2
Ps-MP3
Awake
period
• 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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
Awake
Period End
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Rationale for Proposed Peer Service
Periods
Currently the service period is triggered
–
–
–
Submission
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
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
Assumptions
1.
2.
An MP in Light Sleep mode is in Awake state for the beacons of
its peers
An MP is Deep Sleep is not required to wake up for any beacons
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
–
Submission
[Eliminates the need for triggers to be sent to start a service period]
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)
May 2008
doc.: IEEE 802.11-08/0619r0
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
Submission
M. Benveniste (Avaya Labs)