WiFiSeer: Characterizing and Improving WiFi Latency in Large-Scale Operational Networks
出處：ACM MobiSys 2016，DOI 10.1145/2906388.2906393 作者：Kaixin Sui、Mengyu Zhou、Dapeng Liu、Minghua Ma、Dan Pei、Youjian Zhao、Zimu Li（清華大學）、Thomas Moscibroda（Microsoft Research） 分類：C. 使用者端 — P3 連上但很慢（Wi-Fi 瓶頸） 狀態：✅ 已讀全文，見 WiFiSeer－全文繁體中文翻譯（原文 mobisys_2016b.pdf）
一句話
只用企業／校園 WLAN 本來就有的 SNMP 資料，加上一個輕量的 ping2 量測，就能大規模量測 Wi-Fi 延遲、用機器學習找出原因，並實際把延遲降下來。
WiFiSeer 是什麼
一套「量測 → 建模 → 應用」的框架，目標是大型企業無線網路（EWLAN：校園、商場、機場、旅館）。
image/WiFiSeer－全文繁體中文翻譯/figure-01.png
| 層 | 做什麼 | 重點 |
|---|---|---|
| 資料收集 | ping2 量延遲 ＋ SNMP 收影響因素 | 不改 AP 韌體、不改使用者裝置 |
| 建模 | 監督式 ML，把延遲分類後建模 | 依應用需求選不同模型 |
| 應用 | 3 個應用：理解、診斷、AP 選擇（AGE） | 三者彼此獨立，可分開跑 |
部署規模（清華 THU-WLAN，一週資料）：2,700+ 台 Cisco 雙頻 AP、14 台無線控制器、114 棟建築、47,000+ 台裝置、數億筆紀錄、約 500 GB。
功能一：資料收集
ping2 — 避開省電模式的延遲量測
問題：一般 ping 會被裝置省電模式干擾。裝置要先醒來才能回應，量到的延遲偏高；從 AP 端喚醒甚至要等一個 beacon 週期（約 100 ms）。
做法：放在有線網路上的伺服器對裝置連續 ping 兩次：
- 第 1 次：把裝置叫醒
- 收到回覆後立刻送第 2 次，以第 2 次的 RTT 當結果
裝置醒著的時間（Android 約 200 ms、iPhone 約 100 ms）通常比 RTT 長，所以第 2 次多半能避開省電模式。有線段延遲的第 99 百分位小於 1 ms，可以忽略。
量測設定：每台裝置每 10 秒量一次，取 1 分鐘的 6 次平均當作一筆紀錄；封包不帶 payload。裝置 IP 從 SNMP 取得。
評估
| 面向 | 結果 |
|---|---|
| 準確度 | 與基準（裝置端每 1 ms ping，讓裝置不進入省電）最接近，優於 MobiPerf 等方法 |
| 伺服器負擔 | 尖峰同時量 15,000+ 台裝置，CPU < 10%、頻寬約 1 MB/s（含 SNMP） |
| 電池負擔 | 最壞情況（待機 24 小時一直被喚醒）耗電 7–10%；實務上只需定期收集，例如每季一週 |
SNMP — 收集影響因素
每分鐘從無線控制器輪詢一次（避免控制器過載），共 20 項因素：
| 類別 | 因素 | 說明 |
|---|---|---|
| 無線電（11） | 天線增益、雜訊功率、干擾功率、發射功率、每介面裝置數、頻道使用率、干擾使用率、接收／傳送使用率、RSSI、SNR | 直接描述無線環境 |
| 協定（3） | 頻道編號、頻段（2.4／5 GHz）、協定（802.11a/b/g/n/ac） | 可視為特定無線電因素的組合 |
| 外部（6） | AP 型號、Wi-Fi 晶片製造商（由 MAC 的 OUI 推得）、建築物、建築物類型、星期、時段 | 多半透過無線電因素間接影響延遲 |
量測發現
延遲分類（後面建模都用這套）：
| 類別 | 範圍 | 對應需求 |
|---|---|---|
| EX fast | < 5 ms | 線上遊戲 |
| fast | 6–10 ms | 線上協作 |
| slow | 11–20 ms | 快速網頁瀏覽 |
| EX slow | > 20 ms | — |
- 長尾：中位數約 3 ms，但第 90 百分位約 20 ms、第 99 百分位約 250 ms。約 20% 的量測屬 slow／EX slow；75% 的裝置一週內至少遇過一次持續超過 1 分鐘的 EX slow。
- 頻道使用率最重要：Kendall 分數 0.886、資訊增益 0.1708，兩項都排第一。
- RSSI 不太有用：與延遲有負相關（Kendall −0.472），但資訊增益只有 0.0008。原因是 96% 的 RSSI 落在 −85～−45 dBm，這區間延遲幾乎不隨 RSSI 變。頻道使用率超過 50% 時，RSSI 再好（−50 dBm）也低延遲不了。
- 5 GHz 沒被充分利用：5 GHz 平均延遲比 2.4 GHz 低 35%，裝置數只有一半。但超過 50% 的雙頻裝置連在 2.4 GHz，因為裝置靠 RSSI 選 AP，而 5 GHz 訊號衰減較快。Cisco 用「延遲 2.4 GHz probe response」引導裝置去 5 GHz，但裝置仍能從 beacon 發現 2.4 GHz，AP 廠商和裝置廠商的機制沒有協作。
- 晶片差很多：例如 Intel 第 90 百分位 15 ms，Meizu 高達 131 ms。
功能二：建模
挑戰：關係非線性甚至非單調；因素彼此相依（如 SNR 與 RSSI）；資料高度不平衡（高延遲很少）。
做法：把延遲分類後做分類模型（迴歸樹準確度低，分類也比較直觀）。比較 KNN、SVM、樸素貝氏、神經網路、決策樹、隨機森林後：
- 要解釋 → 決策樹（可讀、準確度尚可）
- 要預測 → 隨機森林（同精確率下召回率最高）
| 模型 1：理解無線電因素 | 模型 2：診斷高延遲 | 模型 3：選低延遲 AP（AGE） | |
|---|---|---|---|
| 用途 | 描述（給人看） | 描述（給人看） | 預測 |
| 方法 | 決策樹 | 多棵決策樹（兩階段） | 隨機森林 |
| 分類 | 4 類 | EX slow vs. 其他 | slow 以上 vs. fast 以下 |
| 因素 | 11 項無線電因素 | 時空因素＋管理者可處理的因素 | 連線前就拿得到的因素 |
| 不平衡處理 | 欠採樣 | 調判斷閾值 | 欠採樣 |
| 效能 | 準確率 0.42（4 類） | 精確率／召回率中位數 0.59／0.64 | 精確率 0.76、召回率 0.67 |
功能三：三個應用
應用 1：理解無線電因素（給廠商、協定設計者）
決策樹中 11 項因素只用到 4 項，最重要的是頻道使用率和裝置數。
image/WiFiSeer－全文繁體中文翻譯/figure-10.png
| 典型問題 | 量化條件 |
|---|---|
| 高負載 | 頻道使用率 > 47.5% 才會出現 EX slow（印證「使用率保持 50% 以下」的經驗法則） |
| 區域競爭 | 即使使用率 ≤ 22.5%，裝置數 > 35.5 仍會變慢（碰撞、退避、輪流等待） |
| 衰落與雜訊 | SNR 低於約 20 dB 會影響延遲（重傳增加、PHY 速率下降） |
應用 2：診斷高延遲（給網管人員）
兩階段：
- 依「建築物 × 建築類型 × 平日／週末 × 時段」切資料（一天分 6 段：上午、午餐、下午、晚餐、晚上、睡眠）。資料量 > 0.1% 且 EX slow 比例 ≥ 全域的 1.5 倍，就算一個問題點。清華 1,368 個組合中找出 92 個。
- 每個問題點各建一棵決策樹，根節點到 EX slow 葉節點的路徑就是「高延遲條件」。
例：第六教學樓平日晚上 → 「頻道使用率 > 66.5% 且裝置數 > 13.5」→ 網管應優先處理該處的高負載與區域競爭。
最常見的高延遲條件：高頻道使用率、裝置數多、干擾功率高。
據此實際部署兩項改善：
| 措施 | 做法 | 成效 |
|---|---|---|
| 5 GHz 專用 SSID | 新增「Tsinghua-5G」，讓雙頻裝置手動選 5 GHz | 2015/10 達 6,000 台，平均延遲比原 SSID 低 22% |
| 高密度 AP | 31 號宿舍每房一台 AP，調好頻道與功率、房內不設網孔（防私接 AP） | 對比一般部署的 17 號宿舍，延遲改善 36% |
應用 3：AGE — 以延遲為導向的 AP 選擇（給使用者）
AGE = Associating to Good Enterprise APs。不改作業系統、驅動或 AP 韌體，只靠一個 App 加一台控制器。
image/WiFiSeer－全文繁體中文翻譯/figure-13.png
流程：
- App 定期（螢幕開啟每 5 分鐘、關閉每 20 分鐘）把掃到的附近 AP 清單送給控制器
- 控制器從 SNMP 取這些 AP 的因素
- 模型 3 預測每台 AP 屬於 fast 或 slow，機率 > 0.6 才歸類，否則為「不確定」
- 若目前 AP 是 slow，且附近有 fast 的 AP → 回傳最可能 fast 的那台；否則回傳 Null
- App 透過 Android API 讓裝置改連該 AP
注意：AGE 線上預測不用 ping2（避免耗電），ping2 只用在收集歷史資料和事後評估。
部署成效（整合進清華 TUNet App，1,165 台裝置、2.5 個月）：
- 92% 的重新連線降低了延遲
- fast 以下（≤ 10 ms）的比例從 47% 升到 93%
- 一半的重新連線延遲減少超過 7.5 ms，10% 減少超過 51 ms
- 72% 的重新連線延遲降到一半以下
限制與延伸方向（論文第 6 節）
- 部分裝置不授權 App 改連線，或改連後又被系統預設演算法拉回原 AP → 最好在 OS／協定層實作。
- 可以整合進 802.11k/v：現在只交換頻道負載、鄰居報告等資料，選 AP 仍交給裝置；AGE 可以補上「選哪台」的智慧。
- 可延伸到吞吐量、網頁載入時間等其他指標，依使用者正在用的 App 選 AP。
- 模型也能用來事先估計網管措施的效果（例如加 AP 後裝置數少 20%，延遲會改善多少）。
- 部分外部因素（AP 型號、建築物）只適用於 THU-WLAN，換場域需要重新收集與訓練。
與主題的關係
- 最接近「校園一鍵診斷」的實證研究：證明只用校園網管既有的 SNMP 資料，就能解釋使用者感受到的「連上了但很慢」。
- 應用 2 的「問題點＋高延遲條件」可以直接當成主動式預警的規則來源：哪棟樓、哪個時段、什麼原因。
- 應用 3 的「建議你改連另一台 AP」是使用者端按鈕可以直接給出的具體建議。
- 決策樹路徑本身就是白話解釋的素材，例如「這台 AP 頻道使用率 70%、連了 40 台裝置，所以慢」。
- AGE 也被 SDWLAN 綜述 IV-B2 引用，見 SDWLAN綜述與主動式網路報修-關聯分析。