Direct Link Multicast Georg Dickmann, BridgeCo AG georg.dickmann@bridgeco

1. Direct Link MulticastGeorg Dickmann, BridgeCo AG georg.dickmann@bridgeco.net Georg Dickmann, BridgeCo AG

2. Outline • Motivation • Main issues • Proposal • Other multicast issues and proposals • Related ballot comments from LB#51 Georg Dickmann, BridgeCo AG

3. Motivation • 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. Applications: • Multi-channel audio streaming • Multi-room audio / video distribution • Higher Layer time / event synchronization QAP QSTA1 Definitiondirect link multicast: multicast originating from a QSTA not using the distribution function of the AP QSTA2 QSTA3 QSTA4 Georg Dickmann, BridgeCo AG

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

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

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

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

8. 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. Otherwise: The multicast frame shall be transmitted at a PHY rate from the basic rate set. Georg Dickmann, BridgeCo AG

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

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

11. Related issues • Buffering of QoS mc/bc in APRequire buffering of mc/bc frames in the QAP only for broadcast frames multicast frames without QoS field multicast 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

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