1. September 2006
doc.: IEEE /1351r0
September 2006
Overview of Broadcast Power Save Optimizations for s Mesh Networks
Date:
Authors:
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 < 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 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
George Calcev, Motorola
George Calcev, Motorola

2. September 2006
doc.: IEEE /1351r0
September 2006
Abstract
This submission proposes a modification of the frame transmission rules defined for MP operating in PS mode. The proposal permits short broadcast or multicast frames to be transmitted during the ATIM window in order to reduce power consumption of MP. Comment 161 is addressed by this submission.
George Calcev, Motorola
George Calcev, Motorola

3. Overview of the Problem
September 2006
Overview of the Problem
The successful delivery rate of multicast/broadcast transmissions is lower than for unicast traffic
Multicast/broadcast transmissions are not retransmitted
When an idle MP operating in power save mode wakes up to receive a multicast/broadcast frame, it stays awake until it either:
Receives a frame with MD=0, or
Until at least the end of the next ATIM window if the frame is not received
If a MP in power save mode stays awake for the interval between ATIM windows, battery life suffers
Problem is larger for mesh points than for stations because the mesh uses broadcast frames to set up and maintain routes
George Calcev, Motorola

4. Illustration of the Problem in a Mesh
September 2006
Illustration of the Problem in a Mesh
In Figure 1, the broadcast route request frame sent by MP1 does not reach MP2 or MP3
MP operating in PS mode must stay awake until receiving a frame with the MD=0
MP4 and MP5 can return to sleep after receiving the RREQ message,
MP2 and MP3 must remain awake until at least the next ATIM window (drawing battery power)
Additionally, MP1 must transmit 2 frames to neighbors in PS mode instead of 1
The two frames it transmits are an ATIM frame plus the RREQ frame (adds to congestion)
MP1
MP2
MP3
MP4
MP5
RREQ
Figure 1 – MP1 sends RREQ frame to MP2 through MP5
George Calcev, Motorola

5. Overview of the Solution
September 2006
Overview of the Solution
Allow MP to transmit short broadcast/multicast frames during the mesh ATIM window
Replaces ATIM frames that announce the presence of short multicast/broadcast frames with the frame itself
Length of short multicast/broadcast frames should be on the order of 1 to 2 times the length of ATIM frames
Longer frames should be transmitted outside the ATIM window and only after transmitting ATIM frame in window
Allow MP in PS mode receiving short broadcast/multicast frames during ATIM window to sleep after end of window
If the MD bit of the short broadcast/multicast frame equals 1, meaning more data frames are pending, the MP should remain awake
George Calcev, Motorola

6. Examples of Short Broadcast Frames
September 2006
Examples of Short Broadcast Frames
The following management frames in s may potentially qualify as short broadcast frames (this is in addition to potentially other short broadcast frames received from higher layer).
Note: (Size of ATIM Frames = SizeofMgtFrame = 26 bytes)
Frame
Description
Size (Bytes)
Route Requests
Request for new route to destination, may be transmitted periodically or on demand (N = number of destinations)
SizeOfMgtFrame + 26+N*11
Root Announcements
Frame under development in the routing group for announcing metric to root portal
SizeOfMgtFrame + 23
Neighborhood Congestion Announcements
Announces congestion level in neighborhood of transmitting mesh point
SizeOfMgtFrame + 7
Route Error
Announces link break has been detected or a route error has been received from another nodes
SizeOfMgtFrame + 6+N*10
George Calcev, Motorola

7. Benefits
September 2006
The benefits of the proposal may be illustrated using a simple “what if” analysis involving periodic RREQ frames
Top line in graph shows duty cycle of MP that exhibits PS-a behavior for one beacon interval (e.g. when BC frame sent outside ATIM window and lost) and PS-b behavior for “N” beacon intervals (all other BC frames received)
Assume node exhibits one of two power save behaviors
PS-a; Stays awake for full 100 ms beacon interval (e.g. waiting for lost BC frame)
PS-b; Stays awake for only 20 ms ATIM window (e.g. sleeps after receiving BC frame during ATIM window or immediately thereafter when frame is not lost)
“What if” scenario assumptions and results
4 neighbors, each sending 1 periodic RREQ per second (e.g average of 5 frames per ~12 beacon intervals)
20% frame loss rate
On average, MP waiting for BC traffic misses about one RREQ per 12 beacon intervals (N=11)
Proposal drops average duty cycle (percentage of time MP is awake) by about 6 percentage points in this scenario
Bottom line in graph shows duty cycle of node that sleeps after every ATIM window
George Calcev, Motorola

8. Proposed Changes to Draft
September 2006
Proposed Changes to Draft
Minor changes required to clause 11A.8 in draft
Modify bullet point in clause 11A.8.4 to permit broadcast/multicast frames to be transmitted during ATIM window
Add bullet point to clause 11A.8.4 defining conditions under which an MP may transmit broadcast/multicast frame during ATIM window
Add bullet point to clause 11A.8.3 allowing MP receiving a broadcast/multicast frame to sleep following end of ATIM window
Modify bullet point in clause 11A.8.3 defining conditions after which MP may return to sleep upon receiving broadcast/multicast frame
George Calcev, Motorola

9. September 2006
Next Steps
Draft text describing the proposed modification to mesh power save is in doc 11-06/1350r0
Questions?
George Calcev, Motorola