Friday, September 11, 2015

Channel Acquisition & Transmit Opportunity [TXOP]

Channel Acquisition:
  • DCF: Legacy Data Access
  • EDCA: QoS Data Access

where AIFS[AC] = SIFS + AIFSN[AC] * Slot time



Scenario:
Lets say, a node has packets to transmit in all of the four access categories then four different instances of EDCA access function will be competing. If two (or more) instances of the EDCA access function gains access simultaneously then internal collision is resolved by the highest priority gaining the access of the medium and other AC behaving as if external collision occurred by doubling its contention window.

Points to Note:

  • DIFS = SIFS + 2*slot time
  • Every access category waits different amount of time for which channel is free before kicking of back off timer. Voice, Video & legacy clients waits for DIFS while BE & BK waits for more time (SIFS + 3*slot time & SIFS + 7*slot time respectively).
  • Working of back off timer: 
    • After picking a random slot count from contention window the timer checks every slot time (9us) for the channel to be free. If it is free then the slot count decrements otherwise (if busy) the backoff timer freezes. To unfreeze the timer, the channel needs to be free for AIFS( for that given access category). After unfreeze, the counter resumes. Once counter reaches zero, the medium can be acquired.
  • Next Step after channel acquisition: 
    • TXOP begins with a short frame exchange which could be RTS/CTS or Data/ACK. (refer here)
    • Send RTS/CTS frame declaring the duration [usec] for which the node will be acquiring the channel. Sending RTS/CTS step is very important step.
    • In Block ACK sessions, presence of RTS/CTS indicates channel acquisition by the node.
    • Duration is a 16 bit field but for duration only 15 bits are used which means channel can be acquired for max 32 msec. Noticed, 27 msec time in RTS frame in Block ACK session even for normal/BE packets.

Transmit Opportunity [TXOP]:
Its a duration during which a node has full channel access for sending and receiving frames of a particular TID after acquiring the channel. It means the node can send multiple packets after SIFS gap and all it needs is acquiring channel only once.  A TXOP of zero means that node can send one Management packet or MSDU after acquiring channel. 

Without Aggregation, it promotes resource fairness as it allow BE/BK traffic to send at least one packet while keeping other time for video & voice. If you think through then you will realize if the client with BE/BK traffic is having low data rates then sending one such packet will consume more time than TXOP recommended for video & voice but that is understandable as nodes with BE/BK traffic are sending just one packet.

However, this concept is seriously flawed when applied with AMPDU. Since, every node can send one AMPDU after channel acquisition but number of MPDUs in an AMPDU can be 64 for the BE/BK traffic (which can take upto 27msec time to go out). This will be lethal for voice and video if constrained to use TXOP of 1.5 / 3 msec respectively. (backing).

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)

MAC Changes in 802.11e & 802.11n for Improving Throughput (75-80% of PHY Rate)

Link
This figure demonstrates how data can be exchanged in a more efficient way using 11e and 11n. Each data frame shown can be simple data packet (MSDU) or AMSDU. The aggregate packet where multiple data frames are glued together is known as AMPDU. Hence, AMPDU is made up of multiple MSDUs or AMSDUs.

Sending AMPDU instead of multiple Data or AMSDU packets (separated by SIFS or RIFS) is more efficient as it saves inter frame space time b/w individual packets and also the PHY header. 

We will refer the complete data transfer shown above as one transaction. 
In the next post, we will see how this transaction fits into BA session. We will also see that each BA session can has multiple transactions.

SIFS: Duration that was originally designed to accommodate receive to transmit switching. 
RIFS: Time required by the receiver to re-arm for the acquisition of new signal. 

11e improvements:
  • Block ACK: Just like TCP, not every data packet is acknowledged. Possible modes are:
    • Immediate: Response to BAR with BA is within SIFS
      • uses uncompressed version of BA where each bit acknowledges one fragment of MSDU/Data packet and up-to 64 MSDU/Data packets can be acknowledged. Hence, uses 1024 (64*16) bit score card as each MSDU can have up-to 16 fragments. 
      • Each MPDU in the transaction (see below to see what transaction means in BA session) has its ACK policy field (inside QoS info field) set to Block ACK. However, it is also possible to have a single data frame in a transaction. Such data frame should be send with its ACK policy set to Normal ACK & in such a case, the receiver responds with normal ACK on receiving this data frame. This is efficient than setting ACK policy for a single frame to Block ACK as BAR is not required.
    • Delayed: BAR is just acked and BA is sent little later (for ease of implementation)
11n improvements:
  • Modified Block ACK
    • HT-Immediate
      • Partial State Block ACK
      • Compressed Block ACK (send small & save time)
        • one bit acknowledges one MSDU/Data packet of a transaction hence one BA can ACK up-to 64 MSDU or Data packets. Fragments are not supposed to be present as fragmentation & aggregation together makes little sense. This reduces the size of BA frames which is a control frame and send with robust MCS index rather than at data rates thus reducing the size of BA helps to be more efficient. 
      • Implicit BAR (BAR bye-bye but not always*)
        • Not all MPDUs in the transaction have their ACK policy field (inside QoS info field) set to Block ACK and if any one or more of the MPDUs have their ACK policy set to normal then receiver responds with BA frame w/o requiring BAR.
