案例-VoLTE RTP丢包分析方法研究
VoLTERTP丢包分析方法研究【摘 要】VOLTE语音业务在网络中传输的时候会受到时延、丢包、抖动、编码速率等因素的影响，造成语音的不连续甚至中断现象，从而降低了用户的使用感知。丢包率的形成原因主要跟网络的拥塞程度、无线环境相关，当网络流量越大、无线环境越差，影响就越明显，丢包率也就越大。通过分析主被叫的QCAT信令，可以详细分析是上行丢包还是下行丢包、是主叫的原因还是被叫的原因，以及发现当前网络问题针对性的进行处理优化VLOTE用户感知。【关键字】VOLTE、丢包分析、QCAT1 概述VOLTE语音业务在网络中传输的时候会受到时延、丢包、抖动、编码速率等因素的影响，造成语音的不连续甚至中断现象，从而降低了用户的使用感知。丢包率的形成原因主要跟网络的拥塞程度、无线环境相关，当网络流量越大、无线环境越差，影响就越明显，丢包率也就越大。通过分析主被叫的QCAT信令，可以详细分析是上行丢包还是下行丢包、是主叫的原因还是被叫的原因，以及发现当前网络问题针对性的进行处理优化VLOTE用户感知。本文档主要针对VoLTE RTP丢包的进行分析进行RTP丢包定界以及的定位。1.1 RTP包传输流程以本端UE接收的下行RTP包为例，RTP包从对端UE上行传输至对端eNB，经过传输核心网等，再从本端eNB下发至本端UE。对端UE接收的下行RTP包流程则刚好相反。当本端UE接收的下行RTP包存在丢包时，整个包传输流程的任何一个环节都有可能丢包。丢包定界的一个重要依据是，PDCP协议是eNB和UE间的协议，与对端无关。即当本端eNB收到对端的RTP包后，重新进行PDCP SN编号，而不管对端传输过来的RTP包SN是否连续。2 RTP丢包分析方法MOS低的时段，大部分都是因为RTP丢包导致，而RTP丢包一般分为两种，RTP NETWORK LOSS和QDJ UNDERFLOW，前者是真的丢包，后者是接收到对应的RTP包，但是因为接收时延太大，因VoLTE语音通话的实时性原因被UE丢弃了。RTP NETWORK LOSS是丢包的主要原因，因此以下分析将针对RTP NETWORK LOSS。2.1 下行RTP丢包定位导出本端UE log的RTP包SN号并筛选出下行RTP丢包处，导出RTP包SN号的方法有很多，如鼎利软件、QCAT或其他工具。高通QCAT软件可以通过IMS RTP SN and Payload字段筛选出RTP包信息，可另存为txt格式然后把RTP SN信息绘制成EXCEL格式：如下图是导出来的下行RTP包（方向为network-to-ue即为下行RTP包）SN号的信息，其中最后一列为SN序号相减的结果，可以看到Ssrc = 87E84FCF的SN = 17641768之间丢包了：2.2 判断本端无线侧问题RTP丢包时刻下行PDCP SN连续，则是传输丢包或者对端上行弃包或丢包，PDCP SN不连续则为本端下行丢包。（偶有两端同时丢包）打开本端UE log对应的MDM文件，过滤IMS RTP SN and Payload，找到上述丢包问题点对应的时刻RTP包的信息：再过滤LTE PDCP DL Cipher Data PDU，打开对应RTP包的PDCP信息。RTP包和PDCP包的打印一般相邻，若是不确定的话，可以通过激活器静默期RTP包大小和PDCP包大小及激活静默期的转化进行对应，如激活器RTP包是73byte，对应PDCP包大小是68byte左右或者更大，静默期19byte，对应PDCP包大小是12byte左右或者更大。从下图可以看到，SN=1764和SN=1768对应的PDCP SN号是连续的，因此可以判定为传输核心网丢包或者对端上行弃包等，本端下行没问题。需注意的是，RTP包对应的PDCP模式为UM模式。2.3 判断对端上行弃包原因若是根据上述流程判断本端下行没问题（丢包处PDCP SN连续），则打开对端的UE log，过滤IMS RTP SN and Payload，找到对应的上行RTP包，Direction = UE_TO_NETWORK。再过滤LTE PDCP UL Statistics Pkt，查看问题点后的PDCP统计数据中是否有弃包。如下图，可以看到对应RTP包后的LTE PDCP UL Statistics Pkt中，UM模式下Num Discard SDU=3，则说明此丢包的原因是对端上行弃3包：再过滤LTE PUSCH Power Control，看上行发射功率。从下图可以看到PUSCH为满功率发射（最大为23dBm），说明可能有干扰。一般PUSCH Actual Tx Power-DL Path Loss=-105-115是比较合理的。另外若是上行没有弃包时，还可以看上行有没有HARQFail。过滤LTE LL1 PUSCH Tx Report，看问题对应时刻是否有重传，即每隔一帧有first、second、third、fourth传输，说明是不断重传，即上行有HARQFail。上行HARQFail的原因也可以查看LTE PUSCH Power Control是否可能有干扰：2.4 判断本端下行丢包原因如下表为本端UE的另一处丢包，可以看到Ssrc = EF4308D2的SN=23042305的RTP包丢了：同样过滤IMS RTP SN and Payload，找到丢包问题点：过滤LTE PDCP DL Cipher Data PDU，可以看到问题点对应的PDCP SN（UM模式）缺了77、78两包，则说明是本端下行丢包：看PDCP SN=7679对应的帧号子帧号为772/5和784/5，过滤LTE PDSCH Stat Indication，看772/5和784/5之间是否存在HARQFail。从下图可以看到，问题点对应确实连续的HARQFail：下行HARQFail的原因，主要看下行的RSRP和SINR。过滤LTE ML1 Serving Cell Meas Response即可看到RSRP和SINR信息。3 总结通过从端到端的角度考虑，在每一协议层的主要参数配置及测试信令进行详细说明，结合分析每一协议层的信令，可以找出E2E的丢包产生的过程及原因，以实现更加精准的优化。
