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.

Theory
A figure from the IEEE 802.11ax draft 4.0 tells this about UL OFDMA

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)

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

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

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

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.

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

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.

Remark
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.

Summarize
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.

 

Conclusion
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

 

Wiresharkfilter