Validar e testar a taxa de transferência sem fio do Wi-Fi 6/6E e Wi-Fi 7

Introdução

Este documento descreve a forma de testar a taxa de transferência sem fio de um access point com foco em 802.11ax e qual taxa de transferência esperar.

Pré-requisitos

Requisitos

Este documento pressupõe uma configuração já em funcionamento com access points (APs) 802.11ax / Wi-Fi 6, fornecendo conectividade de cliente já

Componentes Utilizados

As informações neste documento estão focadas na tecnologia 802.11ax/Wi-Fi 6 e suas velocidades.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Entender a evolução do protocolo

O Wi-Fi 6 pode operar em várias bandas: 2,4 Ghz, 5 Ghz e até mesmo a banda de 6 Ghz de acordo com a certificação Wi-Fi 6E.

802.11ac/Wi-Fi 5 veio em duas ondas. A segunda onda trouxe o suporte de canal de 160 MHz, junto com MU-MIMO e um máximo teórico de 8 fluxos espaciais.

Esses números são apenas os números teóricos do padrão, as diferenças se aplicam dependendo da folha de dados específica do AP.

802.11ax/Wi-Fi 6 não é diretamente definido em velocidades de taxas de dados, mas é uma combinação de 12 esquema de codificação de modulação (MCS 0 a MCS 11), uma largura de canal que varia de 20 mhz (1 canal) a 160 Mhz (8 canais), um número de fluxos espaciais (tipicamente 1 a 2, houve alguns 3 produtos de fluxos espaciais, mas eles são vistos cada vez menos).

O Intervalo de Guarda (GI) curto, médio ou longo também adiciona cerca de 10% de modificação a isso.

Esta é uma tabela para avaliar uma taxa de dados em Mbps quando conhecer todos esses fatores:

Uma tabela mais completa pode ser encontrada em : https://mcsindex.com/

Note: A taxa de dados NÃO é igual à taxa de transferência atingível esperada. Isso está relacionado à natureza do padrão 802.11, que tem muita sobrecarga administrativa (quadros de gerenciamento, contenção, colisão, confirmações,...) e pode depender do link SNR, RSSI e outros fatores significativos.

Você pode calcular o throughput com o uso desta equação usada para a velocidade 802.11ax ou taxa de dados:

Equação usada para velocidade 802.11ax ou taxa de dados

É uma regra prática:

Throughput esperado = Taxa de dados x 0,7

Tome um exemplo real. Um AP Cisco 9120 com um smartphone moderno com capacidade Wi-Fi 6, capaz de 2 fluxos espaciais. Se estivermos em um ambiente de alta densidade onde canais de 20 Mhz são usados, a taxa de dados máxima usada é entre 240 e 280 Mbps, dependendo do intervalo de guarda. Isso significa que, em um ambiente limpo e condições de teste, poderíamos ter um cliente transferindo dados entre 160 e 200 Mbps possivelmente (65 a 70% de eficiência do protocolo). Isso só é válido quando se faz uma transferência grande real ou um teste de velocidade em que o protocolo é otimizado para throughput máximo de dados. Ao usar outros aplicativos, o throughput cai à medida que a latência também desempenha um papel nos protocolos que fazem um ping-pong de pacotes e esperam por confirmações antes de prosseguir.

Observe também que o ambiente sem fio é compartilhado, isso significa que a quantidade de clientes conectados ao AP está compartilhando o throughput efetivo entre si. Se um cliente que estiver fazendo um teste de velocidade puder alcançar entre 160 e 200 MBps, isso significa que dois clientes que estiverem fazendo um teste de velocidade ao mesmo tempo verão cada um de 80 a 100 Mbps. Se quatro clientes fizerem um teste de velocidade ao mesmo tempo, eles verão de 40 a 50 Mbps cada e assim por diante...

Além disso, mais clientes significam mais contenção e, inevitavelmente, mais colisão. A eficiência da célula de cobertura diminui drasticamente à medida que o número de clientes aumenta. Portanto, é irrealista definir qualquer tipo de SLA para produtividade em locais onde você não controla a quantidade de clientes conectados ou o que eles estão fazendo na rede em termos de atividade.

Wi-Fi 7

O Wi-Fi 7 traz várias melhorias de protocolo que melhorarão o throughput observado. No entanto, as velocidades máximas são melhoradas principalmente pela adição da taxa de dados MCS 12 e 13 (que exigem estar muito perto do access point, no entanto), bem como a adição da largura de canal de 320Mhz (que talvez não seja realista de usar em uma configuração empresarial, pois reúne muitos canais juntos). Isso não muda muito a metodologia de teste explicada neste documento.

