為什麼連上 WiFi 存取點需要這麼久

原題：Why It Takes So Long to Connect to a WiFi Access Point
原文版本：arXiv:1701.02528v3，2017 年 5 月 8 日
原文檔案：1701.02528v3.pdf

作者：Changhua Pei†、Zhi Wang§、Youjian Zhao†、Zihan Wang§、Yuan Meng†、Dan Pei†*、Yuanquan Peng‡、Wenliang Tang‡、Xiaodong Qu‡。

† 清華大學；清華資訊科學與技術國家實驗室（TNList）
‡ 騰訊
§ 清華大學深圳研究生院

• Dan Pei 為通訊作者。

譯文說明：以下依原文章節順序翻譯全文，包含圖說、表格、致謝與參考文獻題名。技術縮寫、作者姓名及書目識別資訊保留。圖中曲線與狀態轉移圖保留原圖；圖內文字另附中文對照。原文的數據、方法敘述及推論若有不一致，譯文保留原意，並以「譯註」標示，不將其改寫成新的研究結論。

摘要

現今 WiFi 網路承載了很大比例的流量。然而，WiFi 網路的效能與品質仍遠未令人滿意。在眾多常見的品質指標，例如吞吐量與延遲之中，成功連上 WiFi 存取點（Access Point，AP）的機率，以及 WiFi 連線建立程序所需的時間，是影響 WiFi 使用者體驗的兩個關鍵指標。

為了解真實環境中的 WiFi 連線建立程序，我們進行量測研究。資料來自一款在 Android／iOS App 市場名列前茅的行動「WiFi Manager」App，涵蓋四個具代表性城市中的 500 萬名行動使用者、700 萬個 AP，以及 4 億次 WiFi 工作階段。據我們所知，我們是首個以如此大規模研究下列問題的團隊：WiFi 連線建立耗時有多長、哪些因素會影響 WiFi 連線建立程序，以及可以如何縮短建立連線所需的時間。

根據資料驅動的量測與分析，我們得到以下發現：（1）連線建立失敗與建立連線耗時過長，是現今 WiFi 使用中的常見問題。高達 45% 的使用者遭遇連線建立失敗，而 15%（5%）的使用者建立連線所需時間超過 5 秒（10 秒）。（2）與既有最新研究不同，連線建立程序四個階段之一的掃描（scan），對整體連線建立耗時的貢獻最大，占 47%。（3）若能善用隱含資訊，行動裝置型號與 AP 型號能大幅協助我們預測連線建立耗時。

根據量測分析，我們提出以機器學習為基礎的 AP 選擇策略。相較於僅依訊號強度選擇 AP 的傳統策略，此方法能顯著改善 WiFi 連線建立效能，將連線建立失敗率由 33% 降至 3.6%，並使連線建立耗時的第 80 百分位縮短超過 10 倍。

譯註：原文摘要對 45%、15% 與 5% 使用「使用者」作為敘述對象；正文則主要以連線嘗試、成功的連線嘗試為分母。摘要亦未限定 47% 的適用範圍，正文將此觀察限定於耗時超過 15 秒的連線。本譯文保留這些差異。原文「80% time costs」依圖 11 與評估段落譯為「第 80 百分位耗時」。

I. 緒論

近年來，智慧裝置的爆炸性成長，使無線資料流量呈指數增加。在這些無線網路之中，802.11 無線區域網路（WiFi）承載了當今無線流量的主要部分。過去十年間，超過 10 億個 WiFi AP 已被售出並部署，用以提供無線連線服務 [1]。即使使用者的智慧裝置支援 3G／4G 行動網路，他們仍會使用如今隨處可見的 WiFi 熱點。

然而，WiFi 網路的網路效能與使用者體驗仍不理想。根據我們對都市地區超過 500 萬名 WiFi 使用者進行的量測研究，高達 45% 的行動裝置未能與對應 AP 建立 WiFi 連線；而在成功建立的 WiFi 連線中，15%（5%）的連線建立耗時超過 5 秒（10 秒）。因此，了解使用 WiFi 網路的第一步，也就是 WiFi 連線建立程序，極為重要。我們需要了解此程序的效能、為什麼有相當比例的連線失敗與耗時過長事件，以及可以採取哪些措施縮短連線建立時間。

先前的 WiFi 網路量測研究，主要關注一般性的使用者體驗指標，例如使用者在 WiFi 網路中感受到的頻寬與延遲，很少聚焦於連線建立程序的效能。文獻 [2] 首次嘗試引起大家對連線建立耗時的重視。他們在受控環境中，從少量志願參與者的 Android 智慧型手機蒐集資料，觀察到連線建立耗時過長主要是 DHCP 封包遺失所造成。然而，真實環境中 WiFi 連線建立程序的效能仍不明朗，也缺乏更大規模的深入調查。

本文旨在解決這個問題。我們從數百萬部安裝熱門 Android App「WiFi Manager」的行動裝置，蒐集連線紀錄。首先，這款 App 讓我們能將連線建立程序拆分為不同子階段，找出以往未曾發現的現象。其次，大規模資料蒐集讓我們能訓練機器學習模型，在使用者嘗試連線之前預測連線建立耗時。此模型還能進一步協助行動使用者選擇最佳 AP，縮短建立連線所需的時間。

我們的貢獻可歸納如下。

在巨觀層面，我們探討真實環境中的連線建立耗時情形。我們持續從 500 萬部不同、且安裝 WiFi Manager App 的行動裝置蒐集連線紀錄，取得 4 億次 WiFi 連線嘗試。我們發現 45% 的連線嘗試失敗。在成功的連線嘗試中，15%（5%）耗時超過 5 秒（10 秒）。透過 x-y 視覺化與相關性分析，例如相對資訊增益，我們發現除了已知會影響連線建立程序的訊號強度之外，知道 AP 型號與行動裝置型號，也很有助於預測連線建立耗時。這主要是因為相同型號的 AP 或行動裝置，通常具有相似特性。第 V 節將提供更詳細的分析。

在微觀層面，我們將整個 WiFi 連線建立程序拆分為子階段，計算各階段所占的耗時比例。我們發現，在總耗時超過 15 秒的連線嘗試中，有超過一半的連線，其掃描階段耗時占 47%。這出乎我們的預期，因為先前研究指出，大部分時間耗費於 DHCP 階段，而非掃描階段 [2]。透過追蹤這些連線建立程序的 WiFi 網路狀態轉移，我們發現異常轉移至 Disconnected 狀態會造成重新連線。進一步證據顯示，這主要是行動裝置與 AP 之間不理想的封包遺失所造成，而封包遺失的原因包括：訊號強度變動、WiFi 干擾，以及高負載造成行動裝置與 AP 系統回應延遲。

