doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 1 Broadcast and Multicast Enhancements 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, 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. Date: Authors:

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 2 Abstract This presentation highlights some problems with the current broadcast and multicast functionality of the 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 3 Problems with current bc/mc service 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 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 4 BC/MC powersave in base 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 e did not modify mc/bc power save functionalities

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 5 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.

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 6 Characteristic 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.

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 7 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 8 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 –Base 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 –Multicast Service Info advertisement

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 9 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 10 Multicast Service Setup procedure Intended to serve four purposes: –Enable Multicast => unicast conversion –Used to control multicast service modes –Used to setup multicast group specific listen intervals APnon-AP STA IP level multicast join/setup Multicast Service Setup Request Multicast Service Setup Response Multicast Service Mode Change

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 11 Multicast Service Info advertisement In every Beacon, Multicast Service Info is transmitted 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 12 Broadcast and Multicast Service Modes The service mode selected is up to AP to decide and it is out of scope of the standard. –AP may use e.g., load information, k 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 13 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.

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 14 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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide n ’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

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 16 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.

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 17 Summary Legacy broadcast/multicast operation has some severe problems –Reliability –Fixed power save scheme In this paper some improvements are proposed –Broadcast/multicast to unicast conversion –Flexible multicast service intervals –Multicast Diagnostics for multicast services

doc.: IEEE /1075r0 Submission November 2005 Jari Jokela et al, NokiaSlide 18 Motion#1