Wi-Fi 6/6E en Wi-Fi 7 draadloze doorvoersnelheid valideren en testen

Inleiding

Dit document beschrijft de manier waarop de draadloze doorvoersnelheid van een access point kan worden getest met de focus op 802.11ax en welke doorvoersnelheid u kunt verwachten.

Voorwaarden

Vereisten

Voor dit document is de configuratie al actief met 802.11ax/Wi-Fi 6 access points (AP’s) die al clientconnectiviteit bieden

Gebruikte componenten

De informatie in dit document is gericht op 802.11ax/Wi-Fi 6 technologie en snelheden.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

De protocolevolutie begrijpen

Wi-Fi 6 kan op verschillende banden werken: 2.4GHz, 5GHz en zelfs de 6GHz band volgens de Wi-Fi 6E certificering.

802.11ac/Wi-Fi 5 kwam in twee golven. De tweede golf bracht de 160Mhz kanaalondersteuning, samen met MU-MIMO en een theoretisch maximum van 8 ruimtelijke stromen.

Deze getallen zijn alleen de theoretische getallen van de standaard, verschillen zijn van toepassing afhankelijk van het specifieke AP datasheet.

802.11ax/Wi-Fi 6 is niet direct gedefinieerd in gegevenssnelheden, maar is eerder een combinatie van 12 modulatie coderingsschema (MCS 0 tot MCS 11), een kanaalbreedte variërend van 20mhz (1 kanaal) tot 160Mhz (8 kanalen), een aantal ruimtelijke stromen (meestal 1 tot 2, zijn er ongeveer 3 ruimtelijke stromen producten maar ze worden minder en minder gezien).

Het korte, middellange of lange Guard Interval (GI) voegt hier ook een 10% wijziging aan toe.

Hier is een tabel om een data-rate in Mbps te evalueren bij het kennen van al die factoren:

Een completere tabel is te vinden op : https://mcsindex.com/

Opmerking: De gegevenssnelheid is NIET gelijk aan de verwachte haalbare doorvoersnelheid. Dit is gerelateerd aan de aard van 802.11 standaard die veel administratieve overheadkosten heeft (managementframes, geschil, botsing, bevestigingen,...) en het kan afhangen van de koppeling SNR, RSSI en andere belangrijke factoren.

U kunt de doorvoersnelheid berekenen met behulp van deze vergelijking die wordt gebruikt voor de 802.11ax-snelheid of de gegevenssnelheid:

Vergelijking gebruikt voor 802.11ax snelheid of gegevenssnelheid

Het is een vuistregel:

Verwachte doorvoersnelheid = gegevenssnelheid x 0,7

Neem een voorbeeld uit het echte leven. Een Cisco 9120 AP met een moderne Wi-Fi 6-compatibele smartphone die 2 Spatial Streams kan verwerken. Als we in een omgeving met hoge dichtheid zijn waar 20 MHz kanalen worden gebruikt, is de maximale gegevenssnelheid tussen 240 en 280 Mbps afhankelijk van het wachtinterval. Dit betekent dat, in een schone omgeving en testomstandigheden, we kunnen hebben een klant die gegevens overdraagt tussen 160 tot 200 Mbps mogelijk (65 tot 70% van de protocol efficiëntie). Dit is alleen geldig bij een eigenlijke grote overdracht of snelheidstest waarbij het protocol geoptimaliseerd is voor maximale doorvoersnelheid. Wanneer het gebruiken van andere toepassingen, gaat de productie omlaag aangezien de latentie ook een rol in protocollen speelt die een ping-pong van pakketten doen en op erkenning wachten alvorens zich voorwaarts te bewegen.

Let ook op dat de draadloze verbinding een gedeelde omgeving is, dit betekent dat de hoeveelheid clients die zijn aangesloten op de AP de effectieve doorvoersnelheid tussen elkaar delen. Als een client die een snelheidstest doet tussen 160 en 200MBps kan bereiken, betekent dit dat twee clients die een snelheidstest doen tegelijkertijd elke 80 tot 100Mbps zien. Als vier clients tegelijkertijd een snelheidstest uitvoeren, zien ze 40 tot 50 Mbps elk en zo ...

