1. 项目背景：ax调度这个词是怎么火起来的
最近后台和群里好几个人都在问“ax调度”，有人以为是谁家新发布的分布式任务调度框架，还有人以为是某云厂商包装出来的新名词。其实把“ax”拆开就清楚了：它代指 IEEE 802.11ax，也就是我们常说的 Wi-Fi 6。而“ax调度”说的是 Wi-Fi 6 无线协议里那一整套中心化资源调度机制，包括 OFDMA、MU-MIMO、TWT 这些让 AP 像“调度中心”一样统一分配信道资源的动作。
为什么这个词会火？因为 Wi-Fi 6 和前几代标准最大的差异不是单纯把速率翻倍，而是从“靠运气抢信道”变成了“按计划分配信道”。在办公区、教室、宿舍、机场这类高密度接入场景里，真正决定体验的不是带宽，而是调度效率。所以“ax调度”本质上就是 Wi-Fi 6 的 MAC 层调度器在工作时的一系列行为，这篇文章就把这套机制从设计思路到抓包验证完整过一遍，适合无线网络工程师、企业网管、以及对 Wi-Fi 技术感兴趣的折腾型玩家。
1.1 先说清楚 ax=802.11ax=Wi-Fi 6
命名这件事很容易把人绕晕。IEEE 的无线局域网标准从 802.11b/g/n/ac 一路演进，到了下一代，标准名就是 802.11ax。Wi-Fi 联盟为了让大家好记，从 802.11n 开始给了个通俗编号，802.11n 是 Wi-Fi 4，802.11ac 是 Wi-Fi 5，802.11ax 就是 Wi-Fi 6。所以你在看设备参数时如果出现“AX3000”“AX5400”，或者驱动里出现“HE 模式”，指的都是同一套东西。
“HE”是 High Efficiency 的缩写，这也是 802.11ax 设计目标的缩影。从协议层面看，802.11ax 改动非常系统，它引入了更细的子载波划分、上行和下行 OFDMA、上下行 MU-MIMO、TWT，以及 BSS Coloring。这一大堆新特性背后都围绕一个中心思想：让 AP 能够统一调度多个终端的收发，而不是像过去那样完全依赖随机竞争。也因此，很多资深的无线工程师会直接用“ax调度”来形容这一代协议的核心变化。
1.2 ax调度到底在调度什么
调度这个概念，在无线局域网里和在操作系统里有点像，都是资源分配问题。在 802.11ax 之前的时代，无线介质是典型的随机接入：每个终端发送数据前先监听信道，信道空闲就发送，如果多个终端同时发送产生了碰撞，就各自退避随机时间再重试。这种机制叫 CSMA/CA，简单可靠，但在终端数量多、小报文密集的时候效率极低。
ax调度改变的是这个“各自为战”的模型。AP 在传输周期内充当指挥者，明确告诉每个终端：你在哪个频率块上传、在哪个空间流上收、在哪个时间点唤醒。具体到协议实现，调度发生在三个维度上：
- 频率维度：通过 OFDMA 把信道切分成多个 RU（Resource Unit，资源单元），不同终端可以同时用不同频率段发送数据。
- 空间维度：通过 MU-MIMO 让不同终端使用不同的空间流，相当于在天线层面上并行传输。
- 时间维度：通过 TWT 协商出每个终端的唤醒时间，让设备不发送数据时进入休眠，降低空闲监听带来的竞争和功耗。
这三个维度共同组成了“ax调度”的主体。理解了这一点，再看 Wi-Fi 6 的测速测试和高密度场景表现，思路会清晰很多。
2. 整体设计思路：为什么 Wi-Fi 6 要引入“调度制”
2.1 从“人人大喊”到“交警指挥”的演进
早期 Wi-Fi 的分布式接入模型，可以类比成一群人在一个房间里开自由讨论会。每个人都能说话，但都要先判断别人有没有在说。如果有两个人同时开口，发现冲突后就得停下来，随机等一会儿再试。人少的时候，这种“自由发言”体验还不错；人一旦多起来，空气里全是“抱歉你先说”的相互等待，实际有效交流时间被大量浪费。
在无线协议里，这个过程更精确：终端需要先等待 DIFS（分布式帧间间隔），然后进入退避计数器倒计时。倒计时归零之前发现信道又忙了，就得冻结并重新等待。终端越多，碰撞概率越高，每次碰撞都会导致退避窗口指数增大。结果就是看起来每个设备都连上了 Wi-Fi，但很多时候大家的流量都在空口竞争中被消耗掉了，尤其是大量状态更新、心跳包、IoT 小报文这类场景，效率下降特别明显。
802.11ax 的做法相当于在房间里安排一个“交警”或者“会议主持人”。主持人按顺序点名：张三在 1 号位置说，李四在 2 号位置说，王五等下一轮。每个人在指定时间、指定位置发言，互不干扰。这个“主持人”就是 AP 里的调度器，而“点名规则”就是各种各样的调度算法。这样做牺牲了一点设计的“公平随机性”，但换取的是高密度环境下的确定性、低冲突和高吞吐。
2.2 OFDMA、MU-MIMO、TWT 三种调度机制的定位
ax调度并不是单一技术，而是三个关键特性的组合。它们负责的资源维度不同，适用场景也有明确分工。我用一张表格把它们的定位先列出来：
| 调度维度 | 核心技术 | 作用方式 | 典型受益场景 |
|---|---|---|---|
| 频率 | OFDMA | 把信道切成多个 RU，多终端并行收发 | 小报文密集、物联网心跳、网页浏览 |
| 空间 | MU-MIMO | 利用多天线空间流并发传输 | 大流量下载、视频会议、文件同步 |
| 时间 | TWT | 协商唤醒窗口，避免空口竞争和功耗浪费 | 电池供电终端、无线扫码枪、传感器 |
这三者不是彼此替代，而是协同工作。一个典型的 Wi-Fi 6 传输周期里，AP 先通过 Trigger Frame（触发帧）发送出一份“调度表”，里面写清楚这次传输有哪些终端参与、每个终端用哪个 RU、用几条空间流。随后多个终端在收到触发后同时发出上行数据，AP 再统一回复 Block ACK。整个过程既包含了频率上的 OFDMA 细分，也包含了空间上的 MU-MIMO 叠加，而 TWT 则决定了终端什么时候需要醒来，参与到这一轮调度中。
三种技术中，OFDMA 是“ax调度”最核心的标志。它最关键的变化是把信道从“一条独享大马路”改成了“多条并行小路”，哪怕每个用户只有一小段频率，也能同时发送，大大降低了小报文场景下的空口开销。这也是为什么很多企业 AP 的配置界面里，会把“DL/UL OFDMA”单独列出来作为调度总开关。
3. 核心细节解析与实操要点
3.1 OFDMA 的 RU 分配与配置细节
OFDMA 的实现基础是子载波分组。802.11ax 中，一个标准 20MHz 信道采用 256 点 FFT，可用子载波约为 242 个，这些子载波会进一步组合成不同大小的资源单元 RU。常见的 RU 大小有 26-tone、52-tone、106-tone、242-tone 以及用于更宽信道的 484-tone、996-tone，不同 RU 对应的物理带宽和子载波数量如下：
| RU 类型 | 子载波数 | 20MHz 下最多可分配数量 | 典型用途 |
|---|---|---|---|
| 26-tone | 26 | 9 个 | 小报文，如 IoT 数据、即时消息 |
| 52-tone | 52 | 4 个 | 中低速率业务，如语音通话 |
| 106-tone | 106 | 2 个 | 较高带宽需求，如视频会议 |
| 242-tone | 242 | 1 个 | 全信道占用，适合大流量传输 |
调度器分配 RU 时不是简单均分，而是综合业务量和信道质量来决定。比如同时有 9 个传感器上报数据，每个报文只有几十字节，调度器可以把 20MHz 分成 9 个 26-tone RU，让 9 个传感器同时发送。这样虽然每个 RU 速率不高，但从系统角度看，9 个终端的发送延迟都被压缩在一个传输周期内，比逐个轮询快得多。
反过来，如果一个终端正在下载大文件，调度器会把整个信道作为单个 242-tone RU 分配给这个终端，保证大流量业务不被切成碎片。同时调度器还会参考每个终端的 MCS（调制编码指数）。SNR 差的终端就算给它再宽的信道也跑不起来，反而浪费资源；SNR 好的终端则会被优先分配到较大 RU 和较高 MCS。
在实际配置时，多数企业级 AP 默认会开启 OFDMA，但在低密度家庭环境里，OFDMA 带来的收益可能并不明显。因为 Trigger Frame、资源分配字段这类控制信息本身也要占用空口时间，如果同一时刻只有一两个活跃终端，集中调度带来的开销反而可能让测速结果变得难看。所以很多 AP 的默认策略是“低负载时自动退回到传统传输模式，高负载时才启用 OFDMA”，这个逻辑通常是合理的，不建议盲目关闭。
3.2 MU-MIMO 的探测与空间复用细节
MU-MIMO 是 Wi-Fi 5 时代就引入的概念，但 802.11ax 在上下行两个方向都完善了它。下行 MU-MIMO 由 AP 同时向多个终端发送不同空间流的数据，上行 MU-MIMO 则允许多个终端在 AP 的触发下同时上传数据。
这里有个关键前置过程：波束成形探测。AP 不知道终端在哪个位置、天线形态如何，需要先发送 NDP（空数据包）和 NDP Announcement，终端收到后根据信道状态返回 Compressed Beamforming Feedback，AP 再根据反馈信息计算天线权重矩阵，决定怎么把空间流“指向”不同终端。如果这个探测过程不成功，MU-MIMO 的增益就会大打折扣。
我实际调过很多不达标的场景，最常见的问题是终端天线和 AP 天线数量不对等。比如 AP 是 4x4 天线，但终端是 1x1 天线，那这个终端最多只能占用一条空间流，MU-MIMO 分组时它几乎帮不上忙。要验证终端能力，可以在 Intel AX200 这类网卡上使用iw dev wlan0 link查看 MCS、带宽和 NSS（空间流数量）。如果发现连接速率只有 400Mbps 左右，通常就是 1 条空间流、80MHz、MCS9-11 的组合。
另外，MU-MIMO 还要求终端之间的信号隔离度足够好。如果两个终端物理位置很近，AP 把它们放在同一组 MU 传输里，接收端会互相干扰。因此调度器通常要结合信道相关性判断是否适合组成 MU 组，这也是为什么在“满屋都是手机”的会议室里，MU-MIMO 不一定总能跑出漂亮数据。
关于空间复用，还要提一下 BSS Coloring。BSS Coloring 不算严格意义上的调度，但它是 802.11ax 提升空间利用率的重要设计。AP 会给自己的 BSS 打个“颜色”标签，终端发现邻居 BSS 的颜色和自己不同时，可以选择忽略部分干扰继续发送，而不是像以前那样只要信道忙就退避。这在多楼层、多办公室的密集组网里非常有用，也是 ax 调度的“背景增强器”。
3.3 TWT 的建立流程和功耗优化要点
TWT（Target Wake Time）是 ax调度里最容易被忽略但又很有意思的一项。它的目标是通过协商，让终端只在约定的时间醒来，其他时间进入深度休眠。正因为这个机制，Wi-Fi 6 设备能做到比前代更低的待机功耗。
TWT 的协商过程并不复杂。终端在关联阶段或者关联后通过 TWT 建立请求帧，向 AP 提出期望的唤醒周期；AP 根据当前负载和接入设备数量，返回一个协商好的目标唤醒时间、唤醒间隔和最短唤醒时长。如果是 Broadcast TWT，AP 还可以为一组终端设置同一个唤醒窗口，避免设备在醒来时集体争抢信道。
实际项目中，我看到过不少无线扫描枪和手持终端通过 TWT 获得明显续航提升。比如扫码枪每隔 5 分钟上传一次盘点数据，如果让它在两次上传之间完全休眠，省电效果非常可观。但 TWT 也有代价：如果期间有下行数据要发送，AP 得等终端醒来才能送达，交互式应用会感知到额外延迟。
所以实时性强、需要时刻保持收发包能力的业务，不建议开启严格的 TWT，或者至少把唤醒间隔调得很短。如果 AP 配置界面里有“TWT 业务类型”选项，通常会让语音、视频、游戏等延迟敏感流量绕过 TWT 调度。另外，很多老终端并不支持 TWT，AP 只能忽略它们的请求，这时候混合模式下的调度效率会受影响，但不会导致掉线。
4. 实操过程：从抓包看一次完整的 ax 调度
4.1 搭建一个能观察调度的实验环境
要真正理解 ax调度，纸上谈兵不够，最直接的办法是抓包看一次实际调度的完整流程。我建议用一套组合设备来搭实验环境：
- 一台支持 Wi-Fi 6 的 AP，比如华硕 RT-AX86U、TP-Link XDR5480 或者任意企业级 AP。
- 两台以上支持 802.11ax 的终端，比如带 Intel AX200 的笔记本电脑、iPhone 12 及以上、Android 12 以上机型。
- 一台用于抓包的电脑，最好也用 Intel AX200 网卡，确认驱动支持 monitor 模式。
- Wireshark 4.x 版本，用于解析 HE 帧。
先关闭 2.4GHz 频段或者单独用 5GHz 频段测试，避免干扰和兼容性问题。AP 端把 OFDMA、MU-MIMO、TWT 全部开启，SSID 使用 WPA2/WPA3 加密。把终端放到 AP 附近，保证 RSSI 在 -55dBm 以上，SNR 最好大于 30dB。
抓包机把无线网卡切入 monitor 模式后，用 Wireshark 抓取 5GHz 频段。我习惯过滤 AP 的 MAC 地址，减少无关帧数量。然后从两个终端同时发起流量，比如一边跑 iPerf3 大流，一边循环访问网页模拟小报文，持续抓 10 到 15 分钟。
4.2 抓包分析：Trigger Frame 与 RU 分配记录
抓包文件里最需要关注的是 AP 发出的 Trigger Frame。在 Wireshark 里可以用显示过滤器wlan.fc.type_subtype == 0x1d快速定位，也可以直接在协议树里看到名为 Trigger 的帧。Trigger Frame 是 ax 调度的“发令枪”，AP 通过它告诉终端本次传输的详细安排。
打开一个 Trigger Frame，重点关注几个字段：
- Trigger Type：常见的有 Basic Trigger（基础触发，用于 UL OFDMA）、MU-BAR Trigger（用于请求 Block ACK）、Beamforming Report Trigger（用于触发波束成形反馈）。
- UL BW：上行带宽，例如 0 表示 20MHz，1 表示 40MHz，2 表示 80MHz，3 表示 160MHz。
- User Info 列表：里面是每个参与终端的 AID（关联 ID）、RU Allocation、编码方式、MCS 等。RU Allocation 会明确告诉你某个终端这次被分到了哪个起始频率、多大的 RU。
如果你看到一次 Basic Trigger 里同时包含多个 User Info，并且随后紧跟多个客户端发来的 HE TB PPDU，就说明 UL OFDMA 调度正在正常工作。这些 HE TB PPDU 在 Wireshark 里会显示成 Data 帧，帧头可能带有相同的触发序列号，你可以按时间顺序把它们和前面的 Trigger Frame 对应起来。
下行 OFDMA 调度则没有 Trigger Frame 这么明显，它主要通过 HE MU PPDU 来承载。Wireshark 解出 HE MU PPDU 后，同样可以在协议树里看到多个 User Info 信息，每个用户对应不同的 RU 和空间流配置。不过需要注意的是，常规网卡的 monitor 模式不一定能完整解密 HE 帧，如果抓包结果全是加密的，可以临时把 SSID 改成开放网络在隔离测试环境中抓，或者使用 AP 端的调试抓包功能。
4.3 典型问题排查与避坑记录
我在实际测试中踩过不少坑，这些问题在配置 ax调度时很容易遇到，整理成一份避坑清单供参考：
- 问题一：开启 OFDMA 后，老摄像头或者 11n 终端出现掉线或延迟变大。原因是这些设备无法理解 RU 分配，需要靠混合模式保护机制转发。解决办法是把 2.4GHz 频段的 OFDMA 关闭，只保留 5GHz 频段的开启状态，或者把老旧 IoT 设备隔离到独立 SSID。
- 问题二：开启 MU-MIMO 后，单终端测速并没有明显提升。原因很简单，MU-MIMO 本来就是并发技术，单用户场景没有第二个流可以和它并行，自然看不到效果。要做对比测试，至少让两个终端同时跑大流量，观察总吞吐是否提升。
- 问题三：终端明明支持 Wi-Fi 6，连接速率却很低。先用
iw dev查看链路信息，确认协商到的带宽是 80MHz 还是 40MHz，空间流数量是关键。很多手机在省电模式下会主动降到 1x1 或者较窄带宽，这时候 ax调度的效果会被明显削弱。 - 问题四：抓包时完全找不到 Trigger Frame。先确认 AP 管理界面的“UL OFDMA”是否打开，再确认终端是否在关联请求里携带了 HE Capability。另一个容易忽略的因素是网卡驱动不支持在 monitor 模式下处理 HE 帧，这种情况下可以尝试换一张着名的 AX200 网卡并更新驱动。
- 问题五：TWT 开启后，设备出现“找不到”或者响应延迟变高。典型的做法是检查 TWT 唤醒间隔是否太激进，尤其对需要频繁交互的扫码枪、会议室投屏终端，建议单独关闭 TWT 或缩短唤醒周期。
这些坑都不是配置页面能直接看出来的，得靠现场观察和抓包对证。特别是“调度有收益”的场景判断，千万不要只看单终端测速。测速只能验证链路速率，要验证 ax调度，就像这次抓包实验一样，关注并发传输周期、Trigger Frame 数量和 RU 分配变化，才是真正理解它的方式。
