驗證和測試Wi-Fi 6/6E和Wi-Fi 7無線吞吐量

簡介

本文件說明如何測試以 802.11ax 為主的存取點無線輸送量，以及如何測量預期的輸送量。

必要條件

需求

本文件假設 802.11ax/Wi-Fi 6 存取點 (AP) 已完成設定，並已正常運作，可為用戶端提供連線。

採用元件

本文件中的資訊將著重探討 802.11ax/Wi-Fi 6 技術和速度。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

瞭解協定的演變

Wi-Fi 6可以在多個頻段上運行：2.4Ghz、5Ghz甚至6Ghz頻段符合Wi-Fi 6E認證。

802.11ac/Wi-Fi 5產生兩波訊號。第二個波帶來了160Mhz的通道支援，以及MU-MIMO和理論上的最多8個空間流。

這些數字只是標準中的理論數字，根據特定的AP資料表而有所不同。

802.11ax/Wi-Fi 6並不直接在資料速率中定義，而是12個調制編碼方案（MCS 0到MCS 11）、範圍從20mhz（1個通道）到160Mhz（8個通道）的通道寬度的組合，以及多個空間流（通常為1到2，存在大約3個空間流產品，但是它們被看到的越來越少）。

短、中或長保護間隔(GI)也增加了大約10%的修改。

下面是一個表，在瞭解所有這些因素時以Mbps為單位評估資料速率：

更完整的表位於：https://mcsindex.com/

附註：資料速率不等於預期的可實現吞吐量。這與 802.11 標準具有許多管理負擔（管理訊框、競爭、衝突、確認...等等）的特性有關，而且可能取決於連結 SNR、RSSI 及其他重要因素。

您可以使用用於802.11ax速度或資料速率的等式計算吞吐量：

802.11ax速度或資料速率使用的等式

根據實務經驗歸納而得的估算方法：

預期傳輸量=資料速率x 0.7

以現實生活為例。Cisco 9120 AP 搭配支援 Wi-Fi 6 和 2 個空間串流的現代智慧型手機。如果在使用20 Mhz通道的高密度環境中，則使用的最大資料速率介於240和280 Mbps之間，具體取決於保護間隔。換句話說，在乾淨的環境和測試條件下，用戶端或許能以 160 到 200 Mbps 的速度傳輸資料（通訊協定效率為 65 到 70%）。 唯有實際進行大型傳輸或速度測試才能得知確切速度，而且在測試中，通訊協定必須針對最大資料輸送量完成最佳化。使用其他應用時，吞吐量會下降，因為延遲在協定中也會發揮作用，這些協定會執行資料包的乒乓操作並等待確認，然後繼續前進。

另外還要注意，無線是共用環境，這意味著連線到AP的客戶端數量在彼此之間共用有效吞吐量。如果單一用戶端接受測試時，速度可達到 160 至 200 Mbps，表示兩個用戶端同時進行速度測試時，每個用戶端可達到 80 至 100 Mbps。如果四個客戶端同時執行速度測試，則它們會看到40到50Mbps的速度，等等……

此外，更多的客戶端意味著更多的爭用和不可避免的更多的衝突。基地台效率會隨著用戶端數量增加而大幅降低，因此，如果您不控制連線的客戶端數量或它們在網路中執行的活動，則設定任何型別的SLA來提供吞吐量是不現實的。

Wi-Fi 7

Wi-Fi 7帶來了許多協定改進，這將使觀察到的吞吐量更好。然而，最大速度主要通過新增MCS 12和13資料速率（雖然這要求非常接近接入點）以及新增320Mhz通道寬度（在企業設定中使用可能是不現實的，因為它將許多通道捆綁在一起）來提高。 對於本文檔中介紹的測試方法，它沒有太大的變化。

多鏈路操作(MLO)是Wi-Fi 7的另一種改進，通常用於誇大潛在的資料速率。在現實生活中，大多數客戶端會通過MLO連線多個頻段，但大多數情況下會使用單個頻段（以節省電池壽命）。 5和6GHz頻段也難以同時使用，因為無線電對彼此造成干擾。驗證客戶端的連線方式，以便預測其可合理達到的速度。

