VOLTE异常掉话后连续未接通案例

一、案例关键字二、问题描述：VOLTE拉网路测过程中，测试车辆行驶于南通西路扬州-三元桥LD站点附近时，出现一次掉话事件，随后主叫发起下一次会话建立请求，而网络侧下发INVITE403，再次出现一次未接通事件：三、问题分析：关于VOLTE基本流程和信令解释如下：1. 用户A，摘机对用户B发起呼叫，用户A首先向AS服务器发起INVITE请求。

2. AS服务器回复100 Trying给用户A说明收到INVITE请求。

3. AS服务器通过认证确认用户认证已通过后，向被叫终端B转送INVITE请求。

4. 用户B向AS服务器送呼叫处理中的应答消息，100 Trying 。

5. 用户B向AS服务器送183 Session Progress消息，提示建立对话的进度信息。

（此时被叫QCI1专用承载建立）6. AS服务器向主叫终端A转送183 Session Progress消息，终端A了解到整个Session的建立进度消息。

7. 终端A向AS服务器回复临时应答消息PRACK，表示收到183 Session Progress消息。

（此时主叫QCI1专用承载建立）8. AS服务器向被叫终端B转送临时应答消息PRACK ，终端B了解到终端A收到183Session Progress消息。

9. 被叫终端B向AS服务器发送200 OK消息，表示183 Session Progress请求已经处理成功。

10. AS服务器向主叫终端A转送200 OK消息。

11. 主叫终端A向AS服务器发送UPDATE消息，意在与被叫终端B协商相关SDP信息。

12. AS服务器向被叫终端B转送UPDATE消息。

13. 被叫终端B向AS服务器发送200 OK消息，表示UPDATE请求已经处理成功。

14. AS服务器向主叫用户A转送200 OK消息，通知用户A UPDATE请求已经处理成功。

15. 被叫用户B振铃，用户振铃后，向AS服务器发送180 Ringing 振铃信息。

芜湖频繁切换导致未接通优化案例【摘要】切换失败、切换过早或过晚、切错小区和乒乓切换等情况，都会直接影响客户感知，系统的性能。

本文是通话建立过程中频繁切换引起核心网侧QCI1释放，主叫收到503 Service Unavailable (1:223),被叫收到CANCEL (Reason 503)导致未接通的案例。

【关键字】频繁切换 CANCEL 未接通【故障现象】当UE行驶至北京西路中和路附近，主叫占用WH-市区-福达大厦-ZFTA-442413-0起呼，建立过程中语音转载建立失败，主叫收到503 Service Unavailable (1:223),被叫收到CANCEL (Reason 503)导致未接通。

【告警信息】对周边小区进行告警查询，无影响业务异常告警。

【原因分析】（一）VOLTE基本流程和信令解释如下：（二）问题分析流程如下：（三）未接通事件常见原因：1、信号覆盖质量差现场测试信号覆盖良好，且查看前几个月的测试LOG发现均不存在弱覆盖和sinr差，因此排除覆盖差、无线环境差导致的未通。

2、参数设置问题通过后台网格核查该站点的参数设置，发现该站点的参数设置符合省公司标准，且与周边站点设置一致。

3、核心网问题主叫信令流程：从信令流程可以看到12:03:53.809的handover导致DRB identity 5被释放，而从12:03:48.006建立专载的信令可以看到DRB identity 5为EBI 7即QCI1，所以该handover导致QCI1被释放，主叫主动发送cancel。

被叫信令流程：主叫12:03:46.103发起寻呼，12:03:48.973收到invite 180，12:03:53.825由"WH-市区-福达大厦-ZFTA-442413-0"切换至"WH-市区-新市口-ZFTA-442369-52"，信号相当，频繁切换导致主叫于12:03:53.856主动上发cancel，12:03:53.934收到IMS_SIP_INVITE 503，造成未接通；形成原因为主服务小区不明显造成频繁切换，核心网侧QCI 1释放，引起未接通。

终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。

终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。

被叫上发的183里不携带SDP信息，正常的是会携带Session Description Protocol 信息的，导致SBC不发起承载建立。

主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。

1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMedia Attribute (a): curr:qos local sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local sendrecv| | Media Attribute (a): curr:qos remote none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote none| | Media Attribute (a): des:qos mandatory local sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv | | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 但在终端返回的183和update 200ok消息中，终端没有完成承载预留Media Attribute (a): curr:qos local none| | Media Attribute Fieldname: curr| | Media Attribute Value: qos local none| | Media Attribute (a): curr:qos remote sendrecv| | Media Attribute Fieldname: curr| | Media Attribute Value: qos remote sendrecv| | Media Attribute (a): des:qos mandatory local sendrecv| | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory local sendrecv| | Media Attribute (a): des:qos mandatory remote sendrecv | | Media Attribute Fieldname: des| | Media Attribute Value: qos mandatory remote sendrecv 现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。