最後，我們說明如何利用上述觀察，協助行動使用者選擇較好的 AP，改善 WiFi 連線建立程序的效能。僅依行動裝置量測到的訊號強度來決定連線對象，並不是好方法。我們提出以機器學習為基礎的 AP 選擇方法，加入少量容易取得的指標作為額外特徵，包括行動裝置型號、AP 型號、已關聯至 AP 的裝置數量，以及連線嘗試發生於一天中的哪個小時。

我們使用真實環境中蒐集的資料集，進行情境假設分析（what-if analysis），評估利用機器學習模型協助行動使用者選擇最佳 AP 所帶來的效能改善。評估結果顯示，相較於選擇訊號最強 AP 的基準演算法，機器學習 AP 選擇方法表現良好。我們的方案能將連線失敗率由 33% 降至 3.6%，並將連線建立耗時的第 80 百分位縮短 10 倍。

本文其餘內容安排如下：第 II 節介紹連線建立程序的背景，並定義量測耗時的指標；第 III 節將連線建立程序拆分為不同子階段，找出主要耗時來源；第 IV 節進行相關性分析，探討特定因素如何影響連線建立程序；第 V 節提供行動裝置與 AP 型號的案例研究；第 VI 節使用機器學習方法協助行動使用者選擇 AP；第 VII 節討論相關研究；第 VIII 節總結全文。

II. 連線耗時

本節定義 WiFi 連線建立耗時，以及整個連線建立程序的各個子階段，接著介紹如何使用 WiFi Manager App 記錄各子階段耗時。

本文所用的 WiFi 連線建立耗時（WiFi Connection Set-up Time Cost），定義為使用者點選欲連線 AP 的 SSID（Service Set Identifier，服務集識別碼）名稱，到裝置取得 IP 位址之間的時間間隔，如圖 1 所示。以下也將 WiFi 連線建立耗時簡稱為「連線耗時」。

值得注意的是，取得 IP 位址並不保證可以存取網際網路。例如，部分公共 AP 設有入口網頁，要求使用者先驗明身分。本文不研究這部分的耗時。以下介紹各子階段。

掃描（Scan）： 掃描的主要目的是更新或確認使用者裝置周圍可用的 WiFi SSID 清單。掃描分為主動掃描與被動掃描兩種 [3]。主動掃描會定期觸發：行動裝置先廣播探測請求（probe request），周圍 AP 收到後回覆探測回應（probe response）封包，內容包含支援的實體層速率等資訊。若行動裝置確認 AP 相容，就會將該 AP 的 SSID 加入候選清單。被動掃描則透過 AP 定期廣播的 beacon 封包更新可用 SSID 清單，例如每 100 毫秒廣播一次 [4]。

關聯（Association）： 這是每次連線建立程序都必須經過的步驟，其協定包含驗證請求、驗證回應、關聯請求及關聯回應。這四個封包依序傳送與接收。行動裝置收到關聯回應後，WiFi MAC 層連線便已建立，使用者可以向 AP 傳送任意 MAC 層封包，反向亦然。此處的驗證請求與回應，實際上是一個空的驗證步驟，是早期 WEP 標準留下的機制 [5]。若 WiFi AP 啟用較新的加密機制，例如 WPA2，就必須進行接下來真正的驗證階段。

驗證（Authentication）： 這是 AP 的額外階段，在現今 WiFi 環境中相當常見。驗證包含四個 MAC 層封包的交換。使用者可能輸入錯誤密碼，導致此階段連線失敗。我們會記錄這類失敗，如圖 2 所示，以供後續研究。

DHCP： 在此階段，行動裝置會與 DHCP 伺服器互動。該伺服器可以是獨立伺服器，也可以部署於 AP 上。裝置一取得 IP 位址，我們的 App 就將此時標記為連線嘗試結束，並計算連線耗時。

圖 1：行動裝置連上 WiFi AP 時，網路活動的時間軸。

圖中依序呈現：開始掃描、App 開始計時、開始關聯、開始四向交握（4-way handshake）、請求 IP、取得 IP。子階段為掃描、關聯、驗證、DHCP。連線耗時從 App 開始計時起算，至取得 IP 為止。

III. WiFi 連線建立程序的拆解

在這部分，我們使用 App 記錄每個子階段的耗時。考量對每次狀態轉移計時所增加的運算與儲存負擔，我們僅將具備 WiFi 關聯程序拆解功能的 WiFi Manager App 版本，部署至 12,472 部經審慎挑選的行動裝置，共產生 70.6 萬次連線嘗試。

A. WiFi 關聯：成功與失敗

一次連線建立程序可能以圖 2 所示的結果結束。圖中的「成功」（Success）表示在 30 秒內成功取得 IP 位址的連線建立程序。「逾時」（Timeout）表示 30 秒內仍未進入 DHCP 階段的程序；在這個門檻之後，只有 0.01% 的連線建立程序最終成功。「DHCP 失敗」（DHCP Failure）表示已進入 DHCP 階段，卻未能成功取得 IP 位址。

其餘結果包括「密碼錯誤」（Wrong password，使用者輸入了錯誤密碼）、「切換至另一個 WiFi」（Switching to another WiFi，使用者決定改連其他 WiFi AP）、點選「忘記 WiFi」（Forget WiFi）按鈕，以及「關閉 WiFi 介面」（Switching off the WiFi interfaces）。此外，不到 5% 的連線嘗試被標記為「未知」（Unknown）。所有這些結果都表示連線建立程序終止。

從圖 2 可觀察到，45% 的連線建立程序失敗。最常見的失敗原因是逾時與 DHCP 失敗，合計約占所有連線嘗試的 24%。圖 2 中其餘四類失敗，是因為使用者不願繼續連線到目前 WiFi，例如在連線過程中切換至另一個 WiFi，或關閉 WiFi 介面。換言之，我們只研究行動使用者願意連線的情況，包括成功、逾時與 DHCP 失敗。

圖 2：不同類型連線建立程序的比例。 縱軸為百分比。

譯註：正文稱「未知」不到 5%，但圖 2 標示 5.042%；此處保留兩者。

B. 連線耗時的分布

如第 II 節所述，當且僅當行動裝置在 30 秒內取得 IP 位址時，連線建立程序才算成功。圖 3 呈現成功連線建立程序的耗時分布。

