RFC-0243：WLAN 漫遊

RFC-0243：WLAN 漫遊
狀態已接受
區域
  • WLAN
說明

如果裝置連上無線網路，且該網路有多個存取點，裝置就能在這些存取點之間漫遊。「漫遊」是指裝置在同一個無線網路中，將連線從一個存取點 (AP) 移至另一個 AP，且不會在轉換期間完全中斷連線。
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2023-12-15
審查日期 (年-月-日)2024-04-11

編輯這份 RFC

編輯 RFC 中繼資料

摘要

如果裝置連上無線網路，且該網路有多個存取點，裝置就能在這些存取點之間漫遊。「漫遊」是指用戶端裝置將連線從一個存取點 (AP) 移至同一無線網路中的另一個 AP，且不會在轉換期間完全中斷連線。裝置可能因為許多原因而漫遊：也許裝置已從目前的 AP 移到更遠的地方，並靠近另一個 AP；或者裝置與目前 AP 的連線可能因某種原因而品質下降 (例如錯誤率偏高)。在這種情況下，裝置可能會嘗試漫遊至其他 AP，避免完全中斷連線。本文將說明支援 Fullmac 發起和 WLAN 政策發起的漫遊時，必須進行的 API 變更和邏輯。

提振精神

有時裝置必須使用與目前不同的 AP，才能維持 WLAN 連線。最常見的原因如下：

  • 目前 AP 無法連線
  • 與目前 AP 的連線品質變差

漫遊功能可讓裝置使用 802.11 重新關聯，在切換至新的 AP 時盡量減少服務中斷。如果沒有漫遊功能，裝置必須先與原始 AP 中斷連線 (或得知已中斷連線)，然後終止所有網路連線，再開始連線至新的 AP。

如果裝置支援漫遊，則可選取新的 AP，同時仍連線至原始 AP，並執行重新關聯。據觀察，重新關聯約需 70 毫秒，而先中斷連線再重新連線則約需 130 毫秒。雖然重新關聯並非萬靈丹，但其他可進一步減少中斷的機制需要重新關聯支援。一旦漫遊的基礎架構就位 (即此設計)，日後就能進行一系列漫遊強化作業，例如：

  • 在發生中斷前漫遊：透過 BSS 轉換管理 (IEEE 802.11-2020 4.3.19.3)，存取點可以在即將發生中斷前通知裝置應漫遊。
  • 縮短漫遊中斷時間，有時甚至可完全避免中斷：透過快速 BSS 轉換 (IEEE 802.11-2020 4.5.4.8)，裝置可以在離開原始 AP 前，執行漫遊的大部分高風險和耗時步驟。
  • 善用硬體卸載：某些 Fullmac 晶片韌體提供的漫遊功能卸載可實作漫遊通訊協定、在晶片上執行漫遊邏輯 (而非在 OS 中)，進而減少耗電量，並縮短漫遊決策與漫遊開始之間的延遲時間。
  • 讓 WLAN 政策進一步控管連線：WLAN 政策正在進行重大作業，以決定漫遊的時間和地點。如本文所述，API 和邏輯變更對於允許 WLAN 政策啟動漫遊，以及在漫遊嘗試完成時做出回應至關重要。

利害關係人

協助人員：

neelsa@google.com

審查者：

  • silberst@google.com：適用於 WLAN
  • karthikrish@google.com：適用於 WLAN 驅動程式
  • swiggett@google.com：適用於 WLAN Core
  • haydennix@google.com：適用於 WLAN 政策
  • sbalana@google.com：用於連線自動化測試

已諮詢：

  • 網路堆疊：brunodalbo@google.com
  • 網路政策：dhobsd@google.com
  • WLAN Core：chcl@google.com、kiettran@google.com
  • WLAN 驅動程式：rsakthi@google.com
  • WLAN 政策：mnck@google.com、nmccracken@google.com

社交：

  • 我們為 WLAN Core 邏輯的可能實作方式建立多個變體原型，並在與 WLAN Core 和 WLAN 團隊負責人分別召開的會議中討論這些原型
  • 草案 RFC 已發布，並與連線驅動程式、WLAN Core、WLAN 政策、網路政策和網路堆疊團隊詳細討論
  • 我們草擬了多份輔助文件，探討相關主題，特別是 SME 狀態機變更、EAPOL 行為和中斷連線行為

需求條件

本文中的「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」等關鍵字，應按照 IETF RFC 2119 的說明解讀。相關規定如下。

條款

  • 裝置：802.11 無線網路中的用戶端裝置；以 802.11 術語來說，本文中的「裝置」是指非 AP STA
  • 站台 (STA)：連線至 802.11 無線網路的裝置
  • 存取點 (AP)：透過 802.11 無線網路通訊協定，將一或多個用戶端裝置連線至網路
    • 目前 AP：裝置連線至無線網路時，一次只能與一個 AP 建立關聯；目前 AP 是指裝置目前關聯的 AP
    • 原始 AP：裝置在漫遊嘗試開始時關聯的位置
    • 目標 AP：裝置嘗試漫遊至其他 AP 時，目標 AP 是裝置嘗試關聯的位置；成功嘗試漫遊後，目標 AP 會成為目前的 AP
  • 漫遊：用戶端裝置將連線從一個 AP 移至同一無線網路內的另一個 AP，且在轉換期間不會完全中斷連線；本文中的「漫遊」是指為移動連線而採取的一系列動作，包括向目標 AP 進行驗證和重新關聯，以及 Fuchsia WLAN 軟體層之間的協調
  • 重新關聯：802.11 指定的機制，可將用戶端裝置的關聯從一個 AP 移至另一個 AP (請參閱 IEEE 802.11-2020 4.5.3.4)

設計

漫遊協調作業需要 FIDL API 變更，幾乎會影響所有 WLAN：Fullmac、MLME、SME 和 WLAN 政策。本 RFC 中指定的 API 支援兩種主要作業模式：

在由 Fullmac 啟動的漫遊中，漫遊的時間和地點是由 Fullmac 韌體決定。如要順利漫遊，漫遊開始時「必須」透過 MLME 和 SME 向上傳達，漫遊結果「必須」透過 MLME、SME 向上傳達，並傳送至 WLAN 政策。Fullmac 啟動的漫遊嘗試會從 Fullmac 發出 RoamStartInd 開始，而漫遊嘗試的結果會導致 WLAN 政策收到 ConnectTransaction.OnRoamResult。訊息會經過下列路徑：

  • Fullmac 韌體漫遊開始通知 Fullmac 驅動程式庫 -> Fullmac RoamStartInd -> MLME RoamStartInd -> SME
  • Fullmac 韌體漫遊結果通知傳送至 Fullmac 驅動程式庫 -> Fullmac RoamResultInd -> MLME RoamResultInd -> SME ConnectTransaction.OnRoamResult -> WLAN 政策

