RFC-0243：WLAN 漫遊

RFC-0243：WLAN 漫遊
狀態	已接受
領域	WLAN
說明	將裝置連上無線網路，並有多個存取點時，裝置之間可以進行漫遊。「Roam」表示裝置會將其連線從某個存取點 (AP) 切換到同一個無線網路中的其他 AP，且在轉換期間不會發生完全中斷連線的情況。
更小鳥	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

摘要

讓裝置連線到無線網路，其中有多個存取點時，裝置之間可以進行漫遊。「Roam」表示用戶端裝置會在相同的無線網路內，將連線從某個存取點 (AP) 移至另一個 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 Core：chcl@google.com、kiettran@google.com
• WLAN 驅動程式：rsakthi@google.com
• WLAN 政策：mnck@google.com，nmcracken@google.com

社會化：

• 我們針對 WLAN Core 邏輯的可能實作方式建立了多種原型，並於與 WLAN Core 會談，並與 WLAN 團隊主管分別進行討論。
• 我們與 Connectivity 驅動程式、WLAN Core、WLAN Policy、網路政策和網路堆疊團隊合作，以及詳細討論並進一步討論 RFC 草稿
• 撰寫了多份輔助文件來探索相關主題，特別是 SME 狀態機器變更、EAPOL 行為和中斷連線行為

相關規定

本文件中的關鍵字「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」等關鍵字均以 IETF RFC 2119 中所述的方式解釋。下方列出需求條件。

條款

• 裝置：用戶端裝置位在 802.11 無線網路中；802.11 條款中，「裝置」是指本文件中的非 AP STA
• Station (STA)：連線至 802.11 無線網路的裝置
• 存取點 (AP)：透過 802.11 無線網路通訊協定，將一或多部用戶端裝置連線至網路
  • 目前的 AP：當裝置連線到無線網路時，一次只能與一個 AP 建立關聯；目前的 AP 是裝置目前所關聯的 AP
  • 原始 AP：裝置在漫遊時開始時相關聯
  • 目標 AP：當裝置嘗試漫遊另一個 AP 時，目標 AP 是裝置嘗試建立關聯的位置。在漫遊成功完成時，目標 AP 會變為目前的 AP
• Roam：當用戶端裝置將連線從一個 AP 移動到同一個無線網路內的另一個 AP 時，在轉換期間不會發生完全中斷連線的情況；在本文件中，「漫遊」是移動連線的操作組合，包括驗證和重新關聯目標 AP 軟體，以及 Fuchsia WLAN 軟體層之間的協調
• 關聯：802.11 指定的機制可將用戶端裝置關聯從一個 AP 移動至另一個 AP (請參閱 IEEE 802.11-2020 4.5.3.4)

設計

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

• 完整啟動的漫遊
• WLAN 政策啟動的漫遊
• (如需 Softmac 漫遊可能的運作方式簡短討論，請參閱「附錄 C：未來使用 Softmac 漫遊)。

在「Fullmac-ated Roam」中，由 Fullmac 韌體決定漫遊的時間和位置。為成功執行漫遊， 您必須透過 MLME 和 SME 向上溝通，而探測作業的結果 也必須透過 MLME、SME 和 WLAN 政策向上傳達。從 Fullmac 啟動的 Roam 嘗試始於 Fullmac 發出 RoamStartInd，而 roam 嘗試的結果會導致 WLAN 政策收到 ConnectTransaction.OnRoamResult。訊息路徑如下：

• 傳送至 Fullmac 驅動程式庫的 Fullmac 韌體啟動通知 -> Fullmac 驅動程式 RoamStartInd -> MLME RoamStartInd -> SME
• 傳送至 Fullmac 驅動程式庫程式的 Fullmac 韌體快取結果通知 RoamResultInd -> MLME RoamResultInd -> SME ConnectTransaction.OnRoamResult -> WLAN 政策

