cttc-nr-demo tutorial[译][1]

https://cttc-lena.gitlab.io/nr/cttc-nr-demo-tutorial.pdf
Version:Release 2.6

CHAPTER THREE

#overview

这是一个教程，重点介绍了在ns-3 nr模块的cttc-nr-demo的数据平面操作。本教程的目的是提供一个基本的NR示例的详细介绍，重点关注数据包遍历RAN时的典型生命周期。本教程指出了RAN模型中可能延迟或删除数据包的所有位置，以及如何跟踪这些事件。
本文档假定您已经使用nr模块安装了ns-3，并且您熟悉ns-3的工作原理。如果不是这种情况，请根据需要查看nr模块的自述文件、ns-3安装指南及其教程。还应该查看nr模块的入门页面。
本教程的配套内容是NR模块的详细手册，其中更详细地介绍了5G NR模块的每个组件的设计和测试。
要检查您是否准备好通过本教程，请首先检查您是否可以运行以下程序：

 ./ns3 run cttc-nr-demo

程序将会输出

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:1234) proto UDP
    Tx Packets: 6000
    Tx Bytes: 768000
    TxOffered: 10.240000 Mbps
    Rx Bytes: 767744
    Throughput: 10.236587 Mbps
    Mean delay: 0.271518 ms
    Mean jitter: 0.030006 ms
    Rx Packets: 5998
Flow 2 (1.0.0.2:49154 -> 7.0.0.3:1235) proto UDP
    Tx Packets: 6000
    Tx Bytes: 7680000
    TxOffered: 102.400000 Mbps
    Rx Bytes: 7671040
    Throughput: 102.280533 Mbps
    Mean delay: 0.835065 ms
    Mean jitter: 0.119991 ms
    Rx Packets: 5993
Mean flow throughput: 56.258560
Mean flow delay: 0.553292

本教程还广泛使用了ns-3日志框架。要检查ns-3库中是否启用了日志记录，请尝试以下命令，并检查是否输出了一些额外的详细输出：

NS_LOG="CttcNrDemo" ./ns3 run cttc-nr-demo

该命令应在屏幕上打印以下信息提示：

+0.000000000s -1 CttcNrDemo:main(): [INFO ] Creating 2 user terminals and 1 gNBs

可以观察到该消息附带了一些上下文信息。从左到右，消息还告诉我们生成该消息的模拟时间，节点ID，生成此类消息的对象和函数，以及日志级别。在某些情况下，节点ID可能为-1，因为此处的代码与模拟中的任何节点都是独立的。稍后您将发现，如果执行的代码取决于模拟中的哪个节点正在执行（例如，用于传输或接收某些数据包），此类数字将为正数。

#3.1项目概述

从中可以推断出，该演示程序模拟了两个下行流，每个流都依赖于单播和单向通信。这些流使用UDP来传输应用数据，从具有IPv4-1.0.0.2源地址的源端到两个接收端，分别是IPv4-7.0.0.2和7.0.0.3。此示例的目的是模拟下行场景。两个数据流起源于远程主机，具有特定的特性。一个流强调低延迟通信，而另一个则侧重于实现更高的吞吐量。在所提供的演示输出中，可以明显看到前者的平均延迟和抖动明显低于后者，而后者的吞吐量则相反。在代码中，低延迟通信被称为LowLat，以表示其低延迟性质，而实现更高吞吐量的通信被称为Voice，以反映与高质量语音通信相关的传统流量。对于这种通信，源地址是IPv4地址1.0.0.2，被称为"远程主机"。数据的接收方是两个UE设备。为了支持这种通信，配置了一个5G无线接入网络以及一个LTE核心网络，也称为EPC。整个架构被定义为5G NSA。该演示具有准理想条件。例如，连接SGW和gNB的S1-U链路没有延迟。此外，使用直接路径波束成形，这是一种理想算法，基于发射机始终知道接收机的精确位置的假设。有关更多信息，请参考NR手册的第2.3.9节。不考虑遮蔽，因为没有建筑物或其他可能影响正常视距条件的障碍物。最后，由于场景是静态的，即随时间不变，信道模型只在模拟开始时更新一次。虽然两个UE设备都采用2x4各向同性天线阵列，gNB设备采用4x8的相同阵列配置。在频谱方面，创建了两个频带来支持这种通信。第一个频带在28.0 GHz操作，而第二个频带在28.2 GHz操作，两者的带宽都为100 MHz。在数理方面，即子载波间隔，前者为4，后者为2。这简化了频谱分配，因为每个通信将在一个专用的BWP上运行，在一个占据整个频带的单个CC上运行，使得频谱组织如下所示：

