I am launching the WiFi AirTime Calculator.
WiFi Community, feel free to test it and use it for self-study or during the education of your colleagues, clients or other
You find more information here, in the top menu or in the picture on the right-hand side
During WLPC_EU we had an 802.11ax after-party where we tried to make OFDMA functioning with different vendors AP and we got someone to do OFDMA. But we were kicked out of the meeting room before we got good results.
I have a network at home that does UL ODFMA, but it does not do DL OFDMA.
I have a packet capture of the UL OFDMA transmission and will explain it in this blog.
Theory
A figure from the IEEE 802.11ax draft 4.0 tells this about UL OFDMA
If we look at the last three frames
— the AP sends a Trigger frame to the clients
— the clients (STAs) sends it data uplink to the AP in parallel
— the AP acknowledges the frames
Test network
My test network looks like this (very simple picture)
What I do, briefly explained
– associate two clients, a Samsung S10 and a Jetson Nano, to the Cisco 9115 AP controlled by the Cisco Catalyst 9800CL controller running version 16.12.0. The AP is in FlexConnect mode
— the clients run Speedtest against a WlanPi. Speedtest is started simultaneously on both clients
— a Jetson Nano in sniffer mode does packet capturing
— a Windows client running Wireshark receives the captures frames via sshdump
— a client running Ekahau ESS with RTFM (Real Time Frequency Monitor) with Sidekick connected
A prefer doing Speedtest against the WlanPi because it does a finite period of ping/jitter testing, download test, and upload test. In this way, it’s easier to see how the spectrum changes, instead of doing any kind of iPerf-test.
Spectrum picture
What is this
— a 20 MHz wide spectrum picture during the Speedtest download test
— one client using a 106-tone RU (Resource unit) in the lower half
— one client using a 52-tone RU in the upper part
— a part of the spectrum with lower utilization
Packet analysis
It is still no available method that is able to capture frames that have data in subdivided RUs, so we capture only two packets during a UL OFDMA transmission. The standard describes the use of protection with MU-RTS and CTS, but my network doesn’t use protection. The MU-RTS and CTS are explained in a previous blogpost .
The captured frames are the Basic Trigger frame and the Multi-STA BlockACK
Basic Trigger frame
This is a new control frame the 802.11ax standard uses to trigger an uplink transmission from its associated clients. Wireshark is able to decode it, while Omnipeek doesn’ do it. I have explained the frame format for this frame in the MU-RTS/CTS blogpost, but here is a short recap. The basic Trigger frame consists of:
— MAC header
— Common Info Field
— One or more User Info field
Basis Trigger frame, the MAC header
The most important notice is that the Basic Trigger frame is a broadcast frame (RA= ff:ff….), sent from the TA with the BSSID address. The 9115 notation is because I have entered the AP MAC address into the ethers file in Wireshark.
Common Info field
The Common Info field is information to the clients that are addressed in the User Info field on how they shall build the frame for the uplink data. The content in the Common Info field is outside the scope of this article.
Basic Trigger frame, User Info field
This Basic Trigger frame has three User Info fields, meaning there are three clients (STAs) that are been allocated RUs for their uplink data.
If we open the two first User Info fields, it contains this.
In basic text, it says this for the first User Info field: Client (STA) with association-id 0x001 has been allocated resource unit number 53, and it should use coding type LDPC with MCS8 and 2 spatial streams.
Resource unit number 53 is the 106-tone RU in the lower band of this 20MHz channel.
The next User Info field says that the client (STA) with association-id 0x002 has been allocated resource unit number 39, and it should use coding type LDPC with MCS0 and 2 spatial streams.
Resource unit number 39 is the 52-tone RU right after the middle off this 20MHz channel.
Why MCS0. The controller has three clients in its association table so it allocates RUs to all clients, even if some of them have nothing to send. This is the first code version to Cisco that does UL OFDMA and its scheduling process will be better in later versions.
For client no 3, not shown in a picture
Client (STA) with association-id 0x003 has been allocated resource unit number 40. Resource unit number 40 is the last 52-tone RU in this 20MHz channel.
UL OFDMA data frame
The data frames are not captured. It is amazing stuff that happens during this transmission of the data frames but it will be a topic in another blog post.
In short: Clients send it data in their assigned RUs uplink to the AP.
Multi-STA BlockAck
When the AP has received and decoded the uplink data frames it will send an acknowledgment back to the clients. The AP uses a new Block Acknowledgment frame called Multi-Station BlockAcknowledgement, Multi-STA BlockAck. This frame is sent as a broadcast frame.
Multi-STA BlockAck MAC-header
The figure shows the first part of the Multi-STA BlockAck. The Receiver address is the broadcast address and the Transmitter address is the APs MAC address or BSSID.
This frame is sent straight after the data frames because the Block Ack policy requires an Immediate Acknowledgment and the type of frame is Multi-STA BlockAck.
Per AID Info field
There is three different Per AID TID Info field. This means that the Multi-STA BlockAck sends an acknowledgment to three clients. The first one
This is the BlockAck to association-id 0x001and has a starting sequence number of 3562. Each and every A-MSDU or MSDU that is aggregated into the A-MPDU have their sequence number in their MAC header. The number 3562 is the first sequence number that the AP has received in the data frame transmission.
When the AP receives those aggregated frames it makes what is called a scoreboard. This scoreboard is a view of which frames the AP has successfully received.
In the BlockAck the AP show which sequence number it expects to receive in the next transmission. In the figure, the sequence number of the next frame it expects to receive is 3582. This means that the AP has successfully received sequence number 3562 to 3581 in this transmission.
It could happen that the client has sent more MSDU/A-MSDUs, but the AP has not successfully received all. The AP will only acknowledgment those that are successfully received and the transmitter has to resend some of them
Example: Let us assume that the client has sent sequence number 3562 to 3590. Since the AP has the next expected sequence number to be 3582, the client has to retransmit sequence number 3582 to 3590.
Remark
The 802.11 standards until 802.11ax use mainly MAC addresses as unique identifiers for the different STAs, including the AP.
The 802.11ax amendment uses the association-id to the client as the unique identifier in many of the frames. We see this both in the Basic Trigger frame and the Multi-STA BlockAck.
Summarize
The Basic Trigger frame tells three different clients to do UL OFDMA, the first one with the lower 106-tone RU (53), the next two in the two higher 52-tone RUs (39 and 40).
We are not able to capture the data frames.
The Multi-STA BlockAck acknowledgments successfully received sequence numbers in the aggregated data frame from the three clients.
The client that is allocated the first 52-tone RU is not present
The spectrum picture confirms what the packet capture tells.
Conclusion
UL ODFMA is working in my network, and it is possible to capture and interpret the transmission. The data frames, that are sent in subdivided RUs, is not possible to capture. But we can interpret and understand the UL OFDMA transmission by looking at the Basic Trigger frame and the Multi-STA BlockAck
Wiresharkfilter
My previous article was on how to do wireless capturing on a Jetson Nano, with a big external screen connected to either the HDMI or the Display outputs of the Jetson Nano. And with connected external mouse and keyboard
But what if you want to use favorite packet analyzer on your preferred client where you have all your configured filters, profiles, aliases and so on.
I have tested different methods to do remote connections to the Jetson Nano, either by VNC or SSH. With VNC it connects but I get no picture. With SSH it connects and I am able to start capturing, but I struggle to start Wireshark.
I have bought a small 5″ screen to my Jetson Nano, but it is not very convenient to do packet analyzes on that screen. And I have to use both a keyboard and a mouse. But it could be used during packet captures.
Now I have found a method that works well for me. This includes the Jetson Nano with the small screen, an external mouse at the Jetson Nano and a connection to my preferred client. This method is very simple and has many improvement opportunities, but it is a good start
Basic setup
Use a cross-connect ethernet cable between your client and the Jetson Nano ethernet NICs and use fixed ip addresses on both devices. I prefer to use a /30 network
Jetson Nano
Since I don’t found any suitable box for the screen on the internet, I went to a local grocery store and bought a simple plastic box. Actually a lunchbox.
Some small work with a knife, a drill and some screws and this is the result.
Connect an external mouse to the Jetson Nano. To get rid of the keyboard some changes must be done in the OS of the Jetson Nano. The first one is to skip logging on when power on and the other is to make sure the screen saver doesn’t turn on. You must use a keyboard to change these settings.
– Under System Setting/User accounts: Set the admin user account to automatic login
– System Settings/Brightness and Lock: Set the screen to never turn off
From now on the screen appear after power on and is always on and no more use of the keyboard.
Now it’s time to do some packet capturing
This is my approach
— set the wireless NIC at the Jetson in monitor mode and start capturing
— start Wireshark to collect the captured frames and save them in pcap-file
— transfer the pcap to your preferred client
Simple and not very elegant, but it is a method.
A more elegant solution is to have some sort of script on the client that does “all-in-one”, like we do with the WlanPiShark script. But I’m not able to make that.
Francois Verges has tested different capturing setups at the JetysonNano. I summarize it here, mostly at a “note-to-self”. This is not tested by me.
Capturing at 40 MHz
— sudo airmon-ng start wlan 0 100
— sudo ifconfig wlan0mon up
— sudo iw dev wlan0mon set freq 5500 HT+
Capturing at 80 MHz
— sudo airmon-ng start wlan 0 100
— sudo ifconfig wlan0mon up
— sudo iw dev wlan0mon set freq 5500 80MHz
Reference
How to build the Jetson Nano at hypergeek.net
The NVIDIA Jetson Nano Developer Kit with Intel AX200NGW WiFi6 chips set is one method to make a WIFi6 client. I have some of these.
Earlier today Francois Verges announced at Twitter a method for capturing 802.11ax frames with this kit. And I wasn’t difficult to trigger.
Method:
— Install Wireshark at the Jetson Nano. This link worked well for me, link
— Install aircrack: sudo apt-get install aircrack-ng
— Start capturing: sudo airmon-ng start wlan0 36 (the two last digits is the channel)
— Start Wireshark and select the wlan0mon interface.
— Stop capturing (stop monitor mode): sudo airmon-ng stop wlan0mon
Big thanks to Francois Verges for this method
Test scenario
– Client 1: Jetson Nano with Intel AX200NGW chipset
– Client 2: Samsung S10
– Accesspoint: Cisco Catalyst 9115 in FlexConnect mode
– WLC Cisco Catalyst 9800CL, version 16.12.1, at Workstation
– Sniffer: Jetson Nano with Intel AX200NGW chipset and installed Wireshark version 3.1.1
– WlanPi as the SpeedTest server at the same vlan as the client traffic
Attached to this blog is a pcap with 1000 frames
Downlink direction
As I earlier have blogged about, my network does not do DL OFDMA. The same pattern repeats now. Downlink data are sent from the AP to one client at the time, no parallel downlink transmission.
But the enhancement in this method of capturing versus using a Cisco Catalyst 9115 in sniffer mode is the quality of the Radiotap header and 802.11 Radio Information for the captured frames.
If we look closer at one of the QoS data frames sent from the Ap to the Samsung, opens Radiotap Header and find HE information
As we can see there are six different HE Data field and each of them explains 802.11ax characteristics.
And even closer into HE Data 3 field
Field to look at is among data rate of MCS8 and LDPC encoding.
So we are able to capture and interpret the single user frame in 802.11ax (HE SU PPDU)
For those of us that like to dig into the PHY layer, this tool gives us much better visibility.
Uplink direction
Nothing is changed in capturing with the Jetson Nano versus using the Cisco Catalyst 9115 in sniffer mode. We are still not able to capture the response to the basic Trigger frame, the UL OFDMA QoS data frame. We see the Basic trigger frame and the MultiSTA BlockAck, not the 802.11ax trigger-based frame (HE TB PPDU). But the network do UL OFDMA.
But it is a very interesting thing to consider. My little network had three associated 802.11ax clients, but one of them was turned in to Sniffer mode. So I have two clients to do SpeedTesting with, but the network does UL OFDMA resource allocation between all three clients. Let us see at the Basic Trigger frame and the MultiSTA Block Ack
As we can see. The AP divides the channel in one 106-tones RU and two 52-tones RUs to AID12 (association-id) number 1, 2 and 3, but it is only AID11 number 1 and 3 that has sent data uplink to the AP. AID number 2 is the client that was associated, but are now a sniffer.
And the spectrum picture from the Sidekick shows this during upload test:
As a conclusion to this: With OFDMA there are a lot of situations where we will have unusual results where the network decide to do resource allocation that from the human minds looks unreasonable.
Conclusion
Using the Jetson Nano with Intel AX200NGW chipset gives better visibility to the Radiotap header and 802.11 Radio Information versus the Cisco Catalyst 9115 in Sniffer mode for the single user frame format in 802.11ax (HE SU PPDU)
But we are still not able to capture UL OFDMA frames (HE TB PPDUs). My network doesn’t do DL OFDMA, so I don’t know whether this method is able to capture multiuser DL OFDMA frames (HE MU PPDUs) or not
Attachment, pcap with 1000 frames
OFDMA test with two clients, but with three associated. 190925-2030, 1000 frames
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.
This is a blog article on 802.11ax uplink OFDMA (UL OFDMA) and the control frames that are involved.
According to the IEEE802.11ax draft 4 the UL OFDMA process look like this
The MU-RTS and CTS are optionally and in some Cisco documentation, it says that the MU-RTS/CTS process is not needed. The MU-RTS/CTS process is described in another blog article. And as I say in that article, the MU-RTS/CTS process is not implemented by any vendors yet. And I also say it is better to use legacy RTS/CTS in a mixed environment, maybe.
My test lab is a Cisco Catalyst 9800CL (v16.12.1) wireless controller at Vmware Workstation, a Cisco Catalyst 9115 in FlexConnect mode, a Cisco 9115 in SnifferMode and two clients, a Samsung S10 and a Nano developer Kit with Intel AX200 NIC.
The attached pcap consists of three sessions (TXOP) of UL OFDMA, each consisting of three frames; Basic Trigger Frame, the Dataframe that is not captured and the Multi-STA ACK (0x0016)
The uplink data that are sent in the HE TB PPDU format is not captured. I’m not sure whether it is a problem with Wireshark or the Cisco 9115 in Sniffer mode, but the information in the Basic Trigger frame and the Multi-STA ACK tells us enough information.
The Basic Trigger frame
Let’s start with the Basic Trigger frame. The Trigger frames are a new type of frames in the 802.11ax standard. The main purpose of the Trigger frames is to allocate resources and solicits one or more uplink HE TB PPDUs transmissions. The Basic Trigger frame is used to solicits the uplink data from one or more non-AP STAs
The frame format for a Trigger frame is like this
The MAC header
The most important thing:
– Control frame, type 1 and subtype 2
– Receiver address is the broadcast address
– Transmitter address is the AP that sends this frame
– Duration; distributing the NAV timer for this TXOP to all STAs in the BSS and on the channel
The Common Info field
The field in the Common Info field is mostly information the non-AP STAs needs to build their frame for the uplink data. But these are something to look at:
– Basic Trigger frame, type 0
– UL Length: This value describes the Length of the uplink frame and shall be put into the Legacy Signal field and Lengths bit
– AP TX Power: The non-AP STA uses this value to calculate its TX-power
The User Info field
The Basic Trigger frame consists of one User Info field pr STAs that will send uplink data. In my lab, the two non-AP STAs (Samsung S10 and Nano Kit) has assigned STA-id (association id) 2 and 3
The most important subfield
– AID12 is the STA-id (association id) for the non-AP STA
– RU Allocation: describe which RU the STA is assigned to
– MCS; the MCS each non-AP STA should use. In this example, those two non-AP STAs will use different MCS. It is the AP that decide this value
– Target RSSI; This is the RSSI the AP want to receive each non-AP STAs uplink transmission at. Each non-AP STA calculate this value based on AP TX power from Common Info field and the RSSI it receives this Trigger frame at
RU Allocation
The RU Allocation subfield along with the UL BW subfield in the Common Info field identifies the size and the location of the RU. Table 9-31g in the IEEE802.11ax draft tells about all the possibilities
Four examples
– 9 times 26 tone RU at 20MHz, values 0-8
– 4 times 52 tone RU at 20MHz, values 37-40
– 2 times 106 tone RU at 20MHz, values 53-54
– 1 time 242 tone RU at 20MHz, value 61
Multi-STA BlockAck frame
The Multi-STA BlockAck frame is supported in uplink multi-user (UL MU). The BlockAck processes are diverse and I will only show the Multi-STA BlockAck frame
The MAC header is similar to other control frames
Since the Multi-STA BlockAck is sent til two or more non-AP STAs the receiver address (RA) is the broadcast address.
Next is the BA Control field
As we can see it is a Multi-STA BlockAck frame and it ACKs to AID (association ID) 2 and 3. The same AID as the AIDs in the basic Trigger frame
A closer look into one of the AIDs shows
What this basically says is that it has received a lot of A-MSDUs (or A-MPDUs) where the sequence number on the first A-MSDU (A-MPDU) was 3893 and the last one was 3891. The parameter in Missing Frame is the next frame it expects to receive in the next TXOP
If we use the Starting Sequence Number as a column in Wireshark we will see an increasing number for both AIDs
That’s all
If we want to see all the important information on one screen in Wireshark it could look like this
Attachment
Pcap (zip): UL OFDMA, Basic Trigger Frame and Multi-STA BlockAck.pcapng
The second powerpoint series in my deep dive into the HE/802.11ax protocol is about the Multi User Request to Send (MU-RTS) and Clear to Send (CTS) process.
MU-RTS is one of the new Trigger Frames in the HE process and will be used instead of the legacy RTS.
I’ve have rewritten the slides some times while I have discovered new items during my interpreting of the IEEE802.11ax draft, so the coherence of the slides could have been better.
If I have interpreted it wrong, please tell it to me
My lab is consisting of Cisco equipment and Cisco have not implemented this functionality yet, so nothing is tested in real life.
I hope it useful
