掉话处理案例总结完整版

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承载。

5、若PCRF没有收到指示，则查看P-CSCF是否下发删除QCI1承载。

NSA VoLTE 掉话原因分析处理XX分公司目录1 概述 (3)1.1 版本信息 (3)1.2网络拓扑图 (3)2 NSA VoLTE 掉话问题 (3)2.1问题背景 (3)2.2问题分析 (4)2.3解决措施 (4)2.4.4现场验证 (5)3 整体测试验证情况 (6)3.14G数据业务验证 (6)3.1.1用户感知指标：（上行优良比）（≥5M bp s） (6)2.1.2用户感知指标：(下行优良比)（≥12M bp s） (6)3.1.3切换指标:切换成功率 (6)3.1.4切换失败原因分析 (7)3.2V oL T E验证 (7)3.2.1覆盖率 (7)3.2.2接通率 (8)3.2.3掉话率 (8)3.2.4M O S优良比（≥3.5比例） (8)3.2.5呼叫建立时延（秒） (8)3.2.6切换成功率，切换失败原因分析 (8)3.3关键KP I (8)3.3.1接通率 (8)3.3.2切换成功率 (9)3.3.3V o l t e接通率 (9)4 总结 (10)1概述1.1版本信息项目相关信息升级时间2019 年 4 月 15 日 0:00~4:00eNodeB BTS3900 V100R015C10SPC100测试工具(终端跟踪工具) 4G:鼎利5G:Mate 20 X1.2网络拓扑图2NSA VoLTE 掉话问题2.1 问题背景NSA 用户做 VoLTE，由 NSA 锚点站切换到 17B LTE only 存量站点失败。

测试手机在R15协议版本基站驻留（已添加N R），拨打V o LTE 电话，向R12.1协议版本基站移动，触发切换，切换后 VoLTE 会发生掉话。

2.2 问题分析NSA 终端在 NSA 区域下使用 NR PDCP，而17B 及之前的 LTE 版本不支持 R15 协议，无法识别N R P D C P,所以当17B基站接收到19B基站发出的切换准备消息时，因为协议不兼容，不能识别切换准备消息中的 NR P DCP，最终导致切换准备失败。

问题点1：润州区一泉村（边界同频干扰）测试时间：2009-9-2 09：52：51事件描述：用户投诉在润州区一泉村附近经常出现通话过程中掉话现象。

优化前信号图：（测试文件：0902-01.log）问题分析：在一泉村用户家附近测试时，MS占用Z135-鲇鱼套（BSIC=16，BCCH=115）出现连续7级质差最终导致掉话。

经查MCOM发现，Z135A -鲇鱼套（BSIC=16，BCCH=115）与Y3246B （BSIC=53，BCCH=115）同频对打，在该区域形成同频干扰致使MS占用Z135A -鲇鱼套（BSIC=16，BCCH=115）连续7级质差掉话。

优化建议：修改Z135A鲇鱼套BCCH=115->117。

修改后复测，在用户家中MS占用Z135A鲇鱼套BSIC=16 BCCH=117通话质量很好，无质差出现。

优化后效果图：（测试文件：0902-03.log）问题点2：丁卯桥路沃尔玛附近（邻区缺失）测试时间：2010-01-12 10：19：48事件描述：在丁卯桥路由东向西行驶，MS占用Z146A-丁卯大楼（BSIC=10 BCCH=117 TCH=97）在沃尔玛附近开始出现连续质差内切。

优化前信号图：（1208-03.log）问题分析：该段路应该由Z146C-丁卯大楼（BSIC=23 BCCH=109）和Z149B-丁卯村委（BSIC=16 BCCH=112）联合主覆盖，但由于MS偶然切换到Z146A-丁卯大楼（BSIC=10 BCCH=117 TCH=97），而Z146A和Z149B没有切换关系，导致MS长时间占用Z146A-丁卯大楼（BSIC=10 BCCH=117）越区而出现连续质差内切直至拖死。

优化建议：添加Z146A（丁卯大楼）和Z149B（丁卯村委）的双向邻区关系；修改Z146A（丁卯大楼）TCH=97->100。

调整后复测，MS在占用Z146A（丁卯大楼）信号时，经过几次间接切换顺利切换到Z149B（丁卯村委），且在该路段信号电平覆盖正常，通话质量良好，情况明显得到改善。

VoLTE掉话问题处理思路与优化方法VoLTE掉话问题处理思路与优化方法目录VoLTE掉话问题处理思路与优化方法 (1)1概述 (3)2VoLTE掉话率问题定界排查 (3)2.1VoLTE掉话问题定界思路 (4)2.2VoLTE掉线率TOPN小区定位排查思路 (5)3VoLTE掉线信令流程以及相关指标 (6)4VOLTE掉话无线问题优化方法 (7)4.1由于ENB的无线链路失败 (7)4.2由于ENB重建立失败 (9)4.3由于小区关断或复位 (11)4.4ENB由于S1链路故障发起释放 (11)4.5由于UE切换失败 (14)4.6由于UE不在线导致释放 (14)4.7由于ENB小区拥塞导致的释放 (14)4.8由于ENB过载控制导致的释放 (14)5VOLTE掉话处理案例 (15)5.1邻区漏配导致的掉话问题处理案例 (15)5.2弱覆盖导致的掉话问题处理案例 (18)5.3切换失败导致的掉话问题处理案例 (19)6总结 (20)1 概述目前萍乡电信VoLTE商用在即，VoLTE作为LTE网络实现语音通话的最终方案，用户对VoLTE高清语音的需求将越来越大，但目前由于电信Volte没有实现弱覆盖情况下的异系统切换，所以在弱覆盖区域存在较大的掉话风险。