我們觀察到，約 80% 的成功連線建立程序，耗時低於 5 秒。然而，分布仍有長尾：約 3% 的連線建立程序，最終耗時超過 15 秒。

圖 3：成功連線建立程序耗時的累積分布函數（CDF）。 橫軸為連線耗時（秒），縱軸為 CDF（%）。

C. 拆解連線建立程序

拆解程序的主要優點，是可以透過各子階段耗時比例，輕易找出整體連線耗時的主要來源。然而，許多既有最新研究，例如 [2]，缺乏這類詳細的 WiFi 連線量測。這部分研究不同 WiFi 使用情境下，各子階段耗時絕對值的累積分布函數。

我們依連線耗時，將連線建立程序分為三類：0 至 7 秒、7 至 15 秒，以及 15 至 30 秒。圖 4 顯示各子階段耗時比例的 CDF。最明顯的結果是，相較於掃描與 DHCP 子階段，關聯與驗證子階段所需時間並不多。這是合理的，因為這兩個子階段只包含固定數量的 WiFi 封包交換。

第二個觀察是，耗時 0 至 7 秒與 7 至 15 秒的連線建立程序，分布相似；但耗時 15 至 30 秒的程序，呈現不同模式。在耗時低於 15 秒的連線建立程序中，有一半的程序，其 DHCP 階段占總耗時超過 80%，這與 [2] 的結論一致。

令人意外的是，對耗時超過 15 秒的連線建立程序而言，掃描階段比 DHCP 階段花費更多時間，如圖 4a 與圖 4d 所示。不同類別連線建立程序的掃描耗時如圖 5 所示。對總耗時 0 至 7 秒的程序而言，99% 的掃描耗時低於 3.4 秒。對 7 至 15 秒這一類而言，99% 的掃描耗時低於 11.6 秒。相反地，在 15 至 30 秒這一類中，約 40% 的掃描耗時超過 11.6 秒。

為進一步探討掃描階段為何耗時過長，圖 6 顯示耗時超過 15 秒的連線建立程序之 Android 網路狀態轉移。箭頭旁的數字表示資料集中發生該轉移的總次數。圖 6 顯示存在異常轉移至 Disconnected 狀態的情況。Disconnected 狀態會觸發重新連線，而重新連線從 Scanning 狀態開始。許多連線建立程序多次重新進入 Scanning 狀態，因此掃描耗時較長。

Scanning 狀態轉移至 Disconnected，是因為行動裝置的探測未收到回應。Associating 狀態轉移至 Disconnected，則是因為 AP 沒有回覆關聯回應封包。可能原因有兩種：AP 沒有收到行動裝置的請求封包，或行動裝置沒有收到 AP 的回覆封包。然而，這些連線建立程序最終都成功，意味著 WiFi 封包接收存在不確定性，也就是 WiFi 封包遺失。

這類封包遺失由以下原因造成：行動裝置所量測的 AP RSSI 變動、WiFi 干擾，或系統（AP 或行動裝置）處理延遲導致逾時。本文後續將提出一個方案，綜合考慮上述因素，協助行動裝置選擇較好的 AP。

圖 4：不同子階段所占比例的分布。 （a）掃描；（b）關聯；（c）驗證；（d）DHCP。各圖橫軸為該階段占總耗時的比例（%），縱軸為 CDF（%）；曲線分別對應總耗時 0 至 7 秒、7 至 15 秒、15 至 30 秒。

圖 5：總連線耗時分別落在 0 至 7 秒、7 至 15 秒與 15 至 30 秒的不同類別連線建立程序，其掃描耗時。 橫軸為掃描耗時（秒），縱軸為 CDF（%），圖中標示 3.4 秒與 11.6 秒。

圖 6：連線耗時超過 15 秒之連線建立程序的狀態轉移。 狀態文字對照：Scanning＝掃描中；Associating＝關聯中；Associated＝已關聯；Completed＝已完成；Connected＝已連線；Disconnected＝已斷線。箭頭數字代表轉移總次數，轉移方向與數值保留於上方原圖。

譯註：原文將 Scanning 轉至 Disconnected 的原因寫作「沒有對行動裝置的 probe response 作出回應」，與第 II 節所述探測請求／回應角色不一致。此處譯為「探測未收到回應」。

D. 小結

以下強調上述分析的幾項結論。

首先，只有 54.9% 的連線建立程序成功。約 24% 的程序最終未能取得 IP 位址。在成功的連線建立程序中，15%（5%）耗時超過 5 秒（10 秒）。

其次，對成功連線中耗時超過 15 秒的那 3% 程序而言，非預期的封包遺失是主要原因。這可能由訊號強度變動、WiFi 干擾，以及 AP 或行動裝置的高系統處理延遲所造成。如何有效將這些因素全部納入考量，協助行動裝置縮短連線耗時，是一項挑戰。

IV. 相關性分析

本節首先簡介我們蒐集的連線紀錄資料集，這是後續分析的基礎。接著，使用定性方法（x-y 視覺化）與定量方法（相對資訊增益），分析資料集中蒐集的特定因素如何影響連線耗時。

A. 連線紀錄資料集簡介

我們在每一部安裝 WiFi Manager 的行動裝置上蒐集連線紀錄。從 5 月 3 日至 5 月 9 日，我們連續蒐集一週資料，將每次連線建立程序記錄到中央伺服器。由於 App 普及程度很高，這一週的資料集涵蓋四個不同城市中，約 700 萬個不同 AP 與 500 萬部不同的行動裝置。連線建立程序總數達 4 億次。

資料集中的每筆紀錄包含兩部分，分別列於表 I 的上半部與下半部。上半部為環境相關資料，下半部為效能相關資料。環境相關資料用來描述每次連線建立程序發生時的情境，有助於找出連線耗時過長事件的根本原因。效能資料主要包含連線結果，以及最終成功建立連線時的連線耗時。在這個連線紀錄資料集中，我們只能區分三種連線結果：成功、密碼錯誤造成的失敗，以及網路造成的失敗。

表 I：本文使用之連線紀錄資料集欄位。 上半部包含用來描述連線建立情境的特徵；下半部表示連線是否成功，以及成功時的連線耗時。

取得連線紀錄資料集後，我們先檢查時間、地點與使用者等維度的基本性質。我們發現 80% 的連線嘗試由 20% 的使用者產生，並發生於 20% 的地點，符合 Pareto 原則。連線嘗試在一週的各天之間均勻分布，但在一天中的不同小時略有變化，反映人們一天的作息。

