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

September 2006 doc.: IEEE 802.11-06/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

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

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

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

Examples of Short Broadcast Frames September 2006 Examples of Short Broadcast Frames The following management frames in 802.11s 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

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

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

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