在 WLAN 政策啟動的漫遊中，漫遊時間和地點的決定是由 WLAN 政策做出，且必須透過 SME、MLME、Fullmac 驅動程式庫向下傳達，最後傳入裝置韌體。裝置韌體會嘗試漫遊，且漫遊嘗試的結果必須透過 Fullmac、MLME、SME 回報至 WLAN 政策。WLAN 政策啟動的漫遊嘗試會先由 WLAN 政策發出 ClientSme.Roam，漫遊嘗試的結果最終會讓 WLAN 政策收到 ConnectTransaction.OnRoamResult。訊息會經過下列路徑：

  • WLAN 政策 -> SME ClientSme.Roam -> MLME RoamReq -> Fullmac RoamReq -> Fullmac 韌體漫遊指令
  • Fullmac 韌體漫遊結果通知傳送至 Fullmac 驅動程式庫 -> Fullmac RoamConf -> MLME RoamConf -> SME ConnectTransaction.OnRoamResult -> WLAN 政策

如要實作這些 API 變更，WLAN 中會出現下列邏輯變更：

  • Fullmac 驅動程式庫會變更，以傳送啟動漫遊的韌體指令，並回應韌體傳送的漫遊進度和最終結果通知
  • MLME 會在漫遊期間變更，以開啟/關閉 802.1X 控制的連接埠，並完成驗證、重新關聯和 RSNA 設定
  • SME 變更，導入新的內部 SME 用戶端狀態 (「漫遊」)
  • SME 和 WLAN 政策異動，讓 WLAN 政策能夠啟動漫遊，並通知 WLAN 政策漫遊結果 (無論漫遊是由 Fullmac 啟動或 WLAN 政策啟動，WLAN 政策都會收到相同的漫遊結果通知)

本 RFC 並未指定 Fullmac 或 WLAN 政策應如何做出漫遊決策，僅建議漫遊決策：

  • 決定是否漫遊時，應納入可用的高階連線訊號 (例如 AP 的網際網路連線)
  • ，並應在漫遊成功後納入類似信號，以評估漫遊是否產生可用的連線

中小企業會取得新的「漫遊」內部用戶端狀態

中小企業必須追蹤用戶漫遊時的特定資料，並管理漫遊狀態與其他內部狀態之間的轉換。系統會在 SME 用戶端狀態機器中新增名為「Roaming」的新內部狀態。與 SME Connecting 狀態類似，Roaming 狀態是 SME 嘗試驗證及與 AP 建立關聯的狀態 (我們將此 AP 稱為「目標 AP」)。兩者之間有幾項主要差異：

  • 只有從「已關聯」狀態轉換為「漫遊」狀態才有效； 而從其他狀態轉換為「連線中」狀態則有許多有效轉換
  • 漫遊會特別處理特定事件的接收作業；當連線在收到 802.11 取消驗證時轉換為閒置狀態，或在收到取消關聯時轉換為中斷連線狀態，漫遊必須只處理來自目標 AP 的取消驗證和取消關聯框架
  • 漫遊狀態會處理 Connecting 無法處理的事件 (RoamResultInd 和 RoamConf)
  • 當 SME 從「已關聯」移至「漫遊」時，由於 SME 嘗試連線至目標 AP，因此目前的 AP 會變更；在「已關聯」和「連線中」之間轉換時，AP 不會變更

以下是中小企業客戶狀態機器的概略總覽 (紅色部分為變更)：

SME 狀態機器總覽圖，顯示新的 Roaming 狀態和 SME 狀態之間的轉換

以下是 Fullmac 啟動漫遊的更詳細中小企業客戶狀態機圖表，顯示順利路徑 (RoamStartInd 後接成功 RoamResultInd) 和相關失敗路徑：

SME 狀態機器圖，顯示在 Fullmac 啟動漫遊時，導致漫遊和其他 SME 狀態之間轉換的事件

以下是類似的 WLAN 政策啟動漫遊中小企業用戶端狀態機圖表，顯示順利路徑 (RoamReq 後接成功 RoamConf) 和相關失敗路徑：

SME 狀態機器圖，顯示導致漫遊和其他 SME 狀態之間轉換的事件 (WLAN 政策啟動的漫遊)

如要進一步瞭解 SME 如何轉換至/離開「漫遊」狀態，請參閱下方的「Fullmac 啟動漫遊」和「WLAN 政策啟動漫遊」一節。

Fullmac 啟動漫遊

部分 Fullmac 裝置韌體可設定漫遊的時間和地點。 以下概略說明 WLAN 如何處理 Fullmac 啟動的漫遊：

堆疊圖：顯示 Fullmac 啟動漫遊時，漫遊開始和漫遊結果訊息的流程

當 Fullmac 啟動漫遊嘗試時 (上圖中的步驟 1)，Fullmac 驅動程式庫「必須」將 RoamStartInd 傳送至 MLME (上圖中的步驟 2)。韌體開始驗證或重新關聯至目標 AP 前，必須先傳送 RoamStartInd。與 ConnectReq (建立與 AP 的初始連線) 類似，RoamStartInd 包含目標 AP 的 BSS 說明。MLME 應向 SME 提供完整的 BSS 說明 (請參閱下方步驟 4)。

RoamStartInd 也「必須」包含：

  • 目標 AP 的 BSSID (分開儲存，以防缺少 BSS 說明)
  • 布林值，指出在漫遊開始時間是否維持原始關聯 (如需快速 BSS 轉換支援，請參閱附錄 A)。

隨著更多漫遊功能實作完成，RoamStartInd 中可能會新增其他欄位。

由於漫遊嘗試必須使用與連線至原始 AP 時相同的安全設定，因此 Fullmac 必須保留用於初始連線至 AP 的原始安全設定。Fullmac 不得重新關聯至與初始連線所用原始安全設定不符的 AP。詳情請參閱附錄 D：重新關聯要求安全設定。