我們利用此資料集，重新檢查失敗事件比例（第 III-A 節）與連線耗時分布（第 III-B 節），得到相似結果。除了整體分布，我們也關心特定使用者遭遇連線失敗事件的頻率。我們計算每位使用者的失敗事件比例，結果顯示不同使用者的失敗事件比例從 0 至 100% 不等。不到 20% 的使用者，其失敗事件比例維持在 0.8 以下。

我們也檢查不同時間與地點中，曾經遭遇連線失敗的使用者比例，發現這個數值隨時間與地點平緩變化。總而言之，連線失敗事件並非由少數使用者在少數地點或少數幾天所造成。因此，我們無法僅透過逐一個案分析，減少連線失敗事件或連線耗時過長事件。

譯註：「不到 20% 的使用者，其失敗事件比例低於 0.8」依原文翻譯；原文未進一步解釋此處比例門檻與其他整體失敗率敘述的關係。

B. 定性分析

為了解表 I 中各個特徵如何影響連線耗時，我們使用 x-y 視覺化，呈現連線耗時隨各特徵的變化。由於行動裝置型號與 AP 型號各有數千種，我們省略這兩個特徵的 x-y 視覺化結果，改以定性分析及第 V 節的詳細分析，研究 AP 型號與行動裝置型號對連線耗時的影響。

對非類別型特徵，我們以不同區間寬度進行分箱（binning）：RSSI 的區間寬度為 5 dBm，裝置數量的區間寬度為 10。接著計算每個區間的平均連線耗時，如圖 7 所示。

關聯發生的時間會影響連線耗時。 圖 7a 顯示，一天中的小時會影響連線耗時。白天（上午 7 時至晚上 7 時）的連線耗時，高於夜間。這主要是因為人們在不同小時的活動不同，例如餐廳 AP 在午餐或晚餐時段會出現關聯嘗試數量的尖峰。

RSSI 較高的連線，通常具有較短的平均連線耗時。 RSSI 與連線耗時之間存在明顯的單調關係。當 RSSI 從 -90 dBm 提高至 -60 dBm 時，連線耗時從 5 秒變為 2.5 秒。值得注意的是，當時最新的 Android 裝置設有 RSSI 上限：RSSI ≥ -55 dBm 都會被記錄成 -55 dBm。

圖 7：不同特徵與連線耗時的相關性。 （a）一天中的小時；（b）RSSI（dBm）；（c）裝置數量。縱軸皆為連線耗時（秒）。RSSI 圖中的 -60 dBm 代表 [-60 dBm, -55 dBm] 區間；裝置數量圖中的 10 代表 [10, 20] 區間。

C. 定量分析

本節主要使用相對資訊增益 [6] 與 Kendall 係數 [7]，定量評估各特徵與連線耗時之間的關係，此做法受到 [8]、[9] 啟發。數值列於表 II。為協助解釋結果，我們先簡介這兩項指標。

相對資訊增益（Relative Information Gain，以下簡稱 RIG）： 對原始輸入 $(x,y)$ 而言，RIG 用來表示知道 $x$ 對預測 $y$ 有多少幫助。在計算中，我們依 $x$ 與 $y$ 向量的特性進行分箱。一天中的小時、裝置數量與 RSSI（$x$）的區間寬度分別為 1、10 與 5 dBm；連線耗時（$y$）的區間寬度為 100 毫秒。

Kendall 係數（以下簡稱 Kendall）： Kendall 是一種等級相關計算。直觀而言，當兩個變數 $(x,y)$ 的排序相似時，Kendall 係數較高。我們先使用與資訊增益相同的區間寬度，對向量 $x$ 分箱，再計算落入各區間的 $y$ 平均值，接著計算各 $x$ 與 $y$ 之間的 Kendall 係數。由於 Kendall 主要用來呈現特定特徵與連線耗時之間的單調性，不適用於類別型特徵，因此我們不為類別型特徵計算 Kendall。

表 II：不同特徵與連線耗時之間的 RIG 與 Kendall。 「／」表示未計算。

行動裝置型號與 AP 型號具有最高 RIG。 高 RIG 表示知道裝置或 AP 型號，對預測連線耗時有很大幫助。例如，我們量測到所有 HTC 手機的平均連線耗時，是 Samsung 手機的 1.3 倍。可能原因是部分 Samsung 裝置型號配備了頂級硬體，例如晶片組，而這通常意味著較少的設計缺陷與較快的回應時間。

RSSI 具有較大的 RIG，以及最高的 Kendall。 RSSI 具有最高 Kendall 是自然的結果，因為連線耗時與 RSSI 之間存在明顯的單調遞減關係，如圖 7b 所示。RSSI 對連線耗時也具有可接受的 RIG，這解釋了為什麼許多既有方法依訊號強度選擇 AP [10]。

譯註：原文稱 RSSI 的 Kendall「最高」，但表 II 數值為負；此敘述應理解為其絕對值所表示的單調相關程度較高。

裝置數量的幫助有限。 表 II 顯示，裝置數量具有較低的 RIG 與 Kendall 係數。圖 7c 也證實這一點，因為連線耗時與裝置數量之間沒有明顯相關性。主要原因是，每個 AP 都有可容納一定裝置數量的容量，只有在裝置數量超過門檻時，效能才開始下降。若裝置數量維持在門檻以下，對連線耗時的影響相當小。圖 7c 中的這個門檻大約是 100 部裝置。

值得注意的是，我們的「裝置數量」特徵，表示目前已關聯至該 AP 的裝置數，與 [11] 所指的周圍裝置數量不同。已關聯裝置數會透過區域內競爭影響效能：已關聯裝置越多，發生區域內競爭的可能性越高，進而導致更長的本地佇列。另一方面，[11] 使用旁聽到的無線封包，推估周圍裝置數量。周圍裝置數量反映周遭環境的裝置密度，會影響同一通道上的競爭。

D. 其他特徵

2.4 GHz 頻段與 5 GHz 頻段： 除了表 I 所列的特徵，我們也研究不同 WiFi 頻段的連線耗時差異，即 2.4 GHz 與 5 GHz，結果如圖 8 所示。我們從特定連線嘗試的 SSID 推斷 WiFi 頻段。例如，若 SSID 為「Tsinghua-5G」，就推斷所有連上此 SSID 的嘗試均使用 5 GHz 頻段。

雖然只有一小部分 SSID 採用這種命名方式，但由於資料集規模很大，我們仍有足夠資料描述不同 WiFi 頻段的連線嘗試，如圖 8 所示。圖 8 的資料摘要列於表 III。

