VOLTE路测问题点解析案例集（包括掉话、未接通、时延和MOS值低）

　　关键时刻，第一时间送达

　　

　　一、掉话问题点：

　　1.无线环境问题：

　　Case1：弱覆盖引起掉话

　　【问题现象】

　　测试车辆沿单家围子农村胡同由东向西行驶时，主占后三家子1小区RSRP=-113.56dBm，SINR=-7.2，此处严重弱覆盖导致掉话事件。

　　【问题分析】

　　主叫占用后三家子1小区RSRP=-113.56dBm，SINR=-7.2，此处路段由于蓖麻油厂站点拆除，导致此处路段严重弱覆盖，发生掉话事件。

　　

　　【解决方案】

　　调整运输小区东方位角120°到100°，方位角8°到6°，解决此处路段弱覆盖情况。

　　Case2：越区覆盖导致掉话

　　【问题现象】

　　主被叫寻呼正常通话时，被叫由小区“SYSY_粮食储备库_ZLH_32D_4_JN”切换到小区“SYSY_彩虹桥下西_ZLH_31F_4_JN”之后，由于SYSY_彩虹桥下西_ZLH_31F_4_JN小区距离远，属于越区覆盖，道路覆盖慢慢变差，直到脱网到TD-SCDMA网络，软件最终记被叫一次掉话。

　　【问题分析】

　　主叫在17:36:01.669发起Invite寻呼请求，在17:36:01.873收到网络下发的trying100。被叫在17:36:03.509响应MME寻呼请求，在17:36:03.624收到网络转发的Invite寻呼消息，之后主被叫SIP信令流程转发正常，主叫在17:36:05.981上发ACK请求，被叫在17:36:06.213收到网络转发的ACK消息，之后主被叫正常通话，被叫由小区“SYSY_粮食储备库_ZLH_32D_4_JN”切换到小区“SYSY_彩虹桥下西_ZLH_31F_4_JN”之后，由于SYSY_彩虹桥下西_ZLH_31F_4_JN小区距离远，属于越区覆盖，紧接着覆盖慢慢变差，直到脱网之后又开始重新注册IMS域，最终软件在17:37:44.745记被叫一次掉话。

　　

　　【解决方案】

　　1、删除“SYSY_粮食储备库_ZLH_32D_4_JN”小区与“SYSY_彩虹桥下西_ZLH_31F_4_JN”小区邻区关系；

　　2、需调整彩虹桥下西4小区下倾角6°至8°，粮食储备库1小区方位角340°至°，解决此处弱覆盖及SINR质差问题。

　　【优化效果】

　　

　　Case3：网元断链导致SRVCC之后掉话

　　【问题现象】

　　测试车辆沿嘉园街由南向北行驶时，主占排水泵站2小区RSRP=-108.37dBm，SINR=5.10，由于附近信号较好站点“SYSY_滨江家园DE后中间_ZLH_F12_JNT”网元断链，导致不能正常切换到“SYSY_滨江家园DE后中间_ZLH_F121_JNT”小区，RSRP逐渐变差，达到B2门限触发SRVCC切换到2G，之后被叫在2G掉话。

　　【问题分析】

　　主叫在13:31:25.482发起Invite寻呼，在13:31:25.776收到Trying100。之后被叫正常响应主叫寻呼，主被叫SIP流程转发正常，在通话期间，当测试车辆沿嘉园街由南向北行驶时，主被叫主占排水泵站2小区RSRP=-108.37dBm，SINR=5.10，由于附近信号较好站点“SYSY_滨江家园DE后中间_ZLH_F12_JNT”网元断链，导致不能正常切换到“SYSY_滨江家园DE后中间_ZLH_F121_JNT”小区，RSRP逐渐变差，达到B2门限后主被叫触发SRVCC切换到2G，紧接着被叫在2G掉话。

　　主叫信令：

　　

　　被叫信令：

　　

　　【解决方案】

