RFC-0243：WLAN 漫游

RFC-0243：WLAN 漫游
状态	已接受
区域	WLAN
说明	如果设备连接到具有多个接入点的无线网络，则可以在这些接入点之间漫游。“漫游”是指设备在同一无线网络内将其连接从一个接入点 (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，以避免完全断开连接。本文档介绍了支持 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 政策正在进行大量工作，以确定何时何地进行漫游。此处描述的 API 和逻辑更改对于允许 WLAN 政策发起漫游并在漫游尝试完成时做出响应至关重要。

利益相关方

辅导员：

neelsa@google.com

审核者：

• 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 核心逻辑的多种可能实现方案创建了原型，并在与 WLAN 核心团队的会议中以及与 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 驱动程序更改为发送启动漫游的固件命令，并响应固件关于漫游进度和最终结果的通知
• MLME 更改为在漫游通过身份验证、重新关联和 RSNA 设置进行时打开/关闭 802.1X 控制的端口
• SME 更改，以引入新的内部 SME 客户端状态（漫游）
• SME 和 WLAN 政策更改，使 WLAN 政策能够发起漫游，并通知 WLAN 政策漫游结果（无论漫游是由 Fullmac 发起还是由 WLAN 政策发起，WLAN 政策都会收到相同的漫游结果通知）

此 RFC 未指定 Fullmac 或 WLAN 政策应如何做出漫游决策，只是建议漫游决策：

• 在决定是否漫游时，应纳入可用的更高级别连接信号（例如 AP 的互联网连接）
• 并且在成功漫游后应纳入类似信号，以评估漫游是否产生了有效的连接

SME 将获得新的漫游内部客户端状态

SME 需要在客户端漫游时跟踪有关该客户端的特定数据，并管理漫游状态与其他内部状态之间的转换。将向 SME 客户端状态机添加一个名为“漫游”的新内部状态。与 SME 的连接状态类似，漫游状态是指 SME 尝试与 AP（我们将其称为“目标 AP”）进行身份验证和关联。二者之间存在一些关键区别：

• 进入漫游状态的唯一有效转换是从关联状态转换而来；而进入连接状态的有效转换则有很多
• 漫游对接收某些事件有特殊处理；其中，连接在收到 802.11 取消身份验证时会转换为空闲状态，或者在收到取消关联时会转换为断开连接状态，漫游必须仅处理来自目标 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 驱动程序必须向 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（第 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 的外部请求方（而不是使用固件请求方或 wpa_supplicant 等第三方请求方）。

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

• 即使 RoamStartInd 表明原始关联已保持，SME 也必须将此视为断开连接，因为无效的漫游尝试可能会继续
• SME 必须发送 WLAN 政策 OnRoamResult，指明断开连接是因为 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 不是成功，则 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 必须将其内部状态从 Roaming 更改为 Associated，并将目标 AP 用作当前 AP
• 当 SME 从原始 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 必须从 Roaming 转换到 Disconnecting
  • 否则，SME 必须从漫游状态转换到空闲状态
  • 如果 SAE 超时，且目标 AP 为：
    • SME 可以请求从原始 AP 取消身份验证
    • SME 必须从漫游直接过渡到空闲
• 如果 target_bss_authenticated 为 false：
  • SME 可以请求从原始 AP 进行取消身份验证（但请参阅断开连接行为，了解此处的一些细微差别）
  • 如果 SME 决定从原始 AP 请求取消身份验证，SME 必须从漫游过渡到断开连接
  • 否则，SME 必须从漫游状态转换到空闲状态

SME 通过每个连接的渠道使用现有的 ConnectTransaction API 与 WLAN 政策进行通信。SME 必须向 WLAN 政策发送 OnRoamResult，以告知 WLAN 政策漫游尝试已完成（步骤 10）。RoamResult 类似于 SME ConnectResult。RoamResult：

• 必须包含目标 AP 的 BSSID
• 必须包含一个状态代码，用于指明漫游是否成功
• 必须包含一个布尔值，用于指明是否已保留原始关联
  • 如果漫游成功，则必须为 false
  • 如需了解详情，请参阅展望快速 BSS 过渡
• 应包含目标 AP 的 BSS 说明，无论成功与否（但如果漫游失败，此字段可能为空）
• 如果发生了断开连接，则必须包含 SME DisconnectInfo；换句话说，如果漫游失败且未保持原始关联，则此参数为必需参数

收到 OnRoamResult 后，WLAN 政策会更新其内部状态。如果漫游成功，WLAN 政策必须继续保持现有的 ConnectTransaction 与 SME，但设备现在已关联到目标 AP。如果结果表明漫游失败：

• 如果原始关联未保留，WLAN 政策必须关闭 ConnectTransaction 并结束连接
• 在漫游失败后，WLAN 政策将开始创建新连接的过程，类似于它对任何连接丢失的响应方式

WLAN 政策发起的漫游

WLAN 政策将能够发起漫游尝试并了解其结果。简要概述了 WLAN 如何处理由 WLAN 政策发起的漫游：

当 WLAN 政策发起漫游尝试时，它会通过向 SME 发出 ClientSme.Roam 来实现（上图中的第 1 步）。Roam 包含 RoamRequest，在概念上与 SME ConnectRequest 类似，但选项较少，因为在漫游期间，SSID 和安全配置不得更改（如需详细了解漫游中使用的安全配置，请参阅附录 D：重新关联安全配置）。

由于漫游尝试必须使用与连接到原始 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 会向 MLME 发送 RoamConf（步骤 8 和 9）。RoamConf 类似于 RoamResultInd。

收到 RoamConf 后，MLME 的行为与收到 RoamResultInd 时的行为相同，只不过它会向 SME 发送 RoamConf（第 10 步）。

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

收到 OnRoamResult 后，WLAN 政策会采取与上述在 Fullmac 发起的漫游结束时讨论的相同操作。

实现

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

API 更改可在两个 Gerrit 更改中进行：一个用于 Fullmac 发起的漫游，另一个用于 WLAN 政策发起的漫游。

目前，漫游变更的策略是引入漫游逻辑变更，但不在生产设备上启用这些变更。Fullmac 发起的漫游由 brcmfmac 驱动程序中的驱动程序功能保护。我们提供了单元测试和集成测试，以确保漫游功能处于停用状态，防止该功能被意外启用。

对于 WLAN 政策发起的漫游，可以在没有任何内容调用 SME ClientSme.Roam/ConnectTransaction.OnRoamResult API 的情况下引入该 API，直到 WLAN 政策确信可以启用该 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 驱动程序代码中的漫游功能），并可以使用 Antlion 在真实设备和 AP 硬件上进行集成测试。已经有一个针对 Fullmac 发起的漫游 (WlanWirelessNetworkManagementTest) 的 Antlion 集成测试套件，该套件会测试成功和不成功的漫游尝试。现有测试套件需要支持 Fuchsia Fullmac 的设备，该设备经过检测，可在单个物理 AP 设备上的两个网络之间漫游。此外，我们还计划通过新的 Antlion 测试套件来增加集成覆盖率，以涵盖更多由 Fullmac 发起的漫游场景。

对于 WLAN 政策启动的漫游，可以在本地开发者 build 上测试这些更改，也可以使用 Antlion 在真实设备和 AP 硬件上进行集成测试（通过赋予 WLAN 政策在运行时在接口上启用漫游的功能，请参阅上文第 1 阶段中的讨论）。此外，我们还希望通过新的 Antlion 测试套件来增加集成覆盖率，以涵盖更多 WLAN 政策发起的漫游场景。

执行由 Fullmac 发起或由 WLAN 政策发起的漫游的 Antlion 测试套件必须知道这些功能是否在受测 Fuchsia 设备 (DUT) 上使用。这是必需的，因为 Antlion 需要知道是否在该受测设备上运行或跳过漫游测试。对于现有的 Fullmac 发起的漫游测试套件，Antlion 配置具有针对 WLAN 功能的特殊指令：如果 Antlion 配置中存在漫游功能，则 Antlion 会运行 Fullmac 发起的漫游测试，否则会跳过这些测试。实现应明确赋予 Antlion 查询功能支持（使用 WLAN 驱动程序功能）的能力，并且应明确赋予 Antlion 在 DUT 上运行测试之前在该 DUT 上启用漫游功能的能力。

现有的 Fullmac 发起的漫游 Antlion 测试套件以及任何新的测试套件都必须能够在具有 WLAN Antlion 测试平台的连接自动化测试平台上运行。

支持 Fullmac 启动的漫游的 WLAN 测试平台：

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

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

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

第 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 的 SSID 和安全参数。如果这些验证步骤失败，则会导致连接被拆除。如需详细了解漫游尝试中使用的安全配置，请参阅附录 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 政策发起的漫游来测试漫游场景
• 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 政策都发起漫游尝试，则需要进行额外的设计。

断开连接行为

我们正在对断开连接的情况进行非常仔细的分析。我们需要确信，在出现模糊不清的情况（例如，Fullmac 知道漫游已开始，但 SME 等更高级别层不知道）时，WLAN 仍能正常运行。

SME 中的当前断开连接逻辑尝试在大多数断开连接场景中从 AP 取消身份验证，作为清理措施。当漫游尝试导致设备离开原始 AP 的信道（甚至频段）时：

• Fullmac 可能不知道设备是否仍通过原始 AP 进行身份验证
• 因为 Fullmac 不知道，所以 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 层中断时，使用哪些正确的检查来验证第 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 过渡允许设备在 RSNA 保持不变的情况下将其关联移至目标 AP。当 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 政策漫游，都是如此。一个重要的影响是，在快速 BSS 过渡漫游开始时，MLME 不会关闭受控端口。原始连接将继续正常运行，同时通过快速 BSS 过渡建立新连接。如果快速 BSS 过渡漫游成功且 original_association_maintained 为 true：

• MLME 必须保持 802.1X 受控端口处于打开状态
• 由于受控端口从未关闭，设备可能仅在第 2 层短暂暂停（观察到大约需要 20 毫秒），而不会出现 IP 连接中断

如果漫游尝试失败（或达到漫游尝试超时时间）：

• RoamResultInd/RoamConf original_association_maintained 指定在不成功的漫游尝试期间是否一直保持与原始 AP 的关联
• 如果原始关联已保持，Fullmac 不应发起断开连接（但可能存在驱动程序知道从故障/超时中恢复需要断开连接的情况）

如果 MLME 向 SME 发送 RoamResultInd/RoamConf 以指示快速 BSS 过渡漫游失败：

• 中小企业必须从漫游过渡到与原始 AP 关联
• 如果 target_bss_authenticated 为 true，SME 可能会请求从目标 AP 进行取消身份验证（有关一些细微的详细信息，请参阅断开连接行为）

如果支持快速 BSS 转换，即使 WLAN 政策收到指示快速 BSS 转换漫游尝试失败的 OnRoamResult，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）
  • 设备将降至 authenticated 状态，并使用原始 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 核心团队讨论后，大家普遍认为，如果对 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 发送 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，设备都可以加入该网络
• 将此安全配置向下传播到 MLME，最终传播到将向 AP 发送关联请求的 Fullmac 固件

只有当 AP 安全配置与 SME 指定的安全配置相匹配时，关联才会成功（有关此过程的详细信息，请参阅 IEEE 802.11-2020 12.6.3）。IEEE 802.11-2020 11.3.5.4 要求在任何后续重新关联（漫游）请求中使用与原始关联请求中包含的 RSNE 相同的 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 来允许更改关联/重新关联请求 IE，或者必须修改固件并添加其他配置选项才能提供此行为。