圖 8：不同 WiFi 頻段下連線耗時的 CDF。 曲線分別為 2.4 GHz 與 5 GHz 頻段；橫軸為連線耗時（秒），縱軸為 CDF（%）。

表 III：可辨識連線嘗試所使用頻段的資料摘要。

漫遊（Roaming）： 漫遊是企業網路中的重要功能。不同客製化企業網路可能有不同的漫遊設定，但家庭網路很少發生漫遊。企業網路漫遊對連線耗時的影響程度，是值得研究的議題。

企業網路中有兩種連線建立程序。第一次進入網路的無線站台會執行初始連線建立程序。另一種是漫遊，發生於站台已關聯至企業網路中的一個 AP，卻因使用者移動而想連至另一個具有相同 SSID 名稱的新 AP 時。

企業網路的初始連線建立程序與家庭網路略有不同，因為企業網路包含 IEEE 802.1X EAP（Extensible Authentication Protocol，可延伸驗證協定）程序，會增加以下耗時：

其中，$N_e$ 為 EAP 所需的往返次數，一般情況下等於 4；$T_w$ 為單向 WiFi 一跳延遲；$T_a$ 為 AP 與 AAA（Authentication, Authorization, and Accounting，驗證、授權與計帳）伺服器之間的有線延遲 [12]。家庭網路則使用預先共用金鑰（pre-shared key），因此不需要 EAP 程序 [13]。這些差異的量測結果將於第 V-B 節討論。

企業網路有兩種常見的快速切換（漫遊）方法：CAPWAP 與 HOKEY [12]。它們主要用來減少 EAP 程序帶來的額外耗時，而家庭網路並不包含 EAP 程序。此外，CAPWAP 與 HOKEY 仍需要與家庭網路相同的探索階段。我們的真實環境量測也證實這一點。

文獻 [12] 認為，相較於家庭網路中的連線嘗試，企業網路漫遊增加的時間最多為一次無線往返時間。CDF 結果顯示，企業網路漫遊的連線耗時與家庭網路連線耗時幾乎相同。

譯註：原文後一句將 CAPWAP 拼作「CAPAP」，此處統一為前文名稱。上述公式依 PDF 第 7 頁視覺內容轉錄；原文未補充更多推導。

V. 不同行動裝置與 AP 型號影響的特徵分析

本節進一步討論 AP 型號與行動裝置型號如何影響連線耗時。透過詳細分析，我們希望說明 AP 型號與行動裝置型號這兩個特徵包含額外資訊。[14] 與 [15] 的分析也證實這一點。若能從蒐集的資料集中預先學到這些資訊，就能大幅協助預測行動裝置的連線耗時。

A. 行動裝置型號如何影響連線耗時

表 II 的證據顯示，行動裝置型號對連線耗時具有高 RIG。我們試圖找出型號提供的隱含資訊，包括行動作業系統、晶片組、CPU 時脈、RAM 容量等。我們依平均連線耗時排序行動裝置型號，並選出表 IV 所示的一些熱門型號。每個型號至少包含 50 萬筆資料。

平均連線耗時只使用 RSSI 高於 -60 dBm 的連線建立程序計算，以排除低訊號強度的影響。每一類裝置型號，都包含數千名不同使用者連上數千個不同 AP 的資料。連線嘗試分布於一週內的所有日期與數千個不同地點。對各種環境中的連線耗時取平均，可以減輕時間與空間的影響，讓我們專注於裝置型號本身對連線耗時的作用。從表 IV 可得出下列結論。

晶片組會影響連線耗時。 以 MEIZU M1 Note 與 MEIZU M2 Note 為例。由表 IV 可知，兩部裝置來自同一家公司，具有相同作業系統與 RAM 容量。MEIZU M1 Note 與 MEIZU M2 Note 的晶片組，分別為 MediaTek 6752 與 MediaTek 6753。兩者都採用 ARM Cortex-A53 架構，晶片組上的 WiFi 模組也相同，皆為 MT6625L。這意味著無線介面的詳細規格相同，例如天線與濾波器。

主要差異在 CPU 時脈：MediaTek 6753 為 1.3 GHz，MediaTek 6752 為 1.7 GHz。圖 9a 繪出連線耗時的 CDF，顯示兩款手機的連線耗時存在很大差異。

即使硬體相同，作業系統仍然重要。 以 SAMSUNG G9280 與 MEIZU PRO 5 為例。表 IV 顯示兩者硬體設定幾乎相同，都使用相同晶片組 Exynos 7420、相同 CPU 與 RAM，唯一差別是作業系統。圖 9b 呈現兩款型號的連線耗時 CDF。

許多 MEIZU PRO 5 使用者抱怨其在 5 GHz 頻段的效能。為進一步找出問題，人們在兩款手機上安裝「WiFi Analyzer」，掃描周圍 5 GHz AP。MEIZU PRO 5 只能回報一個 5 GHz AP，且其接收訊號強度為 -80 dBm；SAMSUNG G9280 回報同一 AP 的訊號強度卻為 -60 dBm。此外，SAMSUNG G9280 能發現更多周圍的 5 GHz AP。

這可能是 MEIZU PRO 5 對 5 GHz 封包的訊號強度校準錯誤所造成，使系統因低訊號強度問題而丟棄大部分 5 GHz 封包。

表 IV：不同行動裝置型號的軟硬體參數。

圖 9： （a）顯示 CPU 時脈會影響連線耗時，比較 MEIZU M1 Note 與 MEIZU M2 Note；（b）顯示作業系統會影響連線耗時，比較 SAMSUNG G9280 與 MEIZU PRO 5。橫軸為連線耗時（秒），縱軸為 CDF（%）。

B. AP 型號如何影響連線耗時

1. 公共 AP 與私人 AP

調查過程中，我們發現一個可有效區分 AP 連線耗時的特徵，即表 I 的 IsPublic。若 IsPublic 為 TRUE，表示 AP 為公共 AP；否則為私人 AP。定義如下。

• 私人 AP： 為相對少量使用者提供私人 WiFi 服務的 AP。
• 公共 AP： 提供公共／開放 WiFi 服務的 AP。這些 AP 通常有較多已關聯使用者，且已關聯裝置的差異很大。

為比較公共 AP 與私人 AP 的連線耗時，我們手動將 20 萬個 AP 標記為公共或私人，並於圖 10 繪出兩類 AP 的連線耗時分布。由圖 10 可知，公共 AP 在一天中的連線耗時，持續高於私人 AP。圖 10 也顯示，私人 AP 的第 90 百分位連線耗時，持續低於 10 秒。

