802.11k/v/r 漫游机制

Wi-Fi 漫游如果只看结果，就是终端从 AP1 换到了 AP2。但现场排障很少卡在这个层面。

更麻烦的是这些现象：

1. 终端为什么迟迟不走；
2. 走的时候为什么断流；
3. AP/AC 明明开了 802.11k/v/r，为什么体验还是差；
4. 抓包里看到 BTM Request 或 FT Reassociation，是否就能证明漫游机制正常；
5. 是 AP 配置问题、终端算法问题、射频覆盖问题，还是认证密钥协商问题。

这篇先按一个边界展开：大多数情况下，漫游由 STA 决策；802.11k/v/r 只是把候选、引导、认证这几件事做得更可控。

三者大致对应的位置：

802.11k：帮 STA 更快知道附近有哪些候选 AP          -> 去哪儿
802.11v：AP/AC 给 STA 下发 BSS 切换建议或请求       -> 该不该走、建议去哪儿
802.11r：减少切换到目标 AP 时的认证/密钥协商耗时     -> 怎么快点切过去

所以只说“开了 kvr”意义不大。终端是否支持、关联时是否协商、空口上有没有对应帧、FT 密钥路径是否走通，这些才决定一次漫游能不能解释清楚。

一、漫游边界先定住

Wi-Fi 漫游不是 AP 单方面把 STA “踢到”另一个 AP。大多数客户端实现里，什么时候 roam、roam 到哪个 BSS、是否接受 AP 的建议，最终仍由 STA 的 supplicant、driver、firmware 或芯片内部 roaming engine 决定。

AP/AC 能做的事情主要是：

• 通过 Beacon/Probe Response 暴露能力与负载信息；
• 通过 802.11k 提供邻居 AP 信息；
• 通过 802.11v BSS Transition Management 建议 STA 切换；
• 通过 deauth/disassoc 等方式强制断开，但这不是平滑漫游；
• 通过 802.11r 提供快速过渡所需的密钥层支持；
• 通过射频规划、功率、最小 RSSI、band steering 影响 STA 的选择。

STA 自己通常会综合这些输入：

• 当前 RSSI/SNR；
• 当前链路重传率、PER、ACK miss、MCS 下降；
• Beacon miss 或连接稳定性；
• 候选 BSS 的 RSSI、信道、频段、负载、能力；
• 安全模式是否兼容；
• 应用是否有低延迟需求；
• 芯片/驱动是否启用 offload roaming；
• 厂商自己的 roaming threshold、hysteresis、blacklist 策略。

排障时不能只盯 AP 侧“有没有下发漫游建议”。STA 后面有没有扫描、有没有选候选、有没有发 Reassociation、密钥有没有装上，缺一段都不能算闭环。

二、一次漫游可以拆成三个阶段

把 k/v/r 混在一起看容易乱。按时间线拆开会更清楚。

阶段 1：漫游前
STA 还连在 old AP 上，开始感知链路变差或收到 AP 建议
可能动作：背景扫描、读取 Neighbor Report、评估候选 BSS
相关机制：802.11k、部分 802.11v

阶段 2：漫游触发与目标选择
STA 决定是否离开 old AP，并选择 new AP
可能动作：BTM Request/Response、Candidate List 评估、主动扫描补充
相关机制：802.11v、STA 私有算法

阶段 3：切换执行
STA 到 new AP 完成认证、关联、密钥安装、数据恢复
可能动作：Authentication、Reassociation、EAPOL、FT Authentication/FT Reassociation
相关机制：802.11r、RSN、PMK/PMK-R0/PMK-R1、4-way handshake

802.11k 减少“找目标”的成本；802.11v 提供“引导目标”的能力；802.11r 减少“切过去”的认证成本。三者不互相替代：

• 有 k 没 r：候选找得快，但切换认证仍可能慢；
• 有 r 没 k：切换动作快，但 STA 仍可能花时间扫描候选；
• 有 v 没 k：AP 可以建议，但候选信息可能不充分；
• k/v/r 都开：仍然可能因为终端不支持、配置不匹配、射频差、候选表错而漫游差。

