Wi-Fi 6 ax调度全解析：从OFDMA到BSS Coloring的实战指南

如果你最近在翻无线网络相关的资料，大概率会看到“ax”和“ax调度”这两个词绑在一起出现。这不是某个新出的命令行工具，也不是哪家厂商标的硬件型号，而是 IEEE 802.11ax，也就是 Wi-Fi 联盟改名之后的 Wi-Fi 6。前面的“ax调度”，说的就是 Wi-Fi 6 最核心的那套从“随机竞争”转向“统一分配”的无线资源调度机制。我做了不少年无线网络运维和测试，可以负责任地说，ax 能带来的实际提升，七成体现在调度上，而不是那个纸面上的峰值速率。这篇文章就把 ax 调度这套东西从头到尾捋一遍，适合刚接触 Wi-Fi 6 的网络工程师、做无线路由/AP 测试的伙伴，也适合在校学生想搞懂“OFDMA 到底怎么调度”这类问题。我会从原理讲到验证，把每个机制背后的“为什么”说清楚，最后给到能直接抄作业的排查思路。

1. ax调度到底在解决什么问题

1.1 “ax”是什么：从协议代号到Wi-Fi 6

还没接触 802.11 之前，我一度以为“ax”只是厂商为了推销路由器的营销代号，后来自己做无线抓包和协议分析才搞清楚：ax 是一个实打实的 IEEE 标准编号，全称 802.11ax，它所对应的就是 Wi-Fi 联盟统一认证名称里的 Wi-Fi 6。Wi-Fi 联盟把 802.11n 叫 Wi-Fi 4，把 802.11ac 叫 Wi-Fi 5，把 802.11ax 叫 Wi-Fi 6，本质上是为了让普通用户能直观地对比不同世代。

从协议演进的逻辑看，每一代解决的核心矛盾都不一样。802.11a/b/g 时代解决的是“能不能稳定接入”；802.11n 通过 MIMO 和 40MHz 信道把速率带了起来；802.11ac 继续在 5GHz 上把物理层速率推到千兆级，让“单用户的峰值速率”这个指标变得非常好看。但到了今天，网络里早就不是“几个人用手机刷网页”这种低密度场景，而是会议室、体育场、智慧工厂、医院门诊这种动辄几十上百个终端挤在同一片区域、同时传输小报文和高清视频的复杂环境。802.11ac 那套“一次只服务一个用户，把链路尽量跑到最快”的设计思路，在高密度场景下会迅速碰壁。802.11ax 正是在这种背景下出现的，它的设计目标优先级里，效率、容量、延迟和功耗降低反而排在了单纯峰值速率前面。这也是为什么我会格外关注 ax 调度——因为调度机制正是达成这些目标的骨架。

我在好几个项目里见过有人拿着 Wi-Fi 6 路由器测单用户 Speedtest，测出接近 1Gbps 就直呼厉害，其实这根本没触到 ax 的核心。ax 和 ac 在单用户、良好信噪比下的差距没有想象中大，真正的分水岭是在高密度下表现。

1.2 老Wi-Fi的瓶颈：一次只服务一个终端

传统 Wi-Fi 在介质访问上走的是 CSMA/CA 机制，也就是带冲突避免的载波侦听多路访问。所有终端共享同一个信道，发送之前先听信道，空闲了再发，如果撞车就退避重来。这个机制本身没什么问题，问题出在“所有人在一条路上排队”这件事上。你可以把它想象成一条没有信号灯的窄路，任何两辆车同时上路就会堵住，所有人只能靠默契和等待来通行。当终端数量少、流量小的时候，这种机制够用；可当 20 个终端同时需要上传数据，信道里就会充满 RTS/CTS 握手、ACK 确认和随机回退时间，真正传数据的时间占比低得可怜。

