Skip to main content

MU-MIMO 是否真的有用,或是怎樣的場合應用下有用? 
這邊整理真實實測試報告
本文章主要引用

https://www.smallnetbuilder.com/wireless/wireless-features/33100-why-you-don-t-need-mu-mimo
http://www.acwifi.net/2722.html

MU-MIMO 概述

  • MU-MIMO使用作為802.11ac標準一部分的特殊形式的波束成形。它僅在5 GHz工作。
  • 您需要兩個 MU-MIMO啟用路由器和設備從MU-MIMO中獲益 (增加wireless client到AP 總頻寬) 
  • 您需要至少兩個 MU-MIMO設備才能從MU-MIMO獲得任何好處(增加wireless 到AP 總頻寬) 
  • MU-MIMO僅用於下行鏈路數據(從路由器移動到設備)。它對上行鏈路沒有好處(這點有點可怕待研究)
  • MU-MIMO最適合強到中等強度信號
  • MU-MIMO 不增加範圍

 

MUSU吞吐量差平均值

 

支持MU-MIMO的首款主流手機是Google NexusSamsungGalaxy S6

谷歌和三星都繼續在其手機中包括MU-MIMO,其中包括Google PixelSamsungGalaxy S7 / S7 Edge中的2×2 MU-MIMO。但如果您是iPhone粉絲,蘋果尚未支持MU-MIMO,至少在高通公司解決衝突之前,可能永遠不會。支持MU-MIMO的平板電腦仍然不常見。

現在的
MU-MIMO

拿一對 Google Pixel跟一對三星Galaxy S7手機進行測試。順便說一下,要知道智能手機中用的實際Wi-Fi芯片是非常困難的,因為它們的Wi-Fi通常都是第三方模塊。例如,iFixitGalaxy S7拆卸電話呼叫一個三星1316S7 Wi-Fi模塊,而ChipworksGalaxy S7 Edge拆卸將Wi-Fi模塊識別為處理“5G Wi-Fi +藍牙”KM5D18098。反正這邊確定,Pixel 用高通MU-MIMO Wi-Fi,三星S7則用Broadcom 802.11ac MU-MIMO Wifi

用兩個基於MU-MIMO4×4路由器,一個基於QualcommNETGEAR R7800V1.0.2.32固件)和基於Broadcom的華碩RT-AC88U3.0.0.4_382_15850-g7402e99固件)進行了一些實驗。手機在距離路由器大約8′的房間的相對端的貨架上。

 

測試很簡單:

  1. 在路由器上禁用MU-MIMO
  2. 手機Wlan連線並記錄設備鏈路速率
  3. 運行multiperf3測試來測量吞吐量
  4. 在路由器上啟用MU-MIMO
  5. 重複步驟23

第一個屏幕截圖顯示與禁用MU-MIMOR7800相關的電話。兩者都顯示指示雙流,即2×2連接的鏈路速率。

谷歌像素,三星S7鏈接率與NETGEAR R7800  -  MU-MIMO關閉

谷歌像素,三星S7鏈接率與NETGEAR R7800 – MU-MIMO關閉

當路由器上啟用MU-MIMO時,像素的鏈路速率保持不變,但三星的降低到433 Mbps,表示單流802.11ac連接。

Google Pixel,三星S7 Link Rate,帶有NETGEAR R7800  -  MU-MIMO

Google Pixel,三星S7 Link Rate,帶有NETGEAR R7800 – MU-MIMO

鑑於鏈路速率降低了50%,我們預計S7的吞吐量可以減少一半?這裡有兩個S7連接到帶有MU-MIMOR7800 …

三星S7與NETGEAR R7800  -  MU-MIMO關閉吞吐量

三星S7NETGEAR R7800 – MU-MIMO關閉吞吐量

啟用MU-MIMO。平均總吞吐量從624Mbps下降到513Mbps,損失約18%。鏈接率下降預期不到50%。

三星S7 W / NETGEAR R7800  -  MU-MIMO的吞吐量

三星S7 W / NETGEAR R7800 – MU-MIMO的吞吐量

現在我們來看看Google Pixel 無線網路狀況。首先禁用MU-MIMO

Google Pixel帶有NETGEAR R7800  -  MU-MIMO關閉吞吐量

Google Pixel帶有NETGEAR R7800 – MU-MIMO關閉吞吐量

R7800上禁用MU的情況下,總平均吞吐量約為616 Mbps,啟用後,大約為760 Mbps,增長了約23%。這遠高於高通在其MU-MIMO宣傳材料所稱的“高達3倍快” ,但至少還是有所收穫。

Google Pixel w / NETGEAR R7800  -  MU-MIMO吞吐量

Google Pixel w / NETGEAR R7800 – MU-MIMO吞吐量

