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.

Test OFDMA Sunday Sep.1_gjermund raaen.pcap

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

 

MU-RTS_CTS_final

 

Last week I got one of my colleagues to install Vmware Workstation and Cisco Catalyst 9800 CL at one of my clients and after 24 hours of configuring and troubleshooting, I finally made it works with APs in FlexConnect mode.

Ciscos documentation on Catalyst 9800 CL and APs in FlexConnect mode is not perfect and I had a lot of challenges during configuration. I have therefore made this recipe for myself and anyone else

First of all. I did not manage to send vlan tagged traffic over the ethernet NIC on my laptop, so I have done a simple configuration on the laptop to make it work.
This network diagram shows all the necessary information about my lab network

With a Cisco Catalyst 9800 CL as the wireless controller all the APs should be in FlexConnect mode and do local switching at the access point. In my lab network I use vlan 1702 as the native vlan for wireless management traffic and vlan 2000 as the user traffic vlan. This vlan is locally switch at the AP and sent towards the switch in vlan 2000
The switch must be configured as a trunk interface. The network diagram shows the configuration on the switch
Remark: Ciscos documentation does not include the native vlan in the allowed vlan list. Since I followed Cisco recommendation it gave my 7 hours extra troubleshooting.

When the network is up and running like the network diagram and it is possible from the controller to ping the management vlan default gateway it time to connect an AP to the switch. The AP should join the controller in Local Mode after some reboots.

When we want to convert APs from Local Mode to FlexConnect Mode at the Catalyst 9800 CL we must use a set of policies
This recipe is for Cisco Catalyst 9800 CL version 16.10.01

My worklist:

1. Configure the WLAN
2. Configure the VLANs
3. Configure a Site Tag (in CLI)
4. Configure a AP profile (AP Join Profile)
5. Configure a Flex Profile
6. Configure a Policy Profile
7. Configure a Policy Tag
8. Tie the AP Profile and the Policy Tag to the APs
   When this is done the AP reboots and joins again in FlexConnect mode
9. Associate a client to the WLAN and test traffic

 

Further on we take it step-by-step

1. Configure WLAN
Configuration, under Tags & Profiles, choose WLANs
Add a new WLAN. It is pretty simple in two tabs, General and Security

2.Configure VLAN 
Configuration, under Layer 2, choose VLAN
Under the tab VLAN, add the vlans in your network (in my network vlan 1702 for management traffic and vlan 2000 for user traffic)

 

3. Configure a Site Tag (in CLI)

configure terminal
wireless tag site SITE.TAG
desc DEFAULT.SITE.TAG
no local-site
flex-profile FLEX.PROFILE
ap-profile AP.PROFILE

Remarks: Cisco documentation configure “no local-site” as the last item. I had to do it first. This is the command that puts the AP in FlexConnect mode.
The names in capital letters are used later

4.Configure a AP Profile
Configuration, under Tags & Profiles, choose AP Join
Add a new AP Join Profile,  write the same name as under Site Tags
Set in the profile name in Name and Description (thats all)
Remarks: I did not find anything about this in the Cisco documentation, but the Syslog said that AP Join profile was absent

5. Configure a Flex Profile 
Configuration, under Tags & Profiles, choose Flex Profile
Add a new Flex profile, use the same Flex Profile name as under Site Tags
Under General: Set in the profile name in Name and Description and the native vlan (management vlan). In my lab: vlan 1702

Under the VLAN tab: add the traffic vlan. In my lab vlan 2000

6. Configure a Policy Profile 
Configuration, under Tags & Profiles, choose Policy Profile
Add a new Policy profile, the chosen name will be used in the next step
Under the tab General: Set in the profile name in Name and Description, set the Status to Enabled and uncheck Central Switching under WLAN Switching Policy. The last one is for locally switching of user traffic at the AP

Under the tab Access Policies, change VLAN/VLAN Group to the traffic VLAN (in my lab vlan 2000)