　　加快处理站点告警，解决此处路段弱覆盖情况，复测。

　　Case4：RRC重建立失败导致掉话

　　【问题现象】

　　测试车辆沿S207由北向南行驶时，占用BCBC_一职_ZLH_D12_3小区RRC Connection Reestablish Reject，后重选至越区覆盖小区BCBC_太平洋保险-林业局_ZLH_D11_1小区，无合理邻区切换，导致弱覆盖，后RRC重建失败。

　　【问题分析】

　　主叫占用BCBC_一职_ZLH_D12_3 RSRP=-101.63dBm，SINR=-8.9 dBm无线环境较差，上发A3测量报告中PCI=329的一中图书馆3小区RSPR=-91.93 dBm，但未切换至该小区，邻区漏配导致无法切换，致使RRC Connection Reestablish Reject，后重选到越区覆盖小区BCBC_太平洋保险-林业局_ZLH_D11_1扇区，由于该小区越区覆盖，无合理邻区切换，造成该路段弱覆盖。

　　

　　【解决方案】

　　1、BCBC_一职_ZLH_D12_3添加一中图书馆3小区邻区关系。

　　2、BCBC_太平洋保险-林业局_ZLH_D11_1小区下倾角下压3度。

　　3、排查BCBC_金辉律师事务所_ZLH_D12站点为何信号覆盖不到该区域。

　　2.核心网问题：

　　Case1：信令异常导致掉话

　　问题现象：

　　主叫正常寻呼被叫，主被叫呼通通话，期间网络异常释放主叫QCI1专载，之后主叫上发Bye请求，网络回复Bye 487请求终止，实际为一次掉话。

　　问题描述：

　　主叫在11:30:17.261上发Invite寻呼请求，在11:30:17.543收到网络下发的Trying100。被叫正常响应主叫此次寻呼，之后主被叫SIP流程转发正常，主被叫接通后，在主叫通话360ms时网络异常释放主叫QCI1专载，之后主叫上发Bye请求，网络下发Bye 487请求终止，导致一次掉话。

　　主叫信令：

　　

　　释放原因截图：

　　

　　解决方案：

　　需要核心网确认异常释放主叫QCI1专载原因。

　　Case2：信令丢失导致SRVCC失败掉话

　　问题现象：主叫正常寻呼被叫，呼通后主被叫正常通话，通话过程中被叫由于占用上的小区信号变差，达到SRVCC触发门限，网络给被叫下发SRVCC切换请求，之后核心网信令丢失，导致SRVCC切换失败产生掉话。

　　问题描述：主叫在09:03:56.253发Invite寻呼请求，在09:03:56.472收到网络下发的100Trying。被叫正常响应主叫寻呼，之后主被叫SIP信令流程转发正常，呼通后主被叫正常通话，被叫由于占用上的小区信号变差，达到eSRVCC触发门限，终端上报B2测量报告，分析可知2G小区为：xx公司D (BCCH=532,BSIC=65)，当前服务小区BCBC_xx公司_ZLH_311D_6 (38098,5)和该2G小区已配邻区关系，之后网络给被叫下发SRVCC切换请求、RR切换请求，正常情况下，紧接着网络会下发RR Physical Information，终端回复RR handover complete消息。但此时分析炎强信令可知，网络未响应切换请求，导致异常取消SRVCC切换产生掉话。

　　

　　炎强信令：

　　

　　

　　解决方案：需要核心网分析未响应RR切换请求消息原因。

　　正常SRVCC切换流程:

　　

　　

　　3.终端问题

　　Case1：终端异常发Bye消息导致掉话

　　问题描述：

　　主叫在16:55:10.698上发ACK，被叫在16:55:10.923收到网络转发的ACK，之后在16:55:30.148被叫上发Bye请求，此时通话只有19.225s，因通话不足180s，软件记被叫一次掉话。

　　

　　解决方案：

