做无线网络这一行早几年被问到最多的一句话就是WiFi 6 到底比 WiFi 5 快多少很多人张口就报协商速率2402Mbps、1201Mbps可实际用 iperf3 一打流往往只有几百兆于是开始怀疑设备是不是被坑了。其实 802.11axWiFi 6真正值钱的地方并不只是 1024-QAM 带来的那点峰值速率提升而是 OFDMA 这套资源分配机制带来的多用户并行能力。这篇就围绕 802.11ax 的 OFDMA 资源分配展开把 RU、HE-SIG-B、Trigger Frame 这些平时容易绕晕的概念串起来讲清楚也会把我自己在真实设备上的验证方法、踩坑记录一并分享出来。适合刚开始接触 WiFi 6 协议开发、做无线网优调试或者单纯想搞清楚“为什么 WiFi 6 在人多的地方更稳”的朋友。1. OFDMA 到底解决了什么问题1.1 传统 OFDM 的痛点在 802.11ax 之前802.11a/g/n/ac 用的都是 OFDM这种技术的思路是把一个信道分成很多正交子载波同一时刻所有子载波都服务于同一个终端。也就是说无论这个终端是传大文件还是只发一个几十字节的 ACK都要独占整个信道的全部子载波时间上严格串行。这个机制在终端少的时候问题不大但在高密度场景下就很尴尬。比如一个会议室里 30 台设备同时在用一台设备发一个很小的确认帧占着整个 20MHz 或者 80MHz 信道其他设备只能在旁边等着等它发完再通过 CSMA/CA 竞争信道赢了才能用自己的全信道资源。更麻烦的是管理帧、控制帧这类短报文非常频繁每一次都走完整的信道竞争、退避、确认流程大量空口时间都浪费在排队和碰撞退避上真正传业务数据的占比反而很低。我用一个收费站类比来说明传统 OFDM 就像一条只有一根车道的收费站不管后面排队的是一辆小面包车还是一辆大货车每次只放一辆车通过后面的车哪怕再急也得等着。车一多整条路就变成停车场。1.2 OFDMA 的核心理念与设计出发点OFDMA 的思路很简单既然一个信道里有很多子载波为什么不能把这些子载波按不同数量切成小组分给不同的终端同时使用每个小组就是一个资源单元Resource UnitRU不同终端可以在同一个信道里各自占用不同的 RU 并行收发这就是 802.11ax 相对 802.11ac 最大的协议层变化。从物理层角度看OFDMA 能成立是因为 802.11ax 把子载波间隔从 312.5kHz 缩小到了 78.125kHzOFDM 符号时长从 3.2μs 拉长到 12.8μs。子载波间隔变小、符号变长意味着一个符号内的子载波数量变多了可以更灵活地划分子组。打个比方原来一条马路只是单车道现在路还是那么宽但被重新画线划成了好几条窄车道不同方向的车可以各走各的道。OFDMA 的价值主要有三点。第一是降低时延多个终端可以在同一时刻并行传输不需要反复竞争信道第二是提升频谱利用率短帧、控制帧也可以和其他业务一起复用信道不再单独占满整个带宽第三是改善高密度场景的公平性AP 可以主动调度不同终端的 RU而不是让所有终端靠“抢”来决定谁先发。1.3 上行和下行两条路径都要管OFDMA 在实际工作中分成下行和上行两种情况这也是很多初学朋友容易搞混的地方。下行 OFDMA 由 AP 主动发起。AP 把要发给多个终端的数据打包进一个 HE MU PPDU多用户物理层协议数据单元在帧里标明每个终端各自用哪个 RU一口气发出去。终端收到后解析 HE-SIG-B 字段找到属于自己的 RU 位置取走属于自己的数据。上行 OFDMA 则没有那么简单因为多个终端要同时往 AP 发数据如果没有统一指挥时间、频率、功率都对齐不了。802.11ax 的解决办法是让 AP 先发一个 Trigger Frame触发帧这个帧里包含了每个终端允许使用的 RU、传输时长、MCS、目标接收功率等信息终端收到触发帧后在指定时间、指定 RU 上同时发送 HE TB PPDU。所以上行 OFDMA 本质上是一个“AP 点名终端按点应答”的机制。理解了这两条路径之后接下来要深入的核心自然就浮出来了RU 是怎么划分的AP 又是怎么把这些 RU 分给不同终端的。2. 资源分配的核心RU 与信道划分2.1 RU 是什么里面到底有多少子载波RU 是 OFDMA 资源分配的最小单位802.11ax 标准里定义了 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone 等几种 RU 类型。这里的 tone 指的就是子载波26-tone RU 表示这个 RU 包含 26 个子载波带宽大约是 26×78.125kHz≈2.03MHz。不过并不是 RU 里所有子载波都用来传数据。每个 RU 里都要留出导频子载波用于信道估计和相位跟踪剩下才是数据子载波。下面是各类型 RU 的详细参数这个表在做速率估算时非常有用RU 类型总子载波数数据子载波数导频子载波数约占用带宽26-tone262422.03MHz52-tone524844.06MHz106-tone10610248.28MHz242-tone242234818.91MHz484-tone4844681637.81MHz996-tone9969801677.81MHz这里特别提醒一句网上有些资料为了简化会把 26-tone RU 写成“两个导频、24 个数据子载波”但在实际抓包解析时你还会看到 DC 子载波、null 子载波、guard tone 这些概念。简单理解就是不是所有子载波都能干活物理信道两侧要留保护带中心频点附近也要留空防止直流偏置和相邻信道干扰。所以一个 20MHz 信道虽然总共有 256 个子载波但真正能用于 RU 划分的只有 242 个左右。2.2 不同信道宽度下的 RU 组合规则RU 划分的规则决定了 AP 能把信道切成多少片。以 20MHz 信道为例可以全部切成 9 个 26-tone RU也可以切出 4 个 52-tone RU或者 2 个 106-tone RU再不济就是一个完整的 242-tone RU 给单个用户用。当然也可以混合分配比如一个 20MHz 信道里同时存在 106-tone 52-tone 26-tone 的组合只要不超出信道总容量就行。40MHz 信道可以拆出 18 个 26-tone RU80MHz 信道可以拆出 37 个 26-tone RU160MHz 则是在两个 80MHz 上各做一次 RU 分配。需要注意的是当信道带宽大于 20MHz 时中心频点附近会单独留出一个 26-tone RU 的位置协议里叫 center 26-tone RU。这个 RU 不是在所有帧里都会被分配如果分配了需要在 RU Allocation 字段的最高位做个特殊标记后面讲报文结构时还会提到。从实际操作角度讲RU 组合规则的细节一般不需要工程师去背标准里给了完整表格写解析代码时直接查表即可。但有一个原则要记住RU 越细能同时服务的用户数越多但每个用户的可用子载波越少单用户峰值速率越低RU 越粗单用户体验越好但能并行服务的用户数就少了。AP 的调度器就是在“多用户并行”和“单用户速率”之间找平衡。2.3 RU 大小如何与业务需求匹配分配 RU 不能一刀切。一个只发心跳包、状态上报的 IoT 设备一次就几个字节的数据给它分配一个 242-tone RU 纯属浪费一个正在看高清视频或者传大文件的终端如果只给一个 26-tone RU实际速率会低到没法用。正常调度器的思路是这样小 RU 优先给短报文、低优先级、对时延不敏感的小流量设备大 RU 优先给持续发送、对吞吐有要求的业务。比如一个 20MHz 信道被切成 9 个 26-tone RUAP 可以让 9 个智能插座同时上报状态每个插座的数据都在自己的小 RU 里并行传完这在传统 OFDM 机制下需要 9 次完整的信道竞争和传输效率差距肉眼可见。MCS调制编码策略也会影响 RU 的选择。同样一个 26-tone RU终端信道质量好、支持 256QAM 甚至 1024QAM 时能传更多 bit但信道质量差时调度器只能降低 MCS这时小 RU 的数据承载能力就更有限。所以 AP 调度器通常还会参考终端反馈的信道状态信息和重传率动态调整 RU 大小和 MCS 的组合。2.4 OFDMA 与 MU-MIMO 的叠加关系很多人以为 OFDMA 和 MU-MIMO 是同一回事实际上两者是互补的。OFDMA 是在频域上区分用户MU-MIMO 是在空间域上区分用户。802.11ax 允许这两者叠加使用同一个 RU 上可以同时给多个空间流用户传输数据。举个例子AP 有 4 根天线一个 80MHz 信道被切成两个 RURU1 里用两条空间流给终端 A 传视频同时用另外两条空间流给终端 B 传文件RU2 里再用两条空间流给终端 C 传数据。这样频域和空域都被充分利用了效率自然比单独用 OFDMA 或单独用 MU-MIMO 高得多。协议上一个 HE MU PPDU 最多可以调度 8 个用户每个用户最多 4 条空间流单个 PPDU 的总空间流数不超过 8。实际能调度几个用户还要看 AP 的硬件能力、天线数量以及终端的 MU-MIMO 反馈能力。这里有个经验很多中低端家用路由器虽然在包装上印了 MU-MIMO但实际只支持 OFDMA或者只支持下行 MU-MIMO上行 MU-MIMO 基本是摆设测试时不要被宣传参数误导。3. OFDMA 资源分配在报文里是怎么表达的3.1 下行 HE MU PPDU 里的 HE-SIG-B 字段对于搞协议分析和驱动开发的人来说光知道 RU 的划分规则还不够得能从报文里读出 AP 到底把哪个 RU 分给了哪个用户。下行多用户传输靠的是 HE MU PPDU这个帧的 HE-SIG-B 字段就是 RU 分配信息的载体。HE-SIG-B 分为公共字段和用户特定字段两部分。公共字段里有一个 RU Allocation 子字段长度是 8 bit其中低 7 位是 RU 排列索引最高位表示中心 26-tone RU 是否被分配。协议里把“某信道宽度下、某 RU 组合方式”和索引对应成了一张大表比如 20MHz 下 9 个 26-tone RU 对应的索引是多少、1065226 混合组合对应多少都在表里定义。解析时直接拿这个 7 位索引查表就能还原出 RU 的排列方式。接着用户特定字段会给每个用户列出 STA-ID、MCS、NSTS空间流数、编码方式等信息。所以整个解析逻辑是先查公共字段确认 RU 分布再看用户字段确认每个用户和 RU 的对应关系。实际开发中如果用 Wireshark 看抓包结果这些字段都已经解码好了不需要自己写查表逻辑但如果要做底层板卡调试还是得理解这套结构不然会被各种 Walsh、ID 索引绕晕。3.2 上行 OFDMATrigger Frame 怎么指挥终端上行 OFDMA 的资源分配信息不是放在 HE-SIG-B 里而是在 AP 发送的 Trigger Frame 中。Trigger Frame 的结构同样有 Common Info 和 User Info ListCommon Info 里携带触发类型、UL Length、上行带宽、GI 和 LTF 类型等公共参数User Info 里则有每个终端的 AID12、RU Allocation、UL MCS、空间流分配、UL Target Receive Power 等信息。这个 UL Target Receive Power 字段值得单独说一下。上行多用户同时传输时如果两个终端距离 AP 远近不同、发射功率又一样AP 接收到的信号强度就会差别很大近端强信号会把远端弱信号“吃掉”。所以 AP 会在触发帧里告诉每个终端你发过来的信号到达我这儿时希望是多少 dBm终端再根据自身路径损耗估算值调整发射功率让不同终端的到达功率基本一致。Trigger Frame 的类型也很有讲究。最常见的是 Basic Trigger用于普通的上行 OFDMA 数据传输还有一种叫 BSRP Trigger 的Poll 各终端有多少数据要发。AP 在调度上行资源前往往会先发一个 BSRP 问一遍各终端的 Buffer 状态知道谁有数据、有多少数据之后再决定下一轮 RU 分配。这个机制保证了上行资源不会白白分给无数据可发的终端。3.3 抓包实操从空中看一次 OFDMA 交互纸上谈兵没用我一般会用支持 monitor 模式的网卡直接抓空口报文观察 OFDMA 是否真的在工作。推荐用 Intel AX210 或者 MT7916 这类对 802.11ax 解码支持比较好的网卡做测试在 Linux 下开 monitor 模式的命令大致如下ip link set wlan0 down iw dev wlan0 set type monitor ip link set wlan0 up然后可以用 tshark 抓取特定类型的帧。Trigger Frame 在无线帧头里的 type/subtype 对应关系是 Control/Trigger可以在 Wireshark 里过滤wlan.fc.type_subtype 0x04来观察。抓到一个 Basic Trigger 后点开 User Info List能看到 AID、RU Allocation、UL MCS、Target RSSI 等字段这些就是 AP 给各终端安排资源的具体证据。有一次我在一个多终端办公环境里抓包看到一个 80MHz 带宽的 Trigger FrameUser Info 里同时列了 5 个终端的 RU 分配信息分别是不同大小的 RU 和不同的目标接收功率。从那以后我对 OFDMA 的感知就不再是“宣传页上的功能”而是能实实在在看见的东西。这里提醒一句如果你的测试网卡只支持到 802.11ac是解不出 HE 相关字段的看不到 RU 信息所以测试前先确认网卡能力。3.4 终端能力确认与 AP 侧配置做 OFDMA 测试前最好先确认终端有没有对应的能力位。Linux 下可以用iw phy phy0 info查看 HE Capabilities重点关注 OFDMA 相关的能力位以及支持的 RU 大小。有些老网卡虽然能连上 WiFi 6 路由器但在能力协商时根本没有声明支持 OFDMAAP 自然不会给它分配小 RU这时候你看着协商速率是 WiFi 6实际走的还是老一套单用户传输。AP 侧也一样。以 hostapd 为例要开启 802.11ax需要在配置里加ieee80211ax1 he_oper_chwidth2 he_oper_centr_freq_seg0_idx0ieee80211ax1是开启 HE 模式的总开关he_oper_chwidth设置 HE 操作信道宽度我这里给的是 80MHz 的示意。不同版本的 hostapd 对参数命名有差异有些厂商固件还会在 Web 界面专门提供“上行 OFDMA”开关但背后的逻辑是一样的HE 开启之后OFDMA 调度能力才存在具体能调度多好还要看驱动实现。4. 真实场景下的调度策略与性能影响4.1 AP 调度器是如何决策的OFDMA 资源分配表面上是个物理层概念但真正决定用户体验的是 MAC 层的调度器。AP 会综合考虑每个终端的 Buffer 状态、队列优先级、历史速率、信道质量、支持的 MCS以及当前信道的整体负载然后决定这一轮 RU 怎么切、切多大、给谁用。一个比较典型的调度流程是AP 先周期性发 BSRP让终端上报“我缓存里有 X 字节要发”然后调度器根据这些信息把大 RU 分给数据量大的终端小 RU 分给数据量小的终端如果信道质量差的终端分到大 RU还会伴随 MCS 降级保证传输可靠性。实际产品里各家方案的调度算法差别很大有的偏向公平性有的偏向低时延有的偏向最大化吞吐这也是为什么同一个路由器刷了不同固件后多用户体验会有明显差异。4.2 高密度场景下 OFDMA 的收益到底有多大802.11ax 发布时官方宣传说相比 802.11ac 在高密度场景平均吞吐提升 4 倍这个数字不是跑单用户打流跑出来的而是多用户密集场景下的统计收益。OFDMA 减少的是协议开销和碰撞退避时间这对小报文密集的场景特别明显。我实测过一个 30 台终端同时在线、其中有 20 台在持续上报小数据的办公环境。关闭 OFDMA 时大量终端的 ACK 和状态上报报文排队等待信道空口利用率很高但有效吞吐很低时延抖动也大开启 OFDMA 之后AP 一个触发帧就能让多台上报终端同时发出数据信道竞争次数大幅下降时延明显变得平稳。相反如果只有一两台终端在传大文件OFDMA 的优势几乎体现不出来因为根本不需要并行调度单用户独占大 RU 反而更高效。4.3 打流实验怎么量化 OFDMA 的收益如果你想自己验证 OFDMA 的实际效果我建议准备一台支持 802.11ax 的 AP、至少两台支持 HE 的终端然后用 iperf3 做多用户上行并发测试。测试时注意固定测试变量把 AP 的信道和带宽固定例如锁定在 36 信道、80MHz所有终端连接同一个 SSID关闭不必要的漫游和省电先只跑一个终端的上行业务作为基线再同时跑多台终端的上行业务记录总吞吐和每台终端的平均时延。结果通常会看到两种情况如果 AP 的 OFDMA 调度做得好多终端并发时总吞吐不会比单终端低太多各终端的时延曲线也比较平稳如果 OFDMA 没生效或者调度策略很粗糙并发时的总吞吐可能掉得很厉害时延曲线抖动也严重。这里有个容易踩的坑有些 AP 固件默认没开上行 OFDMA只开了下行 OFDMA这时候你测上行并发性能自然没有提升测试前务必确认 AP 侧开关。5. 常见问题与排查技巧5.1 常见问题速查表现象可能原因排查思路协商速率是 WiFi 6但单用户打流跑不高链路余量不足、天线流数受限、信道带宽没对齐看 AP 和终端协商的 MCS、NSS、带宽检查信号强度多用户并发时总吞吐比单用户还低OFDMA 调度未生效或终端不支持 OFDMA抓 Trigger 帧确认 AP 是否真的在并行调度上行并发时延抖动很大上行 OFDMA 未开启或 Target RSSI 设置不合理检查 AP 的 UL OFDMA 开关观察 Trigger 帧里的发射功率控制某些终端在 WiFi 6 路由器上掉速或频繁重连驱动兼容性问题HE 能力协商异常更新终端驱动/固件尝试关闭 802.11ax 对比测试开启 WiFi 6 后 2.4GHz 频段稳定性变差2.4GHz 信道干扰较大OFDMA 调度收益被噪声抵消固定 20MHz 带宽或优先使用 5GHz 频段5.2 为什么 WiFi 6 协商速率很高实际吞吐上不去这是大家问得最多的一个问题。要明白一个前提协商速率是物理层在最理想条件下的极限速率实际吞吐要扣掉协议开销、导频开销、MAC 层竞争、重传、干扰等因素。即使是 160MHz、2x2、MCS11 协商到 2402Mbps实际 TCP 打流能跑到一半就已经表现不错了。OFDMA 在这里的角色也要正确理解它不是用来提升单用户峰值速率的而是让多个用户能更高效地共享信道。所以如果你只有一台终端跑不满协商速率不一定是 OFDMA 的问题先查信号强度、频段干扰、天线流数和 AP 配置。如果多台终端并发时整体体验明显变差这反而是 OFDMA 调度发挥作用的场景。5.3 关于 Realtek rtl8852be 等终端的兼容性经验很多笔记本和 USB 网卡用的是 Realtek 方案比如项目里经常见到的 Realtek RTL8852BE WiFi 6 PCIe Adapter。这类网卡在 Windows 下驱动相对完整日常使用没问题但在 Linux 下做协议调试就要留个心眼。rtl8852be 在 Linux 下主要靠 rtw89 驱动内核版本太老时不支持monitor 模式的支持也有限我试过在部分内核版本下开 monitor 抓包HE 字段解码不全很多 Trigger 帧解析不出来。实际项目中我会把这类网卡当作“普通终端”来测兼容性而不是当作协议分析工具。如果你手上只有 rtl8852be 的终端又怀疑 OFDMA 工作不正常最靠谱的办法是换一张 Intel AX210 或 MTK 的测试网卡做对照。另外记得先升级终端驱动和 AP 固件Realtek 网卡对部分 AP 的 HE 能力协商存在兼容问题表现为能连上但吞吐异常、掉线频繁升级驱动通常能解决大部分问题。5.4 几个值得记住的实战细节最后分享几个实操中总结出来的细节。第一测试 OFDMA 一定要制造“多用户上行小包并发”的场景单用户测试、纯下行大流量测试都说明不了问题第二抓包时如果看到 AP 周期性发 Trigger Frame且 User Info 里同时列出多个终端的 RU 分配说明 OFDMA 在工作不用再看别的指标第三AP 的 OFDMA 调度参数在很多固件里不开放给用户所以不要盲目相信路由器后台里的“OFDMA 开关”抓包才是验证手段第四2.4GHz 频段因为可用 RU 数量有限、干扰大OFDMA 收益不如 5GHz 明显实际部署时优先把高密度终端放在 5GHz。我个人在实际操作中的体会是OFDMA 这套机制最考验的不是物理层能不能实现而是 AP 的调度器够不够聪明。标准把规则定得很细但同一个 AP 芯片、不同固件版本多用户表现可能完全不同。所以做 WiFi 6 优化时别只盯着协商速率和天线数量多抓几次空口报文看看 Trigger Frame 的调度间隔和 RU 分配是否合理很多“路由器不好用”的问题都能在报文里找到答案。再补充一个小技巧如果你想把某个终端固定在某个 RU 上观察行为可以人为限制终端带宽或者调整 AP 侧的最小 RU 分配策略不同方案商的接口不一样但思路是共通的。这个内容后续还可以往 BSRP 调优、上行 OFDMA 随机接入UORA方向扩展那套机制在 IoT 场景里更能体现价值有机会再单独写一篇。
WiFi 6核心机制OFDMA：RU划分、调度原理与工程实践
做无线网络这一行早几年被问到最多的一句话就是WiFi 6 到底比 WiFi 5 快多少很多人张口就报协商速率2402Mbps、1201Mbps可实际用 iperf3 一打流往往只有几百兆于是开始怀疑设备是不是被坑了。其实 802.11axWiFi 6真正值钱的地方并不只是 1024-QAM 带来的那点峰值速率提升而是 OFDMA 这套资源分配机制带来的多用户并行能力。这篇就围绕 802.11ax 的 OFDMA 资源分配展开把 RU、HE-SIG-B、Trigger Frame 这些平时容易绕晕的概念串起来讲清楚也会把我自己在真实设备上的验证方法、踩坑记录一并分享出来。适合刚开始接触 WiFi 6 协议开发、做无线网优调试或者单纯想搞清楚“为什么 WiFi 6 在人多的地方更稳”的朋友。1. OFDMA 到底解决了什么问题1.1 传统 OFDM 的痛点在 802.11ax 之前802.11a/g/n/ac 用的都是 OFDM这种技术的思路是把一个信道分成很多正交子载波同一时刻所有子载波都服务于同一个终端。也就是说无论这个终端是传大文件还是只发一个几十字节的 ACK都要独占整个信道的全部子载波时间上严格串行。这个机制在终端少的时候问题不大但在高密度场景下就很尴尬。比如一个会议室里 30 台设备同时在用一台设备发一个很小的确认帧占着整个 20MHz 或者 80MHz 信道其他设备只能在旁边等着等它发完再通过 CSMA/CA 竞争信道赢了才能用自己的全信道资源。更麻烦的是管理帧、控制帧这类短报文非常频繁每一次都走完整的信道竞争、退避、确认流程大量空口时间都浪费在排队和碰撞退避上真正传业务数据的占比反而很低。我用一个收费站类比来说明传统 OFDM 就像一条只有一根车道的收费站不管后面排队的是一辆小面包车还是一辆大货车每次只放一辆车通过后面的车哪怕再急也得等着。车一多整条路就变成停车场。1.2 OFDMA 的核心理念与设计出发点OFDMA 的思路很简单既然一个信道里有很多子载波为什么不能把这些子载波按不同数量切成小组分给不同的终端同时使用每个小组就是一个资源单元Resource UnitRU不同终端可以在同一个信道里各自占用不同的 RU 并行收发这就是 802.11ax 相对 802.11ac 最大的协议层变化。从物理层角度看OFDMA 能成立是因为 802.11ax 把子载波间隔从 312.5kHz 缩小到了 78.125kHzOFDM 符号时长从 3.2μs 拉长到 12.8μs。子载波间隔变小、符号变长意味着一个符号内的子载波数量变多了可以更灵活地划分子组。打个比方原来一条马路只是单车道现在路还是那么宽但被重新画线划成了好几条窄车道不同方向的车可以各走各的道。OFDMA 的价值主要有三点。第一是降低时延多个终端可以在同一时刻并行传输不需要反复竞争信道第二是提升频谱利用率短帧、控制帧也可以和其他业务一起复用信道不再单独占满整个带宽第三是改善高密度场景的公平性AP 可以主动调度不同终端的 RU而不是让所有终端靠“抢”来决定谁先发。1.3 上行和下行两条路径都要管OFDMA 在实际工作中分成下行和上行两种情况这也是很多初学朋友容易搞混的地方。下行 OFDMA 由 AP 主动发起。AP 把要发给多个终端的数据打包进一个 HE MU PPDU多用户物理层协议数据单元在帧里标明每个终端各自用哪个 RU一口气发出去。终端收到后解析 HE-SIG-B 字段找到属于自己的 RU 位置取走属于自己的数据。上行 OFDMA 则没有那么简单因为多个终端要同时往 AP 发数据如果没有统一指挥时间、频率、功率都对齐不了。802.11ax 的解决办法是让 AP 先发一个 Trigger Frame触发帧这个帧里包含了每个终端允许使用的 RU、传输时长、MCS、目标接收功率等信息终端收到触发帧后在指定时间、指定 RU 上同时发送 HE TB PPDU。所以上行 OFDMA 本质上是一个“AP 点名终端按点应答”的机制。理解了这两条路径之后接下来要深入的核心自然就浮出来了RU 是怎么划分的AP 又是怎么把这些 RU 分给不同终端的。2. 资源分配的核心RU 与信道划分2.1 RU 是什么里面到底有多少子载波RU 是 OFDMA 资源分配的最小单位802.11ax 标准里定义了 26-tone、52-tone、106-tone、242-tone、484-tone、996-tone 等几种 RU 类型。这里的 tone 指的就是子载波26-tone RU 表示这个 RU 包含 26 个子载波带宽大约是 26×78.125kHz≈2.03MHz。不过并不是 RU 里所有子载波都用来传数据。每个 RU 里都要留出导频子载波用于信道估计和相位跟踪剩下才是数据子载波。下面是各类型 RU 的详细参数这个表在做速率估算时非常有用RU 类型总子载波数数据子载波数导频子载波数约占用带宽26-tone262422.03MHz52-tone524844.06MHz106-tone10610248.28MHz242-tone242234818.91MHz484-tone4844681637.81MHz996-tone9969801677.81MHz这里特别提醒一句网上有些资料为了简化会把 26-tone RU 写成“两个导频、24 个数据子载波”但在实际抓包解析时你还会看到 DC 子载波、null 子载波、guard tone 这些概念。简单理解就是不是所有子载波都能干活物理信道两侧要留保护带中心频点附近也要留空防止直流偏置和相邻信道干扰。所以一个 20MHz 信道虽然总共有 256 个子载波但真正能用于 RU 划分的只有 242 个左右。2.2 不同信道宽度下的 RU 组合规则RU 划分的规则决定了 AP 能把信道切成多少片。以 20MHz 信道为例可以全部切成 9 个 26-tone RU也可以切出 4 个 52-tone RU或者 2 个 106-tone RU再不济就是一个完整的 242-tone RU 给单个用户用。当然也可以混合分配比如一个 20MHz 信道里同时存在 106-tone 52-tone 26-tone 的组合只要不超出信道总容量就行。40MHz 信道可以拆出 18 个 26-tone RU80MHz 信道可以拆出 37 个 26-tone RU160MHz 则是在两个 80MHz 上各做一次 RU 分配。需要注意的是当信道带宽大于 20MHz 时中心频点附近会单独留出一个 26-tone RU 的位置协议里叫 center 26-tone RU。这个 RU 不是在所有帧里都会被分配如果分配了需要在 RU Allocation 字段的最高位做个特殊标记后面讲报文结构时还会提到。从实际操作角度讲RU 组合规则的细节一般不需要工程师去背标准里给了完整表格写解析代码时直接查表即可。但有一个原则要记住RU 越细能同时服务的用户数越多但每个用户的可用子载波越少单用户峰值速率越低RU 越粗单用户体验越好但能并行服务的用户数就少了。AP 的调度器就是在“多用户并行”和“单用户速率”之间找平衡。2.3 RU 大小如何与业务需求匹配分配 RU 不能一刀切。一个只发心跳包、状态上报的 IoT 设备一次就几个字节的数据给它分配一个 242-tone RU 纯属浪费一个正在看高清视频或者传大文件的终端如果只给一个 26-tone RU实际速率会低到没法用。正常调度器的思路是这样小 RU 优先给短报文、低优先级、对时延不敏感的小流量设备大 RU 优先给持续发送、对吞吐有要求的业务。比如一个 20MHz 信道被切成 9 个 26-tone RUAP 可以让 9 个智能插座同时上报状态每个插座的数据都在自己的小 RU 里并行传完这在传统 OFDM 机制下需要 9 次完整的信道竞争和传输效率差距肉眼可见。MCS调制编码策略也会影响 RU 的选择。同样一个 26-tone RU终端信道质量好、支持 256QAM 甚至 1024QAM 时能传更多 bit但信道质量差时调度器只能降低 MCS这时小 RU 的数据承载能力就更有限。所以 AP 调度器通常还会参考终端反馈的信道状态信息和重传率动态调整 RU 大小和 MCS 的组合。2.4 OFDMA 与 MU-MIMO 的叠加关系很多人以为 OFDMA 和 MU-MIMO 是同一回事实际上两者是互补的。OFDMA 是在频域上区分用户MU-MIMO 是在空间域上区分用户。802.11ax 允许这两者叠加使用同一个 RU 上可以同时给多个空间流用户传输数据。举个例子AP 有 4 根天线一个 80MHz 信道被切成两个 RURU1 里用两条空间流给终端 A 传视频同时用另外两条空间流给终端 B 传文件RU2 里再用两条空间流给终端 C 传数据。这样频域和空域都被充分利用了效率自然比单独用 OFDMA 或单独用 MU-MIMO 高得多。协议上一个 HE MU PPDU 最多可以调度 8 个用户每个用户最多 4 条空间流单个 PPDU 的总空间流数不超过 8。实际能调度几个用户还要看 AP 的硬件能力、天线数量以及终端的 MU-MIMO 反馈能力。这里有个经验很多中低端家用路由器虽然在包装上印了 MU-MIMO但实际只支持 OFDMA或者只支持下行 MU-MIMO上行 MU-MIMO 基本是摆设测试时不要被宣传参数误导。3. OFDMA 资源分配在报文里是怎么表达的3.1 下行 HE MU PPDU 里的 HE-SIG-B 字段对于搞协议分析和驱动开发的人来说光知道 RU 的划分规则还不够得能从报文里读出 AP 到底把哪个 RU 分给了哪个用户。下行多用户传输靠的是 HE MU PPDU这个帧的 HE-SIG-B 字段就是 RU 分配信息的载体。HE-SIG-B 分为公共字段和用户特定字段两部分。公共字段里有一个 RU Allocation 子字段长度是 8 bit其中低 7 位是 RU 排列索引最高位表示中心 26-tone RU 是否被分配。协议里把“某信道宽度下、某 RU 组合方式”和索引对应成了一张大表比如 20MHz 下 9 个 26-tone RU 对应的索引是多少、1065226 混合组合对应多少都在表里定义。解析时直接拿这个 7 位索引查表就能还原出 RU 的排列方式。接着用户特定字段会给每个用户列出 STA-ID、MCS、NSTS空间流数、编码方式等信息。所以整个解析逻辑是先查公共字段确认 RU 分布再看用户字段确认每个用户和 RU 的对应关系。实际开发中如果用 Wireshark 看抓包结果这些字段都已经解码好了不需要自己写查表逻辑但如果要做底层板卡调试还是得理解这套结构不然会被各种 Walsh、ID 索引绕晕。3.2 上行 OFDMATrigger Frame 怎么指挥终端上行 OFDMA 的资源分配信息不是放在 HE-SIG-B 里而是在 AP 发送的 Trigger Frame 中。Trigger Frame 的结构同样有 Common Info 和 User Info ListCommon Info 里携带触发类型、UL Length、上行带宽、GI 和 LTF 类型等公共参数User Info 里则有每个终端的 AID12、RU Allocation、UL MCS、空间流分配、UL Target Receive Power 等信息。这个 UL Target Receive Power 字段值得单独说一下。上行多用户同时传输时如果两个终端距离 AP 远近不同、发射功率又一样AP 接收到的信号强度就会差别很大近端强信号会把远端弱信号“吃掉”。所以 AP 会在触发帧里告诉每个终端你发过来的信号到达我这儿时希望是多少 dBm终端再根据自身路径损耗估算值调整发射功率让不同终端的到达功率基本一致。Trigger Frame 的类型也很有讲究。最常见的是 Basic Trigger用于普通的上行 OFDMA 数据传输还有一种叫 BSRP Trigger 的Poll 各终端有多少数据要发。AP 在调度上行资源前往往会先发一个 BSRP 问一遍各终端的 Buffer 状态知道谁有数据、有多少数据之后再决定下一轮 RU 分配。这个机制保证了上行资源不会白白分给无数据可发的终端。3.3 抓包实操从空中看一次 OFDMA 交互纸上谈兵没用我一般会用支持 monitor 模式的网卡直接抓空口报文观察 OFDMA 是否真的在工作。推荐用 Intel AX210 或者 MT7916 这类对 802.11ax 解码支持比较好的网卡做测试在 Linux 下开 monitor 模式的命令大致如下ip link set wlan0 down iw dev wlan0 set type monitor ip link set wlan0 up然后可以用 tshark 抓取特定类型的帧。Trigger Frame 在无线帧头里的 type/subtype 对应关系是 Control/Trigger可以在 Wireshark 里过滤wlan.fc.type_subtype 0x04来观察。抓到一个 Basic Trigger 后点开 User Info List能看到 AID、RU Allocation、UL MCS、Target RSSI 等字段这些就是 AP 给各终端安排资源的具体证据。有一次我在一个多终端办公环境里抓包看到一个 80MHz 带宽的 Trigger FrameUser Info 里同时列了 5 个终端的 RU 分配信息分别是不同大小的 RU 和不同的目标接收功率。从那以后我对 OFDMA 的感知就不再是“宣传页上的功能”而是能实实在在看见的东西。这里提醒一句如果你的测试网卡只支持到 802.11ac是解不出 HE 相关字段的看不到 RU 信息所以测试前先确认网卡能力。3.4 终端能力确认与 AP 侧配置做 OFDMA 测试前最好先确认终端有没有对应的能力位。Linux 下可以用iw phy phy0 info查看 HE Capabilities重点关注 OFDMA 相关的能力位以及支持的 RU 大小。有些老网卡虽然能连上 WiFi 6 路由器但在能力协商时根本没有声明支持 OFDMAAP 自然不会给它分配小 RU这时候你看着协商速率是 WiFi 6实际走的还是老一套单用户传输。AP 侧也一样。以 hostapd 为例要开启 802.11ax需要在配置里加ieee80211ax1 he_oper_chwidth2 he_oper_centr_freq_seg0_idx0ieee80211ax1是开启 HE 模式的总开关he_oper_chwidth设置 HE 操作信道宽度我这里给的是 80MHz 的示意。不同版本的 hostapd 对参数命名有差异有些厂商固件还会在 Web 界面专门提供“上行 OFDMA”开关但背后的逻辑是一样的HE 开启之后OFDMA 调度能力才存在具体能调度多好还要看驱动实现。4. 真实场景下的调度策略与性能影响4.1 AP 调度器是如何决策的OFDMA 资源分配表面上是个物理层概念但真正决定用户体验的是 MAC 层的调度器。AP 会综合考虑每个终端的 Buffer 状态、队列优先级、历史速率、信道质量、支持的 MCS以及当前信道的整体负载然后决定这一轮 RU 怎么切、切多大、给谁用。一个比较典型的调度流程是AP 先周期性发 BSRP让终端上报“我缓存里有 X 字节要发”然后调度器根据这些信息把大 RU 分给数据量大的终端小 RU 分给数据量小的终端如果信道质量差的终端分到大 RU还会伴随 MCS 降级保证传输可靠性。实际产品里各家方案的调度算法差别很大有的偏向公平性有的偏向低时延有的偏向最大化吞吐这也是为什么同一个路由器刷了不同固件后多用户体验会有明显差异。4.2 高密度场景下 OFDMA 的收益到底有多大802.11ax 发布时官方宣传说相比 802.11ac 在高密度场景平均吞吐提升 4 倍这个数字不是跑单用户打流跑出来的而是多用户密集场景下的统计收益。OFDMA 减少的是协议开销和碰撞退避时间这对小报文密集的场景特别明显。我实测过一个 30 台终端同时在线、其中有 20 台在持续上报小数据的办公环境。关闭 OFDMA 时大量终端的 ACK 和状态上报报文排队等待信道空口利用率很高但有效吞吐很低时延抖动也大开启 OFDMA 之后AP 一个触发帧就能让多台上报终端同时发出数据信道竞争次数大幅下降时延明显变得平稳。相反如果只有一两台终端在传大文件OFDMA 的优势几乎体现不出来因为根本不需要并行调度单用户独占大 RU 反而更高效。4.3 打流实验怎么量化 OFDMA 的收益如果你想自己验证 OFDMA 的实际效果我建议准备一台支持 802.11ax 的 AP、至少两台支持 HE 的终端然后用 iperf3 做多用户上行并发测试。测试时注意固定测试变量把 AP 的信道和带宽固定例如锁定在 36 信道、80MHz所有终端连接同一个 SSID关闭不必要的漫游和省电先只跑一个终端的上行业务作为基线再同时跑多台终端的上行业务记录总吞吐和每台终端的平均时延。结果通常会看到两种情况如果 AP 的 OFDMA 调度做得好多终端并发时总吞吐不会比单终端低太多各终端的时延曲线也比较平稳如果 OFDMA 没生效或者调度策略很粗糙并发时的总吞吐可能掉得很厉害时延曲线抖动也严重。这里有个容易踩的坑有些 AP 固件默认没开上行 OFDMA只开了下行 OFDMA这时候你测上行并发性能自然没有提升测试前务必确认 AP 侧开关。5. 常见问题与排查技巧5.1 常见问题速查表现象可能原因排查思路协商速率是 WiFi 6但单用户打流跑不高链路余量不足、天线流数受限、信道带宽没对齐看 AP 和终端协商的 MCS、NSS、带宽检查信号强度多用户并发时总吞吐比单用户还低OFDMA 调度未生效或终端不支持 OFDMA抓 Trigger 帧确认 AP 是否真的在并行调度上行并发时延抖动很大上行 OFDMA 未开启或 Target RSSI 设置不合理检查 AP 的 UL OFDMA 开关观察 Trigger 帧里的发射功率控制某些终端在 WiFi 6 路由器上掉速或频繁重连驱动兼容性问题HE 能力协商异常更新终端驱动/固件尝试关闭 802.11ax 对比测试开启 WiFi 6 后 2.4GHz 频段稳定性变差2.4GHz 信道干扰较大OFDMA 调度收益被噪声抵消固定 20MHz 带宽或优先使用 5GHz 频段5.2 为什么 WiFi 6 协商速率很高实际吞吐上不去这是大家问得最多的一个问题。要明白一个前提协商速率是物理层在最理想条件下的极限速率实际吞吐要扣掉协议开销、导频开销、MAC 层竞争、重传、干扰等因素。即使是 160MHz、2x2、MCS11 协商到 2402Mbps实际 TCP 打流能跑到一半就已经表现不错了。OFDMA 在这里的角色也要正确理解它不是用来提升单用户峰值速率的而是让多个用户能更高效地共享信道。所以如果你只有一台终端跑不满协商速率不一定是 OFDMA 的问题先查信号强度、频段干扰、天线流数和 AP 配置。如果多台终端并发时整体体验明显变差这反而是 OFDMA 调度发挥作用的场景。5.3 关于 Realtek rtl8852be 等终端的兼容性经验很多笔记本和 USB 网卡用的是 Realtek 方案比如项目里经常见到的 Realtek RTL8852BE WiFi 6 PCIe Adapter。这类网卡在 Windows 下驱动相对完整日常使用没问题但在 Linux 下做协议调试就要留个心眼。rtl8852be 在 Linux 下主要靠 rtw89 驱动内核版本太老时不支持monitor 模式的支持也有限我试过在部分内核版本下开 monitor 抓包HE 字段解码不全很多 Trigger 帧解析不出来。实际项目中我会把这类网卡当作“普通终端”来测兼容性而不是当作协议分析工具。如果你手上只有 rtl8852be 的终端又怀疑 OFDMA 工作不正常最靠谱的办法是换一张 Intel AX210 或 MTK 的测试网卡做对照。另外记得先升级终端驱动和 AP 固件Realtek 网卡对部分 AP 的 HE 能力协商存在兼容问题表现为能连上但吞吐异常、掉线频繁升级驱动通常能解决大部分问题。5.4 几个值得记住的实战细节最后分享几个实操中总结出来的细节。第一测试 OFDMA 一定要制造“多用户上行小包并发”的场景单用户测试、纯下行大流量测试都说明不了问题第二抓包时如果看到 AP 周期性发 Trigger Frame且 User Info 里同时列出多个终端的 RU 分配说明 OFDMA 在工作不用再看别的指标第三AP 的 OFDMA 调度参数在很多固件里不开放给用户所以不要盲目相信路由器后台里的“OFDMA 开关”抓包才是验证手段第四2.4GHz 频段因为可用 RU 数量有限、干扰大OFDMA 收益不如 5GHz 明显实际部署时优先把高密度终端放在 5GHz。我个人在实际操作中的体会是OFDMA 这套机制最考验的不是物理层能不能实现而是 AP 的调度器够不够聪明。标准把规则定得很细但同一个 AP 芯片、不同固件版本多用户表现可能完全不同。所以做 WiFi 6 优化时别只盯着协商速率和天线数量多抓几次空口报文看看 Trigger Frame 的调度间隔和 RU 分配是否合理很多“路由器不好用”的问题都能在报文里找到答案。再补充一个小技巧如果你想把某个终端固定在某个 RU 上观察行为可以人为限制终端带宽或者调整 AP 侧的最小 RU 分配策略不同方案商的接口不一样但思路是共通的。这个内容后续还可以往 BSRP 调优、上行 OFDMA 随机接入UORA方向扩展那套机制在 IoT 场景里更能体现价值有机会再单独写一篇。
