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

2. July 2008
doc.: IEEE /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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Conclusions Technique built upon existing 802.11 technology
July 2008
Conclusions
Technique built upon existing 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

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