Wi-Fi 6调度机制深度解析：OFDMA、MU-MIMO与TWT

我调试无线网络时最常被问到的一句话是：换了 Wi-Fi 6 路由器，为什么人多的时候还是卡？过去我会先查干扰、查终端连接数，后来发现真正值得研究的，其实是 802.11ax 里那套平时不太被注意的调度逻辑。ax调度不是某一个开关，也不是某个厂商的私有加速技术，而是 Wi-Fi 6 协议对无线信道使用权的系统性重构。它决定了 AP 怎么把频率资源切给每个终端、怎么安排多台设备同时收发、怎么让低功耗设备“约好时间”再醒来。这篇文章不聊宣传参数，只把 ax调度 的机制、实现细节和实测中容易踩的坑拆开讲清楚，适合做无线运维、终端协议开发，或者只是想搞明白“多用户场景下 Wi-Fi 6 到底强在哪”的朋友。

1. 为什么 Wi-Fi 6 要把调度放在最核心的位置

1.1 老协议的“抢车位”模式到底输在哪

在 802.11n/ac 时代，多个终端接入同一个 AP，本质上是“先听后说、抢到就发”。每个设备在发送前都要监听信道，如果信道忙就随机退避一段时间再重试。这个机制叫 CSMA/CA，它在终端少、流量小的时候足够用，可一旦会议室里同时有几十个终端，问题就暴露了：大部分时间都耗在互相退避上，信道利用率上不去。你可以把 802.11ac 的环境想象成一条没有交通信号灯的窄路，每辆车都要停下来看看有没有别的车，确认安全才往前挪。人多的时候，大家都在路口张望，真正跑起来的时间没多少。

更麻烦的是，802.11ac 的 OFDM 机制每个时刻只能把一个信道分配给一个用户，哪怕这个用户只是传一个几十 KB 的小请求，也要占用整条 20/40/80MHz 信道。视频流、文件下载、语音通话一旦混在一起，AP 就成了单线程服务员，一次只能服务一个人。

1.2 802.11ax 的三大调度核心：OFDMA、MU-MIMO、TWT

802.11ax 为了解决“抢车位”的问题，引入了三个关键能力。第一是 OFDMA，它把信道切成更小的“资源单元”，可以在同一时刻服务多个终端；第二是 MU-MIMO，它让多个终端在同一频率上通过空间维度并行传输；第三是 TWT，它让终端按约定时间醒来，减少空口竞争。这三者共同构成了 ax调度 的主体。

很多人以为 ax调度 只是 OFDMA，其实不对。OFDMA 解决的是“频率上怎么切”，MU-MIMO 解决的是“空间上怎么叠”，TWT 解决的是“时间上怎么排”。AP 需要同时考虑这三者的组合，才能在一个 Beacon 周期内安排出一份合理的“发车时刻表”。所以，ax调度 更像是一个资源调度器，而不是单一的省电功能。理解这一点，后面看厂商的“智能调度”宣传时就不会被带偏。

2. OFDMA 调度：把信道切成“拼盘”

2.1 资源单元 RU 和子载波分配逻辑

OFDMA 的核心是把一个 OFDM 符号里的子载波分成多组，每组称为一个资源单元（Resource Unit, RU）。RU 的最小单位是 26 个子载波（大约 2MHz 带宽），最大可以是 996 个子载波（整条 80MHz 信道）。在 20MHz 信道下，802.11ax 可以把它拆成 9 个 26-tone RU、5 个 52-tone RU、2 个 106-tone RU 加 1 个 26-tone RU 等不同组合。这种灵活性，是 802.11ac 完全不具备的。

具体怎么分，由 AP 的调度算法决定。比如有两个终端，一个只需要传小包，另一个正在下大文件，AP 就可以给小包终端分一个 26-tone RU，给大文件终端分一个 106-tone RU 或更大的 RU。换句话说，OFDMA 的本质是“按需分配频率碎片”，而不是简单地把整条信道轮流给每个人。这也解释了为什么 OFDMA 在“大量短帧并发”场景下收益最明显——比如办公室里的即时消息、网页加载、智能家居的心跳包。

2.2 上下行 OFDMA 调度流程与触发帧

OFDMA 不只是 AP 发数据时用，终端上传时也要用。上行 OFDMA 依赖一个关键帧：Trigger 帧。AP 发送 Trigger 帧，里面带上每个终端的 RU 分配信息、MCS、功率控制参数，收到 Trigger 的终端在指定的时间、指定的 RU 上同时发送上行数据。这个机制避免了上行数据在空口上互相碰撞，因为在协议层面已经约好了“谁在哪个格子发”。

实际抓包时，你会看到类似 Trigger frame -> Multi-User Block Ack 的交互过程。如果 AP 调度算法比较激进，上传流量占满的时候，每个 Trigger 帧会同时调度 5 到 8 个终端。这在 802.11ac 里是不可能的，因为 ac 时代的上行 MU-MIMO 基本是残废，标准虽然存在，但很少有 AP 真正启用上行多用户传输。

2.3 调度参数怎么定：RU 分配、用户分组与 Buffer 报告

