中程 802.11ac 存取點的用戶端密度與視訊效能比較ruckus- · pdf file雖然...

WiFi 諮詢與設計服務 WiFi 教育 WiFi 診斷與最佳化

中程 802.11ac 存取點的用戶端密度與視訊效能比較

Devin K. Akin，執行長

[email protected]

2017 年 9 月

第 1.00 版

2

105 Muirfield Way Carrollton, GA 30116 USA [email protected] +1.404.437.6006 http://DivDyn.com

執行概覽

本文件會詳述在高用戶端密度環境下，且以視訊當作主要資料流量類型，多個供應商的

802.11ac Wave 2 存取點 (AP) 效能表現如何。過去的競爭測試傾向著重於彙總資料輸送量，

並採用檔案傳輸作為在 AP 上建立負載的方式。納入視訊的最新公開壓力測試，應是於

2013 年發表。

在這個測試套件中，選擇了視訊流量作為主要資料載入，最顯而易見的原因，就是視訊

主宰了當今眾多網路的資料流量。根據最新的思科視覺化網路指數 (Cisco Visual

Networking Index)1：

• 2016 年至 2021 年，全球 IP 視訊流量會成長三倍，相當於 26% 的 CAGR。

而 2016 年至 2021 年，網際網路視訊流量會成長四倍，相當於 31% 的 CAGR。

• 2016 年至 2021 年，商用 IP 流量會以 21% 的 CAGR 成長。企業部門對於進階視

訊通訊的採用日益增加，造成 2016 年至 2021 年期間，商用 IP 流量將成長 3 倍。

根據最新的愛立信行動趨勢報告 (Ericsson Mobility Report)2：

• 報告中預測指出，在 2022 年以前，行動視訊流量會以年約 50% 的速度成長，佔

有全部行動資料流量中近四分之三的份額

• 平板電腦的行動資料視訊流量已在 2016 下半年獲取近 60% 的份額

相較於其他多數資料應用 (例如電子郵件、檔案傳輸、瀏覽網頁等)，視訊除了高度的頻

寬消耗，最大的不同在於對終端使用者體驗品質的影響。使用者可能不會注意到或在意

下載電子郵件附件時必須花費多一點時間，卻會立刻注意到影片停頓的情形。當使用者

處於高度用戶端密度環境 (在本測試套件中定義為 60 個用戶端) 中，體驗到低落的視訊品

質 (停頓) 的可能性便會增加。

總的來說，本次測試集合是設計用來對 AP 施加壓力，採用視訊流量與高度用戶端密度

的組合，這兩者是目前無線區域網路環境中最普遍的情況。Ruckus 的技術團隊取得測試

場所與設備，並執行本文件中描述的所有測試。作者親自見證並驗證所有測試設備、軟

體、設定與結果。設施內的實體 AP 與用戶端設定皆符合實際情況，並採用最佳實務的

設計參數。在這項經過驗證的設定中，所有供應商都位於平等的基礎上。

關於作者

Devin Akin 為 CWNP 的共同創辦人，CWNP 提供全球標準、供應商中立的訓練與認證。

