VoLTE外场测试分析案例

VOLTE路测分析报告_20150720 1 概述1.1 测试区域1.2 测试方式2部MATE7互拨语音拉网测试，拨打时长180S，拨打间隔30S。

2 VOLTE测试结果2.1 总体指标概览2.2 关键指标分析1）RSRP&SINR2) MOS评分3 重点问题分析3.1 VOLTE呼叫建立失败问题本轮网格9拉网测试中，主叫VOLTE呼叫建立失败2次，被叫VOLTE呼叫建立失败1次，问题点分布如下所示。

3.1.1 EPC不发QCI建立导致未接通问题分析：车辆沿下贝岭大道由西向东行驶时，主叫UE终端在12:59:53.955占用东莞下岭贝商业街F-HLW-3起呼，RSRP=-84.50dBm，SINR=14dB，无线环境良好，但主叫在层3消息qci1已建立，最后转CSFB，导致接入失败。

在SIP消息上，主叫发INVITE 消息1s后，网络侧向主叫下发invite消息，3s后网络侧向主叫发送503service unavailable，主叫呼叫建立失败。

解决方案：1、需要EPC定位不下发QCI1建立请求的原因2、待复测时跟踪epc信令复测验证：3.1.2 EPC不发QCI建立导致未接通问题分析：车辆沿横东一路由东往西行驶时，主叫UE终端占用东莞富康新街D-HLH-102小区13：58:27:549起呼，起呼时RSRP=-100.38dBm，SINR=14dB，呼叫过程中主叫未收到QCI1的建立请求，2s后网络侧向主叫下发BYE：408 request timeout，网络侧没有响应，从SIP消息上看，主叫发送invite消息后网络侧没有向主叫发送update建立QCI1，最终主叫显示VoLTE的呼叫建立失败。

解决方案：1、epc未给主叫下发qci1建立请求，需要epc核查原因复测验证：3.1.3 被叫QCI=1承载未建立导致未接通问题分析：车辆沿长岭二街由由南向北行驶时，被叫UE占用东莞华诚实业D-HLH-2（PCI=394）小区，RSRP=-86.88dBm，SINR=-10dB，邻区里东莞霞边D-HLH-2（PCI=40）小区RSRP=-86.63dBm，该路段存在MOD3干扰。

VOLTE呼叫建立时延长案例分析问题描述呼叫建立时延为VOLTE用户感知竞争力之一，经用户反馈使用VOLTE手机的呼叫建立时延有时较长，针对反馈的问题点进行实际测试，现个别呼叫建立时延在4s以上，影响用户感知，降低了用户满意度。

原因定位无线侧问题描述：正常呼叫建立时延在3s以内，针对用户反馈的问题，我们对网格进行VoLTE拉网测试，呼叫建立时延均在3.1s以上，最高时达3.5S：无线侧信令分析对多轮测试数据进行信令分段统计，筛选出INVITE REQUEST→180 RINGING信令段时间差大于5s的通话。

对超长时延通话的各个信令段占用时长进行统计，发现影响通话时长的主要信令段集中在100 trying->183段。

对超长时延的通话进行信令分析，均为主叫发送INVITE Request 到被叫收到INVITE Request时间长，在此段信令中进行深入分析，为被叫收到Paging 消息耗时长。

针对此情况在端到端信令分析平台上进行回溯分析，发现对被叫寻呼时，一次寻呼未成功，6s后再次寻呼，导致时延额外增加6秒，影响整体呼叫建立时延。

参数调整测试为减小呼叫建立时延，对一次寻呼成功率进行优化提升，因此在eNodeB侧进行最优参数组合优化，“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数，达到提升空口寻呼成功概率。

对测试网格主服务小区进行参数的修改优化，并对金湖网格进行复测，复测后网格的拉网测试呼叫建立时延由最高的3.5s降低到1.99s，大大降低了呼叫建立时延，提高了VOLTE用户感知。

问题原因：主叫发送INVITE Request到被叫收到INVITE Request时间较长，为被叫收到Paging消息耗时长，深入分析问题根因，为一次寻呼未成功，从而二次寻呼导致呼叫建立时延长，其次100 trying->183 这段信令的时延较长导致整体呼叫建立时延较长。

影响范围：全网解决方案通过eNodeB侧最优参数组合优化，“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数，达到提升空口寻呼成功概率，从而解决语音呼叫建立时延长问题。

