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

设计初衷

保持 Wi-Fi 连接有时需要设备使用与其当前正在使用的 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 之前执行大多数有风险且耗时的漫游步骤。
• 利用硬件分流：某些完整 Mac 芯片固件中存在的漫游功能分流可以实现漫游协议，通过在芯片上（而不是在操作系统中）执行漫游逻辑来减少耗电量，并减少漫游决策和漫游开始之间的延迟。
• 让 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 Core：chcl@google.com、kiettran@google.com
• WLAN 驱动程序：rsakthi@google.com
• WLAN 政策：mnck@google.com、nmccracken@google.com

社交：

• 设计了 Wi-Fi 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 重新关联，以及在 Fuchsia WLAN 软件层之间进行协调
• 重新关联：802.11 指定的机制，用于将客户端设备的关联从一个 AP 移至另一个 AP（请参阅 IEEE 802.11-2020 4.5.3.4）

设计

漫游协调需要 FIDL API 更改，这些更改会影响几乎所有 Wi-Fi：Fullmac、MLME、SME 和 Wi-Fi 政策。此 RFC 中指定的 API 支持两种主要操作模式：

• 完全 Mac 启动漫游
• WLAN 政策发起漫游
• （如需简要讨论 Softmac 漫游如何运作，请参阅附录 C：展望 Softmac 漫游）

在 Fullmac 发起的漫游中，漫游时间和地点由 Fullmac 固件决定。为使漫游成功，必须通过 MLME 和 SME 向上传达漫游的开始，漫游结果必须通过 MLME、SME 向上传达，然后传送到 WLAN 政策。Fullmac 发起的漫游尝试从 Fullmac 发出 RoamStartInd 开始，漫游尝试的结果使 WLAN 政策收到 ConnectTransaction.OnRoamResult。消息遵循以下路径：

• 向 Fullmac 驱动程序 -> Fullmac - RoamStartInd -> MLME RoamStartInd -> SME 发送完整 Mac 固件漫游开始通知
• 将 Fullmac 固件漫游结果通知发送到 Fullmac 驱动程序 -> Fullmac RoamResultInd -> MLME RoamResultInd -> SME ConnectTransaction.OnRoamResult -> Wi-Fi 政策

在 WLAN 政策发起的漫游中，漫游的时间和地点由 WLAN 政策决定，必须通过 SME、MLME、Fullmac 驱动程序向下传达，并最终传送到设备固件。设备固件会尝试执行漫游，且漫游尝试的结果必须通过 Fullmac、MLME、SME 向上报告并报告给 Wi-Fi 政策。WLAN 政策发起的漫游尝试从 WLAN 政策发出 ClientSme.Roam 开始，漫游尝试的结果最终导致 WLAN 政策收到 ConnectTransaction.OnRoamResult。消息遵循以下路径：

• WLAN 政策 -> SME ClientSme.Roam -> MLME RoamReq -> Fullmac RoamReq -> Fullmac 固件漫游命令
• 发送到 Fullmac 驱动程序 -> Fullmac RoamConf -> MLME RoamConf -> SME ConnectTransaction.OnRoamResult -> WLAN 政策的 Fullmac 固件漫游结果通知

为了实现这些 API 变更，整个 Wi-Fi 中的逻辑会发生变化：

• Fullmac 驱动程序进行了更改，以发送用于启动漫游的固件命令，并响应来自固件的关于漫游进度和最终结果的通知
• 随着漫游过程通过身份验证、重新关联和 RSNA 设置，MLME 更改为打开/关闭 802.1X 受控端口
• 对 SME 进行了更改，以引入新的内部 SME 客户端状态（漫游）
• SME 和 Wi-Fi 政策发生变化，使 Wi-Fi 政策能够启动漫游，并通知 Wi-Fi 政策漫游的结果（WLAN 政策会收到相同的漫游结果通知，无论漫游是“Fullmac”发起还是 WLAN 政策发起）

此 RFC 未指定漫游决策的方式，而是通过 Fullmac 或 WLAN 政策做出如下判断：

• 在决定是否要漫游时，应整合可用的高阶连接信号（例如 AP 的互联网连接）
• 并且应在成功漫游后整合类似信号，以衡量漫游时是否产生了有效的连接

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

SME 需要跟踪漫游时客户端的具体数据，并管理漫游状态与其他内部状态之间的转换。系统会将一个名为“Roaming”的新内部状态添加到 SME 客户端状态机。与 SME“正在连接”状态一样，“漫游”状态是指 SME 尝试进行身份验证并与 AP（我们称之为“目标 AP”）关联。它的主要区别在于：

