1. Harmonizing Multicast/Broadcast Proposals
September 2006
doc.: IEEE /1458r0
July 2008
Harmonizing Multicast/Broadcast Proposals
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
SW upgrade for 11n implementations
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

3. Options for Sub-Features
September 2006
doc.: IEEE /1458r0
July 2008
Options for Sub-Features
A2C = AP to client
C2A = Client to AP
08/766r0
08/803r0
08/809r1
08/810r0
08/816r2
Capability Y -
MC setup
AP snoops IGMP, sends IGMP query
New mgmt frame A2C ADDMBBA req/resp
New mgmt frame C2A ADDMRBM req/resp
Block Ack setup
Conventional ADDBA A2C req/C2A resp
Generalizatio n of BAR, BA
Conventional UC BAR, BA with cyclic BARs, identified by TIDs
New ctrl frame MBBA Req schedules new ctrl frames MBBA Ack from clients via AID, start offset, duration; also conventional BAR/BA and normal Ack
New ctrl frame M- BlockAckReq schedules new client ctrl frames M-Block Acks from clients via receiver bitmap control and partial virtual bitmap; or conventional Acks or no Acks or M-Block Acks within PSMP
No BAR; conventional UC or MC BAR, BA; or implicit BAR, BA scheduled by PSMP
Block Ack teardown
A2C or C2A LVMBBA
Conventional A2C or C2A DELBA
MC teardown
New mgmt frame A2C or C2A DELMRBM
Legacy compatibility
“Required”
Retry MAC address
Duplicate detection
Avoid BAR to MC originator
Other
TXOP protection
TXOP protection
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

4. Duplicate detection Background:
September 2006
doc.: IEEE /1458r0
July 2008
Duplicate detection
Background:
Not required in the past for BC/MC as BC/MC is not retried
Now topical since 11aa enables BC/MC retries
One proposal has it
Some proposals omit it, yet no proposal says it is not necessary
Straw-poll 1: 11aa devices shall reuse the same sequence number for retries (on transmit) and perform duplicate detection (on receive)
Y, N, A
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

5. Legacy compatibility July 2008 Background:
September 2006
doc.: IEEE /1458r0
July 2008
Legacy compatibility
Background:
Legacy need not & may not perform duplicate detection
IP header can be used for duplicate detection, yet we build L1/L2 standards and cannot depend on a particular L3 std
This can be read as a requirement from the 802 Overview and Architecture requirements 7.3 c [The probability that an MSDU delivered at an MSAP contains an undetected error, due to operation of the MAC service provider, shall be less than 5 × per octet of MSDU length.]
Now topical since 11aa enables BC/MC retries
One proposal has it, one proposal indicates it is required
Some proposals omit it, yet no proposal says it is not necessary
Straw-poll 2: 11aa devices shall hide retries from legacy stations
Y, N, A
Straw-poll 3: For each MRMB address, 11aa devices shall have a retry address, and retries shall be transmitted to the retry address
Y, N, More Brainstorming Required, A
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

6. Setting up the MRBM stream
September 2006
doc.: IEEE /1458r0
July 2008
Setting up the MRBM stream
Background:
How does a client request MC/BC retries?
IGMP snooping
Layer violation
No room for specifying a retry address
No positive request for MRMB
A2C request, C2A response combined with BA agreement (ADDMBBA)
New management frames
Not client initiated
C2A request, A2C response (ADDMRMB)
Extra frame exchange
Straw-poll 4: Preferred method to setup a MRBM stream is:
a) IGMP snooping
b) A2C req, C2A resp combined with BA agreement req/resp (ADDMBBA)
c) C2A req, A2C resp (ADDMRMB)
d) Abstain
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

7. Setting up the BA agreement
September 2006
doc.: IEEE /1458r0
July 2008
Setting up the BA agreement
Background:
Some sort of BA agreement is needed before soliciting client if & which packets are received correctly
Conventional ADDBA.request and ADDBA.response
Needs prior MRMB setup frame(s) or new versions of BAR and BA
Reuses existing technology
A2C request, C2A response combined with BA agreement (ADDMBBA)
New management frames
Not client initiated
Straw-poll 5: Preferred method to setup some sort of a BA agreement:
a) Conventional ADDBA
b) Combined setup and ADDBA (ADDMBBA)
c) Abstain
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

