Ping时延问题分析指导v1.docx
《Ping时延问题分析指导v1.docx》由会员分享，可在线阅读，更多相关《Ping时延问题分析指导v1.docx（19页珍藏版）》请在冰豆网上搜索。
Ping时延问题分析指导v1
PING时延分析指导书
1概述
联通比拼前，各局点都会进行大量的拉网测试，数据分析量非常巨大，为了保证大多数问题能在一线快速隔离定位，从而不影响各局点的网络优化进度，提高效率。
本文将针对联通路测的数据，给出简单可行的问题排查指导书，从而指导一线快速发现问题，实现简单问题及时闭环，复杂问题及时响应。
2数据反馈模板
2.1版本和测试工具反馈
排查名称
实际使用版本
备注
版本排查
eNodeB版本
Probe版本
Assistant版本
终端、便携、服务器
终端类型
便携型号
便携TCP窗口大小
服务器接收窗口大小
2.2Ping时延影响特性参数反馈输出件
参数名称
参数字段名
参数影响
建议值
实际值
预调度开关
PreAllocationSwitch
1）通常情况下预调度为默认开启特性，有利于ping时延性能；
ON（打开）
2）但由于上行预调度增加了基站主动调度UE的次数，在上行总业务量不变的场景下，eNodeB统计的上行平均用户吞吐率（上行平均用户吞吐率=上行吞吐量/上行数据传输的时长）会随之下降，导致话统每用户上行速率偏低。
同时增加上行PRB开销，还会降低上行频谱效率；
3）由于增加了基站主动调度UE次数，会增加UE的耗电。
用户预调度数据量
PreAllocationSize
小文件TCP吞吐量测试时，增大预调度数据量，减小预调度周期，能减小空口时延，提升TCP吞吐量；但是会减少小区容量和增大对邻区的上行干扰；
80
预调度用户最小间隔周期
PreAllocationMinPeriod
5
DRX特性开关
DrxAlgSwitch
DRX开启后，UE进入预调度状态的概率大大降低，不利于ping时延的性能；
根据局点特性规划确定是否打开。
同时对于eRAN3.0SPC384版本前的counter统计方式，会将T_Lat_DL时长纳入到用户时长统计中，导致话统每用户下行速率偏低；
此外，DRX模式下会存在SR虚警严重的现象，大量浪费CCE和上行PRB资源，影响话统上行用户速率和上行频谱效率。
智能预调度
SmartPreAllocationSwitch
在DRX特性开启情况下，打开智能预调度开关能弥补DRX开启后预调度退出带来的影响，提升UE进入预调度的概率，有利于Ping时延性能的提升
如果局点开启DRX，建议打开
智能预调度每次持续时间
SmartPreAllocationDuration
1、增大此参数，能改善环回时延，对于单线程TCP速率受限场景，可改善TCP的最大速率；
0/1500
2、但是该值越大，系统资源浪费越多。
3、对于1秒间隔的ping时延测试，建议设置为1500；对于100ms间隔，建议设置为200ms
RB优先MCS选择概率门限（降阶扩RB特性开关）
RBPriMcsSelectRatioThd
降阶扩RB功能特性设置和门限开关，该参数在eRAN3.0无效写死为10%，eRAN6.0有效可用户修改。
10
1）设置为0即关闭扩RB降阶功能，设置为100为始终进行降阶扩RB调度；
2）降阶扩RB特性有利于减少下行误包率，减少重传概率，并且避免小包因RBG向下取整时带来的分片影响，从而有利于话统下行速率的提升。
3）由于下行包重传概率减少，有利于ping时延性能的提升；
3）由于比普通调度方式消耗了更多的PRB资源，会导致下行频谱效率下降。
4）商用场景下，建议该值不要设置过大。
上行CoMP算法开关
UlCompSwitch
1）ULCoMP功能会选择符合条件的UE进行两小区天线的联合接收，所以对进行了CoMP的UE来说，小区间边缘可以获得比普通UE更好的上行性能。
根据局点特性规划确定是否打开。
2）边缘上行性能的提升有利于移动场景下远点Ping性能的提升
开启前从问题规避指导书确认该特性是否存在已知问题；
接收机特性开关
MrcIrcAdptSwitch
设置成DISABLE时为MRC接收机（默认情况），ENABLE时为IRC接收机。
Enable
IRC接收机（需要license）的增益有两个方面：
干扰对消效率高、保持平稳的虚警概率。
IRC开启后有利于提升小区边缘上行解调性能，有利于Ping时延性能的提升。
2.3Ping测试整体测试结果反馈
PingSize
TargetIP
Average
Max
Min
LossRate（%）
Pathloss
RSRP
32Byte
1000Byte
1500Byte
3000Byte
2.4传输时延坏点反馈
传输时延坏点反馈
编号
requesttime
replytime
loopdelay
1
2
3
4
5
2.5空口时延坏点反馈
空口时延坏点反馈
编号
3.SRISFN
4.ULGrantSFN
5.ULDataSFN
6.DLDataSFN
3-4
4-5
5-6
1
2
3
4
5
3数据分析指导
3.1Ping时延总体分析
如果是通过便携机的CMD命令PING来执行的话，可以通过直接保存结果，或者在终端侧直接抓包获取PING的结果。
但通过Probe设置的PING任务，可以再ASSTANT工具中吐出PING的详细结果和统计信息。
由于在分析的过程中需要对当前的SINR或者Pathloss的关系曲线进行对比分析，所以需要关联SINR和PathLoss的数据，但是由于SINR和PathLoss的信息无法与PING信息在同一个SHEET上显示，所以需要通过分别导出PING统计页与SINR和PathLoss统计页，然后根据PING统计中的时间（秒级）点去VLOOKUP在SINR和PathLoss页中的信息。
3.2Ping时延分段
在了解了PING时延的大体情况之后，可以进一步分析传输时延和空口时延分别耗时是多少。
可以通过IFTS149跟踪获取eNBPDCP到Server的环回时延。
149跟踪仅支持IFTS和基于IMSI的IFTS跟踪，不支持CellDT跟踪，149跟踪会记录Ping包和PingReply包在PDCP的时间戳等信息，通过将PingReply包减去Ping包获得PDCP至Server的环回时延。
相同Identifer意味这是同一个ping的发包和reply包。
Ping包类型将ping包区分为request和reply包。
usFrmucSubFrm对应帧号，子帧号。
RoopTime人工处理新增列，使用reply包的时间戳减去ping包时间戳获得eNBPDCP至Server的环回时延。
从149跟踪就可以分段隔离出空口以为的传输侧的时延，然后把总时延减去传输侧时延则就是空口的时延了。
当然也可以通过PDCP的UE侧LOG直接来计算空口时延。
3.3传输时延
同运营商，不同友商之间的比拼。
PING的目标服务器尽量选择运营商内部的服务器，减少外部传输干扰对PING时延测试结果的影响。
确认比拼测试的PING测试选择的路由和经过的传输设备大致相同。
可以通过TRACERT命令显示当前的路由信息，进行路由和跳数的对比。
如果发现是由于传输时延导致的PING时延结果差，就需要重点排查传输原因了，例如MTU分片设置，或者是传输的重传、丢包造成。
可以通过使用TRACERT来初步确认有哪些可见节点，但是部分传输设备对TRACERT的协议是不可见的，就需要向客户了解传输拓扑，配合来分段检查各个节点之间的时延。
通过节点抓包，查看PING的包是否一丢包乱序现象（GTP隧道下，ICMP协议）。
3.4空口时延
从之前的分析结果,可以获得空口时延:
空口时延=PING总时延—传输时延
空口时延的基线值为7~8ms。
空口时延具体分段分析需要借助QXDM的LOG，或者可以把Probe的LOG转化成QXDM的文件（LOG不全），然后逐段分析空口侧的用户面时延。
点1为终端应用层发起PING包的时间点；
点2为终端无线的L1模块收到PING包并准备在空口发送的时间点；
点3为终端在SR时机发送SR的时间点（SR周期由eNodeB配置，可通过L3信令查到，以10ms为例,则点2到点3约有1到10毫秒时延）；
点4为基站收到SR后ULGRANT的时间，点3到点4一般为3到4毫秒，但如果SR存在重传，则此处增加一个SR周期；
点5为上行PING包在PUSCH发送的时间，点4到点5为4毫秒。
如果是PING大包，包长超过SR调度的TBsize，则PING包需要分片，会增加7到8毫秒时延；如果是PING大包且用户在远点，则由于MCS阶数和RB数的限制，可能需要多次分片。
如果上行调度存在重传，则重传会增加n*8毫秒时延（n为重传次数）；
点5到点6为上行最后一个分片到达基站基带和下行第一个分片在基站基带下发的时间，包含上行包和下行包在基站内部传递的时延（L1-L2-GTPU，下行反过来），根据经验测试数据，基站内部的处理时延约为4毫秒，在实验室场景，PING包从S1口以上到核心网再到PING服务器一个环回的时延小于等于1毫秒，商用网会因为传输、友商核心网、服务器等原因这部分会比较大，要重点关注。
点7为下行终端收到最后一个PING包分片的时延，要关注下行PING包是否有重传以及是否有分片。
点8为终端应用层收到PING包的时间点。
QXDMLOG能记录点3、4、5、6、7的时间点，而PING工具可以输出1到8的总时延，两者相减可以得到1～3＋7～8的时延。
通过这些信息，基本上可以隔离出在哪个子段PING时延存在异常。
实际分析时，空口的调度过程还存在其它一些过程会干扰分析，主要有如下过程：
1、PING包在RLC层的ACK包也会触发上下行调度过程；
2、下行存在TA的定时调整调度；
3、便携和服务器的一些杂包；
4、有些局点开通了预调度或智能预调度会主动触发上行调度过程；
5、有些局点没有使用SRS，存在周期性的上行TA调度；
由于PING包的如下特殊性，可根据PING包的大小和周期性来过滤出PING包。
PING包大小：
PING包在各层的大小等于PING字节数再加上各层的协议包头，比如以PING32字节和PING1400字节为例，如左下图所示，加上IP包头和ICMP包头，包长分别达到60和1428字节，再加上PDCP包头（以PDCPSN12bit为例，默认设置，如右下图所示，PDCP包头为2字节），PDCP层的包长达到62和1430字节。
图：
PING包的包结构图：
PDCP包结构
周期固定：
如果PING业务不是使用特殊工具的话，默认每秒一个PING包。
第一步：
通过PDCP层过滤PING包确定PING时间点
以终端PING服务器32字节为例，使用MYQXDM工具解析QXDM文件，打开“LTEPDCPDLCipherDataPDU”和“LTEPDCPULCipherDataPDU”文件，过滤包长为62的PDCP包，能够将所有PING32的包过滤出来，QXDM解析文件中包含了每个包的具体时间，在上行PING包解析结果中，还包含了空口调度时的帧号/子帧号（如果碰巧有杂包的长度也为62字节，可以通过PING包每秒1次这个周期特征进一步过滤），下面以第一个包为例，分析整个调度过程。
PDCP层上行PING包PDCP层下行PING包
第二步：
分析SR/ULGRANT/PUSCH等过程
点3SR上报时间点：
第一个PING包的时间点为10：
03：
40左右，对应上行空口PUSCH的帧号/子帧号为993/3。
打开“LTEGMTXReport”文件，过滤其中的PUCCH项目，然后过滤“SchedulingRequestPresent”为Present，就可以得到终端侧在哪些帧号/子帧号上发送了SR，找到和上行PING包最接近的一次SR，帧号/子帧号为992/6。
由于此次SR更前的一次SR相隔较远，所以确认这次SR是初传SR。
点4ULGrant时间点：
在“LTELL1PDCCHDecodingResult”文件中，通过对应时间点和帧号/子帧号，找到这次PING包对应的ULGRANT帧号/子帧号为992/9；
点5PUSCH时间点：
在“LTELL1PUSCHTxReport”文件中，通过对应时间点和帧号/子帧号，找到这次PING包对应的PUSCH，帧号/子帧号为993/3，4个RB，调制方式为16QAM，TBsize为217字节。
并且8毫秒后不存在重传，说明这次PUCSH一次传对（也可以通过PHICH来直接确认）。
第三步：
分析下行ping回包的发数过程
点6PDSCH时间点：
在“LTEPDSCHStatIndication”文件中，通过对应时间点和帧号/子帧号，找到这次PING包下行的回包，但有两次调度时间比较接近，分别是993/7和994/7，由于这两次都是双码字调度，总的TBSize分别为44和88字节，如前面介绍，PING32字节在PDCP层已经为62字节，到MAC后应该比这个要大（增加了RLC和MAC头），所以基本上排除了993/7这次调度。
另外从RLCDLAMALLPDU跟踪项中，也可以确认出993/7这次调度是对上行PING包在RLC层的ACK，而994/7这次调度是下行PING包在空口的调度。
通过CRC结果还可以确认这次初传就传对了。
第四步：
确认每个子过程的时长
将上述过程分析结果汇总在一张图上，如下图所示：
可以看出，3、4、5、6等子过程都不存在重传，没有优化空间。
而5到6之间达到14ms，比实验室基线（实验室基线约为5ms）要大很多，说明S1口以上引入较大时延，主要怀疑S1传输时延，可以通过其它方法来证明（比如CELLDT149跟踪或基站PINGUGW）。
另外1－>3以及7－>8这几个子过程时延之和达到13ms（34-21），从L3信令可以知道，该用户的SR周期为10毫秒，多次测试2－>3的时延均值应为5毫秒，但每次测试会有一定的波动性，1－>2以及7－>8为终端内部处理时延，应该在1～3毫秒左右，所以可以通过多次测试统计来确认这几段时延是否存在问题。
升级会员 