三、802.11k：不是让 STA 漫游，而是减少盲扫

802.11k Radio Resource Measurement 覆盖的内容不少，漫游里最常看的还是 Neighbor Report。

Neighbor Report 的目标不是替 STA 做决定，而是告诉 STA：附近有哪些同 ESS 的候选 BSS，这些 BSS 在什么信道、有什么能力、优先级大概如何。

典型交互是：

STA -> AP: Neighbor Report Request
AP  -> STA: Neighbor Report Response
          Neighbor AP 1: BSSID / Operating Class / Channel / PHY Type / BSSID Information
          Neighbor AP 2: BSSID / Operating Class / Channel / PHY Type / BSSID Information
          ...

没有 802.11k 时，STA 为了找候选 AP，可能要做更重的主动扫描或被动扫描：

2.4 GHz: channel 1/6/11 或全信道扫
5 GHz: 多个非 DFS/DFS 信道扫
6 GHz: PSC 信道、RNR、FILS Discovery 等另说

扫描会带来几个工程问题：

• STA 离开当前工作信道，业务收发短暂停顿；
• DFS 信道被动等待更久；
• 主动扫描 Probe Request/Response 增加空口开销；
• 如果芯片没有良好的 background scan/off-channel 调度，语音/游戏流会出现抖动；
• IoT 设备可能因为省电策略不愿频繁扫描。

Neighbor Report 可以让 STA 只扫少数目标信道，甚至直接去候选信道验证，从而缩短 roam 前的准备时间。

Neighbor Report 重点字段

抓包时不能只看到 Neighbor Report Response 就停下，里面的候选信息要逐项核对：

• BSSID：候选 AP 的 BSSID，不能只是同 SSID 的随机 AP；
• Operating Class：监管域下的信道集合表达，和 channel 一起决定候选位置；
• Channel Number：目标 BSS 所在信道；
• PHY Type：候选 BSS 的 PHY 类型；
• BSSID Information：包含 reachability、security、key scope、spectrum management、QoS、APSD、RM 等能力位；
• 可选 subelement：例如 preference、TSF、measurement pilot、vendor specific 等。

邻居表不准时，问题通常长这样：

Neighbor Report 给了 AP，但信道错了
Neighbor Report 给了同 SSID，但不是同 mobility domain 的 AP
Neighbor Report 漏掉最近的 AP
Neighbor Report 里候选 AP RSSI 实际很差
Neighbor Report 包含安全能力不兼容的 BSS

如果 STA 按这个表去找候选，结果可能比盲扫还差。

802.11k 排障顺序

建议按这个顺序看：

1. Beacon/Association 是否声明 RM capability；
2. STA 是否真的发出 Neighbor Report Request；
3. AP 是否回复 Neighbor Report Response；
4. Response 里候选 BSSID/channel 是否正确；
5. STA 后续是否去这些信道扫描或尝试 Reassociation；
6. 如果 STA 不请求 Neighbor Report，是否是终端不支持、驱动没开、阈值未触发，还是 AP 能力没协商成功。

特别注意：有些终端即使支持 802.11k，也不一定每次漫游前都请求 Neighbor Report。它可能使用缓存、驱动内部扫描结果或厂商私有算法。

四、802.11v：BTM 是建议，不是遥控器

802.11v Wireless Network Management 也不只服务于漫游。和漫游关系最直接的是 BSS Transition Management，简称 BTM。

BTM 不是“AP 遥控 STA 漫游”。它只是 AP/AC 给出切换建议，STA 可以接受、拒绝，也可以不响应。

典型帧序：

AP  -> STA: BSS Transition Management Request
          Request Mode
          Disassociation Timer
          Validity Interval
          Candidate List Entries

STA -> AP : BSS Transition Management Response
          Status Code
          Target BSSID(可选)

STA -> new AP: Reassociation / FT Reassociation

