Understanding OFDMA with Wireshark

The biggest change in Wi-Fi 6 is the introduction of Orthogonal Frequency-Division Multiple Access (OFDMA). OFDMA replaces Orthogonal Frequency Division Multiplexing (OFDM) at the PHY layer and brings support for frequency multiplexing across clients. In other words, a Wi-Fi 6 AP can now transmit to multiple clients simultaneously by using different portions of the bandwidth for each client. Each client only needs to listen to their portion to get their data. In OFDM, the entire bandwidth would go to one client at a time, and clients would need to wait their turn (time multiplexing). With OFDMA, we can also frequency multiplex across clients, splitting up the bandwidth to serve more than one client at the same time.

It also allows multiple clients to simultaneously transmit to the AP, achieved in the same way: each client uses a different portion of the bandwidth, and the AP listens to the entire bandwidth and simultaneously recovers each client’s uplink data.

Resource Units

How does OFDMA work? In Wi-Fi, the AP uses one of many channels that determines its frequency range. For example, my AP is set to channel 4 (which has a frequency range of 2407–2427 MHz), so it has 20 MHz of bandwidth. In OFDMA, this bandwidth is divided into equally spaced subcarriers (also known as tones). A 20 MHz OFDMA channel has 256 subcarriers that are therefore spaced 78.125 KHz apart. 242 of these subcarriers are data subcarriers and the others are used for channel synchronization and estimation.

Whenever the AP wants to utilize OFDMA, it assigns each target client a resource unit. A resource unit is a collection of neighboring subcarriers, so each target client gets a chunk of the bandwidth. The assigned chunks have to be non-overlapping to avoid interference. In the case of downlink OFDMA, AP then simulatnously sends client 1’s data on client 1’s RU, client 2’s data on client 2’s RU, etc. effectively splitting up the bandwidth across the clients. In the case of uplink OFDMA, the clients each send their data on their RU’s and the AP can simultaneously listen to all of them.

For example, resource unit 53 consists of 106 subcarriers on the left side of the channel. These form an 8 MHz channel. Resource unit 54 consists of the mirror image 106 subcarriers on the right side of the channel and also forms a 8MHz channel. During an OFDMA transmission, the AP could, for example, assign client 1 to resource unit 54 and client 2 to resource unit 55 since they are non-overlapping.

For a 20 MHz channel, the smallest possible RU has 26 subcarriers (so a bandwidth of 2 MHz). This means that the maximum number of clients an AP can serve simultaneously using OFDMA on a 20 MHz channel is 9 clients, as there are only 242 data subcarriers.

Association IDs

How do we assign clients to resource units? In order to differentiate between clients without using lengthy MAC addresses, the AP will assign numbers to each client upon association. This number is called the association ID (AID) and is used extensively in OFDMA to specify which clients get which RU.

OFDMA and Sniffing

OFDMA presents new challenges for Wi-Fi sniffing. Since OFDMA splits up the channel for multiple users, a sniffer can no longer just listen to all activity on a channel as it cannot demodulate multiple simultaneous data streams at the same time (unlike an AP which does this during uplink OFDMA).

Therefore, we need to tell the sniffer which AID to follow. Upon receiving an OFDMA frame, the sniffer will use the given RU allocation to tune itself to listen to the chunk of the channel meant for the client with said AID, just like that client would do. Similarly for uplink transmission: upon a trigger frame (explained below) the sniffer will tune itself to listen to the target AID’s uplink tranmission. Not all sniffers support this functionality, but my laptop Wi-Fi interface, an Intel 802.11be (Wi-Fi 7) card, does.

The driver of this Wi-Fi interface (iwlwifi) allows you to set a target AID through debugfs, so debugfs needs to be enabled. This is enabled on most distributions by default. However, you also need to enable the IWLWIFI_DEBUGFS kernel flag. This flag tells iwlwifi to enable its debugfs options. I am on NixOS, so this came down to adding the following lines to my configuration.nix and recompiling my kernel (nixos-rebuild switch):

# Enable debugfs for iwlwifi
boot.kernelPatches = [ {
name = "iwlwifi-config";
patch = null;
structuredExtraConfig = {
  IWLWIFI_DEBUGFS = lib.kernel.yes;
};
} ];

