VoLTE外场测试分析案例

VoLTE网上问题案例集
文档版本
V1.0
发布日期
2015-01-28
华为技术
修订记录
Date
日期
Revision Version
修订版本
CR ID
CR号
Section Number
修改章节
Change Description
修改描述
Author
作者
2015-01-22
V1.0
初稿完成
曾佳00130333
为了统一思路前后方重新整理问题和思路寻求新的突破口，正对不同终端在同一个华为站点PTH112下面验证总共得到以下3种失败场景如下：
Case1:VoLTE注册过程中网络下发401鉴权挑战消息，终端未收到；
图9：Case1网络下发鉴权挑战401终端未收到
Case2: Sony终端基于UDP的Register消息异常；
通过测试发现P7使用的SIP基于UDP承载，并且Register消息总共才1172Bytes，MTU值可通过root权限配置但是设置未生效；待进一步验证。
P7升级到测试成功，但在E///的基站下，接入失败。IMS直接回494消息，CN侧抓包如下：
如下是P7失败和sony成功（E///基站）的对比，差异如红圈出，但P7发送的也符合协议RFC3329.
3.eNodeB版本和配置以及话统分析
检查eNodeB版本：BTS3900 V100R009C00SPC160；
检查EUTRAN支持VoIP能力开关：ENodeBAlgoSwitch.EutranVoipSupportSwitch=ON；
检查小区信号质量：正常；
检查数传业务成功率：正常；
检查所有基站配置和VoLTE业务：总共6个基站PTH100/101/102/104/110/112，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侧最优参数组合优化，“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数，达到提升空口寻呼成功概率，从而解决语音呼叫建立时延长问题。

终端IMS注册问题
终端要完成在IMS的正常注册，前提必须要在LTE MME上 附着成功，即终端当前是在LTE网络上的。
终端未能在IMS注册成功时，终端屏幕上方的IMS图标通常 会显示为红色或出现一个叹号，此时无法做VoLTE语音业 务。
从无线角度可以从QCI=5承载建立不否不SIP注册流程上去 大致定位问题出现在哪部分，然后在联合相关网元迚行具 体排查。
率偏置。 5. 修改RS功率：确保满足预期的小区覆盖半径。
呼叫建立问题—eRAB承载问题
要实现VoLTE语音业务和视频业务需要建立以下承载组合： • 语音业务载组合：SRB1+SRB2+2xAM DRB+1xUM DRB，其中，UM DRB
的QCI=1，2个AM DRB的QCI分别为QCI=5和QCI=8/9。 • 音频业务承载组合：SRB1+SRB2+2xAM DRB+2xUM DRB，其中，2个UM
IMS呼叫建立时延
我司目标值 >99% <0.5% >99% >98% <2.6%
<200ms
<1% >3.8 <5% <5% <1% <1%
<3s
<2s
备注
被叫处于IDLE态下，主叫拨打被叫 被叫处于连接态，主叫拨打被叫
对亍接通率、掉话率、eSRVCC切换成功率等挃标，网优侧需要做好基础优化， 如覆盖、邻区（系统内/间、邻区参数、邻区完善等）、合理参数设置等这几 个方面的网优工作。
图一
图二
呼叫建立问题—eRAB承载问题
从基站侧看，源小区在切换时收到了ERAB Release Command消息，但由亍已经开始切换， 因此回的响应消息中显示为失败，原因是切换触发，见下图三：

异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 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.经验推广情况
在路测过程中需尽量避免设备丢失，如果遇到设备丢失应该进行及时处理；同时进行数据分析时也要详细了解事件的发生的根本原因。