　　需要分析被叫ACK之后很快上发Bye消息原因，以及软件只统计被叫掉话、未统计主叫掉话原因。

　　Case2：

　　4.软件统计问题：

　　Case1：主叫收Bye OK与QCI1专载释放冲突，ATU平台误记主叫一次掉话

　　问题现象：

　　主叫正常寻呼被叫，通话3分钟后，主叫上发Bye请求，网络转发给被叫，被叫发Bye OK，网络未及时转发给主叫Bye OK，而是先进行QCI1专载释放，软件记主叫一次掉话，之后才转发Bye OK给主叫结束通话。

　　问题分析：

　　主叫在15:25:43.698发Invite寻呼请求，在15:25:43.886收到网络下发的100Trying。被叫正常响应主叫寻呼，之后主被叫SIP信令流程正常，主叫在15:25:49.387呼通被叫，主被叫开始正常通话，通话3分钟后，主叫上发Bye请求，网络转给被叫，被叫发Bye OK，此时网络未及时转给主叫，而是先进行QCI1专载释放，ATU平台误记一次掉话，之后转发Bye OK给主叫结束此次通话。

　　

　　

　　解决方案：

　　该问题为客户已知问题，待ATU完善并解决。

　　Case2：被叫收到ACK之后，软件异常统计被叫一次掉话

　　问题描述：

　　主叫在16:37:05.881发起Invite寻呼请求，在16:37:06.084收到网络下发的trying100。被叫在16:37:07.694响应MME寻呼，在16:37:07.956收到网络下发的Invite寻呼消息，之后主被叫SIP信令流程转发正常，被叫在16:37:09.242上发Ringing180消息，此时因为网络异常给主叫下发Update消息，未转发Ringing180消息，之后被叫上发200ok、ACK消息，网络转发给主叫，在被叫ACK之后210ms软件记为被叫一次掉话。

　　

　　解决方案：

　　待下次复测验证软件异常统计被叫掉话原因，是否是偶发问题。

　　5.其他问题：

　　Case1：未正常挂机开始再次寻呼导致掉话

　　未正常挂机：

　　问题描述：

　　主叫在16:33:34.497寻呼被叫，在16:33:34.666收到100trying。被叫在16:33:34.633响应MME寻呼，在16:33:35.587收到网络下发的Invite寻呼请求，之后主被叫SIP信令流程转发正常，主叫在16:33:38.369上发ACK确认消息，被叫在16:33:38.629收到网络转发的ACK消息，之后主被叫正常通话，在通话180s后，主叫未上发Bye请求，被叫也未上发Bye请求，被叫180s后，软件在16:36:04.837记为被叫一次掉话。

　　

　　解决方案：

　　需要分析主、被叫在通话180s后未正常上发Bye消息原因。

　　再次寻呼：

　　问题描述：

　　上次主被叫超时未正常结束挂机，此次，主叫在16:36:04.559发起寻呼，在16:36:04.638收到trying100。被叫在16:36:04.837响应主叫此次寻呼，同时刻上发trying100，被叫中间SIP信令缺失，在16:36:24.873直接给网络上发200ok，主叫在16:36:25.218收到网络转发的200 OK消息，同时主叫回ACK，网络转发给被叫，被叫在ACK之后9s多钟上发Bye消息，此时软件记被叫一次掉话。

　　

　　解决方案：

　　1、此次寻呼不正常，需要确认是否是受上次通话未正常挂机的影响导致一次掉话。

　　二、未接通问题点：

　　1.终端问题：

　　Case1：被叫异常发Invite486 Busy here消息导致

　　问题描述：