在 WLAN 政策啟動的漫遊中，由 WLAN 政策決定漫遊的時間和地點，且「必須」透過 SME、MLME、Fullmac 驅動程式庫和裝置韌體向下通訊。裝置韌體會嘗試發生漫遊，而對於這類嘗試的結果，「必須」透過 Fullmac、MLME、SME 和 WLAN Policy 向上報告。啟動 WLAN 政策的漫遊嘗試由 WLAN 政策發出 ClientSme.Roam，且嘗試的結果最終會導致 WLAN 政策收到 ConnectTransaction.OnRoamResult。訊息路徑如下：

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

如要實作這些 API 變更，整個 WLAN 會進行邏輯變更：

• 全面變更驅動程式庫，傳送用於啟動 Roam 的韌體指令，並回應來自韌體的通知，瞭解發生漫遊的進度和最終結果
• 在漫遊透過驗證、重新關聯和 RSNA 設定時，MLME 變更以開啟/關閉 802.1X 控制的通訊埠
• 主題專家變更，導入新的內部 SME 用戶端狀態 (漫遊)
• SME 和 WLAN 政策變更，讓 WLAN 政策能夠啟動 WLAN 政策，並通知 WLAN 政策的結果 (無論是完全啟動或 WLAN 政策已啟動，WLAN 政策都會收到相同的 roam 結果通知)

這個 RFC 並未指定在 Fullmac 或 WLAN 政策中如何執行漫遊決定，僅說明漫遊決策：

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

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

SME 需要在漫遊時追蹤用戶端的特定資料，以及管理漫遊狀態與其他內部狀態之間的轉換情形。系統會將名為「Roaming」的新內部狀態新增至 SME 用戶端狀態機器。與 SME「連線」狀態一樣，「Roaming」狀態是指 SME 嘗試驗證並與 AP 建立關聯的地方 (我們稱之為「目標 AP」)。兩者的主要差異如下：

• 進入 Roaming 狀態的唯一有效的轉換作業是來自「關聯」狀態；雖然目前也有許多有效的轉換為「連線中」狀態的有效轉換
• 漫遊對接收特定事件具有特殊處理處理方式；在收到 802.11 後，Connecting 會轉換為 Idle 狀態，或在收到解除關聯時轉換為「中斷連線」，則漫遊必須只處理目標 AP 的解除驗證和中斷關聯影格
• 漫遊狀態會處理連線 (RoamResultInd 和 RoamConf) 無法處理的事件
• 當 SME 從「Associated」變更為「Roaming」，目前的 AP 會因為 SME 嘗試連線至目標 AP 而發生變化；在「Associated」和「Connecting」之間轉換期間，AP 不會變更

以下是 SME 用戶端狀態機器的概要總覽 (以紅色標示)：

以下是針對 Fullmac 啟動的 SME 用戶端狀態機器圖表的詳細說明，其中顯示了滿意路徑 (RoamStartInd 後接 RoamResultInd) 和相關失敗路徑：

以下為由 WLAN 政策啟動的 SME 用戶端狀態機器圖表，顯示快樂路徑 (RoamReq 後接 RoamConf) 和相關失敗路徑：

請參閱下方的「完整啟動的漫遊」和「WLAN 政策啟動的漫遊」章節，進一步瞭解 SME 如何來回切換漫遊狀態。

完整啟動的漫遊

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

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

RoamStartInd 也「必須」包含以下內容：

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

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

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

當系統正在嘗試漫遊時，Fullmac 驅動程式庫會：

• MAY 拒絕收到的掃描要求 (如果是 brcmfmac，這是目前唯一的 Fullmac 驅動程式庫)
• 漫遊時，取消正在進行的掃描作業
• 必須針對傳入連線要求傳回錯誤
  • 這與現有的 Fullmac 行為 (在 brcmfmac 中) 類似，在正在進行連線嘗試時，不會服務 (並傳回錯誤) 連入連線要求；在進行 roam 嘗試時，我們也會透過同樣的方式嘗試連線嘗試
