RFC-0243：WLAN 漫遊

RFC-0243：WLAN 漫遊
狀態	已接受
區域	WLAN
說明	如果裝置連線的無線網路有多個存取點，就能在這些存取點之間漫遊。「漫遊」是指裝置在同一個無線網路中，將連線從一個存取點 (AP) 移至另一個 AP，且在轉換過程中不會完全中斷連線。
Gerrit 變更	961555
作者	karlward@google.com
審查人員	haydennix@google.com karthikrish@google.com sbalana@google.com silberst@google.com swiggett@google.com
提交日期 (年-月-日)	2023-12-15
評論日期 (年-月-日)	2024-04-11

摘要

如果裝置連線的無線網路有多個存取點，就能在這些存取點之間漫遊。「漫遊」是指用戶端裝置在同一個無線網路中，將連線從一個存取點 (AP) 移至另一個 AP，且在轉換期間不會完全中斷連線。裝置漫遊的原因有很多：可能是裝置遠離目前的 AP，靠近另一個 AP；也可能是裝置與目前 AP 的連線品質下降 (例如錯誤率偏高)。在這種情況下，裝置可能會嘗試漫遊至其他 AP，避免完全中斷連線。本文將說明 API 異動和邏輯，以支援 Fullmac 啟動和 WLAN 政策啟動的漫遊。

提振精神

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

• 無法再連上目前的 AP
• 與目前 AP 的連線品質下降

漫遊功能可讓裝置使用 802.11 重新關聯，以最少的中斷時間移至新的 AP。如果沒有漫遊功能，裝置必須中斷與原始 AP 的連線 (或得知連線已中斷)，拆除所有網路連線，並開始與 AP 建立新連線。

相較之下，如果支援漫遊，裝置可以在仍連線至原始 AP 的情況下，選取新的 AP 並重新建立關聯。重新關聯約需 70 毫秒，而中斷連線後再重新連線約需 130 毫秒。雖然重新關聯並非萬靈丹，但其他可進一步減少中斷的功能需要重新關聯支援。漫遊機制 (即本設計) 建立後，未來可透過進一步工作，實現一系列漫遊強化功能，例如：

• 在發生中斷前漫遊：透過 BSS 轉換管理 (IEEE 802.11-2020 4.3.19.3)，AP 可以在即將發生中斷前通知裝置應漫遊。
• 縮短漫遊中斷時間，有時甚至可縮短至零：透過快速 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 核心：chcl@google.com，kiettran@google.com
• WLAN 驅動程式：rsakthi@google.com
• WLAN 政策：mnck@google.com、nmccracken@google.com

社交：

• 我們針對 WLAN Core 邏輯的可能實作方式，建立了多個變化版本的原型，並在與 WLAN Core 的會議中，以及與 WLAN 團隊主管的個別會議中討論
• RFC 草案已傳閱，並與連線驅動程式、WLAN 核心、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，且在轉換期間不會完全中斷連線。在本文件中，「漫遊」是指移動連線的一組動作，包括驗證和重新與目標 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 啟動漫遊
• WLAN 政策啟動的漫遊
• (如需簡短討論 Softmac 漫遊的運作方式，請參閱附錄 C：Softmac 漫遊展望)

在「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 會隨著驗證、重新關聯和 RSNA 設定的進展，變更開啟/關閉 802.1X 受控通訊埠
• 變更 SME，導入新的內部 SME 用戶端狀態 (Roaming)
• 變更 SME 和 WLAN 政策，讓 WLAN 政策能夠啟動漫遊，並通知 WLAN 政策漫遊結果 (無論漫遊是由 Fullmac 還是 WLAN 政策啟動，WLAN 政策都會收到相同的漫遊結果通知)

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

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

SME 將取得新的漫遊內部用戶端狀態

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

• 唯一有效的轉換是從「Associated」狀態轉換為「Roaming」狀態，而現有許多有效的轉換是轉換為「Connecting」狀態
• 漫遊會特別處理特定事件的接收作業；當連線在收到 802.11 取消驗證時轉換為閒置狀態，或在收到取消關聯時轉換為中斷連線時，漫遊必須僅處理來自目標 AP 的取消驗證和取消關聯框架
• 漫遊狀態會處理連線中不會處理的事件 (RoamResultInd 和 RoamConf)
• 當 SME 從「Associated」轉換為「Roaming」時，目前的 AP 會變更，因為 SME 正在嘗試連線至目標 AP；在「Associated」和「Connecting」之間轉換時，AP 不會變更