Bovendien betekenen meer klanten meer conflicten en onvermijdelijk meer botsingen. De efficiëntie van de dekkingcel neemt drastisch af naarmate het aantal klanten toeneemt. Het is daarom niet realistisch om enige vorm van SLA voor doorvoersnelheid in te stellen op plaatsen waar u niet de hoeveelheid verbonden cliënten controleert of wat zij op het netwerk in termen van activiteit doen.

Wi-Fi 7

Wi-Fi 7 brengt veel protocolverbeteringen die de waargenomen doorvoersnelheid beter zullen maken. Echter, de maximale snelheden worden meestal verbeterd door de toevoeging van MCS 12 en 13 datasnelheid (die vereist om zeer dicht bij het toegangspunt te zijn) evenals de toevoeging van 320Mhz kanaalbreedte (wat misschien niet realistisch is om te gebruiken in een bedrijfssetting als het bundelt veel kanalen samen). Het verandert niet veel aan de testmethodologie die in dit document wordt uitgelegd.

Multi-Link Operation (MLO) is een andere verbetering van Wi-Fi 7 die vaak wordt gebruikt om op grote potentiële gegevenssnelheden te bogen. In real-life, zullen de meeste cliënten op verscheidene banden met MLO verbinden maar zullen meestal één enkele band gebruiken (om batterijduur te besparen). De 5 en 6GHz banden zijn ook moeilijk om gelijktijdig te gebruiken vanwege de interferenties die de radio's voor elkaar veroorzaken. Controleer hoe uw client is verbonden om te anticiperen op de snelheden die redelijkerwijs kunnen worden bereikt.

Meetlat

Over het algemeen, kunnen wij twee scenario's hebben wanneer u een productietest doet:

• AP's zijn opgenomen in Flexconnect local switching

• AP's zijn in de lokale modus of Flexconnect central switching

Neem deze scenario's een voor een:

(Afbeelding 1)

In het geval van Diagram 1 veronderstellen we dat de AP's in de lokale modus van Flexconnect centrale switching zijn.

Dit betekent dat al het clientverkeer is ingekapseld in CAPWAP-tunnels en wordt afgesloten met de WLC.

(Afbeelding 2)

De rode lijn in Diagram 2 toont de verkeersstroom van de draadloze client.

De iPerf-server moet zo dicht mogelijk bij het stoppunt van het verkeer staan, idealiter in dezelfde switch als de WLC zelf worden aangesloten en hetzelfde VLAN gebruiken.

In het geval van lokale switching voor Flexconnect wordt het clientverkeer op het toegangspunt zelf beëindigd. Hierbij wordt er rekening mee gehouden dat de iPerf-server zo dicht mogelijk bij het afsluitpunt van het draadloze clientverkeer moet worden ingesteld, en steek de iPerf-server in dezelfde switch en hetzelfde VLAN waar het toegangspunt is aangesloten.

In ons geval is dit access switch (Afbeelding 3).

(Afbeelding 3)

De iPerf-tests kunnen in twee categorieën worden onderverdeeld: upstream en downstream.

Gezien het feit dat de iPerf-server luistert en iPerf-client het verkeer genereert, wordt dit, wanneer de iPerf-server zich aan de bekabelde kant bevindt, beschouwd als een upstream-test.

De draadloze client gebruikt de iPerf-toepassing om het verkeer naar het netwerk te duwen.

De stroomafwaartse test is omgekeerd, wat betekent dat de iPerf-server is ingesteld op de draadloze client zelf en dat de iPerf-client aan de bekabelde kant het verkeer naar de draadloze client duwt, in dit scenario wordt dit als stroomafwaarts beschouwd.

De test moet worden uitgevoerd met TCP en UDP. U kunt deze opdrachten gebruiken om de tests uit te voeren:

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

 

Voorbeeld van iPerf3-uitgangen:

TCP-perf3:

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

Wanneer het gebruiken van UDP, is het belangrijk om ervoor te zorgen er niet aan weinig pakketverlies. Het is mogelijk om zeer hoge doorvoernummers te zien, maar als je een pakketverlies van 50% hebt, heb je die hoeveelheid gegevens niet daadwerkelijk overgedragen.

