Validation et test du débit sans fil Wi-Fi 6/6E et Wi-Fi 7

Introduction

Ce document décrit la façon de tester le débit sans fil d'un point d'accès en se concentrant sur la norme 802.11ax et le débit attendu.

Conditions préalables

Exigences

Ce document suppose une configuration déjà fonctionnelle avec des points d'accès 802.11ax / Wi-Fi 6 offrant déjà une connectivité client

Composants utilisés

Les informations contenues dans ce document sont axées sur la technologie et les vitesses 802.11ax/Wi-Fi 6.

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Comprendre l'évolution du protocole

Le Wi-Fi 6 peut fonctionner sur plusieurs bandes : 2,4 GHz, 5 GHz et même la bande 6 GHz selon la certification Wi-Fi 6E.

La norme 802.11ac/Wi-Fi 5 est apparue en deux vagues. La seconde vague a apporté le support de canal 160Mhz, avec MU-MIMO et un maximum théorique de 8 flux spatiaux.

Ces nombres ne sont que les nombres théoriques de la norme, les différences s'appliquent en fonction de la feuille de données AP spécifique.

802.11ax/Wi-Fi 6 n'est pas directement défini dans les débits de données, mais est plutôt une combinaison de 12 schémas de codage de modulation (MCS 0 à MCS 11), une largeur de canal allant de 20 MHz (1 canal) à 160 MHz (8 canaux), un certain nombre de flux spatiaux (généralement 1 à 2, il y a eu quelques 3 produits de flux spatiaux, mais ils sont vus de moins en moins).

L'intervalle de garde (IG) court, moyen ou long ajoute également environ 10% de modification à ce dernier.

Voici un tableau pour évaluer un débit en Mbits/s en connaissant tous ces facteurs :

Un tableau plus complet est disponible à l'adresse : https://mcsindex.com/

Remarque : Le débit de données n'est PAS égal au débit réalisable attendu. Ceci est lié à la nature de la norme 802.11 qui a beaucoup de surcharge administrative (trames de gestion, conflits, collisions, accusés de réception, etc.) et cela peut dépendre de la liaison SNR, RSSI et d'autres facteurs importants.

Vous pouvez calculer le débit en utilisant l'équation suivante pour la vitesse ou le débit de données 802.11ax :

Équation utilisée pour la vitesse 802.11ax ou le débit de données

C'est une règle de base :

Débit attendu = Débit de données x 0,7

Prenez un exemple de la vie réelle. Un point d'accès Cisco 9120 avec un smartphone moderne compatible Wi-Fi 6 et capable de 2 flux spatiaux. Si nous sommes dans un environnement à haute densité où des canaux de 20 Mhz sont utilisés, le débit de données maximal utilisé est compris entre 240 et 280 Mbits/s selon l'intervalle de garde. Cela signifie que, dans un environnement propre et dans des conditions de test, un client peut transférer des données entre 160 et 200 Mbits/s (soit 65 à 70 % de l'efficacité du protocole). Ceci n'est valable que lors d'un transfert important ou d'un test de vitesse où le protocole est optimisé pour un débit de données maximal. Lorsque vous utilisez d’autres applications, le débit diminue car la latence joue également un rôle dans les protocoles qui exécutent une requête ping-pong de paquets et attendent des accusés de réception avant de poursuivre.

Notez également que le sans fil est un environnement partagé, ce qui signifie que la quantité de clients connectés au point d'accès partage le débit effectif entre eux. Si un client effectuant un test de vitesse peut atteindre entre 160 et 200 Mbits/s, cela signifie que deux clients effectuant un test de vitesse en même temps voient chaque 80 à 100 Mbits/s. Si quatre clients effectuent un test de vitesse en même temps, ils voient 40 à 50 Mbits/s chacun, etc.

En plus de cela, plus de clients signifie plus de contention et inévitablement plus de collision. L'efficacité de la cellule de couverture diminue considérablement à mesure que le nombre de clients augmente. Il est donc irréaliste de définir un type de SLA pour le débit dans des endroits où vous ne contrôlez pas la quantité de clients connectés ou ce qu'ils font sur le réseau en termes d'activité.

Wi-Fi 7

Le Wi-Fi 7 apporte de nombreuses améliorations de protocole qui amélioreront le débit observé. Cependant, les débits maximaux sont principalement améliorés par l'ajout des débits de données MCS 12 et 13 (qui doivent cependant être très proches du point d'accès) ainsi que par l'ajout d'une largeur de canal de 320 MHz (qui n'est peut-être pas réaliste à utiliser dans un environnement d'entreprise car il regroupe un grand nombre de canaux). Il ne change pas grand-chose à la méthodologie de test expliquée dans ce document.

Multi-Link Operation (MLO) est une autre amélioration du Wi-Fi 7 qui est souvent utilisé pour se vanter d'énormes débits de données potentiels. Dans la vie réelle, la plupart des clients se connecteront sur plusieurs bandes avec MLO, mais utiliseront surtout une seule bande (afin d'économiser de la batterie). Les bandes 5 et 6 GHz sont également difficiles à utiliser simultanément en raison des interférences que les radios causent l'une à l'autre. Vérifiez comment votre client est connecté afin d'anticiper les vitesses qu'il peut raisonnablement atteindre.