• 「必須」針對傳入的漫遊要求傳回錯誤
  • 類似 Fullmac 中現有的連線行為
• 「必須」接收服務中斷連線要求

基於這些限制，Fullmac 驅動程式必須設定內部漫遊逾時，才能完成 802.11 驗證和重新連結作業。逾時時間長度不包含任何重新關聯後的動作 (例如 EAPOL、DHCP)。如果關聯未在逾時前完成：

• 如果未維護原始關聯，則 Fullmac 必須啟動中斷連線
• 如要瞭解支援快速 BSS 轉場的情況，請參閱附錄 A

需要進行漫遊逾時，以免卡在無法執行掃描和連線等重要功能的狀態停滯。逾時時間應大於一般驗證和重新關聯設定的時間 (目前已觀察到接近 100 毫秒的社區)。合理的預設漫遊逾時時間約為 1 秒。

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

• 以原始 AP 驗證
• 與原始 AP 無關
• 處於待處理 RSNA 狀態 (若安全性設定需要 RSNA)

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

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

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

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

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

請注意，WLAN 政策未通知使用者開始漫遊。而 RoamStartInd 的不同之處在於，RoamStartInd 會傳播至 SME，但漫遊時不會透過 ConnectTransaction 通訊協定傳遞至 WLAN 政策。WLAN 政策團隊在設計時沒有看到這類事件的需求，但可以視需要新增。從實際漫遊的觀察中，若缺乏漫遊啟動通知並傳送至 WLAN 政策，可導致 WLAN 政策無法得知正在進行漫遊的事件；從 SME 向 WLAN 政策傳送 Roam 開始事件可縮減約 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 中提供的資訊類似的資訊。最重要的是，其中包含 roam 嘗試的 802.11 狀態碼。與 RoamStartInd 類似，RoamResultInd 必須含有布林值欄位，用於表示是否保留原始關聯 (請參閱「尋找快速 BSS 轉場效果」一節)。如果漫遊成功，則 original_association_maintained 必須為 false，因為成功的漫遊一律會導致原始 AP 解除關聯。

RoamResultInd 也「必須」包含布林值欄位，用來表示裝置是否已透過目標 AP 進行驗證：

• 如果漫遊成功，則必須為 target_bss_authenticated
• 如果 status_code 不是成功，target_bss_authenticated 會指定裝置目前是否已透過目標 AP 進行驗證
• 這個欄位是用來通知 SME 已獲得目標 AP 的已驗證狀態，因為 SME MAY 決定在清理失敗後，在清理期間將撤銷要求傳送至目標 AP

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

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

如果漫遊失敗：

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

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

收到 MLME RoamResultInd 後，如果車道成功，SME 會執行以下操作：

• SME 必須將其內部狀態從「Roaming」改為「Associated」，並使用目標 AP 做為目前的 AP
• SME 收到原始 AP 的任何解除關聯/取消驗證影格後，不得轉出關聯
• 如果安全性設定需要 RSNA：RSNA 設定，會在 Fullmac 韌體、Fullmac 驅動程式庫、MLME 和 SME 之間進行協調，方式與首次連線的 RSNA 設定相同
• 在成功的 RSNA 設定時 (或若網路不需要 RSNA)，802.1X 受控通訊埠開啟的方式會與一般成功連線的方式相同

如果 RoamResultInd 表示漫遊失敗，SME 會改為執行以下操作：

• 如果 target_bss_authenticated 為 true：
  • SME MAY 要求從原始 AP 取消驗證 (但如需一些微妙，請參閱中斷連線行為一節)
  • SME MAY 要求從目標 AP 撤銷驗證
  • 如果 SME 決定要求目標 AP 取消驗證，則 SME 必須 從漫遊切換成中斷連線
  • 否則 SME 必須從漫遊轉換為 Idle
  • 如果目標 AP 的 SAE 逾時：
    • SME MAY 要求從原始 AP 撤銷驗證
    • SME 必須直接從漫遊轉換為 Idle