异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 6被叫振铃未接听 2测试设备断链 4端到端问题 4TAU与QCI建立流程冲突 1TCP链路问题 1切换与QCI1建立流程冲突 1终端在2G侧无响应 1核心网问题 5TAU与切换流程冲突导致TAU失败 4同一个MME下NAS消息sequence number不连续导致承载未建立 1其他原因 3人为挂断 3终端问题 2跨TAC但未发TAU导致服务拒绝 2总计201、测试软件问题（1）11月25日网格8 被叫振铃未接听主叫号码：136******** 被叫号码：136********（Time: 13:57:00.354，Latitude: 39.92886，Lontitude: 116.52397）13:56:25.184主叫占用朝阳平房乡政府南公园西北HLG-3发起呼叫，RSRP -78 dBm，SINR 17dB，无线环境良好，13:56:27.776主叫收到网络侧转发的被叫的invite 180后，由于被叫一直没有摘机导致在13:56:47.988被叫主动挂机上报invite 603，携带原因为decline，主叫判断为未接通，被叫判断为掉话。

此处属于测试软件问题，应该予以剔除。

（2）11月19日网格55 测试设备断链主叫号码：136******** 被叫号码：136********(Time: 12:57:39.940,Latitude: 39.86454,Lontitude: 116.43406) 12:57:30.631主叫占用丰台左安门桥南HLG-5发起呼叫，RSRP -99 dBm，SINR 6dB 空口良好，由于被叫终端设备断链导致未接通，应该予以剔除。

2、端到端问题（1）11月16日网格67 QCI1与TAU流程冲突主叫号码：136******** 被叫号码：136********（Time: 13:13:21.299，Latitude: 39.92329，Lontitude: 116.41997）13:13:11.358主叫占用东城语文出版社HL-1发起呼叫，被叫于13:13:13.870上发invite 183之后，开始建立QCI1承载，UL information transfer还没有上发时发起TAU，流程冲突导致被叫主动上发invite 580，属于端到端问题，需要集团规范协议流程。

volte测试主叫异常导致的掉话
1.问题描述
在测试过程中，有时间会出现测试一次循环测试结束，信令已经完成，但是由于终端连接问题导致主叫还在继续发送IMS_SIP_BYE-Request，而被叫并没有收到请求，并未做出回应，最终导致Outgoing Dropped Call的错误统计。

2．分析处理过程
图1中在17:44:14时主叫发起IMS_SIP_BYE->Request，被叫也在17:44:14时响应并IMS_SIP_BYE->OK，此时通话应该结束。

但是在图2中主叫事件中出现Outgoing Dropped Call，且主叫信令中在17:44:16时又发起了IMS_SIP_BYE->Request通话结束请求，并连续下发几次请求，最终导致Outgoing Dropped Call。

图1.语音通话结束
图2主叫出现Outgoing Dropped Call现象
图3主叫继续发起IMS_SIP_BYE->Request
检查各项参数并未发现异常，经排查发现是由于UE终端连接异常，从而导致被叫已经挂断而主叫还在继续发送IMS_SIP_BYE->Request请求，出现这种情况检查UE连接状态，必要时需重新连接设备。

3.效果
需要在路测过程中需要实时监控设备连接状况，发现连接异常需及时处理。

4.经验推广情况
在路测过程中需尽量避免设备丢失，如果遇到设备丢失应该进行及时处理；同时进行数据分析时也要详细了解事件的发生的根本原因。

案例1：异频重定向掉话案例【问题描述】主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一次主叫掉话。

【问题分析】分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB 收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB 向MME发送ue context release request，mme释放专用承载。

当UE被重定向后在新的小区发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。

从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。

【解决方案】关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。

【问题总结】根据拉网统计，目前该类掉话占总掉话次数的80%以上，对测试指标影响非常严重。

异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切换到邻区，基站会给UE下发系统内重定向。

优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大优化力度。

后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，禁止专用承载的业务发生异频重定向。

案例2：异系统重定向掉话案例【问题描述】VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。

而CCO对于VoLTE语音来说，必然导致掉话。

【问题分析】具体如下图所示。

1. 对于PSHO、CCO、重定向，优先级为PSHO>CCO>重定向。

经典案例-VoLTE掉话研究和实践总结Volte掉话研究和实践总结1概述随着Volte的不断放号，Volte用户不断增加，如何保持Volte用户在语音通话过程中不掉话将至关重要。

本文将介绍Volte语音掉话优化方法以及台州Volte掉话优化成果。