更要命的是隐藏节点问题。两个终端都离 AP 不远，但它们互相听不见对方的发射，于是很容易同时发起传输，导致 AP 侧完全收不到有效帧。为了缓解这个问题，协议又加了一堆保护机制，结果就是空口利用率进一步下降。实际办公场景里，我见过 5GHz 空口利用率跑满 80%，但业务吞吐只有理论速率三成不到的情况，问题几乎都出在并发竞争上。

ax 的破局思路是：不再让终端之间互相“抢”，而是让 AP 变成调度中心。

1.3 ax调度的整体框架：时间、频率、空间联合分配

802.11ax 引入的调度框架，可以概括成三个维度的联合分配：时间、频率和空间，再叠加功耗维度的唤醒调度。频率维度由 OFDMA 负责，它把信道切成一个个小的资源单元，按需分配给不同终端；空间维度由 MU-MIMO 负责，利用多根天线形成多个空间流，让多个终端在同一时间同一频段上并行传输；时间维度则由 TWT 负责，AP 和终端约定好唤醒时间，避免所有设备在同一时间争抢信道；而在更大尺度上，BSS Coloring 和空间复用调度把“相邻 AP 必须互相避让”的规则改成了“颜色不同就允许并行传输”，让整个区域的频谱效率进一步提升。

这几个机制不是各自独立的，它们在一次完整的传输里会叠加工作。比如一个 HE MU PPDU 里，AP 可能同时给四个站点发数据：两个站点走 OFDMA 的不同 RU，另外两个站点在同一个 RU 里走 MU-MIMO 的多流。终端可以是 OFDMA 和 MU-MIMO 的混合参与者，这正是 ax 和 ac 在实现复杂度上拉开差距的地方。运维人员如果只盯着“开关”看不看协同效果，很容易出现配置了但业务没有改善的情况。

下表格能看清每个子机制的定位：

2. 四大调度机制的核心细节与实操要点

2.1 OFDMA调度：把信道切成小格子按需分配

OFDMA 的全称是正交频分多址，它把原来的整条信道拆成多个子载波组，每组称为一个资源单元，英文缩写是 RU。以 20MHz 信道为例，它可以被拆成 9 个 26-tone 的最小 RU、4 个 52-tone RU、2 个 106-tone RU，或者干脆整条信道给一个用户使用 242-tone RU。不同 RU 大小对应的吞吐能力不同，但调度并不仅仅是“切得越碎越好”。如果所有终端都在传大文件，把小 RU 分给他们反而会让多次传输的控制开销吞掉收益；如果传的是各类传感器心跳、即时消息、语音包这种小报文，把信道切成多个小 RU 让十几个终端一起传，延迟能大幅下降。

OFDMA 的调度的核心对象是上行和下行两个方向。下行 OFDMA 相对好理解：AP 把多个终端的报文拼到一个物理帧里，在同一个传输机会中一起发出去，终端只需解析属于自己的 RU。上行 OFDMA 更复杂一些，由 AP 发送 Trigger 帧来发起，Trigger 帧里包含了每个终端被分配到的 RU 位置、传输时长和允許的 MCS 等参数，终端收到触发后在同一时刻并行上传。

这里有个很容易忽略的实操点：上行 OFDMA 对终端同步要求很高，不同终端的时钟偏差会让 RU 互相干扰。因此协议定义了前导码重复机制和更长的 GI（保护间隔），如果你在配置 AP 时发现上行 OFDMA 反复失败，优先检查 GI 设置和 AP 的时频同步模块。我一般建议在噪声比较干净的室内环境使用 1.6μs GI，在干扰复杂的厂房环境回到 3.2μs GI，虽然速率略有下降，但调度稳定性好得多。

另一个常见误区是只看 AP 开了 OFDMA 就默认所有终端都在走 OFDMA。实际抓包里，只有支持 802.11ax 的终端才会参与 OFDMA 调度，大量 802.11ac 终端依然走传统 SU 传输。所以验证时一定要用两台以上 11ax 终端，并且确认它们的 HE 能力位都协商成功。