這個觀察告訴我們，AP 是否為公共 AP，是預測連線耗時的良好特徵；但要準確將 AP 標記為公共或私人並不容易。以下將處理這個問題。

圖 10：公共 AP 與私人 AP 在一天（5 月 3 日）中的連線耗時。 我們對每個小時，分別計算公共 AP 與私人 AP 連線耗時的最小值、第 25、第 75 與第 90 百分位。虛線分別表示平均連線耗時。橫軸為一天中的小時，縱軸為連線耗時（秒）；Public＝公共，Private＝私人。

2. 公共或私人特性如何協助預測連線耗時

直觀而言，我們發現部分 AP 型號，傾向只被部署來提供某一種 WiFi 服務，即私人或公共服務。例如，許多企業使用 Cisco 無線方案，而這些方案包含的 AP 型號種類有限。

為確認這一點，我們依 AP 型號，將手動標記的 20 萬個 AP 分組，共得到 2,802 種不同 AP 型號。統計結果顯示，27% 的 AP 型號只被用作公共 AP，32% 只被用作私人 AP。這意味著，如果我們預先學到這些 AP 型號資訊，就可以利用型號有效將 59% 的 AP 分為公共與私人。

這項發現促使我們在第 VI 節中，將 AP 型號加入機器學習模型，作為連線耗時分類的特徵。

譯註：原文由 27% 與 32% 的「型號比例」，直接敘述可分類 59% 的「AP」。這兩種分母未必相同；本譯文保留原文推論。

VI. 建模

前幾節研究了不同特徵的重要性，也了解了一些原因，可回答「為什麼我的連線時間這麼長？」這類問題。以下將聚焦於「我可以做什麼來縮短連線時間？」首先，使用表 I 中的特徵訓練機器學習模型，預測連線耗時；接著提出使用此模型的 AP 選擇演算法；最後，在蒐集的資料集中評估演算法的有效性。

A. 機器學習模型

模型選擇： 決策樹雖然具有可解釋性，也容易理解，但單一決策樹的準確度並不令人滿意。隨機森林透過隨機選取的特徵建立多棵決策樹，分類輸出為所有個別樹輸出類別的眾數。它是決策樹的集成，因此在多數情況下比單一決策樹表現更好。我們因此選擇隨機森林，預測每次連線嘗試的連線耗時。

我們以 15 秒為門檻，將連線嘗試標記為 FAST 或 SLOW。若一次連線嘗試耗時超過 15 秒，則標記為 SLOW；反之則標記為 FAST。這個門檻依程序拆解結果決定，見圖 4。耗時大於 15 秒與小於 15 秒的連線建立程序，表現出很大差異。

特徵選擇： 特徵選擇有兩項準則：（1）所有特徵都應容易由行動裝置量測；（2）在準確度可接受的前提下，盡量減少特徵數。

最終選擇用來訓練連線耗時模型的特徵，包括表 I 中的一天中的小時、RSSI、行動裝置型號、AP 型號，以及 Encrypted。根據第 V-B2 節分析，我們以 AP 型號取代 IsPublic，因為 IsPublic 可從行動裝置容易取得的 AP 型號推斷。

為使模型更便於使用，我們將裝置數量排除於特徵集合之外，原因有二：（1）裝置數量是 AP 端資訊，行動裝置很難取得；（2）移除裝置數量後，隨機森林模型仍具有可接受的準確度。最終選定供下一節使用的隨機森林模型，其準確度如表 V 所示。

表 V：隨機森林模型的準確度。 使用的參數為：樹深度＝90、樹數量＝100、權重＝0.3。

B. 我們以機器學習為基礎的 AP 選擇演算法

這部分使用先前訓練的機器學習模型，協助行動使用者選擇 AP，以縮短連線耗時。演算法可歸納為兩個步驟。

首先，對行動裝置候選清單中的每個 AP，蒐集表 V 所列特徵，輸入先前訓練的模型。若分類結果為 SLOW，就將 AP 加入 SLOW 集合；反之加入 FAST 集合。此步驟結束時，候選 AP 會被分為 SLOW 與 FAST 兩個集合。

接著，從 FAST 集合中選擇訊號最強的 AP，讓行動裝置連線，演算法至此結束。

C. 評估

本節使用蒐集的資料，評估演算法效能。比較用的基準演算法稱為「最強訊號強度」（Strongest Signal Strength）。它會協助行動使用者，從每部裝置的候選清單中，選擇訊號最強的 AP。這個方法相當簡單，但非常普遍，許多既有最新研究都採用它。

為進行評估，我們先將連線紀錄資料集分為兩部分，每部分各占整體資料的 50%。其中一部分用於模型調整，包括訓練與驗證；另一部分用於本節評估。評估資料集是機器學習模型從未見過的資料。這份全新資料集，確保我們能準確評估演算法部署至真實環境時的效能，因為真實環境中，許多 AP 先前未曾被行動裝置見過。

接著，我們在評估資料集上執行基準演算法與我們的演算法，協助資料集中的行動裝置選擇 AP。每個演算法輸出一份 AP 清單，包含其為每部行動裝置選擇的 AP。由於我們已知道連上這些 AP 的真實連線耗時，因此可以透過比較兩份輸出檔案，評估我們的演算法。

圖 11 顯示使用這兩種演算法後的連線耗時分布。若資料集中的所有行動裝置都採用「最強訊號強度」演算法，約 33% 的連線嘗試會失敗。在圖 11 中，我們將失敗連線嘗試的耗時記為 30 秒。

相較之下，若所有行動裝置都採用前述以機器學習為基礎的 AP 選擇演算法，失敗的連線嘗試少於 3.6%。其第 80 百分位耗時只有 3 秒，而基準演算法則超過 30 秒，相當於第 80 百分位連線耗時縮短 10 倍。

我們的演算法表現較佳，是因為基準演算法只依訊號強度選擇 AP。然而，即使某個 AP 在行動裝置上量測到的訊號強度最高，仍很可能發生連線失敗。我們的模型能以高準確度預先預測這些連線失敗事件，避免行動裝置連至 SLOW AP。

圖 11：AP 選擇演算法比較。 橫軸為連線耗時（秒），縱軸為 CDF（%）；Strongest Signal Strength＝最強訊號強度，Our Model＝我們的模型，failure＝失敗。

然而，此演算法有其限制：它會減少行動使用者可連線的 AP 數量，也就是 FAST 集合中的 AP 數。這是因為部分耗時低於 15 秒的 AP 可能被分類至 SLOW 集合，使 FAST 集合中的可用 AP 減少。因此，效能改善與可關聯 AP 數量之間存在取捨。

