Wireless Capturing of UL OFDMA

The process of wireless capturing of 802.11ax OFDMA-frames has evolved. The newest step, for me, is to capture the UL OFDMA frames.

I use the NVIDIA Jetson Nano developer kit with the Intel AX200 NIC for wireless capturing and I have earlier showed how to capture:

  • Single-user 802.11 in this blog
    • But Francois Verges has developed this method, see his blog
  • Multi-user frames during DL OFDMA in this blog
  • UL OFDMA without capturing the data frames in this blog

The next step is to capture the data frames during UL OFDMA. These frames are sent in a format called trigger-based frame format (HE TB PPDU). I have explained how the RF looks like during UL OFDMA in this blog.

The key moment for capturing these frames is to capture the preceding Basic Trigger frame, sent from the AP. This Basic Trigger frame tells the stations in the BSS which station who can send its data and in what shape (resource unit, MCS, spatial stream and for how long). This is explained in these blogs (Basic Trigger frame and LENGTH).

When we capture the multi-user frame during DL OFDMA we use an echo command which tells the wireless NIC in our capturing device which AID (association ID) it should capture multi-user frames for. The command was this

echo 0 00:00:00:00:00:00 > /sys/kernel/debug/iwlwifi/*/iwlmvm/he_sniffer_params

where we set the AID in the first parameter. It is explained in this blog.

Now it turns out if we set the MAC address (BSSID) for our 802.11ax AP in the next parameter we are also able to capture the trigger-based frames during UL OFMDA. The command could look like this:

echo 5 6c:ab:05:9e:4b:6e > /sys/kernel/debug/iwlwifi/*/iwlmvm/he_sniffer_params

The number 5 is AID5, the station the AP has assigned the association ID number 5
The MAC address is the MAC address for our AP, the BSSID

A TXOP with UL OFDMA frames sent with trigger-based frames could look like this.

Wireshark TXOP

It is very small, but this is what it is:

  • The Basic Trigger, from the AP, that tells AID3 to sends its data in Resource Unit 53 (106-tones RU), AID2 shall send its data in Resource Unit 39 (52-tone RU), and AID5 shall send its data in Resource Unit 40. Inside this frame, all AIDs are told how they shall send their data
  • Then we capture 6 A-MSDUs inside an A-MPDU from AID5 on a 52-tones RU. And the frame format is HE TB PPDU
    • Remember we do only capture frames from the AID we choose. There are other AIDs which also send their traffic.
  • And at last the AP sends a Multi-STA Block Acknowledgment frame where frames from two different AIDs are Acknowledged. We can see that, at least, some of our captured A-MDSUs are acknowledged because the Starting Sequence Number in the Multi-STA BA contains the first sequence number of the transmission for AID5



The state of wireless capturing of ODFMA frames:

  • Single-user frames by natively start capturing at the NVIDIA Jetson Nano
  • Multi-user frame during DL OFMDA with the Echo command and choose the AID of the station we wish to capture multi-user frames for
  • Trigger-based frames during UL OFDMA with the Echo command and choose both the AID of the station and the MAC address of our AP


But we are still not able to capture the Block Acknowledgment during DL OFDMA. This frame is sent from all the stations which have received data in DL OFMDA and is sent with the trigger-based frame format. The difference between trigger-based frames during UL OFDMA and BlockAcknowledgment is this:

  • UL OFDMA uses the information from the Basic Trigger frame, sent by the AP.
  • Bloch Acknowledgment during DL OFMDA uses trigger information from the first MPDU sent in the A-MPDU during the DL OFMDA data transmission.

But I’m pretty sure someone will find a method for this pretty soon


Thanks to

I have not done this alone. I have to thanks these guys

LENGTH-the Underestimated Parameter in 802.11

LENGTH, the subfield in the legacy Signal field of every 802.11 WiFi frames legacy preamble is more important than you maybe think.

Remarks: This is primarily for the 802.11 5GHz band

During CWNA, and other wireless studies, the Duration value in the MAC header gets a lot of attention because it is used to protect the transmission. But this is only half the truth. The Duration value is only to protect the rest of the transmission after the frame currently been sent. In many of the 802.11 frames, this duration value is either 0 or a very small value. The only place it has real value is in a TXOP with protection, with RTS and CTS. In the RTS and CTS frames, this Duration value includes the duration of the rest of the transmission, including the QoS frame, the ACK-frame, and all the SIFS.