Mesurer

En règle générale, deux scénarios sont possibles lorsque vous effectuez un test de débit :

• Les points d'accès sont dans la commutation locale Flexconnect

• Les points d'accès sont en mode local ou en commutation centrale Flexconnect

Prenez ces scénarios un par un :

(Schéma 1)

Dans le cas du schéma 1, nous supposons que les AP sont en mode local de commutation centrale Flexconnect.

Cela signifie que tout le trafic client est encapsulé dans le tunnel CAPWAP et se termine sur le WLC.

(Schéma 2)

La ligne rouge du schéma 2 indique le flux de trafic du client sans fil.

Le serveur iPerf doit être aussi proche que possible du point de terminaison du trafic, idéalement branché sur le même commutateur que le WLC lui-même et utiliser le même VLAN.

Dans le cas de la commutation locale Flexconnect, le trafic client est terminé sur le point d'accès lui-même, et considérant que le serveur iPerf doit être configuré aussi près du point de terminaison du trafic client sans fil, branchez le serveur iPerf sur le même commutateur et le même VLAN où le point d'accès est branché.

Dans notre cas, il s'agit du commutateur d'accès (schéma 3).

(Schéma 3)

Les tests iPerf peuvent être divisés en deux catégories : amont et aval.

Étant donné que le serveur iPerf écoute et que le client iPerf génère le trafic, lorsque le serveur iPerf est du côté filaire, ceci est considéré comme un test en amont.

Le client sans fil utilise l'application iPerf pour transférer le trafic sur le réseau.

Le test en aval est l'inverse, ce qui signifie que le serveur iPerf est défini sur le client sans fil lui-même et que le client iPerf est du côté filaire, poussant le trafic vers le client sans fil. Dans ce scénario, ceci est considéré comme en aval.

Le test doit être effectué à l’aide des protocoles TCP et UDP. Vous pouvez utiliser ces commandes pour effectuer les tests suivants :

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

 

Exemple de résultats 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 :

Lors de l’utilisation du protocole UDP, il est important de s’assurer qu’il n’y a pas ou peu de perte de paquets. Il est possible de voir des nombres de débits très élevés, mais si vous avez une perte de paquets de 50 %, vous n'avez pas réellement transféré cette quantité de données.

Parfois, iPerf se comporte mal et ne donne pas la bande passante moyenne à la fin du test UDP.

Il est toujours possible de résumer la bande passante pour chaque seconde, puis de la diviser par nombre de secondes :

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

Remarque : les résultats iPerf devraient être légèrement meilleurs sur la commutation locale Flexconnect par rapport au scénario de commutation centrale.
Ceci est dû au fait que le trafic client est encapsulé dans CAPWAP, ce qui ajoute plus de surcharge au trafic et en général le WLC agit comme un goulot d'étranglement car il est le point d'agrégation pour tout le trafic des clients sans fil.
En outre, le test iPerf UDP devrait donner de meilleurs résultats dans un environnement propre, car il s'agit de la méthode de transfert la plus efficace lorsque la connexion est fiable. Cependant, TCP peut gagner en cas de fragmentation importante (lorsque TCP Adjust MSS est utilisé) ou de connexion non fiable

.

Vérifier et valider

La première étape consiste à vérifier la configuration actuelle du client. Sous Windows 11, accédez à Settings > Network & internet > Wi-Fi > Your_SSID_Name:

Paramètres Wi-Fi sur le client

Vous pouvez voir comment l'adresse IP est attribuée (dans ce cas, elle a été attribuée par le processus DHCP (Dynamic Host Configuration Protocol)), le protocole utilisé, la version du pilote, la bande réseau et le canal, et la vitesse de liaison. La vitesse de liaison est la vitesse théorique maximale entre le client et le point d'accès, ce qui signifie que la vitesse réelle peut être plus lente.

Mise en garde : Vérifiez si la version de votre pilote est la plus récente. Un pilote qui n'est pas à jour peut avoir un impact sur les performances/la vitesse du réseau.

Si vous n'atteignez pas les vitesses attendues, cela peut être dû au fait que votre client ne se connecte pas à la bande 6 GHz et ne reste connecté qu'aux autres bandes. Bien qu'ils soient équipés d'un adaptateur Wi-Fi 6E, certains ordinateurs portables nécessitent une mise à jour du BIOS pour activer les fonctionnalités 6 GHz. Cela dépend également du pays où l'essai a lieu : certains points d'accès d'infrastructure désactivent la bande 6 GHz dans certains pays où elle n'est pas encore autorisée et certains ordinateurs portables clients sont codés en dur pour ne pas utiliser la bande 6 GHz dans certains pays. Vérifiez votre point d'accès et le micrologiciel client pour obtenir des détails sur le pays avec lequel vous effectuez le test.

Afin de vérifier à quel débit de données le client est connecté, émettez ces commandes dans CLI 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

Vous pouvez voir que ce client particulier est connecté à ces débits :

