More Reliable Multicast/Broadcast (MRMB) September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 More Reliable Multicast/Broadcast (MRMB) Date: 2008-07-03 Authors: Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Requirements for Multicast Video September 2006 doc.: IEEE 802.11-06/1458r0 July 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 Flexibility (high reliability and efficiency vs high scalability - 100s in MC group) In harmony with FBMS Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Previous work: “Group-Addressed PSMP Ack” September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Previous work: “Group-Addressed PSMP Ack” 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 PSMP 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 et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Latest work: “More Reliable MC/BC” (MRMB) supports multiple MC/BC Ack modes MC/BC retransmission and Ack mode Initial MC/BC frame Retries of MC/BC frame Ack scheme Notes MC frame sent to the legacy MC address None No Ack Legacy MC/BC. No retransmissions 1 Any number of retries sent to the retry address No BARs sent Legacy MC/BC in the BSS, then any number of retries to the retransmission MC/BC address irrespective of any ACK; no PSMP. 2 BAR + BA Block Ack requests may be sent to all or a (possibly time-varying) subset of 11aa-enabled group members; AP may (or may not) send additional retries to retry address for failed packets, perform rate adaptation, etc; no PSMP. 3 Any number of retries sent to the retry address within PSMP sequences Implicit BA + PSMP Ack BAs scheduled for all or a (possibly time-varying) subset of group members; retransmissions sent in subsequent PSMP sequences; requires that all the 11aa-enabled STAs in the group are PSMP-capable, else AP reverts to mode (0,) 1 or 2 4 MC frame sent to the legacy MC address within first PSMP sequence Any number of retries sent to the retry address within subsequent PSMP sequences BAs scheduled for all or a (possibly time-varying) subset of group members; retransmissions sent in subsequent PSMP sequences; requires that all the STAs in the group are 11aa-enabled and PSMP- capable, else AP reverts to mode (0,) 1, 2 or 3 Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Examples of the new MC/BC Ack modes September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Examples of the new MC/BC Ack modes MCA = MC MAC address Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Frame exchanges for MRMB September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Frame exchanges for MRMB Capability exchange (already finished by the end of association) The client unicasts a new action frame ADDMRMB.request to request MRMB for a specified legacy BC/MC MAC address The AP unicasts a new action frame ADDMRMB.response to accept the ADDMRMB.request And to report the retry MAC address The AP promptly unicasts an ADDBA.request to the client indicating the specified stream The client unicasts an ADDBA.response to the AP The AP (continues to) send MC/BC traffic. For legacy reasons, the Ack Policy in the QoS Control field in MC/BC data frames is always “No Ack”; nevertheless the client recognizes it has a BA agreement and stores appropriate BA state At the AP’s discretion, the AP unicasts or MC/BCs the BAR to the client(s) In mode 1, the AP never sends BARs To avoid the MC/BC BAR from creating a BA storm, a BAR to a MC/BC RA shall be followed by delayed BAs with enlarged randomized backoffs For deletion of the BA agreement, the AP unicasts, the AP MC/BCs (with retries) or the client unicasts DELBA For deletion of the MRMB stream, the AP unicasts, the AP MC/BCs (with retries) or the client unicasts DELMRMB Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

How is the MRMB address identified in the different frames? (1) September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 How is the MRMB address identified in the different frames? (1) How should the MRMB stream be identified in all frames? Ideally, simply by MC/BC address But we’ll see TID 8-15 is more backwards compatible ADDBA.request has DA [client], SA [AP], BSSID, TID (in the BA Control field) ADDBA.response has DA [AP], SA [client], BSSID, TID DELBA has DA [AP or client], SA [client or AP], BSSID, TID i.e. all or these have TID yet none of these presently have room for a MC/BC address There is legacy concern with appending a MC/BC address Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

How is the MRMB address identified in the different frames? (2) September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 How is the MRMB address identified in the different frames? (2) BAR has RA, TA [AP] and TID in the BA Control field TA must equal the AP MAC address to avoid OBSS ambiguity/coordination RA can equal the MC/BC address – for MC/BC BARs But, some use cases need unicast MC/BC BARs so here RA equals the client MAC address. Options: New control frames [Delays feature uptake] Append fields to existing BAR [Delays feature uptake] Require the granularity of MRMB to be the TC, not per individual MC/BC address. [Crude and behavior for unwanted/a priori unknown MC/BC addresses needs further study] Allow TID 8-15 to be used as a shorthand for a MC/BC address, with the mapping established during the ADDMRMB exchange (like a TSID established by a TSPEC using an Ethernet TCLAS) Note: This is not intended to preclude existing or future features from consuming other TIDs in the 8-15 range Or instead use 3 bits of the 9 reserved bits in the BA Control field [Not preferred] Either way, different STAs joining different MRMB streams at different times can consume different TSIDs, so it is unlikely all STAs have the same value free for a late-coming MRMB stream; thus, for a common TSID per MRMB stream, an AP cannot guarantee more than 8 simultaneous MRMB streams per BSS [Too limiting?] Or don’t require a common TSID per MRMB stream; allow clients to choose their own. Client processing is: If RA is a MRMB address, ignore the TSID; else (if RA is unicast), map the TSID 8-15 to a MC/BC address; with this there are up to 8 simultaneous MRMB streams per STA [Complicates the client but best solution] Set the TID value to the TC when RA == MRMB address Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

