LTE切换失败问答题分析案例分析

合集下载

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切换为题处理案例及切换参数总结

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

切换问题处理及切换参数总结目录:简述: (1)一、案例分析: (1)1.1. 问题描述: (1)1.2. 优化: (3)二:切换参数总结: (3)1.1.UE测量配置基本信道参数表 (4)1.2.A3事件上报参数表 (4)1.3.切换算法参数表 (5)1.4.UE定时器及常量分析 (6)1.5.ENB协议定时器分析 (8)1.6.ENB实现定时器分析 (9)A1~A5,B1~B2事件总结: (10)简述:地铁部分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在切换之前上报服务小区和邻小区的信道质量,便于网络侧合理地判决切换。

经典案例-关于LTE终端异常导致厂家边界切换失败问题处理最佳实践总结

经典案例-关于LTE终端异常导致厂家边界切换失败问题处理最佳实践总结

宁波FDD-LTE异常终端切换失败处理案例1、概述随着L800站点大规模入网,室外L800M已经实现连续覆盖,优化问题也接踵而来,最近在处理厂家边界(华为&中兴)切换问题时,发现一对小区切换成功率极低,需紧急处理。

图表12、问题描述近期华为区域全网切换指标持续下降,查询TOP小区是发现位于华为与中兴边界处一对L800小区切换成功率较低,影响全网指标,下表为问题站点切换指标统计:图表23、问题分析定位3.1 问题分析分析TOP小区分析切换失败原因值、两两切换统计值,以”LF_H_JD甬波波城北_25为例,切换失败原因是“目标小区回复切换准备失败消息导致同频切换出准备失败”,两两切换统计,失败次数都集中目标小区都是中兴:图表3根据Top小区指标初步分析,主要是由于中兴侧基站回复切换拒绝导致切换失败,下一步通过标口信令分析深一步分析失败原因,筛选出切换失败的消息,该消息是目标基站返回给源基站,携带有切换失败的原因值。

如下图所示,携带的原因值为no-radio-resources-available-in-target-cell(12)图表4原因值解释:目标小区无足够资源可用,最终导致切换阶段失败。

本次切换准备失败TOP小区都是此类原因,但实际目标小区负荷不高。

3.2 问题定位由于该基站有切换成功的情况,华为侧选取切换失败与切换成功信令进行分析对比,结果如下:1)当华为L800M基站X2口切换请求消息中携带终端支持BAND5字段,无论800M目标小区是否为中兴切换都会成功;图表5 携带band52)当华为L800M基站X2口切换请求中未携带终端支持BAND5字段,若L800M目标小区为中兴,则会回复切换失败消息,原因值就是”no-radio-resources-available-in-target-cell”图表6 不携带band5中兴侧信令回复分析:针对回复切换失败消息,原因值就是”no-radio-resources-available-in-target-cell”问题,当中兴L800M小区作为目标小区,需要核实源侧发送的“HANDOVER_REQUEST”消息中RRC_UE_CAP_INFO信息是否携带支持band5,如未携带支持band5,中兴侧eNB就不会生成切换命令,导致切换失败。

VOLTE异常事件典型案例分析

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,属于端到端问题,需要集团规范协议流程。

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。

移动LTEVOLTE案例分析汇总

移动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消息,随后呼叫中止,出现未接通事件。

切换优化常见问题及案例(中兴)剖析

切换优化常见问题及案例(中兴)剖析

1 切换优化常见问题及案例1.1 漏配邻区漏配邻区一般可通过无线参数表结合测试数据检查,或者可以在后台直接通过信令跟踪确认收到测量报告后源小区是否向目标小区发生切换请求来确认,但某些场景下我们不易取得无线参数表,且无法进行后台信令跟踪,那么我们可以通过前台信令来分析的到:LTE网络在协议中是一个自优化的网络,终端上报测量报告中会按照a3事件判断原则进行上报,上报的小区不受测量控制中邻区影响,所以只需要将切换异常点的测量报告和当前服务小区的测量控制中的邻区进行对比就可得出是否为漏配邻区1.1.1 前台分析漏配邻区的现象1.1.1.1多次测量报告正常的流程终端在发送测量报告后基站会很快发送切换命令,但如果有漏配邻区,源小区就无法得知目标小区的基站信息,无法正常完成切换流程介绍中的(见图1-1)中的第三步,故无法发送切换命令消息,此时由于终端仍在行进中,源小区信号越来越差,满足a3事件小区逐渐增加,触发新的测量报告,直到有邻接关系的小区出现,基站才能正常发送切换命令下边选取一个典型问题分析:在某次路测中发现如图4-1情况,前三次测量报告目标PCI都是28(前三次类似图4-2,PCI相同,RSRP测量值略有差异),第四次测量报告(见图4-3)中有PCI28、19两个小区,从测量值上看,28比19高3个dB,接着收到了切换命令,切换命令(见图4-4)中的目标小区不是最高的28而是19。

此时即可初步怀疑28为漏配邻区,图1-1 多次测量报告现象图1-2 第一个测量报告内容图1-3 第四次测量报告内容图1-4 切换命令1:目标小区PCI图1-5 源小区测量控制信息1:邻区列表中带有PCI19小区1.1.1.2测量报告发送后无响应4.2.1.1介绍了漏配邻区导致的多次测量报告,直到某一次测量报告中上报的目标小区是源小区的邻区则才会收到切换命令,但如果上报的测量报告基站还未响应就失步则会发起重建流程,终端上报掉话事件这种情况的分析方法基本和4.1.1.1一致下边选取一个典型例子:某次路测中发现终端在发送测量报告后未收到切换命令,导致无线链路失败发起了重建过程(如图4-6),首先检查测量报告内容(图4-7,两个测量报告PCI都为30),目标小区PCI为30,检查源小区测量控制(图4-8),发现的确未配置邻区。

  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、再分析切换信令流程:根据网络配置,切换应该按下面流程交互:
查看网络侧跟踪的信令,在服务小区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开关后依然出现此问题,可以根据分析和比较正常信令流程,顺藤摸瓜从而判断问题真正所在而将其解决。

相关文档
最新文档