伴随着网络规模的进一步扩大以及网络结构的日渐复杂，处理VoLTE的掉线问题即将成为日常网络维护中一项重要的工作。

本文通过研究VoLTE掉话问题定位及处理方法，主要从无线链路失败、切换失败、拥塞等方面展开分析，并总结VoLTE掉话问题处理优化经验。

2 VoLTE掉话率问题定界排查VoLTE掉话率指在移动通信的过程中，终端在VoLTE的通信意外中断的几率。

在信令监测平台上，VoLTE掉话指标取自于Rx接口和Mw接口，公式如下：VoLTE语音掉话率=VoLTE语音掉话次数/(（VoLTE语音始呼应答次数+VoLTE语音终呼应答次数）)VoLTE语音掉话次数指SBC（不区分主叫域和被叫域）收到PCRF发送媒体类型为语音的ASR（下图消息1）的次数，且ASR中Abort Cause为“PS to CS Handover”不含在内。

终端RTP语音包中断检测定时器超时引起VOLTE掉话处理目录一、问题描述 (3)二、分析过程 (4)2.1 设备及传输原因 (7)2.2 干扰及覆盖原因 (11)2.3 ENB重要VOLTE相关参数核查 (12)2.4 其他异常信令及事件核查 (13)三、解决措施 (18)四、经验总结 (19)终端RTP语音包中断检测定时器超时引起VOLTE掉话处理【摘要】为全力支持VOLTE商用，需要针对网络中出现的异常事件进行专项优化，一点一案进行分析。

目前现网中已利用RCU进行日常DT测试，力求利用常态化管理优化提升网络质量。

在宿州本地网近期日常测试LOG中，出现多次VOLTE掉话事件，经过工作人员细致分析后，发现这些异常掉话均呈现共性。

主要是由于主叫UE在业务态下异常DETTACH导致与被叫间失去信令交互，UE不活动定时器超时后，被叫及主叫依次判定掉话，掉话原因为RTP Inactivity。

通过后续对设备状态，参数设置等多方排查，最终定位RCU主叫端口模块故障引起此次异常掉话。

经过设备返厂维修后复测多日，VOLTE拨测正常，问题得到解决。

案例是从常态化测试优化过程中发现问题，并进行分析提炼，成功解决DT过程中Volte异常掉话问题，保障了日常DT测试完整性及指标严密性。

【关键字】VOLTE掉话、DETTACH、不活动定时器，【业务类别】VoLTE、一、问题描述为贯彻落实“VOLTE双提升”指导思想，保障VOLTE顺利商用，宿州电信公司全力承接省公司任务，积极部署RCU设备进行常态化DT测试。

2019年5月至6月，宿州网优人员发现在市区多处，发生多次VOLTE掉话，导致VOLTE 掉话率指标异常，如图一。

图一 2019年宿州VOLTE掉话DT统计可见，5月份VOLTE掉话率指标高达0.54%，不仅比3、4月份高出很多，更高于省公司定义的0.3%考核值。

选取5月20日至5月26日LOG，结合测试图层及掉话事件撒点，可以直观看到在短短一周的时间内，在市区范围内的多处地点，均出现了掉话，共计5次。

DT测试掉话(Drop Call)处理案例目录1D T测试掉话分类 (2)2D T测试各类掉话案例分析 ..................................................................................................... 错误！未定义书签。

2.1弱覆盖造成的掉话 (3)2.2干扰造成的掉话 (4)2.2.1同频干扰 (8)2.2.2邻频干扰 (9)2.2.3交调干扰 (10)2.3切换造成的掉话 (10)2.3.1切换频繁 (10)2.3.2话务分担切换 (11)2.3.3孤岛效应 (11)2.4参数设置不合理造成的掉话 (12)2.4.1层间切换门限值LAYERTHR过大 (13)2.4.2漏定义切换关系 (14)2.4.3切换关系定义错误 (14)2.5硬件故障造成的掉话 (15)2.5.1TX,RX接错 (16)2.5.2载频故障 (19)2.5.1工参定义错误 (21)2.5.2馈线头松动造成驻波比高 (22)3D T测试掉话处理总结 (22)一、DT测试掉话分类：DT中一般遇到的掉话（Drop Call）主要有：弱覆盖掉话、干扰掉话、切换造成掉话、参数设置不合理造成掉话、硬件故障掉话等。

二、DT测试各类掉话案例分析：2、1弱覆盖造成掉话。

有些小区由于覆盖范围过大造成在小区覆盖的边缘地带信号不好，电平值很低，手机列表中测量的相邻小区的电平值又达不到接入的要求（如RXLEV ACCESS MIN ＝－95dBm）而引起掉话，在边远地区、网络覆盖不好的情况下经常会出现这种掉话。

问题描述:MS占用D1250A袁桥社区由西转南时由于受楼房阻挡信号突然变弱，电平在-90dBm以下，且该地区东面无主覆盖小区（东部最近小区D718C距离为1.6KM）无法切出导致弱信号连续质差掉话。

优化前信号图:优化建议:在该小区以东规划新站。

重庆朝天门长江大桥掉话案例分析报告一、概述在2010-9-10日至2010-10-15日的拉网测试中，朝天门大桥基本上有拉必掉，每次掉话情况不一，情况较复杂。