漫遊嘗試進行中時，Fullmac 驅動程式庫會執行下列動作：

  • 可能拒絕連入掃描要求 (目前只有 Fullmac 驅動程式庫 brcmfmac 會這樣做)
  • 漫遊嘗試開始時，MAY 會取消進行中的掃描
  • 必須針對傳入的連線要求傳回錯誤
    • 這與現有的 Fullmac 行為 (在 brcmfmac 中) 類似，如果連線嘗試正在進行中，Fullmac 不會處理 (並會傳回錯誤) 傳入的連線要求；如果漫遊嘗試正在進行中，我們也會對連線嘗試執行相同操作
  • 針對傳入的漫遊要求，必須傳回錯誤
    • 再次嘗試，與 Fullmac 中現有的連線行為類似，但適用於漫遊嘗試
  • 必須處理傳入的連線中斷要求

由於這些限制，Fullmac 驅動程式庫「必須」設定內部漫遊逾時，才能完成 802.11 驗證和重新關聯。逾時時間不包括任何重新關聯後動作 (例如 EAPOL、DHCP)。如果重新建立關聯作業未在逾時前完成：

  • 如果原始關聯性未維持，Fullmac 必須啟動中斷連線
  • 如要瞭解支援快速 BSS 轉換時的變更，請參閱附錄 A

漫遊逾時是為了避免卡在無法執行掃描和連線等重要功能的狀態。逾時時間應設定得比一般驗證和重新關聯時間長得多 (據觀察，這類時間約為 100 毫秒)。合理的預設漫遊逾時時間可能約為 1 秒。

當 MLME 收到來自 Fullmac 的 RoamStartInd (步驟 2 和 3) 時，必須關閉 802.1X 控制的通訊埠。此時，MLME「必須將裝置視為：

  • 已透過原始 AP 驗證
  • 與原始 AP 無關
  • 處於待處理 RSNA 狀態 (如果安全性設定需要 RSNA)

MLME 會透過 MLME RoamStartInd (步驟 4) 通知 SME 漫遊已開始。 SME 會使用 MLME RoamStartInd 中的 BSS 說明，與 Fullmac 協調執行 802.11 驗證和 RSNA 設定。如果 MLME RoamStartInd 提供的 BSS 說明遺失或無效，SME 必須讓漫遊失敗。

收到 MLME RoamStartInd 後，SME 會更新內部狀態，表示裝置正在漫遊。SME 中已維護重要的狀態和邏輯，以支援驗證和 RSNA，這些程序會與 Fullmac 韌體/驅動程式庫程式和 MLME 協調執行。Fuchsia WLAN 使用 SME 做為 802.11 驗證器 (而非 Fullmac 韌體可能提供的驗證器)。此外，Fuchsia WLAN 會使用 SME 做為 RSNA 的外部 Supplicant (而非使用韌體 Supplicant 或 wpa_supplicant 等第三方 Supplicant)。

如果 SME 偵測到格式錯誤的 RoamStartInd (例如缺少欄位或資料無效)，SME 就會知道漫遊因內部錯誤而失敗。Fullmac 發出 RoamStartInd 時，裝置仍與原始 AP 建立關聯，但 Fullmac 可能在不久後離開原始 AP 的管道和/或頻帶。中小企業會採取下列行動：

  • 即使 RoamStartInd 指出原始關聯性仍維持不變，中小企業也必須將此視為中斷連線，否則無效的漫遊嘗試可能會繼續
  • 中小企業「必須」向 WLAN 政策團隊傳送 OnRoamResult，指出連線中斷是因 RoamStartInd 格式錯誤所致。
  • SME 必須將取消驗證傳送至目標 AP
  • SME 可能會將取消驗證傳送至原始 AP
  • 中小企業「必須解除連結」

如果 RoamStartInd 沒有格式錯誤，中小企業「必須」轉換至漫遊。

請注意，WLAN 政策不會收到漫遊開始的通知。換句話說，RoamStartInd會向上傳播至 SME，但漫遊的開始不會透過 ConnectTransaction 通訊協定傳達至 WLAN 政策。在設計階段，WLAN 原則團隊認為不需要這類事件，但如果需要，可以新增這類事件。從實際漫遊的觀察結果來看，如果 WLAN 政策沒有收到漫遊開始通知，WLAN 政策就會在短時間內不知道漫遊正在進行中；從 SME 將漫遊開始事件傳送至 WLAN 政策，可將這段時間縮短約 50 毫秒。

將 RoamStartInd 傳送至 MLME 後，Fullmac 韌體會開始與目標 AP 進行 802.11 驗證程序 (步驟 5)。驗證作業會與較高層級協調，方式與一般連線相同。802.11 驗證完成後，韌體會開始與目標 AP 重新建立 802.11 關聯。(如要瞭解如何協調驗證、重新關聯和 RSNA，請參閱 IEEE 802.11-2020 11.3.5.4)。 Fullmac 開始重新關聯交換作業後，裝置就不再與原始 AP 建立關聯 (但請參閱「展望快速 BSS 轉換」一節，瞭解一些細微的詳細資料)。

如果 Fullmac 啟動的漫遊嘗試成功、失敗或逾時 (步驟 6)，Fullmac 驅動程式庫必須將 RoamResultInd 傳送至 MLME (步驟 7 和 8)。RoamResultInd 提供的資訊與 ConnectConf 類似。最重要的是，這項資訊包含漫遊嘗試的 802.11 狀態碼。與 RoamStartInd 類似，RoamResultInd 必須包含布林值欄位，指出是否要維持原始關聯 (請參閱「展望快速 BSS 轉換」)。如果漫遊成功，original_association_maintained「必須」為 false，因為漫遊成功一律會導致與原始 AP 取消關聯。

RoamResultInd 也「必須」包含布林值欄位，指出裝置是否已透過目標 AP 驗證：

  • 如果漫遊嘗試成功，則 target_bss_authenticated 必須為 true
  • 如果 status_code 不是 success，target_bss_authenticated 會指定裝置目前是否已透過目標 AP 驗證
  • 這個欄位會顯示目標 AP 的驗證狀態，通知中小企業，因為中小企業「可能」會在漫遊嘗試失敗後進行清理時，決定傳送取消驗證要求給目標 AP

收到 RoamResultInd 後，MLME 必須保持 802.1X 控制埠關閉 (但請參閱「展望快速 BSS 轉換」)。如果漫遊成功：

  • 裝置「必須」與指定的 AP 建立關聯
  • 裝置「可能」仍會透過原始 AP 進行驗證
  • 裝置「不得」與原始 AP 建立關聯

如果漫遊失敗：

  • 裝置「可能」仍會透過原始 AP 進行驗證
  • 裝置「可能」會透過目標 AP 進行驗證，如 target_bss_authenticated 所示

MLME 會將 RoamResultInd 傳送給 SME (步驟 9)。

