Broadcast and Multicast Enhancements November 2005 doc.: IEEE 802.11-05/1075r0 November 2005 Broadcast and Multicast Enhancements Date: 2005-11-16 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>. Jari Jokela et al, Nokia Jari Jokela, Nokia

November 2005 doc.: IEEE 802.11-05/1075r0 November 2005 Abstract This presentation highlights some problems with the current broadcast and multicast functionality of the 802.11. This proposal includes some enhancements to the current BC/MC schemes. Proposal is related to Req#1300, 2010, 2070 (05/0827r3) Normative text: 05/1074r0, 05/1076r0 Jari Jokela et al, Nokia Jari Jokela, Nokia

Problems with current bc/mc services November 2005 Problems with current bc/mc services Power save Fixed and static power save scheme based on DTIM ’concept’ No separation between bc and mc services May lead to nasty traffic peaks in the network Many active multicast services => all the data delivered after DTIM May not scale well considering potential future bc/mc services Reliability No acknowledgements Often unacceptable frame loss rates For some services frame loss may be critical issue No other reporting mechanisms to indicate lousy performance Jari Jokela et al, Nokia

BC/MC powersave in base 802.11 November 2005 BC/MC powersave in base 802.11 In case of one or more STAs are in PS mode, AP buffers BC/MC frames. In next DTIM Beacon frame AP includes indication of buffered bc/mc frames and immediately delivers buffered bc/mc frames Indication by using AID 0 for both broadcast and multicast data No separation between bc/mc and between different mc services Beacon period and DTIM period can be freely chosen by the AP DTIM period length may affect to long term power consumption Wi-Fi Alliance test plans sets some requirements for Beacon and DTIM intervals 802.11e did not modify mc/bc power save functionalities Jari Jokela et al, Nokia

Misc. issues related to BC/MC power save November 2005 Misc. issues related to BC/MC power save During the (re)association STA can indicate its listen interval. Indicates how often STA will wake up to listen Beacon frames AP may use this information to determine the lifetime of buffered frames Not clear whether this is intended for unicast data only or for bc/mc as well? MLME-POWERMGT.request includes option to allow STA not to listen all the DTIM Beacon frames. Jari Jokela et al, Nokia

Characteristics of bc/mc services November 2005 Characteristics of bc/mc services Broacast and multicast services may have very different traffic charactericstics Basic IP-level broadcast services (DHCP, ARP,…) typically does not have tight requirements in terms of latency or bit rate but may have tight requirements in terms of frame loss Multicast streaming services (audio, video,…) on the other hand may have relatively tight requirements in terms of latency, bit rate and frame loss. Service interval can vary a lot Typical Beacon interval ~100ms => min. DTIM interval => powersave based on legacy bc/mc powersave is not feasible in all of the cases => Need for finer granularity for power save Problem is that in WLAN MAC level we have just single and fixed power save mechanism to serve wide variety of bc/mc services. Additionally reliability is a big problem. Jari Jokela et al, Nokia

Terminal stand-by time issues November 2005 Terminal stand-by time issues Terminals stand-by times are largely dependent on how often terminal need to listen the network. From the pure power save point of view listening very seldom would be beneficial. However, this may not be so straightforward. Missing too many DTIM may cause significant problems if e.g., some ARP frames are missed Longer listen interval => longer delays generally. Maybe an issue e.g., in case of VoIP. However, target should be that terminals stand-by listen interval is > 1 sec. ≈ DTIM interval Jari Jokela et al, Nokia

Proposal Enable broadcast/multicast to unicast mapping November 2005 Proposal Enable broadcast/multicast to unicast mapping More reliable service Use (modified) autonomous triggered reporting to facilitate service mode selection 802.11n ’aware’ multicast transmission scheme (informative) Use legacy DTIM as broadcast interval Basic services like DHCP, ARP etc. DTIM interval should be long enough (> 1 sec) Enable more flexible listen interval usage for the multicast services Multicast Service Setup and Multicast Service Termination Multicast Service Mode Change Multicast Service Info advertisement Jari Jokela et al, Nokia