BTM Request 里最值得看的不是“有没有发”，而是 Request Mode 和候选列表。

Request Mode 的工程含义

Request Mode 里可能包含这些语义：

• 是否包含 Preferred Candidate List；
• 是否要求 abridged，只建议列表中的候选；
• 是否设置 Disassociation Imminent；
• 是否带 BSS Termination Included；
• ESS Disassociation Imminent 等。

如果 Disassociation Imminent 被置位，AP 的语气更强：我准备在某个 timer 后断开你。但这仍不等于 STA 一定会按推荐目标漫游。STA 可能提前走，也可能拒绝，也可能等到被断开后重新连接。

如果 AP/AC 为了“优化漫游”频繁发 aggressive BTM，可能造成反效果：

• STA 正在传输业务，被频繁打断评估；
• 候选 RSSI 没明显优势，STA 拒绝；
• STA 被引导到负载更高或干扰更强的 AP；
• 多 AP 互相拉扯，出现 ping-pong roaming；
• 某些终端对 BTM 实现保守，干脆忽略。

BTM Response 不要只看 Accept

BTM Response 里的 Status Code 很关键，至少要区分这些方向：

Accept：STA 接受建议，可能给出 Target BSSID
Reject：STA 拒绝，原因可能是候选不合适、延迟、未指定原因等
No suitable candidates：没有合适候选

工程分析时要把 BTM Response 和后续空口行为连起来看：

BTM Response = Accept
但没有 Reassociation 到 Target BSSID
=> 可能后续扫描失败、认证失败、目标 AP 不可达、STA 内部策略改变

BTM Response = Reject
但随后 STA 自己漫游到另一个 BSSID
=> AP 建议目标不是 STA 认为的最佳目标

STA 不回 BTM Response
=> 可能不支持、不接受、处于省电/离线扫描窗口、管理帧保护/兼容性问题

802.11v 不是踢人策略

有些系统把“低 RSSI 踢人”包装成漫游优化：低于阈值就 deauth/disassoc。这个动作可以迫使 STA 重新连接，但它不是平滑漫游。

如果现场 VoIP 卡顿、TCP 断流、IoT 重连慢，先看 AP 到底是在发 BTM，还是直接 deauth：

平滑引导：BTM Request -> BTM Response -> Reassociation
粗暴踢人：Deauthentication/Disassociation -> STA 重新扫描 -> Authentication -> Association

后者可能在报表里看起来“终端最终去了更好的 AP”，但用户体验已经受损。

五、802.11r：快的是密钥过渡，不是无线瞬移

802.11r Fast BSS Transition 解决的是安全网络下漫游认证耗时问题。它不会替 STA 选择目标 AP，也不会改善目标 AP 的 RSSI，更不会消除所有扫描时间。

没有 802.11r 的 WPA2-Enterprise 漫游可能很慢，因为 STA 到新 AP 后可能需要重新走 802.1X/EAP，再生成 PMK，然后 4-way handshake。

802.11r 做的是密钥层级预布置：同一个 Mobility Domain 内，STA 切到目标 AP 时不必完整重跑高成本认证。

简化理解：

MSK/PMK
  -> PMK-R0   在 R0KH 范围内使用
      -> PMK-R1   派生给具体目标 AP/R1KH
          -> PTK  用于 STA 与目标 AP 的数据保护

关键角色：

• Mobility Domain Identifier (MDID)：同一快速漫游域标识；
• R0KH：R0 Key Holder，通常与认证器/控制器侧相关；
• R1KH：R1 Key Holder，通常对应具体 AP；
• PMK-R0 / PMK-R1：FT 密钥层级中的关键材料；
• FTIE：Fast Transition Information Element，携带 MIC、ANonce、SNonce、R1KH-ID、R0KH-ID 等信息；
• RSNIE：安全能力，里面会体现 AKM suite 是否为 FT 类型。

Over-the-Air 与 Over-the-DS

FT 现场主要看两种执行方式。