If you have a transmission of a Data frame without the preceding RTS and CTS frame, the only protection the Duration value has is to protect the remaining 802.11 Ack/Block Ack frame (including the SIFS).

Therefore, the protection for the transmission of the ongoing frame is the combination of the Rate and the Length field in the legacy Signal-field (L-SIG). This field is called legacy Signal-field for all PHYs except 802.11a, where is called Signal-field. But the content is always the same.

In the 5GHz band and either 802.11n, ac or ax (HT, VHT or HE) transmission the Rate subfield is always set to 6mbs. So it is the Length-subfield that matters.
The legacy Signal-field in the legacy preamble looks like this:


This L-SIG (legacy Signal) field is 24 bit and the Length subfield with 12 bits can have a value between 0 and 4095.
This L-SIG field is, in the 5 GHz-band, always sent with BPSK modulation and a coding rate of 1/2 over 48 data subcarriers and 0,8µs guard interval (802.11a standard). The bits in the L-SIG will fill exactly one symbol because BPSK modulates one bit at each subcarrier and with 1/2 coding rate it will be 24 user bits and 24 redundant bits in a symbol.


How will other stations on the channel interpret this field?

The L-SIG is sent with the legacy format (802.11a) and all the other stations will have a legacy mindset for both reception and interpretation of this field.
With rate equal to 6mbs (or BPSK 1/2) each symbol contains 24 user bits or 3 bytes/octets. If we use the number from the Length field, which indicates the desired duration of the transmission and adds an extra symbol we could calculate the duration of this frame.
The extra symbol is the 16 Service bits and 6 tail bits we have either before or after the PPDU. Even it is only 22 bits it accounts for one symbol.

The number in the Length-field can originate from different sources.
– For 802.11a the Length values are the number of bytes/octets been sent in the MPDU.
– The 802.11n/ac/ax PHYs manipulate this value because of the presence of the long or short guard interval, the number of spatial streams and the presence of extra preambles.

But the goal is still the same: A method for calculation of the duration of the frame.
The formula for the duration of the frame is this:

L-SIG duration

The funny parentheses indicate a rounding up to the next integer value.

An example, L_Length =58

L_SIG duration = (1+ roundup (58/3)) x 4µs = (1+20) x 4µs = 84 µs.

This value is used by the other stations on the channel to defer transmission. The receiving station will use this value or other parameters later in the reception to do a more accurate calculation of the amount of the received data.

This parameter has been a hidden feature in the physical header in the 802.11 standards, but it changes with the introduction of 802.11ax and OFDMA


802.11ax and OFDMA

This Length parameter is more visible in 802.11ax and OFDMA. When a non-Ap station (a client) need to send QoS data uplink to the AP with OFDMA, the AP must first send information downlink to the station where the AP tells how the uplink transmission shall look like. The Length-parameter is one of the information elements been sent. One method of sending this information downlink from the AP is with the trigger frames. This is two situations:

  • UL OFDMA where the non-AP station needs to send data uplink. The AP will first send a Basic Trigger frame with necessary information down to the non-AP station and the uplink QoS-data is sent in a trigger-based frame (HE TB PPDU).
  • DL OFDMA where the AP sends the trigger information for the 802.11 block acknowledgment in the first MPDU of the A-MPDU and the non-AP station responds with the block acknowledgment inside a trigger-based frame.


If we look at a trigger frame during DL OFDMA it could look like this in Wireshark. This is the first MPDU of an A-MPDU sent downlink to a non-Ap station and this trigger MPDU tells the receiver how it shall send the 802.11 block acknowledgment uplink

UL Length in Wireshark

The red box is the UL Length parameter. This parameter shall the non-AP station put into the Length field of the L-SIG during its uplink block acknowledgment transmission.
According to the formula above will all the other stations on the channel calculate the duration for how long they have to defer any transmission based on information in the L-SIG field of the uplink frame, 84 µs.
The AP does not need to be so careful with this because it knows the values.


The maximum value of the Length-field

