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

NrUePhy

信道的另一端是UE，它由NrUePhy实现，可以在model/nr/nrue-phy.cc中找到。可以启用日志记录组件并与gNB的日志进行关联，以评估在物理层发生的情况：

NS_LOG="NrGnbPhy:NrUePhy" ./ns3 run cttc-nr-demo &> out.log

可以分析以下日志摘录：

+0.000000000s 1 [ CellId 2, bwpId 0] NrUePhy:StartEventLoop(): [INFO ] PHY starting.␣
,→Configuration:
TxPower: 2 dBm
NoiseFigure: 5
TbDecodeLatency: 100 us
Numerology: 4
SymbolsPerSlot: 14
Pattern: F|F|F|F|F|F|F|F|F|F|
Attached to physical channel:
Channel bandwidth: 18000000 Hz
Channel central freq: 2.8e+10 Hz
Num. RB: 6
...
+0.400191964s 1 [ CellId 2, bwpId 0] NrUePhy:DlData(): [INFO ] UE2 HARQ ID 19 stream␣
,→0 RXing DL DATA frame for symbols 1-12 num of rbg assigned: 33. RX will take place␣
,→for +53568ns
+0.400245531s 1 [ CellId 2, bwpId 0] NrUePhy:GenerateDlCqiReport(): [INFO ] Stream 0␣
,→WB CQI 15 avrg MCS 28 avrg SINR (dB) 42.9278
+0.400245531s 1 [ CellId 2, bwpId 0] NrUePhy:NotifyDlHarqFeedback(): [INFO ] HARQ␣
,→Feedback for ID 19 Stream 0
...
+0.400767857s 2 [ CellId 3, bwpId 1] NrUePhy:DlData(): [INFO ] UE1 HARQ ID 19 stream␣
,→0 RXing DL DATA frame for symbols 1-12 num of rbg assigned: 133. RX will take place␣
,→for +214284ns
...
+0.400982140s 2 [ CellId 3, bwpId 1] NrUePhy:GenerateDlCqiReport(): [INFO ] Stream 0␣
,→WB CQI 15 avrg MCS 28 avrg SINR (dB) 41.8067
+0.400982140s 2 [ CellId 3, bwpId 1] NrUePhy:NotifyDlHarqFeedback(): [INFO ] HARQ␣
,→Feedback for ID 19 Stream 0

在模拟开始时，为每个UE和BWP ID初始化一个NrUePhy实例。总共有4条这样的信息。通过查看消息前缀[CellId 2, bwpId 0]，可以清楚地看到PHY是如何使用列出的参数配置的，这对于跟踪和理解日志文件中进一步点的流量行为非常有用。
还可以观察到数据由不同的UE PHY接收，使用不同的BWP ID。第一个UE PHY接收低延迟应用的流量，第二个UE PHY接收高质量语音的流量。可以清楚地看到分配的RB数量和数据传输所需的延迟的差异。
当一帧完全接收后，即从发射器PHY复制数据突发到接收器PHY时，相应的CQI报告将被计算。因此，NrUePhy::GenerateDlCqiReport()会打印一个包含有关最后接收的帧的有用统计信息的日志消息，特别是平均MCS和SINR。计算得到的SINR也可以通过DlDataSinr跟踪。
最后，可以通过NrUePhy::NotifyDlHarqFeedback()跟踪HARQ反馈，以完全理解在接收帧之后它的生命周期。
尽管可以在NrUePhy中跟踪数据包的生命周期，但NrSpectrumPhy包含了允许评估TB SINR和TBLER以及最终决定接收过程中TB是否损坏的所有实际逻辑。这样的决策可以在model/nr-spectrum-phy.cc的NrSpectrumPhy::EndRxData()方法中看到。TBLER由NrLteMiErrorModel评估。如果TBLER小于0和1之间的UniformRandomVariable的实现结果，则TB被标记为损坏。这意味着发送NACK作为HARQ状态。
#Packet latency
相同的逻辑适用于NrGnbPhy，因为帧需要给定的持续时间从gNB传输到UE。
#Packet drops
根据NrGnbPhy和相应的NrSpectrumPhy的逻辑，在UE端由NrSpectrumPhy丢弃的传输块会在此层引发HARQ反馈，以便进行重传。

NrUeMac

NrUeMac模块实现在model/nr-ue-mac.cc文件中。通过其DoReceivePhyPdu()回调函数，NrUeMac模块从PHY层接收到新的MAC帧的可用通知。实际上，如果我们像下面这样启用组件日志：

$ NS_LOG="NrUeMac=info|prefix_all" ./ns3 run cttc-nr-demo

我们会得到如下信息

+0.016316963s 1 [ CellId 2, bwpId 0, rnti 0] NrUeMac:DoReceiveControlMessage():␣
,→[INFO ] Received RAR in slot FrameNum: 1 SubFrameNum: 6 SlotNum: 5
+0.016316963s 2 [ CellId 2, bwpId 0, rnti 0] NrUeMac:DoReceiveControlMessage():␣
,→[INFO ] Received RAR in slot FrameNum: 1 SubFrameNum: 6 SlotNum: 5
+0.400345531s 1 [ CellId 2, bwpId 0, rnti 2] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 81 bytes.
...
+0.400671427s 1 [ CellId 2, bwpId 0, rnti 2] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 185 bytes.
...
+0.401082140s 2 [ CellId 3, bwpId 1, rnti 1] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 345 bytes.
...
+0.402582140s 2 [ CellId 3, bwpId 1, rnti 1] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 12065 bytes.