那么 AP 是怎么决定给每个终端分多大 RU 的？主要依据是两个东西：一是终端缓存了多少数据要发，这叫 Buffer Status Report；二是过去一小段时间内的流量统计。802.11ax 标准里定义了 QoS Null 帧携带 Buffer Status Report，终端可以向 AP 报告队列长度，AP 再决定 RU 大小。

这里有个容易忽略的细节：RU 分配不是越大越好。给一个终端分 996-tone RU 意味着它独占整条信道，但如果这个终端只是偶尔传一个小包，这种分配会浪费大量空口时间。更合理的做法是把多个终端塞进同一个 OFDM 符号里，让信道始终是满的。所以很多商用 AP 的调度算法会偏保守，优先保证多用户都能被“轮询”到，而不是让单用户跑满峰值速率。我在调测时见过不少用户抱怨“Wi-Fi 6 单终端速率还不如 Wi-Fi 5”，这就是典型的调度策略取向问题——为了多用户并发牺牲了单用户极限速率。

3. MU-MIMO 调度与空间复用

3.1 MU-MIMO 用户配对怎么选

OFDMA 是在频率维度切分，MU-MIMO 则是在空间维度上做叠加。AP 有 4 条或 8 条天线，理论上可以同时向多个终端发送不同数据流，只要终端在空间上足够“分得开”。ax调度 里的 MU-MIMO 调度，核心任务就是挑选合适的终端组合，让它们在同一时刻共享空间流，而不互相干扰。

用户配对往往不是看信号强度，而是看协方差矩阵或信道状态信息（CSI）。简单说，AP 会通过空口探测（Sounding）过程拿到每个终端的信道信息，然后计算终端之间的空间相关性。如果两个终端方向差别很大，就适合放在同一个 MU-MIMO 组里；如果它们位置接近，空间流数再富裕也没用，因为信号到达 AP 后几乎无法区分。这个原理，有点像两个人同时说话，一个在左边一个在右边，你很容易分辨；但如果两个人贴着耳朵说，就很难分清谁说了什么。

3.2 上行 MU-MIMO 与触发式接入的配合

下行 MU-MIMO 很常见，上行 MU-MIMO 则需要 Trigger 帧配合。和上行 OFDMA 一样，AP 通过 Trigger 帧同时调度多个终端在同一时间、同一频率但不同空间流上发送。这就带来一个额外的难点：终端必须做功率调整，否则距离 AP 近的设备会把远设备的信号压掉。

802.11ax 在 Trigger 帧里包含了每个终端的目标 RSSI 参数，终端需要结合自身实际功率做调整。我在测试中看到不少终端的实现并不那么完美，尤其是老款手机在 UL MU-MIMO 模式下适配性一般，反而容易导致重传率升高。所以很多 AP 的默认调度策略会优先用 OFDMA，然后才考虑 MU-MIMO，因为 OFDMA 对终端能力的要求更低，兼容性更好。

3.3 空间复用率提升背后的调度权衡

ax调度 还引入了 BSS Coloring，通过给不同 AP 的上行链路染色，让终端可以区分“本小区”和“邻小区”的传输。如果信号已经很强，即使邻区在传输，终端也能放心地同时发送数据，这在密集部署场景能显著提升空间复用率。

但 BSS Coloring 与 MU-MIMO/OFDMA 的调度是耦合的。AP 不能只看 Color 来决定是否让终端发射，还要考虑实际的接收信噪比。我曾经在一个多家运营商共建的写字楼里调测，BSS Coloring 打开之后，干扰明显下降，但部分终端的重传率反而升高了。原因是终端看到“不同 Color”就默认可以发，结果它发出的信号在 AP 侧已经被隔壁 AP 的重负载压低。最后问题出在调色阈值和发射功率的匹配上。所以调度参数不是孤立存在的，BSS Coloring 阈值、CCA 阈值、功率控制要一起调，才能看到整体增益。

4. TWT 调度：让设备“约好时间”再来听

4.1 TWT 会话建立与两种工作模式

TWT（Target Wake Time）是 802.11ax 里很有价值的省电机制，它的核心思想是让设备在绝大多数时间内处于休眠状态，只在约定好的时间段醒来，收发数据后再睡回去。与传统 PS-Poll 省电模式不同的是，TWT 不是终端单方面决定什么时候醒，而是 AP 与终端协商一个共同的时间点，这其实就是一种时间维度的调度。

TWT 有两种常见模式：一种是 Individual TWT，AP 和每个终端单独协商唤醒时间；另一种是 Broadcast TWT，AP 在 Beacon 帧里广播一组时间槽，多个终端共享同一个唤醒窗口。IoT 设备、电池供电的传感器节点通常适合 Broadcast TWT，因为它们的流量极小，每隔几十秒或者几分钟上报一次即可。而手机这类交互型设备，更适合 Individual TWT 或者直接把 TWT 关闭，因为频繁的、不可预测的交互流量会让 TWT 成为延迟负担。

4.2 AP 如何把 TWT 排进调度表