• The configured spectrum division is:
• ------------Band1--------------|--------------Band2-----------------
• ------------CC1----------------|--------------CC2-------------------
• ------------BWP1---------------|--------------BWP2------------------

由于只有一个gNB，两个BWP之间的总传输功率为4 dBm，约为2.51 mW左右。根据BWP类型和承载，前者的通信被配置为使用一个带有NGBR低延迟的QCI，在代码中也被称为NGBR_LOW_LAT_EMBB，而后者有一个带有GBR的QCI，并被命名为GBR_CONV_VOICE。其他QCI类型的列表可以在QCI上的ns-3 QCIns-3 QCI页面上找到
堆栈的最顶部使用两个UDP应用程序来模拟低延迟的语音流量和高质量的语音流量。在生成的流量方面，前者模拟每100微秒产生一次100字节的突发，而后者则每100微秒生成1252字节的数据包。使用FlowMonitorHelper来收集有关流量的数据统计信息。最后，EPC的PGW与一个具有理想点对点信道的远程主机连接：数据速率为100 Gbps，MTU为2500字节，没有延迟。

CHAPTER FOUR

END-TO-END OBSERVATIONS

我们主要关注数据包在RAN堆栈中移动时的生命周期。我们可以通过记录来观察数据包流动的一些初始情况。
使用以下启用记录的命令，可以从模拟中的UdpClient和UdpServer对象生成日志信息，这两个对象模拟了前面提到的两种不同类型的通信，并将输出重定向到两个文件中，如下所示：

NS_LOG="UdpClient=info|prefix_time|prefix_node|prefix_func" ./ns3 run 'cttc-nr-demo' > log.client.out 2>&1
NS_LOG="UdpServer=info|prefix_time|prefix_node|prefix_func" ./ns3 run 'cttc-nr-demo' > log.server.out 2>&1

查看log.client.out文件的前几行，可以看到：

+0.400000000s 6 UdpClient:Send(): TraceDelay TX 100 bytes to 7.0.0.2 Uid: 8 Time: +0.
,→4s
+0.400000000s 6 UdpClient:Send(): TraceDelay TX 1252 bytes to 7.0.0.3 Uid: 9 Time: +0.
,→4s

这两个数据包同时从节点6发送到两个不同的UE，节点6表示模拟的远程主机。接下来，通过log.server.out文件观察UE上的第一个数据包到达时间：

+0.400408031s 1 UdpServer:HandleRead(): TraceDelay: RX 100 bytes from 1.0.0.2␣
,→Sequence Number: 0 Uid: 8 TXtime: +4e+08ns RXtime: +4.00408e+08ns Delay: +408031ns
...
+0.401832140s 2 UdpServer:HandleRead(): TraceDelay: RX 1252 bytes from 1.0.0.2␣
,→Sequence Number: 0 Uid: 9 TXtime: +4e+08ns RXtime: +4.01832e+08ns Delay: +1.
,→83214e+06ns

接收时间（和数据包延迟）非常不同。其中一个只需408微秒即可交付，而另一个需要1832微秒才能交付。在本教程中，我们将解释为什么会这样。