以下是 SME 用戶端狀態機的概略總覽 (紅色為變更部分)：

以下是 Fullmac 啟動漫遊的 SME 用戶端狀態機器圖表，其中顯示滿意路徑 (RoamStartInd，後面接著成功的 RoamResultInd) 和相關失敗路徑：

以下是 WLAN 政策啟動漫遊的類似 SME 用戶端狀態機器圖，顯示滿意路徑 (RoamReq 後面接著成功的 RoamConf) 和相關失敗路徑：

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

Fullmac 啟動漫遊

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

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

RoamStartInd 也必須包含：

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

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

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

漫遊嘗試進行時，Fullmac 驅動程式庫會：

• 可以拒絕傳入的掃描要求 (brcmfmac 就是這種情況，這是目前唯一的 Fullmac 驅動程式庫)
• 漫遊嘗試開始時，可以取消進行中的掃描
• 必須針對傳入的連線要求傳回錯誤
  • 這與現有的 Fullmac 行為 (在 brcmfmac 中) 類似，當有連線嘗試正在進行時，不會處理傳入的連線要求 (並傳回錯誤)；當有漫遊嘗試正在進行時，我們也會對連線嘗試採取相同做法
• 必須針對傳入的漫遊要求傳回錯誤
  • 再次嘗試，類似於 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 通知 SME 漫遊已開始 (步驟 4)。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 的外部請求者 (而非使用韌體請求者，或 wpa_supplicant 等第三方請求者)。

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

• 即使 RoamStartInd 指出原始關聯仍維持，SME 也必須將此視為中斷連線，因為無效的漫遊嘗試可能會繼續
• SME 必須傳送 OnRoamResult 給 WLAN 政策，指出連線中斷的原因是 RoamStartInd 格式錯誤
• SME 必須向目標 AP 傳送取消驗證
• SME 可能會向原始 AP 傳送取消驗證
• SME 必須轉換為中斷連線

如果 RoamStartInd 格式正確，SME 必須轉換為漫遊。

請注意，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 驗證
• 這個欄位會向 SME 告知與目標 AP 的驗證狀態，因為 SME 可能會在漫遊失敗後，決定在清理期間向目標 AP 傳送取消驗證要求

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

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

如果漫遊失敗：

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

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

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

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

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

• if target_bss_authenticated is true:
  • SME 可能會要求原始 AP 取消驗證 (但請參閱「中斷連線行為」一節，瞭解一些細微差異)
  • SME 可要求目標 AP 取消驗證
  • 如果 SME 決定要求目標 AP 取消驗證，SME 必須從「漫遊」轉換為「中斷連線」
  • 否則 SME 必須從「漫遊」轉換為「閒置」
  • 與目標 AP 的 SAE 逾時：
    • SME 可能會要求原始 AP 取消驗證
    • SME 必須直接從漫遊轉換為閒置
• 如果 target_bss_authenticated 為 false：
  • SME 可能會要求原始 AP 取消驗證 (但請參閱「中斷連線行為」一節，瞭解一些細微差異)
  • 如果 SME 決定要求原始 AP 取消驗證，則 SME 必須從「漫遊」轉換為「中斷連線」
  • 否則 SME 必須從「漫遊」轉換為「閒置」

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

• 必須包含目標 AP 的 BSSID
• 必須包含狀態碼，指出漫遊是否成功
• 必須包含布林值，指出是否保留原始關聯
  • 如果漫遊成功，則必須為 false
  • 詳情請參閱「快速 BSS 轉換展望」
• 無論成功/失敗，都應包含目標 AP 的 BSS 說明 (但如果漫遊失敗，這個欄位可以留空)
• 如果發生中斷連線，則必須包含 SME DisconnectInfo；換句話說，如果漫遊失敗且未維持原始關聯，則必須提供這項資訊

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

• 如果未保留原始關聯，WLAN 政策必須關閉 ConnectTransaction 並結束連線
• 漫遊失敗後，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)。

MLME 收到 SME 的 RoamReq 後，行為與收到 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 時相同。SME 透過 ConnectTransaction 將 OnRoamResult 傳送至 WLAN 政策 (步驟 11)。

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

實作

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

API 變更可透過兩項 Gerrit 變更進行：一項用於 Fullmac 啟動的漫遊，另一項用於 WLAN 政策啟動的漫遊。

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

對於 WLAN 政策啟動的漫遊，可以引入 API，而無需任何呼叫 SME ClientSme.Roam/ConnectTransaction.OnRoamResult API 的操作，直到 WLAN 政策確定可以啟用為止。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 上執行測試前，啟用漫遊功能的能力。