收到 MLME RoamResultInd 後，如果漫遊成功，SME 會執行下列操作：

  • SME 必須將內部狀態從「漫遊」移至「已關聯」，並將目標 AP 設為目前的 AP
  • 收到原始 AP 的任何取消關聯/取消驗證框架後，主題專家「不得」脫離「已關聯」狀態
  • 如果安全設定需要 RSNA：系統會設定 RSNA，並在 Fullmac 韌體、Fullmac 驅動程式庫、MLME 和 SME 之間協調，方式與首次連線時的 RSNA 設定相同
  • 成功設定 RSNA 後 (或網路不需要 RSNA 時)，802.1X 控制通訊埠會以一般成功連線的方式開啟

如果 RoamResultInd 指出漫遊失敗，SME 會改為執行下列操作：

  • 如果 target_bss_authenticated 為 true：
    • 主題專家「可以」要求從原始 AP 取消驗證 (但請參閱「中斷連線行為」一節，瞭解此處的細微差異)
    • SME MAY request deauthentication from the target AP
    • 如果中小企業決定要求從目標 AP 取消驗證，中小企業「必須」從「漫遊」轉換為「正在中斷連線」
    • 否則，中小企業「必須」從「漫遊」轉換為「閒置」
    • 如果目標 AP 的 SAE 超時：
      • SME 可要求從原始 AP 取消驗證
      • 中小企業必須直接從「漫遊」轉換為「閒置」
  • 如果 target_bss_authenticated 為 false：
    • 主題專家「可以」要求從原始 AP 取消驗證 (但請參閱「中斷連線行為」一節，瞭解此處的細微差異)
    • 如果主題專家決定要求從原始 AP 取消驗證，主題專家「必須」從「漫遊」轉換為「中斷連線」
    • 否則，中小企業「必須」從「漫遊」轉換為「閒置」

SME 會透過每個連線的管道，使用現有的 ConnectTransaction API 與 WLAN 政策通訊。中小企業必須傳送 OnRoamResult 給 WLAN 政策，通知漫遊嘗試已完成 (步驟 10)。RoamResult與中小企業 (SME) ConnectResult 類似，RoamResult：

  • 必須包含目標 AP 的 BSSID
  • 必須包含指出漫遊是否成功的狀態碼
  • 必須包含布林值，指出原始關聯是否已維持
  • 無論成功/失敗，都應包含目標 AP 的 BSS 說明 (但如果漫遊失敗，這個欄位可能為空白)
  • 如果發生連線中斷，則必須包含主題專家 DisconnectInfo；換句話說，如果漫遊失敗且原始關聯未維持，則必須包含主題專家

收到 OnRoamResult 後，WLAN 政策會更新內部狀態。如果漫遊成功，WLAN 政策「必須」繼續透過 SME 維護現有的 ConnectTransaction，但裝置現在會與目標 AP 建立關聯。如果結果顯示漫遊失敗：

  • 如果原始關聯未保留，WLAN 政策「必須」關閉 ConnectTransaction 並結束連線
  • 漫遊失敗後，WLAN 政策會開始建立新連線的程序，與回應任何連線中斷的情況類似

WLAN 政策啟動的漫遊

WLAN 政策將可發起漫遊嘗試並瞭解結果。以下概略說明 WLAN 如何處理 WLAN 政策啟動的漫遊：

堆疊圖：顯示 WLAN 政策啟動漫遊時，漫遊要求和漫遊確認訊息的流程

當 WLAN 政策啟動漫遊嘗試時，會向 SME 發出 ClientSme.Roam (上圖中的步驟 1)。Roam 包含 RoamRequest，概念上與 SME ConnectRequest 類似，但選項較少，因為漫遊期間不得變更 SSID 和安全性設定 (如需漫遊期間使用的安全性設定背景資訊，請參閱附錄 D：重新關聯安全性設定)。

由於漫遊嘗試「必須」使用與連線至原始 AP 時相同的安全性設定，因此漫遊至目標 AP 時，WLAN 政策「必須」保留用於初始連線至 AP 的原始安全性設定。WLAN 政策不得嘗試重新與不符合初始連線所用原始安全設定的 AP 建立關聯。

為使 WLAN 政策保留用於連線至原始 AP 的安全設定，必須先取得該設定，因此 SME ConnectTransaction.ConnectResult 必須取得新欄位，告知 WLAN 政策原始關聯要求中使用的確切安全設定。

收到 WLAN 政策的 ClientSme.Roam 時，SME 的行為與收到 MLME 的 RoamStartInd 時相同，但會將 RoamReq 下傳至 MLME (步驟 2)。

收到 SME 的 RoamReq 後，MLME 的行為與收到 Fullmac 的 RoamStartInd 時相同，但會將 RoamReq 傳送至 Fullmac (步驟 3 和 4)。

收到 MLME 的 RoamReq 後，Fullmac 會將指令傳送至韌體，開始進行驗證和重新關聯程序 (步驟 5)，然後韌體會像 Fullmac 啟動漫遊時一樣執行操作 (步驟 6)。韌體將漫遊嘗試結果通知 Fullmac 驅動程式庫 (步驟 7) 時，Fullmac 會將 RoamConf 傳送至 MLME (步驟 8 和 9)。RoamConf 類似於 RoamResultInd。

收到 RoamConf 時，MLME 的行為與收到 RoamResultInd 時相同，但會將 RoamConf 傳送至 SME (步驟 10)。

收到 RoamConf 後，SME 的行為與收到 MLME 的 RoamResultInd 時相同。主題專家透過 ConnectTransaction (步驟 11) 將 OnRoamResult 傳送至 WLAN 政策。

收到 OnRoamResult 後，WLAN 政策會採取與上述 Fullmac 啟動漫遊結束時相同的動作。

實作

第 1 階段：導入 API 和邏輯，但不推送至正式版裝置

您可以在兩項 Gerrit 變更中進行 API 變更：一項是 Fullmac 啟動的漫遊，另一項是 WLAN 政策啟動的漫遊。

目前漫遊變更的策略是導入漫遊邏輯變更，但不會在正式版裝置上啟用。Fullmac 啟動的漫遊 是由 brcmfmac 驅動程式庫中的驅動程式庫功能保護。我們提供單元和整合測試，確保漫遊功能已停用，避免意外啟用。

如果是 WLAN 政策啟動的漫遊，在 WLAN 政策確定可以啟用之前，API 可以導入，不必呼叫 SME ClientSme.Roam/ConnectTransaction.OnRoamResult API。有了這個 API，WLAN 政策就能開始將漫遊成功/失敗做為連線品質追蹤的輸入內容，WLAN 政策邏輯也能決定是否要對特定 AP 使用 ClientSme.Roam API，甚至決定是否要使用 ClientSme.Roam API。

