Wi-Fi 6核心机制AX调度实战解析：OFDMA、触发帧与TWT

1. 先把“AX 调度”这件事讲清楚AX 调度最近在技术圈里被反复提起但很多人把它当成一个模糊的网络热词来看这其实有点可惜。在无线网络和协议栈开发的人眼中AX 调度指的就是 802.11ax也就是 Wi-Fi 6引入的那一套空口资源调度机制。这套机制回答了一个非常朴素的问题一个 AP 下面同时挂着几十台终端每毫秒谁在哪个频段上发、用多大信道宽度、配几条空间流、什么时候轮到他发全部由 AP 主动分配而不是让终端靠“抢”来决定。做无线设备调试这些年我最大的感受是802.11ac 以前大家比的是“单链路有多快”到 802.11ax 时代真正拉开体验差距的反而是“多链路并发时有多稳”。AX 调度就是这条赛道上最关键的技术底座。如果你要调优一个 Wi-Fi 6 项目或者你只是好奇为什么路由器带机量从几十台提高到一两百台还能不卡那你需要理解的不是那些花哨的速率数字而是 OFDMA、触发帧、TWT 这几个调度相关的核心机制。这篇文章会把 AX 调度从概念到抓包实测、从参数配置到踩坑排查完整串一遍。没有过多理论推导全部是干活时验证过的逻辑和习惯用法看到能直接用是最好的。1.1 为什么 802.11ax 的主要变化不在速率而在调度先做个简单对比。802.11n 引入了 MIMO把单链路速率从 54Mbps 拉到 300Mbps 甚至 600Mbps802.11ac 引入了更宽的 80/160MHz 信道和更高阶的 256QAM单链路速率直接到了 1.7Gbps 以上。但你仔细观察就会发现这两代技术对“多设备同时上网”这件事的改善并不大。原因在于 MAC 层仍然沿用 CSMA/CA也就是“先听后说”每个终端发送前都要等信道空闲如果两台设备同时发送就会冲突冲突后还要退避重传。终端一多空中信道大部分时间都浪费在等待和退避上AP 的速率再高也发挥不出来。802.11ax 的调度机制把思路彻底改了与其让一堆终端互相猜信道什么时候空闲不如由 AP 当一个总指挥把信道的频率资源切成小块在同一时刻分配给多个终端使用。这句“切成小块”就是 OFDMA中文叫正交频分多址。它把一个信道从“一条独享的马路”变成了“一条可以同时并排跑很多辆车的高速公路”每辆车走自己的车道互不干扰。这就是为什么 Wi-Fi 6 带机量比 Wi-Fi 5 有明显提升的核心原因而不是因为路由器 CPU 变强了。这里需要纠正一个常见的误解很多人以为 OFDMA 是把“总带宽平分”给每个设备实际上不是。OFDMA 是把频域资源切分成不同大小的资源单元Resource UnitRU每个终端分配一个或多个 RURU 大小可以根据终端的信道质量、业务量灵活变化。信道好的设备可以用大 RU 获得高吞吐信道差的设备用小 RU 保持连接稳定这个分配决策就是调度器的核心工作。1.2 调度的本质把“竞争”改成“先到先得”理解调度之前先理解竞争。传统 Wi-Fi 里的 CSMA/CA 就相当于银行网点没有叫号机所有客户挤在柜台前谁手长谁先办业务。如果有人插队大家都得停下来重新排队这就是冲突。这种模式在终端少的时候问题不大但终端一旦超过 20 台信道利用率就会断崖式下跌。AX 调度相当于银行装了叫号系统AP 知道每个“客户”终端要办什么业务、手里有多少“材料”待发数据然后把“窗口”RU按需分配出去一群客户在同一时间窗口各自办完自己的事互不干扰。这是效率和公平性兼顾的分配策略。更进一步说AX 的调度不是只有 OFDMA 一个维度。它其实是频域、空域、时域三个维度同时展开频域上 OFDMA 分配不同 RU空域上 MU-MIMO 让多台设备在同一 RU 上使用不同空间流时域上 TWTTarget Wake Time目标唤醒时间让设备在约定时间才醒来收发数据。这三套机制叠加在一起才是完整的 AX 调度。搞明白这三者的边界后面看抓包和调参数的时候思路会清楚很多。2. 调度链路整体设计从 RU 分配和触发帧说起既然调度是 AP 一手包办的那 AP 到底通过什么手段把资源分配下去实际在空口上传送“资源分配命令”的帧叫触发帧Trigger Frame所有上行 OFDMA 传输都由它拉起。这一节把 RU 分配、触发帧和上行调度相关的细节拆开看这些也是抓包时最常碰到的东西。2.1 RU 大小与信道宽度怎么选RU 是 OFDMA 调度中最小的分配单位。一个 20MHz 信道可以切出不同数量的 RU基本颗粒是 26 个 tone子载波然后是 52、106、242、484、996 tone 这几个档次。不同信道宽度下的 RU 数量不一样我整理了一个常用对照表方便查信道宽度26-tone RU52-tone RU106-tone RU242-tone RU484-tone RU996-tone RU20 MHz9421不支持不支持40 MHz188421不支持80 MHz37168421RU 越大单个终端能分到的数据 tone 越多瞬时速率越高RU 越小能同时服务的终端数越多但每个 RU 能承载的有效数据很少。实际工程里AP 调度器会用多轮 RU 分配的办法在两者之间折中这一轮先给四个终端各分一个 242-tone RU下一轮再给八个终端各分一个 106-tone RU保证网络里既有高吞吐的玩家也有低时延的语音设备。选择 RU 大小还有一个隐藏因素频率选择性衰落。无线信道在不同频段上的衰减差异很大如果某个终端恰好落在深衰落的频段上哪怕分给它 996-tone 大 RU调制编码率也上不去。所以好一点的调度器会参考终端的信道状态反馈CSI来动态调整 RU 位置和大小。这个在商用 AP 芯片里是自动完成的但在自己做协议栈或做测试时你得知道为什么明明信号满格RU 却只给了 52-tone——大概率是 AP 在绕开该终端当前频段的深衰落。2.2 触发帧AX 上行调度的“发令枪”上行 OFDMA 和下行 OFDMA 的调度方式完全不同。下行方向AP 自己手里有数据想发什么、发多少由自己决定只要在 HE MU PPDU 里附带 RU 分配信息就行。上行方向则复杂得多因为 AP 不知道终端什么时候要发数据、发多少必须用触发帧去“点名”终端。触发帧是 802.11ax 里新增的帧类型它的核心作用就是告诉指定的一组终端下一帧你们同时发按这个 RU 分配表来发。触发帧有不同的子类型用途也不一样触发帧类型作用典型场景Basic Trigger普通上行调度按 RU 分配让指定终端发数据日常上行数据收发BSRP询问终端的上行缓存状态AP 收集各终端的待发数据量MU-BAR批量 Block ACK 请求同时确认多个终端的上行数据MU-RTS多用户 RTS保护上行传输不被干扰混合环境中防止老终端冲突GCR MU-BAR组播业务批量确认视频组播等场景我在测试时最常观察的是 Basic Trigger 和 BSRP。一个合理设计的 AP 调度流程通常是这样的AP 先发一个 BSRP 触发帧问“谁有数据要发、要发多少”终端在响应帧里上报自己的 Buffer StatusAP 拿到这些状态后下一轮发 Basic Trigger按各终端上报的缓存量分配 RU终端同时上行发送最后 AP 用 MU-BAR 统一确认。整套流程在几毫秒内完成但抓包时非常清晰你能看到触发帧里带了一串终端的 AID关联 ID和对应的 RU 分配信息。要强调一句终端并不是想发就能发。即使它的业务数据已经准备好了也必须等到 AP 用触发帧点名它所在的那一组它才能上行发送。这个改变对芯片厂商的驱动和协议栈影响非常大很多早期 Wi-Fi 6 设备在旧驱动下宁愿用传统方式偷偷发数据也不等触发帧调度器一看拿不到主动权效率自然上不去。这也是大家在调研 AX 调度时常常忽略的“兼容性暗坑”。2.3 怎么读取触发帧里的关键字段如果你在 Wireshark 里打开一个 Wi-Fi 6 抓包文件看到 type0、subtype13 的帧那就是触发帧。触发帧的 Common Info 字段里会写明触发类型、CW 参数、前导码类型等最关键的是 Per User Info 字段里面有一个 12bit 的 AID12 和 RU Allocation 字段。AID12 表示分配给哪个终端RU Allocation 决定这个终端用哪个频率范围的 RU。我习惯用的过滤命令是这样的# 只看触发帧 tshark -r wifiair.pcapng -Y wlan.fc.type_subtype 0x000d # 看触发帧里的 RU 分配和 AID tshark -r wifiair.pcapng -Y wlan.fc.type_subtype 0x000d -T fields \ -e frame.number -e wlan.ta -e wlan.he.aid12 -e wlan.he.ru_allocation # 看上行 HE TB PPDU 的基本信息 tshark -r wifiair.pcapng -Y wlan.fc.type_subtype 0x000d || (wlan.fc.type 0 wlan.fc.subtype 4)需要提醒的是不同版本的 Wireshark 对 802.11ax 字段的命名有差异老版本可能不识别 wlan.he 前缀要看帧原始数据或升级到较新版本。不过字段名是小事情抓包的核心价值在于让你看出“AP 是否在做真正的 OFDMA 调度”还是只是把触发帧当摆设、所有终端仍然各自为战。这个问题我后面在实测环节会展开。2.4 TWT 调度让终端按“预约时间”醒来TWT 是 AX 调度里容易被忽视但实际价值很高的一块。它的核心是为终端安排“睡觉”和“醒来”的时间点。传统 Wi-Fi 网卡即使没有业务也必须周期性醒来听 Beacon就为了确认有没有自己的数据。终端一多这个周期性唤醒产生的空口开销其实很可观。TWT 出现后终端可以和 AP 约定一个唤醒窗口窗口外完全睡眠窗口内才 Listen 或者收发数据。短报文比如智能门锁的心跳、传感器上报用这种模式可以省掉大量无效监听时间终端待机续航也能明显提升。TWT 分为单播 TWTIndividual TWT和广播 TWTBroadcast TWT。单播 TWT 适合某种特定业务量的终端AP 单独给它排时间段广播 TWT 适合一批行为模式相似的终端AP 在 Beacon 里广播一个公共的唤醒窗口。企业园区网里如果有一批扫码枪或者 IP 电话广播 TWT 能让它们的唤醒行为对齐空口调度器的排兵布阵也就更从容。我在实际项目里对 TWT 有一条铁律默认先把 TWT 关闭把网络调稳定后再开。原因很简单TWT 协商本身需要额外交互如果 AP 固件实现得不够好终端协商失败后会反复重试甚至出现“假死”状态——终端以为自己睡眠了AP 以为它还醒着结果数据就丢了。分批打开 TWT并且观察一段时间内终端的空口重传率是稳妥的做法。3. 实测一台 Wi-Fi 6 AP 的 AX 调度过程概念说再多不如亲手抓一次包。这一节我用一套常见的实验室环境演示怎么确认 AP 的 AX 调度是否真的生效以及它在多终端并发时具体怎么分 RU。3.1 测试环境与基础配置我的测试环境不算豪华但足够说明问题一台支持 802.11ax 的 AP支持 hostapd 或用系统自带的 AP 模式都行三个笔记本分别装 Intel AX200、AX210 网卡加一台手机做干扰流量源。整套测试在 5GHz 频段、80MHz 信道下进行因为 80MHz 下能看到更多 RU 组合。AP 配置大概长这样# /etc/hostapd/hostapd.conf 关键配置 interfacewlan0 drivernl80211 ssidax-test hw_modea channel36 ieee80211n1 ieee80211ac1 ieee80211ax1 he_oper_chwidth1 he_oper_centr_freq_seg0_idx42# 客户端连上后用 iw 确认协商结果 iw dev wlan0 link iw dev wlan0 station dumpiw link输出里能看到当前协商的带宽和速率iw station dump里能看到rx bits、tx bits、signal这些基础状态。如果 station dump 里没有 HE 相关的 MCS 信息说明客户端没有真正工作在 802.11ax 模式后面 OFDMA 调度无从谈起先解决驱动问题的产物。3.2 用抓包验证 OFDMA 调度是否生效验证方法是同时让三台终端下行拉流然后在 AP 侧用 tcpdump 抓空口报文。抓包点放在 AP 本机或者用支持监听模式的网卡。我习惯直接抓然后过滤触发帧和 HE MU PPDU# 抓空口报文monitor 模式 iw dev wlan0 set type monitor tcpdump -i wlan0 -w ax-capture.pcapng # 分析时先看触发帧分布 tshark -r ax-capture.pcapng -Y wlan.fc.type_subtype 0x000d | head -20如果你看到触发帧里确实同时出现了几个终端的 AID并且紧接着的 HE TB PPDU 是同时上行的那 OFDMA 调度就是生效的。我用一次典型抓包举例AP 在一次下行调度里把 80MHz 信道分成了这样终端AIDRU 分配估计 MCS用途笔记本 A1996-tone RUMCS 11大流量下载笔记本 B2242-tone RUMCS 9中等流量笔记本 C3106-tone RUMCS 6弱信号设备保底手机 D426-tone RUMCS 4小包语音/控制这一轮调度直接把一台受限于信号质量的弱终端用最小 RU 保护住同时给强信号终端让出大 RU 跑高速互不干扰。放在 802.11ac 时代这三台设备发数据大概率要互相等弱终端还会拖慢整个网络——这就是 AX 调度在真实场景里最大的体感差异。3.3 调度开关切换下的吞吐延迟对照为了量化 OFDMA 的价值我在同一环境里对比了两轮测试第一轮关闭 AP 的 MU 相关特性让所有终端回到类似传统竞争的模式第二轮打开 OFDMA。三轮下行并发 iperf3 跑下来数据大致如下指标关闭 OFDMA开启 OFDMA三终端总下行吞吐720 Mbps860 MbpsP50 单向延迟9 ms4 msP99 单向延迟28 ms9 ms空口重传率4.5%1.2%总吞吐提升不算夸张因为 80MHz 下并发流量的总频谱资源就这么多真正厉害的是延迟抖动的大幅下降 P99 从 28ms 降到了 9ms。这也是 OFDMA 在游戏、语音、AR 这类对时延敏感的场景里价值最明显的原因——它不是让单个人快而是让所有人一起稳。如果测试现场只有一两台终端OFDMA 带来的收益确实不明显这是物理特性决定的所以千万别用单终端的速率去否定调度机制的价值。4. 线上最常踩的 AX 调度坑与排查方法这节是实战部分。AX 调度本身是机制但真跑到现网里各种设备混着老协议、各种驱动半残废的情况下坑非常多。我整理了几个出现频率最高的问题和解法。4.1 老客户端把网络拉回 CSMA/CA 时代这是所有 Wi-Fi 6 网络混布场景下最常见的问题。只要网络里有一个只支持 802.11a/b/g/n 的老设备AP 为了确保它能听懂信道占用状态就必须在 OFDMA 传输前加保护机制。一种常见做法是发 MU-RTS用传统帧格式先占用信道再发触发帧这种保护本意是避免老设备误判信道空闲而乱发数据但代价是一次保护帧 等待 SIFS 的时隙开销非常大。网络里老设备越多调度周期越长OFDMA 的收益被稀释得越严重。排查方式很简单抓包统计传统帧和 HE 帧的比例。如果传统帧占比超过 20%去看看是哪个设备在拖后腿。用iw dev wlan0 station dump找到速率最低、协议最老的关联终端推动它换网卡或者接入访客 SSID往往比调 AP 参数更有效。4.2 RU 分得太碎延迟不降反增调度器有一个很常见的“热心肠毛病”为了照顾所有在线终端每轮 OFDMA 都要给每个终端分 RU哪怕这个终端只有几十 KB 的控制数据要发。结果就是 80MHz 被切成十几个 26-tone 小 RU每个 RU 塞不了多少有效数据反而要付出触发帧、SIFS、前导码这些固定开销。摊下来每轮传输的有效载荷率极低延迟和吞吐一起恶化。我的经验是限制每轮 OFDMA 的 RU 数量尤其是给弱信号终端的 RU 不要小于 52-tone如果有大流量视频类终端优先分 242-tone 以上。不少商业 AP 的调度器可以通过隐式配置调整 RU 分配策略如果芯片原厂固件没有开放参数可以尝试用 QoS 队列优先级把低优先级终端排除在 OFDMA 每一轮调度之外让它们走传统模式单独发送反而能降低整体延迟。4.3 TWT 开启后终端“睡死”TWT 的睡眠机制优化得好能省电但实现不好就是灾难。我遇到过一批物联网扫码设备在 AP 上开启 Broadcast TWT 后部分设备每隔一段时间就彻底失联。排查发现过程是这样的终端在 TWT 协商时请求了很长的睡眠周期AP 也同意了但网络里还有其他组播/广播报文在非 TWT 窗口下发终端醒不来收不到ARP 老化后连接就断了。还有一类情况是终端固件在 TWT 睡眠期间没有正确缓存帧醒来后缓冲队列丢包。排查这类问题第一件事是抓 Beacon 和 TWT 协商帧确认 AP 广播的 TWT 参数、终端的响应结果。看协商成功不代表实际运行正常需要对比 AP 侧是否存在大量“发送失败但终端还在关联”的报文。权益做法是先关掉 TWT 观察基线再按组增量开启每组测试不少于两小时的稳定性再继续推广。对于重要的手持终端用单播 TWT 并缩短唤醒间隔比盲目追求极致睡眠时间更稳妥。4.4 BSS 颜色冲突导致空间复用失效BSS Color 是 802.11ax 为空间复用引入的颜色标记机制AP 在发送 PPDU 时夹带的 6bit 颜色号终端看到颜色相同的帧直接丢弃以减少处理开销看到颜色不同时可以判断是其他 BSS 的同频信号如果信号强度低于阈值就允许自己同时发送。这本来是为了在密集组网时提升并发能力。但是颜色号就那么几十个部署一密就会发生两个相邻 AP 选了同颜色。一旦颜色冲突AP 会把本来其他 BSS 的信号误判成同频干扰要么不敢发要么错误丢弃帧空间复用机制直接失效。排查方法是看 Beacon 里 BSS Color 字段并配合信道扫描结果确认周边同信道 AP 的颜色分配。商业控制器一般会自动避免重复配色如果是家用/小场景手工配置务必在相邻 AP 间规划好 BSS Color别全部留默认值。4.5 常见问题速查表症状直接原因排查命令/手段解决方法老设备一接入全网延迟抖动变大混合模式下保护帧开销剧增抓包统计传统帧占比老终端单独 SSID或调整保护机制多终端并发时吞吐不稳定RU 过碎固定开销占比高查看触发帧 Per User Info限制每轮 RU 数优先大 RU开启 TWT 后设备间歇失联TWT 睡眠丢失组播/ARP 报文抓 Beacon 和 TWT 协商帧分批开启缩短唤醒间隔邻 AP 同频并发时吞吐骤降BSS Color 冲突扫描同信道 AP 的 Color规划颜色避免重复5. 不同业务场景下的 AX 调度参数倾向最后聊一下参数倾向。AX 调度不是“一键开启就完事”不同业务对空口延迟、吞吐、省电的要求完全不同。我按自己的项目经验给几类场景做了取舍建议你可以作为调优参考。5.1 企业会议室/音视频场景这类场景的特点是终端数量稳定、大流量并发、延迟敏感。我的倾向是关闭或调长 Broadcast TWT因为视频会议这类实时业务不适合让终端长时间睡眠OFDMA 调度保持开启但每轮优先保证 242-tone 以上的 RU 给活跃终端语音终端用 106-tone 独立 RU避免和小包混在同一个 RU 上排队。空口抓包时的延迟抖动如果还大优先检查是否有一些隐藏老设备在拖慢保护帧节奏。5.2 智慧园区/物联网场景这类场景终端多、单终端流量极小、对延迟容忍度高。可以把 Broadcast TWT 调开按业务类型把唤醒窗口切分比如传感器每小时醒一次扫码枪每 10 秒醒一次。此时调度器的主要任务是尽量把同一唤醒窗口的终端拢在一起减少 AP 空口唤醒次数。小 RU26/52-tone在这个场景反而有用因为它能把大量低流量终端并到同一轮传输里空口利用率最高。5.3 高密度场馆场景场馆里的核心矛盾是同频干扰和空间复用。BSS Color 要精细规划相邻 AP 用不同颜色并且关闭低信号终端的干扰探测让 AP 更激进地利用空间复用。在调度器层面限制每个 AP 的关联终端数超过阈值就把新终端导向邻频或者引导快速漫游。OFDMA 的 RU 分配要尽量向各个终端的大流量方向倾斜不要为了表面上的“公平”把小 RU 发得满天飞。上面这些策略没有一个能直接照搬到所有网络里因为 AP 的芯片、固件、终端设备的兼容性都会影响最终效果。但只要你理解了 AX 调度的基本链路知道触发帧是怎么发号施令的也知道 OFDMA、TWT、BSS Color 各自管哪一段遇到任何一条现网问题都能沿着这个链路一层层抓包定位。做无线这行经验说白了就是先把机制吃透再用排查工具去验证直觉这两件事做到位AX 调度就不再是悬浮的热词而是你手里真正能用起来的效率工具。