5G通信网络数传参数优化提升5G用户感知时延创新案例Word文档格式.docx

1、2.3、数据记录1）数据格式：原始Log文件（自定义），导出文件（CSV或EXCEL）2）导出精度：1秒/样本点3）数据项：a）终端侧：时间戳、经纬度、RSRP（CSI RS &DM RS）、RS-SINR（CSI RS &DM RS）、各层空口信令消息、ping时延b）基站侧： 信令、话统数据等2.4、测试结果测试结果（单位ms）：（终端ping核心网侧PDN服务器）长度326425610001500近点67中点远点近点：RSRP:-84dBm,SINR:15dB中点：-97dBm,SINR:8dB远点：-96dBm,SINR:-3dB如上图所示：远点位置ping长度1500，CMD命令窗口

2、统计平均时延7ms；从测试结果看，Connected态ping包丢包率0%，时延测试平均在6-7ms内，符合协议要求。由于系统带宽大，并受益于MIMO复用增益，32-1500Byte的ping包时延无明显区别，与CU/DU合设（一体化）架构性能对比，Connected态ping包时延无区别。2.2用户面时延优化方法2.1.1 ping测试问题的分析思路由于ping包测试电脑和测试终端UE的影响不可控，排除这这个因素后，需要重点分析PING环回时延的空口时延和传输时延两部分。当测试得到的环回时延较大时，甚至不能满足PING包测试指标要求时，需要将ping时延分解成下面两部分单独进行分析：无线空口

3、时延，即UE和基站间的交互时延 ，传输侧交互时延。分解为两部分统计环回时延的目的是判断出时延较大的原因是由空口造成还是传输引起的。如果空口时延较大，则需要从调度算法上考虑优化，这块由版本和无线参数来保证；若传输时延较长，那就是非接入层的原因，可以从基站侧ping EPC或PING FTP服务器来确认是否受到传输网络的影响，确认是传输的问题，需要请传输侧工程师协助解决。2.1.2无线空口时延分析方法无线空口时延，即UE和基站间的交互时延主要受基站无线参数设置及无线环境的影响。主要分析方法是通过QXDM或者其他测试工具在终端UE侧进行抓log分析，如果有时延差异的话就需要对相关信令流程和无线参数进

4、行分析定位。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-based Dynamic Schedule（0）2）混合调度 Hybrid Schedule（1）3）动态调度 Dynamic Schedule（2）Ping包时延5种调度模式具体介绍如下：

5、第一种、 动态调度对于当前5G系统，动态调度未打开ping包优化开关条件下，Ping包过程及各段时延分析如下图所示：Ping包过程（动态调度）正常的动态调度模式下，当UE的MAC层收到高层的上行业务请求，会触发一个SR（Schedule Request）请给给基站，基站收到响应后，发送一个小的上行授权，UE用来报告BSR（Buffer Status Report,用来告诉基站有多少数据需要发送）。基站收到BSR之后，根据BSR给UE上行授权，UE使用该授权发上行的PING的内容， PING的数据就发送到基站侧。第二种、 基于收到SR置大的模拟BSR模式这是目前版本默认设置的模式。其基本原理是基

6、于SR上报，根据前一个TTI需要调度的UE个数，基站主动下发一个较大的上行资源，使得UE可以利用该资源发送上行数据，减少了UE发送BSR然后eNB根据BSR进行调度的流程。第三种、 混合调度模式混合调度模式是在预调度持续时间内，定时主动向UE发送上行资源，UE利用该资源发送上行数据。由于基站是周期性的对UE分配上行资源，减少了UE发送SR的流程，因此使得PING包的时延缩短。具体为：UE发送SR请求，基站检测到SR后，产生虚拟的BSR进行正常的调度处理，启动预调度周期PingPreSchPeriodTimer和预调度持续时间PingPreSchHoldTimer（默认2048ms）；在Ping