光明路和汤王大道交口北附近未接通优化摘要： VoLTE是通信基础话音业务的一次全面升级,是无线网、核心网、信令网、承载网、支撑系统的一次系统性改造和变革，VoLTE异常事件的处理相对于C网时代，有着重大区别，不仅关注无线侧问题，核心测问题更需要关注。

关键字：VoLTE 无线网信令网核心网【故障现象】：UE由北向南行驶至光明路和汤王大道交口北附近UE占用BZ-市区-劳服中心-HFUA-439095-55小区信号（RSRP=-75dBm ， PCI=89 ）出现主叫未接通；见下图：【原因分析】：1.干扰情况分析通过干扰核查没有发现异常2.根据测试数据分析，问题路段主叫占用BZ-市区-劳服中心-HFUA-439095-55小区信号（RSRP=-75dBm ，PCI=89 ），无线环境良好，根据信令分析，在测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件（Time: 20181022 14:47:59.255 ，经度：115.760589 纬度：33.858342）。

3.车辆由北向南行驶至光明路和汤王大道交口北附近UE占用BZ-市区-劳服中心-HFUA-439095-55小区信号（RSRP=-75dBm ， PCI=89 ）之后一直发起寻呼消息，14:42:56.235发起 183 进程， 14:42:56.354 释放 EPS 承载， 14:47:43.215主叫收到网络侧下发的 580 进程，由于呼叫建立与切换过程冲突，专载被MME 释放；呼叫建立过程中专载建立与切换几乎同时发生，MME 未收到NAS 专载完成消息导致释放专载；UE就会回复invite580，专有承载丢失形成的未接通事件4.专载QCI 1被释放，去激活后，被叫发送INVITE 580，主叫收到网络侧转发的INVITE580，会话流程中断，导致未接通。

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

TAC设置不合理导致VoLTE未接通目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)TAC设置不合理导致VoLTE未接通【摘要】随着VoLTE业务的不断推广，VoLTE用户数逐步增加，VoLTE业务的感知成为关注的焦点。

经过几个月的不断优化，铜陵VoLTE网络掉话率逐步减少，但是未接通现象仍时有发生。

为提高用户的VoLTE通话感知，需时刻关注未接通发生的原因，逐步解决，提升接通率，保障用户通话感知。

【关键字】VoLTE 未接通【业务类别】VoLTE、参数优化一、问题描述RCU设备在铜陵铜官区北京东路上进行VOLTE路测时，主叫起呼发出Invite消息后，在收到核心网响应Trying 100之前,先收到了核心网下发的RRC Connection Release消息,RRC连接释放后,接续被终止，出现了未接通事件。

二、分析过程通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从TL-市区-康复中心-HFTA-448900-53小区（PCI：210）重选至TL-市区-市二院-HFTA-448913-54小区（PCI：356小区），由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。

然而Invite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫同时释放，从而导致了Blocked Call事件的发生。

三、解决措施由于TL-市区-康复中心-HFTA-448900-53小区的TAC设置为28035，TL-市区-市二院-HFTA-448913-54小区的TAC为28039，两个小区之间正好处于TAC边界。

该路段是一段长距离的连续下坡，车速较快，TAC更新引起此次未接通。

Volte掉话案例在对已经升级为14.3版本的网格10进行拉网测试时发现，仍出现主叫与被叫先后上发BYE，去激活专用承载后收到BYE487导致掉话问题，具体情况如下：被叫，主被叫先后发起Bye消息，去激活专用承载后，网络侧下发Bye 487导致掉话（截图如下）：（A）核心网消息跟踪上看，被叫在15:35:51.470先上发BYE，核心侧未等到主叫回BYE200，就在15:35:51.556又收到主叫上发的BYE消息。

导致核心侧发BYE487：Glare BYE condition encountered，原因：在下发一个bye请求(来自被叫)，但还没有收到应答，收到一个上行的bye请求（来自主叫）。

（B）之前已经出现BYE487掉话的问题，是因为与华为站点的PDCP-SN-SIZE设置不同导致的掉话，但是网格10进行升版之后已经全部修改一致。

为了对问题更好的定位，次日我们对网格10又进行了一次拉网测试，并留意观察在掉话之前是否有声音以最终确定问题现象与PDCP-SN-SIZE导致的问题是否一致！结果发现在BYE487问题导致掉话前10s是没有声音的。

所以依然是单通和不通导致的掉话。