Over-the-Air：STA 直接在目标 AP 信道上完成 FT 认证/重关联。

STA -> new AP: FT Authentication Request
new AP -> STA: FT Authentication Response
STA -> new AP: Reassociation Request + FTIE/RSNIE
new AP -> STA: Reassociation Response + FTIE/RSNIE
数据恢复

Over-the-DS：STA 仍通过 old AP，把 FT Action 帧转发给目标 AP 完成预交互，然后再切过去。

STA -> old AP: FT Action Request  (目标 new AP)
old AP/new AP -> STA: FT Action Response
STA 切到 new AP 信道
STA -> new AP: Reassociation Request + FTIE/RSNIE
new AP -> STA: Reassociation Response + FTIE/RSNIE
数据恢复

实际产品选择哪种方式，取决于 AP/AC、终端芯片、驱动、拓扑和兼容性，不能只看标准名词。

FT 与 4-way handshake 的关系

FT 不是“完全没有密钥握手”。它是把密钥确认和重关联过程结合起来，减少重新认证路径。

抓包时经常会看到这些现象：

• FT roam 中可能看不到完整传统 EAP 过程；
• Reassociation Request/Response 里会有 MDIE、FTIE、RSNIE；
• AKM suite 可能是 FT-PSK 或 FT-802.1X；
• 如果 FT 失败，终端可能 fallback 到普通 roam，再走传统认证/4-way；
• 某些抓包工具对 FT 字段解析不完整，需要看原始 IE。

判断 802.11r 是否生效，不能只看“AP 配置开了 11r”。关联能力、AKM、MDIE/FTIE、FT Authentication 或 FT Reassociation 都要对得上。

六、k/v/r 在 Beacon 和 Association 里怎么体现

排障第一步通常不是等漫游发生，而是看初始连接时能力有没有协商成功。

Beacon / Probe Response

AP 侧需要暴露能力：

• RM Enabled Capabilities：802.11k 相关能力；
• Extended Capabilities：BSS Transition 等 802.11v 能力位；
• Mobility Domain IE：802.11r 的 MDID、FT capability/policy；
• RSN IE：AKM suite 是否包含 FT-PSK、FT-802.1X、FT-SAE 等；
• 同 SSID 下不同 BSSID 的安全配置是否一致。

同一个 ESS 下，如果有的 AP 带 FT AKM、有的不带，或者 MDID 不一致，就会出现“某些方向能快漫游、某些方向失败”的现象。

Association Request / Response

STA 初始关联时也会声明自己要用什么能力：

• 是否声明 RM capability；
• 是否支持 BSS Transition；
• RSN 里选择的 AKM 是否是 FT 类型；
• 是否接受 AP 的 FT/PMF/security policy；
• Association Response 是否成功确认。

AP Beacon 里有 11r，不代表 STA 这次连接用了 11r。STA 可能因为兼容性、配置、PMF、安全模式、驱动策略，选择非 FT AKM。

七、抓包应该怎么抓

漫游问题最好至少双信道或多点抓包。单个 sniffer 固定在 old AP 信道，很可能只能看到 STA 离开，看不到它到 new AP 后发生了什么。

理想抓包方式：

Sniffer A：固定 old AP 信道
Sniffer B：固定 new AP 信道
Sniffer C：跟随 STA 或多信道扫描（可选）
AP/AC 日志：记录 steering、BTM、auth、reassoc、key install
STA 日志：driver/supplicant/firmware roam reason、candidate score、RSSI、FT status

只用一个网卡做 channel hopping 抓包也能看一些线索，但会漏帧，尤其是 FT Authentication、Reassociation、EAPOL 这种关键短帧。

推荐过滤关注点

抓包时按这个顺序看：

1. old AP 上的 Beacon、RSSI、重传、QoS Null、data retry；
2. STA 是否做 Probe Request 或 off-channel 扫描；
3. 是否出现 Neighbor Report Request/Response；
4. 是否出现 BTM Request/Response；
5. STA 是否对目标 BSSID 发 Authentication 或 FT Authentication；
6. 是否出现 Reassociation Request/Response；
7. Reassociation 是否成功；
8. 是否发生 EAPOL/FTIE 密钥交互；
9. 切换前后数据流中断时间；
10. 是否有 deauth/disassoc，以及 reason code。

