欢迎您访问 最编程 本站为您分享编程语言代码，编程技术文章！

热门搜索/Hot Search

您现在的位置是： 首页

LTE 测试指南（译文）

最编程 2024-07-22 16:37:51
...

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 上传输的功率：

\gamma = \frac{ P_\mathrm{signal} }{ P_\mathrm{noise} + \sum P_\mathrm{interference} }
 
 
一般来说，不同的信号可以活跃在不同的时间周期。 定义 chunk 作为任何两种类型的事件的时间间隔，要么在波形开始的地方，要么在波形结束的地方。换句话说，chunk 标识一段时间间隔，在该时间间隔内，活跃波形（active waveforms）的设置不会改变。  令  表示通用的 chunk，  为 chunk 的持续时间，T_i 为 chunk 的 SINR ，使用上述等式计算。使用下公式列计算平均 SINR\mathrm{SINR_i} （用于 CQI 反馈报告）：\overline{\gamma}i
 
 
\overline{\gamma} = \frac{ \sum_i {\gamma}_i T_i }{ \sum_i T_{i} }
test suite 检查上述计算是否在仿真中正确执行。 测试向量通过 Octave 脚本（实现上述等式，重建若干随机传输的信号和干扰信号，模拟这样一个场景——用户试图从基站解码信号，与此同时面临来自其他基站的干扰）线下获得。如果计算值等于测试向量值且容忍为  ，则测试通过。 容忍旨在考虑典型浮点运算的近似误差。10^{-7}
 
 

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 System Tests（系统测试）

2.2.1 Dedicated Bearer Deactivation Tests（专用承载去激活测试）

 
 test suite  lte-test-deactivate-bearer 创建单个 EnodeB 和3个 UE  的情形。 每个 UE 包含一个默认的和一个专用的 EPS 承载，使用相同的承载规范，但是 ARP（地址解析协议） 不同。
 
Test Case Flow 如下： Attach UE -> Create Default+Dedicated Bearer -> Deactivate one of the Dedicated bearer
 
测试例子进一步去激活（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个时期执行：
 
  1. 第一阶段 (0.04s-1.04s)，所有用户和相应承载 get attached ，且专用承载的数据包流激活。
  2. 第二阶段 (1.04s-2.04s)，实例化承载去激活，因此相比其他承载，用户在 UE_ID=1 和 LCID=4 会看到相对较少数目的 TxBytes 。
  3. 第三阶段 (2.04s-3.04s) ，既然 UE_ID=1 和 LCID=4 的承载去激活已经完成，用户将不会看到与 LCID=4 相关的任何日志。
 
测试通过，当且仅当：
 
  1. IMSI=1 且 LCID=4 在第三阶段完全移除
  2. 与 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 接口获取的。如果下列两种条件同时满足，则测试通过：
  1. 仿真器计算的 SINR 符合测试向量的 SNR ，绝对容忍为 ；
  2. 仿真器使用的 MCS  index 完全符合测试向量中的 MCS index。
_images/lte-mcs-index.png
 
  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 描述了场景的拓扑结构。参数  表示每个用户与它连接的基站之间的距离， 然而参数  表示干扰距离。我们注意到，这样的场景拓扑导致上行和下行的干扰距离是相同的； 当然，感知到的实际干扰功率是不同的，原因是上行和下行频带不同的传播损耗。通过改变 d_2 和 参数，可以获得不同的 test cases 。d_1
_images/lte-interference-test-scenario.png
 
 
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