我們定義一項指標，稱為「可用 AP 比例」（Proportion of available APs，PoA）：

PoA 表示經模型分類後，FAST AP 所占的比例。表 VI 列出不同模型及其對應的 PoA。

表 VI：在不同 SLOW 召回率下，採用模型後，行動使用者可關聯之 AP 的對應比例（PoA）。

當隨機森林的 SLOW 召回率為 0.9 時，PoA 為 0.33。此 PoA 值表示，只要行動使用者周圍有超過三個候選 AP，我們的模型就能保證至少有一個 AP 可供關聯。這是可接受的，因為近期調查 [16]、[17] 顯示，在具代表性的都市地區，通常有數十個 AP 可供關聯。

譯註：上述「保證」為原文用語。整體 PoA＝0.33 本身並不能保證每位使用者的候選集合中至少有一個 FAST AP；原文也未交代 FAST 集合為空時的處理方式。圖 11 將失敗記為 30 秒，但正文又稱基準第 80 百分位「超過 30 秒」，此處保留原文措辭。

我們使用一個月內蒐集的所有紀錄訓練模型，再於下個月使用它預測連線耗時。每月初只需訓練一次。我們假設資料集規模足夠大，能涵蓋幾乎所有可能的參數組合。如何以適當權重，將上個月新蒐集的紀錄增量加入既有模型，是一個有趣議題，留待未來研究。

由於模型離線訓練，演算法唯一增加的負擔，是交換少量封包所需的時間，多數情況不超過 10 個封包。具體而言，將行動裝置蒐集的候選清單傳送至遠端伺服器，再從伺服器接收篩選後的清單。由於這些封包採管線化傳送，一次往返時間加上封包傳輸時間即可完成。

在 WiFi 成功關聯之前，行動裝置會使用其他方式，例如行動網路，與遠端伺服器通訊，其平均往返時間為毫秒等級。因此，相較於整體連線耗時，演算法增加的時間可以忽略。

譯註：第 IV-A 節介紹的是一週資料集，此處則敘述一個月訓練、下個月預測的方式；原文未詳細說明這兩種時間範圍之間的關係。

VII. 相關研究

有許多研究聚焦於 WiFi 效能量測 [18]–[21]。[18] 旨在估計特定 AP 與用戶端鏈路的可用吞吐量；[21] 探討 AP 端延遲。然而，根據我們前述量測，迫切需要關注連線建立耗時這個指標，因為高連線失敗率已經影響使用者體驗。

專注於連線建立程序的研究很少。目前大部分涉及連線建立程序的研究，都是關於 WiFi 切換機制：[22]–[29] 旨在縮短切換延遲。本文研究的連線建立程序與切換程序不同，因為切換程序包含在仍關聯至原 AP 的情況下，探索下一個 AP。

文獻 [2] 是首個聚焦於 WiFi 連線建立程序的研究。Suranga Seneviratne 等人從 13 部志願參與的行動裝置蒐集資料，提出一些觀察。然而，真實環境中連線建立耗時的分布仍未知。此外，採用大規模量測時，部分觀察可能不同。例如，我們發現，連線建立耗時超過 15 秒時，掃描階段才是主要耗時來源，而非 [2] 所述的 DHCP 階段。[25] 研究連線建立程序的不同階段，但其情境為車載環境。

VIII. 結論

雖然大部分既有最新研究聚焦於 WiFi 延遲與吞吐量，我們希望透過量測與分析，引起大家對 WiFi 連線建立耗時的重視。我們使用一款在 Android／iOS App 市場名列前茅的行動 WiFi Manager App，持續蒐集 4 億次 WiFi 連線嘗試。結果顯示，45% 的 WiFi 連線嘗試失敗，約 5% 的嘗試耗時超過 10 秒。

為進一步了解 WiFi 連線建立程序，我們將整體程序拆分為四個子階段，發現掃描階段是連線建立耗時過長事件的主要原因。相關性分析發現，雖然訊號強度很重要，但知道 AP 型號與行動裝置型號，也能大幅協助預測連線建立耗時。據我們所知，我們是首個將 AP 型號與行動裝置型號加入特徵，並藉此大幅提高連線建立耗時預測準確度的研究。

根據全面量測與詳細分析，我們提出以機器學習為基礎的 AP 選擇演算法。此演算法以 AP 特徵作為機器學習模型輸入，將候選 AP 分為 SLOW 或 FAST 集合。依分類結果，演算法會避免行動裝置連至被分類為 SLOW 的問題 AP。

評估結果顯示，相較於純粹依訊號強度選擇 AP 的基準演算法，我們能將連線失敗率由 33% 降至 3.6%，並使連線建立耗時的第 80 百分位縮短 10 倍。

譯註：結論將「約 5% 耗時超過 10 秒」寫為所有嘗試的比例，前文則主要以成功連線為分母；此處保留原文。

致謝

感謝匿名審查者提供寶貴意見。感謝騰訊 WiFi Manager 團隊成員部署客製化 App。感謝 Miao Tian 與 Juexing Liao 提供有益建議並協助校閱。

本研究獲得以下支持：中國國家自然科學基金（NSFC），計畫編號 61472210、61472214 與 61402247；中國國家自然科學基金重點計畫，編號 61233007；中國國家重點基礎研究發展計畫（973 計畫），編號 2013CB329105；中國國家高技術研究發展計畫（863 計畫），編號 2013AA013302；以及清華－騰訊網際網路創新技術聯合實驗室。

參考文獻

以下保留作者、出版來源、頁碼、年份與原文提供的連結，並翻譯文獻題名。原文書目若有拼寫或格式不整齊，未另行查證修訂。