AP 的 TWT 调度表要处理两个维度：一是时间槽的分配，二是与 OFDMA/MU-MIMO 调度周期的对齐。如果 TWT 唤醒时间和 OFDMA 传输周期错开，设备醒来后可能等不到资源，反而增加延迟。所以好的 ax调度 会把 TWT 窗口设计在信标间隔的固定位置，并把该窗口内的 RU 预留给唤醒的终端。

在实际调测中，我见过一个常见误区：厂商默认 TWT 开启，结果游戏终端和 IoT 设备混在同一广播 TWT 内，游戏终端被 IoT 设备的低速率传输拖累。排查到最后，是因为 AP 的调度器把所有低优先级的 IoT 终端都安排在同一个 TWT 窗口，而这个窗口与高优先级业务的 OFDMA 周期重叠。方案很简单，给不同业务类型设置不同 TWT 组，比如 IoT 设备走 Broadcast TWT，交互设备禁用 TWT 或走更短的 Individual TWT。

4.3 兼容性与实际收益

TWT 的实际收益和终端支持度强相关。iPhone 11 之后的机型、大量 Android 旗舰都支持 802.11ax 的 TWT，但低端终端和大量 IoT 模块可能只实现了半套。所以房间里只要有一个不支持 TWT 的老终端，它对信道占用不会因此减少，反而可能因为 AP 为它额外留了不加 TWT 的窗口，占用更多可调度时间。换句话说，TWT 的收益是“整体性”的，必须到终端覆盖率足够高的时候才明显。

如果只打算在测试环境里验证 TWT，我建议用两个终端：一个支持 TWT 的 Wi-Fi 6 手机和一个不支持 TWT 的 Wi-Fi 5 设备，同时看 AP 侧的功率曲线和空口占用时间。通常能看到支持 TWT 的设备唤醒时间呈周期性脉冲状，而不支持 TWT 的设备始终在监听。这个对比能直观解释 TWT 的价值。

5. 实测角度：ax调度 性能验证与常见问题排查

5.1 调度性能验证思路

验证 ax调度 到底有没有生效，不需要直接看厂商后台的“调度统计”，可以用抓包加无线吞吐联合判断。先构造一个混合流量场景：3 个终端同时做上行小包推送，1 个终端做下行持续下载，观察 AP 是否在一个 Trigger 帧内同时调度多个终端上行。如果只看到一个终端在某个 RU 上发送，另一个终端要等下一个符号，说明 OFDMA 调度粒度比较粗，或者说 AP 的算法比较保守。

另一个验证角度是空口时间的占用率。在 802.11ax 开启并调度正常的情况下，同样的流量负载，空口占用时间应该比 802.11ac 模式下降 30% 以上。如果下降不明显，往往不是协议问题，而是终端或者 AP 没有真正启用 802.11ax 的 Trigger-based 帧交换。很多厂商 AP 在未开启“Wi-Fi 6 增强模式”时，只是把 802.11ax 当作高速率的 802.11ac 用，OFDMA 和 MU-MIMO 都没切入。

5.2 常见问题速查表

5.3 几个不常被写进文档的实操细节

第一个细节：ax调度 的收益在高密度场景下最明显，但终端太老反而会拖后腿。如果会议室里 80% 的设备都是 Wi-Fi 5，那 OFDMA 调度器为了兼容老设备，可能依然要频繁回退到整信道传输模式，因为旧终端无法被放进同一个 OFDMA 传输中。这种情况下，就算 AP 支持 802.11ax，整体体验提升也有限。所以不要指望只靠换 AP 解决问题，终端的换代率同样重要。

第二个细节：上行 OFDMA 的 Buffer Status Report 并不一定及时。很多 Android 终端的 Wi-Fi 驱动对 Buffer Status Report 的支持质量参差不齐，AP 等不到报告，就会按预估的固定值分配 RU，导致小包被分到大 RU，浪费空口资源。我遇到的某次“上传丢包率升高”，最后是更新终端驱动后才解决的。排查时可以抓包过滤 QoS Control 字段，看终端是否定期发送 QoS Null 帧或者带缓冲报告的帧。

第三个细节：TWT 与漫游之间会有摩擦。TWT 协商成功后，终端进入深度休眠，如果它需要漫游到相邻 AP，往往要等到下一个 TWT 窗口才能执行信道扫描。在一个漫游频繁的园区网里，TWT 可能让终端的漫游时间从 200ms 拉长到 800ms 以上。处理办法是让高移动性终端跳过 TWT，或者给办公网设置较短的 TWT 周期，宁可多醒几次，也别在移动中掉线。

从我个人调试经验来看，真正的 ax调度 并不仅仅是打开一个“OFDMA”按钮那么简单，它更像是在频率、时间、空间三个维度上做均衡。单纯追求吞吐量时，减少用户并发、把 RU 给大块头是最优解；但在办公、园区这类混合业务环境里，调度的价值反而在于“让每个设备都别等太久”。如果你是做无线网络运维的，建议先把 AP 的默认调度策略摸清楚，再考虑是否手动调整。终端能力、业务模型和空口环境都会影响最终结果，纸上谈兵的参数组合往往不如实际抓包看一眼来得靠谱。