RFC-0243：WLAN 漫遊

RFC-0243：無線區域網路漫遊
狀態	已接受
區域	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，以免完全中斷連線。本文將說明支援 Fullmac 啟動和 WLAN 政策啟動漫遊功能所需的 API 變更和邏輯。

提振精神

有時，裝置必須使用與目前使用的 AP 不同的 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 晶片韌體中的漫遊功能卸載功能可實作漫遊通訊協定，在晶片上執行漫遊邏輯，而非在作業系統中執行，進而減少耗電量，並縮短漫遊決定和漫遊開始之間的延遲時間。
• 讓 WLAN 政策更能控管連線：我們正在進行 WLAN 政策的重大改進，以決定漫遊的時機和地點。如要讓 WLAN 政策啟動漫遊功能，並在漫遊嘗試完成時做出回應，就必須使用本文所述的 API 和邏輯變更。

相關人員

協助人員：

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、kietran@google.com
• WLAN 驅動程式：rsakthi@google.com
• WLAN 政策：mnck@google.com、nmcracken@google.com

社會化：

• 我們為 WLAN Core 邏輯的可能實作方式建立了多種原型，並在與 WLAN Core 和 WLAN 團隊主管的個別會議中討論
• 我們已將 RFC 草稿傳閱給 Connectivity Drivers、WLAN Core、WLAN Policy、Network Policy 和網路堆疊團隊，並與這些團隊進行詳細討論
• 我們已起草多份相關文件，以探討相關主題，特別是 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，且在轉換期間不會完全中斷連線；在本文件中，「漫遊」是指為了移轉連線而採取的一系列動作，包括與目標 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 驅動程式庫變更為傳送啟動漫遊功能的韌體指令，並回應韌體通知，說明漫遊功能的進度和最終結果
• 當漫遊功能透過驗證、重新連結和 RSNA 設定進行時，MLME 會變更為開啟/關閉 802.1X 受控通訊埠
• SME 變更，引入新的內部 SME 用戶端狀態 (Roaming)
• SME 和 WLAN 政策變更，讓 WLAN 政策能夠啟動漫遊功能，並通知 WLAN 政策漫遊結果 (無論漫遊是由 Fullmac 啟動還是 WLAN 政策啟動，WLAN 政策都會收到相同的漫遊結果通知)

除了建議漫遊決策外，這份 RFC 並未明確說明 Fullmac 或 WLAN 政策如何做出漫遊決策：

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

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

SME 需要追蹤用戶端漫遊時的特定資料，並管理漫遊狀態與其他內部狀態之間的轉換。系統會將名為「Roaming」的新內部狀態新增至 SME 用戶端狀態機器。就像 SME 的「連線中」狀態一樣，SME 會在「漫遊」狀態下嘗試驗證並連結 AP (我們稱為「目標 AP」)。兩者之間有幾個主要差異：

• 進入「漫遊」狀態的唯一有效轉換是從「已連結」狀態開始；但進入「連線中」狀態的有效轉換則有許多
• Roaming 會針對收到特定事件時進行特殊處理，其中「Connecting」會在收到 802.11 解除認證時轉換為「Idle」狀態，或在收到解除連線時轉換為「Disconnecting」，Roaming 必須只處理來自目標 AP 的解除認證和解除連線框架
• 漫遊狀態會處理「連線」(RoamResultInd 和 RoamConf) 無法處理的事件
• 當 SME 從「Associated」變更為「Roaming」時，SME 會嘗試連線至目標 AP，因此會變更目前的 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)。韌體開始對目標 AP 進行驗證或重新連結之前，必須先傳送 RoamStartInd。就像 ConnectReq (會建立與 AP 的初始連線)，RoamStartInd 包含目標 AP 的 BSS 說明。MLME 應向 SME 提供完整的 BSS 說明 (請參閱下方的步驟 4)。

RoamStartInd 也必須包含：

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

隨著更多漫遊功能的導入，其他欄位也可能會加入 RoamStartInd。

由於漫遊嘗試必須使用與漫遊至目標 AP 時用於連線至原始 AP 相同的安全性設定，因此 Fullmac 必須保留用於與 AP 建立初始連線時使用的原始安全性設定。Fullmac 不得重新連結至與初始連線中使用的原始安全設定不相符的 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 受控通訊埠。此時，LME 必須將裝置視為：

• 透過原始 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 做為 RSN 的外部申請者 (而不是使用韌體申請者或 wpa_supplicant 等第三方申請者)。

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

• SME 必須將此視為連線中斷，即使 RoamStartInd 指出原始關聯仍維持不變，因為無效的漫遊嘗試可能會繼續
• SME 必須傳送 WLAN Policy OnRoamResult，指出中斷連線是因為 RoamStartInd 格式錯誤
• SME 必須向目標 AP 傳送驗證失敗訊息
• SME 可向原始 AP 傳送 deauthenticate
• 主題專家必須轉換為「斷開連線」

如果 RoamStartInd 並未格式錯誤，SME 就必須轉換為漫遊。

