During 802.11ax UL OFDMA TXOPs, clients that are assigned a resource unit (RU) by the AP for uplink data transmission will send data in that specific time slot.
But do clients use this time slot efficiently? Wireshark doesn’t give the answer

Let us have a deeper look in an example

A UL OFDMA TXOP from Wireshark

What do we see in this TXOP?

Basic Trigger frame
— Basic Trigger frame assigns RUs and other stuff to the associated clients that have data to send uplink
— A Network Allocation timer (NAV) at 294 microseconds
– -A UL Length parameter of 154
– -This is an 802.11a Control type of frame and from the Packet Detail and 802.11 Radio Information field we can find the duration of the frame including the 802.11a preamble. It is 52 microseconds

Uplink data
— Two QoS Data frames with Data length of 68 bytes + the 802.11 MAC header of 38 bytes
— Three Null Data frames. Those are only 802.11 MAC headers of 30 bytes
— Since all the blue frames are sub A-MPDUs inside a A-MPDU there are 4 bytes delimiters between each frame, not seen in a capture
— And there are some other bytes not seen in a capture
— Data rate of 56,7mbps on a 106-tones RU

Multi-STA BlockAck
— Multi-STA BlockAck for acknowledgments of the uplink data. As for the Basic Trigger frame, it is possible to obtain the duration from the 802.11 Radio Information field. This is 72 microseconds

SIFS
— Between uplink and downlink transmission there is a SIFS of 16 microseconds. Not seen in the capture

The calculation for the assigned duration of UL OFDMA data frames based on the NAV
Based on the above values we can calculate the assigned duration (time slot) for the UL OFDMA data frame, the full A-MPDU. Like this:

What about the UL Length from the Basic Trigger frame?
The UL Length parameter the AP sends to the clients in the Basic Trigger frame is the value the uplink clients shall set in the Length field in the legacy preamble. This is information for the other stations on the same channel.
How do they interpret this information?
In 802.11a the Length parameter in the preamble tells the numbers of bytes in the Data field. Newer clients combine the Speed parameter which are usually 6 Mbps and the Length parameter like this:
— 6mbps OFDM is BPSK modulation and 1/2 coding over 48 data subcarriers
— 1/2 coding means there are 24 databits in a symbol or 3 bytes
— Then they divide the Length parameter with 3 and get the number of symbols for the data field
— At last, the clients multiply the number of symbols with the legacy symbol time, 4 microseconds.
— Now they got a duration value for the rest of the frame that will be transmitted on the channel and can defer its own transmission or contentions for this period. This is almost like the NAV except is it transmitted in the legacy preamble.
– In this example, the UL Length parameter is 154. Divide it by 3 and multiply by 4 gives 205 microseconds.

As we can see, there is a difference between this calculated number and the number from the NAV calculation. This is because by use of some simplified formulas and some other minor elements. But the difference is only 15 microseconds or approx an 802.11ax symbol time, including the guard interval.
I will use the NAV calculated value in the rest of the blog article. The difference has no major impact on this blog article.

How much UL OFDMA data is it possible to transfer in the assigned period/time slot
In our example, the duration for UL OFDMA data transmission is 190 microseconds.
We have to subtract the UL OFDMA preamble. Let us assume it is 50 microseconds, so the duration for data bits are 140 microsecond

Amount of data over 140 microsecond= Time period x data rate => 140 microseconds x 56,7 mbps = 7,9 kbits = 992 bytes

What is the duration of the data transmission for this client and this TXOP?
— Each QoS Data frame has a Data Length of 68 bytes + 802.11 MAC header of 38 byte
— Each Null Data frame is an 802.11 AMC header of 30 bytes
— A-MPDU delimiters between each sub A-MPDU, and some additional paddings
— A total of approx 340 bytes
— 340 bytes sent with a data rate of 56,7mbps gives a duration of 48 microseconds
— If we then add on the HE UL OFDMA preamble of approx 50 microseconds it gives a total duration of 98 microseconds, approx

Small conclusion
The client uses only 98 microseconds of the uplink transmit window to transfer data bits while it could have used 190 microseconds. The remaining period has to be filled with padding bits

Why did the client not fill the full uplink window with data bits?
The client used only approx half of the assigned duration to send uplink data bits including HE preamble. It sent only 340 bytes while it could have sent approx 992 bytes
If we look at the Null Data frame, it tells us that the client still has data in its queue/buffer for TID 0 or access category 0. The Queue size of 5 indicates that it has (5×256) 1280 bytes in its buffer.
So why did it not sends more data?
For now and forever it is the client’s NIC driver who will decide this and maybe it will do a better job in newer driver versions

Would SU operations do a better job?
What if the clients used single-user frames instead?
First of all, instead of two clients sending uplink data in the same TXOP it must have used two TXOPs for the same data. Thereby double use of 802.11 contention methods.
The data rate for the Multi-STA BlockAck is 6 Mbps while the Basic Trigger frame was sent at 24 Mbps. In a SU operation, the Multi-STA BA would maybe be sent at 24mbps.
And most importantly, a single-user TXOP would not send so many padding bits. Single user operation fills the last symbol with padding bits and no more (not totally exact, but closely).
So for this example, it is not easy to calculate what method is the best one

In fact, most of the frames in the full packet capture are single-user frames. It was a SpeedTest

What do we not know/see?
The challenge with this method of multi-user packet capture is that we only capture the multi-user data frames from the client we decide to capture during multi-user operation.
We don’t see the frames from the other clients. It can be that those frames fill the uplink window better

Conclusion
I have in this blog shown that 802.11ax clients in many cases don’t fill the uplink window with data bits during UL OFDMA. This behavior is not shown in Wireshark. You have to do some manual calculations to obtain this.
But remember, OFDMA works better in a high-density network with a lot of clients according to its definition. This test is done with two clients

It was a rather mathematical blog article and all values are approximate values.
I hope it is useful

If you want to look at the capture you will find it in this blog article