Capabilities advertising November 2005 Capabilities advertising Radio Resource Management Capabilities sent in the Beacon and Probe Response frames Non-AP STAs can indicate its capabilities during the Association Capabilities to be advertised Broadcast/Multicast to unicast conversion Flexible multicast listen interval Multicast diagnostic capabilities Multicast ACK capability (802.11n ’aware’ functionality) Proxy ARP existence in the AP Jari Jokela et al, Nokia

Multicast Service Setup procedure November 2005 Multicast Service Setup procedure Intended to serve three purposes: Enable Multicast => unicast conversion Used to control multicast service modes Used to setup multicast group specific listen intervals AP non-AP STA IP level multicast join/setup Multicast Service Setup Request Multicast Service Setup Response Multicast Service Mode Change Jari Jokela et al, Nokia

Multicast Service Info advertisement November 2005 Multicast Service Info advertisement Multicast Service Info is transmitted in every beacon Exists only if enhanced bc/mc services are used Includes information about broadcast service Broadcast transmit mode Transmit mode change indication Buffered broadcast data indication Includes information about active multicast services within the BSS Multicast address Multicast listen interval Buffered multicast data indication Jari Jokela et al, Nokia

Broadcast and Multicast Service Modes November 2005 Broadcast and Multicast Service Modes It is up to AP to decide the service mode and it is out of scope of the standard. AP may use e.g., load information, 802.11k measurements or Multicast Diagnostics to determine the optimal service mode Service mode may be set STA by STA basis If unicast mode is used then normal unicast transmission and power save rules apply Broadcast/multicast to unicast conversion Usage of ACKs possible Usage of optimal PHY rates per each terminal Fully dynamic mode selection enables optimal mode selection STA by STA basis. Improved security (ref. TGw) Waste of capacity. Not suitable solution in medium-high load situations Fully dynamic mode selection may be rather complicated from the AP point of view However there are options to make it more static way => implementation becomes a lot easier Jari Jokela et al, Nokia

Flexible Multicast Listen Intervals November 2005 Flexible Multicast Listen Intervals Allows more suitable listen interval usage => optimised power save Avoid traffic peaks in the network Operation is similar as in legacy case except the listen interval may be different than DTIM interval. By default DTIM interval is used Usage of other interval than DTIM interval requires that at least one STA completes the Multicast Service Setup signalling. Jari Jokela et al, Nokia

November 2005 Multicast Diagnostic Based on Triggered Autonomous Reporting defined in TGk Fundamental difference is that in this case non-AP STA is measuring the DL multicast traffic and not UL traffic. Triggering conditions setup using Multicast Diagnostic Request Can be set for Broadcast as well Reporting can be based on one condition: Timeout report generated if no multicast frames received during specified time interval Others possible Possible to use ’request’ mode as well Jari Jokela et al, Nokia

802.11n ’aware’ multicast transmission (informative) November 2005 802.11n ’aware’ multicast transmission (informative) Frames sent using multicast MAC address UL ACKs scheduled with PSAD/PSMP structure AP may select the non-AP STA(s) that send acknowledgement Jari Jokela et al, Nokia

Legacy interoperability issues November 2005 Legacy interoperability issues In order to support legacy terminals AP shall send broadcast and multicast frames according to legacy rules even if some non-AP STAs are using enhanced capabilities. Buffered bc/mc sent after DTIM Beacon Usage of TIM field remains the same More data bit set as in legacy case If AP knows that all the associated STAs are capable of using enhanced services it may use only enhanced capabilities. Jari Jokela et al, Nokia

Summary Legacy broadcast/multicast operation has some severe problems November 2005 Summary Legacy broadcast/multicast operation has some severe problems Reliability Fixed power save scheme Improvements proposed Broadcast/multicast to unicast conversion Flexible multicast service intervals Multicast Diagnostics for multicast services Jari Jokela et al, Nokia