• 唯一能够有效转换为漫游状态的操作是从关联状态转换为正在连接状态。
• 漫游针对接收某些事件提供特殊处理；如果收到 802.11 解除身份验证，“连接”将转换为空闲状态；“漫游”仅在收到解除关联的帧时转换为“断开连接”状态，而“漫游”必须仅处理与目标 AP 的解除身份验证和取消关联帧
• 漫游状态可处理连接（RoamResultInd 和 RoamConf）不会处理的事件
• 当 SME 从关联转为漫游时，当前的 AP 会发生变化，因为 SME 正尝试连接到目标 AP；在关联和正在连接之间的转换期间，AP 不会改变

以下是 SME 客户端状态机的简要概述（以红色显示）：

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

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

如需详细了解 SME 如何过渡到/从漫游状态，请参阅下文的 Fullmac 发起的漫游和 WLAN 政策发起的漫游部分。

完全 Mac 启动漫游

您可以配置一些 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 的外部客户端（而不是使用固件客户端或 wpa_supplicant 之类的第三方客户端）。

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

• SME 必须将其视为断开连接，即使 RoamStartInd 指示维持原始关联，因为无效漫游尝试可能会继续
• SME 必须向 WLAN 政策发送 OnRoamResult，指明断开连接是因为 RoamStartInd 格式不正确
• SME 必须向目标 AP 发送撤消身份验证
• SME 可以向原始 AP 发送取消身份验证
• SME 必须转换为断开连接

如果 RoamStartInd 格式有误，SME 必须转换为漫游。

请注意，漫游时不会通知 Wi-Fi 政策。换句话说，RoamStartInd 向上传播到 SME，但漫游的开始时间不会通过 ConnectTransaction 协议传达给 WLAN 政策。在设计时，WLAN 政策团队未发现需要此类事件，但在需要时可以添加。根据对实际漫游的观察，缺少漫游开始通知到 WLAN 政策会导致 Wi-Fi 政策在短时间内不知道漫游正在进行中；如果从 SME 向 WLAN 政策发送漫游开始事件，该时长会缩短大约 50 毫秒。

向 MLME 发送 RoamStartInd 后，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 进行身份验证
• 显示此字段是为了将目标 AP 的身份验证状态告知 SME，因为漫游尝试失败后，SME 可以决定在清理期间向目标 AP 发送取消身份验证的请求

收到 RoamResultInd 后，MLME 必须使 802.1X 受控端口保持关闭状态（但请参阅展望快速 BSS 转换）。如果漫游成功：

• 设备必须与指定的 AP 相关联
• 设备仍可通过原始 AP 进行身份验证
• 设备不得与原始 AP 相关联

如果漫游失败：

• 设备仍可通过原始 AP 进行身份验证
• 设备可以通过目标 AP 进行身份验证，如 target_bss_authenticated 所指示

MLME 向 SME 发送 RoamResultInd（第 9 步）。

收到 MLME RoamResultInd 后，如果漫游成功，SME 将执行以下操作：

• SME 必须将其内部状态从漫游变为已关联，并将目标 AP 作为当前 AP
• 从原始 AP 收到任何取消关联/解除身份验证的帧后，SME 不得从“关联”状态转换
• 如果安全配置需要 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 取消身份验证（但要了解此处的一些细微差别，请参阅断开连接行为）
  • 如果 SME 决定请求从原始 AP 取消身份验证，SME 必须从漫游转换为断开连接
  • 否则，SME 必须从漫游转换为空闲

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

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

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

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

WLAN 政策发起漫游

WLAN 政策将获得启动漫游尝试并了解其结果的权限。Wi-Fi 政策如何处理由 Wi-Fi 政策发起的漫游的简要概览：

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

由于漫游尝试所使用的安全配置必须与在漫游到目标 AP 时连接到原始 AP 时所用的安全配置相同，因此 Wi-Fi 政策必须保留用于初始连接到 AP 的原始安全配置。WLAN 政策不得尝试重新关联到与初始连接中使用的原始安全配置不匹配的 AP。

为了使 WLAN 政策保留用于与原始 AP 的连接的安全配置，它必须先获取该配置，因此 SME ConnectTransaction.ConnectResult 必须获得一个新字段，将原始关联请求中使用的确切安全配置告知 WLAN 政策。

收到来自 WLAN 政策的 ClientSme.Roam 后，SME 的行为与从 MLME 收到 RoamStartInd 相同，只不过它会向 MLME 发送 RoamReq（第 2 步）。

收到来自 SME 的 RoamReq 后，MLME 的行为方式与从 Fullmac 收到 RoamStartInd 相同，只不过它会向 Fullmac 发送 RoamReq（第 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 和逻辑，但未推送到正式版设备

您可以通过两项 Gerrit 更改来实现 API 更改：一项针对 Fullmac 发起的漫游，另一项针对 WLAN 政策发起的漫游。

