In Wireshark version 3.2.1 for Windows, there is a field where the value of the Rate and the Length subfield from the Legacy Signal field in the Physical header is shown for 802.11ax aggregated frames

.
Let us use this and have some fun.

I have earlier written a blog article about “LENGTH-the Underestimated Parameter in 802.11“. This article was written before Wireshark v3.2.1 was released.
The purpose of that article was to tell how the Legacy-Length field in the Physical header is been used to protect the ongoing transmission and how other stations use this information to defer its own transmission.
You should read that one first.

Remark: The value for the duration based on the Length-field (and Rate) is the duration from the end of the legacy preamble to the end of the transmission (the HT/VHT/HE preamble and the A-MPDU). The legacy preamble is not included in this duration.
Like this:

 

Wireshark
Wireshark has, from version 3.2.1, the ability to show the Rate and the Length subfield from the Legacy Signal field.
In Wireshark, make a column out these fields
– RadioTap Header/L-SIG/Data 2/Rate
– RadioTap Header/L-SIG/Data 2/Length

Then we get this:

This says (for frame 3) the rate of 6Mb/s and a Length field of 340 bytes.
Remark: Frame 3-6 is single-user 802.11ax (OFDM) and frame 10-13 is multi-user 802.11ax (OFDMA) frames at 5GHz

 

My previous article was about 802.11ax frame aggregation and we will use data from that article.

• Frame 3-6 is an 802.11ax single-user transmission with these data
  • The A-MPDU with 5344 bytes
  • 20MHz channel i.e. 242 subcarriers
  • mcs 4, GI = 0,8µs, 2 spatial streams
  • LDPC encoding, but we assume it uses the same mcs scheme as BSS encoding

 

If we put these data into my WiFi Airtime Calculator we get these durations:

• PHY HE preamble duration of 20µs
  • Remark: There is a flaw in the calculator. It calculates a HE-SIG-B field in the HE preamble. During single user 802.11ax transmission, there is no HE-SIG-B field. So the correct HE preamble duration for this transmission is 20µs.
• A-MPDU duration of 421,6µs
• The total duration of 441,6µs

 

From the Length blog article, we have this formula for the duration of a frame. This calculates the duration from the Legacy preamble ends to the end of the frame

With the L-Length value from Wireshark (frame 3-6) of 340 bytes, we get this:

L-SIG duration = (1+(roundup(340/3)) x 4µs = 460 µs

 

What can we interpret from this
The frame transmission has a duration of 441,6µs, according to the WiFi AirTime Calculator
The value in the L-Signal field of 340 bytes gives a duration of 460µs. This field is decoded by all clients (STAs) on the channel and they will defer transmission for at least 460µs.

Conclusion 1: The frame transmission is protected

It is almost 18µs difference between those two values.
It could one or more out of these reasons:

• Some flaws in the WiFi AirTime calculator
• Additional padding, packet extensions or else in the frame transmissions I don’t see in Wireshark
• Vendors implementation of the standard
• But the frame transmission is protected based on values in the Legacy Signal field

 

The frame transmission using OFDMA

Let us do the same exercise on the frame transmission when OFDMA is used.
From the Frame aggregation blog, we have these data

• Frame 10-13 is 802.11ax multi-user transmission with these data
  • The A-MPDU with 5374 bytes (the Basic Trigger MPDU in addition to the above transmission)
  • 106-tones resource unit (RU). We assume the rest of the channel is a 106-tones RU, so the HE-SIG-B field in the HE preamble informs two STAs with resource allocation information.
  • mcs 4, GI = 0,8µs, 2 spatial streams
  • HE-SIG-B sent with mcs0
  • LDPC encoding, but we assume it uses the same mcs scheme as BSS encoding

 

If we put these data into my WiFi Airtime Calculator we get these durations:

• PHY HE preamble duration of 32µs
  • Remark: This value is correct in the WiFi AirTime calculator because the HE-SIG-B field is 70 bits when two STAs are informed with resource allocation and it will use 3 symbols.
  • If you want a deep-dive into DL OFMA, read this pdf.
• A-MPDU duration of 966µs
• The total duration of 998µs

 

From the Length blog article, we have this formula for the duration

With the L-Length value from Wireshark (frame 10-13) of 1115 bytes, we get this

L-SIG duration = (1+(roundup(1115/3)) x 4µs = 1492 µs

 

What can we interpret from this
The frame transmission has a duration of 1018µs according to the WiFi AirTime Calculator
The value in the L-Signal field of 1115 bytes, which is decoded by all clients (STAs) on the channel, so all other stations will defer transmission for at least 1492µs.
Conclusion 1: The frame transmission is protected

But there is a big difference between those two values, 494µs.
My estimation is this:

• Since the AP (this is DL OFDMA) has decided to use OFDMA in this TXOP, the AP sends traffic to other stations on other resource units in parallel.
• We have not captured the other STAs transmission so we don’t know whether it has used 106, 52 or 26-tones resource units.
• And we don’t know the amount of data been sent to other stations.
• One of the other resource units transmission has most likely an A-MPDU transmit duration of approximately 1492µs, including the HE preamble
• Whether the AP, for this transmission, fills the gap with padding bits or nothing am I not able to capture and interpret in Wireshark. But according to the standard, it shall use padding bits to fill up the duration time.

Joshua Williams has a nice animation of this padding process, see here

We can draw it like this if we assume the AP sends data til two stations on 106-tones RUs :

 

Length vs Duration in Wireshark
When we use Wireshark as our protocol analyzer we can find the Duration of some frames in the 802.11 Radio Information field/Duration.
This is for control and management frames with 802.11a frame format and some non-aggregated data frames. This is an example of a Clear-to-Send frame

The duration is 44µs for the full-frame, including the Legacy preamble which is always 20µs in the 5GHz band.
The 24µs duration for the Data field in the 802.11a frame format (non-HT) means 6 symbols of 4µs to transmit the 14 bytes CTS plus additional overhead (service bits, tail bits)

For aggregated frames, there is no such Duration information in Wireshark. It is possible to look into the Duration-field (NAV-timer) in the MAC-header of the preceded RTS/CTS if they are used, and have an approximate view.

But with the L-Length field and some manual calculations, it is possible to calculate a precise value of the duration of an aggregated frame.

 

Remark
I use Wireshark as my protocol analyzer. I don’t know whether this is possible in other protocol analyzers.

 

Conclusion
I have shown how we can use the Lenght-information in the Legacy preamble (physical header) to calculate the duration of an 802.11ax aggregated frame with this formula