利用RTP包分析提升VoLTE感知方法.docx

利用RTP包分析提升VoLTE感知方法.docx

《利用RTP包分析提升VoLTE感知方法.docx》由会员分享，可在线阅读，更多相关《利用RTP包分析提升VoLTE感知方法.docx（11页珍藏版）》请在冰豆网上搜索。

利用RTP包分析提升VoLTE感知方法

利用RTP包分析提升VOLTE感知方法

一、【背景】

常见的语音感知问题有单通、断续、音质差、掉话等，Volte投诉的主要问题也将会是这些，导致以上问题的原因大都与RTP丢包、时延及抖动有关。

众所周知，Volte感知需要通过端到端来界定分析，但目前电信网络中已具备端到端分析的省市尚不多，因此本文拟从无线侧分析UE测试log和基站S1口抓包来界定问题边界，对RTP包的丢包、时延和抖动等指标来进行语音感知分析，最后结合案例来介绍无线侧分析RTP包方法。

二、【问题描述】

在用三星S7做VoLTE测试时，主叫手机在接通后过了20S主动上发Bye，Reason：

RTP-RTCPTimeout（从sip-Ack到byerequest时长为20S），导致掉线。

在主叫事件窗口中出现MOSSingleMute，无MOS打分数值。

如下图所示：

三、【RTP分析方法】

3.1RTP包简介

RTP是实时传输协议，是Volte语音应用层使用协议，语音数据以如下结构进行发送。

其中IP首部是IPV4时为20Byte，IPV6则为40Byte；UDP首部为8Byte；RTP首部为12Byte，RTP数据部分大小与编码速率及是否为静默帧有关。

RTP首部格式如下，在分析中常用到序号、时间戳、同步源标识符等。

其中序号是指RTP报文的序列号，每发送一个报文就增加1，接收端通过序列号来检测报文丢失情况（丢包）。

时间戳用来计算时延和抖动，与抽样频率有关，每个语音流以随机数开始，若抽样频率为16K，则两个相连RTP包之间差16000/（1000/20）=320，两个SID帧差16000/（1000/160）=2560。

RTP数据包即语音包，其大小与语音帧类型以及编码方式有关，如下为AMR-WB的各类型的包大小。

静默期以160ms为周期进行传送（SID帧，大小是7Byte）。

通话期以20ms周期进行传送，其大小取决于编码速率。

以目前常见AMR-WB编码速率23.85kbps为例，其大小为23.85kbps*20ms=477bit，加上填充位和帧类型等，其大小为61Byte。

在无线侧分析语音感知问题时，通常分析到UDP层，因此，常见的2种类型UDP包大小分别是81B（对应23.85kbps）=61（RTP包大小）+12（RTP首部大小）+8（UDP首部大小），和27B（对应SID帧）=7（SID帧）+12（RTP首部）+8（UDP首部），其内容如下：

红框内容是分析时主要关注的信息，比如RTP包的方向，directiion=1是UEToNetwork，即上行；directiion=0是NetWorkToUE，即下行。

还有Marker=1代表语音包的起始等等。

通过对比发送端和接收端的RTP包，即可得到RTP丢包、时延及抖动等数据，从而对语音感知进行分析。

下面从UE侧和基站侧分别进行RTP包分析。

3.2UE侧分析方法

通过高通的QXDM或者鼎利的Pioneer可以收集UE的L1信息，查看IMSRTPSNandPayload内容，可以对UE侧的RTP包进行分析。

下面以Pioneer为例，在测试前，先按下图所示顺序进行设置，在软件右上角菜单里点击下拉，选择配置，再选择配置管理，在弹出窗口里选择高级，把手机信令保存设置勾选上，再点击确认即可。

设置好后就可以进行测试了，测试结束，打开测试log，在信令窗口，点击漏斗，把L1点亮，再在空白处点击下，即信令窗口会显示L1和L3内容。

然后点击查询，输入IMSRTP，弹出下来窗口，选择IMSRTPSNandPayload，双击后，再选择过滤，即把IMSRTPSNandPayload过滤出来了。

然后，双击IMSRTPSNandPayload，即可看到RTP包里的内容，如下所示。

在分析时，可以针对问题出现时的RTP包情况进行针对性分析，另外，软件也支持RTP丢包的统计，见IMSRTPPacketLoss，里面有丢包的内容。

另外，也可以把以上内容导出Excle来进行分析，方法如下：

选择菜单，选择文件，点击导出数据。

弹出如下窗口，若已设置好导出模板，则在模板设置里选择模板，然后在添加里把需要导出的log选中，点击导出即可输出excle表。

若没有设置过模板，则点击设置后，在弹出窗口中，在参数选择里把需要输出的参数放到已选参数里，然后在模板里输入模板名称，点击保存即可。

输出excel表内容格式如下，可以针对excle内容进行作图分析，可以按需输出，下面这个模板里有丢包、抖动、RTPSequence、RTPFrameType等等信息，也可以到Pioneer安装目录，直接把插件文件放到ExportTemplate目录下。

3.3基站侧分析方法

Volte的SIP信令以及RTP包在基站侧都是IPSec封装的，在基站侧通过TcpDump，可以把S1口的内容都抓取下来，然后通过Wireshark来打开。