1流與2

 

根據20156Qualcomm演示文稿下面的幻燈片,QCA9984用於較新的路由器,如NETGEARR7800SynologyRT2600ac,可以支持兩個雙流設備。

較舊的MU-MIMO設備每幀只支持三個設備

較早的MU-MIMO設備每幀只支持三個設備
(圖片來源:Sogi.com.tw

所以讓我們比較兩個1×1和兩個2×2設備的MU-MIMO吞吐量增益。我使用了兩台octoScope Pal-5 Wlan 測試設備,它們使用QCA9984並允許設置MIMO流的數量。

我運行了兩台連接到NETGEAR R7800,它用了5GHz無線電中的QCA9984,然後使用了Broadcom BCM4366 的華碩RT- AC88U。不幸的是,當我打開設備時,並沒有註意到設備的修訂級別,所以不知道是否使用了所謂的正確的MU-MIMO支持要求的C0 rev。數據顯示,我懷疑不是。

被測試的每個路由器被放置在octoScope 38室的中心。一個Pal-5連接到腔室右側的天線; 另一個連接到左側的天線。可編程衰減器用於調節由Pals報告的信號電平大致相等。以前的電話測試使用相同的流量,即multiperf3運行四個同時連接的2048 kB TCP / IP窗口大小。

下面的條形圖比較了兩個STA的總吞吐量,因為這是MU-MIMO應該增加的。使用相同QCA9984芯片組的基於QualcommSTA和路由器的配對應該使MU-MIMO成為其最佳拍攝。結果顯示,使用一對1×1 STA的總吞吐量增長了62%,但是使用2×2的增長只有17%。

1對2流MU-MIMO增益 -  NETGEAR R7800

12MU-MIMO增益 – NETGEAR R7800

將Broadcom的路由器和QualcommSTA配對更糟。一對單流STA可以獲得42%的吞吐量增長。但是,這對2×2STA的總吞吐量降低了58%!

1對2流MU-MIMO增益 - 華碩RT-AC88U

12MU-MIMO增益華碩RT-AC88U

這是ASUS吞吐量看起來像,MU-MIMO關閉

華碩RT-AC88U  -  2流Pal STA  -  MU-MIMO關閉

華碩RT-AC88U – 2Pal STA – MU-MIMO關閉

並啟用MU-MIMO華碩RT-AC88U  -  2流Pal STA  -  MU-MIMO on

 

華碩RT-AC88U – 2Pal STA – MU-MIMO on

MU-MIMO怎樣狀況下會沒有效果.

 

MU-MIMO在雙流產品中就是這種情況。我繼續看到像Wi-Fi擴展器和多節點Wi-Fi系統(如NETGEAROrbi)規格中列出的MU-MIMO,它們具有2×2客戶端無線電。

如果我們使用舊數量的流-1經驗法則來提供峰值MU-MIMO增益的單流設備數量,我們得到1,這是沒有道理的。所以我們假設雙流MU-MIMO AP /路由器將通過兩個單流設備提供峰值吞吐量增益。

為了測試這個,我把一個Orbi RBK30放進了測試室,再次打開了兩個octoScope Pal-5,得到了下面的結果。像所有Wi-Fi系統一樣,Orbi是基於高通芯片。所以我們知道它應該能夠支持適當的MU-MIMO操作。雖然原始的Orbi有一個專用的5 GHz 4×4回程無線電,所有型號的面向客戶端的收音機只有2×2

下面的圖表清楚地表明,MU-MIMO在這裡沒有任何有用的東西。但至少它不會像基於BroadcomRT-AC88U那樣降低吞吐量。

1對2流MU-MIMO增益 -  NETGEAR RBK30 Orbi

12MU-MIMO增益 – NETGEAR RBK30 Orbi

看到這可能你會對 MU-MIMO 失去信心
但這邊的測試又有提及Qualcomm MU-MIMO 真實狀況
http://www.acwifi.net/2722.html

測試AP為Tplink wdr8500 4×4  Qualcomm QCA9984
Client 設備也都為Qualcomm
 
先以單個Client 測試

對比開啟MU-MIMO後的測試與比較

模擬可能的狀況

OSSLab結論
對於多點Wireless client場合 ,MU-MIMO確實可以提高AP負載client數量跟總wifi 頻寬.
但必須面對相容性問題. 因此必須視狀況開啟或關閉.不一定打開是最好的.

還有待測試跟釐清的
1.各廠牌Wireless Client 802.11Ac MU-MIMO 相容性
2.Wireless client數到達某個規模,MU-MIMO是否有作用
3.考慮到upstream 需求. 802.11ax也許是下一代解決方案

Thx Chang

Author Thx Chang

More posts by Thx Chang