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

Options for Sub-Features September 2006 doc.: IEEE 802.11-06/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.

Duplicate detection Background: September 2006 doc.: IEEE 802.11-06/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.

Legacy compatibility July 2008 Background: September 2006 doc.: IEEE 802.11-06/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 × 10-14 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.

Setting up the MRBM stream September 2006 doc.: IEEE 802.11-06/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.

Setting up the BA agreement September 2006 doc.: IEEE 802.11-06/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 802.11 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.

Teardown Background: How does an AP or client quit? September 2006 doc.: IEEE 802.11-06/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.

Generalization of BAR, BA (1) September 2006 doc.: IEEE 802.11-06/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 802.11 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.

Generalization of BAR, BA (2) September 2006 doc.: IEEE 802.11-06/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 802.11 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.

Capability signaling Some proposals have it, with little detail September 2006 doc.: IEEE 802.11-06/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.

Unresolved Work (1) July 2008 Power Save September 2006 doc.: IEEE 802.11-06/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.

Unresolved Work (2) July 2008 Repair Requests (Nacks) September 2006 doc.: IEEE 802.11-06/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.