做无线网络时间久了我越来越觉得 802.11ax 这块最值得聊的其实不是“又多快”而是“怎么能让这么多个设备在同一间屋子里都不打架”。很多人把 AX 路由器买回去图的是“Wi-Fi 6”那个标结果设备一多照样卡于是转头就骂厂商宣传夸大。实际上问题多半不在硬件而在于你有没有真正把“ax 调度”这几个字玩明白。所谓 ax 调度简单讲就是 802.11axWi-Fi 6/6E里的一套空口资源分配机制。在旧标准里无线信道本质上是一个“谁抢到谁用”的共享单车同一时刻只能一个人骑。ax 出现以后加入了 OFDMA、TWT、MU-MIMO 这些调度手段等于把一条路改成了可以分车道、分时段、甚至分“层”的立体交通。AP 就是路口红绿灯终端就是等着过马路的车流。调度做得好50 台设备同时开会、下载、刷视频都不乱调度没开或者参数不对哪怕信号满格延迟和丢包一样能把人逼疯。这篇文章我就围绕 ax 调度把原理、配置、抓包验证、踩坑经验一次性讲透。适合三类人看家里设备多到路由器扛不住的人、负责办公网和企业无线优化的工程师、以及想搞懂 Wi-Fi 6 宣传里“OFDMA”“TWT”到底是个啥的技术爱好者。1. ax 调度是什么从 Wi-Fi 5 的“抢车道”到 Wi-Fi 6 的“红绿灯路口”1.1 802.11ax 之前无线信道到底怎么分配的要理解 ax 调度得先回到 Wi-Fi 5802.11ac那套老玩法。Wi-Fi 5 用的是 OFDM 调制每个终端在某个时刻占用整个信道带宽。什么意思呢就好比一条双向两车道的窄路虽然路挺宽但规定“同一时间只能有一个人上路”。终端之间靠 CSMA/CA 机制互相监听先听信道是不是安静安静了才发数据发之前还要随机退避一段时间防止两台设备同时开口撞在一起。这套机制在终端少的时候没问题3、5 台设备没什么感知。一旦会议室里坐满 30 个人手机、笔记本、投屏器、无线打印机全挤在同一个 AP 下冲突概率暴增。每次冲突都要重传每次重传都会进一步增加信道占用然后引发更多冲突。我见过不少办公室的 Wi-Fi 连接数常年 60 以上空口利用率看着只有 30%但实际终端之间的互相等待已经占了另外 70% 的时间。这种环境下路由器标称的 1733Mbps、2167Mbps 根本没有任何参考价值因为物理层速率再高调度效率上不来空口时间全浪费在“排队和撞车”上了。所以 Wi-Fi 6 的研发重点并不是单纯提高单流速率而是要提高“多用户同时通信”的效率。ax 调度的核心思路就是不再让每个终端独占整个信道而是把信道拆成小份让多个终端在同一时刻同时收发。1.2 为什么 OFDMA 能被称为“调度”OFDMA正交频分多址是 ax 调度里最核心的一环。它把一个 20MHz 信道划分成若干个资源单元Resource Unit简称 RU每个 RU 由一定数量的子载波组成。AP 就像调度员根据每个终端的业务需求给不同设备分配不同的 RU。所有 RU 在频域上互不重叠所以可以同时传输。生活化的类比是以前 OFDM 是一条单行道一次只能过一辆车OFDMA 把单行道划成了多车道一辆车占一条道十条车道同时过十辆车。调度器要回答的问题就变成这一秒有 20 辆车要过哪辆走哪条道、给多宽的路、什么时候放行。这个分配动作在 802.11ax 协议里是通过触发帧Trigger Frame完成的。AP 发一帧里面写清楚“这些 STA 在哪些 RU 上、从什么时间开始、发多长时间”所有终端按指令行动。这里必须提一个容易被忽略的点下行 OFDMA 和上行 OFDMA 的难度完全不一样。下行是 AP 自己分配 RU不需要跟终端商量相对简单上行是终端向 AP 发送数据多个终端同时发必须在时间上精确同步。RTA 靠的就是触发帧的同步机制把分散的终端拉到同一个时间起点上。这也是为什么我实测发现不少老固件路由器虽然标着支持 OFDMA但默认只在“下行”开了 OFDMA上行调度并没有真正生效。你从手机往服务器传大文件时照样能感觉到明显延迟。1.3 调度的输入BSR 与 QoS 队列调度器不是瞎分配它必须知道终端到底有多少数据要发、业务优先级高不高。802.11ax 引入了 BSRBuffer Status Report缓冲状态上报终端会定期告诉 AP我缓存队列里还有多少数据。AP 收到后根据每个终端的缓存量、等待时间、业务类型动态调整 RU 的大小和数量。缓存多的设备多分一点资源缓存少的少分一点实时语音类的优先安排短时隙。同时调度器还要看 WMM 的四种接入类别语音AC_VO、视频AC_VI、尽力而为AC_BE、背景AC_BK。家庭路由器平时不太暴露这些队列但企业 AP 的管理后台里你可以看到每个 AC 队列的报文计数、丢弃数、平均时延。我发现很多人排查视频会议卡顿时盯着带宽看半天其实是 AP 调度器把语音和视频流量排在了队列尾部。把 QoS 映射配好、让 ax 调度器优先服务 AC_VO/AC_VI 队列比单纯换更大的宽带管用得多。2. ax 调度的三个核心部件RU、TWT、MU-MIMO 怎么配合2.1 RU把 20MHz 切成了多少份802.11ax 的 RU 有很多种尺寸。一个 20MHz 信道大约有 256 个子载波其中可用的有 242 个。RU 可以按子载波数量划分常见的有 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone 等。你可以这样记26-tone 大约 2MHz 宽适合低速率小包设备242-tone 基本就是整个 20MHz 信道适合大流量高速率设备。换到 80MHz 或 160MHz 带宽时RU 数量还会翻倍增长。这里有个常见的认知误区很多人以为 OFDMA 一定是“每个人分一小块窄频段”。实际上调度器很清楚给一个正在下载 4K 视频的终端只分 26-tone RU那就是灾难。所以 ax 调度是动态的低负载时一个终端可以独占 242-tone 甚至更大的 RU高负载时才把 RU 切小分给更多人。我在 AP 后台查看每个 STA 的 RU 分配历史时能清楚看到某台设备从独占 996-tone 忽然掉到 106-tone基本就是它周围又涌进来一批新设备。RU 切分还会影响调制方式的选择。RU 越小子载波间隔下的符号持续时间越长抗多径能力越好但总吞吐越低。调度器必须在“多服务几个设备”和“保证每个设备速率”之间找平衡。这也是为什么不同厂商的 ax 调度算法差距很大有的激进优先公平性有的保守宁可按需分配也不硬切。2.2 TWT睡眠时间表也是一种调度TWT目标唤醒时间常被宣传成“省电功能”但它本质上也是调度。终端和 AP 协商一个时间表约定好什么时候睡、什么时候醒。唤醒窗口一到终端才起来收广播、发数据其他时间在 AP 眼里就是“不存在”。对 AP 来说已知哪些终端会在哪些时隙醒着信道资源的规划就更容易避开干扰和争抢。TWT 分成两种Individual TWT 是每个设备单独约时间Broadcast TWT 是多个设备共享同一个唤醒窗口。Broadcast 特别适合 IoT 场景比如一堆传感器、插座、灯泡它们本身流量极小如果每个都频繁醒来抢信道只会白白消耗空口资源。把它们塞进同一个广播 TWT 里AP 只需要在一个窗口内集中服务完一批设备。但 TWT 有个副作用唤醒间隔调大了终端响应实时性就会变差。比如手机亮屏瞬间唤醒、然后立刻发一个微信语音消息如果刚好错过了 TWT 唤醒窗口就要等到下个周期体感上就是“转圈 0.5 秒”。家用路由器上这个参数通常不直接开放企业 AP 上会提供 TWT 间隔或者按 BSS 启用/停用的选项。我的建议是IoT 和低功耗设备多的场景该开就开但游戏机、手机、视频会议终端所在的 SSID别把它开得过狠。2.3 MU-MIMO空间流与 RU 的叠加调度Wi-Fi 5 也有 MU-MIMO但只支持下行而且和 OFDMA 是分开的。Wi-Fi 6 把 MU-MIMO 和 OFDMA 结合起来了AP 有 4 根天线可以在同一时间、同一频域资源上用四条空间流同时服务四台设备。空间流之间靠波束成形Beamforming来减少互相干扰而这需要终端反馈信道状态信息CSI。调度器拿到 CSI 后决定把哪些数据流放到哪些空间流上角度上尽量让它们“错开”。这就带来一个实际意义OFDMA 是频域上的并行MU-MIMO 是空间域上的并行两者叠加以后单位时间内的总并发能力大幅提升。我在 5GHz 80MHz 频段上实际测过一台 AP 同时服务 8 台 Wi-Fi 6 终端每台都在跑大流量时并发总吞吐比 4 台 Wi-Fi 5 终端跑到极限还高。MU-MIMO 对天线位置和方向有要求终端离 AP 太远、角度太偏CSI 反馈质量下降空间流的正交性变差调度器也会主动降低 MU-MIMO 的使用频率。3. 落地实操把 ax 调度从参数配到效果验证3.1 先看你的环境和设备支不支持做任何调优之前先确认两件事AP 本身支持完整的 802.11ax 特性终端设备也要支持 Wi-Fi 6。只有一边支持是不行的。我用 Linux 无线工具可以直接在驱动层看到不少信息比如在终端上执行iw dev wlan0 info iw dev wlan0 survey dump iw dev wlan0 station dumpiw dev wlan0 info能看到当前信道、带宽、频段是否 5GHzsurvey dump可以看到信道活跃时间和忙时比例大致判断空口紧不紧张station dump能看到连上的终端信号强度、RX/TX 速率、丢包统计。如果你的网卡和驱动不支持这些接口说明设备或驱动太老ax 调度再强也轮不到你用。在 AP 侧家用路由器通常只在 Wi-Fi 设置里露出 OFDMA 开关、MU-MIMO 开关、TWT 开关。企业 AP 的后台更细一些能看到每 radio 的 OFDMA 使能状态、上行 OFDMA 开关、MU-MIMO 模式、TWT 广播周期等。调优前务必把固件、驱动版本升到最新ax 调度这块后期优化非常依赖软件老固件很可能只是在支持列表里打了个勾实际调度器逻辑早就有了 bug 或者缺了上行调度。3.2 AP 参数怎么配从 OFDMA 到 TWT 的一组合适参数以下是我在常见企业 AP 后台和部分家用路由器上调整的一组经验值按场景取舍不同品牌参数名略有差异但思路通用。参数推荐值说明OFDMA开启尽量同时开启上行和下行上行 OFDMA 别忽略它是多终端同时发数据的关键MU-MIMO开启配合 OFDMA 使用不跟 OFDMA 互斥TWT默认开启高实时性业务可关闭低功耗 IoT 多就开广播 TWT视频会议敏感就调大唤醒频率信道带宽80MHz 起步优先不选 160MHz160MHz 干扰源多、DFS 雷达规避多稳定性优先信号阈值OFDMA 不分配给低于 -65dBm 的终端弱信号终端占用 RU 效率极低浪费调度资源BSS Coloring开启减少同频多 AP 互踩提升空间复用效率短帧间隔 / A-MSDU跟随默认这些影响帧聚合效率不属于调度单独调的参数这里面最值得解释的是信号阈值。isaac 不是所有终端都值得调度器给一个 RU。有些终端在墙角、桌下信号 -70dBm 以下物理层速率已经掉到几十 Mbps。给这样的终端分配 242-tone 大 RU等于把一条高架快车道让给一辆三轮车慢慢开其他终端全部陪跑。我在实际项目中遇到的“一个会议室被某台老笔记本电脑拖垮全场”的案例多半就是这类情况。把弱信号终端引导到 RSSI 更好的频段或者干脆限制它的连接速率能明显缓解 OFDMA 资源被低效占用的问题。3.3 业务队列与空口公平性为什么视频卡顿但下载飞快别光调 OFDMA 和 TWT业务优先级同样影响调度结果。WMM 的四类队列在 802.11ax 里依然是调度器分配 RU 的重要参考。语音和视频队列里的帧时延要求高、报文通常不会太大下载队列里的帧对时延不敏感但要求吞吐高。调度器根据队列优先级决定给哪些终端先发、发多少这就是 QoS 调度的含义。我做过一次印象很深的现场调优一家公司 40 人的 office白天视频会议频繁但奇怪的是下载大文件挺快视频却一卡一卡。后台看空口统计下载类流量占了 80% 以上语音队列的包被排在了下载队列后面。后来把 AC_VO/AC_VI 队列的映射重新核对让调度器优先处理语音视频再把 TWT 的唤醒间隔调短视频会议立刻恢复正常。这次过程中我没有动任何带宽参数纯粹就是让 ax 调度器“知道该先给谁服务”。3.4 用抓包和空口统计验证调度效果参数配置是不是生效不能只看后台开关最好用抓包验证。我用 Wireshark 抓 802.11 报文时会先确认抓到的关联设备支持 HEHigh Efficiency能力。看 Beacon 帧里的 HE Capabilities 和 HE Operation 信息元素里面会带 OFDMA、MU-MIMO 相关的能力位。真正发生 OFDMA 上行传输时能看到 AP 下发的 Trigger 帧并且随后多个终端的上行数据帧紧跟在一起到达。如果你抓到的报文中还是一个个单独立即确认的普通数据帧那基本可以断定 OFDMA 调度没有实际发生。在 Linux 网卡上还可以通过iw dev wlan0 station dump查看每个终端的 RX/TX 字节和帧数。重点观察开启 OFDMA 之后整体空口利用率有没有下降、单位时间内完成的帧数有没有增加。我自己的记录里一次会议室从 Wi-Fi 5 升级到 Wi-Fi 6 并开启 ax 调度后同样业务量下信道忙时占比从 42% 降到 25%体感是“同样的时间做完了更多的事”。4. 常见问题与避坑清单4.1 老终端拖后腿最容易被忽略的问题是ax 调度再好团队里只要有一台 802.11n 老设备它就无法参与 OFDMA。老终端必须用传统帧格式收发AP 为了兼容它经常要降低整个信道的传输效率或者发送特殊前导码来保护老终端的时间片。原本 80MHz 信道上可以同时给 8 个 Wi-Fi 6 终端分配 RU现在因为一个老设备的接入整个传输周期被拉长调度效率直线下降。解决思路就是给老终端单独划一个 SSID或者把它们全部赶到 2.4GHz尽量让 5GHz 频段全部由 Wi-Fi 6 终端占用。有条件的话 apt 直接建议更新那些使用年限超过 8 年的笔记本网卡和手机。很多情况下换一个 100 块钱的 Wi-Fi 6 网卡比调三天 AP 参数有效得多。4.2 OFDMA 和弱信号打架OFDMA 对信噪比的要求并不比 OFDM 低甚至更敏感。RU 切得越小每个 RU 能用于纠错的冗余越少弱信号环境下误码率会快速上升。AP 调度器如果硬把一个 26-tone RU 分配给远距离终端结果就是频繁重传反而比让这个终端独占信道慢。这是 OFDMA 最容易被吐槽的“伪增益”场景之一。我的经验是信号低于 -65dBm 左右就不要指望 OFDMA 带来多少并发收益。在这个区域宁可让终端回到传统传输模式或增强 AP 覆盖、加一个 AP 补盲。很多商用 AP 的后台里有“OFDMA 最低 RSSI 门限”一类的高级设置没有的话也可以通过 CLI 或者 Tune 脚本去限制低速率终端的 RU 分配优先级。4.3 TWT 引发延迟抖动TWT 和低延迟之间存在天然的矛盾。唤醒周期越长终端越省电但每次要通信时赶不上窗口的概率就越大。手机息屏状态下的消息收发、智能家居的偶发上报都还好但游戏手柄、无线投屏这类高交互设备如果 TWT 周期设得太大方向键按下去到屏幕有反应可能要等一个窗口周期用户体感就是延迟忽高忽低。所以遇到延迟类投诉除了看无线干扰一定要把 TWT 相关的配置列为排查项。先把 TWT 关闭对比延迟表现如果延迟明显正常再考虑对特定业务开启 TWT或调短唤醒间隔。切忌所有设备一把抓全开 TWT 省电并不适合高实时性场景。4.4 家用路由器 / 企业 AP 参数速查表场景建议配置要避开的坑家庭全屋 20 终端开 OFDMA 和 MU-MIMOTWT 开广播模式160MHz 可能反而因干扰导致速率下降办公 30 终端重度会议开上行 OFDMAQoS 优先 AC_VO/AC_VI别忽略上行调度别让老设备占 5GHzIoT 与 Wi-Fi 6 混合单独给 IoT 开 TWT 广播限制其带宽别指望一个 SSID 承载所有类型设备直播/游戏低延迟关 TWT 或调短唤醒间隔开 QoS默认 OFDMA 激进公平策略不适合低延迟业务最后再分享一个小技巧ax 调度不是“开了就完”的静态配置。我在同一天的不同时段测过同一台 AP早上没有多少终端时反而关闭 OFDMA 延迟更低因为调度器分配和通知的开销有时比冲突规避还大。终端数量超过 15 台之后OFDMA 的收益才真正体现出来。所以你可以先按上面的表配置然后在不同负载下观察空口统计和延迟数据找到自己环境的最优平衡点。无线调优从来不是一步到位的ax 调度给足了手段但怎么用还得靠现场数据说话。
802.11ax调度详解：OFDMA、TWT与MU-MIMO协同优化Wi-Fi 6
做无线网络时间久了我越来越觉得 802.11ax 这块最值得聊的其实不是“又多快”而是“怎么能让这么多个设备在同一间屋子里都不打架”。很多人把 AX 路由器买回去图的是“Wi-Fi 6”那个标结果设备一多照样卡于是转头就骂厂商宣传夸大。实际上问题多半不在硬件而在于你有没有真正把“ax 调度”这几个字玩明白。所谓 ax 调度简单讲就是 802.11axWi-Fi 6/6E里的一套空口资源分配机制。在旧标准里无线信道本质上是一个“谁抢到谁用”的共享单车同一时刻只能一个人骑。ax 出现以后加入了 OFDMA、TWT、MU-MIMO 这些调度手段等于把一条路改成了可以分车道、分时段、甚至分“层”的立体交通。AP 就是路口红绿灯终端就是等着过马路的车流。调度做得好50 台设备同时开会、下载、刷视频都不乱调度没开或者参数不对哪怕信号满格延迟和丢包一样能把人逼疯。这篇文章我就围绕 ax 调度把原理、配置、抓包验证、踩坑经验一次性讲透。适合三类人看家里设备多到路由器扛不住的人、负责办公网和企业无线优化的工程师、以及想搞懂 Wi-Fi 6 宣传里“OFDMA”“TWT”到底是个啥的技术爱好者。1. ax 调度是什么从 Wi-Fi 5 的“抢车道”到 Wi-Fi 6 的“红绿灯路口”1.1 802.11ax 之前无线信道到底怎么分配的要理解 ax 调度得先回到 Wi-Fi 5802.11ac那套老玩法。Wi-Fi 5 用的是 OFDM 调制每个终端在某个时刻占用整个信道带宽。什么意思呢就好比一条双向两车道的窄路虽然路挺宽但规定“同一时间只能有一个人上路”。终端之间靠 CSMA/CA 机制互相监听先听信道是不是安静安静了才发数据发之前还要随机退避一段时间防止两台设备同时开口撞在一起。这套机制在终端少的时候没问题3、5 台设备没什么感知。一旦会议室里坐满 30 个人手机、笔记本、投屏器、无线打印机全挤在同一个 AP 下冲突概率暴增。每次冲突都要重传每次重传都会进一步增加信道占用然后引发更多冲突。我见过不少办公室的 Wi-Fi 连接数常年 60 以上空口利用率看着只有 30%但实际终端之间的互相等待已经占了另外 70% 的时间。这种环境下路由器标称的 1733Mbps、2167Mbps 根本没有任何参考价值因为物理层速率再高调度效率上不来空口时间全浪费在“排队和撞车”上了。所以 Wi-Fi 6 的研发重点并不是单纯提高单流速率而是要提高“多用户同时通信”的效率。ax 调度的核心思路就是不再让每个终端独占整个信道而是把信道拆成小份让多个终端在同一时刻同时收发。1.2 为什么 OFDMA 能被称为“调度”OFDMA正交频分多址是 ax 调度里最核心的一环。它把一个 20MHz 信道划分成若干个资源单元Resource Unit简称 RU每个 RU 由一定数量的子载波组成。AP 就像调度员根据每个终端的业务需求给不同设备分配不同的 RU。所有 RU 在频域上互不重叠所以可以同时传输。生活化的类比是以前 OFDM 是一条单行道一次只能过一辆车OFDMA 把单行道划成了多车道一辆车占一条道十条车道同时过十辆车。调度器要回答的问题就变成这一秒有 20 辆车要过哪辆走哪条道、给多宽的路、什么时候放行。这个分配动作在 802.11ax 协议里是通过触发帧Trigger Frame完成的。AP 发一帧里面写清楚“这些 STA 在哪些 RU 上、从什么时间开始、发多长时间”所有终端按指令行动。这里必须提一个容易被忽略的点下行 OFDMA 和上行 OFDMA 的难度完全不一样。下行是 AP 自己分配 RU不需要跟终端商量相对简单上行是终端向 AP 发送数据多个终端同时发必须在时间上精确同步。RTA 靠的就是触发帧的同步机制把分散的终端拉到同一个时间起点上。这也是为什么我实测发现不少老固件路由器虽然标着支持 OFDMA但默认只在“下行”开了 OFDMA上行调度并没有真正生效。你从手机往服务器传大文件时照样能感觉到明显延迟。1.3 调度的输入BSR 与 QoS 队列调度器不是瞎分配它必须知道终端到底有多少数据要发、业务优先级高不高。802.11ax 引入了 BSRBuffer Status Report缓冲状态上报终端会定期告诉 AP我缓存队列里还有多少数据。AP 收到后根据每个终端的缓存量、等待时间、业务类型动态调整 RU 的大小和数量。缓存多的设备多分一点资源缓存少的少分一点实时语音类的优先安排短时隙。同时调度器还要看 WMM 的四种接入类别语音AC_VO、视频AC_VI、尽力而为AC_BE、背景AC_BK。家庭路由器平时不太暴露这些队列但企业 AP 的管理后台里你可以看到每个 AC 队列的报文计数、丢弃数、平均时延。我发现很多人排查视频会议卡顿时盯着带宽看半天其实是 AP 调度器把语音和视频流量排在了队列尾部。把 QoS 映射配好、让 ax 调度器优先服务 AC_VO/AC_VI 队列比单纯换更大的宽带管用得多。2. ax 调度的三个核心部件RU、TWT、MU-MIMO 怎么配合2.1 RU把 20MHz 切成了多少份802.11ax 的 RU 有很多种尺寸。一个 20MHz 信道大约有 256 个子载波其中可用的有 242 个。RU 可以按子载波数量划分常见的有 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone 等。你可以这样记26-tone 大约 2MHz 宽适合低速率小包设备242-tone 基本就是整个 20MHz 信道适合大流量高速率设备。换到 80MHz 或 160MHz 带宽时RU 数量还会翻倍增长。这里有个常见的认知误区很多人以为 OFDMA 一定是“每个人分一小块窄频段”。实际上调度器很清楚给一个正在下载 4K 视频的终端只分 26-tone RU那就是灾难。所以 ax 调度是动态的低负载时一个终端可以独占 242-tone 甚至更大的 RU高负载时才把 RU 切小分给更多人。我在 AP 后台查看每个 STA 的 RU 分配历史时能清楚看到某台设备从独占 996-tone 忽然掉到 106-tone基本就是它周围又涌进来一批新设备。RU 切分还会影响调制方式的选择。RU 越小子载波间隔下的符号持续时间越长抗多径能力越好但总吞吐越低。调度器必须在“多服务几个设备”和“保证每个设备速率”之间找平衡。这也是为什么不同厂商的 ax 调度算法差距很大有的激进优先公平性有的保守宁可按需分配也不硬切。2.2 TWT睡眠时间表也是一种调度TWT目标唤醒时间常被宣传成“省电功能”但它本质上也是调度。终端和 AP 协商一个时间表约定好什么时候睡、什么时候醒。唤醒窗口一到终端才起来收广播、发数据其他时间在 AP 眼里就是“不存在”。对 AP 来说已知哪些终端会在哪些时隙醒着信道资源的规划就更容易避开干扰和争抢。TWT 分成两种Individual TWT 是每个设备单独约时间Broadcast TWT 是多个设备共享同一个唤醒窗口。Broadcast 特别适合 IoT 场景比如一堆传感器、插座、灯泡它们本身流量极小如果每个都频繁醒来抢信道只会白白消耗空口资源。把它们塞进同一个广播 TWT 里AP 只需要在一个窗口内集中服务完一批设备。但 TWT 有个副作用唤醒间隔调大了终端响应实时性就会变差。比如手机亮屏瞬间唤醒、然后立刻发一个微信语音消息如果刚好错过了 TWT 唤醒窗口就要等到下个周期体感上就是“转圈 0.5 秒”。家用路由器上这个参数通常不直接开放企业 AP 上会提供 TWT 间隔或者按 BSS 启用/停用的选项。我的建议是IoT 和低功耗设备多的场景该开就开但游戏机、手机、视频会议终端所在的 SSID别把它开得过狠。2.3 MU-MIMO空间流与 RU 的叠加调度Wi-Fi 5 也有 MU-MIMO但只支持下行而且和 OFDMA 是分开的。Wi-Fi 6 把 MU-MIMO 和 OFDMA 结合起来了AP 有 4 根天线可以在同一时间、同一频域资源上用四条空间流同时服务四台设备。空间流之间靠波束成形Beamforming来减少互相干扰而这需要终端反馈信道状态信息CSI。调度器拿到 CSI 后决定把哪些数据流放到哪些空间流上角度上尽量让它们“错开”。这就带来一个实际意义OFDMA 是频域上的并行MU-MIMO 是空间域上的并行两者叠加以后单位时间内的总并发能力大幅提升。我在 5GHz 80MHz 频段上实际测过一台 AP 同时服务 8 台 Wi-Fi 6 终端每台都在跑大流量时并发总吞吐比 4 台 Wi-Fi 5 终端跑到极限还高。MU-MIMO 对天线位置和方向有要求终端离 AP 太远、角度太偏CSI 反馈质量下降空间流的正交性变差调度器也会主动降低 MU-MIMO 的使用频率。3. 落地实操把 ax 调度从参数配到效果验证3.1 先看你的环境和设备支不支持做任何调优之前先确认两件事AP 本身支持完整的 802.11ax 特性终端设备也要支持 Wi-Fi 6。只有一边支持是不行的。我用 Linux 无线工具可以直接在驱动层看到不少信息比如在终端上执行iw dev wlan0 info iw dev wlan0 survey dump iw dev wlan0 station dumpiw dev wlan0 info能看到当前信道、带宽、频段是否 5GHzsurvey dump可以看到信道活跃时间和忙时比例大致判断空口紧不紧张station dump能看到连上的终端信号强度、RX/TX 速率、丢包统计。如果你的网卡和驱动不支持这些接口说明设备或驱动太老ax 调度再强也轮不到你用。在 AP 侧家用路由器通常只在 Wi-Fi 设置里露出 OFDMA 开关、MU-MIMO 开关、TWT 开关。企业 AP 的后台更细一些能看到每 radio 的 OFDMA 使能状态、上行 OFDMA 开关、MU-MIMO 模式、TWT 广播周期等。调优前务必把固件、驱动版本升到最新ax 调度这块后期优化非常依赖软件老固件很可能只是在支持列表里打了个勾实际调度器逻辑早就有了 bug 或者缺了上行调度。3.2 AP 参数怎么配从 OFDMA 到 TWT 的一组合适参数以下是我在常见企业 AP 后台和部分家用路由器上调整的一组经验值按场景取舍不同品牌参数名略有差异但思路通用。参数推荐值说明OFDMA开启尽量同时开启上行和下行上行 OFDMA 别忽略它是多终端同时发数据的关键MU-MIMO开启配合 OFDMA 使用不跟 OFDMA 互斥TWT默认开启高实时性业务可关闭低功耗 IoT 多就开广播 TWT视频会议敏感就调大唤醒频率信道带宽80MHz 起步优先不选 160MHz160MHz 干扰源多、DFS 雷达规避多稳定性优先信号阈值OFDMA 不分配给低于 -65dBm 的终端弱信号终端占用 RU 效率极低浪费调度资源BSS Coloring开启减少同频多 AP 互踩提升空间复用效率短帧间隔 / A-MSDU跟随默认这些影响帧聚合效率不属于调度单独调的参数这里面最值得解释的是信号阈值。isaac 不是所有终端都值得调度器给一个 RU。有些终端在墙角、桌下信号 -70dBm 以下物理层速率已经掉到几十 Mbps。给这样的终端分配 242-tone 大 RU等于把一条高架快车道让给一辆三轮车慢慢开其他终端全部陪跑。我在实际项目中遇到的“一个会议室被某台老笔记本电脑拖垮全场”的案例多半就是这类情况。把弱信号终端引导到 RSSI 更好的频段或者干脆限制它的连接速率能明显缓解 OFDMA 资源被低效占用的问题。3.3 业务队列与空口公平性为什么视频卡顿但下载飞快别光调 OFDMA 和 TWT业务优先级同样影响调度结果。WMM 的四类队列在 802.11ax 里依然是调度器分配 RU 的重要参考。语音和视频队列里的帧时延要求高、报文通常不会太大下载队列里的帧对时延不敏感但要求吞吐高。调度器根据队列优先级决定给哪些终端先发、发多少这就是 QoS 调度的含义。我做过一次印象很深的现场调优一家公司 40 人的 office白天视频会议频繁但奇怪的是下载大文件挺快视频却一卡一卡。后台看空口统计下载类流量占了 80% 以上语音队列的包被排在了下载队列后面。后来把 AC_VO/AC_VI 队列的映射重新核对让调度器优先处理语音视频再把 TWT 的唤醒间隔调短视频会议立刻恢复正常。这次过程中我没有动任何带宽参数纯粹就是让 ax 调度器“知道该先给谁服务”。3.4 用抓包和空口统计验证调度效果参数配置是不是生效不能只看后台开关最好用抓包验证。我用 Wireshark 抓 802.11 报文时会先确认抓到的关联设备支持 HEHigh Efficiency能力。看 Beacon 帧里的 HE Capabilities 和 HE Operation 信息元素里面会带 OFDMA、MU-MIMO 相关的能力位。真正发生 OFDMA 上行传输时能看到 AP 下发的 Trigger 帧并且随后多个终端的上行数据帧紧跟在一起到达。如果你抓到的报文中还是一个个单独立即确认的普通数据帧那基本可以断定 OFDMA 调度没有实际发生。在 Linux 网卡上还可以通过iw dev wlan0 station dump查看每个终端的 RX/TX 字节和帧数。重点观察开启 OFDMA 之后整体空口利用率有没有下降、单位时间内完成的帧数有没有增加。我自己的记录里一次会议室从 Wi-Fi 5 升级到 Wi-Fi 6 并开启 ax 调度后同样业务量下信道忙时占比从 42% 降到 25%体感是“同样的时间做完了更多的事”。4. 常见问题与避坑清单4.1 老终端拖后腿最容易被忽略的问题是ax 调度再好团队里只要有一台 802.11n 老设备它就无法参与 OFDMA。老终端必须用传统帧格式收发AP 为了兼容它经常要降低整个信道的传输效率或者发送特殊前导码来保护老终端的时间片。原本 80MHz 信道上可以同时给 8 个 Wi-Fi 6 终端分配 RU现在因为一个老设备的接入整个传输周期被拉长调度效率直线下降。解决思路就是给老终端单独划一个 SSID或者把它们全部赶到 2.4GHz尽量让 5GHz 频段全部由 Wi-Fi 6 终端占用。有条件的话 apt 直接建议更新那些使用年限超过 8 年的笔记本网卡和手机。很多情况下换一个 100 块钱的 Wi-Fi 6 网卡比调三天 AP 参数有效得多。4.2 OFDMA 和弱信号打架OFDMA 对信噪比的要求并不比 OFDM 低甚至更敏感。RU 切得越小每个 RU 能用于纠错的冗余越少弱信号环境下误码率会快速上升。AP 调度器如果硬把一个 26-tone RU 分配给远距离终端结果就是频繁重传反而比让这个终端独占信道慢。这是 OFDMA 最容易被吐槽的“伪增益”场景之一。我的经验是信号低于 -65dBm 左右就不要指望 OFDMA 带来多少并发收益。在这个区域宁可让终端回到传统传输模式或增强 AP 覆盖、加一个 AP 补盲。很多商用 AP 的后台里有“OFDMA 最低 RSSI 门限”一类的高级设置没有的话也可以通过 CLI 或者 Tune 脚本去限制低速率终端的 RU 分配优先级。4.3 TWT 引发延迟抖动TWT 和低延迟之间存在天然的矛盾。唤醒周期越长终端越省电但每次要通信时赶不上窗口的概率就越大。手机息屏状态下的消息收发、智能家居的偶发上报都还好但游戏手柄、无线投屏这类高交互设备如果 TWT 周期设得太大方向键按下去到屏幕有反应可能要等一个窗口周期用户体感就是延迟忽高忽低。所以遇到延迟类投诉除了看无线干扰一定要把 TWT 相关的配置列为排查项。先把 TWT 关闭对比延迟表现如果延迟明显正常再考虑对特定业务开启 TWT或调短唤醒间隔。切忌所有设备一把抓全开 TWT 省电并不适合高实时性场景。4.4 家用路由器 / 企业 AP 参数速查表场景建议配置要避开的坑家庭全屋 20 终端开 OFDMA 和 MU-MIMOTWT 开广播模式160MHz 可能反而因干扰导致速率下降办公 30 终端重度会议开上行 OFDMAQoS 优先 AC_VO/AC_VI别忽略上行调度别让老设备占 5GHzIoT 与 Wi-Fi 6 混合单独给 IoT 开 TWT 广播限制其带宽别指望一个 SSID 承载所有类型设备直播/游戏低延迟关 TWT 或调短唤醒间隔开 QoS默认 OFDMA 激进公平策略不适合低延迟业务最后再分享一个小技巧ax 调度不是“开了就完”的静态配置。我在同一天的不同时段测过同一台 AP早上没有多少终端时反而关闭 OFDMA 延迟更低因为调度器分配和通知的开销有时比冲突规避还大。终端数量超过 15 台之后OFDMA 的收益才真正体现出来。所以你可以先按上面的表配置然后在不同负载下观察空口统计和延迟数据找到自己环境的最优平衡点。无线调优从来不是一步到位的ax 调度给足了手段但怎么用还得靠现场数据说话。