　　主叫在16:52:53.507发起invite呼叫请求，在16:52:53.716收到网络侧下发的100trying。被叫在16:52:54.362收到网络侧下发的Invite呼叫请求，在16:52:54.439时被叫上发183 Session消息，主叫在16:52:55.181时收到183 Seesion消息，之后主叫上发Prack、Update，网络侧转发给被叫，在16:52:55.723时被叫上发Ringing180消息，此时核心网给主叫下发Update消息，信令存在异常，直到16:52:56.987时网络才给主叫转发Ringing180消息，但被叫在16:52:55.795时异常上发Invite 486 Busy here消息，软件记被叫一次未接通，主叫因一直未收到被叫的响应消息，在16:53:19.391时上发Cancle，软件记为主叫一次未接通。

　　

　　解决方案：

　　需要终端厂家确认被叫在上发Ringing180消息后紧接着异常发invite 486消息原因。

　　Case2：TAU期间上发INVITE请求导致未接通

　　问题现象：

　　主叫在TAU期间上发Invite，随后网络下发RRC连接释放，导致呼叫失败。

　　问题描述：

　　主叫在17:16:08.971异常上发Invite寻呼请求，此时终端进行TAU请求还未完成，网络侧无法响应INVITE请求，继续响应TAU请求，随后网络下发RRC连接释放，完成TAU，导致此次寻呼失败。

　　主叫信令：

　　

　　解决方案：

　　需要联系手机设备厂家确认在TAU未完成期间上发Invite寻呼请求问题，待完善TAU更新和终端发Invite寻呼机制。

　　Case3：终端异常发Cancle消息导致未接通

　　【问题现象】

　　主被叫正常寻呼，无线环境良好，主叫在收到Ringing180后异常上发Cancle消息，导致主叫一次未接通。

　　【问题分析】

　　主叫在18:17:44.434上发Invite寻呼请求，在18:17:44.631收到100trying。被叫正常响应主叫寻呼，主被叫SIP流程转发正常，被叫在18:17:46.923上发Ringing180振铃消息，网络正常转发给主叫，紧接着主叫异常上发Cancle消息，网络下发487 Request Terminated，主叫上发ACK确认，ATU平台记主叫一次未接通。

　　

　　主叫Cancle消息信令：

　　

　　被叫收到的Cancle消息：

　　

　　【解决方案】

　　需要和终端厂家确认，主叫异常上发Cancle消息原因。

　　Case4：被叫终端异常上发Invite 603导致未接通

　　问题现象：

　　主叫正常寻呼被叫，在被叫上发Ringing180之后，正常情况下，被叫紧接着上发200OK，但此时被叫异常上发Invite 603 decline，网络确认，主叫在Ringing180之后异常收到网络转发的Update消息，27s之后主叫上发Cancle消息，导致一次未接通。

　　主叫信令：

　　

　　被叫信令：

　　

　　Invite603消息截图：

　　

　　解决方案：

　　需要确认被叫终端异常发Invite603消息原因。

　　2.核心网问题：

　　Case1：eNB切换与QCI1专载建立冲突导致未接通转CSFB问题

　　问题描述：在松原网格4测试中出现在呼叫建立过程中如果发生eNB切换会导致专用承载建立异常，最终引起VoLTE呼叫失败，终端进行CSFB起呼问题。如下图所示：

　　

　　问题分析：

　　主叫发起INVITE消息后，建立RRC连接、SRB1、SRB2、QCI=9的默认承载和QCI=5的IMS信令承载，如上图中1所示：

　　

　　

　　UE成功切换到目标小区后，收到MME下发的释放EPS承载上下文请求（Deactivate EPS bearer Context request），查看该条信令，MME要求释放的是QCI=1的专用承载。如下图：

　　

　　但从之前的信令可以看到UE并未建立起QCI=1的专用承载，稍后UE收到网络下发的INVITE 503（Service Unavailable）异常消息，VoLTE呼叫未接通，终端选择进行CSFB完成呼叫。

　　问题原因推断：

　　MME在源小区下发建立QCI1承载，此时UE正在进行X2切换，基站会回复MME创建承载拒绝，切换到目标小区后，核心网进行了QCI1承载删除，未在目标小区上重新建立QCI承载导致呼叫失败。核查规范“the MME shall reattempt the same NAS procedure either when the handover is complete”，MME处理机制需优化。

　　