8. Teardown Background: How does an AP or client quit?
September 2006
doc.: IEEE /1458r0
July 2008
Teardown
Background:
How does an AP or client quit?
Similar options to MRMB setup and BA agreement setup
DELBA then DELMBBA
LVMBBA
No strawpoll since the teardown choice should equal the setup choice but in reverse
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

9. Generalization of BAR, BA (1)
September 2006
doc.: IEEE /1458r0
July 2008
Generalization of BAR, BA (1)
Background:
Need to solicit BAs and efficiently harvest BAs
Easy options on this slide
No Ack
Suitable when many clients in MC group
Reuses existing technology
Conventional unicast BAR specifying a TID
Can efficiently harvest BAs from a few clients per data frame only
Need to avoid BAR to originator
Straw-poll 6: 11aa should allow these methods:
Y, N, A
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

10. Generalization of BAR, BA (2)
September 2006
doc.: IEEE /1458r0
July 2008
Generalization of BAR, BA (2)
Background:
Need to solicit BAs and efficiently harvest BAs
Tougher options on this slide
MBBA Req schedules MBBA Acks from clients via AID, start offset, duration
New control frames MBBA Req and MBBA Ack
Efficient and lightweight solution
M-BlockAckReq sequences M-Block Acks from clients via receiver bitmap control and partial virtual bitmap
New control frames M-BlockAckReq and M-Block Ack
M-Block Ack durations need to be agreed upon
Conventional multicast BAR
If MC/BC, requires special back-off provision to avoid a BA storm
Extends existing technology
BAR within PSMP
Use PSMP to schedule the BAs
Straw-poll 7: 11aa should socialize these options with interested parties before selecting 1 or more:
Y, N, A
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

11. Capability signaling Some proposals have it, with little detail
September 2006
doc.: IEEE /1458r0
July 2008
Capability signaling
Some proposals have it, with little detail
Some proposals omit it, yet no proposal says it is not necessary
Straw-person proposal:
an 11aa capability bit, which indicates support for mandatory 11aa features which includes easy MRMB features: e.g. duplicate detection, sequence# preservation, MRMB and BA agreement setup/teardown, No Ack and conventional BAR/BA
an extra capability bit, which indicates support for advanced MRMB features: e.g. new control frames or MC BAR within PSMP
possibly other capability bits if further features with a HW or large SW impact are included
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

12. Unresolved Work (1) July 2008 Power Save
September 2006
doc.: IEEE /1458r0
July 2008
Unresolved Work (1)
Power Save
Currently MC/BC appears after DTIM beacons
MC/BC buffered for n*102.4 ms hurts interactive video (e.g. telepresence)
Clients generally defer while MC/BC is being transmitted after the DTIM beacon, so too much MC/BC sent at the lowest basic rate after the DTIM hurts uplink QoS (e.g. voice)
Allow clients to request (and the AP to determine) whether MC/BC:
Appears after the DTIM beacon (as at present)
Appears at advertised, scheduled intervals (like scheduled APSD, scheduled PSMP)
At any time, so clients within that MC/BC group need to be in Continuously Awake Mode
(We could straw-poll this now)
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.

13. Unresolved Work (2) July 2008 Repair Requests (Nacks)
September 2006
doc.: IEEE /1458r0
July 2008
Unresolved Work (2)
Repair Requests (Nacks)
Repair requests are more efficient that acknowledgements when PER << 0.5
A necessary precondition for video
Repair requests still need to be acknowledged
The efficiency gains are magnified when there are many members of a MRMB group
Repair requests are complementary to acknowledgement-based schemes
Solicit acknowledgements from some devices
Receive repair requests from others
However, as we get into the details we see
Potential for impact on legacy AP and client hardware
Potential for creating new security holes
Therefore we suggest that repair requests should be thought of as a potential complement and enhancement to acknowledgement-based schemes, requiring further work, that is unlikely to displace the acknowledgement-based schemes in near-term products
Repair requests need not delay progress on acknowledgement-based schemes
Hart et al (Cisco Systems et al)
Joonsuk Kim, Broadcom Corp.