《802.11-2024》第08讲 · 聚合与块确认:把「一次一帧」变成「一次一批」

本讲对应 IEEE Std 802.11-2024 的 10.10(MSDU 处理)+ 10.11(A-MSDU 操作)+ 10.12(A-MPDU 操作)+ 10.25(块确认 Block Ack)+ 10.26(No Ack)+ 10.27(保护机制)+ 10.28(MAC 帧处理)+ 10.29(反向授权 RD 协议) 。

第 06--07 讲解决了「怎么把一帧发出去」(DCF/EDCA/HCCA)。本讲回答两个新问题:

怎么把很多帧当「一批」发出去,省下重复开销? ------聚合(A-MSDU / A-MPDU) 与块确认(Block Ack);

怎么让新设备的高速传输不被老设备干扰、老设备也不干扰新设备? ------保护机制(Protection Mechanisms) 。
另外收掉 No Ack、MAC 帧处理规则、RD 反向授权协议 三个配套主题。

阅读目标 :读完本讲,你能分清 A-MSDU(省 MAC 头)与 A-MPDU(省确认)这两种聚合的层次与目的;画出 A-MPDU 的结构(MPDU delimiter + MPDU + padding);讲清块确认的完整流程(ADDBA 建立 → 发一批 → BlockAckReq 请求 → BlockAck 位图应答 → DELBA 拆除);知道 Scoreboard(位图)与接收重排缓冲(WinStartB/WinEndB/WinSizeB)各管什么;理解「隐式 BAR」「立即/延迟块确认」「full-state/partial-state」的含义;明白保护机制为什么存在、non-ERP/HT/VHT/HE 各自怎么保护;知道 RD 协议让 TXOP 持有者把发送权临时转交给对方。与第 06 讲的分片对比:分片是「化整为零抗错」,聚合是「集零为整省开销」------方向正好相反。

一、本讲地图:Clause 10 的「聚合」与「可靠性」段落

小节	内容	规模	主题
10.10	MSDU 处理(U-PID / LLC 头剥离)	短	← 本讲(简述)
10.11	A-MSDU 操作(二层聚合)	中	← 本讲
10.12	A-MPDU 操作(物理层聚合)	中	← 本讲
10.25	块确认 Block Ack(核心)	大	← 本讲
10.26	No Ack 策略	短	← 本讲
10.27	保护机制(non-ERP / HT / VHT / HE)	大	← 本讲
10.28	MAC 帧处理(可扩展性规则)	中	← 本讲
10.29	RD 反向授权协议	中	← 本讲

一句话:聚合解决「开销」,块确认解决「确认开销」,保护机制解决「新旧共存」,RD 解决「信道利用率」------这四件事共同把 802.11 从「一帧一确认」的朴素 DCF 推向「一批一发、一批一认」的高效世界。

二、聚合总览:两个「省」的方向(10.11 / 10.12)

2.1 无线信道的两笔「重复开销」

发一帧数据,要付两笔与数据无关的固定开销:

开销	来源	怎么省
帧头开销	每个 MAC 帧都有 24--30 字节头部 + 加密头等	把多个 MSDU 塞进一个 MPDU → A-MSDU
接入开销	每个 MPDU 都要竞争、等确认	把多个 MPDU 塞进一个 PPDU ,一次确认 → A-MPDU + 块确认

记忆:A-MSDU 省「头」,A-MPDU 省「抢信道 + 确认」。两者可叠加:A-MSDU 造出来的大 MPDU 再装进 A-MPDU。

2.2 层次关系:从 MSDU 到 PPDU 的「套娃」

复制代码

     MSDU │ MSDU │ MSDU │          (LLC 来的上层数据单元)
      └──────┬──────┘
   A-MSDU  ┌─────────┐             = 多个 MSDU 拼一个帧体(省 MAC 头)
           │ A-MSDU  │             (封装进一个 QoS Data MPDU 的帧体)
           └────┬────┘
     MPDU   MPDU│ MPDU  MPDU       (MAC 帧:每个仍带自己的 MAC 头/地址/SN)
      └─────────┬────────┘
   A-MPDU ┌──────────────┐         = 多个 MPDU 拼一个 PSDU(省确认/竞争)
          │ A-MPDU        │
          └──────┬───────┘
    PPDU  ┌─────────────────┐     (PLCP 头 + 数据;一个 PPDU 就是一次「占用信道」)
          │   PPDU           │
          └─────────────────┘

A-MSDU(Aggregate MSDU) :在 MAC 层之上 聚合------多个 MSDU 共用一个 MAC 头,每个 MSDU 前加一个小的 A-MSDU 子帧头(DA/SA/长度);
A-MPDU(Aggregate MPDU) :在 MAC 层之下、PHY 层之上 聚合------多个完整的 MPDU 共用一个 PLCP 头,每个 MPDU 前加 MPDU delimiter(4 字节分隔符);
二者都不改变 CSMA/CA 的接入规则:聚合后仍是一整个 PPDU 参与竞争与确认。

2.3 分片 vs 聚合------方向相反的两个工具

维度	分片(第 06 讲,10.4)	聚合(本讲)
目的	抗错:帧越短,误码率越低	省开销:帧越整,头/确认越少
方向	把 1 个长 MSDU 拆成多个短 MPDU	把多个 MSDU/MPDU 拼成 1 个大单元
可靠性	逐片独立确认、坏一片重传一片	靠块确认一次性确认一批
适用	误码率高的信道	速率高、开销占比大的信道

一句话:分片 = 化整为零保可靠;聚合 = 集零为整提效率。

三、A-MSDU 操作(10.11)------「省 MAC 头的聚合」

3.1 基本规则

A-MSDU 只包含 DA 都映射到同一 RA、SA 都映射到同一 TA 的 MSDU(即发往同一接收方的一组 MSDU);
A-MSDU 封装在一个 QoS Data MPDU 的帧体 里,靠 QoS Control 的 A-MSDU Present 位标记;
每个子帧头包含 DA / SA / 长度 与填充(Padding),接收方据此拆出各 MSDU 交给 LLC;
RA 限制:A-MSDU 帧的 RA 一般是单播地址;只有 AP/PCP、IBSS/PBSS/Mesh 之间的组播场景、或 GLK 的 SYNRA 才允许 RA 为组地址;
安全限制 :加密的 A-MSDU 分 PP A-MSDU(净荷保护) 与 SPP A-MSDU(信令+净荷保护)------后者把「是否聚合」的标记也纳入加密(防攻击者篡改 A-MSDU Present 位)。

3.2 子帧格式与长度限制

子帧格式	特点	使用者
Basic A-MSDU	DA + SA + 长度(固定头)	通用
Dynamic A-MSDU	DA/SA 可省略(用帧头地址推断)	S1G 专用(省字节)
Short A-MSDU	更紧凑	DMG 专用

最大 A-MSDU 长度 按接收方能力协商(HT Capabilities 的 Maximum A-MSDU Length):典型 3839 / 7935 字节;
VHT/HE 下 A-MSDU 长度还要受接收方最大 MPDU 长度限制;
与块确认的关系:块确认协议下能否发 A-MSDU,取决于接收方在 ADDBA Response 里是否置 A-MSDU Supported=1。

记忆:A-MSDU = 「把几个小信封套进一个大信封」------省的是每个信封(MPDU)都要付的 MAC 头邮资。

四、A-MPDU 操作(10.12)------「省接入开销的聚合」

4.1 A-MPDU 的结构

一个 A-MPDU 由若干 A-MPDU 子帧(A-MPDU subframe) 组成,每个子帧 = MPDU delimiter(4 字节)+ MPDU(可选)+ 填充:

复制代码

┌──────────┬───────────┬─────┬──────────┬───────────┬─────┬─────┐
│ delimiter│  MPDU #1  │ pad │ delimiter│  MPDU #2  │ pad │ ... │
└──────────┴───────────┴─────┴──────────┴───────────┴─────┴─────┘
   │ 4 B                        │ 4 B
   └── EOF/保留/MPDU长度/CRC     └── MPDU 长度=0 表示纯填充(delimiter 兼作 padding)

MPDU delimiter 包含 MPDU 长度 (0 = 纯填充)、EOF 标志 、CRC 校验------接收方靠它定位下一个 MPDU 的起点;
子帧里的 MPDU 是完整 MAC 帧(带自己的地址、序列号),只是共享一个 PLCP 头;
S-MPDU(Single MPDU):A-MPDU 里只装一个 MPDU 的特殊形态(用于 A-MSDU 单独发送等场景)。

4.2 内容与长度限制(10.12.1--10.12.2)

可聚合的帧类型:QoS Data、管理帧、控制响应帧(Ack/BlockAck)等,依上下文表(Table 9-660)而定;同一 A-MPDU 内的帧要遵循类型约束;
最大长度 :接收方用 Maximum A-MPDU Length Exponent 声明能收多长的 A-MPDU(HT/VHT/HE/S1G/DMG 各有对应能力字段);发送方不得超出;
HT PPDU 里单个 MPDU ≤ 4095 字节;
组播:只有 AP、Mesh STA、NGV STA 能在 A-MPDU 里装组播 MPDU(且保护模式下不得混发);组播 A-MPDU 的长度/间距取「所有接收方能力的最小值/最大值」以保证都能收。

4.3 最小 MPDU 起始间距(10.12.3)

接收方声明 Minimum MPDU Start Spacing:两个 MPDU 开始之间至少间隔多少时间;
发送方必须保证 PHY SAP 上相邻 MPDU 起点的间隔 ≥ 该值(按速率换算成字节数),不够就插 padding(MPDU 长度=0 的 delimiter);
原因:接收方需要时间处理上一个 MPDU(尤其解扰码/解密),间距太小会处理不过来。

4.4 A-MPDU 与分片、块确认的关系

A-MPDU 里的 MPDU 不再分片(分片与聚合方向相反,二者互斥------见 10.4 的例外);
典型用法:一个 A-MPDU + 一个 BlockAck = 一次「抢信道 → 发一批 → 一次确认」,正是第 07 讲 TXOP 里的主力工作方式。

记忆:A-MPDU = 「一个货柜(PPDU)装多个包裹(MPDU)」------省的是每个包裹单独跑一趟运输(竞争+确认)的钱。

五、块确认总览(10.25.1)------「一次确认一批」

5.1 从「一帧一认」到「一批一认」

DCF 下每个单播帧都要一个 Ack;发 10 帧就要 10 次「等 Ack + 重新竞争」。块确认(Block Ack,BA) 把确认也聚合起来:发方发一批帧,接收方用一个 BlockAck 帧里的位图一次性回报「哪几帧收到了」。

复制代码

传统(逐帧确认):  Data1│SIFS│Ack│DIFS│Data2│SIFS│Ack│DIFS│Data3│...
块确认:          ┌── A-MPDU(Data1..Data8)──┐│SIFS│ BlockAck(位图:1,0,1,1,..)│
                 └─────────────────────────┘     └── 一次回报 8 帧的收没收到 ──┘

5.2 角色与帧

角色	定义
Originator(发起方)	用块确认机制发数据的一方
Recipient(接收方)	接收数据、回报块确认的一方

帧	作用
ADDBA Request / Response	建立块确认「协议」(协商 TID、缓冲区、确认策略)
BlockAckReq	发起方请求接收方回报块确认(显式请求)
BlockAck	接收方回报:位图指示哪些 MPDU 收到
DELBA	拆除块确认协议

5.3 基本流程

复制代码

Originator                           Recipient
    │── ADDBA Request(TID, Buffer Size, 策略) ──►│
    │◀── ADDBA Response(接受/拒绝,缓冲区) ───────│   建立块确认协议
    │                                          │
    │── A-MPDU(Data #0..#n, Ack Policy=Block Ack)─►│  发一批帧
    │── BlockAckReq ───────────────────────────►│   显式请求确认
    │◀── BlockAck(Starting SN + 位图) ──────────│   SIFS 后回报
    │             (未确认的帧重传)               │
    │── DELBA ────────────────────────────────►│   拆除

一块帧的首帧序号(Starting Sequence Control) 在 ADDBA Request 里约定,此后连续编号;
Ack Policy = Block Ack:QoS Data 帧声明「我用块确认来确认,不用逐帧 Ack」;
隐式 BAR(Implicit BAR) :发送方若在 A-MPDU 里最后一个 MPDU 用特定策略,接收方会在 SIFS 后主动回 BlockAck(省去单独的 BlockAckReq);
块可以跨 TXOP/SP:同一 TID 的帧可以分几个 TXOP 发,再合一个 BlockAck 确认------发起方调度很灵活。

5.4 两种确认时序:立即 vs 延迟

类型	行为
立即块确认(Immediate)	接收方在 SIFS 后立即回 BlockAck(现代主流,HT-immediate)
延迟块确认(Delayed)	接收方先回 Ack,稍后单独发 BlockAck(省接收方处理时间,已少用)

记忆:块确认 = 给一整批帧发一张「验收清单」;ADDBA 是签合同,BlockAckReq 是催验收,BlockAck 是验收单,DELBA 是解约。

六、块确认的建立与拆除(10.25.2 / 10.25.4)------「签合同与解约」

6.1 建立(ADDBA 交换)

发起方 发 ADDBA Request ,指明为哪个 TID 建立块确认协议,并携带 Buffer Size(缓冲区大小,建议值) 、Block Ack Timeout(不活动超时) 、Block Ack Policy(立即/延迟);
接收方 回 ADDBA Response :接受或拒绝 ;接受时给出它实际分配多少缓冲区、采用哪种 BlockAck 变体、以及不活动超时;
建立后,块确认协议的首帧序列号 = ADDBA Request 里的 Starting Sequence Control;
约束:非 HT/DMG/S1G 的 STA 之间不能建立块确认协议;不同协议可以有不同缓冲区分配。

6.2 发送窗口(传输窗口)大小

发起方在 ADDBA Response 的 Buffer Size 之内确定自己的发送窗口:
- 不超过 Buffer Size 字段值;
- 非 HE STA 双方 :窗口 ≤ 64;
- HE STA 双方 :窗口 ≤ 256;
若 Response 的 Buffer Size 比 Request 小,发起方必须把窗口调小------接收方说「我只有这么多缓冲」就按它的来。

6.3 数据转移(10.25.3)

建立后、获得介质访问权并做了必要保护后,发起方可发 A-MPDU(或 DMG 下按 SIFS 间隔连发多个 QoS Data);
RA = 接收方单播地址(普通块确认);GCR 场景用隐蔽地址、GLK-GCR 用 SYNRA;
用 BlockAckReq 请求确认未确认的 QoS Data 帧。

6.4 拆除(DELBA 与不活动超时)

主动拆除 :发起方无数据要发、且最后一轮块确认完成后,发 DELBA 通知接收方;接收方不回管理帧(按普通 Ack 规则确认),释放协议占用的资源;
被动拆除 :若在块确认不活动超时(Block Ack inactivity timeout) 内,该 TID 下没有任何 BlockAck/BlockAckReq/Data 帧往来,协议自动拆除;
GCR 例外:GCR 服务的 DELBA 要带 GCR Group Address 元素;GLK-GCR 协议没有显式拆除,通用链路重关联/解除关联即终止。

记忆:建立 = 双方谈好「一次认几个、缓冲多大」;拆除 = 主动发 DELBA 或等超时自动解约。窗口大小永远听接收方的。

七、BlockAck 变体选择(10.25.5)------「验收单的几种格式」

BlockAck / BlockAckReq 有多个变体(Variant),适应不同带宽与场景:

变体	特点	用途
Basic BlockAck(基本)	位图较大、含每个 MPDU 的更多状态	早期/一般场景
Compressed BlockAck(压缩)	只保留「收到/未收到」位图(64 位)	现代主流(HT-immediate 用)
Extended Compressed BlockAck(扩展压缩)	位图更长(可到 256 位)	HE 大窗口
Multi-TID BlockAck(多 TID)	一次回报多个 TID 的位图	多 TID A-MPDU(HE/EDMG)
GCR BlockAck / GLK-GCR BlockAck	组播重试专用	鲁棒组播(第 01 讲 GCR)
NDP BlockAck / BAT(S1G)	无数据部分的极短确认	S1G 省电场景

选择规则要点:

Compressed 系列 :同一个 HT-immediate 协议下,BlockAck 与 BlockAckReq 必须用同一变体保持一致;
Multi-TID :仅 HE STA 之间可用 Multi-TID BlockAckReq,用于确认 Multi-TID A-MPDU;非 HE 不得用;
位图长度(BitmapLength) :非 HE STA 固定 64 位 ;HE STA 在建立协议时协商位图长度(可更大);
S1G 特例 :用 NDP ADDBA 建立的协议 → 用 NDP BlockAck ;用 BAT ADDBA 建立的协议 → 用 BAT ;S1G 还支持非对称块确认(Asymmetric BA)------STA 用更低 MCS 回 BlockAck,省电省时。

记忆:变体 = 验收单的版式------普通单子(Compressed)、多页单子(Extended/Multi-TID)、给组播用的单子(GCR)、给省电终端的极简单子(NDP/BAT)。选哪种,建立协议时就定好了。

八、HT-immediate 块确认(10.25.6)------「现代块确认的引擎」

8.1 为什么单独讲

HT-immediate block ack 是 11n 起定义的立即块确认扩展 :配合 A-MPDU 使用,接收方总是 SIFS 后立即回 Compressed BlockAck ,大幅简化了接收方资源需求。HT STA 必须支持接收方角色,DMG/S1G(支持 A-MPDU 的)也须支持。

8.2 两种状态管理:full-state 与 partial-state

接收方为每个块确认协议维护一份状态记录(scoreboard,记分板),记录每个序列号对应的 MPDU 是否已正确接收:

状态模式	含义
Full-state(全状态)	维护从 WinStartR 到 WinEndR 整个窗口每帧的接收状态(位图)
Partial-state(部分状态)	只维护「收到但乱序的帧」的片段状态(省内存,适合窗口大但乱序少的场景)

WinStartR / WinEndR:接收窗口的起止序列号;
收到帧时:窗口内且未重复 → 存入并置位;窗口外 → 处理窗口滑动;
收到 BlockAckReq (或含 Implicit BAR 的 A-MPDU)→ SIFS 后回 BlockAck,把 WinStartR 到 WinEndR 的状态填进位图;
位图外(小于 WinStartR)的状态可以随便填,大于 WinEndR 的一律报「未收到」。

8.3 接收重排缓冲(10.25.6.6)------「按序交付」

块确认下帧可能乱序到达 (发方没按顺序发、或中途丢了重传),但上层要求按序 。接收方用接收重排缓冲(receive reordering buffer) 保证:

复制代码

每个协议维护:WinStartB = 还没收到的首个序号
             WinEndB   = 当前接收窗口最高序号
             WinSizeB  = 窗口大小 = min(BitmapLength, Buffer Size)

收到窗口内的帧:存入缓冲;按序号递增把「缺口前的连续帧」递交给上层;
重复帧丢弃;
已递交的帧从缓冲删除;
核心保证:MSDU/A-MSDU 永远按序列号递增顺序交给上层------这是块确认「乱序到达、按序交付」的关键。

8.4 发起方行为(10.25.6.7--10.25.6.8)

发起方维护自己的发送窗口 与 SACK(选择性确认) 信息;
收到 BlockAck 后:位图置 1 的帧删除;置 0 的帧在后续 TXOP 里重传;
重传遵循先重传旧帧、再发新帧的顺序(见 c10 提取的第一段);
发起方还可依据接收方的 RBUFCAP(EDMG 流控) 反馈调整发送量,防止淹没接收方内存。

记忆:Scoreboard = 接收方「哪几帧到了」的账本;Reordering Buffer = 「按序号排好队再交给上层」的传送带。账本管确认,传送带管顺序,两者合起来让「一批发、乱序到、按序交」成立。

九、No Ack(10.26)------「发了就不管」

No Ack 确认策略 :QoS Data 帧的 Ack Policy = No Ack 时,没有 MAC 层恢复(无 Ack、无重传);
可靠性下降:丢失的概率因干扰/冲突/信道变化而更高;
用法:对丢一帧无所谓的流量(如实时音视频采样、尽力而为组播),省去确认开销;
补偿 :若担心竞争者插进来,可用 HCCA、RTS/CTS 或保护机制保护 No Ack 的 TXOP。

记忆:No Ack = 「发完即忘」------牺牲可靠性换吞吐,只给能容忍丢包的流量用。

十、保护机制(10.27)------「新旧设备和平共处」

10.1 为什么需要保护

802.11 每代 PHY 都在变:老设备听不懂新 PPDU 。例如 802.11b(HR-DSSS)的 STA 无法解出 802.11g(ERP-OFDM)或 11n(HT-OFDM)的信号------但它能检测到能量,只是不知道「这传输要持续多久」。于是老设备可能在新设备发送中途插进来,造成冲突。

保护机制(Protection Mechanism)的思路 :在新 PPDU 之前,用老设备也能读懂的最慢帧(RTS/CTS/CTS-to-self)提前声明「我要占信道这么久」,让老设备据此设置 NAV,乖乖让路:

复制代码

新设备:  [ RTS(老格式,带 Duration) ]│SIFS│[ 老格式 CTS ]│SIFS│[ 新 PPDU(HT/HE...) ]...
老设备:  听到 RTS/CTS → 按 Duration 设 NAV → 期间不发送(哪怕它解不出后面的新帧)

10.2 保护手段一览

手段	内容	适用
RTS/CTS	双向预约(第 06 讲)	长帧保护
CTS-to-self	只发一个 CTS(RA=自己),广播 NAV	短帧、省开销
L-SIG / 非 HT 重复帧	用老格式头声明时长	40/80/160 MHz 宽带宽
MU-RTS/CTS	多用户版 RTS/CTS	HE OFDMA 多用户上行

10.3 保护 non-ERP 接收方(10.27.2)

Use_Protection 位 (ERP 元素):置 1 表示「本 BSS 里有老 STA 或相邻有老 BSS」,此后 ERP STA 发 ERP-OFDM 数据/管理帧必须先用保护机制;
NonERP_Present 位:检测到非 ERP STA 关联/存在时置 1;
保护帧(RTS/CTS/Ack 等)必须用所有 STA 都懂的强制速率(Clause 15/16 基本速率)发送,让整个 BSA 都能学到 Duration;
典型判定:只要 BSS 里有 802.11b 老 STA,11g 设备发 OFDM 帧前就先 RTS/CTS 或 CTS-to-self。

10.4 保护 HT 传输(10.27.3)------「HT Protection 四级制」

HT Protection 字段(HT Operation 元素,Beacon/Probe Response 广播)指示 HT 传输需要多强的保护,分四级:

HT Protection 值	含义	何时可用
No protection(无保护)	所有 STA 都是 HT STA,无需保护	主/次信道检测到的都是 HT STA
Nonmember protection(非成员保护)	有非成员(但非 BSS 的)非 HT STA 在附近	BSS 成员全是 HT,但周围有非 HT STA
20 MHz protection	BSS 是 20/40 MHz,且有 20 MHz 的 HT STA	宽带宽下照顾只能收 20 MHz 的老 HT
Non-HT mixed mode(混合模式,默认最严)	存在非 HT STA(如 11b/g)	其余情况一律用它

保护方式 (Table 10-27):
- 用 RTS/CTS 或 CTS-to-self(20 MHz 用 Clause 17/18 速率,40 MHz 用非 HT 重复帧)先占信道;
- 或在 TXOP 第一帧用非 HT/HT-mixed 格式发一个「需要立即响应」的帧,让老设备先听懂;后续帧才允许用 HT-greenfield 格式;
HT-greenfield(HT 纯模式) :省掉传统前导,老设备完全听不懂------必须保护;
RIFS 保护:RIFS 模式与保护等级联动,混合模式下可禁用 RIFS;
OBSS 场景:HT 保护还考虑重叠 BSS 里的非 HT STA(Non-HT OBSS Present)。

10.5 保护 VHT 与 HE(10.27.5 / 10.27.6)------「带宽更宽,保护更大」

STA	规则
VHT	沿用本频段 HT 规则;VHT PPDU 可替代 HT-mixed;保护机制扩展到 80/160/80+80 MHz(用 Clause 21 的非 HT 重复帧声明时长)
HE(2.4 GHz)	沿用 HT 规则;HE_SU/HE_ER_SU/HE_MU/HE_TB 可替代 HT_mixed
HE(5 GHz)	沿用 VHT 规则;HE 帧可替代 VHT
HE 专属	可用 MU-RTS/CTS 帧交换保护 OFDMA 多用户传输

DMG/EDMG(60 GHz) :保护帧用 MCS 0 / 非 EDMG 重复控制模式发送(RTS、DMG CTS、CTS-to-self、DTS、CF-End 等),让非 EDMG STA 也能读到时长。

记忆:保护等级跟着「BSS 里最老的那个设备」走------有 11b 就 CTS-to-self,有 20 MHz 老 HT 就 20 MHz protection,全是最新设备才敢 no protection。保护帧永远用「最老设备也懂的语言(最慢速率/老格式)」广播时长。

十一、MAC 帧处理(10.28)------「对陌生帧的优雅态度」

10.28 定义了 MAC 对帧、元素、子元素 的处理规则,核心是可扩展性:让老设备遇到新设备发来的陌生东西时不至于崩溃。

规则	内容
Revision level(10.28.2)	收到比自己支持的更高版本号的帧 → 直接丢弃、不上报
Duration/ID(10.28.3)	值 < 32768 → 用于更新 NAV;≥ 32768 → 按帧类型/子类型解释或忽略
无效 Action 帧(10.28.4)	无法识别的 Category 或语法错误 → 丢弃
Dialog Token(10.28.5)	用于把不同时刻的帧归组到同一「对话」;取值实现自定,尽量防混淆
未知元素(10.28.6)	未知/保留的 Element ID → 忽略该元素,继续解析后续元素(关键!不会因一个陌生元素丢弃整帧)
厂商专用元素(10.28.7)	不支持的 Vendor Specific 元素 → 忽略
可扩展元素(10.28.8)	长度超过已知结构的元素 → 截断到已知长度再处理(前向兼容的关键机制)

记忆:MAC 帧处理 = 「看不懂的部分跳过,看得懂的部分照做」------这正是 802.11 能一代代加新元素、老设备却不宕机的原因。

十二、RD 反向授权协议(10.29)------「把话筒递给对方」

12.1 问题与思路

TXOP 持有者抢到信道后,通常只有自己发。但很多场景是一来一回的对话(比如 AP 给 STA 发下行,STA 正好也有上行要发)。若 STA 必须等 AP 的 TXOP 结束后重新竞争,就又付一次接入开销。

RD(Reverse Direction,反向授权)协议 :TXOP 持有者(AP)可以在自己的 TXOP 里,通过 RDG(Reverse Direction Grant,反向授权) 把发送权临时转交给对方 STA,让对方在自己的 TXOP 剩余时间里发上行数据,再由自己收尾。

复制代码

AP(TXOP 持有者, RD initiator):
  [ RDG PPDU(含 RDG/More PPDU=1, 带 AC Constraint) ]│SIFS│
STA(RD responder):              ┌─────────────────────────┐
  [ RD 响应突发(RD response burst) 一个或多个 PPDU ]│SIFS│
AP(RD initiator):               [ 最终 PPDU(收尾,可含 BlockAck/Ack) ]
   └────────── 整个序列仍在同一个 TXOP/SP 内 ──────────┘

12.2 关键要素

要素	含义
RDG/More PPDU 子字段	=1 表示「我授予反向传输权 / 我还要继续」;=0 表示「传输权还给我」
RD initiator	发出 RDG 的一方(通常是 AP/TXOP 持有者)
RD responder	接收 RDG、在授权下发送的一方
AC Constraint	initiator 用 EDCA 拿到 TXOP 时必须置 1,约束 responder 只能用相同/更低 AC 发
RD response burst	responder 在授权下连续发的 PPDU 序列;首 PPDU 最多带一个立即 BlockAck/Ack
Duration/ID	被授权方按 initiator 帧里的 Duration 知道「有多少时间归我用」

12.3 规则要点

授权条件:RDG 只能放在「需要 Ack/BlockAck 响应」或「不需要立即响应」的帧上;RD 只在支持者之间使用(HT/S1G/DMG,EDMG 在某些信道方案下必支持);
RDG 不强制接受 :收到 RDG 的 STA 没有义务使用授权------不想发就正常回 Ack;
AC Constraint:TXOP 若是 EDCA 抢来的,initiator 必须把 AC Constraint 置 1,限制 responder 用不高于本 AC 的流量;SP 内可放开;
收尾 :responder 发完后把 RDG/More PPDU 置 0,传输权回到 initiator;initiator 可发 BlockAck/Ack 确认,也可在 TXOP 内发起多个 RD 序列(甚至可以授权给不同接收方);
错误恢复 :RD 机制出错是 initiator 的责任(PIFS 恢复);responder 从不发 CF-End。

记忆:RD = 「我抢到话筒后,递给你说几句,再拿回来」------省去一次重新竞争,让上下行在一段 TXOP 里说完。它是 11n 时代的「半双工对话优化」,理解它有助于后面看 HE 的 Triggered Uplink(AP 主导多用户上行)如何继承这套「把发送权分配出去」的思想。

十三、小结

主题	核心要点
聚合动机(10.11/10.12)	A-MSDU 省 MAC 头(多 MSDU 拼一帧);A-MPDU 省竞争/确认(多 MPDU 拼一 PPDU)
A-MSDU(10.11)	单 RA/TA 约束;Basic/Dynamic(S1G)/Short(DMG) 子帧;受接收方长度能力限制;PP/SPP 安全变体
A-MPDU(10.12)	delimiter+MPDU+padding;长度按 Maximum A-MPDU Length Exponent;最小 MPDU 间距;组播仅 AP/Mesh/NGV 可用
块确认(10.25)	ADDBA 建立 → 发一批 → BlockAckReq/隐式 BAR → BlockAck 位图 → DELBA/超时拆除;立即 vs 延迟
变体(10.25.5)	Compressed(64 位,主流)/Extended/Multi-TID(HE)/GCR/NDP+BAT(S1G);协议内须一致
HT-immediate(10.25.6)	SIFS 后必回 Compressed BlockAck;full-state/partial-state scoreboard(WinStartR/WinEndR);重排缓冲按序交付(WinStartB/WinEndB/WinSizeB)
No Ack(10.26)	无 MAC 恢复;牺牲可靠性换吞吐;可用保护手段补
保护机制(10.27)	老设备听不懂新 PPDU → 用老速率 RTS/CTS/CTS-to-self 提前广播 NAV;HT Protection 四级;VHT/HE 扩展更宽带宽与 MU-RTS
帧处理(10.28)	高版本帧丢弃;未知元素跳过;可扩展元素截断处理------保证前向兼容
RD 协议(10.29)	TXOP 持有者用 RDG 把发送权临时给 responder,AC Constraint 约束流量,initiator 负责收尾与恢复

整节一句话回顾 :第 06--07 讲解决了「一帧怎么发、谁先发」;本讲的聚合把「一帧」变成「一批」(A-MSDU 省头、A-MPDU 省接入),块确认把「一帧一认」变成「一批一认」(位图报收、重排保序) ,而保护机制让每一代新 PHY 都能与老设备共享信道、帧处理规则让协议能无限扩展 ,RD 则在 TXOP 内部实现了高效的双向对话------聚合与块确认是现代 Wi-Fi 高吞吐的两大引擎,后续第 19 讲(HE)的 OFDMA 多用户传输正是建在这一套「批量传输 + 批量确认」的地基之上。