80 likes | 206 Views
Real-Time Multicast Streams During Power Save – Part 2. Authors:. Date: 2013-11-12. Abstract.
E N D
Real-Time Multicast Streams During Power Save – Part 2 Authors: Date:2013-11-12 Edward Reuss, Unaffiliated
Abstract Real-time multicast services, such as NTP and the Clair Global Aermonix audio delivery system for concerts & festivals, suffer excessive packet delay & jitter whenever a device on the BSS enters Power Save, causing the AP to buffer the packets until after the next DTIM Beacon Frame. This imposes an additional 0 to 100 msec. of random delay, which is too much for these real-time applications. Document 11-13-0792-01 addressed some possible solutions and their limitations. This presentation addresses another proposed solution using GCR-SP. Edward Reuss, Unaffiliated
Review - Multicast During Power Save Mode • IEEE 802.11-2012, 10.2.1.1, fourth paragraph: • “If any STA in its BSS is in PS mode, the AP shall buffer all group addressed BUs and deliver them to all STAs immediately following the next Beacon frame containing a DTIM transmission.” • This is true no matter which multicast services each client STA has joined. • When ANY device on the BSS enters PS, all multicast streams are buffered until the next Beacon Frame. • Adds random packet delay to all time-sensitive multicast packets • 20 msec. up to several seconds of added maximum latency, depending on the beacon and DTIM intervals. • Default: beacon interval = 100 msec. & DTIM = 1 Edward Reuss, Unaffiliated
Possible Solutions • Previously Proposed Solutions: • Add a management switch to the AP to disable buffering of all multicast frames. • Use a table of multicast services and the clients that have subscribed to each one. If no clients that have subscribed to that service are in PS, then do not buffer the multicast packets for that service. • Reserve a traffic class & queue for unbuffered multicast services. • New Suggested Solutions: • Use GCR-SP for time sensitive multicast services. • ???? Edward Reuss, Unaffiliated
GCR-SP • “Groupcast with Retries Service Period” • IEEE 802.11aa changes 10.2.1.1 as follows: • “If any STA in its BSS is in PS mode, the AP shall buffer all non-GCR-SP group addressed BUs and deliver them to all STAs immediately following the next Beacon frame containing a DTIM transmission.” • Also changes 10.2.1.2 Table 10.1 as follows: • “In PS mode, a STA shall be in the Doze state and shall enter the Awake state to receive selected Beacon frames, to receive group addressed transmissions following certain received Beacon frames, to receive transmissions during the SP of a scheduled GCR-SP, to transmit, and to await responses to transmitted PS-Poll frames or (for CF-Pollable STAs) to receive CF transmissions of buffered BUs.” Edward Reuss, Unaffiliated
Implications of GCR-SP for Multicast in PS • GCR-SP does solve the multicast during Power Save issue. • Define Service Period for every time-sensitive multicast service. • GCR-SP must be supported on the AP, and also on all client devices that use a time sensitive multicast service. • Unclear when a majority of client devices will support GCR-SP, if ever. • Previous solutions only require support in the AP, some of which have been implemented and proven. • Channel utilization increases with the number of users subscribed to the multicast service, although this increase is much smaller than for DMS. • GCR retries improve packet delivery to all clients listening to the multicast service. Edward Reuss, Unaffiliated
Straw Poll • Which type of solution does the Study Group suggest for time-sensitive multicast services? • GCR-SP, encouraging vendors to support GCR-SP in all client devices? • An AP only solution? • No support? • GCR-AP: • AP only: • No support: Edward Reuss, Unaffiliated
References • “Effect of Power Save on Time-Sensitive Multicast Services”, 11-13-0792r1, July 2013. • IEEE 802.11-2012, “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”. • IEEE 80211aa-2012, “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 2: MAC Enhancements for Robust Audio Video Streaming”. Edward Reuss, Unaffiliated