LENGTH, the subfield in the legacy Signal field of every 802.11 WiFi frames legacy preamble is more important than you maybe think.
Remarks: This is primarily for the 802.11 5GHz band
During CWNA, and other wireless studies, the Duration value in the MAC header gets a lot of attention because it is used to protect the transmission. But this is only half the truth. The Duration value is only to protect the rest of the transmission after the frame currently been sent. In many of the 802.11 frames, this duration value is either 0 or a very small value. The only place it has real value is in a TXOP with protection, with RTS and CTS. In the RTS and CTS frames, this Duration value includes the duration of the rest of the transmission, including the QoS frame, the ACK-frame, and all the SIFS.
The parameter that shows the duration of the frame currently been sent and is used by other stations on the channel to defer transmission in the combination of the Rate and Length subfield in the SIGNAL-field of the legacy preamble (or legacy Physical header). In the 5GHz band and either 802.11n, ac or ax (HT, VHT or HE) transmission the Rate subfield is always set to 6mbs. So it is the Length-subfield that matters
The legacy Signal-field in the legacy preamble looks like this:
This L-SIG (legacy Signal) field is 24 bit and the Length subfield with 12 bits can have a value between 0 and 4095.
This L-SIG field is, in the 5 GHz-band, always sent with BPSK modulation and a coding rate of 1/2 over 48 data subcarriers and 0,8µs guard interval. This L-SIG will fill exactly one symbol because BPSK modulates one bit at each subcarrier and with 1/2 coding rate it will be 24 user bits and 24 redundant bits in a symbol.
How will other stations on the channel interpret this field?
The L-SIG is sent with the legacy format and the other stations must have the legacy mindset for this.
With rate equal to 6mbs (or BPSK 1/2) each symbol contains 24 user bits or 3 bytes/octets. If we put the number of bytes/octets in the Length field that indicates the desired duration of the transmission and add an extra symbol we could calculate the duration of this frame.
The extra symbol is the 16 Service bits and 6 tail bits we have either before or after the PPDU. Even it is only 22 bits it accounts for one symbol.
For 802.11a the Length values are the number of bytes/octets been sent in the MPDU. 802.11n/ac/ax manipulates this value because of the presence of the short guard interval.
The formula for the duration of the transmission is this:
The funny parentheses indicate a rounding up to the next integer value.
An example, L_Length =58
L_SIG duration = (1+ roundup (58/3)) x 4µs = (1+20) x 4µs = 84 µs.
This value is used by the other stations on the channel to defer transmission. The receiving station will use this value or other parameters later in the reception to do a more accurate calculation of the amount of the received data.
This parameter has been a hidden feature in the physical header in the 802.11 standards, but it changes with the introduction of 802.11ax and OFDMA
802.11ax and OFDMA
This Length parameter is more visible in 802.11ax and OFDMA. When a non-Ap station (a client) need to send QoS data uplink to the AP with OFDMA, the AP must first send information downlink to the station where the AP tells how the uplink transmission shall look like. One method of sending this information downlink from the AP is with the trigger frames. This is two situations:
- UL OFDMA where the non-AP station needs to send data uplink. The AP will first send a Basic Trigger frame with necessary information down to the non-AP station and the uplink QoS-data is sent in a trigger-based frame (HE TB PPDU).
- DL OFDMA where the AP sends the trigger information for the 802.11 block acknowledgment in the first MPDU of the A-MPDU and the non-AP station responds with the block acknowledgment inside a trigger-based frame.
If we look at a trigger frame during DL OFDMA it could look like this in Wireshark. This is the first MPDU of an A-MPDU sent downlink to a non-Ap station and this trigger MPDU tells the receiver how it shall send the 802.11 block acknowledgment uplink
The red box is the UL Length parameter. This parameter shall the non-AP station put into the Length field of the legacy Signal field during its uplink block acknowledgment transmission.
According to the formula above will all the other stations on the channel calculate the duration for how long they have to defer any transmission based on information in the L-SIG field of the uplink frame, 84 µs.
The AP does not need to be so careful with this because it knows the values.
The Length field in the L-SIG has 12 bits and has a maximum value of 4095, so the longest duration for an 802.11 frame will be
Duration = (1 + roundup (4095/3)) x 4µs = 5,464 ms.
The standards say 5,484ms, but I think this includes the legacy preamble of 20µs.
To simplify it. If we know the Length parameter, the duration is:
Duration (simplified ) = Length_parameter x (4/3)
Is the trigger information in the Wireshark picture for the uplink BlockAck
Since we have a capture of the downlink OFDMA multi-user frames, let us examine this.
The trigger information inside the PPDU of the Wireshark picture shall be used for the setup of uplink block acknowledgment. Let us interpret the information in this frame
- UL Length = 58, gives us a duration of the frame to 84 µs
- UL BW = 80 MHz. This is a part of an 80 Mhz transmission. There are other non-AP stations sending block acknowledgment simultaneously.
- GI and LTF Type: We shall use 4xHE_LTF in the HE preamble and 3,2µs as the guard interval in the data symbols
- RU Allocation: We shall use 242-tones resource unit number 63. This is the third 242-tone RU on the 80 MHz channel, the third 20MHz channel.
- We shall use MCS4, which is 16-QAM, 3/4 coding (4 modulated bits pr subcarrier)
- We shall use 1 spatial stream
- And the coding is LDPC (low density parity check). This is an improvement over the mandatory BCC (binary convolutional coding). It is kindly less effective in regards to the speed rate against the BCC, especially for small frame sizes, but it is more robust.
The HE TB PPDU frame format used when sending data uplink in the OFDMA format looks like this (from Rohde-Schwarz):
The Length parameter is inside the L-SIG field and the calculated duration (84µs) is from the start of RL-SIG to the end.
Total duration (after L-SIG) = the duration of (RL-SIG + HE-SIG-A + HE-STF + HE-LTFn + Data)
84 = 4 + 8 + 4 + ((12,8+3,2)x1) + Data duration –> Data duration = 84 – 32 = 52 µs
A compressed BlockAck is 32 byte = 256 bit
When the Data is encoded with LDPC there are 16 Service bits, but no tail bits. And it is some pre-FEC and post-FEC padding bits. Let us start with 272 bits.
With MCS4 (16-QAM) we modulate 4 bits pr subcarriers and on a 242-tone RU there are 234 data subcarriers, which gives us 936 modulated bits pr symbols. But with 3/4 coding rate, there are only 702 user bits pr symbol.
Those 272 bits we have to send, together with pre-FEC, post-FEC and padding bits, will fill up one symbol.
A data symbol in 802.11ax has a data symbol duration of 12,8µs. And we shall use 3,2µs guard interval so the symbol time in this transmission is 16 µs.
Summarize: We send this uplink block acknowledgment information inside one symbol, but we have still (52-16) 34 µs left for our data transmission duration or approx two symbols.
Whether this is because of other station’s needs for more time to send their block acknowledgment or we can send other elements in addition I am not sure of. Since we are not able to capture this uplink OFDMA frame it’s not easy to interpret this.
My interpretation of the HE-LTF.
HE-LTF is not easy to understand. In this case, I have used the value of the T (HE-LTF-4x) of 12,8µs plus the 3,2µs guard interval from table 27-12 in the IEEE802.11ax draft 4.3 and used it one time because of only one spatial stream. It could be right and it could be wrong.
UL Length = 58, not 60 (or 59)
It is another interesting thing with the UL Length value of 58. Since we do a dividing by 3 and round up to the next integer value when we calculate the duration for 802.11ax frames, why not send the Length value of 60 (or 59)? All those values will give the same result.
Here is why
In the 802.11ax standard, there are four different frame formats. Common with all of these formats is the repeated legacy SIG-field (RL-SIG) straight after the L-SIG field. When an 802.11ax receiver discovers this RL-SIG, it understands the presence of an 802.11ax frame. All other stations will not understand this field and use the above calculation to defer transmission for the duration of the frame.
When 802.11ax understands that the frame is an 802.11ax frame it does a MOD3 calculation of the Length value and examines the residue value.
MOD3 is dividing the Length parameter by 3 and look at the residue value (as I understand it).
Our Length of 58. MOD3 of 58 gives an integer value 19 and a residue value of 1 (I hope you understand it)
The residue value of 1 tells the receiver that it is either a HE TB PPDU or HE SU PPDU frame.
If Length was 59 and the residue of 2 will tell the receiver it is either a HE MU PPDU or HE ER SU PPDU frame.
For further differentiating between the different types of frames, is done with bits in the HE-SIG-A field.
Block Acknowledgment at MCS-speed
For 20 years the Acknowledgment or Block Acknowledgment frame has been sent at a basic speed rate, as a control type of frame.
In DL OFDMA this Block Acknowledgment frame (or MPDU) is sent at MCS speed rates inside a Resource Unit.
It becomes exciting to see all the possibilities for this frame/MPDU as OFDMA evolves over the next period
I have shown the importance of the Length subfield in the legacy Signal field of the legacy preamble (physical header).
And how we can use this parameter to calculate the duration of the ongoing frame.
This a formula to remember.
And the Block Acknowledgment frame/MPDU sent at MCS rates inside resource units
If someone disagrees or have any improvements, please contact me