在对拉网数据进行分析时发现，在黄浦路二试扩L-1小区下进行起呼时在下发重配消息中的PDCP-SN-SIZE还是12bit。

（C）所以我们再一次进行了参数的核查，发现14.3版本的站点的应该和LR13.3一样指向DedicatedConf/0 PdcpConf/1，因为DedicatedConf/0 PdcpConf/2中定义的PDCPPDUSNSIZE=12,所以指向到了DedicatedConf/0 PdcpConf/2，就出错了。

截图如下：（D）最终核查结果又一百多个站点的指向错误，在修改指向后进行了复测，BYE487掉话没有出现。

精品案例_电信Volte用户异常掉话故障排查案例Volte用户异常掉话故障排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)宣城电信Volte用户异常掉话故障排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB 异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。

【关键字】VoLTE 掉话专用承载【业务类别】VoLTE、掉话一、问题描述3月23日对宣城电信市区的主要路段进行了VOLTE业务拉网测试。

统计分析指标时，按照省公司下发的VOLTE业务能力测试规范统计指标时，发现1处掉话测试UE在其他基站可以正常进行VoLTE呼叫，基本可以排除测试UE的问题。

并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。

由于之前一直未查出原因，现场还进行数据重新制作，也未能解决。

二、分析过程按逻辑时间在MS1信令中查找该问题点，是一条RRC连接释放消息，如下图：向上查找，在22:53:13:452时刻发现DEACTIVATE EPS REQ （EPS承载去激活请求）消息，并得到了网络的响应（DEACTIVATE EPS ACC）。

继续向上查找，发现在22:53:13:392时刻MS1收到了BYE 500 Service Internal消息，如下图：查看消息体（下图），该消息为网络下发给UE的（Network to UE）,告警正文中显示无法收到对端（MS2）的响应（No Response From Peer）。

全网V O L T E终呼未接通分析案例分析LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】终呼未接通分析基于SEQ第一拆线原因对全网终呼未接通进行分析汇总。

终呼第一拆线原因占比表：根据第一拆线原因、拆线原因、拆线网元对终呼未接通进行分析汇总：1终呼580未接通1.1VOBB用户INVITE信息不符合协议规范VOBB用户拨打苹果VOLTE用户，由于VOBB用户INVITE信息里support中不携带100rel，导致苹果终端返回的183消息中不携带SDP，SBC不发起承载建立导致未接通详细话单信令：VOBB下发的INVITE消息里Supported里不携带100rel,正常一般携带Supported:100rel,timer,histinfo,precondition。

被叫上发的183里不携带SDP信息，正常的是会携带SessionDescriptionProtocol信息的，导致SBC不发起承载建立。

主叫发出183到被叫6秒后没有建立承载超时后主叫UE上发580 LOCAL QOS NOT ESTABLISHED(Cause:580)导致未接通处理建议：按照协议规范升级VOBB终端，使之VOBB终端INVITE信息符合规范。

1.2三星终端和彩铃平台配合异常在发给被叫的invite和update消息中，要求被叫终端完成preconditionMediaAttribute(a):curr:qoslocalsendrecv||MediaAttributeFieldname:curr||MediaAttributeValue:qoslocalsendrecv||MediaAttribute(a):curr:qosremotenone||MediaAttributeFieldname:curr||MediaAttributeValue:qosremotenone||MediaAttribute(a):des:qosmandatorylocalsendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatorylocalsendrecv||MediaAttribute(a):des:qosmandatoryremotesendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatoryremotesendrecv但在终端返回的183和update 200ok消息中，终端没有完成承载预留MediaAttribute(a):curr:qoslocalnone||MediaAttributeFieldname:curr||MediaAttributeValue:qoslocalnone||MediaAttribute(a):curr:qosremotesendrecv||MediaAttributeFieldname:curr||MediaAttributeValue:qosremotesendrecv||MediaAttribute(a):des:qosmandatorylocalsendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatorylocalsendrecv||MediaAttribute(a):des:qosmandatoryremotesendrecv||MediaAttributeFieldname:des||MediaAttributeValue:qosmandatoryremotesendrecv现有彩铃平台SNEC82版本是在继续等待被叫发送的新的完成资源预留的UPDATE，但是一直没有新来UPDATE，超时了。

VOLTE拨打2G未接通问题分析问题描述：20:18:18.380主叫开始起呼被叫，20:18:21.052主叫开始重配建立CQI=1专载并激活，20:18:21.113到20:18:34.643这段时间主叫方没有任何信令，20:18:34.643时MME下发重配消息，但CQI=1专载被释放，主叫没有收到网络侧下发IMS_SIP_INVITE 183，主叫等待超时主动上发挂机，造成未接通。

