Andrew McHale wrote a blog last week on “Will we be able to capture 802.11ax frames“. Since I was mentioned in it, I have to answer. I jump straight to the core and if you need some background, read Andrews blog

I will in this article try to explain some aspect regarding 802.11ax ODFMA wireless capturing, and suggest how it could be done in the future

 

Notes for this articles:

• I use the word client throughout this article. The correct word is non-AP station, according to the 802.11 standard.
• We don’t care about RSSI and other RF-parameters. The placement of the capturing device is important in a real world scenario
• There is a lot of acronyms in this article and I assume you know then
• When I write “OFDMA frames” I mean frames sent in resource units on a subdivided channel
• When I write “sending data to the client” I often mean both directions, both uplink and downlink

Status of today
I do capturing of both DL and UL OFDMA frames today when the network decides to do it. The last one is an important aspect. I use Cisco equipment in my test network and it is only in version 16.12.1 the network does both  DL and UL OFDMA. In version 16.12.4a, and other versions of code,  it does DL OFDMA under certain test setups, but not UL OFDMA. And, under the same test setup, the amount of OFDMA frames is less in newer versions of code.  It could probably be correct because OFDMAs intention is to make high-density network more effective. My lab network would never be able to simulate an HD network

Today, for capturing OFDMA frames, I need to know the association ID (STA-id) for the test client, and to obtain it I have to capture the association response frame during association. When I know the STA-id I send a command to the capturing device and tell it to capture OFDMA frames to or from that STA-id.
This is very constraining because in real-world scenario it is not easy to obtain this STA-id, and I must pre-set my capturing device with this value before the OFDMA capturing

Since I am only able to capture one (my) clients OFDMA frames I don’t know what happens in the other resource units during ODFMA.

When I set up my test to capture wireless frames in an 802.11ax environment, this happens:

• Capture all legacy frames, control/management/data frames
• Capture all single user 802.11ax frames
• Capture OFDMA frames for the STA-id (association ID) I choose
• When my selected STA-id sends OFDMA frames I loose the OFDMA frames from all the other clients doing OFDMA
• If the capturing device does not have a STA-id to capture on I miss all OFDMA frames
   

DL OFDMA background
When the AP sends DL ODFMA it basically sends an ordinary OFDM frame with the bandwidth used for that transmission. And it sends it in all direction decided by the antennas. But because it is a DL OFDMA frame the intended receivers have their data in specific parts (resource units) of the frame
The frame format for this DL OFDMA frame is called HE MU PPDU and looks like this:

Inside of the Pre HE preamble there is the field HE-SIG-B. The fields preceding the HE-SIG-B are sent with BPSK 1/2 encoding, the L-SIG over 28 data subcarriers, and RL-SIG/HE-SIG-A over 52 data subcarriers. The HE-SIG-B can be sent with MCS0 to MCS5, but I will think MCS0 will be used most of the time. Nevertheless, this field is heard and understood by all 802.11ax clients in the BSS. The format of the HE-SIG-B field looks like this:

The common field contains RU Information (Resource Allocation) for the Data field in this frame. And some other information. Basically it says how the channel is subdivided during the Data field transmission. For a 20MHz transmission, where the 106, 52, or 26 tones RUs are placed in the frequency space.

The User Specific field, have one User Specific subfield for each RU used in the transmission. The information in each subfield is:

• Association ID for the client receiving data in this RU
• Number of spatial streams
• Beamforming or not
• MCS-index
• Dual Carrier Modulation or not
• Coding, BCC or LPPC

A previous article, DL OFDMA, the RF Perspective, has a closer look at the RF perspective on this transmission.

After the HE-SIG-B field, the transmission changes to the 802.11ax subcarriers format and each intended receiver will have their data in their assigned RU

To sum up, the DL OFDMA transmission is a frame sent from the AP where the first part, the preamble, contains OFDMA resource information, and the last part, the data, in the different RUs have different characteristics.

Capturing DL OFDMA
When we put our capturing device in the middle, between the AP and the clients, this device could listen to the preamble and interpret, based on the HE-SIG-B field, how the channel will be subdivided during the data transmission. And it could be capable to capture and decode the data in each RU.

One challenge could be the different characteristics in each RU. Different MCS-indexes, different amounts of spatial streams, and BCC or LDPC encoding. I don’t know whether NICs like the Intel AX200 is capable of processing this. NICs used 802.11ax access point is capable to process it. They do this during UL OFDMA.

Another challenge is to visualize this in a protocol analyzer UI. I dwell on it later.

The data part from all the RUs in a DL OFDMA transmission is maybe not the most interesting part for wireless professionals, but the information from the HE-SIG-B is important. If we could get this out from the capturing NIC and visualized it in the protocol analyzer, it would be great. With this information, we could see how the channel is subdivided and which clients are receiving data with OFDMA

