Friday, September 11, 2015

Block ACK Session

Key Points on Block ACK Session:
  • Session is established using ADDBA Request & Response which are Management (Action) frames (hence ACKed).
  • Session can be tear down by either party by sending DELBA request (ACKed).
  • Block ACK Session is specific to particular AC of  a given station & in one direction.
  • Each Block ACK session will have one or more transactions. Hence, it is good for the station to start Block ACK session with the peer and use it for multiple transactions.
  • Each transaction can have 
    • Single AMPDU or
    • Multiple Data / MSDU packets or
    • Multiple AMSDU packets or
    • Mix of Data & AMSDU packets. 
  • Each transaction acquire channel using EDCA rules. Moreover, one transaction can make use of multiple TXOP by acquiring channel multiple times if sending Multiple Data/AMSDU frames. Sending AMPDU will involve channel acquisition only once. 

  • Each transaction will be acknowledged using BA frame. Immediate (not Delayed) Block ACK is something which is generally used. 
  • BAR & BA are Control packets & hence not acknowledged in Immediate Block ACK. However, In Delayed Block ACK, BAR & BA packets are acknowledged using ACK packet.
  • Actual frames in an AMPDU (channel acquisition only once) is governed by:
    • TXOP Limit: Correction: An AMPDU can stretch across multiple TXOPs. 
    • BA capacity (64 Data/AMSDU for compressed BA)
    • Buffer available at the receiver for the data expected to receive in one transaction.
  • Backward Compatibility:
    • Block ACK session b/w HT node and non-HT node is possible.
    • HT station will use 802.11e Block ACK for legacy stations.
    • HT station will use HT-Immediate / Delayed Block ACK while setting BA session with another HT client.
  • If one or more of the QoS DataMPDUs in an aggregate have their Ack Policy field set to Normal Ack then the responder will return a BA in response to the aggregate.
  • Fields in ADDBA request & response
    • Block Ack Policy in BA session (Immediate or Delayed)
      • HT & non HT Station:
        • The policy is proposed by originator but final policy is given by recipient.
      • HT & HT Station:
        • Recipient either accepts or rejects the policy proposed by originator.
    • Buffer Size: 
      • Number of frame buffers (typical value 64) which receiver has or MPDUs which can be sent in one transaction. Each buffer is 2304 bytes.
    • AMSDU Support: 
      • ADDBA RQ: Originator can send AMSDU in the session
      • ADDBA Response: Receiver supports receiving AMSDU in the session or not. Receiving AMSDU is mandatory. 
    • Block Ack Timeout Value:
      • Duration during which if no frames (including BA, BAR or QoS Data) are exchanged, session can be terminated by either party by sending DELBA frame.
  • MPDU Retransmission:

  • Cases when AMSDU should be used in Block ACK session
    • Case 1: 
      • High volume of small packets. If only AMPDU is used then one transaction will have 64 small data packets in one TXOP (hence under utilizing the TXOP) which will limit the throughput. e.g. Aggregation of TCP ACKs can lead to throughput improvements.
      • Q: This should be valid only for voice and video as they have TXOP specified in msec. For BE/BK, the TXOP will be derived by size of AMPDU and hence if frames are smaller then TXOP will be small which invalidates the above point. We have already seen  in one of the post that using TXOP of 11e and AMPDU is a very bad idea. Need to see, what the TXOP used for voice and video.
    • Case 2: 
      • Very high Data rates. 64 frames each of size 1500 bytes cannot fully utilize TXOP.
  • Capture: ADDBA Request

  • Capture: ADDBA Response

Note: Buffers available = 64 * 2304 = 147456 bytes. Max AMPDU size is 64K (65535)

No comments:

Post a Comment