Jay's some notes

最近太想进步了，开始研究 NS-3 Wi-Fi 仿真模型。本文翻译自，https://www.nsnam.org/docs/models/html/wifi-design.html 。

ns-3 节点可以包含多个 NetDevice 对象，就像一台实际的计算机可以包含多个独立的网络接口卡（如以太网、Wi-Fi、蓝牙等）。本章节描述了 ns-3 的 WifiNetDevice 及其相关模型。通过将 WifiNetDevice 对象添加到 ns-3 节点中，可以创建基于 802.11 的基础设施网络和自组织（Ad Hoc）网络模型。

1. 模型概览

WifiNetDevice 模拟了基于 IEEE 802.11 标准的无线网络接口控制器 [ieee80211]。我们将在后续章节中详细说明，但简单来说，ns-3 提供了以下 802.11 相关模型：

• 基本的 802.11 分布式协调功能（DCF），支持 基础设施模式 和 自组织模式
• 802.11a、802.11b、802.11g、802.11n（支持 2.4 GHz 和 5 GHz 频段）、802.11ac、802.11ax（支持 2.4 GHz、5 GHz 和 6 GHz 频段）以及 802.11be 的物理层
• MSDU 聚合 和 MPDU 聚合 的 802.11n 扩展，并支持两者组合（两级聚合）
• 802.11ax 的 下行链路 OFDMA（DL OFDMA） 和 上行链路 OFDMA（UL OFDMA）（包括多用户增强分布式协调功能（MU EDCA）参数集的支持）
• 802.11be 的 多链路 发现与设置
• 基于 QoS 的增强分布式协调功能（EDCA）以及 802.11e 的队列扩展
• 支持使用不同的传播损耗模型和传播延迟模型，详细信息请参见 Propagation 章节
• 经验证的分组错误模型和帧检测模型，与链路仿真和其他参考一致
• 多种速率控制算法，包括 Aarf、Arf、Cara、Onoe、Rraa、ConstantRate、Minstrel 和 Minstrel-HT
• 802.11s（网状网络），另见其他章节
• 802.11p 和 WAVE（车联网），另见其他章节

ns-3 提供的 802.11 模型尝试准确实现 802.11 规范的 MAC 层功能，同时为 802.11a/b/e/g/n/ac/ax/be 物理层提供基于分组的抽象。

在 ns-3 中，节点可以在不同的信道上拥有多个 WifiNetDevice，且 WifiNetDevice 能与其他设备类型共存。通过使用 SpectrumWifiPhy 框架，还可以创建涉及跨信道干扰或单个信道上多种无线技术共存的场景。

WifiNetDevice 及其模型的源代码位于目录 src/wifi。

实现是模块化的，主要包括三个子层模型：

• 物理层模型（PHY layer models）：模拟具体修正案的物理层操作及通用物理层功能。
• 低层 MAC 模型（lower MAC models）：模拟诸如介质访问（DCF 和 EDCA）、帧保护（RTS/CTS）以及确认（ACK/BlockAck）等功能。在 ns-3 中，低层 MAC 包括一个 帧交换管理器（Frame Exchange Manager） 层级结构、一个 信道访问管理器（Channel Access Manager）、Txop 对象、BlockAckManager 对象和一个 MAC 中间实体（MAC middle entity）。
• 高层 MAC 模型（upper MAC models）：实现 Wi-Fi 中非时间关键的过程，如 MAC 层信标生成、探测和关联状态机，以及一组 速率控制算法。在文献中，这一子层有时称为 高层 MAC（upper MAC），相较于时间关键的硬件实现，它更偏向软件实现。

接下来，我们将概述每一层的设计，具体结构如图 WifiNetDevice 架构 所示。对于 802.11be 的多链路设备（MLDs），WifiPhy、FrameExchangeManager 和 ChannelAccessManager 的实例数量与链路数量相同。

WifiNetDevice 架构

1.1. 高层 MAC 模型

目前，高层 MAC 的父类 ns3::WifiMac 有三种变体：接入点（AP）（ns3::ApWifiMac）、非 AP 站点（STA）（ns3::StaWifiMac）以及独立基本服务集（IBSS）中的 STA（通常称为自组织网络）（ns3::AdhocWifiMac）。

其中最简单的是 ns3::AdhocWifiMac，它实现了一个不执行信标生成、探测或关联的 Wi-Fi MAC。ns3::StaWifiMac 类实现了一个主动探测和关联状态机，能够在错过过多信标时自动重新关联。而 ns3::ApWifiMac 则实现了一个生成周期性信标并接受所有关联请求的 AP。

这三种高层 MAC 模型共享一个共同的父类 ns3::WifiMac。该类提供了一些 MAC 配置选项，其中包括一个 QosSupported 属性，用于配置 802.11e/WMM 风格的 QoS 支持。

此外，还可以在低层 MAC 中使用多种 速率控制算法。这些算法均实现为 ns3::WifiRemoteStationManager 的子类。完整的可用速率控制算法列表在单独的章节中提供。

1.2. 低层 MAC 模型

低层 MAC 分为三个主要组件：

1. ns3::FrameExchangeManager：这是一个类层次结构，负责实现支持的 IEEE 802.11 修正案中引入的帧交换序列。它还处理帧聚合、帧重传、保护和确认。
2. ns3::ChannelAccessManager：实现分布式协调功能（DCF）和增强分布式协调功能（EDCAF）。
3. ns3::Txop 和 ns3::QosTxop：负责分组队列管理。ns3::Txop 对象用于不支持 QoS 的高层 MAC，以及标准规定应通过 DCF 访问介质的帧（例如管理帧）的传输。而 ns3::QosTxop 则用于支持 QoS 的高层 MAC。

1.3. 物理层模型

物理层模型主要负责对分组的接收进行建模以及跟踪能量消耗。分组接收通常包含以下三个主要组件：

• 每个接收的分组都会通过概率方法评估其接收是否成功或失败。成功概率取决于分组的调制方式、信噪比（以及干扰比），以及物理层的状态（例如在传输或休眠期间无法进行接收）。
• 一个对象用于记录所有接收到的信号，以便在做出接收决策时计算每个分组的正确干扰功率。
• 一个或多个与调制方式和标准相对应的错误模型用于查找接收成功的概率。

ns-3 提供了两种物理层模型供用户选择，其基本接口定义在 ns3::WifiPhy 类中。YansWifiPhy 类实现了一个简单的物理层模型，该模型在题为 Yet Another Network Simulator 的论文中有所描述。“Yans” 这一缩写源自该论文标题。SpectrumWifiPhy 类是一个基于 ns-3 用于其他无线模型的 Spectrum 框架的更高级实现。Spectrum 框架允许对信号进行精细的频率分解，并支持多种技术在单一信道上共存的场景。

2. 范围与限制

IEEE 802.11 标准 [ieee80211] 是一个庞大的规范，ns-3 并未涵盖其所有方面；仅记录 ns-3 的合规性本身就可能构成一份很长的文档。本节尝试总结 ns-3 对标准的符合性以及与实际行为的对比。