WLAN 政策必須能夠在介面建立時啟用或停用漫遊功能。這項功能可讓 WLAN 政策：

  • 瞭解特定介面上是否已啟用或停用 Fullmac 啟動的漫遊
  • 在發生執行階段問題時，完全停用介面上的漫遊功能

如要支援這項需求，必須對 fuchsia.wlan.device 進行簡單的 API 變更。 如要進行最簡單的實作，只需在 CreateIfaceRequest 中新增單一欄位，讓呼叫端指定介面建立期間必須啟用的漫遊功能。

請注意，如果是 Fullmac 介面，現有韌體只能在建立介面時啟用漫遊卸載等功能。

階段 2：整合測試

如要測試 Fullmac 啟動的漫遊功能，可以在本機開發人員版本上進行測試 (例如取消註解 brcmfmac Fullmac 驅動程式庫程式程式碼中的漫遊功能)，並使用 Antlion 在實際裝置和 AP 硬體上進行整合測試。Fullmac 啟動漫遊 (WlanWirelessNetworkManagementTest) 的 Antlion 整合測試套件已存在，可測試漫遊嘗試成功與否。現有的測試套件需要具備 Fuchsia Fullmac 功能的裝置，並在單一實體 AP 裝置上，在兩個網路之間漫遊。我們也預期會推出新的 Antlion 測試套件，涵蓋更多 Fullmac 啟動的漫遊情境，進一步提升整合涵蓋範圍。

如果是 WLAN 政策啟動的漫遊，可以在本機開發人員版本測試變更，並使用 Antlion 在實際裝置和 AP 硬體上進行整合測試 (方法是賦予 WLAN 政策在執行階段啟用介面漫遊的功能，請參閱上文第 1 階段的討論)。此外，我們也預期會透過新的 Antlion 測試套件，增加整合涵蓋範圍，以因應其他 WLAN 政策啟動的漫遊情境。

執行 Fullmac 啟動或 WLAN 政策啟動漫遊的 Antlion 測試套件，必須知道 Fuchsia 受測裝置 (DUT) 是否正在使用這些功能。這是必要步驟，因為 Antlion 需要知道是否要在該 DUT 上執行或略過漫遊測試。對於現有的 Fullmac 啟動漫遊測試套件，Antlion 設定具有 WLAN 功能的特殊指令：Antlion 設定中是否有漫遊功能，會決定 Antlion 是否執行 Fullmac 啟動漫遊測試，否則會略過這些測試。實作時「應」明確賦予 Antlion 查詢功能支援 (使用 WLAN 驅動程式功能) 的能力，並「應」明確賦予 Antlion 在 DUT 上執行測試前，啟用 DUT 漫遊功能的能力。

現有的 Fullmac 啟動漫遊 Antlion 測試套件，以及任何新的測試套件，都必須在連線自動化測試平台 (搭配 WLAN Antlion 測試平台) 上執行。

可發起漫遊的 Fullmac WLAN 測試平台：

  • 必須包含至少一個可發起漫遊的實體 Fuchsia 裝置
  • 必須包含與 Antlion 相容的實體 AP 裝置，能夠提供兩個以上的同步 AP (以 802.11 來說，即為同一 ESS 內的兩個以上 BSS)
  • 應允許變數信號衰減
  • MAY enclose devices in radio shields to decrease interference

如果這類測試平台可用，開發人員就能使用現有的 Antlion tryjobs 基礎架構，針對進行中的變更執行這些測試。

此外，您可能也會使用更深入的整合測試 (例如使用第三方實驗室測試漫遊情境)。

階段 3：在正式版裝置上推出

整合測試結果出爐後，即可開始推出。如上文第 1 階段所述，WLAN 政策「必須」能夠根據每個介面啟用及停用漫遊功能。

Fullmac 啟動和 WLAN 政策啟動的漫遊功能推出作業，將由 WLAN 政策控管，並使用 WLAN 政策的典型功能推出機制 (或選擇使用新的推出機制)。WLAN 政策已具備連線選取、連線品質和連線失敗復原的邏輯。WLAN 政策通常會在運作過程中頻繁變更這些函式。WLAN 政策可能會導入漫遊專用的額外執行階段安全措施，但本 RFC 不會嘗試指定這些措施。

效能

在推出階段，我們需要評估的指標包括：

  • 漫遊嘗試次數 / 漫遊成功次數 (以次數和比率表示)
  • 漫遊完成時間 (以直方圖表示)
  • 漫遊逾時 (次數和比率)
  • 漫遊成功，但介面無法使用 (如計數)
  • 漫遊失敗原因，按 DisconnectInfo 分類 (大致上是中斷來源和原因)
  • 漫遊時間過長

我們也需要監控非漫遊專屬的指標：

  • 非漫遊中斷次數 (不應大幅增加)
  • 正常運作時間比率 (不應大幅降低)
  • 閒置介面自動連線的數量 (不應顯著增加)

人體工學

這項 RFC 並未指定任何漫遊使用者控制項。其他作業系統不允許使用者控管漫遊 (例如 macOS)，或僅允許透過特殊設定進行非常有限的控管 (例如 Windows、Linux)。目前我們不希望 WLAN 政策為使用者提供漫遊控制選項。因此，Fuchsia 終端使用者不會因導入 Fullmac 啟動或 WLAN 政策啟動的漫遊功能，而承受顯著的認知負荷。預期使用者只會看到存取點之間的轉換速度變快。對終端使用者而言，漫遊失敗與任何其他連線中斷並無不同，而從中斷狀態恢復連線的方式，也與未涉及漫遊的連線中斷相同：進行一般掃描並連線。

回溯相容性

早在 Fuchsia 推出之前，802.11 規格就已包含漫遊 (重新關聯)。

向後相容性的主要考量是，導入漫遊功能後，現有許多使用 Fuchsia WLAN 的裝置不會經常發生網路連線無法使用的情況。如上方的推出時間表所述，賦予 WLAN 政策明確決定啟用和使用漫遊功能時機的能力，將有助於確保漫遊功能不會導致介面效能降低或無法使用。WLAN Policy MAY：

  • 節流漫遊掃描
  • 將有問題的 AP 加入拒絕清單
  • 實作輪詢機制，限制漫遊嘗試次數
  • 在執行階段停用漫遊

安全性考量

