VoLTE业务资料VoLTE问题案例集

VoLTE网上问题案例集文档版本V1.0发布日期xxxx-01-28VoLTE网上问题案例集文档版本DOCPROPERTYDocumentVersionV1.0(DATE\@"yyyy-MM-dd"2017-08-25)第页修订记录Date日期RevisionVersion修订版本CRIDCR号SectionNumber修改章节ChangeDescription修改描述Author作者xxxx-01-22V1.0初稿完成xxxx00130333目录TOC\o"1-2"\h\z\u1 导读 42 语音呼叫类问题 52.1 呼叫失败 52.2 单通 313 语音质量类问题 583.1 语音质量差 584 语音增强特性类问题 594.1 RoHC 594.2 TTI_Bundling 664.3 SPS 70

导读本文根据以往网上问题整理VoLTE相关问题的相关案例，在处理网上语音问题时，可以先翻阅本文相关案例，以拓展思路并缩小问题范围，最终提升问题定位效率。本文所包含案例包括从各产品收集到的历史案例，以及GTACVoLTE专题组启动后处理的问题提取出来的案例，在案例格式上有些差异，后续逐步统一。本文档会逐步完善，新需求或建议，请联系xxxx00130333。

语音呼叫类问题呼叫失败案例1：英国VDF，VoLTE用户呼叫失败问题分析【问题描述】英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTEcall，在xx基站下必然失败；问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致不能通话；【问题分析】1.组网环境信息分析1.1VoLTE业务原理分析正常VoLTE业务流程分为以下几个过程：VoLTE终端完成TAUAttach流程建立QCI5承载；VoLTE终端发起IMS注册流程,注册使用的SIP信令使用QCI5承载；VoLTE终端发起语音呼叫，建立QCI1专有承载，语音媒体使用QCI1承载；VoLTE终端发起视频呼叫，建立QCI2专有承载，视频媒体使用QCI2承载；图1：正常VoLTE用户注册流程图2：正常VoLTE用户语音呼叫流程图3：VoLTE业务所使用的承载方式1.2网络拓扑分析11.18日下午，一线实验室复测抓取了S-PGWP-CSCF上的抓包。分析xx和爱立信基站下主要有如下两个差异点

