5G通信网络数传参数优化提升5G用户感知时延创新案例Word文档格式.docx
《5G通信网络数传参数优化提升5G用户感知时延创新案例Word文档格式.docx》由会员分享，可在线阅读，更多相关《5G通信网络数传参数优化提升5G用户感知时延创新案例Word文档格式.docx（20页珍藏版）》请在冰豆网上搜索。
⏹2.3、数据记录
1）数据格式：
原始Log文件（自定义），导出文件（CSV或EXCEL）
2）导出精度：
1秒/样本点
3）数据项：
a）终端侧：
时间戳、经纬度、RSRP（CSIRS&
DMRS）、RS-SINR（CSIRS&
DMRS）、各层空口信令消息、ping时延
b）基站侧：
信令、话统数据等
⏹2.4、测试结果
测试结果（单位ms）：
（终端ping核心网侧PDN服务器）
长度
32
64
256
1000
1500
近点
6
7
中点
远点
近点：
RSRP:
-84dBm,SINR:
15dB
中点：
-97dBm,SINR:
8dB
远点：
-96dBm,SINR:
-3dB
如上图所示：
远点位置ping长度1500，CMD命令窗口统计平均时延7ms；
从测试结果看，Connected态ping包丢包率0%，时延测试平均在6-7ms内，符合协议要求。
由于系统带宽大，并受益于MIMO复用增益，32-1500Byte的ping包时延无明显区别，与CU/DU合设（一体化）架构性能对比，Connected态ping包时延无区别。
2.2用户面时延优化方法
2.1.1ping测试问题的分析思路
由于ping包测试电脑和测试终端UE的影响不可控，排除这这个因素后，需要重点分析PING环回时延的空口时延和传输时延两部分。
当测试得到的环回时延较大时，甚至不能满足PING包测试指标要求时，需要将ping时延分解成下面两部分单独进行分析：
无线空口时延，即UE和基站间的交互时延，传输侧交互时延。
分解为两部分统计环回时延的目的是判断出时延较大的原因是由空口造成还是传输引起的。
如果空口时延较大，则需要从调度算法上考虑优化，这块由版本和无线参数来保证；
若传输时延较长，那就是非接入层的原因，可以从基站侧pingEPC或PINGFTP服务器来确认是否受到传输网络的影响，确认是传输的问题，需要请传输侧工程师协助解决。
2.1.2无线空口时延分析方法
无线空口时延，即UE和基站间的交互时延主要受基站无线参数设置及无线环境的影响。
主要分析方法是通过QXDM或者其他测试工具在终端UE侧进行抓log分析，如果有时延差异的话就需要对相关信令流程和无线参数进行分析定位。
2.1.3影响ping时延的无线参数
影响ping时延的无线参数主要有3类，分别介绍如下：
⏹ping包调度模式
1）动态调度（0）
2）基于收到SR置大的模拟BSR模式
（1）
3）混合调度模式
（2）
4）增强型混合调度模式（3）
5）基于预调度模式（4）
VSWc2单板的ping包时延具有3中调度模式，见DV参数表中V2调度参数---ping包优化开关：
1）基于收到SR置大的模拟BSR模式Large-TB-basedDynamicSchedule（0）
2）混合调度HybridSchedule
（1）
3）动态调度DynamicSchedule
（2）
Ping包时延5种调度模式具体介绍如下：
第一种、动态调度
对于当前5G系统，动态调度未打开ping包优化开关条件下，Ping包过程及各段时延分析如下图所示：
Ping包过程（动态调度）
正常的动态调度模式下，当UE的MAC层收到高层的上行业务请求，会触发一个SR（ScheduleRequest）请给给基站，基站收到响应后，发送一个小的上行授权，UE用来报告BSR（BufferStatusReport,用来告诉基站有多少数据需要发送）。
基站收到BSR之后，根据BSR给UE上行授权，UE使用该授权发上行的PING的内容，PING的数据就发送到基站侧。
第二种、基于收到SR置大的模拟BSR模式
这是目前版本默认设置的模式。
其基本原理是基于SR上报，根据前一个TTI需要调度的UE个数，基站主动下发一个较大的上行资源，使得UE可以利用该资源发送上行数据，减少了UE发送BSR然后eNB根据BSR进行调度的流程。
第三种、混合调度模式
混合调度模式是在预调度持续时间内，定时主动向UE发送上行资源，UE利用该资源发送上行数据。
由于基站是周期性的对UE分配上行资源，减少了UE发送SR的流程，因此使得PING包的时延缩短。
具体为：
UE发送SR请求，基站检测到SR后，产生虚拟的BSR进行正常的调度处理，启动预调度周期PingPreSchPeriodTimer和预调度持续时间PingPreSchHoldTimer（默认2048ms）；
在PingPreSchHoldTimer超时前，每隔PingPreSchPeriodTimer基站主动产生虚拟BSR并进行调度；
UE利用预调度的资源发送PING包的上行数据和可能的BSR。
混合调度模式对所有的SR均做同样的处理，如果商用系统中用户量较大，大量的上行资源预授权将导致基站反向干扰加重，严重影响基站反向解调性能。
商用局环境下不建议采用这种模式。
第四种、增强型混合调度模式
为了避免混合调度模式带来的负面影响，增强型混合调度模式能够对PING的业务进行识别，识别出PING业务的周期和大小之后，仅仅在PING的周期到来时，给一定长度及相应大小的预授权即可。
这样能大大减缓预授权带来的带宽损失，可提升上行的有效载荷。
第五种、基于预调度模式
预调度模式下，UE直接发送ping包，没有SR及BSR预授权协商过程，这种模式只能用于单用户实验室测试，属于极限测试。
⏹SR传输周期
Ping包测试时，上行传输默认使用LargeBSR方式传输。
终端首先发起SR（SchedulingRequest），在基站进行上行资源授权之后，终端再发起BSR（BufferStatusRequest）和ping数据包一起上传。
注意当UE高层要求发送SR的时候，并不是在每一个时隙都可以发送，而是需要在SR周期内的某一个时隙才能发送。
如下图。
图4-1SR周期示意
网管参数在无线参数---上下行物理信道配置表：
UESR传输周期（ms），如果配置SR周期为10ms，那么SR发送前的等待时间为1~10ms，平均等待时间为5ms，协议规定的最小SR周期是5ms，SR周期最短只能设置到5ms，目前我司默认配置是10ms，其实有些场景下如果S1传输时延太大导致ping时延离验收标准只差几ms的时候，可以把SR周期改为5ms，使得SR发送前的平均等待时间缩小到2.5ms，某外场局，通过将SR传输周期从10ms修改为5ms，使得ping时延平均值减少了3ms。
⏹DRX参数
DRX功能开启之后，在没有数据传输的时候，终端会进入休眠状态以节省电源，这时候上/下行数据的发送都可能会被延迟，进行ping业务会造成时延变长。
网管参数是E-UTRANFDD小区表的参数：
非GBR业务DRX使能开关。
某商用外场局，在NGBRDRX打开和关闭前后进行ping对比测试，关闭DRX时ping平均时延减少了3~4ms。
建议各商用外场局，在用户数量不多的时候将NGBRDRX开关关闭。
2.1.4无线环境对ping时延的影响
如果无线环境较差，或者无线环境的突然变化，都会造成空口发送的数据包解码错误而产生HARQ重传，重传一次的额外时延是8ms。
下图是通过QXDM抓取的一个ping包测试log数据，利用QCAT进行分析，在系统帧和子帧1099时上行MAC层发了一个ping包数据。
在系统帧和子帧1123时才收到下行MAC层返回的ping包数据，时延为1123-1099=24ms，这个商用局的S1口传输时延为10ms，即使扣除这个S1口10ms时延后，14ms也明显大于基站内部标准处理时延6ms。
在LTEPDSCHStatIndication消息中查看，发现在系统帧子帧1115时的CRCResult是fail，导致HARQ重传，在8ms后的系统帧子帧1123重新收到了ping包数据，这时候的CRCResult为pass，正确解码。
从这个例子中可以看出空口解码错误导致的HARQ重传，会增加ping包时延8ms。
2.1.5S1口传输时延分析方法
S1口时延指PingReq从基站出去（发往UE需要Ping的服务器）->
基站收到服务器返回的PingReply的时延，该段时延应该小于1ms，而不是单单指的基站与核心网的传输交互时延。
S1口时延测试有三种方法：
第一种、IP通道质量测试确定S1口时延
这个功能可实现通过在OMC客户端上进行操作，发起以“基站”做为ping操作的起点，对目标IP地址的IP通道质量通道检测。
目标IP地址选择核心网MME或者SGW的IP地址。
正常情况下，从基站ping核心网MME或者SGW的时延应该在1~2ms，如果偏大的话将会导致UEping时延增大，需要联系传输侧排查S1口时延。
第二种、Wireshark在基站VSWc2板debug口抓包确定传输时延
Telnet192.254.1.16，并padMGR.exe，登录到平台管理进程，敲入MirrorToDebug0,0，在QE进行端口映射，然后开启wireshark，在CC板debug口抓包。
详细抓包方法请参考附录ADebug口抓包方法。
在Ping之前，打开Wireshark工具，点击Capture捕获窗口，选择正确的interface,对应的服务器地址，在过滤栏指定IMCP消息，选择Updatelistofpacketsinrealtime。
使用完成之后使用BspClearESwitchMirror清除镜像，以免出现其他问题。
在InterControlMessageProtocol里：
Sequencennumber:
确定该Ping包的序列号，Data里确定一次Ping包的大小。
以下图为例：
传输时延=Echo（ping）reply的frame23里的Arrivaltime-Echo（ping）request的frame24里的Arrivaltime。
第三种、UE侧log分析确定传输时延
通过Ue侧Log来看，看上行包发出去时间及下行接收到的时间差，将这个时间差减去基站内部处理时延，既可以得到传输时延了。
通常基站内部处理时延正常值为6ms。
使用QXDM抓包时注意把所有LTE相关设置都选上，否则可能引起MAC层抓包不全，无法记录下所有上下行数据包的信息。
抓包完成后，使用QCAT把记录的LOG打开，并使用以下条件过滤，见下图：
Ping包是32字节，在加了各个协议层的开销之后，在MAC层看到的就是64字节。
见下图，在0xB064LTEMACULTransportBlock中找到LCID为3或者4，长度为64的包，为UE侧数据包发出的时间，如下图：
在上行数据附近的0xB063LTEMACDLTransportBlock找到LCID为3或者4，长度为64的包，对应的帧号子帧号为UE侧收到ping包的ACK的时间，如下：
故上述ping包在网络侧的时延为5448（DLreceive）-5441（ULsend）=7ms。
基站侧内部处理时延正常的情况下，S1口时延为7ms-6ms=1ms。
2.1.6预调度策略
增加部分预调度情况下的措施可以减小ping时延，也就是前面章节提到的增强型混合调度模式，但是实际网络中的用户不建议使用，因为会造成系统资源的浪费。
而且如果用户是做上行FTP等业务，第一包数据需要通过SR过程，后面的数据包如果连续调度是不需要再通过SR过程申请资源的，这种情况下第一包数据包的端到端时延等同于动态调度下的ping时延，而后续数据包的使用等同于预调度下的ping时延，不会影响用户感受。
最后，值得关注的是，在商用网络中，是不建议配置预调度模式的，因为如果存在预调度用户，这将造成频内干扰，因为这些用户的周期性的上行数据包就是明显的干扰源，会干扰临小区的其它正常用户的业务。
2.3控制面时延优化方法
2.3.1随机接入基本过程
在小区搜索过程之后，UE与小区取得了下行同步，因此UE能够接收下行数据。
但UE只有与小区取得上行同步，才能进行上行传输。
UE通过随机接入过程（RandomAccessProcedure）与小区建立连接并取得上行同步。
控制面时延主要关注接入过程中MSG1-5的时延。
目前NRMSG1-MSG5的空口时间，在CPE的LMT上都可以看到，信令的slot号就是空口时间。
2.3.2接入时延优化过程
2.3.2.1时延目标流程
msg1-msg2
实测3ms目标3ms
msg2-msg3实测5ms
目标3ms需优化
msg3-msg4
实测17.5ms目标6.5ms
需优化
msg4-msg5
实测5.5ms，目标3.5ms需优化
2.3.2.2控制面时延的优化方案
✧Msg1-Msg2
实测值与目标值一致，时延正常。
✧Msg2-Msg3
CPE收到msg2之后，CPE内部处理时间CPEProc1太长，CPE侧进行进程优化，使得msg3提前了4个slot（2ms）出空口，从而满足时延要求。
✧Msg3-Msg4
msg3->
msg4的流程如下：
mcc->
pps/mcc->
spa流程如下：
UC发出UE上下文给MCC，在此过程中存在板间传输时延（VSW->
VBP），MCC先给PPS发上下文消息（因为SPA建立上下文需要PPS生成的UEID），后PPS将消息通过调用平台OP接口发给MCC，之后MCC给SPA的组件SMC发上下文消息，SMC的启动时间是每个slot的起始位置offset=0，错过后SPA只能到下个slot收到上下文消息，SMC再给UAC配置上下文消息，从图中看出RAC在200微秒的位置启动，UAC在310微秒的位置启动，所以UAC收到上下文后，不能在slotN给RAC调度，只能在slotN+1的位置调度RAC，这里要注意，slotN的位置pps要把bsr给UAC，UAC在slotN同时收到bsr和UE上下文才会调度RAC，假如slotN的时候PPS没有发bsr，那么只能是在slotN+1的位置起调度（从实际的情况来看，PPS是收到ue上下文之后，下一个slot发出bsr，这个已经优化）。
RAC从收到UAC的调度的当前slot起，3个slot之后调度PPS发msg4，即slotN+3调度pps，slotN+4msg4出空口。
pps->
uc的时延优化：
在控制面内部，pps将msg3递交个ucm，ucm做一个头解压，然后OP给uc_stable，在stable中有20个OP，这20个OP中其中10多个是轮流用来发来自ucm消息的，（stable在接入阶段对于msg3来说就是个缓冲器，但是释放阶段及接入之后又其他的用途），最后UC拿到msg3，之后UC向hrrm申请srb1资源，此过程是一个串行过程，必须等到hrrm回应才行（实际可以做成并行的过程，或者这做成预调度srb1的过程），之后发上下文消息，然后发msg4，最后给sts发uecontextconfig。
一开始的实现是msg4和上下文的顺序是随机的，但是UC->
MCC->
SPA配置上下文的时间很长，如果先发上下文，再发msg4可以节约时间，前提是这三条消息都是并行发送的。
对于平台OP操作的时延很长的解决办法是绑核，绑核的目的是为了减少任务间核的切换，每切换一次需要重新catch一次，相当于重新读取代码的过程，这样很耗时间，核排他的目的是为了减少其他优先级高的任务的抢占，因为任务都是在核上面跑的。
✧Msg4-msg5
图5
CPEProc2（从接收到MSG4到准备接收MSG5的DCI0）的处理时间（1ms）足够，但基站侧dci0下发时间晚了2ms，RAC修改处理过程，msg4收到之后不推迟4个slot，只推迟2个slot就可以发送，这样使得msg5的DCI0在Uslot上下发给CPE（每个Uslot上带一个pdcch），从而msg5能够在下发DCI0后的第四个slot出空口。
2.4参数介绍
参数MO
参数ID
参数名称
默认值
商用场景推荐值【低频】
NRDuCellRsvdParam
RsvdU8Param65
ULRANK固定值
RsvdU8Param66
ULMCS固定值
NRDUCELLALGOSWITCH
Ul256QamSwitch
上行256QAM开关
UL_256QAM_OFF
SuMimoMultipleLayerSw_UL_SU_MULTI_LAYER_SW
上行单用户多流开关
on
AdaptiveEdgeExpEnhSwitch：
UL_IBLER_ADAPT_SW
上行IBLER自适应开关
off
NRDUCellPusch
UlTargetIbler
上行IBLER自适应算法关闭时的上行IBLER目标值
10
GNBCIPHERCAPB
CipherAlgoPriority
gNodeB加密算法优先级配置
PRIMARY（最高优先级加密算法）
常规测试：
保持默认值（参考备注）
NRDUCellRsvdOptParam
Param1WithParamId67
上行预调度用户数（C10）
2
NRDUCellRsvd
RsvdParam21
上行预调度用户数（C11）
Param1WithParamId74
上行预调度周期（C10）
5
RsvdParam27
上行预调度周期（C11）
Param1WithParamId73
上行预调度开关（C10）
1
RsvdParam26
上行预调度开关（C11）
Param1WithParamId60
预调度数据量
100
RsvdParam19
Param1WithParamId103
非周期调度CSI-RS周期（C10版本）
40
NRDUCellRSVD
RsvdParam40
非周期调度CSI-RS周期（C11版本）
CsiAlgoSwitch
Periodic_CSI_SWITCH
周期CSI-RS控制开关
Param1WithParamId39
下行IBLER目标值自适应特性开关（C10）
RsvdParam6
下行IBLER目标值自适应特性开关（C11）
SuMimoMultipleLayerSw_DL_SU_MULTI_LAYER_SW
下行单用户多流开关
NRDuCELLPDSCH
DlTargetIbler
该参数表示下行IBLER目标值。
2.5方案实施情况
本轮方案主要通过打开上行预调度开关、上行IBLER自适应开关、PUSCH占用PUCCHRB资源控制开关，修改配置上行预调度用户的调度数据量、上行预调度周期达到优化时延和上行吞吐率的目的。
MODNRDUCELLRSVD:
NRDUCELLID=176,RSVDPARAM26=1;
MODNRDUCellRsvd:
NRDUCELLID=176,RSVDPARAM19=1500;
MODNRDUCELLALGOSWITCH:
NRDUCELLID=176,ADAPTIVEEDGEEXPENHSWITCH=DL_PMI_SRS_ADAPT_SW-1;
NrDuCellId=13,RsvdParam28=1;
MODNRDUCELLALGOSWITCH:
NrDuCellId=7,Ul256QamSwitch=UL_256QAM_OFF;
2.6验证情况
2.6.1验证方式
1、分别使用32Bytes、1500Bytes的包长向服务器59.37.73.7进行ping包测试。
2.6.2验证情况
参数优化后同一无线环境下（RSRP-75dbm、SINR：
38，CQI：
15、DLMCS：
23），分别ping32Bytes、1500Bytes包长提升效果明显，32Bytes包长时延由25ms提升至16ms，1500Bytes包长时延由28
升级会员 