　　Case2：信令异常导致未接通

　　问题现象：

　　主叫寻呼被叫，被叫上发Ringing180振铃消息，网络转发给主叫，主叫收到Ringing180，之后主被叫由于无线环境差达到B2门限，触发SRVCC到2G，2G信号良好，期间网络异常给被叫下发Disconnect，延时6s多后网络转发给主叫，导致未接通。

　　问题描述：

　　主叫在10:33:31.234上发Invite寻呼请求，在10:33:31.562收到100trying。之后被叫正常响应主叫寻呼，主被叫SIP流程转发正常，被叫振铃后，网络给主叫播放回铃音，之后主被叫SRVCC切到2G，期间2G信号良好，被叫在10:33:38.438上发Connect消息，主叫未响应，10s多后被叫在10:33:48.941异常收到网络下发的Disconnect消息，打开信令详情可知，原因为：Recovery on timer expiry计时器超时，最终主叫在10:33:54.521收到网络转发的Disconnect导致一次未接通。

　　主叫信令：

　　网络转发Disconnect消息给主叫：

　　

　　被叫信令：

　　被叫上发Connect消息：

　　

　　定时器超时后网络给被叫下发Disconnect消息：

　　

　　解决方案：

　　1、需要核心网分析在2G信号良好情况下未转发Connect消息给主叫原因。

　　2、分析触发SRVCC切换之前测量报告，可知有测量到信号较好小区但未配置邻区，建议添加“BCBC_西校宿舍室分-农科院_ZLW_E11_2”(38950,61)和“BCBC_省所_ZLH_D12”(37900,432)邻区关系。

　　效果验证：

　　添加完邻区对后待复测验证问题是否解决。

　　3.IMS注册问题：

　　Case1：ATU平台误统计401为注册失败问题

　　问题现象：

　　被叫从2G返回4G后，终端发起IMS注册，注册流程正常，因用户数据不在数据库中，网络正常下发401Unauthorized消息携带用户认证所需的令牌，但ATU平台误统计一次注册失败。

　　问题描述：

　　被叫17:48:52.150发起IMS注册，因用户数据不在数据库中，网络正常下发401Unauthorized消息携带用户认证所需的令牌，但ATU平台误统计一次注册失败。紧接着终端重新发起注册，网络下发Register OK注册成功消息。

　　

　　解决方案：

　　需要优化ATU平台统计401注册失败机制，待完善。

　　Case2：CSFB到2G后发起IMS注册网络未响应

　　问题现象：

　　被叫在寻呼过程中CSFB到2G，紧接着在2G发起IMS注册请求，网络未响应被叫注册，软件记被叫一次注册失败。

　　问题描述：

　　因被叫响应寻呼时延超时，之后CSFB到2G，紧接着在2G发起注册请求，网络未响应，软件记注册失败一次。

　　

　　解决方案：

　　需要确认终端在2G注册的原因及软件记为注册失败的机制。

　　效果验证：

　　待问题解决后复测验证。

　　三、呼叫建立时延问题：

　　Case1：被叫响应寻呼延时导致CSFB到2G时延增大

　　【问题现象】

　　主叫寻呼被叫，无线环境良好，在被叫响应MME寻呼后直接CSFB到2G响应主叫寻呼，导致主叫呼叫建立时延增大，软件统计为20.018s。

　　【问题分析】

　　主叫在15:26:27.109发起Invite呼叫请求，在15:26:27.306收到网络下发的trying100。超过13s后被叫在15:26:40.910响应MME寻呼上发Service request消息，被叫侧因超过13s还未收到网络转发的Invite呼叫请求，在15:26:42.727时被叫上发Extended service request回落到2G请求，网络响应被叫CSFB回落请求，之后被叫在15:26:46.532上发Alerting振铃消息，主叫在15:26:46.998收到网络转发的Ringing180振铃消息，此时软件统计呼叫建立时延为20.018s。

　　

