LTE切换失败问题分析报告案例
案例-切换问题优化
切换问题优化案例摘要:切换是LTE系统中一个重要事件,对于保持终端的移动性起到重要作用。
在数据网中,切换失败可能影响不是很大,但是在VoLTE网络中,切换失败就意味着可能掉话。
关键字:切换掉话【故障现象】:1、车辆在北一环与魏武大道交口附近路段行驶,UE连接BZ-市区-城北精神病医院-HFTA-439139-0,RSRP值基本在-100dBm以下,覆盖不好2、车辆在汤陵南路由西向东行驶,UE连接BZ-市区-金色国际城-HFTA-439133-3,RSRP 值基本在-100dBm以下,无法切换至距离较近的BZ-市区-汤陵公园-HFTA-439132-53、BZ-市区-汤陵公园-HFTA-439132-54、BZ-市区-汤陵公园-HFTA-439132-55,导致此路段覆盖不好3、车辆在交通路路由西向东行驶,UE连接BZ-市区-谯陵派出所-HFTA-439083-0,RSRP值基本在-100dBm左右,无法切换至距离较近的BZ-市区-老方圆-HFMA-439163-53、BZ-市区-木兰小区南-HFTA-439377-52,导致此路段覆盖不好4、车辆在汤王大道由南向北行驶,UE连接在TDD小区(频点:41140,PCI:39),RSRP值基本在-105dBm以下,SINR也较差,无法及时切换至距离较近的FDD小区,导致此路段覆盖不好【原因分析】:1、后台查询发现BZ-市区-城北精神病医院-HFTA-439139-0与周边L1800小区有邻区关系,但是由于是异频切换,触发机制采用A2+A4事件,未达到触发门限。
2、后台查询发现BZ-市区-金色国际城-HFTA-439133-3与BZ-市区-汤陵公园-HFTA-439132-53有邻区关系,但是由于是异频切换,触发机制采用A2+A4事件。
3、后台查询发现BZ-市区-谯陵派出所-HFTA-439083-0与周边L1800有邻区关系,但是由于是异频切换,触发机制采用A2+A4事件,未达到触发门限。
LTE切换为题处理案例及切换参数总结
LTE切换为题处理案例及切换参数总结切换问题处理及切换参数总结⽬录:简述:地铁部分FDD线路分布问题导致覆盖盲区场景下,FDD切TDD。
由FDD 站点覆盖快速衰落情景下,终端开启A2测量,信令窗⼝中频繁上报MR,⽆响应,切换失败导致重建。
经由本次问题处理,对切换参数进⾏总结。
⼀、案例分析:1.1.问题描述:由芍药居⾄太阳宫段,FDD切TDD终端占⽤1350(PCI=467) ENB=502165,地铁⾏驶过程中,信号快速衰落,终端开启A2测量,信令窗⼝频繁上报MR,⽆响应,切换失败导致RRC重建⾄1350(PCI=496)502163,经由此站切换⾄TDD38950(PCI=87)ENB=82354-42海淀⼗号线海淀黄庄站FDDNLS1.测试结果:1.2.优化:●参数查询:A1:-92,A2 :-100,A5 :-90,-95 CIO:0db TTT: 640ms●调整:由于FDD衰落迅速,⼏次测试均有-92左右迅速衰落⾄-120,导致重建,所以建议将A2门限提⾼,同时为满⾜快衰场景下能够顺利切换,将CIO调为10,使其提前切换,TTT切换切换时间由640ms改为160ms调整后参数:A1:-90,A2 :-92,A5 :-90,-95 CIO:10db TTT: 120ms●调整后测试⼆:切换参数总结:当UE处于连接状态,⽹络通过切换过程实现对UE的移动性管理。
切换过程包含移动性测量、控制⾯流程和⽤户⾯流程。
为了辅助⽹络作切换判决,原eNodeB为UE配置测量,使UE在切换之前上报服务⼩区和邻⼩区的信道质量,便于⽹络侧合理地判决切换。
测量配置基本信道参数表●eueMeasCellSMeasureRsrpSmeasure:服务⼩区RSRP门限启动测量的服务⼩区RSRP门限,取值(-141..-44),单位为dBm。
此参数仅对针对信道质量的测量配置有效,对于针对CGI上报的测量配置⽆效。
对于针对信道质量的测量配置,当⽹络侧没有配置此参数,或者配置了此参数,且服务⼩区RSRP低于此参数指⽰的门限值时,UE根据测量配置对邻⼩区进⾏测量和上报。
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功关键字:X2IPPATH 切换【现象描述】切换测试时,从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败,HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE,进入该消息中可以看到cause为transport-resource-unavailable,切换不成功,如下图所示。
【原因分析】对于切换流程失败而言,如果是切换准备阶段的失败,其原因通常为以下几种:(1)传输资源不够用;(2)没有配置IPPATH;(3)IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小,接入用户数少,通过X2口传输的数据不多,一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题,在处理过程中需要对X2口和IPPATH问题排查处理,一步步解决问题。
【处理过程】每次切换到目标小区完成后,UE会读取目标小区的系统消息(RRC_SIB_TYPE1),该消息中可以看到目标小区的CGI,通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令(RRC_CONN_RECFG)可以找到目标小区CELL2的PCI,在目标基站B2中用MML命令查询确实存在小区CELL2,所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置,如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下:LST SCTPLNK;检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE;检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No,查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId,查看X2口两端的IP配置是否正确。
通达国际LTE-2小区X2切换失败处理案例
名称:通达国际LTE-2小区X2切换失败处理案例
提交人:岳明提交日期:2017-6-19
软件版本:EMB5116_TD-L V6.00.10.50.35.12 硬件版本:EMB5116_TD-L V6.00.10.50.35.12
【问题描述】:在日常X2切换质差问题小区处理中,发现通达国际LTE-2小区连续几天指标较差,切换失败次数每天在8000次以上,如下所示:
其切换对如下:
【问题分析】:提取CDL统计失败原因主要为:切换出失败UE在源侧发起重建立和核心网原因导致切换出失败,如下图所示:
源小区向目标小区切换走高优先级的A4切换,A1/A2/A4等参数无异常。
一般切换重建立回源侧的原因主要有目标小区覆盖不好或目标小区电平陡降,核心网原因导致切换出失败的可能原因为PCI复用度过高。
从CDL切换统计中看出在切换前源小区和目标小区电平均良好,核查同频同PCI情况发现附近新开小区陇商国际3(室分)LTE-1小区和目标小区经五路纬三路十字LTE-5均为D频点PCI是388,如下图所示:
失败过程流程图如下:
故需修改经五路纬三路十字LTE-5小区的PCI 后观察。
【优化建议】:将目标小区经五路纬三路十字LTE-5的PCI 由388修改为268。
【优化效果】:修改PCI 后,通达国际LTE-2小区切换失败次数明显减少,指标如下:
【备注】:附件或日志:
时间 ENBID 小区名 eNB 间X2
切换成功
率 eNB 间X2切
换出请求次数(HO.AttOut
eNB 间X2切换出成功次数(HO.SuccOutI X2。
关于光衰导致LTE eNodeB内切换成功率低优化案例
光衰导致LTE eNodeB内切换成功率低优化案例一、现象描述:在处理KPI TOP小区时发现L800M新建站崔庄2小区切换成功率突然恶化,并导致全网切换成功率指标恶化严重,该小区切换成功率基本保持在98.9%左右,而在7月18日时指标突然恶化至81,0%左右,且切换失败次数在7月19日时达到切换失败6619次,e NodeB内切换成功率更是低至7%,急需分析排查造成异常的原因。
指标如下:指标趋势图如下:二、分析思路1、排查设备硬件故障、基站告警原因;2、核查切换参数配置是否正确;3、核查是否因PCI冲突或MOD3干扰引起;4、核查邻区配置是否有错;5、光路隐性故障;三、分析过程1、经后台查询,208204_16崔庄2小区无告警,设备工作状态正常,X2告警不影响,因冗余邻区导致,已删除,排除设备原因,如下:2、经后台查询切换参数配置,无明显异常,排除切换参数配置原因;3、经后台指标分析,改站点1、2小区eNodoB切换失败次数较多,怀疑为PCI冲突导致,结合MAPINFO,对此站点位置进行PCI核查,发现无PCI冲突,核查该站点邻区配置是否存在PCI冲突情况,经核查无相同PCI,排除PCI冲突原因,;4、对该站点BBU至RRU端光路进行收发光检测发现,该站点BBU发光正常,但2小区RRU收光较弱,怀疑为BBU端至BUU端光衰大,但未导致小区退服,通知代维对该站点BBU至RRU光路进行排查,代维现场进行收发光检测发现的确存在光衰大问题,督促代维对该站点光路进行排查故障后,该站点2小区切换成功率恢复到正常水平;最终定位为BBU至RRU光路隐性故障导致该小区切换成功率差;现场排查:经现场代维排查发现,该站点光纤安装摆放位置不合理,现场进行整改。
四、优化建议当后台KPI指标波动异常时,排除了基站告警问题、参数配置问题等原因,还需对基站隐性故障及光路隐性故障进行排查,除了排查告警、参数等问题还需对设备隐性故障进行排查,从而加快解决问题,恢复指标。
LTE-切换优化案例
TD-LTE切换问题优化案例1 基站不下发切换命令该问题的前提是UE上报了切换的MR,基站侧也收到了MR,但没有收到切换命令,可能的原因有邻区漏配或邻区配错、下发重配置没收到重配置完成和同频邻区中有PCI相等的邻区。
下面以案例形势一一展开。
1.1 邻区漏配&邻区配错1.1.1邻区漏配从基站跟踪看到基站收到了大量的MR,没有下发切换命令,导致掉话,如下图。
从probe上看信道质量不差没到解调门限以下,因为没有下发切换命令而掉话,可以查看是否为邻区漏配。
中兴通讯179向科技园四182发起切换,上报了切换的MR,基站侧也收到了MR,没有下发切换命令,之后读系统消息,发起重建,重新接入到MR中小区,即科技园四182,可以确认为邻区漏配。
Probe和基站侧log如下:图表1邻区漏配UE侧无线环境图表2邻区漏配UE侧LOG图表3邻区漏配基站侧log邻区漏配有2种情况:1、同频邻区和外部小区都没有配置;2、配置了外部邻区,但没配置同频邻区;建议:添加邻区注:也可通过对比SIB4中的邻区信息与MR中的邻区PCI发现是否为邻区漏配,如下图;图表4SIB4消息内容1.1.2邻区配错下面为外部小区和同频邻区均已配置,且同频邻区也配置正确,但外部小区的PCI添加有错,导致的掉话。
如下图,102(科技园三1小区)上报181(科技园四的1小区)的MR,但没下发切换命令,查询同频邻区已配置eNBID为28即科技园四的1小区为邻区,但1小区的PCI被配成了182,且配置了同站的两个PCI相等的外部邻区。
图表5邻区错配终端侧LOG图表6科技园三1小区的同频邻区图表7科技园三的外部邻区建议:修正外部小区的PCI,在添加邻区时务必保证外部小区的PCI及同频邻区的eNBID正确,减少优化工作量。
1.2 PCI相等导致不发切换命令现象:基站标识117,67(本地小区1)、68(本地小区0)为同站邻区,68往67切换正常,67往68切则切不过去,表现为上报了MR,不发切换命令,LOG如下:图表8PCI相等终端侧LOG图表9PCI相等基站侧LOG经查询67(本地小区标识为1)的外部邻区中有PCI为68和同站邻区的PCI相等,如下,在ANR关闭情况下,会不发切换命令;图表1067小区的外部邻区图表1167小区的同频邻区措施:首先核查是外部邻区中的PCI配置错误(即该站不存在,或基站存在但PCI配置有错);核查都无误时需要调整PCI;建议:1、调整完PCI后或新加站后用M2000上的PCI冲突核查工具进行核查邻区中是否存在PCI相等情况。
TD-LTE切换案例分析
并没有出现非资源准入失败(流程失败),所以排除切换惩罚的原
因。
经核心网确认并没有将服务小区和目的小区配臵进切换限制列表。
目标小区禁止切换开关在同频邻区关系中配臵和显示的,需要进行
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page30
而睡眠小区一般表现为eNodeB的L3收不到UE的RRC建立请求消息。也出 问题在图7红色标注部分 与此问题站点的现象非常一致。 没有告警,没有操作日志,DSP小区状态也正常,没有用户接入和流量,但 是有随机接入过程。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page12
【建议与总结】
切换的问题先从信令入手,再分析信令流程失败点所有可能 的原因,采用逐一排除、逐一确认的方法来找问题原因。
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page17
异频测量控制下发
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
Page18
UE上报异频测量结果:
Copyright © 2012 Huawei Technologies Co., Ltd. All rights reserved.
小区半径设置不合理导致切换失败案例
“细耕800M、多频协同、提升感知”专项-小区半径设置不合理导致切换失败案例1概述目前LTE网络正在大范围的开展和建设中,基站大部分集中在城区和人口密集的乡镇对于这些站覆盖和接入的距离都较近,对于北京现网已基本实现LTE网络深度覆盖。
但在路测过程中发现在一个区域内出现频发的切换失败,监控KPI指标切换成率也仅有95%左右。
对此我们对该问题点进一步分析。
2问题描述现网KPI指标分析发现,部分基站同频切换指标异常,具体如下表所示:基站名称小区名称本地小区标识eNodeB间同频切换出成功次数eNodeB间同频切换出尝试次数失败次数HHF_CP北新建材厂北新建材厂_2 2 7477 8943 1466HHF_CY柏瑞安科技大楼柏瑞安科技大楼_2 2 9324 10017 693 HHF_HD科实五金科实五金_3 3 5645 6239 594 HHF_CY柏瑞安科技大楼柏瑞安科技大楼_1 1 13279 13700 421 HHF_CP西三旗西三旗_3 3 6337 6592 255下图是切换区域示意图:上表中,存在切换失败异常的基站通过Mapinfo打点发现,该几个基站都在同一片区域,初步怀疑失败都由一个目标基站引起,具体如下:3问题分析3.1 两两小区切换问题分析。
通过两两小区切换分析发现,几个基站切换失败都由同一个小区东升锅炉厂搬迁1_4引起,具体如下表所示:3.2 NASTAR小区定位分析对小区切换失败的最多的基站进行NASTAR小区定位分析,通过分析发现:系统内同频切换出执行失败占比最高,如图所示(以北新建材厂_2小区定位分析为例):深入分析同频切换失败,如下图。
从小区间切换RSRP测量来看,切换时RSRP在-90dBm左右,上行切换时上报的TA为7,信号覆盖较好,从信令可以看出,源基站向目标基站通过X2发送HANOVER_REQ信令后,目标基站未响应,具体入下图所示:根据Nastar小区分析发现,引起切换失败的主要原因为目标小区未响应,初步怀疑是目标小区存在底噪、告警、邻区关系不合理、参数设置不合理等问题。
LTE邻区关系不合理导致切换失败
LTE邻区关系不合理导致切换失败一、现象描述基站分布及路测轨迹图如下:测试车辆在(网格14)绥德路由西向东行驶至万镇路附近,UE占用普职校-HLH第1小区进行下载业务,RSRP为-141dBm,SINR为-5,信号陡降发起切换,随后发起切换但是不成功,从而发起RRC连接重建立,也失败,最后掉线。
二、处理过程分析(1)UE占用普职校-HLH第1小区,RSRP为-141dBm,SINR为-5,下载速率降至580kbps,信号质量差从而发起切换,向eNodeB发送“测量报告”消息(A3事件),携带两个邻区的测量报告:第一个是普绥祁-HLH第3小区(PCI=127),第二个是普职校-HLH第3小区(PCI=23)。
其中,普绥祁-HLH第3小区的RSRP=-140dBm+70=-70dBm,普职校-HLH第3小区的RSRP=-140dBm+28=-112dBm。
(2)普职校-HLH第1小区给UE发送“RRC连接重配置”消息,携带切换命令(MobilityControlInfo标识切换命令),切换目标小区是PCI=23(普职校-HLH第3小区)。
从此前的测量报告看,普绥祁-HLH第3小区(PCI=127)的RSRP更好(-70dBm),但该小区却不是切换目标小区。
因此,怀疑普职校-HLH第1小区的邻区列表中没有添加普绥祁-HLH第3小区(PCI=127)为邻区,故选择向RSRP弱的普职校-HLH第3小区切换,但由于普职校-HLH第3小区RSRP太弱,无线环境差导致切换失败。
(3)UE切换失败后进行小区选择。
从SIB1消息可知,当前选择小区eNodeBID为01959A (16进制)=103834,本地小区号是0D(16进制)=13,对应的是普绥祁-HLH第3小区。
(4)UE完成小区选择后,向普绥祁-HLH第3小区发起RRC连接重建立。
但是,按照3GPP 协议36.331,只有具备UE上下文的prepared cell(prepared cell包括源小区和切换目标小区)才可能实现RRC连接重建立。
LTE切换问题分析
1相关Counter介绍1.1 切换相关KPI公式(L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧eNB间切换出成功率(L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut)*100% ✧同频切换出成功率(L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.IntraFreq.ExecSuccOut- L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut)*100% ✧异频切换出成功率(L.HHO.IntereNB.InterFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut- L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% ✧切换出成功率(L.HHO.IntereNB.IntraFreq.ExecSuccOut+L.HHO.IntereNB.InterFreq.ExecSuccOut+ L.HHO.IntraeNB.IntraFreq.ExecSuccOut+L.HHO.IntraeNB.InterFreq.ExecSuccOut-L.HHO.IntereNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntereNB.InterFreq.Succ.ReEst2Src-L.HHO.IntraeNB.IntraFreq.Succ.ReEst2Src-L.HHO.IntraeNB.InterFreq.Succ.ReEst2Src)/(L.HHO.IntereNB.IntraFreq.PrepAttOut+L.HHO.IntereNB.InterFreq.PrepAttOut+L.HHO.IntraeNB.IntraFreq.PrepAttOut+L.HHO.IntraeNB.InterFreq.PrepAttOut)*100% 1.2 Counter解释Counter解释:✧切换成功率Counter✧切换失败counter原因:1.3 Counter计数位置及说明1.3.1站内切换图(2)1.3.2 X2切换图(3)2.3.3 S1切换图(4)注明:尝试切换Counter都计数在A点位置,准备切换Counter都计数在B点位置,切换成功Counter都计数在C点位置1.3.4 切换失败Counter说明图(5)a). 在S1接口切换及X2接口切换过程中的切换准备阶段,源小区收到来自MME的UE CONTEXT RELEASE COMMAND消息时,如果切换过程中源小区和目标小区为同频或异频,指标L.HHO.Prep.FailOut.MME加1。
LTE切换问题定位指导二(切换问题分析)
LTE切换问题定位指导一(切换问题分析)目录1站内切换,随机接入失败导致切换失败 (1)2站内切换,切换完成丢失导致切换失败 (4)3X2切换,源侧等待上下文释放命令超时 (6)4 X2切换,S1PathSwitch失败导致切换失败 (8)5切换随机接入失败触发重建,重建重配失败而掉话 (11)6eNB未响应UE切换测量报告,信道质量恶化而掉话 (12)7切换命令丢失导致切换失败 (14)8X2切换,Preamble丢失导致切换失败 (16)9X2切换,目标侧等待S1PathSwitchAck超时导致切换失败 (18)10X2切换,随机接入失败触发重建,重建完成丢而掉话 (21)11站内切换,随机接入失败触发重建,重建失败而掉话 (22)12站内切换,切换完成丢失触发重建,重建失败而掉话 (25)可以通过CHR分析切换问题,以下举例给出CHR分析切换问题的方法。
1站内切换,随机接入失败导致切换失败CHR中记录的释放原因值为usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT,如下图。
Step1:“掉话前最后10条信令”分析备注:目前Insightsharp不支持解析“掉话前最后10条信令”,需要用内部工具UMAT 解析。
首先在CHR中找到本次掉话的CallID,再在UMAT中过滤出该CallID的相关记录。
从CHR 记录的掉话前最后10条信令可以看到,eNB等待切换完成5s定时器超时后向核心网发起释放请求。
Step2: 分析L2_SRB_LOG,判断UE是否收到切换命令切换命令HARQ反馈为ACK,说明UE收到了切换命令,如下图:Step3:查找L2_L1_DEDI_PREAMBLE ,分析切换随机接入过程是否成功专用Preamble 收到了10条(Preamble 最大重传次数配置为10次),说明UE 没有收到RAR 而进行了Preamble 重传,并且达到最大重传次数10。
LTE切换失败问题分析案例
X2IPPATH配置问题导致切换不成功关键字:X2IPPATH 切换【现象描述】切换测试时,从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败,HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE,进入该消息中可以看到cause为transport-resource-unavailable,切换不成功,如下图所示。
【原因分析】对于切换流程失败而言,如果是切换准备阶段的失败,其原因通常为以下几种:(1)传输资源不够用;(2)没有配置IPPATH;(3)IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小,接入用户数少,通过X2口传输的数据不多,一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题,在处理过程中需要对X2口和IPPATH问题排查处理,一步步解决问题。
【处理过程】每次切换到目标小区完成后,UE会读取目标小区的系统消息(RRC_SIB_TYPE1),该消息中可以看到目标小区的CGI,通过CGI中的基站ID 确认目标基站B2的ID。
从该次切换的切换命令(RRC_CONN_RECFG)可以找到目标小区CELL2的PCI,在目标基站B2中用MML命令查询确实存在小区CELL2,所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置,如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下:LST SCTPLNK;检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE;检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No,查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId,查看X2口两端的IP配置是否正确。
LTE-华为-传输模式不一致导致切换失败
传输模式不一致导致切换失败问题现象:荣昌高铁站-HLHA在站台优化添加了与爱立信站点荣昌高铁站-ELW跨厂家邻区后观察指标,切成功率掉至12%左右,切换指标非常差。
下表为邻区添加前后指标:原因分析:1、分析问题可能原因:●站点告警导致切换失败;●邻小区定义数据错误导致切换失败;●同频同PCI导致切失败;●邻小区拥塞导致切换失败;●切换参数配置不当导致切换失败;●站点干扰大导致掉线;●弱覆盖导致掉线;●X2接口配置数据错误导致切换失败;●PRACH配置冲突导致切换失败●其他原因;分析及解决步骤:1.查询站点实时告警及历史告警信息,站点状态正常无告警和历史告警。
查询截图如下:2.邻小区定义数据和同频同PCI情况,检查配置的移动国家码,移动网络码,基站标识,小区标识,下行频点,物理小区标识,跟踪区码均配置正常,且邻区内和5公里范围内无同频同PCI情况。
3.检查邻小区拥塞情况,查询立信站点荣昌高铁站-ELW话务情况,无拥塞情况。
4.切换参数配置情况,参数配置正常。
5.站点干扰和弱覆盖情况,提取上行干扰情况正常,现场测试反馈无下行干扰和弱覆盖情况。
6.X2接口配置数据检查,X2接口配置数据正常。
7.PRACH配置冲突导致切换失败,检查PRACH配置无冲突。
8.提取掉线原因值进行分析,从话统上看,切换失败时,“目标小区回复切换准备失败消息导致模式内切换出准备失败次数”占比非常高,而切换正常时,基本没有这个问题9.X2信令跟踪,有大量的“HandOver_Preparetion+failure”,内部原因值为“no-radio-resources-available-in-target-cell”10.统计信令切换失败的QCI分布,其失败主要由于QCI=7业务下切换时导致切换失败,其他QCI情况下切换成功。
检查QCI=7时RLCPDCP参数组配置为如下图:查询RLCPDCP参数组1时为UM模式,5时AM模式。
LTE切换优化总结案例
XX市LTE切换优化总结报告目录一、LTE切换概述 (4)1.1 切换流程图 (4)1.2 切换分类介绍 (6)1.2.1 站内切换 (6)1.2.2 X2口切换 (6)1.2.3 S1口切换 (7)二、LTE切换日常优化 (8)2.1 LTE切换原理 (8)2.2 切换问题优化流程 (9)三、LTE切换自动优化(MRO) (10)3.1 MRO优化场景 (10)3.1.1 切换过早 (11)3.1.2 切换过晚 (12)3.1.3 乒乓切换 (13)3.1.4 切换到错误小区 (14)3.2 MRO优化模式 (15)3.3 MRO优化原理及动作 (15)3.4 网络影响 (16)3.4.1 系统容量影响 (16)3.4.2 网络性能影响 (17)3.5 MRO优化部署建议 (17)3.5.1 部署要求 (17)3.5.2 数据准备 (17)3.5.3 特性激活 (18)3.5.4 开通观测 (19)四、MRO优化试点 (20)4.1 试点区域 (20)4.2 同频MRO优化 (20)4.2.1 试点分析 (20)4.2.2 优化效果 (22)4.3异频MRO优化 (24)4.3.1 试点分析 (24)4.3.2 优化效果 (26)五、日常切换差处理案例 (27)5.1 切换准备失败类优化案例 (27)5.2 模三干扰严重优化案例 (27)5.3 参数配置错误导致切换差优化案例 (28)5.4 T/F切换参数调整提升切换成功率案例 (29)六、总结 (30)一、LTE切换概述1.1 切换流程图切换流程图Measurement Control:测量控制,一般在初始接入或上一次切换命令中的重配消息里携带Measurement Report:测量报告,终端根据当前小区的测量控制信息,将符合切换门限的小区进行上报HO Request:源小区在收到测量报告后向目标小区申请资源及配置信息(站内切换的话为站内交互,站间切换会使用X2口或者S1口,优先使用X2口)HO Request Ack:目标小区将终端的接纳信息以及其它配置信息反馈给源小区RRC Connection Reconfiguration:将目标小区的接纳信息及配置信息发给终端,告知终端目标小区已准备好终端接入,重配消息里包含目标小区的测量控制SN Status Transfer:源小区将终端业务的缓存数据移至目标小区Random Access Preamble:终端收到第5步重配消息(切换命令)后使用重配消息里的接入信息进行接入Random Access Response:目标小区接入响应,收到此命令后可认为接入完成了,然后终端在RRC层上发重配完成消息(第9步)RRC Connect Reconfiguration complete(HO Confirm):上报重配完成消息,切换完成Release Resource:当终端成功接入后,目标小区通知源小区删除终端的上下文信息1.2 切换分类介绍按照我们实际情况,切换可分为eNb站内切换,X2口切换以及S1口切换,下边分别进行介绍(下边介绍的所有切换都是基于已经接入且获取到了测量配置后)。
参数配置导致切换失败优化案例
芜湖LTE参数配置导致切换失败优化案例网优中心李晓刚【摘要】测试中UE由LTE_鹤毛2小区(PCI:49)向LTE_鹤毛1小区(PCI:50)切换失败。
重新核查参数,发现邻区配置参数存在问题。
【关键字】LTE邻区配置参数【故障现象】一、LOG分析,UE在四号大街由东向西行驶,占用LTE_鹤毛2(PCI:49)UE上发测量报告,目标小区为LTE_鹤毛1(PCI:50),当RSRP相差10db仍未发生切换,1秒后出现“HandOver Failed”。
图1:前台标示(初测)【告警信息】网管上检查周边基站,无告警且工作正常。
【原因分析】1、核查切换参数:配置正确无问题;2、核查邻区配置:均已配置;3、怀疑设备问题,重启设备,复测问题依旧;4、尝试重新配置邻区:删除原邻区配置,重新添加双向邻区,进行复测,切换关系正常,如下图所示图2:前台标示(复测)【解决方法】1、重新核查参数,发现邻区配置参数存在问题。
正常邻区配置参数如下:eNodeB IP,eNB id,MCC,MNC,MNC length in PLMN,如172.27.0.121 442820 460 11 2存在问题的邻区配置参数如下:172.27.0.19 0 0 0 2 172.27.0.99 172.27.0.105 2 172.27.0.106 172.27.0.121 442820 460 8 2 172.27.0.123 442820 460 11 2172.27.0.139由于前期工程部门配置邻区参数存在问题,需要重新正确配置。
【结论与推广】通过对邻区配置参数优化调整,有效的改善了邻区切换问题,对小区邻区切换情况有了一定程度上的改善和提升。
在小区邻区切换主要有以下几种优化调整方法思路:思路一:核查切换参数。
思路二:核查邻区配置。
lte切换失败案例
一、案例问题描述对LTE全网切换成功率进行TOP小区处理及分析,发现竹园D3切换成功率一直很低。
见下表:ENB内同频、异频切换正常,ENB间同频切换正常,但ENB间异頻切换率在29%~59%之间,其中按接口类型统计S1口的切换全部失败。
二、切换分析流程三、问题处理过程1)查询小区告警信息,未发现存在影响性能的告警。
2)查询小区相应时间段内的干扰情况,未发现不存在强干扰问题。
3)查询两两小区间的切换对,查看是否由个别邻区的关系影响了小区的切换成功率:查询两两小区间切换对时,发现该基站竹园D2和竹园D3切出到卢屋广场F 基站的三个小区都是全部失败,其他切换对是正常的。
因此问题定位到邻区级和目标基站级。
4)通过跟踪本小区与目标小区的S1口信令,HANDOVER REQUEST及HANDOVERPREPARATON FAIL两条关键信令信息。
其中查询S1AP_HANDOVER_REQUEST的信令解码查询目标小区ENB的消息:关键数据:目标NB-ID为0001,0000,1111,0001,0001B,应对的十六进制为10F11,即十进制为:69393。
5)查看S1AP_HANDOVER_PREPARATON_FAIL的信令解码,查看其失败原因:解码的失败原因为:HO-failure-in-target-EPC-ENB-or-target-system(失败原因为目标EPC或者目标ENB问题)。
根据S1AP_HANDOVER_PREPARATON_FAIL目标小区无法完成切换准备而导致切换失败。
6)查询源小区定义的外部邻区,其中卢屋广场F基站标识为69393共5位的基站NBID,现网配置基站标识的时候一般是6位数,怀疑是基站标识配置错误导致切换失败。
7)查询目标小区的基站标识信息:发现目标小区的基站标识为693937,与竹园D基站定义的源小区的69393不同有错误。
四、优化效果9月10日下午修改源小区错误的邻小区参数,从69393改为693937。
MME互连链路不通导致LTE站点切换失败
MME互连链路不通导致LTE站点切换失败1问题描述X局点新建大量LTE站点,经过前期优化调整,同频切换成功率有明显提升(由94.46%提升至97.81%),如图1所示。
但仍与验收指标有差距,要进行进一步分析调整。
图1 X局点LTE站点同频切换成功率2问题分析关于切换成功率低的问题首先判断是全网性现象的还是由TOP小区指标差造成的,如果是全网性的,检查近期是否有大面积修改参数,或者核心网是否有割接调整。
在本案例中,LTE站点均为新建,而指标随着前期优化调整已有提升,因此首先考虑TOP小区问题。
根据此思路,对TOP小区分析后可知,大量边界站点同频切换成功率低,如图2所示。
图2 同频切换成功率TOP小区问题分析要寻找共性,首先将站点导入地图中查看,切换成功率低的站点均位于省际边界;其次,提取切换指标成功率,发现切换失败多为切出失败。
如图3所示。
(a)站点分布;(b)切换成功率指标图3 切换成功率低站点分布及切换成功率指标如图4 S1信令,S1AP_HANDOVER_PREPARATION_FAIL的原因是Unknown Target ID。
以下为具体信令消息:HandoverType=intralte;cause=handover-desirable-for-radio-reason,handover-desirable-for-radio-reason; tarENBID=A1 C9 A0 ; tAc=41385; TargetCellid=A1 C9 A1 20; SourceCellid=97 D4 B1 80; sourceUE-Identity=EE BE,切换源小区为A,为X局点基站,目标小区为B,为邻省基站,即该切换问题为向邻省基站切出失败。
(a)S1信令;(b)源小区与目标小区位置图4 S1信令跟踪及两两切换成功率低站点位置而Uu消息中可以看到(如图5所示),手机上报的MR中测量邻区信号强度满足切换门限(4dB)。
LTE核心网鉴权关闭导致切换失败
LTE核心网鉴权关闭导致切换失败现象描述:
在某TDD-LTE实验网,站间小区切完后直接RRC CONNECTION RELEASE,切换失败率增加。
告警信息:
无
原因分析:
LTE核心网鉴权关闭导致切换失败
处理过程:
前台测试信令
1、 UE 在站内小区间切换时,前台测试信令都是正常的未出现异常
2、站间小区切换完成后, UE 在上报 RRC 重配完成信令后,收到基站侧下发的“ RRC CONNECTION RELEASE ”信令,随后 UE 发起接入过程,尝试多个站间切换,该问题始终存在。
但经现场测试人员确定切换过程中 RSRP 良好,无干扰存在。
从以上情况可以得出无线侧是没有问题的,初步怀疑是核心网之间是否存在问题。
如下图:
后台信令跟踪:
1 、通过后台信令跟踪发现 UE 上发切换完成信令“ RRC Connection Reconfiguration
Complete ”后,核心网直接下发“ RRC CONNECTION RELEASE ”给 UE ,导致 UE 重新建立 RRC 连接;
前后台的信令对比分析得出,由于核心网下发了 RRC 拆链的信令,导致切换不成功,故问题可以暂定为核心网存在问题。
后通过与核心网人员确认,核心网将鉴权功能关闭,导致在站间切换时, UE 鉴权被拒,从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权,该切换问题解决。
建议与总结:
核心网将鉴权功能关闭,导致在站间切换时, UE 鉴权被拒,从而导致切换完成后直接 RRC 释放。
后核心网打开鉴权,该切换问题解决。
04-14.2LTE切换问题案例分析教案
切换案例1 邻区漏配问题的案例分析为了保证在各种复杂的地形环境下,用户在移动的同时能够获得良好的信号质量,保证业务的畅通进行,切换是必不可少的保障。
良好的切换性能直接关系到小区的吞吐量、用户的通话质量和数据传输速率,因此,对切换问题进行优化,能提升小区的吞吐量、改善用户的通话质量、提高用户的数据传输速率,从而提升用户对LTE网络的感知。
本次课就来学习一下有关LTE无线网络中邻区漏配问题的典型案例。
一、实训目的1.掌握邻区漏配问题的重要特征。
2.加深对邻区漏配问题优化处理思路的理解。
二、实训步骤及注意要求1.启动Pilot Pioneer在安装好的电脑中,启动Pilot Pioneer后台分析软件。
2.导入数据(1)导入基站数据库启动Pilot Pioneer之后,在主菜单“配置”菜单中选择“基站数据库管理”,在弹出的对话框中,选择基站栏目下的LTE选项,再选择导入按钮,将文件名为“实训9基站工程参数.xls”的文件导入到Pilot Pioneer中来。
(2)打开数据文件在Pilot Pioneer软件主菜单“文件”中选择“导入测试数据”子菜单,再选择“常规”在弹出的对话框中,选择文件的路径,将文件名为“实训9数据.RCU”文件导入到Pilot Pioneer中来。
3.解压和解码数据文件在工程窗口中,选择“工程”选项卡,用鼠标双击导入的数据文件(即“实训7数据”文件)下面的Message选项,软件就会对“实训9数据”进行解压和解码,并自动弹出信令窗口。
4.打开常用的窗口Graph窗口、Line chart窗口、事件窗口、LTE Serving+Neighbor Cell List窗口等常用窗口。
9.2 数据分析1.问题描述UE由南往北行驶至图S9-1所示的椭圆区域时,UE接收到RSRP信号强度急剧下降。
图S9-1 UE的RSRP测试轨迹图2.问题分析通过LTE Serving+Neighbor Cell List窗口查看服务小区和邻区的RSRP发现,在15:07:56.036时刻服务小区的RSRP=-105.56dBm,UE检测到距离359.60m 之外开发区盛华心港湾49(PCI=23)的小区RSRP信号较强,其RSRP=-97.75dBm 如图所示:图S9-3 UE检测到信号较强小区RSRP测试图在随后3s多的时间内,UE多次向eNodeB上报测量报告消息,要求进行A3事件切换,即由开发区茂华国际10号楼50(PCI=142)的小区切换到开发区盛华心港湾49(PCI=23)的小区。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
X2IPPATH配置问题导致切换不成功
关键字:X2IPPATH 切换
【现象描述】
切换测试时,从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败,HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE,进入该消息中可以看到cause为
transport-resource-unavailable,切换不成功,如下图所示。
【原因分析】
对于切换流程失败而言,如果是切换准备阶段的失败,其原因通常为以下几种:
(1)传输资源不够用;
(2)没有配置IPPATH;
(3)IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小,接入用户数少,通过X2口传输的数据不多,一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题,在处理过程中需要对X2口和IPPATH问题排查处理,一步步解决问题。
【处理过程】
每次切换到目标小区完成后,UE会读取目标小区的系统消息(RRC_SIB_TYPE1),该消息中可以看到目标小区的CGI,通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令(RRC_CONN_RECFG)可以找到目标小区CELL2的PCI,在目标基站B2中用MML命令查询确实存在小区CELL2,所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置,如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下:
LST SCTPLNK;检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE;检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No,查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId,查看X2口两端的IP配置是否正确。
经过以上步骤的核查,发现目标基站B2虽然配置了与源基站B1间的X2接口(从DSP X2INTERFACE 命令的显示结果可以看到已配置),但是没有配置相应的IPPATH(通过LST IPPATH命令看不到X2口对应的IPPATH)。
导致站点B1向B2发送X2口切换请求(HANDOVER_REQUEST)后,收到基站B2发回的X2切换准备失败消息(HANDOVER_PREPARATION_FAILURE),导致切换不成功。
用ADD IPPATH命令配置了站点B2到站点B1的IPPATH后(源站点也要有X2口的配置以及从B1到B2的IPPATH),可以进行正常的X2口站间切换。
【告警信息】无
【建议总结】
在网络负荷不大的情况下,X2口切换准备失败的原因通常与IPPATH配置有关,所以在配置IPPATH时一定要仔细认真,源站与目标站双向配置,预防漏配错配的问题,提高切换成功率。
切换过晚导致切换失败
关键字:切换小区偏置信道质量陡降
【现象描述】
在切换流程进行中,目标小区信号质量出现抖动,信道质量陡降导致切换失败。
在L3信令的表现为:源小区eNB收到多条测量报告,并且下发切换命令。
而UE未收到切换命令,并且仍然周期上发测量报告,直到发起重建,切换失败。
【原因分析】
1、从最后一个测量报告内容看,服务小区无线质量比邻区差6dB,根据现象看可能是邻区漏配。
但是从网络侧操作维护台查询服务小区邻区信息,查找到有邻区配置。
如下图:
且源小区下发测量报告,因此不会是邻区漏配
2、再分析切换信令流程:根据网络配置,切换应该按下面流程交互:
查看网络侧跟踪的信令,在服务小区Uu跟踪可以看到,收到了UE的测量报告,再查看X2口,源小区向目标小区发送了切换请求,并且收到目标小区的切换请求回应,最后在UU口下发了切换命令,但没有收到UE的切换完成消息(站间切换):
UU、X2口信令交互
eNB下发切换命令,但UE侧未收到切换命令,由此可以判断可能是空口出现传输质量问题。
3、再看空口无线质量,查看对应时间的RSRP值,发现在切换时间点附近服务小区的RSRP值出现陡降现象如下图:
从上图看,邻区比服务小区RSRP高1dB的情况维持了近两秒钟,但满足切换门限时服务小区突然变差,导致切换失败,如果切换时机可以提前,应该可以完成切换信令交互,这种现象应该属于切换过晚。
【处理过程】
根据前文分析,这次切换失败的原因在于切换过晚,因此可以通过修改切换门限或延迟触发时间来提前切换。
从上面记录的无线质量变化情况看,如果把切换门限设置为1dB(延迟触发时间默认为320毫秒),基本可以保证在服务小区RSRP突降之前完成切换交互。
可以选择两个方法:
1、把切换门限设置为1dB可以达到目的,但可能影响当前服务小区的所有邻区切换。
2、为了减小影响面,可以修改服务小区到当前切换目标小区之间的小区偏置CIO来解决,从eNB
操作维护台执行:MOD EUTRANINTRAFREQNCELL命令,修改服务小区与切换目标小区间的
CellIndividualOffset = 1dB,表示把切换门限减小1dB。
之后问题解决,切换正常:
【告警信息】无
【建议总结】
合理规划小区偏置是网规网优的重要工作,对提高覆盖意义重大。
外部邻区配置错误引起下发重配置PCI错误导致切换失败问题
关键字:外部邻区 PCI错误切换失败
【现象描述】
UE在 Servering CELL PCI为10的小区上,上报PCI为13(或者12)的测量报告,但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息,引起切换失败,业务中断。
【原因分析】
A国S市的LTE Trail项目中,进行全网SIMO优化时发现,上报的测量报告的PCI和eNodeB下发给UE 的RRC重配消息中的PCI不匹配,从而UE未收到重配置完成消息,引起切换失败掉话,业务中断。
具体现象如下:
UE从Servering CELL PCI为10的小区往PCI为13或12的小区切换时,切换失败,查看L3信令,发现UE 上报PCI为13(或者12)的测量报告,但是eNB下发的RRC重配消息是PCI为12(或者13)的相关信道等配置信息,造成切换失败,UE发起重建到目标小区。
如下图1:
UE上报PCI为13的测量报告,见下图2
eNB下发PCI为12的重配置消息,见下图3
第二次出现:见下图4
UE上报PCI为12的测量报告:见下图5
eNB下发PCI为13的重配置消息,见下图6
切换失败,UE重建连接。
见下图7
【处理过程】
1、因为相邻关系和测量报告的小区对不起来,初步怀疑是ANR开关问题,因为前期并未打开ANR
开关且没有出现此问题,于是运行MOD ENODEBALGOSWITCH将全网的ANR开关关闭,发现问题依然存在。
2、分析全网的切换关系,发现只要当服务小区(源小区)为PCI=10时,测量上报PCI=12/13就会
出现问题,只要服务小区(源小区)不是10,就没有问题。
3、重点检查小区PCI=10的环境配置,
LST CELL
LST EUTRANEXTERNALCELL
LST EUTRANINTRAFREQNCELL
LST ENODEBALGOSWITCH:;
LST HOMEASCOMM:;
LST INTRARATHO:;
LST INTRARATHOQCI: QCIBEARERINDEX=9;
LST EUTRANEXTERNALCELL中的结果核查发现,在配置PCI为10的外部邻区关系时把PCI为12和13的对应扇区号恰好弄反,导致UE上报了测量报告后,EnodeB下发给UE的PCI错误,不能收到UE给EnodeB 的重配置完成信令,从而发起目标小区或者源小区重建请求,遭到重建拒绝,切换失败,业务中断。
如下图8
使用MOD EUTRANEXTERNALCELL命令修改目标小区的扇区和PCI的对应关系,问题解决。
【告警信息】无
【建议总结】
配置邻区和修改邻区关系时一定要注意对应关系
ANR功能早已经融入EnodeB版本,确实前期引起过X2口切换失败问题,也有可能引起切换上报PCI 错误或其他问题,但是关闭ANR开关后依然出现此问题,可以根据分析和比较正常信令流程,顺藤摸瓜从而判断问题真正所在而将其解决。