问题分析：从主叫信令来看，主叫起呼，随后建立CQI=1专载并激活。

激活后主叫在20:18:21.113到20:18:34.643这段时间主叫方没有任何信令，volte主叫信令正常。

主叫信令流程：从被叫信令来看，20:18:18.380时刻主叫发起对被叫寻呼，20:18:20.123时刻被叫收到主叫发起的寻呼并回应寻呼，建立SDCCH回应pagerespone,随后鉴权加密，但后续一直无法建立TCH（被叫终端未收到2G网络侧下发建立TCH信令RR Assignment Command），13秒后被叫网络侧下发DISCONNECTED，原因Temporary failure。

被叫信令流程：主叫由于长时间未收到网络回应的183消息，最终导致超时，网络侧MME下发QCI=1释放，最终导致未接通。

初步判断2G网络侧TCH未能成功建立造成主叫寻出现未接通。

查询被叫当时占用的2G小区“江门污水处理厂1(CI=20011,LAC=9287)”，对应时间段小区的状态正常，无告警、无TCH拥塞，但存在轻微的外部干扰外。

再回到现场进行了多轮20次的VoLTE拔打2G拨打，接通成功率为100%。

没有再次发生未接通问题，故怀疑是当时2G无线环境引起的未接通。

问题结论：本次VOLTE拨打2G的失败，原因为被叫侧2G的无线环境导致TCH未分配成功引起的未接通，并非是VOLTE主叫侧的问题。

volte试商用初期的测试分析中，由于volte侧涉及一系列的网元改造和新网元入网工程。

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，重建立不成功时掉话。