　　【解决方案】

　　需要网络侧分析13s内未给被叫转发Invite消息原因，导致被叫CSFB回落到2G呼叫时延变大。

　　Case2：软件异常统计导致时延大

　　【问题现象】

　　主叫寻呼被叫，因被叫响应延时，主叫RRC Connection Release，RRC连接重建立后SIP流程信令正常，导致软件统计呼叫时延为19.335s。

　　【问题分析】

　　主叫在14:45:15.277发起Invite呼叫请求，在14:45:15.487收到网络下发的trying100。超过13s后被叫响应主叫此次寻呼上发Service request，之后未收到网络转发的Invite寻呼消息，直到14:45:31.154被叫上发CSFB回落请求回落到2G。主叫从收到trying100后等待13s超时未收到183 Session消息，网络在14:45:28.002下发RRC Connection Release消息，正常情况软件应统计为主叫一次未接通，此时主叫又建立起RRC连接，收183 Session、发PRACK、UPDATE消息，被叫在14:45:34.230上发Alerting振铃消息，网络给主叫转发Ringing180振铃消息，此时软件统计呼叫建立时延为19.335s。

　　

　　【解决方案】

　　需要和鼎力软件厂家沟通，确定软件异常统计时延原因。

　　Case3：彩铃问题导致时延大

　　【问题现象】

　　主被叫呼叫信令转发正常，无线环境良好，在被叫上发Ringing180消息后，主叫一直未收到核心网转发的Ringing180，而是收到核心网下发的3遍Update消息，此处信令转发存在异常，导致呼叫建立时延增大1.4s左右。这种情况网格普遍存在，需要核心网监控信令协助问题定位分析。

　　【问题分析】

　　主叫在11: 54: 06.943时上发invite呼叫请求，在11:54:07.228时收到100trying，之后主被叫信令转发正常，无线环境良好，主叫RSRP-87.31 SINR 14.40，被叫RSRP-78 SINR 14.70，被叫在11:54:10.206时上发Ringing180，此时主叫收到网络侧下发3遍update并响应，一直未收到核心网转发的Ringing180消息，此处核心网信令下发存在异常，导致呼叫建立时延增大1.4s左右。

　　

　　【解决方案】

　　需要核心网分析在被叫上发Ringing180后一直未转发给主叫Ringing180消息，而是下发3

　　遍Update消息。

　　【效果验证】

　　核心网问题已解决，未有彩铃问题出现。

　　Case4：核心网修改专用承载导致时延增大

　　分析松原VoLTE呼叫建立时延高问题时发现，每次VoLTE呼叫建立时主叫侧都出现核心网对QCI=1的专用承载进行修改导致时延较高的问题。如下图所示：

　　

　　1、主叫在11:50:31.671发送INVITE消息，消息携带内容如下：

　　

　　主叫支持的媒体类型为语音audio，支持的格式列表为104、102、105、100，会话所用的媒体（audio）带宽为49Kbit/s。

　　2、主叫在11:50:31:909激活专用承载，如下图所示：

　　

　　主叫激活的QCI=1的专用承载MaxBitRate_UL=52Kbit/s、MaxBitRate_DL=52Kbit/s、GuaranteedBitRate_UL=52Kbit/s、GuaranteedBitRate_DL=52Kbit/s。

　　3、被叫在11:50:34:015回复INVITE 183消息，如下图所示：

　　

　　被叫支持的媒体类型为语音audio，支持的格式列表为104、105，会话所用的媒体（audio）带宽为49Kbit/s。

　　4、被叫在11:50:34:065激活专用承载，如下图所示：

　　

　　被叫激活的QCI=1的专用承载MaxBitRate_UL=49Kbit/s、MaxBitRate_DL=49Kbit/s、GuaranteedBitRate_UL=49Kbit/s、GuaranteedBitRate_DL=49Kbit/s。