7、PreSchHoldTimer超时前，每隔PingPreSchPeriodTimer基站主动产生虚拟BSR并进行调度；UE利用预调度的资源发送PING包的上行数据和可能的BSR。混合调度模式对所有的SR均做同样的处理，如果商用系统中用户量较大，大量的上行资源预授权将导致基站反向干扰加重，严重影响基站反向解调性能。商用局环境下不建议采用这种模式。第四种、 增强型混合调度模式为了避免混合调度模式带来的负面影响，增强型混合调度模式能够对PING的业务进行识别，识别出PING业务的周期和大小之后，仅仅在PING的周期到来时，给一定长度及相应大小的预授权即可。这样能大大减缓预授权带来的带宽损失，可提升上

8、行的有效载荷。第五种、 基于预调度模式预调度模式下，UE直接发送ping包，没有SR及BSR预授权协商过程，这种模式只能用于单用户实验室测试，属于极限测试。SR传输周期Ping包测试时，上行传输默认使用Large BSR方式传输。终端首先发起SR（Scheduling Request），在基站进行上行资源授权之后，终端再发起BSR（Buffer Status Request）和ping数据包一起上传。注意当UE高层要求发送SR的时候，并不是在每一个时隙都可以发送，而是需要在SR周期内的某一个时隙才能发送。如下图。图 4-1 SR周期示意网管参数在无线参数-上下行物理信道配置表：UE SR传输周

9、期（ms），如果配置SR周期为10ms，那么SR发送前的等待时间为110ms，平均等待时间为5ms，协议规定的最小SR周期是5ms，SR周期最短只能设置到5ms，目前我司默认配置是10ms，其实有些场景下如果S1传输时延太大导致ping时延离验收标准只差几ms的时候，可以把SR周期改为5ms，使得SR发送前的平均等待时间缩小到2.5ms，某外场局，通过将SR传输周期从10ms修改为5ms，使得ping时延平均值减少了3ms。DRX参数DRX功能开启之后，在没有数据传输的时候，终端会进入休眠状态以节省电源，这时候上/下行数据的发送都可能会被延迟，进行ping业务会造成时延变长。网管参数是E-UT

10、RAN FDD小区表的参数：非GBR业务DRX使能开关。某商用外场局，在NGBR DRX打开和关闭前后进行ping对比测试，关闭DRX时ping平均时延减少了34ms。建议各商用外场局，在用户数量不多的时候将NGBR DRX开关关闭。2.1.4无线环境对ping时延的影响如果无线环境较差，或者无线环境的突然变化，都会造成空口发送的数据包解码错误而产生HARQ重传，重传一次的额外时延是8ms。下图是通过QXDM抓取的一个ping包测试log数据，利用QCAT进行分析，在系统帧和子帧1099时上行MAC层发了一个ping包数据。在系统帧和子帧1123时才收到下行MAC层返回的ping包数据，时延为

11、1123-1099=24ms，这个商用局的S1口传输时延为10ms，即使扣除这个S1口10ms时延后，14ms也明显大于基站内部标准处理时延6ms。在 LTE PDSCH Stat Indication消息中查看，发现在系统帧子帧1115时的CRC Result是fail，导致HARQ重传，在8ms后的系统帧子帧1123重新收到了ping包数据，这时候的CRC Result为pass，正确解码。从这个例子中可以看出空口解码错误导致的HARQ重传，会增加ping包时延8ms。2.1.5 S1口传输时延分析方法S1口时延指Ping Req从基站出去（发往UE需要Ping的服务器）-基站收到服务器返

12、回的Ping Reply的时延，该段时延应该小于1ms，而不是单单指的基站与核心网的传输交互时延。S1口时延测试有三种方法：第一种、IP通道质量测试确定S1口时延这个功能可实现通过在OMC客户端上进行操作，发起以“基站”做为ping操作的起点，对目标IP地址的IP通道质量通道检测。目标IP地址选择核心网MME或者SGW 的IP地址。正常情况下，从基站ping 核心网MME或者SGW的时延应该在12ms，如果偏大的话将会导致UE ping时延增大，需要联系传输侧排查S1口时延。第二种、Wireshark在基站VSWc2板debug口抓包确定传输时延Telnet 192.254.1.16，并pad

13、 MGR.exe，登录到平台管理进程，敲入MirrorToDebug 0,0，在QE进行端口映射，然后开启wireshark，在CC板debug口抓包。详细抓包方法请参考附录A Debug口抓包方法。在Ping之前，打开Wireshark工具，点击Capture捕获窗口，选择正确的interface,对应的服务器地址，在过滤栏指定IMCP消息，选择Update list of packets in real time。使用完成之后使用BspClearESwitchMirror清除镜像，以免出现其他问题。在Inter Control Message Protocol里：Sequencen num

