ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Ax调度深度解析:从802.11ax协议原理到Wi-Fi 6排障实践

Ax调度深度解析:从802.11ax协议原理到Wi-Fi 6排障实践 你说的“ax调度”如果放到无线网络圈子里第一反应就是 802.11ax也就是大家更熟悉的 Wi-Fi 6。我最初接触这个词是在一次办公室无线网络改造的项目里——明明终端都支持 Wi-Fi 6路由器也换了支持 802.11ax 的企业级 AP可一到中午人多的时候视频会议照样卡顿延迟忽高忽低。当时我一度怀疑是运营商出口带宽的问题直到我把抓包文件翻了个底朝天才意识到真正的问题出在“调度”这两个字上802.11ax 引入了 OFDMA、MU-MIMO、TWT 等一系列资源调度机制但不是说设备支持就万事大吉AP 端的调度算法、终端的上报行为、固件里默认开启的开关每一项都在影响最终体验。这篇文章就是想把“ax 调度”这件事彻底讲透从协议原理到实际排障适合正在做无线网络优化、或者对 Wi-Fi 6 路由器选购有兴趣的朋友参考。1. “ax”到底是谁从命名混乱说起1.1 为什么老网工习惯叫 802.11ax厂商却叫 Wi-Fi 6搞无线网络久了的人基本都经历过那段“命名混乱期”。早期标准叫 802.11a/b/g/n/ac工程师之间讨论问题靠协议编号区分比如“你那个 AP 是不是 802.11ac 的”大家一听就懂。但普通用户根本分不清 ac 和 ax 有什么区别厂商也觉得这编号太不亲民于是 Wi-Fi 联盟推出了面向大众的命名方式802.11n 对应 Wi-Fi 4802.11ac 对应 Wi-Fi 5802.11ax 对应 Wi-Fi 6。所以当你看到“ax”这个词时它不一定指代某个具体设备更多时候是 802.11ax 这个协议代次。而“ax 调度”这个热词准确讲的是 802.11ax 为了解决多用户并发场景而引入的那一整套资源分配机制。行业内聊起来经常简写成“OFDMA 调度”“MU-MIMO 调度”或者直接说“ax 的调度机制”。1.2 ax 要解决的核心问题密集场景下的多终端并发在 802.11ac 时代一个 AP 在同一时刻只能和一个终端完成数据传输也就是说信道资源是“时分复用”的。哪怕路由器有 4x4 MIMO能同时向 4 个终端发数据但这是基于空间流的并行前提是每个终端都支持 MU-MIMO 且天线数匹配。而现实情况是会议室里 20 台手机、平板、笔记本大部分只有 1-2 根天线很多终端甚至不支持 MU-MIMO结果就是 AP 必须排队逐个服务信道利用率很低。802.11ax 的思路就是把“排队过独木桥”改成“多车道并行”。一方面继续强化 MU-MIMO另一方面引入了 OFDMA 技术从频率维度把信道切成更小的资源块分给不同终端同时使用。再配合 TWT目标唤醒时间和 BSS Coloring让整个无线网络在高密度场景下也能保持较低延迟和较高吞吐。这正是“调度”二字的含义所在AP 像交通调度中心一样决定谁在什么时间、什么频率资源上发送数据。协议频段最大带宽多用户技术调制方式802.11n2.4GHz/5GHz40MHz无标准 MU64-QAM802.11ac5GHz160MHzDL MU-MIMO256-QAM802.11ax2.4GHz/5GHz/6GHz160MHzDL/UL OFDMA MU-MIMO1024-QAM从这张表可以直观看出802.11ax 和前两代的关键差异不在峰值速率而在“多用户并发能力”。峰值速率提升只是把 256-QAM 换成了 1024-QAM撑死了提升 30% 上下但 OFDMA 和上下行 MU-MIMO 带来的并发效率提升在高密度场景下是数量级的差别。2. OFDMA 调度ax 里最值钱的那个技术2.1 用“拼桌吃饭”来理解 OFDMA 和 OFDM 的区别传统 OFDM 的做法就像一个餐厅里只有一张大桌每次只接待一桌客人哪怕这桌只有一个人整张桌子也是他的其他人只能排队等。这个“一个人占一整张桌子”的效率问题在多人同时用网时非常致命。OFDMA 的做法是把这张大桌切分成若干小区域每个区域RUResource Unit资源单元可以分配给不同的客人。比如 80MHz 带宽的信道可以切出 9 个 26-tone 大小的 RU同时服务 9 个低速率需求的终端。AP 就是这个餐厅的调度员它根据每个终端的流量需求、缓存数据量、信道质量决定把哪些 RU 分给谁、用多宽的 RU、持续多长时间。2.2 RU 是怎么划分的子载波分组逻辑这里有一个容易被忽略的细节802.11ax 的 RU 大小不是随意切分的最小单位是 26-tone RU。一个 tone 就是一条子载波26-tone RU 里实际包含 24 个数据子载波和 2 个导频子载波。更大的 RU 包括 52-tone、106-tone、242-tone、484-tone、996-tone以及 160MHz 下的 2x996-tone。不同大小的 RU 不仅影响能容纳的用户数还直接影响单用户能达到的最大速率。比如 26-tone RU 因为可用子载波太少很多高阶调制方式如 1024-QAM根本没法用所以在 OFDMA 调度的实际表现中AP 往往会尽量分配 106-tone 或更大的 RU 给高吞吐需求的终端。带宽RU 划分可能组合用户数适用场景20MHz9 个 26-tone RU或 4 个 52-tone RU或 2 个 106-tone RU或 1 个 242-tone RU单人高带宽 vs 多人低并发40MHz18 个 26-tone RU或 8 个 52-tone RU或 4 个 106-tone RU或 2 个 242-tone RU中型房间多终端80MHz37 个 26-tone RU或 16 个 52-tone RU或 8 个 106-tone RU或 4 个 242-tone RU或 2 个 484-tone RU或 1 个 996-tone RU大型办公区160MHz74 个 26-tone RU或 32 个 52-tone RU或 16 个 106-tone RU或 8 个 242-tone RU或 4 个 484-tone RU或 2 个 996-tone RU高吞吐密集场景这里要提醒一点这张表是理论上的最大组合方式实际调度中 AP 还要考虑每个终端的信道质量、业务优先级、Buffer 状态所以不可能每次都按最大化用户数来切分。我在实测中发现很多 AP 在终端数量少于 5 个时宁愿分配更大的 RU 给单个终端也不愿意把信道切得太碎因为切得太碎会让单用户的速率明显下降。2.3 下行 OFDMAAP 说了算的调度下行 OFDMA 相对简单因为 AP 是发送方它天然掌握所有终端的缓存数据量。AP 会周期性地为每个终端评估流量需求然后在一个下行 PPDU物理层协议数据单元里把不同 RU 分配给不同终端一次性发出去。这个过程中调度器要解决的是“RU 分配比例”问题。比如关联的终端 A 正在看高清视频终端 B 只是偶尔发个心跳包那么调度器分配给 A 的资源就应该是 B 的几十倍。802.11ax 协议本身没有规定具体的调度算法这部分是由芯片厂商自己实现的所以不同品牌 AP 在相同环境下的 OFDMA 效率可能差异很大。这也是为什么拿着同样支持 Wi-Fi 6 的路由器实测吞吐却可能差出一倍的原因。2.4 上行 OFDMA需要终端配合的“复杂调度”上行 OFDMA 就复杂多了。AP 虽然是调度中心但它并不知道每个终端的上行队列里有多少数据。如果让所有终端自由竞争发送OFDMA 就无从谈起。所以协议设计了“AP 主动触发终端被动响应”的机制AP 发送 Trigger 帧里面包含 RU 分配信息和各终端的发送参数收到 Trigger 的终端才在指定的资源上发送自己的数据。这个机制具体到抓包里的样子是你能看到 AP 周期性发出 Trigger 帧指向多个终端地址随后这些终端在对应的 RU 上分别回应。如果你在 Wireshark 里看不到 Trigger 帧或者看到大量终端在非 OFDMA 方式下竞争发送那就说明这个 AP 的调度效率不高。3. 上行调度链路拆解Trigger、BSR 与缓存状态3.1 BSR 是如何“告诉”AP 我该吃多少的上行 OFDMA 调度中有一个非常关键的角色叫 BSRBuffer Status Report缓存状态报告。终端通过在特定 MAC 控制帧里携带自己上行缓冲区的数据量信息告诉 AP我这里有大约 X 字节的数据要发。AP 收到所有终端的 BSR 后再综合信道状况和业务优先级计算出各终端的 RU 分配方案。这里涉及一个细节BSR 不是终端随时上报的而是 AP 在需要时用 BSRPBuffer Status Report Poll触发帧来“询问”。所以在无线抓包里你经常能看到 AP 先发 BSRP然后各终端在短帧间间隔里回复各自的上行数据长度紧接着 AP 发出携带 RU 分配的 Trigger 帧整个调度流程就像一个“点名问答—按号分配—同时发送”的循环。3.2 一次完整上行 OFDMA 调度的实际交互为了让你更直观地理解这条链路我把它拆成四个步骤这也是我在排查无线问题时最喜欢画给同事看的过程AP 定期发送 BSRP 触发帧点名询问关联终端的缓存状态。各终端收到 BSRP 后在各自被分配的上行资源或竞争窗口内回复 BSR报告自己的上行数据量。AP 根据 BSR、RSSI 和信道质量表决定 RU 大小和位置生成 Trigger 帧并广播。被点名的终端收到 Trigger 帧后直接在指定的 RU 上同时发送上行数据不需要再走 CSMA/CA 竞争。你在抓包里看到的现象就是BSRP 之后跟着一连串紧凑的 QoS Null 或 Data 帧这些帧的大小不均匀因为每个终端的数据量不同。如果某个终端始终不回 BSR那它大概率就是一台“调度不配合”的老旧设备AP 只能退而求其次给它分配传统竞争资源。3.3 为什么有些终端连上了 802.11ax 却不快这是我在实际项目里踩过最深的坑。很多用户换了大几千的路由器手机也显示 Wi-Fi 6 图标但速度就是跑不上去。用抓包一看问题出在两个地方第一终端虽然支持 802.11ax但没有实现 BSR 上报功能或者驱动里默认关闭了这个能力。这类终端在上行 OFDMA 调度里只会被动等 AP 分配但 AP 缺少它的缓存信息只能按保守策略分配资源效率大打折扣。第二很多终端的省电策略会主动关闭 OFDMA 参与资格。安卓和 iOS 系统都有一套“低功耗模式”在不活跃时会让 Wi-Fi 芯片进入深度睡眠这时候 AP 的调度中心根本没法把资源分给它。所以如果你发现某个 Wi-Fi 6 终端速度异常不要急着骂路由器。可以先在电脑上用 Wireshark 抓一下信令看看 BSRP 之后有没有这个终端的响应如果没有尝试关闭终端的省电模式或者更新无线网卡驱动很多时候问题就解决了。4. MU-MIMO 与 OFDMA 的协同一套组合调度逻辑4.1 一个管空间一个管频率OFDMA 解决的是频率维度的复用MU-MIMO 解决的是空间维度的复用。两者不冲突可以叠加。AP 在一个 PPDU 里既能混合不同终端的 RU又能让多个终端同时使用不同空间流这被称 OFDMA MU-MIMO 联合调度。打个比方商场里的餐饮区既有多家不同店铺频率上的 OFDMA每家店里又有多个座位空间上的 MU-MIMO。调度中心要做的是让尽可能多的人在同一时刻坐下来吃饭而不是让整层楼只有一个人坐在一张大桌上。4.2 联合调度的实际限制端口数、天线与协议版本但联合调度不是没有代价。芯片的基带处理能力有限多用户帧的调制编码、导频设计、信道估计复杂度会成倍增加。实际产品中很多 Wi-Fi 6 路由器的 OFDMA MU-MIMO 联合能力只能同时处理 4-8 个用户超过这个数量后AP 会把剩余终端排到下一轮。另外MU-MIMO 对终端的空间流数量有硬性要求。一个 2x2 天线终端只能占用 2 个空间流如果 AP 是 4x4 天线那它最多只支持 2 个这样终端同时做 MU-MIMO。相比之下OFDMA 对终端天线数量的要求更低哪怕是单天线的 IoT 设备也可以分配一个 26-tone RU 和 4x4 的高端终端同时通信。所以在多用户高密度场景里OFDMA 往往是比 MU-MIMO 更有效的调度手段。我在办公室实测时用 iperf3 同时跑 6 台终端的下行带宽打开 OFDMA 后总吞吐提升了接近 2 倍而 MU-MIMO 的提升却没有这么明显原因就在于 6 台终端基本都是 1x1 或 2x2 的笔记本和手机空间流叠加能力有限。4.3 调度算法比协议参数更影响体验协议只是定了一个框架具体怎么调度完全看厂商。有的厂商调度器偏爱公平性给所有终端平分 RU有的偏爱最大化吞吐给信道质量好的终端更大的 RU有的则按照 QoS 队列来区分优先级保证语音视频业务的低延迟。对于自己做无线网络优化的人来说这个信息的意义在于当你发现某个 AP 的上行吞吐上不去不要惯性思维去调发射功率而是先查一下该型号 AP 的固件里有没有 OFDMA 调度相关参数。很多企业级 AP 系统里有“OFDMA 调度模式”选项可以选择“效率优先”“公平优先”或“平衡模式”改一次可能比调天线角度效果更明显。5. 不只是带宽TWT 与 BSS Coloring 的另类“调度”5.1 TWT给终端安排“闹钟”的省电调度很多人聊 802.11ax 只盯着速率忽略了 TWTTarget Wake Time目标唤醒时间才是真正改变 Wi-Fi 使用方式的机制。TWT 允许 AP 和终端协商一个“唤醒时间表”终端平时可以深度睡眠只有到约定时间才唤醒接收数据相当于调度中心给每个终端排了一个闹钟。对手机和平板来说TWT 能显著降低待机功耗。对物联网设备来说TWT 的意义更大——一批传感器可以分别约定不同的唤醒窗口避免同时醒来争抢信道。我在一个智能楼宇项目里测试过把几十个温湿度传感器全部接入 Wi-Fi 6 AP 并开启 TWT 后设备平均功耗下降约 40%同时信道竞争明显减少。但 TWT 也有副作用对延迟敏感的应用可能反而变差。因为终端在非约定时间内处于睡眠状态AP 如果突然有高优先级数据要发给它必须等它的下一个唤醒窗口。所以很多 AP 在 TWT 设计上做了一层“按需突发”机制如果 AP 缓存了高优先级数据会提前唤醒目标终端。这个机制的调度决策和 OFDMA 是两套逻辑但都非常依赖芯片实现。5.2 BSS Coloring给信道“涂颜色”实现空间复用BSS Coloring 是 802.11ax 在信道接入层面的调度优化。传统 Wi-Fi 要求终端在发送数据前先监听信道如果信道忙就退避等待哪怕这个“忙”是隔壁 AP 的信号。密集办公区里到处都是 AP传统 CSMA/CA 导致大量无效退避。BSS Coloring 的思路是给每个 BSS 分配一个 6bit 的 Color 值。终端收到帧时先看看帧里的 Color 是自己的还是邻居的。如果是邻居的只要信号强度低于某个阈值就允许终端忽略这个“外部干扰”并行发送从而提高空间复用效率。这个机制在调试中有一个坑BSS Coloring 开启后原本应该退避的终端会变得更加“激进”如果在 AP 部署过密的环境里不加限制地开启反而可能造成隐藏节点增多、丢包率上升。我在现场通常会把 Color 阈值从默认的 -72dBm 往上调几档或者干脆关闭让终端更保守一点。5.3 实测ax 调度对时延和续航的影响如果只看峰值速率Wi-Fi 6 和 Wi-Fi 5 的差别可能不明显但在时延稳定性上差距非常大。我在一个 40 人左右的培训教室做过对比测试在同一台 AP 下接入 40 台终端跑一个每隔 5 秒上报一次数据的客户端程序。关闭 OFDMA 和 TWT 的状态下上报延迟的抖动范围在 120ms 到 1.8 秒之间大量时间消耗在信道竞争和退避上。开启完整的 ax 调度机制后延迟抖动被压缩到稳定的 20-60ms。原因很好理解OFDMA 让 40 台终端分批次并行上报不用再互相打架TWT 让不上报的终端保持睡眠不参与竞争。省电效果方面TWT 的收益最直观。用同一台手机连续刷 30 分钟短视频开启 TWT 的续航比关闭状态多出约 15% 耗电优势。这个数字在不同终端上差异较大但方向是明确的。6. 从“ax 调度”反推无线路由器和终端的实际选择6.1 如何确认路由器真的支持 OFDMA 调度现在市面上几乎所有标着 Wi-Fi 6 的路由器都支持 OFDMA但支持程度有区别。入门级方案可能只支持下行 OFDMA上行 OFDMA 被省略了高端的芯片组则支持完整的上下行 OFDMA MU-MIMO TWT。判断方法有两个一是看拆解评测找芯片型号对应的规格表二是直接抓包确认。如果你有 Wireshark 和一台支持监听模式的无线网卡可以在连接 Wi-Fi 6 路由器后在 5GHz 频段上过滤wlan.fc.type_subtype 0x1cTrigger 帧能看到周期性 Trigger 帧说明下行调度正常能看到 BSRPwlan.fc.type_subtype 0x1a配合帧控制里的 QoS 类型说明上行调度也比较完整。6.2 固件里的调度开关别一上来就全开多数企业级 AP 和新款家用路由器的后台里都有 MU-MIMO、OFDMA、TWT 等参数。我的建议是不要把所有调度功能同时打开要结合实际环境来调整。如果家里终端数量少于 10 台且基本都是高性能手机和电脑OFDMA 的意义不大反而可能因为频繁的 Trigger 开销拉低速率这时候可以保持默认状态就行。如果是办公室、教室、商场这种高密度场景重点打开 OFDMA并检查终端兼容性TWT 是否启用则需要看终端业务类型——如果是视频会议和高频交互应用TWT 的省电收益远小于带来的时延不确定性建议关闭。我做过一组对照测试在 20 台终端的教室里开启 OFDMA 关闭 TWT 的模式实测交互延迟最低同时开启 OFDMA TWT延迟有小幅上升但终端续航明显改善。这是一个典型的“按业务取舍”的调度决策。6.3 三个容易踩的坑都是实测换来的第一个坑是路由器里的 OFDMA 开关名称五花八门。有的厂商叫“OFDMA 智能调度”有的叫“多用户加速”有的藏在“高级无线设置”里还有的干脆默认关闭需要手动打开。不看说明书的话你可能以为自己的路由器根本没这功能。第二个坑是老终端拖累新调度的效率。802.11ax 的 OFDMA 是向下兼容传统终端的但如果一个 AP 关联的终端里混有大量老旧 Wi-Fi 4/5 设备AP 无法对它们做 OFDMA 调度为了兼容它们整个信标周期里都要预留传统竞争窗口导致新终端的调度效率被拉低。遇到这种情况要么把老终端尽量迁移到另一个 AP 或频段要么干脆把 2.4GHz 和 5GHz 分开让老设备待在 2.4GHz 上别拖累 5GHz 的 ax 调度。第三个坑是同时开启了 WPA2/WPA3 混合加密模式某些终端的驱动在混合模式下会主动禁用部分 802.11ax 特性特别是 TWT 和 BSR。我遇到过好几次把路由器的加密改成纯 WPA3 后终端的速率和调度参与度立刻恢复正常。如果你排查无线问题时发现 ax 相关功能出不来先看看加密模式设置。做了这么多年无线网络我最大的感受是 802.11ax 这套调度机制本身设计得足够好真正影响体验的往往是设备厂商的实现细节以及我们对这些细节的认知。遇到“ax”相关的网络问题先别急着换硬件从调度机制入手做一次排查可能成本最低、见效最快。
返回列表