第 6 章：802.11ax（Wi-Fi 6/6E）— 智能交通系统
"问题不是路不够宽，而是路上的车太乱了。"
¶ 本章导读
802.11ac 追求的是峰值速率，但现实中的 Wi-Fi 问题往往不是 "速度不够快"，而是 "在密集场景下效率太低"——几十个设备同时竞争一个信道，碰撞频繁，实际吞吐量远低于理论值。
2020 年，802.11ax（Wi-Fi 6，HE，High Efficiency）登场。它的核心理念不再是 "修更宽的路"，而是 "更智能地管理交通"：OFDMA 把信道分成小资源块同时服务多用户、BSS Coloring 减少同频干扰、TWT 让 IoT 设备定时休眠省电。
本章你将学到：
- OFDMA：把一条路分成多个车道，每辆车分配不同车道
- BSS Coloring：不同快递公司的颜色标记
- TWT：定时班车制度
- 1024-QAM：更极限的装载
- 上行 MU-MIMO：终于双向都支持了
- Wi-Fi 6E：6 GHz 新大陆
¶1 OFDMA — 频率维度的多用户
¶1.1 OFDM vs OFDMA
这是 802.11ax 最核心的创新。
OFDM（802.11a/g/n/ac）：每次传输只服务一个用户，即使用户只需要很小的数据量，也要占用整个信道。
OFDMA（802.11ax）：把信道分成多个小的资源单元（RU），同时服务多个用户。
交通比喻：OFDM 就像一条宽马路，每次只允许一辆车通行——即使这辆车只需要走很短的距离，后面的车也必须等。OFDMA 就像把这条马路划分成多个车道，每条车道分配给不同的车辆——小车走窄车道，大车走宽车道，所有车同时出发。
¶1.2 资源单元（Resource Unit, RU）
OFDMA 将信道在频率维度上划分为不同大小的资源单元（RU），每个 RU 是一组连续的子载波，作为一个整体分配给一个 STA。
子载波 vs RU 的关系：子载波本身是 OFDM 的基本技术——把宽带信道分成许多窄带子载波，使得每个子载波上的信道近似平坦，从而对抗多径衰落。子载波在 802.11a/g/n/ac 时代就存在了，但那时所有子载波只能同时服务一个用户。OFDMA 的创新在于：既然子载波已经存在了，那就把它们按标准规格打包分配给不同的人用——这就是 RU 的由来。
RU 的编号（26、52、106...）代表该 RU 包含的子载波数量，这些规格由 IEEE 802.11ax 标准明确定义：
| RU 类型 | 子载波数 | 带宽 | 适用场景 |
|---|---|---|---|
| RU-26 | 26 | ~2 MHz | IoT 小数据 |
| RU-52 | 52 | ~4 MHz | 普通数据 |
| RU-106 | 106 | ~8 MHz | 中等数据 |
| RU-242 | 242 | ~20 MHz | 大文件 |
| RU-484 | 484 | ~40 MHz | 高速传输 |
| RU-996 | 996 | ~80 MHz | 极高速 |
注意：一个 RU 内的子载波仍然是各自独立调制的（每个子载波有自己的 QAM 调制），RU 只是在调度层面将它们捆绑为一个分配单元，一起交给同一个 STA 使用。
标准还规定了每个信道宽度下合法的 RU 组合方式——不能随意把子载波拆成任意大小，必须按照标准定义的组合树来切分。这是为了保证不同厂商设备之间的互操作性。
在 RU 划分中，信道正中心有一个子载波被标记为 DC（DC Subcarrier，直流子载波），不参与数据传输。原因是 OFDM 发射机的本振（Local Oscillator）恰好位于信道中心频率，会产生直流泄漏（DC Offset），导致该子载波上的信号被严重干扰，因此必须置空。实际的 RU 分组是在 DC 两侧分别进行的。
这些 RU 规格并非随意取值——它们都服从同一条设计逻辑：子载波必须成对、对称地分布在 DC 两侧，所以每个 RU 的总子载波数永远是偶数（26 = 13×2，DC 两侧各 13 个）。以最小的 26-tone 为例：24 个数据子载波 + 2 个导频（pilot），DC 两侧各放 12 数据 + 1 导频；更大的 RU 依此类推——52 = 48+4，106 = 102+4，242 = 234+8，484/996 各带 16 个导频。以 26-tone（约 2 MHz）为最小粒度，更大的 RU 大致逐级翻倍，构成一棵可递归切分的资源树，让 20/40/80 MHz 信道被整齐地拆成大小不等的资源块。
一个 80 MHz 信道可以被划分为：
- 37 个 RU-26（每个 ~2 MHz），同时服务 37 个用户
- 或 16 个 RU-52，同时服务 16 个用户
- 或 8 个 RU-106，同时服务 8 个用户
- 或更少的更大 RU，服务更少但速率更高的用户
交通比喻：RU 就像车道宽度。RU-26 = 自行车道（窄，给 IoT 小数据），RU-106 = 普通车道（给普通数据），RU-996 = 16 车道超级高速（给大文件传输）。交通调度员（AP）根据每辆车的货物量，动态分配最合适的车道。
¶1.3 RU 怎么分配给用户？— DL 与 UL 机制
OFDMA 的 RU 分配有两种模式，区别在于谁来调度、怎么通知：
下行 OFDMA（DL OFDMA）— AP 说了算：
AP 决定每个用户分到哪些 RU，然后在 HE-SIG-B（HE PPDU 的信令字段，类似 802.11ac 的 VHT-SIG-B）中告知所有用户。工作流程：
- AP 根据各用户的数据量和信道条件，计算 RU 分配方案
- AP 在 HE-SIG-B 中填写每个 RU 对应的 STA-ID 和 MCS
- AP 在同一个 OFDM 符号中，同时向不同用户发送数据——每个用户的数据在各自的 RU 上传输
- 各 STA 只需解码自己被分配的 RU，忽略其他 RU
这里的「告知」分两层：HE-SIG-B 的 Common 字段里是 RU Allocation 子字段（8-bit，规范 Table 27-26），每个 8-bit 值编码一个 20 MHz 子信道内的 RU 组合——如 00000000 代表 9 个 RU-26、01110010 代表单个 RU-484。STA 先解码 RU Allocation，还原出整条信道的 RU 切分图；再到 User Specific 字段里按 STA-ID 找到自己的 User field，其出现次序即对应自己所在 RU，由此定位该 RU 的起始子载波索引，只解调那一段。
这就像交警（AP）在路口同时给不同方向的车放行——东向的走左车道，西向的走右车道，所有车在同一时刻同时通过。
上行 OFDMA（UL OFDMA）— AP 发 Trigger Frame 调度：
上行更复杂——STA 不能自己决定用哪个 RU，必须等 AP 通知。工作流程：
- AP 发送一个 Trigger Frame（Type=01, Subtype=0010），告诉各 STA："STA-A 你用 RU-26 #1，STA-B 你用 RU-52 #3，STA-C 你用 RU-26 #5..."
- 各 STA 在 SIFS 后，同时在各自分配的 RU 上发送数据
- AP 接收所有 RU 上的数据（频域分离，互不干扰）
- AP 回复 Multi-STA Block ACK 确认
这就像交警用对讲机通知每辆车："红色车走 1 号车道，蓝色车走 2 号车道，绿色车走 3 号车道——现在同时出发！" 所有车在同一时刻启动，各自在自己的车道上行驶。
为什么上行需要 Trigger Frame？
关键问题是时间同步。下行所有数据来自同一个 AP，天然同步。但上行各 STA 分散在不同位置，信号传播延迟不同。Trigger Frame 的作用不仅是分配 RU，还要校准各 STA 的发送时机——确保各 STA 的信号到达 AP 时恰好对齐在同一个 OFDM 符号边界上。Trigger Frame 中包含 UL Target Receive Power 字段，让各 STA 调整发送功率；
上行时间同步则以 Trigger Frame 的结束时刻为公共参考点——各 STA 在 SIFS 后同时发送，Cyclic Prefix 吸收传播延迟差异。
Trigger Frame 是广播帧：AP 以广播方式发送，所有 STA 都能收到。帧中包含一个 User Info Field 列表，每个 STA 根据其中的 AID（Association ID）找到属于自己的 RU 分配。一次广播就通知了所有需要上行的 STA。
STA 没收到 Trigger Frame 怎么办？ 不会产生碰撞——STA 没收到就不知道自己被调度了，不会发送任何东西，信道上是安静的。AP 在 Multi-STA Block ACK 阶段发现该 STA 未响应后可以重试调度。真正的代价是延迟和资源浪费（分配的 RU 空跑了一轮），而不是碰撞。
UL OFDMA 的效率账：Trigger Frame 本身是额外开销，但换来的是 N 个 STA 同时传输，省去了 N 次独立的竞争退避和逐个发送。STA 越多，优势越大——100 个 IoT 设备逐个竞争可能碰撞频繁、耗时极长，而 OFDMA 可以几轮调度就全部发完。少量大流量 STA 时优势不明显，大量小流量 STA 时效率提升巨大。
AX 不一定用 Trigger Frame：UL OFDMA 只是上行传输的一种方式，STA 仍然可以用传统的 EDCA 竞争来发送数据。两种方式共存：
| 方式 | 机制 | 触发方 |
|---|---|---|
| Trigger-Based UL（HE TB PPDU） | AP 发 Trigger Frame 调度 | AP 主动调度 |
| Non-Trigger-Based UL（HE SU PPDU） | STA 自己竞争信道，传统 CSMA/CA | STA 自己抢 |
Sniffer 中怎么判断？ Sniffer 抓的是 MAC 层，前导码和 PHY 头部（包括 HE-SIG-A）在硬件解调时就被剥掉了，看不到 UL Format 位。实际判断方法是看有没有 Trigger Frame——它是 MAC 层 Control 帧，Wireshark 能直接解析：
1 | [Trigger Frame] → [SIFS] → [上行数据帧] → AP 调度的 |
有一个盲区：如果 AP 发了 Trigger Frame 但 sniffer 没抓到（信号弱等原因），只看到一个孤立的上行帧，就无法区分它是 TB PPDU 还是 SU PPDU——PHY 类型信息不在 MAC 层。
¶1.4 一个具体例子：20 MHz 信道同时服务 9 个用户
一个 20 MHz 信道（256-FFT，242 个可用子载波）可以这样划分（9 × RU-26 = 234 个子载波，在 242 个可用范围内）：
| RU 编号 | 类型 | 分配给 | 用户数据 |
|---|---|---|---|
| #1 | RU-26 | 温度传感器 | 上报 22.5°C |
| #2 | RU-26 | 门磁传感器 | 状态 = 关闭 |
| #3 | RU-26 | 烟雾传感器 | 状态 = 正常 |
| #4 | RU-26 | 智能手表 | 心率 72bpm |
| #5 | RU-26 | 手机 B | 网页请求 |
| #6 | RU-26 | 笔记本 A | 文件下载 |
| #7 | RU-26 | 手机 C | 微信消息 |
| #8 | RU-26 | 智能灯泡 | 确认收到 |
| #9 | RU-26 | 温湿度计 | 湿度 65% |
9 个设备在同一时刻、同一个 20 MHz 信道上同时传输，互不干扰。如果用传统 OFDM，这 9 个设备需要排队逐个发送——总耗时是 OFDMA 的 9 倍。
¶1.5 OFDMA 的效率提升
在密集场景下，OFDMA 的效率提升是革命性的：
| 场景 | OFDM | OFDMA |
|---|---|---|
| 100 个 IoT 设备各发 100 字节 | 100 次竞争 + 100 次传输 | 1 次调度，同时传输 |
| 30 个用户同时上网 | 排队等待，延迟高 | 同时服务，延迟低 |
| 混合大小数据 | 大数据阻塞小数据 | 动态分配，各取所需 |
¶2 BSS Coloring — 不同快递公司的颜色标记
¶2.1 OBSS 过度退避问题
在密集部署中，多个 AP 使用相同信道（同频部署）是常态——商场、体育场、办公楼里，几十个 AP 可能挤在同一个信道上。
传统 Wi-Fi 的 CCA（Clear Channel Assessment）机制是 "一刀切" 的：物理层检测到任何 802.11 信号超过能量门限（如 -82 dBm），就认为信道忙，必须退避等待。
问题在于：这个信号可能来自很远的、属于另一个 BSS 的 AP，对你的网络实际干扰很小，但你还是得傻等。这叫做 Overlapping BSS（OBSS）过度退避——明明隔壁 BSS 的信号很弱、不会真正影响你的传输，但传统机制无法区分，只能保守地等待，白白浪费信道时间。
交通比喻：你开了一家顺丰快递站，隔壁中通站点共用一条巷子（同一信道）。巷子里只要有快递员在走（不管哪家的），你就得停手等着。中通的快递员在巷子另一头搬货，离你很远，实际上根本不影响你，但你还是得干等——这就是过度退避。
¶2.2 BSS Coloring 机制
BSS Coloring 在 HE-SIG-A（802.11ax PPDU 的信令字段）中添加一个 6-bit 的颜色标识（1-63，0 表示未着色），让设备能快速区分不同 BSS 的信号——不需要解析完整的 MAC 头部（BSSID），在物理层就能判断 "这个信号是谁的"。
有了颜色标识，物理层的 CCA 机制就可以区分对待不同来源的信号：
| 信号来源 | 门限 | 行为 |
|---|---|---|
| 同色信号（本 BSS） | 标准门限（如 -82 dBm） | 必须认真退避——这是你自己网络的流量 |
| 异色信号（OBSS） | 宽松门限（如 -72 dBm） | 信号弱就忽略，信号强才退避 |
-82 dBm 不是随便定的——它是 CCA 在 20 MHz 主信道上的包检测门限：任何 PPDU 在主信道测得的功率达到 -82 dBm 就判忙。BSS Coloring 的贡献，是把对 OBSS 的门限放宽到更高（如 -72 dBm，即放松 10 dB）：异色信号只有强到超过这个放宽门限才需要退避。规范把放宽上限约束在 -62 dBm（-82+20 dB 的能量检测门限），并加了一道安全阀——靠放宽门限忽略某个 OBSS 帧后，必须同步压低自身发射功率（TX_PWRmax），避免干扰那个被忽略的 BSS。进一步地，规范区分空间复用组（SRG，Spatial Reuse Group）：多个 BSS 用 BSS Color 或部分 BSSID 编成一组（成员在 Spatial Reuse Parameter Set 元素里用位图通告），同组内互相套用 SRG OBSS PD 门限，组外 non-SRG 则走另一套（non-SRG OBSS PD）门限。
交通比喻：你认出那是中通的快递员（异色），而且他离你还很远（信号弱），你就继续干自己的活。只有当顺丰自己的快递员（同色）在用巷子，或者中通的人就在你跟前（信号强）时，你才退避。
¶2.3 空间复用：BSS Coloring 的真正价值
BSS Coloring 解决的不是 "碰撞" 问题——CSMA/CA 竞争机制始终存在。它解决的是 "空间复用" 问题：在密集场景下，让物理上距离足够远的 BSS 可以更激进地共享信道。
没有 BSS Coloring 时，所有同频 AP 必须互相退避，信道利用率极低。有了 BSS Coloring，不同颜色的 BSS 在信号弱时可以同时传输——虽然碰撞风险微增，但空间复用的收益远大于偶尔碰撞的代价，碰撞后还有重传机制兜底。
本质上这是一个吞吐量 vs 碰撞率的工程权衡，BSS Coloring 让系统能更激进地复用信道，提升密集场景下的整体容量。
¶2.4 颜色信息在哪里传递
BSS Color 不只是在 PHY 头部出现一次，它贯穿了整个协议交互过程：
| 位置 | 帧类型 | 作用 |
|---|---|---|
| HE-SIG-A | 所有 HE PPDU（SU / MU / TB） | 物理层解调时立即识别颜色，决定 CCA 行为 |
| Beacon / Probe Response | 管理帧的 HE Operation 元素 | AP 向全网通告 "本 BSS 的颜色是 X" |
| Trigger Frame | 控制帧的 HE Control 字段 | 上行调度时告知 STA 当前颜色 |
| QoS Data 帧 | HE Control 字段 | STA 上行发送时携带自己 BSS 的颜色信息 |
交通比喻：颜色标识不只是印在快递员的工服上（PHY 头部），还写在公司的公告栏里（Beacon）、调度指令里（Trigger Frame）、以及每份快递单上（数据帧）。所有人都能随时确认 "我属于哪家公司"。
¶2.5 向后兼容性
6-bit 颜色标识是 802.11ax 新增的功能，传统 802.11a/n/ac 设备不识别 BSS Color，无法做颜色感知的 CCA。在混合网络中：
- ax 设备：能区分同色 / 异色信号，享受空间复用的好处
- 旧设备：仍然用标准门限一刀切退避，无法利用颜色信息
这意味着在传统 2.4 GHz / 5 GHz 频段的混合部署中，BSS Coloring 的效果会被旧设备稀释。这也是 Wi-Fi 6E（6 GHz 频段）效果更好的原因之一——该频段的设备必须支持 802.11ax，没有旧设备拖后腿，所有设备都能做颜色感知的空间复用。
¶2.6 动态 BSS Coloring
BSS Coloring 还支持动态调整——当检测到相邻 AP 使用相同颜色时，可以自动更换颜色，避免 "撞色" 导致门限策略失效。
¶3 TWT — 定时班车制度
TWT（Target Wake Time）是 802.11ax 为 IoT 设备设计的省电机制。它的核心思想是：让每个设备有自己的个性化唤醒时刻表，而不是所有人都按同一个节奏醒来。
¶3.1 为什么有了 DTIM 还不够？
在 TWT 之前，802.11 已经有 DTIM（Delivery Traffic Indication Message）省电机制。传统 PSM（Power Save Mode）的工作方式：
- AP 每隔一个 Beacon Interval（默认 100 TU = 102.4ms）发一次 Beacon
- Beacon 里携带 TIM（Traffic Indication Map） 位图，标记 "哪些 STA 有缓存数据"
- 每个 STA 都必须醒来听每一个 Beacon，检查自己有没有数据
- DTIM 是 TIM 的聚合版——AP 每隔 N 个 Beacon 才发一次 DTIM，STA 可以跳过中间的普通 Beacon，只在 DTIM 时醒来
问题在于：
| 痛点 | 说明 |
|---|---|
| 唤醒周期不可定制 | 所有 STA 都按同一个 Beacon Interval（如 102.4ms）醒来，不管你是一秒钟要交互一次的手机，还是一小时才上报一次的温度传感器 |
| IoT 设备浪费严重 | 温度传感器一小时只发一次数据，但每 102.4ms 就得醒来看一眼 Beacon——99.99% 的唤醒是白醒的 |
| 密集场景更糟 | 100 个 IoT 设备同时在每个 DTIM 周期醒来，醒来后还要竞争信道，碰撞概率极高 |
| 延迟不可预测 | 即使 STA 被标记有数据，它也得等到下一个 DTIM 才能知道——最坏情况要等整个 DTIM 周期 |
交通比喻：DTIM 就像全公司统一的打卡时间——不管你几点有活干，都得每小时去打卡机看一眼 "有没有我的快递"。100 个员工同时挤在打卡机前，效率极低。
TWT 的突破：让每个 STA 有自己的个性化唤醒时刻表。温度传感器每 30 秒醒一次，手机每 1 秒醒一次，各不干扰。而且唤醒时间是错开的，不竞争。
¶3.2 TWT 协商机制
TWT 有两种模式，协商方式不同。AP 和 STA 通过 TWT Setup Action Frame 进行协商，协商完成后 STA 就按约定的时刻表自动休眠 / 唤醒。
¶3.2.1 Individual TWT（一对一协商）
每个 STA 与 AP 独立协商自己的唤醒时间表，整个生命周期分五步：
- 协商：STA 发送 TWT Setup Action Frame（Management, Type=00, Subtype=1101），携带期望的 Wake Duration、TWT Wake Interval、Target Wake Time；AP 回复 Accept，或提出替代参数（同为 Action 帧）。
- 休眠：协商完成后 STA 进入深度休眠，省电等待。
- 唤醒：到达 Target Wake Time 时 STA 自动醒来。
- 数据交换：AP 发送 Trigger Frame（Control, Type=01, Subtype=0010）调度，STA 回复 QoS Data（Data, Type=10, Subtype=1000），AP 以 Multi-STA Block ACK（Control, Type=01, Subtype=1001）确认。
- 再休眠：数据交换完成，STA 再次进入休眠，等待下一个 Target Wake Time。
这就像乘客和公交公司签了一份个性化时刻表：每天 8:05 在小区门口等 3 号车，只等 2 分钟。其余时间不用在车站傻等。
¶3.2.2 Broadcast TWT（广播协商）
适用于多个 STA 有相似唤醒需求的场景（如一群 IoT 传感器）。AP 在 Beacon（Management, Type=00, Subtype=1000）中广播 Broadcast TWT Element（包含 TWT ID 和参数），STA 根据 TWT ID 决定是否加入该组（回复 TWT Setup Accept, Management/1101）。到达 TWT 时刻时，同组所有 STA 同时醒来，AP 发送 Broadcast Trigger Frame（Control, Type=01, Subtype=0010，包含多个 STA 的 RU 分配），各 STA 同时在各自 RU 上行 QoS Data（Data, Type=10, Subtype=1000），互不干扰，AP 以 Multi-STA Block ACK（Control, Type=01, Subtype=1001）统一确认。
| 特性 | Individual TWT | Broadcast TWT |
|---|---|---|
| 协商方式 | STA ↔ AP 一对一协商 | AP 广播，STA 自愿加入 |
| 唤醒时间 | 每个 STA 独立 | 同组 STA 相同 |
| 灵活性 | 高（个性化参数） | 中（统一参数） |
| 协商开销 | 每个 STA 单独一次 Action Frame | 一次 Beacon 广播 |
| 适用场景 | 手机、笔记本等交互设备 | IoT 传感器群组 |
¶3.3 TWT 协商的关键参数
TWT Element 是协商的核心载体，包含以下关键字段：
| 参数 | 含义 | 示例 |
|---|---|---|
| Target Wake Time | 首次唤醒的绝对时刻（TSF 时间戳） | 0x0000A3F2... |
| Wake Duration | 每次醒来保持清醒的最长时间 | 4ms |
| TWT Wake Interval | 两次唤醒之间的间隔 | 500ms |
| TWT Setup Command | 协商命令类型 | Request / Suggest / Demand / Accept / Alternate / Dictate / Reject |
| Trigger | 是否在唤醒时由 AP 发 Trigger Frame | 是 / 否 |
| Implicit/Explicit | 隐式（自动续期）或显式（每次重新协商） | Implicit |
| Flow Type | 流量类型 | 0=Announced, 1=Unannounced |
| TWT Protection | 是否保护唤醒窗口不受其他 STA 干扰 | 是 / 否 |
Setup Command 的含义：
| 命令 | 发起方 | 含义 |
|---|---|---|
| Request | STA | STA 请求加入 / 建立 TWT |
| Suggest | STA | STA 建议一组参数，但可协商 |
| Demand | STA | STA 要求精确匹配该参数（不接受替代） |
| Accept | AP | AP 接受 STA 的参数 |
| Alternate | AP | AP 不接受，提出替代参数 |
| Dictate TWT | AP | AP 强制指定与 STA 建议不同的参数 |
| Reject TWT | AP | AP 拒绝建立 TWT |
¶3.4 协商发生在哪里？什么时机？
| 场景 | 时机 | 载体帧 |
|---|---|---|
| 首次协商 | Association 之后，数据传输之前 | TWT Setup Action Frame（Management/1101, Category=HE, Action=TWT Setup） |
| 修改参数 | 任何时候，任何一方都可以发起 | TWT Setup Action Frame（Management/1101, 重新协商） |
| 退出 TWT | 任何一方都可以发起 | TWT Teardown Action Frame（Management/1101） |
| Broadcast TWT 发布 | AP 周期性在 Beacon 中通告 | Beacon（Management/1000）的 TWT Element |
¶3.5 一个完整的时序示例
假设温度传感器每 60 秒上报一次数据，唤醒窗口 2ms：
1 | t=0.000s 协商完成：约定每 60s 醒来，醒 2ms |
电池消耗：60 秒中只清醒 ~2ms，省电 99.997%。
¶3.6 TWT 的好处
| 好处 | 说明 |
|---|---|
| 省电 | IoT 设备电池寿命可延长数倍——从 DTIM 的 "每 102.4ms 醒一次" 变为 "每 30s 醒一次" |
| 减少竞争 | 设备在不同时间唤醒，信道上同时竞争的设备数量大幅减少 |
| 确定性延迟 | 调度后延迟可预测——唤醒时刻已知，无需等待 Beacon |
| 密集场景优化 | 100 个 IoT 设备不再同时醒来，碰撞概率从 "必然碰撞" 变为 "几乎不碰" |
交通比喻总结：TWT 就像定时班车制度——乘客（设备）不需要一直在车站等车，只需要在班车到达的时间出现在车站。其余时间可以在家休息（深度休眠），大大节省了 "等待" 的精力（电量）。而且每个乘客有自己的班车时刻表，互不干扰。
¶4 1024-QAM — 极限装载
QAM 通过在 I/Q 平面上同时调制载波的幅度与相位来编码比特，星座点越多、每符号承载的比特越多。802.11ax 把单符号承载能力从 256-QAM 的 8 bit 提升到 1024-QAM 的 10 bit：
| 调制 | 每符号比特 | SNR 要求（工程估算） | 适用场景 |
|---|---|---|---|
| 256-QAM (ac) | 8 bit | ~32 dB | 近距离 |
| 1024-QAM (ax) | 10 bit | ~37 dB | 极近距离 |
| 4096-QAM (be) | 12 bit | ~42 dB | 室内极近距离 |
1024-QAM 相比 256-QAM 提升约 25% 的速率，但需要更高的 SNR。为什么？它把星座点从 256 个加密到 1024 个（4 倍），同样的 I/Q 幅度范围内相邻星座点间距缩小一半。间距一缩，噪声容限就收紧——任何幅度/相位误差都更容易把符号推到相邻点上造成误判。规范用 EVM（Error Vector Magnitude，误差矢量幅度）量化发射端允许的最大误差：256-QAM 要求不超过 -32 dB，1024-QAM 收紧到 -35 dB（Table 27-49）。这正是 1024-QAM 只能用于极近距离的原因——离 AP 稍远、噪声一上来，星座点糊成一片，误码率陡增。
交通比喻：1024-QAM 是把货车的货格从 8 格扩到 10 格——车厢大小没变，格子更密更挤，路面稍一颠簸（噪声），货物（符号）就容易错位到相邻格子（误判）。所以这种 "更大货车" 只能在离 AP 极近、路面极平（高 SNR）的条件下才敢上路。
¶5 上行 MU-MIMO
802.11ac 只支持下行 MU-MIMO。802.11ax 终于支持了上行 MU-MIMO——多个设备同时向 AP 发送数据。
上行 MU-MIMO 与上行 OFDMA 分工明确：OFDMA 在频率维切分——各 STA 分到不同的 RU，靠子载波正交把信号分开，适合大量小数据 STA；MU-MIMO 在空间维复用——多个 STA 同时占用同一段带宽、各走一条空间流，靠 AP 的多根天线在空域把它们区分开，适合数据量大但 STA 数少的场景。两者都由 AP 的 Trigger Frame 触发，差别只是分配的资源不同：OFDMA 分 RU，MU-MIMO 分空间流。
要让 AP 知道该调度谁、给多少资源，还有两个配套机制：MU-RTS（Trigger Type=3）——AP 先发 MU-RTS 让目标 STA 同时回 CTS，为随后的上行传输预留信道（NAV），防止隐藏终端撞车；BSR（Buffer Status Report，缓存状态报告）——AP 用 BSRP Trigger Frame（Trigger Type=4）轮询各 STA，STA 在 QoS Null 帧里上报自己缓存了多少上行数据，AP 据此决定调度顺序和资源量。
Trigger Type 共 8 种取值（规范 Table 9-29c）：0=Basic、1=BFRP（波束成形报告轮询）、2=MU-BAR、3=MU-RTS、4=BSRP、5=GCR MU-BAR、6=BQRP（带宽查询报告轮询）、7=NFRP（NDP 反馈报告轮询）。其中 3（MU-RTS）与 4（BSRP）是上行调度主力，其余用于波束成形反馈、块确认请求与带宽 / NDP 反馈轮询。
交通比喻：OFDMA 是横向多车道（频分），上行 MU-MIMO 是纵向立体层（空分）——几辆车在同一个地面位置、不同高度同时通过，靠 AP 这个 "空中交警" 的多根天线把它们一一分辨开。上下行都成了多车道，补齐了 "双向多车道" 的最后一块。
¶6 Wi-Fi 6E — 6 GHz 新大陆
2021 年，Wi-Fi 6E 将 802.11ax 扩展到 6 GHz 频段（5.925-7.125 GHz）。这块新频谱最大的价值不只是 "多了一条路"，而是它完全干净——没有旧设备占用，也不需要和雷达、微波炉等共享。三条频段的对比一目了然：
| 参数 | 2.4 GHz | 5 GHz | 6 GHz |
|---|---|---|---|
| 可用带宽 | 83.5 MHz | ~500 MHz | ~1200 MHz |
| 20 MHz 信道 | 3 | 25 | 59 |
| 80 MHz 信道 | 0 | 6 | 14 |
| 160 MHz 信道 | 0 | 2 | 7 |
| 干扰 | 严重 | 中等 | 几乎无 |
59 个 20 MHz 信道也带来一个新问题：STA 要逐个信道发 Probe Request 才能发现 AP，扫完 59 个信道耗时极长。为此 6 GHz 定义了 PSC（Preferred Scanning Channel，优先扫描信道）——把每 4 个 20 MHz 信道中的第 1 个定为 PSC（共 15 个），AP 尽量把主信道设在 PSC 上，STA 只扫这 15 个信道就能大概率发现 AP，扫描开销降为原来的四分之一。
不过 6 GHz 的 "干净" 只对旧 Wi-Fi 设备成立——它其实与卫星上行、微波固定链路等既有业务共用频谱。为避免干扰这些既有业务，监管把 6 GHz AP 分成两类：标准功率（Standard Power）AP 开机时必须向 AFC（Automated Frequency Coordination，自动频率协调） 数据库查询可用信道与功率上限，数据库会避开既有业务的占用；而低功率室内（Indoor）AP 发射功率受限、信号穿不出建筑，可免于查询。所以 6 GHz 不是 "没人管"，而是 "有规则地共享"。
交通比喻：6 GHz 就像在一个全新开发的区域建设道路——没有历史包袱，没有旧建筑限制，可以一次性规划出最合理的路网。59 个 20 MHz 信道 = 59 条独立的道路，拥堵问题大大缓解。而 PSC 就像在每条主干道入口挂上路标，司机不用逐条巷子去探，只看路标就能找到主路。
¶7 缺陷分析
| 缺陷 | 具体问题 | 影响 |
|---|---|---|
| MLO 缺失 | 只能在一个频段工作 | 无法同时利用多频段 |
| 更高 QAM 需求 | 1024-QAM 需要极高 SNR | 实际使用率有限 |
| 320 MHz 不支持 | 最大 160 MHz | 单信道速率有限 |
| 多链路能力不足 | 无法同时在 2.4/5/6 GHz 通信 | 延迟和可靠性受限 |
¶8 本章总结
802.11ax 是 Wi-Fi 从 "追求峰值速率" 到 "追求实际效率" 的转折点：
| 特性 | 效果 | 交通比喻 |
|---|---|---|
| OFDMA | 多用户同时传输 | 多车道分配 |
| BSS Coloring | 减少同频干扰 | 颜色标记 |
| TWT | IoT 省电 | 定时班车 |
| 1024-QAM | 速率提升 25% | 更大货车 |
| 上行 MU-MIMO | 上行多用户 | 双向多车道 |
| 6 GHz | 1200 MHz 新频谱 | 新大陆高速公路 |
下一章将讲述：MLO 如何让一辆车同时走多条路？4096-QAM 把装载能力推到了什么极限？320 MHz 信道和 Preamble Puncturing 又带来了什么新能力？