GAPA - Efficient, More Reliable Multicast September 2006 doc.: IEEE 802.11-06/1458r0 May 2008 GAPA - Efficient, More Reliable Multicast Date: 2008-05-08 Authors: Hart, Qian (Cisco Systems) Joonsuk Kim, Broadcom Corp.

Requirements for Multicast Video May 2008 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)

Few candidate solutions meet these requirements May 2008 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)

Few candidate solutions meet these requirements May 2008 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)

May 2008 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)

Three Main Schemes Illustrated September 2006 doc.: IEEE 802.11-06/1458r0 May 2008 Three Main Schemes Illustrated Data (1) MC (2) MC2UC Data Data Data ACK1 ACK2 ACK3 (3) GAPA Data ACK1 ACK2 ACK3 Delay Hart, Qian (Cisco Systems) Joonsuk Kim, Broadcom Corp.

Anticipated Characteristics of the Three Schemes September 2006 doc.: IEEE 802.11-06/1458r0 May 2008 Anticipated Characteristics of the Three Schemes Multicast Unicast PSMP Data frames repeated No (>=1) x #dest 1+#retries ACK Yes Packet Loss Rate Too high to meet requirement Low Delay and delay jitter Too high Capacity High Medium Rate The lowest in the MC group Individual rate for each The lowest of the unAcked members of the MC group Complexity Hart, Qian (Cisco Systems) Joonsuk Kim, Broadcom Corp.

Preliminary Simulations September 2006 doc.: IEEE 802.11-06/1458r0 May 2008 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) Joonsuk Kim, Broadcom Corp.

GAPA is compatible with legacy (= pre-11aa) May 2008 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) is likely sufficient [08/0615r0] GAPA MC duplicate detection is provided by: Same sequence number for all retries Hart, Qian (Cisco Systems)

GAPA can be robust to lost STAs May 2008 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 BA agreement/TSPEC, or no longer send retries if only lost STAs have not Acked the MC data Hart, Qian (Cisco Systems)

Summary of GAPA Benefits May 2008 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)

May 2008 Questions ? Hart, Qian (Cisco Systems)

Strawpoll Would you support the GAPA scheme in 11aa? May 2008 Hart, Qian (Cisco Systems)