2.2 MU-MIMO调度：多流并行和天线资源的调度

MU-MIMO 并不是 802.11ax 的首创，802.11ac Wave 2 已经支持下行 MU-MIMO，但实现得比较“鸡肋”。到了 ax，上行 MU-MIMO 被正式补齐，同时 OFDMA 和 MU-MIMO 还能叠加使用，这就让“空间”这个维度的调度真正有了价值。

MU-MIMO 的原理是基于多根天线形成的多个空间流。AP 有四根天线，就能最多同时形成四条空间数据流，理论上可以给四个不同终端各发一条流，或者给两个 2x2 终端各发两条流。要让这些空间流互不干扰，AP 必须知道每个终端的信道状态信息。终端会在协商阶段反馈 CSI（信道状态信息），AP 随后做波束成形，把信号“瞄准”目标终端，同时尽量在其它终端的路径上形成零陷。

实操中我最常遇到的问题不是“空间流不够”，而是“终端天线数量不匹配”。很多手机、笔记本只有 1x1 或 2x2 天线，你却硬开 4x4 MU-MIMO，结果某些流上信噪比很差，AP 为了保护重传率，只能把 MCS 压得很低，整体收益反而还不如老老实实做 SU MIMO。正确的思路是先看终端 HE Capabilities 里的 RX Spatial Stream 数量，再决定 AP 侧 MU-MIMO 组队方案。做高密度场景测试时，我一般会准备三类终端：1x1 IoT 模组、2x2 手机/笔记本、4x4 测试网卡，分别验证不同组队下的吞吐。

同样要提醒的是，MU-MIMO 只有在信道信息相对准确时才有效。移动中的终端，尤其是快速走动的人，信道变化很快，AP 刚刚算好的波束成形向量可能几十毫秒后就失效。所以车站、机场这类人员流动很大的场景，没必要迷信 MU-MIMO，OFDMA 反而更可靠。

2.3 TWT调度：让终端按“闹钟”休眠与唤醒

TWT（Target Wake Time）是个很容易被低估的机制。它的核心思想是让终端和 AP 约定一个“作息表”，终端大部分时间休眠，只在约定时间醒来收发数据。这个机制最初是为了解决 WiFi 功耗问题，但用在大规模高密场景里，它还有另一层价值：避免所有终端在同一时间醒来抢信道。

TWT 分成两种工作模式。Individual TWT 是每个终端单独和 AP 协商自己的唤醒周期，适合 IoT 传感器、智能门锁这类业务规律很强的设备；Broadcast TWT 是 AP 广播一组公共的唤醒时间表，多个终端按统一节奏唤醒，适合智能照明、楼宇自控这类批量设备。在信标帧和探测响应帧里，AP 会通告自己的 TWT 支持能力，之后通过 TWT Setup 帧协商出每个终端的唤醒时间。

实操里最容易翻车的点在于：TWT 调得激进会让终端访问延迟显著上升。设备大部分时间在睡觉，业务随机来临时必须等到下一个约定的唤醒窗口。做 VoWiFi 或实时控制类业务时，一定不要把 TWT 周期设得过长，我默认会把实时终端放进免 TWT 或短 TWT 的 SSID，IoT 终端单独划一个 SSID 用长周期 TWT。这个“按业务类型分流，而不是按终端型号分流”的做法，能让调度效率和用户体验都保住。

另外，老终端完全不认识 TWT 帧，AP 开了强制 TWT 后它们很可能会频繁断线。厂商固件里一般会有 compatibility 模式，建议开启兼容模式，或者在 Beacon 里只通告 TWT 能力而不强制，让支持者自动使用TWT，让不支持者走传统流程。

2.4 BSS Coloring与空间复用：让相邻小区也能并行传输

