Block Acknowledgement
- It is initialized by ADDBA request / response from between originator and recipient.
- after initiation blocks of QoS data are transmitted from originator to recipient.
- the originator can start transmitting the blocks of data after a polled TXOP or by winning the EDCA contention.
- the MPDUs within the block of transmitted frames are acknowledged by a BlockAck frame which is request by the originator in the BlockAckReq (BAR) frame.
- there are two flavors - Immediate Block Ack and Delayed Block Ack
- Immediate Block Ack and Delayed Block Ack differ in the way BAR and BA are handled. With Immediate Block Ack, the BA is required after the receipt of BAR whereas with Delayed Block Ack, the BAR itself is acknowledged (by recipient) with a simple Ack frame and the BA is sent later on separately which also gets acknowledged (by originator) separately.
- the originator or the recipient may tear down the Block Ack agreement by sending the DELBA (delete BA) Request which, if received successfully, is acknowledged with an Ack.
Chart showing BlockAck mechanism
a) Setup
- Originator first checks if the recipient STA is capable of Block Ack mechanism by checking Delayed Block Ack and Immediate Block Ack capability bits (as seen in Beacons, Association / Reassociation request, and Response frames).
- If the recipient is capable of Block Ack mechanism the originator sends a ADDBA Request frame indicating the TID (traffic ID) for which Block Ack is being set up.
- for Block Ack mechanism between HT-STAs the buffer size field in the ADDBA Request can be changed by the recipient of ADDBA Req frame.
- the recipient responds with the ADDBA Response frame and can chose to accept or reject the request.
- if the recipient rejects, the originator may not use the Block Ack mechanism.
- when recipient accepts, it indicates the number of buffers it allocates for this Block Ack agreement. Buffer size may be different for different Block Ack agreements.
- the originator changes the size of the transmission window based on the ADDBA response from the recipient. The originator may increase or decrease the size in accordance to the recipient response but is not greater than value of 64.
- the originator sets the A-MSDU supported field to 1 indicating it might transmit A-MSDU with the TID and recipient can set the same field to 1 to indicate it is capable of receiving an A-MSDU with this TID. The recipient can technically respond with any value of the A-MSDU supported field and if the originator does not like it, it can tear down the Block Ack agreement and send frames using normal ack.
- Block Ack Timeout Value: duration after which the Block Ack session is terminated when there are no frame exchanges.
- Start Sequence Number (SSN): the sequence number of the first data frame from the originator for this Block Ack session.
b) Data and Block Ack
- Once the Immediate Block Ack or Delayed Block Ack is setup, the originator may transmit a block of QoS data frames separated by a SIFS (Short Inter-frame Space) duration with total number of data frames not exceeding buffer size as defined by ADDBA Response.
- the originator may do the following
- separate the Block and Basic BlockAckReq frames into separate TXOPs
- split a Block frame across multiple TXOPs
- split transmission of data MPDUs sent under Block Ack policy across multiple TXOPs
- Interleave MPDUs with different TIDs within same TXOP
- sequence or interleave MPDUs for different RAs within a TXOP
- Originator uses SSN to indicate to the recipient of the sequence number of first frame in the block for which acknowledgment is expected.
- Recipient maintains a Block Ack record which consists of originator address, TID and acknowledgment state of the data frames received from the originator.
- In case of Immediate Block Ack policy - recipient responds to basic BlockAckReq frame from originator with a basic BlockAck frame which indicates any missing frames. The originator retries any frames that are not acknowledged in the basic BlockAck frame in another block or individually.
- The difference with Delayed Block Ack policy is that the recipient responds to the BlockAckReq frame with a normal Ack and then transmits the BlockAck frame in a TXOP obtained later. The originator responds to the basic BlockAck with an Ack and then retries the unacknowledged frames from the BlockAck frame in another block or individually.
- In BlockAck frame the recipient only acknowledges the frames starting from the starting sequence number (SSN) until the highest sequence number that has been received correctly and sets the bit in the BlockAck bitmap of other frames (frames not received correctly from originator) to 0. The recipient reports the status of old and prior frames (frames before the first frame that the originator sends - SSN) as successfully recieved (bit is the bitmap set to 1).
- The recipient maintains a field called NextExpectedSequenceNumber which is set to 0 when the Block Ack mechanism is negotiated. if the recipient receives a frame with a sequence number older than the NextExpectedSequenceNumber for that Block Ack agreement than the recipient drops the frame thinking its either old or a duplicate.
c) Teardown
- When originator has not more data to send and the final frame in the Block has been sent the originator signals the end of the Block Ack mechanism by sending the DELBA (Delete BlockAck) frame to the recipient.
- There is no response needed from the recipient. It just releases all resources allocated for that Block Ack agreement.
- The Block Ack agreement may be torn down if there are no BlockAck, BlockAckReq or QoS data frames (sent under the Block Ack policy) for the Block Ack's TID received from the peer within duration of the Block Ack timeout value.
AP Debugs:
debug dot11 d1 monitor address 7cd1.c392.3232
debug dot11 d1 tr pr clients xmt rcv ba
*Apr 10 00:15:05.471: 8893F78B r 12 28/17/28/34 77- B000 030 EBBF4F 923232 EBBF4F 1600 auth l 6
*Apr 10 00:15:05.471: 8893F7A2-1 923232 - newauth
*Apr 10 00:15:05.471: 8893F7AD-1 923232 - restart B0 300
*Apr 10 00:15:05.471: 8893F7CC-1 923232 - stop: re-assoc aid 1
*Apr 10 00:15:05.471: 8893F990 t 12 0 - B000 001 923232 EBBF4F EBBF4F 0000 auth l 37
*Apr 10 00:15:05.471: 8893FA55 r 12 29/18/29/35 76- 0000 030 EBBF4F 923232 EBBF4F 1610 assreq l 109
*Apr 10 00:15:05.471: 8893FA6E-1 923232 - restart 0 300
*Apr 10 00:15:05.475: 8893FEFF-1 923232 - clrfp
*Apr 10 00:15:05.475: 8894003D t 12 0 - 1000 000 923232 EBBF4F EBBF4F 0000 assrsp l 123
*Apr 10 00:15:05.475: 889402A0-1 923232 - add request
*Apr 10 00:15:05.475: 88940368-1 923232 - client restart pend - clear and set new key
*Apr 10 00:15:05.475: 889405D6-1 923232 - add AID:(status ST_CAN_BF [10]) (mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280]) (vrates [0014000030]) (age [300]) (blk [400]) (rate [00FCFFFFFF]) (AID [1]) (VLAN [1]) (0 []) (istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144]) (encr [0])
*Apr 10 00:15:05.475: 889405EB-1 923232 - uapsd_compliant_client 0
*Apr 10 00:15:05.479: 88941929 r m0-2 28/20/30/32 75- 8809 03C EBBF4F 923232 B92348 0000 q0 l36
ARP1 hdw 1 prot 800 7cd1.c392.3232 10.0.0.107 > 0000.0000.0000 10.0.0.1
0001 0800 0604 0001 7CD1 C392 3232 0A00 006B 0000 0000 0000 0A00 0001
*Apr 10 00:15:05.479: 8894199C r 12 34/24/35/40 70- 4801 030 EBBF4F 923232 EBBF4F 1620 null l0
*Apr 10 00:15:05.479: 88941A88-1 923232 - Request addba 0
*Apr 10 00:15:05.479: 88941DC3-1 923232 - xmt ADDBA req pri 0, seq E0F0, window 64 timeout 0 1 ----> transmit ADDBA req for priority 0, SSN 3599
*Apr 10 00:15:05.479: 88941DD3-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10
*Apr 10 00:15:05.479: 88941DDA-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10
*Apr 10 00:15:05.479: 88941EE5 t 12 0 - D000 C8EC 923232 EBBF4F EBBF4F 0000 action l 40 ----> same as above. actual frame transmission
*Apr 10 00:15:05.479: 88942164 r m0-2 29/25/33/31 70- 8809 03C EBBF4F 923232 mFFFFFF 0010 q0 l336
C392 3232 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
*Apr 10 00:15:05.479: 889421E3 r m23-2 35/25/36/38 69- 8801 030 EBBF4F 923232 m333300 0020 q0 l56
SNAP 86DD 6002 839F 0008 3AFF FE80 0000 0000 0000 7ED1 C3FF FE92 3232
*Apr 10 00:15:05.479: 88942293 r 12 36/25/36/41 70- D000 030 EBBF4F 923232 EBBF4F 1630 action l 9 ---> received ADDBA response for priority 0 from client
*Apr 10 00:15:05.483: 8894229C-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10
*Apr 10 00:15:05.483: 889422AB-1 923232 - rcv ADDBA rsp pri 0, window 64 timeout 0 ----> same as above. above is actual frame
*Apr 10 00:15:05.483: 889427A4 t m2-2 4 - 880A 000 923232 EBBF4F B92348 E0F0 q0 l58 ---> TID 0 data frame transmit to client (last 3 octect 92:32:32)
ARP2 hdw 1 prot 800 ecc8.82b9.2348 10.0.0.1 > 7cd1.c392.3232 10.0.0.107
0001 0800 0604 0002 ECC8 82B9 2348 0A00 0001 7CD1 C392 3232 0A00 006B
*Apr 10 00:15:05.483: 889428B2-1 923232 - send BAR 0 E100
*Apr 10 00:15:05.483: 889429EA t 12 0 - 8400 1750 923232 EBBF4F 0004 E100 bar ----> sent BAR (BlockAckReq) for priority 0 and SSN 3600 (E10)
Note: the response to BAR which is BA is not seen in the debug outputs
As you see above the clients indicates the missing frames which the originator may resend using another Block Ack mechanism or send them individually.
Note: The aim of this article is to try and summarize the key points involved in the Block Ack mechanism. This article is by no means a comprehensive guide for the Block Ack process. For detailed info please refer to the IEEE 802.11-2012 standard.
