LTE切换失败问题分析案例

合集下载

案例-目标小区回复切换准备失败案例

案例-目标小区回复切换准备失败案例

目标小区回复切换准备失败案例摘要:LTE系统内切换包括三种类型:eNodeB内切换、X2接口切换、S1接口切换。

本文主要针对现网中存在最多的一类原因目标小区回复切换准备失败TOP区域分析,并进行全网推广核查和总结经验。

关键字:eNodeB内切换 X2接口切换 S1接口切换目标小区回复切换准备失败【故障现象】:统计6月10日至6月16日一周指标发现,阜阳全网日均切换失败次数约17万次,切换准备阶段出现的切换出准备失败次数约1.5万次。

华为网管报表目前仅能统计到切换准备阶段的失败原因分类,执行阶段的失败原因分类暂无法统计。

切换准备阶段4类失败原因:核心网原因、源小区发送切换取消、目标小区回复切换准备失败、目标小区无响应。

阜阳现网切换准备阶段的失败原因类型主要是目标小区回复切换准备失败。

颍上县的谢桥矿区、汤店、周楼区域部分站点目标小区回复切换准备失败次数较多,且主要集中在X2接口切换失败。

【告警信息】:无【原因分析】:Handover Request消息中可以看到切换的目标基站号、小区号、SGW 的IP地址。

Handover Request Acknowledge消息携带目标基站的ip地址。

实际分析,可以通过X2接口信令跟踪或是两两小区切换,查到切换失败的目标小区,进一步分析判断原因。

【解决方法】:1.FY-颍上-谢桥矿区-HFTA-436935-50通过两两小区切换指标发现谢桥矿区50小区向目标小区436943-52切换失败较多,且主要为目标小区回复切换准备失败。

网管查询 436943为迪沟路口基站,小区号为53、54、55。

而网管配置的谢桥矿区50小区同频邻区列表里为436943-52小区。

查询其定义的外部小区,发现定义了436943的50-55小区均为迪沟路口。

怀疑迪沟路口初始规划挂在前3个端口,而实际施工挂在了后3口。

邻区并没有同步更新,导致配置了不存在的小区,从而发生目标小区回复切换准备失败。

LTE切换为题处理案例及切换参数总结

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的S1口IP配置错误导致切换全失败

LTE的S1口IP配置错误导致切换全失败

LTE的S1口IP配置错误导致切换全失败现象描述:RIY322站点大量异常释放Cluster测试中发现在RIY322站点周围,所有站间切入和切出的切换都会失败,当UE占用RIY322周围站点如RIY274C小区信号时,当满足A3事件触发条件时不断的上发测量报告想触发切换,但是一直未收到切换命令,过了一段时间就会触发异常释放。

告警信息:无原因分析:无处理过程:1. 查询RIY322以及周围站点的告警,都无任何告警2. 由于路测数据里面的现象为不断的上报测量报告但是一直未触发切换,初步怀疑为缺失邻区关系导致,检查现网邻区关系发现已经添加了RIY322与周围站点的双向邻区关系3. 检查RIY322以及周围站点的外部描述数据里面的PCI、ENODEB ID、TAC等信息,都与实际配置数据一致且与规划数据完全一致,未发现错误4. 到现场路测并同时跟踪了RIY322站点的Uu、X2、S1口以及周围站点RIY274、RIY258站点的S1信令,现场确认每当切入RIY322或者从RIY322切出的时候都会导致异常释放,但是在RIY322站点下能正常附着成功5. 查看路测数据在15:15:03左右发起了切向RIY258C(PCI=170)的切换,在15:15:45左右发起了从RIY258C(PCI=170)切向RIY322B(PCI=196)的切换请求测量报告RIY258切入切出空口路测数据6. 查看RIY258站点的S1口信令在15:16:41时刻收到了切入的切换请求有完整的切换信令流程成功完成切入RIY258的切换,同时在15:17:21时刻发起了切向RIY322站点的切换请求,但是一直反馈切换失败信息RIY258切入切出S1口信令7. 核对路测数据与S1口信令数据的时间差,差不多为1分37秒左右的时间差8. 由于RIY258站点配置了RIY322站点的X2链路,所以从RIY258切入的时候走的都是X2口切换,从RIY322站点的X2口信令可以看出,不断的有切换请求发过来,但是反馈的切换失败消息为:unknown-MME-Code,始终不能完成切换,发送多次以后就导致了异常释放RIY322的X2口信令9、RIY322站点未配置切出的X2链路,所以切出时都是走的S1切换,查看S1口信令发现在RIY322发出了切换请求以后,从MME发回的失败原因为:unknown-targetID,最终切换失败导致异常释放RIY322的S1口信令10. 从上面的分析可以把切换失败的原因与基站配置的MME的相关数据有关系,从现网导出DBS文件转换为MML脚本后,和现网的正常切换基站作了脚本对比发现,RIY322站点配置的MME的IP地址为10.127.218网段,而RIY258配置的MME的IP地址为10.127.72网段,10.127.218网段为达曼区域的MME的网段,10.127.72为利雅得区域的MME的网段,但是MME与MME之间还未做相关的对接配置,导致跨MME的切换都会失败RIY322与RIY258站点脚本对比建议与总结:修改RIY322站点的MME的IP地址为10.127.72网段。

