2024年4月11日发(作者：)

切换出准备失败问题分析

【摘 要】已开通站点站号变更，如果变更前邻区关系数据未完全清除会产生冗余数

据，即邻区信息中既存在变更前站点数据又存在变更后数据，而本次CL共模站点只变更

ENODEBID，其余信息不变。切换是根据终端检测到的PCI进行测量切换的，由于邻区存

在冗余数据，邻区信息中存在2个站点同PCI情况，PCI混淆导致切换失败。

【关键字】ENODEBID变更 PCI混淆 冗余数据

【故障现象】：

已站点446483的eNB间S1口同频切换出成功率较低，失败原因主要是目标侧准

备失败。

图1 S1切换成功率低指标

【原因分析】：

查询该站点的切换出的邻接小区对，发现目标侧准备失败的站点为446482，涉及到

其站点下的所有小区。但是从eNB间S1口小区同频切换出准备请求次数，切换出准备成

功次数和目标侧准备失败次数看，存在成功的情况，而非所有切换出准备请求次数全部失

败。

图2 切换对指标统计

虽然知道是由于目标侧准备失败导致，但是最终原因还没有得到定位。为此，进行了

UE级小区信令跟踪来进一步确认问题原因。

通过跟踪信令查看msgname==handover preparation failure，发现其准备失败只

有一个原因，其原因值为：unknown_targetID。

图3 UE级小区跟踪信令图

详细查看gid==11130的信令流程，当源侧基站通过S1链路发Handover Required

请求给核心网时，在短短20ms的时间里，核心网给基站回复Handover preparation

Failure，失败原因是目标侧ID未知。后面再次发起切换请求时，核心网10ms的时间里

给基站回复Handover preparation Failure，失败原因依然是目标侧ID未知

图4软件跟踪信令图

分析“unknown_targetID”切换失败的原因，有以下几种可能情况：

用户请求的targetID（eNodeBID、TAI、CELLID）在现网中出现重复配置，冗余数

据。

目标小区在源小区的邻区信息表，与现网小区的信息不一致，导致上报的targetID无

法被网络识别。

用户切换请求中的targetID（eNodeBID、TAI、CELLID）目标小区不存在（可能存

在基站断链，基站板卡硬件故障）。

因446483向446482切换时，切换出准备请求次数有一部分成功，一部分失败，所

以邻接小区表中引用的目标小区与现网信息不一致的可能性就不存在了，如果存在，那应

该是所有切换出准备请求全部失败。

每个站点与MME配置了2条S1链路，因此怀疑切换的目标站点446482的某条S1

链路故障，导致当源站446483下通过该条S1链路向MME发起切换请求时，MME通过

该条S1链路对应的MME_code未能获取目标站点446482的站点信息，从而引起切换出

准备失败。而通过另外1条正常的S1链路发起请求时，切换准备成功。

动态管理里查询目标站点446482的S1AP状态，发现其中一条S1链路运行状态故障。

图5 S1AP状态图

再次回看信令，发现当ue在MME_code=26（HEX）发起S1切换（切换目标站点

为446482），几次切换准备均失败。

图6 软件切换信令图

查看S1链路配置，SCTP列表和S1AP列表如下所示：

图7 S1AP截图

图8 SCTP截图

SCTP列表中的2条链路号分别为0、1，而S1AP列表中，引用的SCTP确是0、1，

很明显S1AP中引用的0是有问题的。

那么可以确认目标站点因S1AP引用错误，从而导致发生在该链路上的S1切换出准备

失败，即源站点446483通过该S1链路发起MME的切换准备请求时，因446483对应

的S1链路引用错误，导致MME侧给源站点446483回复了原因值为unknown_targetID

的handover preparation failure。

【解决方法】：

将S1AP列表中引用的0修改为1后，接下来的小时级KPI指标中，目标侧准备失败

导致的eNB间S1口同频切换出准备失败次数最后锐减至0，eNB间S1口同频切换出成

功率恢复。

【结论与推广】

对于目标侧准备失败引起的切换出准备失败，如果是全部失败，通常需要优先确认源

站邻接小区信息里配置的目标站点参数（如PLMN、MCC、MNC、TAC等）是否有问题，

如果非全部失败，就需要考虑S1链路配置是否部分存在有问题，当然优先查看确认告警信

息，排除告警导致的问题，再结合UE级小区信令跟踪来进一步确认准备失败的具体原因

值，深入分析从而找到问题的根本原因。