广东移动4GTD-LTE详细案例分析案例1：580 Precondition Failure导致的未接通;问题描述在集团测试LOG中,存在Precondition Failure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580 Precondition Failure消息,随后呼叫中止,出现未接通事件;Log文件名：MO UE:MT UE:时间：10：16：1、呼叫过程中,被叫发送Ringing 180后,收到网络下发的专载去激活命令,QCI 1被释放,被叫随后上报580 Precondition Failure,主叫同样收到网络侧转发的580消息,呼叫接续中止,导致未接通;2、从信令中可以看到,被叫回复Ringing 180且主叫也已经收到Ringing 180,被叫随后收到网络侧下发的RRC重配,携带有QCI 1被释放的信息,被叫去激活专有承载;由于专载已被释放,业务资源已不存在,所以被叫上发580 Precondition Failure 失败消息;主叫收到网络侧下发的580,接续被中止,导致了会话未接通;3、从MME下发到Node B的E-RAB RELEASE COMMAND,原因上看是Nas层nomal_release,导致专载QCI 1被释放;4、专载QCI 1被释放,去激活后,被叫发送INVITE 580,主叫收到网络侧转发的INVITE580,会话流程中断,导致未接通在正常的会话流程中,由于MME下发E-RAB RELEASE COMMAND,使得QCI 1被释放,导致未接通;解决措施需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND;测试验证案例2：Server Internal Error 500导致的未接通问题描述在集团测试LOG中,存在Server Internal Error 导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的Server Internal Error 500消息,随后呼叫中止,出现未接通事件;Log文件名：MO UE:MT UE:时间：10：19：问题分析1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE 200,随后被叫发送Ringing 180,主叫同时收到UPDATE 200和Ringing 180;按照正常的信令流程应该是先收到UPDATE 200,再收到Ringing 180;2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放,去激活,导致会话未接通;问题定位主叫收到网络侧下发的INVITE 500,然后网络侧又下发RRC重配,释放掉QCI 1,然后去激活,会话流程终止,导致未接通解决措施需要核心网确认,为什么会下发INVITE 500,什么情况下会导致网络侧下发INVITE 500,随后的专载释放是否由INVITE 500导致的测试验证案例3：软件对失败事件的误判导致统计错误问题描述在集团测试LOG中,存在软件的误判而错误统计的失败事件;如在某个特定时间点上,信令显示主被叫正常通话,软件却统计出掉话或未接通事件;Log文件名：MO UE:MT UE:时间：09：44：问题分析1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功,在通话过程中信令流程正常,中间出现一次RRC重建被拒,导致RRC释放,事件表现为掉话,软件统计为掉话;2、在09：44：主叫收到网络侧下发的RRC重建被拒,主叫随后发起RRC建立请求,在09：44：15：004,然后因为TAU,在09：44：15：128 RRC Connection Release了,软件统计为掉话;随后主叫又发起RRC连接,且在09：44：重建完成,从RRC重建被拒到RRC连接成功不到1s,且默认承载和专有承载均保持,未被释放,证明会话保持正常;3、到最后结束通话正常挂机都没有出现失败事件问题定位主叫接通后,在没有收到通话结束的情况下,中间出现RRC Connection Release,软件判断为掉线,此次是在会话建立后出现,软件统计为掉话解决措施需要鼎利修改判断事件失败的机制测试验证案例4：软件对失败事件的重复统计问题描述软件对于失败事件存在重复统计的问题,在集团测试问题统计表中,多次出现同一次失败事件,软件却作了多次统计,导致失败事件的增多;Log文件名：MO UE:MT UE:时间：10：04：问题分析1、主叫在10：04：发出INVITE会话请求,被叫在10：04：收到网络侧下发的BYE Request,软件统计为掉话;查看BYE Request中的CALL-ID,发现是上次会话的BYE Request2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100,又在10：04：收到网络侧下发的INVITE Request同时发送Trying 100,并在同时发送INVITE 486,软件统计为未接通;3、主叫在收到网络侧下发的UPDATE 200后,在10：04：上报Cancel,主叫的整个会话流程到这里被终止,事件上表现为未接通;且承载都存在问题定位通话期间,被叫收到网络下发的BYE Request会被软件统计为掉话;被叫连续两次收到网络下发的INVITE Request,回复INVITE 486 Busy Here,由于第一次INVITE Request未释放,故第二次INVITE Request网络侧才会下发INVITE 486,流程停止,软件统计为未接通;此时主叫在进行正常的会话接续,信令流程正常,事件中未出现失败事件;直到主叫上报Cancel,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计;解决措施需要鼎利确认对失败事件的统计机制;测试验证案例5：LTE到2G eSRVCC切换失败导致的掉话问题描述呼叫会话建立后,由于到达异系统B2门限,终端上报B2事件,网络下发eSRVCC切换配置命令,但在2G侧切入失败,导致掉话;Log文件名：MO UE:MT UE:时间：11：16：42：311问题分析1、被叫上报B2事件,满足切换门限系统下发mobility切换命令,此时4G的流程已完成,接下来切入2G网络,2G网络下发TMSI Reallocation Command,被叫回复TMSI Reallocation Complete,此后流程中断,eSRVCC切换失败;3、信令上看,4G流程正常走完且建立会话,被叫切换到2G,但是网络下发TMSIReallocation Command导致流程终止,eSRVCC切换失败,会话流程结束,怀疑是2G问题;问题定位4G流程正常且已正常建立会话,由于2G网络侧下发TMSI Reallocation Command导致eSRVCC 切换失败,会话流程结束,导致掉话,怀疑是2G的问题;解决措施下周准备复侧,准备定位;测试验证案例6：TAU过程中RRC Connection Release 导致的未接通问题描述在越秀区网格10的测试LOG中,出现如下的未接通事件：主叫起呼发出Invite消息后,在收到网络效应Trying 100之前,先收到了网络下发的RRC Connection Release消息,RRC连接释放后,接续被终止,出现了Blocked Call事件;问题分析1、通过信令详细分析主叫起呼的过程,可以发现,起呼前,主叫刚完成重选过程,从PCI216小区重选至PCI103小区,由于源小区与目标小区处在不同的TAC,主叫发起了TAU请求：2、在主叫上发TAU请求后,未等网络回复ATU Accept,主叫已开始了起呼,上发Invite消息;然而Invite上发后,主叫同时收到了网络下发的ATU Accept和RRC Connection Release 消息因此时主叫处在非业务态,ATU更新会伴随RRC连接的释放,主叫被叫释放,从而导致了Blocked Call事件的发生：3、进一步分析信令可以发现,主叫在该测试路段内连续在3个TAC9437、10315、10014间进行TAU更新,其中从11:42:53至11:43:04就发生了4次,可能在存在TAC规划不合理的问题;问题定位解决措施测试验证案例7：Alerting中eSRVCC失败导致未接通问题描述主叫起呼后,流程正常,达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180,主叫未摘机,由于切换失败导致未接通;Log文件名：MO UE:MT UE:时间：11：25：28：189问题分析1、主叫在11：25：起呼,到11：25：收到网络侧转发的Ringing 180,整个信令流程正常2、在主叫几乎收到网络侧转发的Ringing 180的同时,主叫达到eSRVCC切换门限,网络侧在11：25：下发eSRVCC切换命令,在切换过程中主叫处于振铃中,并未摘话,而切换失败,导致了未接通;问题定位主叫已经收到Ringing 180,处于振铃状态还未摘话,由于在Alerting中发生了eSRVCC 切换失败导致了未接通解决措施需要核心网方面帮忙定位测试验证案例8：CSFB失败导致未接通问题描述主叫起呼后,被叫CSFB失败,主叫直接Cancel导致未接通Log文件名：MO UE:MT UE:时间：15：42：53：063问题分析1、主叫于15:42:22发起invite,被叫未收到网络侧转发的INVITE Request,但是主叫能一直收到网络侧下发的INVITE 183 、PRACK、UPDATE消息,这些消息被叫并没有收到也没有回复;被叫在15:42:24收到网络侧下发的CSFB request,但CSFB到2G后从信令看没有呼叫相关的信令交互过程2、直到15:42:35 CSFB失败,由于收不到被叫的响应,主叫主动于15:42:53发起CANCLE;导致会话未接通;问题定位主叫发起会话后,被叫没有收到会话请求,直接CSFB,CSFB失败,主叫一直未收到被叫的响应,直接Cancel,导致会话未接通;解决措施需要核心网查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息;测试验证案例9：被叫Detach导致会话未接通问题描述主叫发起会话,被叫驻留在2G未返回4G,没有响应主叫的会话请求,主叫收不到被叫相应,直接Cancel导致未接通;Log文件名：MO UE:MT UE:时间：15：43：37：999问题分析1、主叫在15：43：起呼,此时被叫任然驻留在2G,由于上一次会话中CSFB失败,并没有返回4G;2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发的PRACK、UPDATE消息;3、主叫一直收不到被叫的回复,被叫在15:43:被叫上发Detach Request,主叫在15：43：上发Cancel,取消会话,导致未接通问题定位被叫停留在2G未返回4G,然后上发Detach Request,主叫收不到被叫的回复,直接Cancel,导致未接通解决措施需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请求;同时查看2G无线侧,为什么被叫会上发Detach Request;测试验证案例10：承载未建立导致未接通问题描述主叫收到100 Trying 后未建立承载,使得 RRC直接释放,导致未接通Log文件名：MO UE:MT UE:时间：15：46：36：271问题分析1、主叫在15：46：发起会话,收到网络侧下发的100 Trying后,专有承载一直未建立,10s后RRC释放,主叫在15：46：上发Cancel,导致会话未接通问题定位专有承载未建立,10s后RRC释放,导致未接通解决措施需要核心网查看为什么没有建立专有承载测试验证案例11：承载异常释放导致掉话问题描述被叫重建立成功后,专有承载突然被释放,导致掉话Log文件名：MO UE:MT UE:时间：10：35：41：981问题分析1、主叫在10：28：起呼,流程正常,收到网络侧转发的Ringing 180,UPDATE 200,主被叫会话正常建立;2、被叫在10：35：发送重建立,重建立成功,且流程正常,但是在10：35：承载被释放,导致掉话问题定位会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话解决措施需要核心网确认承载释放的原因测试验证案例12：信令转发失败导致未接通问题描述主叫发起会话请求,网络侧未转发,被叫未收到,主叫Cancel,导致未接通Log文件名：MO UE:MT UE:时间：10：03：48：952问题分析主叫在10：03：发起会话,被叫未收到,直到10：03：主叫Cancel,会话接续无法继续,导致未接通;整个过程无线环境良好,网络侧未转发信令;问题定位网络侧未转发主叫会话请求,使得会话接续无法继续,主叫Cancel,导致未接通;解决措施需要核心网确认会话信令是否成功转发测试验证案例13：终端上报Cancel导致会话未接通问题描述会话流程正常接续,终端上报Cancel,导致会话未接通Log文件名：MO UE:MT UE:时间：14：53：06：510问题分析1、主叫在14：53：起呼,信令流程正常,且被叫上发Ringing 180,主叫收到网络侧转发的Ringing 180,主被叫都已经振铃;但是主叫突然在14：53：上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通;问题定位主被叫会话流程正常,无线环境良好,信令转发正常;主叫上报Cancel,导致会话未接通,定位为终端问题解决措施需要终端确认或者更换终端测试再查看结果测试验证。