A Multi-Link Operation (MLO) é outra melhoria do Wi-Fi 7 que é frequentemente usada para ostentar taxas de dados potenciais enormes. Na vida real, a maioria dos clientes se conectará em várias bandas com MLO, mas usará principalmente uma única banda (a fim de economizar a vida útil da bateria). As faixas de 5 e 6 GHz também são difíceis de usar simultaneamente devido às interferências que os rádios causam entre si. Verifique como seu cliente está conectado para antecipar as velocidades que ele pode razoavelmente alcançar.

Medir

De modo geral, podemos ter dois cenários quando você faz um teste de throughput:

• Os APs estão na comutação local Flexconnect

• Os APs estão no modo local ou no switching central Flexconnect

Siga esses cenários um por um:

(Diagrama 1)

No caso do Diagrama 1, supomos que os APs estão no modo local de switching central Flexconnect.

Isso significa que todo o tráfego do cliente é encapsulado no túnel CAPWAP e encerrado na WLC.

(Diagrama 2)

A linha vermelha no diagrama 2 mostra o fluxo de tráfego do cliente sem fio.

O servidor iPerf deve estar o mais próximo possível do ponto de terminação de tráfego, idealmente conectado ao mesmo switch que a própria WLC e usar a mesma VLAN.

No caso do switching local do Flexconnect, o tráfego do cliente é terminado no próprio AP e, considerando que o servidor iPerf deve ser configurado o mais próximo possível do ponto de término do tráfego do cliente sem fio, conecte o servidor iPerf ao mesmo switch e à mesma VLAN onde o AP está conectado.

No nosso caso, trata-se de um switch de acesso (Figura 3).

(Diagrama 3)

Os testes de iPerf podem ser subdivididos em duas categorias: upstream e downstream.

Considerando que o servidor iPerf está escutando e que o cliente iPerf está gerando o tráfego, quando o servidor iPerf está no lado com fio, isso é considerado um teste de upstream.

O cliente sem fio está usando a aplicação iPerf para enviar o tráfego para a rede.

O teste de downstream é vice-versa, significando que o servidor iPerf está definido no próprio cliente sem fio e o cliente iPerf está no lado com fio enviando o tráfego para o cliente sem fio, nesse cenário, isso é considerado downstream.

O teste deve ser feito usando TCP e UDP. Você pode usar estes comandos para executar os testes:

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

 

Exemplo de saídas de iPerf3:

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:

Ao usar o UDP, é importante certificar-se de que não haja pouca perda de pacotes. É possível ver números de throughput muito altos, mas se você tiver 50% de perda de pacotes, não transferiu realmente essa quantidade de dados.

Às vezes, o iPerf não se comporta corretamente e não fornece a largura de banda média no final do teste de UDP.

Ainda é possível somar a Largura de Banda para cada segundo e dividi-la pelo 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

Observação: espera-se que os resultados de iPerf sejam um pouco melhores no switching local do Flexconnect em comparação com o cenário de switching central.
Isso é causado pelo fato de que o tráfego do cliente é encapsulado no CAPWAP, o que adiciona mais sobrecarga ao tráfego e, em geral, o WLC age como um gargalo, pois é o ponto de agregação para todo o tráfego de clientes sem fio.
Além disso, espera-se que o teste UDP iPerf dê melhores resultados em um ambiente limpo, pois é o método de transferência mais eficiente quando a conexão é confiável. O TCP, no entanto, pode vencer em caso de fragmentação pesada (quando o TCP Adjust MSS é usado) ou conexão não confiável

.

Verificar e validar

A primeira etapa é verificar a configuração atual do cliente. No Windows 11, navegue para Settings > Network & internet > Wi-Fi > Your_SSID_Name:

Configurações Wi-fi no cliente

Você pode ver como o endereço IP é atribuído (neste caso, foi pelo protocolo DHCP) o protocolo em uso, a versão do driver, a banda e o canal da rede e a velocidade do link. A velocidade do link é a velocidade máxima teórica entre o cliente e o AP, o que significa que a velocidade real pode ser mais lenta.

Caution: Verifique se a versão do seu driver é a mais recente. Um driver não atualizado pode causar impacto no desempenho/velocidade da rede.

Se você não atingir as velocidades esperadas, pode ser porque seu cliente não está se conectando à banda de 6 GHz e se agarra apenas às outras bandas. Apesar de ter um adaptador Wi-Fi 6E, alguns notebooks exigem uma atualização do BIOS para habilitarem os recursos de 6 GHz. Depende também do país onde o teste é realizado: alguns APs de infraestrutura desabilitam 6GHz em alguns países onde ainda não é permitido e alguns laptops de cliente são codificados para não usar 6GHz em países específicos. Verifique o AP e o firmware do cliente para obter detalhes sobre o país específico com o qual você está testando.

Para verificar em que taxa de dados o cliente está conectado, execute estes comandos na CLI da WLC:

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

Você pode ver que este cliente específico está conectado a estas taxas:

Taxa Atual.......................... m10 ss2

O que significa que o cliente está usando o índice MCS 10 (m10) em 2 fluxos espaciais (ss2)

A partir do comando "show wireless client mac <MAC> det", não é possível ver se o cliente está conectado em uma combinação de canais de 20/40/80 MHz.

Isso pode ser feito diretamente no AP:

9164 exemplo:

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

A última opção para verificar a taxa conectada são as capturas OTA. Nas informações de rádio do pacote de dados, você pode encontrar as informações necessárias:

 Esta captura OTA foi feita com um cliente de macbook 11ac.

Troubleshooting

Caso você não esteja obtendo os resultados esperados durante o teste, há várias maneiras de solucionar o problema e coletar as informações necessárias antes de abrir um caso de TAC.

Os problemas de throughput podem ser causados por:

-Cliente

-AP

- Caminho com fio (problemas relacionados a switching)

- WLC

Solução de problemas do cliente

• A primeira etapa é atualizar os drivers nos dispositivos clientes sem fio para a versão mais recente
• A segunda etapa é fazer o teste de iPerf com clientes que têm um adaptador sem fio diferente para ver se você obtém os mesmos resultados

• Se o vídeo de reuniões online 'congelar' ou o áudio tiver qualidade ruim, configure a QoS (Qualidade de Serviço Wi-Fi). Os serviços que dependem de áudio e vídeo em tempo real, como voz sobre IP (VoIP), jogos on-line e videoconferência corporativa, têm fortes requisitos em termos de latência e instabilidade para oferecer uma experiência de qualidade. A QoS gerencia problemas de congestionamento e reduz a probabilidade de ocorrência de uma colisão e, em primeiro lugar, evita congestionamento. Os aplicativos em tempo real não aproveitam com altas taxas de transferência e não devem ser comparados a baixas velocidades em uma rede. Eles estão mais relacionados à confiabilidade da entrega de pacotes em tempo real.

  Implante as configurações de QoS na WLC, com os seguintes perfis: Voz, Convidado, Empresa, Fastlane. Esses perfis são configurados no perfil de política. A WLC também fornece quatro perfis de QoS pré-configurados: Platinum, Gold, Silver e Bronze (políticas de QoS de metal). Bronze para tráfego de segundo plano ou prioridade mais baixa, Silver para melhor esforço, Gold para aplicativos de vídeo, Platinum para aplicativos de voz.

Troubleshooting de AP

Pode haver situações em que o AP esteja descartando tráfego, determinados quadros ou com comportamento incorreto.

Para obter mais informações sobre isso, são necessárias capturas Over The Air (OTA) + sessão de span na porta do switch do AP (span deve ser feito no switch onde o AP está conectado)

As capturas OTA e SPAN devem ser feitas durante o teste, usando o SSID aberto para poder ver o tráfego passado para o AP e o AP de tráfego está passando para o cliente e vice-versa.

Há vários bugs conhecidos para esse comportamento:

CSCvg07438: AP3800: Baixa taxa de transferência devido a quedas de pacotes no AP em pacotes fragmentados e não fragmentados

CSCva58429: AP Cisco 1532i: baixo rendimento (switching local FlexConnect + EoGRE)

Solução de problemas de caminho com fio

Pode haver alguns problemas no próprio switch, você precisa verificar a quantidade de quedas nas interfaces e se elas aumentam durante os testes.

Tente usar outra porta no switch para conectar o AP ou a WLC.

Outra opção é conectar um cliente ao mesmo switch (ao qual o ponto de terminação do cliente [AP/WLC] está conectado) e colocá-lo na mesma VLAN e, em seguida, executar os testes com fio na mesma VLAN para ver se há algum problema no caminho com fio.

Troubleshooting de WLC

Pode ser que a WLC esteja descartando o tráfego (quando os APs estão no modo local) do cliente.

Você pode colocar o AP no modo Flexconnect e a WLAN na comutação local, depois executar os testes.

Se você observar que há diferenças significativas no throughput no modo local (switching central) em comparação com o switching local do Flexconnect e não há nenhum problema no switch conectado ao WLC, provavelmente o WLC está descartando o tráfego.

Para solucionar esse problema, aplique o plano de ação:

- Capturas de SPAN na porta do switch da WLC (deve ser feito no switch)

- Capturas de SPAN na porta do AP

- Capturas OTA do cliente

Ao executar essa solução de problemas e fornecer os resultados ao TAC, isso acelera o processo de solução de problemas.

Informações Relacionadas

• Detalhes para obter OTA com MacBook
• Detalhes para obter OTA com AP no modo Sniffer
• Teste IPERF para medir o throughput/velocidade de um cliente WLAN

• Calculadora de velocidade WLAN 802.11ax | calculadora de taxa de dados 802.11ax

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

• Suporte técnico e downloads da Cisco