Re: [閒聊] 新一代Wi-Fi系統: 網狀網路 (Mesh Wi-Fi)

看板PC_Shopping作者nfstako (sLc0mk tpR1ZE)時間6年前 (2018/01/21 21:31)推噓26(26推 0噓 53→)

留言79則, 17人參與討論串2/2 (看更多)

整體來說你對於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

推

b325019

01/21 22:00, 6年前 , 1^F

01/21 22:00, 1^F

→

b325019

01/21 22:00, 6年前 , 2^F

01/21 22:00, 2^F

→

b325019

01/21 22:00, 6年前 , 3^F

01/21 22:00, 3^F

→

b325019

01/21 22:00, 6年前 , 4^F

01/21 22:00, 4^F

→

b325019

01/21 22:00, 6年前 , 5^F

01/21 22:00, 5^F

舊資料分享，HTC U11至今還不支援11r https://goo.gl/i7wTMZ

→

b325019

01/21 22:00, 6年前 , 6^F

01/21 22:00, 6^F

→

b325019

01/21 22:00, 6年前 , 7^F

01/21 22:00, 7^F

沒錯！雖然AP主動斷線的功能，對STA好像很壞，可是長期放任訊號差的STA做低速的封包傳輸，會拖慢同頻道所有人的速度。所以以企業的營運角度來說，可能寧願犧牲訊號差的STA，保持整體的服務品質。 SI要了解這件事情，還要知道怎麼優化這些門檻值，這要做實地驗證和調教，非常不容易。

推

Jay915

01/21 22:09, 6年前 , 8^F

01/21 22:09, 8^F

※ 編輯: nfstako (180.217.163.63), 01/21/2018 22:43:57

推

wahaha99

01/21 22:46, 6年前 , 9^F

01/21 22:46, 9^F

→

wahaha99

01/21 22:46, 6年前 , 10^F

01/21 22:46, 10^F

推

Shauter

01/21 22:53, 6年前 , 11^F

01/21 22:53, 11^F

推

b325019

01/21 23:05, 6年前 , 12^F

01/21 23:05, 12^F

如果你的兩台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

推

Cubelia

01/21 23:32, 6年前 , 13^F

01/21 23:32, 13^F

推