802.11 Frame Aggregation is the technology in WiFi that enables the sender/transmitter to “pack” together several frames and send them in one frame transmission, a TXOP.

I will in this case study drill down in a frame capture and interpret the different parts of an 802.11ax aggregated frame transmission, both a single-user transmission (OFDM) and a multi-user transmission (OFDMA).

The wireless capture I use in this case study contains two-level aggregation, where A-MSDU is sent inside an A-MPDU.

Setup
My network is the same as earlier blog articles and I have captured a downlink transmission from my Cisco 9115 AP to a Jetson Nano Developer kit with Intel AX200 NIC. The capturing device is also a Jetson Nano Developer kit with Intel AX200 NIC.
The protocol analyzer is Wireshark version 3.2.1 for Windows.

The test is done in downlink direction and the client is doing a downlink iperf3 test with UDP-packet sizes of 1000bytes. The iperf server is a WlanPi and since we send data from the iperf-server to the client we use this command on the clients iperf-application

iperf3 -c 192.168.99.26 -u -b 20m –length 1000 -R

This command says: do iperf3 as a client against the server with ip address 192.168.99.26 with a throughput of 20 Mbs. Use 1000 bytes UDP packets and send them from the server and down to the client (reverse).

The WiFi network is with open authentication (no encryption) so we can drill into the data payload.

The attached wireless pcap
The wireless capture is attached pcap.
The capture is an extract from a big capture and I have found two equal transmissions(TXOPs).
The single-user transmission (frame 2-6) is missing the RTS-frame (Request to Send).
The multi-user transmission (frame 10-13) is missing the trigger-based Block-Ack. I have no method of capturing this frame for now.

I use both aliasing and Metageek color rules, so if you download the pcap and look into it it could look different.

 

Constraints and comments
This theme is very big and there are a lot of very big papers on the internet which go deeper than this article. But they have a more throughput approach.
I have a more protocol analysis approach and use Wireshark to look at the different items.
There is a lot of items I don’t describe and I was in doubt whether to write this article or not. So you have to take it for what it is.
And please, give feedback if you want.
This is an article with a lot of A-MPDU and A-MSDU acronyms. Please, think every time you read these

 

Single-user transmission
First, we look at a single-user (OFDM) 802.11ax transmission downlink. This is what we see in the capture at first glance (frame 2-6). The RTS is missing

Nothing particular with this. An ordinary TXOP with 3 aggregated QoS-frames.

But if we go into the QoS-frames and find these fields and make them as columns:
–  RadioTap Header/HE Information/HE Data 1/PPDU Format
–  IEEE 802.11 QoS Data/QoS Control/Payload Type
–  IEEE 802.11 Aggregate MSDU/one of the subframes/A-MSDU length  (an A-MSDU frame)
–  IEEE 802.11 Aggregate /Data/Length

For the last two, you have to check all three QoS-frames to see the difference.
Now we see this (I have removed the first columns):
What can we interpret from this:
– it is a 802.11ax single-user transmission because of the HE_SU PPDU format
–  there are three A-MPDU subframes because 802.11ax does send its data frames as A-MPDU
– it uses two-level frame aggregation because it sends what Wireshark calls A-MSDU and MSDU inside an A-MPDU
– and we recognize the 1000 bytes packet and there is some overhead in the A-MSDU subframes

I will use this frame transmission further on in this article

 

The general A-MPDU frame
802.11ax (and 802.11ac) send data frames with the A-MPDU frame format. In this frame transmission, there are three different A-MPDU subframes (the blue ones in Wireshark). So we can draw it like this:

The first is the general format and the second is our transmission. As always it starts with the Physical header and then there are three A-MPDU subframes. And in the end, there is an EOF Padding field.

 

The first A-MPDU subframe
In our transmission, the first A-MPDU subframe is an A-MSDU consisting of two MSDU subframes. It looks like this:

Each A-MPDU subframe consists of an MPDU Delimiter, the PSDU, and Padding.
In the MPDU-field there are two different MSDU subframes and they are preceded by a MAC-header because it is an A-MPDU subframe.
Each MSDU subframes consists of a subframe header, the MSDU and, padding
The Wireshark capture looks like this:

The red squares are the MAC-header and each of the two MSDU subframes.
Inside each of the MSDU subframes, we can see (blue rectangles)
– A-MSDU subframe headers with the Destination address, Source address and, the A-MSDU length
– the payload overhead from the  LLC, IP and, UDP-layer in the OSI-stack
– the data (or payload) which are the 1000 bytes UDP-packet

The green rectangle in the MAC header is the FCS value. These four bytes are sent towards the end of the subframe, but Wireshark will always show it together with the MAC header.

Padding in A-MSDU subframe
Each A-MSDU subframe has a Padding field, 0-3 bytes. The rule for this field is that the total amount of bytes in each non-final A-MSDU subframe shall be a multiple of 4 bytes.
If we look closely at the capture for the first A-MPDU subframe we can see that the first A-MSDU is 1052 bytes and the second is 1050 bytes. 1052 is a multiple of 4, 1050 is not.

In each A-MSPD subframe, there are 14 bytes subframe header, 36 bytes LLC, IP and UDP header and the 1000 bytes payload. A total of 1050 bytes.

Therefore is the first one A-MSDU subframe padded with 2 bytes and the last one without padding.

