1. 从Wi-Fi 5到Wi-Fi 6：为什么调度能力成了分水岭
1.1 Wi-Fi 5的困局：CSMA/CA的随机竞争本质
去年我在一个工业园区做无线网络验收，客户反复问我一个问题：为什么我们买了双频千兆AP，一开会就卡？我说这个事得分两层看——设备规格是上限，协议机制才是日常体验的底盘。他们当时的AP还是802.11ac（Wi-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.11ax（Wi-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 RU | 24 | 9 | 18 | 37 |
| 52-tone RU | 48 | 4 | 8 | 16 |
| 106-tone RU | 102 | 2 | 4 | 8 |
| 242-tone RU | 234 | 1 | 2 | 4 |
| 484-tone RU | 468 | - | 1 | 2 |
| 996-tone RU | 980 | - | - | 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的RU，MCS设定为较高的档位保证低时延；同时另外几台终端在后台做文件同步、收邮件，对时延不敏感，数据包又小，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先通过一个叫BSRP（Buffer Status Report Poll）的触发机制，问一下哪些终端有缓冲数据要上传，终端在BSRP响应中上报自己的缓冲状态。第二步，AP根据收集到的缓冲信息，在真正的上行传输周期里，用触发帧精确分配RU。
这里最核心的信令就是触发帧。你可以把触发帧理解为交警手里的哨子加手势：哨声一响，所有被点名的终端同时起步，不允许有人提前开跑。这样，上行OFDMA才可能实现多个终端在同一时刻、不同频段上并行上传。
从性能上看，这套机制带来的改善非常直观。我在实验室里用20个Wi-Fi 6终端同时上传300字节左右的遥测小包，关掉上行触发调度时，由于竞争碰撞严重，总速率大约12Mbps左右；开启上行OFDMA触发调度后，总速率能到40Mbps以上，同时丢包率从百分之几降到千分之一以下。原因就在于，碰撞几乎消失了，信道时间全部被用来传输有效载荷。
3.2 触发帧里到底写了什么
触发帧是802.11ax多用户调度的关键信令帧，看起来是个控制帧，但里面携带的调度信息相当细。抓包时你看到Trigger Frame（TF）包含这些主要内容：
- Trigger Type：指明触发用途。最常见的是Basic Trigger用于MU数据的调度，还有BSRP Trigger用于缓冲状态采集，MU-RTS Trigger用于信道保护。
- UL Length：指定上行HE TB PPDU的长度，所有被触发的终端都必须按这个时长发送数据，超长尾巴会被丢弃。
- UL BW：指定上行传输的总带宽，可以是20MHz的整数倍。
- User Info字段列表：这是调度表的核心，每组User Info里包含一个终端的AID（关联标识符），对应的RU Allocation（RU位置和大小）、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之间的信道矩阵需要靠NDP（Null 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的本质：约好时间再说话，而不是随时待命
TWT（Target 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里有两种主要形式，区分清楚了才好在实际里配置。
第一种是单用户TWT（Individual TWT），终端在关联时或者关联后通过TWT协商请求和AP约定自己的专属唤醒周期。这种适合单个行为规律的低功耗设备，比如门锁、传感器。但你要注意，单用户TWT一旦协商成功，AP和终端都要严格遵守约定，如果终端在约定时间之外突然有紧急数据要发，它需要额外发一个帧来“打断”协议，处理起来比较麻烦。
第二种是广播TWT（Broadcast TWT），AP在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和上行OFDMA，RU公平策略打开，MU-MIMO按终端新旧比例决定。如果办公网络里超过一半还是Wi-Fi 5终端，那你在AP硬件上花的钱有一半发挥不出效果，该推动终端更新就推动，不要指望单换AP能解决所有历史包袱。
高密场馆和校园无线场景，最忌讳的就是把所有优化特性全开。我曾在一个体育场馆做过测试，只保留下行OFDMA + BSS Coloring默认值，关闭上行OFDMA和TWT，配合cell size调低和最低速率限制，整体用户满意度反而比全开模式高。原因在于高密条件下，调度器的稳定性比“瞬时吞吐最大”更重要。
其实做ax调优这么久，我最大的心得不是某个参数怎么设，而是永远不要脱离终端分布去做优化决策。Wi-Fi协议再怎么扩展调度能力，最终还是在为一个结构复杂的用户群服务，调度器只是工具，服务目标才是判断依据。
