前阵子做 Wi-Fi 6 项目验收，客户网管跟我提了个词：AX 调度。他说网上讲得都太零散，想知道这个调度到底调度了什么、开了之后有没有用、为什么自己的 AP 开了某些开关后终端反而掉线。这其实正好戳到 802.11ax（Wi-Fi 6）的核心价值——多用户高效调度机制。这篇文章就从协议原理、抓包实测到 AP 参数调整，把 AX 调度这件事讲透。无论你是企业无线工程师、学校/园区网管，还是家里换了 AX 路由器想搞明白固件里那些“MU-MIMO/OFDMA/TWT”开关的人，这篇都值得往下看。
1. 802.11ax 之前的 Wi-Fi 是“抢车位”，AX 调度把它变成了信号灯
1.1 随机竞争的效率天花板在哪
在 802.11ac 及更早的时代，一个 AP 下的所有终端共享同一个无线信道，谁想发数据，谁就得先听信道，信道空闲就进入随机退避，退避结束再发送。官方的说法叫 CSMA/CA，我给客户解释时更喜欢叫它“抢车位”。车少的时候没问题，车一多，大家都在起步、刹车、让行，真正用于数据的空口时间被大量浪费。
教室、报告厅、大型办公室这类高密度场景里，几十台终端同时在线，每一台终端都要竞争信道、等 ACK、做退避重传，实际吞吐量和时延非常难看。更麻烦的是，很多轻流量终端（比如手机消息推送、传感器心跳）虽然数据量很小，但每次都要参与抢信道，白白消耗掉大量空口资源。
我做过一次对比：同一个 60 人的办公区，用 802.11ac 双频 AP，单台 AP 上挂 45 个终端，晚高峰时整体下行吞吐只能跑到 200Mbps 左右，而每台终端的平均时延会从平时 5ms 跳升到 80ms 以上。问题不在空口速率不够，而在没有调度的随机竞争机制让整体效率崩掉了。
1.2 AX 调度拆开看：频域、空域、时域三层调度
802.11ax 引入的调度思想，本质上是把“中央集中式资源分配”拿到了 Wi-Fi 里。AP 不再只是被动接收数据，而是像信号灯一样，提前知道哪个终端有多少数据、什么时候该走、该在哪个频率通道上走。
AX 调度不是单一机制，它至少包含三层：
- 频域调度：OFDMA，把信道切分成多个资源单元（RU），同时分给不同终端；
- 空域调度：MU-MIMO，让支持多天线的终端在同一资源单元上通过空间流并行传输；
- 时域调度：TWT，协商终端的唤醒和休眠时间，按约定的时间窗口发送/接收数据，避免无谓竞争。
这三层可以叠加使用。AP 的调度器会综合每个终端的缓存状态、信号质量、队列优先级，来决定下一时刻谁用哪个 RU、用几根空间流、在什么时间窗口里传输。这是 802.11ax 和过去所有 Wi-Fi 协议最大的区别。
用信号灯来类比：CSMA/CA 是每个路口车辆自己看情况挤着过，AX 调度则是在路口装上了信号灯和车道分配员，什么时候放行、哪条车道给谁，都由 AP 统一决定。
1.3 别把应用层 QoS 和 AX 调度混为一谈
很多人会把 Qos、WMM 和 AX 调度搞混。其实是两件事：WMM/QoS 是在 MAC 层之上做业务优先级映射，例如语音队列、视频队列、尽力而为队列，它决定“谁优先”；而 OFDMA/MU-MIMO/TWT 是物理层和 MAC 层的资源调度，它决定“给谁分配哪些可用资源、何时下发”。
AP 实际工作时，调度器会先看队列优先级，再从队列里拿出数据帧映射到 RU 上。所以正确理解是：QoS 做优先级排队，AX 调度做并发传输。两者配合才能真正实现高密度下的低时延，只开 Qos 不开 OFDMA，高并发时依然会拥堵。
2. OFDMA 调度到底是怎么把 20MHz 切成 9 个车位并指挥上车的
2.1 资源单元 RU 不是随便切的
OFDMA 的核心是把信道在频率上分割成更小的单元，每个单元叫 RU（Resource Unit）。以 20MHz 信道为例，802.11ax 最多能把它切成 9 个 26-tone RU，一个 tone 大约等于 78.125kHz 的子载波间隔，26-tone RU 约占 2MHz 带宽，够传一路低码率语音或几路传感器数据。
更宽的信道对应更多的 RU 数量：
- 20MHz：9 个 26-tone RU；
- 40MHz：18 个 26-tone RU；
- 80MHz：37 个 26-tone RU；
- 160MHz：74 个 26-tone RU。
RU 还可以拼成大块。协议支持 52-tone、106-tone、242-tone、484-tone、996-tone 等规格。小 RU 适合低速率、小数据包业务，大 RU 适合高速率业务。调度器分配时，不会把 9 个 RU 全部分给同一台手机，而是根据每台终端的业务量、缓存队列长度、调制编码等级来动态决定。
我做好几个高密度项目时得到一个很直观的体会：如果 45 台终端同时挂在同一 20MHz 信道上，开启 OFDMA 后可以同时服务 9 台终端，虽然每台终端分到的频率变窄了，但总吞吐和时延稳定性远好于让 45 台终端挨个抢信道。
2.2 下行 OFDMA：AP 按队列和数据量发车
下行方向，AP 是自己决定什么时候发的，实现集中调度容易一些。AP 调度器会轮询所有关联终端的发送队列，选出若干终端，把数据帧填充到不同的 RU 上，然后组装成一个 HE MU PPDU（多用户物理帧）一次性发出去。
这个多用户帧里，每个终端都有自己的 RU 区域和对应数据，物理层前导码（HE-SIG-B）会携带 RU 分配信息，终端收到后只解码属于自己的 RU。对于终端来说，它不需要知道别人的 RU 在哪，只需要认领自己被分配的部分。
下行 OFDMA 的收益有多明显？我们在会议室测试过：8 台终端同时在线看视频，802.11ac 下 AP 得一帧一帧地轮发，每台终端拿到信道的间隔很长；打开下行 OFDMA 后，AP 可以把 8 台终端的数据一次性放进一个 PPDU 里发出去，帧间隔从几十毫秒降到几毫秒。
2.3 上行 OFDMA：Trigger 帧和缓存状态才是关键
上行方向比下行复杂得多，因为 AP 不知道终端什么时候有数据要发。802.11ax 的做法是“AP 主动查询，终端按指示发送”。
AP 会先发送一个 Buffer Status Report Poll（BSRP）触发帧，询问关联终端各自的缓存队列长度。收到回应的终端会在 QoS Null 帧里捎带缓存状态信息，告诉 AP“我要发多少数据”。AP 据此分配上行 RU，再发一个 Basic Trigger 触发帧，里面列出了哪些终端在哪些 RU 上发送。
真正参与上行传输的终端收到 Basic Trigger 后，就在指定 RU 上同时发数据。由于多个终端是同时发的，它们之间不会竞争，也就不会互相碰撞。等数据发完，AP 会回一个多用户 Block ACK（Multi-STA BA）确认。
这个机制对低时延业务非常重要。传统 Wi-Fi 上行需要终端随机竞争，时延不确定；802.11ax 上行 OFDMA 把这种不确定变成了“AP 统一排班”，每次排班都能让多台终端同时上车。
2.4 一次典型上行调度的时间线
用一次最简单、最典型的上行 OFDMA 调度为例，流程大致是：
- AP 发送 BSRP Trigger，所有关联终端收到后评估自身缓存；
- 有数据的终端在 QoS Null 帧中携带 BSR 信息回复；
- AP 的调度器根据 BSR、信号质量、优先级，分配 RU 并发送 Basic Trigger；
- 多台终端在各自 RU 上同时上传数据，组成 HE MU PPDU；
- AP 回复 Multi-STA BA，一个 TXOP 结束。
某些情况下 AP 还会在触发前发 MU-RTS，作用是把周围隐藏节点和保护间隔纳管进 NAV，防止其他设备在这段时间内乱发送。所有步骤都在微秒级完成，效率远高于过去“一次只服务一台终端”的随机竞争。
注意：上行 OFDMA 需要终端同样支持 802.11ax。802.11ac 及更老的终端无法参与，它们仍然退回到传统随机竞争模式。这也是为什么老终端很多的环境里，AX 调度收益会被拉低。
3. 空域调度与时间调度：MU-MIMO 和 TWT 并不比 OFDMA 简单
3.1 MU-MIMO 是空间上的并行
OFDMA 解决的是“频率上并行”，MU-MIMO 解决的是“空间上并行”。802.11ax 支持 8×8 MU-MIMO，也就是 8 根天线可以同时给多个终端传输不同的空间流。
单独使用 MU-MIMO 时，AP 依靠终端反馈的信道状态信息（CSI）来调整每个终端的空间流权重。终端信号质量、朝向、距离都会影响 MU-MIMO 的效果。因此调度器并不是把 8 个波束随便分配给任意 8 台终端，而是会挑选空间隔离度较好的终端组合，减少互相干扰。
在 802.11ax 里，OFDMA 和 MU-MIMO 可以叠加使用：同一个多用户 PPDU 内，某个 RU 分配给终端 A 单人使用，另一个 RU 上则可以用 MU-MIMO 再服务 2 个终端。这等于在“频率并行”之上又叠加了一层“空间并行”，对芯片的计算能力和调度算法要求非常高。
实际项目中，我发现下行 MU-MIMO 对 5GHz 频段、终端天线数较多的环境效果好，但在 2.4GHz 频段、多穿墙场景下经常因为信道反馈不准而失效。很多 AP 固件默认开 MU-MIMO，但不代表它对所有场景都有正收益。
3.2 TWT 是时间上的预约
TWT（Target Wake Time，目标唤醒时间）是我认为 802.11ax 里被忽略很多的一个调度机制。它的用途是：AP 和终端协商一个精确的唤醒时间，终端在规定时间之前休眠，到点醒来收发数据，之后继续睡。
传统空口省电模式是“终端随时可能醒来竞争信道、收听 beacon”，虽然耗电不高，但在高密度下会产生大量无效唤醒和信道争用。TWT 把它变成“按预约表唤醒”，设备和设备之间错峰，既省电又减少空口冲突。
广播 TWT（Broadcast TWT）在 IoT 场景特别有价值：几十个温湿度传感器、门锁、定位标签，约定同一个唤醒窗口，AP 一次性下发数据，它们再回去睡觉。大量低功耗、低速率设备共存而不影响正常办公终端，靠的就是这套时间调度。
不过 TWT 的兼容性是项目里最让我头疼的问题之一。早期一些支持 802.11ax 的终端对 TWT 支持不完善，开了之后会出现终端长时间睡死、连接假掉线、收不到数据的现象。这部分我在后面翻车案例里细讲。
3.3 AP 队列级调度与 OFDMA 的配合
有了 OFDMA、MU-MIMO、TWT 三层物理链路调度之后，别忘了 AP 上还有熟悉的 WMM 队列。调度器做决策时，会先按照语音、视频、尽力而为、后台四个队列优先级去取帧，再把这些帧映射到本次 PPDU 的 RU 中。
高密度场景下，语音和视频会议对时延最敏感。好的 AP 固件会在每个调度周期内优先为 AC_VO（语音）和 AC_VI（视频）保留部分 RU，而不是等这些低时延业务随时插队，避免它们和大量批量下载业务抢资源。
这也回答了很多人的疑问：为什么同是 Wi-Fi 6 AP，不同厂商实际体验差异很大。OFDMA 看的是 AP 调度算法的优先级策略，不只是协议本身有没有这个能力。同样一颗芯片，固件怎么调度，决定了高并发下谁被打爆、谁依然流畅。
4. 抓包看调度，以及我遇到过的三次“翻车”
4.1 怎么在抓包里确认调度正在发生
调优之前，先要有能力判断调度到底有没有生效。最简单的方法是用 Wireshark 抓空口报文，过滤 Trigger 帧和 HE MU PPDU。
在 Wireshark 里，802.11 管理帧和触发帧可以通过控制帧子类型识别。Trigger 帧的控制帧子类型是 13（0x0D）。抓包后可以这样过滤：
tshark -r ax.pcapng -Y "wlan.fc.type_subtype == 0x0d" -T fields \ -e frame.time_relative -e wlan.ta -e wlan.trigger.he_trigger_type如果看到大量 Trigger 帧，并且帧里带有“Basic”“BSRP”等类型，说明 AP 正在做上行 OFDMA 调度。HE MU PPDU 可以在 Wireshark 里观察 PHY 层字段，过滤时使用wlan.he系列字段，例如wlan.he.ru_allocation，能看到 RU 分配情况。
只看一轮 Trigger 还不够，我一般会统计一段时间内 Trigger 帧的数量、Trigger 帧里包含的 STA 数量，以及对应上行 MU PPDU 的成功率。如果 Trigger 发了很多，但上行数据帧重传率高，说明调度没有真正跑到最优，需要进一步排查。
4.2 实测：开 OFDMA 前后在同一会议室的差异
有次做某公司会议室无线改造，一间 80 平米会议室坐了 24 个人，每个人都在用笔记本电脑参加视频会议，外接了一些无线投屏盒子。改造前用的是 802.11ac AP，高峰时视频卡顿频繁，无线投屏基本不可用。
改造后同一位置部署 Wi-Fi 6 AP，只开下行 OFDMA、不开上行 OFDMA 时，视频会议已经明显流畅；再把上行 OFDMA 打开后，我记录了一组对比数据：
| 指标 | 802.11ac | Wi-Fi 6 关上行 OFDMA | Wi-Fi 6 开上行 OFDMA |
|---|---|---|---|
| 视频会议平均时延 | 约 60ms | 约 12ms | 约 7ms |
| 上行丢包率 | 约 2.5% | 约 0.6% | 约 0.1% |
| 30 秒内上行总吞吐 | 约 45Mbps | 约 82Mbps | 约 118Mbps |
| 无线投屏卡顿次数 | 频繁 | 偶尔 | 基本没有 |
这里“上行总吞吐”的提升，很大一部分来自上行 OFDMA 让 24 台电脑不再排队抢信道，而是分批并发上传。这组数据也让我确定了后续项目里只要终端支持率允许，就默认开上行 OFDMA。
4.3 翻车案例一：老终端 + UL OFDMA 的隐性重传
后来另一个项目却翻了车。客户办公区有 70 多个终端，但其中约 30 台是老式笔记本，网卡还是 802.11ac。部署完 Wi-Fi 6 AP、开启全部 OFDMA 后，老终端的用户反馈网页加载变慢，视频会议偶尔花屏。
抓包发现 AP 一直正常发 Trigger 帧，但有一些帧没等到 802.11ax 终端的上行响应。问题不在协议层面，而在固件策略：AP 默认把上行 OFDMA 的 Trigger 帧调度周期压得太密，每当有 802.11ax 终端按 Trigger 发送时，旁边的 802.11ac 终端也在同时做传统信道竞争，两者互相拖累。
排查链路是：先看关联终端类型分布，再按终端 MAC 过滤重传率，发现非 AX 终端重传显著高于 AX 终端。最后把某些支持率低的 SSID 单独关闭 UL OFDMA，或者对老终端绑定更宽松的调度间隔，问题解决。
这给我的教训是：AX 调度虽然高效，但不能脱离终端生态单独谈。终端支持率低于 70% 时，盲目开启所有调度特性反而可能伤害整体体验。
4.4 翻车案例二：TWT 开启后批量掉线的排查链路
另一个更头疼的问题是 TWT。某智慧办公项目里，客户在会议室部署了一批 Wi-Fi 6 终端，同时还有几十个智能传感器和电子桌牌。AP 默认开了广播 TWT，想让 IoT 设备省电。
结果上线当天，传感器每 30 分钟掉线一批，需要重新关联。抓包看到的表象是：传感器在约定唤醒时间没有回复 AP 的下行数据，AP 等不到数据就标记掉线。
层层排查后，问题出在传感器固件的 TWT 实现不完整。这些设备虽然标着 Wi-Fi 6，但它们对广播 TWT 的“成员 ID”分配处理有缺陷，多个设备被分到同一唤醒时间后互相踩踏，导致一部分设备醒来后没有及时进入传输窗口。
修复方案不是把 TWT 整体关掉，而是把 IoT 设备放到独立 SSID，关闭该 SSID 的广播 TWT，保留普通办公终端的 TWT 功能。这样一来，不同设备的调度需求完全隔离，传感器也稳定运行了。
给同行的建议：TWT 不是越强越好。先确认终端是否齐全支持，再决定开全局还是分区开，否则省电目标没达成，可靠性反而先崩了。
4.5 翻车案例三：多 SSID 环境 OFDMA 的资源“假死”
第三个案例严格说是厂商固件 bug。客户在一个 AP 上配了 4 个 SSID（办公、访客、IoT、打印）。某天下午，访客网络所有终端速度骤降，刷新页面明显卡顿，但办公网络正常。
抓包看到 AP 的 Trigger 帧大量出现在办公 SSID 所在频段，访客SSID 的关联终端却几乎得不到 RU 分配。联系厂商后确认为调度器在多个 SSID 间做资源切分时出现优先级反转，部分固件版本在特定流量模型下会把批量下载业务的队列权重误判为最高优先级。
最终通过升级固件解决。这个案例本身没有太多可操作性，但提醒我一点：在部署多 SSID 时，一定要核对 AP 固件版本和 Release Notes，不能默认“大版本一致就没问题”。AX 调度算法非常复杂，厂商固件迭代对行为影响极大。
5. 企业 AP 上 AX 调度参数的调优清单
5.1 哪些开关值得动
不同厂商的叫法略有差异，但常见可调项基本一致。我把最值得关注的参数整理成了一张表，方便验收和排障时对照：
| 参数项 | 默认状态 | 适用场景 | 建议 |
|---|---|---|---|
| DL OFDMA | 通常开 | 高密度办公、视频会议 | 终端支持率高时保持开启 |
| UL OFDMA | 通常开 | 上行并发高的场景 | 老终端多时可考虑关闭或调松调度周期 |
| DL MU-MIMO | 通常开 | 5GHz 覆盖好、终端天线数多 | 2.4GHz 或穿墙环境建议关闭 |
| UL MU-MIMO | 通常关 | 上行大流量集中场景 | 需要终端支持且信道反馈准确 |
| TWT | 通常开 | IoT、电池设备多 | 按 SSID 差异化配置，不全局一刀切 |
| 广播 TWT | 通常关 | 大量低功耗传感器 | 确认设备兼容后再开 |
| Airtime Fairness | 通常开 | 防止低速设备拉低整体效率 | 高带宽需求环境保持开启 |
这些参数不是固定值。比如高密度场馆和普通办公区的需求完全不同，开法也不一样。
5.2 不同场景的推荐配置
我按自己做过的高密度办公、会议室、IoT 混合三类场景给出常见配置思路，你可以把它当起点，再结合现场抓包微调。
高密度办公区：终端以手机和笔记本为主，业务是视频会议、Web、Office 混合。建议开 DL/UL OFDMA，开 DL MU-MIMO，关闭广播 TWT，保留单播 TWT。信道宽度在 5GHz 下优先用 80MHz，这样 RU 数量够多，调度并发能力最强。
会议室重点保障低时延：开 DL/UL OFDMA，关掉不必要的省电协议，确保视频会议流被映射到高优先级队列。如果无线投屏设备较老，最好把投屏 SSID 和会议终端 SSID 分开，投屏 SSID 单独调整调度策略。
IoT 混合场景：给 IoT 设备单独划 SSID，开启广播 TWT 前逐个验证设备固件；办公终端所在的 SSID 则保留完整调度能力。注意把广播 TWT 的唤醒周期拉长，避免高频唤醒带来无意义开销。
5.3 验收一个调度效果是否正常的方法
验收时别只盯着连接速率。我常用的三个判断指标是：信道利用率、重传率、客户端空口占用分布。
用 AP 自带统计或抓包工具都可以看这些数据。调度生效的正常状态是：高业务量终端的空口占用合理，低速终端虽然连接速率低，但不至于把大量空口时间消耗在重传上；信道利用率高峰和业务高峰匹配，而不是无业务时依然飙高。
如果开启 OFDMA 后重传率不降反升，先查 Trigger 帧的响应率；如果响应率低，再看参与终端的协议版本。很多问题到最后都指向“调度参数和终端生态不匹配”，而不是 AX 调度本身无效。
从 802.11ac 换到 802.11ax，本质上是从“竞争”走向“调度”，这是一个架构级的改变。我个人的实际体会是，AX 调度做得好不好，决定了 Wi-Fi 6 在网络里是“新一代 WiFi”还是“换了个名字的 WiFi”。如果你最近也正在调 AX 调度，建议先从抓包确认 Trigger 帧开始，再逐项开关验证，别一口气全部拉满。把调度打开并调到适合现场的那一刻，你才会真正理解 802.11ax 这几年代码改动值在哪。
