1. Broadcast and Multicast Enhancements
March 2006
doc.: IEEE /0370r0
March 2006
Broadcast and Multicast Enhancements
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
Jari Jokela et al, Nokia
Jari Jokela, Nokia

2. March 2006
doc.: IEEE /0370r0
March 2006
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/0827r5)
A new revision of: 05/1075r1
Normative text: 06/0369r0
Jari Jokela et al, Nokia
Jari Jokela, Nokia

3. Problems with current bc/mc services
March 2006
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

4. BC/MC powersave in base 802.11
March 2006
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
802.11e did not modify mc/bc power save functionalities
Jari Jokela et al, Nokia

5. Misc. issues related to BC/MC power save
March 2006
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?
AP can reject association due to too long listen interval requested
MLME-POWERMGT.request includes option to allow STA not to listen all the DTIM Beacon frames.
Jari Jokela et al, Nokia

6. Characteristics of bc/mc services
March 2006
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

7. Terminal stand-by time issues
March 2006
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

8. Proposal Enable broadcast/multicast to unicast mapping
March 2006
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

9. Capabilities advertising
March 2006
Capabilities advertising
Wireless Network Management Capabilities sent in the Beacon and Probe Response frames
Includes bc/mc service related capabilities
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

10. Multicast Service Setup procedure
March 2006
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

11. Multicast Service Info advertisement
March 2006
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

12. Broadcast and Multicast Service Modes
March 2006
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, 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
Jari Jokela et al, Nokia

13. Multicast => unicast conversion
March 2006
Multicast => unicast conversion
Normal data frames (from DS):
Address 1: RA=DA <= this is multicast address
Address 2: TA = BSSID
Address 3: SA
Multicast => unicast converted data frames (from DS):
Address 1: RA=DA <= this is STA’s address
Address 2: TA = BSSID
Address 3: SA
Conversion done only if multicast service setup completed => both AP and STA knows for which multicast addresses conversion applies.
STA can perform further filtering based on other information available (SNAP/Ethertype, IP header, …).
Conversion is not causing problems in simple infrastructure case
Conversion may create problems in mesh networks
Recommendation is not to use conversion in mesh networks
Jari Jokela et al, Nokia

14. Flexible Multicast Listen Intervals
March 2006
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

15. March 2006
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

16. March 2006
Proxy ARP
Intention is to inform non-AP STAs that proxy ARP is enabled in AP/edge router
Intention is not to specify neither the AP/AN detailled operation nor non-AP STA detailled operation – this is just information that the service is available.
Allows non-AP STA to optimise its stand-by operation without sacrificing the basic connectivity
Jari Jokela et al, Nokia

17. 802.11n ’aware’ multicast transmission (informative)
March 2006
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

18. Legacy interoperability issues
March 2006
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

19. Summary Legacy broadcast/multicast operation has some severe problems
March 2006
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

20. March 2006
Straw poll #1
Do you feel that submission 11-06/0369r0 should be considered for inclusion in the TGv draft text as a whole?
Jari Jokela et al, Nokia

21. March 2006
Straw Poll #2
Do you feel that Broadcast/Multicast to unicast conversion to enable more reliable service is generally acceptable?
Jari Jokela et al, Nokia

22. March 2006
Straw Poll #3
Do you feel that it is worthwhile to separate broadcast and multicast power save operations?
Get rid of common service interval (i.e., DTIM based intervals)
Separate More Data fields for broadcast and different multicast services
Jari Jokela et al, Nokia

23. March 2006
Straw Poll #4
Do you feel that flexible multicast service intervals per multicast group is acceptable?
Jari Jokela et al, Nokia

24. March 2006
Straw Poll #5
Do you feel that carrying proxy ARP indication in frames is acceptable?
Jari Jokela et al, Nokia