抓包时间线比单帧更重要

漫游排障不要孤立看某一帧。要把时间线串起来：

T0  STA 数据重传升高，RSSI 下降
T1  AP 发 BTM Request，建议 BSSID = AP2
T2  STA 回 BTM Response: Accept
T3  STA 在 AP2 信道发 FT Authentication Request
T4  AP2 回 FT Authentication Response
T5  STA 发 Reassociation Request，带 MDIE/FTIE/RSNIE
T6  AP2 回 Reassociation Response: Success
T7  数据恢复

关注：T1 到 T7 的耗时、T3/T5 是否重传、T6 status、T7 数据是否真的恢复

只看到 T1 就写“802.11v 已经生效”，证据不够。

八、驱动和固件侧要看什么

很多移动终端和 IoT 芯片把 roaming 决策放在 firmware 或 driver 里，hostapd/wpa_supplicant 日志只能看到一部分。

STA 侧建议看这些信息：

• 当前 BSSID、RSSI、SNR、noise floor；
• beacon loss、RSSI low event、PER high event；
• scan trigger reason；
• scan result 列表和候选 BSS score；
• roam trigger reason；
• roam reject reason；
• authentication/reassociation status code；
• FTIE MIC failure、R0KH/R1KH mismatch、PMKID mismatch；
• key install 成功/失败；
• roam complete 时间戳；
• 数据队列是否 stop/wake，是否发生 DHCP/ARP/TCP 重连。

AP/AC 侧建议看：

• STA capabilities：是否支持 k/v/r；
• Neighbor Report 生成来源和候选列表；
• BTM 触发原因：RSSI、负载、频段引导、手工策略；
• BTM Response status；
• 目标 AP 是否收到认证/重关联；
• FT key holder 是否一致；
• mobility domain、NAS identifier、R0KH/R1KH 配置；
• PMF/RSN/AKM 是否匹配；
• disassoc/deauth reason code；
• controller 是否发生 AP 间上下文同步失败。

只有 AP 侧日志，容易把“STA 不愿意走”误判成“v 不生效”；只有 STA 侧日志，又看不到 AC 侧邻居表和 BTM 策略错误。

九、故障模式

1. 开了 802.11k，但终端还是全信道扫描

先别急着认定 11k 没生效。要把这几件事拆开看：

• STA 有没有发 Neighbor Report Request；
• Association 阶段 RM capability 有没有协商上；
• AP 返回的 Neighbor Report 是否可信；
• 候选列表有没有漏掉目标频段或目标 BSSID；
• STA 是否因为自身策略仍然要求主动验证 RSSI；
• 驱动 roaming engine 是否直接使用缓存扫描结果，而不是依赖 11k。

如果 Request/Response 是完整的，但 STA 仍然全信道扫，问题多半在终端策略或邻居表质量，而不是“AP 没开 11k”。

2. AP 发了 BTM，STA 不走

这种情况要先看 BTM Response，而不是直接怪终端。

• STA 可能根本不支持 BSS Transition；
• STA 支持，但当前策略拒绝；
• 候选 AP 的 RSSI 没有明显优势；
• 候选 AP 负载高、能力不匹配或安全配置不同；
• Request Mode 太激进，终端直接拒绝；
• STA 正在省电、扫描、语音保护或应用敏感状态；
• 某些终端实现本来就很少接受 BTM。

重点看 BTM Response status、Target BSSID、后续扫描动作和 STA 日志里的 roam reason。

3. 802.11r 开了，但切换仍然慢

先确认慢在哪里。很多时候瓶颈不在 FT 本身。

