VOLTE异常掉话后连续未接通案例
被叫未收到BYE指示导致下次会话主叫未接通优化案例
一、案例关键字二、问题描述：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 振铃信息。
频繁切换导致VOLTE未接通优化案例
芜湖频繁切换导致未接通优化案例【摘要】切换失败、切换过早或过晚、切错小区和乒乓切换等情况，都会直接影响客户感知，系统的性能。
本文是通话建立过程中频繁切换引起核心网侧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释放，引起未接通。
全网VOLTE终呼未接通分析案例分析
终呼未接通分析基于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，会话流程中断，导致未接通。
VOLTE异常事件典型案例分析
异常事件典型案例分析未接通对第四轮测试数据进行分析发现未接通常见案例如下：未接通原因分类求和项:统计次数测试软件问题 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测试主叫异常掉话案例
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未接通
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掉话案例(参数指向错误)
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掉话没有出现。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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掉话逐步凸现出来，除去空口质量问题之外还存在一些设备厂家接口之间的问题，需要逐步完善发现的问题，解决问题。
目前VOLTE异常掉话受多种问题因素导致，如空口覆盖差，网络负荷高，核心网出入口带宽不足，核心网及空口参数设置不合理，遇到此类问题时，需按照排查步骤，一步步进行问题定位并制定解决方案，最终问题解决。