息包含重定向的目标频点，该频点与A3测报中小区频点一致。 ➢ 分析方法 检查异频A3测报中小区是否存在于异频邻区列表中。 ➢ 优化方法 1、基站侧增加区分QCI1业务的异频重定向关闭功能； 2、对于漏配邻区进行增补。
五、常见问题分析二 异系统重定向(1/2)
➢问题现象
终端在弱场区域，基站下发盲重定向的RRC Release消息，消息中包含重定向的2G 频点列表。
➢优化方法 1）可以通过调整天线方向角和下倾角、增加天线挂高、更换更高增益天线、 增强RS功率等方法来优化覆盖 2）对于相邻基站覆盖区不交叠部分内用户较多或者不交叠部分较大时，应新 建基站，或增加周边基站的覆盖范围，使两基站覆盖交叠深度加大 3）对于凹地、山坡背面等引起的弱覆盖区可用新增基站或RRU，以延伸覆盖 范围；对于电梯井、隧道、地下车库或地下室、高大建筑物内部的信号盲区可 以利用RRU、室内分布系统、泄漏电缆、定向天线等方案来解决
五、常见问题分析三 RSRP/SINR差（1/2）
➢问题现象 终端在弱场区域，RSRP/SINR过差，导致业务中断，原因多为RTP inactivity 导致RRC Release。 ➢分析方法 查看RRC Release之前的终端测量，确定终端是否处在RSRP/SINR过差区域。
五、常见问题分析三 RSRP/SINR差（2/2）
五、常见问题分析二 异系统重定向(2/2)
➢ 优化方法 1. LTE弱覆盖：优化LTE覆盖 2. 假性弱覆盖：优化切换、重选参数 3. 终端测量B2不及时：一是高通正在验证新的芯片，新芯片支持DRX休
眠期对异频异系统进行测量，缩短测量周期；二是通过删减无用的异 频频点，减少终端测量的频点数以达到缩短测量周期的目的 4. 2G邻区配置错误：做好eSRVCC的邻区精细化规划和周期一致性核查 5. 基站功能改进： 601P02版本可针对语音业务关闭重定向功能

案例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，由于漏配邻区，导致服务小区未切换到最优小区。

VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE 高清语音（或VoLTE 23.85kbps）。

【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。

●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。

AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。

可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。

AMR NB的语音带宽范围：300－3400Hz，8KHz采样。

AMR WB的语音带宽范围：50－7000Hz，16KHz采样。

用户可主观感受到话音比以前更加自然、舒适和易于分辨。

AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。

用来降低复杂度，AMR WB将位算法集中到更重要的频率区。

低频带使用ACELP算法进行编码。

添加几个特征来达到一个高的主观质量。

线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。

高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。

案例: EPC
现象描述:
UE2占用844199 PCI：69，RSRP=-97 SINR=7，收到主叫INVITE呼叫建立流程走到被叫上发180 ringing，网络层未下发Modify EPS Bearer Context Request，同时终端在做A3切换（目标小区417950 PCI:61），可能网络侧发送Modify EPS Bearer Context Request到源小区导致终端切换到 目标小区收不到。20s网络侧返回503 Service Unavailable，主叫call blocked 。
S1AP: INITIAL UE MESSAGE + EMM ATT_REQ + ESM PDN CONN_REQ
NAS Security Establishment (Authentication + NAS security start)
案例: 异常RRC连接释放
问题描述： 被叫UE占用PCI：61，收到来自主叫的BYE后,回BYE200,紧接着发生切换,1S后RRC连接释放. 问题原因： 1、为什么被叫收到BYE 后1S在没有回复去专载接收情况下，网络又下发RRC连接释放。
处理进展： 已抓取LOG，定位中
14
案例: IMS注册引起掉话
问题处理: 正常情况下，终端会在注册周期前完成注册，或者注册不应影响正在进行的本次通话，联系终端厂家,待终端厂家解决
15
案例: 异常去激活QCI9
现象描述:
UE1通话过程中接收来自网络数据业务寻呼，去激活QCI9 ，但是无BYE上报 ，还是在通话结束后上发BYE，不影响用户感知。
问题分析：发生这个问题是因为UE建立了两个承载,一个为ipv4承载给正常上网用的，另一个是ipv6承载，这个ipv6承载是无法上ipv6网(因为没有对接ipv6 骨 干网), UE得到的ipv6地址与其他UE有冲突触发UPCC删除这个多余的ipv6承载，这个不会影响正常业务(IPV4的承载还在)。另外不是所有的UE都会建两个承载 ，和UE的终端类型有关，当前大部分的终端都只是建一个ipv4承载。 刚也和测试人员陈斌(18850356626)电话确认，这种现象不影响正常上网。 核心网可以根据测试号只让ue建立ipv4承载,如果只是为了测试的话，可以按这个方案先规避。

VoLTE测试常见掉话未接通案例1.背景VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。

首先，高清语音和视频编解码的引入显著提高了通信质量，其次，VoLTE的呼叫接续时长大幅缩短，但VoLTE测试过程中仍发现部分掉话、未接通的现象，严重影响用户的感知。

本文梳理了VoLTE测试过程中常见的掉话、未接通的处理案例，为日后VoLTE试商用后此类问题的处理打下坚实的基础。

