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切换为题处理案例及切换参数总结切换问题处理及切换参数总结⽬录：简述：地铁部分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配置是否正确。
TDD-LTE宏站切换失败小区问题分析
TDD-LTE宏站切换失败小区问题分析
作者：李俞瑾
邮箱：liyujin@
所在省：辽宁
关键字：邻区漏配;宏站;弱覆盖;掉线;下载速率低;
专业：无线/TD-LTE
设备类型：ENODEB
设备厂家：无线/华为
设备型号：BTS3900 LTE
软件版本：V100R008C01SPC100
故障描述：
LTE站点1小区在单验过程中，由站内向站外切换成功，但由站外向站内切换失败，并且RSRP差距大于10dB。
该测试小区RSRP相对良好，并无任何告警。
故障诊断：
1、处理流程图：
2、原因分析：
经查看，测试小区无告警，并且与站内邻区切换正常，且事件发生在由站外小区切换到站内小区，初步分析原因为邻区漏配或者切换门限过大
针对问题表象，分析处理步骤如下进行：
（1）、邻区参数核查
（2）、切换门限阀值核查
处理过程：
步骤一：联系后台人员对LTE小区进行切换门限阀值核查，发现该小区并不存在切换门限阀值过大。
步骤二：联系后台人员对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就不会生成切换命令，导致切换失败。
基于S1接口切换失败-分析
.教育资料基于S1接口切换失败分析2014-09-25一、概述广州LTE网络的S1切换性能从9月18日开始，出现HO Prepare Fail “切换出准备失败_目前侧准备失败”次数增加明显，总体切换成功率从98.9%恶化到98.5%左右。
失败切换的邻区关系，在小区和TAC维度存在聚类。
二、S1-Based Handover信令流程LTE网络S1接口的切换流程：➢源eNodeB决定进行基于S1的切换。
S1切换的原因可能是源eNodeB和目标eNodeB之间不存在X2连接，或者源eNodeB根据其他情况作出的判断。
➢源eNodeB向源MME发送Handover Required消息，其中Handover Type 在此时是intra-LTE，TargetID包含Target Cell ID和Target TAI两部分，源MME可以根据目标TAI来选定合适的目标MME。
Direct Forwarding Path Avaliability用来指示在源和eNodeB之间是否存在存在直接转发的路径还是需要进行Indirect Tunnel Forwarding。
➢源MME选定合适的目标MME，通过S10接口发送Forward Relocation Request消息给目标MME。
➢目标MME选定相应的目标SGW，发送Create Session Request消息给目标SGW，消息中包含每个承载的上下文。
目标SGW为数据承载分配上行GTP －U的地址和TEID值，返回Create Session Response消息给源MME。
➢目标MME发送Handover Request消息给目标eNodeB，其中包括要建立的EPS承载的列表等内容，每个EPS承载的信息包括SGW的地址，上行GTP －U的在SGW侧的TEID值，EPS 承载的QoS等。
目标eNodeB收到上述消息后会建立UE上下文，包括承载的信息，安全上下文等。
LTE同频切换失败优化
LTE同频切换失败优化案例【摘要】ANR邻区自动优化功能开启后，一些新开通4G小区由于实施RF优化前覆盖过远，极易被切换源小区添加为同频邻区关系；同时源小区也添加了相同PCI的另一距离较近的切换目标小区邻区关系，终端由源小区向目标小区切换时，根据PCI遍历邻区关系列表，发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI，若因终端问题或其它因素导致ECGI上报失败，容易产生切换失败问题。
【关键字】ANR 同PCI ECGI【故障现象】：市区优化DT测试期间，终端占用43633-邮政储蓄银行2小区由北往南至436218-天上人间3小区出现一次同频切换失败现象。
DT测试软件截图如下图1图1：同频切换失败【告警信息】：U2000网管查询基站无告警图2：告警查询【原因分析】：同频切换失败原因较多，如基站故障、邻区漏配、切换参数配置不合理等都有可能导致切换失败问题，具体分析处理如下。
核查43633-邮政储蓄银行2与436218-天上人间3小区邻区关系表及同频切换参数配置正常。
图3：邻区核查配置正常436218-天上人间3小区PCI配置PCI85正常图4：目标小区PCI配置查询操作日志核查43633-邮政储蓄银行2与436218-天上人间3小区DT测试期间无任何操作。
图5：操作日志查询回溯切换失败前基站下发的切换配置消息中，基站要求终端上报PCI85的ECGI信息，截图6如下图6：ECGI上报请求根据LTE同频切换流程可知终端由源小区向目标小区切换时，会根据PCI遍历邻区关系列表，若发现存在两处相同PCI的邻区关系后，基站会要强求终端上报ECGI方式来判断最终切换目标小区。
图6信令的出现表明43633-邮政储蓄银行2小区存在两条相同PCI85的邻区关系，核查43633-邮政储蓄银行2的外部小区中PCI为85的存在436670-51/436218-55两个外部小区，查询结果如下图4图7：外部小区核查结果43633-邮政储蓄银行2小区邻区列表中436670-51/436218-55已添加邻区关系，查询如下图8图8：邻区关系核查结果回到DT数据中终端切换流程，基站要求终端上报ECGI信息，根据MSGID找到相应的终端测量报告，打开发现终端上报PCI85的小区ECGI为空值，如下图9图9：ECGI上报失败至此已确定是因终端上报目标小区ECGI信息不成功导致切换失败问题，本次测试终端为华为MATE8：LTER10版本，实际自R9版本及以上终端大部分是支持ECGI上报功能。
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、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 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、再分析切换信令流程：根据网络配置，切换应该按下面流程交互：
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口下发了切换命令，
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开关后依然出现此问题，可以根据分析和比较正常信令流程，顺藤摸瓜从而判断问题真正所在而将其解决。