請注意，WLAN 政策不會收到漫遊開始的通知。換句話說，RoamStartInd 會向上傳播至 SME，但漫遊的開始時間不會透過 ConnectTransaction 通訊協定傳送至 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 不是成功，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
• 主題專家收到原始 AP 傳送的任何解除關聯/解除認證影格時，不得轉換為「關聯」
• 如果安全性設定需要 RSNA：發生 RSNA 設定，並在 Fullmac 韌體、Fullmac 驅動程式庫、MLME 和 SME 之間進行協調，與首次連線時發生的 RSNA 設定相同
• 在 RSNA 設定成功後 (或網路不需 RSNA)，802.1X 控管的通訊埠會以與一般成功連線相同的方式開啟

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

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

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

• 必須包含目標 AP 的 BSSID
• 必須包含狀態碼，指出漫遊是否成功
• 必須包含布林值，指出是否已保留原始關聯
  • 如果漫遊成功，則必須為 false
  • 詳情請參閱「Fast BSS Transition 展望」
• 無論成功/失敗，都應包含目標 AP 的 BSS 說明 (但如果漫遊失敗，這個欄位可能會為空白)
• 如果發生連線中斷，則必須加入 SME DisconnectInfo；換句話說，如果漫遊失敗且未保留原始關聯，則必須加入 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 相同，唯一的差別是 SME 會將 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 時相同。SME 會透過 ConnectTransaction 將 OnRoamResult 傳送至 WLAN 政策 (步驟 11)。

收到 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 上執行測試前啟用漫遊功能的功能。

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

可透過 Fullmac 啟動的漫遊功能 WLAN 測試平台：

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

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

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

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

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

由 Fullmac 啟動和 WLAN 政策啟動的漫遊功能，將由 WLAN 政策控制，並使用 WLAN 政策的一般功能推出機制 (或選擇採用新的推出機制)。WLAN 政策已包含連線選取、連線品質和連線失敗復原的邏輯。WLAN 政策經常會在一般運作過程中變更這些功能。WLAN 政策可能會引入額外的漫遊專屬執行階段安全防護措施，但本 RFC 不會特別說明這些措施。

成效

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

• 漫遊嘗試 / 漫遊成功次數和比率
• 完成漫遊時間 (以直方圖呈現)
• Roam 逾時時間 (計數和速率)
• 漫遊成功，接著是無法使用的介面，以計數方式呈現
• 漫遊失敗原因，按 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 政策已負責決定要連線至哪個存取點。WLAN 政策啟動的漫遊功能只會提供不同的機制，用於連線至目標存取點 (使用 802.11 重新關聯，而非 802.11 關聯)。

隱私權注意事項

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

測試

• 已為 Fullmac 驅動程式庫建立單元測試 (使用 brcmfmac Sim 架構)
• 針對 Fullmac 啟動的漫遊功能，已在實際裝置和 AP 硬體上進行整合測試 (使用 Antlion WlanWirelessNetworkManagementTest 套件)
• 我們會建立其他整合測試，以便測試 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 的看法不一致，而 Fullmac 和 WLAN 政策同時嘗試漫遊，可能會導致 AP 之間發生「抖動」現象。BSSID 封鎖清單 API 可讓 WLAN 政策在 Fullmac 漫遊決策中設定「防護欄」，而不需要有超過一個漫遊決策啟動程序。如果我們判斷有充分理由讓 Fullmac 和 WLAN 政策同時發起漫遊嘗試，就需要額外的設計。

斷開連線行為

我們目前正仔細分析斷線情境，我們必須確保 WLAN 在模糊期間 (例如 Fullmac 知道漫遊已開始，但 SME 等較高層級不知道) 發生連線中斷時，能夠恢復正常。

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

• Fullmac 可能不知道裝置是否仍透過原始 AP 進行驗證
• 由於 Fullmac 無法得知，因此無法告知 SME 裝置是否在某些情況下仍與原始 AP 進行驗證
• 如果 SME 在清除期間決定向原始 AP 要求解除驗證 (透過傳送解除驗證要求給 Fullmac)，Fullmac 可能無法處理這項要求，因為 Fullmac 可能無法連上原始 AP

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

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

WLAN 政策和 SME 具有現有的「重新連線」行為，會嘗試重新建立先前可用的連線。舉例來說，當連線已解除關聯但未解除驗證時，SME 會在 SME 嘗試連結 AP 時，保留 WLAN 政策和 SME 之間的 ConnectTransaction 通訊協定。如果 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 層中斷情形，選擇最佳化選項
• 決定在發生第 2 層中斷情形時，要使用哪些檢查來驗證第 3 層連線 (例如 DNAv4、ARP 探測、DHCP 動作、現有或新的可及性檢查)
• 協調執行這些第 3 層檢查的邏輯，並在必要時改用完整 DHCP 用戶端拆除和初始化功能

您必須找出確切的機制、漫遊後驗證，以及所需的邏輯。Android 在這方面有先前技術 (請參閱 Android updateLayer2Information)，而 DNAv4 和 DNAv6 的 IETF RFC 也涵蓋這個問題空間 (請參閱 DNAv4 和 DNAv6)。

