验收结论先行
企业 Wi-Fi 7 的 MLO 验收，不能停在“AP 支持”这一层。更可靠的判断是：指定终端在指定系统、驱动、认证与射频环境下，能否建立预期的多链路连接；链路选择是否符合业务目标；漫游、语音、会议、桌面云、扫码终端等真实业务是否获得可感知改善。支持 MLO 的 AP 不等于所有终端和应用都能获得叠加收益，这是验收时最常见、也最需要提前写进边界的事实。
先确认能力范围
Wi-Fi 7 引入 MLO，是为了让终端在多个频段或链路之间更灵活地使用无线资源，可能带来更低时延、更高吞吐或更好的抗拥塞能力。但这些收益依赖 AP、控制器或云管平台版本、终端芯片、驱动、操作系统、国家和地区频谱规则以及现场配置共同成立。选型阶段可查阅 RUCKUS R770 官方页面核对其作为 Wi-Fi 7 AP 的定位和官方公开能力，再把这些能力映射到本项目的终端清单与业务场景，避免把产品页面上的能力直接等同于现场收益。
终端清单比 AP 清单更关键
MLO 是端到端能力，验收表应按终端型号、无线网卡、驱动版本、操作系统版本、是否启用省电策略、是否支持 6 GHz 或目标频段逐项登记。对于不支持 MLO 的终端，只能按传统单链路能力验收；对于支持 MLO 但驱动较旧的终端，应先升级并复测。会议室笔记本、移动查房车、仓储手持机、访客手机和 IoT 设备的无线行为差异很大，不能用一台高端笔记本的测速结果代表全网。
链路选择要服务业务目标
验收 MLO 时，应先定义链路策略想解决什么问题：是提高大文件传输吞吐、降低视频会议抖动、改善高密办公区拥塞，还是提升移动终端漫游连续性。不同目标对应不同观察指标。若终端在 5 GHz 信号稳定、业务带宽不高、空口拥塞轻的环境中运行，即使连接到 Wi-Fi 7 AP，也可能看不到明显叠加收益；若 6 GHz 覆盖不足或穿墙衰减导致链路频繁变化，强行追求多链路反而可能增加排障复杂度。
现场步骤要可复现
- 冻结测试窗口，记录 AP 固件、控制器或云平台版本、SSID、安全策略、频宽、功率、信道和频段启用状态。
- 按业务场景选择终端样本，至少覆盖高性能办公终端、移动终端和不支持 MLO 的传统终端。
- 分别测试单链路基线与 MLO 配置，保留同一位置、同一业务脚本、同一并发规模下的数据。
- 在会议室、开放办公区、走廊、弱覆盖边缘和漫游路径上重复测试，避免只在 AP 旁边测速。
- 记录失败样本，不把异常终端从统计中删除，而是标注其硬件、驱动和应用限制。
指标不能只看峰值速率
建议把指标分成连接、性能、稳定性和业务四类。连接类看终端是否按预期建立 MLO、链路数量是否稳定、是否频繁退回单链路；性能类看吞吐、时延、抖动、丢包和重传；稳定性类看长时间会议、文件同步、休眠唤醒、低电量模式后的连接保持；业务类看语音 MOS 或主观质量、视频会议卡顿、桌面云键鼠延迟、扫码提交耗时。峰值速率可以作为参考，但不能替代应用体验。
漫游测试要单独验收
MLO 不应被简化为“多频段同时加速”。在企业网络中，移动中的业务连续性往往比静止测速更重要。测试应覆盖同楼层移动、跨房间移动、弱覆盖边缘返回、会议中走动和终端休眠唤醒后的重连。观察重点包括漫游前后业务是否中断、链路是否异常震荡、终端是否长时间黏在低质量链路上，以及安全认证和策略下发是否引入额外等待。若某类终端在漫游中表现不稳定，应允许为该终端组采用更保守的频段或 SSID 策略。
失败边界要写进验收单
验收文件应明确：AP 支持 Wi-Fi 7 或 MLO，并不承诺所有终端、所有应用、所有位置都获得吞吐叠加。低带宽应用、服务器端瓶颈、互联网出口拥塞、终端 CPU 或驱动限制、老旧安全客户端、频谱不可用、6 GHz 覆盖不足、邻频干扰和电池省电策略，都可能让 MLO 收益不明显。对于需要较小规模或不同形态部署的 Wi-Fi 7 AP，可同时查看 RUCKUS R670 官方页面了解官方公开定位，再按项目地区、版本和现场供电、上联、安装条件复核，不应推断未公开的规格或兼容性。
回退路径要提前设计
生产上线前应准备回退方案，包括保留单链路基线配置、按终端组拆分 SSID 或策略、限制问题终端使用特定频段、调整信道宽度与发射功率、回滚 AP 或控制器配置、保留旧终端的兼容接入方式。回退不代表 MLO 失败，而是把新能力限定在真正受益的终端和业务上。最终验收通过条件应写成“哪些终端、在哪些区域、对哪些业务达到哪些指标”，而不是笼统写成“已启用 MLO”。
WeChat
Profile