　　5、被叫在11:50:34.155完成QCI=1的专载建立后，主叫在11:50:34.397对已经建立起来的QCI=1的专载进行修改，如下图所示：

　　

　　主叫QCI=1的专载修改内容为：将MaxBitRate_UL=52Kbit/s、MaxBitRate_DL=52Kbit/s、GuaranteedBitRate_UL=52Kbit/s、GuaranteedBitRate_DL=52Kbit/s分别修改为MaxBitRate_UL=49Kbit/s、MaxBitRate_DL=49Kbit/s、GuaranteedBitRate_UL=49Kbit/s、GuaranteedBitRate_DL=49Kbit/s。

　　修改后主被叫QCI=1的专载内容一致：媒体带宽均为49Kbit/s。

　　6、主叫专载修改完成后在11:50:34:426收到被叫回复的INVITE 183。

　　需要核心网配合排查的问题如下：

　　1、主叫INVITE消息中携带的会话所用的媒体（audio）带宽为49Kbit/s，为什么主叫初始建立QCI=1的专载时核心网下发的带宽为52Kbit/s？

　　2、当被叫回复INVITE 183并建立起带宽为49Kbit/s的QCI=1的专载时，核心网对主叫的QCI=1的专载的带宽由52Kbit/s修改为49Kbit/s。核心网是否可以在主叫初始建立QCI=1的专载时就将带宽设定为49Kbit/s来避免后续的专载修改导致呼叫建立时延高的问题？

　　Case5：核心网异常下发invite503导致寻呼转CSFB时延增大

　　问题描述：主叫在16:02:11.340时发起寻呼请求，在16:02:11.638时建立QCI1专载，之后在16:02:11.708时收到网络下发的100trying。同时刻网络给主叫下发invite503Service Unavailable消息，主叫上发ACK确认，在16:02:11.748时网络下发释放QCI1专载信令，主叫在16:02:13.007上发CSFB回落请求，之后网络下发RRC Connection Release确认。被叫在16:02:18.315时响应MME呼叫，之后SIP信令正常，在16:02:20.012时上发Ringing180振铃消息。此时主叫已回落到2G呼叫，在16:02:20.781时收到网络转发的Alerting(振铃)消息，此时软件统计呼叫建立时长为9.409s。由于网络异常下发invite503消息，主叫CSFB导致呼叫时延大。

　　

　　解决方案：

　　需要核心网分析在主叫呼叫过程中下发Invite503消息原因。

　　Case6：弱覆盖导致主叫CSFB时延增大

　　问题描述：主叫在13:04:31.467发起寻呼请求，在13:04:41.014无线环境开始变差RSRP-110.93dBm SINR -4dB，此时占用小区SYSY_体育馆北_ZLH_F123_JN，主叫上发2次测量报告，其中有测量到最强小区“SYSY_规划展览馆_ZLH_F122_JBT”(PCI=166)，此处可能漏配最强小区，主叫在13:04:42.070时发生CSFB回落到2G呼叫，被叫在13:04:47.662发起Service Request请求，在13:04:48.479上发Ringing180振铃消息，主叫在13:04:49.550收到网络侧转发的ALERTING(振铃)，此时主叫寻呼完成，软件统计寻呼时长为18.105s。

　　主叫信令：

　　

　　被叫信令：

　　

　　解决方案：

　　添加“SYSY_体育馆北_ZLH_F123_JN”与“SYSY_规划展览馆_ZLH_F122_JBT” (PCI=166)邻区关系。

　　Case7：核心网信令丢失导致CSFB时延增大

　　问题描述：主叫在14:57:22.543上发invite呼叫请求，在14:57:33.971上发CSFB回落请求，之后网络响应主叫CSFB回落，释放RRC连接。被叫在14:57:44.328响应MME寻呼请求，在14:57:44.509收到网络转发的invite呼叫请求，之后被叫SIP流程正常，在14:57:45.107时上发Ringing180振铃消息，主叫在14:57:45.975收到网络下发的Alerting消息，此时软件统计呼叫时延为23.329s。

