VOLTE案例分析报告
volte测试问题分析报告
湘潭Volte测试问题分析报告V1.0目录1. 概述 (3)2. 道路测试拉网结果统计 (3)2.1未接通/掉话和CSFB问题事件点汇总 (3)3. 问题详细分析 (4)3.1. 接通问题分析 (4)3.1.1 主叫在通话时被异常释放，呼叫接续后被叫回复183请求被IMS直接立即拒绝 (4)3.1.2 被叫回复invite183请求被IMS直接立即拒绝 (7)3.1.3 被叫回复invite183请求被IMS直接立即拒绝 (9)3.1.4 被叫在通话建立时被去激活导致未接通和CSFB，需核心网排查去激活原因 (10)3.1.5 被叫在通话建立时被去激活导致未接通和CSFB，需核心网排查去激活原因 (12)3.1.6 主叫无线质量差导致未接通 (14)3.1.7 被叫无线质量差导致未接通（与主叫未接通相同位置） (14)3.1.8 被叫无线质量差导致未接通，并导致被叫CSFB (16)3.1.9 主叫弱覆盖/质量差导致未接通，并导致CSFB失败 (16)3.2. 掉话或掉线问题分析 (17)3.2.1 主叫发挂机指令被IMS拒绝，导致主叫掉话 (17)3.2.2 主叫质量差导致掉话 (17)3.2.3 主叫质量均差导致掉话 (18)3.2.4 主叫质量差导致掉话 (18)3.2.5 主叫质量差,导致掉话 (19)3.2.6 被叫相同地点因质量差导致掉话 (19)3.2.7 主叫质量差导致掉话 (20)3.2.8 被叫质量差导致掉话 (20)1.概述为了提升4G用户对4G网络的满意感知度，尤其是在4G网络成熟进行语音和视频业务，近期省公司在集团移动公司的安排策略下，在全省开启VolTE功能。
诺基亚区域省公司安排湘潭先行进行优化实施。
2.道路测试拉网结果统计湘潭于7月23日对市区进行了第3次VolTE拉网测试，统计结果如下：总体接通率97.54.%(未剔除IMS原因导致的未接通)，掉线率1.39%.地市网格测试时间试呼次数接通次数未接通次数掉话次数接通率掉话率被叫CSFB 次数未接通中主叫CSFB次数eSRVCC切换次数时延（s）丢包率湘潭2 个网格汇总20150723 366 357 9897.54% 2.19% 70 0 3．62 0.59% 事件汇总原因汇总原因出现次数备注未接通怀疑 IMS 原因被叫回复 invite183 时被IMS立即 Cancel 导致未接通3被叫上下行链路质量均较好，主叫信令正常，需核查网 Cancel被叫在通话建立过程中收到核心网去激活指令导致未接通2被叫上下行链路质量均较好，主叫信令正常，需核心网 IMS 查去激活原因无线质差原因主叫或被叫质量差导致未接通3弱覆盖/质量差，导致未接通1需查eSRVCC 邻区及切换门限掉话怀疑 IMS 原因主叫正常挂机被 IMS 拒绝导致掉话1无线质差原因主叫或被叫质量差导致掉话8备注：被叫CSFB的原因：主要是被叫Volte呼叫失败引起CSFB或被叫掉话后主动发起了CSFB业务。
全网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，超时了。
中国移动LTEVOLTE案例分析汇总
中国移动L T E V O L T E案例分析汇总Standardization of sany group #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#广东移动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，主叫收到网络侧转发的INVITE 580，会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND，使得QCI 1被释放，导致未接通。
【解决措施】需要核心网查看MME在什么情况下会下发E-RAB RELEASE COMMAND。
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评估测试典型案例分析【案例分类】VoLTE【案例摘要】结合VoLTE网络城区测试评估工作，对测试中的异常事件进行分析，总结VoLTE优化分析经验。
1、切换与承载建立流程冲突问题导致掉话问题描述：UE在行驶至此路段占用二中分校-432486_51小区在被叫上发sip183之后，在激活EPS承载之前，终端上报一条MR，满足A3，触发同频切换，在目标小区成功接入后很快发生掉话。
问题分析：起呼时MME进行激活EPS承载流程过程中，恰好发生切换时，由于EPS承载建立未完成，MME在切换准备阶段，对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载，导致VOLTE专载源小区完成的情况下，在目标小区下发的rrc ConnectionReconfiguration消息中的radioResourceConfig Dedicated中释放了DRB-Identity = 6，切换完成后呼叫中断。
结论建议：切换与EPS激活流程碰撞，为无线网与核心网配合问题。
在进行激活EPS专载过程中，发生切换时，均会造成上述问题，需要和核心网确认目前是否有解决方案。
2、弱覆盖导致掉话问题描述：终端RSRP持续低于-120dbm左右，SINR在-7左右,主被叫UE均发生切换失败，单通，最终掉话。
问题分析：主被叫问题一直为弱覆盖，终端RSRP持续低于-120dbm左右，SINR在-7左右，切换失败后的TAU无法成功建立RRC 连接，此时段RTP包不能正常发送，上下行丢包严重（丢包率60%以上），出现单通，10s后RTP Inactivity定时器超时，会话终端，产生掉话。
结论建议：附近已有建设任务站点，开通后可解决弱覆盖问题。
3、弱覆盖导致未接通问题描述：本通话过程中，主叫占用HF-市区-太阳湾9号楼-HFTA-430739-51无线环境良好（RSRP=-92,SINR=9）,被叫占用HF-市区-金色池塘-HFTA-905606-54无线环境较差（RSRP=-100,SINR=-7）,呼叫发起6s左右释放，造成未接通。
VOLTE接通率优化思路及案例
VOLTE接通率优化思路及案例随着移动通信技术的快速发展，人们对通话质量的要求也越来越高。
VOLTE（Voice over LTE）作为一种高质量的语音通信技术，具有更高的音质、更快的连接速度和更低的延迟，逐渐取代了传统的2G和3G语音通信方式。
然而，由于各种原因，VOLTE接通率可能会受到一些干扰，影响通话质量。
因此，提高VOLTE接通率成为了运营商和设备厂商共同面临的一个重要问题。
下面将介绍一些优化VOLTE接通率的思路和案例：1.信号覆盖优化：VOLTE需要在LTE网络下进行语音通信，因此优化LTE网络的覆盖范围和信号强度可以提高VOLTE接通率。
对于信号覆盖不好的区域，可以增设更多的LTE基站或放置室内LTE小站，以消除信号死角和盲区。
案例：城市的一些居民小区信号覆盖很差，导致VOLTE接通率低。
该地区的运营商决定在小区内增设室内LTE小站，通过强化信号覆盖，提高VOLTE接通率。
经过实施后，VOLTE接通率显著提高，用户体验得到了极大改善。
2. QoS优化：VOLTE语音通话对QoS（Quality of Service）要求较高，需要保证较低的延迟和较高的网络带宽。
因此，通过对网络中的资源进行调度和优化，可以提高VOLTE接通率。
例如，对于VOLTE通话流量进行优先级调度，确保其能够优先获得网络资源。
案例：国家的一个运营商发现，其LTE网络中VOLTE语音通话的延迟较高，导致VOLTE接通率较低。
通过对网络的QoS策略进行优化，提高了VOLTE语音通话的优先级，将相关资源分配给VOLTE通话，从而提高了接通率。
案例：运营商发现其IMS网络存在一些性能问题，导致VOLTE接通率较低。
运营商对IMS网络进行优化，增加了IMS服务器的数量，改进了通信协议，优化了网络参数等。
通过这些改进措施，VOLTE接通率得到了明显提高。
4.终端设备优化：VOLTE通话不仅依赖于网络的性能，还与终端设备的质量和性能密切相关。
5.VoLTE案例分析
注：该问题正在与终端厂家沟通中….
几类人工剔除异常介绍
平台规则问题：3分钟双bye收OK回复案例
现象：呼叫满3分钟后，终端上发SIP bye后3秒又上发sip bye消息，并收到OK回复。 规则：已有网络问题发现，存在双bye后掉话的情况，因此平台算法对全部双bye问题标记为掉话。 分析：虽然出现了双bye挂断，（1）满足呼叫规则3分钟挂断且收到OK回复，（2）期间RTP包交互正常 确认应为正常挂断，sip bye消息重发。
2. 被叫振铃不接听案例 现象：被叫update交互完成后，上发振铃，未上发 OK,主叫收到振铃，18秒后上发了cancel取消。 软件：惠杰朗CDS 分析：被叫上发振铃后，按照软件设置应在1秒后立 即接听，怀疑软件触发的接听AT指令未其作用。
注：平台对掉话判断规则，在出现sip invite OK后，监测后续 的sip bye消息，若出现sip bye且收到OK则判断为正常，若无 发生下1次起呼，则以下次起呼时间作为上次掉话的时间点。。
现象/原因分类 振铃不接听
呼叫过程中主叫再次起呼或被叫异常发起寻呼 终端主动挂机
LOG信令记录丢失 SIM卡故障
说明 被叫振铃但不接听 接通状态下起呼或寻呼 起呼或接通后的立即挂断 由于软件问题导致的LOG未记录 非人为因素导致的SIM卡松动
问题判定
问题子类判定
测试软件问题 测试设备问题
丢信令
如GSM下的信令丢失，TD、LTE信令不连续则需要仔细辨认，确 认非基站闪断造成
注：VOLTE未接通触发CSFB接通，仍然统计VOLTE未接通；特别说明由于是统计规则后续可能会按照集团要求变更。
HTC M8版本升级引入silent redial功能
Volte测试问题分析报告
娄底Volte测试问题分析报告V1.0湖南移动娄底分公司诺基亚项目组2015年9月25日目录目录21.概述 (3)2.道路测试拉网结果统计 (3)2.1未接通/掉话和CSFB问题事件点汇总............................................................................3.问题详细分析 (4)3.1掉话和未接通问题分析.......................................................................................3.1.1终端无法正常切换，切换到TDS网络上之后造成一次掉话。
(4)3.1.2 终端在GSM网络上进行寻呼，造成一次未接通，怀疑GSM网络无线质量也差。
（软件未统计为未接通）。
...........................................................................................3.2其他问题分析..............................................................................................3.2.1终端由GSM网络回落到LTE网络时，为注册成功，由于软件寻呼机制进行起呼，被迫CSFB进行接续。
..............................................................................................3.2.2娄底娄星月塘社区景观塔无线质差，无法正常切换，怀疑存在告警。
(6)3.2.3娄底娄星档案馆景观塔1小区与娄底娄星药监局3小区邻区漏配，导致一次RRC重建失败。
(6)3.2.4娄底娄星上尚城站点存在RP3告警，小区退服，导致一次RRC重建失败。
案例-VOLTE未接通分析案例
案例-VOLTE未接通分析案例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掉话研究和实践总结
经典案例-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承载。
VOLTE寻呼拥塞分析优化案例
VOLTE寻呼拥塞分析优化案例一、案例背景VOLTE（Voice over LTE）是指通过LTE网络进行语音通信的技术，它提供了高质量的语音通话和丰富的通话功能。
然而，在实际网络运营中，由于网络拥塞等原因，VOLTE寻呼过程中可能浮现延迟或者失败的情况，影响用户的通话体验。
因此，我们需要进行VOLTE寻呼拥塞分析优化，以提高寻呼成功率和通话质量。
二、问题分析1. 寻呼拥塞原因分析：我们需要对VOLTE寻呼拥塞问题进行深入分析，找出导致寻呼失败或者延迟的具体原因。
可能的原因包括网络拥塞、信号覆盖不足、信道干扰等。
2. 寻呼成功率分析：对于寻呼成功的情况，我们需要分析成功率，并根据不同地区、时间段等因素进行对照分析，找出成功率较低的地区或者时间段，并进一步分析原因。
3. 通话质量分析：除了寻呼成功率外，我们还需要分析VOLTE通话质量，包括音质、时延、丢包率等指标。
通过对通话质量的分析，我们可以找出影响通话质量的因素，并进行优化。
三、数据采集与分析1. 数据采集：我们需要采集VOLTE寻呼过程中的相关数据，包括寻呼请求次数、寻呼成功次数、寻呼失败次数、寻呼延迟时间、通话质量指标等。
这些数据可以通过网络监测设备、基站设备、用户设备等进行采集。
2. 数据分析：采集到的数据需要进行详细的分析，包括寻呼成功率的计算、寻呼延迟时间的统计、通话质量指标的计算等。
通过对数据的分析，我们可以找出问题所在，并制定相应的优化方案。
四、优化方案1. 网络优化：针对网络拥塞问题，我们可以通过增加基站、优化网络参数、调整信道分配等手段来提高网络容量和覆盖范围，从而减少寻呼拥塞情况的发生。
2. 信号优化：对于信号覆盖不足的问题，我们可以通过增加基站或者调整天线方向来改善信号覆盖情况，提高寻呼成功率。
3. 干扰处理：针对信道干扰问题，我们可以通过频谱分析、干扰源定位等手段来找出干扰源，并采取相应的干扰消除措施，提高寻呼成功率和通话质量。
全网VOLTE终呼未接通分析案例分析
全网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接通率错误优化分析案例
V O L T E接通率（500错误）优化分析案例一、问题现象某地市VOLTE接通率（信令）指标一直处于全省倒数，未达到99.5%考核值。
通过借助中兴信令平台分析发现，失败原因值主要为主要集中在500（占比39.11%）、504（占比34.47%）错误。
二、问题分析从失败反馈原因值500进行深入分析发现，500错误场景主要为VOLTE-CS 与VOLTE-固话。
而两者问题以后者为主，如下表。
故从VOLTE-固话入手分析，而且失败固话号码基本全部为移动铁通固话。
通过中兴信令平台信令来看，携带原因值解码为R eason:Q.850;cause=4;text=”Sendspecialinformationtone“,SIP;cause=500.根据此信息联系本地铁通关口局管理人员。
得知，目前IMS固定电话和VOLTE 用户拨打铁通固定电话由移动关口局完成话务转接，因前期固话业务在话务转接中，对主叫号码属性有要求，故移动关口局上，对IMS号码拨打铁通号码做有主叫号码属性变换：后在拨打测试中发现，当VOLTE用户拨打铁通固定号码时，因关口局对主叫号码进行变换为“用户号码”，此时，关口局会将主叫号码进行删除前四位的处理（关口局指定用户号码本质是删除前四位0915区号），此时主叫号码只剩下后7位，继续接续到铁通后，由于主叫号码改变，铁通关口局无法识别主叫号码，便会将此呼叫过程拒绝，在拒绝的返回原因中未指定具体原因值，此拒绝信令通过关口局透传至主叫侧，由于整个拒绝信令中都未指定拒绝原因值，VOLTE核心网变将此类失败统一归纳为：“失败值500：serverfault”。
发现此问题后，9月27日17点通过在关口局对指定主叫号码格式的参数进行修改，对主叫号码格式不再进行指定：再次进行业务测试，主叫号码位长正常，铁通关口局正常完成接续过程，VOLTE接通正常。
三、问题总结验证抽取9月27日前三天VOLTE接通失败数据与9月27日17点后数据进行对比，发现500错误中VOLTE-固话基本全部消失。
VoLTE外场测试分析案例
案例1：580 Precondition Failure导致的未接通。
【问题描述】在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。
【问题分析】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消息，随后呼叫中止，出现未接通事件。
5.VoLTE案例分析
测试软件问题：呼叫过程中主叫再次起呼与被叫振铃不接听
1. 呼叫过程中再次起呼案例
现象：上次呼叫满3分钟后，主叫终端未上发挂断， 间隔30秒后，主叫按照呼叫规则又上发了起呼。 软件：惠杰朗CDS 分析：满3分钟，终端不挂断；怀疑软件触发的挂断 AT指令未能正常发到主叫终端，导致30秒后主叫在 通话中再次起呼，被计为掉话。
注：确实发现了满3分钟挂断，但RTP包单通的情况，将认为网络问题不予剔除。
几类人工剔除异常介绍
统计规则问题：VOLTE起呼失败触发CSFB且未接通
现象：1次VOLTE呼叫后，发生sip 500错误，2秒触发CSFB再起呼，但该次CSFB起呼也未接通。 规则：集团统计认为，该现象实际是1次用户按键行为触发了2次信令起呼，对客户感知来讲是1次失败，而 非两次失败，当前认定前1次VOLTE失败计入未接通统计，而CSFB不计失败 分析：实际该次触发的CSFB确实未接通，但是遵循集团VOLTE统计规则，暂时不列入未接通统计。
几类人工剔除异常介绍
测试终端问题：主叫CSFB回落位置更新不起呼与丢信令
1. 主叫CSFB回落位置更新不起呼
2. 丢信令
现象：主叫CSFB上发ESR，触发盲重定向回落GSM 并进行了回落位置更新，位置更新请求不带起呼标识， 且位置更新后不做起呼 。 终端：HTC M8 分析：主叫CSFB起呼时，ESR消息实际已触发了终 端后续行为在回落GSM后必然进行CM起呼，在信令 侧首先看到CM起呼后，再做RR信道请求。
主叫CSFB呼叫回落后位置更新不带起呼标识
主叫侧发起ESR后回落位置更新均应带follow 端偶尔为0
on=1，但VOLTE终
SIM卡欠费或误开机
欠费导致的业务无法进行，或非测试区域的误开机
VOLTE案例分析
1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME 未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
常州案例：高校场景VoLTE优化经验总结
常州高校校园场景VoLTE优化报告目录一、场景概述 (3)二、场景评估 (3)2.1 容量评估 (3)2.2 容量评估 (4)2.3 容量评估 (4)三、高校场景特点及优化思路 (5)3.1高校场景特点 (5)3.2优化思路 (6)四、常见问题及优化方法详解 (6)4.1弱覆盖场景优化 (6)4.2移动场景优化 (11)4.3室内场景高负荷优化 (16)4.4干扰场景优化 (24)五、小结 (30)一、场景概述本次优化主要针对常工院本部进行选点，校内存在高干扰高话务基站(常工院本部LDF) ，话务突发性强，流变动大，场景极具代表性二、场景评估2.1 容量评估根据初步数据统计，常工院本部校内人数约为5000人，最大在线用户数总数为984，移动用户渗透率为70%，其中LTE用户为96.81%.具体如下：2.2 室外覆盖评估常工院本部涉及5个宏站站点共39个小区，9个室分站点共71个室分小区：根据测试指标统计，平均RSRP电平值-85.2dBm，RSRP>-101dBm and SINR>-3dB的比率占比90.23%，可以满足用户需求，现场测试轨迹及覆盖指标如下：2.3 室外干扰评估常工院本部场景楼层密集，个别区域无主覆盖，信号较杂乱导致SINR值较差；根据测试指标统计，平均SINR值为12.39dB，SINR值大于0的采样点占比93.94%，基本满足用户需求，现场测试轨迹及覆盖指标如下：重叠覆盖度：路测中主服务小区与最强邻区RSRP的差值小于6dB，同时最强邻区RSRP>=-105dB。
重叠覆盖度大于等于3比例定义为：重叠覆盖度为大于等于3的采样点/ 总采样点* 100%；三、高校场景特点及优化思路3.1高校场景特点经过分析，初步归纳出如下的场景特点：1）高校学生群体4G用户渗透率高，以及用户较高的业务使用。
高校话务量随时间变化较稳定，上课时段话务主要集中在教学楼，早中晚饭时间话务主要集中在学校食堂，晚间休息时段话务主要集中在学生宿舍。
案例---VoLTE优化经验汇报分析
熟悉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回落频点。
移动LTEVOLTE案例分析汇总
移动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案例分析报告
漏配邻区的各种情况邻区漏配导致主叫掉话（漏配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不存在邻区关系。
随后主叫发生掉话事件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
邻区漏配的案例邻区漏配导致主叫掉话（漏配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，由于漏配邻区，导致服务小区未切换到最优小区。
在18:09:28时分由于无线环境恶劣引起RRC重建失败，平台在18:09:40判断为掉话。
后台查询已配置**兴海四D-HLH-3与**妈湾五D-HLH-2的邻区关系，漏配第二载波的邻区关系。
【问题结论】邻区漏配导致主叫掉话【解决方案】添加**兴海四D-HLH-103与**妈湾五D-HLH-102双向邻区关系邻区漏配导致主叫掉话(漏配D2-D2，已添加D1-D1)【问题现象】主叫在2016-04-10 18:24:51于发生主叫掉话【问题分析】测试车辆在妈湾大道由北往南行驶过程中，主叫在18:24:50时分发生eSRVCC切换失败事件，主叫在18:24:48通话过程中主叫占用**妈湾五D-HLH-102（RSRP=-119dBm,SINR=）多次上报A3事件切往**妈湾三D-HLH-102，由于漏配邻区，导致服务小区未切换到最优小区。
在在18:24:51时分由于无线环境恶劣引起RRC重建失败导致掉话。
后台查询已配置**妈湾五D-HLH-2与**妈湾三D-HLH-2的邻区关系，漏配第二载波的邻区关系。
【问题结论】漏配邻区导致主叫掉话【解决方案】1.添加**妈湾五D-HLH-102与**妈湾三D-HLH-102 双向邻区关系2.修改**妈湾五D-HLH-102 的eSRVCC A2（-112dBm）切换门限，提高eSRVCC切换成功率邻区漏配导致主叫未接通(漏配D1-D1，新站无D2)测试日期：2016/04/11主叫号码：被叫号码：【问题现象】2016-04-11 17:02:44在，发生主叫未接通。
【问题分析】测试车辆在莲花路由西往东行驶过程中，主叫在17:03:14时分出现未接事件，主叫在17:02:36时分开始起呼,在测试过程中主叫占用**特发D-HLH-2（RSRP=-103dBm,SINR=-1dB）多次上报A3事件切往**香蜜壹号二D-HLH-2，由于漏配邻区，导致服务小区未切换到最优小区。
在18:09:28时分由于无线环境恶劣引起RRC重建失败，平台在18:09:40判断为掉话。
**香蜜壹号二D-HLH是新建的站点只有第一载波。
【问题结论】邻区漏配导致主叫未接通【优化建议】添加**特发D-HLH-2和**香蜜壹号二D-HLH-2双向邻区关系邻区漏配导致主叫掉话（漏配F-F）测试时间：2016-04-14主叫号码：被叫号码：【数据来源】**_3_移动_VOLTE主叫_网格【问题现象】主叫17:15:02在，处发生掉话【问题分析】测试车辆在宝安大道由北向南行驶，主叫17:14:17占用**宝安北环F-HLH-2小区（RSRP=-103dBm，SINR=）多次发送A3测量报告，目标小区**村前街道二F-HLH-1。
经后台核查，**宝安北环F-HLH-2与**村前街道二F-HLH-1不存在邻区关系。
由于无线环境恶劣引起RRC重建失败。
主叫发生掉话。
【问题结论】邻区漏配导致主叫掉话【优化建议】添加**宝安北环F-HLH-2与**村前街道二F-HLH-1的邻区关系。
邻区漏配导致主叫掉话(漏配D2-D2、D1-D1)测试时间：2016-04-14主叫号码：被叫号码：【数据来源】**__移动_VOLTE主叫_网格13_CDS和【问题现象】主叫在13:45:32于，发生掉话【问题分析】在13:45:31通话过程中主叫占用**前进路D-HLH-23（RSRP=-122dBm,SINR=）多次上报A3事件切往**新乐社区D-HLH-101，由于漏配邻区，导致服务小区未切换到最优小区。
在13:45:32时分由于无线环境恶劣引起RRC重建失败，平台在13:45：32判断为掉话。
【问题结论】邻区漏配导致主叫掉话【优化建议】1、添加**前进路D-HLH-23与**新乐社区D-HLH-101的双向邻区关系2、添加**前进路D-HLH-3与**新乐社区D-HLH-1的双向邻区关系GSM信号拖死导致掉话(核查G网邻区及告警)主叫号码：被叫号码：【问题现象】时间2016-04-06 10:18:54经度: 纬度: 被叫在GSM侧掉话【问题分析】在**金域缇香一F-HLW附近路段，主叫在10:16:31开始起呼，在10:18:06时分通话过程中被叫占用**坪山好运D-HLH-103 (RSRP=-116dBm)启动eSRVCC切换到2G通话，在10:18:49时分被叫占用G网小区信号发生掉话。
GSM服务小区未切换到最优小区信号，导致G网信号拖死引起掉话。
附近400米范围有4G宏站覆盖，建议RF调整解决弱覆盖。
【问题结论】GSM拖死导致被叫掉话【解决方案】1.调整**大东城D-HLH-2、**坪山好运D-HLH-103天馈，加强该路段覆盖2.需核查华瀚科技M2与丹梓西二m2是否存在漏配邻区的现象及告警信息GSM信号拖死导致掉话(核查G网邻区及告警)【问题现象】时间2016-04-11 17:09:43经度: 纬度: 主叫在GSM侧掉话【问题分析】测试车辆东滨路拐海月路行驶过程中，主叫在17:09:08开始起呼，在17:09:19时分通话过程中被叫占用**东滨招月F-ZLH-2 (RSRP=-104dBm)启动eSRVCC正常切换到东滨招月m1通话，在17:09:43时分主叫占用G网小区信号发生掉话。
GSM服务小区未切换到最优小区信号，导致G网信号拖死引起掉话。
附近50米范围内有规划站【问题结论】GSM信号拖死导致主叫掉话【解决方案】1.加快**招商海月路（微小M）微站建设2.需核查东滨招月m1与蓝月湾畔l0是否存在漏配邻区的现象3. 需核查东滨招月m1与蓝月湾畔l0是否存在基站告警信息RF调整GSM信号拖死导致掉话（L网弱覆盖，RF调整）主叫号码：被叫号码：【问题现象】时间2016-04-06 10:18:54经度: 纬度: 被叫在GSM侧掉话【问题分析】在**金域缇香一F-HLW附近路段，主叫在10:16:31开始起呼，在10:18:06时分通话过程中被叫占用**坪山好运D-HLH-103 (RSRP=-116dBm)启动eSRVCC切换到2G通话，在10:18:49时分被叫占用G网小区信号发生掉话。
GSM服务小区未切换到最优小区信号，导致G网信号拖死引起掉话。
附近400米范围有4G宏站覆盖，建议RF调整解决弱覆盖。
【问题结论】GSM邻区漏导致被叫掉话【解决方案】1. 根据现场情况调整**大东城D-HLH-2、**坪山好运D-HLH-3、**坪山三D-HLH-1天馈，加强道路覆盖IMS注册失败(弱覆盖，RF调整)主叫号码：被叫号码：【问题现象】时间2016-04-06 10:19:09 被叫IMS注册失败【问题分析】测试车辆在丹梓西路由西往东行驶过程中，在10:18:06时分由于弱覆盖被叫启动eSRVCC切换到2G通话，被叫在10:19:02时分返回L网，此时占用**坪山好运D-HLH-103（RSRP=-116dBm,SINR=）于10:19:发起IMS注册，由于空口环境差导致主叫在IMS的注册信令流程尚未完成，软件在10:19:时分记为IMS注册失败。
附近400米范围有4G宏站覆盖，建议RF调整解决弱覆盖。
【问题结论】IMS注册失败【解决方案】根据现场情况调整**大东城D-HLH-2、**坪山好运D-HLH-3、**坪山三D-HLH-1天馈，加强道路覆盖弱覆盖导致被叫掉话（弱覆盖，RF调整）测试时间：2016-04-07主叫号码：被叫号码：【数据来源】**__移动_VOLTE主叫_网格7_CDS和【问题现象】被叫19:07:56在，处发生掉话【问题分析】主叫在19:04:53占用**十围F-HLH-3发起呼叫，RSRP=-102dBm，SINR=6dB。
6秒后通话建立。
当测试车辆19:07:19在机场路由东向西行驶过程中占用**民航酒店F-HLH-3，RSRP=-110dBm，SINR=。
无线环境恶劣，连续弱覆盖，造成被叫脱网，被叫重新附着。
被叫19:07:56发生掉话。