With the introduction of 802.11ax and the newly released frequency band for 802.11 transmission in the 6GHz band (WiFi6E) there have been talks about allowing only 802.11ax frame formats in WiFi6E. A week ago Jim Vajda (@jimvajda) released a blog article on “Whats Different About 802.11ax in 6Ghz“. This article concluded with the use of 802.11a, or non-HT, frame format for some types of control and management frames, and 802.11ax (HE) frame format for the rest.

In this article, I will describe airtime consumption for those two frame formats and show where 802.11a/non-HT frame formats consume less airtime than 802.11ax/HE frame format.

This article is only regarding airtime consumption for single user frame types. Multi-user frame types in 802.11ax/HE solve other issues. 

Frame formats

The frame format for 802.11a, called non-HT, and 802.11ax single user frame, called HE SU PPDU, is like this:

The non-HT frame format is build of the legacy preamble and the data field. The legacy preamble is consisting of Legacy Short Training Field (L-STF, 8µs), Legacy Long Training Field (L-LTF, 8µs), Legacy Signal Field (L-SIG, 4µs). This is also called the Physical header and is layer 1 information. The Data field consists of the MPDU (the user data and MAC header) and some bits called Service field and Tail bits. It is common to say the legacy preamble is sent at 6mbs, but it is only the L-SIG which are modulated with BPSK 1/2 over 48 data subcarriers. The L-STF and L-LTF are only waveforms used to synchronize the receiver.   
From an airtime point-of-view, the duration of this non-HT frame has a fixed value for the legacy preamble (20µs) and a variable time duration for the Data field.  The data field is modulated on 48 data subcarriers with different modulation and coding.

 

The HE SU PPDU frame format is an extension of the non-HT frame format, so the legacy preamble is the same. After the legacy preamble comes first the Repeated Legacy Signal field (RL-SIG, 4µs) and the HE-Signal field-A (HE-SIG-A, 8µs). The field until now is called Pre HE Preamble and it uses the same subcarrier format as non-HT with 312,5KHz spacing. It is a small difference since these new fields use 52 data subcarriers, while the legacy preamble uses 48 data subcarriers. This HE preamble is, because of the different use of subcarriers, sent with 6mbs for the legacy preamble and mcs0 (6,5mbs) for the remaining of the Pre-HE preamble.
Note; The HE MU PPDU can use another speed rate for its unique field (HE-SIG-B).
When the transmitter starts sending the HE-Short Training field (HE-STF, 4µs) it changes to the new 802.11ax/HE subcarrier format with 78,125 Khz spacing. The HE Long Training field can have a variable duration and variable repetitions. It depends on the number of spatial streams and other factors processed internally in the transmitter. The Data field consists of the MPDU and other fields depended whether it uses BCC or LDPC encoding. And there are other factors like pre-FEC and post-FEC padding process.
The duration of this HE SU PPDU preamble is 32µs for the Pre HE Preamble, 4µs for the HE-STF, plus the duration of the HE-LTF field. The data field is modulated on the 234 data subcarriers we use when sending HE SU PPDU frames on a 20MHz channel. Is it usually called a 242-tones Resource Unit and includes the 8 guard tones.
Because a lot of factors, data speeds in HE is higher than data speeds in non-HT for the same modulations and coding values

 

If we compare those two frame formats it is easy to see that the HE preamble has a longer duration than the non-HT preamble, and the non-HT frame format will have sent a lot of data before the HE frame is finished with its preamble. And we know data speed rates are lower in non-HT versus HE, but because of the different durations for the preambles will frame sent with non-HT frame format have lower airtime consumptions for some data field sizes.

 

Calculation setup

I will compare the airtime consumptions for the mandatory non-HT speed rates (6, 12, 24 Mb/s) against the same modulation and coding scheme with HE SU.
Non-HT 6mbs uses BPSK 1/2, non-HT 12mbs uses QPSK 1/2, and non-HT 24mbs uses 16-QAM 1/2. The same modulation and coding for HE are the MCS indexes mcs0/mcs1/mcs3. With the use of 1,6µs Guard Interval, the data speed is 8.1, 17.2, and 32.5 mbs.

