More Reliable Multicast/Broadcast (MRMB)

1. More Reliable Multicast/Broadcast (MRMB) • Authors: • Date: 2008-07-03 Hart et al (Cisco Systems et al)

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 • Flexibility (high reliability and efficiency vs high scalability - 100s in MC group) • In harmony with FBMS • SW upgrade for 11n implementations Hart et al (Cisco Systems et al)

3. 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)

4. Latest work: “More Reliable MC/BC” (MRMB) supports multiple MC/BC Ack modes Hart et al (Cisco Systems et al)

5. Examples of the new MC/BC Ack modes MCA = MC MAC address Hart et al (Cisco Systems et al)

6. 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)

7. 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)

8. 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 one of TIDs 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 one of the TSIDs 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)

9. 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 one of TIDs 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)

10. 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)

11. 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)

12. Summary of Benefits • 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)

13. Next Steps • Gather input on MC/BC address identification • Write normative text • Harmonize with other BC/MC schemes Hart et al (Cisco Systems et al)

14. Questions ? Hart et al (Cisco Systems et al)

15. Strawpoll • - Write normative text • - Continue to develop the proposal and harmonize with other MC/BC schemes in 11aa • - Don’t keep working on the MRMB scheme • - Abstain Hart et al (Cisco Systems et al)

16. Backup slides 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)

17. Additional Strawpoll 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)