1 / 13

Harmonizing Multicast/Broadcast Proposals

Harmonizing Multicast/Broadcast Proposals. Authors:. Date: 2008-09-02. 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

elu
Télécharger la présentation

Harmonizing Multicast/Broadcast Proposals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Harmonizing Multicast/Broadcast Proposals • Authors: • Date: 2008-09-02 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. Options for Sub-Features A2C = AP to client C2A = Client to AP Hart et al (Cisco Systems et al)

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

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

  6. 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) • New management frames • 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)

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

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

  9. 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 • Reuses existing 802.11 technology • Need to avoid BAR to originator • Straw-poll 6: 11aa should allow these methods: • Y, N, A Hart et al (Cisco Systems et al)

  10. 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 • Efficient and lightweight solution • 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 • Extends existing 802.11 technology • 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)

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

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

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

More Related