前阵子做 Wi-Fi 6 项目验收客户网管跟我提了个词AX 调度。他说网上讲得都太零散想知道这个调度到底调度了什么、开了之后有没有用、为什么自己的 AP 开了某些开关后终端反而掉线。这其实正好戳到 802.11axWi-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 的核心是把信道在频率上分割成更小的单元每个单元叫 RUResource Unit。以 20MHz 信道为例802.11ax 最多能把它切成 9 个 26-tone RU一个 tone 大约等于 78.125kHz 的子载波间隔26-tone RU 约占 2MHz 带宽够传一路低码率语音或几路传感器数据。更宽的信道对应更多的 RU 数量20MHz9 个 26-tone RU40MHz18 个 26-tone RU80MHz37 个 26-tone RU160MHz74 个 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 下行 OFDMAAP 按队列和数据量发车下行方向AP 是自己决定什么时候发的实现集中调度容易一些。AP 调度器会轮询所有关联终端的发送队列选出若干终端把数据帧填充到不同的 RU 上然后组装成一个 HE MU PPDU多用户物理帧一次性发出去。这个多用户帧里每个终端都有自己的 RU 区域和对应数据物理层前导码HE-SIG-B会携带 RU 分配信息终端收到后只解码属于自己的 RU。对于终端来说它不需要知道别人的 RU 在哪只需要认领自己被分配的部分。下行 OFDMA 的收益有多明显我们在会议室测试过8 台终端同时在线看视频802.11ac 下 AP 得一帧一帧地轮发每台终端拿到信道的间隔很长打开下行 OFDMA 后AP 可以把 8 台终端的数据一次性放进一个 PPDU 里发出去帧间隔从几十毫秒降到几毫秒。2.3 上行 OFDMATrigger 帧和缓存状态才是关键上行方向比下行复杂得多因为 AP 不知道终端什么时候有数据要发。802.11ax 的做法是“AP 主动查询终端按指示发送”。AP 会先发送一个 Buffer Status Report PollBSRP触发帧询问关联终端各自的缓存队列长度。收到回应的终端会在 QoS Null 帧里捎带缓存状态信息告诉 AP“我要发多少数据”。AP 据此分配上行 RU再发一个 Basic Trigger 触发帧里面列出了哪些终端在哪些 RU 上发送。真正参与上行传输的终端收到 Basic Trigger 后就在指定 RU 上同时发数据。由于多个终端是同时发的它们之间不会竞争也就不会互相碰撞。等数据发完AP 会回一个多用户 Block ACKMulti-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 PPDUAP 回复 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 是时间上的预约TWTTarget Wake Time目标唤醒时间是我认为 802.11ax 里被忽略很多的一个调度机制。它的用途是AP 和终端协商一个精确的唤醒时间终端在规定时间之前休眠到点醒来收发数据之后继续睡。传统空口省电模式是“终端随时可能醒来竞争信道、收听 beacon”虽然耗电不高但在高密度下会产生大量无效唤醒和信道争用。TWT 把它变成“按预约表唤醒”设备和设备之间错峰既省电又减少空口冲突。广播 TWTBroadcast 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 帧的控制帧子类型是 130x0D。抓包后可以这样过滤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.11acWi-Fi 6 关上行 OFDMAWi-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 这几年代码改动值在哪。