Validar y probar el rendimiento inalámbrico de Wi-Fi 6/6E y Wi-Fi 7

Introducción

Este documento describe la manera de probar el rendimiento inalámbrico de un punto de acceso centrado en 802.11ax y qué rendimiento se puede esperar.

Prerequisites

Requirements

En este documento se presupone que ya hay una configuración en funcionamiento con puntos de acceso (AP) 802.11ax / Wi-Fi 6 que ya proporciona conectividad al cliente

Componentes Utilizados

La información de este documento se centra en la tecnología y las velocidades 802.11ax/Wi-Fi 6.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Comprender la evolución del protocolo

Wi-Fi 6 puede funcionar en varias bandas: 2,4 Ghz, 5 Ghz e incluso la banda de 6 Ghz según la certificación Wi-Fi 6E.

802.11ac/Wi-Fi 5 se presentó en dos fases. La segunda oleada incluyó el soporte de canal de 160 Mhz, junto con MU-MIMO y un máximo teórico de 8 flujos espaciales.

Estos números son solo los números teóricos del estándar, las diferencias se aplican dependiendo de la hoja de datos AP específica.

802.11ax/Wi-Fi 6 no está definido directamente en velocidades de velocidad de datos, sino que es una combinación del esquema de codificación de modulación de 12 (MCS 0 a MCS 11), un ancho de canal que va desde 20 mhz (1 canal) a 160 Mhz (8 canales), un número de flujos espaciales (normalmente de 1 a 2, ha habido unos 3 productos de flujos espaciales, pero se ven cada vez menos).

El intervalo de protección (GI) corto, medio o largo también añade una modificación del 10%.

Esta es una tabla para evaluar una velocidad de datos en Mbps cuando se conocen todos esos factores :

Puede encontrar una tabla más completa en : https://mcsindex.com/

Nota: La velocidad de datos NO es igual al rendimiento esperado alcanzable. Esto está relacionado con la naturaleza del estándar 802.11, que tiene una gran cantidad de sobrecarga administrativa (tramas de gestión, contención, colisión, reconocimientos,...) y puede depender del SNR de enlace, RSSI y otros factores significativos.

Puede calcular el rendimiento mediante el uso de esta ecuación utilizada para la velocidad de datos o velocidad de 802.11ax:

Ecuación utilizada para velocidad o velocidad de datos de 802.11ax

Es una regla general:

Rendimiento esperado = Velocidad de datos x 0,7

Tomemos un ejemplo real. Un Cisco 9120 AP con un moderno smartphone compatible con Wi-Fi 6 que puede admitir 2 flujos espaciales. Si estamos en un entorno de alta densidad donde se utilizan canales de 20 Mhz, la velocidad máxima de datos utilizada es de entre 240 y 280 Mbps, dependiendo del intervalo de protección. Esto significa que, en un entorno limpio y en condiciones de prueba, podríamos tener un cliente que transfiriera datos entre 160 y 200 Mbps, posiblemente (entre el 65 y el 70% de la eficacia del protocolo). Esto solo es válido cuando se realiza una prueba de transferencia o velocidad real grande donde el protocolo está optimizado para el rendimiento máximo de datos. Cuando se utilizan otras aplicaciones, el rendimiento disminuye, ya que la latencia también desempeña un papel en los protocolos que realizan un ping-pong de paquetes y esperan las confirmaciones antes de avanzar.

Tenga en cuenta también que la red inalámbrica es un entorno compartido, esto significa que la cantidad de clientes conectados al AP están compartiendo el rendimiento efectivo entre sí. Si un cliente que realiza una prueba de velocidad puede alcanzar entre 160 y 200 MBps, esto significa que dos clientes que realizan una prueba de velocidad al mismo tiempo ven cada 80 a 100 Mbps. Si cuatro clientes realizan una prueba de velocidad al mismo tiempo, verán de 40 a 50 Mbps cada uno, etc.

Además de eso, más clientes significan más contención e inevitablemente más colisión. La eficacia de la celda de cobertura disminuye drásticamente a medida que aumenta el número de clientes. Por lo tanto, no es realista establecer ningún tipo de SLA para el rendimiento en lugares donde no se controla la cantidad de clientes conectados o lo que están haciendo en la red en términos de actividad.

Wi-Fi 7

Wi-Fi 7 aporta muchas mejoras de protocolo que mejorarán el rendimiento observado. Sin embargo, las velocidades máximas se mejoran principalmente mediante la adición de la velocidad de datos de MCS 12 y 13 (que, sin embargo, deben estar muy cerca del punto de acceso), así como la adición de un ancho de canal de 320 MHz (que puede que no sea realista utilizar en un entorno empresarial, ya que agrupa muchos canales). No cambia mucho a la metodología de prueba explicada en este documento.

Multi-Link Operation (MLO) es otra mejora de Wi-Fi 7 que a menudo se utiliza para presumir de enormes velocidades de datos potenciales. En la vida real, la mayoría de los clientes se conectarán en varias bandas con MLO, pero utilizarán principalmente una sola banda (para ahorrar batería). Las bandas de 5 y 6 GHz también son difíciles de usar simultáneamente debido a las interferencias que las radios provocan entre sí. Verifique cómo está conectado su cliente para anticipar qué velocidades puede alcanzar razonablemente.