物理层和信道模型以每个分组为基础进行操作。当使用默认的 YansWifiPhy 模型时，未包含频率选择性传播或干扰效应。目前也不支持定向天线。在加性白高斯噪声（AWGN）场景或宽带干扰场景下，性能由对接收信号的信噪比应用分析模型（基于调制方式和信道宽度等因素）决定，噪声包括热噪声以及其他 Wi-Fi 分组的干扰。当使用 SpectrumWifiPhy 时，其他无线技术的干扰才会被建模。以下是物理层和信道模型的具体限制：

• 不支持 802.11n/ac/ax/be 波束成形
• 不支持 802.11n RIFS
• 未实现 802.11 PCF/HCF/HCCA
• 不支持信道切换公告
• 缺少认证和加密功能
• 未建模处理延迟
• 不支持使用 HT/VHT/HE/EHT 格式传输 RTS/CTS 和 ACK
• 能量消耗模型未考虑 MIMO
• 物理层支持 802.11ax 前导符打孔，但 MAC 层目前尚未利用该功能
• 仅支持最小化的 MU-MIMO（假设理想的物理层，没有 MAC 层实现）

在 MAC 层，大多数 802.11a/b/e/g/n/ac/ax/be 的主要功能已被实现，但模型中仍有一些零星的限制。对 802.11n、ac、ax 和 be 的支持仍在演进中。

一些未被标准强制要求的实现选择如下：

• 对于 802.11b，假定 BSSBasicRateSet 为 1-2 Mbit/s。
• 对于 802.11a/g，假定 BSSBasicRateSet 为 6-12-24 Mbit/s。
• 假定 OperationalRateSet 包含所有强制速率（参见 问题 183）。
• Wi-Fi 管理器总是为管理帧选择最低的基本速率。
• 如果 STA（AP 或非 AP）支持 VHT，则一旦第一个分组排队，就会始终设置 Block Ack 协议，无论该分组是否将在 A-MPDU 中传输。
• 一旦创建了 A-MSDU，它就不会再被修改，即使是在首次传输之前。这意味着该 A-MSDU 无法与其他 MSDU 结合使用 A-MSDU 聚合。

3. 设计细节

本节其余部分将深入描述一些 Wi-Fi 模型的设计细节。若用户希望直接跳转到 Wi-Fi 模块的使用章节（用户文档），可以跳过此部分。我们按照自下而上的分层方式组织了这些详细描述，首先介绍信道和物理层模型，然后是 MAC 层模型。

我们首先关注物理层框架的选择。ns-3 支持一个仅 Wi-Fi 的物理层模型 YansWifiPhy，该模型不提供信号的频率级别分解。对于仅涉及 Wi-Fi 信号且不涉及与频率相关的传播损失或衰落模型的仿真，默认的 YansWifiPhy 框架是合适的选择。而对于包含同一信道上混合技术或频率相关效应的仿真，SpectrumWifiPhy 更为适合。这两个框架的配置方式非常相似。

SpectrumWifiPhy 框架使用 Spectrum 模块 信道框架。

YansWifiChannel 是 ns-3 Wi-Fi 模块中唯一的具体信道模型类。ns3::YansWifiChannel 的实现使用了 ns-3 Propagation 模块中提供的传播损失和传播延迟模型。特别是，可以将多个传播模型添加到信道对象（如果添加了多个损失模型，则可以链式组合），还可以添加传播延迟模型。从 ns3::YansWifiPhy 对象发送到信道的分组会以特定的信号强度发送，之后信号强度会因传播损失模型而衰减，同时引入传输（序列化）延迟以及由于任何信道传播延迟模型（通常由设备之间的光速传播延迟引起）的传播延迟，然后被复制到所有其他 ns3::YansWifiPhy 对象。

仅允许将 ns3::YansWifiPhy 对象附加到 ns3::YansWifiChannel；因此，不允许模拟其他技术（如 LTE）的对象。此外，来自不同信道的分组不会相互影响；例如，如果信道被逻辑配置为信道 5 和 6，尽管它们的信道编号可能重叠，但分组不会引起相邻信道干扰。

3.1. WifiPhy 和相关模型

ns3::WifiPhy 是一个抽象基类，表示 802.11 物理层功能。传递给该对象的分组（通过 Send() 方法）会被发送到信道对象，在接收时，接收 PHY 对象根据信号强度和干扰决定分组是否接收成功。此类还提供了多个回调，用于通知物理层事件，公开了一个状态机的概念，可供监控 MAC 层的流程（如载波侦听），并处理休眠/唤醒/关闭模型以及能量消耗。ns3::WifiPhy 挂接到 WifiNetDevice 中的 ns3::FrameExchangeManager 对象。

目前 WifiPhy 有两个实现：ns3::YansWifiPhy 和 ns3::SpectrumWifiPhy。它们与以下五个对象协同工作：

• PhyEntity：包含物理层处理的修订特定部分。
• WifiPpdu：对修订特定的物理协议数据单元（PPDU）进行建模。
• WifiPhyStateHelper：维护物理层状态机。
• InterferenceHelper：跟踪信道上观察到的所有分组。
• ErrorModel：根据信噪比（SNR）计算错误的概率。

3.1.1. PhyEntity

3.1.1.1. 背景简介

考虑到相关文件的大小和复杂性，对 ns3::WifiPhy 和 ns3::WifiMode（以及其他文件）进行了一些重构。此外，添加和维护新的 PHY 修订已成为一项复杂的任务（尤其是那些实现于其他模块内部的任务，如 DMG）。所采用的解决方案是引入 PhyEntity 类，这些类包含 PHY 处理的“修订”特定部分（即 HT/VHT/HE/EHT 等）。

在标准中，每个 PHY 层描述章节的开头都有“PHY 实体”的概念，例如 IEEE 802.11-2016 第 21.1.1 节：

:: 第 21 条规定了一个非常高吞吐量（VHT）正交频分复用（OFDM）系统的 PHY 实体。

注意，在 wave 模块中已经存在一个同名概念（例如 WaveNetDevice::AddPhy），用于指代每个 11p 信道上的 WifiPhy，但该术语仅在类中使用，并且没有任何文件使用该名称，因此使用该名称来表示 802.11 修订不会引起歧义。

3.1.1.2. 架构

抽象基类 ns3::PhyEntity 提供了一组唯一的 API，可供每个 PHY 实体使用，对应于 IEEE 802.11 标准的不同修订。目前已实现的 PHY 实体包括：

• ns3::DsssPhy：DSSS 和 HR/DSSS（11b）的 PHY 实体
• ns3::OfdmPhy：OFDM（11a 和 11p）的 PHY 实体
• ns3::ErpOfdmPhy：ERP-OFDM（11g）的 PHY 实体
• ns3::HtPhy：HT（11n）的 PHY 实体
• ns3::VhtPhy：VHT（11ac）的 PHY 实体
• ns3::HePhy：HE（11ax）的 PHY 实体
• ns3::EhtPhy：EHT（11be）的 PHY 实体

它们的继承图见图 PhyEntity 继承结构，并紧密遵循标准的逻辑，例如 IEEE 802.11-2016 第 21.1.1 节：

:: VHT PHY 基于 第 19 条中定义的 HT PHY，而 HT PHY 又基于 第 17 条中定义的 OFDM PHY。

PhyEntity 继承结构

这种架构可以以修订特定的方式处理以下操作：

• WifiMode 的处理和数据/PHY 速率计算，
• PPDU 字段大小和持续时间计算，以及
• 发送和接收路径。

3.1.2. WifiPpdu

与 PhyEntity 类似，ns3::WifiPpdu 基类被具体化为以下修订特定的 PPDU：

• ns3::DsssPpdu：DSSS 和 HR/DSSS（11b）的 PPDU
• ns3::OfdmPpdu：OFDM（11a 和 11p）的 PPDU
• ns3::ErpOfdmPpdu：ERP-OFDM（11g）的 PPDU
• ns3::HtPpdu：HT（11n）的 PPDU
• ns3::VhtPpdu：VHT（11ac）的 PPDU
• ns3::HePpdu：HE（11ax）的 PPDU
• ns3::EhtPpdu：EHT（11be）的 PPDU

它们的继承图如图 WifiPpdu hierarchy 所示，并紧密遵循标准的逻辑。例如，IEEE 802.11-2016 第 21.3.8.1 节指出：

:: 为了与非 VHT STA 兼容，定义了特定的非 VHT 字段，这些字段可由符合 Clause 17（OFDM）或 Clause 19（HT）的非 VHT STA 接收。

WifiPpdu 继承结构

3.1.3. YansWifiPhy 和 WifiPhyStateHelper

类 ns3::YansWifiPhy 负责接收从 MAC（ns3::FrameExchangeManager 对象）传递来的分组，将其发送到所连接的 ns3::YansWifiChannel，并从信道接收分组。如果接收成功，则将分组传递回 MAC。

信号接收的能量根据发送功率计算，并基于发射机的发射增益、接收机的接收增益和适用的路径损失传播模型进行调整。

类 ns3::WifiPhyStateHelper 管理 PHY 层的状态机，并允许其他对象作为 监听器 挂钩以监控 PHY 状态。监听器的主要用途是让 MAC 层知道 PHY 是否忙碌（用于传输和避免冲突）。

PHY 层可以处于以下状态之一：

1. TX：PHY 当前正在为其关联的 MAC 发送信号。
2. RX：PHY 已同步信号，正在等待接收最后一位以将其转发到 MAC。
3. CCA_BUSY：PHY 正在为主信道发出 PHY-CCA.indication(BUSY) 指示。
4. IDLE：PHY 未处于 TX、RX 或 CCA_BUSY 状态。
5. SWITCHING：PHY 正在切换信道。
6. SLEEP：PHY 处于节能模式，无法发送或接收帧。
7. OFF：PHY 已关闭，无法发送或接收帧。

接收分组的过程如下：对于 YansWifiPhy，大部分逻辑在 WifiPhy 基类中实现。YansWifiChannel 调用 WifiPhy::StartReceivePreamble()，后者调用适当 PHY 实体的 PhyEntity::StartReceivePreamble() 开始接收分组，但首先会检查分组的信号功率是否高于 WifiPhy::RxSensitivity 中存储的阈值。任何低于该阈值的分组将被丢弃，默认值为 -101 dBm（20 MHz 信号在室温下的热噪声底）。此属性的目的包括：

1. 弱信号对仿真结果无影响，但会消耗内存和处理资源，因此应丢弃；
2. 可将阈值调高以模拟基本载波侦听的限制，用于涉及空间复用的实验。

在 StartReceivePreamble() 中，分组被立即添加到干扰助手中以进行信噪跟踪，随后根据 PHY 的状态决定接收步骤。如果 PHY 处于发送状态，分组将被丢弃；如果 PHY 为空闲或正在接收，且使用了 FrameCaptureModel（且分组在捕获窗口内），则调用 PhyEntity::StartPreambleDetectionPeriod()。

PhyEntity::StartPreambleDetectionPeriod() 通常会调度一个事件 PhyEntity::EndPreambleDetectionPeriod()，用于检查前导码是否被检测到。自 ns-3.30 版本起，从空闲状态的状态机转换会被抑制直到前导码检测事件完成。

PhyEntity::EndPreambleDetectionPeriod() 方法使用前导码检测模型检查信号是否足够强以被接收。若检测到前导码，则调度事件 PhyEntity::EndReceiveField() 到前导码结束时，并将 PHY 置于 CCA_BUSY 状态。目前 ns-3 中仅提供一个简单的阈值前导码检测模型 ThresholdPreambleDetectionModel。如果没有前导码检测模型，则假定前导码已被检测到。自 ns-3.30 起，默认添加 ThresholdPreambleDetectionModel，其阈值为 -82 dBm 的 RSSI 和 4 dB 的 SNR，只有两者均超过阈值时，前导码才会成功检测到。

在 PhyEntity::EndReceiveField() 中，检查当前前导码和头部字段是否接收正确。若接收成功，则调用 PhyEntity::StartReceiveField() 处理下一个字段，否则中止接收。

该流程在处理单个 MPDU 时运行。对于 MPDU 聚合（A-MPDU），StartReceivePayload 为每个 MPDU 调度一个接收事件 ScheduleEndOfMpdus，成功接收的 MPDU 被逐一传递到 FrameExchangeManager，并在 A-MPDU 完成后通知成功接收的 MPDU 数量。

3.1.4. InterferenceHelper

InterferenceHelper 是一个用于跟踪所有接收分组并计算其错误概率的对象，同时还评估信道上的能量是否以及何时超过给定阈值。

错误概率的基本计算过程如图 SNIR function over time 所示。在 ns-3 模型中，分组以比特（而非符号）表示。InterferenceHelper 将分组分解为一个或多个具有不同信噪比（SNIR）的“片段”。每个片段会使用错误模型独立计算指定比特数的错误概率。InterferenceHelper 根据这些片段及其持续时间，生成一个聚合的“错误概率”值，并将其返回给 WifiPhy 以决定是否接收分组。

SNIR 随时间的变化

通过 SNIR 函数，我们可以推导出所使用调制和编码方案的比特错误率（BER）和分组错误率（PER）。

如果使用 MIMO 且接收天线数量多于空间流数量，则计算的 SNIR 会获得如下增益（假设未使用 STBC）：

对于加性高斯白噪声（AWGN），发送天线数量的影响可以忽略。增益值如下：

antennas   NSS    gain
2 x 1       1     0 dB
1 x 2       1     3 dB
2 x 2       1     3 dB
3 x 3       1   4.8 dB
3 x 3       2   1.8 dB
3 x 3       3     0 dB
4 x 4       1     6 dB
4 x 4       2     3 dB
4 x 4       3   1.2 dB
4 x 4       4     0 dB

3.1.5. ErrorRateModel

ns-3 根据输入帧的信噪比（SNR）以及可能重叠的干扰帧（即信噪加干扰比，SINR）决定分组是成功还是错误。分组错误率（PER）与 SINR 的关系由 ns3::ErrorRateModel 定义，目前有多个模型可用。PER 是帧的调制和编码方案（MCS）、其 SINR 和配置的具体 ErrorRateModel 的函数。

ns-3 的默认 ErrorRateModel 随版本更新不断改进。目前（截至 ns-3.33 版本）针对现代 OFDM 标准（如 802.11n/ac/ax）的默认模型是 ns3::TableBasedErrorRateModel。对于 802.11a/g，默认使用 ns3::YansErrorRateModel；对于 802.11b，默认使用 ns3::DsssErrorRateModel。在 ns-3.33 版本之前，现代标准的默认模型是 ns3::NistErrorRateModel。

不同错误模型的详细说明可参考外部文献。当前的 OFDM 模型基于 [patidar2017] 中的工作，使用 MATLAB WLAN 工具箱进行链路仿真，并与 IEEE TGn 结果进行验证 [erceg2004]。有关其他错误模型的更多文献，请参见 [pei80211ofdm]、[pei80211b]、[lacage2006yans] 等。

当前的 ns-3 错误率模型仅适用于加性高斯白噪声（AWGN）信道，未建模任何潜在的频率选择性衰落效应。

错误模型总结如下：

1. ns3::TableBasedErrorRateModel：用于 OFDM 模式，同时复用 ns3::DsssErrorRateModel 处理 802.11b 模式。这是 802.11n/ac/ax 的默认模型。
2. ns3::YansErrorRateModel：用于 OFDM 模式，同时复用 ns3::DsssErrorRateModel 处理 802.11b 模式。这是 802.11a/g 的默认模型。
3. ns3::DsssErrorRateModel：包含 802.11b 模式的模型。1 Mbps 和 2 Mbps 基于经典调制分析。5.5 Mbps 和 11 Mbps 使用 GSL 时基于 [pursley2009] 提供的 CCK 调制模型；否则，使用基于 MATLAB 的备选模型。
4. ns3::NistErrorRateModel：用于 OFDM 模式，同时复用 ns3::DsssErrorRateModel 处理 802.11b 模式。

用户可以在 OFDM 模式下选择 NIST、YANS 或基于表格的模型，而 DSSS 模式下始终使用 DsssErrorRateModel。

3.1.6. TableBasedErrorRateModel

ns3::TableBasedErrorRateModel 是针对 802.11n/ac/ax 新增的默认模型，而 ns3::YansErrorRateModel 是 802.11a/g 的默认模型。

与基于误差界的分析模型不同，TableBasedErrorRateModel 包含 AWGN 信道的端到端链路仿真表格（PER vs SNR）。由于为所有可能的分组大小和输入 SNR 生成查找表在计算上不可行，该模型采用 IEEE P802.11 TGax [porat2016] 提出的建议，使用参考长度 32 字节（小于 400 字节）和 1458 字节（大于或等于 400 字节）进行外推估计。LDPC 编码仅需单一参考长度。

MATLAB WLAN 工具箱用于生成每种调制和编码方案的表格。对 SNR 的每个值，模拟运行直到总计 40000 个分组被模拟。

结果与 TGax 曲线非常接近，如图 Comparison of table-based OFDM Error Model with TGax results.。

基于表格的 OFDM 错误模型与 TGax 结果对比

3.1.7. Legacy ErrorRateModels

原始错误率模型 ns3::YansErrorRateModel 基于分析结果。对于 802.11b 调制，1 Mbps 模式基于 DBPSK；2 Mbps 模式基于 DQPSK。详细信息参见 [lacage2006yans]。

ns3::NistErrorRateModel 后来加入。DSSS 调制的 1 Mbps 和 2 Mbps 模式与 YansErrorRateModel 一致，而 5.5 Mbps 和 11 Mbps 模式基于 [pursley2009] 的研究。OFDM 调制模式的结果基于 NIST [miller2003]。

当 GSL 可用时，802.11b 的 5.5 Mbps 和 11 Mbps 模式使用 [pursley2009]；否则，使用 MATLAB 模拟的备选模型。

基于分析的错误模型在高 MCS 时逐渐偏离链路仿真结果，如图 YANS and NIST error model comparison with TGn results 所示。这推动了基于链路仿真的新错误模型的开发。

YANS 和 NIST 错误模型与 TGn 结果的比较

3.1.8. SpectrumWifiPhy

本节描述了 SpectrumWifiPhy 类的实现，代码位于 src/wifi/model/spectrum-wifi-phy.{cc,h}。

此外，该实现还使用了以下同目录中的类：

• wifi-spectrum-phy-interface.{cc,h}
• wifi-spectrum-signal-parameters.{cc,h}

以及 spectrum 模块中的类：

• wifi-spectrum-value-helper.{cc,h}

SpectrumWifiPhy 类重用了最初为 YansWifiPhy 构建的干扰管理器和错误率模型，但在第一步中允许将外部（非 Wi-Fi）信号视为附加噪声。

为使 Spectrum 框架适配 Wi-Fi，进行了两项主要改动。首先，物理层必须发送与 Spectrum 信道框架兼容的信号，特别是允许不同技术信号共存的 MultiModelSpectrumChannel（对于纯 Wi-Fi 仿真中 5 GHz 和 6 GHz 频段，也可以使用 SingleModelSpectrumChannel，但不适用于 2.4 GHz 频段。如果在使用 SingleModelSpectrumChannel 时遇到错误，请切换到 MultiModelSpectrumChannel）。其次，InterferenceHelper 必须扩展以支持插入非 Wi-Fi 信号并将其接收功率添加到噪声中，就像意外 Wi-Fi 信号（可能来自不同的 SSID 或隐藏节点）添加到噪声中一样。

与 YansWifiPhy 不同，在 SpectrumWifiPhy 中，超过 CcaEdThreshold 的外部信号会触发 CCA_BUSY 状态（见 802.11-2012 标准中 16.4.8.5 节定义的 CCA 模式 1）。因此，WifiPhy::CcaEdThreshold 属性在该模型中可能比在 YansWifiPhy 模型中更为重要。

为了支持 Spectrum 信道，YansWifiPhy 的发送和接收方法被适配以使用 Spectrum 信道 API。这需要开发一些 SpectrumModel 相关的类。例如，WifiSpectrumValueHelper 用于使用 Spectrum 框架创建 Wi-Fi 信号，并将其能量分布到各个频段。频谱被细分为子频段（宽度等于 OFDM 子载波，取决于技术）。分配给特定信道的功率分布在子频段上，近似于标准中定义的 OFDM 发射频谱掩码。

WifiBandwidthFilter 类用于在传输过程的早期阶段丢弃信号，通过忽略发射带宽（包括保护带）与当前操作信道不重叠的任何 Wi-Fi PPDU。这样可以绕过信号传播/损失计算，从而减少计算负担并提高仿真性能。要启用 WifiBandwidthFilter，用户可以使用以下代码进行对象聚合：

Ptr<WifiBandwidthFilter> wifiFilter = CreateObject<WifiBandwidthFilter> ();
Ptr<MultiModelSpectrumChannel> spectrumChannel = CreateObject<MultiModelSpectrumChannel> ();
spectrumChannel->AddSpectrumTransmitFilter(wifiFilter);

为了提供更方便的用户配置体验，现有的 YansWifi 帮助类（位于 src/wifi/helper）被复制并调整，用于提供等效的 SpectrumWifi 帮助类。

最后，为了避免 C++ 多重继承问题，插入了一个名为 WifiSpectrumPhyInterface 的小型转发类，作为 SpectrumWifiPhy 和 Spectrum 通道之间的桥梁。WifiSpectrumPhyInterface 调用了不同的 SpectrumWifiPhy::StartRx() 方法以启动接收过程。此方法会根据 WifiPhy::RxSensitivity 属性检查信号强度，并丢弃弱信号。同时，它还会验证信号是否为 Wi-Fi 信号；非 Wi-Fi 信号会添加到 InterferenceHelper 中，在这里它们可能会触发 CCA_BUSY，但不会在接收链中进一步处理。有效的 Wi-Fi 信号会触发调用 WifiPhy::StartReceivePreamble，随后按照之前描述的流程继续处理。

此外，为了支持更灵活的通道切换，SpectrumWifiPhy 可以管理多个 WifiSpectrumPhyInterface 实例（多 RF 接口概念）。每个实例处理频谱的特定频率范围，通过 MHz 定义起始和结束频率，且这些范围不能重叠。只有一个实例对应于 SpectrumWifiPhy 的活动 RF 接口，其他实例被称为非活动 RF 接口，可能会与频谱通道断开连接。

多 RF 接口概念

如果将 SpectrumWifiPhy::TrackSignalsFromInactiveInterfaces 属性设置为 true（默认值），非活动 RF 接口会连接到各自的频谱通道。当非活动 RF 接口接收到属于其覆盖频率范围配置部分的信号时，SpectrumWifiPhy 也会接收这些信号。非活动接口监控的频谱部分由中心频率和信道宽度指定，并无缝设置为使用该频率范围的 Spectrum PHY 的活动信道的等效配置。SpectrumWifiPhy 将这些来自非活动接口的接收信号转发给 InterferenceHelper，而不进一步处理它们。这样做的好处是，当信号在新信道上开始传输但切换尚未完成时，能够生成更准确的 PHY-CCA.indication，这些信号否则会被忽略。这在图 通道切换期间信号跟踪的示例 中进行了说明，其中红色部分仅在 SpectrumWifiPhy::TrackSignalsFromInactiveInterfaces 设置为 true 时生成。

通道切换期间信号跟踪的示例

3.1.9. MU-MIMO PHY 支持

在 ns-3.40 版本中，为 PHY 层引入了 MU-MIMO 的基础支持。当前模型可用于下行链路和上行链路的 MU-MIMO 传输。

MU-MIMO 和 OFDMA 的多用户传输依赖于 MAC 层中 TXVECTOR 的填充方式（尚未实现）。由于不支持混合 OFDMA 和 MU-MIMO 配置，TXVECTOR 会在所有用户分配相同 RU 时标识为 MU-MIMO，否则它表示为 OFDMA 传输。

在 PHY 层，OFDMA 和 MU-MIMO 的传输方式相似，主要区别在于 MU-MIMO 在上行链路方向上允许多个发射器同时共享相同的频谱。当前的 PHY 抽象模型假设完美条件，其中干扰管理器能够检测属于同一 MU-MIMO 传输的信号，并确保它们不会相互干扰。模型仍然支持与其他信号（包括其他 MU-MIMO 传输）的干扰。

3.2. MAC 模型

3.2.1. 基础架构模式中的关联

在基础架构模式中，关联是一种高层 MAC 功能，由关联管理器（WifiAssocManager 基类和默认子类 WifiDefaultAssocManager）实现。站点 MAC、关联管理器基类和子类之间的交互如图 扫描过程 所示。

扫描过程

STA 的 Wi-Fi MAC 请求关联管理器启动具有指定参数的扫描过程，包括扫描类型（主动或被动）、目标 SSID、扫描的信道列表等。在扫描结束时，STA Wi-Fi MAC 期望收到最佳 AP 的通知以进行关联。在扫描期间接收到的每个 Beacon 或 Probe Response 帧都会被转发到关联管理器，该管理器会维护一个与扫描参数匹配的候选 AP 列表。默认关联管理器会按照接收到的 Beacon/Probe Response 帧的 SNR 降序排列这些 AP。

当通知开始扫描过程时，默认关联管理器会调度一个方法调用，该方法处理在调用时已接收到的帧中包含的信息。当 AP 和 STA 都具有多个链接（即它们是 802.11be MLDs）时，默认关联管理器尝试尽可能多地建立链接。这涉及在 STA 的一些链接上切换工作信道以匹配与 AP MLD 关联的 AP 所运行的信道。

如果 AP 因某种原因拒绝关联，STA 将尝试与下一个最佳 AP 关联，直到候选列表耗尽，这时 STA 将进入 “REFUSED” 状态。在这种情况下，模拟用户需要通过某种方式强制重新尝试关联，例如更改配置（即 STA 不会在拒绝后持续尝试关联）。

一旦关联完成，如果模拟用户更改了配置，STA 将尝试重新关联到现有的 AP。

如果丢失的 Beacon 数量超过阈值，STA 将通知设备其他部分链路已断开（关联丢失），并重新启动扫描过程。需要注意的是，当关联请求失败且未明确被拒绝时（即 AP 未响应关联请求），也可能发生这种情况。在非 AP MLD 的情况下，要丢失关联，必须在任何链接的最大 Beacon 丢失次数乘以两次连续 Beacon 帧间隔的时间间隔内未接收到 Beacon。

3.2.2. 漫游

当前不支持第 2 层漫游（即 STA 将其关联从一个 AP 切换到另一个 AP）。因此，IEEE 802.11 标准中描述的最小/最大信道驻留时间实现也被省略，因为它仅在信道漫游的上下文中有意义。

3.2.3. 信道访问

802.11 分布式协调功能（DCF）用于计算何时允许访问传输介质。虽然实现 DCF 使用周期性定时器（每个时隙到期触发）会相对简单，但我们选择了 [[ji2004sslswn]](https://www.nsnam.org/docs/models/html/wifi-references.html#ji2004sslswn) 中描述的方法，该方法仅在需要时惰性计算退避定时器持续时间，据称性能明显优于更简单的周期性定时器解决方案。

DCF 基本访问的描述详见 [[ieee80211-2016]](https://www.nsnam.org/docs/models/html/wifi-references.html#ieee80211-2016) 的第 10.3.4.2 节：

• “当 STA 确定传输队列中有帧时，若介质空闲且持续空闲一个 DIFS 时间（或一个 EIFS 时间，从上一忙碌事件结束算起，以较大者为准），并且退避定时器为零，则可以传输 MPDU。否则，应遵循 10.3.4.3 节描述的随机退避过程。”

因此，当以下所有条件都满足时，STA 可以不调用退避过程：

• 在帧排队等待传输时，介质处于空闲状态；
• 从帧排队开始到以下事件的较新者为止，介质持续空闲：一个 DIFS 时间；从上一个介质忙碌事件（与接收的错误帧相关联）结束开始的一个 EIFS 时间；
• 退避定时器为零。

EDCA 的退避过程与 DCF 的稍有不同，其描述详见 [[ieee80211-2016]](https://www.nsnam.org/docs/models/html/wifi-references.html#ieee80211-2016) 的第 10.22.2.2 节。

在信道访问方面，ns-3 默认配置下，QoS 和非 QoS AP 的 Beacon 在 PIFS 时间（SIFS 加上一个时隙时间）后访问信道，且无需退避（CWmin 和 CWmax 都设置为零），这使得 Beacon 比其他访问类别具有更高的优先级。

3.2.4. Frame Exchange Managers

随着 IEEE 802.11 标准的不断演进，添加的功能越来越多，因此让单个组件处理所有允许的帧交换序列变得愈发困难。为保持代码的清晰和可扩展性，同时避免代码重复，ns-3 引入了一系列 FrameExchangeManager 类。这些类分别处理不同修正案引入的帧交换序列。FrameExchangeManager 类的继承关系如图 FrameExchangeManager hierarchy 所示。

FrameExchangeManager 层次结构

每个 FrameExchangeManager 类支持的功能如下：

• FrameExchangeManager：基类，处理非 QoS 站点的基本序列，包括 MPDU 和普通确认帧、RTS/CTS 和 CTS-to-self、NAV 设置和重置、MPDU 分片等。
• QosFrameExchangeManager：添加了 TXOP 支持，包括多种保护设置、通过 CF-End 进行 TXOP 截断、TXOP 恢复、在响应 TXOP 持有者发送的 RTS 时忽略 NAV。
• HtFrameExchangeManager：支持压缩型 Block Ack、A-MSDU 和 A-MPDU 聚合以及隐式 Block Ack 请求策略。
• VhtFrameExchangeManager：支持 S-MPDUs。
• HeFrameExchangeManager：支持通过 DL OFDMA 和 UL OFDMA 传输和接收多用户帧。

FrameExchangeManager 类可以通过属性控制其处理的帧交换序列。例如，FrameExchangeManager 基类具有 ProtectedIfResponded 属性，用于启用/禁用 RTS/CTS 保护，适用于已响应需要确认的帧的站点，即使该帧未受到 RTS/CTS 的保护。

3.2.5. MAC 队列

在 QoS 站点，每个 EDCA 功能，以及在非 QoS 站点，DCF，都有自己的 MAC 队列（WifiMacQueue 类的一个实例），用于存储来自上层的待传输数据包。在 QoS 站点，每个接收到的数据包根据套接字优先级分配一个用户优先级（例如，可参考 wifi-multi-tos 或 wifi-mac-ofdma 示例），该优先级决定处理数据包的接入类别（Access Category）。默认情况下，Wi-Fi MAC 队列支持流控制，因此如果对应的 MAC 队列已满，上层不会向下转发数据包。

Wi-Fi MAC 队列不支持动态队列限制（如字节队列限制）；因此，只有当某接入类别的 WifiMacQueue 完全满时，才会对流量控制层产生反压（即，当队列深度达到 MaxSize 属性值时，默认值为 500 个数据包）。TCP 小队列（TSQ）[corbet2012] 是 Linux 的一项功能，用于从 Wi-Fi 设备向套接字层提供反馈，以控制 Wi-Fi 层队列中的数据量。ns-3 的 TCP 尚未实现 TSQ，WifiNetDevice 也未提供此类具体反馈（尽管使用现有的追踪源可能足以支持）。无论如何，实验测试表明，TSQ 会干扰 Wi-Fi 上行传输中的聚合 [grazia2022]。

数据包在 Wi-Fi MAC 队列中保留，直到被确认或丢弃。数据包可能因以下原因被丢弃，例如，其生命周期到期（即在队列中停留时间过长）或达到最大重试次数。数据包的最大生命周期可以通过 WifiMacQueue 的 MaxDelay 属性配置。可以使用多种追踪源来跟踪数据包传输的结果（请参阅对应的 Doxygen 文档）：

• WifiMac 追踪源：AckedMpdu、NAckedMpdu、DroppedMpdu、MpduResponseTimeout、PsduResponseTimeout、PsduMapResponseTimeout。
• WifiMacQueue 追踪源：Expired。

内部，Wi-Fi MAC 队列由多个子队列组成，每个子队列存储特定类型的帧（例如，数据帧或管理帧），并具有特定的接收方地址和 TID。对于单用户传输，下一站由 Wi-Fi MAC 队列调度器（由 WifiMac 实例持有）确定。Wi-Fi MAC 队列调度器由一个基类（WifiMacQueueScheduler）及其定义特定调度策略的子类实现。默认调度器（FcfsWifiQueueScheduler）为管理帧分配更高优先级，并以先进先出（FCFS）方式处理数据帧。对于多用户传输（见下文），调度由多用户调度器执行，该调度器可以选择是否咨询 Wi-Fi MAC 队列调度器，以确定通过多用户下行链路（DL）或上行链路（UL）传输需要服务的站点。

3.2.6. 多用户传输

自 IEEE 802.11ax 修正案引入以来，多用户（MU）传输成为可能，通过 OFDMA 和/或 MU-MIMO 实现下行链路（DL）和上行链路（UL）传输。目前，ns-3 仅支持通过 OFDMA 进行的多用户传输。以下为 DL OFDMA 的三种确认序列。

第一种确认序列由多个 BlockAckRequest/BlockAck 帧组成，这些帧作为单用户帧发送，如图 单用户格式的 DL MU 帧确认 所示。

单用户格式的 DL MU 帧确认

第二种确认序列使用 MU-BAR 触发帧发送（作为单用户帧），以请求在 TB PPDUs 中发送的 BlockAck 响应，如图 通过单用户帧发送的 MU-BAR 触发帧的 DL MU 帧确认 所示。

通过单用户帧发送的 MU-BAR 触发帧的 DL MU 帧确认

第三种确认序列将 MU-BAR 触发帧聚合到 DL MU PPDU 中的每个 PSDU，BlockAck 响应在 TB PPDUs 中发送，如图 通过聚合的 MU-BAR 触发帧的 DL MU 帧确认 所示。

通过聚合的 MU-BAR 触发帧的 DL MU 帧确认

对于 UL OFDMA，支持 BSRP 触发帧和基本触发帧，如图 使用 UL OFDMA 的帧交换序列 所示。AP 发送 BSRP 触发帧，以请求站点发送包含缓冲状态报告（Buffer Status Reports）的 QoS Null 帧。AP 发送基本触发帧，以请求站点在 TB PPDUs 中发送数据帧，这些帧由 AP 通过 Multi-STA BlockAck 帧确认。需要注意的是，为了使两次帧交换序列以 SIFS 间隔分隔（如图所示），必须满足以下条件：传输接入类别具有非零 TXOP 限制；TXOP 中有足够剩余时间进行基本触发帧启动的帧交换序列；多用户调度器选择在 BSRP 触发帧之后发送基本触发帧。

使用 UL OFDMA 的帧交换序列

3.2.7. 多用户调度器

一个新的组件，称为 MultiUserScheduler，负责确定聚合 AP 在获得 TXOP 时执行的帧交换序列（DL OFDMA、UL OFDMA 或 BSRP 触发帧），以及执行所选帧交换序列所需的信息（例如，在 DL OFDMA 的情况下需要发送的 PSDU 集合）。TXOP 是在请求信道访问后（通常由 DCF/EDCA 执行）获得的。如果设备有帧需要传输，MultiUserScheduler 可以协调 UL MU 传输，即使没有 DL 流量。访问请求间隔可以通过 AccessReqInterval 属性设置为非零值。此访问请求间隔是 MultiUserScheduler 两次连续请求信道访问的间隔。这些请求独立于 AP 队列中是否有帧存在。还可以设置 MultiUserScheduler 请求信道访问的接入类别（通过 AccessReqAc 属性），并选择访问请求间隔是否从 MultiUserScheduler 上次请求信道访问或上次由 DCF/EDCA 获得信道访问的时间开始计算（通过 DelayAccessReqUponAccess 属性）。

MultiUserScheduler 是一个抽象基类。目前，唯一可用的子类是 RrMultiUserScheduler。默认情况下，没有多用户调度器聚合到 AP（因此未启用 OFDMA）。

3.2.8. 轮询多用户调度器

轮询多用户调度器动态分配每个站点的优先级，以确保在选择站点进行 DL 多用户传输时的空中时间公平性。NStations 属性允许设置可成为 DL 多用户帧接收方的最大站点数。因此，每当 HE AP 访问信道以传输 DL 多用户帧时，调度器确定 AP 需要发送帧的站点数（以该属性指定的值为上限），并尝试为尽可能多的站点分配相等大小的 RUs，而不留有未使用的相同大小的 RUs。例如，如果信道带宽为 40 MHz，且确定的站点数为 5，则前 4 个站点（按优先级排序）将各分配一个 106-tone RU（如果分配了 52-tone RU，将会有三个 52-tone RUs 未使用）。如果可以分配中央 26-tone RU（由 UseCentral26TonesRus 属性确定），尚未分配 RU 的站点可能会被分配这些 RU。在上述示例中，第五个站点将分配一个可用的中央 26-tone RU。

当启用 UL OFDMA（通过 EnableUlOfdma 属性）时，每个 DL OFDMA 帧交换之后都会有一个 UL OFDMA 帧交换，涉及相同的站点集和与之前 DL 多用户帧相同的 RU 分配。可以选择（取决于 EnableBsrp 属性的值）在发送基本触发帧之前发送 BSRP 触发帧，以便 AP 收集站点的缓冲状态信息。

3.2.9. 增强的多链路单无线电操作（EMLSR）

IEEE 802.11be 修正案引入了 EMLSR 操作模式，允许非 AP MLD 在一组设置的链路（称为 EMLSR 链路）上交替进行帧交换（参见 IEEE 802.11be D4.1 第 35.3.17 节）。ns-3 支持以下描述的 EMLSR 操作。

3.2.9.1. 支持 EMLSR 操作模式的非 AP MLD 架构

支持 EMLSR 操作模式的非 AP MLD 架构基于以下假设：只有一个 PHY 实例（称为 主 PHY）具有完整的 TX/RX 能力，而其他 PHY 实例（简称为 辅助 PHY 或 aux PHYs）的 TX/RX 能力有限。因此，只有主 PHY 能够与 AP MLD 进行帧交换。由于帧交换可以发生在任何 EMLSR 链路上，主 PHY 所操作的链路会在模拟过程中动态切换，具体如以下所述。

3.2.9.2. 启用/禁用 EMLSR 模式

在支持 EMLSR 操作模式的非 AP MLD 上，可以启用 EMLSR 模式的链路（至少两条），并与支持 EMLSR 操作模式的 AP MLD 执行多链路设置。MLD 的 EHT 配置中的 EmlsrActivated 属性决定了该 MLD 是否支持 EMLSR 操作模式。如果非 AP MLD 的 EmlsrActivated 属性被设置为 true，则 WifiMacHelper 将通过 SetEmlsrManager 方法配置的类型和属性值安装一个 EMLSR 管理器。

可以通过 EMLSR 管理器基类的 EmlsrLinkSet 属性启用或禁用非 AP MLD 链路上的 EMLSR 模式（默认情况下，多链路设置后禁用 EMLSR 模式）。设置 EmlsrLinkSet 属性会触发 EML 操作模式通知帧的发送，用于向 AP 通知新的 EMLSR 链路集（如果多链路设置已完成）。否则，EMLSR 链路集将被存储，并在多链路设置完成后立即发送 EML 操作模式通知帧。因此，用户可以通过在初始化时设置 EmlsrLinkSet 属性，选择在多链路设置完成后立即启用某些链路上的 EMLSR 模式；或者可以在初始化时将 EmlsrLinkSet 属性留空，并在运行时设置它以在特定的模拟时间启用某些链路上的 EMLSR 模式（多链路设置完成后）。非 AP MLD 用于发送 EML 操作模式通知帧的链路由 EMLSR 管理器子类选择。默认的 EMLSR 管理器子类 DefaultEmlsrManager 选择主 PHY 操作的链路。当非 AP MLD 收到 EML 操作模式通知帧的确认后，会启动一个计时器，其持续时间为 AP MLD 通知的切换超时时间。当计时器过期，或者非 AP MLD 收到来自 AP MLD 的 EML 操作模式通知帧时，EMLSR 模式将在请求的链路集上启用（如果该集合不为空）或禁用（否则）。请求启用 EMLSR 模式的链路集必须包括主 PHY 操作的链路；在其他启用 EMLSR 模式的链路上操作的 PHY 实例被认为是辅助 PHY。

主 PHY 的 PHY 实例通过 EMLSR 管理器基类的 MainPhyId 属性进行配置。该类还允许定义辅助 PHY 的 TX/RX 能力：

• AuxPhyMaxModClass 属性表示辅助 PHY 支持的最大调制类别。
• AuxPhyChannelWidth 属性表示辅助 PHY 支持的最大信道宽度（MHz）。该属性的值可能会根据支持的最大调制类别自动限制。
• AuxPhyTxCapable 属性表示辅助 PHY 是否能够发送帧。

3.2.9.3. 下行链路 TXOP

EMLSR 操作：下行链路 TXOP

当支持 EMLSR 操作模式的 AP MLD 需要在与以 EMLSR 模式运行的非 AP MLD 的链路上启动帧交换时，它会发送一个 MU-RTS 触发帧，作为该交换的初始控制帧（ICF），请求非 AP MLD（以及可能的其他设备）响应（见图 EMLSR 操作：下行链路 TXOP）。MU-RTS 触发帧以非 HT 重复 PPDU 形式传输，传输速率为 6 Mbps、12 Mbps 或 24 Mbps。当初始控制帧的传输开始时，AP MLD 会阻止 EMLSR 链路上受 MU-RTS 触发帧影响的客户端的其他链路上的传输，以避免在这些链路上启动新的帧交换。

当 EMLSR 模式启用时，可以通过 EMLSR 管理器基类的 EmlsrPaddingDelay 和 EmlsrTransitionDelay 属性分别设置填充延迟和切换延迟。

3.2.9.4. 上行链路 TXOP

EMLSR 操作：上行链路 TXOP

EMLSR 客户端可以在任何 EMLSR 链路上启动 UL TXOP。当在辅助 PHY 操作的链路上获得信道访问时，辅助 PHY 会发送 RTS 帧，然后主 PHY 接管 TXOP（见图 EMLSR 操作：上行链路 TXOP）。

通过 EmlsrManager 类的 MediumSyncDuration、MsdMaxNTxops 和 MsdOfdmEdThreshold 属性可以分别配置同步延迟计时器的持续时间、最大 TXOP 尝试次数和主 20 MHz 信道的 OFDM ED 阈值。

3.2.10. 确认管理器

自 IEEE 802.11e 修正案引入以来，可用的确认策略编码在 QoS 数据帧的 QoS 控制字段中的确认策略子字段中。WifiAckManager 是为多种确认管理器提供接口的抽象基类，目前默认确认管理器是 WifiDefaultAckManager。

3.2.11. WifiDefaultAckManager

WifiDefaultAckManager 根据以下属性值确定使用的确认策略：

• UseExplicitBar：决定当需要接收方响应且当前传输包括多个帧（A-MPDU）时是否使用 显式 Block Ack 请求 策略。
• BaThreshold：确定 Block Ack 协议的发起方需要请求接收方响应的条件。
• DlMuAckSequenceType：选择 DL MU 帧的确认序列（单用户格式确认、通过 MU-BAR 触发帧确认或通过聚合到数据帧的 MU-BAR 触发帧确认）。

3.2.12. 保护管理器

保护管理器负责在发送帧时决定是否使用保护机制。

WifiProtectionManager 是一个抽象基类，为多种保护管理器提供接口。目前默认的保护管理器是 WifiDefaultProtectionManager。

3.2.13. WifiDefaultProtectionManager

WifiDefaultProtectionManager 根据远程站点管理器提供的信息选择合适的保护机制。

3.2.14. 速率控制算法

ns-3 提供多种速率控制算法，有些基于真实设备中的实现，另一些来自学术文献。以下是 MAC 低层可用的速率控制算法：

真实设备中的算法：

• ArfWifiManager
• OnoeWifiManager
• ConstantRateWifiManager
• MinstrelWifiManager
• MinstrelHtWifiManager

文献中的算法：

• IdealWifiManager（WifiHelper 的默认算法）
• AarfWifiManager [lacage2004aarfamrr]
• AmrrWifiManager [lacage2004aarfamrr]
• CaraWifiManager [kim2006cara]
• RraaWifiManager [wong2006rraa]
• AarfcdWifiManager [maguolo2008aarfcd]
• ParfWifiManager [akella2007parf]
• AparfWifiManager [chevillat2005aparf]
• ThompsonSamplingWifiManager [krotov2020rate]

3.2.15. ConstantRateWifiManager

固定速率控制算法始终为每个数据包使用相同的传输模式。用户可以为所有单播包设置所需的 DataMode，以及为所有请求控制包（例如 RTS）设置 ControlMode。

如果希望为非单播包指定不同的数据模式，用户需设置 WifiRemoteStationManager 的 NonUnicastMode 属性。否则，将默认使用最低速率模式。

可用属性：

• DataMode（默认值：WifiMode::OfdmRate6Mbps）：指定所有单播包的模式。
• ControlMode（默认值：WifiMode::OfdmRate6Mbps）：指定所有请求控制包的模式。

3.2.16. IdealWifiManager

理想速率控制算法根据先前发送数据包的信噪比（SNR）选择最佳模式。当节点 A 向节点 B 发送单播包，且 B 成功接收后，B 会记录接收包的 SNR 并通过 ACK 将其发送回 A。这样，A 可以通过一个额外的机制（因而被称为“理想”）获取发送给 B 的数据包的 SNR，从而根据一组 SNR 阈值选择传输模式。

可用属性：

• BerThreshold（默认值：1e-6）：用于计算每种模式的 SNR 阈值的最大比特错误率（BER）。

3.2.17. ThompsonSamplingWifiManager

Thompson 采样（TS）是多臂老虎机问题的经典解决方案。ThompsonSamplingWifiManager 实现了一种基于 TS 的速率控制算法，其目标是提供一个简单的统计算法，且参数较少。

3.2.18. MinstrelWifiManager

Minstrel 是一种源自 madwifi 项目的速率控制算法，当前是 Linux 内核的默认速率控制算法。

3.2.19. MinstrelHtWifiManager

Minstrel 的扩展，支持 802.11n/ac/ax。

3.2.20. 802.11ax OBSS PD 空间复用

802.11ax 模式支持 OBSS PD 空间复用功能。OBSS PD 表示重叠基本服务集前导检测（Overlapping Basic Service Set Preamble-Detection），在特定条件下允许 STA 忽略其他 BSS 的 PPDU。

3.2.21. OBSS PD 算法

ObssPdAlgorithm 是 OBSS PD 算法的基类，实现了通用功能，包括设置回调并在算法请求时执行 PHY 重置。

3.2.22. 恒定 OBSS PD 算法

恒定 OBSS PD 算法由 ConstantObssPdAlgorithm 类实现。

3.2.23. 修改 Wi-Fi 模型

修改默认的 Wi-Fi 模型是研究中常见的任务。本节概述了如何修改默认的 Wi-Fi 模型，常见任务包括但不限于：

• 创建或修改 Wi-Fi 帧/头部，修改 wifi-mac-header.*。
• 修改 MAC 低层，例如处理新控制帧（RTS/CTS/ACK/Block ACK）、更改双向/四向事务，通常修改 frame-exchange-manager.* 或其子类。
• 修改 MAC 高层，例如处理新管理帧（Beacon/Probe），修改 wifi-mac.*、sta-wifi-mac.*、ap-wifi-mac.* 或 adhoc-wifi-mac.*。
• Wi-Fi 队列管理：修改 txop.* 和 qos-txop.*。
• 通道接入管理：修改 channel-access-manager.* 文件，这些文件负责授予对 Txop 和 QosTxop 的访问。
• 修改分片和 RTS 阈值，这些由 Wi-Fi 远程站点管理器处理。
• 修改或创建新速率控制算法，需创建 Wi-Fi 远程站点管理器的子类或修改现有的算法。