For the HE calculation, I use 2 times HE-LTF 7,2µs, data symbol time 12,8µs, and guard interval 1,6µs. This is one of the mandatory setups for HE SU PPDU frames

The formula for calculating airtime consumptions for non-HT is

t= 20 + (round.up ((16 service bits + MPDU in bits + 6 tail bits)/user bits pr data subcarrier))*4   [µs]

The formula for calculation airtime consumptions for HE SU PPDU is

t= 36 + 7,2 + (round.up ((30 additional bits + MPDU in bits)/user bits pr data subcarrier))*14,4   [µs]

 

Note
– I use 30 additional bits in the HE calculations. It includes the service field, tail bits, and other bits. It is an estimated value
– The round.up is because each symbol must be filled up with padding bits
– The next table is not correct according to how 802.11 processes a frame setup, but from a mathematical point-of view the result is correct

The amount of number of data bits pr symbols changes by the modulation and coding scheme like this:

I will not explain the setup for the calculations in detail. The best method for you is to reverse engineer it.

 

Comparing airtime consumptions in graphs

When we insert all the data into a spreadsheet and make a graph showing airtime consumption for BPSK 1/2 for frame sizes from 10 to 330 bytes we get this:

As we can see in this graph the 6mbs non-HT frame has smaller airtime consumption than HE mcs0  frames from a small number of bytes, up till approx. 70 bytes.

 

For QPSK 1/2, 12mbs for non-HT and HE mcs1, it looks like this:

Here is the area where non-HT has smaller airtime consumption up till approx. 140-160 bytes.

 

And for 16-QAM 1/2, 24mbs for non-HT and HE mc3s, it looks like this:

Here is the area where non-HT has smaller airtime consumption up till approx. 300 bytes.

 

For all three modulations and coding indexes, the graphs show non-HT frame transmission has smaller airtime consumption than HE SU PPDU for smaller frame sizes. The braking point against HE SU PPDU is slightly different in regards to the modulation and coding scheme used. Be aware of the different resolutions on the y-axis, the airtime consumptions.

The frame sizes for the most common types of 802.11 control and management frames are:

• Clear to Send (CTS) and Acknowledgement (ACK) 14 bytes
• Request to Send (RTS) 20 bytes 
• Compressed Block Acknowledgement (B-ACK) 32 bytes
• A typical Basic Trigger frame is 40-60 bytes
• A typical Beacon frame is around 300-330 bytes
• Voice packets use frame sizes in this area too

So from an airtime consumption point-of-view, it not wrong to choose non-HT frame format for a lot of control and management frames in WiFi6E.

 

Another interesting moment from these graphs is the tagged shape on the HE graphs. It is because HE uses more subcarriers on a 20 MHz channel and can modulate more data pr symbol, but also the negative impact of using more padding bits to fill up a symbol.
Look at mcs0 and 16-QAM 1/2. Each symbol can transfer 468 user data bits out of a total of 936 bits, the last 468 bits is the redundant bits for error correction according to the coding scheme. So each symbol can transfer 58,5 bytes. It is why the airtime consumption is equal for frame sizes from 0 bytes to 58,5 bytes, and at 59 bytes it jumps up one symbol time.

 

Conclusion
The title for this blog article is “Can 802.11a be more efficient than 802.11ax?”

I have shown that non-HT (802.11a) frame formats have shorter airtime consumption than HE SU PPDU (802.11ax) frame format for smaller frame sizes. Depended on the modulation and coding scheme used the breaking point where non-HT frames go from smaller to longer airtime consumptions in regards to single-user HE frames are between 70-300 bytes.
So it is not wrong to use non-HT frame formats for a lot of control and management frames in a HE environment like WiFi6E.