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，以免完全断开连接。本文档介绍了支持 Fullmac 发起和 WLAN 政策发起漫游所需的 API 更改和逻辑。

设计初衷

有时，为了保持 WLAN 连接，设备需要使用与其当前使用的 AP 不同的 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 芯片固件中的漫游功能分流可以实现漫游协议，通过在芯片上（而非操作系统中）执行漫游逻辑来降低功耗，并缩短漫游决策和漫游开始之间的延迟时间。
• 让 WLAN 政策更好地控制连接：我们正在 WLAN 政策中进行大量工作，以确定何时何地漫游。如需允许 WLAN 政策发起漫游并在漫游尝试完成时做出响应，必须进行本文所述的 API 和逻辑更改。

利益相关方

教员：

neelsa@google.com

Reviewers:

• silberst@google.com：适用于 WLAN
• karthikrish@google.com：适用于 WLAN 驱动程序
• swiggett@google.com：适用于 WLAN 核心
• haydennix@google.com：WLAN 政策
• sbalana@google.com：用于连接自动化测试

咨询了：

• Netstack：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 政策、网络政策和 Netstack 团队，并与他们进行了详细讨论
• 我们起草了多份辅助文档，以探索相关主题，尤其是 SME 状态机更改、EAPOL 行为和断开连接行为

要求

本文档中的关键字“必须”“不得”“必需”“会”“不会”“应”“不应”“建议”“可以”和“可选”应按 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 需要跟踪客户端漫游时的特定数据，并管理漫游状态与其其他内部状态之间的转换。SME 客户端状态机中将添加一个名为“漫游”的新内部状态。与 SME Connecting 状态一样，在 Roaming 状态下，SME 会尝试对某个 AP（我们将其称为“目标 AP”）进行身份验证并与其关联。二者之间存在一些关键区别：

• 进入漫游状态的唯一有效转换是从关联状态转换；而进入连接状态的有效转换有很多
• 漫游会对收到的特定事件进行特殊处理；如果 Connecting 在收到 802.11 分离帧时转换为 Idle 状态，或者在收到分离帧时转换为 Disconnecting 状态，则 漫游 必须仅处理来自目标 AP 的分离帧
• 漫游状态用于处理连接（RoamResultInd 和 RoamConf）无法处理的事件
• 当 SME 从已关联状态转换为漫游状态时，当前 AP 会发生变化，因为 SME 会尝试连接到目标 AP；在已关联状态和正在连接状态之间转换期间，AP 不会发生变化

以下是 SME 客户端状态机的概览（红色部分表示更改）：

下面是 Fullmac 发起漫游的更详细的 SME 客户端状态机图，其中显示了正常路径（RoamStartInd 后跟成功的 RoamResultInd）和相关失败路径：

下面是 WLAN 政策发起漫游的类似 SME 客户端状态机图，显示了正常路径（RoamReq 后跟成功的 RoamConf）和相关失败路径：

如需详细了解 SME 如何从/到漫游状态进行转换，请参阅下面的 Fullmac 发起的漫游和 WLAN 政策发起的漫游部分。

Fullmac 发起漫游

某些 Fullmac 设备固件可以配置为确定何时何地漫游。下面简要介绍了 WLAN 如何处理由 Fullmac 发起的漫游：

当 Fullmac 发起漫游尝试时（上图中的第 1 步），Fullmac 驱动程序必须向 MLME 发送 RoamStartInd（第 2 步）。必须在固件开始与目标 AP 进行身份验证或重新关联之前发送 RoamStartInd。与 ConnectReq（用于创建与 AP 的初始连接）一样，RoamStartInd 包含目标 AP 的 BSS 说明。MLME 应向 SME 提供完整的 BSS 说明（请参阅下文第 4 步）。

RoamStartInd 还必须包含：

• 目标 AP 的 BSSID（单独存储，以防 BSS 说明缺失）
• 一个布尔值，表示在漫游开始时间是否保持了原始关联（如需了解快速 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 受控端口。此时，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 的外部 supplicant（而不是使用固件 supplicant 或 wpa_supplicant 等第三方 supplicant）。

如果 SME 检测到 RoamStartInd 格式错误（例如缺少字段或数据无效），则会知道漫游因内部错误而失败。在 Fullmac 发出 RoamStartInd 时，设备仍与原始 AP 相关联，但 Fullmac 可能在之后不久就离开了原始 AP 的频道和/或频段。SME 将采取以下措施：