1)xx基站下注册的终端是诺基亚，爱立信基站下注册的终端型号未知。2）注册到xx的register消息是通过TCP承载，且在TCP层有分包，对端SBC回503serviceunavailable，而注册到爱立信的register消息是UDP承载，无分包，对端SBC正常回复401。通过多次抓包和定点分析最终确定网络拓扑图如下：图4：英国VDF实验室组网图B2.分段隔离分析针对现场所有xx站点分析，现场总共有6个xx站点PTH100/101/102/104/110/112，而发现在xxPTH102站点(未配置IPSEC)进行测试，VoLTE业务有大概率60%左右成功率(剩余40%失败主要和核心网相关)，当时已经怀疑和IPSEC隧道(SeGW节点)强相关。进一步锁定在PTH112站点(配置IPSEC)分析，通过修改S1接口上链路，尝试旁路CPN和SeGW，并且修改IPSec加密算法为空加密等方案后，发现VoLTE业务均能建立成功，最终问题隔离到和IPSEC相关。2.1IPSec旁路方案一图5：IPSec旁路方案一安全网关SeGW旁路之后，基站配置不变，基站的下一跳地址配置到跟SGE比较靠近的路由器上，基站直接拉线到该路由器；VoLTE业务测试结果为OK。此旁路方案同PTH102站点，102站点没有配置IPSec，从102站点的S1用户面地址pingSpGW地址，8000字节的报文都可以ping通，整条链路没有报文大小限制。2.2IPSec旁路方案二图6：IPSec旁路方案二相对于方案一，方案二直接把在连接安全网关SeGW两端的路由器互联，基站配置不变；VoLTE业务测试结果为OK。2.3IPSec旁路方案三图7：IPSec旁路方案三方案三实际上没有改变组网，而是将基站和安全网关的IPSECPROPOSAL的加密算法设置为NULL，验证算法不改；VoLTE业务测试结果为失败。同时抓取路由器和安全网关两端报文，确认SIP_401消息已经从安全网关发送到基站；此时排查重点转移到基站，需要确认eNodeB是否成功转发401消息；3.eNodeB版本和配置以及话统分析检查eNodeB版本：BTS3900V100R009C00SPC160；检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；检查小区信号质量：正常；检查数传业务成功率：正常；检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，VoLTE均失败；检查话统话统来确认QCI5是否丢包：话统正常无丢包；CellDT和IFTS跟踪：确认eNodeB的PDCP和MAC层无丢包且调度正常；eNodeB跟踪CELLDT和终端侧QXDM数据分析从Celldt132跟踪看，有些时候VoLTE建立的时候QCI5的下行有数据包，有些时候又没有下行数据包。从CELLDT34看，下行都是ACK，说明空口发送QCI5数据时没有误码。终端侧QXDM看到，QCI5的RBID为2，该RB下行也收到了数据包，但有时这些数据包能到PDCP层，有些到不了PDCP层，但是SIP层都收不到，不确定这些数据包是否就是401消息。4.异常问题流程分析由于前期从英国VDF一线和罗马尼亚GTAC二线得到信息是终端收不到SIP_401消息，前后方重点都放在下行SIP_401丢失问题上，但是前面分析SeGW证实已经下发；而eNodeBeRAN7.0使用CellDT、IFTS、话统等都无法准确判断401是否从S1和UU接口转发，现场的终端Nokia和Sony也都不具备QXDM抓包条件；问题分析未能取得突破进展。为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个xx站点PTH112下面验证总共得到以下3种失败场景如下：Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；图9：Case1网络下发鉴权挑战401终端未收到Case2:Sony终端基于UDP的Register消息异常；图10：Case2Sony终端基于UDP的注册失败Case3:Nokia终端基于TCP的Register消息异常；图11：Case3Nokia终端基于TCP的注册失败根据以上3种失败场景，根据不同终端和网元节点跟踪定位分析确定如下失败模型；至此很明显最初得到的Case1所描述的失败类型是一个错误的判断，是因为Nokia和Sony终端不同的失败表现产生混淆导致：5.友商成功数据分析针对相同终端在IMS侧抓包，分别从E///站点和xx站点比较分析，发现E///站点和xx站点的Register和401Unauthorized消息没有明显差异；E///，从IMSCORE到SBCWWW-Authenticate:Digestnonce="6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="673C3B94B35314C9FE03432A239BA836",ik="FFD4EB7997DCB64E714184274286A155"AuthenticationScheme:DigestNonceValue:"6TbnQHPNBhWjXau/+X5Q3CTBZv5lNwAAogwDWpz3r+Y="Realm:"ims.vodafone.co.uk"Algorithm:AKAv1-MD5QOP:"auth"CypheringKey:"673C3B94B35314C9FE03432A239BA836"IntegrityKey:"FFD4EB7997DCB64E714184274286A155"E///，从SBC到UESecurity-Server:ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3407;spi-s=3408;port-c=6000;port-s=7000[Security-mechanism]:ipsec-3gppq=0.1alg:hmac-sha-1-96ealg:aes-cbcprot:espmod=transspi-c:3407(0x00000d4f)spi-s:3408(0x00000d50)port-c:6000port-s:7000Huawei从IMSCORE到SBCWWW-Authenticate:Digestnonce="+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ=",realm="ims.vodafone.co.uk",algorithm=AKAv1-MD5,qop="auth",ck="31ED1CC2BAE29058057070437894DBC0",ik="71CF825E807149738C7EF51A794D7FEF"AuthenticationScheme:DigestNonceValue:"+cF5iJzFh0c1ulqe4K+f0gqf1fC3WAAA2YG/KEDpHPQ="Realm:"ims.vodafone.co.uk"Algorithm:AKAv1-MD5QOP:"auth"CypheringKey:"31ED1CC2BAE29058057070437894DBC0"IntegrityKey:"71CF825E807149738C7EF51A794D7FEF"HUAWEI，从SBC到UESecurity-Server:ipsec-3gpp;q=0.1;alg=hmac-sha-1-96;ealg=aes-cbc;prot=esp;mod=trans;spi-c=3437;spi-s=3438;port-c=6000;port-s=7000[Security-mechanism]:ipsec-3gppq=0.1alg:hmac-sha-1-96ealg:aes-cbcprot:espmod=transspi-c:3437(0x00000d6d)spi-s:3438(0x00000d6e)port-c:6000port-s:7000至此，通过以上分析判断排除终端和核心网异常；而从P1点抓包来看也能够确认eNodeB成功转发了Register和401Unauthorized消息。6.诸点抓包分析通过xx站点和E///站点对比分析，已经明确问题出现在S1接口所连接设备上面，但是由于eRAN7.0版本(内部确认eRAN8.0以上版本可以)不具备SIP信令跟踪和足够的证据，来证明eNodeB成功转发SIP消息；即便我们能够证明PDCP和MAC无丢包且调度正常。根据现场组网信息启动网络逐点抓包隔离异常网元，开始尝试Ping不同大小报文并且抓包分析结果如下：对Nokia和Sony两款终端异常场景抓包分析发现P3段会丢弃大于1500Bytes的报文，统计数据结果如下：同时对Nokia和Sony两款终端在友商E///抓包分析发现报文在P3段传输固定为1420Bytes的报文，统计数据结果如下：至此，发现丢包问题最终锁定在P3(SeGW-->CPN)抓包段，并且此段只会丢弃大于1490Bytes的报文；而对比友商E///网络传送的1420Bytes报文能够成功传输；最终问题锁定在SeGW和CPN网元节点。7.UE侧问题分析7.1xxP7 现场使用的P7不支持VoLTE，临时升级到研发内部版本但是仍然测试失败;通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.对比协议，P7发送的register消息，是符合协议的，需联合IMS确认，其发送494的原因。RFC3329定义的SIP协商安全传输机制：2.Solution2.1OverviewofOperation

Themessageflowbelowillustrateshowthemechanismdefinedinthis

documentworks:

1.Clientclientlist>Server

2.Client<serverlistServer

3.Client(turnonsecurity)Server

4.Clientserverlist>Server

5.Client<okorerrorServer

Figure1:Securityagreementmessageflow.

Step1:

Clientswishingtousethisspecificationcansendalistoftheirsupportedsecuritymechanismsalongthefirstrequesttotheserver.

Step2:

Serverswishingtousethisspecificationcanchallengetheclienttoperformthesecurityagreementprocedure.

Thesecuritymechanismsandparameterssupportedbytheserveraresentalonginthischallenge.

Step3:

Theclientthenproceedstoselectthehighest-preferencesecuritymechanismtheyhaveincommonandtoturnontheselectedsecurity.

Step4:

Theclientcontactstheserveragain,nowusingtheselectedsecuritymechanism.

Theserver'slistofsupportedsecuritymechanismsisreturnedasaresponsetothechallenge.

Step5:

Theserververifiesitsownlistofsecuritymechanismsinordertoensurethattheoriginallisthadnotbeenmodified.协议RFC3329要求494必带Security-Server头域

AserverreceivinganunprotectedrequestthatcontainsaRequireorProxy-Requireheaderfieldwiththevalue"sec-agree"MUSTrespondtotheclientwitha494(SecurityAgreementRequired)response.