有三項安全疑慮：

  • 原始 AP 和目標 AP 必須使用相同的 SSID
  • 目標 AP 必須符合連線至原始 AP 時指定的安全參數
  • 一向由 WLAN 政策決定要連線的 AP；Fullmac 發起的漫遊會將部分責任委派給 Fullmac 韌體

WLAN SME 已驗證 SSID 和安全參數與原始安全設定相符，且會使用相同機制驗證目標 AP 的 SSID 和安全參數。如果這些驗證步驟失敗，連線就會中斷。如要進一步瞭解漫遊嘗試中使用的安全性設定，請參閱附錄 D。

至於選擇存取點的責任歸屬：

  • 如果是 Fullmac 啟動的漫遊，Fullmac 韌體找到合適的漫遊 AP 後，我們會明確授權漫遊至該 AP。在完成漫遊的過程中，WLAN SME 會驗證 AP 是否適用於原始安全設定 (如附錄 D 所述)。
  • 如果是 WLAN 政策啟動的漫遊，WLAN 政策已負責決定要連線的 AP。WLAN 政策啟動的漫遊只提供不同的機制，用於連線至目標 AP (使用 802.11 重新關聯，而非 802.11 關聯)。

隱私權注意事項

這項設計提供 API，可讓 Fullmac 和 WLAN 政策啟動漫遊並瞭解漫遊結果。這些動作會使用與現有 (非漫遊) 連線和中斷連線邏輯相同的資訊。這項設計不會改變 WLAN 軟體目前的隱私權狀態。

測試

  • Fullmac 驅動程式庫已有單元測試 (使用 brcmfmac Sim Framework)
  • 針對 Fullmac 啟動的漫遊 (使用 Antlion WlanWirelessNetworkManagementTest 套件)，現已在真實裝置和 AP 硬體上進行整合測試
  • 我們會建立更多整合測試，以練習 Fullmac 啟動和 WLAN 政策啟動的漫遊情境
  • 連線自動化團隊會在實驗室設施中使用這些 Antlion 測試
  • 也可能使用第三方漫遊測試

說明文件

FIDL 變更包括新訊息、欄位和方法的重要說明文件。我們不打算提供內嵌文件以外的額外文件。

缺點、替代方案和未知事項

BSSID 封鎖清單擴充功能

Fullmac 啟動漫遊可能需要 BSSID 封鎖清單 API (類似於 Android 中的 API)，讓 WLAN 政策指定不應連線的特定 AP。這樣一來，WLAN 政策就能避免 Fullmac 韌體重複漫遊至 WLAN 政策已知無法運作的 AP。

是否在 Fullmac 和 WLAN 政策之間共用控制項

這項 RFC 指定 WLAN 政策是否要控管 Fullmac 介面是否啟用漫遊邏輯。預期 Fullmac 或 WLAN 政策會控管介面的漫遊邏輯，但可能不會同時控管兩者。如果 Fullmac 和 WLAN 政策同時啟動漫遊嘗試，且兩者對最佳 AP 的看法不一致，可能會導致 AP 之間發生「顛簸」情形。BSSID Blocklist API 可讓 WLAN 政策在 Fullmac 的漫遊決策中設定「護欄」，而不會有多個漫遊決策發起者。如果我們認為有正當理由讓 Fullmac 和 WLAN 政策都啟動漫遊嘗試，則需要額外設計。

中斷連線行為

我們正在非常仔細地分析連線中斷情境。我們必須確保 WLAN 在不明確期間 (例如 Fullmac 知道漫遊已開始，但 SME 等較高層級不知道時) 發生連線中斷時，仍能正常運作。

SME 目前的連線中斷邏輯會嘗試從 AP 取消驗證，做為大多數連線中斷情境的清除措施。漫遊嘗試導致裝置離開原始 AP 的管道 (甚至是頻段) 時：

  • Fullmac 可能不知道裝置是否仍透過原始 AP 進行驗證
  • 因為 Fullmac 不知道，所以無法在某些情況下通知中小企業裝置是否仍透過原始 AP 進行驗證
  • 如果 SME 在清除期間決定向原始 AP 要求取消驗證 (方法是向 Fullmac 傳送取消驗證要求)，Fullmac 可能無法處理這項要求，因為 Fullmac 可能無法連上原始 AP

在這種情況和其他中斷連線的情況下，我們可能會發現 Fullmac 和/或 SME 層需要不同的中斷連線行為。

與 WLAN 政策和 SME 中現有的「重新連線」邏輯互動

WLAN 政策和 SME 具有現有的「重新連線」行為，會嘗試重新建立先前運作中的連線。舉例來說，當連線取消關聯但未取消驗證時，SME 可以保留 WLAN 政策和 SME 之間的 ConnectTransaction 通訊協定，同時 SME 會嘗試與 AP 建立關聯。如果 SME 重新連線成功，SME 就能略過驗證負擔，縮短中斷連線時間。這類行為可能需要經過仔細檢查，才能瞭解與漫遊的互動方式。舉例來說，我們可能會發現，在漫遊嘗試期間或之後，需要更積極地取消驗證，才能避免重新連線時發生問題。我們也可能會發現需要變更重新連線的時間，或調整其他參數。

與 DHCP 和第 3 層管理互動

WLAN 軟體會管理資料連結層，又稱為「第 2 層」。第 2 層以上是網路層 (也稱為「第 3 層」)，由 DHCP、網路堆疊、網路政策和其他管理軟體管理。嘗試漫遊時，第 2 層和第 3 層可能會發生中斷：

  • 裝置與原始 AP 中斷連線，但尚未完全連線至目標 AP 時，第 2 層流量可能會暫時中斷
  • 漫遊嘗試會導致 802.1X 控制的通訊埠關閉，進而導致第 3 層連結中斷，如果嘗試成功，連結就會恢復

在 Fuchsia 中，第 3 層連結中斷目前會導致完整的 DHCP 用戶端終止並初始化。使用者可能不會注意到這點，也可能導致使用者可見的 IP 連線中斷。「第 2 層中斷導致第 3 層中斷」的情況不只會發生在漫遊時：中斷連線後再連線 (即使連線至同一個 AP)，也會導致 DHCP 用戶端完全終止並初始化。

如要減少第 3 層中斷，可透過額外設計 (不在本 RFC 範圍內) 達成下列目標：

  • 為第 3 層軟體提供選項，針對預期會提供相同第 3 層連線能力的第 2 層中斷進行最佳化，方法是向第 3 層軟體提供足夠的第 2 層中斷資訊
  • 決定適當的檢查項目，以驗證第 3 層連線 (例如 DNAv4、ARP 探查、DHCP 動作、現有或新的可連線性檢查)，在發生這類第 2 層中斷時使用
  • 協調執行這些第 3 層檢查的邏輯，並在必要時回退至完整的 DHCP 用戶端拆解和初始化