How is the MRMB address identified in the different frames? (3) September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 How is the MRMB address identified in the different frames? (3) BA has RA [AP], TA [client] and TID in the BA Control field RA should equal the AP MAC address to simplify OBSS ambiguity/coordination Same options as with BAR, with one change: Allow TID 8-15 to be used as a shorthand for a MC/BC address, with the mapping established during the ADDMRMB exchange (like a TSID established by a TSPEC using an Ethernet TCLAS) Different STAs joining different MRMB streams at different times can consume different TSIDs, so it is unlikely all STAs have the same value free for a late-coming MRMB stream; thus, for a common TSID per MRMB stream, an AP cannot guarantee more than 8 simultaneous MRMB streams per BSS [Too limiting?] Or don’t require a common TSID per MRMB stream; allow clients to choose their own. Client always uses its TSID for the MRMB stream, and the AP maps {TA,TSID} to specific MRMB stream Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Retry MAC addresses Define a well-known BC retry address September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Retry MAC addresses Define a well-known BC retry address ff-ff-ff-ff-ff-fe Recommend a method to allocate MC retry addresses If the MRMB stream is an IEEE-administered address, make the retry address the same except locally administered, unless that is already in use Else, allocate an unused locally administered MAC address from ff-ff-ff-ff-00-00 to ff-ff-ff-ff-ff-fd (65534 addresses) Only requires uniqueness within the BSS since the legacy MC address is reused for subsequent hops / bridge segments The legacy address and retry address are treated as synonymous for 11aa-enabled devices The legacy address is used in all frames except for retries and setting up the retry address Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Shape of Standards Work September 2006 doc.: IEEE 802.11-06/1458r0 July 2008 Shape of Standards Work Define appropriate capability fields and MIB variables Require duplicate detection for BC/MC addresses, especially retry addresses And sequence number preservation for BC/MC retries Define actions frames to request/accept/delete MRMB Define how TIDs 8-15 identify a specific MRMB stream Define procedures for initiating a MRMB stream, for error recovery, etc Hart et al (Cisco Systems et al) Joonsuk Kim, Broadcom Corp.

Summary of Benefits July 2008 All STAs receive the data simultaneously (modes 1-4) Reduced delay and delay jitter Data is sent once and only retried when necessary (modes 2-4) Better capacity Flexible Ack policy No Acks (mode 1) Most scalable, simplest Block Acks for all or a (possibly time-varying) subset of clients (mode 2) Flexible, easier to support than PSMP Acks PSMP Acks for all or a (possibly time-varying) subset of clients (modes 3-4) are scheduled efficiently (modes 3-4) Efficient, reliable, enables rate adaptation Compatible with power saving mechanisms Compatible with legacy MC/BC Provides for duplicate detection Complementary to collision-avoidance scheduling mechanisms Hart et al (Cisco Systems et al)

Next Steps Gather input on MC/BC address identification July 2008 Next Steps Gather input on MC/BC address identification Write normative text Harmonize with FBMS Hart et al (Cisco Systems et al)

July 2008 Questions ? Hart et al (Cisco Systems et al)

Strawpoll 1 July 2008 Vote for H or to disapprove of 0 or more of A-G: A. New control frames for BA/BAR B. Append fields to existing BA/BAR C. Require the granularity of MRMB to be the TID, not per individual MC/BC address. D. Allow TID 8-15 to be used as a shorthand for a MC/BC address, with the mapping established during the ADDMRMB exchange (like a TSID established by a TSPEC using an Ethernet TCLAS), with 1 TID for all STAs in the MRMB stream E. Allow TID 8-15 to be used as a shorthand for a MC/BC address, with the mapping established during the ADDMRMB exchange (like a TSID established by a TSPEC using an Ethernet TCLAS), with each STA allowed to have a different TID for the same MRMB stream F. Same as D except use 3 bits of the 9 reserved bits in the BA Control field G. Same as E except use 3 bits of the 9 reserved bits in the BA Control field H: Abstain Hart et al (Cisco Systems et al)

Strawpoll 2 Would you support the MRMB scheme in 11aa? Y N A July 2008 Hart et al (Cisco Systems et al)