• STA 初始关联时没有选择 FT AKM；
• 目标 AP 不在同一 MDID；
• R0KH/R1KH 配置或同步错误；
• PMK-R1 不可用，fallback 到普通认证；
• FTIE MIC 校验失败；
• 802.1X 后端或控制器同步慢；
• 漫游前扫描耗时很长，认证阶段并不是瓶颈；
• 切过去后 DHCP/ARP/网关路径异常，被误认为 Wi-Fi roam 慢。

抓包里要对 RSN AKM、MDIE/FTIE、FT auth/reassoc status、EAPOL 是否重跑、数据恢复时间。

4. 漫游发生了，但业务还是卡

Reassociation Success 只是管理面成功，业务面还要单独看。

• roaming break time 超过业务容忍；
• 上层 TCP 因丢包进入恢复；
• 语音 RTP jitter buffer 被打空；
• 切换后 ARP/ND 更新慢；
• 目标 AP airtime 忙，RSSI 好但实际吞吐差；
• QoS/WMM/DSCP 映射不一致；
• 省电队列或 U-APSD 在切换前后处理异常。

这一类问题要把 Wi-Fi 管理帧和业务流时间戳放在一起看，单看 Reassociation 很容易误判。

5. 终端在两个 AP 之间来回跳

ping-pong roaming 一般不是单个协议帧的问题，而是策略和射频一起造成的。

• 两个 AP 覆盖重叠过强，RSSI 差值小；
• roaming hysteresis 太小；
• AP steering 策略太激进；
• 2.4/5 GHz band steering 与 roaming steering 互相打架；
• Neighbor preference 不合理；
• 终端 blacklist/penalty 策略和 AC 策略冲突。

连续几次 roam 的 BSSID、RSSI、BTM 触发源、候选 preference、终端 roam score 要放在同一条时间线上看。

十、配置检查清单

上线前至少检查这些项。

ESS 一致性

同一个漫游域内：

• SSID 一致；
• 安全模式一致；
• AKM suite 一致；
• 加密套件一致；
• PMF 策略一致；
• VLAN/二层网络策略按设计一致；
• captive portal、ACL、RADIUS policy 不制造 AP 间差异。

如果 AP1 是 WPA2-PSK，AP2 是 WPA2/WPA3 transition，AP3 又强制 PMF，终端漫游行为可能非常不稳定。

802.11r 配置

重点看：

• Mobility Domain ID 是否一致；
• FT over-the-air / over-the-DS 是否与终端兼容；
• FT-PSK、FT-802.1X、FT-SAE 是否按安全模式正确启用；
• R0KH/R1KH 是否正确配置或由控制器自动同步；
• NAS Identifier、R1KH-ID 是否稳定；
• 多控制器、多站点是否存在 key holder 不一致；
• legacy 终端是否因为 11r 兼容性问题无法关联。

802.11k/v 配置

重点看：

• AP 是否在 Beacon/Probe Response 暴露对应能力；
• Neighbor list 是否自动生成且正确；
• 是否需要手工补充邻居；
• Candidate preference 是否符合覆盖规划；
• BTM 触发阈值是否合理；
• Disassociation Imminent 是否过于激进；
• low RSSI kick 是否和 BTM 引导策略冲突。

射频规划

k/v/r 救不了糟糕的射频设计。

如果覆盖本身有问题，协议机制只能缓解，不能根治：

• AP 间覆盖断层；
• 同信道干扰严重；
• 发射功率过大导致 sticky client；
• 2.4 GHz 过度拥塞；
• DFS 信道导致扫描/可用性复杂；
• AP 密度过高导致候选太多、干扰太强；
• 天线方向和安装位置不合理。

很多“漫游问题”最后不是 802.11k/v/r 配错，而是 RSSI 看似够，SNR、重传、airtime 和候选质量都不够。

十一、排障路径

不要一上来就反复开关 k/v/r，先把问题落到具体阶段。

1. 明确症状
   是 sticky、不漫游、漫游慢、断流、认证失败，还是 ping-pong？

2. 确认终端能力
   STA 是否支持 802.11k/v/r？本次关联是否协商？