1. Cisco VNI 2016 年報告。http://goo.gl/eqy2s2 。存取日期：2016 年 5 月 20 日。
2. Suranga Seneviratne、Aruna Seneviratne、Prasant Mohapatra、Pierre-Ugo Tournoux。〈WiFi 連線的特徵及其對行動使用者的影響：實務洞見〉（Characterizing wifi connection and its impact on mobile users: practical insights）。WiNTECH，頁 81–88，ACM，2013。
3. Yong Liao、Lixin Gao。〈802.11 無線網路中平順 MAC 層切換的實用方案〉（Practical schemes for smooth mac layer handoff in 802.11 wireless networks）。WOWMOM，頁 181–190，IEEE Computer Society，2006。
4. IEEE 802.11 Working Group 等。〈IEEE 802.11 標準〉（Ieee standard 802.11）。IEEE Std，802:11p，2010。
5. A. Bohk、L. Buttyn、L. Dra。〈WiFi 存取點之間快速切換的驗證方案〉（An authentication scheme for fast handover between wifi access points）。Proc. of ACM Wireless Internet Conference（WICON），2007。
6. Thomas M. Mitchell。《機器學習》（Machine learning）。Computer Science Series（McGraw-Hill，Burr Ridge，1997）MATH，1997。
7. Maurice George Kendall。《等級相關方法》（Rank correlation methods），1948。
8. F. Dobrian、V. Sekar、A. Awan、I. Stoica、D. Joseph、A. Ganjam、J. Zhan、H. Zhang。〈了解影片品質對使用者參與度的影響〉（Understanding the impact of video quality on user engagement）。SIGCOMM，41(4):362–373，2011。
9. A. Balachandran、V. Aggarwal、E. Halepovic、J. Pang、S. Seshan、S. Venkataraman、H. Yan。〈行動網路上的網頁體驗品質建模〉（Modeling web quality-of-experience on cellular networks）。MobiCom，頁 213–224，ACM，2014。
10. S. Vasudevan、K. Papagiannaki、C. Diot、J. Kurose、D. Towsley。〈協助 IEEE 802.11 無線網路中的存取點選擇〉（Facilitating access point selection in ieee 802.11 wireless networks）。IMC，頁 26–26，Usenix Association，2005。
11. X. Hu、L. Song、D. Van Bruggen、A. Striegel。〈有 WiFi 了嗎？積極的探測請求如何惡化能源消耗與吞吐量〉（Is there wifi yet?: How aggressive probe requests deteriorate energy and throughput）。IMC，頁 317–323，ACM，2015。
12. T. C. Clancy。〈企業無線區域網路中的安全切換：CAPWAP、HOKEY 與 IEEE 802.11r〉（Secure handover in enterprise wlans: capwap, hokey, and ieee 802.11r）。IEEE Wireless Communications，15(5):80–85，2008。
13. Wikipedia。〈IEEE 802.11i〉。https://en.wikipedia.org/wiki/IEEE_802.11i-2004 。存取日期：2017 年 1 月 9 日。
14. Hctor Velayos、Gunnar Karlsson、Trita imit-lcn R、Hctor Velayos、Gunnar Karlsson。〈縮短 IEEE 802.11b MAC 層切換時間的技術〉（Techniques to reduce ieee 802.11b mac layer handover time）。技術報告，ISSN 1651-7717，ISRN KTH/IMIT/LCN/R-03/02 SE，KTH，2003。
15. Arunesh Mishra、Minho Shin、William A. Arbaugh。〈IEEE 802.11 MAC 層切換程序的實證分析〉（An empirical analysis of the ieee 802.11 mac layer handoff process）。ACM Special Interest Group on Data Communication，33(2):93–102，2003。
16. A. Farshad、M. K. Marina、F. Garcia。〈透過行動群眾感測分析都市 WiFi 特性〉（Urban wifi characterization via mobile crowdsensing）。NOMS，頁 1–9，IEEE，2014。
17. A. S. Engineering、Q. Associates。〈Wi-Fi 用於都會區應用之研究〉（Study on the use of wi-fi for metropolitan area applications）。Final Report for Ofcom，2013。
18. A. Patro、S. Govindan、S. Banerjee。〈透過 WiFi AP 觀察家庭無線網路使用體驗〉（Observing home wireless experience through wifi aps）。MobiCom，頁 339–350，ACM，2013。
19. S. Grover、M. S. Park、S. Sundaresan、S. Burnett、H. Kim、B. Ravi、N. Feamster。〈窺探 NAT 背後：家庭網路的實證研究〉（Peeking behind the nat: an empirical study of home networks）。IMC，頁 377–390，ACM，2013。
20. S. Sundaresan、W. De Donato、N. Feamster、R. Teixeira、S. Crawford、A. Pescapè。〈寬頻網際網路效能：從閘道器觀察〉（Broadband internet performance: a view from the gateway）。SIGCOMM，41(4):134–145，2011。
21. S. Sundaresan、N. Feamster、R. Teixeira。〈量測家庭無線網路中使用者流量的效能〉（Measuring the performance of user traffic in home wireless networks）。PAM，2015。
22. S. Shin、A. G. Forte、A. S. Rawat、H. Schulzrinne。〈縮短 IEEE 802.11 無線區域網路的 MAC 層切換延遲〉（Reducing mac layer handoff latency in ieee 802.11 wireless lans）。MobiWac，頁 19–26，ACM，2004。
23. M. Shin、A. Mishra、W. A. Arbaugh。〈使用鄰居圖改善 802.11 切換延遲〉（Improving the latency of 802.11 hand-offs using neighbor graphs）。MobiSys，頁 70–83，ACM，2004。
24. Moo Ryong Jeong、Fujio Watanabe、Toshiro Kawahara。〈用於量測與切換的快速主動掃描〉（Fast active scan for measurement and handoff）。Contribution to IEEE 802，11，2003。
25. V. Bychkovsky、B. Hull、A. Miu、H. Balakrishnan、S. Madden。〈利用現地 Wi-Fi 網路進行車載網際網路存取的量測研究〉（A measurement study of vehicular internet access using in situ wi-fi networks）。MobiCom，頁 50–61，ACM，2006。
26. Anastasios Giannoulis、Marco Fiore、Edward W. Knightly。〈支援都市多跳無線網路中的車輛移動性〉（Supporting vehicular mobility in urban multi-hop wireless networks）。Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services，頁 54–66，ACM，2008。
27. Héctor Velayos、Gunnar Karlsson。〈縮短 IEEE 802.11b 切換時間的技術〉（Techniques to reduce the ieee 802.11 b handoff time）。Communications, 2004 IEEE International Conference on，第 7 卷，頁 3844–3848，IEEE，2004。
28. Jon-Olov Vatn。〈IEEE 802.11b 切換效能及其對語音流量影響的實驗研究〉（An experimental study of ieee 802.11 b handover performance and its effect on voice traffic）。技術報告，Citeseer，2003。
29. Yair Amir、Claudiu Danilov、Michael Hilsdale、Raluca Musloiu-Elefteri、Nilo Rivera。〈無縫無線網狀網路的快速切換〉（Fast handoff for seamless wireless mesh networks）。Proceedings of the 4th International Conference on Mobile Systems, Applications, and Services，頁 83–95，ACM，2006。