doc.: IEEE /1413r1 Submission November 2013 Edward Reuss, UnaffiliatedSlide 1 Real-Time Multicast Streams During Power Save – Part 2 Date: Authors:

doc.: IEEE /1413r1 Submission November 2013 Edward Reuss, UnaffiliatedSlide 2 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 addressed some possible solutions and their limitations. This presentation addresses another proposed solution using GCR-SP.

doc.: IEEE /1413r1 Submission November 2013 Edward Reuss, UnaffiliatedSlide 3 Review - Multicast During Power Save Mode IEEE , , 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

doc.: IEEE /1413r1 Submission November 2013 Edward Reuss, UnaffiliatedSlide 4 Possible Solutions Previously Proposed Solutions: 1.Add a management switch to the AP to disable buffering of all multicast frames. 2.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. 3.Reserve a traffic class & queue for unbuffered multicast services. New Suggested Solutions: –Use GCR-SP for time sensitive multicast services. –????

doc.: IEEE /1413r1 Submission GCR-SP “Groupcast with Retries Service Period” IEEE aa changes 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 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.” November 2013 Edward Reuss, UnaffiliatedSlide 5

doc.: IEEE /1413r1 Submission 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. November 2013 Edward Reuss, UnaffiliatedSlide 6

doc.: IEEE /1413r1 Submission 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? –Both? –No support? –GCR-AP: 5 –AP only: 5 –Both: 9 –No support: 2 November 2013 Edward Reuss, UnaffiliatedSlide 7

doc.: IEEE /1413r1 Submission November 2013 Edward Reuss, UnaffiliatedSlide 8 References “Effect of Power Save on Time-Sensitive Multicast Services”, r1, July IEEE , “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”.