3. 看射频质量
   old AP 与 new AP 的 RSSI/SNR/重传/airtime 是否支持合理漫游？

4. 看候选发现
   是否有 Neighbor Report？候选 BSSID/channel 是否正确？STA 是否扫描候选？

5. 看引导过程
   是否有 BTM Request/Response？状态码是什么？目标 BSSID 是谁？

6. 看切换执行
   是否 FT Authentication / Reassociation？status code 是否 success？

7. 看密钥路径
   AKM、MDIE、FTIE、PMKID、R0KH/R1KH 是否匹配？是否 fallback？

8. 看业务恢复
   首个数据帧、ARP/ND、TCP/RTP 恢复时间是多少？

按这个路径走，最后应该能把问题落到某一段：

候选找不到   -> 多看 802.11k、扫描、邻居表、射频
STA 不愿走   -> 多看 802.11v、BTM status、roam threshold、候选质量
切换慢/失败  -> 多看 802.11r、RSN、FTIE、EAPOL、key holder
切完还卡     -> 多看 QoS、二层路径、ARP/ND、业务重传、目标 AP 负载

十二、几个容易误判的结论

“开了 k/v/r，漫游就一定快”

不对。k/v/r 只优化部分环节。扫描、认证、数据恢复、射频质量、终端策略都会影响最终体验。

“AP 发 BTM，STA 不走就是终端有问题”

不一定。可能是候选 AP 质量不够，AP 策略太激进，候选表错误，或者 STA 的业务状态不适合马上切换。

“FT 漫游不应该有任何中断”

不对。FT 减少认证耗时，但 STA 仍要切信道、重关联、安装密钥、恢复队列。中断可以很短，但不是物理上不存在。

“RSSI 高的 AP 就是好目标”

不一定。目标 AP 的 airtime、干扰、负载、信道宽度、频段、回程、QoS 策略都可能更差。

“抓到 Reassociation Success 就说明业务恢复”

不一定。管理面成功不等于数据面马上正常。还要看密钥安装、首个加密数据帧、ARP/ND、TCP/RTP 连续性。

十三、现场结论怎么写

这种写法信息量太低：

现场已开启 802.11k/v/r，漫游正常。

更像一份能复盘的结论：

STA 初始关联时选择 FT-PSK AKM，Association Request/Response 中可见 MDIE；
AP Beacon 暴露 RM Enabled Capabilities 与 BSS Transition 能力；
漫游前 STA 向 AP1 请求 Neighbor Report，AP1 返回 AP2/AP3 的 BSSID 与正确信道；
AP1 在 RSSI 低于策略阈值后发送 BTM Request，候选首选 AP2；
STA 回复 BTM Response Accept，并在 18 ms 后于 AP2 信道发起 FT Authentication；
FT Authentication 与 Reassociation 均成功，未重跑完整 EAP；
从最后一个 AP1 数据帧到 AP2 首个数据帧间隔约 45 ms；
业务侧 RTP sequence 连续，未见明显丢包扩大。

这种结论能说明 k/v/r 在这次漫游里分别起了什么作用，也能让后面的人复查。

十四、收尾

802.11k/v/r 要分开理解：

• 802.11k 解决候选发现效率：让 STA 少盲扫、快找到可能目标；
• 802.11v 解决网络侧引导能力：让 AP/AC 能表达“建议你去哪里”；
• 802.11r 解决安全切换耗时：让 STA 到目标 AP 时更快完成密钥过渡。

但漫游体验最终取决于完整链路：射频覆盖、STA 决策、邻居表、BTM 策略、FT 密钥配置、驱动/固件实现、数据面恢复，任何一环出问题，都可能表现为“开了 kvr 还是卡”。

现场更应该问：

能力有没有协商？
候选有没有给对？
STA 有没有接受？
FT 有没有真的走？
切换耗时卡在哪个阶段？
业务流什么时候恢复？

这些问题能回答清楚，一次 Wi-Fi 漫游才算看明白。