2.VoLTE语音通话流程简要如下：1.主叫发起INVITE消息，触发RRC建立过程（假设为空闲态）；INVITE消息包括主被叫电话号码，主叫支持的媒体类型、编码；2.主叫建立SRB2承载、QCI=9的DRB、QCI=5的sip信令承载；3.核心网反馈INVITE 100，表面正在处理应答；4.主叫RRC重配置建立QCI=1的专用承载；并激活；5.主叫收到被叫INVITE 183消息；并反馈PRACK启动资源预留；6.被叫收到PRACK后，反馈PRACK 200，启动资源预留；7.主叫收到PRACK 200，发送UPDATE，表明资源预留成功；8.同样被叫收到UPDATE，反馈UPDATE 200，表明资源预留成功；9.被叫发送INVITE 180 RINGING，振铃；10.被叫反馈INVITE 200，表明摘机11.主叫收到INVITE 200后，反馈ACK给IMS服务器，应答初始INVITE请求；并有IMS发给被叫；12.通话中；13.被叫挂机，发送BYE；IMS转发给主叫；14.主叫挂机，反馈BYE 200，IMS转发给被叫，表明结束会话；15.RRC重配置去激活QCI=1专载；图1.1 释放专载图1.2 简化信令流程图3.DT测试中常见的掉话、未接通问题2.1.切换失败导致常见有较多MR上报但不切，可能邻区漏配，之后触发RRC Re-Establishment，重建立不成功时掉话。

熟悉VoLTE基本原理、终端设置以及业务测试要求，负责本地市VoLTE测试过程以及试商用友好用户投诉问题的预处理，
预判断问题类型并反馈至省公司相应联系人。 4、分场景测试研究：完成《VoLTE分场景参数测试规范》，外场测试涉及“两大”场景（宏站、室分）、“四小” （高铁、上行高干扰、高话务、VoLTE覆盖边界）场景，并给出参数配置建议。
组团队
1.将基础参数核查纳入到日工作计划，按照省公司规范要求，明确不合规参数原因 并及时修改。 2.加强测试管理，建立测试日报。第1天开展的工作，第三天必须分析总结好，并
明要求
上传到专用FTP服务器。 3.测试开展前，需检查此次测试是否跟踪，保证异常事件分析时，各网元信令可 用。 对试商用和网格测试出现的问题点形成跟踪表，定期对问题点进行跟踪 4. 中心负责人负责牵头进行端到端分析，打破中兴、华为两个厂家的壁垒。 解决进展。 5.建立问题跟踪表，进行问题点的闭环管理。 1.组织进行案例收集，并进行分享。
提技能
2.联系厂家后台研发人员进行技术交流。 3.邀请核心网负责人进行技术交流，扩展知识面。 4.总结问题分析案例，及时上报省公司和集团公司案例库。
8
测试问题分析优化思路
济南公司理论结合实践，聚焦接通、掉话、时延等重要事件，通过定目标、找方向、提指标三步 走全面提升VoLTE试验网质量。
质差指标 分析方向 解决措施
4
济南VoLTE基础优化进展
济南公司对各项参数进行了如下检查：
联合工参更新
部署2-4G重选功 能

6月中旬完成全网1.2万个GSM小区开启，确保 VoLTE用户重选或切换到2G后快速返回4G 结合6月中旬2G翻频工作，将4G到2G的频点与 小区一一对应，eSRVCC继承CSFB回落频点。

移动L T E V O L T E案例分析汇总Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】广东移动4GTD-LTE详细案例分析案例1：580PreconditionFailure导致的未接通。

【问题描述】在集团测试LOG中，存在PreconditionFailure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580PreconditionFailure消息，随后呼叫中止，出现未接通事件。

Log文件名：MOUE:MTUE:时间：10：16：【问题分析】1、呼叫过程中，被叫发送Ringing180后，收到网络下发的专载去激活命令，QCI1被释放，被叫随后上报580PreconditionFailure，主叫同样收到网络侧转发的580消息，呼叫接续中止，导致未接通。

2、从信令中可以看到，被叫回复Ringing180且主叫也已经收到Ringing180，被叫随后收到网络侧下发的RRC重配，携带有QCI1被释放的信息，被叫去激活专有承载。

由于专载已被释放，业务资源已不存在，所以被叫上发580PreconditionFailure失败消息。

主叫收到网络侧下发的580，接续被中止，导致了会话未接通。

3、从MME下发到NodeB的E-RABRELEASECOMMAND，原因上看是Nas层nomal_release，导致专载QCI1被释放。

4、专载QCI1被释放，去激活后，被叫发送INVITE580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RABRELEASECOMMAND，使得QCI1被释放，导致未接通。

