Real time multicast streams during power save part 2
Download
1 / 8

Real-Time Multicast Streams During Power Save – Part 2 - PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on

Real-Time Multicast Streams During Power Save – Part 2. Authors:. Date: 2013-11-12. Abstract.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Real-Time Multicast Streams During Power Save – Part 2' - iren


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Real time multicast streams during power save part 2
Real-Time Multicast Streams During Power Save – Part 2

Authors:

Date:2013-11-12

Edward Reuss, Unaffiliated


Abstract
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
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
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
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
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
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
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


ad