Validate 802.11ax wireless throughput and validation testing

Introduction

This document describes the way of testing the wireless throughput of an access point focusing on 802.11ax and what throughput to expect.

Prerequisites

Requirements

This document assumes an already functioning setup with 802.11ax / Wi-Fi 6 access points (APs) giving client connectivity already

Components Used

The information in this document is focused on 802.11ax/Wi-Fi 6 technology and speeds.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Understand

Wi-Fi 6 can operate on several bands : 2.4Ghz, 5Ghz and even the 6Ghz band as per the Wi-Fi 6E certification.

802.11ac came in two waves. The second wave brought the 160Mhz channel support, along with MU-MIMO and a theoretical maximum of 8 spatial streams.

These numbers are only the theoretical numbers from the standard, differences apply depending on the specific AP datasheet.

802.11ax is not directly defined in data rates speeds, but is rather a combination of 12 modulation encoding scheme (MCS 0 to MCS 11), a channel width ranging from 20mhz (1 channel) to 160Mhz (8 channels), a number of spatial streams (typically 1 to 2, there has been some 3 spatial streams products but they are seen less and less).

The short,medium or long Guard Interval (GI) also add around a 10% modification to this.

Here is a table to evaluate a datarate in Mbps when knowing all those factors :

A more complete table can found at : https://mcsindex.com/

Note: The data rate is NOT equal to the expected achievable throughput. This is related to the nature of 802.11 standard which has a lot of administrative overhead (management frames, contention, collision,acknowledgements,...)  and it can depend on the link SNR, RSSI and other significant factors.

It is a rule of thumb:

Expected throughput = Data Rate x 0.65

Take a real life example. A Cisco 9120 AP with a modern Wi-Fi 6 capable smartphone that is capable of 2 Spatial Streams. If we are in a high density environment where 20 Mhz channels are used, the maximum data rate used is between 240 and 280Mbps depending on the guard interval. This means that, in a clean environment and test conditions, we could have one client transferring data between 160 to 200 Mbps possibly (65 to 70% of protocol efficiency). This is only valid when doing an actual large transfer or speed test where the protocol is optimized for maximum data throughput. When using other applications, throughput goes down as latency also plays a role in protocols that do a ping-pong of packets and wait for acknowledgements before moving forward.

Note as well that wireless is shared environment, this means that the amount of clients connected to the AP are sharing the effective throughput between each other. If one client doing a speed test can reach between 160 to 200MBps, this means that two clients doing a speed test at the same time see each 80 to 100Mbps. If four clients do a speed test at the same time, they see 40 to 50Mbps each and so on ...

On top of that, more clients mean more contention and inevitably more collision. The effiency of the coverage cell drastically decreases as the number of clients increase. It is thefore unrealistic to set any kind of SLA for throughput in places where you do not control the amount of clients connected or what they are doing on the network in terms of activity.

Measure

Generally speaking, we can have two scenarios when you do a throughput test:

• APs are in Flexconnect local switching

• APs are in local mode or Flexconnect central switching

Take those scenarios one by one:

(Diagram 1)

In case of Diagram 1 we suppose that the APs are in local mode of Flexconnect central switching.

This means that all client traffic is encapsulated into CAPWAP tunnel and terminated on the WLC.

(Diagram 2)

The red line in the Diagram 2 shows the traffic flow from the wireless client.

The iPerf server must be as close as possible to the traffic termination point, ideally plugged in the same switch as the WLC itself and use the same VLAN.

In case of Flexconnect local switching, the client traffic is terminated on the AP itself, and considering that the iPerf server must be set up as close to the termination point of wireless client traffic, plug in the iPerf server to the same switch and same VLAN where AP is plugged.

In our case this is access switch (Diagram 3).

(Diagram 3)

The iPerf tests can be subdivided into two categories: upstream and downstream.

Considering that the iPerf server is listening and iPerf client is generating the traffic, when the iPerf server is on the wired side, this is considered upstream test.

The wireless client is using the iPerf application to push the traffic into the network.

The downstream test is vice-versa, meaning that the iPerf server is set on the wireless client itself and the iPerf client is on the wired side pushing the traffic to the wireless client, in this scenario, this is considered downstream.