二、拉网掉话分析➢朝天门地理环境分析配合Gogle分析发现朝天门大桥所在地理环境可看出，朝天门大桥所处地势很低，海拔平均低于周围两岸地势80米左右，加上楼房高度估计超过去130米左右，这样的地形使朝天门大桥处于谷底位置，周围小区容易越区过来，信号很杂，导频污染在所难免。

➢掉话分析⏹越区问题引起掉话1）、20100926拉网朝天门大桥主叫掉话南岸区城区语音_201009261405.lg4分析掉话前后信令：掉话前PSMM:PN140 8(观音桥)江北上格林-0,掉话后同步：PN168 根据BASID计算，cell=904 南岸南山-0配合MAP分析发现南岸南山-0越区严重，天馈调整 ,(3+T9)->(6+T14)；南岸南山-0天馈调整优化方案实施后，多次拉网朝天门大桥不再出现因PN168信号干扰引起的掉话。

2）、20100921拉网朝天门大桥主叫掉话江北区城区语音1_201009211153.lg4分析掉话前后信令：掉话前PSMM:PN380 南岸盘龙花园-101_1608_10_283；掉话后SYNC同步：PN56 (观音桥)江北五里店电信大楼-0 1_54_0_283配合MAP分析发现，南岸盘龙花园-10越区，天馈调整（4+T11）->(6+T14) , 方位角240->250;邻区优化：中心：南岸盘龙花园-10 1_1608_10_283，20/60/80-》28/60/80邻区：1_72_1_283 ，双向加邻区，优先级13;1_54_0_283, 双向加邻区，优先级别14;1_66_0_283 , 双向加邻区，优先级15；参数优化：搜索窗优化 WinA/WinN/WinR 20/60/80->28/60/80导频功率：-37->-44;方案实施后，多次拉网不再出现因PN380南岸盘龙花园-10越区引起的掉话。