【解决措施】需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。

【测试验证】案例2：ServerInternalError500导致的未接通【问题描述】在集团测试LOG中，存在ServerInternalError导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的ServerInternalError500消息，随后呼叫中止，出现未接通事件。

网管KPI指标
指标类型 指标名称（中文） 指标描述 公式定义 指标来源 建议值 VoLTE无线接通率 (QCI 9 E-RAB建立成功数/QCI 9 E-RAB建立 QCI 9 E-RAB建立成功率 * QCI 5 E-RAB建 请求数)*(QCI 5 E-RAB建立成功数/QCI 5 E立成功率 * QCI 1 E-RAB建立成功率 * RRC RAB建立请求数)*(QCI 1 E-RAB建立成功数 Enb 连接建立成功率 /QCI 1 E-RAB建立请求数)*(RRC连接建立成 功次数/ RRC连接建立请求次数)*100% 统计QCI=1的用户平面连接建立成功率。 统计QCI=5的用户平面连接建立成功率。 分QCI的E-RAB建立成功数（QCI=1）/分 QCI的E-RAB建立请求数（QCI=1）*100% 分QCI的E-RAB建立成功数（QCI=5）/分 QCI的E-RAB建立请求数（QCI=5）*100% Enb Enb 98%
RTP丢包率（PLR）（话音）
RTP丢包率（PLR）（视频）
统计RTP/PDCP层数据包
（发送的VoIP数据包数量接收的数据包数量）/发送 1% 的VoIP数据包数量*100%
主要测试指标
指标类型
指标名称（中文）
指标描述
公式定义
建议值
上行RB数(话音）
每秒上行调度RB数：指该用户在过去1秒内被实际调度的 上行RB数；每秒上行实际调用次数：指该用户在过去1秒内 每秒上行调度RB数/每秒上 95%小于2 被系统实际上行调度的次数，而非过去1秒内的所有调度机 行实际调度次数 会（例如过去一秒内所有的上行时隙数目）； 每秒下行调度RB数：指该用户在过去1秒内被实际调度的 下行RB数；每秒下行实际调用次数：指该用户在过去1秒内 每秒下行调度RB数/每秒下 95%小于4 被系统实际下行调度的次数，而非过去1秒内的所有调度机 行实际调度次数 会（例如过去一秒内所有的下行时隙数目）；

VoLTE手机拨打固话不通的案例分析【案例摘要】VoLTE全员测试中发现，使用高通芯片的VoLTE手机在拨打部分固话时，接入失败，而使用海思芯片的VoLTE手机可正常接入。

通过各网元节点跟踪抓包分析，端到端分析VOLTE呼叫流程，最终定位为核心网QCI1专用承载未及时建立的问题。

核心网PCRF在第一次收到SBC发送的AAR后未能及时建立QCI1的专用承载，高通芯片的VoLTE手机收到183消息后没有向IMS发送了PRACK消息，导致接入失败，而海思芯片的VoLTE手机可正常发送PRACK消息。

修改PCRF承载建立配置参数后解决问题。

关键字：PRACK、专用承载、未接通、AAR、Precondition【现象描述】VoLTE全员测试反馈三星、中兴等VoLTE手机拨打部分固话不通，部分固话可接通，而华为VoLTE手机拨打固话均可正常接通，三星、中兴、华为VoLTE手机互打正常。

【问题分析】(1)鼎利软件测试分析使用三星S7拨打固话86118114，测试显示未接通，主叫处于呼叫状态无任何应答，最后终端向IMS发起CANCEL；三星S7拨打86118114测试截图由上图可以看到，网络侧收到INVITE消息后，下发了100 trying信令，之后下发了183消息，终端在收到183消息后向IMS发送了PRACK消息，但未收到网络侧发来的200 OK消息，呼叫建立；三星S7拨打86118114测试截图随后当终端向网络侧发起CANCEL后，终端才收到网络侧IMS下发的多个183消息协商请求，从鼎力测试软件看到终端没有收到IMS发送的200 OK消息，导致呼叫未建立。

(2)基站侧跟踪分析通过U2000跟踪信令流程，发现网络侧收到INVITE消息后，下发了100trying信令，之后也下发了183消息，但未向EPC上传PRACK消息，由于正常的呼叫流程U2000跟踪也只显示上传PRACK消息，而不显示收到UE侧上行的PRAC消息，因此不能证明基站是否收到UE PRACK消息但未转发给EPC，导致SIP流程未走通，呼叫失败。