可以明显看到两个BWP接收到的数据量。最后，仅通过删除其PDU中的MAC头，MAC SDU将被准备好并转发给LTE RLC层。
# Packet latency
可以通过交叉检查NrGnbMac发送的数据和在这里接收到的数据来进行验证。下面给出了启用了两个日志组件的示例：

$ NS_LOG="NrGnbMac=info|prefix_all:NrUeMac=info|prefix_all" ./ns3 run cttc-nr-demo

如果我们只过滤跟踪每个BWP发送的前3个TB的输出，我们可以得到以下日志消息：

+0.400062500s 0 [ CellId 2, bwpId 0] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 19 LC ID 4 stream 0 size 81␣
,→bytes
+0.400125000s 0 [ CellId 2, bwpId 0] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 18 LC ID 4 stream 0 size 81␣
,→bytes
+0.400187500s 0 [ CellId 2, bwpId 0] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 17 LC ID 4 stream 0 size 81␣
,→bytes
+0.400250000s 0 [ CellId 3, bwpId 1] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 19 LC ID 4 stream 0 size 345␣
,→bytes
+0.400345531s 1 [ CellId 2, bwpId 0, rnti 2] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 81 bytes.
+0.400408031s 1 [ CellId 2, bwpId 0, rnti 2] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 81 bytes.
+0.400470531s 1 [ CellId 2, bwpId 0, rnti 2] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 81 bytes.
    +0.400500000s 0 [ CellId 3, bwpId 1] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 18 LC ID 4 stream 0 size 345␣
,→bytes
+0.400750000s 0 [ CellId 3, bwpId 1] NrGnbMac:DoSchedConfigIndication(): [INFO ]␣
,→Notifying RLC of TX opportunity for HARQ Process ID 17 LC ID 4 stream 0 size 345␣
,→bytes
+0.401082140s 2 [ CellId 3, bwpId 1, rnti 1] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 345 bytes.
+0.401332140s 2 [ CellId 3, bwpId 1, rnti 1] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 345 bytes.
+0.401582140s 2 [ CellId 3, bwpId 1, rnti 1] NrUeMac:DoReceivePhyPdu(): [INFO ]␣
,→Received PHY PDU from LCID 4 of size 345 bytes.

可以观察到，在约1,519.64微秒内，第一个BWP正确发送了243个字节给UE，而第二个BWP发送了1035个字节。另一方面，第一个BWP平均只需要约283微秒来传输这些TB，而第二个BWP需要约832微秒。这一方面非常突出了在选择不同的BWP时发生的权衡。
# Packet drops
数据包可能会因为RNTI与期望值不匹配而被NrUeMac丢弃。

LteRlcUm - UE Side

当RLC PDU在LteRlcUm::DoReceivePdu()被接收时，它的报头被移除。它的数据包序列号被检查以验证是否(i)数据需要重新排序，(ii)数据是前一个数据的副本，以及(iii)它已在重新排序窗口外接收。要完全理解这个逻辑，请参考LTE RLC的5.1.2.2节
协议规范。
一旦SDU从收到的pdu中正确地重新组装，LteRlcUm::ReassembleAndDeliver()将数据包发送到PDCP层。
#Packet latency
RLC层的延迟可以用RxPdu跟踪来跟踪。同时，可以启用LteRlcUm日志组件，并通过LteRlcUm::DoReceivePdu()消息进行过滤。可以注意到，对于低延迟语音，数据包的平均延迟为234 us，而高质量语音的平均延迟为681 us。这些数据可以通过以下两个命令轻松提取:

$ grep '1 LteRlcUm:DoReceivePdu' output.log | \
grep -oP '[0-9]+(?=ns)' | \
awk '{ total += $1; count ++ } END { print total/count/1e3 }'
233.976
$ grep '2 LteRlcUm:DoReceivePdu' output.log | \
grep -oP '[0-9]+(?=ns)' | \
awk '{ total += $1; count ++ } END { print total/count/1e3 }'
680.866

同时，可以很容易地调整上述命令来报告每个数据包传输的平均字节数。前者为132字节，后者为3210字节。
#Packet drops
在LTE RLC协议规范的第5.1.2.2节中规定，如果RLC PDU已经被接收过或其序列号超出了重排序窗口范围，该RLC PDU将被丢弃。

LtePdcp - UE Side

类似于在RLC层所看到的情况，PDCP层接收到的传入PDCP PDU将会在LtePdcp::DoReceivePdu()方法中被接收。头部被移除后，数据包将会被传输给LteUeRrc，然后直接传递给EpcUeNas，最终到达NrUeNetDevice。
#Packet latency
Packet latency可以使用与第5.10.1节相同的方法进行评估。LteUeRrc和EpcUeNas表现透明，不会增加任何额外的延迟。
#Packet drops
数据包在这一层、RRC层和UE NAS层都不能被丢弃。

NrUeNetDevice

不会丢弃和产生延迟