做无线这行久了看到“ax”这两个字母第一反应基本都一致802.11ax也就是 Wi-Fi 6 的协议代号。真正让 ax 和之前几代拉开差距的并不是标称速率又高了多少而是它把无线接入从“抢占式”改成了“调度式”。前面再加“调度”两个字说的就是 802.11ax 里最核心、也最容易被普通用户忽略的那套机制——OFDMA、MU-MIMO、触发帧、资源分配、空间复用一套组合拳打下来Wi-Fi 才从“一群人抢一根带宽”变成“一个总调度官按需排课”。前几天还有客户问我公司已经全换 Wi-Fi 6 路由器了30 台电脑开会一起传文件为什么会场还是卡。这个问题的答案通常不在天线、不在宽带而在你到底有没有真正理解“ax 调度”在干什么。这篇文章我会把 802.11ax 调度的原理、调度器内部怎么决策、怎么通过抓包和压测验证调度有没有生效以及我在项目里踩过的坑全部梳理一遍。无论你是做无线网络运维、企业 AP 选型还是做嵌入式协议栈开发这篇都能给你一套可以直接落地的判断方法。1. 先把“ax 调度”拆开Wi-Fi 6 重构了接入方式1.1 从抢话筒到排课表调度范式彻底变了传统 Wi-Fi 从 802.11 到 802.11acMAC 层接入主要靠 CSMA/CA 和 EDCA 信道竞争。所谓 EDCA就是每个站点根据自己的优先级队列去监听信道信道空闲了就退避一个随机时间再尝试发送。这个机制在终端少的时候非常高效就像小会议室里只有三四个人谁想发言随手举起话筒就行基本不用排队。可一旦人多了比如大会场里三十个人同时要发言靠抢话筒的方式就会出现大量碰撞、退避、重传信道利用率断崖式下降。802.11ax 做的第一件大事就是在 MAC 层引入 OFDMA把“抢话筒”改成“老师点名”。AP 作为唯一的调度者把信道从频率上切成大小不同的资源单元也就是 RU然后在一个发送机会里同时给多个终端派发数据上行方向则由 AP 发 Trigger 帧点名让多个终端同时在不同 RU 上回传。这个转变非常关键原来每一帧传输都要先竞争信道现在大部分数据传输由 AP 主动安排竞争开销被大幅压缩多终端场景下的空口利用率提高了一大截。这个设计背后还有一个深层原因Wi-Fi 6 时代的主要矛盾已经不是单终端速率而是高密度场景里的系统容量。智能手机、笔记本、摄像头、传感器单台设备的需求其实并不大但数量一多传统机制的开销就变成了天花板。OFDMA 这种“分频段并行传输”的思路本质上是把无线资源从“独占”变成“共享再细分”让大量低速率小流量设备可以在同一时刻共存。1.2 OFDMA 与 MU-MIMO频率和空间的“双车道”OFDMA 是在频域上切分MU-MIMO 则是在空间域上叠加这两者经常被放在一起说但很多人会把它们搞混。我打一个比方OFDMA 相当于把一条马路按车道划分一辆车跑一条车道多辆车并排走MU-MIMO 则是在同一段路面上让多辆车叠罗汉式地同时通过靠的是不同车辆走不同“空间路径”AP 用天线阵列把各路信号分离开。802.11ax 里 OFDMA 和 MU-MIMO 是可以同时组合的。一个 HE MU PPDU 里AP 可以把 80MHz 带宽切成若干个 RU一部分 RU 分配给终端 A另一部分 RU 分配给终端 B同时在某个 RU 上给终端 C 做多流传输。这个灵活度是 802.11ac 完全不具备的。ac 时代虽然也有下行 MU-MIMO但只能把整个信道的时频资源按相同带宽分给最多四个用户而且上行 MU-MIMO 根本不存在探测反馈开销又大实际部署里经常是“纸面有、收益少”。ax 把 MU-MIMO 和 OFDMA 绑在一起之后下行可以灵活选择哪些用户进入同一帧上行也可以通过 Trigger 帧同时收集多个终端的突发数据。单从调度角度看这相当于把原来“一帧只服务一个用户”的串行模式变成了“一帧同时服务多个用户”的并行模式。我用实际项目里的体感说在 50 台终端同时办公的开放区开启完整 ax 调度之后单终端体验不一定比老协议快多少但整体并发能力、时延抖动、以及网络在高负载下的稳定性提升是非常明显的。1.3 上行调度怎么发生一次 Trigger Frame 的完整旅程很多人以为上行调度就是终端“想发就发”实际完全不是。802.11ax 的上行传输是 AP 主动控制的整个流程大概是这样的AP 先通过调度器决定接下来要给哪些终端发送触发机会然后发出一个 Trigger 帧。Trigger 帧里包含公共信息比如触发类型、传输时长、带宽、保护间隔还包含每个被调度终端的用户信息比如 AID关联标识、RU 分配位置、目标接收功率、MCS 等。终端收到 Trigger 帧之后在 SIFS 时间后立刻用 HE TB PPDU 格式同时上行发送。这个“同时”非常讲究因为不同终端距离 AP 远近不同、发射功率也不同如果不做任何控制AP 接收时就会近端信号压制远端信号。所以 Trigger 帧里专门带了一个目标接收功率字段每个终端会根据自己估算的路径损耗调整发射功率目的就是让 AP 收到来自不同用户的信号电平尽量接近。我们可以把 Trigger 帧理解成老师在课堂上点名“张三交作业、李四交作业、王五交作业限时 3 分钟必须同时起身。”张三、李四、王五人虽然在教室不同位置说话音量也天然有差别但老师要求每个人说话声音到他耳朵里都差不多大这样他才能同时听清楚。触发帧不止 Basic Trigger 一种还有用于信道探测的 BSRP缓存状态报告轮询和 Beamforming Report Poll。其中 BSRP 比很多人想象得更关键——AP 要调度就得知道“谁有数据要发、有多少数据”否则就是瞎排课。BSRP 会定期向终端询问上行缓存状态终端上报之后调度器再决定下一轮把上行机会给谁。这也是我排查问题时最喜欢看的环节看看 AP 是不是真的在做有依据的调度。2. 调度器在做什么RU 分配与关键权衡2.1 调度目标远不止“公平”提到调度器搞系统的朋友第一时间会想到 CPU 调度或者网络队列调度ax 里的空口调度器其实是同一类问题只不过资源变成了“频率 RU、空间流、发送时长”这三样。一个 802.11ax AP 的调度器在每个发送机会到来之前需要回答四个问题本帧服务哪些站点RU 怎么切分每个站点分配多大 RU、多少空间流用什么样的 MCS这四个问题的答案相互耦合而且目标不止一个。最朴素的调度目标是最大化系统吞吐也就是把信道给信道条件最好的终端让它们用 1024-QAM 高速率跑。但这样做会让远处那些信号弱的终端饿死视频电话卡成幻灯片。行业内最常用来平衡吞吐和公平的算法叫比例公平核心思路是对每个终端维护一个历史平均速率调度优先级等于当前可达到的速率除以历史平均速率。这样一来信道好的终端不会因为“平时吃得饱”就被冷落信道差的终端只要有机会达到相对自身水平的速率也能得到发送机会。除了公平还有时延。语音、视频会议这类实时业务走的是高优先级 AC 队列调度器在分配 RU 时通常会给高优先级队列更多的发送机会和更小的触发间隔。我在无线音视频项目里看到过一种很有意思的现象如果调度器只盯着吞吐把 RU 全部分给下载大文件的终端语音花包的时延会直接飙到几百毫秒用户听到的会议就是一顿一顿的。所以一个成熟的 ax 调度器至少要在吞吐、公平、时延三者之间做动态权衡。2.2 RU 怎么分从 26-tone 到 996-tone 的选择题OFDMA 的 RU 大小不是随便定的协议规定了若干固定粒度常见的有 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone。这里的 tone 是子载波数量802.11ax 的子载波间隔是 78.125kHz比传统 802.11 的 312.5kHz 小了四倍。子载波间隔缩小带来的好处是符号时间变长到 12.8 微秒抗多径和覆盖能力更好代价是单个子载波更窄必须靠更多子载波聚合才能支撑高速率。RU 分配的核心权衡是你是想让少数终端跑得飞快还是想让大量终端并发不卡。我经常用一个表格帮助客户理解RU 大小约等于带宽典型用途26-tone约 2MHz极小包、物联网传感器、语音小包并发52-tone约 4MHz低速终端、控制类报文106-tone约 8MHz普通网页、消息类流量242-tone约 20MHz高吞吐单用户、视频流484-tone约 40MHz高速率大流量传输996-tone约 80MHz单终端极限速率场景从实际项目经验来看RU 并不是切得越小越好。26-tone RU 虽然能容纳更多用户同时传输但每个 RU 都需要导频、保护子载波开销占比很高频谱效率并不理想。如果会场里十几个终端都在看网页这种小流量业务切 26-tone 和 52-tone 是合理的但如果有一台服务器在备份大文件给它塞一个 26-tone 小 RU 就是用傻子的速度跑马拉松。好的调度器应该能识别业务流量大小大流量给大 RU、小流量给小 RU而不是一刀切。另外协议对 RU 的组合排列也有严格限制调度器不能随意画格子只能按照标准里规定的 RU 分配表来切。这也是为什么有些低端 AP 虽然标着支持 802.11ax实际上可能只做了非常简单的轮询调度甚至干脆只在单终端时走 HE SU 模式多终端时退化成传统 OFDM——抓包里看得一清二楚后面我会讲怎么抓。2.3 BSS Coloring把空间复用也纳入调度范畴调度并不只是单个 AP 内部的事。在一个办公区里可能有十几个 AP 覆盖重叠区域不同 BSS 之间如果没有协调就会互相侦听、互相退避形成 OBSS重叠基础服务集问题白白浪费大量空口时间。802.11ax 解决这个问题的手段叫 BSS Coloring。BSS Coloring 的原理是在 HE-SIG-A 字段里放一个 6 位的 BSS 颜色标识站点收到邻居信号时先看颜色如果颜色和自己所属 BSS 一致说明是来自本小区的信号该避让就避让如果颜色不一样说明是邻居 BSS 的信号只要信号强度没有超过 OBSS_PD 阈值就可以认为“它干扰不到我”允许并发传输这就是空间复用。这项机制调度上的意义在于它让“能不能同时发”的判断从简单的能量检测升级成了更智能的“颜色识别 强度判断”。实际调优的时候AP 产品里一般会提供 OBSS_PD 阈值的调整通常默认在 -82dBm 附近往高了调会让站点更大胆地在邻居信号旁并发传输理论上提升容量但有可能造成边缘用户体验下降往低了调则更保守。还要注意一个很实际的坑相邻 AP 如果配置了相同的 BSS Color站点会把邻居信号误认为本小区信号从而放弃复用机会白白损失容量。所以在高密度规划里我会刻意检查 AP 控制器的自动颜色分配结果必要时手工调整。3. 实操怎么观测、怎么测试、怎么调优3.1 用 Wireshark 直接看调度是否真的在跑判断一个 AP 的 ax 调度是否真正生效最可靠的方法不是看宣传彩页而是抓包。没有做过这件事之前我对“AP 支持 OFDMA”这句话都是保留态度的因为不少型号实际上只在部分场景下启用或者启用后触发频率极低。抓包需要用支持 802.11ax 的无线网卡比如常见的 Intel AX200/AX210 这类并开启 monitor 模式。在 Wireshark 里定位上行调度最直接的方法是找 Trigger 帧。Trigger 帧是控制帧Wireshark 里过滤表达式常用wlan.fc.type_subtype 0x1c展开细节能看到 Common Info 和 User Info。User Info 里是不是有多个终端就说明这次点名点了几个人。紧接着这些 Trigger 后面一般会跟着一串短帧间隔的 HE TB 上行 PPDU如果同时能看到多个站点在同一时刻回传数据那就是 OFDMA 实实在在发生了。另外还要学会看 HE MU PPDU 的下行调度。Wireshark 里展开 802.11 层如果看到 HE MU PPDU并且里面包含了多个 STA 的 RU 分配信息说明 AP 正把下行资源同时分给多个终端。反之如果一个号称支持 ax 的 AP 在抓包里全是 HE SU PPDU 或者传统 OFDM 帧那它的调度器基本就是摆设多终端场景下性能和高密场景不会有本质提升。我自己的习惯是在同一个点位抓满 60 秒统计 Trigger 帧的数量、平均每帧调度的用户数、HE MU 帧占比这三个指标。任何一次无线性能分析都先看这三个数再决定要不要动配置。3.2 多终端并发压测验证 OFDMA 是否真的带来收益抓包能证明“调度在跑”但调度跑得好不好还得靠性能测试来量化。单终端测速是看不出 OFDMA 优势的因为单终端本来就该用大 RU 跑高 MCS。正确的测法是多终端并发。我在测试时最常用的工具是 iperf3。比如在 AP 下挂 8 台无线终端同时向服务器发起下行流量命令大概是这样iperf3 -c 192.168.1.10 -t 60 -P 8这里 -P 8 是同一终端起的 8 条流。真正要做的其实是拿 8 台不同终端分别跑每台各自起一条或两条流然后对比两个数据一是聚合总吞吐二是每条流的吞吐是否均匀。OFDMA 生效时每条流的吞吐方差应该明显小于传统竞争模式最差流的吞吐会显著提高同时传输时延抖动会下降。换句话说你不需要期待总吞吐翻倍而应该期望“没有一台设备被饿死”。除了吞吐还要测时延抖动。用 iperf3 的 UDP 模式可以看 jitter 和丢包率iperf3 -c 192.168.1.10 -u -b 30M -t 60 -P 4Wi-Fi 语音和视频会议对抖动最敏感OFDMA 开启后小包并发时的抖动通常会明显改善。如果测出来抖动比不开 OFDMA 还高那就要看看是不是触发间隔太长或者 RU 切得过碎导致小包排队时间变长。3.3 产品里的那些开关到底怎么选现在企业级 AP 的射频配置页面里一般都能看到跟 802.11ax 相关的一排开关OFDMA、MU-MIMO、TWT、BSS Coloring名称可能略有不同但作用大致一致。我把自己的配置经验总结如下先看场景。如果部署场景是教室、会议室、办公区这类多终端并发明显的地方OFDMA 和上行 MU-MIMO 建议都打开。这个组合解决的是多终端同时读写时的公平性和效率问题实际收益最大。如果场景是仓库、厂房这类以少量扫描枪和传感器为主的环境OFDMA 开不开影响不大反而要重点关注 TWT因为这类设备大多是周期小包TWT 能让它们协商出统一的唤醒节奏大幅降低空口竞争和功耗。TWT 是很多设备翻车的地方。有些厂商默认全局开启 TWT结果部分老终端的协议栈实现不完整协商失败后反复重试网络看起来就是“信号满格但下载卡”。我的经验是TWT 不要一上来就全局强开先把 AP 和终端之间的兼容性测明白或者只在特定 SSID 上针对 IoT 终端开。宁可牺牲一点极端的省电指标也要保证兼容性。BSS Coloring 默认开就行但要注意密集部署下相邻 AP 的颜色冲突。至于 160MHz 频宽它在 5GHz 高密度环境里并不总是最优选择因为可用信道少、雷达避让多、邻居干扰大很多时候 80MHz 反而能获得更稳定的协商速率。带宽策略的影响往往比 OFDMA 那几个开关更明显别一上来先奔着 160MHz 去。4. 真实项目里的坑ax 调度问题排查实录4.1 症状一协商速率正常总吞吐就是上不去这个现象我见过不下十次客户端和 AP 之间协商到了 1200Mbps跑 iperf3 单流却只有 400 多 Mbps多终端一并发直接崩到 200 以内。一开始很多人怀疑是 OFDMA 调度出了问题实际上我在现场测出来的首要因素通常是信道带宽被压缩了。排查时先看协商速率的具体构成和实际信道占用带宽比如 Linux 下可以用iw dev wlan0 station dump iw dev wlan0 survey dump第一条命令能看到每个终端的 tx bitrate、rx bitrate以及协商的 MCS 和 NSS第二条命令能看到每个信道上的活动时间分布。如果发现信道带宽只有 20MHz或者 MCS 很低那问题多半出在干扰和覆盖上跟调度器没什么关系。我处理过一个客户现场隔壁公司有一批老设备把整个 5GHz 频谱的底噪抬高了一截AP 的 CCA 阈值又不敏感结果明明是 Wi-Fi 6 设备协商速率被压到 802.11n 的水平。先去修射频环境再谈调度优化。4.2 症状二开启 OFDMA 后老终端开始掉线、卡顿Wi-Fi 6 AP 往往会兼容 802.11a/b/g/n/ac 设备。但兼容模式下的调度非常微妙OFDMA 的 Trigger 帧对老设备来说是不可识别的新帧格式理论上它们应该忽略并继续走传统流程可现实中有不少老网卡驱动在遇到触发帧时处理异常比如把 Trigger 误判为普通控制帧进而出错。遇到这类问题我的排查顺序是先看掉线终端集中在哪个协议版本和哪块网卡然后到 AP 配置里尝试关闭 OFDMA只保留 MU-MIMO 或完全关闭看看现象是否消失。如果确认是 OFDMA 触发兼容问题在生产环境里最稳妥的方案是把老终端单独放到一个关闭 802.11ax 功能的 SSID 上让新终端走完整 ax 调度两边互不干扰。不要想着靠同一个 SSID 下的“自适应”解决所有问题厂商驱动更新速度没那么快。4.3 症状三AP 负载飙升调度器成了新瓶颈OFDMA 的好处是多终端并发但调度器本身也是要消耗算力的。在一些用户数特别多的高密场景比如 200 人以上的报告厅AP 的 CPU 和基带资源会随着 RU 分配计算、Trigger 调度、状态维护而快速上升。我自己测过高密 AP在满载状态下如果每帧都硬切多用户基带资源占用率会比传统模式高一截。碰到这种情况我的处理思路不是把 OFDMA 关掉而是调整“调度粒度”。一是把 AP 的最大关联用户数设合理上限超过上限就引导终端漫游到邻近 AP别让单个 AP 硬扛二是检查是否开启了很多终端同时进行 MU-MIMO 的配置MU-MIMO 对基带算力的需求比纯 OFDMA 更大在用户密度极高、单用户流量也大的场景反而要适当关掉 MU-MIMO只保留 OFDMA。这听起来反直觉但我实测不止一次发现关掉高负载场景下的 MU-MIMO 后整体稳定性和每用户吞吐都有提升。4.4 症状四漫游频繁调度重建开销大ax 调度并不是终端一关联就万事大吉。AP 要维护每个终端的信道状态、缓存状态、历史速率、RU 分配记录这些信息在终端漫游切换时会全部丢失或过期新 AP 需要重新探测、重新累积统计调度器的“冷启动”会导致切过去的最初几秒速率不稳定。在多个 AP 覆盖交叉区域这个问题尤其明显。我在一个办公园区项目里遇到手机端视频会议频繁卡顿排查到最后发现是 AP 信号交叠太大、漫游阈值设置过紧终端在两台 AP 之间来回横跳每次切换都触发调度重建会议体验自然拉胯。解决方案比较常规统一全网射频配置调整漫游阈值和最小 RSSI让终端在合适的位置“一次切到位”而不是反复横跳。另外全网 AP 的 OFDMA、TWT 等参数必须一致否则终端切换后行为模型变化调度器还要重新适应该终端的特征。4.5 症状五音视频延迟抖动变大小包被“派课”拖累了最后说一个特别容易误判的场景。有人以为 OFDMA 开了之后所有业务都会变好其实不是。语音这类小包业务在一个 RU 占比很小的调度帧里虽然能同时传输但如果触发间隔太长小包要在终端里等一个完整的调度周期排队时延反而可能上升。我在做无线语音项目时调过 AP 的触发周期参数并且用抓包统计 Trigger 帧的出现频率。对于语音终端比较多的场景我倾向让调度器提高高优先级队列的触发频次甚至给语音终端预留固定 RU。同时也注意到如果网络里语音终端本来就不多传统 EDCA 的高优先级机制已经够用OFDMA 反而增加等待。所以我的原则是小包多且并发高才需要 OFDMA 调度介入少量语音终端就让它们走原有高优先级队列不要一刀切地“全开”。这几年摸爬滚打下来我最大的体会是ax 调度不是面板上多勾几个选项就能无脑生效的它需要你结合场景、终端形态、射频环境一起来看。不管厂商标得的调度能力有多炫我建议你先打开抓包工具亲眼看到 Trigger 帧里同时出现多个终端的名字再谈调优两个字。如果抓不到这样的场景那所谓的 Wi-Fi 6 体验提升大概率只是从 802.11ac 到 802.11ax 的标签升级罢了。