1、MME专载保持功能验证
**描述：**当无线环境较差时，有可能由于“Radio_Connection_with_UE_Lost” 原因造成的VoLTE通话掉话，如果UE发生RRC重建成功，手机将不会掉话。
对MME1202进行功能验证：开启后，MME专载保持的成功率为90%左右，有利于改善掉话指标。

在通话过程中无线信号变弱，之后手机于00:26:31.287处于Idle状态

发起RRC connect request，在之后的RRC 重配消息里我们可以看到存有QCI1的DRB
MME并没有删除专载（执行Delete Bearer Command），而是只释放UE context release消息，但是专载还在保持

2、多目标RRC重建功能验证
**描述：**多目标RRC重建功能开启，可以有效的提升网络性能。在VoLTE业务中，可以保持通话，提高RRC重建成功率。
选择28网格(共163个小区)进行试验，功能开启后，可以有效的提升网络性能，在MBB业务中，它可以使得RRC重建成功率提升60%，UE掉线率改善10%以上。已全网开通。

RRC重建成功率从31%提高到50%,提升了60%，UE掉话率从0.918%降低到0.825%，改善超过10%。
[外链图片转存失败,源站可能有防盗在这里插入!链机制,建描述]议将图片上https://传(imblog.csdnimg.cngd-

3、DRX配置问题
**现象：**外场测试中发现手机无法进行IMS注册，多次重新启动后，问题依旧存在。需定位问题原因
原因排查：分析消息信令发现网络下发QCI5的重配消息后，UE没有发送重配完成消息，之后发起了原因值为reconfigurationFailure的RRC重建消息。RRC重建拒绝后，QCI5请求失败，UE进入IDLE模式。
从UE log来看，UE收到网络下发的QCI重配消息后，在MAC层出现RADIO LINK FAILURE
对比QCI5重配消息中发现在DRX设置与之前不一致，当前的DRX设置为图1，成功的DRX设置为图2

解决方案：更改DRX设置后恢复正常。

4、Attach引起的异常事件
**问题描述：**在主被叫通话过程中，主叫发起LTE-NAS attach request，attach完成之后，进行IMS SIP 注册请求，在此过程过程中，网络给被叫发起bye（Content=reason: SIP; text=“signal losed timeout”)
问题分析:主被叫15:33:04.090通话成功，15:33:50.898主叫进行LTE-NAS Attach request（EPS_Attach_Type = (2)combined EPS/IMSI attach）默认承载（QCI9）建立成功，attach完成，PDN connect完成，QCI5等建立之后，主叫于15:33:59.727上发IMS_SIP_REGISTER request,15:34:01.349手机上发Notify200，IMS SIP注册成功，在此期间15:33:59.490网络给被叫下发bye
（Content = Reason: SIP;text=“signal losed timeout）
被叫上发bye 200，之后拆专载，主叫没有收到任何bye响应，于15:34:08.780软件统计为掉话。
**问题总结：**在一月份拉网测试中，有37次掉话是因为手机发起attach导致，需要定位终端为何无缘无故发起Attach。