確切的機制、漫遊後驗證和所需邏輯都必須經過計算。Android 在這方面有一些先有技術 (請參閱「Android updateLayer2Information」)，而 DNAv4 和 DNAv6 的 IETF RFC 也涵蓋這個問題空間 (請參閱「DNAv4 和 DNAv6」)。

既有技術和參考資料

附錄 A：快速 BSS 轉換的未來發展

Fuchsia WLAN 目前不支援快速 BSS 轉換。快速 BSS 轉換可讓裝置將關聯性移至目標 AP，並保持 RSNA 完整性。WLAN 支援快速 BSS 轉換後，部分行為會有所變更，目前的設計已將這些行為變更納入考量。

在初始連線時，WLAN 政策需要查看一或多個額外資訊元素 (簡稱 IE)，這些元素專用於支援快速 BSS 轉換。這些資訊可能會傳達給 WLAN 政策中的中小企業 ConnectTransaction.ConnectResult (類似於這項 RFC 指定安全性設定傳達給 WLAN 政策的方式)。快速 BSS 轉移 AP 會宣傳「行動網域」IE，裝置可使用該 IE 識別其他 AP，並接受來自目前 AP 的快速 BSS 轉移。

在指定使用快速 BSS 轉換的漫遊開始時，WLAN「必須」保留與原始 AP 相關聯的狀態和 RSNA。無論漫遊是由 RoamStartInd 啟動的 Fullmac 漫遊，還是由 RoamReq 啟動的 WLAN 政策漫遊，都是如此。其中一項重要影響是，MLME 不會在 Fast BSS Transition 漫遊開始時關閉受控連接埠。透過快速 BSS 轉換建立新連線時，原始連線會照常運作。如果快速 BSS 轉換漫遊成功，且 original_association_maintained 為 true：

  • MLME 必須保持 802.1X 受控通訊埠開啟
  • 由於受控連接埠從未關閉，裝置可能只會在第 2 層短暫暫停 (觀察到約需 20 毫秒)，不會中斷 IP 連線

如果漫遊嘗試失敗 (或達到漫遊嘗試逾時)：

  • RoamResultInd/RoamConf original_association_maintained 指定在漫遊嘗試失敗期間，是否維持與原始 AP 的關聯
  • 如果原始關聯性維持不變，Fullmac「不應」啟動中斷連線 (但驅動程式庫可能知道，從失敗/逾時中復原需要中斷連線)

如果 MLME 將 RoamResultInd/RoamConf 傳送至 SME，表示快速 BSS 轉換漫遊失敗：

  • 中小企業「必須」從「漫遊」轉換為「與原始 AP 建立關聯」
  • 如果 target_bss_authenticated 為 true，SME 可能會要求從目標 AP 取消驗證 (如需一些細微的詳細資料，請參閱「中斷連線行為」)

如果支援快速 BSS 轉換，即使 WLAN 政策收到 OnRoamResult，指出快速 BSS 轉換漫遊嘗試失敗，WLAN 政策仍可與原始 AP 維持現有 ConnectTransaction。

快速 BSS 轉換也會為與 DHCP 和第 3 層管理互動新增考量事項：部分成功的漫遊嘗試不會在嘗試期間關閉 802.1X 控制的連接埠，因此不會有第 3 層連結中斷。如果沒有第 3 層連結中斷，然後第 3 層連結啟動，第 3 層管理軟體就需要其他信號，才能知道應執行漫遊後驗證動作。

另一項影響是，各種狀態機器 (MLME、SME、WLAN 政策) 必須為多個 AP 維護狀態。雖然可以透過在現有狀態中新增欄位來完成這項作業，但一旦快速 BSS 轉換即將推出，將這些狀態機器重構為可感知多個 BSS 的機器，可能就會變得更具吸引力。快速查看 SME 用戶端狀態機器，即可瞭解可能需要進行的變更品質：

  • 在快速 BSS 轉移漫遊開始時，SME 需要模擬裝置仍與原始 AP 上的 RSNA 相關聯，同時模擬裝置正在向目標 AP 進行驗證
  • 完成目標 AP 的驗證後，SME 必須模擬裝置仍與原始 AP 上的 RSNA 相關聯，同時重新與目標 AP 建立關聯
  • 成功完成快速 BSS 轉換漫遊後：
    • 裝置會移至 802.11 與 RSNA 相關聯的狀態 (請參閱 IEEE 802.11-2020 11.3.1)，並使用目標 AP
    • 裝置會降至 authenticated 狀態，並使用原始 AP
    • 裝置隨後可能會失去與原始 AP 的驗證狀態，例如原始 AP 傳送取消驗證指標給裝置，但這不會影響與目標 AP 的連線
  • 如果快速 BSS 轉換漫遊嘗試失敗，裝置狀態會更加複雜：
    • 如果裝置與原始 AP 失去關聯前發生失敗情形，裝置仍會與原始 AP 上的 RSNA 建立關聯，且可能通過目標 AP 的驗證
    • 如果裝置與原始 AP 失去關聯後發生失敗情形，裝置就不會關聯至任何 AP，且可能會驗證原始 AP 和/或目標 AP

附錄 B：支援備援的漫遊功能

802.11 規定裝置可透過多個 AP 進行驗證，但一次只能與一個 AP 建立關聯。漫遊嘗試失敗時，裝置仍會透過原始 AP 進行驗證，除非收到原始 AP 的取消驗證指示。也就是說，中小企業可以透過原始 AP 維持足夠的狀態，從「漫遊」狀態轉換回「連線」狀態，並略過與原始 AP 的驗證程序。這樣一來，裝置就能更快恢復與原始 AP 相關聯的狀態。我們在 SME 用戶端狀態機中新增了兩個狀態，藉此製作原型：

  • 漫遊，如本 RFC 所述
  • RoamingWithFallback：保留原始 AP 的足夠狀態，以便在漫遊失敗時返回原始 AP 的「連線中」狀態

目前沒有繼續開發這個可支援備援的 SME 用戶端狀態機原型。與 WLAN 核心團隊討論後，大家一致認為，如果 SME 用戶端狀態機器經過重構，可明確保留多個 AP 的狀態，那麼實作具備備援功能的漫遊功能會比較容易。此外，您可能還需要處理 Fullmac 韌體限制，因為部分韌體要求 Fullmac 驅動程式庫在漫遊失敗時中斷連線並重設韌體狀態，這可能會導致無法回復。

