中国移动LTEVOLTE案例分析汇总
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，属于端到端问题，需要集团规范协议流程。
中国移动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优化经验总结及案例
VoLTE优化经验总结及案例分享1优化经验总结1.1日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3.导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3QCI5PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
中国移动集团LTE案例资料
集团LTE案例库总结目录1.LTE下载速率低原因及相关案例 (4)1.1无线环境 (4)1.1.1案例1：系统外干扰（DCS1800）导致LTE宏站单小区下载速率低 (5)1.1.2案例2：服务小区与邻小区PCI存在mod3 干扰造成下载速率过低 (7)1.1.3案例3：由GPS失锁引起的F频段LTE基站上行干扰 (9)1.2 容量 (9)1.3无线参数配置 (10)1.3.1案例4：爱立信小区上下行时隙配比错误导致上行高BLER速率低 (10)1.3.2案例5：LTE的功率PA、PB参数设置不合理导致下载速率低的处理 (10)1.3.3案例6：爱立信LTE小区DLTARGETBLER参数配置有误导致下行速率低111.3.4案例7：华为eNodeB升级8.0版本默认开启MR功能后导致速率低 (12)1.3.5案例8：由于PDCCH信道误码率较高导致下载速率波动 (13)1.3.6案例9：TA同步功能未打开导致LTE下载速率抖降问题案例 (13)1.4传输问题 (14)1.4.1案例10：LTE 传输问题导致小区下载速率低 (14)1.5传输参数问题 (15)1.5.1案例11：PTNQOS参数限制导致LTE下载速度低案例 (15)1.5.2案例12：PTN侧MAC地址学习功能未配置导致LTE基站FTP下载速率低 (16)1.5.3案例13：由交换机端口配置不正确导致LTE TDD下载速率波动问题 (16)1.6核心网参数 (17)1.6.1案例14：QCI设置错误导致演示厅LTE下行速率低问题 (17)1.7基站存在故障或告警 (18)1.7.1案例15：室分场景多RRU合并后某一RRU驻波导致速率低 (18)1.8其它类别 (19)1.8.1案例16：LTE测试软件配置错误导致下载速率低 (19)1.8.2案例17：由于合路器接法不正确引起的下载速率低的问题 (20)1.8.3案例18：LTE室分双路不平衡导致下载速率低 (22)2.LTE基站小区无法建立或建立异常问题及案例 (23)2.1无线参数配置 (23)2.1.1案例1：GPS数据配置错误导致LTE TDD无法正常开通的案例 (23)2.1.2案例2：LTE宏站小区CRS端口配置错误导致小区无法建立 (24)2.1.3案例3：LTE小区与RRU关联错误导致覆盖接反 (25)2.1.4案例4：LTE基站eNodeB ID标识不唯一导致基站S1偶联链路频繁规律闪断 (26)2.1.5案例5：大唐和华为GTP-U检测功能参数协商不一致导致LTE站点业务频繁中断 (26)2.1.6案例6：由于TDS频点设置问题导致LTE基站无法开启的案例 (27)3.LTE切换问题及案例 (28)3.1覆盖 (28)3.1.1案例1：由于弱覆盖导致成都理工大学LTE小区1与音乐公园LTE小区2切换失败案例 (28)3.2无线参数配置 (29)3.2.1案例2：爱立信LTE小区DCI配置错误导致切换失败 (29)3.2.2案例3：开启防乒乓切换开关导致不切换 (29)3.2.3案例4：由切换门限设置错误导致某LTE站无法进行异频切换 (30)3.2.4案例5：TAU与X2切换冲突导致切换失败并掉线 (31)3.3核心网参数 (32)3.3.1案例6：LTE核心网鉴权关闭导致切换失败 (32)3.4传输参数 (32)3.4.1案例7：LTE基站S1口少配导致切换成功率低处理案例 (32)3.5异厂家参数配置 (33)3.5.1案例8：爱立信与中兴LTE邻小区RLC传输模式配置不一致导致切换失败 (33)3.5.2案例9：大唐与诺西Local Cell Resource ID配置不一致导致切换失败的案例 (34)3.5.3案例10：由于DRB-ID分配策略华为中兴LTE异厂家切换失败案例 (35)4.LTE终端接入问题 (35)4.1无线参数配置 (35)4.1.1案例1：TD-LTE帧同步参数配置错误导致上行干扰，造成终端有信号无法接入 (35)4.1.2案例2：TDL完整性保护算法设置错误导致部分终端无法上网 (36)4.1.3案例3：爱立信室分小区PrachConfigIndex配置错误导致接入性差 (37)4.2核心网配置 (38)4.2.1案例4：LTE的S1口IP配置错误导致终端无法正常接入 (38)4.2.2案例5：在MME中未绑定IMSI和HSS对应关系导致LTE新号段无法附着到网络 (39)4.3传输参数配置 (40)4.3.1案例6：未设置用户面路由导致LTE基站无业务速率 (40)5.2/3/4G互操作问题 (40)5.1.1案例1：由于3G/4G的PLMN不同且未配置EHPLMN导致TD-S重选TD-L失败 (40)5.1.2案例2：华为和中兴MME选路策略不同导致CSFB被叫接通率较低 (41)6.掉话问题 436.1.1案例1：TD-LTE SRS带宽重配置导致掉话率高案例 (43)1.LTE下载速率低原因及相关案例现阶段排查LTE下载速率低影响的主要因素包括：（1）无线环境（2）容量（3）无线参数配置（4）传输问题（5）传输相关参数配置（6）故障（7）传输相关参数配置1.1无线环境无线环境是影响下载速率低的一个重要原因。
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掉话研究和实践总结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案例分析
1 优化经验总结日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS 专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
VOLTE寻呼拥塞分析优化案例
VOLTE寻呼拥塞分析优化案例一、案例背景VOLTE（Voice over LTE）是指通过LTE网络进行语音通信的技术，它提供了高质量的语音通话和丰富的通话功能。
然而，在实际网络运营中，由于网络拥塞等原因，VOLTE寻呼过程中可能浮现延迟或者失败的情况，影响用户的通话体验。
因此，我们需要进行VOLTE寻呼拥塞分析优化，以提高寻呼成功率和通话质量。
二、问题分析1. 寻呼拥塞原因分析：我们需要对VOLTE寻呼拥塞问题进行深入分析，找出导致寻呼失败或者延迟的具体原因。
可能的原因包括网络拥塞、信号覆盖不足、信道干扰等。
2. 寻呼成功率分析：对于寻呼成功的情况，我们需要分析成功率，并根据不同地区、时间段等因素进行对照分析，找出成功率较低的地区或者时间段，并进一步分析原因。
3. 通话质量分析：除了寻呼成功率外，我们还需要分析VOLTE通话质量，包括音质、时延、丢包率等指标。
通过对通话质量的分析，我们可以找出影响通话质量的因素，并进行优化。
三、数据采集与分析1. 数据采集：我们需要采集VOLTE寻呼过程中的相关数据，包括寻呼请求次数、寻呼成功次数、寻呼失败次数、寻呼延迟时间、通话质量指标等。
这些数据可以通过网络监测设备、基站设备、用户设备等进行采集。
2. 数据分析：采集到的数据需要进行详细的分析，包括寻呼成功率的计算、寻呼延迟时间的统计、通话质量指标的计算等。
通过对数据的分析，我们可以找出问题所在，并制定相应的优化方案。
四、优化方案1. 网络优化：针对网络拥塞问题，我们可以通过增加基站、优化网络参数、调整信道分配等手段来提高网络容量和覆盖范围，从而减少寻呼拥塞情况的发生。
2. 信号优化：对于信号覆盖不足的问题，我们可以通过增加基站或者调整天线方向来改善信号覆盖情况，提高寻呼成功率。
3. 干扰处理：针对信道干扰问题，我们可以通过频谱分析、干扰源定位等手段来找出干扰源，并采取相应的干扰消除措施，提高寻呼成功率和通话质量。
VOLTE案例汇总
1：覆盖类问题1.1：地形环境导致弱覆盖【问题表象】路测表现为：主被叫手机当前小区和所有邻区RSRP均小于-110dbm，无主服务小区导致SINR<-3dbm,无线环境恶化，导致掉线、切换失败、接入失败等异常事件频发。
【问题分析方法】结合现场环境和基站拓扑图，对周边所有基站进行逐个勘察和验证覆盖，对于地形原因导致无法彻底解决的区段，提交后续工程建设方案。
【解决方案】：1：核查局方站点规划方案，如果有规划站点，提高建设开通优先级，如果无建设规划，提交建站方案；2：测试2G网络覆盖情况，对于2G覆盖良好情况下，开启SRVCC（基于IMS网络提供语音业务(SRVCC)SRVCC指的是单无线模式终端从TD-LTE网络切换到3GPP UTRAN/GERAN时话音呼叫的业务连续性）功能；同时确保2G侧FR功能开启，确保及时回落4G。
（IMS（IP Multimedia Subsystem）即IP多媒体子系统）3：对于有测试考核要求的情况下，采取规避路线，减少异常事件发生概率；1.2：邻区漏配导致弱覆盖【问题表象】DT测试中，此类问题主要表象为如下几种情况：频发A3事件而无法切换；（同频切换通过事件A3触发，且事件上报方式采用事件转周期的上报方式。
事件A3的触发，即邻区质量高于服务小区一定偏置值。
参照3GPP协议36.331规定事件A3的判决公式。
触发条件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off ）✧通常伴随主被叫占用小区不同，RSRP（Reference signal receive power 参考信号的强度）相差较大；✧切换链紊乱；✧容易引发掉线、重建立、切换失败等事件如下图：【问题分析方法】1：前台测试分析，核对A3事件上报小区信息是否包含在RRCConnectionReconfiguration(无线资源控制重建)。
如未包含，则确定为漏配邻区。
核对基站拓扑图，判断是否需要添加该邻区，排除过覆盖、针状覆盖小区（室分泄露小区、非道路覆盖小区等）尤其需要慎重添加，防止切换后无法及时切出问题发生。
VoLTE拉网案例分析集
VoLTE拉网测试案例摘要：4G承载语音技术（VoLTE技术）逐步成熟，初步具备试商用条件，在测试过程中发现问题，针对问题进行分析优化解决问题，提升网络质量。
本案例通过对亳州市区拉网过程中无线侧出现的问题进行优化分析，提升VoLTE体验。
关键字：VoLTE RRC重建拉网1、RRC重建导致VoLTE掉话【故障现象】：在拉网过程中，车辆从文帝街中段行驶至文帝街东头时，发生了一次RRC重建异常事件，进而导致掉话。
【原因分析】：查看异常事件前后无线环境、事件可以看到在异常事件发生前，UE持续上报MR测量报告，触发A3切换事件，但是UE始终占用消防队2.1G的3扇区信号。
初步分析是由于消防队2.1G的3扇区没有没有配置邻区或者漏配邻区导致无法完成切换事件。
查询U2000网管，分别查询小区同频、异频邻区配置关系均不存在邻区关系，查询其他小区均正常。
查看基站级ANR开关正常。
小区级算法开关为关闭.产生异常事件的原因就是由于小区级ANR开关关闭导致没有邻区信息，无法完成切换。
【问题处理】：修改消防队2.1G扇区3小区的小区级ANR开关为打开查询邻区，正常对问题路段进行复测，复测，无异常事件产生，切换事件正常。
无线环境改善明显。
针对全网进行核查，进入CME-配置报表管理，可以统计出全网小区级ANR开关状态，核查26个小区，ANR开关状态为关闭。
对此一一核实优化。
2、异频切换不及时导致信号差【故障现象】：在拉网过程中，车辆从希夷大道与菊花路交口由东向西行驶过程中，有一段路程信号很差。
【原因分析】：该区域距离周边基站较近，且为室外，无遮挡，只是这一小段信号差，其他路段正常。
查询网管，基站正常。
UE在该路段时主要占用2.1G信号，较差(-110dbm左右)，之后切换到1.8G扇区（信号-88dbm 左右）由于目前2.1G覆盖是热点覆盖，未能形成连片覆盖，导致有些区域2.1G信号覆盖较差，目前异频切换门限按照模板统一刷成A2事件触发门限-109dbm，导致该区域未能及时发起异频切换，始终占用2.1G信号，信号较差。
移动LTEVOLTE案例分析汇总
移动L T E V O L T E案例分析汇总Pleasure Group Office【T985AB-B866SYT-B182C-BS682T-STT18】广东移动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。
【测试验证】案例2：Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中，存在Server Internal Error 导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的Server Internal Error 500消息，随后呼叫中止，出现未接通事件。
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接通率优化思路及案例(个人资料)
VOLTE 接入问题优化思路及方案整理一、 VLOTE 主被叫接入流程主被叫接入流程指标定义：主叫呼叫成功次数/主叫发起呼叫总数*100% 事件定义：主叫上发 INVITE 后，收到网络下发200 OK二、 VOLTE 接入分析流程：影响业务告警过覆盖弱覆盖重叠覆盖干扰无线质差网络问题终端问题外部因素ATU 维护邻区漏配ATU 建、优、规VOLTE 未接通问题分析思路ATU 优化三、 VOLTE 接入处理流程：1. 影响业务告警：转维护处理2.无线质差：a)弱覆盖：转ATU建设、优化、规划流程处理b)过覆盖、重叠覆盖、干扰、邻区漏配：转ATU优化流程处理3.网络问题：转EPC\IMS排查处理4.终端问题：转软件、终端排查处理5.外部因素：人为误操作：转测试相关人员按规范正确操作、测试。
四、本轮VOLTE分析未接通分类：➢无线问题：1.弱覆盖、过覆盖、重叠覆盖、邻区缺失、模三干扰、外部干扰空口质差导致信令交互超时未接通。
案例：主叫发送UPDATE REQUEST后由于弱覆盖质差UPDATE REQUEST超时导致未接通。
➢网络问题：1.网络不回消息案例：主叫上发INVITE request 消息后网络侧未回100tring导致未接通。
2.流程冲突案例：主叫QCI1专载建立请求与切换请求流程冲突导致未接通。
3.网络主动释放案例：主叫在收到200 OK前网络侧下发rrcConnectionRelease导致未接通。
4.网络回错误码案例1：网络侧下发500 Server Internal Error消息导致主叫未接通。
案列2：网络下发invite service unavaible消息转CSFB导致主叫未接通。
➢软件&终端问题1.终端无响应案列：被叫上发INVITE- Ringing消息后终端10秒无响应，导致网络向主叫下发rrcConnectionRelease未接通。
2.终端响应延时案列：被叫UE发送INVITE- Ringing消息13秒后才上发INVITE 200 OK，导致网络向主叫下发rrcConnectionRelease未接通。
案例VoLTE优化经验汇报汇总
组团队
1.将基础参数核查纳入到日工作计划，按照省公司规范要求，明确不合规参数原因 并及时修改。 2.加强测试管理，建立测试日报。第1天开展的工作，第三天必须分析总结好，并
明要求
上传到专用FTP服务器。 3.测试开展前，需检查此次测试是否跟踪，保证异常事件分析时，各网元信令可用。 4. 中心负责人负责牵头进行端到端分析，打破中兴、华为两个厂家的壁垒。 对试商用和网格测试出现的问题点形成跟踪表，定期对问题点进行跟踪 5. 建立问题跟踪表，进行问题点的闭环管理。 解决进展。
系统内切换成 eSRVCC切换 功率 成功率
100.00% 100.00% 99.57% 100.00% 100.00% 99.75% 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
VoLTE的无线丢包率(%)
0.1126 0.1142 0.5289 0.0487 0.1681 0.5441
【专题研究】当信号强度突然恶化，同时满足重定向门限
和eSRVCC切换门限时，最终触发哪种事件？
选取没有LTE覆盖但有2G覆盖的场景进行测试，LTE信号突然由80dBm降低至-120dBm以下。同时满足eSRVCC和重定向门限，观 察终端和网络的表现。
【初步结论】：通过信令可以看出，在快衰同时满足重定向和
无线问题导致的掉话
移动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-4-VoLTE语音高质量优化案例(14个)
VoLTE语音质量优化案例1：VoLTE窄带与宽带语音质量对比【问题现象】在3GPP LTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE 12.2kbps）和VoLTE 高清语音（或VoLTE 23.85kbps）。
【问题分析】AMR-NB和AMR-WB这2种编码具有如下特点：●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；●每160ms生成一个SID语音静默包。
●帧长20ms；AMR-NB编码特点为：● 4.75kbps到12.2kbps共8个码率，分别为：4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；●采样率为8kHz。
AMR-WB编码特点为：● 6.6kbps到23.85kbps共8个码率，分别为：6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；●采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMR NB的语音带宽范围：300－3400Hz，8KHz采样。
AMR WB的语音带宽范围：50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMR WB与AMR NB不同之处在于AMR WB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz 进行编码。
用来降低复杂度，AMR WB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms 的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs 速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。
VOLTE案例分析报告
邻区漏配的案例漏配邻区的各种情况漏配F-D漏配F-F漏配D2-D2，已添加D1-D1漏配D1-D1，新站无D2漏配D2-D2和漏配D1-D1邻区漏配导致主叫掉话（漏配F-D）时间：2016-04-07主叫：被叫：【数据来源】**_20160406_移动_VOLTE主叫_网格1_鼎立ATU和HTCM8_03820【问题现象】主叫11:10:56在113.786591,22.718498处发生掉话【问题分析】测试车辆在松福大道由北向南行驶，主叫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主叫：被叫：【数据来源】**_20160409_移动_VOLTE主叫_网格43_CDS和HTCM8_01506ms1.lte【问题现象】主叫20:27:58在114.310455,22.6014899处发生掉话。
【问题分析】测试车辆在盐葵公路由东向西行驶，主叫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)。
中国移动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。
【测试验证】案例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，随后被叫发送Ringing180，主叫同时收到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：收到网络侧下发的BYERequest，软件统计为掉话。
查看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个TAC（9437、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消息。