下图所示为挂机流程：Volte掉话定义如下：掉话率：（主叫掉话次数+被叫掉话次数）/(主叫呼叫建立成功次数+被叫呼叫建立成功次数)路测软件掉话定义：呼叫成功后，通话阶段收到RRCCONECTION RELEASE消息，挂机阶段QCI1承载没有释放，BYE REQUEST没有收到200 OK。

2影响Volte掉话的因素Volte掉话问题涉及到UE，EnodeB，EPS，IMS端到端网元，需要各个网元联合分析和定位具体原因。

影响Volte掉话的因素如下图所示：3Volte掉话定位思路首先确定是哪类原因引起的掉话，再根据触发异常的网元分析掉话原因。

Volte通话过程中网络侧下发RRC Release或者SIP信令异常等掉话问题，一般是由空口质量，切换失败，重建，流程冲突等原因造成，涉及端到端网元，因此定位根因需要端到端信令，下图是Volte 定位思路。

如上图所示，分析Volte掉话时，告警核查和参数核查是无条件执行的。

掉话是在通话阶段收到了RRC Release1、查看基站侧虚用户跟踪，若是基站触发的，查看S1口释放原因。

2、根据原因值结合基站日志进行分析。

3、若是MME触发的，则查看释放原因，联合MME分析。

QCI1承载没有删除1、查看QCI1承载删除是否有切换，TAU流程，若存在查看基站虚用户跟踪，EPC跟踪，分析流程交叉处理顺序是否合理。

2、若流程交叉无问题或是无流程冲突，则查看基站虚用户跟踪是否收到QCI1承载删除。

3、若基站收到QCI1承载删除，则分析基站为何没有下发给终端。

4、若基站没有收到QCI1承载删除，则查看MME/PGW/SGW是否收到PCRF指示删除QCI1承载。

邻区漏配导致主叫掉话（漏配F-D）时间：2016-04-07主叫：被叫：【数据来源】**__移动_VOLTE主叫_网格1_鼎立ATU和HTCM8_0【问题现象】主叫11:10:56在,处发生掉话【问题分析】测试车辆在松福大道由北向南行驶，主叫11:07:36占用**沙井信维D-HLH-2发起呼叫，11:07:40通话建立。

主叫11:10:55发生掉话事件。

查看主被叫信令，从11:10:00开始，主叫占用**沙井展群F-HLH-2一直在上报切往**和山路D-HLH-2的A4事件，此时服务小区信号为RSRP=-106dBm，SINR=-16dB；无线环境恶劣导致RRC重建被拒，经后台查询**沙井展群F-HLH-2与**和山路D-HLH-2没有邻区关系。

主叫11:10:24占用**和山路D-HLH-2发生LTE Service Failure，随后主叫上报BYE，随后发生掉话。

【问题结论】邻区漏配导致主叫掉话【优化建议】1、添加**沙井展群F-HLH-2与**和山路D-HLH-2与的邻区关系邻区漏配导致主叫掉话（漏配F-F）测试时间：2016-04-09主叫号码：被叫号码：【数据来源】**__移动_VOLTE主叫_网格43_CDS和【问题现象】主叫20:27:58在,处发生掉话。

【问题分析】测试车辆在盐葵公路由东向西行驶，主叫20:25:57占用**盐葵梅沙D-HLH-1发起呼叫，RSRP=-93dBm，SINR=15dB，20:25:02通话开始建立。

测试车辆在盐葵公路行驶过程中，主叫20:27:49占用**下角湾F-HLH-1（RSRP=-118dBm，SINR=-12dB）期间连续弱覆盖，终端一直上报A3测量报告，目标小区为**大梅沙F-HLH-2，随后RRC重建被拒，经后台核查圳下角湾F-HLH-1与**大梅沙FHLH-2不存在邻区关系。

随后主叫发生掉话事件。

【问题结论】邻区漏配导致主叫掉话【优化建议】添加**下角湾F-HLH-1与**大梅沙F-HLH-2的邻区关系推动**云水间D-HLH **梅沙天琴半岛（微小M）建设邻区漏配导致主叫掉话(漏配D2-D2，已添加D1-D1)【问题现象】主叫在2016-04-10 18:09:40于发生主叫掉话【问题分析】测试车辆在航海路由东往西行驶过程中，主叫在18:09:40时分出现掉话事件，主叫在18:09:04时分开始起呼,在18:09:09时分通话建立，在18:09:10通话过程中主叫占用**兴海四D-HLH-103（RSRP=-112dBm,SINR=）多次上报A3事件切往**妈湾五D-HLH-102，由于漏配邻区，导致服务小区未切换到最优小区。