多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

WiFi 6的AX调度实战:OFDMA、RU分配与高密场景优化

WiFi 6的AX调度实战:OFDMA、RU分配与高密场景优化 做无线网络优化这些年我花在AX调度上的时间比调RF信道还要多。很多人觉得WiFi 6就是比WiFi 5快个一两百兆其实真正的分水岭在调度。802.11axWiFi 6引入的OFDMA、TWT、BSS Coloring让AP不再是一个只能逐台派单的“快递站”而是一个可以把几十条包裹按不同巷口同时分发的“智能枢纽”。你手里的AP如果只是开了AX模式但没有理解调度那实际用起来和WiFi 5区别不大如果调度调到位了高密度场景下的时延和吞吐能发生质变。这篇文章想把这套AX调度从原理、机制到抓包验证、常见坑整体拆一遍适合正在做高密办公、会展场馆、高校宿舍无线优化或者单纯想搞懂WiFi 6为什么能在人多的时候还保持稳定的人。1. AX调度要解决的真正问题1.1 高密场景下老协议为什么“卡”从做网络运维的第一年开始我就在和高密度场景下的空口效率较劲。办公楼中午休息时几百个终端同时挂在同一台AP上视频会议、文件传输、网页加载全挤在一起没人觉得网快。但看无线网卡的协商速率每个终端都显示着不错的链路速率问题到底出在哪答案不在射频物理层而在MAC层的介质访问机制。在802.11a/g/n/ac时代所有终端共享同一个信道用的是CSMA/CA的随机竞争机制一个时刻只有一台设备在信道上收发数据其他设备都得退避等待。你可以把这个过程想象成一条单车道所有车辆排着队前一辆没走完后一辆就得等哪怕旁边还有整片空草地。到了802.11ac虽然加入了MU-MIMO理论上AP可以同时给多个终端发送数据但MU-MIMO是在天线空间上并行要依赖终端的多天线能力和足够好的信噪比。在2x2天线的终端居多、环境干扰又强的办公区MU-MIMO的收益非常有限。而且它只管下行上行还是老规矩你争我抢。换句话说老协议的根本问题是“频谱空置”和“排队浪费”。一个20MHz信道上哪怕分配给了单个终端它也只能占用一部分子载波其余子载波都是闲着的却又不能给其他人用。设备越多等待时间越长TCP窗口涨不上去就会出现“信号很好、体验很差”的场面。AX调度要解决的就是这种空口资源的浪费。1.2 OFDMA把一条路拆成多股分道802.11ax引入的正交频分多址OFDMA是AX调度的地基。它把20MHz、40MHz、80MHz甚至160MHz的信道重新划分成了许多小单位的资源块。每个终端在使用时不一定要占据整个信道只需要占用其中一小段频率资源即可。这个“小段频率”在协议里叫资源单元RUResource Unit。通俗理解OFDM时代信道是一座独木桥一个人上桥别人就要等OFDMA时代桥面被画成多条车道电动车走一条道汽车走另一条道只要各守各道就能同时通过。调度器就是那个站在桥头的交通管理员它决定一条道画多宽、分配给谁、什么时候放行。OFDMA带来的最大变化是“并发”从时间维度扩展到了频域维度。AP可以在同一个下行物理帧里同时给多个终端发送数据前提是它们分别处在不同的RU上。上行也一样AP发一个触发帧终端们在同一时刻、各自的RU上把数据交上来。这是一种典型的频域调度也是“AX调度”这个词的核心内涵。这里要区分两个经常被混淆的概念OFDMA和MU-MIMO。OFDMA是频域并行不同终端用不同的频率段MU-MIMO是空间域并行不同终端用不同的天线流。802.11ax把两者结合起来调度器甚至可以在一帧里一部分用户走OFDMA、另一部分用户走MU-MIMO灵活性很高。但同时也会让调度算法变得复杂这也是为什么同样都标着AX不同厂商AP的表现可能差很多。2. 核心细节解析AX调度器的关键机制2.1 资源单元RU的划分规则AX调度最底层的一个概念就是RU怎么划分。在802.11ax的PHY层一个OFDM符号的子载波被按块组织RU可以由26、52、106、242、484、996个音调tone组成。一个“音调”就是物理层一个可用于传输数据的OFDM子载波26个音调大约对应2MHz带宽属于最小的RU。以最常见的20MHz信道为例整个信道大约有242个可用于数据传输的音调。如果全部拆成最小RU就是9个26-tone RU如果全合并则是1个242-tone RU。也可以混合比如1个52-tone RU加7个26-tone RU或者2个106-tone RU加1个26-tone RU。802.11ax在标准附录里给了一张合法的RU分配表AP不能随性组合必须按表里定义的组合方式划分。RU组合方式并发终端数参考适合场景9个26-tone RU最多9个低速终端高密IoT、并发小包4个52-tone RU最多4个中速终端普通办公混合业务2个106-tone RU最多2个高速终端视频流、大文件下载1个242-tone RU1个极速终端单终端极限吞吐测试这个划分直接决定了并发终端数和单用户体验速率的平衡。同样一个20MHz信道全拆成9个小RU能让9个低速率终端同时并发全合成一个大RU只能服务1个高速率终端。调优AX调度本质上就是在这两者之间找平衡点。到了80MHz信道可用音调数约为968个最多可以分成37个26-tone RU。不过RU数量越多负责标记RU分配信息的HE-SIG-B字段就越长控制开销也越大。所以实际场景里AP并不会无脑拆最小RU而是根据队列积压、用户状态和业务类型动态选择。我在高密办公区里见过最佳实践AP自动调度平均每个用户拿到26到52-tone RU特殊大流量用户临时拿到106-tone RU整体时延控制得很好。2.2 Trigger Frame上行调度怎么发起上行OFDMA比下行复杂因为数据在终端侧AP不知道谁有数据要发。为了在指定时刻把多个终端的数据收上来AP必须发一个Trigger Frame触发帧。这个帧里携带着RU分配信息告诉每个终端“你站在哪条泳道上、什么时候出发、用多大的力气游”。具体到协议字段触发帧里最关键的是RU Allocation字段和Associated RA信息。RU Allocation标记了每个终端的RU位置和大小Associated RA告诉终端自己是不是被触发的目标此外还有目标功率字段控制终端的发射功率避免某个RU上的信号泄漏到旁边的RU造成邻频干扰。终端收到触发帧后根据里面的分配信息在指定时间对齐发送HE Trigger-based PPDU。所有终端共享同一套时间基准所以能精确地在同一时刻开始上行传输哪怕它们的数据长度不同。结束后AP回Broadcast BA一次上行调度完成。抓包时触发帧的识别可以这样看在Wireshark协议列会有“Trigger”字样或者用显示过滤器wlan.fc.type 1 wlan.fc.subtype 0找到控制帧再在帧详情里检索“Trigger”。现在很多消费级网卡抓不到完整的HE触发帧建议用支持monitor模式的企业级网卡或者用AP的调试接口抓。提示如果你抓包时看到大量触发帧但上行并发成功率一直不高很可能是重叠BSS之间的同频干扰在作祟这时候就要看一下BSS Coloring的配置而不只是盯着OFDMA开关。2.3 下行OFDMA与MU-MIMO的配合下行调度的数据源头在AP一侧所以AP可以完全自主决定把哪些终端的下行数据放在同一个物理帧的不同部分。下行触发不需要专门的触发帧AP直接发一个HE MU PPDU帧里的HE-SIG-B字段标明每个用户的RU位置和空间流数。这里有一个关键的协同点下行OFDMA和MU-MIMO可以同时出现在同一个PPDU中。什么意思呢AP可以给用户1分配26-tone RU加空间流0给用户2分配26-tone RU加空间流1给用户3分配52-tone RU加空间流0和1。这种二维调度既用频域分用户又在同一RU内用空间域分用户大幅提高了单帧的并发能力。但付出的代价也很现实调度器需要知道每个终端的信道状态信息CSI以决定要不要做MU-MIMO预编码。终端越多、天线组合越复杂计算量非线性上涨。很多AP在固件里默认关闭部分MU-MIMO组合就是怕调度复杂度高了之后影响整机转发性能。这也解释了为什么在终端很少时OFDMA优势不明显在终端很多时计算力强的AP优势就出来了。2.4 TWT与BSS Coloring调度之外的补充手段AX调度不仅仅指RU分配还包括时间域的错峰调度和空间域的复用。其中TWTTarget Wake Time是802.11ax主推的省电和错峰机制AP和终端协商一个唤醒时间片终端在未轮到自己时进入doze状态减少空口竞争。从调度的角度看TWT有点像给不同类型的用户安排不同的出行时段。会议室AP可以把打印机、传感器、后台同步用户放进低优先级的TWT组唤醒间隔设大把视频终端放进高优先级组唤醒周期很短。这样虽然有250个终端在线但每个时刻真正醒着并参与数据收发的终端可能只有30个冲突概率大幅下降。BSS Coloring则是空间复用的手段。每个BSS用6bit的颜色编号标识自己终端在侦听信道时如果收到的信号来自相邻BSS且颜色不同同时信道能量低于阈值就可以认为信道是可以穿插使用的允许并行发送。这相当于给相邻区域贴上了不同颜色标签只要确定别人家的信号不会撞到自己家的数据就不必互相避让。完整的AX调度应该是“频域OFDMA 空间MU-MIMO 时间TWT 颜色复用”四位一体。你只调OFDMA而不管TWT或者只开TWT而没配好BSS Coloring都算不上真正调好了AX调度。3. 实操过程与核心环节实现3.1 配置侧确认AP是真的开了AX调度很多朋友以为把SSID换成“AX”字样开出11ax模式AX调度就自动生效了。实际情况不是。不同厂商的默认配置差异很大我测过几个主流企业AP有的默认关闭上行OFDMA只开启下行OFDMA还有的默认连OFDMA都没开只是开了HE能力字段。所以第一步永远是确认环境查看AP的无线模式确认5G射频工作在802.11ax-only或ax/ac mixed模式。如果还在兼容11a/11n调度器会被迫频繁回退到传统模式。在5G SSID的射频配置里找到“OFDMA”相关开关。有的AP叫“OFDMA”有的叫“Orthogonal Frequency Division Multiple Access”还有叫“Multi-User Scheduling”的中文界面可能是“多用户调度”或“资源调度”。必须同时确认“Downlink OFDMA”和“Uplink OFDMA”两项都是Enabled。查看“TWT”开关。如果是“Target Wake Time”不要一刀切关闭。默认Auto/Enabled通常够用但对于时延敏感的终端比如视频会议终端建议在SSID级别关闭TWT或者让终端加入白名单豁免。配置命令方面我用过的某厂商AP可以这样查询ssh adminap-a.office.corp ap# show wireless radio 1 ap# show wireless ssid office-5g如果看到OFDMA Downlink: Enabled和OFDMA Uplink: Enabled说明基本OK。如果只有单向下行OFDMA就需要进到SSID配置里打开上行调度。不同厂商命令不同但配置项的逻辑是一样的。注意开启上行OFDMA之后终端必须支持HE Trigger-based PPDU老终端802.11ac/n会退回传统上行这是正常的别被吓到。高密环境里新旧终端混存时建议把传统终端和AX终端分开走不同SSID否则兼容终端的轮询会拖慢AX调度器的节奏。3.2 抓包验证调度是“真开”还是“假开”最有效的验证方式是到AP覆盖区域用一个支持AX调度的终端连接目标SSID然后让几个终端同时做流量在AP侧或镜像端口上抓包。抓包要点找一个监听无线网卡设置成monitor模式信道锁定在目标5G频段。抓到Beacon后先确认Beacon帧里是否带HE Capabilities字段基本可确认AP在广播HE能力。继续抓找Trigger帧。在Wireshark的显示过滤器里可以用(wlan.fc.type 1) (wlan.fc.subtype 0)抓控制帧然后从协议树中找Trigger。如果能看到周期性的Trigger帧并且Trigger帧后的几毫秒内出现来自多个不同终端的上行帧那么上行OFDMA一定是生效的。下行调度看HE MU PPDU。抓包里若出现“Multiple Users”列或协议树里的HE MU标识说明多用户下行调度在工作。我一般不看那些复杂字段直接打开捕获文件的“Protocol Column”如果看到同一时间戳下有多个终端的帧突发成组出现那这个AP的AX调度就没白开。如果抓包十分钟始终只有单用户的上行就得回去检查上行OFDMA开关。3.3 场景调优RU策略和TWT参数怎么给AX调度器虽然自动跑但我还是会做几件“手动干预”的事情。高密办公场景AP天线少、终端多我希望并发终端数优先。这时候把SSID的调度模式设置为“高密度优化”有些设备上叫“公平调度时间公平”或者“最大并发”。RU分配会尽量偏向小RU让更多终端挤进来。实测下来高密会议室里开启这个策略人均时延能降低30%左右。视频流和大文件场景大RU更适合。如果此时终端只有个位数AP自动调度也会给大RU。但混合场景下某个终端在看4K视频另一个终端只是发微信默认调度器可能给视频终端分配太少RU导致卡顿。我一般会在AP的QoS策略里给视频终端的流量标记高优先级同时开启“按需分配”模式让视频终端在队列积压时能拿到大RU。IoT场景大量低速终端比如电池传感器不建议全部跑在WiFi 6上。如果必须跑同一个SSID优先开启TWT并把TWT唤醒间隔设成合理的值比如3到5秒。如果有些传感器对唤醒时延不敏感甚至可以为它们单建SSIDTWT间隔调大到5到10秒能明显降低空口竞争。这些调整的通用步骤是先在低峰期改一个变量观察24小时再改下一个。不要一次开一堆功能否则出问题根本不知道是哪个配置引起的。4. 常见问题与排查技巧实录4.1 假AX开了AX模式速率不升反降这是最常见的“假AX”现象。排查顺序是先看终端是否真的以HE速率接入。在终端无线网卡状态里确认链路速率是超过1Gbps还是只有866Mbps。很多手持设备只支持2x2 MIMO加80MHzHE速率也就是1201Mbps如果你的5G信道是40MHz速率再减半那就别怪AX调度是信道配置本身的问题。另外如果同一AP下大量老终端关联AP为了兼容传统终端可能会在混合传输中压缩OFDMA的TXOP。最好的办法是查看AP的“协议分布”数据。如果11ac老终端占比超过60%建议把老终端分流到另一个SSID或者只在5G频段强制ax-only模式。4.2 上行OFDMA抓不到Trigger帧抓包时发现整个空口只有单用户上行没有周期性的Trigger帧。先确认监听网卡是不是也支持HE monitor模式有些普通USB无线网卡抓不到HE控制帧。如果你能抓到Beacon但抓不到Trigger大概率是网卡过滤了控制帧切换网卡或改用AP侧抓包工具再试。如果排除了抓包问题再检查AP上行OFDMA开关是否真的生效以及固件版本是否包含上行调度优化。部分中低端AX AP对上行调度支持不完整只做了下行OFDMA上行Trigger频率极低这时候无论怎么调终端上行并发都起不来。现象可能原因处理方向能协商HE速率但下行无MU帧固件未开启下行OFDMA打开OFDMA DownlinkBeacon带HE但无Trigger上行OFDMA未开或固件不支持打开OFDMA Uplink并升级固件有Trigger但终端无响应终端不支持HE TB PPDU检查终端协议能力换AX终端测试有MU帧但只有1个用户调度器认为并发收益低增加并发终端数并调公平策略4.3 TWT开启后视频会议卡顿TWT本意是省电但把唤醒周期调得太大终端可能长时间处于doze状态外部语音包到达时终端还在睡。如果你的AP在SSID级开通了TWT默认间隔又比较激进很容易在音视频场景翻车。我踩过一次坑客户要求开TWT我把唤醒间隔设成了5秒结果视频会议终端每5秒才醒一次画面卡成PPT。后来把TWT间隔改成1秒同时只对支持弹窗唤醒的终端开TWT才恢复正常。经验是TWT要分设备对待低延迟设备不给TWT或者设一个短于100ms的服务周期。4.4 RU分配不均导致交互应用超时当某个终端在持续做TCP高速下载时AP调度器会倾向于给它分大RU和高MCS这看起来公平但如果旁边有10个终端都在做实时语音就会出现“少数人占道”的局面。我一般会在AP配置里把调度公平策略从“吞吐最大化”改成“时间公平”。吞吐最大化会把RU按需分配大流量用户吃到更多资源时间公平会让每个终端大致占用相同的空口时间这样大流量终端会被限速但整体交互体验会稳很多。适合高密交互场景。5. 项目落地AX调度选型与验收清单5.1 企业AP选型时怎么考察调度能力同样标着802.11ax不同AP的调度能力差得非常多。选型时不要只看峰值速率和天线数量要把“调度”当成一个独立能力去考察。先看规格表里是否明确写了“OFDMA Downlink/Uplink”和“MU-MIMO”同时支持。很多入门级AX AP只支持下行OFDMA上行需要额外许可证或固件版本才开。再看是否支持TWT的调度组管理而不只是广播TWT。能按终端分组设置不同唤醒间隔的AP在高密场景里明显更灵活。然后看调度算法有没有可调参数。我比较看重“公平策略”和“RU分配倾向”这两项。如果固件里只能开或关OFDMA没有更细的调度策略那到了高密场景很难精调。有条件的话在项目招标前做一轮真实场景PoC同时连接50个AX终端跑上下行混合流量看抓包里Trigger帧的周期和RU分配合理性。5.2 一套AX调度验收清单我在项目验收时会把下面的几项列进测试报告只要有一项不达标就说明AX调度没有真正跑起来5G频段信道上抓包能稳定看到Beacon中的HE能力字段。下行流量高峰期抓包中HE MU PPDU数量占多用户PPDU的50%以上。上行流量高峰时能看到周期性Trigger帧且同一个Trigger周期内至少有2个及以上终端同时上行。开启TWT后用打流终端监测空口空闲时间的降低幅度幅度不明显说明TWT参数没生效。连续跑30分钟并发业务AP测得的“每用户空口公平指数”不低于0.8。这套清单不一定需要昂贵工具一台支持monitor模式的网卡加Wireshark就能完成大部分验证。6. 一点个人体会AX调度这个功能查资料不难难的是在一个真实的无线环境里把它的作用调出来。做了这几年网络优化我越来越觉得WiFi 6的价值不在标称速率而在空口资源的调度能力。先把环境里的传统终端管好再开OFDMA最后用抓包结果验证每次调整这套节奏基本不会走偏。如果你手头的AP有比较完善的调度统计页面一定要每周看一次里面的“RU利用率”和“每用户空口占用时间”。这两个指标比RSSI和信噪比更能反映用户体验。最后分享一个小技巧调AX调度时不要一上来就改参数先在同一个位置、同一个终端上用iperf3 -R和iperf3各跑一轮留下数据改完后再跑同样的脚本对比上下行各分位数的抖动值用数据判断调度策略是否值得保留。这样至少不会再为了一个“看起来高大上”的开关去盲改。
返回列表