• 如果 target_bss_authenticated 為 false：
  • SME MAY 要求從原始 AP 取消驗證 (但如需一些微妙，請參閱中斷連線行為一節)
  • 如果 SME 決定要求取消原始 AP 裝置的驗證，則 SME 必須從漫遊轉換為中斷連線
  • 否則 SME 必須從漫遊轉換為 Idle

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

• 必須包含目標 AP 的 BSSID
• 必須加入狀態碼指出 漫遊是否成功
• 必須加入布林值，表示是否已維護原始關聯
  • 如果漫遊成功，則必須為 false
  • 詳情請參閱展望 BSS 快速轉換
• 無論成功/失敗，請務必加入目標 AP 的 BSS 說明 (但如果 roam 失敗，則這個欄位「可能」為空白)
• 如果發生中斷連線，則必須包含 SME DisconnectInfo；換句話說，如果發生漫遊失敗且未保留原始關聯，就屬於必要欄位

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

• 如果未保留原始關聯，WLAN 政策「必須」關閉 ConnectTransaction 並結束連線
• 發生漫遊失敗後，WLAN 政策會開始建立新的連線，就像回應任何遺失的連線時一樣

WLAN 政策啟動的漫遊

WLAN 政策將能夠發起漫遊嘗試，並瞭解其結果。WLAN 政策如何處理 WLAN 政策啟動的 roam 的概略總覽：

當 WLAN 政策啟動 Roam 嘗試時，可向 SME 發出 ClientSme.Roam (上圖步驟 1)。Roam 包含 RoamRequest，其概念與 SME ConnectRequest 類似，但由於 SSID 和安全性設定在漫遊期間「不得」變更，因此選項較少 (請參閱附錄 D：重新建立關聯安全性設定)，進一步瞭解在漫遊中使用的安全性設定背景。

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

為使 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)，然後韌體就會與完全啟動的漫遊程序相同 (步驟 6)。當韌體通知 Fullmac 驅動程式庫程式結果 (步驟 7) 時，Fullmac 會將 RoamConf 傳送至 MLME (步驟 8 和 9)。RoamConf 和 RoamResultInd 類似，

收到 RoamConf 後，MLME 的行為會與收到 RoamResultInd 相同，差別在於前者會將 RoamConf 傳送至 SME (步驟 10)。

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

收到 OnRoamResult 後，WLAN 政策會在 Fullmac 啟動的漫遊結尾時執行上述動作。

實作

第 1 階段：導入未推送至正式版裝置的 API 和邏輯

API 變更可以在以下兩項 Gerrit 變更中進行：一項用於完全啟動巨集，另一種則用於 WLAN 政策啟動的漫遊。

截至目前為止，漫遊變更的策略在於導入漫遊邏輯變更，而不會在正式版裝置上啟用。Brcmfmac 驅動程式庫中的驅動程式庫程式功能會保護完全啟動的漫遊服務。我們提供單元和整合測試，確保漫遊功能已停用，以免意外啟用。

針對 WLAN 政策啟動的漫遊，在沒有呼叫 SME ClientSme.Roam/ConnectTransaction.OnRoamResult API 的任何情況下，就可以導入此 API，直到 WLAN 政策確定可以啟用。有 API 後，WLAN 政策可以開始採用漫遊成功/失敗做為連線品質追蹤的輸入內容，WLAN 政策邏輯可判斷是否要在特定 AP 中使用 ClientSme.Roam API，甚至是完全不使用 ClientSme.Roam API。

WLAN 政策「必須」能在建立介面時啟用或停用漫遊功能。因此，WLAN 政策可以：

• 知道特定介面上已啟用/停用全巨集啟動漫遊
• 在發生執行階段問題時完全停用介面的漫遊功能

為此，您必須對 fuchsia.wlan.device 進行簡單的 API 變更。最低實作程序需要在 CreateIfaceRequest 中新增單一欄位，讓呼叫端指定在建立介面時必須啟用的漫遊功能。

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