7. Configure a Policy Tag. Could be done i both CLI and GUI

CLI
wireless tag policy POLICY.TAG
wlan WiFi6 policy POLICY.PROFILE

GUI
Configuration, under Tags & Profiles/ Tags
Add a Policy tag and map the WLAN Profile and the Policy Profile

 

8. Configure AP
Now it’s time to tie those profiles to the AP. The AP is in Local mode when it first joins the controller. When we tie the Profiles to the AP it will reboot and join again in FlexConnect mode.
Configuration, under Wireless, choose Access Points
This first picture shows one AP already in FlexConnect and another in Local Mode (disabled)

Choose the Local Mode AP. Set it to enabled status and choose the configured Policy Tag and Site Tag. It will now, after updating, reboot and rejoin in FlexConnect mode
I had to enable the AP it after rejoining in FlexConnect mode

The status after rejoining. The AP that was in FlexConnect is disabled in this example

9. Connect a client
Now is the moment of truth.
Enable WiFi on your client and connect (associate) it to the WLAN. Check your connected ip address and test traffic to the internet or other services

Closing remarks
When you configure you have to use the “Update and Apply to Device”. This button is in the lower right corner in each window. Always wait for some time before the changes is applied to the devices
The Syslog under Troubleshooting is a very good help during this process
And of course, constructive feedbacks are welcome

 

Other references
It is other blogs that do research into the same area. Two of them are

• cleartosend.net
• wifininjas.net

 

 

 

I mentioned in my latest blogarticle that I have read the book “Next Generation Wireless LANs” second edition from Eldad Perahia and Robert Stacy. This is fantastic book that goes way beyonds study material for the CWAP-certification .

To memorize this bit-by-bit stuff I have made myself a ODFM, HT and VHT PHY cheat sheet

Remark: This is a 50% product and in A3 format.

Constructive feedback are welcome

Downloadable file (pdf): OFDM, HT and VHT PHY Reference cheat sheets

 

There are a lot of blogs, podcast and videos at the internet explaining 802.11ax at a high level. And some have done testing with 802.11ax compatible devices. But I have not found anyone that explains 802.11ax at a deep level. So why not me

The last year, since I bought the Perahia and Staceys book “Next Generation Wireless LANs”, I have been interested in the PHY-level of 802.11. And to go deep at 802.11ax I had to buy the 802.11ax, Draft 4.0.
There are so many new topics in the 802.11ax technologies so I had to make usecases for some of the topics and I have choosen the MU OFDMA process. This first blogarticle, in a series of articles, are about the frame where the AP sends data down to stations that needs data, the DL MU OFDMA frame. This frame is sent in i HE MU PPDU format, one of the four different frame formats in the 802.11ax standard.

Later on I will cover other aspect of the MU OFMDA process, like the MU-RTS/CTS process, the uplink OFDMA (UL MU OFDMA) process and the Acknowledgement process

Nothing of this is testet in real world, it’s picked out of the 802.11ax draft

DL MU OFDMA
DL MU OFDMA is the process where the AP sends data down to several stations that need/want data in a parallell process. In this slides I have used a example where four stations receives data in parallell. The AP have, before it starts to send data, decided how it should allocate its RUs.

A overview of this frame (PPDU) is like this

The presentation (slides) could be downloaded at this link (pdf)

DL OFDMA, bit-by-bit

If someone have constructive feedback I would be grateful

Useful links

• Cleartosend 802.11ax podcast-series,  link
• David Colemans presentation at WLPC_US 2019, link
• Wifininjas, link
• IEEE 802.11ax draft 4.0 ($400), link

 

Next Pcap-quiz, number 2, is “Fun with Beacons”

In the attached file there are

• pcap with three different beacons
• a questionare
• a questionare with answers

Pcap#2 Fun with beacons

It is 1000 different parameters to check in a beacon, but we are not going so very deep. Just some basic parameters that are useful to know about

Please, try it