Soms gedraagt iPerf zich niet en geeft hij niet de gemiddelde bandbreedte aan het eind van de UDP-test.

Het is nog steeds mogelijk om de bandbreedte voor elke seconde op te tellen en deze vervolgens te delen door het aantal seconden:

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

Opmerking: verwacht wordt dat de resultaten van iPerf op de lokale overschakeling van Flexconnect iets beter zijn dan bij het centrale overschakelingsscenario.
Dit wordt veroorzaakt door het feit dat het cliëntverkeer in CAPWAP wordt ingekapseld, dat meer overheadkosten aan het verkeer toevoegt en in het algemeen werkt WLC als knelpunt aangezien het het samenvoegingspunt voor al draadloos cliëntverkeer is.
Bovendien wordt verwacht dat de UDP iPerf-test betere resultaten oplevert in een schone omgeving, aangezien het de meest efficiënte overdrachtmethode is wanneer de verbinding betrouwbaar is. TCP kan echter winnen in geval van zware fragmentatie (wanneer TCP MSS wordt gebruikt) of onbetrouwbare verbinding

.

Verifiëren en valideren

De eerste stap is het verifiëren van de huidige cliëntconfiguratie. Ga in Windows 11 naar Settings > Network & internet > Wi-Fi > Your_SSID_Name:

Wi-Fi-instellingen op de client

U kunt zien hoe het IP-adres wordt toegewezen (in dit geval via het Dynamic Host Configuration Protocol (DHCP)-proces), het gebruikte protocol, de driver-versie, de netwerkband en het kanaal en de koppelingssnelheid. De koppelingssnelheid is de maximale theoretische snelheid tussen de client en AP, wat betekent dat de werkelijke snelheid langzamer kan zijn.

Voorzichtig: Controleer of de versie van het stuurprogramma de laatste versie bevat. Een stuurprogramma dat niet up-to-date is, kan de prestaties/snelheid van het netwerk beïnvloeden.

Als u niet de verwachte snelheden bereikt, kan dit zijn omdat uw client geen verbinding maakt met de 6GHz band en alleen met de andere banden blijft plakken. Ondanks dat er een Wi-Fi 6E adapter is, hebben sommige notebooks een BIOS update nodig om de 6 GHz mogelijkheden ingeschakeld te krijgen. Het hangt ook af van het land waar de test plaatsvindt: sommige infrastructuur AP's uitschakelen 6GHz in sommige landen waar het nog niet is toegestaan en sommige client-laptops zijn hardgecodeerd om 6GHz niet te gebruiken in bepaalde landen. Controleer zowel het toegangspunt als de firmware van de client voor meer informatie over het land waarmee u probeert.

Om te controleren bij welke gegevenssnelheid de client is aangesloten, geeft u deze opdracht in WLC CLI uit:

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

U kunt zien dat deze bepaalde client is aangesloten op deze snelheid:

Huidige koers..................................... m10 ss2

Dit betekent dat de client de MCS 10 (m10) index gebruikt op 2 ruimtelijke stromen (ss2)

Van de "show wireless client mac <MAC> det" opdracht, is het niet mogelijk om te zien of de client is verbonden op 20/40/80 MHz kanaal bonding.

Dit kan direct op het toegangspunt worden gedaan:

9164 voorbeeld:

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

De laatste optie om de aangesloten snelheid te controleren is OTA vangt. In de radioinformatie van het gegevenspakket kunt u de benodigde informatie vinden:

 Deze OTA-opname werd genomen met een 11ac macbook-client.

Problemen oplossen

Als u tijdens de test geen verwachte resultaten krijgt, zijn er verschillende manieren om het probleem op te lossen en de benodigde informatie te verzamelen voordat u een TAC-case opent.

De doorvoerproblemen kunnen door deze factoren worden veroorzaakt:

-Klant

- AP

- bekabeld pad (switching gerelateerde problemen)

- WLC

Probleemoplossing voor clients

• De eerste stap is het updaten van de stuurprogramma's op de draadloze clientapparaten naar de nieuwste versie
• De tweede stap is het doen van de iPerf test met cliënten die een verschillende draadloze adapter hebben om te zien of krijgt u de zelfde resultaten

