5G ping包时延问题的优化和定位方法

 概述

5G系统相比其它通讯系统，结构更加精简。从协议已发布一些指标来看，时延相比其它系统有较大改善。比如协议要求用户面时延小于4ms，用户面ping包时延指标往往作为单站验收的KPI指标之一。本文主要介绍5G ping包时延问题的优化和定位方法。

基本原理和流程介绍

5G做ping时延测试，一般是在连接终端UE的笔记本电脑上面进行ping包，为了排除，外网时延的影响，一般采用ping FTP内网服务器IP地址的方式。正常Ping 包测试方法如下：

• 前提条件

测试目标小区正常建立。 移动UE找到想要的测试点，通常PING包测试中要求测试UE在目标小区近点即SINR大于20的点，为了测试出较理想结果尽量找到SINR大于25的测试点。 UE正常注册成功并接入网络。

• 测试步骤

第一步、将NR测试终端放置在近点；第二步、NR测试终端发起初始业务连接；第三步、分别使用32Bytes 、64Bytes、256Bytes、1000Bytes、1500Bytes的包长向网络进行ping包测试100次，使用抓包软件记录应用层RTT时间；第四步、将测试UE放置在中点，重复步骤2~3；第五步、将测试UE放置在远点，重复步骤2~3；

• 数据记录

数据格式：原始Log文件（自定义），导出文件（CSV或EXCEL）导出精度：1秒/样本点终端侧：时间、经纬度、RSRP（CSI RS &DM RS）、RS-SINR（CSI RS &DM RS）、各层空口信令消息、ping时延基站侧：信令、话统数据等

用户面时延优化方法

3.1、ping测试问题的分析思路

由于ping包测试电脑和测试终端UE的影响不可控，排除这这个因素后，需要重点分析PING环回时延的空口时延和传输时延两部分。当测试得到的环回时延较大时，甚至不能满足PING包测试指标要求时，需要将ping时延分解成下面两部分单独进行分析：无线空口时延，即UE和基站间的交互时延 ，传输侧交互时延。分解为两部分统计环回时延的目的是判断出时延较大的原因是由空口造成还是传输引起的。如果空口时延较大，则需要从调度算法上考虑优化，这块由版本和无线参数来保证；若传输时延较长，那就是非接入层的原因，可以从基站侧ping EPC或PING FTP服务器来确认是否受到传输网络的影响，确认是传输的问题，需要请传输侧工程师协助解决。

3.2、无线空口时延分析方法

无线空口时延，即UE和基站间的交互时延主要受基站无线参数设置及无线环境的影响。主要分析方法是通过QXDM或者其他测试工具在终端UE侧进行抓log分析，如果有时延差异的话就需要对相关信令流程和无线参数进行分析定位。

3.3、影响ping时延的无线参数

影响ping时延的无线参数主要有3类，分别介绍如下。ping包调度模式动态调度（0）基于收到SR置大的模拟BSR模式（1）混合调度模式（2）增强型混合调度模式（3）基于预调度模式（4）
Ping包时延5种调度模式具体介绍如下：

第一种、 动态调度

对于当前5G系统，动态调度未打开ping包优化开关条件下，Ping包过程及各段时延分析。Ping包过程（动态调度）正常的动态调度模式下，当UE的MAC层收到高层的上行业务请求，会触发一个SR（Schedule Request）请给给基站，基站收到响应后，发送一个小的上行授权，UE用来报告BSR（Buffer Status Report,用来告诉基站有多少数据需要发送）。基站收到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和预调度持续时间Ping PreSch Hold Timer (默认2048ms)；在Ping PreSch Hold Timer超时前，每隔PingPreSch PeriodTimer 基站主动产生虚拟BSR并进行调度；UE利用预调度的资源发送PING包的上行数据和可能的BSR。

混合调度模式对所有的SR均做同样的处理，如果商用系统中用户量较大，大量的上行资源预授权将导致基站反向干扰加重，严重影响基站反向解调性能。商用局环境下不建议采用这种模式。

第四种、 增强型混合调度模式

为了避免混合调度模式带来的负面影响，增强型混合调度模式能够对PING的业务进行识别，识别出PING业务的周期和大小之后，仅仅在PING的周期到来时，给一定长度及相应大小的预授权即可。这样能大大减缓预授权带来的带宽损失，可提升上行的有效载荷。

第五种、 基于预调度模式

预调度模式下，UE直接发送ping包，没有SR及BSR预授权协商过程，这种模式只能用于单用户实验室测试，属于极限测试。

• SR传输周期