VoLTE经验总结1 广州VOLTE网络质量现状经过近三个月的优化工作,广州ATU网格内,掉话率逐步改善,从%四月下降至%七月；接通率从%提升至6月份的%,七月份下降至%;七月份测试期间核心网的IOT测试也在进行；较多invite 500、SIP unknown、MT CSFB 等异常问题导致的连续多次未接通;广东公司计划在本周对广州IMS进行华为IMS替换爱立信IMS的操作,故七月份测试遇到的异常IMS相关问题分析进度暂缓;2 广州VoLTE测试问题优化进展异频重定向掉话问题验证问题解决背景：中兴eNodeB在P01版本下,因邻区缺失导致异频重定向掉话,该问题需升级P02版本解决;网格44、45测试过程中未发生异频重定向掉话,信令上分析测试过程中出现过多次连续上报异频A3的测报,未切换也未发生重定向,P02版本禁止QCI 1 业务异频重定向功能生效;异系统重定向掉话问题验证问题解决背景：中兴eNodeB在P01版本下,VoLTE发生重定向掉话,该问题需升级P02版本解决; 网格44、45基础覆盖较差,以往拉网测试均会发生多次系统重定向掉话,7月24日,网格44、45完成P02版本升级,升级后重定向掉话问题解决,拉网测试掉话率改善明显;P02版本禁止QCI 1业务重定向功能打开,终端上报A2盲重定向门限或B2事件2G邻区信息错误等前期会导致重定向的情况下,网络均未下发重定向,VoLTE业务保持通话结束后自动挂机,未产生掉话事件TM3/8转换掉话问题验证问题解决背景：中兴eNodeB在P01版本下,VoLTE业务过程中发生TM3到TM8模式转换,因为基站提前转换导致终端掉话,该问题需升级P02版本解决;8月3日,网格45所有升级站点打开TM3/8自适应,验证VoLTE业务在TM3与TM8进行转换时是否掉话,测试结果如下：网格45遍历拉网测试中出现26次TM3向TM8的模式转换,转换正常未发生异常;X2开启告警验证问题解决背景：广州前期因中兴网管告警问题未打开X2接口,导致跨站重建立不可用,需升级P02版本对X2告警量进行抑制;8月5日,网格44、45所有升级站点打开X2接口功能,指定开启X2自配置站点213个,8月6日统计站点X2偶联条数共计4604条;告警问题：网格44、45开启X2后,8月6日网管出现60多条X2断链告警,告警主要原因：a、传输不通,部分微站无法与宏站正常建链；b、个别小区被蔽塞不能正常建链；升级后EMS网管上只出X2断链告警,并且所有基站仅出1条多条X2断链,无SCTP断链告警,网管上可明确区分X2与S1告警,告警量大幅下降;X2开启跨站重建立功能验证P02版本支持无邻区的跨站重建立,在X2链路建立后,对于无邻区跨站重建立带来一定的增益,提高跨站重建立的效率；X2开启,网格44统计VoLTE拉网发生重建立请求共14次,跨站重建成功6次；从性能指标统计来看,RRC重建成功率从50%左右提升至80%左右;原理：目标小区通过终端上报的PCI查找该站点保存的有X2关系的邻站所有小区信息,向所有相同PCI小区索取上下文;3 广州VOLTE优化经验日常优化工作日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化,功能优化四个方面着手,与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,被叫回复bye481\invite486\invite580,呼叫失败;优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次,最大重传隔间从十几分钟改为15s,此类问题已解决;系统间邻区优化广州LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划,同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据,将4G和2G拉网信号强度、经纬度、服务小区等信息导出;通过经纬将4G弱信号RSRP<-110dbm与2G 强信号RXLOV>-95dbm在50米范围内拟合,根据拟合度对2G邻区进行补漏工作5月份第一轮拟合数据,剔除现网已配置的邻区关系,补漏483对；6月份第二轮拟合数据,剔除现网已配置的邻区关系,补漏邻区关系487对;eSRVCC切换提升明显,且由于2G邻区不准确导致的异系统重定向大大减少;重定向掉话中兴区域掉话最严重属于重定向掉话,在中兴基站算法中,以下三种可能发生重定向,重定向释放RRC后,专载同时被拆除,VoLTE业务产生掉话;上行PUSCH功控参数优化背景：4月集团在中兴区域拉网测试发现上行PUSCH发射功率偏高,对现网参数检查发现,中兴区域上行期望功率值设置过高;优化措施：进行功控相关参数优化,现网配置：p0NominalPUSCH =-75 ；puschPCAdjType=0优化值：p0NominalPUSCH =-87 ；puschPCAdjType=2●同等路损情况下,参数修改后,ue发射功率大约下降2~3dB;●目前终端平均上行发射功率仍高于10db,仍需中兴完善现有功控方式;修改后,PUSCH TxPower10dbm以上占比由40%下降到30%左右;RTP丢包率优化背景：4月份测试中,中兴区域RTP丢包率偏高,个别网格甚至达到2%以上;原因分析：在无线质量较好的情况下基本无丢包；无线质量较差的情况下上行丢包现象较为严重,PDCP重传时间超时,数据包将被丢弃；外场测试表明QCI 1 PDCP Discardtimer 配置与RTP丢包率及Jitter有密切关系,QCI 1 PDCP Discardtimer 配置越大,RTP丢包率越低,但Jitter也随之变大;●MOS值与RTP丢包及Jitter关系都较大,目前广州正在601P02版本下进行100ms / 300ms / 500ms / 750ms / 1500ms / infinity完整的对比验证;●进一步联合中兴公司定位RTP丢包率偏高的问题,并推动产品功能算法改进;MME专载保存功能可选功能描述：在基站发起UE-lost原因值的上下文释放请求时,MME保持专载2s不释放,等待空口重建;验证情况：已在GZMME1602下成功验证了该功能;当时无线环境较差,UE发起RRC重建失败,通过MME专载QCI1保持功能使得在新发起的业务过程中,RRC重配中建立包括专载QCI1的3条DRB,不会发生掉话;本次测试中专载保持时长约功能总结：1当无线环境较差时,UE发生RRC重建,若RRC重建成功,将不会掉话;2MME侧也可以在RRC重建失败后,通过MME专载QCI1保持功能使得在新发起的业务过程中,专载QCI1继续保持,也可使得不掉话;3此功能为爱立信MME非必选功能,建议打开;但是该功能不在集采目录,暂时无法采购; 专载释放与切换冲突,通话结束未收到专载释放掉话问题描述：在拉网测试过程中,通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时发生切换,未收到EPS专载释放请求,1s后软件统计掉话;问题分析：经分析MME log,发现MME未收到PGW下发的delete bearer request消息;当X2切换触发SGW-initiated bearer modification procedure完整信令是CCR-CCA,如果此时SIP挂机触发PCRF也发RAR给PGW,由于Gx链路时延等原因,使得RAR先于CCA到达PGW,根据协议规定,PGW会继续SGW-initiated bearer modification procedure而reject RAR result code DIAMETER_OUT_OF_SPACE; 优化措施：当前解决办法：1缩短DRA时延配置;2修改SAPC到DRA链路为主-备模式,保证CCA和RAR走同一路径和到达PGW的先后顺序;优化结果：近期调整后的网格测试,暂时没有发现BYE200消息前后发生的切换没释放QCI 1专载的情况;通话结束MME收到del bearer req,专载释放与切换冲突,基站未下发NAS问题描述：通话挂机后,主叫上报BYE消息,IMS回BYE200消息前后,同时发生切换,EPS 专载没有释放,1s后软件统计掉话;问题分析：主叫挂机后,MME收到del bearer req,下发Deactivate EPS bearer context Request给源eNB携带NAS释放专载,但同时源eNB触发X2切换,向MME响应ERABrelease response X2-Handover-Triggered,NAS消息未下发到;根据协议中有描述当eNB在触发X2切换时,eNB将不传递NAS消息;优化措施：属测试软件统计问题,建议软件加以剔除该问题;4 存在问题和建议设备功能问题：●切换冲突问题：基站无法解码SIP消息,UE专载建立完成的NAS消息上报时间无法确认,基站侧难以彻底解决,需要核心网做相应的功能优化,●呼叫过程eSRVCC：IMS不支持呼叫过程中发生eSRVCC,在4g网络覆盖达到2g规模之前,该问题都不可避免存在;终端eSRVCC测量性能提升4G弱覆盖比例较高：广州网格范围内黑点路段603个,是VoLITE业务问题多发路段,大部分需要加站解决,专项整治计划进度和质量不在项目把控范围;而目前芯片在测量GSM 邻区的时延较长,存在LTE弱信号拖死掉话的较大概率;2 案例分析典型案例案例1：LTE弱覆盖,eSRVCC切换不及时掉话10:57:基站下发异频异系统测量报告,包含2G频点及B2门限LTE:-110,GERAN:-9510:57:,主叫达到B2门限10:57:,主叫RSRP已恶化至-117dBm,SINR至-3,但终端仍没有上报B2事件10:58:,RTP包不能正常收发,10s后RTP inactivity定时器触发,会话中断,出现掉话：解决建议：①规范LTE频点配置,清理多余异频频点,缩短终端测量周期；②终端芯片提高测量能力,尽快实现CDRX休眠期测量功能;案例2：VoLTE单通现象VoLTE单通现象分为两类：一是VoLTE打VoLTE单通,二是VoLTE拨打GSM单通;经分析,第一类主要是终端问题,第二类主要是网络问题;注：红圈为RTP包抓包位置案例3：eNodeB参数配置不合理,导致eSRVCC失败问题现象：终端发生eSRVCC时,在LTE向GSM切换过程中产生掉话;问题分析：终端可以正常收到测控消息,并上报测量报告,且掉话发生在向GSM切换过程中,是GSM或者和基站侧参数设置问题;问题解决：基站BsCAccess-ID项中的管理状态为Locked,设置有误;将该状态修改为Unlock 后,对该站点进行重启后发现eSRVCC功能正常;空口信令判断案例案例1：RRC重建失败,无线网问题现象：切换失败导致RRC释放,重建RRC未成功,重新进行RRC申请,QCI=1的承载未建立成功,导致掉话分析：呼叫重建失败后,新小区重新申请RRC,未能建立VOLTE专载,导致掉话;该流程均由ENODEB控制执行;而切换失败的原因往往是无线环境问题、参数配置不合理、邻区漏配、非竞争随机接入异常等,均为无线网问题;结论：切换失败与RRC重申请流程均与EUTRAN相关,因此认定为无线网问题; 案例2：基站异常导致双端无下行信令及RTP包断传,无线网问题现象：主被叫VOLTE接通后,在同一小区同时发生缺失下行信令20秒,此后数秒发生终端上发bye request挂断;分析：丢信令之前,主被叫双端处于同一小区,且RTP包双向传输正常;丢信令期间,终端测量信息完整,但在2秒后发生RTP包只有终端向网络单向传输,未再有任何网络下发的RTP包,高度怀疑基站临时故障导致;结论：软件显示丢信令,但通过进一步分析确认应为基站故障导致;无线网问题; 案例3：VOLTE接通下发生IMS注册掉话,IMS网络问题现象：VOLTE接通后,被叫发生IMS注册且成功,此时主叫收到网络下发的bye request内含注册超时字样分析：按照3GPP协议,终端应在3000秒上发注册,本次华为SBC于3600秒才收到注册请求,此时IMS认为注册超时,对主叫下发了sip bye消息释放了;但通过进一步确认,终端实际于600秒前已上发了注册消息UDP,但此时恰好在G网下,未收到回复：注：同样类型的掉话也有600秒前处于LTE网TCP,而未收到OK或未鉴权回复的情况结论：前10分钟的注册失败,导致了后续的IMS通话中释放,虽然终端前一次的失败处理机制可能存在问题,但仍然体现出IMS对通话中发生注册时直接释放会话的措施欠妥;网元流程判断案例案例1：被叫收到寻呼但未收到INVITE请求,核心网问题现象：主叫上发了invite,被叫收到了寻呼且建立RRC成功,此时应收到下行的invite,但始终未收到;分析：被叫响应寻呼并进行了RRC申请,表明MME已收到由SGW触发的数据业务请求,即sip invite消息应由IMS网元的SBC下发给了PGW、SGW;①Sip invite消息由IMS网元SBC下发到被叫核心网网元PGW②PGW转发给SGW,SGW通过S11触发MME进行寻呼被叫③被叫被寻呼到,并完成RRC连接与建立默认承载所需RAB,接收数据结论：收到寻呼消息表示sip invite数据包已经到达了LTE核心网,未能继续下发当前怀疑是sip数据在S/PGW异常丢失;案例2：重配置消息释放DRB承载,无线网与核心网配合问题现象：被叫上发sip183后,在激活EPS承载之前,终端上报了1条A3测报,激活EPS 后,发生切换重配置消息中释放了QCI=1的DRB;分析：起呼时MME进行激活EPS承载流程过程中,恰好发生S1切换时,由于EPS 承载建立未完成,MME在切换准备阶段,对下发到目标小区的切换准备的请求消息中不携带QCI=1的VOLTE专载,导致VOLTE专载源小区完成的情况下,在目标小区被释放,切换完成后呼叫中断①切换准备时,MME向目标小区发切换请求,RAB建立请求表只有2条,无QCI=1的专载②目标小区收到MME的切换请求后,回复的切换确认消息里仅有2条RAB建立③MME向源小区下发的切换命令消息中,只建立2条承载,导致ENODEB释放了QCI=1的VOLTE专载;结论：切换与EPS激活流程碰撞,无线网与核心网配合问题;在进行激活EPS专载过程中,发生切换时,均会造成上述问题,目前还无较好的解决办法;网络设备问题案例总结案例1：中兴ENODEB异频重定向掉话,无线网问题现象：主被叫VOLTE接通后,服务小区信号较差,但未配置异频邻区；通过重定向消息RRC connection release携带频点,由D频段重定向到F频段,但VOLTE呼叫不支持重定向方式的RTP包接续,导致掉话;设备：中兴ENODEB分析：中兴设备为了防止邻区漏配情况下,影响用户在LTE数据业务下的感知质量,默认具备异频重定向功能,但未曾考虑对VOLTE呼叫的接续保持;结论：完善邻区配置,在VOLTE呼叫区域考虑关闭中兴设备的异频重定向功能;案例2：华为基站到卡特切换导致的RTP包传输中断问题,无线网问题现象：主被叫接通状态下,在发生一次由华为设备到卡特设备的切换后,20秒后主被叫终端同时上发了bye request消息,网络侧回复bye487 Request Terminated,后网络去激活了EPS承载,掉话;设备：华为ENODEB与卡特ENODEB分析：PDCP SN SIZE长度有12bit和7bit,目前华为基站配置为12bit,贝尔配置为7bit,两个厂家配置数据不统一;华为enodeb设备具有自适应功能;①在华为小区起呼时,切换到卡特小区时,卡特无自适应功能,PDCP SN不一致导致组包混乱;②当在贝尔小区起呼时,切换到华为小区时,华为PDCP SN自适应为7bit,通话正常; 结论：临时解决方案：华为PDCP SN Size修改为7bit,进行拉网测试主叫呼叫56次,未出现终端主动上发bye的掉话;异常掉话及切换后单通问题基本解决案例3：爱立信IMS网元CS域呼叫处理能力不足问题,IMS网络问题现象：在做互通测试过程中,主叫VOLTE起呼后,被叫始终在TD下未收到寻呼消息,主叫收到网络侧下发trying后,立即收到网络下发的invtie 604Does Not Exist Anywhere,呼叫失败;设备：爱立信IMS分析：空口信令仅能确认,被叫端处于TD网,发INVITE到MGCF,MGCF回复604 Does Not Exist Anywhere;该问题为爱立信IMS网元MGCF默认配置仅能同时容纳32个CS域呼叫,导致互通测试过程中,由于容量不足,造成大量连续未接通;结论：爱立信IMS网元MGCF默认配置容量偏小,发生以上问题后,经过扩容已达可处理2、3G呼叫320个;案例4：华为EPC修改EPS与切换碰撞,拒绝承载修改;核心网问题现象：主叫VOLTE起呼后,收到网络回复trying,激活了EPS承载后,又进行了1次EPS承载的修改,此时主叫侧在发生了1次LTE的切换后,收到IMS网络下发的sip503消息,服务不可得;设备：华为EPC分析：某地在激活EPS完成后,仍需要进行2次EPS承载的修改,本次呼叫时第2次EPS的修改空口信令不可见恰好与切换同时发生,当IMS要求核心网PCRF需要对EPS承载进行修改时,由于切换具有更高的优先级,华为EPC拒绝了承载更新,而只执行切换,导致IMS下发sip 503消息中断呼叫该市合适的CQI=1的EPS承载建立需要3个步骤：①CQI=1的初始EPS承载建立,GBR=40kbps但TFT无IPV6地址②修改GBR49kbps支持高清语音并对TFT内的增加IPV6地址以及UDP端口进行修改③在现有TFT中再新建两个ptf;结论：冗余的EPS承载修改TFT,一方面导致了呼叫建立时延长；同时增加了与切换发生冲突的几率；华为EPC在切换与修改EPS承载冲突时,不具备同时处理或排队处理的能力,导致直接以“资源临时不可得”拒绝了承载更新;一方面建议降低EPS 承载修改次数,减少切换碰撞几率与时延；另一方面建议华为EPC进行升级;案例5：华为EPC、中兴IMS协议理解不一致;IMS网络问题升级SBC解决故归此类现象：VOLTE起呼后,EPS承载激活完成,有一定几率1秒后直接收到网络直接下发sip 500消息Server Internal Error,中断呼叫;设备：华为EPC、中兴IMS分析：EPC按照3GPP规范产生的计费标识中包含“0a”的内容,但在IMS网络中,按照SIP协议将“0a”解析成换行符,造成对计费标识的误读;导致中兴IMS网与华为EPC网元PCRF对RX接口中字符格式理解不一致；中兴不支持PCRF通过Rx接口返回的不可见字符,导致了IMS直接下发了内部服务器错误经过IMS内部信令跟踪：①中兴IMS网元SCSCF返回500错误,原因为收到SBC转发的invite request消息携带的PCV头部有问题,发现换行符0A,导致S-CSCF网元上解码认为头部结束,从而认为不合语法规范,获取ecid失败②华为EPC网元PCRF通过Rx接口返回接入网络计费标识Access-Network-Charging-Identifier-value,至中兴IMS SBC,而后中兴SBC通过ecid参数来HEXDIG编码上述计费标识信息协议：The Access-Network-Charging-Identifier-Value AVP AVP code 503 is of type OctetString, and contains a charging identifier结论：即3GPP该计费标识可以包含字符串形式,中兴按IMS SIP协议理解ecid只能是可见字符,对字符串形式不进行HEXDIG转换,导致了上述问题;临时解决方案,中兴SBC进行相应的版本或补丁解决,支持不可见字符;。