• SME 必须将其视为断开连接，即使 RoamStartInd 指示原始关联保持不变也是如此，因为否则无效漫游尝试可能会继续
• SME 必须向 WLAN 政策发送 OnRoamResult，指明断开连接是由于 RoamStartInd 格式有误
• SME 必须向目标 AP 发送 deauthenticate
• SME 可以向原始 AP 发送 deauthenticate
• 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 驱动程序必须向 MLME 发送 RoamResultInd（第 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
• SME 在收到来自原始 AP 的任何解除关联/取消身份验证帧后，不得退出已关联状态
• 如果安全配置需要 RSNA：系统会在 Fullmac 固件、Fullmac 驱动程序、MLME 和 SME 之间协调进行 RSNA 设置，方式与首次连接时进行的 RSNA 设置相同
• RSNA 设置成功后（或如果网络不需要 RSNA），802.1X 受控端口将以与常规成功连接相同的方式打开

如果 RoamResultInd 指示漫游失败，SME 会改为执行以下操作：

• 如果 target_bss_authenticated 为 true：
  • SME 可以请求从原始 AP 取消身份验证（但请参阅断开连接行为，了解其中的一些细微之处）
  • SME 可以请求从目标 AP 取消身份验证
  • 如果 SME 决定请求从目标 AP 取消身份验证，则 SME 必须从漫游状态转换为断开连接状态
  • 否则，SME 必须从漫游状态转换为空闲状态
  • 如果 SAE 与目标 AP 超时，请执行以下操作：
    • SME 可以请求从原始 AP 取消身份验证
    • SME 必须从漫游直接转换为空闲
• 如果 target_bss_authenticated 为 false：
  • SME 可以请求从原始 AP 取消身份验证（但请参阅断开连接行为，了解其中的一些细微之处）
  • 如果 SME 决定请求从原始 AP 解除身份验证，则 SME 必须从漫游状态转换为断开连接状态
  • 否则，SME 必须从漫游状态转换为空闲状态

SME 使用现有的 ConnectTransaction API 通过每个连接通道与 WLAN 政策进行通信。SME 必须向 WLAN 政策发送 OnRoamResult，以告知其漫游尝试已完成（第 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 一样，但它会向 MLME 发送 RoamReq（第 2 步）。

收到 SME 发送的 RoamReq 后，MLME 的行为与收到 Fullmac 发送的 RoamStartInd 的行为相同，只不过它会向下发送 RoamReq（第 3 步和第 4 步）。

收到 MLME 发送的 RoamReq 后，Fullmac 会向固件发送命令以开始身份验证和重新关联流程（第 5 步），然后固件会执行与 Fullmac 发起漫游相同的操作（第 6 步）。当固件通知 Fullmac 驱动程序漫游尝试的结果（第 7 步）时，Fullmac 会向 MLME 发送 RoamConf（第 8 步和第 9 步）。RoamConf 类似于 RoamResultInd。

收到 RoamConf 后，MLME 的行为与收到 RoamResultInd 时相同，但它会将 RoamConf 发送给 SME（第 10 步）。

收到 RoamConf 后，SME 的行为与从 MLME 收到 RoamResultInd 时一样。SME 通过 ConnectTransaction 向 WLAN 政策发送 OnRoamResult（第 11 步）。

收到 OnRoamResult 后，WLAN 政策会执行与 Fullmac 发起漫游结束时上述操作相同的操作。

实现

第 1 阶段：引入 API 和逻辑，但未推送到生产设备

这些 API 更改可通过两个 Gerrit 更改进行：一个用于 Fullmac 发起漫游，另一个用于 WLAN 政策发起漫游。

到目前为止，漫游更改策略一直是引入漫游逻辑更改，而不在生产设备上启用这些更改。Fullmac 发起的漫游由 brcmfmac 驱动程序中的驱动程序功能进行保护。我们提供了单元测试和集成测试，以确保漫游功能已停用，以免用户意外启用该功能。

对于 WLAN 政策发起的漫游，在 WLAN 政策确信可以启用该 API 之前，可以引入该 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 发起的漫游，您可以在本地开发者 build 上测试更改（例如，取消注释 brcmfmac Fullmac 驱动程序代码中的漫游功能），还可以在真实设备和 AP 硬件上使用 Antlion 进行集成测试。已经有一个适用于 Fullmac 发起漫游 (WlanWirelessNetworkManagementTest) 的 Antlion 集成测试套件，用于测试成功和失败的漫游尝试。现有测试套件需要一台支持 Fuchsia Fullmac 的设备，该设备经过插桩，可在单个物理 AP 设备上在两个网络之间漫游。此外，我们还预计通过新的 Antlion 测试套件，针对其他 Fullmac 发起漫游场景增加集成覆盖率。

对于 WLAN 政策发起的漫游，您可以在本地开发者 build 上测试更改，还可以使用 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 测试平台：

• 必须包含至少一个支持 Fullmac 发起漫游的实体 Fuchsia 设备
• 必须包含与 Antlion 兼容的物理 AP 设备，能够提供两个或更多同时使用的 AP（在 802.11 术语中，是指同一 ESS 中的两个或更多 BSS）
• 应允许使用可变信号衰减
• 可以将设备封闭在无线电屏蔽装置中以减少干扰