UL OFDMA background
UL OFDMA is an another topic.
During UL OFDMA, each client sends their data in their assigned RU in a trigger-based frame format. But before the clients can do this, they need necessary resource allocation information from the AP.
This information is sent from the AP in a frame called the Basic Trigger frame. This is usually a control type of frame. My article, UL OFDMA, basic Trigger Frame and Multi-STA BlockAck, explains this process.
Another of my previous articles, UL OFDMA- Make RF Collisions Work, has a closer look from the RF perspective.

To sum it up. The AP sends a Basic Trigger frame, a control type of frame. This contains information on how each client shall send their uplink data. This information is similar to the information in the HE-SIG-B field during DL OFDMA.
The clients send their data uplink, in parallel, according to the information in the basic Trigger frame

Capturing UL OFDMA
To do capturing of this transmission when several clients send their uplink data on their assigned RUs, the capturing device must use information from the previous Basic Trigger frame to know how it should interpret the transmission.
Again, the capturing NIC can have challenges with the different characteristics inside each RUs.
Maybe is the biggest challenge to synchronize receptions between each RU since it is sent from different clients with different RF characteristics and from a different location, so it could be minor timing differences.
An aspect is also that the setup, from the Basic Trigger frame, is optimized for uplink transmission towards the AP, not any other devices.

The Acknowledgment process during UL OFDMA is done by the AP where it sends a Multi-STA BlockAck frame. This is a control type of frame, where the AP ACKs UL OFDMA received frames from several clients in one frame.
Even without capturing the trigger-based data frame, it is maybe enough to look at the Basic Trigger frame and the Multi-STA Block Ack to understand the flow of UL OFDMA
E.g look at the STA-ID and other information in the Basic Trigger Frame and the increase of Starting Sequence Number and Bitmap in the Multi-STA BA.

DL OFMDA Data with BlockAck in a UL OFDMA frame
Until now we have looked at DL or UL OFDMA as separate entities. But one of the most effective methods of doing DL OFDMA is to embed information for the uplink BlockAck in the downlink OFDMA frame and send BAs from the receiving clients in a trigger-based uplink frame, just like UL OFDMA.
Like this:

A friend, Richardo Villareal, has captured it. It is the first time I have seen this in a capture. I am not able to capture this BlockAck.

We can see the Basic Trigger frame as the first MPDU, then several QoS data MPDUs inside the A-MPDU. The PPDU format column tells it is a MU PPDU frame. The last one is the uplink BA from the receiving client inside a trigger-based frame. Also look at the Starting Sequence Number from the BA, it corresponds to the Sequence Number of the first QoS-MPDU.

To sum up this scenario.
– The DL OFDMA frame is sent as a HE MU PPDU frame. It contains the resource allocation information for the uplink BA in a Basic Trigger MPDU and several QoS data MPDUs
– The BlockAck is sent inside i trigger-based frame.
– So during a DL OFDMA transmission, it is used both DL and UL OFDMA technology.

Wireshark as a protocol analyser
I am using Wireshark as my protocol analyzer. Wireshark shows us a lot of information from the preamble header in its RadioTap header and 802.11 Radio Information information fields, but there is a lot of information it doesn’t show. Whether this is information not available or information Wireshark doesn’t understand I’m not sure of. My latest version of Wireshark is version 3.2.6.
This is some of the information, from a DL OFDMA frame:

But still, we only see information for one STA-id/client. It doesn’t show which RU either and other information I think could be interesting.

What do I want to look at in a OFDMA capture
So, what could be interesting to see in a capture where there is OFDMA traffic. I am not sure if it’s possible or a financially sound to make something like this, but I can wish.

• First of all, we need a wireless NIC in monitor mode that can give necessary information from the scheduling process to the protocol analyzer
• A capturing NIC able to decode data from all RUs, even with different characteristics like MCS-indexes, spatial streams, BCC/LDPC encoding
• The ability to send the captured data to the protocol analyzer. The data must of course be serialized, even it is received in parallel. The AP does the same during UL OFDMA, before sending data out in the wire
• A protocol analyzer which can receive this data and visualize it in a suitable manner
• A kind of logic that can tie together STA-id against MAC-addresses. When the protocol analyzer knows the STA-id and captures the data, the client’s MAC addresses is in the MAC header of the data field
• With this logic, be able to use some kind of display filter for viewing traffic flow for a selected client based on its MAC address
• Viewing the HE-SIG-B field. It will give us information of which clients/STA-id using which RU and its characteristics during DL OFDMA
• Some kind of color diagram or a graph visualizing frame-by-frame or statistical how the channels is subdivided by using data from the HE-SIG-B and/or the Basic Trigger frame.
• And so on. This has to be an on-going process, implementing part by part.

As I said, I don’t know whether this is possible or not. And I’m not doing it. Other technologies use OFDMA, maybe it is possible to have a look at what they do if they do this

Summarize
I have looked at some parts of the 802.11ax OFDMA technology from a capturing point-of-view, and have ended up with a wishlist for a capturing device and features for a protocol analyzer.
Maybe we will have a capturing device and a protocol analyzer in the future that gives us visibility into the OFDMA process

Please, give me feedback in the comment sections of my blog or on Twitter. It is an interesting and fascinating item