Ping包测试时，上行传输默认使用Large BSR方式传输。终端首先发起SR （Scheduling Request），在基站进行上行资源授权之后，终端再发起BSR (Buffer Status Request)和ping数据包一起上传。 注意当UE高层要求发送SR的时候，并不是在每一个时隙都可以发送，而是需要在SR周期内的某一个时隙才能发送。 网管参数在无线参数---上下行物理信道配置表：UE SR传输周期(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。需要注意的是，将SR周期从10ms修改为5ms，将会使得PUCCH SR信道支持的最大用户数减少一倍，默认参数是按照每载扇400激活用户配置的，修改后会使得PUCCH信道容量减少。在网络负载比较小的场景下，修改这个参数影响不大。

• DRX参数

DRX功能开启之后，在没有数据传输的时候，终端会进入休眠状态以节省电源，这时候上/下行数据的发送都可能会被延迟，进行ping业务会造成时延变长。网管参数是E-UTRAN FDD小区表的参数：非GBR业务DRX使能开关。某商用外场局，在NGBR DRX打开和关闭前后进行ping对比测试，关闭DRX时ping平均时延减少了3~4ms。建议各商用外场局，在用户数量不多的时候将NGBR DRX开关关闭。

3.4无线环境对ping时延的影响

如果无线环境较差，或者无线环境的突然变化，都会造成空口发送的数据包解码错误而产生HARQ重传，重传一次的额外时延是8ms。

S1口传输时延分析方法

S1口时延指Ping Req从基站出去（发往UE需要Ping的服务器）->基站收到服务器返回的Ping Reply的时延，该段时延应该小于1ms，而不是单单指的基站与核心网的传输交互时延。

S1口时延测试有三种方法：

第一种、IP通道质量测试确定S1口时延 这个功能可实现通过在OMC客户端上进行操作，发起以“基站”做为ping操作的起点，对目标IP地址的IP通道质量通道检测。目标IP地址选择核心网MME或者SGW 的IP地址。正常情况下，从基站ping 核心网MME或者SGW的时延应该在1~2ms，如果偏大的话将会导致UE ping时延增大，需要联系传输侧排查S1口时延。第二种、Wireshark在基站VSWc2板debug口抓包确定传输时延 Telnet 192.254.1.16，并pad MGR.exe，登录到平台管理进程，敲入MirrorToDebug 0,0，在QE进行端口映射，然后开启wireshark，在CC板debug口抓包。在Ping之前，打开Wireshark工具，点击Capture捕获窗口，选择正确的interface,对应的服务器地址，在过滤栏指定IMCP消息，选择Update list of packets in real time。使用完成之后使用Bsp ClearE SwitchMirror清除镜像，以免出现其他问题。在Inter Control Message Protocol里：Sequencen number:确定该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把记录的LOG打开，并使用条件过滤：Ping包是32字节，在加了各个协议层的开销之后，在MAC层看到的就是在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。 基站侧内部处理时延正常的情况下，S1口时延为7ms-6ms=1ms。

3.5、预调度策略

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

控制面时延优化方法

4.1、随机接入基本过程

在小区搜索过程之后，UE 与小区取得了下行同步，因此 UE 能够接收下行数据。但 UE 只有与小区取得上行同步，才能进行上行传输。UE 通过随机接入过程（Random Access Procedure）与小区建立连接并取得上行同步。控制面时延主要关注接入过程中MSG1-5的时延。目前NR MSG1-MSG5的空口时间，在CPE的LMT上都可以看到，信令的slot号就是空口时间。

4.2 接入时延优化过程

4.2.1 时延目标流程

• msg1-msg2 实测 3ms 目标3ms

• msg2-msg3 实测 5ms 目标3ms

• msg3-msg4 实测17.5ms 目标6.5ms 需优化

• msg4-msg5 实测5.5ms，目标3.5ms

• 4.2.2 控制面时延的优化方案

  Msg1-Msg2  实测值与目标值一致，时延正常。 Msg2-Msg3  CPE收到msg2之后，CPE内部处理时间CPE Proc1太长，CPE侧进行进程优化，使得msg3提前了4个slot（2ms）出空口，从而满足时延要求。 Msg3-Msg4：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在310ms的位置启动，所以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+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资源，此过程是一个串行过程，必须等到hrrm回应才行（实际可以做成并行的过程，或者这做成预调度srb1的过程），之后发上下文消息，然后发msg4，最后给sts发uecontextconfig。一开始的实现是msg4和上下文的顺序是随机的，但是UC->MCC->SPA配置上下文的时间很长，如果先发上下文，再发msg4可以节约时间，前提是这三条消息都是并行发送的。对于平台OP操作的时延很长的解决办法是绑核，绑核的目的是为了减少任务间核的切换，每切换一次需要重新catch一次，相当于重新读取代码的过程，这样很耗时间，核排他的目的是为了减少其他优先级高的任务的抢占，因为任务都是在核上面跑的。Msg4-msg5CPE Proc2（从接收到MSG4 到 准备接收MSG5的DCI0）的处理时间（1ms）足够，但基站侧dci0下发时间晚了2ms，RAC修改处理过程，msg4收到之后不推迟4个slot，只推迟2个slot就可以发送，这样使得msg5的DCI0在U slot上下发给CPE（每个U slot上带一个pdcch），从而msg5能够在下发DCI0后的第四个slot出空口。

典型案例

当ping包时延超过4ms不达标，优化方法如下：具体步骤

1. 以基站为起点，排查到基站网关的时延，平均时延为0ms。

2. 以基站为起点，排查到EPC的X-GW时延，平均时延为11ms。从排查结果看，问题主要在IPRAN出口到核心网之间，这一段的平均时延达到了11ms，明显偏大。从上面的分析结果看，单站验证中发现的ping时延过大问题，主要是传输导致，时延的大部分是在IPRAN出口到核心网之间，光缆ODF接触不良导致了传输时延大，经整改后恢复正常。