How can we see these byte values:
Wireshark can show us the length of different values/field. We can mark one line and there will be information in the button of the Wireshark screen. Example:

 

The MPDU Delimiter
Each A-MPDU subframe starts with an MPDU Delimiter and it looks like this:

This is something that is processed in the lower levels in the MAC-layer of the receiver and information of this “could” be found in the  RadioTap header in Wireshark. I can not find any good information regarding this in Wireshark.

The Delimiter Signature is a unique pattern and the receiver search after this signature if there has been some kind of bit faults during the reception. And because of the non-final subframe 32-bit rule, the receiver can recognize this pattern and thereby understand when a new A-MPDU subframe starts.

So, to summarize the padding field. All non-final A-MSDU subframes and A-MPDU subframes shall have a multiple of 4 bytes

Summarize the first A-MPDU subframe.
If we summarize the first A-MPDU subframe, who is an A-MSDU inside an A-MPDU subframe, and write the different bytes-values in it, it will look like this:

Remarks on the different Padding fields
– the first one has 2 bytes with padding because the sum of bytes in non-final MSDU subframes must be a multiple of 4 bytes (32 bits word). Total for the first A-MPDU subframe 1052 bytes
-the second padding is  0 because the previous rule is not used on the last A-MSDU subframe. Total for the second/last A-MPDU subframe 1050 bytes
– the last padding is also 0 because of the full A-MPDU subframe rule of the 32-bits word rule. There are 2136 bytes in this non-final A-MPDU subframe. 2136 is a multiple of 4.

 

The second A-MPDU subframe
The second A-MPDU subframe is an MPDU inside the A-MPDU frame. It will look like this:

And the Wireshark capture looks like this:

And lastly with the byte values:

Here is the padding with two bytes because of the 32-bit word rule, a total of 1072 bytes.

 

The third A-MPDU subframe
The contents in the third A-MPDU subframe are the same as A-MPDU subframe number 1 and it is totally equal.
It could have been a difference at the last Padding because the last A-MPDU subframe doesn’t have to be a multiple of 4 bytes.

The EOF padding subframe
I have to admit that I don’t understand it, so let us assume it does not exist in this frame transmission

 

Summarizing the full A-MPDU
The full A-MPDU consists of three A-MPDU subframes. The first and the last one is equal and together it looks like this. This picture is with each A-MPDU subframe on a separate line, but they follow each other continuously. And of course, the PHY-preamble precedes this

The total length of the A-MPDU is 5344 bytes.

802.11ax can also use packet extension (PE) at the end of the Data field, after the A-MPDU. The packet extension can be used to give the receiver time to build its answer, e.g the Block-Ack. The packet extension can be reduced if there is little data in the last symbol or much padding to fill this last symbol.

 

The same A-MPDU sent with OFDMA (multi-user) in Resource Units
If the same A-MPDU shall be sent with OFDMA technology in Resource Units (RU) in the downlink direction (DL OFDMA) the first A-MPDU subframe is often a Basic Trigger PPDU. This Basic Trigger frame is used by the receiver of the A-MPDU to build and send back the trigger-based Block-Ack.
The capture looks like this. I have marked the Basic Trigger frame so we can see the content of this Basic Trigger frame in Wireshark.

The A-MPDU subframe containing the Basic Trigger frame looks like this:

This will give an addition to the total length of the A-MPDU subframe with 40 bytes. So the total length by sending the previously A-MPDU with OFDMA on a Resource unit is:
5344 bytes at the single-user format + 40 bytes for the Basic Trigger frame addition =
a total of 5384 bytes

The amount of bytes is independent of what type of resource unit been used, but in the attached wireless capture a 106-tones resource unit is used

 

Two-level frame aggregation
A-MPDU aggregation is the mandatory aggregation type in 802.12ax (and 802.11ac). Whether the transmitter also includes A-MSDUs inside A-MPDU is threated differently between vendors.

Combining these methods is called two-level frame aggregation and is the method that gives the highest throughput.

A-MSDUs has the least amount of overhead, but since it uses a common FCS check it has to resend the full A-MSDU if there have been some transmission errors.

 

What about encrypted frame transmission
I have in this case study used an open WiFi-network (non-encrypted) so that we was able to drill into the data/payload. If we capture from an encrypted network the data field is encrypted. An example looks like this.

We can see this is:
–  an A-MPDU TXOP with 6 A-MPDU subframes
– – first is a un-encrypted Basic Trigger frame, so it is a DL OFDMA transmission
– – two MPDUs. Wireshark calls them MSDU
—  two A-MSDUs inside each MPDU
—  one MPDU
– we can not see how many A-MSDU subframes who are inside each A-MSDU
– we can not see the size of the payload without some external calculations
– two-level frame aggregation is used.

 

Next blog article
I will use the results in this blog article in my next article where we will compare the number of bytes in both A-MPDUs and compare it to the legacy Length subfield in the legacy Signal-field (legacy preamble).

 

Conclusion
I have in this article drilled into a two-level frame aggregated 802.11ax frame transmission, both single-user and, multi-user.
The pcap is attached.

I hoped it has been informative and I am, as always, glad for all feedback.

 

Other references
If you want to read more about 802.11 frame aggregation, do a search for “802.11 frame aggregation” and read articles from researchgate.net.
They are not new, but great information