14、ber:确定该Ping包的序列号，Data里确定一次Ping包的大小。以下图为例：传输时延 = Echo （ping） reply的frame 23里的 Arrival time - Echo （ping） request的frame 24里的 Arrival time。第三种、UE侧log分析确定传输时延通过Ue侧Log来看，看上行包发出去时间及下行接收到的时间差，将这个时间差减去基站内部处理时延，既可以得到传输时延了。通常基站内部处理时延正常值为6ms。使用QXDM抓包时注意把所有LTE相关设置都选上，否则可能引起MAC层抓包不全，无法记录下所有上下行数据包的信息。抓包完成后，使用QCAT

15、把记录的LOG打开，并使用以下条件过滤，见下图：Ping包是32字节，在加了各个协议层的开销之后，在MAC层看到的就是64字节。见下图，在0xB064 LTE MAC UL Transport Block中找到LC ID为3或者4，长度为64的包，为UE侧数据包发出的时间，如下图：在上行数据附近的0xB063 LTE MAC DL Transport Block找到LC ID为3或者4，长度为64的包，对应的帧号子帧号为UE侧收到ping包的ACK的时间，如下：故上述ping包在网络侧的时延为5448（DL receive） - 5441（UL send）=7ms。基站侧内部处理时延正常的情况

16、下，S1口时延为7ms-6ms=1ms。2.1.6预调度策略增加部分预调度情况下的措施可以减小ping时延，也就是前面章节提到的增强型混合调度模式，但是实际网络中的用户不建议使用，因为会造成系统资源的浪费。而且如果用户是做上行FTP等业务，第一包数据需要通过SR过程，后面的数据包如果连续调度是不需要再通过SR过程申请资源的，这种情况下第一包数据包的端到端时延等同于动态调度下的ping时延，而后续数据包的使用等同于预调度下的ping时延，不会影响用户感受。最后，值得关注的是，在商用网络中，是不建议配置预调度模式的，因为如果存在预调度用户，这将造成频内干扰，因为这些用户的周期性的上行数据包就是明显

17、的干扰源，会干扰临小区的其它正常用户的业务。2.3控制面时延优化方法2.3.1随机接入基本过程在小区搜索过程之后，UE 与小区取得了下行同步，因此 UE 能够接收下行数据。但 UE 只有与小区取得上行同步，才能进行上行传输。 UE 通过随机接入过程（Random Access Procedure）与小区建立连接并取得上行同步。 控制面时延主要关注接入过程中MSG1-5的时延。目前NR MSG1-MSG5的空口时间，在CPE的LMT上都可以看到，信令的slot号就是空口时间。2.3.2接入时延优化过程2.3.2.1 时延目标流程msg1-msg2 实测 3ms 目标3ms msg2-msg3 实

18、测 5ms 目标3ms 需优化msg3-msg4 实测17.5ms 目标6.5ms 需优化msg4-msg5 实测5.5ms，目标3.5ms 需优化2.3.2.2控制面时延的优化方案Msg1-Msg2实测值与目标值一致，时延正常。Msg2-Msg3CPE收到msg2之后，CPE内部处理时间CPE Proc1太长，CPE侧进行进程优化，使得msg3提前了4个slot（2ms）出空口，从而满足时延要求。Msg3-Msg4msg3-msg4的流程如下：mcc-pps/mcc-spa流程如下：UC发出UE上下文给MCC，在此过程中存在板间传输时延（VSW-VBP），MCC先给PPS发上下文消息（因为S

19、PA建立上下文需要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，那么只能是在sl

20、otN+1的位置起调度（从实际的情况来看，PPS是收到ue上下文之后，下一个slot发出bsr，这个已经优化）。RAC从收到UAC的调度的当前slot起，3个slot之后调度PPS发msg4，即slotN+3调度pps，slotN+4 msg4出空口。pps-uc的时延优化：在控制面内部，pps将msg3递交个ucm，ucm做一个头解压，然后OP给uc_stable，在stable中有20个OP，这20个OP中其中10多个是轮流用来发来自ucm消息的，（stable在接入阶段对于msg3来说就是个缓冲器，但是释放阶段及接入之后又其他的用途），最后UC拿到msg3，之后UC向hrrm申请srb1