Devin (CWNE #1) 在 IT 產業已有超過 20 年的經驗，其中投入於無線區域網路超過 15 年。

他也是 Divergent Dynamics 的創辦人與 CEO，這家公司為 WiFi 系統整合商與訓練機構，

專精於 WiFi 創新設計、驗證與效能解決方案。

1 思科視覺化網路指數：全球行動數據流量預測更新，2016–2021 年白皮書 2 愛立信行動趨勢報告，2017 年 6 月

3


測試內容為何？

本報告說明了專為測量在視訊流量負載下之 AP 效能的一系列測試。我們選用中程

802.11ac Wave 2 3x3:3 AP，以反映現實環境中可能的部署方式。若該製造商無法提供

3x3:3 AP 機型，則會選用次高階的機型。

我們選用具備 2x2:2 802.11ac 無線規格的 Chromebook，因為其價格實惠，且可充當在許

多無線區域網路環境中採用的各式短程至中程無線裝置。而 12 年義務的教育體系則廣泛

採用 Chromebook，讓本測試套件特別適切這種環境。

Apple Mac Mini 則是用來在視訊測試期間，以非視訊資料流量增加網路負載。

這份測試為何重要？

視訊流量佔有大部分的資料流量，且相較於其他多數的資料流量類型，若承載的網路效

能不彰，更可能顯著影響終端使用者體驗。因此，無線區域網路確保視訊服務品質的能

力，對於所有類型的組織機構是最基本的要求。

有了穩健的服務品質 (QoS) 機制為基礎，才能提供可靠一致的應用。這樣的 QoS 控制對

於任何組織機構都是至關重要的，不論是企業、教育，乃至於任何規模的垂直式企業。

對於物連網 (IoT) 裝置的爆炸性發展來說，服務品質亦非常關鍵。許多 IoT 裝置透過

Bacnet (一種 UDP 通訊協定) 彼此通訊，具有與視訊及語音裝置類似的效能目標 (時間/延

遲敏感)。

測試環境

我們在加州 Union 市的一所中學中，利用兩間相鄰的教室進行測試。我們選擇此處的主

要原因，在於此地點為閒置空間，且擁有不用干擾的無線電頻率 (RF) 環境。

我們安裝了各製造商的無線區域網路設備，並以單一 SSID 設定，來承載影像與資料流量。

每項測試 AP 會安裝在其中一間房間，且不會位於分隔兩間房間的牆上，而是其對面的

牆上。

4


受測 Access Point

下列為用於此次測試的硬體與韌體。

廠商 AP/控制器軟體版本 MIMO 類型

Ruckus R610 搭配 SZ100 3.5.0.0.832 3x3:3 11ac

阿路巴 AP-305 搭配 7205 6.5.1.2 3x3:3 11ac

Aerohive AP250 HiveOS 8.0r1 build-161337 3x3:3 11ac

Meraki MR42 雲端 3x3:3 11ac

Cisco 1850i 搭配 5508 8.3.102.0 4x4:4 11ac

圖 1：受測的 AP 機型

測試方法

無線區域網路設定

所有測試皆以 5 Ghz 頻段進行，此頻段是業界推薦，用於高密度環境的最佳實務。所有

用戶端都會透過單一 SSID (受一組 PSK 保護，採用 40 Mhz 寬的頻道) 連線到無線區域網

路。雖然 802.11ac 在使用 80 Mhz 寬頻道時可以支援更高的資料速率，但出於頻道爭用與

頻道再使用不彰等原因，不建議在高密度環境中使用如此巨大的頻寬。

為了避免 AP 在測試期間變更頻道，每部 AP 皆手動指派為某個 149 以上的頻道。我們掃

描了整個頻譜，確保沒有其他裝置使用該頻道。

由於其中一部 AP (Aerohive AP250) 支援設定第二組 5 Ghz 射頻 (即雙 5 Ghz 無線電模式)，

AP250 會接受兩次測試，一次為啟用單 5 Ghz 射頻，第二次為啟用雙 5 Ghz 射頻。依製

造商建議，第一和第二射頻間隔 80 MHz。第一射頻設定使用第 40 頻道，第二射頻使用

第 149 頻道。

乙太網路交換器設定

我們採用 Ruckus ICX 7150 交換器來建置有線基礎架構。所有裝置都會使用 Layer 2 虛擬

區域網路，以連接到 gigabit 乙太網路連接埠。

視訊設定

採用六個 Microsoft Windows 媒體伺服器，以提供各 Chromebook 用戶端 1.6 Mbps 單點傳

送 TCP 的視訊串流。視訊皆以 Chrome 瀏覽器的「無痕」模式播放，以避免快取。此視

訊不會循環播放，並於每次測試時重新開始。所有的視訊流量皆以有線交換器上的

DSCP 40 標示。

5


加入資料載入前，所有的用戶端會有一分鐘的時間來播放視訊，並計算停頓次數。由於

視訊停頓的情形一瞬即逝，因此我們採用保守的方法來定義視訊停頓。若要計為停頓，

必須是視訊沒有開始，或在各測試階段結束時處於停頓狀態。

我們將 Mac Mini 用戶端設定為 Ixia Chariot 7.3 EA 端點 (各組一個)，只要視訊用戶端開

始播放，非視訊資料流量便會加入無線區域網路中，為時一分鐘。我們會加入足夠的網

路負載，以觸發不同流量類別 (即視訊和資料) 競爭可用頻寬。為了獲得精準的控制並建

立一致的資料載入，我們選擇的資料流量型式為 UDP。

若發生視訊沒有立即開始播放的情形，會重測第二次。如果仍無法開始，就會視為停頓，

且計為初始停頓 (無網路負載的支援視訊用戶端) 和網路負載期間的停頓用戶端數量 (假

設停頓情形持續)。

在為時一分鐘的資料載入執行期間結束後，會以相同的停頓標準，再次計算發生停頓情

形的視訊用戶端數量。資料用戶端 (Mac Mini) 的最終彙總輸送量即為 Chariot3

報告的數值。

客戶端

採用 60 部 2x2:2 Chromebook，以及 30 部 Mac Mini 用戶端。兩項測試 (於下方說明) 的用

戶端數量與組成有所不同。

3 Chariot 指令碼係用於標準效能測試，此指令碼停用 UDP_RFC768。這是依據 Ixia 對於 UDP 輸送量測試的建議。

6


圖 2：測試平台的網路拓撲

測試 1：30 個視訊用戶端和 30 個資料用戶端

目標

藉由測量加入資料載入前後，AP 支援的同時視訊播放次數差異，來確定在相鄰房間加入

30 個純資料用戶端，對主房間之 30 部 Chromebook 用戶端的視訊品質有何影響。

說明

30 部 Chromebook 上的視訊串流會手動啟動。所有的視訊開始播放一分鐘後，資料會推

送至隔壁房間內的 30 個 Mac Mini 用戶端上。未發生視訊停頓的用戶端數量以及與純資

料用戶端關聯的彙總資料輸送量都會記錄下來。各項測試亦會記錄先前發生停頓，而在

網路負載停止後重新開始的視訊次數。每測試各執行三次。

成功標準

AP 須在網路負載之前和期間順利將無停頓視訊傳送至全部的 30 個用戶端，且能同時傳

送資料至純資料用戶端。若視訊在負載情形下發生停頓，視訊應在移除負載後重新開始。

這樣的做法可以顯示在網路負載之前、期間和之後是否有一致的表現。我們沒有為彙總

資料輸送量訂定絕對的成功標準值。

7


圖 3：同時在 Chromebook (30 個用戶端) 進行視訊串流以及 Mac Mini 上 (30 個用戶端) 進行資料下載

結果

所有的受測 AP 皆能在網路未負載、僅傳送視訊流量的情況下，成功伺服 30 個視訊串流

用戶端。加入資料載入後，大部分的 AP 無法支援所有的視訊串流。如下圖所示 (圖 4)，

未發生停頓的視訊連線數量從 30 個用戶端 (最佳) 到 0 個用戶端 (最差) 都有。

圖中顯示的所有結果為三次測試的中位數。

圖 4：測試 1 在有負載的情形下未發生視訊停頓的結果

8


由於網路負載會隨時間波動，若能量測移除負載後網路的恢復情形，就能進行更深入的

效能分析。下表顯示套用資料載入之前、期間和之後，未發生視訊停頓的次數。

圖 5：測試 1 在套用資料載入之前、期間和之後的結果

圖 6：測試 1 在套用資料載入之前、期間和之後的結果

僅有一部 AP (Ruckus R610) 不論有無資料網路負載，皆能提供全部的 30 個用戶端無停頓

的視訊。R610 同時也能針對純資料型的 Mac Mini 用戶端提供最高的彙總資料輸送量。

9


圖 7：測試 1 的彙總資料輸送量結果

結論

串流高解析度視訊到教室中的 30 部筆記型電腦，同時要推送超過 200Mbps 的資料輸送

量至另外 30 個競爭的用戶端 (Mac Mini)，顯示需要高效能的無線電驅動程式調節能力。

R610 擊敗所有競爭者一枝獨秀，是唯一的 Access Point 能夠達成針對各個用戶端裝置傳

送視訊的目標。

測試 2：60 個視訊用戶端和 2 個資料用戶端

目標

藉由測量加入資料載入前後，AP 支援的同時視訊播放次數差異，來確定在相鄰房間加入

2 個純資料用戶端，對兩間房間之 60 個 Chromebook 用戶端的視訊品質有何影響。

說明

60 個 Chromebook 用戶端上的視訊串流會手動啟動。所有的視訊開始播放一分鐘後，資

料會推送至隔壁房間內的 2 個 Mac Mini 用戶端上。未發生視訊停頓的用戶端數量以及與

純資料用戶端關聯的彙總資料輸送量都會記錄下來。各項測試亦會記錄先前發生停頓，

而在網路負載停止後重新開始的視訊次數。每測試各執行三次。

成功標準

AP 須在網路負載之前和期間順利將無停頓視訊傳送至全部的 60 個用戶端，且能同時傳

送資料至純資料用戶端。我們沒有為彙總資料輸送量訂定絕對的成功標準值。

10


圖 8：同時在 Chromebook (30 個用戶端) 進行視訊串流以及 Mac Mini 上 (2 個用戶端) 進行資料下載

結果

與第一個測試案例不同，僅有兩部 AP (Ruckus R610 與 Aruba AP-305) 能夠在沒有同時資

料載入的情況下，將無停頓視訊傳送至 60 個用戶端。若加入資料載入，則與第一個測試

案例相同，大多數供應商設備的無停頓視訊次數會下降。如下圖所示 (圖 9)，未發生停頓

的視訊連線數量從 60 個用戶端 (最佳) 到 0 個用戶端 (最差) 都有。

圖中顯示的所有結果為三次測試的中位數。

僅有一部 AP (Ruckus R610) 不論有無資料網路負載，皆能提供全部的 60 個用戶端無停頓

的視訊。

11


圖 9：測試 2 在有無負載的情況下，支援視訊的視訊用戶端數量

所有 AP 皆能在視訊測試時順利將資料流量傳送至純資料用戶端。Ruckus R610 和 Cisco

1850 傳送近乎等量的匯總輸送量至純資料用戶端，但以思科的案例來看，代價是有三分

之二的視訊串流用戶端發生停頓視訊的情形。

圖 10：測試 2 的彙總資料輸送量結果

12


結論

除了將高解析度視訊串流到兩間教室中的各 30 部筆記型電腦 (共 60 部視訊筆記型電腦)，

還要同時維持 QoS 來處理 150 Mbps 的 UDP 資料，成功的話會非常令人印象深刻。

Ruckus R610 這部 AP 是唯一能夠達成將視訊傳送至 60 個用戶端的測試目標。這次執行

驗證的程度證明了 Ruckus 符合其所承諾的價格效能比。

總結與結論

觀測各項測試程序的同時，也結合各種診斷工具，包括頻譜分析程式、通訊協定分析程

式以及手持診斷平台，來獲取與驗證各個結果。系統設定會與最佳實務及製造商建議設

定比對來進行驗證。我們監控了所耗用的播放時間，確保所有測試皆維持一致性。所有

結果會在測試當下經過視覺檢查，並由作者記錄。

這裡列出的各個衡量標準皆明顯有助於整體效能，以及本測試對於實際情況的效度。舉

例來說，很少僅有視訊會穿經 AP，因此我們評估了資料流量對於大量視訊流的影響。我

們也根據教室的實際情況選擇了特定視訊用戶端數量，這樣往後的客戶即可瞭解在其真

正環境中，各供應商的產品會有何表現。

計算整體網路容量的函數會納入可用播放時間、通訊協定效率以及啟用 QoS 流量傳送等

參數。在所有測試中，播放時間耗用 (頻道利用) 比較高是可以理解的，通常會在 75% 附

近，表示這個頻道已接近飽和。然而，僅有 Ruckus R610 能夠在所有測試中，實現夠強

的 QoS 及流量處理效率，達成向各用戶端裝置提供高品質視訊的目標，雖然其頻道會近

乎飽和。

作者要求 Ruckus 團隊在各項測試中須對供應商維持中立性與公平性，而事實上，如有需

要，總是姑且相信而較偏袒其競爭者。此處所有結果都是從測試中收集而來的原始資料

直接得出的，完全沒有經過四捨五入或任何處理。測試方法對於所有供應商都是公平且

相同的，一切都順其自然而不加干涉。

現今有更多的無線裝置與應用程式在網路上運行，因此瞭解這些裝置的使用方式至關重

要。隨著歷次 802.11 標準升級 (從 802.11、802.11n 到現在的 802.11ac)，雖然資料速率增

加了，但輸送量有沒有更好，則仍未有定論。直接結合啟用更佳的輸送量，並最終提供

更好的使用者體驗，是每個網路必須解決的行動挑戰。在小型網路中，快速來回、黏著、

主控及隨時發送訊息的裝置可能會帶來問題，但在高密度環境中，會變得具有破壞性。

能解決所有這些問題的網路基礎架構，最終將能提供最佳的彙總輸送量與使用者體驗。

13


附錄 A：Ruckus R610 結果

測試 1：30 個視訊用戶端及 30 個資料用戶端

無資料載入下支援的無停頓視訊串流數量 30 個，共 30 個 (100%)

有資料載入下支援的無停頓視訊串流數量 30 個，共 30 個 (100%)

彙總下行 UDP 總輸送量 (30 個用戶端) 201 Mbps





14


附錄 B：Aruba 305 結果









15


附錄 C：Aerohive AP250 結果

測試 1：30 個視訊用戶端及 30 個資料用戶端 (單 5 GHz 射頻)

無資料載入下支援的無停頓視訊串流數量 (全部共 30 個) 30 個，共 30 個 (100%)

有資料載入下支援的無停頓視訊串流數量 (全部共 30 個) 0 個，共 30 個 (100%)


測試 2：60 個視訊用戶端及 2 個資料用戶端 (單 5 GHz 射頻)




16


測試 1：30 個視訊用戶端及 30 個資料用戶端 (雙 5 GHz 射頻)




測試 2：60 個視訊用戶端及 2 個資料用戶端 (雙 5 GHz 射頻)




17


附錄 D：Meraki MR42 結果









18


附錄 E：Cisco 1850i 結果









中程 802.11ac 存取點的用戶端密度與視訊效能比較ruckus- · pdf file雖然...

Documents