Direct link multicast georg dickmann bridgeco ag georg dickmann@bridgeco net
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

Direct Link Multicast Georg Dickmann, BridgeCo AG [email protected] PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Direct Link Multicast Georg Dickmann, BridgeCo AG [email protected] Outline. Motivation Main issues Proposal Other multicast issues and proposals Related ballot comments from LB#51. Motivation.

Download Presentation

Direct Link Multicast Georg Dickmann, BridgeCo AG [email protected]

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Direct link multicast georg dickmann bridgeco ag georg dickmann@bridgeco net

Direct Link MulticastGeorg Dickmann, BridgeCo AG [email protected]

Georg Dickmann, BridgeCo AG



  • Motivation

  • Main issues

  • Proposal

  • Other multicast issues and proposals

  • Related ballot comments from LB#51

Georg Dickmann, BridgeCo AG



  • Multicast: N times unicast of typical audio / video bandwidths will exceed the available bandwidth.

  • Direct Link: Relay by the QAP would double the required bandwidth.

  • Time/event synchronization relies on common events as generated by multicast frames.


  • Multi-channel audio streaming

  • Multi-room audio / video distribution

  • Higher Layer time / event synchronization



Definitiondirect link multicast: multicast originating from a QSTA not using the distribution function of the AP




Georg Dickmann, BridgeCo AG

List of main issues

List of main issues

  • ToDS: Currently, multicast frames from a QSTA must have ToDS = 1, direct link multicast is not allowed.

  • TSPEC: There are no mechanisms defined to negotiate a TSPEC for a multicast destination address.

  • PHY Rate: The source has to find out what PHY rate to use for multicast frames. The supported PHY rates of the receivers and the link quality to each receiver need to be known.

  • Power Save: All participants need to be awake when a multicast frame is transmitted.

  • Reliability: Typical error rates of wireless PHYs will not satisfy most streaming applications.

Georg Dickmann, BridgeCo AG

Summary of proposed solution

Summary of proposed solution

Proposed changes to the draft are written like this.

  • ToDS: Allow QSTAs in a QBSS to set the ToDS field to zero in frames with a multicast destination address.

  • TSPEC: A granted TSPEC for a direct link with an Ack policy of No Ack may be used for a multicast direct link stream.

  • PHY Rate / Power Save: Use direct link handshakes with each intended recipient to find out about allowed PHY rate, link quality and to prevent STAs from going into power-save. Multicast frames shall prevent a participating QSTA from going into power-save. Without direct link handshakes, PHY rates from the basic rate set may be used.

  • Reliability: Let the higher layer deal with it. Receiver-initiated protocols based on NAK-initiated retransmissions are candidates. Both NAKs and retransmissions are likely to be direct link multicast as well.

Georg Dickmann, BridgeCo AG

Details tods

Details: ToDS

  • It is to be clarified whether a direct link multicast frame received by the AP is to be forwarded to the infractructure or not.Proposal: Introduce a header bit to indicate the desired behaviour. In QoS frames, the Order bit is a candidate since it would otherwise have no significance for multicast frames.

  • A QSTA may perform an RTS/CTS exchange with the QAP prior to transmission of a direct link multicast frame in order to set the NAV in all STAs within the QBSS.

Georg Dickmann, BridgeCo AG

Details tspec

Details: TSPEC

  • The use of a direct link TSPEC allows only QSTA originated direct link multicast streams. A QSTA will not be able to negotiate a TSPEC for a downlink multicast stream.

  • A downlink multicast stream is likely to require higher layer support in the AP which is out of the scope of TGe.

Georg Dickmann, BridgeCo AG

Details phy rate

Details: PHY rate

If a direct link handshake has been successfully completed between the source and each of the targeted recipients:

The multicast frame may be transmitted at any PHY rate that is supported by all the targeted recipients. The source may probe the link quality for each recipient.


The multicast frame shall be transmitted at a PHY rate from the basic rate set.

Georg Dickmann, BridgeCo AG

Details power save

Details: Power Save

  • It is assumed that multicast streams would be used only where high throughput is an issue such that QSTAs participating in a negotiated direct link multicast stream would not go into power save.

  • When direct link negotiation is omitted, it is up to the higher layers to insure that the targeted receivers are out of power save. If this is not possible, a broadcast with ToDS = 1 may be used leaving the responsibility to the AP.

Georg Dickmann, BridgeCo AG

Details reliability

Details: Reliability

  • Reliability will be guaranteed through some higher layer feedback mechansims that trigger higher layer retransmissions.In that context the transmitter may want to adjust the PHY rate at which the stream is transmitted. Implementations should therefore provide an application interface that allows control of the PHY rate for each frame.Higher layer control messages (NAKs) are likely to be small and can therefore, without much bandwidth penalty, be transmitted at a low PHY rate from the basic rate set.

Georg Dickmann, BridgeCo AG

Related issues

Related issues

  • Buffering of QoS mc/bc in APRequire buffering of mc/bc frames in the QAP only forbroadcast framesmulticast frames without QoS fieldmulticast frames with TID = 0all other mc/bc frames are transmitted immediately regardless of the power save status of the associated QSTAs (see also 03/089r0)Change the meaning of MoreData for mc to be the same as for unicast frames.

  • Choice of data format (QoS or basic format) for mc/bc.Best effort bc/mc -> basic formatNon best-effort bc -> basic format if legacy STAs are associated, otherwise use QoS frame.Non best-effort mc -> use QoS frame(similar, but not identical to proposal from 03/102r0)

  • Filtering of received mc frames that have the own address as source address.Do not filter those mc frames addressed to the group address that has been registered with MLME-HL-SYNC.request. (see also 03/089r0)

Georg Dickmann, BridgeCo AG

Related ballot comments

Related ballot comments

Ballot comments from LB#51 related to this proposal:

178, 1073, 1488 (power save)

179, 867, 1071 (frame usage)

629, 661, 778, 1814 (multicast direct link)

628 (PHY rate for multicast)

765, 1156, 1264, 1804 (multicast buffering)

1152 (forwarding of mc frames to the DS)

1814 (TSPEC for multicast stream)

Georg Dickmann, BridgeCo AG

  • Login