TheserverMUSTaddaSecurity-Serverheaderfieldtothisresponseistingthesecuritymechanismsthattheserversupports.

TheserverMUSTadditslisttotheresponseeveniftherearenocommonsecuritymechanismsintheclient'sandserver'slists.

Theserver'slistMUSTNOTdependonthecontentsoftheclient'slist.爱立信核心网回的494没有Security-ServerSIP/2.0494SecurityAgreementRequiredTo:<sip:234159136179274@>;tag=aprqngfrt-0fqlel2000020From:<sip:234159136179274@>;tag=Z3dcbqtCall-ID:Y2dcbqtET@6CSeq:1REGISTERVia:SIP/2.0/UDP6:5060;received=6;branch=z9hG4bKW4dcbqtETatET9aaaqJg;rport综上所述发现P7终端VoLTE业务失败原因为SIP协商安全传输机制失败，由于P7使用测试版本有可能不支持IPSec加密算法”ealg=null;”原因，导致友商E///的IMSCore直接拒绝；而P7终端在研发内部测试VoLTE业务成功，使用的是xxCN兼容性更高。7.2NokiaLumia830现场使用的Nokia终端，WindowsPhone操作系统Lumia系列手机；通过测试发现Nokia终端使用的SIP基于TCP承载，并且第一条Register消息的大分片报文为1360Bytes，第二条Register消息的大分片报文为1480Bytes；Nokia的MTU值通过信令判断为1480，具体配置待继续研究；7.3SonyXperiaZ2现场使用的Sony终端，安卓操作系统；通过测试发现Sony终端使用的SIP基于UDP承载，并且第一条Register消息的大分片报文为1500Bytes，第二条Register消息的大分片报文为1500Bytes；Nokia的MTU值通过信令判断为1500，具体配置待继续研究；8.eNodeB侧问题分析8.1xxeNodeB版本为BTS3900V100R009C00SPC160，此系列版本无SIP信令跟踪，并且不能基于CellDT和IFTS跟踪判断SIP消息；即eRAN7.0版本无有效定位SIP信令的手段。//已经确认eRAN8.0以上版本可跟踪SIP消息。通过对比xx和E///报文分析，发现MTU实现差异如下，xxeNodeB经过加密后在IPSEC以下IP层进行MTU(1500)分包；SeGW收到后会进行组包再解密，解密后如果报文大于SeGW的MTU设置会再次进行分片处理；8.2E///eNodeB 通过对比xx和E///报文分析，发现MTU实现差异如下，友商E///可以实现在IPSEC以上IP层进行MTU(1420)分包，即先将业务报文分片再进行独立加密传输；SeGW收到后对报文解密而不需要组包，这样避免了传输过程中再次组包和分片的操作；其IPSEC是通过独立单板实现；8.3NSNeNodeB NSNeNodeB暂时未抓取报文，但是相同组网其站点下业务能够成功说明其实现也有类似业务分片机制；NSN具体实现方式待后续验证9.传输问题分析根据现场网络拓扑和组网进行分段Ping包，能够快速进行分段隔离异常网元；通过现场测试不同大小报文的Ping结果，发现异常点主要集中在P3抓包点，而P3抓包点为SeGW—>CPN互联方向；P3点报文大于1490Bytes都被丢弃，而SeGW组包后解密再分片的小包能够正常传输，最初问题锁定在T5(SeGW)和T6(CPN)两个端点； 通过多次修改SeGW和CPN端口的MTU值尝试Ping包测试，并且结合现场CPN抓包镜像端口M，实际抓包端口M也是CPN物理端口，此端口M通过镜像T2/T3/T6/T7实现Wireshark抓包的，丢包点再次确认为T6(CPN)和T7(CPN)两个端点；即T6实际收到报文且出现异常丢弃导致没有发送给镜像端口M。再次检查整条链路中各节点MTU配置，统一修改eNodeB(T1)、T2、T3、T4、T5、T6、T7MTU为1700Bytes，再次检查SeGW的PathMTU为1700；最终Ping报文1601Bytes能够成功，验证VoLTE业务成功。Ping结果如下：【问题根因】问题结论简述：现象为VoLTE用户注册失败，上行传输网络有大包限制和丢弃问题；处理问题过程中发现eRAN7.0BTS3900V100R009C00SPC160版本存在两点不足：1）、eRAN7.0以前版本不支持SIP信令跟踪，缺乏有效手段定位SIP消息转发情况；2）、xxeNodeB对不支持按照业务报文分片处理，虽然符合协议但是与友商灵活实现机制相比；xxeNodeB实现方式优势：可以减少传输网络负荷，提高传输效率；xxeNodeB实现方式缺点：安全网关SeGW需要组包，增加对组网传输网路MTU限制的要求；RFC:791【解决方案】解决英国VDF的VoLTE问题，根据现场诉求提供两种方案：方案1）、建议现场检查全网设备节点的MTU设置，通过Ping报文确认S1口(eNodeB-->SpGW)能够ping通至少1600Bytes报文；研发根据现场组网提供推荐配置和现场实际成功配置如下：方案2）、xxeNodeB根据现场诉求实现按照业务报文分片处理功能，待最终讨论确认正式版本；案例2：iphone6做主叫VoLTE呼叫失败问题分析【问题描述】西研实验室进行iphone6VoLTE测试，iphone6VoLTESIPRegistration成功，但iphone6作为主叫呼叫P7，呼叫失败；而P7呼叫iphone6是正常的。【问题分析】1、根据问题现象，属于VoLTE呼叫建立失败问题，这类问题，从语音核心网IMS侧入手分析VoLTE呼叫控制面SIP信令效率较高。eNodeB/S-GW/P-GW主要负责将SIP信令（承载在QCI5EPSbearer上）在UE和P-CSCF间正确转发，如下为LTE终端与LTE终端呼叫示意图，其中，黑色虚线为VoLTE呼叫建立所涉及到的网元：流程简述：LTE用户发起呼叫。MMTelAS执行主叫业务处理。完成主叫业务处理后，MMTelAS将呼叫路由回S-CSCF；S-CSCF查询ENUM，并将呼叫路由到被叫。在被叫侧，呼叫被路由到向被叫用户提供业务的I-CSCF，I-CSCF发送呼叫请求到S-CSCF。MMTelAS执行被叫业务处理后，MMTelAS将呼叫路由回S-CSCF；S-CSCF触发SCCAS进行域选（即选择被叫落地的域），选择LTE网络接入被叫用户。S-CSCF将呼叫请求通过P-CSCF接续到被叫用户。承载建立。2、如下为测试同事在SBC侧镜像抓包采集的log：从上面可以看出，当Iphone6发起VoLTE呼叫时，Iphone6先触发建立TCPconnection，但SBC却没有响应，经确认，我司SBCSE2600在作为A-SBC时，缺省情况下，仅支持SIPoverUDP，SIPoverTCP为可选特性，需要相关license和相关配置才能支持，如下内容摘自SE2600产品手册：注：SE2600部署在IP网络的边缘或汇聚层，是会话信令和媒体流的聚合点。SE2600作为信令代理和媒体代理设备。通过对信令和媒体的处理，SE2600实现拓扑隐藏、NAT（NetworkAddressTranslation）/防火墙穿越等功能。A-SBCSIP代理功能包括信令代理和媒体代理。信令代理：对SIP信令报文的解析、处理和转发。媒体代理：对音频、视频等媒体流的代理。3、测试同事在SBC上补充SIPoverTCP相关配置后，再进行测试，发现仍是无法呼叫，log如下：经测试同事咨询SE2600同事，该问题确认为：Iphone6在SIPRegistration过程中采用的是UDP传输协议，而在发起VoLTE呼叫时，采用的是TCP传输协议，我司SE2600不支持这种场景，仅支持对于同一个UA，所有SIP消息都采用UDP协议或TCP协议。所以，导致iphone6终端作为主叫时，VoLTE呼叫无法建立。问题分析到这里，我们会有个疑问，那到底SE2600的问题，还是Iphone6的问题呢？翻查了一下RFC3261SIP协议（18Transport章节），18.1.1SendingRequestsIfarequestiswithin200bytesofthepathMTU,orifitislargerthan1300bytesandthepathMTUisunknown,therequestMUSTbesentusinganRFC2914[43]congestioncontrolledtransportprotocol,suchasTCP.18.2.1ReceivingRequestsForanyportandinterfacethataserverlistensonforUDP,itMUSTlistenonthatsameportandinterfaceforTCP.ThisisbecauseamessagemayneedtobesentusingTCP,ratherthanUDP,ifitistoolarge.Asaresult,theconverseisnottrue.AserverneednotlistenforUDPonaparticularaddressandportjustbecauseitislisteningonthatsameaddressandportforTCP.Theremay,ofcourse,beotherreasonswhyaserverneedstolistenforUDPonaparticularaddressandport.大致理解如下：SIP协议是基于transaction的协议，每个transaction应该都可以根据SIP消息需求场景决定所要采用的传输协议。而且，SIP协议也要求大于1300字节的SIPRequest消息使用支持拥塞控制的传输层协议（如：TCP）。所以，该问题应该是SE2600的兼容性不够导致的问题，Iphone6的实现没有错。【问题根因】Iphone6终端在VoLTESIPRegistration过程中采用了SIPoverUDP，发起VoLTE呼叫时，采用了SIPoverTCP，而我司SE2600不支持场景，SE2600只支持对于同一个UA，所有SIP消息都采用UDP协议或TCP协议。所以，出现了Iphone6注册成功，但做主叫时，呼叫无法建立的问题。该问题根因是SE2600产品兼容性问题，我司SBC下一代产品SE2900会支持上述场景。【解决方案】1）目前，西研实验室下，由Iphone6临时加载补丁，使得Iphone6在SIPRegistration和VoLTE呼叫过程中都采用UDP传输协议来规避。2）也可以考虑部署SE2900设备来解决（SE2900的SIPoverTCP是产品基础特性，不再受license限制）。案例:3：UE未发送INVITE消息导致电话呼叫失败的问题分析【问题描述】一线反馈VoLTE电话呼叫失败【问题分析】1、终端拨打电话时，基站侧的Uu口和S1口没有建立QCI1的承载2、QCI1的建立条件：只有在MME在收到SIP消息后才会触发QCI1的承载建立。由于在基站侧看到没有建QCI1，所以怀疑MME没有收到SIP消息。3、通过UE侧的QXDM抓包，确认UE没有在拨打电话时没有发送INVITE消息，所以呼叫失败。4、复位手机后，问题现象消失，QXDM抓包如下【问题根因】UE没有在拨打电话时没有发送INVITE消息【解决方案】需要终端分析不发送invite消息的原因。本案例中复位手机可以解决该问题。案例4：AnalysisreportforVOLTEsetupfailureunderHL475201_Sangambank300site【问题描述】TheVOLTEservicealwaysfailsunderMicrositeHL475201_Sangambank300【问题分析】1.ENODEBalarmandfaultyanalysisThereisnoanyrelatedactivealarmandfaultyfromENODEBside.2.ENODEBtraceanalysisAsdemonstratedinthebelowfigure,thereisnoRRCsetupandERABsetupfailure,nocalldrop.AndtheQCI5whichisusedtocarrytheVOIPsetupsignal(SIP)issetupsuccessfully.Figure1.S1andUUinterfacesignalflowSotheVOLTEsetupfailureshouldbefromSIPsignalpart.3.WiresharktraceanalysisInthisversion,thereisnowaytocapturetheSIPsignalfromENODEBside.SotheonlymethodtotracetheSIPsignalistocaptureallthedatatransmissionbetweenENODEBandSGW.Belowfigureshowswherethewiresharkdatawascaptured.Figure2.DatacapturelocationFromthewiresharktrace,theVOLTEcallfailureisduetoregisterfail,andthereasonistheCNdoesnotreceivesthesecondregistermessagefromUEaftersending“401unauthorized”messagetoUE.Figure3.TheSIPsignaltracebetweenENODEBandSGWFigure4.ThenormalregisterSIPsignalflowThepossiblereasonsofCNnotreceivethesecond“register”messageare:a.UEdoesn’treceivethe“401unauthorized”message.b.UEdoesn’tsendthesecondregister.c.ENODEBdoesn’tsendthesecondregistertoCN.1).UEdoesn’treceivethe“401unauthorized”messageBycomparingwiththeENODEBtrace,thetimedifferencebetweentheCNdataandENODEBtraceis1hour,ENODEBtimeis1hourlaterthanCN.Sothe4timesfailureshappenedfrom3:53:06to3:53:21accordingtoENODEBtime.Therearelogstorecordthedatapacketsateachpointdemonstratedinthebelowfigure:Figure5.TheENODEBpacketstatisticpointA:receivedtotalGTPpacketsnumberfromSGW.B:sentGTP-UpacketsnumbertoPDCPmoduleC:sentGTP-CpacketsnumbertoGTPcontrolmoduleD:PDCPreceivedtotalGTP-UpacketsfromtransmissionmoduleFirstly,fromthePDCPcounter,thereisnoanyQCI5DLdatareceivedfromtransmissionmodulefrom3:50:00to3:55:00.Figure6.TheENODEBcounterL.Traffic.UL.PktLoss.Tot.QCI.5:ULreceivedQCI5datafromUE. L.PDCP.Tx.TotRev.Trf.SDU.QCI.5:DLreceivedQCI5datafromtransmissionmodule.L.PDCP.Tx.TotRev.Trf.SDU.QCI.8:DLreceivedQCI8datafromtransmissionmodule.Secondly,fromthetransmissionmodulestatistic,alltheGTPdatareceivedfromSGWhavebeensenttoPDCPandGTPcontrolmoduleFigure7.TheENODEBpacketstatisticBycomparingthestatisticatpointBandD,itisthesecondproofthatthereisnoanydatalossfromENODEBside,andENODBEdoesnotreceivetheDLSIPmessagesuchas“Unauthorized”.BelowsheetshowsthestatisticatpointDFigure8.TheENODEBcounterPDCPreceived18730packetsfromtransmissionmodulefrom3:30to4:30,anditissamewiththestatisticatpointBbytransmissionmodule.2)TheQCI5downlinkpacketsdiscardedbytransmissionThedatatracewascaptureattheoutletofSGW,itprovesthattheSGWalreadysenttheSIPmessagetoENODEB,buttheENODEBdidn’treceiveit.Soitmustbetransmissionnetworkproblem.Afterthetransmissioninvestigation,itisconfirmedthattheDLQCI5packets(DLSIPmessage)discardedbymistake,becausedifferentQCIpackethasdifferentDSCPvalue,theQCI5DL(fromSGWtoENODEB)DSCPis46,andallpacketswithDSCP46werediscardedattransmissionequipment.Aftercorrecttheerroroftransmissionequipment,theproblemissolved.【问题根因】Wrongconfigurationfromtransmissionequipment,causeallpacketswithDSCP46arediscardedbymistake.【解决方案】Correctthetransmissionwrongconfiguration.案例5：E///处理异常导致UE从xx基站切换到E///基站后，语音中断【问题描述】阿联酋+ET，V100R008C00SPC260，客户在实验室测试，发现从xx基站切换到E///基站后，语音通话中断，从E///切换到xx，没有问题。【问题分析】1.UE侧日志分析。（一线只反馈了UE侧日志的截图，没有反馈具体的日志信息）从图1和图2对比分析，切换后语音中断出现在PCI=381（我司基站）往PCI=16（E///基站）切换以后；PCI=16往PCI=381切换没有问题。从切换流程分析，两次切换均成功。排除切换失败导致的语音中断。图1.切换后出现通话中断图2.切换后通话正常2.eNB侧日志分析由于语音业务需要建立qci5和qci1的承载，所以接下来需要分析，切换后qci5和qci1是否建立正常。1）handoverrequestack消息对比分析：当UE从PCI=381的站点切换到PCI=16的站点时，qci1的承载准入失败。由此找到了语音中断的原因：切换到E///后，qci1准入失败。2）handoverrequest消息对比分析：qci1的开户信息一致，无异常；排除切换后qci1开户信息不一致导致的准入失败。由此需要进一步分析qci1的空口配置信息是否一致。qci1空口配置分析：RLCSNsize配置不一致。我司切换到E///基站时，qci1的RLCSNSize=5bit；而从E///基站切换回来时，qci1的RLCSNSize=10bit。由此推测：我司基站qci1的RLCSNSize配置的5bit；E///基站qci1的RLCSNSize配置的10bit。3、在其他局点遇到过类似问题，当E///基站配置的SNSize和他收到的切换命令中的SNsize不一致时，E///基站处理会出问题，导致承载准入失败。4、一线将我司基站qci1的RLCSNsize配置成10bit后，问题可以规避。【问题根因】当E///基站配置的SNSize和他收到的切换命令中的SNsize不一致时，E///基站处理会出问题，导致承载准入失败。需要E///给出根因。我司基站做了兼容性处理，当基站配置的SNSize和收到的切换命令中的SnSize不一致时，会选择基站配置的SNsize下发给UE，不会准入失败。【解决方案】将我司基站qci1的RLCSNsize和E///基站配置一致，可以规避该问题。案例6：DRXtoolongcausedQCI5packetsdiscardedbyENB【问题描述】whenDRXON,thereissometimesVOLTEcannotworkwhenused2VOLTEUEdoingcalls.【问题分析】1.LastQCI5TCPpacketlostByanalysistheS1wireshsarklog,whenQCI5bearissetup,theSIPsignallingmessageisnormal,butthelastTCP[RST,ACK]packetsislostwhentransmitthroughLTEwirelessair.Figure1lastTCPpacketatENBS1Asthefigureaboveshows,everytimeVOLTEcallsinterrupted,thelastQCI5TCPpacketsisnotreceivedbyUE,butreceivedbyENBS1,itmeansthepacketsislostwithinENB.2.QCI5packetsdiscardedbyENBPDCPByanalyzingthePDCPtrace,whenVOLTEcallsinterrupted,thereisQCI5packetslostduetoPDCPdiscardtimertimeoutasshownbelow(thelastQCI5[RST,ACK]TCPpacketisabout66bytes).Figure2thestatisticsofPDCPpackets3.DRXparametersunreasonablecasuedpacketslostAfteranalysisthewirelessUUtrace,itshowswhenQCI1isreleased,QCI5DRXparametersisre-configuredbyENBsenttoUEduetohigherpriorityofQCI5thanQCI6.andthelongDRXis320ms:Figure3theUUtraceAndtheQCI5PDCPdiscardedtimeris150msindefault:SowhenUEisinDRXsleepstatus,andENBwillwait320msatmosttosendthelastTCPpackettoUE,butthePDCPdiscardtimerofQCI5is150ms,soENBwilldiscardthispacket.【问题根因】BecausethelongDRXis320mstoolong,