VoLTE测试常见掉话未接通案例1.背景VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。

首先，高清语音和视频编解码的引入显著提高了通信质量，其次，VoLTE的呼叫接续时长大幅缩短，但VoLTE测试过程中仍发现部分掉话、未接通的现象，严重影响用户的感知。

本文梳理了VoLTE测试过程中常见的掉话、未接通的处理案例，为日后VoLTE试商用后此类问题的处理打下坚实的基础。

2.VoLTE语音通话流程简要如下：1.主叫发起INVITE消息，触发RRC建立过程（假设为空闲态）；INVITE消息包括主被叫电话号码，主叫支持的媒体类型、编码；2.主叫建立SRB2承载、QCI=9的DRB、QCI=5的sip信令承载；3.核心网反馈INVITE 100，表面正在处理应答；4.主叫RRC重配置建立QCI=1的专用承载；并激活；5.主叫收到被叫INVITE 183消息；并反馈PRACK启动资源预留；6.被叫收到PRACK后，反馈PRACK 200，启动资源预留；7.主叫收到PRACK 200，发送UPDATE，表明资源预留成功；8.同样被叫收到UPDATE，反馈UPDATE 200，表明资源预留成功；9.被叫发送INVITE 180 RINGING，振铃；10.被叫反馈INVITE 200，表明摘机11.主叫收到INVITE 200后，反馈ACK给IMS服务器，应答初始INVITE请求；并有IMS发给被叫；12.通话中；13.被叫挂机，发送BYE；IMS转发给主叫；14.主叫挂机，反馈BYE 200，IMS转发给被叫，表明结束会话；15.RRC重配置去激活QCI=1专载；图1.1 释放专载图1.2 简化信令流程图3.DT测试中常见的掉话、未接通问题2.1.切换失败导致常见有较多MR上报但不切，可能邻区漏配，之后触发RRC Re-Establishment，重建立不成功时掉话。