如果我們決定實作支援備援的漫遊功能，這項功能可以與快速 BSS 轉移功能並存。支援備援的漫遊會盡力保留原始 AP 的已驗證狀態，而快速 BSS 轉換則會盡力保留關聯狀態和 RSNA。我們可以同時使用快速 BSS 轉換和支援備援的漫遊，也可以只使用其中一項，或兩者都不使用。

附錄 C：Softmac 漫遊服務的未來展望

「Softmac」WLAN 裝置與 Fullmac 的重要差異在於，Fullmac 裝置的大部分 802.11 MLME 邏輯都在韌體中實作，而 Softmac 裝置的大部分 WLAN MLME 邏輯則是在驅動程式庫程式軟體中實作。由於 Fullmac 會處理重新關聯框架的建構和剖析作業、協調漫遊程序，甚至可以決定漫遊的時間和地點，因此 Fullmac API 需要進行重大變更才能支援漫遊 (即本 RFC)。但在 Softmac 中，漫遊支援所需的 API 和邏輯變更性質可能不同：

  • WLAN 政策的漫遊控制邏輯 (本 RFC 未說明) 可能會用於判斷漫遊時機和地點，而不是在 Softmac 驅動程式庫或 Fuchsia MLME/SME 中實作這項邏輯
  • 建構及剖析 802.11 重新關聯框架，以及協調漫遊程序的邏輯，可能會在 MLME 中實作，而不是在 Softmac API 介面中新增更多內容
  • Softmac 必須追蹤目前的管道，原因有很多，而且由於漫遊嘗試可能會變更管道或頻帶，因此可能需要調整這項邏輯
  • 但請注意，我們尚未進行 Softmac 漫遊的原型設計，因此可能會遇到需要不同做法的 Softmac 韌體

附錄 D：重新關聯安全性設定

裝置漫遊 (透過重新關聯) 時，重新關聯要求框架中指定的安全設定，必須與原始連線使用的安全設定相同 (請參閱 IEEE 802.11-2020 11.3.5.4)。這項規定值得深入探討，瞭解其對本 RFC 中指定 API 變更的影響。

WLAN 政策會儲存已儲存的網路，這些網路會在NetworkConfig中指定，目的是以人類可理解的用語呈現這些網路：

  • SSID
  • 網路的高層級保護類型 (例如 WPA2 或 WPA3，但不是這些廣泛類型中的許多可能變化)
  • 憑證 (例如密碼)

當 WLAN 政策決定連線至特定 AP 時，WLAN 政策會傳送 SME a ConnectRequest，其中包含 AP 的其他詳細資料：

  • 裝置應連線的 AP 的 BSS 說明
  • 802.11 驗證類型 (例如 802.11 開放式驗證或 WPA3 SAE)

中小企業：

  • 將這項更詳細的規格與 AP 提供的安全設定 (包含在 BSS 說明中) 進行比較
  • 決定要納入關聯要求中的安全性設定
  • 產生將在關聯要求中傳送至 AP 的確切位元組
    • 舉例來說，針對 WPA2 網路，SME 會產生 RSNE 資訊元素
    • RSNE 可能會將 RSN 功能 MFPR 位元設為 1，表示需要管理框架保護 (MFP，請參閱 IEEE 802.11-2020 9.4.2.24.4)，因此裝置不會加入不支援 MFP 的網路
    • 或中小企業可能已將 MFPR 設為 0 (表示非必要)，同時將 MFPC 設為 1，表示裝置可以加入網路，無論該網路是否支援或需要 MFP
  • 將這項安全設定向下傳播到 MLME，最終傳播到 Fullmac 韌體，該韌體會將關聯要求傳送至 AP

只有在 AP 安全性設定與 SME 指定的安全設定相符時，關聯才會成功 (如需運作方式，請參閱 IEEE 802.11-2020 12.6.3)。IEEE 802.11-2020 11.3.5.4 規定，後續任何重新關聯 (漫遊) 要求都必須使用原始關聯要求中包含的相同 RSNE。

如果是 Fullmac 啟動的漫遊嘗試，則不需要任何額外的 API。中小企業會決定原始關聯要求中使用的安全性設定，Fullmac 會儲存這項設定，並在任何漫遊嘗試中使用這項安全性設定。由於 WLAN 政策不會選擇目標 AP，因此在這種情況下，WLAN 政策不需要知道 Fullmac 啟動漫遊嘗試的安全設定。

但如果是 WLAN 政策啟動的漫遊，WLAN 政策必須瞭解用於連線至原始 AP 的 SME 指定安全設定，因為：

  • WLAN 政策會選擇漫遊嘗試的目標 AP
  • 但如果 WLAN 政策不知道原始關聯要求中包含的 SME 指定安全性設定，就無法確定所選 AP 是否符合原始安全性設定
  • 如果 WLAN 政策選擇不相容的目標 AP，漫遊就會失敗

解決方法是在 SME ConnectResult 中新增欄位，以便在初始連線時與 WLAN 政策共用安全性 IE。

如果我們發現 Fullmac 韌體在漫遊期間使用不同的安全性設定：

  • SME 幾乎一定會無法漫遊，而不是冒著安全設定比原始安全設定不安全的風險；SME 應大聲抱怨
  • WLAN 政策「幾乎」應停用該裝置的漫遊功能，以防止這種情況再次發生；WLAN 政策應大聲抱怨

如果我們在漫遊期間發現需要變更安全性設定，就必須根據 IEEE 802.11-2020 11.3.5.4 強制的安全性設定不變量，評估這項需求。考量到先前修訂的 802.11 並未釐清這個問題，我們可能會遇到不遵守不變量的 Fullmac 韌體。如果發現需要支援的案例，我們可能會新增 API 欄位/方法，明確允許 WLAN 政策取得和/或設定安全性設定。

我們也可能發現，WLAN 需要比 802.11 規格規定的限制更嚴格的安全保障。如果是 WLAN 政策啟動的漫遊，WLAN 政策可自由選擇符合比初始連線更嚴格安全條件的存取點，藉此強制執行更嚴格的安全措施，但仍須通過 SME 驗證，確認安全參數符合原始安全設定。如果是 Fullmac 啟動的漫遊，可能需要導入驅動程式庫 API，才能變更關聯/重新關聯要求 IE，和/或修改韌體並提供額外的設定選項，才能提供這項行為。