掉话处理案例总结完整版
经典案例-VoLTE掉话研究和实践总结
![经典案例-VoLTE掉话研究和实践总结](https://img.taocdn.com/s3/m/99ff24a4b7360b4c2e3f64c3.png)
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承载。
5G优化案例:nsa_volte掉话原因分析处理案例
![5G优化案例:nsa_volte掉话原因分析处理案例](https://img.taocdn.com/s3/m/348621a75fbfc77da269b1cc.png)
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,最终导致切换准备失败。
典型案例(掉话)
![典型案例(掉话)](https://img.taocdn.com/s3/m/6d567643336c1eb91a375d23.png)
问题点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掉话问题处理思路与优化方法](https://img.taocdn.com/s3/m/8ce83a3a02d276a201292e93.png)
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掉话处理
![精品案例_终端RTP语音包中断检测定时器超时引起VoLTE掉话处理](https://img.taocdn.com/s3/m/947f3aa04028915f804dc2ad.png)
终端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)处理案例
![DT测试掉话(Drop Call)处理案例](https://img.taocdn.com/s3/m/73a76dc9a1c7aa00b52acbdb.png)
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)无法切出导致弱信号连续质差掉话。
优化前信号图:优化建议:在该小区以东规划新站。
CDMA掉话案例分析
![CDMA掉话案例分析](https://img.taocdn.com/s3/m/a38b072a700abb68a882fb65.png)
(5)搜索窗太小导致的掉话
问题描述
如果搜索窗太小,会导致某些PN落到了搜索窗之外而不能进入成为 服务导频,反而该成为内部自干扰源,使该区域Ec/Io变差,导致 掉话
解决办法
调整相应搜索窗口
(5)搜索窗太小导致的掉话(续-1)
问题主要是隧道口的基站发射功率无法满足隧道内覆盖
(1)覆盖不足导致的掉话(续-2)
隧道内移动台接收功率图
隧道内接收电平较差
(1)覆盖不足导致的掉话(续-3)
问题的解决
初步解决方案
由于在隧道口有基站天线直接对着隧道内,考虑调整参数“pilotgain”, “TPTLTPO”的设置和天线方位角的方案
3. 邻区缺失
4. 邻区位序不合理 5. 搜索窗太小 6. 导频混淆 7. 同PN 8. 导频污染 9. 边界硬切换失败 10. 终端问题 11. 外部干扰 12. 其它
(3)邻区缺失导致的掉话
问题描述
如果移动台要求将不以导频加入激活集,但此导频如果不在 Neighbour List, 则会切换失败,
Mobile Station Acknowledgement Message (移动台->基站 反向业务信道)
……
Pilot Strength Measurement Message (移动台->基站 反向业务信道)
Handoff Direction Message (基站->移动台 前向业务信道)
完善邻小区关系解决掉话,复测该路段已无掉话
(3)邻区缺失导致的掉话(续-2)
狮子滩至云集掉话MOBILE LOG
移动台使用 PN429进行通 信,尽管信号
已经很差
掉话后,移动 台同步到 PN126
朝天门长江大桥掉话案例分析报告报告材料报告材料
![朝天门长江大桥掉话案例分析报告报告材料报告材料](https://img.taocdn.com/s3/m/0163ebc4a8956bec0875e324.png)
重庆朝天门长江大桥掉话案例分析报告一、概述在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掉话分析
![重点VOLTE掉话分析](https://img.taocdn.com/s3/m/a0a80e8d1b37f111f18583d049649b6648d709a9.png)
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测试常见掉话未接通案例
![案例-VoLTE测试常见掉话未接通案例](https://img.taocdn.com/s3/m/c011a005783e0912a2162a9c.png)
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切换失败掉话处理
![经典案例-VoLTE基于业务的切换与MLB参数互斥导致VoLTE切换失败掉话处理](https://img.taocdn.com/s3/m/54830f8da32d7375a517805b.png)
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掉话率定位分析及优化案例
![关于VOLTE掉话率定位分析及优化案例](https://img.taocdn.com/s3/m/8ef1cc60e45c3b3567ec8bcd.png)
关于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平台进行异常事件统计。
案例09-邻区漏配导致VOLTE掉话优化案例
![案例09-邻区漏配导致VOLTE掉话优化案例](https://img.taocdn.com/s3/m/4c36c6c576a20029bd642dcb.png)
案例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 上下文信息,容易发生。
无线通信掉话案例解决技巧
![无线通信掉话案例解决技巧](https://img.taocdn.com/s3/m/7d43ec126edb6f1aff001f74.png)
注:该项指标要求在无线侧统计,由BSC进行统计
1. 2.
爱立信交换机对掉话总次数(TFNDROP)的统计定义是: 当BSC 向MSC 发”CLEAR REQUEST”时,会使TFNDROP 加一. 或者是BSC 收到MSC 送来的不是因为“CALL CONTROL”或者是 “Handover successful”而产生的"CLEAR COMMAND”信息,也会使 TFNDROP 加一.但如果是由BSC 先发“CLEAR REQUEST“,MSC 再向 BSC 发“CLEAR COMMAND“的这种情况,则不会使TFNDROP 加一.
日讯科技
2006年
Page 5
Rising Technology
正常的通话释放流程
日讯科技
2006年
Page 6
Rising Technology
不正常的通话释放流程
日讯科技
2006年
Page 7
Rising Technology
流左 程侧 为 信 令 跟 踪 掉 话 的 A 接 口 的 信 令
日讯科技
2006年
Page 19
Rising Technology
无线掉话概述 测量报告丢失与掉话的关系 T200&N200概述 T200&N200在分配TCH阶段 T200&N200在通话过程中 T200&N200在信道释放过程中 测量报告丢失与T200 超时
过多测量报告丢失与T200 超时的
调整
日讯科技
2006年
Page 14
Rising Technology
BSC内部掉话流程
日讯科技
2006年
Page 15
Rising Technology
高负荷场景VoLTE语音掉话分析案例
![高负荷场景VoLTE语音掉话分析案例](https://img.taocdn.com/s3/m/c8879c962f60ddccdb38a089.png)
高负荷场景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设置。
TD-SCDMA掉话案例
![TD-SCDMA掉话案例](https://img.taocdn.com/s3/m/f65a5d1ec281e53a5802ff0a.png)
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口释放命令,释放原因为正常释放。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
掉话处理案例总结Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】路测掉话的原因分析及解决1. 关于掉话的描述在 GSM 系统中掉话从统计角度讲分为两大类:RF_LOSS 和 HO_LOSS 即射频掉话和切换掉话。
考虑到2层信令的接续等问题,我们把掉话作如下描述。
1) 射频掉话●下行原因:Radio_link_timeout 计数器减至 0●上行原因:BSS 在 link_fail 的设定时间内未能接收到 UL SACCH 消息,使link_fail 计数器减至 0。
BSS 下行功率停止发射●在 Layer 2 上: BSS/MS 每 T200 时间发送 N200+1 次 SABM/DISC 消息,但未从接收端收到回应2) 切换掉话●MS 未能成功切换至目标小区, 但未能回到源小区●MS 发送 HO FAILURE 和 UL-SABM 消息给源小区,但未得到回应2. 在路测时发现的掉话问题时,我们应从哪些方面进行考虑在路测中,如果我们发现了掉话,我们应该如何入手建议根据不同的现象作出一些初步的判断,可以尽量减少不必要的周折,提高工作效率。
归纳起来初步判断有以下几点:●带内、外干扰●无可切换的小区(拥塞、无邻区)●覆盖问题(overshooting/poor coverage)●有线口的信道释放●基站硬件故障(时钟、CTU 低功、信道盘的收发功率不平)●天线错误(下倾角、方位角等错误)●由于切换失败造成的掉话●参数设置不当●其它特殊原因(手机问题、交换机参数设置问题)3. 对掉话现象进行分析以及可能的原因在这一节中我们对每种造成掉话的可能原因进行具体的研究。
在每一种原因中,我们尽可能的举出实际例子来进行说明。
1) 频率干扰干扰会导致误码率升高,通信质量下降,是造成掉话的一个重要的原因。
干扰可以分为带内干扰和带外干扰,也可以叫做系统内部干扰和系统外部干扰。
带外干扰:随着科技的进步,空中的无线电波越来越多,有些系统如 TCS 系统与 GSM 系统工作在同一频段,如果频率设置不当,会造成严重的频率干扰。
在发射设备的非线性单元由于载波与通过天线进入的干扰信号产生互调干扰,会引起通话质量下降,产生掉话。
另外一种情况就是人为的加建 GSM 频段的直放站,对功率以及天线方向不进行控制,对系统会造成上下行的干扰。
一般有这种直放站时,基站会通过对话音信道空闲时的干扰电平测量值(IOI)上有所体现。
带内干扰:GSM 系统内部干扰主要由以下几个方面原因产生:●频率规划不合理,引起同频、邻频干扰;●基站或手机功率设置不合理,引起下、上行链路干扰;●频率复用不合理;●由于多径效应、建筑物反射等造成干扰;●码间干扰;●TA 与实际不符造成时隙干扰。
当 MS 在服务小区收到很强的同频或邻频干扰信号时,会引起误码率恶化,使手机无法准确解调邻近小区的 BSIC 或不能正确接收MS的测量报告,从而产生掉话。
下面两个例子分别从由于直放站造成的带外干扰、由于频率规划原因造成的带内干扰两个方面对干扰造成的掉话进行了说明。
实例 1:频率规划问题现象:从图 1 我们看到:从当前显示的信息看,3361 基站信号很强,但是质量很差,致使 RLT 超时掉话。
手机掉话后马上进行小区重选,基站为 914,但是 BCCH 与 3361 同频,同时我们发现掉话时 3361 的 TA 已经为 4,且覆盖方向也不应该是掉话地点。
分析:在我们日常测试中这种情况多是由于干扰或是硬件问题引起的。
通过OMC 我们未观察到该基站存在硬件问题,由此我们认为该基站存在干扰情况。
这样我们就初步判断除了掉话原因。
结合小区分布图来判断,我们认定这个掉话是由于同频干扰引起的。
图 1:掉话时刻情况又经过分析,发现之所以在该地区占用 3361,主要是由于 3363 基站无法切换到 914 基站。
3361 是 3363 的邻区但是 914 不是,由于 3361 于 914 同BCCH,手机切到了 3361 上。
再加上网络规划不好,这就造成了同频干扰,继而掉话。
图 2:事故原因:同频干扰造成掉话,通过对规划的调整和修改邻区参数,上述问题得到解决。
实例 2:直放站、阻断器造成的掉话随着用户的增多,很多宾馆酒店写字楼等建筑物内为了解决电梯、地下室等信号覆盖的盲区就会出现私建直放站,从而产生了强烈的上下行干扰,有时波及周围很多小区的性能,对网络指标的影响非常大。
频率阻断器是一种宽带的干扰器,其安装的目的就是要对移动通信系统产生强烈的干扰,以达到阻断器周围一定范围内手机无法接入系统服务的目的。
一般在路测时我们很难直接从下行的测量发现是否有上行干扰,可以结合统计是否有上行的 IOI 来分析。
如下图,占上问题小区后下行 Rx_Level,Rx_Quality 都很好,但是过了十几秒后系统停止发送 System Info5/5ter/6,进入了 IDLE 状态,没有 Disconnect 以及 Channel Release 等拆线消息。
通过分析发现虽然 Level 和 Quality 都很好,但是手机却在逐渐的提升功率,造成功控的原因就是上下行的 Level 和 Quality,因此可以因为问题出现在上行。
查找该小区的统计发现,整个小区的各个载频均有较严重的IOI 干扰电平,因此,可以认定当时基站是 Link_Fail 计时器超时自行拆线,而上行干扰是造成这次掉话的罪魁祸首。
图 3:下行电平和通话质量很好,但是手机却在提升功率虽然都是对网络产生了干扰,但是阻断器和直放站的影响有些不同,阻断器会带来话务量下降,并对周围基站的切换影响更大。
因此阻断器的干扰影响比直放站更加严重。
2) 缺少邻区 &目标小区话务信道拥塞严重其实缺少邻区的现象和目标小区 TCH 拥塞严重在 DT 测试中的现象是极为相似的。
下面仅以缺邻区为例进行分析。
实例:Cell56 缺 Cell3703 邻区最终导致掉话。
现象:Cell56(BCCH46) 缺 Cell3703 邻区(BCCH35),但有 Cell3266 邻区(BCCH34)。
但 3703 强度高 20dbm,但由于无 3703 邻区,只能切换至3266,造成干扰。
切换时如图 4 所示,当前服务小区为 CELL56(BSIC2-BCCH46),经过判断,向排在邻区第三位的 CELL3266(BSIC23-BCCH34)切换,如图所示,源小区 56 当前的下行电平为-76dbm,目标小区 3266 当前的下行电平为-65dbm。
图 4:系统消息 5 中没有 35 号频点切换后,发现服务小区电平依然很强但 Quality 突然变差,最后致使掉话。
如图5所示,我们看到有频点号为 34,35 的邻频存在,C/I = -21dbm。
从源小区 56 的 SYSTEM INFORMATION TYPE 5 中看到 Neighbor 的频点 list 中没有35 号频点,即说明 56 没有 3703 的邻区,因此在 56 为服务小区时,手机没有对 35 号频点进行扫描。
若对 35 号频点进行扫描,则会切至该小区,同时也避免了邻频的干扰。
加上邻区后,一切恢复正常。
图 5:切换后发现邻频干扰一般来说,如果缺少了邻区,将会发生拖带直至掉话的现象。
在整个拖带过程中,很有可能邻区列表中的场强远远大于服务小区电平值,同时其它频点的BSIC也已经解出,但就是没有下行的 Handover_Command 消息。
出现这种现象说明了以下两点:①手机所扫描的邻区频点必定是在当前服务小区下行所发的系统消息5/5ter(System Information 5/5ter)的 BA_LIST 中所包含的,即当前服务小区的邻区中有 BCCH 为该频点的邻区;②排在邻区列表前几位的频点与已解出的 BSIC 组合之后得出的小区必定不是当前服务小区的邻区。
在实际工作中,如果遇到上述情况,在分析出不是缺邻区的问题后,就应该检查是否目标小区 TCH 拥塞。
3) 覆盖问题(Poor level & Overshooting)a. 覆盖场强低(Poor Level)在测试中,我们在遇到覆盖场强很低的情况下,通常会导致 RxQuality 随着场强的下降而恶化,最终由于 Radio_link_timeout 或 Link_fail 超时导致掉话。
这种情况一般发生在郊区缺乏基站覆盖或山区信号阻挡较严重的地区,解决这种无信号覆盖的唯一办法就是加站或是直放站扩大覆盖。
图 6:很差的覆盖造成了掉话b. 过覆盖(Overshooting)还有一种覆盖问题就是邻区间交叠区过大,甚至出现了过覆盖(Overshooting)的现象。
比较典型的情况是:一个较高的基站 A 的天线没有作下倾角或只有很小的下倾角度,与它相邻的一个基站 B 的天线高度较低,覆盖范围很小,造成B的覆盖范围被 A 完全包含。
如图7所示。
所以在越过绿色的 B 小区主控覆盖范围后,手机还会“回切”至 A 小区,但是由于种种原因,A 小区并没有 C 小区的邻区。
因此,当测试人员继续行驶后,就会因无邻区可切而造成拖带掉话(例如在红色区域)。
解决的办法就是如图中所示,将小区 A 的覆盖范围控制好(小区 A’),就可以解决过覆盖造成掉话的问题。
图 7:Overshooting 现象同前边一节缺邻区掉话中所提到的类似,Overshooting 造成的掉话现象有两种:①在邻区列表中有很强的信号,同时 BSIC 早已解出,但根本没有下行的HO_Command 消息,这说明手机所扫描的邻区频点必定是在当前服务小区下行所发的系统消息 5/5ter(System Information 5/5ter)的 BA_LIST 中所包含的,即当前服务小区的邻区中有 BCCH 为该频点的邻区;②看不到有比当前服务小区信号更强的信号,说明小区 C 的频点不在 A 小区的 BA_LIST 中,手机没有对该频点进行扫描。
对于后一种情况,测试人员更不容易发现,因此需要测试人员在测试现场结合基站位置图对原因进行判断。
4) 有线口的信道释放造成的掉话●Abis掉话:这类掉话主要是传输质量引起的,如传输误码、滑码、帧丢失等。
●A接口掉话:A 接口掉话特别容易发生在 MSC 之间、BSC 之间等与 A 接口有关的切换过程中,MSC、BSC 之间的切换除了与无线网络有关外,还与网间信令配合、信号同步等因素有关,局间切换相对较复杂,也较容易引起掉话。
5) 硬件故障直接导致的掉话经验指出在现网中大多数掉话都是由于频率干扰和这样或那样的基站硬件问题所导致的。
在这一节中,我们就介绍以下所遇到过的硬件问题导致的掉话,一般来说,如果硬件有问题的话,从统计结果的掉话次数和掉话率上就能比较明显的发现异常。