ns3网络模拟器
NS3网络模拟器 官方教学视频
https://www.bilibili.com/video/av28452403
NS-3网络仿真平台搭建及可视化
https://blog.csdn.net/HuaCode/article/details/79767851?utm_source=blogxgwz8
LTE 测试文档（翻译）
Testing Documentation 翻译
（如有不当的地方，欢迎指正！）
1 概述
为了测试和验证 ns-3 LTE 模块，文档提供了几个 test suites （集成在 ns-3 测试框架中）。为了运行它们，可以按照以下方式配置仿真器的 buid：
$ ./waf configure --enable-tests --enable-modules=lte --enable-examples $ ./test.py
上述代码将不仅运行 LTE 模块的 test suites ，而且包括 LTE 模块依赖的所有 ns-3 模块。参见 ns-3 manual 了解更多有关测试框架的信息。
你可以使用下列方式得到一份更加详细的 HTML 格式的报告：
$ ./test.py -w results.html
使用下列命令单独运行每个 test suite：
$ ./test.py -s test-suite-name
详情使用 test.py ，参见 ns-3 manual 了解更多有关测试框架的信息。
2 描述 test suites
2.1 Unit Tests（单元测试）
2.1.1 下行的 SINR 计算
test suite lte-downlink-sinr 检查下行链路的 SINR 计算是否正确执行。下行链路的 SINR 计算分配给数据传输的每个 RB，通过将考虑基站（eNB）的目标信号功率除以噪声功率的和加上来自其他基站（干扰信号）在同一RB 上传输的功率：
一般来说，不同的信号可以活跃在不同的时间周期。 定义 chunk 作为任何两种类型的事件的时间间隔，要么在波形开始的地方，要么在波形结束的地方。换句话说，chunk 标识一段时间间隔，在该时间间隔内，活跃波形（active waveforms）的设置不会改变。 令 
表示通用的 chunk， 
为 chunk 的持续时间，
为 chunk 的 SINR ，使用上述等式计算。使用下公式列计算平均 SINR 
（用于 CQI 反馈报告）：
test suite 检查上述计算是否在仿真中正确执行。 测试向量通过 Octave 脚本（实现上述等式，重建若干随机传输的信号和干扰信号，模拟这样一个场景——用户试图从基站解码信号，与此同时面临来自其他基站的干扰）线下获得。如果计算值等于测试向量值且容忍为 
，则测试通过。 容忍旨在考虑典型浮点运算的近似误差。
2.1.2 上行的 SINR 计算
test suite lte-uplink-sinr 检查上行链路的 SINR 计算是否正确执行。 该 test suite 与上一节描述的 lte-downlink-sinr test suite 相同，区别是信号和干扰现在参考用户（UE）的传输，接收由基站执行。该 test suite 重建若干随机传输的信号和干扰信浩，模拟这样一个场景——基站试图同时从几个用户（与基站在同一个小区）中解码信号，与此同时面临来自其他用户（属于其他小区）的干扰。
测试向量通过专用的 Octave 脚本获得。如果计算值等于测试向量值且容忍为 ，则测试通过。对于下行 SINR 测试， 容忍旨在处理浮点运算的近似值。
2.1.3 E-UTRA Absolute Radio Frequency Channel Number (EARFCN，E-UTRA 绝对无线频道编号)
test suite lte-earfcn 检查类 LteSpectrumValueHelper （实现 LTE 频谱模型）使用的载波频率，按照 [TS36101] （定义EARFCN）完成。 该 test suite 的测试向量包括一系列 EARFCN 值，并且相应的载波频率是按照规范 [TS36101] 手工计算。如果 LteSpectrumValueHelper 返回的载波频率与测试向量中每个元素已知的相同，则测试成功。
2.2.1 Dedicated Bearer Deactivation Tests（专用承载去激活测试）
2.2 System Tests（系统测试）
test suite lte-test-deactivate-bearer 创建单个 EnodeB 和3个 UE 的情形。 每个 UE 包含一个默认的和一个专用的 EPS 承载，
Test Case Flow 如下： Attach UE -> Create Default+Dedicated Bearer -> Deactivate one of the Dedicated bearer
使用相同的承载规范，但是 ARP（地址解析协议） 不同。
测试例子进一步去激活（deactivates）专用无线承载（第一个用户（UE_ID=1）的承载 ID 2（LCID=BearerId+2））。通过使用 Simulator::Schedule () 方法，在特定的时延后，用户可以调度承载去激活。
一旦测试例子执行结束，它会创建 DlRlcStats.txt 和 UlRlcStats.txt。统计数据中需检查的关键字段有：
|Start | end | Cell ID | IMSI | RNTI | LCID | TxBytes | RxBytes |
测试例子分3个时期执行：
- 第一阶段 (0.04s-1.04s)，所有用户和相应承载 get attached ，且专用承载的数据包流激活。
- 第二阶段 (1.04s-2.04s)，实例化承载去激活，因此相比其他承载，用户在 UE_ID=1 和 LCID=4 会看到相对较少数目的 TxBytes 。
- 第三阶段 (2.04s-3.04s) ，既然 UE_ID=1 和 LCID=4 的承载去激活已经完成，用户将不会看到与 LCID=4 相关的任何日志。
测试通过，当且仅当：
- IMSI=1 且 LCID=4 在第三阶段完全移除
- 与 IMSI=1 和 LCID=4 相关的 TxBytes 和 RxBytes 无数据包可见
如果上述条件不匹配，则认为测试例子没有通过。
2.2.2 Adaptive Modulation and Coding Tests（自适应调制和编码测试）
test suite lte-link-adaptation 提供系统测试，重建单个基站和单个用户的场景。对于用户感知到的不同 SNR 值，会创建相应的不同的 test cases。 test 的目标是检查在每个 test case 中，选定的 MCS 符合一些已知的参考值。这些参考值通过重新实现 Octave （见 src/lte/test/reference/lte_amc.m ）中 Adaptive Modulation and Coding 这一节描述的模型来获得，用于计算频谱效率，并且通过手动查阅 [R1-081483] 中的表格确定相应的 MCS index 。 生成的测试向量见图 Test vector for Adaptive Modulation and Coding 。
仿真器使用的 MCS 通过获取由调度器在 4ms （考虑 CQI 报告中的初始时延，这是必要的）后产生的 tracing 输出来测量。仿真器计算的 SINR 也是通过使用 LteChunkProcessor 接口获取的。如果下列两种条件同时满足，则测试通过：
- 仿真器计算的 SINR 符合测试向量的 SNR ，绝对容忍为 ；
- 仿真器使用的 MCS index 完全符合测试向量中的 MCS index。
Test vector for Adaptive Modulation and Coding
2.2.3 Inter-cell Interference Tests（小区间干扰测试）
test suite lte-interference 提供系统测试，重建一个小区间干扰场景，有两个基站，每个基站有一个用户与其连接，在上行和下行链路同时采用自适应调制和编码（AMC）。图 Topology for the inter-cell interference test 描述了场景的拓扑结构。参数 
表示每个用户与它连接的基站之间的距离， 然而参数 
表示干扰距离。我们注意到，这样的场景拓扑导致上行和下行的干扰距离是相同的； 当然，感知到的实际干扰功率是不同的，原因是上行和下行频带不同的传播损耗。通过改变 和 参数，可以获得不同的 test cases 。
Topology for the inter-cell interference test
测试向量通过使用专用的 octave 脚本（ src/lte/test/reference/lte_link_budget_interference.m），计算每种 test case 拓扑对应的链路预算（包括干扰），输出作为结果的 SINR 和频谱效率。后者然后用于确定（与 Adaptive Modulation and Coding Tests 使用的过程相同）？注意到测试向量包含分别用于上行和下行的各自值。
2.2.4 UE Measurements Tests（用户测量测试）
test suite lte-ue-measurements 提供系统测试，重建的小区间干扰场景与 lte-interference test-suite 中定义的相同。然而，在该测试中，测试的数量通过 RSRP 和 RSRQ 测量值（通过把用户放入到堆栈的两个不同点）表示：source—— UE PHY layer， destination—— eNB RRC 。
测试向量通过使用专用的 octave 脚本（src/lte/test/reference/lte-ue-measurements.m）获得，计算每种 test case 拓扑对应的链路预算（包括干扰） ，输出作为结果的 RSRP 和 RSRQ 。 所得值然后用于检查物理层用户测量的正确性。 此后，它们必须根据 3GPP 格式转换，目的是用于检查它们在基站 RRC 级别的正确性。
2.2.5 UE measurement configuration tests（用户测量配置测试）
除了前面提及的 test suite，还存在3种其他 test suites 用于测试用户测量： lte-ue-measurements-piecewise-1、lte-ue-measurements-piecewise-2 和 lte-ue-measurements-handover。这些 test suites 更加关注上报触发过程，例如，这里已经验证了基于事件触发标准的实现的正确性。
更具体的说，测试验证了基站接收到的每个测量报告的 timing 和 content 。每种 test case 都是一个独立的 LTE 仿真，并且如果测量报告只在规定的时间发生且显示正确级别的 RSRP（ 此刻还没有验证 RSRQ ），则 test case 通过。
（1）Piecewise configuration（分段配置）
piecewise configuration 旨在测试特定的用户测量配置。仿真脚本将对用户（整个仿真中为活跃态）设置相应的测量配置。
既然参考值是通过手算预先算好的，我们做几个假设来简化仿真。 首先，信道只受路径损耗模型的影响（这种情况下，使用 Friis 模型）。 其次，使用理想的 RRC 协议，并且禁用 layer 3 filtering 。最后，用户使用预定义的运动模式——在4个不同的点间移动，如下图 UE movement trace throughout the simulation in piecewise configuration 。因此，可以更容易确定测量的 RSRP 的波动。
UE movement trace throughout the simulation in piecewise configuration
预定义的点之间的 “teleport” 背后的动机是引进 RSRP 水平的剧烈变化，这将确保进入触发或测试事件的离开条件触发。通过执行剧烈的变化，测试可以在更短的时间内运行。
下图 Measured RSRP trace of an example Event A1 test case in piecewise configuration 表示，在仿真期间使用 piecewise configuration，在物理层的 layer 1 过滤完后测量 RSRP。由于不能使用 layer 3 过滤，因此这些值是精确值（由用户 RRC 实例使用的 ），目的是用于估计上报触发过程。注意，这些值每 200 ms 会更新一次，其中 200 ms 是物理层测量报告的默认过滤周期。该图也表明，在仿真期间当 Event A1（服务小区比该阈值好） 实例的进入和离开条件发生时的时间。
Measured RSRP trace of an example Event A1 test case in piecewise configuration
每个报告标准使用不同的阈值/偏移参数测试几次。一些测试场景会考虑滞后现象（Hysteresis ）和 time-to-trigger 。下图 Measured RSRP trace of an example Event A1 with hysteresis test case in piecewise configuration 描述了另一个例子 Event A1 测试的滞后现象。
Measured RSRP trace of an example Event A1 with hysteresis test case in piecewise configuration
Piecewise configuration 用于用户测量的两种 test suites 。第一种是 lte-ue-measurements-piecewise-1，此后称为 Piecewise test #1，仿真一个用户和一个基站。另一种是 lte-ue-measurements-piecewise-2，仿真一个用户和两个基站。
Piecewise test #1 用于测试基于事件的标准，不依赖相邻小区的存在。 这些标准包括 Event A1 和 A2 。 在缺乏任何相邻小区的情况下，其余的事件也会进行简短地测试，用于确认它们是否正常工作（尽管没有上报任何东西。下表 UE measurements test scenarios using piecewise configuration #1 列举了 piecewise test #1 中测试的场景。
UE measurements test scenarios using piecewise configuration #1
| Test # | Reporting Criteria | Threshold/Offset | Hysteresis | Time-to-Trigger |
| 1 | Event A1 | Low | No | No |
| 2 | Event A1 | Normal | No | No |
| 3 | Event A1 | Normal | No | Short |
| 4 | Event A1 | Normal | No | Long |
| 5 | Event A1 | Normal | No | Super |
| 6 | Event A1 | Normal | Yes | No |
| 7 | Event A1 | High | No | No |
| 8 | Event A2 | Low | No | No |
| 9 | Event A2 | Normal | No | No |
| 10 | Event A2 | Normal | No | Short |
| 11 | Event A2 | Normal | No | Long |
| 12 | Event A2 | Normal | No | Super |
| 13 | Event A2 | Normal | Yes | No |
| 14 | Event A2 | High | No | No |
| 15 | Event A3 | Zero | No | No |
| 16 | Event A4 | Normal | No | No |
| 17 | Event A5 | Normal-Normal | No | No |
其他事件例如 Event A3、A4 和 A5 依赖相邻小区的测量值，因此它们会在 Piecewise test #2 中进行更加完整的测试。 仿真会把节点放置在一条直线上，并指示用户以一种与 Piecewise test #1 相似的方式进行 “jump” 。仿真中禁用切换，因此仿真期间服务小区和相邻小区的角色不会呼唤。下表 UE measurements test scenarios using piecewise configuration #2 列举了 Piecewise test #2 中测试的场景。
UE measurements test scenarios using piecewise configuration #2
| Test # | Reporting Criteria | Threshold/Offset | Hysteresis | Time-to-Trigger |
| 1 | Event A1 | Low | No | No |
| 2 | Event A1 | Normal | No | No |
| 3 | Event A1 | Normal | Yes | No |
| 4 | Event A1 | High | No | No |
| 5 | Event A2 | Low | No | No |
| 6 | Event A2 | Normal | No | No |
| 7 | Event A2 | Normal | Yes | No |
| 8 | Event A2 | High | No | No |
| 9 | Event A3 | Positive | No | No |
| 10 | Event A3 | Zero | No | No |
| 11 | Event A3 | Zero | No | Short |
| 12 | Event A3 | Zero | No | Super |
| 13 | Event A3 | Zero | Yes | No |
| 14 | Event A3 | Negative | No | No |
| 15 | Event A4 | Low | No | No |
| 16 | Event A4 | Normal | No | No |
| 17 | Event A4 | Normal | No | Short |
| 18 | Event A4 | Normal | No | Super |
| 19 | Event A4 | Normal | Yes | No |
| 20 | Event A4 | High | No | No |
| 21 | Event A5 | Low-Low | No | No |
| 22 | Event A5 | Low-Normal | No | No |
| 23 | Event A5 | Low-High | No | No |
| 24 | Event A5 | Normal-Low | No | No |
| 25 | Event A5 | Normal-Normal | No | No |
| 26 | Event A5 | Normal-Normal | No | Short |
| 27 | Event A5 | Normal-Normal | No | Super |
| 28 | Event A5 | Normal-Normal | Yes | No |
| 29 | Event A5 | Normal-High | No | No |
| 30 | Event A5 | High-Low | No | No |
| 31 | Event A5 | High-Normal | No | No |
| 32 | Event A5 | High-High | No | No |
注意测试的 time-to-trigger，它们使用 3 种不同的 time-to-trigger 值进行测试， short （短于报告间隔），long（短于过滤测量周期200 ms），和 super （长于 200 ms）。前两种值确保 time-to-trigger 估计总是使用从物理层接收到的最新测量报告。最后一种负责验证 time-to-trigger 取消，例如，当来自物理层的测量报告表明，在第一个触发器触发前，进入/离开条件不再为真。
（2）Handover configuration（切换配置）
切换配置的目的是验证在成功发生一次切换后用户测量配置是否正确更新。 基于此目的，仿真构造了使用不同用户测量配置的 2 个基站，并且用户将从一个小区切换到另一个小区。用户位于2个基站之间的一条直线上，切换通过手动调用。每个仿真的持续时间为 2 秒（特别是最后一种 test case），并且切换是在仿真进行到一半时进行精准触发。
lte-ue-measurements-handover test suite 涉及几种类型的配置差异。第一种是上报间隔的差异，例如第一个基站配置 480 ms 的上报间隔，第二个基站配置 240 ms 的上报间隔。因此，当用户执行切换到第二个小区时，新的上报间隔必须生效。如同在 piecewise configuration 中， 基站接收到的每种测量报告的 timing 和 content 将被验证。
test suite 涉及的其他类型的差异主要是事件和阈值/偏移的差别。下表 UE measurements test scenarios using handover configuration 列举了测试场景。
UE measurements test scenarios using handover configuration
| Test # | Test Subject | Initial Configuration | Post-Handover Configuration |
| 1 | Report interval | 480 ms | 240 ms |
| 2 | Report interval | 120 ms | 640 ms |
| 3 | Event | Event A1 | Event A2 |
| 4 | Event | Event A2 | Event A1 |
| 5 | Event | Event A3 | Event A4 |
| 6 | Event | Event A4 | Event A3 |
| 7 | Event | Event A2 | Event A3 |
| 8 | Event | Event A3 | Event A2 |
| 9 | Event | Event A4 | Event A5 |
| 10 | Event | Event A5 | Event A4 |
| 11 | Threshold/offset | RSRP range 52 (Event A1) | RSRP range 56 (Event A1) |
| 12 | Threshold/offset | RSRP range 52 (Event A2) | RSRP range 56 (Event A2) |
| 13 | Threshold/offset | A3 offset -30 (Event A3) | A3 offset +30 (Event A3) |
| 14 | Threshold/offset | RSRP range 52 (Event A4) | RSRP range 56 (Event A4) |
| 15 | Threshold/offset | RSRP range 52-52 (Event A5) | RSRP range 56-56 (Event A5) |
| 16 | Time-to-trigger | 1024 ms | 100 ms |
| 17 | Time-to-trigger | 1024 ms | 640 ms |
2.2.6 Round Robin scheduler performance（RR调度器性能）
test suite lte-rr-ff-mac-scheduler 创建不同的 test case ，单个基站和几个 用户，全都拥有相同的无线承载规范。在每种 test case 中， 用户从基站获得相同的 SINR ；不同的 test cases 通过用户和基站间不同的距离（例如，因此有不同的 SINR 值）和不同的 用户数目来实现。测试包含检查用户间获得的吞吐量性能是否相等， 和根据感知的 SINR 匹配参考吞吐量值是否在给定容忍范围内。
测试向量根据传输块（ 见 table 7.1.7.2.1-1 of [TS36213]）的值获得，考虑用户间物理资源块的均匀分布，使用 Resource Allocation Type 0 ，定义在 Section 7.1.6.1 of [TS36213]。
令 
为 TTI 持续时间，
为用户数目，
为传输带宽（配置为RBs的数目），
为 RBG 大小，
为在给定 SINR 下使用的调制和编码方式， 
为传输块大小，单位为比特，定义在 3GPP TS 36.213。
我们首先计算分配给每个用户的 RBGs 数目 
：
每个用户实现的参考吞吐量 
（单位为 bit/s） 计算公式如下：
如果测量的吞吐量匹配参考吞吐量，相对容忍为 0.1，则测试通过。该容忍需要考虑仿真开始时的瞬时动态（例如，CQI 反馈只在几个子帧后可用），以及在选定仿真时间 （0.4s）平均吞吐性能的估计函数的精确度。仿真时间的选择通过遵循 ns-3 指南调整，保持测试 suite 总的执行时间低，尽管有大量测试情形。在任何情况下，注意，当仿真运行时间越长，可以使用的容忍值会越低。
在图 fig-lenaThrTestCase1 中，曲线标记为 “RR” 表示用于计算 RR 调度器测试的测试值，在每个测试情形中都是用户数目和 MCS 索引的函数。
Test vectors for the RR and PF Scheduler in the downlink in a scenario where all UEs use the same MCS
2.2.7 Proportional Fair scheduler performance（PF 调度器性能）
test suite lte-pf-ff-mac-scheduler 使用 PF 调度器创建不同的 test case ，1 个基站和几个用户，全都拥有相同的无线承载规范 。 test case 分为两类，目的是从两方面估计性能，一个是对信道条件的适应性，另一个是从公平性的角度。
在第一类 test case 中，用户全都放置在距离基站相同的位置，目的是具有相同的 SINR。不同的测试例子通过使用不同的 SINR 值和不同数目的用户来实现。测试包括检查得到的吞吐性能是否匹配已知的参考吞吐量和达到给定容忍。当所有用户具有相同SNR 时，PF 调度器期望当使用所有资源时，每个用户能得到相同比例的吞吐量。估计参考吞吐量值——通过在给定 SNR，除以用户总数，划分为单个用户可实现的吞吐量。
令 为 TTI 持续时间， 为传输带宽（配置为RBs的数目）， 为给定 SINR 下的调制和编码方式， 为传输块大小， 每个用户实现的参考吞吐量 （bit/s）计算为
图 fig-lenaThrTestCase1 中标记为“PF”的曲线表示计算的第一类的PF调度器的测试值。
第二类 test case 目的是在一个更加实际的仿真场景（其中用户具有不同的 SINR，整个仿真中是常数）验证 PF 调度器的公平性。 在这些条件下， PF 调度器将给每个用户分配一份系统带宽（与一个用户可实现的能力成比例，考虑其 SINR ）。具体地，令 
为每个用户使用的调制编码方式(它是用户的SINR的确定性函数，因此在场景中已知)。基于MCS，我们可以确定每个用户 
的可实现率 
。然后定义每个用户的可实现率比 
：
现在令 
为用户实际实现的吞吐量，作为仿真输出的一部分。定义用户得到的吞吐率 
为：
测试包含检查下来条件是否得到验证：
如果得到验证，根据理论，说明在整个仿真过程中，每个用户获得的吞吐量匹配 PF 调度器期望的稳态吞吐量。 该测试可以参见 [Holtzman2000] 。从 [Holtzman2000] 的第三节中，我们可以发现
其中 
是常数。通过代入上面的定义 
，我们得到
这正是测试中使用的表示。
图 Throughput ratio evaluation for the PF scheduler in a scenario where the UEs have MCS index 表明测试中得到的结果，其中UEs 
位于距离基站不同的位置，它们使用的 MCS 索引分别为 28，24，16，12，6 。从图中我们可以发现，正如预期的，所得吞吐量与可实现率成比例。换句话说，MCS 索引越大的用户得到的调度资源越多 。
Throughput ratio evaluation for the PF scheduler in a scenario where the UEs have MCS index
2.2.8 Maximum Throughput scheduler performance（MT调度器性能）
test suites lte-fdmt-ff-mac-scheduler 和 lte-tdmt-ff-mac-scheduler 创建不同的 test cases ，一个基站和几个用户，全都有相同的无线承载规范，分别使用 Frequency Domain Maximum Throughput (FDMT，频域最大吞吐量) 调度器和 Time Domain Maximum Throughput (TDMT，时域最大吞吐量) 调度器。换句话说，用户全都放置在距离基站相同的位置，目的是让所有用户都具有相同的 SNR。 不同的 test cases 通过使用不同的 SNR 值和不同的用户数目来实现。测试包括检查给定容忍值下，所得吞吐量是否匹配已知的参考吞吐量。 FDMT 和 TDMT 调度器预期的行为是，当所有用户具有相同的 SNR 时，调度器分配所有的 RBGs 给第一个用户（定义在脚本中）。原因是，当存在多个用户同时有相同的 SNR 值时，当前的 FDMT 和 TDMT 实现总是选择服务第一个用户。我们通过单个用户在给定 SNR 可实现的吞吐量来计算第一个用户的参考吞吐量值，而其他用户的参考吞吐量值为0 。 令 为 TTI 间隔， 为传输带宽（配置为 RBs 的数目）， 为给定 SNR 下的调制和编码方式， 为传输块大小（定义在[TS36213] 中）。每个用户的参考吞吐量 （ bit/s） 计算方式如下：
2.2.9 Throughput to Average scheduler performance（TTA调度器性能）
test suites lte-tta-ff-mac-scheduler 创建不同的 test cases ，一个基站和几个用户， 使用 TTA 调度器，全都具有相同的无线承载规范。 TTA test case 的网络拓扑和配置与 MT 调度器的测试一样，还需要开发更多复杂的 test case 来表明 TTA 调度器的公平性特征。
2.2.10 Blind Average Throughput scheduler performance（有的地方写的是 Blind Equal Throughput ，简写为BET，一个意思）
Test suites lte-tdbet-ff-mac-scheduler 和 lte-fdbet-ff-mac-scheduler 创建不同的 test cases ，使用一个基站和几个用户，全都具有相同的无线承载规范。
在 lte-tdbet-ff-mac-scheduler 和 lte-fdbet-ff-mac-scheduler 的第一种 test case 中，用户全都放置在距离基站相同的位置，其目的是目的是让所有用户都具有相同的 SNR。 不同的 test cases 通过使用不同的 SNR 值和不同的用户数目来实现。 测试包括检查给定容忍值下，所得吞吐量是否匹配已知的参考吞吐量。 当所有用户具有相同的 SNR 时， TD-BET 和 FD-BET 预期的行为是每个用户应获得相同的吞吐量。然而，在该 test case 中，TD-BET 和 FD-BET 的准确吞吐量值并不相同。
当所有用户具有相同的 SNR 时，TD-BET 可以看作 PF 的一种特殊情形，其可实现率等于 1。因此，TD-BET 获得的吞吐量等于 PF 的吞吐量。另一方面，当所有用户具有相同的 SNR 以及用户（或 RBG）数目为 RBG（或用户）数目的整数倍时，FD-BET 与 round robin （RR） 调度器的实现过程非常相似。这种情况下，FD-BET 总是给每个用户分配相同数目的 RBGs。例如，如果基站有 12 个RBGs ，并且有6个用户，那么每个用户在每个 TTI 获得 2 个 RBGs。或者，如果基站有 12 个 RBGs ，并且有 24 个用户，那么每个用户每隔2个TTIs 可以获得 2 个 RBGs 。当用户 （RBG）的数目不是 RBG （UE）数目的整数倍时，FD-BET 将不再遵循 RR 的行为，因为它将给一些用户分配不同数目的 RBGs ，虽然每个用户的吞吐量仍然一样。
第二种类别的测试旨在在一个更加实际的仿真场景中验证 TD-BET 和 FD-BET 调度器的公平性，其中用户有不同的 SNR （整个仿真期间为常数）。这种情况下，两个调度器都应该给每个用户分配相同数量的平均吞吐量。
特别地， 对于 TD-BET，令 
为整个仿真时间内分配给用户 i 的时间片段，
为用户 i 的整个带宽可实现率，
为用户 i 可实现的吞吐量。然后我们可以得到：
TD-BET 中，所有用户的 和加起来为 1 。从长远来看，所有用户具有相同，因此我们可以通过来替换，这样我们可以得到下列式子：
2.2.11 Token Band Fair Queue scheduler performance（TBFQ 调度器性能）
test suites lte-fdtbfq-ff-mac-scheduler 和 lte-tdtbfq-ff-mac-scheduler 创建不同的 test cases ，测试 TBFQ 调度器的3个关键特质： traffic policing（流量策略）、 fairness（公平性） 和 traffic balance（业务均衡） 。常数比特率 UDP 业务用于所有 test cases 中的上行和下行链路。数据包间隔设置为 1ms 用于保持 RLC 缓存 non-empty 。不同的业务率通过设置不同的数据包大小实现。特别地， test suites 中创建了两类 flows ：
- Homogeneous flow: 具有相同 token generation rate（令牌产生率） 和 packet arrival rate（数据包到达率）的 flows
- Heterogeneous flow: 具有不同数据包到达率但相同令牌产生率的flows
test case 1 验证 traffic policing 和 fairness 特征，用于场景——所有用户放置在距基站相同距离的位置。这种情况下，所有用户具有相同的 SNR 值。不同的 test cases 通过使用不同的 SNR 值和不同的用户数目来部署。因为每个 flow 具有相同的业务速率 （traffic rate ）和令牌产生率，TBFQ 调度器将在用户间产生相同的吞吐量，没有令牌产生率这一约束条件。此外，用户吞吐量的精确值依赖于 total traffic rate ：
- If total traffic rate <= maximum throughput, UE throughput = traffic rate
- If total traffic rate > maximum throughput, UE throughput = maximum throughput / N
其中，N 表示连接到基站的用户数目。这种情况下的最大吞吐量等于把所有 RBs 分配给一个用户的速率（例如，当距离为0 时，最大吞吐量为 2196000 byte/sec ）。当 业务速率小于最大带宽时， TBFQ 可以通过令牌产生率监督（police ）业务，这样用户吞吐量可以等于实际的业务速率（令牌产生率设置为业务产生速率）；在另一方面，当总的业务速率大于最大吞吐量时，基站不能转发所有业务给用户。因此，在每个 TTI ， 由于大的数据包缓存在 RLC buffer 中，TBFQ 将给一个用户分配所有 RBGs。在当前 TTI ，当一个用户被调度时，它的令牌计数器会减少，这样在下一个 TTI 该用户就不会被调度。 因为每个用户具有相同的业务产生率，TBFQ 将轮流服务每个用户，并且每个 TTI 只服务一个用户（ TD TBFQ 和 FD TBFQ ）。因此，第二种条件下的用户吞吐量等于最大吞吐量的均匀份额（evenly share）。
test case 2 验证流量策略和公平性特征，场景为——用户放置在距基站不同距离的位置。在该场景下，每个用户具有不同的 SNR 值。 与 test case 1 相似的是， test case 2 中的用户吞吐量也依赖于总的业务速率，但是最大吞吐量不同。假定所有的用户具有高的业务负载。 然后业务将使得基站的 RLC 缓存饱和。在每个 TTI ，在使用最高指标选择完一个用户后， 由于大的 RLC 缓存区大小，TBFQ 将给该用户分配所有 RBGs。另一方面，一旦 RLC 缓存饱和，所有用户总的吞吐量就不能再增加了。此外，正如我们在 test case 1 中讨论的， 对于 homogeneous flows （具有相同 t_i 和 r_i），从长远看来，每个用户将实现相同的吞吐量。因此，我们可以使用和 TD BET 中相同的方法计算最大吞吐量：
其中，
表示最大吞吐量，
表示用户 i 的整个带宽可实现率 。
表示用户数目。
当所有业务速率大于 时，用户吞吐量等于 
。否则，用户吞吐量等于其业务产生速率。
test case 3 中会创建具有不同的业务速率的 3 种 flows。每个 flow的 令牌产生率相同且等于 3 种 flows 的平均业务速率。因为 TBFQ 使用一个共享的 token bank ，有着更低业务负载的用户贡献的令牌可以由具有更高业务负载的用户使用。 用这种方法，TBFQ 可以保证每个流的业务速率。虽然我们这里使用 heterogeneous flow ，最大吞吐量的计算与 test case 2 中的一样。在计算 test case 2 的最大吞吐量时，我们假定所有用户都可以承受高的业务负载，这样调度器总是在每个 TTI 给一个用户所分配有的 RBGs 。该假设在 heterogeneous flow 的情况下也是对的。换句话说， 是否这些流具有相同的业务速率和令牌产生率，是否它们的业务速率足够大，TBFQ 与 test case 2 中的 TBFQ 执行情况一样。因此， test case 3 的最大带宽与 test case 2 中的最大带宽相同。
在 test case 3 的一些 flows 中，尽管所有的 flows 为固定比特率（CBR，Constant Bit Rate）业务，令牌产生率不等于最大比特率（ MBR，Maximum Bit Rate） 。这不符合我们的参数设置规则。实际上业务均衡特征使用在可变比特率（VBR，Variable Bit Rate） 业务中。因为不同用户的峰值速率可能发生在不同时间，TBFQ 使用共享的 token bank 来平衡这些 VBR 业务。 Test case 3 使用 CBR 业务来验证这一特点。但是在实际仿真中，推荐设置令牌产生率为 MBR 。
2.2.12 Priority Set scheduler performance（PSS性能）
test suites lte-pss-ff-mac-scheduler 使用单个基站和几个用户创建不同的 test cases 。 在所有的 test cases 中，我们选择 FD 调度器中的 PFsch。相同的测试结果也可以通过使用 CoItA 调度器实现。此外，所有的 test cases 并么有定义 nMux ，因此，PSS 中的 TD 调度器将总是选择总用户数的一半。
在 lte-pss-ff-mac-scheduler 的第一类test case 中，用户全都放置在距基站相同距离的位置上，这种情况下，所有用户具有相同的 SNR 值。不同的 test cases 通过使用不同的 TBR （用于每个用户）来实现。在每种 test case 中，所有用户全都具有相同的目标比特率（TBR，Target Bit Rate），TBR 由 EPS 承载设置中的 GBR （保证比特率）配置。如果总的流速（flow rate）低于最大吞吐量，PSS 预期的行为是保证每个用户的吞吐量至少等于其 TBR 。与 TBFQ 相似，这种情况下的最大吞吐量等于所有 RBGs 分配给一个用户的速率。当业务速率小于最大带宽时，用户吞吐量等于其实际的业务速率；另一方面，用户吞吐量等于最大吞吐量的 evenly share。
在第一类 test case 中，每个用户具有相同的 SNR 。 因此， PF 调度器由历史平均吞吐量 
确定，因为在 PFsch（CoItA）中每个用户具有相同的可实现吞吐量 
（ 
） 。这意味着，PSS 将与 TD-BET 一样，在每个 TTI 给一个用户分配所有的 RBGs 。然后，用户吞吐量的最大值等于所有 RBGs 分配给该用户的可实现率。
在 lte-pss-ff-mac-scheduler 的第二类 test case 中，用户全都放置在距基站相同距离的位置上，这种情况下，所有用户具有相同的 SNR 值。 每个用户被分配不同的 TBR 值。这种情况下也存在一个最大吞吐量。一旦总的业务速率大于该阈值，一些用户将不能实现它们的 TBR 。因为没有衰落，每个 RBGs 频率的 subband CQIs 是一样的。因此，在 FD 调度器值，每隔 TTI ， 所有 RBGs 的用户优先级指标全都是相同的。这意味着 FD 调度器总是给一个用户分配所有 RBGs。因此，在最大吞吐量的情况下， PSS 与 TD-BET 很类似，然后我们有：
其中，
表示最大吞吐量。
表示用户 i 的整个带宽可实现率 。
表示用户数目。
2.2.13 Channel and QoS aware scheduler performance（CQA调度器性能）
当 GBR flows 对时延不敏感，通过测量，如果在 RLC 层的可实现吞吐量接近 TBR 时，那么测试 CQA 调度器性能的方式与测试 PSS 性能的方式相似。有了这一点， CQA 调度的性能测试使用与 lte-pss-ff-mac-scheduler 相同的 test case 。此外，在, [Bbojovic2014] 中，当 GBR flows 对时延敏感、考虑不同的 QoE （体验质量）指标时，可以找到 CQA 调度器的性能估计。
2.2.14 Building Propagation Loss Model（建立传播损耗模型）
系统测试的目标是验证 LTE 模块中 BuildingPathlossModel 的集成。 该测试利用 3 个预计算的损耗的集合来生成预期的 SINR （在接收端统计传输功率和噪声功率）。然后将这些 SINR 值与 LTE 仿真（使用 BuildingPathlossModel ）所得结果进行比较。参考损耗值通过使用 Octave 脚本（/test/reference/lte_pathloss.m）离线计算。如果参考损耗值等于仿真器计算的值，且容忍为 0.001 dB（考虑计算中的数值误差）， 则每种 test case 通过。
2.2.15 Physical Error Model（物理误差模型）
test suite lte-phy-error-model 生成不同的 test cases ，用于估计数据和控制误差模型。对于所关心的数据，测试包含 6 种 test cases ，单个基站和不同数目的用户，全都有相同的无线承载规范。每种测试是专门为估计特定 TB 大小感知到的误差率而设计的，目的是根据生成用于 CB （Coding Block，码块）大小（模拟 TB 大小）的 BLER ，验证误差率对应预期的值。这意味着，例如，通过收集用户（用户根据与基站之间的距离，被迫生成这样一个 TB 大小）的性能，测试将检查一个TB（大小为 
bits）的性能类似于一个CB （大小为 bits ）。 为了在 MAC 级别有效地测试 BLER ，我们配置自适应调制和编码（AMC ，Adaptive Modulation and Coding ） 模块，即 LteAmc 类，通过使用 PiroEW2010 AMC 模型使得它相对信道条件来说不那么健壮，并且考虑目标 BER 0.03（不是默认值 0.00005）来配置选择 MCS。 我们注意到，这些值不会反映实际的 BER， 因为它们来自 analytical bound（并不会考虑所有的 transmission chain 方面）； 因此，BER 和 BLER 实际上在有经验地接收 TB 方面一般来说是不同的。
6 种 test cases的参数报告如下：
- 4 UEs 放置在距离基站 1800 米的距离，意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小为 256 bits，轮流产生值为 0.33 的 BLER （见图 BLER for tests 1, 2, 3. 中的点 A）。
- 2 UEs 放置在距离基站 1800 米的距离， 意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小为 528 bits， 轮流产生值为 0.11 的 BLER （见图 BLER for tests 1, 2, 3 中的点 B）。
- 1 UE 放置在距离基站 1800 米的距离， 意味着使用 MCS 2 (SINR of -5.51 dB) 且TB 大小为 1088 bits， 轮流产生值为 0.02 的 BLER （见图 BLER for tests 1, 2, 3 中的点 C）。
- 1 UE 放置在距离基站 600 米的距离，意味着使用 MCS 12 (SINR of 4.43 dB) 且TB 大小为 4800 bits， 轮流产生值为 0.3 的 BLER （见图 BLER for tests 4, 5. 中的点 D）。
- 3 UEs 放置在距离基站 600 米的距离，意味着使用 MCS 12 (SINR of 4.43 dB) 且TB 大小为 1632 bits， 轮流产生值为 0.55 的 BLER （见图 BLER for tests 4, 5. 中的点 E）。
- 1 UE 放置在距离基站 470 米的距离，意味着使用 MCS 16 (SINR of 8.48 dB) 且TB 大小为 7272 bits（分段为 2 个码块，分别为 3648 和 3584 bits）， 轮流产生值为 0.14 的 BLER ，因为每个 CB 的 CBLER 等于0.075 （见图 BLER for tests 6 中的点 F）。
BLER for tests 1, 2, 3
BLER for tests 4, 5
BLER for test 6
测试条件验证，在每一个 test case 中，预期正确接收的数据包数符合伯努利分布（置信区间为 99%），其中每个 trail 的成功概率为 
，且 
为发送数据包的总数目。
PCFICH-PDCCH 信道的误差模型包含 4 种 test cases ，场景为1个用户和几个基站，其中用户只连接到一个基站，剩余的基站作为干扰对象。 数据的误差是禁用的，目的是验证由于错误解码 PCFICH-PDCCH 引起的误差。如前所示，系统被迫以一种不那么保守的方式在 AMC 模块中工作，用于正确评价边界条件的结果。 4 种 tests cases 的参数报告如下：
- 2 eNBs 放置在距离用户 1078 米的距离，意味着使用 SINR 为 -2.00 dB ，且 TB 大小为 217 bits，轮流产生值为 0.007 的 BLER 。
- 3 eNBs 放置在距离用户 1040 米的距离，意味着使用 SINR 为 -4.00 dB ，且 TB 大小为 217 bits，轮流产生值为 0.045 的 BLER 。
- 4 eNBs 放置在距离用户 1250 米的距离，意味着使用 SINR 为 -6.00 dB ，且 TB 大小为 133 bits，轮流产生值为 0.206 的 BLER 。
- 5 eNBs 放置在距离用户 1260 米的距离，意味着使用 SINR 为 -7.00 dB ，且 TB 大小为 81 bits，轮流产生值为 0.343 的 BLER 。
测试条件验证了在每种 test case 中，预期正确接收的数据包数目符号伯努利分布（置信区间为 99.8%），其中每个 trail 的成功概率为 ，且 为发送数据包的总数目。 更大的置信区间是由于量化 MI 和误差曲线可能产生的误差。
2.2.16 HARQ Model
test suite lte-harq 包含两种测试，用于估计 HARQ 模型和误差模型的相关扩展。测试包含检查仿真期间接收到的字节数是否符合根据传输块值和 HARQ 动态值所得的预期值。具体地，测试检查 HARQ 重传后的所得吞吐量是否为预期值。为了估计预期的吞吐量，先根据下列式子估计预期的 TB 传递时间：
其中，
为在第 
（例如3GPP命名的 RV）次尝试成功接收HARQ块的概率。根据场景，在测试中我们总是使 
等于 0.0，而 
的值会在两种测试中变化，具体地：
预期的吞吐量通过计算仿真中可用的传输时隙的的数目（例如 TTIs 的数目）和仿真中 TB 的大小，具体地：
其中，
为 1 秒内 TTIs 的数目。测试可以进行在 RR 调度器和 PF 调度器中。如果测量的吞吐量匹配参考吞吐量且相对容忍为 0.1，则测试通过。该容忍需要考虑仿真开始时的瞬时行为和仿真结束时的 on-fly blocks 。
2.2.17 MIMO Model
test suite lte-mimo 旨在验证系统性能的传输方式（Transmission Mode）和通过调度器接口切换的传输方式这两者的增益影响。 测试包含检查在某一个窗口时间（本例中为 0.1 秒）内接收的字节数是否符合根据 [TS36213] 的表格 7.1.7.2.1-1 记录的传输块大小所得的预期值，类似于调度器的测试执行过程。
测试可以进行在 RR 调度器和 PF 调度器中。如果测量的吞吐量匹配参考吞吐量且相对容忍为 0.1，则测试通过。该容忍需要考虑仿真开始时的瞬时行为和传输模式间的过渡阶段。
2.2.18 Antenna Model integration（天线模型集成）
test suite lte-antenna 检查天线模型是否正确集成在LTE 模型中。该 test suite 重建一个仿真场景，一个基站节点位于坐 (0,0,0) ，一个用户节点位于坐标 (x,y,0) 。基站节点配置为给定方向和波束宽度的 CosineAntennaModel 。相反，用户使用默认的 IsotropicAntennaModel 。测试检查接收的上行和下行功率，考虑天线增益的正确值（线下确定）；测试通过比较上行和下行的 SINR 、并检查两者是否符合参考值且容忍为 
（考虑数值误差）来实现。通过改变用户的坐标 x 和 y，以及基站的天线方向和波束宽度，可以提供不同的 test cases。
2.2.19 RLC
两种 test suites lte-rlc-um-transmitter 和 lte-rlc-am-transmitter 检查 UM RLC 和 AM RLC 实现是否正确进行。这两种 suites 通过测试 RLC 实例连接到特定的测试实体（在 MAC 和 PDCP 扮演重要角色）上， 分别实现 LteMacSapProvider 和 LteRlcSapUser 接口。提供不同的 test cases（例如，输入测试向量由一系列来自 MAC 和 PDCP 的原始调用组成）用于检查下列 cases 中的行为：
- one SDU, one PDU： MAC 通知一个传输机会（TX opportunity ） 导致创建 PDU （正好包含一个完整的SDU）；
- segmentation（分段）： MAC 通知多个传输机会（TX opportunity ），传输机会小于存储在传输缓存中的 SDU 大小，然后分段SDU，因此会生成多个 PDUs ；
- concatenation（串联）： MAC 通知一个传输机会（TX opportunity ），传输机会大于 SDU，因此多个 SDUs 串联到同一个 PDU中；
- buffer status report（缓存状态报告）：一系列来自 PDCP 层的新的 SDUs 通知与一系列传输机会通知交织在一起，目的是验证缓存状态报告过程是否正确。
在所有这些 cases 中， 输出测试向量由输入测试向量知识和预期行为知识手动确定。 这些测试向量专门用于 UM RLC 和 AM RLC（由于它们的不同 behavior）。如果被测试的RLC 实例触发的原语顺序恰好等于输出测试向量，则每种 test case 会通过。特别地，对于RLC实例发送的每个PDU，需要验证PDU 的大小和内容以检查它们与测试向量是否完全匹配。
AM RLC 实现的特点是有一个额外的 test suite， lte-rlc-am-e2e，在存在信道损耗的条件下测试 RLC PDUs 的正确重传。测试实例化一个 RLC AM 发射机和接收机，并根据固定的损耗概率干预随机丢包的信道。使用不同的 RngRun 值和不同的损耗概率值对不同的 test cases 进行实例化。如果在仿真结束时所有的 SDUs 正确传输给接收 RLC AM 实体的上层，则每个 test case 通过。
2.2.20 RRC
test suite lte-rrc 测试下列方面的正确功能：
- MAC 随机接入
- RRC 系统信息获取
- RRC 连接建立
- RRC 重配置
test suite 考虑一种类型的场景——4个基站排列在一个正方形布局的100米边界上。多个用户位于正方形对角线上的一个特定的点上，用户被要求连接到第一个基站上。每种 test case 实现该场景的一个实例，使用下列参数的特定值：
- 用户数目
- 每个用户上激活的数据无线承载的数目
- 第一个用户被要求开始连接到基站上的时间
- 开始连接用户 和用户 的时间间隔
； 用户 连接的时间因此由 
sdf 确定 - 用户在正方形对角线上的相对位置，其中值越大表示距离服务基站越远
- 布尔标识符表示是否使用理想的或实际的 RRC 协议模型
从用户开始连接到基站到经过时延 后，如果每个用户的测试条件被肯定地估计，那么测试通过。时延 由下式确定：
其中：
-
表示用于获取系统信息所必需的最大时延。设置它为 90ms ，10ms 用于获取 MIB ，80ms 用于获取随后的 SIB2 。
-
表示 MAC 随机接入过程的时延。这依赖前导码碰撞以及上行授权（UL grant）分配资源的可用性。由于缺乏足够的资源， 必要的 RA 尝试的总数依赖于前导码碰撞和分配上行确认的失败。碰撞次数依赖试图同时接入用户的数目；我们用 0.99 的 RA 成功概率来估计它，5次尝试足够多达 20 个用户，10 次尝试足够多达50个用户。对于 UL grant，考虑到系统带宽和默认的用于上行授权的 MCS （MCS 0） ，在一个TTI 至多只能分配 4 次上行授权；因此对于同时尝试执行随机接入的 
个用户来说，最大尝试数为 
（由于上行授权问题）。 随机接入尝试的时间由 LteEnbMac::RaResponseWindowSize 的值决定，为 3ms + ，默认的值为 3ms， 加上 1ms 用于新的传输调度。
表示传输 RRC CONNECTION SETUP + RRC CONNECTION SETUP COMPLETED 的时延。我们考虑往返时延 10ms ，考虑必须传输的 2 个 RRC 数据包和每个 TTI 至多可以传输 4 个这样的数据包，加上 
。在干扰很高的情况下，我们建议用户进行重试尝试，因此我们加倍 值，然后在它的上面再加上 
（因为超时（timeout）已经清零以前接收到的 SIB2）。
表示最终需要 RRC CONNECTION RECONFIGURATION 交易的时延。每个承载集合需要交易的数量为 1 。与 相似， 对于每次交易，考虑往返时延 10ms 加上 。时延为 20ms。
LteRrcConnectionEstablishmentTestCase 的基本版本用于测试缺乏信道误差情况下正确的 RRC 连接建立。对于每个用户，通过该 test case 要估计的条件为：
- 用户的 RRC 状态为 CONNECTED_NORMALLY
- 用于配置有基站的 CellId、DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
- 存储在基站的用户的 IMSI 是正确的
- 激活的数据无线承载的数目为预期值，包括基站和用户
- 对于每个数据无线承载，下列标识符在用户和基站之间相匹配：EPS bearer id、DRB id 和LCID
test variant LteRrcConnectionEstablishmentErrorTestCase 是相似的，除了在第一次连接尝试期间选择传输特定的 RRC 消息中存在误差外。误差通过临时移动用户到一个遥远的位置获得；移动的时间基于预期存在误差的消息，通过 test case 的每个实例经验性获得。在用户移回到原始位置之前，test case 检查下列条件至少有一个为假：
- 用户的 RRC 状态为 CONNECTED_NORMALLY
- 基站有用户的上下文（context ）
- 基站上用户 Context 的 RRC 状态为 CONNECTED_NORMALLY
此外，估计 LteRrcConnectionEstablishmentTestCase 的所有条件—— 它们预计为真，因为如果连接建立失败，NAS 会立即重新尝试连接。
2.2.21 Initial cell selection（初始小区选择）
test suite lte-cell-selection 负责验证 Initial Cell Selection 过程。该测试是一个小的网络仿真，使用 2 个 CSG（闭合用户组）小区和 2 个 non-CSG （非闭合用户组）小区。 几个静态用户然后放置在预定义的位置。用户不用连接到任何小区就可以进入任何仿真。初始小区选择为这些用户开启，因此每个用户将找到最合适的小区并自己连接到小区。
在仿真期间预定义的检查点时间（check point time），测试验证每个用户是否连接到合适的小区。并且，测试也会保证用户进行了正确地连接 ，例如，它的最终状态为 CONNECTED_NORMALLY。 下图 Sample result of cell selection test 描述了网络部署和预期的结果。当用户描述为具有 2 个成功的小区选择时（例如 UE #3 和 #4），则 test case 可以接收其中任何一个。
Sample result of cell selection test
上图表明 CSG 成员可以连接到 CSG 或 non-CSG 小区，并且只选择最强小区。 另一方面，非成员只能连接到 non-CSG 小区，即使当它们实际上接收了来自 CSG 小区的更强信号。
用于参考目的，下表 UE error rate in Initial Cell Selection test 表示当用户接收来自控制信道的传输时每个用户的误差率。基于此信息，UE #3 check point time 完成的时间比其他用户晚，用于补偿其失败的高风险。
UE error rate in Initial Cell Selection test
| UE # | Error rate |
| 1 | 0.00% |
| 2 | 1.44% |
| 3 | 12.39% |
| 4 | 0.33% |
| 5 | 0.00% |
| 6 | 0.00% |
该测试使用默认的 Friis 路径损耗模型，没有任何信道衰落模型。
2.2.22 GTP-U protocol
unit test suite epc-gtpu 检查 GTP-U 头部的编码和解码是否正确执行。测试使用一系列已知的值填充头部，在数据包中添加头部，然后从数据包中移除头部。一旦移除，GTP-U 头部的任何字段不能正确解码，则测试失败。 这是通过监测解码的值和已知的值而得到的。
2.2.23 S1-U interface
两种 test suites （epc-s1u-uplink 和 epc-s1u-downlink） 确保 S1-U 接口实现单独正确进行。这是通过创建一系列仿真场景实现的，其中只使用 EPC 模型，没有 LTE 模型（例如，没有 LTE 协议栈，LTE 协议栈由简单的 CSMA 设备替换）。这会在各种场景中检查多个基站中的多个 EpcEnbApplication 实例和 SGW/PGW 节点中的 EpcSgwPgwApplication 实例的交互性是否正确执行，场景包括变化的终端用户（安装有 CSMA 设备的节点）数目、基站数目和不同的业务模型（数据包大小和总的数据包数目）。每种 test case通过在网络（分别在上行或下行 test suite 的考虑的用户或远程主机）中注射选择的业务模型并检查接收端 （分别为远程主机或每个考虑的用户） 是否接收到完全相同的业务模型。如果用户监测到发射端和接收端的业务模型有任何不匹配，则测试失败。
2.2.24 TFT classifier
test suite epc-tft-classifier 单独检查 EpcTftClassifier 类是否执行正确。 这是通过创建不同的 classifier 实例实现的，其中不同的 TFT 实例是激活的，且测试每种 classifier（对一组异构的数据包进行正确分类，包括 IP 和 TCP/UDP 头部） 。提供了几种 test cases ，目的是检查用于上行和下行业务的 TFT（例如本地/远程 IP 地址，本地/远程端口）的不同匹配方面。每种 test case 对应一个特定的 classifier 实例，给定一组 TFTs 。 如果由classfier 返回的承载标识符精确匹配考虑的数据包的预期值，则 test case 通过。
2.2.25 End-to-end LTE-EPC data plane functionality（端到端 LTE-EPC 数据面功能）
test suite lte-epc-e2e-data 确保 LTE-EPC 数据面正确的端对端功能。对于该 suite 中的每种 test case ，使用下列特征创建一个完整的 LTE-EPC 仿真场景：
- 给定的基站数目
- 对于每个给定的基站，给定用户的数目
- 对于每个用户，给定激活的 EPS 承载的数目
- 对于每个激活的 EPS 承载，给定业务模型（将要传输的 UDP 数据包和数据包大小）
在随后的时间间隔，每种测试通过在上行和下行传输给定的业务模型实现。如果所有下列条件都满足，则测试通过：
- 对于每个激活的 EPS 承载，传输的和接收的业务模型（分别在上行的用户和远程主机，下行则相反）正好相同
- 对于每个激活的 EPS 承载 和每个方向（上行或下行），相应的无线承载实例上恰好是预期的数据包流数目
2.2.26 X2 handover
test suite lte-x2-handover 检查 X2 切换过程的正确功能。 测试的场景的拓扑结构为两个基站以一个 X2 接口相连接。每种 test case 是该场景的一个特定实例，由下列参数定义：
- 初始连接到第一个基站的用户数目
- 每个用户激活的 EPS 承载的数目
- 一系列将要触发的切换事件，其中每个事件定义为：+ 切换触发的开始时间 + 执行切换的用户的索引 + 源基站的索引 + 目标基站的索引
- 布尔型标识符，指示目标基站是否允许切换
- 布尔型标识符，指示是否使用理想的 RRC 协议而不是实际的 RRC 协议
- 使用的调度器的类型（RR 或 PF）
如果下列条件为真，则3 种 test case 通过：
- 在时间 0.06s ，测试 CheckConnected 验证每个用户是否连接到第一个基站。
- 对于切换列表中的每个事件：
- 在指定的事件开始时间，指定用户连接到指定源基站
- 在开始时间后的 0.1s ，指定用户连接到指定目标基站
- 在开始时间后的 0.6s ，对于每个激活的 EPS 承载，指定用户的上行和下行 sink 应用已经获得了许多字节，至少是相应的源应用传输的字节数的一半。
只有当下列条件满足时，才能肯定地估计条件 “UE is connected to eNB”：
- 基站有用户（通过用户RRC恢复得到的RNTI值标识）的上下文（context ）
- 用户在基站的 RRC 状态为 CONNECTED_NORMALLY
- 用户的 RRC 状态为 CONNECTED_NORMALLY
- 用户配置有基站的CellId、 DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
- 存储在基站中的用户的 IMSI 是正确的
- 激活的数据无线承载的数目是预期值，同时适用于基站和用户
- 对于每个数据无线承载，下列标识符在用户和基站之间是匹配的： EPS bearer id、 DRB id、LCID
2.2.27 Automatic X2 handover（自动 X2 切换）
test suite lte-x2-handover-measures 检查切换算法的正确功能。测试的场景的拓扑结构为——以 X2 接口连接的两个或三个或四个基站。基站位于 X 轴上，以直线排列。用户沿着 X 轴从相邻的一个基站移动到下一个基站。 每种 test case 是一个特定的实例，由下列参数定义：
- X轴上的基站数目
- 用户的基站数目
- 用户激活的EPS承载数目
- 一系列将要触发的 check point 事件，其中每个事件定义如下： + 第一个check point 事件的时间+ 最后一个 check point 事件的时间 + 两次 check point 事件之间的时间间隔 + 执行切换的用户的索引 + 用户必须连接的基站的索引
- 布尔型标识符，指示是否使用 UDP 业务而不是TCP 业务
- 使用的调度器类型
- 使用的切换算法的类型
- 布尔型标识符，指示是否默认允许切换
- 布尔型标识符，指示是否使用理想的 RRC 协议而不是实际的 RRC 协议
test suite 由很多 test cases 组成。实际上，它一直是ns-3中最耗时的 test suite 之一。 test cases 结合下列可变的参数一起运行：
- 基站的数目： 2, 3, 4；
- EPS 承载的数目： 0, 1, 2；
- RRC：理想的，实际的 （见 RRC protocol models）；
- MAC 调度器：RR ，PF （见 The FemtoForum MAC Scheduler Interface）；且
- 切换算法： A2-A4-RSRQ，最强小区（见 Handover algorithm）。
如果下列条件为真，则 test case 通过：
- 在时间 0.08s，测试 CheckConnected 验证每个用户是否连接到第一个基站
- 对于 check point 列表中的每一个事件：
- 在制定的 check point 时间，指定的用户连接到指定的基站
- 在 check point 后的 0.5s ，对于每个激活的 EPS 承载，用户的上行和下行 sink 应用已经获得了许多字节，至少是相应的源应用传输的字节数的一半。
只有当下列条件满足时，才能肯定地估计条件 “UE is connected to eNB”：
- 基站有用户（通过用户RRC恢复得到的RNTI值标识）的上下文（context ）
- 用户在基站的 RRC 状态为 CONNECTED_NORMALLY
- 用户的 RRC 状态为 CONNECTED_NORMALLY
- 用户配置有基站的CellId、 DlBandwidth、 UlBandwidth、DlEarfcn 和 UlEarfcn
- 存储在基站中的用户的 IMSI 是正确的
- 激活的数据无线承载的数目是预期值，同时适用于基站和用户
- 对于每个数据无线承载，下列标识符在用户和基站之间是匹配的： EPS bearer id、 DRB id、LCID
2.2.28 Handover delays（切换时延）
切换过程包含用户、源基站和目标基站之间在 RRC 协议和 X2 接口上几个消息的交换。test suite lte-handover-delay 验证该过程是否始终如一地花相同的时间。
test suite 将运行几个切换 test cases 。 每种 test case 是一个单独的仿真，特点为切换是在仿真特定的时间进行。例如，第一个 test case 的切换触发时间为 +0.100s，而第二个test case 的切换触发时间为 +0.101s。总共有 10 个test cases，每个测试LTE中不同的子帧。因此最后一个test case切换的时间为 +0.109s 。
test cases 中的仿真场景如下：
- 启用 EPC
- 2 个基站使用圆形的（各项同性的）天线，相隔 1000 米
- 1 个静态的用户恰好位于两个基站的中间
- 无应用安装
- 无信道衰落
- 默认的路径损耗模型（Friis）
- 0.300s 仿真持续时间
test case 运行如下。在仿真的开始，用户连接到第一个基站。然后在test case 指定的时间输入参数，切换请求将明确发送给第二个基站。 接着 test case 将记录开始时间，等待直到切换完成，然后记录完成时间。如果完成时间和开始时间之间的差小于预定义的阈值，那么测试通过。
在当前ns-3实现中，当使用理想的 RRC 协议模型时典型的切换时间为 4.2141 ms，当使用实际的 RRC 协议模型时，典型的切换时间为 19.9283 ms 。因此，test cases 使用 5 ms 和 20 ms 作为最大阈值。test suite 使用理想的 RRC 协议运行10 个 test cases ，使用实际的RRC协议运行 10 个 test cases 。关于这些模型更详细的信息参见节 RRC protocol models。
使用子帧作为主要测试参数的动机是，子帧索引是计算法 RA-RNTI（切换过程中由随机接入使用）的因素之一。 test cases 验证该计算，利用事实——当该计算被破坏时，切换将被推迟。 在默认的仿真配置中，因为一个破坏的RA-RNTI 计算通常为6 ms ，因此可以观察到切换时延。
2.2.29 Selection of target cell in handover algorithm（切换算法中的目标小区选择）
基站可以利用 Handover algorithm 在仿真期间自动创建切换策略。策略包括应该执行切换的用户和用户执行切换的地点目标小区。
test suite lte-handover-target 验证切换算法是否做出正确的决策，特别地，在选择正确的目标小区上。它由几个短的 test cases 组成，用于不同的网络拓扑（2×2 网格 和 3×2 网格） 以及切换算法的类型 （A2-A4-RSRQ 切换算法和最强小区切换算法）。
微蜂窝仿真环境中的每种 test case 使用下列参数：
- 启用 EPC
- 几个圆形的（各项同性的天线）微小区基站，使用矩形网格布局，每个相邻的点之间的距离为130 m
- 1 个静态用户，位于源小区附近且连接到源小区
- 没有控制信道误差模型control channel error model
- 无应用安装
- 无信道衰落
- 默认的路径损耗模型（Friis）
- 1s 仿真持续时间
为了触发切换， test case 在 +0.5s 仿真时间会“暂时关闭”源小区。下图 lte-handover-target test scenario in a 2×2 grid 说明了该过程。这是通过设置源小区的发射功率到一个非常低的值来实现的。 因此，切换算法注意到用户需要切换且几个相邻小区同时成为目标小区的候选者。
lte-handover-target test scenario in a 2×2 grid
当用户面临不止一个目标小区可选时，test case 会先验证切换算法然后选择一个合适的目标小区。
2.2.30 Downlink Power Control（下行功率控制）
test suite lte-downlink-power-control 使用3种不同的方式检查下行功率控制的正确性：
- LteDownlinkPowerControlSpectrumValue test case 检查 LteSpectrumValueHelper::CreateTxPowerSpectralDensity 是否正确创建了用于下行传输的功率谱密度（PSD）值。测试向量包含 EARFCN、系统带宽、发射功率、每个RB的发射功率、激活的RBs以及预期的发射功率谱密度（ TxPSD）。如果 LteSpectrumValueHelper::CreateTxPowerSpectralDensity 产生的 TxPSD 等于预期的 TxPSD，则测试通过。
- LteDownlinkPowerControlTestCase test case 会检查数据信道和控制信道之间发射功率的差是否等于配置的 PdschConfigDedicated::P_A 值。在用户 DownlinkSpectrumPhy 中，发射功率的控制信道通过添加到 RsPowerChunkProcessor 列表中的 LteTestSinrChunkProcessor 测量。数据信道的发射功率以一种相似的方式测量，但是必须实现。现在，在用户 DownlinkSpectrumPhy 中， LteTestSinrChunkProcessor 被添加到 DataPowerChunkProcessor 列表中。 测试向量包含一系列所有可用的 P_A 值。如果功率差等于 P_A 值，则测试通过。
- LteDownlinkPowerControlRrcConnectionReconfiguration test case 检查 RrcConnectionReconfiguration 是否正确执行。当 FR 实体得到用户测量，它会立即调用函数改变该用户的 P_A 值，并且也触发连接到该事件的回调函数（callback）。 然后，测试检查是否用户获取到 RrcConnectionReconfiguration 消息（该消息触发回调函数）。最后，它会检查基站是否接收到 RrcConnectionReconfigurationCompleted 消息，该消息也会触发回调函数。如果所有事件都发生了，则测试通过。测试执行两次，一次使用 IdealRrcProtocol ，一次使用 RealRrcProtocol 。
2.2.31 Uplink Power Control Tests（上行功率控制测试）
用户使用上行功率控制自动改变上行物理信道的发射功率（Tx Power ）等级。发射功率的计算基于路径损耗、用于传输的 RB 数目，一些可配置的参数以及来自基站的 TPC 命令。
test suite lte-uplink-power-control 验证发射率是否正确被计算。如果计算正确，存在 3 种不同的 test cases：
- LteUplinkOpenLoopPowerControlTestCase test case 检查开环机制条件下的上行功率控制功能。 用户连接到基站并在下行和上行发射数据。启用使用开环机制的上行功率控制，且用户每隔 100 ms 改变一次位置。 trace 这些值，如果在每个用户位置的 PUSCH、PUCCH 和 SRS 的上行发射功率值等于预期的值，则测试通过。
- LteUplinkClosedLoopPowerControlAbsoluteModeTestCase test case 检查闭环机制（Closed Loop mechanism ）和绝对模式（Absolute Mode）条件下的上行功率控制功能。用户连接到基站且在上行和下行发送数据。启用闭环机制和绝对模式条件下的上行功率控制 。用户位于距离基站 100 m 的位置，且不会改变其位置。 LteFfrSimple 算法用于基站侧设置 DL-DCI 消息中的 TPC 值。基站中的 TPC 配置每隔 100 ms 改变一次。因此，每隔100 ms ，用户中的上行功率实体应计算所有上行信道的不同发射发射功率等级。trace 这些值，如果使用所有 TCP 值计算的 PUSCH、PUCCH 和 SRS 的上行发射功率的值等于预期的值，则测试通过。
- LteUplinkClosedLoopPowerControlAccumulatedModeTestCase test case 检查闭环机制和累积模式（Accumulative Mode）条件下的闭环上行功率控制功能。用户连接到基站，且在上行和下行传输数据。 启用闭环机制和累积模式条件下的上行功率控制 。 用户位于距基站 100 m 的位置，且不会改变其位置。 如同在上述 test case 中， LteFfrSimple 算法用于基站侧设置 DL-DCI 消息中的 TPC 值，但是在该 case 中，设置在 DL-DCI 中的 TPC 命令只配置了次数，且此后TPC设置为 1，累积模式下映射为 0（TS36.213 Table 5.1.1.1-2）。基站中的 TPC 配置每隔 100 ms 改变一次，用户累积这些值且基于累积的值计算所有上行信道的发射功率等级。如果计算的发射功率等级低于最小用户发射功率，用户应使用最小的发射功率传输。如果计算的发射功率高于最大的用户发射功率，则用户应使用最大的发射功率传输。 trace PUSCH、PUCCH 和 SRS 的发射功率等级，如果它们等于预期的值，则测试通过。
2.2.32 Frequency Reuse Algorithms（频率复用算法）
test suite lte-frequency-reuse 包含两种 test cases 。
第一种 test cases 根据频率复用算法策略检查是否正确使用 RBGs 。我们测试调度器是否只使用 FR 配置允许的 RBGs 。为了检查使用了哪些 RBGs ，连接 LteSimpleSpectrumPhy 到下行信道。 注意，当发生数据下行信道传输时，传递信号TxPsd 频谱值以检查哪些 RBs 用于传输。测试向量包含 Hard 和 Strict FR 算法（使用这种方式检查其他算法没有任何意义，因为它们使用整个小区带宽）的一系列配置。如果没有不允许使用 RBGs ，则测试通过。
第二种类型的 test cases 检查是否提供给用户合适的子频带和合适的发射功率。一个使用频率复用算法，另一个不使用。第二个基站负责在整个系统带宽生成干扰。由第一个基站提供服务的用户每隔几秒时间（相当慢，因为上报新的用户测量需要时间）会改变位置。为了检查该用户使用了哪些 RBGs ，连接 LteSimpleSpectrumPhy 到下行信道。注意，当出现小区１中数据下行信道传输时，传递信号 TxPsd 频谱值，以检查哪些 RBs 用于传输以及它们的功率等级。相同的方法可以应用到上行方向，且第二个 LteSimpleSpectrumPhy 连接到上行信道。如果由基站提供服务的用户 ，使用频率复用算法在上行和下行服务时具有预期的 RBs 和预期的功率等级，则测试通过。 测试向量包含 Strict FR、 Soft FR、Soft FFR 和 Enchanced FFR算法的一系列配置。每种 FR 算法使用所有的调度器进行测试，调度器支持 FR （例如， PF、PSS、CQA、TD-TBFQ 和 FD-TBFQ）。（Hard FR 并不使用用户测量，因此使用 Hard FR 执行该类型的测试将毫无意义。）
Distributed FFR 算法的 test case与上述非常相似，但是因为基站需要交换一些信息，因此需要考虑启用 EPC 和 X2 接口的场景。并且，两者基站都要使用 Distributed FFR 算法。在第一个小区中有两个用户，第二个小区中有一个用户。每个用户的位置是变化的（因为需要上报新的用户测量，所以相当慢），目的是从 Distributed FFR 算法实体中获取不同的计算结果。为了检查哪些 RBGs 用于用户传输，连接 LteSimpleSpectrumPhy 到下行信道。注意，当出现数据下行信道传输时，传递信号 TxPsd 频谱值，检查哪些RBs 用于传输以及它们的功率等级。同样的方法适用于上行方向，其次连接 LteSimpleSpectrumPhy 到上行信道。如果由小区２中的基站提供服务的用户 ，在上行和下行服务时具有预期的 RBs 和预期的功率等级，则测试通过。测试向量包含 Distributed FFR配置。 测试可以在所有的调度器中进行，其中调度器支持 FR （例如 PF、 PSS、 CQA、TD-TBFQ 和 FD-TBFQ）。
2.2.33 Inter-cell Interference with FR algorithms Tests（使用频率复用算法的小区间干扰测试）
test suite lte-interference-fr 与 lte-interference 非常相似。 拓扑 （图 Topology for the inter-cell interference test） 是一样的，并且测试检查干扰水平。 区别是，在该 test case 中，频率复用算法是可以启用的，并且我们在不同的 RBGs （不止一个） 上检查干扰水平。例如，当我们在基站上安装 Hard FR 算法时，前一半系统带宽分配给一个基站，后半部分系统带宽分配给第二个基站，相比传统的干扰场景，干扰水平应该更低。测试向量包含所有可用的频率复用算法的一系列配置。如果在特定 RBs 上计算的 SINR 等于从 Octave 脚本中获得的值，则测试通过。
参考文献：
https://www.nsnam.org/docs/models/html/lte-testing.html
分类: LTE, NS3