Group Block Acknowledgements for Multicast Traffic July 2008 doc.: IEEE 802.11-08/0766r0 July 2008 Group Block Acknowledgements for Multicast Traffic Date: 2008-07-07 Authors: Alex Ashley, NDS Ltd Alex Ashley, NDS Ltd

July 2008 doc.: IEEE 802.11-08/0766r0 July 2008 Abstract This presentation describes a way to extend the “leader based” approach to any number of reporting STAs This approach is based upon re-using the existing block-ACK mechanisms It has the further advantage of not requiring one (or more) ACKs per multicast frame Alex Ashley, NDS Ltd Alex Ashley, NDS Ltd

Leader Based Multicast July 2008 Leader Based Multicast One receiving device is elected as a “leader” for a set of group addresses Leader sends back an ACK if it successfully receives a group addressed frame AP uses these ACKs (or lack of) to retransmit packets not received by the leader to all members of the group Alex Ashley, NDS Ltd

Leader Based Multicast July 2008 Leader Based Multicast Assumes errors are correlated such that if leader successfully received frame, all other stations also received it correctly Random & dynamic nature of WM does not fit well with this assumption Requires AP to send one frame, wait for an acknowledgment (or time out) before sending the next frame If LB multicast not enabled, the AP can burst multiple frames This means power saving STAs have to stay awake for longer Alex Ashley, NDS Ltd

Block ACK Setup July 2008 To start block ACK, a request is sent Request contains first sequence number to start using block ACK and a buffer size. Buffer size is max number of frames that the transmitter will keep for possible retransmission. Recipient replies with AddbaResponse Response says if request has been accepted and a buffer size. Buffer size in AddbaResponse defines max number of frames that either the transmitter or receiver needs to keep while the block ACK is active Receiver creates a re-order buffer for frames of this BA agreement Alex Ashley, NDS Ltd

July 2008 Block ACK Once block ACK is active, sending device can send frames with the ACK policy set to BLOCK_ACK Frames with this policy set are not acknowledged immediately Sending device sends a BlockAckRequest frame Requests information on the frames that have been received successfully BlockAckRequest must be sent at least as often as the buffer size to ensure that it can retransmit lost frames before the receiver’s buffer overflows Recipient sends a BlockAck frame Contains a map of received sequence (fragment) numbers Sending device can use this BlockAck frame to discover which frames have been received by the destination and which ones need to be retransmitted. When a BlockAckRequest is received, the receiver can empty its receive buffer of all the oldest frames in its buffer that make a continuous set of sequence numbers. Buffer overflow in the receiver If, after an MPDU is received, the receive buffer is full, the complete MSDU with the earliest sequence number shall be indicated to the MAC client using the MA-UNIDATA.indication primitive Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast STA 2 STA 1 AP 1 STA 4 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 1 1 STA 2 STA 1 AP 2 1 STA 4 1 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 2 1 2 1 STA 2 STA 1 AP 3 2 1 STA 4 2 1 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 3 2 1 STA 2 STA 1 BA BAR=3 AP 2 1 STA 4 2 1 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 3 2 1 STA 2 STA 1 AP 4 2 1 STA 4 2 1 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 3 2 1 4 STA 2 STA 1 AP 5 2 1 4 STA 4 2 1 4 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 5 3 2 1 4 5 STA 2 STA 1 BAR=5 BA AP 2 1 4 5 STA 4 2 1 4 5 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 5 3 2 1 4 5 STA 2 STA 1 AP 4 2 1 4 5 STA 4 2 1 4 5 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 4 5 3 2 1 4 5 STA 2 STA 1 AP 6 2 1 4 5 STA 4 2 1 4 5 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 4 5 6 3 2 1 4 5 6 STA 2 STA 1 AP 2 1 4 5 6 STA 4 BAR=6 2 1 4 5 BA STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 4 5 6 3 2 1 4 5 6 STA 2 STA 1 AP 3 2 1 4 5 6 STA 4 2 1 4 5 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 4 5 6 3 2 1 4 5 6 STA 2 STA 1 AP 6 3 2 1 4 5 6 STA 4 3 2 1 4 5 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast July 2008 Block ACK for Multicast 3 2 1 4 5 6 3 2 1 4 5 6 STA 2 STA 1 AP 3 2 1 4 5 6 STA 4 3 2 1 4 5 6 STA 3 Alex Ashley, NDS Ltd