The Length field in the L-SIG has 12 bits and has a maximum value of 4095, so the longest duration for an 802.11 frame will be

Duration = (1 + roundup (4095/3)) x 4µs = 5,464 ms.
The standards say 5,484ms, but I think this includes the legacy preamble of 20µs.



To simplify it. If we know the Length parameter, the duration of a frame is:

Duration (simplified ) = Length_parameter x (4/3)  [µs]




I have shown the importance of the Length subfield in the legacy Signal field of the legacy preamble (physical header).
And how we can use this parameter to calculate the duration of the ongoing frame.
This a formula to remember.

L-SIG duration


If someone disagrees or have any improvements, please contact me


Wireless Capturing of Multi-User OFDMA Frames

The introduction of the OFDMA feature in the 802.11ax standard gives us packet analyzers some challenges regarding wireless capturing. It is two aspects that are challenging. Capture data inside specific resource units (RUs) and how to visualize it in a graphic user interface (GUI) if we can capture several parallel transmissions.
Some experts have said it would be very difficult to do multi-user capturing, but I have always thought it should be possible to do this
It is basically the same transmission method as we have used for over 20 years. It is some new frame formats and the OFDM subcarriers are split between several stations, but that’s all (almost).


Wireless capturing in single-user frame transmission

In the case of single-user 802.11 transmission and the half-duplex structure of 802.11, only one station (STA) is transmitting at each time. It is therefore never more than one frame in the air at the time, assuming there is no collision, and the full contents (or channel)  is used by every receiving station.
The wireless capturing device will capture each and every frame, one after another and show it in the UI of our packet analyzer software.
A normal capture of single-user transmission (TxOP) looks like this:

Single-User frame

A very important aspect of single-user frames is that the unique identifier of each frame are the MAC addresses from the MAC-header of an 802.11 frame


Multi-user frames in OFDMA

When the AP, or the controller, decides to use OFDMA during transmission it introduces two new frame types.

  • For QoS data frames downlink from the AP to several stations (DL OFDMA), the AP uses a frame format called HE MU PPDU (the multi-user frame format).
  • For QoS data frames uplink from several stations to the AP (UL OFDMA), they use a frame format called HE TB PPDU (the trigger-based frame format).
  • I have several blog articles where those are explained in more detail.

For the stations to be able to receive its data in their assigned resource unit (RU) they have to look and decode a specific field during a transmission.

  • For DL ODFMA, all 802.11ax station in the BSS has to look into the HE-SIG-B field of the pre-HE preamble (the HE physical header) in the downlink multi-user frame and see if the AP sends data to him.
  • For UL OFDMA, the station has to use information in the previously sent Basic Trigger frame to find out if he is allowed to send its data, and in which RU and with which characteristics.
  • And the new unique value to identify each station during resource allocation is the association ID (AID), in which each station is assigned during the association process to the BSS.
    Let us take a closer look


Downlink QoS data frame in the multi-user frame format

The downlink multi-user frame format (HE MU PPDU), used for DL OFDMA, looks like this (simplified).


I have a blog article with a deep-dive of this multi-user frame.

The HE-SIG-B field in the HE preamble contains a Common field and one or more User Specific field, one for each of the stations that will receive data. The frame in this picture above contains one Common field, a User Specific fields for the station AID1 and a User Specific field for the station AID2. The frame can contain several other User Specific fields, but those have other meanings.

The Common field contains information on how the channel is subdivided for the data (A-MPDU) part of it. It is a bit pattern and in the frame above this pattern tells that the channel is subdivided in two times 106-tones RUs.

The User Specific field for each of the receiving station contains:
– The receiving stations association ID (AID)
– Number of spatial streams
– Use of transmit beamforming
– The MCS
– The use of Dual Carrier Modulation (DCM) or not
– The coding scheme, BCC or LDPC

Based on this information, the station which will receive data recognize its association ID (AID), see which type of RU (how many tones/subcarriers) is used, where the RU is in the frequency band (which tones/subcarriers), the MCS, numbers of spatial streams and coding scheme for its receiving data. And it will only listen to the assigned RU during A-MPDU reception.

One very important aspect for us to learn is that this is only one (1) frame transmission, sent from the AP. It is accidentally set up in a way where several independent A-MPDUs (data payloads) are modulated into specific subcarriers (RUs).