到目前为止，关于漫游的策略是引入漫游逻辑方面的变更，而没有在正式版设备上启用漫游逻辑。由 Fullmac 发起的漫游由 brcmfmac 驱动程序中的驱动程序功能提供保护。还有一些单元测试和集成测试，用于确保停用漫游功能，防止该功能被意外启用。

对于 WLAN 政策发起的漫游，可以在不调用 SME ClientSme.Roam/ConnectTransaction.OnRoamResult API 的情况下引入该 API，直到 WLAN 政策确信可以启用该 API。当该 API 存在后，WLAN 政策可以开始将漫游成功/失败用作其连接质量跟踪的输入，WLAN 政策逻辑可以决定是否将 ClientSme.Roam API 用于特定 AP，甚至是否使用 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 设备上的两个网络之间漫游。对于更多由 Fullmac 发起的漫游场景，我们预计还会通过新的 Antlion 测试套件扩大集成覆盖范围。

对于 WLAN 政策发起的漫游，可以在本地开发者 build 上测试这些更改，并使用 Antlion 在真实设备和 AP 硬件上进行集成测试（通过让 WLAN 政策能够在运行时在接口上启用漫游，请参阅上述第 1 阶段的讨论）。对于其他 Wi-Fi 政策发起的漫游场景，预计还会通过新的 Antlion 测试套件扩大集成覆盖范围。

执行 Fullmac 发起的漫游或 WLAN 政策发起的漫游的 Antlion 测试套件必须知道被测设备 (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 tryjobs 基础架构对运行进行中的更改进行这些测试。

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

第 3 阶段：发布到正式版设备

待集成测试结果出来后，方可开始发布。WLAN 政策必须能够按接口启用和停用漫游功能，如上面的第 1 阶段所述。

Fullmac 发起的漫游和 Wi-Fi 政策发起的漫游的发布将由 Wi-Fi 政策控制，并使用 Wi-Fi 政策的典型功能发布机制（或根据其选择的新发布机制）。WLAN 政策已包含用于连接选择、连接质量以及从连接故障恢复的逻辑。WLAN 政策会在常规操作过程中经常更改这些功能。WLAN 政策可能会引入特定于漫游的其他运行时保护措施，但此 RFC 并不尽力指定这些保护措施。

性能

在发布阶段，我们需要评估的指标包括：

• 漫游尝试 / 漫游成功，如计数和速率
• 完成漫游所用时间（以直方图表示）
• 漫游超时（以计数和速率）
• 漫游成功后接口不可用，按计数
• 漫游失败原因，按 DisconnectInfo 细分（大致上，断开连接来源和原因）
• 长时间漫游

我们还需要监控与漫游无关的指标：

• 非漫游断开连接次数（不应显著增加）
• 正常运行时间比率（应该不会显著降低）
• 空闲接口自动连接数（不应显著增加）

工效学设计

此 RFC 未指定最终用户对漫游的控制机制。其他操作系统使最终用户无法控制漫游（如 MacOS），或通过特殊配置（如 Windows、Linux）进行非常有限的控制。目前，我们不要求 Wi-Fi 政策为最终用户提供漫游控件。因此，Fuchsia 最终用户不会因引入 Fullmac 启动或 WLAN 政策发起的漫游而承担巨大的认知负载。唯一预期的用户可见效果是接入点之间的某些转换会更快。对最终用户而言，漫游失败与任何其他连接中断是无法区分的，并且从中断中恢复的过程就像是不涉及漫游的连接中断：常规扫描并连接。

向后兼容性

早在 Fuchsia 存在之前，802.11 规范就包含漫游（重新关联）。

对于向后兼容性而言，主要考虑因素是，对于许多使用 Fuchsia WLAN 的现有设备，漫游的引入不会经常导致有效的网络连接无法使用。如上文的部署部分所述，让 WLAN 政策能够明确决定何时启用和使用漫游功能，将对确保使用漫游功能不使接口处于降级或无法使用状态大有帮助。WLAN 政策可以：

• 限制漫游扫描
• 将有问题的 AP 列入拒绝名单
• 实施退避算法来减少漫游尝试次数
• 在运行时停用漫游

安全注意事项

存在三个安全问题：

• 原始 AP 和目标 AP 必须具有相同的 SSID
• 目标 AP 必须与原始 AP 的连接中指定的安全参数匹配
• 决定要连接到哪个 AP 始终是 Wi-Fi 政策的控制范围；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 可让完整 Mac 和 WLAN 政策启动漫游并了解漫游结果。这些操作会使用已用于现有（非漫游）连接和断开连接逻辑的信息。此设计不会改变 WLAN 软件的当前隐私状况。

测试

• 已针对 Fullmac 驱动程序（使用 brcmfmac Sim 框架）运行单元测试
• 对于 Fullmac 发起的漫游（使用 Antlion WlanWirelessNetworkManagementTest 套件），在真实设备和 AP 硬件上已经存在集成测试
• 我们将创建进一步的集成测试，针对 Fullmac 发起的漫游和 WLAN 政策发起的漫游练习漫游场景
• 连接自动化功能将在他们的实验室设施中使用 Antlion 测试
• 您还可以使用第三方漫游测试

文档

FIDL 变更将包含有关新消息、字段和方法的重要文档。我们并未计划内联文档之外的其他文档。

缺点、替代方案和问题

BSSID 屏蔽名单扩展

完整的 Mac 发起的漫游可能需要 BSSID 屏蔽名单 API（类似于 Android 中存在的 API），从而允许 WLAN 政策指定某些不应连接到的 AP。这将允许 Wi-Fi 政策，以避免 Fullmac 固件反复漫游到 Wi-Fi 政策已知无效的 AP 的情况。

是否在 Fullmac 和 Wi-Fi 策略之间共享控制

此 RFC 指定 WLAN 政策将控制 Fullmac 接口是否启用漫游逻辑。预期是 Fullmac 或 WLAN 政策可以控制接口的漫游逻辑，但可能不会同时控制两者。如果 Fullmac 和 WLAN 政策同时启动漫游尝试，则当 Fullmac 和 WLAN 政策分辨哪个 AP 最佳时，可能会导致 AP 之间出现“抖动”。BSSID Blocklist API 可让 Wi-Fi 政策在 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、Netstack、网络政策和其他管理软件管理。当发生漫游尝试时，第 2 层和第 3 层可能会中断：

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

在 Fuchsia 中，目前第 3 层链路关闭会导致完整的 DHCP 客户端拆解和初始化。此问题可能无法被用户注意到，或者可能导致用户可见的 IP 连接断开。这种“第 2 层中断导致第 3 层中断”情况不是漫游独有的情况：断开连接后建立连接（即使连接到同一 AP）会导致 DHCP 客户端完全断开，并且现在执行 init 操作。

通过额外设计（此 RFC 范围之外）可以减少第 3 层中断，以实现以下目的：

• 为第 3 层软件提供选项，通过提供有关第 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)
  • 检测 IPv6 网络连接的简单过程