現有的 Fullmac 啟動漫遊 Antlion 測試套件，以及任何新的測試套件，都必須能在具備 WLAN Antlion 測試平台的 Connectivity Automation 測試平台上執行。

可進行 Fullmac 啟動漫遊的 WLAN 測試平台：

• 必須包含至少一部可由 Fullmac 啟動漫遊的實體 Fuchsia 裝置
• 必須包含與 Antlion 相容的實體 AP 裝置，且能同時提供兩個以上的 AP (以 802.11 來說，即相同 ESS 內有兩個以上的 BSS)
• 應允許變動信號衰減
• 可將裝置裝入無線電屏蔽罩，減少干擾

這類測試平台推出後，開發人員就能使用現有的 Antlion 試用工作基礎架構，針對進行中的變更執行這些測試。

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

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

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

Fullmac 啟動和 WLAN 政策啟動漫遊的推出，將由 WLAN 政策控制，並使用 WLAN 政策的一般功能推出機制 (或新的推出機制，由他們選擇)。WLAN 政策已具備連線選取、連線品質和連線失敗復原的邏輯。WLAN 政策在正常運作過程中，會經常變更這些函式。WLAN 政策可能會導入其他專門針對漫遊的執行階段防護措施，但本 RFC 不會嘗試指定這些措施。

效能

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

• 漫遊嘗試/漫遊成功次數和比率
• 漫遊完成時間 (直方圖)
• 漫遊逾時次數和比率
• 漫遊成功後介面無法使用的次數
• 漫遊失敗原因，依 DisconnectInfo 細分 (大致上是中斷連線來源和原因)
• 漫遊時間過長

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

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

人體工學

這項 RFC 未指定任何使用者漫遊控制項。其他作業系統則不提供使用者漫遊控制權 (例如 macOS)，或僅透過特殊設定提供非常有限的控制權 (例如 Windows、Linux)。目前我們不預期 WLAN 政策會提供使用者漫遊控制項。因此，Fuchsia 使用者不會因為導入 Fullmac 或 WLAN 政策啟動的漫遊，而承受重大認知負荷。使用者唯一會注意到的變化，是部分存取點之間的轉換速度會加快。對使用者來說，漫遊失敗與其他連線中斷並無差別，而中斷後的復原作業也與不涉及漫遊的連線中斷相同：一般掃描和連線。

回溯相容性

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

回溯相容性的主要考量是，對於許多使用 Fuchsia WLAN 的現有裝置，漫遊功能的導入不會經常導致可用的網路連線無法使用。如上述推出一節所述，讓 WLAN 政策能明確決定何時啟用及使用漫遊功能，將有助於確保使用漫遊功能時，介面不會降級或無法使用。WLAN 政策可能：

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

安全性考量

有三個安全疑慮：

• 原始 AP 和目標 AP 必須具有相同的 SSID
• 目標 AP 必須與連線至原始 AP 時指定的安全性參數相符
• 決定要連線至哪個 AP 一直是 WLAN 政策的權限範圍；Fullmac 啟動的漫遊會將部分責任委派給 Fullmac 韌體

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

至於選擇 AP 的責任：

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

隱私權注意事項

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

測試

• Fullmac 驅動程式庫已有單元測試 (使用 brcmfmac Sim 架構)
• Fullmac 啟動漫遊 (使用 Antlion WlanWirelessNetworkManagementTest 套件) 已有在實際裝置和 AP 硬體上執行的整合測試
• 我們將建立更多整合測試，針對 Fullmac 啟動和 WLAN 政策啟動的漫遊，執行漫遊情境
• Connectivity Automation 將在實驗室設施中使用這些 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 之間發生「thrashing」現象。BSSID 封鎖清單 API 可讓 WLAN 政策為 Fullmac 的漫遊決策設定「防護機制」，而不需要多個漫遊決策啟動器。如果我們認為有正當理由讓 Fullmac 和 WLAN 政策同時啟動漫遊嘗試，則需要額外設計。

中斷連線行為

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

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

• Fullmac 可能不知道裝置是否仍透過原始 AP 進行驗證
• 因為 Fullmac 不知道，Fullmac 無法通知 SME 裝置是否在某些情況下仍與原始 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 用戶端拆除和初始化。

您可以透過額外設計 (超出本 RFC 的範圍) 減少第 3 層中斷，例如：

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

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

既有技術和參考資料

