结论边界

802.11 的很多问题不是 RSSI 或 MCS 一眼能解释的，而是卡在“什么时候能发、什么时候必须等”。

先写清几个边界：

  • SIFS 用于同一次交换里的立即响应，例如 ACK、CTS、Block ACK。
  • DIFS/AIFS 用于新的竞争发送，必须比 SIFS 长。
  • Slot Time 是随机退避的计时粒度，不同 PHY/模式取值不同。
  • NAV 是虚拟载波侦听，来自 Duration/ID 预约语义。
  • EIFS 是异常接收后的保守等待，不能和 DIFS 混用。
  • VHT/HE dynamic bandwidth RTS 中，RTS 的 TA 可能是 bandwidth signaling TA；看到 I/G bit 置 1 时不能直接判错。

文中的典型时间值只用于建立抓包判断基线。芯片/驱动级定位时，以对应 802.11 标准条款、芯片配置和抓包 PHY metadata 为准。

介质访问先看两类载波侦听

STA 发包前至少要同时满足两类条件：

protocol trace
Physical carrier sense: CCA idle
Virtual carrier sense : NAV = 0

CCA 由 PHY 判断信道是否 busy，可能基于可解码前导码、能量检测或信号类型识别。

NAV 来自其他帧的 Duration/ID 字段。旁听 STA 根据 Duration 预约时间，在 NAV 归零前不参与竞争。

只看 CCA 不够：

  • hidden node 可能听不到对方 STA；
  • legacy STA 可能听不懂 OFDM 帧；
  • 发送端未必能感知接收端附近干扰；
  • 能量检测只能说明忙，不说明要等多久。

只看 NAV 也不够。NAV 没被设置时，CCA busy 仍会阻止发送。

SIFS

SIFS 是 Short Interframe Space，用于一次 MAC 交换内部的立即响应。

典型场景：

protocol trace
DATA -> SIFS -> ACK
RTS  -> SIFS -> CTS
CTS  -> SIFS -> DATA
DATA -> SIFS -> Block ACK

SIFS 比 DIFS/AIFS 短。已经获得介质的一次交换，可以优先完成后续响应，不需要重新竞争。

如果 ACK/CTS 也要重新竞争，吞吐和可靠性都会明显变差。

Slot Time 与随机退避

新发送不能在信道刚空闲时立即开始。STA 需要先等待 DIFS/AIFS，再从 contention window 中随机选择 backoff counter。

protocol trace
Backoff time = random_integer * Slot Time

每经过一个空闲 slot，counter 减 1。信道 busy 时 counter 暂停；信道重新空闲并再次等待 DIFS/AIFS 后继续倒计时。

常见基线：

protocol trace
802.11b long slot: 20 us
802.11a/g OFDM : 9 us

2.4 GHz b/g mixed 环境里，如果因为 legacy 条件回退到 long slot，即使 DATA PHY rate 仍显示 54 Mbps，MAC 层效率也会下降。

DIFS 与 AIFS

DCF 普通数据竞争通常使用 DIFS：

protocol trace
DIFS = SIFS + 2 * Slot Time

常见基线：

protocol trace
802.11b:
  SIFS = 10 us
  Slot = 20 us
  DIFS = 50 us

802.11a/g OFDM:
  SIFS = 16 us
  Slot = 9 us
  DIFS = 34 us

WMM/EDCA 使用 AIFS，不同 AC 可以有不同等待时间：

protocol trace
AIFS[AC] = SIFS + AIFSN[AC] * Slot Time

因此语音/视频/尽力而为/后台流量在竞争优先级上可能不同。排障时如果只看平均 RSSI，而不看 AC、AIFSN、CWmin/CWmax 和 TXOP，会漏掉不少时延抖动原因。

PIFS

PIFS 位于 SIFS 和 DIFS 之间：

protocol trace
PIFS = SIFS + 1 * Slot Time

它主要和 PCF/HCF、AP 获得较高优先级访问等机制有关。普通数据竞争排障里不常作为主因，但看到 PIFS 级别的间隔时，不要误判为 DIFS/backoff 异常。

EIFS

EIFS 是 Extended Interframe Space。

当 STA 收到一个无法正确解码的帧时，它不知道该帧后续是否需要 ACK，也无法可靠获得 Duration。为了避免打断可能存在的后续 ACK，STA 会等待更保守的 EIFS。

工程意义：

  • FCS error 多时，等待时间会被拉长；
  • 弱信号、同频干扰、hidden node 都可能触发更多 EIFS；
  • 吞吐下降不一定来自 MCS 降低，也可能来自异常接收后的保守等待。

抓包里如果看到大量坏帧或 PHY/FCS error，同时帧间隔异常拉长，要把 EIFS 纳入判断。

Duration/NAV

Duration/ID 字段告诉旁听 STA：这次交换后面还要占用多久介质。

经典 RTS/CTS/DATA/ACK：

protocol trace
RTS
SIFS
CTS
SIFS
DATA
SIFS
ACK

对应 RTS Duration：

protocol trace
RTS Duration = 3*SIFS + T_CTS + T_DATA + T_ACK

这个公式只适用于经典单帧、有 ACK 的交换。以下场景要按实际序列重算：

  • A-MPDU + Block ACK；
  • TXOP 内多帧；
  • No Ack policy；
  • 分片；
  • 管理帧响应不同于 DATA/ACK；
  • 宽带宽 duplicate RTS/CTS 下的后续 PPDU。

Duration 异常的后果：

  • 太短：旁听 STA 过早竞争；
  • 太长：浪费 airtime；
  • 被扣成 0：保护语义可能失效；
  • 与实际后续帧不匹配：抓包会出现 RTS/CTS 有、DATA/ACK 异常或 retry 增多。

ACK timeout 与 CTS timeout

SIFS 之后，发送方期望在规定时间内收到响应。

典型异常：

protocol trace
DATA 发出后没有 ACK -> ACK timeout -> retry / CW 增大
RTS 发出后没有 CTS  -> CTS timeout -> retry / CW 增大

不要只看“有没有重传”。还要看：

  • 响应是否在 SIFS 附近出现；
  • 响应 rate 是否可被发送方解码；
  • RA 是否匹配；
  • 发送方附近是否漏收，而接收方附近实际回了；
  • 设备日志是否记录 CTS timeout、ACK timeout、TX abort。

RTS/CTS 与时间机制

RTS/CTS 是 Duration/NAV 最典型的应用。

protocol trace
发送方 -> 接收方: RTS，声明需要预约多久
接收方 -> 发送方: CTS，继续声明剩余预约时间
发送方 -> 接收方: DATA
接收方 -> 发送方: ACK

隐藏节点可能听不到 RTS，但只要听到接收方发出的 CTS，就能设置 NAV。

这也是为什么 RTS/CTS 排障必须同时看：

protocol trace
RA / TA
Duration
SIFS 时序
CTS 是否覆盖接收方附近 STA
后续 DATA 是否在保护窗口内发送

VHT/HE 动态带宽 RTS 的 TA 例外

普通 RTS 中，TA 通常是发送方 MAC。

VHT/HE dynamic bandwidth RTS 中，这句话不总成立。当 RTS 以 non-HT 或 non-HT duplicate PPDU 承载，并用于动态带宽信令时，TA 可能是 bandwidth signaling TA。

抓包线索：

  • TA 的 I/G bit 被置 1；
  • PPDU 是 non-HT 或 non-HT duplicate；
  • 场景涉及 VHT/HE dynamic bandwidth；
  • PHY metadata 或后续 DATA 带宽显示发生带宽请求/收缩。

不要只看 MAC header 就把这种 TA 判成“源地址错误”。要结合 PPDU 类型、scrambler/PHY metadata、channel width 和后续 DATA 带宽。

抓包判断路径

1. 先确认等待类型

protocol trace
SIFS 响应？
DIFS/AIFS 后新竞争？
backoff 倒计时？
EIFS 保守等待？
NAV 未归零？
CCA busy？

不同等待类型对应不同问题。把 backoff 当成设备卡顿，或者把 NAV 当成 CCA busy，都会误判。

2. 看帧间隔

记录相邻帧时间差：

protocol trace
DATA -> ACK
RTS  -> CTS
CTS  -> DATA
ACK  -> 下一次新发送

对照 SIFS、DIFS/AIFS、Slot Time 和 backoff。偏差很大时，再查 PHY rate、抓包时钟精度和是否漏帧。

3. 看 Duration 与 NAV

检查：

  • RTS/CTS Duration 是否覆盖后续交换；
  • DATA Duration 是否覆盖 ACK/Block ACK；
  • 旁听 STA 是否在 NAV 期间保持静默；
  • NAV 是否异常过长或过短。

4. 看失败后的竞争变化

失败后通常会扩大 contention window，后续 backoff 变长。

如果 ACK miss 或 CTS timeout 后没有看到预期退避变化，要查驱动/固件日志和抓包是否漏了重传链路。

常见误判

现象不能直接下的结论下一步确认
RSSI 很好但延迟高 链路质量没问题 还要看 backoff、AIFS、NAV、EIFS、retry
两个帧之间有几十微秒空白 设备处理慢 可能是 DIFS/AIFS、SIFS 或 backoff
RTS/CTS 后没有 DATA AP 一定没收到 CTS 还要查 dynamic/static 带宽、CCA/NAV、TX abort、抓包覆盖范围
FCS error 多且吞吐低 只怪信号差 EIFS 和重传也会拉低效率
Duration 很大 协议异常 可能是 TXOP/A-MPDU/Block ACK 场景，要按实际交换判断
RTS.TA I/G bit 置 1 源 MAC 错 可能是 VHT/HE bandwidth signaling TA

现场记录模板

protocol trace
BSS / 设备：
频段 / 信道 / 带宽：
PHY 类型：DSSS / ERP / OFDM / HT / VHT / HE
Slot Time：
SIFS / DIFS / AIFS：
业务 AC：BE / BK / VI / VO
RTS/CTS：有 / 无
Duration 异常：有 / 无
NAV 是否未归零：
CCA busy 比例：
FCS/PHY error：
ACK timeout / CTS timeout：
Retry 变化：
设备日志：
结论：
缺失证据：

来源与核验

  • IEEE Std 802.11：DCF/EDCA、SIFS/PIFS/DIFS/AIFS/EIFS、Slot Time、Duration/NAV、ACK/CTS timeout、RTS/CTS 时序。
  • Wireshark/radiotap：frame timestamp、Duration、Retry、FCS、rate、channel、channel width、PHY metadata。不同网卡暴露字段不同，缺 metadata 时不要硬下结论。
  • 设备日志：CCA busy、NAV、rate control、TX status、ACK timeout、CTS timeout、TX abort。

最后结论

802.11 timing 排障不要从“速率低”开始，要从“为什么此刻不能发”开始。

按这个顺序查：

protocol trace
CCA 是否 idle？
NAV 是否为 0？
等待的是 SIFS、DIFS/AIFS、EIFS，还是 backoff？
Duration 是否覆盖后续交换？
失败后 contention window 是否扩大？
RTS/CTS、ACK、Block ACK 是否按 SIFS 衔接？
VHT/HE dynamic bandwidth 是否触发 TA 例外？

这些证据串起来，才能解释吞吐、时延、retry 和“看起来空闲但设备不发”的问题。