Taux actuel....................................m10 ss2

Ce qui signifie que le client utilise l'index MCS 10 (m10) sur 2 flux spatiaux (ss2)

À partir de la commande « show wireless client mac <MAC> det », il n’est pas possible de voir si le client est connecté sur une liaison de canal 20/40/80 MHz.

Ceci peut être fait directement sur le point d'accès :

Exemple 9164 :

#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 dernière option pour vérifier le débit connecté est les captures OTA. Dans les informations radio du paquet de données, vous pouvez trouver les informations nécessaires :

 Cette capture OTA a été effectuée avec un client macbook 11ac.

Dépannage

Si vous n'obtenez pas les résultats escomptés pendant le test, il existe plusieurs façons de résoudre le problème et de collecter les informations nécessaires avant d'ouvrir un dossier TAC.

Les problèmes de débit peuvent être causés par les éléments suivants :

-Client

- AP

- Chemin filaire (problèmes liés à la commutation)

- WLC

Dépannage client

• La première étape consiste à mettre à jour les pilotes des périphériques clients sans fil vers la dernière version
• La deuxième étape consiste à effectuer le test iPerf avec des clients qui ont un adaptateur sans fil différent pour voir si vous obtenez les mêmes résultats

• Si la vidéo des téléconférences en ligne « gèle » ou si la qualité audio est mauvaise, configurez la QoS (qualité de service Wi-Fi). Les services qui reposent sur l'audio et la vidéo en temps réel, tels que la voix sur IP (VoIP), les jeux en ligne et la vidéoconférence d'entreprise, ont de fortes exigences en termes de latence et de gigue pour offrir une expérience de qualité. La QoS gère les problèmes d'encombrement et réduit la probabilité d'occurrence d'une collision et évite tout d'abord l'encombrement. Les applications en temps réel ne s'exploitent pas avec des débits élevés et ne doivent pas être comparées à des débits faibles dans un réseau. Ils concernent davantage la fiabilité de la livraison des paquets en temps réel.

  Déployez les paramètres QoS sur le WLC, avec les profils : Voix, Invité, Entreprise, Fastlane. Ces profils sont configurés sous le profil de stratégie. WLC fournit également quatre profils QoS préconfigurés : Platinum, Gold, Silver et Bronze (politiques QoS métal). Bronze pour le trafic de fond ou de moindre priorité, Silver pour le meilleur effort, Gold pour les applications vidéo, Platinum pour les applications vocales.

Dépannage AP

Il peut y avoir des scénarios où le point d'accès abandonne le trafic, ou certaines trames ou d'autres comportements inappropriés.

Afin d'obtenir plus d'informations à ce sujet, il y a besoin de captures OTA (Over The Air) + session span sur le port de commutation AP (span doit être fait sur le commutateur où le point d'accès est connecté)

Les captures OTA et SPAN doivent être effectuées pendant le test, en utilisant le SSID ouvert afin de pouvoir voir le trafic passé au point d'accès et le trafic AP passe vers le client et vice versa.

Il existe plusieurs bogues connus pour ce comportement :

CSCvg07438 : AP3800 : Faible débit dû aux pertes de paquets dans le point d’accès dans les paquets fragmentés et non fragmentés

CSCva58429 : AP Cisco 1532i : faible débit (commutation locale FlexConnect + EoGRE)

Dépannage des chemins câblés

Il peut y avoir des problèmes sur le commutateur lui-même, vous devez vérifier la quantité de chutes sur les interfaces et si celles-ci augmentent pendant les tests.

Essayez d'utiliser un autre port sur le commutateur pour connecter le point d'accès ou le WLC.

Une autre option consiste à brancher un client sur le même commutateur (auquel le point de terminaison client [AP/WLC] est connecté) et à le placer sur le même VLAN, puis à exécuter les tests câblés à câblés sur le même VLAN pour voir s'il y a des problèmes dans le chemin câblé.

Dépannage du WLC

Il se peut que le WLC abandonne le trafic (quand les AP sont en mode local) du client.

Vous pouvez mettre le point d'accès en mode Flexconnect et le WLAN en commutation locale, puis exécuter les tests.

Si vous voyez qu'il y a des différences significatives dans le débit en mode local (commutation centrale) par rapport à la commutation locale Flexconnect et qu'il n'y a aucun problème sur le commutateur connecté au WLC, alors très probablement le WLC abandonne le trafic.

Pour résoudre ce problème, appliquez le plan d'action :

- Captures SPAN sur le port de commutation WLC (doit être effectué sur le commutateur)

- Captures SPAN sur le port AP

- Captures OTA du client

En effectuant ce dépannage et en fournissant les résultats au TAC, cela accélère la procédure de dépannage.

Informations connexes

• Détails pour obtenir OTA avec MacBook
• Détails pour obtenir OTA avec AP en mode Sniffer
• Test IPERF pour mesurer le débit/la vitesse d’un client WLAN

• Calculateur de vitesse WLAN 802.11ax | Calculateur de débit 802.11ax

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

• Assistance technique de Cisco et téléchargements