Chasing Trigger Frames

Lately, I have been on the hunt for as many trigger frames as possible to accomplish two main goals:

• Learn more about the conditions that produce different trigger frames.
• Prove when OFDMA vs MU-MIMO operation is happening (or happened).

Maybe it isn’t 100% correct to pit these two against each other, but many Wifi6 AP’s are switching between OFDMA and MU-MIMO when confronted with certain RF and traffic conditions from 11ax capable stations.

In my testing for this write-up, I stuck with one particular AP where I could monitor the AP for its participation in OFDMA or MU-MIMO which was a big help in looking for patterns in the pcaps. I did run into trouble with uplinks (STA-to-AP) because the AP only shows what it is doing for downlinks (AP-to-STA). So it was a bit more difficult to tell what happened in upload captures, but I found some interesting IO Graphs and what follows are snapshots of my journey down this particular rabbit hole…enjoy!

For reference, here are two wireshark filters for trigger frame hunters:

wlan.fc==0x2400

wlan.trigger.he.trigger_type <= 15

One question is, between the above two filters, if wlan.fc==0x2400 is all trigger frames, why is it showing 166 less frames than wlan.trigger.he.trigger_type<=15 which is also all trigger frames?

If I setup a wireshark filter for those 166 frames, there is no clear pattern that explains the difference…so please feel free to let me know if you can explain!

wlan.trigger.he.trigger_type<=15 and !wlan.fc==0x2400

To clearly define the exact trigger frames I am chasing, here are the possible values for the wlan.trigger.he.trigger_type filter:

• 0 – Basic
• 1 – Beamforming Report Poll (BRP)
• 2 – Multi-User Block ACK Request (MU-BAR)
• 3 – Multi-User Request To Send (MU-RTS)
• 4 – Buffer Status Report Poll (BSRP)
• 5 – Group Cast Retries (GCR MU-BAR)
• 6 – Bandwidth Query Report Poll (BQRP)
• 7 – NDP Feedback Report Poll (NFRP)
• 8-15 – Reserved

However, as is the case with wifi, this isn’t the whole story…there is another important frame named the HE TB PPDU (High Efficiency Trigger Based PPDU) which is the 802.11ax frame sent by stations when they have uplink data to send. It is labeled in wireshark as HE_TRIG and found with the filter:

radiotap.he.data_1.ppdu_format==3

How I Tested

The test setup is a ASUS AXE11000 Wifi6e AP with a LANforge traffic generator with 4 11ax stations, a Jetson Nano, and a Samsung S10. Although the ASUS is a 6E AP, I am only chasing trigger frames on 5GHz during this round of testing and will plan to go trigger frame hunting on 6GHz next.

Using the ASUS AP built in monitoring commands, I can observe when OFDMA or MU-MIMO is happening from the AP’s perspective…so my reasoning is: if the AP thinks it is doing fancy things…let’s go capture it!

Setting up the AP status monitoring:

• Enable SSH service from the AP’s Administration menu
• SSH in as the admin user
• while true; do wl -i eth7 bs_data; sleep 1; done

Setting up the monitor interface:

• Setup at least one 11ax interface as described in Gjermund’s blog.
• Verify that you have the correct AID for the station you want to monitor for OFDMA.
  This is an important step because it allows the monitor interface to decode the HE frames for that particular station and the AID can change if the station reassociates.

Useful tshark command to grab the AID when the station associates or reassociates…basically filter for wlan subtype 1, the Association Response, and display the station’s MAC and AID in hexadecimal:

tshark -i <monitor interface> -Y "wlan.fc.type_subtype==0x0001" -T fields -e wlan.addr -e wlan.fixed.aid

Traffic Tests to stimulate OFDMA or MU-MIMO

In general, smaller payload sizes will stimulate OFDMA and larger payload sizes will stimulate MU-MIMO. However, it seems that different AP’s will toggle between OFDMA and MU-MIMO at different payload sizes. For the Asus AP, the sizes that worked for me were 300B for OFDMA and 1472B for MU-MIMO. Using these payload sizes, I performed the following tests:

• UDP Download
• UDP Upload

Iperf3 Server is running on all station devices as:

iperf3 -s -i <interface>

Each iperf3 client connection was run from the LANforge device on the wired interface connected to the AP, but this could also have been any iperf3 capable device with a wired connection to the AP. I used LANforge mainly to orchestrate the different tests for all iperf clients as well as run the background traffic from the additional 11ax stations.

The IO Graphs are generated from the Wireshark Statistics menu. Some tests only needed a single graph to see what was happening, but for other tests it was better to generate multiple graphs to observe what was happening.

• Jetson Nano – DL OFDMA – UDP – Link to pcap: nano-ofdma-udp-down.pcapng
  iperf3 -c 192.168.50.142 -t 10 –length 300 -u –tos 0 -b 200000K –bind_dev eth1 -i 1
  This graph clearly shows HE_MU DL OFDMA.
  
  
• Jetson Nano – UL OFDMA – UDP – Link to pcap: nano-ofdma-udp-up.pcapng
  iperf3 -c 192.168.50.142 -t 10 –length 300 -u -R –tos 0 -b 200000K –bind_dev eth1 -i 1
  Graph of HE_TRIG and UL OFDMA.
  
  What I think this next graph shows is that the Basic Trigger frames broadcast from the AP also indicate UL OFDMA is happening.
  
  