　　主叫信令：

　　

　　被叫信令：

　　

　　解决方案：

　　需要核心网排查未及时下发100trying消息给主叫原因。

　　四、MOS低问题点：

　　Case1：弱覆盖转SRVCC导致MOS打分低

　　【问题现象】

　　被叫占用越区覆盖小区滨江一号北3小区，切换至GSM网络后，MOS打分持续低于3。

　　【问题分析】

　　由于被叫占用越区覆盖的滨江一号北3小区，无合理邻区切换，RSRP持续降低，达到B2门限后切换至GSM网络，导致MOS值低。

　　

　　【解决方案】

　　下压滨江一号北3小区下倾角3度，调整后复测此路段。

　　Case2：CSFB到2G导致MOS打分低

　　【问题现象】

　　测试车辆沿滨江大道由西向东行驶，占用松原市广电局3小区，RSRP-70dB、SINR25dB，23:28:56发生CSFB，占用GSM网络后MOS打分较低，均在3以下。

　　【问题分析】

　　主叫23:28:39.656INVITE寻呼消息给被叫，但被叫一直未收到主叫INVITE消息，14秒后超时，被叫进行CSFB，导致占用GSM网络，MOS打分低。

　　主叫信令：

　　

　　被叫信令：

　　

　　【解决方案】

　　需核心网解决转发Invite消息超过13s延迟问题。

　　Case3：频繁切换导致MOS打分低

　　【问题现象】

　　测试车辆沿沿江西路由西向东行驶，占用开发区国土局3小区，RSRP-92dBm、SINR 3.5dB，07:38:02.045上发A3事件，切换至恒大御景3小区，07:38:02.884上发A3事件，切换至伟业铭城路口1小区，07:38:05.881上发A3事件，又切换至恒大御景2小区，在此时间段MOS打分较低。

　　【问题分析】

　　由于此路段频繁切换导致MOS打分较低，对应事件LTE handover request和LTE handover success。

　　

　　【解决方案】

　　恒大御景3与伟业铭城路口1小区个性偏置修改为-6。

　　Case4：模三干扰导致MOS打分低

　　【问题现象】

　　测试车辆沿中山大街由北向南行驶，占用文建胡同1小区，RSRP-86dBm、SINR 8.6dB，MOS打分在3以下。

　　【问题分析】

　　分析发现由于中山大街1小区PCI=60 RSRP在此路段较强，与文建胡同1 PCI=150模三干扰导致MOS打分较低。

　　

　　【解决方案】

　　中山大街1小区方位角较由30°调整到10°。

　　Case5：设备异常导致MOS打分低

　　【问题现象】

　　主叫在西郭尔罗斯大路持续MOS差现象，MOS=1.948-2.871之间波动，严重影响话音质量，影响用户体验。

　　【问题分析】

　　测试发现在该路段RSRP和SINR较好，RSRP-61.9dBm、SINR 22.4dB，无频繁切换现场，核查后台底噪无外部干扰，可能由于测试设备（UE终端和MOS盒）故障导致的MOS差。

　　

　　【解决方案】

　　对此路段进行复测，排除MOS盒或者终端异常原因。

　　Case6：重叠覆盖导致MOS打分低

　　【问题现象】

　　测试车辆在公园东路由西向东行驶，占用政务大厅3小区（PCI=307，RSRP=-92dbm，SINR=11db），MOS值较差。

　　

　　【问题分析】

　　图中问题路段RSRP较差，无主导小区通话质量受到影响导致MOS值低。

　　【解决方案】

　　调整政务大厅1小区的方位角至30度，政务大厅3小区的方位角至290度，解决问题路段弱覆盖问题，并且使问题路段主占政务大厅3小区，避免模三干扰，以此解决mos差问题。