21、资源，此过程是一个串行过程，必须等到hrrm回应才行（实际可以做成并行的过程，或者这做成预调度srb1的过程），之后发上下文消息，然后发msg4，最后给sts发uecontextconfig。一开始的实现是msg4和上下文的顺序是随机的，但是UC-MCC-SPA配置上下文的时间很长，如果先发上下文，再发msg4可以节约时间，前提是这三条消息都是并行发送的。对于平台OP操作的时延很长的解决办法是绑核，绑核的目的是为了减少任务间核的切换，每切换一次需要重新catch一次，相当于重新读取代码的过程，这样很耗时间，核排他的目的是为了减少其他优先级高的任务的抢占，因为任务都是在核上面跑的。Msg4-ms

22、g5图 5CPE Proc2（从接收到MSG4 到 准备接收MSG5的DCI0）的处理时间（1ms）足够，但基站侧dci0下发时间晚了2ms，RAC修改处理过程，msg4收到之后不推迟4个slot，只推迟2个slot就可以发送，这样使得msg5的DCI0在U slot上下发给CPE（每个U slot上带一个pdcch），从而msg5能够在下发DCI0后的第四个slot出空口。2.4参数介绍参数MO参数ID参数名称默认值商用场景推荐值【低频】NRDuCellRsvdParamRsvdU8Param65UL RANK固定值RsvdU8Param66ULMCS固定值NRDUCELLALGOSWITC

23、HUl256QamSwitch上行256QAM开关UL_256QAM_OFFSuMimoMultipleLayerSw_UL_SU_MULTI_LAYER_SW上行单用户多流开关onAdaptiveEdgeExpEnhSwitch：UL_IBLER_ADAPT_SW上行IBLER自适应开关offNRDUCellPuschUlTargetIbler上行IBLER自适应算法关闭时的上行IBLER目标值10GNBCIPHERCAPBCipherAlgoPrioritygNodeB加密算法优先级配置PRIMARY（最高优先级加密算法）常规测试：保持默认值（参考备注）NRDUCellRsvdOptPar

24、amParam1WithParamId67上行预调度用户数（C10）2NRDUCellRsvdRsvdParam21上行预调度用户数（C11）Param1WithParamId74上行预调度周期（C10）5RsvdParam27上行预调度周期（C11）Param1WithParamId73上行预调度开关（C10）1RsvdParam26上行预调度开关（C11）Param1WithParamId60预调度数据量100RsvdParam19Param1WithParamId103非周期调度CSI-RS周期（C10 版本）40NRDUCellRSVDRsvdParam40非周期调度CSI-RS周期（

25、C11版本）CsiAlgoSwitchPeriodic_CSI_SWITCH周期CSI-RS控制开关Param1WithParamId39下行IBLER目标值自适应特性开关（C10）RsvdParam6下行IBLER目标值自适应特性开关（C11）SuMimoMultipleLayerSw_DL_SU_MULTI_LAYER_SW下行单用户多流开关NRDuCELLPDSCHDlTargetIbler该参数表示下行IBLER目标值。2.5方案实施情况本轮方案主要通过打开上行预调度开关、上行IBLER自适应开关、PUSCH占用PUCCH RB资源控制开关，修改配置上行预调度用户的调度数据量、上行预调

26、度周期达到优化时延和上行吞吐率的目的。MOD NRDUCELLRSVD:NRDUCELLID=176,RSVDPARAM26=1;MOD NRDUCellRsvd:NRDUCELLID=176,RSVDPARAM19=1500;MODNRDUCELLALGOSWITCH:NRDUCELLID=176,ADAPTIVEEDGEEXPENHSWITCH=DL_PMI_SRS_ADAPT_SW-1; NrDuCellId=13, RsvdParam28=1;MOD NRDUCELLALGOSWITCH: 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、DL MCS：23），分别ping32Bytes、1500Bytes包长提升效果明显，32Bytes包长时延由25ms提升至16ms，1500Bytes包长时延由28