1 / 9

QBSS Downlink Broadcast and Multicast Data Frame Handling

QBSS Downlink Broadcast and Multicast Data Frame Handling. Sid Schrum Texas Instruments, Inc. sschrum@ti.com. Issue Summary. Which frame format (Basic Data vs. QoS Data) should be used for Data broadcast and multicast MSDUs sent by a QAP is not clearly specified.

javier
Télécharger la présentation

QBSS Downlink Broadcast and Multicast Data Frame Handling

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. QBSS Downlink Broadcast and Multicast Data Frame Handling Sid Schrum Texas Instruments, Inc. sschrum@ti.com Sid Schrum, Texas Instruments, Inc.

  2. Issue Summary • Which frame format (Basic Data vs. QoS Data) should be used for Data broadcast and multicast MSDUs sent by a QAP is not clearly specified. • Several possible QAP behaviors • Affects interoperability • Prioritization of non-best effort Data broadcast and multicast frames is not clearly specified in the current draft. Sid Schrum, Texas Instruments, Inc.

  3. Current Draft • 5.2.5, last paragraph “Non-QoS STAs may associate in a QBSS. All frames that are sent to non QoS STAs by an AP are conformant to IEEE Std. 802.11, 1999 or its extensions, if applicable. An AP also sends frames that are defined in IEEE Std. 802.11, 1999 or its extensions, if applicable.” • 9.10.2 “The HC shall perform delivery of queued broadcast and multicast frames following DTIM beacons in a CFP.” Other Related • 6.1.3 MSDU OrderingReordering of frames between TCs permittedbc/mc not excluded Sid Schrum, Texas Instruments, Inc.

  4. BC/MC Considerations • MAC SAP: does not preclude non-best effort priority parameters for bc/mc • Wired Ethernet: bc/mc frames may be “tagged” with a priority • Broadcast • Targeted for all stations • Might be used for priority protocol signalling • Multicast • Targeted for a limited set of stations • might be used for priority protocol signaling or distribution of multimedia streams Sid Schrum, Texas Instruments, Inc.

  5. Frame Format Considerations • Basic Data Frame • Does not contain priority information • lack of information which otherwise could be used by receiver to provide preferential treatment • Best effort traffic – priority indication not particularly useful • QoS Data Frame • cannot be understood by legacy stations Sid Schrum, Texas Instruments, Inc.

  6. BC/MC Transmit Options Option 1 - Always use Basic Data Frame • Simple • All stations are capable of receiving • Loss of priority information Option 2 - Always use QoS Data Frame • Simple • Only QSTA are capable of receiving • Not an option – precludes backwards compatibility Sid Schrum, Texas Instruments, Inc.

  7. Hybrid Options Option 3 - Use QoS format if no legacy stations associated, Basic otherwise • Best of both options • BUT – behavior may change over time and without warning to STAs Variant Option - Different treatment for bc and mc • Mc are targeted for a group of stations, not all stations • Delivery not intended to all stations Sid Schrum, Texas Instruments, Inc.

  8. Proposal • Best effort bc/mc  Basic Data Frame • Non-best effort bc  may use QoS Data Frame if no non-QoS STA are associated • Non-best effort mc  may use QoS Data Frame Sid Schrum, Texas Instruments, Inc.

  9. BC/MC Prioritization Proposal • Add text to require QAP to prioritize transmission of bc/mc traffic consistent with the TID, irrespective of the transmitted Data Frame format. Sid Schrum, Texas Instruments, Inc.

More Related