測量

一般來說，測試輸送量會有兩種情況：

• AP 處於 FlexConnect 本機交換模式

• AP 處於本機模式或 Flexconnect 中央交換模式

以下逐一說明：

（圖 1）

在圖 1 中，我們假設 AP 處於本機模式或 Flexconnect 中央交換模式。

也就是說，所有用戶端流量都會封裝到 CAPWAP 通道並於 WLC 上終止。

（圖 2）

圖 2 中的紅線表示來自無線用戶端的流量。

iPerf 伺服器必須盡可能靠近流量終止點，最好與 WLC 連接相同的交換器，並使用相同的 VLAN。

在 Flexconnect 本機交換模式的案例中，用戶端流量終止於 AP 本身，加上 iPerf 伺服器必須安裝在靠近無線用戶端流量終止點的位置，因此請將 iPerf 伺服器連接到 AP 所接上的相同交換器及相同 VLAN。

在我們的案例中，此為存取交換器（圖 3）。

（圖 3）

iPerf測試可細分為兩類：上游和下游。

假設 iPerf 伺服器正在偵聽，而 iPerf 用戶端產生流量，當 iPerf 伺服器位於有線端時，這種測試稱為上行測試。

無線客戶端使用iPerf應用將流量推入網路。

下游測試反之亦然，這表示iPerf伺服器設定在無線使用者端本身，而iPerf使用者端是在有線端將流量推送到無線使用者端，在此案例中，這視為下游。

執行測試必須使用 TCP 和 UDP。可以使用以下命令執行測試：

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

 

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：

使用 UDP 時，請務必確保沒有或僅有少數封包遺失。即便顯示的輸送量數據很高，但如果封包遺失率為 50%，則實際上並未傳輸這麼多的資料量。

iPerf 有時確實會出現異常行為，而且在 UDP 測試結束時也不會提供平均頻寬。

不過，您仍然可以加總每秒頻寬，然後除以秒數：

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

備註：Flexconnect 本機交換模式下的 iPerf 結果預期會稍微優於中央交換模式。
這是因為客戶端流量被封裝到CAPWAP中，這增加了流量的額外開銷，而且一般來說，WLC會成為瓶頸，因為它是所有無線客戶端流量的聚合點。
此外，UDP iPerf測試預計在清潔環境中能提供更好的結果，因為它是連線可靠時最有效的傳輸方法。不過，如果網路嚴重分段（使用 TCP Adjust MSS 時）或連線不穩，TCP 就會是較好的選擇。

.

確認及驗證

第一步是驗證當前的客戶端配置。在Windows 11上，導航到Settings > Network & internet > Wi-Fi > Your_SSID_Name:

客戶端上的Wi-Fi設定

您可以看到如何分配IP地址(本例中通過動態主機配置協定(Dynamic Host Configuration Protocol, DHCP)進程分配)正在使用的協定、驅動程式版本、網路頻寬和通道以及鏈路速度。鏈路速度是客戶端和AP之間的最大理論速度，這意味著實際速度可能較慢。

注意：驗證您的驅動程式版本是否處於最新版本。未更新的驅動程式可能會影響網路效能/速度。

如果您沒有達到預期的速度，則可能是由於您的客戶端沒有連線到6GHz頻段，並且僅與其他頻段保持連線。儘管有Wi-Fi 6E介面卡，但有些筆記型電腦需要BIOS更新才能啟用6Ghz功能。這還取決於測試所在的國家：某些基礎設施AP在某些國家/地區禁用了6GHz，在這些國家/地區，某些客戶端筆記型電腦被硬編碼為在特定國家/地區不使用6GHz。檢查您的AP和客戶端韌體，以瞭解有關測試的具體國家/地區的詳細資訊。

若要查看用戶端連線時的資料傳輸速率，請在 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

您可以看到此特定使用者端已按以下速率連線：

當前速率…….................................. m10 ss2

這表示使用者端正在兩個空間流(ss2)上使用MCS 10(m10)索引