• Linux cfg80211 子系统（请参阅函数 connect 和 cfg80211_roamed 的文档）
• 适用于企业客户的 macOS 无线漫游
• Microsoft WifiCx OID_WDI_TASK_ROAM
• wpa_supplicant 开发者文档（尽管很少有适当文档）

附录 A：展望快速 BSS 过渡

Fuchsia WLAN 目前不支持快速 BSS 转换。通过快速 BSS 转换，设备可以在 RSNA 保持不变的情况下将其关联移至目标 AP。当 Wi-Fi 支持快速 BSS 转换时，有几项行为会发生变化，并且当前设计将这些行为变更考虑在内。

在初始连接时，WLAN 政策将需要查看一个或多个特定于快速 BSS 转换支持的额外信息元素（缩写 IE）。这些信息可能会传达给 SME ConnectTransaction.ConnectResult 内的 Wi-Fi 政策（类似于此 RFC 指定安全配置传递给 Wi-Fi 政策的方式）。快速 BSS 转换 AP 会通告“移动域”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 政策将能够保留使用原始 AP 的现有 ConnectTransaction，即使在 WLAN 政策收到指示快速 BSS 转换漫游尝试失败的 OnRoamResult 之后也是如此。

快速 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 关联的 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 核心团队讨论后，大家普遍一致认为，如果重构 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）

那么 SME：

• 将此更详细的规范与 AP 提供的安全配置（包含在 BSS 说明中）进行比较
• 决定将要包含在关联请求中的安全配置
• 生成将在关联请求中发送到 AP 的确切字节
  • 例如，对于 WPA2 网络，SME 会生成一个 RSNE 信息元素
  • RSN 可能将 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。

对于由 Fullmac 发起的漫游尝试，这并不要求使用任何其他 API。SME 会决定将在原始关联请求中使用的安全配置，Fullmac 存储此配置，而 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 政策获取和/或设置安全配置。

我们还可能会发现，与 802.11 规范所规定的限制条件相比，我们希望 WLAN 能够提供更强大的安全保证。对于 WLAN 政策发起的漫游，WLAN 政策将自由执行更强的安全防护措施，具体做法是仅选择符合比初始连接中所用安全标准更严格的安全标准，但仍需要接受 SME 验证，确认安全参数与原始安全配置一致。对于 Fullmac 发起的漫游，可能需要引入驱动程序 API 以允许更改关联/重新关联请求 IE，并且/或者必须使用其他配置选项修改固件以提供此行为。