The test must be done using TCP and UDP. You can use these commands to perform the tests:

iperf3 -s  <- this command starts iPerf server

iperf3 -c SERVER_ADDRESS -u -b700M <- this command initiates UDP iPerf test with bandwidth of 700 Mbps

iperf3 -c SERVER_ADDRESS <- this command initiates a simple TCP iPerf test

iperf3 -c SERVER_ADDRESS  -w WINDOW_SIZE  -P NUM_OF_PARALLEL_TCP_STREAMS <- this commands initiates a more complex  TCP iPerf test where you can adjust the window size as well the number of parallel TCP streams. 
Please not that in this case you should consider the sum of all the streams as the result

 

Example of iPerf3 outputs:

TCP iPerf3:

 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec   188 MBytes   157 Mbits/sec                  receiver
 
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.05  sec   304 MBytes   254 Mbits/sec                  receiver

   With 10 parallel TCP streams:
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.06  sec  88.6 MBytes  73.9 Mbits/sec                  receiver
[  7]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  7]   0.00-10.06  sec  79.2 MBytes  66.0 Mbits/sec                  receiver
[  9]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[  9]   0.00-10.06  sec  33.6 MBytes  28.0 Mbits/sec                  receiver
[ 11]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 11]   0.00-10.06  sec  48.7 MBytes  40.6 Mbits/sec                  receiver
[ 13]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 13]   0.00-10.06  sec  77.0 MBytes  64.2 Mbits/sec                  receiver
[ 15]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 15]   0.00-10.06  sec  61.8 MBytes  51.5 Mbits/sec                  receiver
[ 17]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 17]   0.00-10.06  sec  46.1 MBytes  38.4 Mbits/sec                  receiver
[ 19]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 19]   0.00-10.06  sec  43.9 MBytes  36.6 Mbits/sec                  receiver
[ 21]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 21]   0.00-10.06  sec  33.3 MBytes  27.8 Mbits/sec                  receiver
[ 23]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 23]   0.00-10.06  sec  88.8 MBytes  74.0 Mbits/sec                  receiver
[SUM]   0.00-10.06  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-10.06  sec   601 MBytes   501 Mbits/sec                  receiver
 

UDP iPerf3:

When using UDP, it is important to make sure there no to little packet loss. It is possible to see very high throughput numbers, but if you have a 50% packet loss, you did not actually transfer that amount of data.

Sometime iPerf does misbehave and does not give the average bandwidth in the end of the UDP test.

It is still possible to sum up the Bandwidth for each second and then divide it by number of seconds:

Accepted connection from 192.168.240.38, port 49264
[  5] local 192.168.240.43 port 5201 connected to 192.168.240.38 port 51711
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  53.3 MBytes   447 Mbits/sec  0.113 ms  32/6840 (0.47%)  
[  5]   1.00-2.00   sec  63.5 MBytes   533 Mbits/sec  0.129 ms  29/8161 (0.36%)  
[  5]   2.00-3.00   sec  69.8 MBytes   586 Mbits/sec  0.067 ms  30/8968 (0.33%)  
[  5]   3.00-4.00   sec  68.7 MBytes   577 Mbits/sec  0.071 ms  29/8827 (0.33%)  
[  5]   4.00-5.00   sec  68.0 MBytes   571 Mbits/sec  0.086 ms  55/8736 (0.63%)  
[  5]   5.00-6.00   sec  68.6 MBytes   576 Mbits/sec  0.076 ms  70/8854 (0.79%)  
[  5]   6.00-7.00   sec  66.8 MBytes   561 Mbits/sec  0.073 ms  34/8587 (0.4%)  
[  5]   7.00-8.00   sec  67.1 MBytes   563 Mbits/sec  0.105 ms  44/8634 (0.51%)  
[  5]   8.00-9.00   sec  66.7 MBytes   559 Mbits/sec  0.183 ms  144/8603 (1.7%)  
[  5]   9.00-10.00  sec  64.1 MBytes   536 Mbits/sec  0.472 ms  314/8415 (3.7%)  
[  5]  10.00-10.05  sec   488 KBytes  76.0 Mbits/sec  0.655 ms  2/63 (3.2%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.05  sec  0.00 Bytes  0.00 bits/sec  0.655 ms  783/84688 (0.92%)  
[SUM]  0.0-10.1 sec  224 datagrams received out-of-order

Note: It is expected that the iPerf results are slightly better on the Flexconnect local siwtching compared to the central switching scenario.
This is caused by the fact that client traffic is encapsulated into CAPWAP, which adds more overhead to the traffic and in general the WLC acts as a bottleneck as it is the aggregation point for all wireless clients traffic.
As well, it is expected that the UDP iPerf test will give better results in a clean environment as it is the most efficient transfer method when the connection is reliable. TCP however, can win in case of heavy fragmentation (when TCP Adjust MSS is used) or unreliable connection

.

Verify and validate

In order to check at which data rate the client is connected, issue these command in WLC CLI:

WLC#show wireless client mac e88d.a6b0.3bca det

Client MAC Address : e88d.a6b0.3bca
Client MAC Type : Universally Administered Address
Client DUID: NA
Client IPv4 Address : 192.168.1.44
Client IPv6 Addresses : fe80::7798:a5a:a957:ec89
Client Username: N/A
AP MAC Address : 18f9.354d.9d60
AP Name: 9164-etage
AP slot : 1
Client State : Associated
Policy Profile : Darchispp
Flex Profile : default-flex-profile
Wireless LAN Id: 2
WLAN Profile Name: Darchis6
Wireless LAN Network Name (SSID): Darchis6
BSSID : 18f9.354d.9d6f
Connected For : 103 seconds
Protocol : 802.11ax - 5 GHz
Channel : 52
Client IIF-ID : 0xa0000003
Association Id : 2
Authentication Algorithm : Open System
Idle state timeout : N/A
Session Timeout : 80000 sec (Remaining time: 79899 sec)
Session Warning Time : Timer not running
Input Policy Name  : None
Input Policy State : None
Input Policy Source : None
Output Policy Name  : None
Output Policy State : None
Output Policy Source : None
WMM Support : Enabled
U-APSD Support : Disabled
Fastlane Support : Disabled
Client Active State : Active
Power Save : ON
Current Rate : m10 ss2
Supported Rates : 54.0
AAA QoS Rate Limit Parameters:
  QoS Average Data Rate Upstream             :  (kbps)
  QoS Realtime Average Data Rate Upstream    :  (kbps)
  QoS Burst Data Rate Upstream               :  (kbps)
  QoS Realtime Burst Data Rate Upstream      :  (kbps)
  QoS Average Data Rate Downstream           :  (kbps)
  QoS Realtime Average Data Rate Downstream  :  (kbps)
  QoS Burst Data Rate Downstream             :  (kbps)
  QoS Realtime Burst Data Rate Downstream    :  (kbps)
Mobility:
  Move Count                  : 0
  Mobility Role               : Local
  Mobility Roam Type          : None
  Mobility Complete Timestamp : 02/26/2024 14:35:10 Central
Client Join Time:
  Join Time Of Client : 02/26/2024 14:35:10 Central
Client State Servers : None
Client ACLs : None
Policy Manager State: Run
Last Policy Manager State : IP Learn Complete
Client Entry Create Time : 103 seconds
Policy Type : WPA3
Encryption Cipher : CCMP (AES)
Authentication Key Management : FT-SAE
AAA override passphrase : No
SAE PWE Method : Hash to Element(H2E)
Transition Disable Bitmap : None
User Defined (Private) Network : Disabled
User Defined (Private) Network Drop Unicast : Disabled
Encrypted Traffic Analytics : No
Protected Management Frame - 802.11w : Yes
EAP Type : Not Applicable
VLAN Override after Webauth : No
VLAN : default
Multicast VLAN : 0
VRF Name : N/A
WiFi Direct Capabilities:
  WiFi Direct Capable           : No
Central NAT : DISABLED
Session Manager:
  Point of Attachment : capwap_90000002
  IIF ID             : 0x90000002
  Authorized         : TRUE
  Session timeout    : 80000
  Common Session ID: 00000000000041B8E5D75432
  Acct Session ID  : 0x00000000
  Auth Method Status List
  	Method : FT-SAE
  Local Policies:
  	Service Template : wlan_svc_Darchispp (priority 254)
  		VLAN             : 1
  		Absolute-Timer   : 80000
  Server Policies:
  Resultant Policies:
  		VLAN Name        : default
  		VLAN             : 1
  		Absolute-Timer   : 80000
DNS Snooped IPv4 Addresses : None
DNS Snooped IPv6 Addresses : None
Client Capabilities
  CF Pollable : Not implemented
  CF Poll Request : Not implemented
  Short Preamble : Not implemented
  PBCC : Not implemented
  Channel Agility : Not implemented
  Listen Interval : 0
Fast BSS Transition Details :
  Reassociation Timeout : 20
11v BSS Transition : Implemented
11v DMS Capable : No
QoS Map Capable : No
FlexConnect Data Switching : Local
FlexConnect Dhcp Status : Local
FlexConnect Authentication : Local
Client Statistics:
  Number of Bytes Received from Client : 64189
  Number of Bytes Sent to Client : 85831
  Number of Packets Received from Client : 808
  Number of Packets Sent to Client : 244
  Number of Data Retries : 66
  Number of RTS Retries : 0
  Number of Tx Total Dropped Packets : 0
  Number of Duplicate Received Packets : 0
  Number of Decrypt Failed Packets : 0
  Number of Mic Failured Packets : 0
  Number of Mic Missing Packets : 0
  Number of Policy Errors : 0
  Radio Signal Strength Indicator : -41 dBm
  Signal to Noise Ratio : 52 dB
Fabric status : Disabled
Radio Measurement Enabled Capabilities
  Capabilities: None
Client Scan Report Time : Timer not running
Client Scan Reports
Assisted Roaming Neighbor List
Nearby AP Statistics:
EoGRE : Pending Classification
Device Classification Information:
  Device Type      : Un-Classified Device
  Device Name      : Unknown Device
  Protocol Map     : 0x000001  (OUI)
Max Client Protocol Capability:
WiFi to Cellular Steering : Not implemented
Cellular Capability : N/A
Advanced Scheduling Requests Details:
  Apple Specific Requests(ASR) Capabilities/Statistics:
    Regular ASR support: DISABLED

You can see the this particular client is connected on these rate:

Current Rate..................................... m10 ss2

Which means that the client is using the MCS 10 (m10) index on 2 spatial streams (ss2)

From the "show wireless client mac <MAC> det" command, it is not possible to see if the client is connected on 20/40/80 MHz channel bonding.

This can be done directly on the AP:

9164 example:

#show controllers dot11Radio 2 client E8:8D:A6:B0:3B:CA
              mac radio vap aid state       encr  Maxrate Assoc   Cap is_wgb_wired      wgb_mac_addr
E8:8D:A6:B0:3B:CA     2   0  33   FWD AES_CCM128 MCS112SS HE-6E HE-6E        false 00:00:00:00:00:00
Configured rates for client E8:8D:A6:B0:3B:CA
Legacy Rates(Mbps): 6 9 12 18 24 36 48 54
HE Rates: 1SS:M0-11 2SS:M0-11
HT:yes     VHT:no     HE:yes     40MHz:no     80MHz:yes     80+80MHz:no     160MHz:yes
11w:yes     MFP:no     11h:no     session_timeout: 79950     encrypt_policy: 4
_wmm_enabled:yes     qos_capable:yes     WME(11e):no     WMM_MIXED_MODE:no
short_preamble:no     short_slot_time:no     short_hdr:no     SM_dyn:no
short_GI_20M:no     short_GI_40M:no     short_GI_80M:no     LDPC:no     AMSDU:yes     AMSDU_long:no
su_mimo_capable:no     mu_mimo_capable:no     is_wgb_wired:no     is_wgb:no
HE_DL-MIMO:yes     HE_UL-MIMO:yes     HE_DL-OFDMA:yes     HE_UL-OFDMA:yes     HE_TWT_CAPABLE:no

Additional info for client E8:8D:A6:B0:3B:CA
RSSI: -52
SNR: 41
PS  : Legacy (Sleeping)
Tx Rate: 1297100 Kbps
Rx Rate: 1921600 Kbps
VHT_TXMAP: 0
CCX Ver: 0
Rx Key-Index Errs: 0

Statistics for client E8:8D:A6:B0:3B:CA
              mac   intf TxData TxMgmt TxUC TxBytes TxFail TxDcrd TxCumRetries RxData RxMgmt RxBytes RxErr                      TxRt(Mbps) RxRt(Mbps) idle_counter stats_ago expirat
ion
E8:8D:A6:B0:3B:CA apr2v0    391      4  391  129127      0      0           97    559      4   74055     0 HE-160,2SS,MCS6,GI0.8 ,BF(1297)         12          295  8.674000      79
950

Per TID packet statistics for client E8:8D:A6:B0:3B:CA
Priority Rx Pkts Tx Pkts Rx(last 5 s) Tx (last 5 s)
       0     539     383           84            28
       1       0       0            0             0
       2       0       2            0             0
       3       0       0            0             0
       4       0       0            0             0
       5       0       0            0             0
       6      20       3            5             1
       7       0       3            0             0

 Rate Statistics:
Rate-Index    Rx-Pkts    Tx-Pkts Tx-Retries
         0        176          3          0
         5          0         62          0
         6          4        178         21
         7        250        152         52
         8        100          2         22
         9         51          0          0
        10          1          0          0
        11          0          0          2
webauth done: true
Pre-WebAuth ACLs:
Post-Auth ACLs:
Acl name Quota Bytes left In bytes Out bytes In pkts Out pkts Drops-in Drops-out
iPSK TAG: \<0000000000000000>
              MAC Allow HIT iPSK tag
E8:8D:A6:B0:3B:CA  true   0      \<>

The last option to check the connected rate is OTA captures. In the radio information of the data packet, you can find the necessary information:

 This OTA capture was taken with an 11ac macbook client.

Troubleshoot

In case you are not getting expected results during the test, there are several ways to troubleshoot the issue and collect necessary information before opening a TAC case.

The troughput issues can be caused by these:

- Client

- AP

- Wired path (switching related issues)

- WLC

Client troubleshooting

• First step will be updating the drivers on the wireless client devices to the latest version
• Second step will be doing the iPerf test with clients that have a different wireless adapter to see if you get the same results

AP troubleshooting

There can be scenarios when the AP is dropping traffic, or certain frames or otherwise misbehaving.

In order to get more insight about this, there are needed Over The Air (OTA) captures + span session on the AP switchport (span must be done on the switch where the AP is connected)

The OTA captures and SPAN must be done during the test, using open SSID in order to be able to see the traffic passed to the AP and the traffic AP is passing towards the client and vice a versa.

There are several known bugs for this behavior:

CSCvg07438 : AP3800: Low throughput due to packet drops in AP in both fragmented and non-fragmented packets

CSCva58429 : Cisco 1532i AP: low throughput (FlexConnect Local switching + EoGRE)

Wired path troubleshooting

There can be some problems on the switch itself, you need to check the amount of drops on the interfaces and if those increase during the tests.

Try using another port on the switch to connect the AP or WLC.

Another option is to plug in a client to the same switch (where the client termination point [AP/WLC] is connected to) and put it to the same VLAN, then run the tests wired to wired on the same VLAN to see if there are any issues in the wired path.

WLC troubleshooting

It can be that the WLC is dropping the traffic (when APs are in local mode) from the client.

You can put the AP in Flexconnect mode and the WLAN into local switching, then run the tests.

If you see that there are significant differences in the throughput in local mode (central switching) compared to Flexconnect local switching and there is no problem on the switch connected to WLC, then most probably the WLC is dropping the traffic.

To troubleshoot this, apply the action plan:

- SPAN captures on the WLC switchport (must be done on the switch)

- SPAN captures on the AP port

- OTA captures of the client

By performing this troubleshooting and providing the results to TAC, this speeds up the troubleshooting process.