简介：这份PDF文档收录了IEEE 802.11be（WiFi 7）协议草案英文原文，版本为IEEE P802.11be/D3.0（2023年1月），面向无线通信工程师、网络协议研究人员及高校相关专业学生，可用于查阅极高吞吐量（EHT）下MAC层与PHY层的规范细节，并了解1至7.250GHz频段内、目标吞吐量至少30Gbit/s的设计要求。资源为1个PDF文件，压缩包整体6.85MB，便于离线阅读和标注。内容覆盖320MHz频宽、4096-QAM调制、多链路操作（MLO）、增强型MU-MIMO、TWT节能机制及WPA3安全等WiFi 7关键特性，可作为对比WiFi 6（802.11ax）演进差异的一手参考资料。该文档已有8954人学习/下载，是当前较受关注的WiFi 7协议草案。需要注意的是，此版本为IEEE草案而非最终正式标准，但其中关于信道规划、帧格式、接入机制和后向共存的描述，对协议分析、标准预研、毕业设计或技术博客写作仍颇具参考价值；结合其目录结构，也能快速定位各条款。
1. IEEE 802.11be（WiFi7）协议原文 PDF：工程人真正需要的不是参数表，是这条读懂路径
做 WiFi 开发两年，最深的体会是：网上铺天盖地的 WiFi7 科普文，翻来覆去就三件事——4096-QAM、320MHz 带宽、MLO，配几张营销图就完了。可真到了要调吞吐、排查 AMSDU 分片失效、确认 MLO 三链路是否真正并发时，你发现那些文章没有一个能回答你「协议原文到底怎么写的」。这份 IEEE 802.11be 协议原文 PDF 的价值就在这：它不是让你读完的，是让你在规格评审、联调排错、测试用例设计时，能一页一页翻到准确答案的一手依据。适合做 AP/STA 固件、射频测试、路由器方案选型的从业者。这文档不厚也不薄，一千多页，但真正要啃的关节就十来处，下面按工程路径给你拆清楚。
2. 把一千页协议读薄：文档架构、版本与四类必看章节
2.1 拿到 PDF 先看版本：Amendment 状态决定你读的是草稿还是定稿
IEEE 802.11be 这份 PDF 最坑的地方在于版本众多。Draft 1.0、Draft 2.0、Draft 3.0、Draft 4.0，再到最终的 IEEE Std 802.11be-2023，每一版在 MLO 的 Channel Switching 字段、EHT Operation Element 的长度定义上都有改动。我手里这份资源是协议原文 PDF，但你在下载后第一步要做的不是翻正文，而是打开首页确认 Amendment 标识和出版日期。
提示：如果首页写的是 "IEEE P802.11be/D4.0"，说明是草案，不能直接作为产品合规依据；只有盖了 "IEEE Std" 字样的才算是正式标准。做设计引用时，草稿和定稿的差异集中在 EHT Capabilities 的字段位序，引用错了，固件联调直接对不上。
确认版本后，用 PDF 阅读器的书签栏把目录导出来。11be 的目录结构沿用了 802.11 系列一贯的组织方式，Part 1 是 Management，Part 2 是 MAC，Part 3 是 PHY。对工程师来说，第四类必看章节如下表：
| 章节范围 | 内容定位 | 阅读优先级 |
|---|---|---|
| 9.x（MLO 相关） | Multi-Link Operation 的建立、拆除与寻址 | 最高，直接影响多链路产品功能 |
| 10.x（EHT Operation Element） | 必选/可选能力协商、EHT Capabilities 位图 | 最高，联调必翻 |
| 12.x（EHT PHY） | 4096-QAM、320MHz、EHT-LTF 序列 | 高，测试向量设计靠它 |
| 35.x（EHT PPDU 格式） | PPDU 的结构、前导码、U-SIG 字段 | 高，抓包解析对齐用 |
2.2 从目录到 PPDU：一条从「文字」到「抓包字节」的映射线
读协议原文最忌讳从头到尾当小说看。我一般按「三层映射线」读：先是 Management 层的帧格式与状态机，再往下落到 MAC 层的数据封装，最后到底层 PHY 的 PPDU 结构。这条线对应到具体章节是 9（帧格式）→ 35（EHT PHY 格式）→ 36（EHT-LTF 序列）。
举个例子，你要搞清楚 320MHz 带宽下 EHT-LTF 的序列怎么生成，光看文字描述远远不够。协议里给的是基础序列映射表，你需要配合 MATLAB 或 Python 的 802.11 工具箱复现一遍。这类工作不是「读文档」而是「对文档」，建议把 PDF 里对应的公式截图，粘贴到自己的设计笔记里，并标注「这是哪一个 table number」，以后写测试脚本时直接按图号回溯。
2.3 读协议的三件套工具：书签、全文检索、段号引用
工程上引用协议条款，讲究的是「可回溯」。我习惯在 PDF 里用三个工具读这一千多页：书签目录做章节导航、全文检索做关键词定位、段号做沟通语言。比如调试 MLO 时发现对端设备始终不响应 Setup 帧，很大概率是怪在 EHT Operation 里的 MLO 参数没配对。
注意：跟芯片原厂 FAE 沟通时，别只说「MLO 连不上」，要报「按照 802.11be 35.3.17 的 EHT MU PPDU 里的 RU Allocation 字段解析，bit 位对不上」。段号一报，对方立刻知道你在哪一层出了问题。
3. MLO 多链路机制与 320MHz 带宽：协议里的核心参数表与工程含义
3.1 MLO 的三种模式：STR、eMLSR 与 NSTR，协议怎么定义、产品怎么选
MLO（Multi-Link Operation）是 11be 最重要的架构级新增。协议把链路之间的关系分成三类：STR（Simultaneous Transmit/Receive）、eMLSR（Enhanced Multi-Link Single-Radio）、NSTR（Non-STR）。三者的本质差异在于射频并发能力，直接决定产品能否做到「三条链路同时收发」。
我在实际做方案时是这样区分的：STR 模式下每个链路独立射频，吞吐叠加最直接，但成本高、功耗大；eMLSR 是单射频分时复用，适合 IoT 网关这类低成本设备；NSTR 则要求链路间有明确的收发约束。协议 35.3.4 节给了 MLO 的 capability 字段表，其中 STR 相关的 "STR" 字段 bit 位定义你要在固件初始化时跟 RF 前端驱动对齐，否则使能了 MLO 却发现射频不支持并发，日志里会出现 EHT-MLO Setup 失败。
MLO 的建立流程在协议里被拆成 Setup/Teardown/Reconfiguration 三个阶段。工程上最容易忽略的是 Setup 阶段对链路 ID 的分配——协议允许最多 8 个 link，但每个 link 有独立 MAC 地址。固件里如果只用了一个 MAC 地址做三条链路的寻址，对端会在链路切换时丢包。
3.2 320MHz 带宽与 4096-QAM：速率表怎么查、测试向量怎么造
320MHz 带宽是 WiFi7 在 PHY 层的标志性参数。但要注意，320MHz 只在 6GHz 频段可用，5GHz 以下受限于信道划分最多只能到 240MHz。协议里的 MCS 速率表（位于 12.5 节之后的附表）给出了 16 个 MCS 档位，其中 MCS 14 和 15 对应 4096-QAM，只有在接收端 SNR 足够高时才建议使用。
| MCS 档位 | 调制方式 | 320MHz、2.4Gbps 级别速率（4x4 MIMO 算例） | 适用距离 |
|---|---|---|---|
| MCS 0 | BPSK | 约 115Mbps | 最远 |
| MCS 7 | 64-QAM | 约 920Mbps | 中距 |
| MCS 11 | 1024-QAM | 约 1.8Gbps | 近距 |
| MCS 13 | 4096-QAM | 约 2.8Gbps | 极近、高 SNR |
工程上造测试向量时，不能只看调制阶数，还要看码率。4096-QAM 的码率是 5/6，而 1024-QAM 高码率档是 3/4，两者吞吐差一截，但对 EVM 的要求也完全不同。频谱仪上测 4096-QAM 时，EVM 门限一般在 -38dB 以下，而 WiFi6 的 1024-QAM 只要 -35dB。换句话说，用旧的射频前端直接跑 4096-QAM，往往不是协议问题，而是硬件底噪达不到。
3.3 PPDU 结构对比：EHT MU PPDU 里的 U-SIG 与 RU Allocation 怎么解析
11be 的 PPDU 格式保留了 11ax 的 HE-SIG-B 结构，但在 EHT MU PPDU 中引入了 U-SIG（Universal SIG）字段，用于承载版本无关的信息。你在抓包工具里看到 EHT PPDU 时，解析顺序是：L-STF → L-LTF → L-SIG → RL-SIG → U-SIG → EHT-SIG → EHT-STF → EHT-LTF → Data。
一个常见误区是拿 11ax 的解析流程直接套 11be。EHT-SIG 的存在与否取决于带宽和 MCS，当带宽为 320MHz 且 MCS 低于某个阈值时，EHT-SIG 会被简化甚至省略，RU Allocation 信息全部由 U-SIG 中的字段给出。我在写抓包解析插件时，吃过一次亏：按 11ax 的 HE-SIG-B 偏移去读字节，导致 RU 起始位置偏了一位，整个数据符号解出来全是乱码。后来对照协议 35.3.10 的 EHT MU PPDU 格式图，才发现 U-SIG 里还带了一个 3bit 的 "Bandwidth" 字段，320MHz 的编码值是 0b010，和 160MHz 完全不同。
4. 从协议条文到产品选型：WiFi7 路由器和设备如何对应到每一页文档
4.1 看芯片方案先对协议功能表：capability 位图才是真正的「选型对照表」
做路由器方案选型时，原厂会给一堆 marketing 级别的参数表：峰值速率、频段、MIMO 数。但作为工程师，我更建议你拉一份协议的 capability 位图去逐项对照。协议里 EHT Capabilities 字段是按 bit 定义的，比如 bit 0 是 320MHz in 6GHz、bit 1 是 MLO、bit 2 是 eMLSR，不同芯片厂商对支持位的开启策略完全不同，直接决定了固件里哪些 feature 可以开、哪些开了也只是空转。
| 能力位 | 协议定义 | 工程含义 |
|---|---|---|
| 320MHz in 6GHz | 支持 320MHz 信道宽度 | 需要射频前端支持 6GHz 频段和宽带宽滤波器 |
| MLO | 支持多链路操作 | 需要 MAC 层多链路状态机、多个 MAC 地址管理 |
| 4096-QAM | 支持更高阶调制 | 需要 PA 线性度和 EVM 余量，测试环境要求高 |
| Multi-RU | 支持多个 RU 聚合 | 和调度器行为强相关，固件复杂度上升 |
我在选 SoC 时会把「协议支持位」和「实测能力」分开看。有些芯片在能力位里宣称支持 320MHz，但实际 RF 前端只有 160MHz 的 SAW 滤波器，开了 320MHz 模式后整个频段临频干扰严重。这类问题说明书里不会写，只有对着协议条文去做传导测试才能逼出来。
4.2 测试与验收：报吞吐低不是答案，要能定位到 MCS 回退还是 CCA 误判
测试 WiFi7 AP 时，最常见的验收口径是「用 iPerf 打出来只有 1.2Gbps，不够」。但这个结论对排查没有帮助，因为低吞吐的可能原因有十几层。我的做法是先用协议条文框定排查边界：第一步看 MCS 协商结果，确认双方是否在 4096-QAM 且最高档码率上；第二步看信道带宽，客户端是否真的关联在 320MHz 上，还是因为 DFS 或雷达检测回退到了 160MHz；第三步看 MLO 状态，多链路是否真的同时在工作。
这三步分别对应协议的不同章节：MCS 由速率自适应算法决定，查 12.5 节速率表；带宽状态看 EHT Operation Element 里的 Channel Width 字段；MLO 状态查链路 ID 映射。当三步走完仍然低吞吐，才会怀疑到射频底噪、天线隔离度这些非协议因素。这种排查路径，比直接在射频端乱调功率有效得多。
另外要注意，WiFi7 测试里的 4096-QAM 和 320MHz 不是开关式的选项。协议允许在「320MHz + MCS 13」之外存在组合限制，比如 320MHz 带宽下某些 MCS 档位被定义为 Reserved。如果测试脚本里强行设置了不支持组合，AP 会直接按最低能力降级，这时候看日志里会出现 Rate Adaptation 的降级记录。
4.3 WiFi6 与 WiFi8 的关系：11be 不是终点，协议族的演进边界
讨论 802.11be 时绕不开 WiFi6 和 WiFi8。WiFi6（802.11ax）的 OFDMA 和 TWT 在 11be 里被保留，而 WiFi8（802.11bn）已经转向 60GHz 频段的 UHR（Ultra High Reliability）研究。但作为从业者，你更要清醒：WiFi7 的协议原文在 2023 年定稿，产品化却是 2024 到 2025 年才逐步完善。你现在拿到的这份 PDF，用于产品定义没有问题，但如果要写 WiFi8 的预研方案，不能直接在 11be 文档上做增量开发，需要另找 802.11bn 的立项文档。
协议是「活物」这件事，我在 Wi-Fi Alliance 的认证测试里体会最深。同一台设备，在 6GHz 频段跑 320MHz 时，会触发 11be 特有的 Preferred Scanning Channel 机制，而这一机制在 11ax 里是没有的。所以做 WiFi7 产品，光会读 11ax 的旧经验远远不够，必须回到 11be 原文里逐条核对行为差异。
5. 读协议避坑指南：版本、图与字段、TLV 解析的五个典型踩坑记录
5.1 现象：对端上报的 EHT Capabilities 解析出来长度不对，固件直接死机
原因：EHT Capabilities 在 11be 里分为 MAC Capabilities 和 PHY Capabilities 两段，长度随可选字段变化。有些芯片实现里把 PHY Capabilities 里的 "Maximum MPDU Length" 字段扩展到了 4 字节，而解析端还按旧版固定长度读取，导致后续字段全部错位。
解决：解析前不要硬编码长度，先读 EHT Capabilities 第一个字节的 "Length" 字段，再按长度值动态截取。同时保留草稿版本和定稿版本两套解析表，靠判断帧里的 Version 字段切换。
5.2 现象：Wireshark 里能识别出 EHT PPDU，但 RU Allocation 解析出来与协议表格对不上
原因：11be 的 RU Allocation 字段在 320MHz 下能表达的 RU 数量远多于 11ax，不同带宽下的 RU 编号表不一样。Wireshark 的解析插件如果没有更新到支持 11be 的 320MHz 表，就会用 11ax 的 160MHz 表去做映射。
解决：手工对照协议 Table 35-31（EHT RU Allocation）重新编写一段解析逻辑，确认表格索引与带宽字段联动。关键跳转条件：U-SIG 里 Bandwidth=320MHz 时，RU Allocation 的 bit 位从第二位开始解释。
5.3 现象：MLO 三链路同时收发，但 TCP 吞吐反而不如单链路
原因：MLO 建立成功并不代表链路间负载均衡有效。协议里 MLO 的流量分发是在 MAC 层做的，如果三条链路的信道质量差异太大，TCP 的 ACK 走慢链路返回，会导致快链路的发送窗口阻塞。
解决：先在协议层面确认三条链路的 TID-to-Link Mapping 是否被正确协商，再把慢链路的 TID 重映射到快链路上。协议 35.3.5 节给出了 TID 映射的字段定义，重新协商需要在 Reconfiguration 阶段完成。
5.4 现象：320MHz 频段的 DFS 雷达检测频繁误报，AP 自动回退到 160MHz
原因：320MHz 由两个相邻的 160MHz 信道拼接而成，其中任意一个子信道触发雷达检测，整个 link 都要退出。这不是协议 bug，而是 11be 对 DFS 信道的处理策略本就如此。
解决：查协议 35.3.3 节的 Channel Occupancy 限制，确认当前信道的 DFS 标志位；同时把 AP 的信道设置为非 DFS 的 320MHz 信道（如果法规允许），或接受回退逻辑并做链路迁移。
5.5 现象：EHT Operation Element 里携带的 MLO 参数，对端 AP 忽略了
原因：EHT Operation Element 的 MLO 参数分为基础字段和扩展字段，扩展字段是否需要处理由 "MLO Control" 字段里的 bit 位决定。不少 AP 实现只解析了基础字段，扩展字段直接跳过，这在协议上不算违规，但会导致 MLO 的辅助能力（比如 Simultaneous RX/TX 的链路分组）无法生效。
解决：看对端是否在 Association 请求里声明了对应的 MLO Support 子字段。如果声明了却不处理，可以用 Probe Request 主动携带测试参数，观察响应帧的行为，定位是协议栈裁剪问题还是寄存器配置遗漏。
6. 把协议文档用起来：查表法、标注法与一个自查清单
读协议原文不是一遍过，而是要形成自己的工作目录。我的习惯是：把 PDF 按需要拆成三份。「索引本」只保留目录、表格编号和段号目录；「精读本」放 MLO、EHT PHY、PPDU 格式这三大块，每页标注日期和当时正在做的项目；「速查本」是一份自己整理的字段级笔记，格式是「Table 35-31 / RU Allocation / 适用于 320MHz / 注意带宽关联」。这套方法我用了三个项目，效率比从头翻 PDF 高很多。
自查清单可以固定成下面这个模板，每次产品迭代前过一遍：
- 当前固件固化了哪个版本的 802.11be（Draft 还是 Std）？
- EHT Operation Element 里声明的带宽和射频前端实际能力是否一致？
- MLO 的链路 ID 分配是否有冲突，多 MAC 地址是否独立管理？
- 4096-QAM 档位有没有绑定 EVM 测试条件？
- 320MHz 模式下 RU Allocation 解析是否走新表，而不是 11ax 的老表？
- 测试报告里报的峰值速率，对应的是哪一档 MCS、哪一档码率？
最后说一个我自己的教训。去年做 WiFi7 网关项目，临近送样时发现 6GHz 频段的吞吐只有标称值的六成。我花了两天查射频、调天线、换功放，统统没用。后来回到协议原文，翻到 EHT PHY 的 LDPC 编码章节，才发现是固件里把 LDPC 的额外符号位算错了一位，导致解码器每包都触发重传。从那以后，我每次遇到「原理上讲不通的怪问题」，都强制自己先回到协议原文的对应段号，把字段级的 bit 定义重新过一遍，而不是急着动硬件。希望帮到你——这份 PDF 不会直接告诉你答案，但它确实是唯一不会骗你的那本参考书。
本文还有配套的精品资源，点击获取
