I have tested the new 802.11ax standard lately and I have suspected that the downlink data frames don’t do Multi User OFDMA (DL OFDMA). I have also sent a question regarding this to some WiFi experts, but no one has answered. So, let us use Wireshark and Sidekick to dive into it.
This test is done with public available devices and software. I have not dived into release notes for each device. This is an article where I use Wireshark and Sidekick to examine how things work.
Good references are my previous articles about the OFDMA-process, and my last one was about the DL OFDMA in the same network
My test lab is consisting of
– Cisco Catalyst 9800CL (v16.12.1) wireless controller at Vmware Workstation
– a Cisco Catalyst 9115 AP in FlexConnect mode
– a Cisco Catalyst 9115 AP in SnifferMode
– a Samsung Galaxy S10
– a Nano developer Kit with Intel AX200 NIC with the latest software
– a WlanPi as the SpeedTest server connected to the FlexConnect vlan
– a Windows client with Wireshark v3.0.3 on the native management vlan
– all devices are connected to a Cisco 3560CG-switch.
To make sure that the Sniffer AP could capture the traffic I hide the FlexConnect AP behind a computer and into a box. Just to force mcs rates a little down.
General view of the captured data in Wireshark
– A SpeedTest test with two clients generates 60-80.000 frames
– Very few of the Nano data frames are captured. Maybe my setup should have been even better
– A lot, but not all, Samsung data frames are captured
– During those tests, there are some datastreams downlink and some datastreams uplink.
– All downlink data frames are preceded by RTS and CTS
– All uplink data frames are preceded by a Basic Trigger frame
– The radio tap information inside the AiroPeek/OmniPeek encapsulated IEEE802.11 or the 802.11 Radio Information is not reliable. The data for mcs, coding, datarates and so on are either missing or not valid.
Start Wireshark, associate the clients and then start the SpeedTest against the WlanPi simultaneously on both clients.
Association-id
First step is to associate the two clients to the SSID just to find out which association ID/AID/STA-ID those gets. It is found in the Association Response frames
Wireshark-filter : wlan.fc.type_subtype==1
In the Capabilities Information Element, we will find the Association ID
The Samsung S10 got association ID 0x0003
The Nano got association ID 0x0001
Then I started SpeedTest against the WlanPi from the two clients. First, they do some ping and jitter test, then a download test and at last an upload test. During this test, I had the RTFM-monitor in Ekahau ESS Pro running with Sidekick connected, and I took some snapshots
Download
I have in a previous article done a deep-dive into DL OFMA based on the IEEE802.11ax draft v4. But to sum up:
Theory
-if the AP does DL OFDMA it announces the subdivisions of the band in the PHY header of the data frame. In the HE-SIG-B field there are two subfields:
— HE-SIG-B Common subfield where the RU allocation is announced. In my lab network, it should have announced two times 106 RUs
–HE-SIG-B User content subfield where the AP announces which STA-id that have their data in which RU-allocation. In my lab network, it should announce STA-id 3 to one of the 106 tones RU and STA-id 1 to the another 106 tones RU.
Practice
Here is a small capture during downloading and with a display filter that filters on RTS, CTS, Data frames and Compressed BlockAck
We can differentiate between the clients on the Starting Sequence Number (SSN) from the Compressed BlockAck. Samsung is around 2000 and Nano at 600
Nano (SSN around 600)
-We have captured RTS, CTS and Compressed BlockAck
– The duration field (NAV) in RTS and CTS show approx 5400 µs each time it is a big jump in the BlockAck Starting Sequence Number and a small number, approx 350 µs, when it has been retransmissions of some frames.
– The Time, displayed, in the BlockAck from the Nano is little bit smaller than the NAVs from the previous CTS
Samsung (SSN around 2000)
– We have captured RTS, CTS, some data frames and Compressed BlockAck
– The Duration in RTS and CTS has the same pattern as for the Nano
– If we compare Starting Sequence Number and Missing frames columns against the next BlockAck we can see that there is missing a lot of data frames in the capture
example
-frame 21975 (BlockAck) have acknowledged data frame (Sequence Number, SN) 1912 to data frame SN 1958 from the previous data frame transmissions. Frame SN 1912 as the Starting Sequence Number and frame SN 1959 is the first frame in the next transmission.
– in the next TXOP (frame SN 21981-21986) we have captured data frames SN 1990, SN 1993 and SN 2330.
– but the BlockAck in frame SN 21986 have acknowledged data frame SN 1959 to SN 2004, which means that it has been transmitted a lot of frames that we don’t have captured
To sum up the download test in Wireshark we see that each client gets it data one after another, and not in parallel.
The spectrum picture during the download test looks like this
From my point of view, this is not ODFMA with two times 106 tones RU. Whether it is a HE Multi User frame with one allocated station that has all the 242 subcarriers or a HE Single user frame I’m not able to interpret.
Upload test
If we go down in Wireshark to the frames where the upload test is done and filter on Trigger Frames and Multi-STA BlockAck we have this example from Wireshark.
We see consecutive Basis Trigger Frame and Multi-STA BlockAcks
Basic Trigger Frame from the AP
– Ul Length is the parameter that the uplink clients shall set in their Length-bits in the Legacy Signal field
– RU Allocation tells how the channel allocation is during uplink data. Here is it two times 106-tones RU, 53 and 54
-AID12 tells that STA-id 1 (Nano) shall use the lower 106-tone RU and STA-id 3 (Samsung) shall use the upper 106-tone RU
Multi-STA BlockAck
– A Multi-STA BlockAck from the AP sends BlockAck to several clients in parallel.
– in the first frame in the figure, the AP has acknowledged date frame with Sequence Number 1879 (Starting Sequence Number) 1879 from the Nano and the data frame with SN 664 from the Samsung A-id 1 (Nano).
– and the Starting Sequence Number is growing at a steady pace.
This is UL ODFMA according to the IEEE802.11ax draft v4. And my network is not able to capture those multiuser data frames.
The Spectrum picture for the upload test looks like this
The Nano uses subcarrier [-122:-17] and Samsung uses subcarrier [17:122] for the uplink data frames, as we can see clearly. The center subcarriers are not been used during two times 106-tones RUs. But it is a lot of other traffic between the two clients and the AP at the same time that uses the full channel width.
Simultaneously DL OFDM and UL OFDMA
Based on what now have learned and if we do a closer look at the full capture we can see that it is both downlink data frames not using DL OFDMA (using OFDM) and uplink data frames using UL OFDMA throughout the full capture. The difference is the amount of data in uplink versus downlink. If we see at the first Spectrum picture, during SpeedTest downloading, it is possible to see the UL OFDMA spectrum pattern inside the spectrum for DL OFDM. I have marked it with black boxes
Conclusion
Does my network do both DL and UL ODFMA? Answer: No
Why it is doing UL OFDMA, but not DL OFDMA? I’ll answer it later if not someone smacks me on my fingers and tells me that I’m wrong
Remarks
This is how I, with my knowledge, is able to interpret a Wireshark capture, supported by Sidekick spectrum analysis.
Maybe I am wrong on some of the things. I attach the full Wireshark capture so others can do the same analysis.
If I’m wrong, please send me a note.
Gjermund Raaen 