简介：IEEE P802.11be（Wi-Fi 7）Draft 3.0 标准草案正式发布于 2023 年 1 月，是 IEEE 802.11 工作组针对极高吞吐量（EHT）场景的重要修订版，适合无线协议研发、通信测试及标准跟踪人员阅读。草案在保持 2.4/5/6 GHz 频段旧设备兼容性的前提下，对 MAC 层与 PHY 层作出系统性增强，引入 320 MHz 超高带宽、OFDMA、MU-MIMO、Channel Bonding、Multi-User OFDMA 与 Dynamic Sensitivity Control 等机制，使 MAC 数据服务访问点吞吐量达到至少 30 Gbit/s，并改善最坏情况下的时延与抖动。文件包含完整草案正文及摘要、关键字，便于逐章理解 EHT 物理层设计、多用户调度策略和协议兼容性方案，也可用于 Wi-Fi 7 技术预研、课程讲解或标准对比。资源为单个 PDF 文档，大小 6.84 MB，内容紧凑，支持离线精读。已有 1054 人学习下载，适合对下一代 WLAN 标准有深入研究需求的技术人员。

1. 进入 D3.0：Wi-Fi 7 草案第三版的实质变化

如果你在 Wi-Fi 7 协议栈开发或者无线测试岗位，手里没有一份 802.11be D3.0 草案，很多联调问题只能靠猜。这份 IEEE P802.11be D3.0.pdf 是 Wi-Fi 7 的第三版草案，也是第一个把多链路操作（MLO）、4096-QAM 和 320MHz 带宽的信令细节收敛到“可以动手实现”程度的版本。相比 D2.0，它删掉了一批含糊表述，补齐了 EMLSR/EMLMR 链路切换、TID-to-Link 映射和打孔传输的约束条件。适合协议栈工程师、驱动开发者和测试人员做实现基准，也适合刚入行的人用它建立对 Wi-Fi 7 帧结构和能力协商的正确认知。如果你的设备还跑在 D2.0 的实现上，这篇笔记能帮你把差异一次性看清。

2. 读薄 D3.0：正文结构、关键条款与检索路径

2.1 拿到 PDF 先定位：封面、修订记录与版本号

一份 802.11be 草案拿到手，第一件事不是翻正文，而是确认版本身份。D3.0 的正式名称是 IEEE P802.11be/D3.0，通常封面右下角会标“Draft 3.0”，修订记录页会列出从 D0.1 到 D3.0 的变更历史。很多工程师只看文件名的“11be”就往下读，结果把 D2.0 的条款当成 D3.0 用，联调时对不上。

注意一个细节：802.11be 的草案版本号从 D0.1、D0.2 一直到 D1.0、D2.0、D3.0，版本之间的条款编号会变化。D3.0 里 MLO 相关的子条款集中在 35.3 节（MLO 协议模型）和 35.4 节（MLO 建立与维护），而 PHY 层的 EHT 能力在 36.3 节。如果你手头只有旧版注释，务必先做一次条款编号映射。

提示：读草案前先翻修订记录页。D3.0 相对 D2.0 的每一条变更都有编号（比如 CID 编号），这些编号在后续讨论邮件列表时经常被引用。

2.2 用目录和子条款号快速检索：一份精简地图

802.11be D3.0 正文约六百页，逐页读效率太低。我一般按子条款号建立检索地图，问题是“这个字段在哪定义、这个流程在哪个图里”。常用位点如下表。

这个表不是让你死记，而是建立“问题到条款”的映射。我在做驱动时遇到 MLO 链路无法建立，直接翻 35.4.1 的时序图；遇到速率协商不对，翻 36.3.7 的 MCS 表。标准文档不需要通读，但检索路径必须清晰。

2.3 D2.0 到 D3.0 的核心变更一览

D3.0 最大的价值是“定了”。D2.0 里很多标注为“待定”的字段，在 D3.0 里有了具体语义。以下变更直接影响实现：

这张表我贴在很多同事工位上。用 D2.0 做开发的团队，拿到 D3.0 后先按这六项逐条核对代码，基本能覆盖 90% 的兼容性改动。

2.4 用命令行快速提取和对比条款