VOLTE异常掉话后连续未接通分析案例设备厂家：华为设备型号：HTC-M8 时间：2016/2/9关键字： VOLTE、掉话、BYE、语音一、问题内容：日常VOLTE测试中(1)主叫在19:15:10.645发起BYE挂机请求；（2）被叫一直未收到BYE消息;（3）主叫在19:15:16.829收到网络侧下发的BYE408消息，原因值是“No Response From Network”，主叫掉话；（4）19:15:30.649和19:15:33.684被叫发BYE请求，19:15:33.779网络侧应答BYE487（Glare Bye condition encountered）主叫掉话后紧接着发生连续两次未接通掉话未接通二、问题分析：掉话分析：主叫发了BYE请求，无线环境较好的情况下被叫却一直未收到BYE消息，需要核心网定位是否下发了BYE消息给被叫手机【IMS核心网信令分析】：被叫侧SBC在主叫挂机后，随即向被叫UE发送了BYE消息。

需EPC继续排查。

主被叫掉话后线环境较好，且主叫手机收到了INVITE100，但是被叫手机一直未收到INVITE。

需要核心网定位这两次呼叫是否向被叫终端下发了INVITE消息。

【IMS核心网信令分析】：两次呼叫中被叫侧SBC在主叫发起INVITE后，随即向被叫UE发送INVITE。