After this has been enabled, there will be a file in /sys/kernel/debug/iwlwifi/*/iwlmld called he_sniffer_params that one can write to in order to set a target AID.

Downlink OFDMA

The AP begins downlink OFDMA by sending a DL-PPDU (Downlink Physical Protocol Data Unit). It can optionally be preceded by RTS, which in this case would be a MU-RTS, but this behavior was not seen on my router. The DL-PPDU’s preamble contains a section (the HE-SIG-B preamble) which, among other things, specifies the RU allocation for the imminent data frame.

Every 802.11ax client will use this preamble to know whether they are included in this downlink transmission at all and, if so, their RU allocation for the imminent frame. This allocation is used to correctly demodulate their data and not any other client’s data. After the DL-PPDU has been sent, the AP follows up with a MU-BAR (Multi User Block Ack Request). This frame is a control frame sent at low speed and also contains an RU allocation; this time an uplink RU allocation for the clients’ eventual block ACK response.

(Even though every client hears the HE-SIG-B preamble and therefore has access to the entire RU allocation, Wireshark only provides information about the bandwidth of the RU allocation provided to our current target AID. Information about other client’s RU allocations or the exact position of our allocation is not available. Maybe drivers can be patched to provide this information?)

The above Wireshark screenshot shows a typical downlink OFDMA flow. The AP skips the MU-RTS/CTS option and goes directly into transmitting a multi-user frame. Our sniffer is configured to listen to AID 2, which corresponds to the Apple client. The Apple client is assigned a 106 subcarrier RU and we catch the 7 frames sent on that RU by the AP. The AP follows up with a MU-BAR, assigning the Apple device to RU 53 and another client device with AID 1 to RU 54. The Apple device responds in the last frame, using RU 53 to submit a Block Ack. At the same time, the second client device with AID 1 is using RU 54 to submit its own Block Ack, but this doesn’t show up on Wireshark as our Wi-Fi sniffer can only demodulate one RU at a time.

Uplink OFDMA

The AP can start uplink OFDMA by sending a Basic Trigger frame. This is a control frame that is sent at low speed and contains the uplink RU allocations for the stations. The stations use their respective allocations to send UL-PPDUs containing the uplink data. Finally, the AP sends a Multi-STA Block ACK to every client, allowing clients to retransmit lost frames if necessary. This Multi-STA Block ACK is sent using the entire bandwidth at a low speed (without OFDMA).

In order to efficiently allocate RUs, especially when using channels with larger bandwidths, the AP can optionally begin uplink OFDMA with a Buffer Status Report Poll (BSRP). This control frame requests clients to submit a Buffer Status Report (BSR), which indicates how much uplink data they are waiting to send. The AP then uses this data to allocate RUs. More details on BSRP and BSR below.

The above Wireshark screenshot shows an uplink OFDMA flow. The AP starts it with a Basic Trigger frame, assigning AID 1 and 2 to half of the channel each. The Apple client sends its uplink data on its assigned RU, and the AP finishes off with a Multi-STA Block ACK.

Buffer Status Report

With OFDMA, the AP has a lot more power. Instead of only deciding which one client to serve at a transmit opportunity, the AP can decide to serve multiple clients. But with great power comes great responsibility, which in this case is coming up with a reasonable RU allocation. For example, if client 1 is more bandwidth hungry than clients 2 and 3 combined, the AP can assign client 1 to an 8 MHz RU and client 2 and 3 to 4 MHz RUs each. This is easy to do in the downlink direction, because the AP knows exactly how much data it needs to send to each client.

However, the AP also provides RU allocations in the uplink direction. Let’s say client 1 is on Zoom while clients 2 and 3 are watching YouTube videos. Clearly client 1 requires more uplink bandwidth than the others. In order for the AP to learn about the uplink desires of each client, Wi-Fi 6 also specifies a Buffer Status Report (BSR) system.

A BSR contains information about how much a client is waiting to transmit. An AP can then use this to allocate RUs effectively. BSRs can either be unsolicited or solicited. Clients can voluntarily include a BSR in any of their data frames without an AP request: this is an unsolicited BSR. Otherwise, the AP can send a Buffer Status Report Poll (BSRP) to request clients to send BSRs. This is done with OFDMA, so each involved client responds with their BSR concurrently. BSRPs are also sent at low speed so all clients, including legacy clients, can hear them.

This is an example BSRP trace. The TPLink AP is requesting a BSR from the Apple client, so it assigns the entire 20 MHz band to it with the largest 242 subcarrier resource unit. The Apple client responds with 8 QoS Null frames. These frames are called Null because they contain no connection data, only metadata (in this case, the BSR). Why is the Apple device responding 7 times? And what exactly does the BSR contain? I hope to continue this post soon; stay tuned!

References

Thank you for reading! References and resources: