ndnSIM无线WiFi模块分析

1. 设计文档

ns-3节点可以包含NetDevice对象的集合，就像实际的计算机包含以太网、Wifi、蓝牙等的单独接口卡一样。本章描述了ns-3的WifiNetDevice和相关模型。通过将WifiNetDevice对象添加到ns-3节点，可以创建基于802.11的基础设施和自组织网络的模型。

1.1 模型概述

WifiNetDevice基于IEEE 802.11标准[iee80211]为无线网络接口控制器建模。

我们将在下面进行更详细的介绍，但简而言之，ns-3为802.11的这些方面提供了模型：

• 具有基础设施和自组织模式的基本802.11 DCF（Distributed Coordination Function）
• 802.11a、802.11b、802.11g、802.11n（2.4和5 GHz频带）、802.11ac、802.11ax（2.4、5和6 GHz频带）和802.11be物理层
• 802.11n的MSDU聚合和MPDU聚合扩展，并且两者可以组合在一起（两级聚合）
• 802.11ax DL OFDMA和UL OFDMA（包括对MU EDCA参数集的支持）
• 802.11be多链路发现和设置
• 802.11e的基于QoS的EDCA和排队扩展
• 使用不同传播损耗模型和传播延迟模型的能力，请参阅传播一章了解更多详细信息
• 已根据链路模拟和其他参考文献验证的数据包错误模型和帧检测模型
• 各种速率控制算法，包括Aarf、Arf、Cara、Onoe、Rraa、ConstantRate、Minstrel和Minstrel HT
• 802.11s（网状），在另一章中描述
• 802.11p和WAVE（车载），在另一章中描述

ns-3中提供的一组802.11模型试图提供802.11规范的准确MAC级实现，并为不同的PHY提供PHY级别的分组级抽象，对应于802.11a/b/g/n/ac/ax/be规范。

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

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

该实现是模块化的，并提供了大约三个子层的模型：

• 物理层模型：它们对特定修正和常见物理层操作和功能进行建模。
• 所谓的MAC低模型：它们对介质访问（DCF和EDCA）、帧保护（RTS/CTS）和确认（ACK/BlockAck）等功能进行建模。在ns-3中，较低级别的MAC由帧交换管理器层次结构、信道接入管理器和MAC中间实体组成。
• 所谓的MAC高模型：它们在Wifi中实现非时间关键过程，如MAC级信标生成、探测和关联状态机，以及一组速率控制算法。在文献中，该子层有时被称为上层MAC，并且由更多面向软件的实现与时间关键的硬件实现组成。

接下来，我们提供了每一层的设计概述，如图WifiNetDevice架构所示。对于802.11be多链路设备（MLD），WifiPhy、FrameExchangeManager和ChannelAccessManager的实例数量与链路数量一样多。

MAC高层模型

目前有三种MAC高模型提供了这三种（非网格；网格等价物，它是具有公共父节点ns3::WifiMac的这些节点的兄弟节点，此处不讨论）Wi-Fi拓扑元素-接入点（AP）（ns3::ApWifiMac）、非AP站（STA），和独立基本服务集（IBSS）中的STA，也称为自组织网络（ns3::AdhocWifiMac）。

其中最简单的是ns3::AdhocWifiMac，它实现了一种不执行任何类型的信标生成、探测或关联的Wi-Fi MAC。ns3::StaWifiMac类实现了一个主动探测和关联状态机，该状态机在错过太多信标时处理自动重新关联。最后，ns3::ApWifiMac实现了一个AP，它生成周期性信标，并接受每一次关联尝试。

这三种MAC高模型在ns3::WifiMac中共享一个共同的父级，该父级在其他MAC配置中公开了一个属性QosSupported，该属性允许配置802.11e/WMM风格的QoS支持。其实是都继承了ns3::RegularWifiMac，ns3::RegularWifiMac又继承了ns3::WifiMac；

MAC低层也可以使用几种速率控制算法。可用速率控制算法的完整列表在单独的部分中提供。

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.2 范围和限制

IEEE 802.11标准[iee80211]是一个大型规范，ns-3并没有涵盖所有方面；ns-3的一致性文档本身将导致一个非常长的文档。本节试图总结对标准和实践中发现的行为的遵守情况。

物理层和信道模型以每个分组为基础进行操作，在使用默认YansWifiPhy模型时没有频率选择性传播，也没有干扰效应。此时也不支持定向天线。对于加性高斯白噪声（AWGN）场景或宽带干扰场景，性能取决于分析模型（基于调制和信道宽度等因素）对接收信噪比，其中噪声结合了热噪声和来自其他WiFi分组的干扰的影响。只有在使用SpectrumWifiPhy时，才会对来自其他无线技术的干扰进行建模。以下详细信息与物理层和通道模型有关：

(频率选择性衰落就是信号带宽大于相关带宽)

1.3 设计细节

本节的其余部分专门介绍一些Wi-Fi型号的更深入的设计说明。有兴趣跳过wifi模块使用部分（用户文档）的用户可以在此时跳过。我们通过首先描述信道和PHY模型，然后描述MAC模型，从底层开始组织这些更详细的部分。

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

SpectrumWifiPhy框架使用频谱模块信道框架。

YansWifiChannel是ns-3无线网络模块中唯一的具体信道型号类别。ns3::YansWifiChannel实现使用ns-3传播模块中提供的传播损耗和延迟模型。特别地，可以将多个传播模型添加到信道对象（如果添加了多个损耗模型，则链接在一起），并且还添加了传播延迟模型。从ns3::YansWifiPhy对象发送到具有特定信号功率的信道上的数据包，在信号功率由于（一个或多个）传播损耗模型而降低，并且在与传输（串行化）延迟和由于任何信道传播延迟模型（通常由于设备位置之间的光速延迟）而导致的传播延迟相对应的延迟之后。

只有ns3::YansWifiPhy的对象可以附加到ns3::YansWifiChannel；因此，不允许对诸如LTE之类的其他（干扰）技术进行建模的对象。此外，来自不同信道的分组不进行交互；如果信道被逻辑配置用于例如信道5和6，则分组不会引起相邻信道干扰（即使它们的信道号重叠）。

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的错误概率

PhyEntity

抽象基类ns3::PhyEntity使每个PHY实体能够使用一组唯一的API，对应于IEEE 802.11标准的不同修订。当前实现的PHY实体是：

• ns3::DsssPhy: PHY entity for DSSS and HR/DSSS (11b)
• ns3::OfdmPhy: PHY entity for OFDM (11a and 11p)
• ns3::ErpOfdmPhy: PHY entity for ERP-OFDM (11g)
• ns3::HtPhy: PHY entity for HT (11n)
• ns3::VhtPhy: PHY entity for VHT (11ac)
• ns3::HePhy: PHY entity for HE (11ax)
• ns3::EhtPhy: PHY entity for EHT (11be)

WifiPpdu

与PhyEntity相同，ns3::WifiPpdu基类已专门化为以下特定于修正案的PPDU：

• ns3::DsssPpdu: PPDU for DSSS and HR/DSSS (11b)
• ns3::OfdmPpdu: PPDU for OFDM (11a and 11p)

YansWifiPhy and WifiPhyStateHelper

类ns3::YansWifiPhy负责接收从MAC（ns3::FrameExchangeManager对象）传递给它的数据包，并将它们发送到它所连接的ns3::YangsWifiChannel上。它还负责从该信道接收数据包，如果接收被认为是成功的，则将其传递给MAC。

预期接收的信号的能量是根据传输功率计算的，并根据发射器的 Tx 增益、接收器的 Rx 增益以及有效的任何路径损耗传播模型。

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

• TX：PHY当前正在代表其关联的MAC发送信号，上层向下层转发
• RX：PHY在信号上同步，并等待，直到它接收到最后一个比特，将其转发到MAC，下层向上层转发。
• CCA_BUSY：PHY正在为主信道发出PHY-CCA.指示（BUSY）指示。
• 空闲：PHY不处于TX、RX或CCA_BUSY状态。
• 切换：物理层正在切换信道。
• 睡眠：PHY处于省电模式，既不能发送也不能接收帧。
• 关闭：PHY电源关闭，无法发送或接收帧。

数据包接收工作如下。对于YansWifiPhy来说，大部分逻辑都是在WifiPhy基类中实现的。YansWifiChannel调用WifiPhy::StartReceivePreamble()。后者调用适当PHY实体的PhyEntity::StartReceivePreamble()来开始分组接收，但首先要对照存储在属性WifiPhy::RxSensitivity中的阈值来检查分组的概念信号功率电平。功率低于RxSensitivity的任何数据包都将被丢弃，无需进一步处理。默认值为-101 dBm，这是室温下20 MHz信号的热噪声基底。
该属性的目的有两个：1）不会影响结果的非常弱的信号将消耗模拟内存和事件处理，因此将其丢弃；2）可以向上调整该值，以作为涉及空间重用考虑的实验的基本载波感知阈值限制。提醒用户注意提高此阈值的行为；即功率低于该阈值的所有分组将在接收时被丢弃。

在StartReceivePreamble()中，数据包被立即添加到干扰辅助器以进行信噪比跟踪，然后根据PHY的状态决定进一步的接收步骤。例如，在PHY正在发送的情况下，数据包将被丢弃。如果PHY是IDLE，或者如果PHY正在接收并且正在使用可选的FrameCaptureModel（并且数据包在捕获窗口内），则接下来调用PhyEntity::StartPreambleDetectionPeriod()。

PhyEntity::StartPreambleDetectionPeriod。自ns-3.30中的模型修订以来，任何从IDLE状态转换的状态机都被抑制，直到前导码检测事件之后。

PhyEntity::EndPreambleDetectionPeriod()方法将使用前导码检测模型来检查信号是否足够强以被接收，如果足够强，则为前导码的结尾调度事件；PhyEntity::EndReceiveField()，并且PHY被置于CCA_BUSY状态。目前，ns-3中只有一种简单的基于阈值的前导码检测模型，称为ThresholdPreambleDetectionModel。如果不存在前导码检测模型，则假定已经检测到前导码。需要注意的是，从ns-3.30版本开始，WifiPhyHelper中的默认设置是添加阈值前导检测模型，阈值RSSI为-82dBm，阈值SNR为4dB。RSSI(接受信号强度)和SNR都必须高于这些相应的值，才能成功地检测到前导码。与以前的版本相比，ns-3.30中的默认灵敏度有所降低，因此以前成功的一些数据包接收现在将在这次检查中失败。

PhyEntity::EndReceiveField()方法将检查当前前导码和报头字段的正确接收，如果是，则为下一个字段调用PhyEntity::StartReceiveField()。指示（BUSY）不是针对主通道发出的。

PhyEntity::StartReceiveField（）处的下一个事件使用干扰助手和错误模型检查标头是否成功解码，如果成功，则检查PhyRxPayloadBegin回调（相当于PHY-RXSTART原语）被触发。PHY报头通常以比有效载荷更低的调制速率来发送。
基于观测到的SNR来评估与PHY报头相对应的分组的部分的错误概率。InterferenceHelper对象根据InterferenceHelp跟踪的SNR返回此标头的“错误概率（PER）”值。然后，PhyEntity从均匀分布中提取一个随机数，并将其与PER进行比较，并决定成功或失败。

这是重复执行的，直到调用PhyEntity::StartReceivePayload（）的数据字段的开头。

即使PHY接收到的分组对象不是接收过程的一部分，它们也会被InterferenceHelper对象跟踪，用于SINR计算和做出明确的信道评估决策。如果在接收过程中，由于PHY处于不能接收分组的状态而导致分组出错或丢弃，则将分组添加到干扰辅助器，并且将所有这样的信号的能量的总和与能量检测阈值进行比较，以确定PHY是否应进入CCA_BUSY状态。

如果PHY已经接收到占用具有高于WifiPhy::CcaSensitivity（默认为-82dBm）的接收功率的主信道的信号，或者如果主信道上的测量能量高于能量检测阈值WifiPhy::CcaEdThreshold（默认为-62dBm），则发出PHY-CA.指示（BUSY）。

当使用信道绑定时，还报告未占用主信道的信号的CCA指示。由于802.11ac及以上版本需要检测大于20 MHz的辅助信道的CCA灵敏度，因此可以使用VhtConfiguration::SecondaryCaSensitivityThresholds属性按辅助信道宽度调整CCA灵敏度阈值。

对于802.11ax及以上，并且如果操作带宽等于或大于40MHz，则正在感测操作带宽的每个20MHz子信道，并且PHY-CA指示还报告这些20MHz子通道中的每个的CCA_BUSY持续时间指示。给定20MHz子信道的零持续时间指示20MHz子通道为空闲。

上面描述了分组是单个MPDU的情况。对于使用MPDU聚合的最新Wi-Fi标准，StartReceivePayload为每个单独的MPDU的接收安排一个事件（ScheduleEndOfMpdus），然后在MPDU到达FrameExchangeManager时转发每个MPDU（如果MPDU接收成功）。一旦A-MPDU接收完成，FrameExchangeManager也会收到关于成功接收的MPDU数量的通知。

InterferenceHelper

InterferenceHelper是一个跟踪所有传入分组并计算正在接收的分组的错误值概率的对象，还评估信道上的能量是否上升到给定阈值以上以及上升超过给定阈值的时间。

误差概率计算的基本操作如图SNIR函数所示。在ns-3模型中，数据包被表示为比特（而不是符号），InterferenceHelper将数据包分解为一个或多个“块”，每个“块”具有不同的信噪比（SNIR）。通过从所使用的错误模型中询问给定数量的比特的错误概率来单独评估每个块。InterferenceHelper基于这些块及其持续时间构建一个聚合的“错误概率”值，并将其返回给WifiPhy以进行接收决策。

根据SNIR函数，我们可以导出用于传输的调制和编码方案的误码率（BER）和分组误码率（PER）；

如果使用MIMO，并且空间流的数量低于接收机处的活动天线的数量，则如下将增益应用于计算的SNIR（因为没有使用STBC）：

ErrorRateModel

ns-3基于帧的输入接收SNR并且基于可能在时间上重叠的任何可能的干扰帧来做出分组错误或成功决策；即基于信噪比（加干扰）或SINR。ns-3中的分组差错率（PER）和SINR之间的关系由ns3:：ErrorRateModel定义，其中有几个。PER是帧的调制和编码（MCS）、其SINR以及为MCS配置的特定ErrorRateModel的函数。

ns-3已经随着时间的推移更新了其默认的ErrorRateModel。最近基于OFDM的标准（即802.11n/ac/ax）的当前（截至ns-3.33版本）模型是ns3:：TableBasedErrorRateModel。802.11a/g的默认值是ns3::YansErrorRateModel，802.11b的默认值为ns3::DsssErrorRateModel。
最新标准的错误率模型在ns-3.33发布周期内进行了更新（以前是ns3:：NistErrorRateModel）。

SpectrumWifiPhy

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

为了使频谱框架适应Wi-Fi，需要进行两项主要更改。首先，物理层必须发送与频谱信道框架兼容的信号，特别是允许来自不同技术的信号共存的MultiModelSpectrumChannel。其次，必须扩展InterferenceHelper以支持非Wi-Fi信号的插入，并将其接收功率添加到噪声中，就像将非预期的Wi-Fi信号（可能来自不同的SSID或从隐藏节点延迟到达）添加到噪声一样。

与没有外部信号的YansWifiPhy不同，对于高于CcaEdThreshold的外部信号，将提升CCA_BUSY状态（有关CCA模式1的定义，请参阅802.11-2012标准中的第16.4.8.5节）。因此，属性WifiPhy:：CcaEdThreshold在该模型中可能比YansWifiPhy模型中发挥更大的作用。

为了支持频谱信道，YansWifiPhy的发射和接收方法被调整为使用频谱信道API。这需要开发一些与SpectrumModel相关的类。WifiSpectrumValueHelper类用于创建具有频谱框架的Wi-Fi信号，并将其能量分布在频带上。频谱被细分为子频带（OFDM子载波的宽度，这取决于技术）。分配给特定信道的功率大致根据功率将如何分配给子载波而分布在子频带上。相邻信道是通过使用如标准中所定义的OFDM发射频谱掩码来建模的。

为了支持更轻松的用户配置体验，复制并调整了现有的YansWifi辅助类（src/wifi/helper中），以提供等效的SpectrumWifi帮助类。

最后，出于避免C++多重继承问题的原因，在SpectrumWifiPhy和Spectrum信道之间插入了一个名为WifiSpectrumPhyInterface的小型转发类作为垫片。
WifiSpectrumPhyInterface调用不同的SpectrumWifiPhy:：StartRx（）方法来启动接收过程。该方法根据WifiPhy:：RxSensitivity属性执行信号功率检查，并丢弃弱信号，还检查信号是否为Wi-Fi信号；非Wi-Fi信号被添加到InterferenceHelper，并且可以引起CCA_。在这一点之后，有效的Wi-Fi信号导致WifiPhy:：StartReceivePreamble被调用，并且处理如上所述继续。

MAC Model

基础设施模式下的关联是由关联管理器执行的高级MAC功能，它通过基类（WifiAssocManager）和默认子类（WifiDefaultAssocManager）来实现。
站点MAC、Association Manager基类和子类之间的交互如图扫描过程所示。

STA wifi MAC请求关联管理器启动具有指定参数的扫描过程，包括扫描类型（主动或被动）、所需SSID、要扫描的信道列表等。然后，STA wifi MAC期望在扫描过程结束时被通知要关联的最佳AP。在扫描期间接收到的每个信标或探测响应帧被转发到关联管理器，该关联管理器保持与扫描参数匹配的候选AP的列表。这种列表的排序标准是由Association Manager子类定义的。默认关联管理器按照接收到的信标/探测响应帧的SNR的递减顺序对AP进行排序。

当被通知扫描过程开始时，默认关联管理器调度对一个方法的调用，该方法处理包括在接收到的帧中的信息，直到调用这种方法为止。当AP和STA都具有多个链路（即它们是802.11be MLD）时，默认的关联管理器尝试设置为尽可能多的链接。这涉及切换STA的一些链路上的操作信道，以匹配与AP MLD相关联的AP正在其上操作的那些链路。

如果AP出于某种原因拒绝了关联，则STA将尝试与下一个最佳AP关联，直到候选列表耗尽，然后将STA发送到“拒绝”状态。如果发生这种情况，模拟用户将需要以某种方式强制重新关联重试，可能是通过改变配置（即，STA不会在拒绝时持续尝试关联）。

当关联时，如果模拟用户更改了配置，则STA将尝试与现有AP重新关联。

如果丢失信标的数量超过阈值，则STA将通知设备的其余部分链路断开（关联丢失），并重新启动扫描过程。注意，当关联请求在没有明确拒绝的情况下失败时（即，AP未能响应关联请求），也可能发生这种情况。

Channel access

802.11分布式协调功能(Distributed Coordination Function)用于计算何时授予对传输介质的访问。
虽然如果我们使用每个插槽都过期的重复计时器，实现DCF会特别容易，但我们选择使用[ji2004sslswn]中描述的方法，在该方法中，无论何时需要，都会延迟计算退避计时器持续时间，因为据称它比更简单的重复计时器解决方案具有更好的性能。

DCF基本访问在[iee80211-2016]第10.3.4.2节中进行了描述。

• “当STA在DCF接入方法下操作时，当STA确定帧排队等待传输时介质空闲，并且在DIFS或EIFS的一段时间内保持空闲时，STA可以发送MPDU（10.3.2.3.7）从紧接在前的介质繁忙事件结束，以较大者为准，并且回退计时器为零。否则，应遵循10.3.4.3中所述的随机退避程序。”

因此，如果满足以下所有条件，则允许站点不调用退避过程：

• 当帧排队等待传输时，介质处于空闲状态
• 介质保持空闲，直到这两个事件中的最近一个：帧排队等待传输时的DIFS；上一次中忙事件结束时的EIFS（与错误帧的接收相关）
• 退避定时器为零

DCF的退避程序如[iee80211-2016]第10.3.4.3节所述。

• “当发现物理或虚拟CS机制指示的介质繁忙时，STA应调用退避过程来传输帧。“
• ”每次传输结束后，应立即执行退避程序，将具有子类型PS轮询的数据、管理或控制类型的MPDU的More Fragments位设置为0，即使当前没有其他传输排队。“

EDCA退避程序与DCF退避程序略有不同，如[iee80211-2016]第10.22.2.2节所述。当发生以下任何事件时，EDCAF应调用退避程序：

• 帧“排队等待传输，使得与该AC(无线接入控制器)相关联的一个传输队列现在变为非空，而与该AC关联的任何其他传输队列都是空的；主信道上的介质繁忙”
• “在该AC的TXOP期间，TXOP支架传输的最终PPDU中的MPDU传输已完成，TXNAV计时器已过期，并且该AC是主AC”
• “TXOP的初始PPDU中MPDU的传输失败[..]，该AC是一个主AC”
• “传输尝试与具有更高优先级的AC的另一个EDCAF内部冲突”
• （可选）“TXOP持有者在TXOP的非初始PPDU中传输MPDU失败”

此外，[iee80211-2016]第10.22.2.4节引入了时隙边界的概念，其基本上发生在作为接收具有正确FCS的帧的结果的最后繁忙介质之后的空闲介质的SIFS+AIFSNslotTime之后，或者发生在作为导致FCS错误的帧接收的结果的最近指示繁忙介质之后空闲介质的EIFS-DIFS+AIFSNslotTime+SFS之后，或者紧接在这些条件中的任何一个之后出现的空闲介质的slotTime之后。

在这些特定的插槽边界上，每个EDCAF应确定执行以下一项且仅执行其中一项功能：

• 递减退避定时器。
• 启动帧交换序列的传输。
• 由于内部冲突而调用退避程序。
• 什么都不做。

因此，如果EDCAF在给定时隙边界上递减其退避定时器，并且因此退避定时器具有零值，则EDCAF不能立即发送，但是它必须等待空闲介质的另一个slotTime才能开始发送。

当信道接入管理器确定可以准许信道接入时，它基于PHY提供的CCA-BUSY指示来确定被认为空闲的最大主信道。这样的信息被传递到Frame Exchange Manage，帧交换管理者依次通知多用户调度器（如果有的话）和Wifi Remote Station Manage。因此，PPDU在最大空闲主信道上传输。例如，如果STA在40MHz信道上操作，并且辅助20信道被指示为繁忙，则传输将在主20信道上发生。

更高级别的MAC函数在一组其他C++类中实现，并处理：

• 数据包碎片化和碎片整理
• RTS/CTS协议的使用
• 速率控制算法
• 与接入点的连接和断开
• MAC传输队列
• 信标生成
• MSDU聚合

Frame Exchange Managers

随着IEEE 802.11标准的发展，越来越多的特征被添加，并且越来越难以由单个组件来处理所有允许的帧交换序列。引入了FrameExchangeManager类的层次结构，以使代码干净且可扩展，同时避免代码重复。每个FrameExchangeManager类都处理由给定修改引入的帧交换序列。FrameExchangeManager层次结构如图FrameExchangeManager层级结构所示。

MAC queues

每个EDCA功能（在QoS站上）和DCF（在非QoS站上的）具有它们自己的MAC队列（WifiMacQueue类的实例），以存储从上层接收并等待传输的分组。在QoS站上，每个接收到的分组基于套接字优先级被分配一个用户优先级（例如，参见wifi multi-tos或wifi mac ofdma示例），该优先级确定处理分组的接入类别。默认情况下，wifi MAC队列支持流量控制，因此，如果相应的MAC队列中没有数据包的空间，上层就不会向下转发数据包。数据包一直保留在wifi MAC队列中，直到它们被确认或丢弃。数据包可能会被丢弃，因为例如，它的寿命已过期（即，它在队列中停留的时间太长）或达到了最大重试次数。数据包的最大生存期可以通过WifiMacQueue的MaxDelay属性进行配置。有许多跟踪可用于跟踪数据包传输的结果（请参阅相应的doxygen文档）：

• WifiMac trace sources: AckedMpdu, NAckedMpdu, DroppedMpdu, MpduResponseTimeout, PsduResponseTimeout, PsduMapResponseTimeout
• WifiMacQueue trace source: Expired

在内部，wifi MAC队列由多个子队列组成，每个子队列存储给定类型的帧（即数据或管理），并具有给定的接收器地址和TID。对于单用户传输，下一个要服务的站点由wifi MAC队列调度器（由WifiMac实例持有）确定。wifi MAC队列调度器通过基类（WifiMacQueueScheduler）和定义特定调度策略的子类来实现。
默认调度器（FcfsWifiQueueScheduler）赋予管理帧比数据帧更高的优先级，并且以先到先得的方式服务数据帧。对于多用户传输（见下文），调度由多用户调度器执行，多用户调度器可以咨询也可以不咨询wifi MAC队列调度器，以识别要使用多用户DL或UL传输服务的站。

Ack manager

由于引入了IEEE 802.11e修正案，因此可以使用多个确认策略，这些确认策略在QoS数据帧的QoS控制字段中的Ack Policy子字段中进行编码（参见IEEE 802.11-2016标准的9.2.4.5.4节）。例如，A-MPDU可以用正常确认或隐式块确认请求策略来发送，在这种情况下，接收器根据A-MPDU包含单个MPDU还是多个MPDU来用正常确认或者块确认来回复，或者用块确认策略来回复，在这种情况下，接收器等待将来接收块确认请求，并用块确认来回应。

WifiAckManager是一个抽象基类，用于为多个ack管理器提供接口。目前，默认的ack管理器是WifiDefaultAckManager。

WifiDefaultAckManager

WifiDefaultAckManager允许根据其属性的值来确定要使用的确认策略：

• UseExplicitBar：用于确定在需要接收方响应且当前传输包括多个帧（a-MPDU）或之前传输的帧需要确认时使用的ack策略。如果此属性为true，则使用“阻止确认”策略。否则，将使用隐式阻止确认请求策略。
• BaThreshold：用于确定Block Ack协议的发起人何时需要向接收方请求响应。零值意味着在每次帧传输时都会请求响应。否则，非零值（小于或等于1）意味着在发送序列号与发送窗口的起始序列号相距至少BaThreshold乘以发送窗口大小的帧时请求响应。
• DlMuAckSequenceType：用于选择DL MU帧的确认序列（单用户格式的确认，通过作为单用户帧发送的MU-BAR触发帧的确认，或通过聚合到数据帧的MU-BAR触发帧的承认）。

Modifying Wifi model

修改默认的wifi型号是进行研究时的常见任务之一。我们在本节中概述了如何更改默认的wifi模式。根据您的目标，常见任务有（没有特定顺序）：

• 通过更改wifi mac报头来创建或修改默认的Wi-Fi帧/报头。
• MAC低修改。例如，处理新的/修改的控制帧（想想RTS/CTS/ACK/Block ACK），对双向事务/四向事务进行更改。用户通常会对框架交换管理器.或其子类进行更改以实现这一点。控制帧的处理在FrameExchangeManager::ReceiveMpdu中执行。
• MAC高修改。例如，处理新的管理帧（想想信标/探测）、信标/探测生成。用户通常会对wifi mac.、“sta-wifi-mac.”、ap wifi mac.或ad-hoc wifi mac..进行更改以实现这一点。
• Wi-Fi队列管理。文件txop.和qos txop.对此任务感兴趣。
• 通道访问管理。用户应该修改文件通道访问管理器.*，该管理器授予对Txop和QosTxop的访问权限。
• 分段和RTS威胁由Wi-Fi远程站点管理器处理。请注意，Wi-Fi远程站管理器只是指示是否需要分段和RTS。分段由Txop或QosTxop处理，而RTS/CTS事务由FrameExchangeManager处理。
• 修改或创建新的速率控制算法可以通过创建新的Wi-Fi远程站管理器子类或修改现有的算法来完成。