PDF 草案不适合直接 diff，我习惯先转文本再比对。以下是我常用的处理流程。

# 将 D3.0 与 D2.0 都转成纯文本，方便 diff pdftotext -layout P802.11be_D3.0.pdf d3.txt pdftotext -layout P802.11be_D2.0.pdf d2.txt # 按子条款号提取特定范围，比如 MLO 相关章节 awk '/^35\.3/{flag=1} /^36\./{flag=0} flag' d3.txt > mlo_d3.txt # 对比两个版本的文本差异，忽略空白行 diff -b -B d2.txt d3.txt | less

这个流程的核心是先把 PDF 转成可检索文本，再按条款边界切分。-layout参数保留原始换行，对表格和公式较多的页面很重要；awk 的匹配模式按你需要检索的子条款号调整。diff 输出会很大，我一般先看“修订记录”里的变更编号，再定向 diff 修改过的部分，而不是全量对比。另外可以用md5sum P802.11be_D3.0.pdf记录文件哈希，确保团队内部使用的版本一致，避免出现 A 同事看 D2.0、B 同事看 D3.0 的乌龙。

3. EHT 物理层落地：4096-QAM、320MHz 与打孔传输的核对方法

3.1 4096-QAM 的 13/12 码率：D3.0 里最容易被读错的一处

D2.0 时代很多实现按 5/6 的编码率做 4096-QAM 速率表，D3.0 把码率改成了 13/12。这个改动直接影响了 MCS 表的速率计算。13/12 的含义不是“一个新的基础码率”，而是在 5/6 的基础上做等效提升——通过减少填充开销，实际有效吞吐增加约 8.3%。你不需要改星座映射逻辑，但要改速率表的计算公式。

# 计算 4096-QAM 在 13/12 码率下的有效速率（单流示例） # 参数：symbol_duration=12.8us，data_subcarriers=392（典型 320MHz 配置） # 注意：D3.0 中 13/12 是相对于基码率 5/6 的等效值 symbol_duration = 12.8e-6 data_subcarriers = 392 bits_per_symbol = 12 # 原始码率 5/6，等效提升系数 13/12 coding_rate = (5/6) * (13/12) data_bits_per_symbol = data_subcarriers * bits_per_symbol * coding_rate rate_mbps = data_bits_per_symbol / symbol_duration / 1e6 print(f"Estimated PHY rate: {rate_mbps:.1f} Mbps")

这段代码的用途不是算最终速率，而是帮你建立参数变化的敏感度。bits_per_symbol是每子载波比特数（4096-QAM 为 12），coding_rate在 D3.0 中要带 13/12 系数。如果把 13/12 漏掉，速率值会偏低约 8%，你在测试报告里看到的吞吐差异可能就来自这里。另外注意data_subcarriers取决于带宽和打孔情况，不同 RU 分配下这个值会变，不能固定用 392。

3.2 320MHz 带宽模型：连续与非连续的 RU 分配差异

D3.0 对 320MHz 的定义做了收敛：320MHz 连续信道可用，160+160MHz 非连续也保留，但非连续模式下信令流程更复杂。驱动实现里，320MHz 的 RU 分配表在 36.3.9 节有完整定义。

# 判断一个信道配置是否属于合法的 320MHz 模式 def is_valid_320mhz(primary_80, secondary_80, tertiary_80, quaternary_80): # 连续 320MHz：四个 80MHz 连续 if is_contiguous([primary_80, secondary_80, tertiary_80, quaternary_80]): return True, "320MHz contiguous" # 非连续 320MHz：两个 160MHz 块，块内连续 if is_contiguous([primary_80, secondary_80]) and \ is_contiguous([tertiary_80, quaternary_80]): return True, "320MHz 160+160" return False, "invalid"

这个判断逻辑的价值在于：D3.0 允许 160+160 非连续，但要求每个 160MHz 块内部连续。很多测试脚本只判断总带宽等于 320MHz，忽略了块内连续性，导致信道配置在合规性测试中被判失败。is_contiguous函数按信道编号差值为 1 判断即可。如果你在做信道可用性扫描，还要把雷达检测和 DFS 状态加进判断条件，这里只是最基础的合法性校验。