传统 Wi-Fi 的 CCA（信道空闲评估）机制非常“一刀切”：只要检测到信道上有任何信号，不管强度多低，都会判断信道忙。这在两个相隔较远的 AP 覆盖边缘地带造成大量无谓退避。BSS Coloring 的做法很直接：每个 BSS 在信号里打上一个颜色标识，终端收到帧时先看颜色，如果是相同颜色，说明是本 BSS 的帧，遵循传统避让；如果是不同颜色，则允许根据 OBSS_PD 阈值决定是否忽略它并继续传输。

从 ax 调度角度看，BSS Coloring 等于在空间维度上把“绝对避让”改成了“有条件并行”，相当于把整片区域所有 AP 的信道利用率一起盘活。它特别适合高密办公区里相邻 AP 使用同信道的部署。每家厂商都有类似“空间复用”或“SR”的开关，但决定调度质量的关键参数是可调整的 OBSS_PD 阈值。阈值设得太高，被忽略的异色信号可能还是真实干扰，导致本 BSS 的用户收包失败；设得太低，又无法获得并行收益。这个值通常要结合现场路测的 SINR 数据来微调，不能照搬某个万能参数。

我在密集 AP 场景里习惯的做法是：先把所有 AP 的发射功率降低到覆盖恰好重叠的程度，再开 BSS Coloring，并做一组“关 BSS Coloring/开 BSS Coloring”的对比测试。对比指标不是单用户速率，而是整片区域的总吞吐和时延 P95。只要总吞吐明显上升且丢包率没恶化，就说明调度方向是对的。

3. 从规划到验证：AX调度的实操落地

3.1 先做射频规划：信道带宽直接决定调度空间

很多工程师一上来就在控制器里点 OFDMA、MU-MIMO，结果现场效果平平，回来问原因。我通常会反问一句：你先做了信道规划吗？因为 ax 调度是基于信道的，信道带宽直接决定了 OFDMA 能切出多少 RU，也决定了 MU-MIMO 的并行空间。

我常用的一张带宽选择表如下：

看到这张表你就明白了：如果某个区域有几十个并发终端，强行用 160MHz 反而浪费——你这么宽的信道里，大量 RU 虽然存在，但终端数量根本吃不满，而且宽信道更容易受干扰，稍微有雷达信号或邻频干扰就要退避。我在写字楼项目里基本只用 80MHz，配合 OFDMA 让十几个终端在一帧里并行，效果远比 160MHz 好。

规划之外还要注意信道内的噪声地板。AX 调度对信噪比的要求比 ac 时代敏感，如果底噪高过一定水平，即使 RU 分配得再合理，MCS 也上不去。进场前先用频谱仪扫一遍现场，确认没有直放站干扰、微波干扰，再决定开多大带宽。这一步别省，出了问题再回头排查成本高得多。

3.2 在无线控制器上打开AX调度相关开关

不同品牌的企业无线控制器，界面和命令关键字不一样，但核心参数基本逃不出下面这几类：OFDMA 开关、MU-MIMO 开关、TWT 开关、BSS Coloring 开关、空间复用阈值。我以某一类常见控制器的 radio-profile 配置为例，说明参数在哪里、为什么要这样配。下面的命令是伪 CLI，仅用于理清配置思路，现场以厂商手册为准。

# 进入AX射频模板并命名 radio-profile "AX-HIGHDENSITY" # 启用OFDMA，且下行/上行都开 # 下行是对AP发往多终端生效，上行是对终端并行上传生效 he-ofdma enable he-ofdma-dl enable he-ofdma-ul enable # 启用MU-MIMO，按AP天线能力选择最大空间流 mu-mimo enable mu-mimo-max-streams 4 # 启用TWT，并允许兼容传统终端 he-twt enable he-twt-mode compatible # BSS Coloring 与空间复用 bss-coloring enable obss-pd-threshold -72

在这个配置里，obss-pd-threshold 是个需要结合现场调的值。数值越高，表示越敢于忽略异色信号。一般现场噪声低、AP间距近时，可以从 -72 起步测试；如果同频干扰重，我会往 -78 以下压。不要盲目抄网上的“最佳阈值”，每个现场底噪不一样。

