1. 从Wi-Fi 5到Wi-Fi 6为什么调度能力成了分水岭1.1 Wi-Fi 5的困局CSMA/CA的随机竞争本质去年我在一个工业园区做无线网络验收客户反复问我一个问题为什么我们买了双频千兆AP一开会就卡我说这个事得分两层看——设备规格是上限协议机制才是日常体验的底盘。他们当时的AP还是802.11acWi-Fi 5时代的中高端款硬件不差问题就出在机制上。802.11ac以及更早的Wi-Fi协议介质访问控制的核心是CSMA/CA也就是载波侦听多路访问/冲突避免。这个机制可以理解成一条单行道收费站所有车辆先听一听路上有没有车没人走就自己开如果有人正在走就随机退避一小段时间再试。听起来很公平但终端一多问题立刻暴露大家都在听大家都以为没人走于是几十个随机退避值有概率相撞相撞之后又要加倍退避。这种竞争式访问在高密度场景下的信道利用率会急剧下降我实测过30个终端同时在一个20MHz信道上做小包上行有效吞吐大概只有理论速率的30%到40%剩下的时间全部消耗在退避和空闲等待上了。还有一个更隐蔽的问题——隐藏终端。两个终端都在AP覆盖范围内但它们彼此听不到对方的信号它们同时向AP发数据AP这边就会发生碰撞而发送方还浑然不知。传统Wi-Fi解决这个问题要靠RTS/CTS握手但握手本身也要占用信道时间。所以在11ac时代多用户并发能力基本是个伪命题AP再强同一时刻也只能服务一个用户除非用户天线数够多才能用上MU-MIMO而MU-MIMO在Wi-Fi 5里是下行专属上行不支持。这个局面到了802.11axWi-Fi 6圈内习惯叫“ax”才真正被打破。ax不只是快了它是把Wi-Fi从一个“随机竞争的以太网式无线协议”变成了一个“带中央调度能力的蜂窝式无线协议”。这篇文章我想围绕“ax调度”展开——也就是802.11ax引入的OFDMA资源调度、上行触发调度、TWT定时唤醒调度这套机制聊聊它们到底解决了什么问题、实际部署中怎么用以及我在真实组网中踩过的坑。1.2 802.11ax的核心转变AP从旁观者变成了交通指挥ax做得最关键的一件事是把调度权从随机竞争交给了AP。还记得上面那个单行道收费站的比喻吗ax的做法不是修更多收费站而是让AP变成信号灯控制员每个终端什么时候能走、占哪条车道、用多快的速度走全部由AP统一安排。这背后有两套核心工具。一套是OFDMA正交频分多址它把信道在频率维度上切成更小的资源块RU可以同时分配给多个终端使用这就是“频分调度”。另一套是上行触发调度机制AP通过发送触发帧Trigger Frame在特定时刻点名一批终端一起上行发送数据这就是“时分调度”。这两者组合起来配合MU-MIMO在空间维度上的复用使得一个AP在同一个时刻可以和多个终端同时通信。要理解这个转变的分量可以对比一下效果数字。我做过多用户并发测试同样一台AP、同样的终端、同样20MHz频宽关闭OFDMA时20个终端分别进行小包上行总吞吐约18Mbps打开OFDMA调度后同场景总吞吐能到45Mbps以上。这里没有增加任何硬件纯粹是调度机制带来的提升。对于视频会议、在线课堂、场馆看台这类“人人都要同时说话”的场景这种提升才是真正的刚需。1.3 调度机制真正解决的几个实际问题很多朋友问ax调度的价值是不是只在人多的时候体现不完全对但人多确实是最明显的场景。我给你列几个我实际遇到的案例第一个是办公网。某公司会议室区域一台AP带了40多台终端平时网页和邮件都正常一到线上全员大会就卡。原因很典型视频流全是小包同一时刻几十个终端在竞争CSMA/CA随机退避机制下碰撞率很高AP的CPU其实没满信道却被无效重传占满了。ax下行OFDMA起来后AP可以把视频小包按RU分给不同终端大家不用再抢信道卡顿问题基本消失。第二个是高密场馆。看台、候机厅这类场景终端密度可达每AP上百个。传统机制下终端关联数上去后单个终端体验呈断崖式下降开放ax调度后至少能保证每个终端都有固定的“时隙频段空间流”组合可供使用体验下降变得平缓这是质变。第三个是物联网。大量传感器、电子价签、智能门锁它们上报的数据量很小平时绝大多数时间在休眠。11ax的TWT机制允许AP和终端约定唤醒时间终端不用时刻监听Beacon按约好的点醒来发数据即可。这个看似简单的调度约定能让一批电池类终端的功耗大幅下降同时还能错峰上报避免所有设备在同一时刻抢占信道。所以ax调度不是一个可以简单开关的“性能模式”它是一整套新的协议交互逻辑。理解了它要解决的问题下面几节拆解起具体机制来就顺多了。2. OFDMA的RU调度一个信道怎么切成多个车道2.1 从一整条信道到可拼分的资源网格OFDMA并不是新的无线技术4G/5G蜂窝网络早就用过但把它引入Wi-Fi是802.11ax的标志性动作。要理解OFDMA先得理解OFDM符号。一个OFDM符号内数据是调制在多个子载波上的802.11ac的子载波间隔是312.5kHz一个20MHz信道里大约有64个子载波可用802.11ax把子载波间隔缩小到78.125kHz符号时间拉长到13.6微秒这样在相同频宽下可用的子载波数量大幅增加同时因多径时延扩展导致的符号间干扰也更好处理了。子载波数量增加了就有了“切分”的余地。802.11ax最少可以把一个20MHz信道切成9个26音调tone的资源单元也就是RU每个RU包含24个数据子载波和2个导频子载波可以单独分配给一个终端。一个终端即使只需要发一个很小的包也能获得一个专属RU不用去跟别人抢整个信道。反过来如果终端业务量大也可以把多个RU合并分配给同一个终端使用最大可以用整个信道的242-tone RU甚至跨信道合并成996、2x996-tone RU。这里有一个很容易混淆的概念OFDMA调度和传统意义上的“绑定频宽”不是一回事。信道绑定性是让一个终端独占更宽的频段来跑大流量而OFDMA调度是把频段按RU粒度同时分给多个终端让每个终端都能低延迟地使用信道。前者追求单用户极限速率后者追求多用户整体效率和时延两者目标完全不同。我把常用的RU规格整理了一下方便你查表RU类型数据子载波数20MHz下数量40MHz下数量80MHz下数量26-tone RU249183752-tone RU484816106-tone RU102248242-tone RU234124484-tone RU468-12996-tone RU980--1注意82MHz下26-tone RU的理论数量是37其中有部分是因为80MHz下边带子载波多出来的实际标准里具体数量要按表查这里列的是常用值。实站配置时不用记太死但要明白RU越小能同时服务的终端数越多单用户的速率上限越低。2.2 下行OFDMA调度AP如何决定把哪个RU给谁下行OFDMA是ax里最见效、兼容性也最好的能力。AP把发给多个终端的下行数据合并进同一个HE MU PPDU帧里一个PPDU可以带多个终端的独立数据块每块占用不同的RU。这样一来AP实际上承担了中央调度器的角色它需要决定下一个下行传输周期里哪些终端参与、每个终端分配多大的RU、用什么MCS调制等级。我的配置建议是AP侧通常考虑三个因素。第一是每个终端的下行队列长度队列积压多的终端优先给大口径RU第二是终端的时延敏感度视频会议、语音这类业务要尽量快速发完第三是终端的信道质量也就是RSSI和误码率信道很差的终端即使分给它242-tone的大RU调制阶数上不去吞吐反而浪费。一个典型的分配策略可以这样理解会议室里一台终端在开视频会议需要持续走流量AP给它分配一个106-tone的RUMCS设定为较高的档位保证低时延同时另外几台终端在后台做文件同步、收邮件对时延不敏感数据包又小AP把剩下的242-tone RU按26或52-tone切碎分给它们大家互不干扰地在同一时刻完成传输。这里有个很多新手会掉进去的坑是不是AP应该把所有RU都分配给信号最好的终端不是。只照顾高RSSI终端算法上最简单但会造成“部分终端饿死”的公平性问题。无线协议里有最低服务保障的要求实际产品也普遍采用保留RU轮转分配的策略。比如Broadcom、Qualcomm、MTK的商用方案里都有RU分配策略开关有的叫“公平调度”有的叫“吞吐优先”。我一般建议在办公场景用公平策略在专网中只有少量高吞吐终端的场景才考虑吞吐优先。2.3 RU分配中的三个隐藏约束RU调度看着灵活实际用起来有几个隐藏约束这都是在现场踩过坑才明白的。第一个约束是RU大小和调制阶数的权衡。26-tone RU只有24个数据子载波导频开销占比高代表同样MCS下它能承载的速率低。如果终端信号质量好把它塞进26-tone RU就是浪费如果信号质量差给它分大的RU也提不上MCS等级。所以真正好的调度算法要先按信道质量给终端分档再按业务量给RU口径两套维度要对齐。第二个约束是终端能力差异。802.11ax标准虽然定义了RU但老终端不支持HE MU PPDU。它们要么完全听不懂RU分配要么只能通过传统竞争方式接入。这意味着一个AP下面如果混有大量Wi-Fi 5和Wi-Fi 4终端OFDMA的调度效率会被老终端拖后腿。我在项目中见过一个极端情况一台AP带10个Wi-Fi 6终端和30个Wi-Fi 5终端打开OFDMA后总吞吐提升只有20%左右因为老终端还在走竞争机制信道被它们占掉一大半。这引出一个重要的工程结论ax调度的收益和终端更新率强相关不是AP换了就完事。第三个约束是空间复用参数BSS Coloring与RU调度的关系。BSS Coloring本身是提高密集组网空间复用度的机制它让不同AP可以更大胆地同频共存但它不会直接决定AP给谁分RU。可很多网管在配置时容易把两者混为一谈——BSS Coloring做的是“干扰避让优化”RU调度做的是“帧内多用户分配”方向不同调优时得分开看指标。3. 上行触发调度AP如何当交警指挥终端排队发言3.1 上行调度难在哪下行调度是AP关起门来就能做的事数据都在它自己手里想怎么分就怎么分。但上行调度就要复杂得多AP不知道每个终端到底有没有数据要发、要发多少、发多发少这些信息只有终端自己知道。如果AP大笔一挥给某个终端分配了RU结果这个终端的数据寥寥无几那么信道资源就被浪费了其他排队等待的终端体验就会受影响。802.11ax解决这个问题的思路是两步走。第一步AP先通过一个叫BSRPBuffer Status Report Poll的触发机制问一下哪些终端有缓冲数据要上传终端在BSRP响应中上报自己的缓冲状态。第二步AP根据收集到的缓冲信息在真正的上行传输周期里用触发帧精确分配RU。这里最核心的信令就是触发帧。你可以把触发帧理解为交警手里的哨子加手势哨声一响所有被点名的终端同时起步不允许有人提前开跑。这样上行OFDMA才可能实现多个终端在同一时刻、不同频段上并行上传。从性能上看这套机制带来的改善非常直观。我在实验室里用20个Wi-Fi 6终端同时上传300字节左右的遥测小包关掉上行触发调度时由于竞争碰撞严重总速率大约12Mbps左右开启上行OFDMA触发调度后总速率能到40Mbps以上同时丢包率从百分之几降到千分之一以下。原因就在于碰撞几乎消失了信道时间全部被用来传输有效载荷。3.2 触发帧里到底写了什么触发帧是802.11ax多用户调度的关键信令帧看起来是个控制帧但里面携带的调度信息相当细。抓包时你看到Trigger FrameTF包含这些主要内容Trigger Type指明触发用途。最常见的是Basic Trigger用于MU数据的调度还有BSRP Trigger用于缓冲状态采集MU-RTS Trigger用于信道保护。UL Length指定上行HE TB PPDU的长度所有被触发的终端都必须按这个时长发送数据超长尾巴会被丢弃。UL BW指定上行传输的总带宽可以是20MHz的整数倍。User Info字段列表这是调度表的核心每组User Info里包含一个终端的AID关联标识符对应的RU AllocationRU位置和大小、UL MCS调制编码方案、UL Target RSSI上行功率控制目标、以及分配的时空流数量。我自己在Wireshark里过滤Trigger Frame时最常盯的就是User Info里的RU Allocation和UL Target RSSI两个字段。RU Allocation决定谁占哪块频段UL Target RSSI则告诉终端“你发射功率调到多少能让我正好收到合适的信号强度”因为OFDMA频段内多个终端并行发送如果某个终端离AP特别近功率太大就会压掉远处终端的信号这是典型的远近效应。所以上行调度比下行调度更依赖功率控制硬件实现不好或者校准不到位的AP上行OFDMA启用后反而会出现误码率升高的怪象。我这里用一段简化后的抓包字段来描述方便你对照实际定位Trigger Frame |_Trigger Type: Basic (0) |_UL Length: 2828 (us) |_UL BW: 80MHz |_User Info 1 |_AID11: 3 |_RU Allocation: 242-tone RU at index 36 |_UL MCS: 11 (HE-MCS-5) |_UL Target RSSI: -58 dBm |_Number of Spatial Streams: 2 |_User Info 2 |_AID11: 5 |_RU Allocation: 106-tone RU at index 72 |_UL MCS: 8 (HE-MCS-2) |_UL Target RSSI: -64 dBm |_Number of Spatial Streams: 1注意真实抓包里RU Allocation编码是二进制索引表上面这段是给你看逻辑含义的。推荐初学者先在Wi-Fi 6终端和AX AP之间打流用Wireshark抓一次带Trigger Frame的空中报文把上面字段逐个对照标准文档看一遍比看十篇教程都管用。3.3 上行MU-MIMO与OFDMA的联合调度上行调度不只有OFDMA一个维度802.11ax还支持上行MU-MIMO。区别在于OFDMA是把不同终端分到不同频段上而MU-MIMO是让多个终端用完全相同的频段通过不同的空间流来区分信号。实际调度中这两者很少被独立使用而是联合调配一部分终端使用不同RU是频分维度另一部分终端共享某个RU但使用不同空间流是空间维度。打一个比方OFDMA是把高速路横向划成几条车道MU-MIMO则是在同一条车道里让几辆车上下叠着飞——只要接收端能分辨出每一层的信号就行。这样叠加之后一个触发帧可以在80MHz频宽下同时调度最多8个终端参与上行传输还可以进一步将2个终端放在同一个RU上用不同空间流。具体怎么组合要看终端的空间流能力双天线的终端能在同RU上承担2个空间流单天线室内终端只能分到1个空间流。有个工程经验值得分享上行MU-MIMO对信道校准要求非常高终端和AP之间的信道矩阵需要靠NDPNull Data Packet进行探测移动中的终端信道变化快校准过一次以后很快就失准。所以我在会议室这类静态场景会开上行MU-MIMO但在机场、候车厅这类高移动性场景我更倾向于只开上行OFDMA关闭上行MU-MIMO这样调度器反而更稳定。3.4 上行调度的实际效果与局限跑过真实组网的朋友很快会发现一个现实上行调度效果好不好最终取决于终端的支持比例。你AP调度能力再强终端不支持也没有用。标准里802.11ax终端理论上都支持被触发上传但实际看终端侧的实现。某知名手机品牌在系统设置里有一个“Wi-Fi省电模式”默认开启时会把Wi-Fi芯片的上行HE功能关掉导致这台手机在AP眼里就从Wi-Fi 6“退化”成了传统终端只能靠CSMA/CA竞争。我排查过好几次“明明终端支持ax为什么跑不出多用户效果”的问题最后都定位到这个省电开关上。另外不同芯片厂商对BSRP的处理策略也不太一样。有的芯片在缓存数据小于一个阈值时不做响应这会让AP误以为它“无话可说”从而不参与本轮调度。这个问题在低数据量传感器场景里特别明显。所以验证上行调度效果不要只看单终端吞吐而是要看AP统计的“触发帧响应率”指标这个数值在主流厂商的无线控制器上都能直接看到。4. TWT设备的对话窗口让低功耗和低延迟同时成立4.1 TWT的本质约好时间再说话而不是随时待命TWTTarget Wake Time不是802.11ax的首创早在802.11ah就开始标准化了但直到ax把它引入主流Wi-Fi才变成大众熟悉的特性。它的核心思想特别简单终端和AP提前约定好一个或者多个唤醒时间点在这些时间点之外的时段终端可以去睡觉AP不会主动给它发数据。想理解TWT的价值可以先回忆一下老Wi-Fi是怎么处理省电的。传统PSM省电模式下终端平时可以睡但得周期性醒来听Beacon看看AP有没有给它缓冲的数据。Beacon默认每100ms一个也就是说最久100ms就要醒一次。DTIM周期进一步决定了多播数据缓冲的唤醒频率。这个机制的问题在于醒来的时间是系统固定的而不是按设备实际业务约定的。每一轮Beacon唤醒都会消耗一点无用功耗。TWT本质上把“定时醒来”改成了“按需预约醒来”。终端可以和AP协商出一个Wake Interval比如每2秒醒来一次也可以协商出一个窗口期在窗口期内一次性传输完积压的数据然后再睡。最有价值的是物联网场景里几十个传感器可以各自安排不同的唤醒时隙避免大家同时醒来挤爆信道。这个调度能力实际上是给低功耗设备设计了专用的信道时间分配方案。我做过一个挺直观的对照实验两个相同的温湿度传感器分别用传统PSM和TWT接入同一台AP上报周期都是30秒一次、每次报文200字节。连续跑三天后TWT方案的电池电压下降比PSM方案低了将近三成。原因就在于PSM每100ms就要醒一次听Beacon而TWT把醒来的次数降到每30秒一次。对电池供电的智能家居设备来说这个收益非常实在。4.2 单用户TWT与广播TWT的适用场景TWT在802.11ax里有两种主要形式区分清楚了才好在实际里配置。第一种是单用户TWTIndividual TWT终端在关联时或者关联后通过TWT协商请求和AP约定自己的专属唤醒周期。这种适合单个行为规律的低功耗设备比如门锁、传感器。但你要注意单用户TWT一旦协商成功AP和终端都要严格遵守约定如果终端在约定时间之外突然有紧急数据要发它需要额外发一个帧来“打断”协议处理起来比较麻烦。第二种是广播TWTBroadcast TWTAP在Beacon帧里直接广播一个统一的TWT约定时间表广播域内的终端按角色加入。省去了逐个协商的流程特别适合成百上千台设备统一管理的IoT场景。AP会为广播TWT设定一个服务周期在这段时间内允许被调度的终端集中上/下行传输其他时间终端休眠。实际部署中我建议对语音类和视频类终端慎用长周期的TWT。因为TWT周期拉长意味着终端休眠时间变长AP如果有数据要发给终端必须等到下一个唤醒窗口这对实时性业务不友好。语音通话的RTP包每20ms一个如果你的TWT周期设为100ms以上就需要终端侧做大幅缓冲包延迟直接超标。如果你确实想在会议室里开TWT降噪周期也建议控制在50ms以内并且只对支持良好的设备开启。4.3 TWT对漫游和AP调度的影响TWT有一个容易被忽视的副作用它会影响终端的漫游灵敏度。漫游决策依赖终端持续监听Beacon和邻居AP信号强度。如果终端被TWT大量时间处于休眠它能感知到的邻区信息就会变少这会推迟甚至抑制漫游触发。在部署了主动漫游算法的AP方案里常会看到这类问题设备在会议室里沉浸式休眠走出门口很久了还没切换因为它在自己约定的窗口之外根本没听到邻居AP的Beacon。解决思路是在AP侧设定TWT最大周期上限同时要求支持“TWT不可用期间缓冲转发”的终端至少每几个周期保留一次全信道监听。有一个厂商推荐的做法是把TWT的Wake Interval上限设为DTIM周期的整数倍并且不要超过2秒在省电和漫游之间取得可接受平衡。这个数字不是标准强制值但我在移动办公场景验证下来体验较好。另外TWT和调度器之间也有耦合关系。AP的调度器在做RU分配时如果某些终端正处于TWT休眠期就不能参与调度但如果AP为了迁就TWT把调度周期拉长又会拖累普通终端的延迟。所以成熟的AP芯片方案里都有“TWT感知调度”调度器会把终端分为TWT组和常规组分时处理。如果你买到的AP固件没有这个分组调度能力高密场景里不要同时开TWT和强OFDMA调度否则两种机制会打架这是我在实际项目里验证过的。4.4 兼容性TWT最大的坑TWT在802.11ax标准里是可选特性也就是说每个终端厂家可以选择实现也可以选择不实现或者实现一半。实际兼容性问题可分为三类。第一类是完全不支持老终端甚至802.11ax早期固件的终端都没有TWT能力AP发了TWT IE也只当作普通元素跳过。第二类是支持但策略保守部分手机会在检测到特定网络环境比如隐藏网络、企业认证时自动关闭TWT意图是避免省电导致的连接不稳定。第三类是实现了但行为不一致比如有的终端上报的Wake Interval精度是微秒级但实际时钟漂移严重到了约定时刻还得额外等轮询并没有达到省电目的。怎么验证AP和终端的TWT是否真的协商上了我的建议是抓Beacon和关联阶段的动作帧看关联请求里是否携带TWT IE再看AP发回的关联响应和Beacon里的广播TWT参数。在Wireshark里过滤wlan.twt能快速确认协商结果。千万不要只看AP面板上开着“TWT开关”就认为设备都在享受省电了实际协商成功率的统计参数有些AP是单独列出来的有些没有没有的话只能靠抓包。5. 真实组网里的调度经验参数调优与踩坑记录5.1 一次现场问题全功率打开优化特性反而变慢前阵子做了一家连锁办公空间的无线改造方案里采购的是某主流厂商的Wi-Fi 6 AP控制器里有“全优化模式”开关打开后会自动启用OFDMA上下行、MU-MIMO、TWT等能力。客户要求“全场景优化”我也就一键全开了。结果验收时发现了奇怪现象会议室单终端测速能跑满千兆但一进高密模拟测试——30台笔记本加手机同时开会视频反而比原来Wi-Fi 5网络还卡。排查过程是这样的。我先看AP的统计数据发现下行OFDMA参与度很高大量终端都走了多用户调度但上行触发帧响应率只有不到50%也就是说有一半的终端对Trigger Frame根本没有反应。这直接导致AP调度器认为大量上行数据积压不断重复触发反而占用了更多信道时间。再用Wireshark抓包发现响应率低的终端全是旧款笔记本和几年前上市的手机它们的Wi-Fi芯片要么不支持HE要么虽然支持但在省电模式下关闭了HE功能。这个问题的根子就在终端能力参差。高密场馆里永远是“新老设备混跑”在旧终端比例超过三成时激进的调度设置反而让整体效率下降。因为AP发的触发帧没人响应这些帧占用信道时间而真正参与调度的新终端又因为等待响应而延迟增长。最后我把方案调成了“下行OFDMA开启、上行OFDMA按需开启、MU-MIMO开启、TWT关闭”的组合再测高密场景整体时延和吞吐立刻恢复到正常水平。这个项目给我留下一个经验所有调度特性全开未必是好事调度器要按真实终端结构做取舍。5.2 关键调度参数怎么设一份实操清单基于这个项目的后续调优也结合其他几个现场我整理了一份偏保守但稳当的参数建议你在做Wi-Fi 6网络规划和优化时可以直接当参考参数项推荐设置说明下行OFDMA开启多用户下行场景收益明显风险低上行OFDMA开启但观察触发帧响应率响应率低于60%时建议关闭或降级上行MU-MIMO静态场景开高移动场景关移动终端信道估计容易失准RU分配策略办公场景选“公平调度”专网选“吞吐优先”公平策略能避免低吞吐终端饿死BSRP周期100ms左右周期太短占用信道太长上行调度响应迟钝TWT默认关闭IoT设备单独SSID再开启避免和漫游、语音业务冲突BSS Coloring按同频AP干扰情况调整着色阈值优化干扰但不要和OFDMA调参混淆这里的参数是通用起步值具体设备厂商可能会有不同的命名和默认值。我的建议是改任何一个参数之前先在AP侧打开“信道利用率”和“帧重传率”两个指标改完观察一段时间不要拍脑袋叠加。因为调度参数的互相影响比较复杂你动一个其实可能牵动另外三个。有一个特别容易忽略的配置是MU-MIMO的天线策略。如果你的老旧终端是单天线而新终端是双天线AP的MU-MIMO分组会天然偏向双天线设备单天线设备就只能排在后面造成不公平体验。遇到这种情况不要一刀切关闭MU-MIMO而是检查是否可以在分组策略里把单天线终端单独分到一个组用不同优先级调度。5.3 验证调度效果别信面板信数据调度类参数配置完之后怎么知道真的有效果很多朋友习惯看AP面板上的“OFDMA次数”数据确实好看但那个数字高不一定代表体验好。我建议按下面三个层面做验证。第一层是终端层验证。选几台不同代际的终端固定接入分别做单流下行、单流上行、并发多用户上行三类测试记录各自的速率和时延抖动。重点看两种场景的对比开启调度前和开启调度后同一组终端同时并发上传小包时的总吞吐。第二层是空口抓包验证。用Wireshark接到一张支持监听模式的Wi-Fi 6网卡上抓取空中帧。重点看几个指标HE MU PPDU的数量占比Trigger Frame是否有稳定的Uplink响应以及不需要去数每个点但能看到连续传输周期中调度器的工作状态。当你看到Trigger Frame之后没有紧跟着出现一串HE TB PPDU就要小心了——说明触发链路可能断了。第三层是AP侧统计验证。主流厂商的AP统计里都有“MU MPDU TX次数”“触发帧响应率”“OFDMA上行/下行使用率”这些项。我在验收项目时有一个硬指标上行OFDMA场景下触发帧响应率应在80%以上低于60%就是异常要考虑关闭上行调度。时延方面重点盯99分位时延而不是平均时延平均时延好看但99分位爆表恰恰说明调度器对部分终端长期不公平。5.4 不同场景下ax调度的取舍建议最后从场景维度给几点更偏工程实践的建议这些都是踩过坑换来的。宽带家庭和SOHO场景终端数量一般在10到20台下行OFDMA大胆开上行OFDMA建议也开。家里视频通话和网课并发时上行调度的改善很明显。TWT可以选择默认关因为家用路由器管理界面大多没有细粒度TWT配置终端自己协商出长周期反而可能造成智能门锁响应变慢。我碰到过一次用户投诉智能门锁视频预览要等两秒排查下来就是路由器固件默认开启了广播TWT门锁频繁睡死在非唤醒窗口关掉后恢复正常。办公室和会议室场景重点关注视频会议体验。这里我建议打开下行OFDMA和上行OFDMARU公平策略打开MU-MIMO按终端新旧比例决定。如果办公网络里超过一半还是Wi-Fi 5终端那你在AP硬件上花的钱有一半发挥不出效果该推动终端更新就推动不要指望单换AP能解决所有历史包袱。高密场馆和校园无线场景最忌讳的就是把所有优化特性全开。我曾在一个体育场馆做过测试只保留下行OFDMA BSS Coloring默认值关闭上行OFDMA和TWT配合cell size调低和最低速率限制整体用户满意度反而比全开模式高。原因在于高密条件下调度器的稳定性比“瞬时吞吐最大”更重要。其实做ax调优这么久我最大的心得不是某个参数怎么设而是永远不要脱离终端分布去做优化决策。Wi-Fi协议再怎么扩展调度能力最终还是在为一个结构复杂的用户群服务调度器只是工具服务目标才是判断依据。