How to do wireless capturing of DL QoS ODFMA frames

For wireless capturing, we can use the same method as the receiving station does for its receiving of the A-MPDU.
But we must tell the sniffer to capture on specific association ID (AID) because our packet analyzer software is not capable to show several payloads in parallel, yet.
If the sniffer knows which AID it should capture, it uses the information from each frame HE-SIG-B field and captures on the assigned RU. This can change from frame to frame

The Intel AX200 NIC has the ability to capture frames on specific AIDs. Tim Higgins has sent me information on how this could be done on the NVIDIA Jetson Nano developer kit.

John Kilpatrick has a blog on how to build this device.
Francois Verges has a blog on how to do remote capturing on the same device.

The method is to start capturing and type this command into a terminal window, or via SSH, to the sniffer device

echo 0 00:00:00:00:00:00 > /sys/kernel/debug/iwlwifi/*/iwlmvm/he_sniffer_params

The first parameter is the value of the AID you want to capture.
The second parameter is the MAC address of a specific AP/BSS. You only need this in an environment where there are multiple APs using OFDMA.
If you want to capture on several AIDs, just toggle between the AIDs in your BSS. But remember that you can only capture frames from one AID at the time.

You will with this method capture all single-user frames and the downlink multi-user frames for the AID you have selected.

To examine the captured multi-user frames in your packet analyzer software, you can either use a display filter for MU-frames (in Wireshark).

radiotap.he.data_1.ppdu_format == 0x2

Or, in Wireshark,  make a column out of the same display filter. You find it in the RadioTap Header/ HE Information/ HE Data 1/ PPDU_ format.

Wireshark, MU-PPDU


How to find the Association ID (AID)?
This a very good question and is an area of further development.

If we want to capture and analyze a specific station with a specific MAC address in an OFDMA environment we need to know the association ID (AID) to this station. And a station AID will change when it roams to another BSS, or it re-associate to the BSS.
I have not a very good answer now, but this is some suggestions:

  • The association response frame when the station (re-) associate to the BSS
  • VHT/HE NDP Announcement frames, there are two types
    • The destination address is the broadcast address
      • Those contain STA Info with all stations in the BSS (STA List)
      • No MAC addresses
    • The destination address is a unicast address
      • Those contain both the STA MAC address (MAC header) and the AID (STA List)
  • Basic Trigger frame that precedes the UL OFDMA transmission
    • This contains the AIDs (User Info field) for the next UL OFDMA-transmission
    • No MAC address of the AIDs
  • Multi-STA BlockAcknowledgment frame, which ends a UL OFDMA transmission
    • This contains the AIDs (Per AID TID Info) for the received UL OFDMA-transmission
    • No MAC address of the AIDs
  • Capture some MU-frames and use either aliasing or write the connection between the MAC addresses and the AIDs on a paper
  • Look into the wireless controller or in the CLI of the AP. I have not tested this.


Very important remark
This method captures only the downlink multi-user frame in the HE MU PPDU format. The BlockAcks for those frames are sent uplink in a HE trigger format, similar to UL OFDMA

Uplink QoS frame in the HE Trigger format

The HE TB PPDU ( trigger-based) frame format is used when the stations (clients) sends data frame uplink to the AP in a multi-user format (UL OFDMA). I have several blog articles explaining this.

Briefly, it is like this:

  • the AP sends the Basic Trigger frame as a control type of frame. This frame contains information for which and how the clients (AIDs) shall send their uplink data.
  • the clients (AIDs) send their data in their assigned RU in the HE TB PPDU format.The HE TB PPDU frame format looks like this (simplified) when one of the stations sends its data in a specific RU

Trigger-based frame

Unlike DL OFDMA, where the AP sends one frame containing all the different payloads (A-MPDUs), in UL ODFMA each station (client) sends its own frame.
The AP will receive several frames in parallel and has to decode each and every one. But the payload (A-MPDU) from each station is into its own resource unit. This blog article explains the RF during UL OFDMA

BlockAcknowledment during DL OFDMA
The BlockAcknowledgment for the downlink QoS data frames in DL OFDMA is sent uplink in this trigger-based format, just like payloads during UL OFDMA.
The first MPDU in the A-MPDU during DL ODFMA contains the trigger information for the BlockAck.
Look at the Wireshark picture above showing the captured multi-user frames during DL OFDMA. The first MPDU, before the QoS MPDUs, is the trigger information for the uplink BlockAck


Are we able to capture uplink multi-user frames in the HE TB PPDU frame format?
I don’t know any methods for capturing this trigger-based frame yet.
This blog explains the current status of capturing UL OFDMA, where we capture the Basic Trigger frame and the Multi-STA BlockAck. And based on the information in these two frames we can interpret the trigger-based QoS frames in between.

There are to main challenges with capturing uplink trigger-based frames (my opinions)

  • The information the sniffer needs for capturing the uplink data frame for a particular AID is in the previous Basic Trigger frame from the AP. So the sniffer needs processor capabilities and code to do this.
  • Multiple frames in the RF spectrum. It is only the AP in an 802.11ax OFDMA environment that shall receive those types of frames and it is built to do it. Our capturing wireless NIC is build to be a wireless NIC in, what the 802.11ax draft calls, a non-AP station.
  • It is possible to use APs in sniffer mode. But still, we need a system to visualize selected AIDs in a packet analyzer


Permissions while using the echo command

When I use my NVIDIA Jetson Nano as the capturing device and sends the echo command to the sniffer, a failure message appears regarding permissions.
It is because of some permission rules in the OS of the Jetson Nano.
I am not very familiar with Ubuntu, but Tim has sent me this recipe

In terminal (or over SSH)
sudo chmod a+rx /sys/kernel/debug
sudo chmod a+rx /sys/kernel/debug/iwlwifi
sudo chmod a+rx /sys/kernel/debug/iwlwifi/0000:03:00.0
sudo chmod a+rx /sys/kernel/debug/iwlwifi/0000:03:00.0/iwlmvm
sudo chmod a+rwx /sys/kernel/debug/iwlwifi/0000:03:00.0/iwlmvm/he_sniffer_params

You have to check the file path and the name on the “0000:03:00.0” directory. It could be different. He sent this as a script, but I have to type each and every line separately.
This has to be done each time the sniffer reboots.


Triggering of the UL and DL OFDMA process

I have a lab network with a Cisco Catalyst 9115 access point and the Catalyst 9800CL wireless controller, three clients, and two WlanPi as the SpeedTest server.

The AP (and the controller) enables the UL OFDMA feature all the time, but it is a challenge to trigger the DL OFDMA feature. I must generate a lot of traffic and still, it’s difficult to trigger the DL OFDMA. Very often my network does downlink single-user OFDM on 802.11ax frame format instead of DL OFDMA.
Why: I think Cisco is still developing this feature and it will become better in future code releases 

I use SpeedTest against WlanPi as my test method because it generates a lot of traffic and it is easy to see in a spectrum analyzer whether the network does OFDMA or not.


I have explained the theory behind capturing multi-user frames in resource units and how we can capture the downlink multi-user frame in DL OFDMA with the Jetson Nano.
And maybe we can be able to capture uplink trigger-based frames soon.


A big thank you to Tim Higgins

I have to send a big thank you to Tim Higgins from https://www.smallnetbuilder.com

It is Tim who told me how to capture multi-user frames.







DL OFDMA, the RF Perspective

My previous blog post was on how the RF spectrum looks like during a UL ODFMA transmission.

This article is about the DL OFDMA transmission. The DL ODFMA transmission can be preceded by an MU-RTS (multi-user request to send) and CTS (clear-to-send). I keep it to a later article.


The Acknowledgment process
The most efficient mechanism to get the 802.11 acknowledgments back from the STAs (non-Ap STA) during DL OFDMA is to include a Trigger frame as the first MPDU in the A-MPDU.
The STAs will respond with a BlockAck in a HE TB PPDU immediately and in parallel. Just like the UL OFDMA process.
This picture (found on the internet) shows this process

DL ODFMA with Trigger for BA
This is a new method of sending the 802.11 acknowledgment. For 20 years this 802.11 acknowledgment frame has been sent in non-HT format as a Control frame on a mandatory data rate. In 802.11ax and DL OFDMA is one of the options is to send it in a subdivided trigger-based frame.
I will explain it in a later article.


A short summary of DL OFDMA
– In this example, the AP will data downlink to two STAs (clients)
– The AP decides to subdivide the 20MHz channel into two 106-tones RUs and send the data (payload) til client1 (AID1) in the lower 106-tones RU and the data(payload) to client2 (AID2) in the higher 106-tones RU.
– This receiving STAs sends their acknowledgment as BlockAck inside their assigned RU, based on the content in the Trigger frame, uplink to the AP in a TB PPDU format


The DL ODFMA frame
The frame been used when sending data down to multiple non-AP STAs in parallel is called MU-PPDU (multi-user). I have a deep-dive article on this.
Basically, the transmitting procedure is like this:
– First the legacy preamble
– The HE-preamble. It contains the HE-SIG-B field with information about the resource allocation for the rest of the frame.  It tells each receiving STA which RU the STA will receive its data on.
– The HE short and long training symbols
– The A-MPDU to each non-AP STA in their assigned RU, where the first MDPU is the Trigger information for Block Acknowledgment

From the perspective of the AP it looks like this:

MU PPDU , AP perspectice


The non-AP STA, let’s say AID1, will see in the HE-SIG-B field that the data to AID1 is sent in the lower 106-tones RU. The STA with AID1 will therefore only look at the subcarriers that are assigned for him, both short/long training fields and the data.
So from the perspective of AID1, the transmission looks like this:

MU PPDU , STA perspectice



The receiving STA will use the Trigger information from the first MPDU in the A-MPDU in the downlink data frame to build the frame that sends back the BlockAck. The frame type used for this is called HE TB PPDU and is the same method as used with UL OFDMA. UL OFDMA is explained in this article.

In this example, the receiving STA sends their BlockAck like this:

HE TB PPDU BlockAck, separated


Just like any other 802.11 frames, it starts with preambles using the full channel. And the BlockAck information is sent in their assigned RU.

From the AP perspective, those transmissions will be received in parallel.

HE TB PPDU BlockAck, parallel

This was explained in my previous article


This is DL ODFMA briefly explained


A friend of mine has sent me some packet captures with the Multi-User frame down to several clients. He uses SOHO-routers in beta code for this.
He has explained how he does it and today I was able to capture MU-PPDU from a Cisco Catalyst 9115 access point down to a Samsung S10.

I will put together an article on “how to capture DL OFDMA”


















UL OFDMA- Make RF Collisions Work

During 802.11ax UL OFDMA magic happens in the RF space. What were RF collisions before is with 802.11ax normal behavior.

I will in this blog briefly explain what happens in the RF space during UL OFDMA.
I recommend reading one of the previous articles where I explain what it looks like in Wireshark.
I will simplify it so it is two clients that will send their data uplink in two different 106-tones RU

A short summary of the UL OFDMA process
– The AP sends a Basic Trigger frame, as a broadcast frame, in the legacy frame format at one of the mandatory rates
– STAs (clients) that are announced in the Basic Trigger frame sends their data uplink to the AP in parallel
— The AP sends a broadcast Multi-STA BlockAck frame to acknowledgment the received data frames


The Basic Trigger frame
This is the frame that is sent by the AP to solicits an uplink triggered frame from one or multiple STAs. This frame is a control type of frame and is sent at one of the mandatory data rates.
The information in the Common Info field and the User Info field is used by the STAs to build their uplink data frames
It uses the full channel, 20MHz. A visualization of this could be like this
Basic Trigger frame.gif


The UL OFDMA data frame
The STAs (AID1 and AID2) will receive the Basic Trigger frame, interpret it and start sending their data in a frame format called Trigger Based frame (HE TB PPDU).

Each and every 802.11 frame has to start with the legacy preamble for backward compatibility, then these two have to send the pre-HE preamble because it is a 802.11ax frame. These two preambles are sent at the legacy subcarrier format, with 48 and 52 data subcarriers with 312.5KHz spacing. When this is done each STA will send the HE Short Training fields and the HE Long Training fields at the 802.11ax subcarriers format and at each STAs assigned subcarriers. And at last, each STA will send their data (A-MPDU) on their assigned subcarriers.
This transmission will start, from both STAs, a SIFS after receiving the Basic Trigger frame. A visualization of this is like this.

HE TB PPDU separated.gif

As we see, the legacy preamble and the pre-HE preamble uses the full channel and the HE-training fields and the A-MPDU is sent at each STAs assigned RU

If we combine these into one picture it looks like this, from the perspective of the AP
HE TB PPDU in parallel.gif

In legacy 802.11 (a,n and ac) this is a collision in the RF domain and the AP is not able to decode it correctly.
In 802.11 ax, the AP knows what is will receive and the legacy preamble of those two transmissions is equal because of the STAs (AID1 and AID2) uses information from the Basic Trigger frame to build the legacy preamble.
So the AP has basically one task: to use all its skills to prepare itself to receive a Multiple Input transmission (from MIMO). Spatial diversity, radio chains, memory, processor power, etc
And during the reception of the HE-training fields and the data (A-MPDU) the AP knows the setup (subcarriers, MCS, spatial streams, guard interval and so on).

And this works. My lab network based on Cisco equipment does UL OFDMA


The Multi-STA BlockAck
When the AP has received the data frame from the STAs, it acknowledgment the data frames with the Multi-STA BlockACK. This is a control frame sent at any of the basic rates, but it is usually sent at a mandatory data rate. Since it is sent at a basic rate it uses the full channel. Visualization like this

Multi-STA BlockAck.gif


This is UL ODFMA briefly explained


UL OFDMA, what do we see in Wireshark

During WLPC_EU we had an 802.11ax after-party where we tried to make OFDMA functioning with different vendors AP and we got someone to do OFDMA. But we were kicked out of the meeting room before we got good results.

I have a network at home that does UL ODFMA, but it does not do DL OFDMA.

I have a packet capture of the UL OFDMA transmission and will explain it in this blog.

A figure from the IEEE 802.11ax draft 4.0 tells this about UL OFDMA
UL OFDMA draft 4
If we look at the last three frames
— the AP sends a Trigger frame to the clients
— the clients (STAs) sends it data uplink to the AP in parallel
— the AP acknowledges the frames

Test network
My test network looks like this (very simple picture)
My network

What I do, briefly explained
– associate two clients, a Samsung S10 and a Jetson Nano,  to the Cisco 9115 AP controlled by the Cisco Catalyst 9800CL controller running version 16.12.0. The AP is in FlexConnect mode
— the clients run Speedtest against a WlanPi. Speedtest is started simultaneously on both clients
— a Jetson Nano in sniffer mode does packet capturing
— a Windows client running Wireshark receives the captures frames via sshdump
— a client running Ekahau ESS with RTFM (Real Time Frequency Monitor) with Sidekick connected

A prefer doing Speedtest against the WlanPi because it does a finite period of ping/jitter testing, download test, and upload test. In this way, it’s easier to see how the spectrum changes, instead of doing any kind of iPerf-test.

Spectrum picture

What is this
— a 20 MHz wide spectrum picture during the Speedtest upload test
— one client using a 106-tone RU (Resource unit) in the lower half
— one client using a 52-tone RU in the upper part
— a part of the spectrum with lower utilization


Packet analysis
It is still no available method that is able to capture frames that have data in subdivided RUs, so we capture only two packets during a UL OFDMA transmission. The standard describes the use of protection with MU-RTS and CTS, but my network doesn’t use protection. The MU-RTS and CTS are explained in a previous blogpost .
The captured frames are the Basic Trigger frame and the Multi-STA BlockACK

Basic Trigger frame
This is a new control frame the 802.11ax standard uses to trigger an uplink transmission from its associated clients. Wireshark is able to decode it, while Omnipeek doesn’ do it. I have explained the frame format for this frame in the MU-RTS/CTS blogpost, but here is a short recap. The basic Trigger frame consists of:
— MAC header
— Common Info Field
— One or more User Info field

Basis Trigger frame, the MAC header

Basic Trigger Frame, MAC header

The most important notice is that the Basic Trigger frame is a broadcast frame (RA= ff:ff….), sent from the TA with the BSSID address. The 9115 notation is because I have entered the AP MAC address into the ethers file in Wireshark.

Common Info field
Basic Trigger Frame, Common Info field
The Common Info field is information to the clients that are addressed in the User Info field on how they shall build the frame for the uplink data. The content in the Common Info field is outside the scope of this article.

Basic Trigger frame, User Info field
Basic Trigger Frame, User Info field, overview
This Basic Trigger frame has three User Info fields, meaning there are three clients (STAs) that are been allocated RUs for their uplink data.

If we open the two first User Info fields, it contains this.
Basic Trigger Frame, User Info field, detailed

In basic text, it says this for the first User Info field: Client (STA) with association-id 0x001 has been allocated resource unit number 53, and it should use coding type LDPC with MCS8 and 2 spatial streams.
Resource unit number 53 is the 106-tone RU in the lower band of this 20MHz channel.

The next User Info field says that the client (STA) with association-id 0x002 has been allocated resource unit number 39, and it should use coding type LDPC with MCS0 and  2 spatial streams.
Resource unit number 39 is the 52-tone RU right after the middle off this 20MHz channel.
Why MCS0. The controller has three clients in its association table so it allocates RUs to all clients, even if some of them have nothing to send. This is the first code version to Cisco that does UL OFDMA and its scheduling process will be better in later versions.

For client no 3, not shown in a picture
Client (STA) with association-id 0x003 has been allocated resource unit number 40. Resource unit number 40 is the last 52-tone RU in this 20MHz channel.

UL OFDMA data frame
The data frames are not captured. It is amazing stuff that happens during this transmission of the data frames but it will be a topic in another blog post.
In short: Clients send it data in their assigned RUs uplink to the AP.

Multi-STA BlockAck
When the AP has received and decoded the uplink data frames it will send an acknowledgment back to the clients. The AP uses a new Block Acknowledgment frame called Multi-Station BlockAcknowledgement, Multi-STA BlockAck. This frame is sent as a broadcast frame.

Multi-STA BlockAck MAC-header

MultiSTA BA, first part

The figure shows the first part of the Multi-STA BlockAck. The Receiver address is the broadcast address and the Transmitter address is the APs MAC address or BSSID.
This frame is sent straight after the data frames because the Block Ack policy requires an Immediate Acknowledgment and the type of frame is Multi-STA BlockAck.

Per AID Info field
There is three different Per AID TID Info field. This means that the Multi-STA BlockAck sends an acknowledgment to three clients. The first one


This is the BlockAck to association-id 0x001and has a starting sequence number of 3562. Each and every A-MSDU or MSDU that is aggregated into the A-MPDU have their sequence number in their MAC header. The number 3562 is the first sequence number that the AP has received in the data frame transmission.
When the AP receives those aggregated frames it makes what is called a scoreboard. This scoreboard is a view of which frames the AP has successfully received.
In the BlockAck the AP show which sequence number it expects to receive in the next transmission. In the figure, the sequence number of the next frame it expects to receive is 3582. This means that the AP has successfully received sequence number 3562 to 3581 in this transmission.
It could happen that the client has sent more MSDU/A-MSDUs, but the AP has not successfully received all. The AP will only acknowledgment those that are successfully received and the transmitter has to resend some of them
Example: Let us assume that the client has sent sequence number 3562 to 3590. Since the AP has the next expected sequence number to be 3582, the client has to retransmit sequence number 3582 to 3590.

The 802.11 standards until 802.11ax use mainly MAC addresses as unique identifiers for the different STAs, including the AP.
The 802.11ax amendment uses the association-id to the client as the unique identifier in many of the frames. We see this both in the Basic Trigger frame and the Multi-STA BlockAck.

The Basic Trigger frame tells three different clients to do UL OFDMA, the first one with the lower 106-tone RU (53), the next two in the two higher 52-tone RUs (39 and 40).
We are not able to capture the data frames.
The Multi-STA BlockAck acknowledgments successfully received sequence numbers in the aggregated data frame from the three clients.
The client that is allocated the first 52-tone RU is not present
The spectrum picture confirms what the packet capture tells.


UL ODFMA is working in my network, and it is possible to capture and interpret the transmission. The data frames, that are sent in subdivided RUs, is not possible to capture. But we can interpret and understand the UL OFDMA transmission by looking at the Basic Trigger frame and the Multi-STA BlockAck


Wireshark filter