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

2. Requirements for Multicast Video
September 2006
doc.: IEEE /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.

3. Previous work: “Group-Addressed PSMP Ack”
September 2006
doc.: IEEE /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.

4. September 2006
doc.: IEEE /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.

5. Examples of the new MC/BC Ack modes
September 2006
doc.: IEEE /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.

6. Frame exchanges for MRMB
September 2006
doc.: IEEE /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.

7. How is the MRMB address identified in the different frames? (1)
September 2006
doc.: IEEE /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.

8. How is the MRMB address identified in the different frames? (2)
September 2006
doc.: IEEE /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.

9. How is the MRMB address identified in the different frames? (3)
September 2006
doc.: IEEE /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.

10. Retry MAC addresses Define a well-known BC retry address
September 2006
doc.: IEEE /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 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.

11. Shape of Standards Work
September 2006
doc.: IEEE /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.

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

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

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

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

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