LTE切换失败问题分析案例

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切换失败处理案例

名称:通达国际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内切换成功率低优化案例

光衰导致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指标波动异常时,排除了基站告警问题、参数配置问题等原因,还需对基站隐性故障及光路隐性故障进行排查,除了排查告警、参数等问题还需对设备隐性故障进行排查,从而加快解决问题,恢复指标。

TDD-LTE eNodeB标识配置错误导致入切换失败

TDD-LTE eNodeB标识配置错误导致入切换失败

TDD-LTE eNodeB标识配置错误导致入切换失败1【问题描述】外场拉网测试过程中发现TDL小区得力纺织入切换异常,该站周围所有小区均无法切入该小区,在UE多次上报测量报告无法正常切换情况下,后台虚用户跟踪信令出现MME回复S1AP_HANDOVER_PREPARATION_FAIL消息,详细原因为MME无法识别目标基站,提示unknown-targetid(未知目标标识)。

图1 连续发送测量报告但无法切换2【处理过程】2.1 告警分析查看当前和历史告警,该站点无任何告警信息。

2.2 话统数据分析提取该站一周话统指标分析,发现eNodeB间入切换尝试次数、执行次数和成功次数均为0。

而该站eNodeB内切换正常、eNodeB间切出正常,所以该站小区状态应该是正常的。

但是周边小区无法切换,可能存在切换参数配置异常导致,所以对小区切换参数进行了全面核查,并未发现参数异常现象。

另外,双模站点GPS故障或收星不足也可能导致入切换异常,故通过TDS系统查询GPS装置工作状态,也并未发现状态异常。

通知外场测试人员对该切换问题复测,并结合信令辅助分析,测试结果显示该站eNodeB间入切换仍然异常。

信令分析结果发现,当占用华新电缆3小区时,UE是可以测量到邻区得力纺织的RSRP 电平值、RSRQ值,但是在满足A3同频切换条件后,源eNodeB往MME发送切换请求时,MME 回复信息内容一直为unknown-targetid,说明源eNodeB上报的邻区信息内容有误或者MME无法识别,即MME接收到eNodeB上报的邻区信息后无法解析或解析后无法找到目标eNodeB。

由于目前华为所有eNodeB均下挂在同一套华为核心网EPC下面,所以不存在多个EPC之间交互的问题,所以只要EPC工作正常,出现MME回复信息内容为unknown-targetid消息,存在两种可能:一、上报的目标eNodeB不存在;二、根据前期优化经验,在同一核心网EPC下如果上报的目标eNodeB ID存在重复现象,核心网在无法辨别的情况下,也是发送unknown-targetid消息的。

LTE切换问题分析

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。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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、再分析切换信令流程:根据网络配置,切换应该按下面流程交互:
Meas_RPRT
Handover_Request
Handover_Request ACK
RRC_CONN_RECFG
(HO_CMD)SN_STATUS_TRANSFER
UE S_eNB T_eNB Core Network
S1AP_PATH_SWITCH_REQ
S1AP_PATH_SWITCH_REQ_ACK
RRC_CONN_RECFG_CMP
(HO_CMP)
UE_CONTEXT_RELEASE
RRC_CONN_RECFG
RRC_CONN_RECFG_CMP
UU_interface X2_interface S1_interface 查看网络侧跟踪的信令,在服务小区Uu跟踪可以看到,收到了UE的测量报告,再查看X2口,源小区向目标小区发送了切换请求,并且收到目标小区的切换请求回应,最后在UU口下发了切换命令,但没有收到UE的切换完成消息(站间切换):
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开关后依然出现此问题,可以根据分析和比较正常信令流程,顺藤摸瓜从而判断问题真正所在而将其解决。

相关文档
最新文档