当此类测试平台可用时，开发者将能够使用现有的 Antlion tryjob 基础架构对正在运行的更改进行这些测试。

可能还会使用更深入的集成测试（例如，使用第三方实验室来测试漫游场景）。

第 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 存在分歧，那么 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、Netstack、网络政策和其他管理软件管理。发生漫游尝试时，第 2 层和第 3 层可能会中断：

• 在设备从原始 AP 断开连接但尚未完全连接到目标 AP 的期间，第 2 层流量可能会短暂暂停
• 漫游尝试会导致 802.1X 受控端口关闭，这会导致第 3 层链路断开，如果尝试成功，则会紧接着建立链路

在 Fuchsia 中，第 3 层链路断开目前会导致完全终止并初始化 DHCP 客户端。用户可能不会注意到这一点，但可能会导致 IP 连接中断，而用户会注意到这一点。这种“第 2 层中断导致第 3 层中断”场景并非仅限于漫游：断开连接后再连接（即使连接到同一 AP）也会导致完全终止 DHCP 客户端并重新初始化。

通过额外的设计（不在本 RFC 的讨论范围之内），可以减少此第 3 层中断，以便：

• 通过向第 3 层软件提供有关第 2 层中断的足够信息，让第 3 层软件可以选择针对预计会提供相同第 3 层连接的第 2 层中断进行优化
• 确定在发生此类第 2 层中断时要使用的正确检查（例如 DNAv4、ARP 探测、DHCP 操作、现有或新可单播性检查）来验证第 3 层连接
• 协调执行这些第 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 政策需要看到一个（或多个）特定于快速 BSS 转换支持的额外信息元素（简称 IE）。这些信息可能会传达给 SME ConnectTransaction.ConnectResult 中的 WLAN 政策（类似于此 RFC 中指定将安全配置传达给 WLAN 政策的方式）。快速 BSS 转换 AP 会通告“移动性网域”IE，设备可以使用该 IE 来识别接受来自当前 AP 的快速 BSS 转换的其他 AP。

在漫游开始时，如果指定正在使用快速 BSS 过渡，WLAN 必须保留与原始 AP 的关联状态和 RSNA。无论漫游是由 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 向 SME 发送 RoamResultInd/RoamConf，表示快速 BSS 转换漫游失败：

• SME 必须从漫游状态转换为与原始 AP 关联
• 如果 target_bss_authenticated 为 true，SME 可能会请求从目标 AP 取消身份验证（如需了解一些细节，请参阅断开连接行为）

支持快速 BSS 切换后，即使 WLAN 政策收到指示快速 BSS 切换漫游尝试失败的 OnRoamResult，也能与原始 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 时仍与原始 AP 上的 RSNA 相关联
• 快速 BSS 转换漫游成功完成后：
  • 设备将与目标 AP 一起进入与 RSNA 相关联的 802.11 状态（请参阅 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 Surface 中添加更多内容
• 出于多种原因，Softmac 必须跟踪当前信道，并且由于漫游尝试可能会更改信道或频段，因此可能需要调整此逻辑
• 需要注意的是，我们尚未对 Softmac 漫游进行原型设计，因此可能会遇到需要采用其他方法的 Softmac 固件

附录 D：重新关联安全配置

当设备漫游（通过重新关联）时，重新关联请求帧中指定的安全配置必须与原始连接所用的安全配置相同（请参阅 IEEE 802.11-2020 11.3.5.4）。我们有必要深入探讨这一要求对本 RFC 中指定的 API 更改有何影响。

WLAN 政策用于存储已保存的网络，这些网络在 NetworkConfig 中指定，旨在以人类可理解的术语表示它们：

• SSID
• 网络的高级保护类型（例如 WPA2 或 WPA3，但不包括这些大类中的许多可能的变体）
• 凭据（例如密码）

当 WLAN 政策决定连接到特定 AP 时，WLAN 政策会向 SME 发送 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 的网络
  • 或者 SME 可能已将 MFPR 设为 0（表示不必），同时将 MFPC 设为 1，这意味着无论该网络是否支持 MFP 或是否要求 MFP，设备都可以加入该网络
• 将此安全配置向下传播到 MLME，最终传播到将关联请求发送到 AP 的 Fullmac 固件

只有当 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 政策需要知道用于连接到原始 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 政策可以自由强制执行更强的安全性，只选择与初始连接中使用的安全性条件更严格的 AP，但仍需 SME 验证安全参数是否与原始安全配置匹配。对于 Fullmac 发起的漫游，可能需要引入驱动程序 API 才能更改关联/重新关联请求 IEs，并且/或者必须使用其他配置选项修改固件才能提供此行为。