第 2 階段：整合測試

對於全巨集啟動的漫遊，可以在本機開發人員版本上測試此變更 (例如在 brcmfmac Fullmac 驅動程式庫程式程式碼中取消註解漫遊功能)，以及使用 Antlion 在實體裝置和 AP 硬體上進行整合測試。已經有適用於 Fullmac 啟動漫遊 (WlanWirelessNetworkManagementTest) 的 Antlion 整合測試套件，可以測試成功和失敗的漫遊嘗試。現有測試套件需要具備 Fuchsia Fullmac 功能的裝置，才能在單一實體 AP 裝置中於兩個網路之間漫遊。對於其他已啟動的 Fullmac 漫遊情境，我們也預期透過新的 Antlion 測試套件提高整合涵蓋範圍。

針對 WLAN 政策啟動的漫遊，可在本機開發人員版本中測試變更，並且可以使用 Antlion 在實體裝置和 AP 硬體上進行整合測試 (方法是讓 WLAN Policy 在執行階段啟用介面上的漫遊，請參閱上方第 1 階段的討論)。對於額外的 WLAN 政策啟動的漫遊情境，我們也預期透過新的 Antlion 測試套件提高整合涵蓋範圍。

如果 Antlion 測試套件會執行完全啟動或 WLAN 政策啟動的漫遊，必須知道這些功能是否用於 Fuchsia 裝置進行測試 (DUT)。這是必要的，因為 Antlion 需要知道要針對該 DUT 執行還是略過漫遊測試。對於現有的 Fullmac 啟動的漫遊測試套件，Antlion 設定具有 WLAN 功能的特殊指令：在 Antlion 設定中有漫遊功能，就會指示 Antlion 執行 Fullmac 啟動的漫遊測試，否則系統會略過這些測試。這項實作作業應讓 Antlion 明確使用 WLAN 驅動程式功能查詢功能支援 (使用 WLAN 驅動程式功能)，並應讓 Antlion 明確能夠在 DUT 上啟用漫遊功能，再對該 DUT 執行測試。

目前使用 Fullmac 啟動的漫遊 Antlion 測試套件以及任何新測試套件，都「必須」可在 Connectivity Automation 測試上搭配 WLAN Antlion 測試環境執行。

具備完整巨集的漫遊功能，且支援 WLAN 測試平台：

• 必須包含至少一部支援 Fullmac 啟動漫遊功能的實體 Fuchsia 裝置
• 必須包含與 Antlion 相容的實體 AP 裝置 (依照 802.11 條款，同一 ESS 內有兩個以上的 BSS)
• 應允許變數信號感知變量
• MAY 將裝置裝入無線電護盾，以減少干擾

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

您也可以進行更深入的整合測試，例如使用第三方研究室測試漫遊情境。

第 3 階段：發布至正式版裝置

等待整合測試結果出爐後，即可開始推出作業。如上方第 1 階段所述，WLAN 政策「必須」能夠針對個別介面啟用和停用漫遊功能。

推出 Fullmac 啟動的漫遊以及 WLAN 政策啟動的漫遊服務將由 WLAN 政策控制，使用 WLAN Policy 的一般功能推出機制 (或新的推出機制) 進行控制。WLAN 政策已有多種邏輯，分別用於選擇連線、連線品質和連線失敗問題。WLAN 政策會在正常作業程序中經常變更這些函式。WLAN 政策可能會導入漫遊專用的額外執行階段保護措施，但這項 RFC 並不明確指定。

效能

必須在推出階段評估的指標包括：

• 漫遊成功 / 漫遊成功，計數與速率
• 要完成的 Roam 時間，如同直方圖
• 漫遊逾時，數量和速率
• Roam 成功，隨後出現無法使用的介面，數量不限
• 漫遊失敗原因，按照 DisconnectInfo 細分 (大約、取消連結來源和原因)
• 漫遊次數過多期間

我們也必須監控非漫遊的指標：