VoLTE基于业务的切换与MLB参数互斥导致VoLTE切换失败掉话处理1.问题描述海盐区例行测试发现在海盐第二高级中学北面路段存在切换失败导致的掉话现象，影响拉网指标及用户感知体验，具体问题点如下：2.分析处理过程在分析问题点数据时，发现切换问题点测试终端占用LF_H_海盐巴黎都市_51（PCI:26,RSRP=-104.63）信号，邻区LF_H_海盐城东_51（PCI=188,RSRP=-95.81）,信号良好；发现UE频繁进行A3事件上报，但切换执行失败导致掉话。

可以从以下几方面进行核查定位、解决问题：A、告警排查；B、邻区核查；C、问题分析；D、参数核查；2.1告警排查查询LF_H_海盐城东与LF_H_海盐巴黎都市基站告警，无异常告警。

2.2邻区核查核查LF_H_海盐巴黎都市_51信号与LF_H_海盐城东_51邻区关系结果如下：2.3问题分析排除告警及邻区问题后，结合后台指标分析信令发现，切换失败时的切换请求原因值为handover-optimisation，准备失败原因为目标侧无可用资源；而且是同一用户多次发起切换请求。

根据该原因分析，初步判断切换失败应该是基于业务的切换导致，需对切换参数进行细致核查。