• Android Wi-Fi 網路選擇
• Android SSID 和 BSSID 封鎖
• Android updateLayer2Information
• DNAv4 和 DNAv6：
  • 偵測 IPv4 中的網路連結 (DNAv4)
  • Simple Procedures for Detecting Network Attachment in IPv6
• Linux cfg80211 子系統 (請參閱 connect 和 cfg80211_roamed 函式的說明文件)
• macOS wireless roaming for enterprise customers
• Microsoft WifiCx OID_WDI_TASK_ROAM
• wpa_supplicant 開發人員說明文件 (雖然適當的說明文件不多)

附錄 A：快速 BSS 轉換

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

在初始連線時，WLAN 政策需要查看一或多個與快速 BSS 轉換支援相關的其他資訊元素 (簡稱 IE)。這些資訊可能會傳送至 SME ConnectTransaction.ConnectResult 中的 WLAN 政策 (類似於這個 RFC 指定將安全性設定傳送至 WLAN 政策的方式)。快速 BSS 轉換 AP 會宣傳「行動網域」IE，裝置可使用該 IE 識別其他接受目前 AP 快速 BSS 轉換的 AP。

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

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

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

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

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

• SME 必須從「漫遊」轉換為「與原始 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 轉換漫遊後：
  • 裝置會與目標 AP 進入 802.11 與 RSNA 相關聯狀態 (請參閱 IEEE 802.11-2020 11.3.1)
  • 裝置會降至與原始 AP authenticated 的狀態
  • 裝置隨後可能會失去與原始 AP 的「已驗證」狀態，例如原始 AP 向裝置傳送取消驗證指示，但這不會影響與目標 AP 的連線
• 如果快速 BSS 轉換漫遊嘗試失敗，裝置狀態會變得更複雜：
  • 如果失敗發生在裝置與原始 AP 失去關聯之前，裝置仍會與原始 AP 上的 RSNA 相關聯，並可能與目標 AP 進行驗證
  • 如果失敗發生在裝置與原始 AP 失去關聯之後，裝置就不再與任何 AP 關聯，且可能與原始 AP 和/或目標 AP 驗證

附錄 B：展望具備備用機制的漫遊

802.11 規定裝置可透過多個 AP 進行驗證，但在任何指定時間只能與單一 AP 建立關聯。漫遊嘗試失敗時，裝置仍會透過原始 AP 進行驗證，除非收到原始 AP 的取消驗證指示。這表示 SME 可以與原始 AP 保持足夠的狀態，以便從「漫遊」狀態轉換回「連線中」狀態，略過原始 AP 的驗證程序。這樣可以縮短與原始 AP 重新建立關聯狀態的時間。我們在 SME 用戶端狀態機器中新增兩個狀態，藉此建立原型：

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

目前不打算採用這個具備備用功能的 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 政策會傳送 ConnectRequest 給 SME，其中包含 AP 的其他詳細資料：

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

SME 當時：

• 將這項更詳細的規格與 AP 提供的安全性設定 (包含在 BSS 說明中) 進行比較
• 決定關聯要求中要包含的安全性設定
• 產生要傳送至 AP 的關聯要求確切位元組
  • 例如，對於 WPA2 網路，SME 會產生 RSNE 資訊元素
  • RSNE 可能會將 RSN 功能 MFPR 位元設為 1，這表示需要管理框架保護 (MFP，請參閱 IEEE 802.11-2020 9.4.2.24.4)，因此裝置不會加入不支援 MFP 的網路
  • 或 SME 可能將 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。SME 會決定原始關聯要求中使用的安全性設定，Fullmac 會儲存這項設定，並在任何漫遊嘗試中使用這項安全性設定。由於 WLAN 政策不會選擇目標 AP，因此在這種情況下，WLAN 政策不需要知道 Fullmac 啟動漫遊嘗試的安全設定。

不過，如果是 WLAN 政策啟動的漫遊，WLAN 政策必須知道 SME 指定的安全設定，用於連線至原始 AP，原因如下：

• WLAN 政策將選擇漫遊嘗試的目標 AP
• 但如果 WLAN 政策不知道原始關聯要求中包含的中小企業指定安全性設定，就無法確定所選 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 政策可以自由選擇符合比初始連線更嚴格安全性條件的 AP，強制執行更強大的安全性，但仍須經過 SME 驗證，確認安全性參數符合原始安全性設定。如果是 Fullmac 啟動的漫遊，可能需要導入驅動程式庫 API，才能變更關聯/重新關聯要求 IE，且/或必須修改韌體，並提供額外的設定選項，才能提供這項行為。