既有技術與參考資料

• Android Wi-Fi 網路選取功能
• Android SSID 和 BSSID 封鎖功能
• Android updateLayer2Information
• DNAv4 和 DNAv6：
  • 在 IPv4 中偵測網路連結 (DNAv4)
  • 在 IPv6 中偵測網路連結的簡單程序
• Linux cfg80211 子系統 (請參閱 connect 和 cfg80211_roamed 函式的說明文件)
• 適用於企業客戶的 macOS 無線漫遊功能
• Microsoft WifiCx OID_WDI_TASK_ROAM
• wpa_supplicant 開發人員說明文件 (但幾乎沒有適當的說明文件)

附錄 A：展望快速 BSS 轉換

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

在初始連線期間，WLAN 政策需要看到一個 (或多個) 額外資訊元素 (簡稱 IE)，這些元素專門支援快速 BSS 轉移。這些資訊很可能會傳送至 SME ConnectTransaction.ConnectResult 中的 WLAN 政策 (類似於本 RFC 指定將安全性設定傳送至 WLAN 政策的方式)。快速 BSS 轉移 AP 會宣傳「mobility domain」IE，裝置可使用該 IE 識別其他接受來自目前 AP 的快速 BSS 轉移的 AP。

在指定使用快速 BSS 轉移功能的漫遊期間，WLAN 必須保留與原始 AP 相關聯的狀態和 RSNA。無論漫遊是 RoamStartInd 透過 Fullmac 啟動，還是 RoamReq 透過 WLAN 政策啟動，都會發生這種情況。其中一個重要的影響是，在 Fast BSS Transition 漫遊功能開始時，MLME 不會關閉受控的連接埠。原始連線會照常繼續，同時透過快速 BSS 轉移建立新連線。如果 Fast BSS Transition 漫遊成功且 original_association_maintained 為 true：

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

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

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

如果 MLME 傳送 RoamResultInd/RoamConf 給 SME，表示 Fast BSS Transition 漫遊失敗：

• 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 政策) 都需要為多個存取點維護狀態。雖然您可以透過在現有狀態中新增欄位來執行這項操作，但在 Fast BSS Transition 推出後，將這些狀態機器重構為可辨識多個 BSS 的機器，可能會更具吸引力。快速查看 SME 用戶端狀態機器人，瞭解可能需要的變更品質：

• 在快速 BSS 轉移漫遊功能開始時，SME 需要模擬裝置仍與原始 AP 上的 RSNA 相關聯，同時模擬裝置正在與目標 AP 進行驗證
• 完成與目標 AP 的驗證後，SME 需要模擬裝置在重新連結至目標 AP 時，仍與原始 AP 上的 RSNA 建立關聯
• 快速 BSS 轉移漫遊成功後：
  • 裝置會轉移至與目標 AP 相關聯的 802.11 associated with RSNA 狀態 (請參閱 IEEE 802.11-2020 11.3.1)
  • 裝置會以原始 AP 的已驗證狀態結束
  • 裝置之後可能會失去與原始 AP 的「已驗證」狀態，例如原始 AP 傳送裝置解除驗證指示；但這不會影響與目標 AP 的連線
• 在 Fast BSS Transition 漫遊嘗試失敗後，產生的裝置狀態會變得更複雜：
  • 如果裝置失去與原始 AP 的關聯前就發生失敗，裝置仍會與原始 AP 的 RSNA 關聯，並可能會透過目標 AP 進行驗證
  • 如果裝置在與原始 AP 失去關聯後發生失敗，則裝置將不再關聯任何 AP，並可能會透過原始 AP 和/或目標 AP 進行驗證

附錄 B：展望可備援漫遊功能

802.11 規範指出，裝置可以透過多個存取點進行驗證，但在任何特定時間點，只能與單一存取點建立關聯。如果漫遊嘗試失敗，除非已從原始 AP 收到解除認證指示，否則裝置仍會透過原始 AP 進行驗證。這表示 SME 可透過原始 AP 維持足夠的狀態，讓 SME 從「漫遊」狀態轉換回「連線」狀態，並略過與原始 AP 的驗證程序。這樣一來，系統就能縮短回到原始 AP 關聯狀態的時間。我們在 SME 用戶端狀態機制中新增兩個新狀態，以製作原型：

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

這個可備用備援機制的 SME 用戶端狀態機器原型目前並未開發。與 WLAN Core 團隊討論後，我們一致認為，如果 SME 用戶端狀態機制經過重構，可明確保留多個存取點的狀態，就能更輕鬆地實作可備援漫遊功能。您可能還需要處理 Fullmac 韌體限制。某些韌體會要求 Fullmac 驅動程式庫在漫遊失敗時中斷連線並重設韌體狀態，這可能會導致無法回復。

如果我們決定實作可備援漫遊功能，則可與 Fast 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 指定的安全性設定，因為：

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

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

如果我們發現 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，以便變更關聯/重新關聯要求 IEs，以及/或者必須使用額外的設定選項修改韌體，才能提供此行為。