Block ACK for Multicast - Setup July 2008 Block ACK for Multicast - Setup AP needs to know which stations are listening to which multicast groups E.g. snoop on IGMP messages sent by STAs, send out IGMP query messages AP selects ‘n’ stations from the ‘m’ listening to the multicast group to become block ACK recipients where 0<n<=m For each of the ‘m’ stations, the access point sends AddbaRequests From the resulting AddbaResponse frames, AP knows minimum buffer size that can satisfy all ‘m’ stations. Alex Ashley, NDS Ltd

Block ACK for Multicast - Setup July 2008 Block ACK for Multicast - Setup AP calculates number of group addressed frames to send before sending a BlockAckRequest: BlockAckRequestFrequency * n <= BufferSize (eqn 1) By satisfying equation 1, each of the ‘n’ stations will be asked at least once their reception status before its receive buffer becomes full* This allows at worst case one retransmission of each frame An improvement can be made by reducing BlockAckRequestFrequency: BlockAckRequestFrequency * n * retries <= BufferSize (eqn 2) * Assuming all STAs use immediate block ACK Alex Ashley, NDS Ltd

Block ACK for Multicast - Operation July 2008 Block ACK for Multicast - Operation After transmitting BlockAckRequestFrequency group addressed frames, the AP sends a BlockAckRequest to a STA from of its list of ‘n’ Normally first in list, however AP does not select a STA that was the source of any of the packets in its block ACK buffer The sender of the frame will not have this frame in its receive buffer, so a BlockAckRequest would erroneously look like a failed reception Selected STA moves to the back of the list Typically will not receive another BlockAckRequest until all other ‘n’ stations have been sent a BlockAckRequest. Extra BlockAckRequests may need to be sent to STAs not in ‘n’ to stop Block ACK agreement timeout Alex Ashley, NDS Ltd

Block ACK for Multicast - Operation July 2008 Block ACK for Multicast - Operation When frames are retransmitted, all STAs listening to this multicast/broadcast will attempt to receive the frame If reception errors between stations are correlated, the retransmission caused by processing one BlockAck may provide frames lost by many stations This technique allows improved reliability even when ‘n’ is less than ‘m’ This is also why BlockAckRequests are staggered between stations, as opposed to sending them at the same time or one after the other. The Block ACK setup means that there is a delay of up to BufferSize frames between a frame first being received and being passed up the software stack If a lost frame is retransmitted during this delay it will be placed in its correct position in the receive buffer. Alex Ashley, NDS Ltd

July 2008 Legacy Issues Retransmissions need to be hidden from legacy STAs that do not have active block ACK agreement They will not have setup a re-order buffer and will probably pass up all received frames Block ACK requires a TID For multicast, this needs to be a TID not used by any associated STA (apart from the source of the traffic) Assumes legacy STA can handle block ACK on group addressed frames Suggest adding a flag to the AddBlockAckRequest to signal group block ACK (E.g. using reserved B0 of parameter set) Capability signalling in an IE also a recommended Alex Ashley, NDS Ltd

Conclusions Technique built upon existing 802.11 technology July 2008 Conclusions Technique built upon existing 802.11 technology Can re-use existing non-AP STA block-ACK implementation AP needs to keep buffer of sent frames and send periodic BlockAckReq frames and schedule retransmits when BlockAck received Any number of group members can be used for reception reports Does not require an ACK on every transmitted frame Alex Ashley, NDS Ltd

References “Leader based Multicast.” July 2008 References “Leader based Multicast.” Yongho SEOK, Diego DUJOVNE, Thierry TURLETTI, Emily Qi, Menzo Wentink IEEE 802.11-07/2128r0 Alex Ashley, NDS Ltd