需EPC继续排查。

正常挂机流程：正常挂机流程，由主被叫任何一方发起BYE消息，经由IMS系统、PGW，SGW发送到对端设备，对端设备回复BYE 200确认消息，通话结束。

三、解决方案：问题点原因在空口质量良好的情况下被叫未受到BYE消息，主叫超时未挂断导致掉话，怀疑EPC 和IMS之间的接口问题，目前对问题点占用小区进行反复拨测，未出现问题，接口问题需要厂家进一步定位原因。

1、核心网及无线测设备参数核查，对定时器等参数进行优化2、对于基站故障及空口拥塞区域进行处理，保证覆盖及容量四、借鉴经验：随着4G网络VOLTE技术的到来，VOLTE掉话逐步凸现出来，除去空口质量问题之外还存在一些设备厂家接口之间的问题，需要逐步完善发现的问题，解决问题。

1.【问题描述】：MS1在接收到金昌利-3小区时发生严重的语音质量差，导致掉话，情况如图所示：
【问题分析】：MS1在接收到金昌利-3小区，MIAO为2时，通过分析信令得知，手机像基站连续发出测量报告，得不到基站回应，上行链路弱，导致掉话
【优化方案】：更换MAIO为2的载频
2.【问题描述】：驱车行驶，手机在金昌利-2小区附近利用电机厂-3小区信号起呼，导致一次未接通，情况如图所示：
【问题分析】：手机在金昌利-2小区附近利用电机厂-3小区信号起呼，导致一次未接通，疑似金昌利-2小区和电机厂-3小区没加邻区
【优化方案】增加邻区
3.【问题描述】：驱车行驶，在信德宾馆附近，手机由金昌利-2小区切换至电机厂-3小区发生一次掉话，情况如下：
【问题分析】：在信德宾馆附近，手机由金昌利-2小区切换至电机厂-3小区，没有占用沃尔玛小区信号，电机厂-3小区越区覆盖，导致一次掉话
【优化方案】：检查沃尔玛小区信号，下压电机厂-3小区天线。

Server Internal Error 500导致的VOLTE语音未接通分析案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (7)Server Internal Error 500导致的VOLTE语音未接通分析案例【摘要】VOLTE是基于IMS的语音业务，而IMS由于支持多种接入和丰富的多媒体业务，成为全IP时代的核心网标准架构。

经历了过去几年的发展成熟后，VOLTE已经实现规模商用。

VOLTE测试中核心网、上行质差会导致通话质量较差、掉话、未接通等问题，本文主要分析由于上行质差、核心网问题造成的未接通处理过程。

【关键字】核心网VOLTE【业务类别】VoLTE、过远覆盖、核心网一、问题描述统计RCU指标时发现7月13日10:52:43时在京台高速与宁洛高速立交桥附近出现未接通事件，车辆在该问题路段时由东向西行驶，占用BB-淮上区-蚌埠宁洛33站-ZFTA-440018-54小区信号，RSRP=-85dBm、SINR=7.4dB；主被叫均出现未接通。

二、分析过程主叫在10:52:35秒时发出IMS_SIP_INVITE->Trying的信令，在10:52:43时出现未接通事件，产生事件原因为IMS_SIP_INVITE->Server Internal Error 500，主叫占用B BB-淮上区-蚌埠宁洛33站-ZFTA-440018-54小区信号，RSRP=-84dBm、SINR=7.4dB，信号正常；分析被叫数据，被叫在10:52:36时收到IMS_SIP_INVITE->Trying 100消息后，占用BB-淮上区-丁岗村-ZFTA-156178-181小区信号，RSRP=-90dBm、SINR=-1.5dB左右，占用该小区信号SINR较差，发A3消息请求切换，但一直未切换至BB-淮上区-蚌埠宁洛33站-ZFTA-440018-54小区，最终由于Reason: MAX RETRX产生LTE RRC Radio Link Failure 事件；产生 LTE RRC Radio Link Failure事件后，小区重选至800M信号，占用BB-淮上区-市区吴郢-ZFTA-155978-150小区信号，RSRP=-83dBm,SINR=6.7dB,信号正常，小区进入空闲状态，一直未收到IMS_SIP_INVITE消息，被叫持续近6分钟空闲态，而主叫仍一直在呼叫尝试，导致主叫出现约10次未接通事件；主叫：被叫：查询核心网信令，核心网侧认为被叫切换至2G网络，因此导致主叫由于IMS_SIP_INVITE->Server Internal Error 500产生多次未接通事件三、解决措施优化方案（1）.从扇区分布上看BB-淮上区-丁岗村-ZFTA-156178-181存在越区覆盖，且与BB-淮上区-蚌埠宁洛33部-ZFTA-440018-54小区存在mod3干扰；BB-淮上区-丁岗村-ZFTA-156178-181小区下倾角由4度调整至8度，小区功率由18.2调整至15.2（2）.分析核心网侧切换至2G网络具体原因。