5、IMS周期性重注册引起的异常事件
问题描述：
主被叫通话成功，在通话过程中，被叫发起了IMS _SIP_REGISTER request ，在此过程中，网络给主叫下发bye（Content = Reason: Q.850;cause=31,SIP;text=“S.gd.chinamobile.com.261.005.125.00045 CSCF released the session because of USER DEREGISTRATION” ），导致掉话
问题分析:
主被叫于15:10:06.174通话成功，通话1分钟后，被叫手机于15:11:42.014进行IMS_SIP重注册（被叫在10分钟前进行过一次IMS SIP注册，软件显示注册成功），在15:11:43.584手机上发Notify 200注册成功，与此同时主叫在15:11:43.494收到网络下发bye（Content = Reason: Q.850;cause=31,SIP;text=“S.gd.chinamobile.com.261.005.125.00045 CSCF released the session because of USER DEREGISTRATION” ），整个过程无线环境良好RSRP-90，sinr20；而被叫没有收到bye，也没有上发bye200，在15:12:15.544收到网络下发的拆专载建立请求，之后软件统计被叫为一次掉话。
解决方案：
重注册掉话的问题已经定位，是由于重注册时网络侧没有带P-Associated-URI，导致终端认为失败，然后在第60分钟是更换PCSCF地址重注册，导致掉话。
目前华为IMS已经对此作出修改，
验证结果：
针对此类问题我们在1月28号对由于IMS周期性注册而掉话较多的网格50,51进行复测验证，发现此问题掉话消失，案例如下，
主被叫通话1分钟后，被叫于13:56:20.968发起每50分钟的IMS周期重注册请求，200ms后网络下发IMS_SIP_REGISTER 200 ok,通话满三分钟后，正常挂机，通话结束
10分钟后，我们从测试数据来看，手机正常通话，满三分钟后，正常挂机，期间没有注册过程
由此可见在如果第50分钟UE IMS重注册成功，在第60分钟UE就不会因为更换PCSCF再进行重注册而导致的掉话；

6、TAU流程冲突导致VoLTE异常问题
**问题描述：**终端在TAC边界发起呼过程中，若终端触发了跨TAI切换，随之发起TAU更新，之后QCI1专载被网络侧释放，最终导致未接通事件。
主叫侧：UE于发起INVITE消息之后，建立RRC连接和QCI5、QCI9承载。并触发了跨TAC切换，切换完成之后，发起了TAU更新，TAU更新成功，在此期间又触发了2次跨TAC切换，并发起TAU更新过程。主叫于收到网络下发的INVITE 503，导致未接通事件。
被叫测：UE于收到PAGING消息，建立了RRC连接，建立了QCI1专载，之后，发起了跨TAC切换，并发起TAU更新过程，TAU更新完成之后，网络于侧下发专载释放请求，
**问题分析：**从炎强后台系统来看，MOC上看到多次切换和TAU更新后，MME向eNB下发UEcontextreleasecommand 消息，原因值为release-due-to-eutran-generated-reason，导致MME没有下发专载建立请求见右图1：
而被叫侧由于TAU请求消息中的Active flag = 0，即no bearer establishment request。故MME下发专载释放消息，见右图2，
由此可见，由于终端发起TAU请求中的标志位Active flag有误，导致MME把专载被释放，从而导致未接通事件
**解决方案：**建议终端修改在有QCI1专载的情况下的标志位Active flag为1,从而专载被保持，VoLTE通话正常

7、被叫注册失败导致未接通
**问题描述：**主叫发起invite消息，直到收到网络下发的PRACK200之后，网络下发的INVITE487 Request Terminated，被叫在前面有次注册失败导致，而在呼叫这个时刻由于注销导致拆除
**问题分析：**主叫侧分析：
【ims分析】183协商报错“temporary failure”
从问题描述上来看，本次接通失败主要是由于被叫的2次重注册导致未接通。
【ims分析】从注册信令来看，14:15:07S从PSBC2注册到IMS，14:15:08S被叫完成注册；CSC发NOTIFY通知PSBC04注销用户；失败的呼叫时15:14:58S起呼的，导致呼叫失败。
从前一次注册来看，终端刷新注册失败，原因是没有带鉴权向量，导致被叫终端更换SBC重新注册，见右图
正常的注册流程如右图：
其中在第一个REGISTER消息中的字段Authorization:中的内容“nonce”和“response”都是空的。而网络下发的的401 Unauthorize字段Authorization:中的内容nonce为随机码和“response”为空，终端在回复第二个REGISTER消息中的字段Authorization:中的内容nonce抄写“nonce”的内容，并填充“response”内容。自此过程鉴权通过。
而本次case中，第二个REGISTER的鉴权向量为空。出现400 Bad Request消息原因值为"Sip key parameter invalid“。
另外，IMS注册相关定时器为32s
问题总结:
该问题主要是由于被叫注册失败导致主叫接通不了而导致的掉话，而注册过程中，终端和网络需要核对鉴权向量，当终端和网络协商鉴权向量一致时，才能保证注册成功。