1 / 13

GAPA - Efficient, More Reliable Multicast

GAPA - Efficient, More Reliable Multicast. Authors:. Date: 2008-05-08. Requirements for Multicast Video. Requirements Very low PLR Low delay and delay jitter Multiple transmissions per beacon period Compatible with legacy STAs Duplicate detection Objectives

vernon
Télécharger la présentation

GAPA - Efficient, More Reliable Multicast

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GAPA - Efficient, More Reliable Multicast • Authors: • Date: 2008-05-08 Hart, Qian (Cisco Systems)

  2. Requirements for Multicast Video Requirements • Very low PLR • Low delay and delay jitter • Multiple transmissions per beacon period • Compatible with legacy STAs • Duplicate detection Objectives • Efficiency (since video throughput can be high) • Feedback for rate adaptation • Compatible with power save Hart, Qian (Cisco Systems)

  3. Few candidate solutions meet these requirements • (1) Existing multicast • No retries, no Acks, no inputs to rate adaptation, sent infrequently • Doesn’t work without retries (3 retries assumed) Hart, Qian (Cisco Systems)

  4. Few candidate solutions meet these requirements • Retransmitting multicast frames a fixed number of times • Inefficient if all receivers receive the frame correctly the first time • No feedback for rate adaptation • Legacy STAs cannot be guaranteed to perform duplicate detection and discarding correctly • (2) Multicast-to-unicast conversion • Increases delay for later receivers • Increases delay jitter for later receivers • Multiplies the number of packets over the air for an already high-throughput application • Can’t be used with bridges if MC-ness not preserved • Retransmitting multicast frames with a delayed Block Ack policy • Block Acks must contend for the medium Hart, Qian (Cisco Systems)

  5. Proposed Solution “Group-Addressed PSMP Ack” (GAPA) is More Efficient and More Reliable • (3) Transmit multicast frames via PSMP • PSMP bursts comprise: • PSMP sequences, which in turn comprise: • Downlink phase – for MC data • Uplink phase – for PSMP Acks to MC data • The first PSMP sequence • Sends the MC data in the DTT • Retrieves scheduled ACKs in the UTT • Subsequent PSMP sequences are used for MC data retries if needed • All within the same TXOP • Scheduled PSMP may make sense for some applications The benefits of GAPA are orthogonal to using scheduling to avoid collisions. Likely both problems need to be solved via complementary proposals Hart, Qian (Cisco Systems)

  6. Three Main Schemes Illustrated Data (1) MC (2) MC2UC Data Data Data ACK2 ACK3 ACK1 (3) GAPA Data ACK1 ACK2 ACK3 Delay Hart, Qian (Cisco Systems)

  7. Anticipated Characteristics of the Three Schemes Hart, Qian (Cisco Systems)

  8. Preliminary Simulations • N x [3 video devices at [24, 54, 130] Mbps in a single BSS with a fixed PER] • Low throughput video (max 360 kbps) • For a delay limit of 20 ms, GAPA allows for a 7 times increase in capacity over MC2UC! • (Courtesy of Luke Qian) ms) Hart, Qian (Cisco Systems)

  9. GAPA is compatible with legacy (= pre-11aa) • Since we cannot depend upon legacy’s ability to perform duplicate detection with MC (see 9.2.9), then retries need to be hidden from legacy • GAPA is hidden from legacy by sending GAPA transmissions to a different MC MAC address • GAPA-capable STAs request GAPA for selected MC TSPECs • The accepted TSPEC response includes an alternative, AP-allocated, otherwise-unused MC address (called GAPA MC MAC address) • If legacy TSPECs are part of the MC group, frames are (also) sent via legacy MC & addressed to the normal MC address • Ignored by STAs with GAPA TSPECs • If GAPA TSPECs are part of the MC group, frames are (also) sent via GAPA & addressed to that MC group’s GAPA MC MAC address • GAPA BC is sent to a special MAC address (TBD – e.g. ff-ff-ff-ff-ff-fe) • BA agreement (rather than TSPEC) may be sufficient • GAPA MC duplicate detection is provided by: • Same sequence number for all retries Hart, Qian (Cisco Systems)

  10. GAPA can be robust to lost STAs • If retries are exhausted for a specific STA say a threshold number of PSMP bursts in a row, possibly that STA has roamed away without disassociating / been turned off / etc. • Call this a lost STA • The AP may disassociate the lost STA, or decline that lost STA’s TSPEC, or no longer send retries if only lost STAs have not Acked the MC data Hart, Qian (Cisco Systems)

  11. Summary of GAPA Benefits • All STAs receive the data simultaneously • Reduced delay and delay jitter • Data is sent once and only retried when necessary • Better capacity • Acks are scheduled as efficiently as possible • Better capacity, reliability, and enables rate adaptation • Compatible with power saving mechanisms • Compatible with legacy MC/BC • GAPA provides for duplicate detection • GAPA is complementary to collision-avoidance scheduling mechanisms Hart, Qian (Cisco Systems)

  12. Questions ? Hart, Qian (Cisco Systems)

  13. Strawpoll • Would you support the GAPA scheme in 11aa? Hart, Qian (Cisco Systems)

More Related