3.3 前导码打孔（Puncturing）：D3.0 的信令位与接收端行为

前导码打孔是 Wi-Fi 7 应对干扰的重要机制。D3.0 定义了完整的打孔位置指示，通过 EHT-SIG 字段中的打孔位图告知接收端哪些 20MHz 子信道被禁用。实现时最容易出错的是打孔位图的 bit 顺序——它从主 20MHz 开始编号，且打孔位置不能包含主 20MHz。

发送端行为在驱动里表现为：扫描到某个 20MHz 被雷达或强干扰占用，就把对应 bit 置 1，其余子信道正常传输。接收端碰到打孔包时，要能正确解析 EHT-SIG 并跳过打孔位置做信道估计。这里有个坑：D3.0 限定了打孔位置数量上限，不是任意打孔都合法。超过上限的配置会被接收端当作无效包丢弃。

3.4 用 Python 按 bit 位校验 EHT Capabilities 元素

EHT Capabilities 元素是能力协商的核心，每个 bit 都对应一个能力。D3.0 里该元素的字段顺序和 D2.0 有差异，如果按旧版解析会错位一整节。

# 解析 EHT Capabilities 元素的关键 bit（D3.0 定义） # 数据来自抓包中的 bytes 数组，cap[0] 是第一个能力字节 def parse_eht_cap(cap): result = {} # 字节 0：EHT PHY 能力 result["320mhz_in_6g"] = bool(cap[0] & 0x01) # bit0: 6GHz 320MHz result["320mhz_160_160"] = bool(cap[0] & 0x02) # bit1: 160+160 result["242ton"] = bool(cap[0] & 0x04) # bit2: 242MHz 打孔 # 字节 1：MLO 相关标志 result["mlo_support"] = bool(cap[1] & 0x01) result["emlsr_support"] = bool(cap[1] & 0x02) # D3.0 新增 return result

bit 偏移务必与 D3.0 的表格逐位对应。常见做法是先打印 raw bytes 对照标准表人工核对一次，再写自动化解析。EHT Capabilities 元素内部的字段长度不固定，如果要支持后续版本，建议用元素 ID 加偏移的方式解析，而不是硬编码字节下标。参数说明上，cap[0]的 bit0 和 bit1 容易被混淆，连续 320 与非连续 320 是独立能力位，AP 可能只支持其中一个。

4. MLO 与 MAC 层避坑：字段语义、能力协商与自动重传的变化

4.1 EMLSR/EMLMR：D3.0 补齐的链路切换状态机

MLO 的实现在 D2.0 里最头疼的是 EMLSR 缺信令细节。D3.0 把 EMLSR 操作模式、dormant link 的进入和退出条件，以及 EM LMR（多链路单射频）的流量镜像规则都补齐了。这意味着你终于可以把“链路切换”从概念变成代码。

EMLSR 的核心是：非 AP MLD 声明支持 EMLSR 后，它的多条链路在单一射频下交替监听，AP 需要知道哪些链路处于 dormant 状态，以及什么时候可以把流量切到唤醒链路。D3.0 里定义了 EMLSR 模式的通知帧和切换触发条件，没有按 D3.0 实现的话，AP 发往 dormant link 的帧会一直得不到响应，表现为链路“假死”。

4.2 TID-to-Link 映射：从建议性到约束性

TID-to-Link 映射决定 QoS 流走哪条链路。D2.0 里这个映射是建议性的，D3.0 细化了映射切换的时机和同步要求。具体到代码，就是 driver 里的 traffic classifier 要能动态把不同 TID 的报文分发到不同链路。

这里最容易翻车的场景：AP 侧改了 TID-to-Link 映射，但没有通过对应信令通知非 AP MLD，结果报文持续走旧链路。D3.0 要求映射变更要在特定帧交换序列内完成，且双方需要确认。实现上我建议把映射表放在一个单独的结构体里，变更时先缓存新映射，确认后再原子切换，避免中间态丢包。链路切换期间不发数据，这是很多早期实现忽略的，导致切换瞬间吞吐掉到零。

4.3 自动重传（AR）的语义反转：D3.0 删了什么