移动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消息，随后呼叫中止，出现未接通事件。

VOLTE未接通分析案例摘要：市区2.1G覆盖不连片导致的邻区干扰对VOLTE呼叫建立成功率和掉话影响较大关键字： VOLTE未接通 2.1G【故障现象】：汤王大道玉兰苑向北， 16:36:45.596主叫起呼随后信令正常交互至prack200，在16:37:05.391发cancel取消通话，此时统计为主叫未接通。

主叫占用BZ-市区-建安中学-HFTA-439095-50（RSRP=-63,SINR=17.3）。

【原因分析】：volte呼叫信令说明如下：1．1到6，UE起呼，UE高层协议层需要发送INVITE到IMS，触发RRC连接、安全模式等过程，并通过RRC重配置消息建立SRB2信令无线承载、恢复QCI 5承载，配置测量控制，IMS收到主叫的INITE消息，开始寻呼，并发送INVITE 100（TRYING）给主叫UE，用于响应INVITE 消息，INVITE消息中包含呼叫类型、主被叫的号码、主叫方支持的媒体类型和编码等；2．7到15，核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户，被叫UE收到寻呼后，触发RRC连接、安全模式等过程，被叫通过RRC重配置消息建立SRB2信令无线承载，CN侧通过QCI=5的RB向被叫发送INVITE消息，UE收到后发送INVITE 100消息进行响应，同时被叫发送INVITE 183消息给CN表示会话正在处理，启动Precondition(资源预留)过程，并通知主叫自己所支持的媒体类型和编码，并建立起QCI=1的承载；3. 16到17，IMS收到被叫的INVITE 83 后，对主叫启动Precondition(资源预留)过程，通过EPC通知主叫SM层建立起QCI=1的承载后，向UE发送INVITE 183消息；4．18到25，主叫向被叫发送PRACK消息，PRACK过程是一个预确认过程，主要为了防止会话超时及拥塞，被叫收到后返回PRACK 200，主叫收到被叫的PRACK 200以后，发送UPDATE消息，进行媒体格式协商过程，被叫通过UPDATE 200返回协商结果；5. 26到31是振铃接听过程，被叫发送INVITE 180给主叫，振铃，摘机后发送INVITE 200给主叫，主叫返回ACK进行确认，通话完全建立，进入通话过程；6. 32到37为挂机过程，通话结束后，主叫发送BYE请求结束本次会话，IMS服务器给被叫发送BYE,请求结束本次会话，被叫挂机，回BYE 200消息，核心网IMS服务器给主叫发BYE 200，标明会话结束，主被叫分别去激活EPS专用承载消息，删除QCI=1的数据无线承载。

VOLTE 580 Precondition Failure导致未接通案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)VOLTE 580 Precondition Failure导致未接通案例【摘要】VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。

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

【关键字】VoLTE 、VoLTE未接通【业务类别】参数优化一、问题描述在日常测试中，发现在全椒盛大2站附近发生 Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。

二、分析过程1.主被叫均在11:41:25.334左右，基站下发了RRC Connection Release消息主被叫进入空闲态。

2.主叫在11:41:32.214，发起了呼叫请求，网络测并响应主叫的呼叫请求，进行终端RRC 建立、终端能力查询等相应流程，随后网络测下发给主叫，INVITE100表示正在处理主叫的呼叫请求。

由于该路段存在无线环境较差现象，影响被叫终端直至11:41:46.968才响应呼叫的寻呼消息，进行服务建立准备。

3.被叫终端在11:41:47.044向网络测上发INVITE 100 、INVITE183消息，但网络测未向被叫终端下发RRC Connection Reconfiguration 消息建立QCI承载，11:41:47.347随后被叫终端上发580消息，主叫在11:41:51.233,上发CANCEL消息，网络测响应并下发给主叫487消息，导致本次主被叫未接通。

4. 追踪信令发现QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。