802.11 ax UL OFDMA is one of the new and key features of 802.11ax or WiFi6. I’ve been able to capture this in my lab network and in this article I will explain key elements on how I do it, and what I look for in this capture

Setup
– Cisco 9800 controller, version 17.9.1
– Cisco 9120 AP, joined the network in FlexConnect mode
– WlanPi to do SpeedTest against
– 2 NVIDIA Jetson Nano Developer Kit with Intel ax200 NIC as test devices, clients
– 1 NVIDIA Jetson Nano Developer Kit with Intel ax200 NIC as the capturing device
– The capturing device sends the captured frames to a Windows client with Wireshark
– Ekahau Sidekick1 to monitor the RF spectrum

Testing
For the Jetson to capture wireless multi-user frames (in RUs) I need to configure it to capture frames from specific association IDs (AID). So the first thing I do is to re-associate the Jetson to the wireless network, read the assigned association ID in the association frame in Wireshark and configure the Jetson to capture the multi-user frames from that AID.
Then I do some SpeedTest testing on the two test devices and dig into the capture file in Wireshark and look for frames with 802.11ax Trigger-based frame format

Wireshark display filter: radiotap.he.data_1.ppdu_format == 0x3

When I find those frames I do some mix and match in Wireshark to get the view I want on the screen

Capture for this blog
I have selected 4 consecutive TXOPs, made the columns I found most interesting, and put red boxes/arrows on different items I will further explain.
This picture (yes, I know it is small) and the pcap is attached to this article

Box 1. The Basic Trigger frame
This frame is sent by the AP and it tells which clients that can send data uplink right after this frame. Each TXOP start with this Basic Trigger frame. In the first TXOP we can see this:
– the Basic Trigger frame is sent with a data rate of 24mbps, it is a Control frame sent with the legacy 802.11a frame format
– the picture doesn’t show it but it is a broadcast frame, RA is all “f”
– it tells the client with AID 0x002 to send its data on RU number 53 which is the lower 106-tones RU on a 20MHz channel and it shall use MCS5. Client with AID 0x001 shall use RU number 54 which is the higher 106-tones RU on a 20MHz channel and it shall use MCS8.
– if we dig into the packet detail we would have found other interesting items like which Guard Interval to use uplink, number of HE Long Training fields, Tx power information, coding type, number of spatial streams, and other items
-This Basic Trigger frame also distributes the NAV (Network Allocation vector), the value 310 in the first TXOP
– the UL Length parameter (166 in the first TXOP) is the information for how long the uplink transmit windows is. I will explain this in another blog article.

All those parameters can be changed by the AP TXOP by TXOP depending on how the AP estimates the environment

Box 2. QoS Data in the uplink data frame
Each TXOP contains one A-MPDU frame and this A-MPDU contains a variable number of sub A-MPDU frames. In each UL OFDMA frame, there are usually some sub A-MPDUs containing QoS Data frames and some QoS Null Data frames.
Box 2 show one of the QoS Data sub A-MPDU frames. Each QoS Data frame contains a sequence number that is increasing for each sent QoS Data frame. We can also see that the frame is sent on a 106-tones RU with a data rate of 56,7 mbps.

Box 3- Null Data Frame
One method the client can use to signal whether it has more data to send or not is to use the Null Data frame. This frame is only an 802.11 MAC header.
This frame is formerly used by clients to signal the power management bit to the AP, indicating whether it will go into power save mode or get out of power save mode.
In 802.11ax network, this frame uses the TID (access category) and the Queue Size. The TID indicates the AC (access category), in this capture AC numbers 0, 1, 5, and 7, and the Queue Size is a number that has to be multiplied by 256 bytes
In box 3, the client uses the Null Data frame to indicate to the AP that still has (9x256bytes) 2304 bytes in its buffer for the access category 0.
For the other access categories, the clients do not have data in its buffer.

Box 4- The Multi-STA BlockAck
When the clients have sent their data uplink to the AP, the AP responds with a new 802.11 frame called Multi-STA Block Acknowledgement. With this broadcast frame, the AP sends BlockAck information to each of the clients that have sent data uplink
In box 4, we can see the AP has BlockAcked the sub A-MPDUs from the starting sequence number 2064 and 4 consecutive sub-AMPDUs for one client. The “f” in the BlockAck Bitmap. In this TXOP the AP has only received frames from one of the associated clients. If you look at the TXOP above you can see the AP has received and BlockAcked frames from two different clients

Arrow 5- The relations between QoS Data frame Sequence Number and the Multi-STA BlockAck
Understanding BlockAck Starting Sequence Number, the BlockAck Bitmap, and how the QoS Data frame set the Sequence Number in each sub A-MPDU is a key feature to know about while interpreting wireless packet captures. I will not go into the theory.
But if you compare the BlockAck Startings Sequence Number, the BlockAck Bitmap, and the QoS Data frame Sequence number you can see that all the sub A-MPDUs is transmitted without any retries.
In fact, for UL OFDMA you can use the information only from the Basic Trigger frame and the Multi-STA BA to predict the data flow. You don’t need to see the data frames in RUs

Arrow 6. Why doesn’t the clients send data when it has data in its buffer
If we look at TXOP number 3 we can see that the client indicates it has data in its buffer for access category/TID 0. The Queue size of 5 indicates that the client has (5×256) 1280 bytes in its buffer. But still, in the next TXOP, it doesn’t send any data and now it says the buffer is empty for AC0.
Why it does this is unknown. A moment later the AP receives the next QoS Data frames (frame numbers 2071 and 2072) in single user frame format (not in this capture)

Is this efficient or should the network do SU operation instead?
The next big question is: Are the use of UL OFDMA and multi-user operations more efficient than old and legacy single-user operations?
I give you the answer in my next blog

I hope this has been useful

Attachments
– Picture number 1

– the pcap,