基于S1接口切换失败-分析
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网段。
切换出准备失败问题分析
切换出准备失败问题分析【摘要】已开通站点站号变更，如果变更前邻区关系数据未完全清除会产生冗余数据，即邻区信息中既存在变更前站点数据又存在变更后数据，而本次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）在现网中出现重复配置，冗余数据。
基于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上下文，包括承载的信息，安全上下文等。
S1链路引起切换失败
S1链路引起切换失败1、问题描述从近期的KPI指标上看，绍兴中兴区域切换成功率有下降趋势，从前期的99.5%以上下降到近期的99.4%上下，我们近期加强了对切换指标的分析，3月14日发现LF_Z_柯桥华舍路社（348474）少条S1链路造成周围基站向该站3个扇区切换均存在大量失败，切换成功率较低，，3月14号对其S1链路进行了增加后，该站切换成功率明显提升；2、问题分析通过观察KPI指标，发现绍兴电信切换成功率指标有下降趋势，我们对全网切换小区对进行了分析，发现周边站点向LF_Z_柯桥华舍路社（348474）切换均存在大量失败，切换成功率均较低，但均有成功；2.1KPI指标表一切换成功率指标近期10天切换成功率趋势图：图一切换成功率趋势图2.2切换小区对分析切换小区对分析：通过全网导出小区对进行分析时发现，周围基站切入LF_Z_柯桥华舍路社（348474）基小区名称eNodeB 邻区关系[FDD]系统内同频切换出成功率(小区对)[FDD]系统内同频切换出请求次数(小区对)[FDD]系统内同频切换出失败次数(小区对)LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:50 37.61% 1933 1206 LF_Z_柯桥华舍街道_3 348173 0:460:11:348474:50 30.21% 1304 910 LF_Z_绍兴金城村_2 349225 0:460:11:348474:51 16.26% 990 829 LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:51 41.45% 1035 606 LF_Z_柯桥华舍金城村南_1 348598 0:460:11:348474:51 18.71% 684 556 LF_Z_柯桥华舍金城村南_2 348598 0:460:11:348474:51 32.31% 718 486 LF_Z_绍兴杨汛桥联社东_2 349017 0:460:11:349302:50 0.00% 221 221 LF_Z_柯桥华舍金城村南_1 348598 0:460:11:348474:50 16.26% 246 206 LF_Z_柯桥华舍街道_1 348173 0:460:11:348474:49 21.15% 208 164 LF_Z_柯桥华舍街道_1 348173 0:460:11:348474:50 34.21% 152 100 LF_Z_绍兴金城村_2 349225 0:460:11:348474:50 5.56% 72 68 LF_Z_柯桥华舍街道_3 348173 0:460:11:348474:49 4.62% 65 62 LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:49 66.00% 150 51 LF_Z_柯桥大西庄_1 348245 0:460:11:348474:51 47.73% 88 46 LF_Z_柯桥华舍华舍北_1 348315 0:460:11:348474:49 11.76% 34 30 LF_Z_柯桥华舍金城村南_3 348598 0:460:11:348474:51 29.73% 37 26表二柯桥华舍路社切入小区对通过小区对发现，该站LF_Z_柯桥华舍路社（348474）切出均正常，如下所示表三柯桥华舍路社切出小区对2.3告警检查通过对LF_Z_柯桥华舍路社（348474）基站的当前告警进行查询，该站当前无任何告警，如下所示：图二柯桥华舍路社当前告警同时我们对该站历史告警查询发现该站在3月11号出现系统lisence过期告警，怀疑有人在3月11号对该站进行操作过，同时我们对该站参数进行检查，未发现该站参数异常首先我们考虑对基站进行网元复位，3月14号12:05:11我们对该站进行网元复位，如下所示图三柯桥华舍路社历史告警通过对基站进行网元复位后，观察指标，发现该站切换指标没有变化，从切换失败原因看，全部是S1目前侧准备失败，切换成功率又不是100%失败，这时我们怀疑S1链路造成，小区名称eNodeB 邻区关系[FDD]系统内同频切换出成功率(小区对)[FDD]系统内同频切换出请求次数(小区对)[FDD]系统内同频切换出失败次数(小区对)eNB间X2口小区间同频切换出准备失败次数，目标侧准备失败eNB间S1口小区间同频切换出准备失败次数，目标侧准备失败表四柯桥华舍路社切入小区对2.4 S1链路检查我们对全网S1链路进行检查时发现，全网只有LF_Z_柯桥华舍路社（348474）基站配置了2条S1链路，如下所示3、解决问题对LF_Z_柯桥华舍路社（348474）S1链路进行增加，目前全网每个站配置3条链路，如下所示图四柯桥华舍路社网管S1链路4、指标跟踪3月14号对该站进行增加一条S1链路后，3月15号对LF_Z_柯桥华舍路社（348474）日期小区名称eNodeB 邻区关系[FDD]系统内同频切换出成功率(小区对)[FDD]系统内同频切换出请求次数(小区对)[FDD]系统内同频切换出失败次数(小区对)2015/3/15 LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:50 99.28% 417 3 2015/3/15 LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:51 99.55% 223 1 2015/3/15 LF_Z_柯桥华舍金城村南_2 348598 0:460:11:348474:51 100.00% 205 0 2015/3/15 LF_Z_柯桥华舍街道_3 348173 0:460:11:348474:50 100.00% 122 0 2015/3/15 LF_Z_绍兴金城村_2 349225 0:460:11:348474:51 100.00% 70 0 2015/3/15 LF_Z_柯桥蜀阜_3 348230 0:460:11:348474:51 100.00% 48 0 2015/3/15 LF_Z_柯桥华舍金城村南_1 348598 0:460:11:348474:51 97.83% 46 1 2015/3/15 LF_Z_柯桥华舍街道_1 348173 0:460:11:348474:50 100.00% 22 0 2015/3/15 LF_Z_柯桥大西庄_1 348245 0:460:11:348474:51 100.00% 17 0 2015/3/15 LF_Z_柯桥华舍街道_2 348173 0:460:11:348474:50 100.00% 16 0 2015/3/15 LF_Z_柯桥蜀阜_2 348230 0:460:11:348474:50 100.00% 16 0 2015/3/15 LF_Z_柯桥华舍金城村南_1 348598 0:460:11:348474:50 100.00% 15 02015/3/15 LF_Z_柯桥华舍金城村南_3 348598 0:460:11:348474:51 92.31% 13 1 2015/3/15 LF_Z_柯桥蜀阜_1 348230 0:460:11:348474:49 100.00% 13 0 2015/3/15 LF_Z_柯桥华舍街道_1 348173 0:460:11:348474:49 100.00% 8 0 2015/3/15 LF_Z_柯桥蜀阜_3 348230 0:460:11:348474:50 100.00% 8 0 2015/3/15 LF_Z_绍兴金城村_3 349225 0:460:11:348474:51 100.00% 6 0 2015/3/15 LF_Z_柯桥建拓五金_3 348231 0:460:11:348474:51 100.00% 6 0 2015/3/15 LF_Z_柯桥华舍排污站西_3 348299 0:460:11:348474:50 100.00% 4 0 2015/3/15 LF_Z_柯桥华舍华舍北_1 348315 0:460:11:348474:49 100.00% 3 0 2015/3/15 LF_Z_绍兴金城村_2 349225 0:460:11:348474:50 100.00% 2 0 2015/3/15 LF_Z_柯桥华舍排污站西_1 348299 0:460:11:348474:50 100.00% 1 0表六柯桥华舍路社切入小区对同时我们对LF_Z_柯桥华舍路社全天切换失败次数进行了统计，加了S1链路后，失败次数明显下降；统计时间13:00------14：00图5 柯桥华舍路社切换失败次数。
S1链路缺失引起切换失败
通过咨询厂家后，发现网管上LF_Z_柯桥时代广场只有2条S1链路，是由于1月12号晚上对全网进行了升级，个别站点未升级到原因造成，通过手动增加后指标提示明显，马上恢复到99%左右
2条S1链路
MEID
sctpNo
localPort
remoteAddr
管理网元ID
SCTP链路号
本端端口号
远端地址
7140
17512
10372
40.77%
49
LF_Z_柯桥中海国际广场RRU1_2幢2单元
348165
4612
13060
8448
35.31%
49
LF_Z_柯桥韩国城RRU1_东北向
348930
6711
13754
7043
48.79%
49
LF_Z_柯桥华宇_1
348182
7388
14395
7007
51.32%
99.49%
2016/1/21 0:00
2016/1/22 0:00
1天
9765994
9817439
99.48%
2016/1/22 0:00
2016/1/23 0:00
1天
9068843
9106025
99.59%
2016/1/23 0:00
2016/1/24 0:00
1天
8338101
8369998
2016/1/8 0:00
1天
10450268
10492258
99.60%
2016/1/8 0:00
2016/1/9 0:00
1天
11107102
11153127
切换失败分析及处理流程
切换失败分析及优化流程 测试过程中发现切换失败时处理流程：小区切换成功率低的处理流程：处理说明：1)切换成功率小于20％，可以判断两个小区具有相同的BCCH和BSIC。
手机区分小区首先判断BCCH频点，如果BCCH相同,则判断BSIC（此时存在一个同频干扰），如果BSIC也相同，手机将无法判断小区,从而导致BSC也无法判断究竟需要切换到哪个小区上去。
原则上，只要手机能够收到该小区的信号，就不能存在同BCCH并且同BSIC。
一般地，如果切换成功率低于50%,可以估计是由于同BCCH并且同BSIC引起的.2)检查参数定义是否对应和正确：a)切换参数：OFFSET、HYST原则上，OFFSET应该等于0，HYST大约等于2左右。
在某些情况下，OFFSET会不等于0，此时需要注意检查两个小区的OFFSET是否对应,即CELL-A定义到CELL—B的OFFSET＝3,那CELL—B定义到CELL—A的OFFSET＝－3。
OFFSET不等于0，表示两个小区的切换边界与小区实际边界有所偏离，此时也需要注意空闲模式下的CRO也要对应设置，以保持小区空闲模式边界与切换边界相同，否则手机将可能在通话开始后,马上发生一次不必要的切换。
两个小区的切换边界与小区实际边界有所偏离，等于扭曲了小区边界，原则上是不好的,但是在以下情况可以取得相应的效果（好的效果）:第一、如果小区的实际边界正处于话务量集中区域或者干扰区域，在不能调整基站位置和天线方向角/下倾角的情况下，让切换避开这些区域，可以提高切换成功率;第二，如果某个小区话务量高或者硬件故障多，可以通过缩小切换边界来减少在该小区内的通话，从而达到提高指标的作用，当然,这只是治标的措施。
HYST不能等于0，否则会引起乒乓切换.但是也不能太大,否则会造成强信号不切换.如果两个小区的信号重叠实在太多,可以适当增加HYST，同时增加定位算法的滤波器值。
b)定位参数：定位算法直接影响最合适小区的选择,如果手机不能选择到最合适的小区上，必然影响切换成功率。
基于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上下文，包括承载的信息，安全上下文等。
S1接口链路建立失败导致切换失败
S1接口链路建立失败导致切换失败【案例时间】2015-04-21 【案例作者】 【产 品 族】LTE【故障类别】保持类 切换类 【关 键 字】切换成功率低 【现象描述】h819524省外呼中心DM 切换出成功率低降，失败原因均为目标小区回复切换准备失败消息导致切换出准备失败。
图1小区切换失败信息【告警信息】用户面承载链路故障告警（S1） 【原因分析】查看站点点到点的切换信息，h819524省外呼中心DM 的切换失败主要集中在与h719475滨江移动枢纽大楼DM_new 的切换中。
核查外部小区定义，均无异常，且周边不存在同频同PCI 小区，核查切换参数，均配置合理。
图2 点到点切换失败信息开始时间周期(分钟)小区标识本地小区标识基站标识本地基站标识本地小区名称特定两小区间切换出失败次数 (无)特定两小区间切换出成功次数 (无)特定两小区间切换出尝试次数 (无)切换成功率04/03/2015 08:00:006032757056397225省外呼中心D_21607517212424.34%04/03/2015 15:00:006032757056397225省外呼中心D_21382375175721.34%04/03/2015 13:00:006032757056397225省外呼中心D_21227327155421.04%04/03/2015 12:00:006032757056397225省外呼中心D_21184426161026.46%04/03/2015 14:00:006032757056397225省外呼中心D_21150334148422.51%04/03/2015 09:00:006032757056397225省外呼中心D_21073365143825.38%04/03/2015 10:00:006032757056397225省外呼中心D_21040439147929.68%04/03/2015 11:00:006032757056397225省外呼中心D_21019312133123.44%04/03/2015 15:00:006012757056397225省外呼中心D_21012345135725.42%04/03/2015 08:00:006012757056397225省外呼中心D_2968539150735.77%核查站点告警信息，目标站点h719475滨江移动枢纽大楼DM_new 无告警，且站点激活正常，但h819524省外呼中心DM 存在用户面承载链路故障告警（S1），推测是告警导致了切换失败，优先处理告警信息。
LTE网络S1接口切换成功率低分析V1
LTE网络S1接口切换成功率低分析V1LTE网络S1接口切换成功率低分析【原理说明】S1接口切换成功率=S1接口切换成功次数/ S1接口切换请求次数；S1切换失败原因：目标小区回复切换准备失败消息导致模式内切换出准备失败，目标小区无响应导致模式内切换出准备失败，源小区发送切换取消导致模式内切换出准备失败和核心网原因导致模式内切换出准备失败这些原因导致。
1 问题描述4月26日凌晨，**市核心网增加一条S1链路，在原有三条链路的基础上变成了四条，核心网修改后，对比4月25日与4月26日KPI 指标，发现S1接口切换成功率有小幅下降，之后继续观察，并发现该项指标持续降低。
2 问题定位首先我们先通过后台对全网S1切换失败站点查询，对失败次数按照TOP 10统计，如下表，其中前7个小区S1切换成功率为0 ，核查以上站点，均无告警。
将以上站点制作为Mapinfo 图层，问题站点集中分布区域如下所示，对Top10站点中抽取LF_H_黄岩移动新前牟村和LF_H_黄岩西城岙岸两基站进行两两小区切换，指标按小时提取T op10，切换失败的站点均为LF_H_黄岩移动黄岩中学。
基站名称小区名称本地小区标识LTE 系统内切换成功率-jtS1接口切换成功率-jt(%)S1接口切换请求次数-jt S1接口切换成功次数-jt S1接口切换失败次数-jtLF_H_黄岩移动新前牟村LF_H_黄岩移动新前牟村_50295.34702590259LF_H_黄岩西城岙岸LF_H_黄岩西城岙岸_51394.5502020202LF_H_黄岩新前支局BBU9LF_H_黄岩联通新前七里浮桥_49193.385401810181LF_H_黄岩新前支局BBU12LF_H_黄岩新前消防队_50297.881901800180LF_H_黄岩新前支局BBU13LF_H_黄岩移动七里_49195.646601660166LF_H_黄岩头陀孙东村LF_H_黄岩头陀孙东村_49186.857801160116LF_H_黄岩柑橘研究所LF_H_黄岩柑橘研究所_49189.9802074074LF_H_黄岩新前支局BBU12LF_H_黄岩新前消防队_49199.4117 1.538565164LF_H_黄岩头陀孙东村LF_H_黄岩头陀孙东村_50298.33737.2549511932LF_H_玉环城关岭头村LF_H_玉环城关岭头村_49196.94692.507234732126同时通过对S1切换失败次数最多站点LF_H_黄岩移动新前牟村进行S1链路信令跟踪，发现切换失败命令中，失败原因值为，Unknow-Target ID，目标小区丢失。
切换失败的原因及优化方法
切换异常的原因及优化方法（1）硬件故障导致切换异常由于TD采用多通道智能天线系统，而良好的赋形首先需要各个通道之间功率校正保持一致。
如功率校正通不过，将会导致赋形产生偏差，从而可能导致系统切换失败。
优化方法：查看基站设备告警记录，对故障的天线、基站硬件设备进行更换。
（2）同频同扰码小区越区覆盖导致切换异常在专用模式下，UE发送的测量报告，是根据PCCPCH 的使用频点以及扰码为标识来区分不同邻小区的。
如果存在同频同扰码小区越区覆盖，则可能会出现UE上报的测量报告中存在虚假邻小区信息，从而导致系统发出切换指令，使得某些处于专用模式下的UE频频尝试向实际信号并不好的越区覆盖小区发出切换请求，必然造成切换失败（也可能是乒乓切换）。
优化方法：从规划以及优化方面来避免同频同扰码小区越区覆盖现象。
主要是调整频点、扰码或工程参数（天线方位角、俯仰角、天线高度、小区最大发射功率等）。
（3）越区孤岛切换问题在环境比较复杂时，较近小区的信号由于阻挡产生一定损耗，而其他小区可能会从建筑物夹缝中透露出来，形成较强越区孤岛。
由于该区域的小区和越区小区之间不会互配置邻小区，在干扰没有严重到导致下行失步时，UE将不会选择到该小区上，但在服务小区信号较弱时，UE很可能会重选到该越区孤岛上。
当在该小区上通话（建立其他的DPCH也是一样）后，将会导致无法切换从而掉话的现象。
此类问题在切换指标上是无法显示出异常的，主要表现为掉话严重。
优化方法：对发生越区覆盖的小区的天线方向角、俯仰角、小区最大发射功率进行调整，必要时要降低天线高度；如果上述方法均不可行，可添加邻区关系，使切换正常。
（4）目标邻小区负荷过高（或部分传输通道故障），导致切换失败当目标邻小区的负荷过高时，切换将无法完成。
另外，当目标小区的部分传输通道由于误码较高或频繁瞬断时，也会引起切换（选择）失败。
如果是跨RNC，由于源RNC不了解目标RNC的传输故障情况，因此只要有切换请求，就会尝试进行切换执行，而最终导致切换失败，这种情况要持续到源RNC收不到目标小区的测量报告为止。
S1口导致切换成功率低
a)包头东河彩虹超市-HLHF及周边站点邻区核查：
根据基站拓扑结构核查包头东河彩虹超市-HLHF及周边站点的邻区，确定现网邻区无漏配的问题，确定包头东河彩虹超市-HLHF及周边站点的PCI规划合理。
b)包头东河彩虹超市-HLHF及周边站点外部邻区定义核查：
核查包头东河彩虹超市-HLHF及周边站点外部邻区的定义，主要核对外部邻区PCI及TAC设置,将外部邻区定义的PCI及TAC与现网比对，确定没问题。
c)同频切换参数检查及现场测试：
切换参数均为默认值，核查无问题。
现场测试，包头东河彩虹超市-HLHF与包头东河远大蔬菜市场-HLHF切换正常，验证了该站的参数设置没问题，可能有其他不常见的问题导致。
d)后台跟踪：
查询周边站点切换出失败原因全部为目标小区回复切换准备失败消息导致切换出准备失败
后台信令跟踪对包头东河彩虹超市-HLHF标准X2口进行跟踪，发现切换准备失败，失败原因值：传输不可用。
查询ENODEB X2接口自建链开关状态，结果显示正常
查询基站的DEVIP配置信息是否正确，结果显示正常
查询基站IPRT是否正确，结果显示正常
查询基站VLANID是否正确，结果显示正常
查询基站SCTPLNK是否正确，结果显示配置正常
查询基站 IPPATH,发现S1接口配置为1条，IPPATH资源有限，所以相邻站点切到该站的成功率很低，通过增加到S1接口的IPPATH到8条（现网标准为8条）后：。
S1-U链路故障导致切换失败案例
S1-U链路故障导致切换失败案例
【摘要】LTE系统内切换包括三种类型：eNodeB内切换、X2接口切换、S1接口切换。
通
过两两小区切换或是接口信令跟踪，可以确定切换失败的目标小区和原因，然后进一步判
断分析。
【关键字】eNodeB内切换 X2接口切换
【故障现象】：
FY-太和-太和线务站-HFMA-436409-53 X2接口切换成功率88%。
【告警信息】：无
【原因分析】：
跟踪其X2接口信令，发现失败的目标站都是436408。
失败出现时间集中，失败原因为传输资源不可用，且均为到
7.191.1.252的SGW。
查询436408站点经常出现用户面承载链路故障告警，并且目标
地址为7.191.1.252的SGW。
初步怀疑为436408站点到SGW的S1-U
链路故障导致传输资源不可用，从而回复切换准备失败。
提取阜阳一个时间段切换入测量统计，发现所有切换入准备失
败都是集中在以下三个站点下的，并且原因都是传输原因。
同一时间，436408到以下不同站点发送了多次切换准备失败的
消息，进一步确认为436408站点S1-U链路问题导致切换准备失败。
【解决方法】：
通知传输处理排查这几个站之间的传输链路隐性问题。
【结论与推广】：
切换失败可以通过两两小区切换分析和信令跟踪两种手段，确定切换失败目标小区，结合报表统计的失败原因或是信令跟踪的失败原因，进一步查找问题所在。
当周围站点都到同一个或是同几个站点切换失败，需具体排查这几个站点的传输链路状态。
上海：关于S1切换失败导致掉话问题分析
关于S1切换失败导致掉话问题分析【问题描述】测试车辆由东林路向盘古路行驶过程中，在盘古路与东林路交汇处出现由于切换失败导致掉话，主要是宝临江_3(PCI=110)向天子湖_1(PCI=72)切换。
如图1-1所示：图1-1 切换失败时的PCI图层【问题分析】通过专题分析结果可以看出ERAB非正常释放之前UE上报大量的测量报告，但是eNodeB并未给予响应。
如图1-2所示：图1-2切换失败点专题分析图查看切换失败前的的专题分析，可以看出，ERAB非正常释放前无线环境非常好，没有模三干扰，eNodeB可以收到测量报告，主要是上报测量报告eNodeB 没有给予回应。
如图1-3所示：图1-3 ERAB非正常释放前的无线环境怀疑是该小区没有配置邻区导致无法切换，查看后台小区邻区关系，确认已经添加邻区，配置无误；查看X2接口是否建立，发现宝临江的并没有与天子湖建立X2接口，按照规定，如果X2接口没有手动建立，系统将会通过S1自建立，跟踪S1接口信令查看如图1-4所示：图1-4 S1接口截取信令（网管侧）图1-5 Uu接口截取信令（网管侧）图1-6 发起测量报告截图由于M2000系统采集时间与实际的时间不匹配，但不影响无线功能。
由上图可以看到UE上报测量报告Probe测试的时间为13:56:44（图1-6），网管上采集到Uu接口的测量报告时间为10:11:45（图1-5），对应S1接口信令（图1-4）的采集时间，发现UE上报测量报告后，检测到没有配置到天子湖的X2链路。
基站立即进行S1接口切换请求并申请X2链路建立（如图1-4）。
这时应该核心网的MME进行与目标基站的X2链路建立。
但是在申请X2链路10s后，MME返回S1接口切换准备失败。
如图（1-7）所示：在等待MME回复切换响应期间，UE不断上报测量报告，eNodeB收到MME切换准备失败信令后，立即再次发送切换请求，但是过了10s后，又返回切换准备失败如图：图1-8 S1切换失败返回信令这时eNodeB继续上报S1切换信令，但是由于无线环境已经很恶劣，导致掉线，所以eNodeB向MME发送S1AP_UE_CONTEXT_REL_CMD来请求释放。
电联共享站点无法进行S1切换以及回落的问题
关于新建电联共享站点无法进行S1切换以及回落的问题关键字：电联共享、S1切换回落异常、SCTP对端、MME地址摘要：4G电联共享新建站，对基站进行测试时发现手机无法进行S1切换和回落，通过排查和处理，在核心网测进行跟踪发现SCTP对端S1地址配置错误。
经过修改SCTP 对端S1地址，再次测试，基站切换和回落都已正常。
案例正文：1、背景河北xx市xx站点电联共享新建基站，此共享站为电信承建，共享给联通，联通侧需要对基站进行业务测试。
2、问题、事件描述在测试过程中，手机可以正常接入网络，呼叫和上网等测试都正常，但是在进行回落和切换测试时却无法正常切换和回落。
3、分析与对策（1）查询现网告警，存在用户面承载链路异常告警，业务类型为S1。
（2）排查基站小区故障告警，邻区关系配置问题原因。
通过查询现网小区故障告警，与工参比较邻区配置发现并没有什么异常情况。
（3）排查基站数据配置是否存在错误：通过与MML脚本核对，发现未配置X2，S1切换流程与X2切换类似，只不过所有的站间交互信令及数据转发都需要通过S1口到核心网进行转发，时延比X2口略大。
eNodeB间切换一般都要通过X2接口进行，但当如下条件中的任何一个成立时则会触发S1接口的eNodeB间切换：（1）源eNodeB和目标eNodeB之间不存在X2接口；（2）源eNodeB尝试通过X2接口切换，但被目标eNodeB拒绝。
由于未配置X2接口导致在切换时全部为S1切换，但是S1接口也未切换成功，因此怀疑在电联共享情况下切换是否必须配置X2链路。
因此加载了X2链路重新进行测试，发现S1链路依旧不能进行切换。
（3）为了定位S1链路故障位置，在网管侧进行了信令跟踪。
跟踪S1信令，对S1AP_HANDOVER_PREPARATION_FAIL 原因进行分析，从跟踪站点情况看，切换失败原因值为“ho-failure-in-target-EPC-eNB-or-target-system(6)"。
定时器原因导致的S1口切出成功率低问题处理-浙江
定时器原因导致的S1口切出成功率低问题1 问题描述在处理切换成功率低的TOPN小区时，发现某小区切出成功率偏低，在90%左右。
而导致切换失败的原因基本上都为“eNb间S1口小区间同频切出执行失败，其他原因”。
2 问题分析排查查看问题站点假山新村的小区对切换统计，看到S1口的切出失败都发生在与银海苑站点之间，而银海苑站点是半个月前新开站点。
那么问题极可能就出在银海苑站点上。
再查看到银海苑站点的所有小区对切换统计（一个月），同频切出成功率低的小区都存在相同的现象。
进行后台网管的统一信令跟踪，提取切换源侧的后台信令，看到了如下切换失败：从信令上可以看到，eNodeB 下发切换命令后很快就收到了MME 的上下文释放命令Ue context release command ，原因为release_due_to_eutran_generated_reason 。
从内部模块间的信令也看不出有价值的信息。
由于切出成功率在90%，那么10%的失败可不可能是由于接入失败导致的呢?所以做了调整Prach 接入起始RB 位置调整的测试，发现修改为手动配置并且起始RB 从高位开始后，S1口切换失败返回源侧的次数增加了，而other 原因的次数并没有减少，说明可能不是接入导致的切换失败。
（事后想想，没必要做此操作。
下发切换命令后很快就收到MME 的消息，说明在目标侧的接入应该是没问题的。
）同时在后台跟踪源侧小区和目标侧小区的信令，通过handover required 和handover request 消息中的Source_Identity 串联起完整的切换信令，半个小时内看到两次如下场景的切换，在目标侧的信令是这样的：eNodeB 在给MME 发送切换成功handover notify 消息的同时，还发送了Ue Context Release Request 消息，携带原因为User_Inactivity 。
看来问题可能就出在User_Iactivity 的定时器上啦，可到底是怎么回事呢？查看目标侧银海苑站点及周边站点的UE 常量和定时器中的控制面的User_Iactivity 定时器和基于移动性的UE 未激活定时器配置。
精品案例_联通主建的共享站点不切换导致S1切换失败案例
联通主建的共享站点不切换导致S1切换失败案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (4)四、经验总结 (5)联通主建的共享站点不切换导致S1切换失败案例【摘要】4G异常小区日常检查时，发现阜阳出现大量的S1切换失败，结合网管排查确定原因为联通主建的共享站点不切换导致S1切换失败导致，从网管上禁止切换后S1切换恢复正常。
【关键字】S1切换共享站点【业务类别】优化方法一、问题描述在日常4G异常小区检查时，发现阜阳出现大量的S1切换失败，结合网管排查确定原因为联通主建的共享站点不切换导致S1切换失败导致。
二、分析过程在4G异常小区日常处理中，S1切换失败是一种常见的切换失败，通常的原因是与联通共建共享的干扰导致的切换失败与光缆故障导致的周边小区切换失败以及公安监控等原因。
联通基站配置网络号（PLMN）分为基站级和小区级，其中联通基站级和小区级配置的PLMN均为46001，开通电信共享小区的PLMN配置为46011，导致小区级PLMN 与基站级PLMN不一致，因此S1切换全部失败。
1、排查基站侧是否存在故障,排查未发现存在影响S1切换的故障2、首先找出失败小区，为FY-临泉-高堰集-HFTA-172668-180。
核查告警小区的两两切换，如下:3、由上可知，172668-181切换目标小区为168560-138，切换成功率为0，经核查发现168560-138为联通主建的电信小区李善寨基站（共建共享小区），详情如下：华为U2000跟踪S1接口信令发现，切换失败发生在准备阶段，失败原因值均为：unknown-targetID，目标小区无法识别：三、解决措施U2000网管设置禁止向46011站点切换，并手动添加460-01邻区关系，最后添加46001到46011的PLMN映射来解决。
四、经验总结遇到此类站点状态正常、无告警的情况，需从基站工作状态，历史告警日志，邻区关系等方面考虑，一步一步排查出具体原因，可以通过基站网管来快速定位问题。
南京S1切换失败问题分析
南京S1切换失败问题分析南京核心网统计的S1切换成功率非常低下，只有13%。
其最主要的原因是切出准备成功率很低。
大量的HO Required消息发送到MME以后，MME 具体流程如下：注：一般情况下，MME发送HO Preparation Failure（UnknownTargetID）是由于目标ENB未在MME中登陆或在MME中状态为不可用所致。
在南京，我们经常可以看到一些基站脱管、S1/X2传输断的告警，其中一部分和基站断电有关，另一部分与基站传输断有关。
当基站传输断时，基站仍然在发射，其周边小区中的UE 仍然可以测量到其信号，并请求向其发生切换。
此时周边小区到问题站点的X2是不通的，所以会选择S1上发送HO Request，但是MME会发现到问题站点的S1也不通，所以会回送HO Preparation Failure（UnknownTargetID）导致周边小区的切出准备失败。
如果问题站点是断电原因导致的基站脱管、S1/X2传输断的话，那么它不会发射，所以一般也不会导致周边的小区向它的切换请求和切换失败。
可见传输原因是引起目标eNB在MME中不可用、并导致S1切换准备失败的主要原因。
由于S1切换是在X2不通的情况下才会发生，如果由于传输原因导致X2不通的情况下S1基本也是不通的，所以S1的切换成功率一般会比较低下。
而切换准备失败后的重试又放大了这个问题的影响。
先举一个案例：河北大街基站一直处于脱管状态，当前告警如下。
分析其周边的河北村北基站的CallTrace，发现其向河北大街基站的S1 HO Required都收到MME的HO Preparation Failure（UnkownTargetID）导致失败。
两个小区的地理位置如下图所示。
为了全网性分析S1切换准备失败与S1断的相关性，我们进行了如下分析。
我们在现网告警中选择“ReachabilityProblem”和“MME Access Down”作为S1断的告警（其中前者还有可能是基站断电导致的，如果是断电的话就不会导致周边小区切换准备失败了），我们统计了9月9日全网中出现过该告警、或现网中仍然存在该告警、或现网中脱管的小区作为S1断的小区；将9月9日S1切换准备失败率高于30%且S1切换准备失败次数高于10次的小区作为S1切换准备失败高的小区，将它们投射到MapInfo图上去。
S1链路拥塞导致切换入失败案例
S1链路拥塞导致切换入失败案例
案例上报省份：河北案例上报人：刘红星、叶振洋
一、关键词：
S1链路拥塞，锚点，切换
二、案例分类
1.问题分类：切换类
2.手段分类：参数调整
三、优化背景
5G站点开通过程中核心网升级改造，锚点站的S1需要进行配合调测。
四、问题现象
4G网络指标日常监控过程中发现XAROC0797容城四站-HFH-1切换入指标明显出现异常，而切换出指标无明显波动，由99.9%恶化至40%。
五、原因分析
XAROC0797容城四站-HFH-1小区04/21/2019 13:00:00切换成功率为96.37%，其他时间段都在98.5%以上，从基站升级到现在，未出现切换出指标明显异常波动。
2.1核查基站状态无明显异常，无告警。
2.2通过对该站数据进行核查，该站共配置8条S1链路，该站为5G站点的锚点，由于5G调测，进行核心网升级改造，将其中的6条S1链路闭塞，导致出现链路拥塞，切换入失败。
六、解决方案
对LTE基站配置的S1链路需配置8条，如果S1链路配置少于5条将会出现S1链路传输资源不足导致S1切换失败。
七、效果评估
将XAROC0797容城四站-HFH站点的S1链路全部恢复正常，eNodeB间模式内切换入准备失败次数由4000次左右降至0次，指标恢复正常。
八、基于案例提炼的方法、流程及评估标准建议
5G站点单验开通后，要观察4/5G指标，仿真5G站点的开通对现网4G锚点站产生较大影响。
华为基站S1-MME链路漏配导致VOLTE用户向其切换失败低处理案例
准备阶段失败，提取邻区级切换指标，只有 BHYHFuChengZhenHaiLuCunLTE-ELH-1 小区与与北海铁山港福成镇海
本文档仅用于通信从业者学习交流 4. 查询现网 S1-MME 信息，在现网下配置的 S1-MME 为三条，分别为 4600-900-12；4600-900-48；4600-900-60，
源小区配置如下：
本文档仅用于通信从业者学习交流
本文档仅用于通信从业者学习交流 目标小区配置如下：
本文档仅用于通信从业者学习交流
本文档仅用于通信从业者学习交流
陆村 2-HLH-3 小区邻区间存在切换准备失败，判断为该 TOP 邻区对 导致 BHYHFuChengZhenHaiLuCunLTE-ELH-1 小区 VoLTE 切换指标差。 2. 通过排查源小区 BHYHFuChengZhenHaiLuCunLTE-ELH-1 和目标小区北海铁山港福成镇海陆村 2-HLH-3 告警、干扰。 发 现 目 标 小 区 北 海 铁 山 港 福 成 镇 海 陆 村 2-HLH-3 ， 无 告 警 ， 干 扰 值 正 常 。 源 小 区 BHYHFuChengZhenHaiLu CunLTE-ELH-1 存在天线校准告警，但源小区与其它目标小区切换无影响，初步排除告警导致。 3. 查看 CTR，发现源小区发送“HandoverRequest”后，目标小区回了“HandoverPreparationFailure”携带原因值 为“unknown-MME-Code”；对比正常切换信令发现，当“HandoverRequest”携带的 GUMMEID 为“0064F00038430” 时，目标小区全部响应失败；而携带“0064F0003840c”“0064F000384303c”时，目标小区全部响应成功，初步 判断为目标小区与源小区 MME code 不一致导致。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
V .. . ..基于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上下文，包括承载的信息，安全上下文等。
目标eNodeB 也回送Handover Request Ack消息给目标MME，其中包含EPS承载建立结果的信息。
对于每个成功建立的EPS承载，其信息包括下行数据在目标eNodeB 侧的GTP－U的TEID值。
➢目标MME发送Create Indirect Data Forwarding Tunnel Request消息给目标SGW，将上述数据转发通道的TEID值通知目标SGW，转发通道的从目标SGW到目标eNodeB的部分可以建立。
➢目标MME发送Forward Relocation Response消息给源MME，将EPS Bearers Setup Result 通知源MME。
在Indirect Tunnel的情况下，转发通道在目标SGW侧的地址和TEID值也会在此消息中通知源MME。
在Indirect Tunnel的情况下，源MME发送Create Indirect DataForwarding Tunnel Request消息给源SGW，转发通道在目标SGW侧的地址和TEID值通知源SGW。
➢源MME发送Handover Command消息给源eNodeB，将目标eNodeB分配的需要转发的EPS Bearers的TEID 值和目标eNodeB的地址通知源eNodeB。
➢源eNodeB发送eNB Status Transfer消息，此消息经源MME，目标MME，最终到达目标eNodeB。
此消息将无损切换的EPS Bearer的PDCP的状态通知目标eNodeB。
源eNodeB此时可以经过Indirect Data Forwarding Tunnel 将下行数据转发给目标eNodeB。
➢UE与目标eNodeB建立上，下行同步后，发送Handover Confirm消息给目标eNodeB。
目标eNodeB发送Handover Notify消息给目标MME。
➢目标MME发送Forward Relocation Complete Notification消息给源MME。
源MME回应Forward Relocation Complete Acknowledge 消息。
目标MME 发送Modify Bearer Request消息给目标SGW。
➢目标SGW分配下行EPS Bearer在SGW的TEID值，发送Modify Bearer Request消息给PGW，这样切换后的下行数据通道在PGW到目标SGW之间的部分建立了起来。
这样整个的PGW到目标eNodeB之间的下行通道就建立完毕。
➢目标SGW收到PGW的回应后，上行通道在SGW到PGW的部分可以建立，目标SGW返回Modify Bearer Response 消息给目标MME。
➢UE可以触发相应的TAU的过程，随后的步骤中，源MME和目标MME将触发相应的资源释放过程。
/showpic.html -blogid=673b30dd0100je8b&url=/orignal/673b30ddt8962fe203ab3三、S1口切换失败分析3.1、S1口切换成功率统计09月24日全天时段S1_HO成功率的趋势，在切换请求(HO Required)次数较少的情况下，切换成功率上升。
相反，当白天忙时切换请求次数增多时，切换成功率下降。
（以下分析涉及到的数据均采集9月24日全天统计）S1_HO切换成功率与切换请求数量存在反比关系，可能与网络容量或干扰，隐性故障等原因有关。
3.2、S1口切换失败分析在源eNodeB和源MME之间的S1接口切换失败消息有HO Cancel和HO Prepare Fail，在目标eNodeB和目标MME之间的S1接口切换失败消息只有HO Failure。
有一种情况是，即使返回Handover Request Acknowledge时，但在没有默认承载建立信息表时也会导致目标MME清除UE在目标MME和eNodeB 所预留的信道资源。
统计09月24日全天切换失败消息，目标S1接口失败消息HO Failure会比源S1接口HO Prepare Fail失败消息少，因为有可能切换请求确认后，但由于默认承载而导致失败。
S1接口FAILURE_MSG COUNT 失败占比源S1接口HO Cancel 77045 0.08%源S1接口HO Prepare Fail 178645 0.36%目标S1接口HO Failure 64542 0.13%以下为S1接口消息占比的饼图：3.3、S1口HO Prepare Fail原因分析出现HO Prepare Fail切换的触发原因，主要触发原因为无线原因正常切换和S1接口间切换触发。
HO_CAUSE COUNT CAUSE_RATE cell-not-available 3 0.00% handover-desirable-for-radio-reason 92324 51.68% s1-intra-system-handover-triggered 86318 48.32% HO Prepare Fail切换消息的失败原因值分布分析，其中unknown-targetID 原因占比达32.08%，其次为“no-radio-resources-available-in-target-cell”原因占比达18.46%。
原因值分析：Unknown-TargetID：在用户发起切换请请求Handover Required消息，其中Handover Type在此时是intra-LTE，TargetID包含Target Cell ID和Target TAI 两部分，源MME可以根据目标TAI来选定合适的目标MME。
当网络对用户请求的目标CELLID和TAI无法识别时，返回此失败原因值。
No-Radio-Resources-Available-In-Target-Cell：当用户通过源MME向目标MME请求无线信道资源时，小区存在无线资源不足或拥塞时，网络返回此失败原因值。
以下为HO Prepare Fail切换消息失败原因值占比的条形图：3.4、S1口HO Prepare Fail维度分析能过以上切换失败的FAILURE_CAUSE可以定位到小区级和TAC级的问题，以下通过小区维度分析“no-radio-resources-available-in-target-cell”失败值，可以发现大部分切换失败聚类在小区级别上。
FAILURE_M SG FAILURE_CAUSEORIGIN_CI->TARGET_CI失败出现的次数HO PrepareFail no-radio-resources-available-in-target-cell43447309->43424780 1078544663565->43424780 153845022997->43424780 81244463884->44494348 49144494348->44463884 41644494349->44463884 40243447309->43424781 375附件为“no-radio-resources-available-in-target-cell”切换失败原因值小区表：no-radio-resources-available-in-targe对“Unknown-TargetID”切换失败原因值进行小区维度分析，以下为TOP10小区。
因为该切换失败原因值（TargetID）包括了目标CI的因素，还有目标TAC 的因素影响。
对“Unknown-TargetID”切换失败原因值进行TAC维度分析：9427 68742279 6759442 59642255 5849484 153 由于用户在发起切换请求时，附带的信息有TargetID包含Target Cell ID和Target TAI两部分，源MME可以根据目标TAI（TAI= MCC + MNC +TAC）来选定合适的目标MME。
附件为“unknown-targetID”切换失败原因值小区表：unknown-targetID.xlsx以下为HO Prepare Fail切换失败返回unknown-targetID原因值截图：分析“unknown-targetID”切换失败的原因，有三种可能情况：➢用户切换请求的targetID (eNodeBID、TAI、CELLID)目标小区不存在（可能存在基站断链，基站板卡硬件故障）。
➢用户切换请求的targetID (eNodeBID、TAI、CELLID)在现网中出现重复配置，冗余数据。
➢目标小区在源小区的邻区信息表，与现网小区的信息不一致，导致上报的targetID无法被网络识别。