配置完成后，还要检查终端的接入策略。比如把支持 11ax 且对时延敏感的设备放到一个 SSID，开启 OFDMA 和 TWT 兼容；把 IoT 设备放到另一个 SSID，TWT 周期调长。AP 会为每个 SSID 维护一套调度参数，这种“按业务切片”的做法在厂商文档里叫 per-SSID radio profile，实践里非常管用。

3.3 用Wireshark验证AX调度是否真的生效

开机抓包验证是了解 ax 调度到底干没干活的唯一可靠手段。抓包工具的选择比较讲究，普通笔记本的无线网卡不一定支持 802.11ax 监听模式。我自己常用的是一块支持 monitor mode 的 11ax USB 网卡，配合 Wireshark 就能直接解析 HE 帧。

抓包前把抓包网卡固定到目标 AP 的信道，用 80MHz 频宽监听 5GHz 频段。Wireshark 打开抓包文件后，先用过滤器把 HE 相关的管理帧和数据帧筛出来。一个比较高效的组合是看 Trigger 帧和 HE MU PPDU：

# 筛选包含HE信息的各类帧 wlan_he # 筛选触发帧，也就是AP发起的上行调度指令 wlan.fc.type_subtype == 0x1d # 筛选HE MU PPDU的数据帧（下行多用户传输） wlan_he.ppdu_type == 1

看到 Trigger 帧，说明 AP 确实在做上行 OFDMA 调度；看到 HE MU PPDU 里包含多个终端的 MAC 地址，说明下行同时服务了多个终端的调度确实在进行。如果抓了十几分钟全是传统单用户 SU PPDU，那基本可以断定 AP 的 OFDMA/MU-MIMO 没真正参与传输，问题要么在配置没同步，要么在终端能力不够。

更有意思的验证点是看每个 RU 的分配情况。Wireshark 展开 HE-SIG-B 的 User Information 字段，你能看到每个 RU 的起始位置、RU 大小，以及对应用户的 AID。如果同一个 PPDU 里出现多个来自不同终端的 AID，就说明 OFDMA 在按既定的资源计划调度，而不是把整条信道都塞给一个用户。TWT 的验证相对抽丝剥茧，可以过滤 TWT Setup 请求/响应帧，确认 AP 和终端是否协商成功，协商成功后才能指望低功耗设备按“作息表”工作。

4. 常见问题与排查技巧实录

4.1 OFDMA开启后吞吐不升反降

这是我在论坛和客户现场被问得最多的一个问题。现象通常是：开了 OFDMA，单终端测速反而掉了两三百兆。原因有两类。一类是 OFDMA 切小 RU 后，控制开销占比变大，尤其当每个 RU 传的数据量都很小时，效率反而低于单用户独占整信道，这在高 MCS 且大报文场景里特别明显。另一类是上行 OFDMA 的同步问题，终端时钟偏差导致包错位，引发重传，空口看起来忙，实际有效数据不高。

排查时先别动参数，先把“应用层速度”和“PHY层速率”分开测。我用 iPerf3 做 TCP 测试同时抓包看速率指标，再用 AP 自带的 RF 统计看 MCS 分布和重传率。如果 MCS 分布很高但 TCP 吞吐低，多半是调度开销问题，把 OFDMA 的作用范围调整为只对小报文生效；如果重传率明显升高，那就优先检查 GI 和 Trigger 帧的同步设置。

4.2 MU-MIMO并行传输效果不明显

有一次我在实验室里做 4x4 MU-MIMO 测试，四台终端只有一台能跑到高速率，其它三台速率都很低。后来一看终端列表，那三台全是 1x1 天线的 IoT 设备，4x4 MU-MIMO 里只有一条流被真正利用，而且为了照顾它们的 CSI 反馈，AP 还得浪费空口资源发训练序列。