D2.0 里自动重传被列为一个可协商能力，很多芯片厂商在早期宣传里写“支持 AR”。D3.0 决定把 AR 从能力协商中移除，回到传统 802.11 的 ARQ 机制。这对测试的影响很大：如果你按 D2.0 的协商位测试 AR 能力，D3.0 设备上这个 bit 已经不存在，测试脚本会误报“功能缺失”。

注意：D3.0 文档里你仍能看到 AR 相关文本，但已标注为“不使用”或“待清理”。实现时直接忽略相关字段，不要因此改变重传行为。

4.4 避坑清单：协议栈开发中的五个真实踩坑记录

坑 1：EHT Capabilities 解析错位现象：关联完成后，AP 上报的能力集和驱动解析的结果不一致，某些能力标志缺失。 原因：D3.0 调整了 EHT Capabilities 元素内部字段顺序，驱动仍按 D2.0 的偏移解析。 解决：按 D3.0 的字段表重建解析结构，并用 raw bytes 打印做一次人工核对。

坑 2：EMLSR 链路假死现象：非 AP MLD 声明支持 EMLSR 后，AP 往次要链路发帧，对方不回应，重传超时。 原因：驱动没有实现 dormant link 状态跟踪，AP 不知道链路已休眠。 解决：实现 EMLSR 模式通知帧解析，维护每条链路的活跃状态，AP 侧只在 activity link 上调度数据。

坑 3：320MHz 速率算低约 8%现象：实测吞吐比预期低约 8%，但信道占用和 MCS 都正常。 原因：速率表还在用 5/6 码率计算 4096-QAM，D3.0 已改为 13/12。 解决：更新速率表公式，重跑一次 PHY 速率校准。

坑 4：打孔位置非法导致丢包现象：接收端对某些打孔配置的包完全不响应，日志里没有解析错误。 原因：打孔位置超过了 D3.0 允许的上限，接收端直接丢弃。 解决：发送端在组包前校验打孔位图合法性，非法配置回退到全带宽模式。

坑 5：TID-to-Link 切换瞬间丢包现象：切换映射后，短暂出现高丢包，TCP 吞吐下降。 原因：映射切换没有做原子操作，中间态报文被发往旧链路。 解决：映射变更先缓存，确认后原子切换，切换期间暂停发送。

5. 从 D2.0 迁移到 D3.0：变更清单、测试矩阵与验证习惯

5.1 一张可以直接当检查单的迁移核对表

如果你团队里代码还在 D2.0 阶段，整理一份核对表比什么都强。我每次接手新草案都先建这张表，D3.0 这张是这样列的：

这张表不挑剔工具，用在线表格或手写都行，关键是每一项都能对应到具体代码文件和测试用例。转给硬件测试同事时，最好附上“涉及子条款号”一列，方便查原始文档。

5.2 最小测试矩阵：覆盖关联、协商与吞吐回退

迁移完代码，跑一轮最小测试矩阵就够了。我常用的 D3.0 回归矩阵包含四个用例：

测试结果记得和抓包对应起来，不要只记 PASS/FAIL。比如能力协商用例失败时，导出一份关联请求和关联响应帧的 EHT Capabilities 字段对比，问题出在哪个 bit 一目了然。

5.3 一个具体技巧：用修订记录做回归范围判断

D3.0 修订记录里每个 CID 都对应一处变更。我在做迁移时有个习惯：先把修订记录里涉及 MAC 和 PHY 的条目列出来，标注“影响驱动”或“影响固件”，再决定先改哪块。这个做法在时间紧的时候特别有用，能帮你跳过与你无关的文本修订，集中精力处理信令和速率相关的改动。

从那以后，我每次拿到新草案第一件事不再是打开正文，而是先翻修订记录建变更清单，然后按清单去核对代码。这个习惯帮我避开了好几次把旧版本实现带进新测试的翻车。D3.0 既然已经定稿了这么多关键信令，尽早对齐规范，比你在实验室里“试错式调参”要省太多时间。希望这份笔记里的检索路径和核对方法能帮你少走几趟弯路，也让你在拿到新草案时不再对着 PDF 发愁。

本文还有配套的精品资源，点击获取