• 非漫遊的中斷連線計數 (不會大幅增加)
• 運作時間比率 (不應大幅減少)
• 閒置介面自動連線的數量 (不應大幅增加)

人體工學

這個 RFC 不會指定任何使用者的漫遊控制權。其他作業系統讓使用者無法控制漫遊 (例如 MacOS)，或是提供特殊設定 (例如 Windows、Linux) 的有限控制選項。我們目前並無預期 WLAN 政策可以為使用者提供漫遊控制。因此，從啟用 Fullmac 啟動功能或 WLAN 政策啟動的漫遊，Fuchsia 使用者不會大幅承擔認知責任。唯一會預期的使用者可見效果，就是在存取點之間進行一些轉場速度會更快。對使用者而言，失敗的漫遊會不會與其他連線中斷區分，而中斷的復原會就像不涉及漫遊的連線中斷一樣，也就是定期掃描與連線。

回溯相容性

自 Fuchsia 問世以來，802.11 規格包括漫遊 (重新建立關聯)。

回溯相容性的問題主要在於，對於許多使用 Fuchsia WLAN 的現有裝置，漫遊不會經常導致正常運作的網路連線無法使用。如上述推出章節提到，讓 WLAN Policy 能夠明確決定何時啟用和使用漫遊功能，有助於確保漫遊功能不會讓介面處於效能降低或無法使用的狀態。WLAN 政策允許：

• 節流漫遊掃描
• 拒絕清單有問題的 AP
• 採用輪詢來限制漫遊嘗試
• 在執行階段停用漫遊。

安全性考量

目前有三個安全疑慮：

• 原始 AP 和目標 AP 必須具有相同的 SSID
• 目標 AP 必須與原始 AP 連線中指定的安全性參數相符
• 所連 AP 的決定一直都是 WLAN 政策的決定；全 mac 啟動的漫遊服務將部分責任委派給 Fullmac 韌體

WLAN SME 已驗證 SSID 和安全性參數是否與原始安全性設定相符，並且將採用相同的機制來驗證目標 AP 的設定。上述驗證步驟失敗會導致連線中斷。如要進一步瞭解 Roam 嘗試使用的安全性設定，請參閱附錄 D。

如果是負責選擇 AP 的情況，請注意下列事項：

• 對於全巨集啟動的漫遊，如果 Fullmac 韌體找到了適合漫遊的 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 政策啟動的漫遊情況進行漫遊情境
• 連線自動化功能會在實驗室設施中使用這些 Antlion 測試
• 也可能使用第三方漫遊測試

說明文件

FIDL 變更將包含有關新訊息、欄位和方法的重要說明文件。除了內嵌說明文件之外，我們並不規劃其他說明文件。

缺點、替代項目和未知

BSSID 封鎖清單擴充功能

完全啟動的漫遊功能可能需要 BSSID 封鎖清單 API (與 Android 中的 API 類似)，可讓 WLAN 政策指定不應連線至的特定 AP。這樣一來，WLAN 政策可避免 Fullmac 韌體不斷繞向 WLAN 政策已知無法運作的 AP 的情況。

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

此 RFC 指定 WLAN 政策將控制 Fullmac 介面是否已啟用漫遊邏輯。一般而言，Fullmac 或 WLAN Policy 可以控制介面的漫遊邏輯，但可能不會同時控制兩者。如果 Fullmac 和 WLAN 政策同時啟動漫遊服務，如果 Fullmac 和 WLAN 政策無法判定哪一個 AP 為最佳，則可能會導致 AP 之間「輾轉現象」。BSSID 封鎖清單 API 可讓 WLAN 政策針對 Fullmac 漫遊決策設定「防護機制」，而且不需有多個漫遊決策的啟動者。如果我們認定有充分的理由需要執行 Fullmac 和 WLAN 政策來啟動漫遊，就需要進行額外設計。

中斷連線