afterENBreceived[RST,ACK]packets,theUEmayisinsleepstatus,andENBwillwait320msatmosttosendthelastTCPpackettoUE,butthePDCPdiscardtimerofQCI5is150ms,soENBwilldiscardthispacket.【解决方案】1.modifytheQCI5PDCPdiscardedtimertoinfinite.2.modifythelongDRXofQCI5asthesameasQCI1.单通案例1：iphone6呼叫P7单通分析【问题描述】西研实验室采用iphone6，HuaweiP7，Huaweimate7终端进行VoLTEIOT测试，发现iphone6呼叫P7出现单通问题，iphone6听不到P7侧语音，而其他场景下，语音均正常：【问题分析】根据测试同事反馈，iphone6呼叫P7时，单通问题必现，并且均为iphone6听不到P7话音，而其他呼叫场景，包括P7呼叫iphone6，iphone6呼叫mate7等，呼叫都正常，所以，该问题初步怀疑是iphone6与P7之间因兼容性问题导致单通，与其他网元无关。对于这种实验室内必现的单通问题，网元侧数据采集比较方便，问题是比较容易分析的。如下为LTE终端与LTE终端呼叫示意图，其中，黑色虚线为VoLTE呼叫建立所涉及到的网元，蓝色实线为媒体RTP包所经历路径：从上图可以看出，SBC是VoLTESIP信令和RTP媒体都经过的网元，实验室内SBC可以通过镜像抓包采集到SIP信令和RTP媒体包，并且可以通过wireshark进行数据分析，因此，该问题优先选择在SBC网元（实验室为我司SE2600）采集数据包进行分析。如下为SBC网元iphone6呼叫P7数据log：Iphone6IP：8P7IP：77SBC信令代理IP：SBC媒体代理IP：从上述wiresharklog，可以比较容易找到“疑点”，SBC→iphone6的RTP报文，没有解析为AMR-WBcodec，仅是解析到RTP包，PT=DynamicRTP-Type-116：而SBC→P7的RTP报文，均解析为AMR-WB：所以，我们怀疑iphone6侧单通，是因为无法正常将RTP包解码为AMR-WB导致的。那为何wireshark没有将SBC发送给iphone6的RTP报文解析为AMR-WB呢？RTP媒体包收发规则是在VoIP呼叫建立过程中，通过SDPoffer/answer机制“协商”确定的，包括收发RTP包的IP地址，端口号，codec类型等。在上述流程中，主叫终端iphone6在SIP：INVITE消息中携带了SDPoffer，被叫终端P7在SIP：200OK中携带了SDPanswer：SIP：INVITE——SDPoffer：SIP：200OK——SDPanswer：从上述RTP媒体协商来看，iphone6在SDPoffer中携带了其支持的codec集合，按照优先codec顺序进行了排序：P7在SDPanswer中携带了如下媒体信息：我们可以看出，iphone6和P7最终协商要采用的codec是相同的，都是bandwidth-efficientformatAMR-WB，但iphone6和P7所要使用的RTPPayloadType却是不同的，再继续看看RTP媒体中的PayloadType，发现iphone6发送的RTP包是采用的PT=116，P7发送端RTP包也是采用的PT=116，而PT116在iphone6SDPoffer中没有包含，会不会是因为这个原因导致iphone6无法解码相应的RTP包而单通呢？问题分析到这里，我们要回答如下几个问题：Q1：通话RTP包中的PT的取值到底是如何确定的？是应该根据对端在SDPoffer/answer中给定的PT来发送？还是根据最终在SDPanswer中指定的PT来发送？Q2：主被叫都支持的是完全相同的codec，那到底如何确定PT类型呢？是否必须遵从SDPoffer中的PT吗？Q3：相同的codec类型，是否必须要协商采用相同取值的PT呢？上述问题，翻查了几个协议，整理如下：1）SDPoffer方接收的RTP包的Payloadtype必须为SDPoffer中的payloadtypenumber，SDPoffer方也希望在相应的payloadtypenumber上发送RTP包2）协议上是允许SDPanswer中对相同的codec使用不同的payloadtypenumber。3）SDPoffer方必须根据SDPanswer中的payloadtypenumber来发送RTP包4）若SDPoffer和SDPanswer支持相同的codec，则建议SDPanswer采用与SDPoffer中相同的payloadtype。相关协议摘录如下：RFC3264：5.1UnicastStreamsForrecvonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisexpectingtoreceiveforthatcodec.ForsendonlyRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldinRTPpacketstheoffererisplanningtosendforthatcodec.ForsendrecvRTPstreams,thepayloadtypenumbersindicatethevalueofthepayloadtypefieldtheoffererexpectstoreceive,andwouldprefertosend.However,forsendonlyandsendrecvstreams,theanswermightindicatedifferentpayloadtypenumbersforthesamecodecs,inwhichcase,theoffererMUSTsendwiththepayloadtypenumbersfromtheanswer.DifferentpayloadtypenumbersmaybeneededineachdirectionbecauseofinteroperabilityconcernswithH.323.6.1UnicastStreamsInthecaseofRTP,ifaparticularcodecwasreferencedwithaspecificpayloadtypenumberintheoffer,thatsamepayloadtypenumberSHOULDbeusedforthatcodecintheanswer（这里采用should来描述，表示建议，并不是强制）.Evenifthesamepayloadtypenumberisused,theanswerMUSTcontainrtpmapattributestodefinethepayloadtypemappingsfordynamicpayloadtypes,andSHOULDcontainmappingsforstaticpayloadtypes.7OffererProcessingoftheAnswerWhentheoffererreceivestheanswer,itMAYsendmediaontheacceptedstream(s)(assumingitislistedassendrecvorrecvonlyintheanswer).ItMUSTsendusingamediaformatlistedintheanswer,anditSHOULDusethefirstmediaformatlistedintheanswerwhenitdoessend.3GPP26.114A.3.1aSDPanswerfromanMTSIclientinterminalwhenonlynarrowbandspeechwasoffered回答了上述几个问题，该单通问题的原因也就找到了：就是因为P7终端发送的RTP媒体包中的Payloadtype取值不正确，导致iphone6侧无法解码相应的RTP包而导致单通。Iphone6终端工程师针对该问题的答复与我们的分析是相同的，如下：此外，我们对比了正常的Iphone6呼叫mate7以及mate7呼叫iphone6的流程，这两种场景下，SDPanswer都是遵从了SDPoffer中建议的Payloadtypenumber：【根因总结】通过上面分析，Iphone6呼叫P7单通问题（Iphone6侧听不到P7侧话音），是因为P7终端未根据SDPoffer/answer过程中协商的RTPpayloadnumber来正确填写媒体包RTPHeader中的Payloadtype字段导致Iphone6无法解码相应的RTP包而出现单通。【解决方案】该问题需P7终端修正相关bug【参考协议】（1）IETFRFC3264(2002):"AnOffer/AnswerModelwiththeSessionDescriptionProtocol(SDP)"（2）3GPPTS26.114:"IPMultimediaSubsystem(IMS);Multimediatelephony;Mediahandlingandinteraction".案例2：S国N局点VoIP概率单通问题分析【问题描述】eRan6.0,TDD,S国N局点WBBVoIP概率单通，需要分析原因。【问题分析】对于VoIP单通问题，通常我们需从VoIP媒体包“途经”通道的网元节点采集log，根据log来确认问题发生节点。LTEVoIP媒体通道如下：客户反馈采用QCI1专用EPSbearer承载会概率出现语音单通，而采用QCI9缺省EPSbearer承载则不会出现语音单通问题，所以，我们需重点排查EPSbearer所经历的网元：LTECPE，eNodeB，S-GW/P-GW。4月28日，一线反馈单通复现后的相关log（客户此次仅采集了问题发生后的数据log，未采集到问题发生时间点的log），分析发现：1）ThroughputMonitoring：QCI1承载ULRLC和DLRLC速率基本对称，符合VoIP业务行为：注：单路G.729语音IP层速率约为24kbps，ThroughputMonitoring中DL/ULRLC吞吐量是指RLCSDU/PDCPPDU的吞吐量：当PDCPSNsize=7bits时，相应的RLC吞吐量为24.4kbps；UserPlaneTrace->L2Performance->138跟踪项，显示仅有下行RTP媒体包，而无任何上行RTP媒体包为何ThroughputMonitoring中，QCI1承载上ULRLC吞吐量正常，而到138跟踪中，却没有任何上行RTP媒体包信息呢？联合FDD层二专家一起分析，采用FDD层二专家提供的“MyLDT”解析工具重新解析138跟踪，发现并不是真的QCI1承载上ULPDCP层没有数据包，而是ULPDCP层数据包是“坏包”，IpVersion字段已不是“4”，即：ULPDCP层数据包已经不是“IPpacket”了。到此，问题锁定在CPE和eNodeB之间。为何ULPDCP层数据包“坏”了呢？我们先看一下PDCP层对业务面数据所提供的功能：从PDCP层所提供的功能来看，很容易想到是因为“解密”过程导致数据包“坏了”。后续重点分析为何解密过程出了问题。LTE加密/解密示意图如下：加密/解密过程涉及如下参数，对于同一个PDCPSDU，必须采用相同的参数完成加密和解密过程，我们分析一下哪个参数会导致解密失败呢：加密/解密参数32-bitCOUNT由两部分组成：HFN和PDCPSN1）当DRB承载建立时，UE和eNodeB侧将HFN和PDCPSN均初始化为0.2）对于每一个PDCPSDU，PDCPSN++；3）当PDCPSN达到Maximum_PDCP_SN，HFN++;PDCPSN会在每一个PDCPPDU中明文传递，而HFN则是由UE和eNodeB根据PDCPSN取值自行维护。 因此，COUNT中HFN失步将会导致解密过程异常，数据包坏掉。 根据理论分析和FDD专家经验，导致HFN失步的最大可能性是连续丢包超过Maximum_PDCP_SN导致：AlossofsynchronizationoftheCOUNTvaluebetweentheUEandeNodeBcanthenonlyoccurifanumberofpacketscorrespondingtothemaximumSNarelostconsecutively.Inprinciple,theprobabilityofthiskindoflossofsynchronizationoccurringcouldbeminimizedbyincreasingthelengthoftheSN,eventotheextentoftransmittingthewholeCOUNTvalueineveryPDCPDataPDU.However,thiswouldcauseahighoverhead,andthereforeonlytheleastsignificantbitsareusedastheSN;theactualSNlengthdependsontheconfigurationandtypeofPDU.——LTE–THEUMTSLONGTERMEVOLUTIONRLCUMmode对应的PDCPSNsize有两种：7bits和12bits。对于QCI1DRB承载，eNodeB产品默认建议PDCPsize配置为7bits；即：当出现连续丢弃128个PDCPSDU（即：IP包），就可能出现HFN失步；通常，一路VoIP语音，每20ms一个VoIP语音包，1s约50个语音包，对于N路话音场景，则1s约N*50个语音包；因此：1）当网络存在突发干扰或信道突然恶化2）当同时通话话路所需带宽大于QCI1承载GBR配置可能会因连续丢包导致HFN失步。连续丢包导致HFN失步，表现为加密端HFN>解密端HFN；该问题可以通过扩展PDCPSNsize为12bits来解决。客户4月28日复现单通问题，并未采集到出现单通时的userplanetrace数据，所以，到底是否是因为连续丢包导致HFN失步并无法确认。直到客户在5月5日反馈4月29日时复现的单通log，TDD研发层二专家分析133跟踪项后，初步怀疑是PDCP层数据包乱序导致HFN失步，并不是之前理论分析的连续丢包导致HFN失步。1、标红代表出问题的时间点（138跟踪解密后的数据的IP头都异常了），在出问题前，基本1s有100个包左右（2路VoIP话路，1s约100个VoIP媒体包），PDCP入口的包数量跟基站维护的HFN,SN计算的包数量一致；在出问题的时间点，可以发现PDCP入口收到的包数量还是100左右，而基站维护的HFN,SN计算出的包数量增加了224个，两者之间刚好差128（对应7bitPDCPSN配置），此差异是由于基站的HFN调整导致的。基站HFN调整的过程：PDCP每收到一个包，首先解析包头，获取SN号，然后对SN号进行判断，如果SN号比基站预期要接收到的SN号小，则基站认为中间有丢包且HFN应该要加1。由于出问题的时候，基站维护的包数量刚好比真实的包数量多128，认为丢包刚好丢128个的可能性比较少，因此认为PDCPSN号乱序的可能性较大（从eNodeBULPDCP在HFN自行调整前后PDCP层收到数据包个数来看，VoIP话路数并未改变，因此，也可以确认空口并未发生连续丢包，HFN自行调整是因乱序引入。）。例如：如果基站收到的包并没有丢，而只是SN号乱序，例如：1,3,2,4,基站收到的这类包后HFN就会调整加1，而维护的总包数也会刚好比真实包数多128。2、分析上行调度49号跟踪，出问题时间点附近的误帧、MCS、RB数，调度间隔都没有异常，基本排除空口传输异常的可能性——TDD层二专家分析结论从一线单通获取日志，无法定位是什么原因导致PDCP层数据包乱序，包括eNodeB侧log信息因流控有信息丢失，并且B222终端无法采集空口相关log：1、133号跟踪中的PDCP_Trace_Type_PktLoss内容项有丢失，49号跟踪内容也有丢失，应该是被流控掉了，无法判断基站侧PDCP层具体收到的包的SN号不连续的具体情况2、分析RLC142号跟踪，在出问题的时刻，RLC刚好检测到有重复RLC包；而到出问题前，RLC共检测到重复RLC包11次；由于49号跟踪数据丢失很严重，无法把调度跟RLC检测到重复包进行关联——TDD层二专家分析结论PDCP数据包乱序导致HFN失步，表现为加密端HFN<解密端HFN；该问题可以在eNodeB上开启countercheck功能来规避：eNodeBcountercheck功能用于与UE核查安全参数COUNT是否一致，如果出现加密端HFN<解密端HFN，当COUNTERCHECKUSERRELSWITCH=ON，eNodeB会触发该承载释放（E-RABRelease）。研发实验室人为构造上述两种HFN失步场景，验证相应规避方案有效后，提供给一线实施：一线反馈客户执行规避方案后，现网仍出现单通问题。经分析确认：1）扩大PDCPSNsize后仍有单通问题：说明现网大部分单通问题不是因连续丢包导致HFN失步；2）开启countercheck后仍有单通问题：经确认，一线客户执行countercheck功能有误，我们建议配置：MODCOUNTERCHECKPARA:COUNTERCHECKCOUNTNUM=128,COUNTERCHECKUSERRELSWITCH=ON;而客户执行配置为：MODCOUNTERCHECKPARA:COUNTERCHECKTIMER=128,COUNTERCHECKUSERRELSWITCH=ON;COUNTERCHECKTIMER配置为128表示每128s执行一次countercheck功能；而我们是建议每128个包执行一次countercheck功能（若单路呼叫，相当于2.5s执行一次countercheck功能）。实验室复现下行单通时，分析eNodeBlog，确认：eNodeB下行发送的