研发产品测试 » 2.0基站产品化测试

使用DU alpha的2023年11月9日 16:29:16的版本,CU Rel_2.1.14P_Pre2 (master上 2023年11月14日 16:06:18的代码)和phyRel_2.1.14P_Pre2的2023年8月23日的版本,重新测了一下
log见附件
ping了4个包,延迟如下:
yzrt@yzrt:~$ sudo ping c 4 60.60.0.1
[sudo] password for yzrt:
PING 60.60.0.1 (60.60.0.1) 56(84) bytes of data.
64 bytes from 60.60.0.1: icmp_seq=1 ttl=63 time=20.3 ms
64 bytes from 60.60.0.1: icmp_seq=2 ttl=63 time=18.5 ms
64 bytes from 60.60.0.1: icmp_seq=3 ttl=63 time=16.5 ms
64 bytes from 60.60.0.1: icmp_seq=4 ttl=63 time=14.6 ms
这4个包在DU的log如下:
16:12:00.402][WRN_19]gRecvUdpFromCuCnt = 1206 SysTime 16:12:00.401848
这行打印用于说明此时zlog打印的时间16:12:00.402与系统时间16:12:00.401848的偏差很小
16:12:00.402][DBG_24]decode,nrup_sn 1181
16:12:00.402][DBG_23]KwUiKwuDedUeDatReq: ue¹⁷⁰¹⁷ rbId² lchId⁵ Dequeue rlcDlMsgQ¹ sduCnt¹
16:12:00.404][DBG_24]kwAssembleSdus, pduInfo>amHdr.sn 1181
16:12:00.419][INF_24 numPdu⁰,numPduToProcess² RBID:2 UEID:17017 CELLID:1
16:12:00.419][INF_24 kwAmmUlHndlStatusPdu: ACK SN¹¹⁸² UEID¹⁷⁰¹⁷ CELLID¹ RBID² LCID⁵
16:12:00.419][INF_24 kwAmmProcessPdus: UEID:17017 CELLID:1 RBID:2 sn:730
16:12:00.759][INF_24 kwAmmProcessPdus: UEID:17017 CELLID:1 RBID:2 sn:731
16:12:00.766][WRN_19]gRecvUdpFromCuCnt = 1207 SysTime 16:12:00.765572
16:12:00.766][DBG_24]decode,nrup_sn 1182
16:12:00.766][DBG_24]KwUiKwuDedUeDatReq: ue¹⁷⁰¹⁷ rbId² lchId⁵ Dequeue rlcDlMsgQ¹ sduCnt¹
16:12:00.767][DBG_24]kwAssembleSdus, pduInfo->amHdr.sn 1182
16:12:00.779][INF_23 numPdu⁰,numPduToProcess² RBID:2 UEID:17017 CELLID:1
16:12:00.779][INF_23 kwAmmUlHndlStatusPdu: ACK SN¹¹⁸³ UEID¹⁷⁰¹⁷ CELLID¹ RBID² LCID⁵
16:12:00.779][INF_23 kwAmmProcessPdus: UEID:17017 CELLID:1 RBID:2 sn:732
16:12:01.404][WRN_19]gRecvUdpFromCuCnt = 1208 SysTime 16:12:01.403761
16:12:01.404][DBG_24]decode,nrup_sn 1183
16:12:01.404][DBG_23]KwUiKwuDedUeDatReq: ue¹⁷⁰¹⁷ rbId² lchId⁵ Dequeue rlcDlMsgQ¹ sduCnt¹
16:12:01.406][DBG_23]kwAssembleSdus, pduInfo->amHdr.sn 1183
16:12:01.419][INF_23 numPdu⁰,numPduToProcess² RBID:2 UEID:17017 CELLID:1
16:12:01.419][INF_23 kwAmmUlHndlStatusPdu: ACK SN¹¹⁸⁴ UEID¹⁷⁰¹⁷ CELLID¹ RBID² LCID⁵
16:12:01.419][INF_23 kwAmmProcessPdus: UEID:17017 CELLID:1 RBID:2 sn:733
16:12:02.406][WRN_19]gRecvUdpFromCuCnt = 1209 SysTime 16:12:02.405724
16:12:02.406][DBG_23]decode,nrup_sn 1184
16:12:02.406][DBG_24]KwUiKwuDedUeDatReq: ue¹⁷⁰¹⁷ rbId² lchId⁵ Dequeue rlcDlMsgQ¹ sduCnt¹
16:12:02.407][DBG_23]kwAssembleSdus, pduInfo->amHdr.sn 1184
16:12:02.419][INF_23 numPdu⁰,numPduToProcess² RBID:2 UEID:17017 CELLID:1
16:12:02.419][INF_23 kwAmmUlHndlStatusPdu: ACK SN¹¹⁸⁵ UEID¹⁷⁰¹⁷ CELLID¹ RBID² LCID⁵
从上面的打印可以看出zLog(DU_LOG_DEBUG,"kwAssembleSdus, pduInfo->amHdr.sn %d",pduInfo->amHdr.sn)这个打印 到 zLog(DU_LOG_INFO, "numPdu[%ld],numPduToProcess[%ld] RBID:%d UEID:%ld CELLID:%ld" 打印已经是 12到15ms了,不知道能否从MAC的角度定位一下?这个时延是发送在哪个位置?MAC还是物理层?还是其他位置

用基站250，没有动任何版本，
1.改了SR周期(40slots --> 10slots)，关闭上行预调度(SR周期比较小并且强制SR打开的时候，预调度没啥作用)；
修改后平均时延在12ms附近，

2.SR周期修改为5slots，UE无法接入，prach TA达到7，比正常值大，多次重启程序无效，reboot基站无效。poweroff，掉电RU，待RU稍稍冷却后再启动还是无效。
后经debug发现，不是TA导致的，该基站接入TA比之前正常TA 2,3大。原因是DU下发rrcsetup中没包含SR周期小于10的分支，导致未给UE配置SR周期，UE收到msg4后没有后续接入动作。
DU修改后，UE仍然无法接入，明天继续debug看看。

DU修改支持SR周期5ms的版本，SR周期配置为5ms，下行平时延如下图（平均10ms附近）。
存在一个问题，华为手机无法接入(不响应msg4 harq和msg5)，高通芯片手机可以接入。

由于华为手机不支持SR 5ms周期，继续查看DU代码，发现上行预调度功能在开发CNRTI MAC CE和重建立的时候，会在其中任一功能支持时被屏蔽。
而目前的版本默认支持CRNTI MAC CE，导致即便上行预调度开关打开了，也只能在收到CRNTI MAC CE后才生效。

修改DU版本支持上行预调度，配置打开上行预调度，SR周期10slots，华为手机能够接入，整体上下行ping包时延在10ms。
如下图所示：

修改后的DU，配置合适的参数，平均时延能够达到10ms，
转测试。

15p_pre1版本，2.5ms平均时延为9.5ms，问题单关闭