简介IEEE P802.11beWi-Fi 7Draft 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.0Wi-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 正文约六百页逐页读效率太低。我一般按子条款号建立检索地图问题是“这个字段在哪定义、这个流程在哪个图里”。常用位点如下表。内容子条款位置典型用途EHT Capabilities 元素35.3.2能力协商、bit 位解析MLO 建立与链路添加35.4.1AP MLD 与非 AP MLD 关联流程EMLSR/EMLMR 链路切换35.4.17dormant link 恢复与流量镜像4096-QAM 调制参数36.3.7速率表、编码参数320MHz 与 240MHz 带宽36.3.9信道带宽与 RU 分配前导码打孔Puncturing36.3.11打孔位置、EHT-SIG 指示自动重传AR35.3.5D3.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 变化4096-QAM 编码率5/6改为 13/12实际等效提高约 8.3% 速率EMLSR 链路切换概念存在信令不全补齐 EMLSR/EMLMR 操作模式、dormant link 状态机自动重传AR可选项从能力协商中移除不再作为强制/可选能力320MHz 操作支持 320MHz 连续明确 320MHz 与 160160MHz 的非连续模型TID-to-Link 映射建议性细化映射与切换时序约束多频段操作MBB未完整新增 MBB 相关信令与操作框架这张表我贴在很多同事工位上。用 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/{flag1} /^36\./{flag0} 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_duration12.8usdata_subcarriers392典型 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(fEstimated PHY rate: {rate_mbps:.1f} Mbps)这段代码的用途不是算最终速率而是帮你建立参数变化的敏感度。bits_per_symbol是每子载波比特数4096-QAM 为 12coding_rate在 D3.0 中要带 13/12 系数。如果把 13/12 漏掉速率值会偏低约 8%你在测试报告里看到的吞吐差异可能就来自这里。另外注意data_subcarriers取决于带宽和打孔情况不同 RU 分配下这个值会变不能固定用 392。3.2 320MHz 带宽模型连续与非连续的 RU 分配差异D3.0 对 320MHz 的定义做了收敛320MHz 连续信道可用160160MHz 非连续也保留但非连续模式下信令流程更复杂。驱动实现里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 160160 return False, invalid这个判断逻辑的价值在于D3.0 允许 160160 非连续但要求每个 160MHz 块内部连续。很多测试脚本只判断总带宽等于 320MHz忽略了块内连续性导致信道配置在合规性测试中被判失败。is_contiguous函数按信道编号差值为 1 判断即可。如果你在做信道可用性扫描还要把雷达检测和 DFS 状态加进判断条件这里只是最基础的合法性校验。3.3 前导码打孔PuncturingD3.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 元素的关键 bitD3.0 定义 # 数据来自抓包中的 bytes 数组cap[0] 是第一个能力字节 def parse_eht_cap(cap): result {} # 字节 0EHT PHY 能力 result[320mhz_in_6g] bool(cap[0] 0x01) # bit0: 6GHz 320MHz result[320mhz_160_160] bool(cap[0] 0x02) # bit1: 160160 result[242ton] bool(cap[0] 0x04) # bit2: 242MHz 打孔 # 字节 1MLO 相关标志 result[mlo_support] bool(cap[1] 0x01) result[emlsr_support] bool(cap[1] 0x02) # D3.0 新增 return resultbit 偏移务必与 D3.0 的表格逐位对应。常见做法是先打印 raw bytes 对照标准表人工核对一次再写自动化解析。EHT Capabilities 元素内部的字段长度不固定如果要支持后续版本建议用元素 ID 加偏移的方式解析而不是硬编码字节下标。参数说明上cap[0]的 bit0 和 bit1 容易被混淆连续 320 与非连续 320 是独立能力位AP 可能只支持其中一个。4. MLO 与 MAC 层避坑字段语义、能力协商与自动重传的变化4.1 EMLSR/EMLMRD3.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 避坑清单协议栈开发中的五个真实踩坑记录坑 1EHT Capabilities 解析错位现象关联完成后AP 上报的能力集和驱动解析的结果不一致某些能力标志缺失。 原因D3.0 调整了 EHT Capabilities 元素内部字段顺序驱动仍按 D2.0 的偏移解析。 解决按 D3.0 的字段表重建解析结构并用 raw bytes 打印做一次人工核对。坑 2EMLSR 链路假死现象非 AP MLD 声明支持 EMLSR 后AP 往次要链路发帧对方不回应重传超时。 原因驱动没有实现 dormant link 状态跟踪AP 不知道链路已休眠。 解决实现 EMLSR 模式通知帧解析维护每条链路的活跃状态AP 侧只在 activity link 上调度数据。坑 3320MHz 速率算低约 8%现象实测吞吐比预期低约 8%但信道占用和 MCS 都正常。 原因速率表还在用 5/6 码率计算 4096-QAMD3.0 已改为 13/12。 解决更新速率表公式重跑一次 PHY 速率校准。坑 4打孔位置非法导致丢包现象接收端对某些打孔配置的包完全不响应日志里没有解析错误。 原因打孔位置超过了 D3.0 允许的上限接收端直接丢弃。 解决发送端在组包前校验打孔位图合法性非法配置回退到全带宽模式。坑 5TID-to-Link 切换瞬间丢包现象切换映射后短暂出现高丢包TCP 吞吐下降。 原因映射切换没有做原子操作中间态报文被发往旧链路。 解决映射变更先缓存确认后原子切换切换期间暂停发送。5. 从 D2.0 迁移到 D3.0变更清单、测试矩阵与验证习惯5.1 一张可以直接当检查单的迁移核对表如果你团队里代码还在 D2.0 阶段整理一份核对表比什么都强。我每次接手新草案都先建这张表D3.0 这张是这样列的检查项涉及模块D3.0 要求完成状态EHT Capabilities 解析MAC/MLME按 D3.0 字段顺序重写待办4096-QAM 速率表PHY码率改为 13/12待办320MHz 配置PHY/信道管理区分连续与非连续模式待办EMLSR/EMLMRMLO实现 dormant link 状态机待办TID-to-Link 映射MLO/QoS原子切换与同步确认待办自动重传MAC删除 D2.0 协商位处理待办前导码打孔PHY按 D3.0 限制校验打孔位图待办这张表不挑剔工具用在线表格或手写都行关键是每一项都能对应到具体代码文件和测试用例。转给硬件测试同事时最好附上“涉及子条款号”一列方便查原始文档。5.2 最小测试矩阵覆盖关联、协商与吞吐回退迁移完代码跑一轮最小测试矩阵就够了。我常用的 D3.0 回归矩阵包含四个用例测试用例前置条件预期结果失败特征EHT Capabilities 关联协商D3.0 AP D3.0 STA双方能力 bit 对齐能力解析错位320MHz 连续带宽6GHz 连续四信道PHY 速率达到预期速率偏低 8%160160 非连续带宽6GHz 两个分离 160MHz正常建链且速率正确信道配置非法EMLSR 链路切换双链路非 AP MLD休眠链路自动唤醒链路假死测试结果记得和抓包对应起来不要只记 PASS/FAIL。比如能力协商用例失败时导出一份关联请求和关联响应帧的 EHT Capabilities 字段对比问题出在哪个 bit 一目了然。5.3 一个具体技巧用修订记录做回归范围判断D3.0 修订记录里每个 CID 都对应一处变更。我在做迁移时有个习惯先把修订记录里涉及 MAC 和 PHY 的条目列出来标注“影响驱动”或“影响固件”再决定先改哪块。这个做法在时间紧的时候特别有用能帮你跳过与你无关的文本修订集中精力处理信令和速率相关的改动。从那以后我每次拿到新草案第一件事不再是打开正文而是先翻修订记录建变更清单然后按清单去核对代码。这个习惯帮我避开了好几次把旧版本实现带进新测试的翻车。D3.0 既然已经定稿了这么多关键信令尽早对齐规范比你在实验室里“试错式调参”要省太多时间。希望这份笔记里的检索路径和核对方法能帮你少走几趟弯路也让你在拿到新草案时不再对着 PDF 发愁。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 20:47:46 · 阅读 1.2k Wi-Fi 7草案D3.0解读：MLO、4096-QAM与320MHz关键变更
简介IEEE P802.11beWi-Fi 7Draft 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.0Wi-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 正文约六百页逐页读效率太低。我一般按子条款号建立检索地图问题是“这个字段在哪定义、这个流程在哪个图里”。常用位点如下表。内容子条款位置典型用途EHT Capabilities 元素35.3.2能力协商、bit 位解析MLO 建立与链路添加35.4.1AP MLD 与非 AP MLD 关联流程EMLSR/EMLMR 链路切换35.4.17dormant link 恢复与流量镜像4096-QAM 调制参数36.3.7速率表、编码参数320MHz 与 240MHz 带宽36.3.9信道带宽与 RU 分配前导码打孔Puncturing36.3.11打孔位置、EHT-SIG 指示自动重传AR35.3.5D3.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 变化4096-QAM 编码率5/6改为 13/12实际等效提高约 8.3% 速率EMLSR 链路切换概念存在信令不全补齐 EMLSR/EMLMR 操作模式、dormant link 状态机自动重传AR可选项从能力协商中移除不再作为强制/可选能力320MHz 操作支持 320MHz 连续明确 320MHz 与 160160MHz 的非连续模型TID-to-Link 映射建议性细化映射与切换时序约束多频段操作MBB未完整新增 MBB 相关信令与操作框架这张表我贴在很多同事工位上。用 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/{flag1} /^36\./{flag0} 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_duration12.8usdata_subcarriers392典型 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(fEstimated PHY rate: {rate_mbps:.1f} Mbps)这段代码的用途不是算最终速率而是帮你建立参数变化的敏感度。bits_per_symbol是每子载波比特数4096-QAM 为 12coding_rate在 D3.0 中要带 13/12 系数。如果把 13/12 漏掉速率值会偏低约 8%你在测试报告里看到的吞吐差异可能就来自这里。另外注意data_subcarriers取决于带宽和打孔情况不同 RU 分配下这个值会变不能固定用 392。3.2 320MHz 带宽模型连续与非连续的 RU 分配差异D3.0 对 320MHz 的定义做了收敛320MHz 连续信道可用160160MHz 非连续也保留但非连续模式下信令流程更复杂。驱动实现里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 160160 return False, invalid这个判断逻辑的价值在于D3.0 允许 160160 非连续但要求每个 160MHz 块内部连续。很多测试脚本只判断总带宽等于 320MHz忽略了块内连续性导致信道配置在合规性测试中被判失败。is_contiguous函数按信道编号差值为 1 判断即可。如果你在做信道可用性扫描还要把雷达检测和 DFS 状态加进判断条件这里只是最基础的合法性校验。3.3 前导码打孔PuncturingD3.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 元素的关键 bitD3.0 定义 # 数据来自抓包中的 bytes 数组cap[0] 是第一个能力字节 def parse_eht_cap(cap): result {} # 字节 0EHT PHY 能力 result[320mhz_in_6g] bool(cap[0] 0x01) # bit0: 6GHz 320MHz result[320mhz_160_160] bool(cap[0] 0x02) # bit1: 160160 result[242ton] bool(cap[0] 0x04) # bit2: 242MHz 打孔 # 字节 1MLO 相关标志 result[mlo_support] bool(cap[1] 0x01) result[emlsr_support] bool(cap[1] 0x02) # D3.0 新增 return resultbit 偏移务必与 D3.0 的表格逐位对应。常见做法是先打印 raw bytes 对照标准表人工核对一次再写自动化解析。EHT Capabilities 元素内部的字段长度不固定如果要支持后续版本建议用元素 ID 加偏移的方式解析而不是硬编码字节下标。参数说明上cap[0]的 bit0 和 bit1 容易被混淆连续 320 与非连续 320 是独立能力位AP 可能只支持其中一个。4. MLO 与 MAC 层避坑字段语义、能力协商与自动重传的变化4.1 EMLSR/EMLMRD3.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 避坑清单协议栈开发中的五个真实踩坑记录坑 1EHT Capabilities 解析错位现象关联完成后AP 上报的能力集和驱动解析的结果不一致某些能力标志缺失。 原因D3.0 调整了 EHT Capabilities 元素内部字段顺序驱动仍按 D2.0 的偏移解析。 解决按 D3.0 的字段表重建解析结构并用 raw bytes 打印做一次人工核对。坑 2EMLSR 链路假死现象非 AP MLD 声明支持 EMLSR 后AP 往次要链路发帧对方不回应重传超时。 原因驱动没有实现 dormant link 状态跟踪AP 不知道链路已休眠。 解决实现 EMLSR 模式通知帧解析维护每条链路的活跃状态AP 侧只在 activity link 上调度数据。坑 3320MHz 速率算低约 8%现象实测吞吐比预期低约 8%但信道占用和 MCS 都正常。 原因速率表还在用 5/6 码率计算 4096-QAMD3.0 已改为 13/12。 解决更新速率表公式重跑一次 PHY 速率校准。坑 4打孔位置非法导致丢包现象接收端对某些打孔配置的包完全不响应日志里没有解析错误。 原因打孔位置超过了 D3.0 允许的上限接收端直接丢弃。 解决发送端在组包前校验打孔位图合法性非法配置回退到全带宽模式。坑 5TID-to-Link 切换瞬间丢包现象切换映射后短暂出现高丢包TCP 吞吐下降。 原因映射切换没有做原子操作中间态报文被发往旧链路。 解决映射变更先缓存确认后原子切换切换期间暂停发送。5. 从 D2.0 迁移到 D3.0变更清单、测试矩阵与验证习惯5.1 一张可以直接当检查单的迁移核对表如果你团队里代码还在 D2.0 阶段整理一份核对表比什么都强。我每次接手新草案都先建这张表D3.0 这张是这样列的检查项涉及模块D3.0 要求完成状态EHT Capabilities 解析MAC/MLME按 D3.0 字段顺序重写待办4096-QAM 速率表PHY码率改为 13/12待办320MHz 配置PHY/信道管理区分连续与非连续模式待办EMLSR/EMLMRMLO实现 dormant link 状态机待办TID-to-Link 映射MLO/QoS原子切换与同步确认待办自动重传MAC删除 D2.0 协商位处理待办前导码打孔PHY按 D3.0 限制校验打孔位图待办这张表不挑剔工具用在线表格或手写都行关键是每一项都能对应到具体代码文件和测试用例。转给硬件测试同事时最好附上“涉及子条款号”一列方便查原始文档。5.2 最小测试矩阵覆盖关联、协商与吞吐回退迁移完代码跑一轮最小测试矩阵就够了。我常用的 D3.0 回归矩阵包含四个用例测试用例前置条件预期结果失败特征EHT Capabilities 关联协商D3.0 AP D3.0 STA双方能力 bit 对齐能力解析错位320MHz 连续带宽6GHz 连续四信道PHY 速率达到预期速率偏低 8%160160 非连续带宽6GHz 两个分离 160MHz正常建链且速率正确信道配置非法EMLSR 链路切换双链路非 AP MLD休眠链路自动唤醒链路假死测试结果记得和抓包对应起来不要只记 PASS/FAIL。比如能力协商用例失败时导出一份关联请求和关联响应帧的 EHT Capabilities 字段对比问题出在哪个 bit 一目了然。5.3 一个具体技巧用修订记录做回归范围判断D3.0 修订记录里每个 CID 都对应一处变更。我在做迁移时有个习惯先把修订记录里涉及 MAC 和 PHY 的条目列出来标注“影响驱动”或“影响固件”再决定先改哪块。这个做法在时间紧的时候特别有用能帮你跳过与你无关的文本修订集中精力处理信令和速率相关的改动。从那以后我每次拿到新草案第一件事不再是打开正文而是先翻修订记录建变更清单然后按清单去核对代码。这个习惯帮我避开了好几次把旧版本实现带进新测试的翻车。D3.0 既然已经定稿了这么多关键信令尽早对齐规范比你在实验室里“试错式调参”要省太多时间。希望这份笔记里的检索路径和核对方法能帮你少走几趟弯路也让你在拿到新草案时不再对着 PDF 发愁。本文还有配套的精品资源点击获取