• Als online vergaderingen video 'bevriest' of de audio heeft slechte kwaliteit, configureer QoS (Wi-Fi Quality of Service). Diensten die afhankelijk zijn van real-time audio en video, zoals Voice-over-IP (VoIP), online gamen, bedrijfsvideoconferencing hebben sterke eisen in termen van latentie en jitter om een kwaliteitservaring te leveren. QoS beheert congestieproblemen en vermindert de waarschijnlijkheid van het voorkomen van een botsing en vermijdt in de eerste plaats congestie. De real-time toepassingen maken geen gebruik van hoge doorvoersnelheden en kunnen niet worden vergeleken met lage snelheden in een netwerk. Zij hebben meer op betrouwbaarheid van pakketlevering in real time betrekking.

  Implementeer de QoS-instellingen op de WLC, met de profielen: Stem, Gast, Onderneming, Fastlane. Deze profielen worden geconfigureerd onder het beleidsprofiel. WLC biedt ook vier vooraf geconfigureerde QoS-profielen: Platina, Goud, Zilver en Brons (metalen QoS-beleid). Brons voor achtergrond of verkeer met de laagste prioriteit, Zilver voor de beste inspanning, Goud voor videotoepassingen, Platinum voor spraaktoepassingen.

Probleemoplossing AP

Er kunnen scenario's zijn wanneer het toegangspunt verkeer laat vallen, of bepaalde frames of anderszins zich misdraagt.

Om hier meer inzicht in te krijgen, zijn er nood aan Over The Air (OTA) neemt + span sessie op de AP switchport (span moet worden gedaan op de switch waar de AP is aangesloten)

OTA vangt en SPAN moet tijdens de test worden gedaan, die open SSID gebruiken om het verkeer te kunnen zien dat tot AP wordt overgegaan en AP van het verkeer is dat naar de cliënt overgaat en vice versa.

Er zijn verschillende bekende bugs voor dit gedrag:

CSCvg07438 : AP380 Lage doorvoersnelheid dankzij pakketdalingen in AP in zowel gefragmenteerde als niet-gefragmenteerde pakketten

CSCva58429 : Cisco 1532i access point: lage doorvoersnelheid (FlexConnect Local Switching + EoGRE)

Probleemoplossing voor bekabeld pad

Er kunnen enkele problemen zijn op de switch zelf, moet u controleren hoeveel druppels op de interfaces en als die tijdens de tests toenemen.

Probeer een andere poort op de switch te gebruiken om de AP of WLC aan te sluiten.

Een andere optie is om een client in te pluggen op dezelfde switch (waar het client-afsluitpunt [AP/WLC] is aangesloten) en deze op hetzelfde VLAN te plaatsen, en vervolgens de tests uit te voeren die zijn bekabeld om op hetzelfde VLAN te worden bedrad om te zien of er problemen zijn met het bekabelde pad.

WLC-probleemoplossing

Het kan zijn dat de WLC het verkeer (wanneer AP's in lokale modus zijn) van de client laat vallen.

U kunt het toegangspunt in de Flexconnect-modus zetten en het WLAN in lokale switching plaatsen, en vervolgens de tests uitvoeren.

Als u ziet dat er significante verschillen zijn in de doorvoersnelheid in de lokale modus (centrale switching) in vergelijking met Flexconnect lokale switching en er is geen probleem op de switch die is aangesloten op WLC, dan is de WLC zeer waarschijnlijk het verkeer aan het laten vallen.

Om dit op te lossen, pas het actieplan toe:

- SPAN neemt op de WLC-switchpoort op (dit moet op de switch gebeuren)

- SPAN neemt op de AP poort op

- OTA van de klant

Door deze probleemoplossing uit te voeren en de resultaten aan TAC te leveren, versnelt dit het proces voor probleemoplossing.

Gerelateerde informatie

• Details om OTA te krijgen met MacBook
• Details om OTA met AP in Sniffer modus te krijgen
• IPERF-test om de doorvoersnelheid/snelheid van een WLAN-client te meten

• WLAN 802.11x-snelheidscalculator | 802.11Berekening van het belastingtarief

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

• Cisco Technical Support en downloads