我們會持續謹慎分析中斷連線的情境。我們必須確信 WLAN 在不明確時期會發生連線中斷時 (例如 Fullmac 知道 Roam 已啟動，但像 SME 這樣的較高層那樣的) 具有彈性。

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

• Fullmac 可能無法得知裝置是否仍透過原始 AP 進行驗證
• 因為 Fullmac 不明問題，Fullmac 無法通知 SME 在某些情況下，裝置是否仍通過原始 AP 驗證
• 如果 SME 在清理期間決定從原始 AP 要求撤銷驗證 (藉由向 Fullmac 傳送反驗證要求)，則這個取消驗證要求可能無法由 Fullmac 處理，因為 Fullmac 可能無法連線至原始 AP

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

與 WLAN 政策和 SME 中現有的「reconnect」邏輯互動

WLAN 政策與 SME 有現有的「重新連線」行為，系統會嘗試重新建立先前有效連線。例如，若連線已脫離但尚未驗證，SME 可以保留 WLAN Policy 和 SME 之間的 ConnectTransaction 通訊協定，同時 SME 嘗試與 AP 建立關聯。如果 SME 重新連線成功，SME 就能略過驗證負擔，並減少中斷連線的時間。這類行為可能需要仔細審查這類行為與漫遊的互動方式。我們有個假設範例。在某些情況下，我們發現在嘗試漫遊期間或嘗試後，需要更積極地撤銷驗證，避免在嘗試失敗後重新連線問題。我們可能也會發現需要變更重新連線的時間，或調整其他參數。

與 DHCP 和第 3 層管理的互動

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

• 第 2 層流量流程中可能會短暫暫停，直到裝置與原始 AP 中斷連線但尚未完全連線到目標 AP 時
• 如果嘗試嘗試，系統會關閉第 802.1X 控制的通訊埠， 就會關閉第 3 層連結，如果嘗試成功，會接著顯示連結

在 Fuchsia 中，向下的第 3 層連結目前會導致 DHCP 用戶端完全刪除及初始化。這可能會讓使用者沒有註意到，或可能導致使用者看不到 IP 連線中斷。這種「第 2 層幹擾導致第 3 層中斷」的情況並非漫遊：如果先中斷連線，後接連線 (即使是同一個 AP)，則會導致 DHCP 用戶端立即完全拆卸並啟動 init。

額外設計 (此 RFC 範圍以外) 可以減少這層 3 的干擾，達到以下目的：

• 向第 3 層軟體提供最佳化第 2 層中斷情形，且預期能提供相同第 3 層連線能力的中斷點，針對第 3 層軟體提供足夠的相關資訊
• 在發生第 2 層服務中斷時，決定正確的檢查以驗證第 3 層連線能力 (例如 DNAv4、ARP 探測、DHCP 動作、現有或新的可連性檢查)，
• 協調執行這些第 3 層檢查的邏輯，其為完整的 DHCP 用戶端刪除作業，並在必要時進行 init

需要確切的機制、漫遊後驗證以及所需的邏輯必須解決。Android 有一些先進技術 (請參閱 Android updateLayer2Information)，而 DNAv4 和 DNAv6 的 IETF RFC 也涵蓋此問題空間 (請參閱 DNAv4 和 DNAv6)。

優先藝術與參考資料

• Android Wi-Fi 網路選項
• 封鎖 Android SSID 和 BSSID
• Android updateLayer2Information
• DNAv4 和 DNAv6：
  • 偵測 IPv4 (DNAv4) 中的網路連結
  • 偵測 IPv6 網路附件的簡易程序
• Linux cfg80211 子系統 (請參閱函式連線和 cfg80211_roamed 的說明文件)
• 適用於企業客戶的 macOS 無線漫遊
• Microsoft WifiCx OID_WDI_TASK_ROAM
• wpa_supplicant Developers 的說明文件 (但目前還沒有適當的說明文件)

附錄 A：預計很快就能進行 BSS 轉換

