If you really want to dig into 802.11ax frame formats, a wireless capture (pcap) and Wireshark is a great way of doing it.
In this blog, I will dig into the preamble of an 802.11ax frame and point out several items to look at. I will also find information from the first part of the preamble, the legacy preamble
First of all, in the 802.11ax draft/protocol there are defined four different frame formats. They are
- HE SU PPDU. The single-user frame format. It is used when there is only transmission from one station to another station
- HE ER SU PPDU. This is a single user frame format which intention is to have a longer range
- HE MU PPDU. This is the multi-user frame format the AP use when it shall send data to two or more stations in parallel or simultaneously
- HE Trigger-Based PPDU. This is the frame format used by the stations when they shall send data to the AP in parallel or simultaneously. This frame is sent based on one type of Trigger frame from the AP
Next, it was a change in how the preamble or the physical header is written in the IEEE 802.11-2016 standards. The IEEE 802.11-2016 standards separate the preamble into two parts, the legacy preamble which is in every frame, and a PHY-dependent preamble. It can look like this:
The preamble for this frame format is all the way to the Data field and it consist of two parts
- The legacy preamble. This is common for all frame formats and all stations on the same primary channel will understand it, all 802.11 a/n/ac/ax stations.
- The HE MU Preamble. It consists of several fields and only 802.11ax capable stations are able to understand this part of the preamble.
One thing to remark is that the fields before the HE-STF are modulated with the same subcarrier format as 802.11a/n/ac, 312,5kHz separation. It is called, together with the legacy preamble, the Pre HE Preamble.
When the HE-STF starts, the preamble changes to 802.11ax subcarrier format with subcarrier separation of 78,125 kHz
I have earlier made a blog with a HE MU deep-dive, see here. It could be wise to have that as background information for the rest of this article.
Isaac Konikoff has a blog article, chasing trigger frames, where he has a lot of captures and I use the first one in my blog, with some selection. The file name is nano-ofdma-udp-down.pcapng
I have, from Isaac’s cap selected:
- one TXOP with SU transmission
- one TXOP with MU transmission down to a station and with the BlockAck in a trigger-based frame.
This pcap is attached at the bottom of the article:
The scenario is
- ASUS AXE11000 Wifi6E AP
- 5 GHz, 80 MHz WLAN
- Several stations receiving a UDP stream
- a wireless sniffer with an Intel ax200 NIC tuned to capture one specific AID (association ID)
- Wireshark version 3.4.4
Looking into a pcap
If we look at one of the data frames in Wireshark (frame 12) and open the RadioTap Header and 802.11 radio information in the packet detail pane it looks like this:
The two first subelements in HE information is only status messages which are added to the frame capture. If we expand the rest of the elements we will find almost every subfield from the HE-SIG-A and the HE-SIG-B field of the HE MU PPDU frame format. First, the HE Information Data 3-6:
I will not point out any of the subfields in the HE information Radio 3-6 because most of them are self-explaining. Please, use my earlier linked HE MU Deep Dive article as a reference. For more thorough information, look at the 802.11ax draft/standard.
If we expand the HE_MU information we get this:
Summarizing and remarks for this frame
Information in the HE Information and HE-MU Information is captured from both the HE-SIG-A and the HE-SIG-B field of the preamble and it could have been better organized (my opinion). Maybe it will be better in later releases on NIC drivers and Wireshark
We can summarize the attributes for the setup for sending the Data field:
- MCS 0xb, or MCS 11
- LDPC encoding
- 242- tones RU
- Shortest Guard Interval, 0,8 microsecond
- 2 spatial streams
Things to remark
- the data MCS in HE information Data 3 is a value from the HE-SIG-B and is unique for the transmission on this RU to this client. Other RUs can have other MCS rates
- The SIG-B MCS in the HE-MU Information (yellowed) is from the HE-SIG-A field. It tells that the HE-SIG-B field in this HE MU preamble is sent with MCS0. HE-SIG-B can be sent with MCS0 to MCS5
- The # of HE-SIG-B Symbols in the HE-MU information (yellowed) tells that the HE-SIG-B fields consist of four symbols. This will vary depending on how many recipients this transmission has and the MCS-rate of the HE-SIG-B field.
- The STA-ID in HE information Data 4 is wrong. The AID for this station is 0x01a or decimal 26.
- The other subfields are for other elements in 802.11 and 802.11ax standards like BSS Color, STBC, TxBF, Spatial Reuse, and so on. It is outside the scope of the blog article
What is missing
There are elements I think should have been shown in this pcap. Those are
- This data frame is sent on a 242-tones RU (approx 20 MHz) on an 80 MHz channel I can not find any indication of which RU been used
- Since this data frame is sent on a RU there is also transmission on other RUs to other stations/AIDs. The information on how the channel is RU-allocated and which station will receive its data in which RU is in the HE preamble (HE-SIG-A and HE-SIG-B). The capturing NIC reads and understands it, but for now, it only cares about information to the AID it is configured to capture on. I would love to see all the information from the HE preamble in the capture too. Not the data, only the HE preamble.
- There are fields under HE-MU Channel RUs. This could be useful data but I don’t know what it stands for yet
The Legacy Preamble
It is some very interesting information in the RadioTap header L-SIG element also. The L-SIG field is the last field in the legacy preamble and it is sent with legacy PHY. In 5GHz, it is sent with 802.11a frame format, and all stations on the channel that can decode it will understand and use it. Let’s look at it:
If we look at Data 2 we see that the rate is “0000”. This means 6mb/s and it is the usual value for the rate in the legacy preamble for PHYs like 802.11n/ac/ax.
The length is 458. If the rest of the frame were 802.11a frame format it would have meant that the Data field was 458 bytes. Since this frame is an 802.11ax frame only station understanding 802.11ax will understand the rest of the preamble. Other stations that don’t understand the rest of the preamble use these values (rate and length) to calculate the duration of this frame in microseconds and can/will defer its own transmission for that period of time. I have a blog article regarding the Length field, see here.
The formula is like this:
Another key item from the length value of 458 is to do a modolo3 calculation. Divide the value with 3 and look at the rest. 458 mod3 give the rest of 2. (Not mathematically correct described, I assume)
The receiver uses this number together with some other attributes to find out which type of 802.11ax frame format it receives. I have a blog on that topic too, look here
Remark: It is a difference between the rest values and the frame format between this article and the linked article. In this article, the rest is 2 for HE MU PPDU while the linked article says the rest for ME MU PPDUs is 1. I have discovered flaws in the linked article. It will be updated soon.
I have in this blog article shown how much of the HE preamble is captured and shown in Wireshark when we use the Intel AX200 NIC as the capturing device. I have shown it for the HE MU frame, and it is likewise for both the SU and Trigger-based frame.
It is not true that the preamble is not possible to capture. This is because the word Preamble has a different meaning in the IEEE 802.11-2016 standards and those who say it not possible have not updated their knowledge
The attached pcap consist of both SU, MU and Trigger-based 802.11ax frame. Please use it to discover all the contents of the HE preamble.
Look also at the difference of the BlockAck between the SU TXOP and the MU TXOP.
There are also control frames with legacy frame format, 802.11a.
Tip: Use the “Apply as Coloumn” feature in Wireshark
I have used Wireshark version 3.4.4