2.4参数核查根据信令原因分析，切换失败应该是基于业务的切换导致，核查LF_H_海盐城东与LF_H_海盐巴黎都市参数，开启基于业务的异频切换。

核查LF_H_海盐城东与LF_H_海盐巴黎都市参数，基于业务的异频切换开关也是打开。

LF_H_海盐城东与LF_H_海盐巴黎都市站点开启基于业务的异频切换，该切换为非必要切换，故信令上携带的原因为handover-optimisation，查看特性文档，基于业务的异频切换与MLB参数HoAdmitSwtich（切换准入开关）存在互斥关系。

LF_H_海盐城东与LF_H_海盐巴黎都市基站进行核查，小区开启了异频负载平衡开关。

同时切换准入开关也是打开的。

核查邻区开启MLB站点，关闭切换准入开关后，VoLTE切换成功恢复正常。

关于VOLTE掉话率定位分析及优化1.1.1.1.优化思路定界流程：1.1.1.2.定位及优化1.1.1.2.1.基于话统定位优化流程对小区的QCI1的ERAB异常释放原因进行统计分析。

➢对于传输层问题占比大，则需传输侧进行排查分析；➢切换流程失败原因则重点分析无线质量、邻区关系、参数配置；●排查源小区及目标小区覆盖、干扰等无线质量情况，避免切换时与目标小区同步失败。

●核查邻区关系及参数，并结合地理图层确保已完善周报邻区，保证邻区关系及参数合理性；●参数一致性：核查确保外部邻区基站标识、小区标识、频点、PCI与邻区小区实际参数一致性、避免测量上报错误小区导致切换失败。

●核查切换参数配置：现网同异频切换基本都是基于A3事件：Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off。

同频切换参数，主要核查优化同频切换参数组ID的同频切换幅度迟滞、同频切换偏置、同频切换时间迟滞：异频切换参数，主要核查优化异频A3偏置、基于A3的异频A1 RSRP触发门限、基于A3的异频A2 RSRP触发门限。

异系统的切换参数，主要合理设置 A2 测量门限，避免由于测量过晚导致终端来不及测量目标小区信号无法切换掉话；➢无线层问题原因则重点排查弱覆盖、过覆盖、PCI模3干扰、外部干扰、参数配置等；●借助MR数据等措施判断弱覆盖及优化；●核查小区干扰情况并进行处理优化；●通过CQI上报指标统计各调制方式占比，可反映下行信道质量情况，正常情况是64QAM远大于QPSK占比，反之则说明无线质量存在异常。

如下为正常小区下各调制方式占比情况：●通过性能平台TA数据统计评估是否存在过覆盖问题，当TA统计距离明显大于最小站间距，则该小区极可能存在过覆盖。

对于过覆盖问题需进行增大下倾角、降低功率、站点整改等。

➢无线网络拥塞原因。

对于无线网络拥塞原因导致语音掉话，则需对拥塞原因进行排查及扩容等优化处理。

1.1.1.2.2.基于路测定位优化流程➢基于测试数据在ATU平台进行异常事件统计。

案例1：案例主叫UE信令主叫UE占用大名城LF1，RSRP值-96dbm，MR上报的最优目标小区为长江一号LF3，由于该组邻区漏配，导致该路段存在弱覆盖，UE最终向长江一号LF1发起切换。

因目标小区RSRQ 值-25，无线环境差造成切换失败。

UE发起RRC重建立被拒。

最终被叫挂机后，主叫也未收到IMS_SIP_BYE->Request和后续的DEACTIVATE_EPS_BEARER_CONTEXT_REQUEST消息，承载未释放掉。