Fuchsia WLAN 目前不支援快速 BSS 轉換。快速 BSS 轉換功能可讓裝置根據 RSNA 的指示，將裝置關聯移至目標 AP。當 WLAN 支援快速 BSS 轉場時，會有幾項行為改變，而目前的設計也會將這些行為變更納入考量。

一開始連線時，WLAN 政策將需要查看一或多個快速 BSS 轉換支援專用的其他資訊元素 (縮寫 IE)。這些版本很可能是傳送至 SME ConnectTransaction.ConnectResult 中的 WLAN 政策 (類似這個 RFC 指定安全性設定傳達給 WLAN 政策的方式)。快速 BSS 轉換 AP 所宣傳的「行動網域」IE，可讓裝置識別其他接受從當前 AP 進行快速 BSS 轉場的 AP。

當指定使用「快速 BSS 轉換」的漫遊時，WLAN 必須保留與原始 AP 相關的狀態和 RSNA。無論 roam 是由 RoamStartInd 或 WLAN Policy 發起的 RoamReq 啟動的 WLAN 政策，都是如此。其中一項重要的影響是，在快速 BSS 轉換漫遊時，MLME 不會關閉控制的通訊埠。當您透過快速 BSS 轉換功能建立新連線時，原始連線會照常進行。如果快速 BSS 轉換漫遊成功，且 original_association_maintained 為 true：

• MLME 必須讓 802.1X 控制的連接埠保持開啟
• 因為受控通訊埠從未關閉，裝置可能只會在第 2 層發生短暫暫停情形 (大約需要 20 毫秒)，且沒有 IP 連線中斷的問題

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

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

如果 MLME 傳送 RoamResultInd/RoamConf 給 SME，表示 Fast BSS 轉場效果失敗：

• SME 必須從漫遊轉換至關聯 (AP)
• 如果 target_bss_authenticated 為 true，SME MAY 要求從目標 AP 撤銷驗證 (如需一些細微的詳細資料，請參閱中斷連線行為)

支援快速 BSS 轉換時，WLAN 政策將能透過原始 AP 維持現有的 ConnectTransaction，即使收到 WLAN 政策收到 OnRoamResult，指出嘗試的快速 BSS 轉換漫遊失敗。

快速 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 並進入已驗證狀態
  • 裝置隨後可能會失去與原始 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 的「連線」狀態

我們目前並未採用這個可備用的 SME 用戶端狀態機器的原型。與 WLAN Core 團隊討論後，一般共識是，如果 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 啟動的 Roam 嘗試，則不需要任何其他 API。SME 決定將用於原始關聯要求中的安全性設定，Fullmac 會儲存這項設定，而 Fullmac 會在任何嘗試漫遊時使用此安全性設定。由於 WLAN 政策並未選擇目標 AP，因此在這種情況下，WLAN 政策一律不需要知道 Fullmac 啟動的漫遊作業的安全性設定。

但若是 WLAN 政策啟動的漫遊，需要 WLAN 政策才能知道用於連線至原始 AP 的 SME 專屬安全性設定，原因如下：

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

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

如果發現 Fullmac 韌體在 Roam 期間使用不同的安全性設定的狀況：

• SME 應該幾乎絕對無法使 Roam 故障，而不是暴露配置的安全性比原始安全性設定低的風險；SME 應該大聲地抱怨
• WLAN 政策應盡量停用該裝置的漫遊功能，以避免再次發生這種情形。WLAN 政策應大聲解釋

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

我們也發現，我們想讓 WLAN 維持比 802.11 規格的限制，更強大的安全保證。針對以 WLAN 政策啟動的漫遊，WLAN 政策將能自由強制執行更高的安全性，方法是選擇僅選擇符合比初始連線中更更嚴格的安全標準的 A，但仍需要符合安全性參數與原始安全性設定相符的 SME 驗證。針對完全啟動的漫遊，可能需要導入驅動程式庫 API，以允許變更關聯/關聯要求 IE，且/或韌體必須修改其他設定選項，才能提供這項行為。