S1抓包内容如下图所示，可以通过输入ESP来过滤SIP信令，也可以通过IPv6和Stream号来过滤呼叫流程，然后对基站侧的RTP包与UE侧的RTP包进行关联分析，从而判断是核心网部分出问题，还是无线侧出问题。

SIP信令在基站内虽然是封装的，但在二进制里还是可以看到其详细内容的，里面有每条SIP信令的内容，比如From/To，CallID等，因此可以与空口内容进行关联。

此外，也有第三方软件”流鲨FlowShark”，可以对S1抓包内容进行解码，可以按照呼叫流程显示，这就方便与空口内容进行关联比对了。

四、【问题分析处理】

4.1问题分析

单通在RTP包上可以表现为某段时间内只有单方向的RTP包，包括SID帧，目前鼎利软件是5S内只有单向包时，会判断为SigleMute。

若连续20S时间单通的话，则会触发UE侧计时器超时，上发Bye来拆链，形成掉话，Cause：

RTP-RCTPTimeout（或者inactietimeout）。

断续或质差，通常是RTP有丢包或抖动较大，通常连续丢3个RTP就会出现吞字现象，而连续吞多个字就出现断续现象。

4.2单通且20S后掉话（RTPTimeout）

主被叫手机无线环境尚可，主被叫占用是PCI73/74，RSRP在-100dBm左右，SINR在6~10dB之间

主叫于16:

07:

09.851从PCI=73切换到74，被叫于16:

07:

01.301从74切换到73，被叫于16:

07:

04.438MOS打分4.233，MOS打分周期是8S，即从16:

06:

56开始，从主叫放音，然后被叫进行MOS打分，此时被叫分别占用过PCI74和73，上下行均正常。

随后被叫放音，主叫打分，在此期间，主叫从PCI73切换到74，到打分周期结束，主叫显示MOSSingleMute（即单通），无MOS分，随后20S后主叫手机主动上发Bye（RTP-RTCPTimeout）。

下一次呼叫，主叫占用74，被叫占用73，主被叫正常MOS打分，通话正常。

从RTP包来进一步分析：

主叫在接通后先占用PCI73，还没开始切换，先开始放音，被叫录音，如下图所示，主叫16:

06:

54.950（UEToNetworkd）端口765455，RTPTimestamp1728，FrameType=8（23.85kbps），即主叫上发23.85kpbs的语言帧，连续7个，第8个为SID帧（16:

06:

55.153），RTPTimestamp3968（=1728+7*320）。

被叫从16:

06:

55.013收到第一个主叫发的语言包，连续7个（到16:

06:

55.122）,第8个是SID帧。

以上可以说明主叫上发的语言帧，被叫都收到了。

随后，被叫上发了SID帧（端口767478），查看主叫流程，并没有收到。

因此，说明主叫只有上行RTP包，没有下行RTP包，即单通。

再看主叫从PCI73切换到PCI74之后，被叫此时也已从PCI74切换到PCI73的RTP包，此时应该是被叫放音，主叫录音。

主叫一直在向Network发SID帧，如下图，16:

07:

09.773与16:

07:

09.976（RTPTimestamp243968-241408=2560=8*320），被叫可以收到这2个主叫发的SID帧，时间是16:

07:

09.991到16:

07:

10.132，在此期间，被叫上发了7个23.85kbps的语音帧，但主叫在此期间只有上行的SID帧，没有下行的RTP包，这也说明在切换后占用不同小区时，主叫仍然是上行正常，下行没有RTP包，即单通。

以上是Pioneer软件里查看的信息，还可以用前面的导出模板导出csv文件进行作图。

如下图所示，UE1是主叫，UE2是被叫，对主被叫的上下行RTPSequence以及Payload进行作图，其中Payload=73对应23.85kbps的语音包，Payload=19对应SID帧。

RTPSequence按顺序递增，可以看到主叫UE1在开始时间段只有上行RTP包，没有下行RTP包，到16:

07:

45之后才有下行RTP包，而同样时间段，被叫UE2上下行RTP包都有，这是正常的，因此从主被叫的2张图可以看出主叫的下行无RTP包，形成单通。

Payload=73是23.85kbps语音包

录音间隙，上下行都是SID帧

由于测试时并未进行基站侧S1抓包，因此尚无法完全确定是核心网问题还是无线侧问题，后续测试还遇到过1次，但也未同时进行S1抓包。

专门安排复测并未复现。

4.3断续或质差问题

如下图所示，被叫UE2在16:

08:

59.652和16:

09:

15.613时，MOS打分仅2.626和2.56。

此时RSRP-100dBm，SINR11.9dB，在信令窗口过滤L1的IMSRTPPacketLoss，可以看到16:

08:

53.138的RTPPacketLoss显示有14个RTP包丢了，在16:

09:

13.006时也有14个RTP包丢了，中间一次丢了1个RTP包。

再把VoiceRFC1889Jitter用Table表显示，可以看到对应时段的抖动情况尚好，packetdelay也好，因此，可以判断主要是被叫的下行RTP丢包影响了MOS值，需要结合基站侧的S1抓包，看基站侧是否也存在下行RTP丢包。

五、【问题总结】

通过Pioneer的UElog以及基站侧的S1抓包的关联进行RTP包分析，可以用来分析Volte语音感知中的单通、断续或质差等问题。

另外，从Pioneer导出的CSV文件作图，可以清晰看出单通问题。