透過「show wireless client mac <MAC> det」命令，您無法確認用戶端是否採用 20/40/80 MHz 通道匯整技術進行連線。

這可以直接在AP上完成：

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

最後一個檢查連線速率的選項是OTA捕獲。在資料包的無線電資訊中，可以找到必要的資訊：

 OTA 擷取作業是透過 11ac MacBook 用戶端執行。

疑難排解

如果在測試期間沒有得到預期的結果，有幾種方法可以在開啟TAC案例之前解決問題並收集必要的資訊。

問題可能是由以下原因引起的：

- 用戶端

- AP

- 有線路徑（與交換相關的問題）

- WLC

客戶端故障排除

• 第一步是將無線客戶端裝置上的驅動程式更新為最新版本
• 第二步是對具有不同無線介面卡的客戶端執行iPerf測試，以檢視您是否獲得相同結果

• 如果線上會議影片「凍結」或音訊品質不好，請配置QoS（Wi-Fi服務品質）。 依賴即時音訊和影片的服務(例如IP語音(VoIP)、線上遊戲和企業視訊會議)對延遲和抖動有著強烈的要求以提供優質體驗。QoS管理擁塞問題，降低發生衝突的概率，並首先避免擁塞。即時應用不會利用高吞吐量，並且不會與網路中的低速度進行比較。它們更多的是與資料包即時傳輸的可靠性有關。

  使用配置檔案在WLC上部署QoS設定：語音、訪客、企業、Fastlane。這些配置檔案在策略配置檔案下配置。WLC還提供四個預配置的QoS配置檔案：白金、金牌、銀牌和銅牌（金屬QoS策略）。 青銅級用於後台或最低優先順序流量，銀級用於最大努力，金級用於影片應用，白金級用於語音應用。

AP 疑難排解

AP 可能捨棄流量或特定訊框，或出現其他異常行為。

為了更深入瞭解這一點，需要在AP交換器連線埠上執行空中傳輸(OTA)擷取+ span作業階段（必須在AP所連線的交換器上執行span）

在測試過程中，必須使用開放式SSID完成OTA捕獲和SPAN，以便能夠檢視傳遞到AP的流量和AP正在傳遞至客戶端的流量，反之亦然。

此行為具有幾個已知錯誤：

CSCvg07438:AP3800:由於分段和非分段資料包中的AP中的資料包丟棄導致吞吐量低

CSCva58429:Cisco 1532i AP:低吞吐量（FlexConnect本地交換+ EoGRE）

有線路徑故障排除

交換器本身可能有一些問題，您必須在介面上檢查捨棄數量，並觀察數量是否會在測試期間增加。

嘗試使用交換器上的其他連接埠來連接 AP 或 WLC。

另一種方法是，將使用者端連線到同一個交換器（使用者端終端點[AP/WLC]連線到該交換器）並將其放在同一個VLAN中，然後對同一個VLAN上的有線電纜運行測試，檢視有線路徑中是否存在任何問題。

WLC 疑難排解

WLC 可能捨棄來自用戶端的流量（AP 處於本機模式時）。

您可以將 AP 調整到 Flexconnect 模式，並讓 WLAN 處於本機交換模式，再執行測試。

如果您比對 Flexconnect 本機交換模式的輸送量，發現本機模式（中央交換模式）的傳輸量出現明顯落差，而且連接 WLC 的交換器沒有任何問題，那很有可能是 WLC 會捨棄流量。

若要排除此問題，請執行以下操作：

- WLC交換器連線埠上的SPAN擷取（必須在交換器上完成）

- AP埠上的SPAN捕獲

- 在用戶端執行 OTA 擷取

執行以上疑難排解程序並向 TAC 提供結果可加速排除問題。

相關資訊

• 使用MacBook獲取OTA的詳細資訊
• 在監聽器模式下通過AP獲取OTA的詳細資訊
• 用於測量WLAN客戶端吞吐量/速度的IPERF測試

• WLAN 802.11ax速度計算器 | 802.11ax資料速率計算器

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

• 思科技術支援與下載