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:

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.

 

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

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.

Summarize

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.