• Jetson Nano – MU-MIMO – UDP
  I could not get the Nano to participate in MU-MIMO. I tried to limit the number of spatial streams in use, but the iw command would not allow the set antenna option.
  
• Samsung S10 – DL OFDMA- UDP – Link to pcap: s10-ofdma-udp-down.pcapng
  iperf3 -c 192.168.50.143 -t 10 –length 300 -u –tos 0 -b 100000K –bind_dev eth1 -i 1
  Another example of HE_MU DL OFDMA.
  
  
• Samsung S10 – UL OFDMA – UDP – Link to pcap: s10-ofdma-udp-up.pcapng
  iperf3 -c 192.168.50.143 -t 10 –length 300 -u -R –tos 0 -b 100000K –bind_dev eth1 -i 1
  It appears that the HE_TRIG here indicates an uplink OFDMA.
  
  Graph of Basic Trigger frames and Multi-STA Block ACKs broadcast from the AP indicating UL OFDMA.
  
  
• Samsung S10 – DL MU-MIMO – UDP – Link to pcap: s10-mumimo-udp-down.pcapng
  iperf3 -c 192.168.50.143 -t 10 –length 1472 -u –tos 0 -b 100000K –bind_dev eth1 -i 1
  Here, the S10 iperf starts at 11s into the capture, where HE_SU increases which is one indication that the traffic is no longer OFDMA, but how to prove that it is MU-MIMO?
  
  There are also a large number of Beamforming Report Poll type trigger frames.
  
  If I filter the BRP frames by Upload Length, then it appears to show when the BRP frames include multiple users and this seems to agree with what the AP shows as participation in downlink MU-MIMO.
  

Observations:

OFDMA can be identified, but has to be further classified as Uplink or Downlink.

• The PPDU formats tell the story pretty well for UDP traffic.
• HE_MU indicates DL-OFDMA
• HE_TRIG indicates UL-OFDMA
• Originally, I was going to test UDP and TCP, but this post was getting long…so I decided to just try and analyze the UDP tests and save TCP testing for another time. I did run one combined UDP and TCP test that was very interesting. TCP traffic is different because the protocol has TCP ACKs that have to be uplinked when the station is downlinking and downlinked when the station is uplinking so there is a mixture of HE_MU and HE_TRIG as seen in this IO Graph.
  10-20 secs is a UDP download
  25-35 secs is a UDP upload
  45-55 secs is a TCP download
  60-70 secs is a TCP upload
  
  Link to pcap: he-udp-down-up_tcp-down-up.pcapng
• Don’t be discouraged if the payload size is not working at first…keep trying because the AP is in charge and its behavior varies.
• MU-MIMO is more difficult to identify in wireshark, I’ll need to spend some time doing further testing to explore upload MU-MIMO.
• Despite using similar traffic settings, I could not get the Jetson Nano to participate in MU-MIMO traffic.

In conclusion, here is my estimate of difficulty level with capturing trigger frames:

Link to pcap for the following: nano-ofdma-udp-down.pcapng

Basic Trigger Frame – difficulty level EASY – downloading or uploading tests.

BRP – difficulty level EASY – downloading or uploading tests.

MU-BAR – difficulty level MEDIUM – found one during the Jetson Nano OFDMA download test from AP to Nano.

MU-RTS – difficulty level EASY – found many during the Jetson Nano OFDMA download test.

BSRP – difficulty level MEDIUM – found a few during the Jetson Nano OFDMA download test.

GCR MU-BAR – difficulty level UNKNOWN

BQRP – difficulty level HARD – found one, but could not repeat the capture.

NFRP – difficulty level UNKNOWN

Thanks for reading, please let me know if you have any comments or suggestions.

And a big thank you to all the Wifi Pros out there who blog/vlog/present and tweet!
https://twitter.com/KeithRParsons/status/575341966319349760
https://twitter.com/mistermultipath/status/1361489845114273795
http://wifinigel.blogspot.com/2014/02/wlan-packet-capture-frame-colorization.html
https://gjermundraaen.com/2019/11/24/wireless-capturing-of-ul-ofdma/
http://wifi.hypergeek.net/you-too-can-have-a-sub-200-11ax-client/
https://www.semfionetworks.com/blog/80211ax-remote-packet-captures-using-the-jetson-nano
https://www.cleartosend.net/wp-content/uploads/2019/10/Wi-Fi6_in_the_real_world_wlpc_prague_2019.pdf
https://www.youtube.com/watch?v=qRs_5K4EgnM
https://www.youtube.com/watch?v=8GQaWCjS-vk&t=1792s
https://howiwifi.com/2020/07/03/spectrum-analysis-phys-and-interferers/
https://dot11.exposed/2020/06/22/a-msdu-vs-a-mpdu-real-world-examples-in-wireshark/
https://wifiwiki.wordpress.com/2019/11/19/understanding-a-mpdu-block-ack-through-wireless-captures/
https://twitter.com/FirasShaari/status/1253012991928401921