遇到 MU-MIMO 收益不明显，第一件事是确认参与调度的终端空间流数，别说“都是 Wi-Fi 6 手机”，不同机型的空间流数差异很大。第二件事是看 CSI 反馈是否稳定。终端在静止状态下，CSI 质量好，MU-MIMO 增益明显；终端一动起来，反馈的 CSI 迅速过期，此时 MU-MIMO 的波束成形向量是“瞎的”。所以用于 MU-MIMO 调度的场景尽量是会议室、工位等静止场景。测试时我会把测试终端固定在支架上，并让每台终端之间拉开一米以上距离，减少空间相关性。

4.3 TWT导致低功耗设备唤醒延迟高

TWT 调度的初衷是省电，但省电和低延迟天然矛盾。有个智能水表项目就是典型案例：设备每 5 分钟上报一次数据，却协商了一个 10 分钟的唤醒周期，导致上报延迟漂到了 10 分钟开外，业务侧直接判定设备离线。

排查 TWT 问题时，先问业务周期。确定业务上报间隔后，把 TWT 唤醒周期设为略小于业务间隔，留出重传余量。再就是看是 Individual TWT 还是 Broadcast TWT。Broadcast TWT 的公共周期一旦设定，所有同组设备都被绑在一起，如果混合了不同业务的设备，建议按业务分组建立多个 Broadcast TWT 参数集。最后检查一下 AP 侧有没有 TWT 冲突避免功能，部分厂商会默认打散不同终端的唤醒时间，防止唤醒风暴。

4.4 高密场景下调BSS Coloring反而不稳定

BSS Coloring 开得太激进，会让“异色即并行”的假设引入真实干扰。曾经有个 200 人办公室，开了 SR 后空口利用率下降了，但应用侧却频繁掉包。抓包发现两个相邻 AP 覆盖重叠区里的终端虽然在并行传输，但由于 OBSS_PD 阈值放松导致信号互相压制，双方的信噪比同时恶化，MCS 一路跳水。

这时候不能只看空口利用率，要结合 SINR 和关键应用的时延来看。我把 OBSS_PD 阈值逐档往下调，每档跑一组业务模拟和丢包统计，最终停在“空口利用率提升、掉包率未增加”的拐点上。这组参数必须现场反复测，没有任何一个离线推荐值能代替实测。

4.5 老终端拖慢整个AX网络

在老终端和 11ax 终端混合的场景里，一个 802.11n 终端接入后，AP 为了兼容它，往往会让整条信道的保护间隔和帧格式降级，导致 AX 调度的优势被拖累。这种情况最典型的特征是多用户调度的 MU 统计里，老终端所在时刻几乎没有 OFDMA/MU-MIMO 传输。

处理办法是按 SSID 分流。让支持 11ax 的终端进专用 SSID，该 SSID 只允许 HE 终端接入，彻底避开兼容性负担。老终端单独放一个 SSID，允许 HT/VHT 传输模式。如果硬要在同一个 SSID 里兼容，务必开启厂商的“保护帧优化”和“Mixed Mode”功能，并设置较短的 non-HT 保护周期，尽量减少向下兼容对整个 AX 调度周期的影响。

个人在实际项目中遇到最多的不是调度算法不工作，而是“不知道调度是否真的在工作”。很多网工在 AC 上勾上 OFDMA、MU-MIMO 就以为完事了，结果抓包一看，全部还是单用户 SU 传输。建议整个流程按“先参数、再统计、后抓包”的顺序来：先在 AP 上开对应特性，再看 AP 统计接口里的 MU/OFDMA 计数器，最后用支持 11ax 的抓包网卡做端到端确认。最后再分享一个小技巧：测试 AX 调度，最好准备两台以上支持 11ax 的终端，同频同时拉吞吐，否则你看到的就是普通 SU-MIMO 的速率，调度真正带来的并发收益完全体现不出来。