Mesh、AiMesh(WiFi Mesh)、ThinAP比較表與推薦如下 《第一種》 Mesh網狀網路系統原理:採用IEEE 802.11k/v/r 或IEEE 802.11s無線漫遊協定,達到漫遊 ... ... <看更多>
802.11 kvr 在 有支援IEEE 802.11 K、V、R標準協議的Mesh WiFi路由器 的推薦與評價
相關內容
-
Halo S12 Mesh 協定802.11 k/v,少了r差在哪? - Mobile01
-
[開箱] 802.11 k/v/r Mesh + Wi-Fi 6,TP-Link Deco X20 開箱
-
請教一般的802.11 ac router 可以搭配任意品牌的mesh satelite
-
www.mobile01.com 的其他相關資訊
-
Halo S12 Mesh 協定802.11 k/v,少了r差在哪? - Mobile01
-
[開箱] 802.11 k/v/r Mesh + Wi-Fi 6,TP-Link Deco X20 開箱
-
請教一般的802.11 ac router 可以搭配任意品牌的mesh satelite
-
www.mobile01.com 的其他相關資訊
802.11 kvr 在 Re: [閒聊] 新一代Wi-Fi系統: 網狀網路(Mesh Wi-Fi) - 批踢踢實業坊 的推薦與評價
整體來說你對於Mesh的市場現況我沒有什麼意見。
不過在一些技術細節,我和你有不一樣的看法。
※ 引述《parislove3 (艾草糖)》之銘言:
: 一般在平面大範圍、多層透天厝布置 Wi-Fi 時,通常是單一大功率 AP、每層拉一個 AP
: 或是利用延伸器中繼擴大訊號,這些方式有時不盡人意
: 如訊號涵蓋不均造成死角,就必須調整 AP 擺設 & 天線角度
: 此外裝置無法從 A點 AP 自動切換至 B點 AP,移動後持續會咬住前一個 AP 訊號
: 必須手動斷線重連
其實訊號差的時候 WiFi Driver應該都要主動尋找下一個SSID嘗試連線
會持續咬住上一個訊號差的AP原因很多
可能是他找不到更好的,
可能是他覺得訊號還是不錯的,
(很多人會想辦法把AP刷機功率開很強,改天線,但是手機另一端根本打回去超弱
所以會造成手機根本不知道,只覺得AP的訊號超強,
造成手機沒有意識到,他的連線品質很差,該漫遊了。)
或者是他的漫遊機制根本就壞了。
: 這牽涉到消費級無線路由器的功能限制,一般不支援兩個技術
: ● Wireless AP Roaming
: ● 負載平衡
: 在商用、企業級的機器,802.11r Fast Transition Roaming 是基本功能
: AP 控制器與 AP 均開啟功能時,當偵測到裝置訊號不良後會自動剔除連線
: 使其連接至訊號良好的 AP
802.11r 說穿了就是讓Station(連線端以下簡稱STA)在切換基地台的時候,
省下EAPOL 4-way handshake的時間,
讓整個漫遊斷線的時間可以從幾百個ms,降低到幾十個ms。
802.11r主要有兩種,分成 Over-Air 和 Over-DS
以下我用Over-Air作為說明
https://alln-extcloud-storage.cisco.com/ciscoblogs/802.11r-image-2-550x356.png
我認為 「802.11r不會主動剔除訊號不良的STA」
從圖片可以看到,整個802.11r FT的過程,STA才是主導的一端。
其他的漫遊機制大部分也都是由STA主動發起。
從理論上,AP把STA剔掉是非常EZ的事情,只要對STA發出Deauth就可以了,
但是實務上,不會有原廠建議你為了漫遊這麼做。
原因如下:
1.
AP覺得STA的RSSI(訊號)不好,把STA踢掉後,
原AP沒有辦法確保STA有其他訊號更好的AP可以連線,
STA可能又跑回來跟原AP連線整個瞎忙一場。
2.
突然切斷STA,整個連線要重來,會耗費非常多重新建立連線時間
(為什麼要花很多時間註1解釋,有興趣自己看),
如果STA正在打傳說會戰,一定會被送回家。
如果正在跟老婆語音or視訊 一定會被...?
所以AP主動發出Deauth對AP來說很簡單,但是對STA來說是殺他個措手不及。
那回到802.11r,STA他會覺得自己跟AP的訊號不好時,STA會預先在背景
用很短的時間,快速切換頻道送Probe,偷偷地先把附近可以用的AP資訊收集好,
決定好下一個AP是誰,才會主動啟動802.11r的機制。
你給的圖解居易科技,他們家有做出類似的功能,https://goo.gl/vaqXHL
他可以減少第一個原因的情況發生,具體的實作細節我不太清楚
我猜應該是他們家的AP會紀錄Probe request的強度,並且在系統內的AP分享這個表,
確保,強制STA漫遊之後,他一定可以找到下一台訊號更好的AP。
但是這個強制漫遊,和802.11r一點關係也沒有。
===========================================================
註1: 重新連線光是L2要做很多事,Probe、Auth、Association、4 way-handshack。
Probe request、Probe response(要去找附近的基地台)
你斷線之後,
對STA第一個問題就是,要找一個訊號最好的AP連線。
第二個問題來了,WiFi的頻道這麼多,STA怎麼知道最適合的他AP在哪個頻道?
以台灣的iPhone來說2.4G有1-11ch可以用,5G有36-48、52-144、149-165,
對於STA來說,這件事超靠杯的你懂嗎?
搜尋頻道這件事情,不能同步做,因為理論上WiFi一次只能在一個頻道工作。
STA要在各個不同的頻道丟Probe request,然後不是射後不理,送完之後
還要等待附近的AP回覆,然後把他收到的可用AP記錄下來整理成一張表,
最後,再根據這張表,決定要嘗試跟哪個AP連線,整個Probe才算完成。
終局,你嘗試連線的AP可能壞了。
(你應該有手機自己公共WiFi然後,網路不通,怒把WiFi關一波的經驗)
挖哩勒~搞了一大圈,STA可能又跑回去連原本那顆AP。
(以下吃光光)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.217.163.63
※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1516541500.A.8A1.html
※ 編輯: nfstako (180.217.163.63), 01/21/2018 21:36:19
※ 編輯: nfstako (180.217.163.63), 01/21/2018 21:37:35
https://goo.gl/i7wTMZ
雖然AP主動斷線的功能,對STA好像很壞,
可是長期放任訊號差的STA做低速的封包傳輸,會拖慢同頻道所有人的速度。
所以以企業的營運角度來說,可能寧願犧牲訊號差的STA,保持整體的服務品質。
SI要了解這件事情,還要知道怎麼優化這些門檻值,這要做實地驗證和調教,
非常不容易。
如果你的兩台AP是在L3同一個網路下,
(你可以把它想成在同一個IP分享器下面的兩台無線AP)
即使在L2 WiFi漫遊過去之後,L3在同一個網路下,
TCP還沒有超過斷線的最大限制,
那連線是有機會可以接回來的。
如果剛剛說的這個因為WiFi漫遊斷線的時間太久,
PTT Server或者是你的手機任何一方切斷TCP session 那PTT的連線就要整個重連了。
※ 編輯: nfstako (180.217.163.63), 01/21/2018 23:31:33
※ 編輯: nfstako (180.217.163.63), 01/21/2018 23:35:29
要看你是怎麼部署的,session是L3以上的設備在維護的,
如果你是兩台IP分享器,然後有各自的DHCP/NAT,再把SSID設成一樣,
這樣Session一定會斷,因為漫遊過去之後
IP不一樣、Network不一樣、default GW也不一樣
WLAN漫遊是L2的事情,如果你換過去之後他還在同一個網路就可以有機會不斷線。
看你要做到什麼漫遊,如果只是訊號差自己斷線去跟下一顆AP重新建立連線,
這個不需要特別支援什麼。
但如果是特別的漫遊協定(802.11r 802.11k 802.11v),這種當然要手機有支援才有。
雖然是舊的表了,但是可以參考一下。
https://goo.gl/i7wTMZ
我跟你不一樣的看法,我理解的session是由NAT負責維護的,
各個AP Mode 的AP就只是一台L2 的switch,只是它是走wireless。
理論上 TCP session的維護是在RT-N18U上面就做掉了,
你漫遊過去之後,會感應到漫遊的只有兩台AP與HP 8Port switch,
當你把AP設成AP mode他就是一台L2的設備,
AP只是忠實地把你的無線封包橋接到有線設備(HP 8Port)上
所以我認為AP mode 不會維護session,也就沒有AP同步session的問題
L2的設備我沒有聽過有在維護連線session的,可能是我孤陋寡聞
有的話可以貼出來看看
當然你遇到斷線的問題,應該是有真實發生,但原因可能還有待驗證。
應該是手機和N18U之間有什麼東西沒處理乾淨。
(先看看你漫遊過去之後,手機拿到的IP 有沒有變)
Thin AP是給企業大量部署的時候才會好用,
部署一台Thin AP跟部署1台家用的AP你就會知道,
你可以試試看UniFi他們家的Thin AP
Mesh 是給佈線不方便又想要WiFi覆蓋率的使用者用的(比較適合大坪數或店家)
小弟不才在WiFi相關的網路公司開發韌體,做過很多實驗,沒有遇到類似的問題。
※ 編輯: nfstako (118.150.29.44), 01/23/2018 13:50:27
... <看更多>