Medida

En términos generales, podemos tener dos escenarios cuando se realiza una prueba de rendimiento:

• Los AP están en el switching local Flexconnect

• Los AP están en modo local o conmutación central Flexconnect

Tomen esos escenarios uno por uno:

(Diagrama 1)

En el caso del Diagrama 1, suponemos que los AP están en el modo local de conmutación central Flexconnect.

Esto significa que todo el tráfico del cliente se encapsula en el túnel CAPWAP y termina en el WLC.

(Diagrama 2)

La línea roja del diagrama 2 muestra el flujo de tráfico del cliente inalámbrico.

El servidor iPerf debe estar lo más cerca posible del punto de terminación del tráfico, idealmente conectado en el mismo switch que el propio WLC y utilizar la misma VLAN.

En el caso de la conmutación local Flexconnect, el tráfico del cliente se termina en el AP mismo, y considerando que el servidor iPerf debe configurarse lo más cerca posible del punto de terminación del tráfico del cliente inalámbrico, conecte el servidor iPerf al mismo switch y a la misma VLAN donde está conectado el AP.

En nuestro caso se trata del switch de acceso (Diagrama 3).

(Diagrama 3)

Las pruebas iPerf se pueden subdividir en dos categorías: ascendente y descendente.

Teniendo en cuenta que el servidor iPerf está escuchando y que el cliente iPerf está generando el tráfico, cuando el servidor iPerf está en el lado cableado, esto se considera una prueba ascendente.

El cliente inalámbrico utiliza la aplicación iPerf para dirigir el tráfico a la red.

La prueba de flujo descendente es viceversa, lo que significa que el servidor iPerf está configurado en el propio cliente inalámbrico y que el cliente iPerf está en el lado cableado que envía el tráfico al cliente inalámbrico; en este escenario, esto se considera flujo descendente.

La prueba se debe realizar mediante TCP y UDP. Puede utilizar estos comandos para realizar las pruebas:

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

 

Ejemplo de salidas iPerf3:

Rendimiento de TCP 3:

 
[ 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:

Al utilizar UDP, es importante asegurarse de que no haya una pérdida mínima de paquetes. Es posible ver cifras de rendimiento muy altas, pero si tiene una pérdida de paquetes del 50%, en realidad no transfirió esa cantidad de datos.

A veces, iPerf se comporta mal y no proporciona el ancho de banda promedio al final de la prueba UDP.

Todavía es posible resumir el ancho de banda para cada segundo y luego dividirlo por número de segundos:

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

Nota: Se espera que los resultados de iPerf sean ligeramente mejores en el switching local Flexconnect en comparación con el escenario de switching central.
Esto se debe al hecho de que el tráfico del cliente se encapsula en CAPWAP, que agrega más sobrecarga al tráfico y en general el WLC actúa como un cuello de botella ya que es el punto de agregación para todo el tráfico de clientes inalámbricos.
Además, se espera que la prueba UDP iPerf dé mejores resultados en un entorno limpio, ya que es el método de transferencia más eficiente cuando la conexión es confiable. TCP, sin embargo, puede ganar en caso de fragmentación pesada (cuando se utiliza MSS de ajuste de TCP) o de conexión no confiable

.

Verificar y validar

El primer paso es verificar la configuración actual del cliente. En Windows 11, desplácese hasta Settings > Network & internet > Wi-Fi > Your_SSID_Name:

Configuración Wi-Fi en el cliente

Puede ver cómo se asigna la dirección IP (en este caso mediante el proceso DHCP) al protocolo en uso, la versión del controlador, la banda y el canal de red, y la velocidad del enlace. La velocidad del link es la velocidad teórica máxima entre el cliente y el AP, lo que significa que la velocidad de la vida real puede ser más lenta.

Precaución: Compruebe si la versión del controlador es la más reciente. Un controlador que no está actualizado puede afectar al rendimiento y la velocidad de la red.

Si no alcanza las velocidades esperadas, puede deberse a que el cliente no se conecta a la banda de 6 GHz y se adhiere únicamente a las otras bandas. A pesar de disponer de un adaptador Wi-Fi 6E, algunos ordenadores portátiles requieren una actualización de la BIOS para habilitar las capacidades de 6 GHz. También depende del país donde se está llevando a cabo la prueba : algunos AP de infraestructura desactivan 6GHz en algunos países donde todavía no está permitido y algunos portátiles cliente están codificados para no utilizar 6GHz en países específicos. Compruebe tanto el firmware del punto de acceso como el del cliente para obtener detalles sobre el país específico con el que está realizando la prueba.

Para verificar a qué velocidad de datos el cliente está conectado, ejecute estos comandos en WLC CLI:

WLC#show wireless client mac-address 72e6.81a1.XXXX detail
(...)
Current Rate..................................... m11 ss2 -> MCS 11 (m11) index on 2 spatial streams (ss2)
(...)
Radio Signal Strength Indicator............ -46 dBm
      Signal to Noise Ratio...................... 49 dB

Puede ver que este cliente en particular está conectado a estas velocidades:

Velocidad actual..................................... m10 ss2

Lo que significa que el cliente está utilizando el índice MCS 10 (m10) en 2 flujos espaciales (ss2)

Desde el comando "show wireless client mac <MAC> det", no es posible ver si el cliente está conectado en la vinculación de canales de 20/40/80 MHz.

Esto se puede hacer directamente en el AP:

9164 ejemplo:

#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      \<>

La última opción para verificar la velocidad conectada es capturas OTA. En la información de radio del paquete de datos, puede encontrar la información necesaria:

 Esta captura de OTA se realizó con un cliente de MacBook 11ac.

Troubleshoot

En caso de que no obtenga los resultados esperados durante la prueba, hay varias formas de resolver el problema y recopilar la información necesaria antes de abrir un caso TAC.

Los problemas de rendimiento pueden deberse a lo siguiente:

-Cliente

-AP

- Ruta cableada (problemas relacionados con el switching)

- WLC

Troubleshooting del cliente

• El primer paso consiste en actualizar los controladores de los dispositivos cliente inalámbricos a la última versión
• El segundo paso es realizar la prueba de iPerf con clientes que tienen un adaptador inalámbrico diferente para ver si obtiene los mismos resultados

• Si el vídeo de las reuniones online se "congela" o el audio tiene mala calidad, configure QoS (calidad de servicio Wi-Fi). Los servicios que se basan en audio y vídeo en tiempo real, como voz sobre IP (VoIP), juegos en línea y videoconferencias empresariales tienen unos requisitos estrictos en términos de latencia y fluctuación para ofrecer una experiencia de calidad. QoS gestiona los problemas de congestión y reduce la probabilidad de que se produzca una colisión y evita la congestión en primer lugar. Las aplicaciones en tiempo real no ofrecen un rendimiento elevado y no deben compararse con las velocidades bajas de una red. Se relacionan más con la fiabilidad de la entrega de paquetes en tiempo real.

  Implemente la configuración de QoS en el WLC, con los perfiles: Voz, invitado, empresa, vía rápida. Estos perfiles se configuran bajo el perfil de política. WLC también proporciona cuatro perfiles QoS preconfigurados: Platino, Oro, Plata y Bronce (políticas de QoS de metal). Bronze para tráfico de fondo o de menor prioridad, Silver para el mejor esfuerzo, Gold para aplicaciones de vídeo, Platinum para aplicaciones de voz.

Troubleshooting de AP

Puede haber escenarios cuando el AP está descartando tráfico, o ciertas tramas o se comporta mal de otra manera.

Para obtener más información sobre esto, se necesitan capturas Over The Air (OTA) + sesión span en el puerto de switch AP (el span se debe realizar en el switch donde está conectado el AP)

Las capturas de OTA y SPAN se deben realizar durante la prueba, utilizando SSID abierto para poder ver el tráfico que pasa al AP y el AP de tráfico que pasa hacia el cliente y viceversa.

Existen varios errores conocidos para este comportamiento:

CSCvg07438: AP3800: Bajo rendimiento debido a caídas de paquetes en AP en paquetes fragmentados y no fragmentados

CSCva58429: Cisco 1532i AP: bajo rendimiento (FlexConnect Local Switching + EoGRE)

Troubleshooting de trayecto cableado

Puede haber algunos problemas en el switch en sí, debe verificar la cantidad de caídas en las interfaces y si éstas aumentan durante las pruebas.

Intente utilizar otro puerto en el switch para conectar el AP o el WLC.

Otra opción es conectar un cliente al mismo switch (donde el punto de terminación del cliente [AP/WLC] está conectado) y ponerlo en la misma VLAN, luego ejecutar las pruebas cableadas a cableadas en la misma VLAN para ver si hay algún problema en la trayectoria cableada.

Troubleshooting de WLC

Puede ser que el WLC esté descartando el tráfico (cuando los AP están en el modo local) del cliente.

Puede poner el AP en el modo Flexconnect y el WLAN en el switching local, luego ejecutar las pruebas.

Si usted ve que hay diferencias significativas en el rendimiento en el modo local (conmutación central) comparado con la conmutación local de Flexconnect y no hay ningún problema en el switch conectado al WLC, entonces lo más probable es que el WLC esté descartando el tráfico.

Para solucionar este problema, aplique el plan de acción:

- Capturas SPAN en el puerto de switch WLC (se debe hacer en el switch)

- Capturas SPAN en el puerto AP

- Capturas OTA del cliente

Al realizar esta solución de problemas y proporcionar los resultados al TAC, se acelera el proceso de solución de problemas.

Información Relacionada

• Detalles para obtener OTA con MacBook
• Detalles para obtener OTA con AP en modo Sniffer
• Prueba IPERF para medir el rendimiento/velocidad de un cliente WLAN

• Calculadora de velocidad WLAN 802.11ax | Calculadora de velocidad de datos 802.11ax

• Comprensión de Wi-Fi 4/5/6/6E/7 (802.11 n/ac/ax/be)

• Soporte técnico y descargas de Cisco