* BAR performs two functions
  1. Invoke BA frame. [now can be done by sending Normal ACK policy]
  2. Flushes recipient reorder's buffer which is required when re-transmission count of MPDU has reached its MAX limit (each MPDU has time to live field which defines maximum allowed re-transmissions for the MPDU) and transmitter/originator wants recipient to flush its reorder buffer as that MPDU will NOT be transmitted again. Hence, in this case we still need to have BAR. Receiver will pass on the following MPDU after expired MPDU to the OS. MPDU Reordering is best tried by the receiver even if there are no fragments.  


    • HT-Delayed
  • Aggregation: 
    • AMSDU
      • Done at the top of MAC layer
      • Good for aggregating small packets.
      • Max AMSDU length which a station can receive is either 3839 or 7935 bytes.  Its communicated by station using "HT capability info" element (available in Probe & Association Request, not available in ADDBA Request or Response)
      • AMSDU introduction lead to increase of payload length to 7,955 in Data frames which was earlier 2,312 bytes.
      • MSDU Delineation: Using prefix (DA, SA & len), possible only if AMSDU is not corrupted. Each MSDU aligned on 32 bit boundary. 
      • In the event of corruption in one MSDU other MSDUs in AMSDU are not recoverable.




    • AMPDU
      • Done at the bottom of the MAC
      • Each MPDU has its own wireless MAC header.
      • Max AMPDU length which a station can receive is 8191, 16383, 32767 or 65535 bytes.  Its communicated by station using "HT capability info" element (available in Probe & Association Request, not available in ADDBA Request or Response) 
      • MPDU Delineation: Each MPDU is aligned on 32 bit boundary + MPDU Delimiter has a signature (ASCII character "N") which helps to track MAC delimiter of each MPDU. Due to presence of CRC in the MPDU delimiter, length field in the delimiter is verified.
      • MPDUs with corrupted delimiters or corrupted payload will be filtered out.
      • After the PHY preamble, the receiver should be capable to understand either MPDU Delimiter or normal 802.11 MAC header. 
n


  • Packet Classification at receiver: 
    • Frames larger than AMSDU length or Length mentioned in AMPDU Delimiter header is only of one MPDU however actual frame receive length is larger will indicate AMPDU (multiple MPDUs)
    • Data vs AMSDU: AMSDU is marked in QoS Field
  • Notes:
    • AMSDU or AMPDU can be sent only in the Block ACK session.
    • All HT Stations are required to support HT-immediate block ACK as receiver.
  • MAC Efficiency: Throughput with the above mentioned changes is 75% - 80% of Phy Data rate. Hence, 300Mbps phy rate should give 225 Mbps to 240 Mbps.


Sunday, September 6, 2015

UAPSD aka WMM Power Save

Problems in Legacy Power Save:
====================

  • Retrieving frames using PS-Poll frame is inefficient as each PS-Poll frame fetch only single packet. 
  • Not suited to efficiently handle the needs of bi-directional traffic e.g. VoIP traffic.
  • Slow and hence not suitable for low latency applications such as voice. 

UAPSD Explanation
============
  • Legacy Power Save is more like a polling mechanism where polling interval is 100 msec (beacon interval) in the best case whereas UAPSD is more like interrupt (trigger) driven mechanism hence more fast. 
  • Uses up-link traffic (QoS Data Frame) as a trigger for the delivery of buffered frames. 
  • AP supporting UAPSD has two queues: Legacy Power save queue & UAPSD queue. For all the ACs which are marked delivery enabled, buffering is done in UAPSD queue & for the other queues it is done in legacy power save queue. Hence, if any AC needs to use UAPSD procedure it should be marked delivery enabled.
  • When a trigger frame is received, it will start buffering out frames from the UAPSD queue on FIFO basis. Its not that voice will be followed by video.
  • To improve power consumption of the station, AP must respond to trigger ASAP. 


  • Number of frames to be delivered by the AP is decided from Service Period length field which is decided by client. 
  • As the AP can send any number of frames less than or equal to that of service period, station does not know when service period will end. Hence, AP need to send EOSP information to the stations using QoS Info field in the last data frame. However, if AP does not have any data buffered when trigger is received then AP responds with QoS NULL frame with EOSP bit set.  



  • Works only for uni-cast traffic. Delivery of Multicast & Broadcast still follows legacy power save method.
  • Well suited for applications that have bidirectional traffic flow. For applications which do not have sufficient up-link traffic to meet the needs of down-link traffic needs to send QoS frames periodically.


  • Trigger Enabled vs Delivery Enable AC
    • Trigger Enabled: Frame for AC which is marked as trigger enabled act as a trigger to the AP.
    • Delivery Enabled: Frames for ACs marked as Delivery enabled are queued in UAPSD queue otherwise they go in legacy power save queue. Hence, during service period only frames from Delivery enabled queues will be transmitted.
    • During association, station just marks that WMM is enabled for one or more of the ACs (no provision to mark ACs as Delivery enabled or Trigger enabled). Hence, ACs supporting UAPSD are both triggered as well as delivery enabled by default during association. Disabling one of the property needs TSPEC which is beyond the scope for this blog post.
  • Hybrid Mode:
    • Few ACs supports UAPSD & other supports Legacy Power Save. 
    • In this mode, TIM indicates buffering of frames only for the non UAPSD ACs.

Working with 
=========
  • Legacy Clients: APs supporting UAPSD still have to support legacy power save for one or more of AC. Hence, supporting legacy clients is as simple as marking station as legacy power save capable only.  
  • Legacy Access Points