当 eNB 侧未成功下发 AM 信令，会进行 HARQ 及 RLC 的重传，在 SRB 达到最大重传次数后，如果是普通信令，则会继续等待 UE UU 口响应定时器超时后释放，若为 5 大特殊信令，则会在 SRB 达到 RLC 最大重传次数后直接启动延迟释放定时器，等待延迟释放定时器超时后掉话。

（延迟释放定时器配置：T310+T311+20s）主叫UE在15:41:25时呼叫已达到180s，因未收到BYE请求，在经过20s等待无响应后，被统计为掉话。

被叫UE 信令被叫UE 在RRC 重配置失败后，重新驻留到长江一号LF3小区，在15:41:25本次呼叫结束。

影响范围：VOLTE 通话接续本例中，通过信令分析，确定因缺少邻区导致无线环境差造成切换失败所致。

首先核查大名城LF1邻区配置，查询网管发现，该小区配置的邻区有长江一号LF1/LF2，无长江一号LF3的邻区关系。

表现在测试信令中是终端持续上报Measurement Report 但是无法成功切换。

添加大名城LF1和长江一号LF3双向邻区后，复测正常，未再发生掉话。

网管查询大名城LF1邻区结果LTE 掉话常见原因主要有以下几类：切换掉话：切换异常分为过早切换、过晚切换、乒乓切换。

由于引入了重建流程，发生过早切换能够重建回到原小区，故不会发生掉话；过晚切换容易发生目标小区没有UE 上下文信息，容易发生。

高负荷场景VoLTE语音掉话分析案例一、【问题描述】分析淮南市区网格RCU V oLTE测试数据，测试中出现掉话事件，掉话原因：“RRC重配消息中包含释放DRB承载信息或未重建起呼DRB”。

针对此现象，我们展开分析处理。

二、【问题分析与排查】2.1 UE log分析终端占用HN-市区-洞山局-NFTA-440705-50无线环境良好（RSRP=-80.62dBm，SINR=15.2dB），通话过程中，在19:21:03.574收到基站侧下发的携带释放QCI=1专载的重配置消息，之后终端上发BYE请求挂机，主叫掉话。

被叫在19:21:03.534同样收到携带释放QCI=1专载的重配置消息，被叫终端也上发BYE请求挂机，造成被叫掉话。

2.2 Emil Trace分析Emil 信令消息显示，在19:21:04基站侧下发重配置消息，消息中包含释放QCI=1专载的信息，如下图所示：在E-RAB Release Indication消息中显示，释放专载的原因值为：radio-resources-not-available，即无线资源不可用，如下图所示：2.3 原因排查2.3.1 设备告警&干扰排查经核查，问题区域附近站点无设备告警，无异常干扰现象。

2.3.2 参数核查① V oLTE相关参数（包含切换参数）核查；②QCI1 DRX ROHC核查；③Inactivity timer参数核查；④ iniMcsUl和iniPrbsUl参数核查；⑤CFI核查。

参数影响排查后：只有CFI、iniMcsUl 和iniPrbsUl这3个参数与网络物理资源相关。

2.4 指标统计分析HN-市区-洞山局-NFTA-440705-50小区V oLTE掉话问题点，对这些小区对应时间段的重要指标进行统计，对比测试异常时段与其他非测试同时段网管KPI 发现，测试时段该小区CCE_BLOCKING_RATE异常，指标如下：可以得出结论：本次异常掉话很可能与问题小区CCE_BLOCKING_RATE 指标相关联，而从参数核查情况来看，与PDCCH拥塞相关参数只有CFI设置。

1、东涧沟村委会T2掉话现象描述：主叫UE在王城大道上由南向北，在10:07:25时占用东建构村委会T1小区发起向白马集团T1的切换，随后掉话，此时PCCPCH RSCP=-111dbm，PCCPCH C/I=-11，DPCH_CI=-114dbm。

掉话原因分析：主叫UE在王城大道上由南向北行驶，10:05:18时占用T网东涧沟村委会T1发起1G测量报告，切换的目标小区是白马集团T1，此时的PCCPCH_RSCP=-92dbm，10:05:20时切换至白马集团T1成功，此时的PCCPCH_RSCP=-97dbm，10:05:21时脚本时间到，上报了Disconnect，10:05:22时释放完成，此时的PCCPCH_RSCP=-100dbm。

随后进入了空闲模式，后频繁重选，重选混乱。

在10:05:53时发起语音呼叫，此时占用渤海湾T1的PCCPCH_RSCP=-97dbm，10:06:16时切换至美城商务T1，在10:07:25时占用东建构村委会T1小区发起向白马集团T1的切换，随后掉话，此时PCCPCH RSCP=-111dbm，PCCPCH C/I=-11，DPCH_CI=-114dbm，无线环境差导致的掉话。

解决方案：优化此路段的异系统重选关系。

2、王庄小学T1掉话现象描述：主叫UE在洛宜公路上由西向东行驶，在09:38:56时占用RNC4的华达集团T3发起向RNC3王庄小学T1的跨RNC切换，在09:38:59时掉话。

掉话原因分析：主叫UE在洛宜公路上由西向东行驶，在09:38:56时占用RNC4的华达集团T3发起向RNC3王庄小学T1的跨RNC切换，从鼎力软件看09:38:56时UE上报1G测量报告，09:38:58时切换成功，后UE收到RNC下发的1G、2A、3A三条测量控制，09:38:59时收到释放命令；从RNC侧信令看，RNC上报给CN侧Relocation Complete，跨RNC切换完成，随后收到CN侧下发的IU口释放命令，释放原因为正常释放。