定时器原因导致的S1口切出成功率低问题
1 问题描述
在处理切换成功率低的TOPN小区时，发现某小区切出成功率偏低，在90%左右。而导致切换失败的原因基本上都为“eNb间S1口小区间同频切出执行失败，其他原因”。
2 问题分析排查
查看问题站点假山新村的小区对切换统计，看到S1口的切出失败都发生在与银海苑站点之间，而银海苑站点是半个月前新开站点。那么问题极可能就出在银海苑站点上。再查看到银海苑站点的所有小区对切换统计（一个月），同频切出成功率低的小区都存在相同的现象。
进行后台网管的统一信令跟踪，提取切换源侧的后台信令，看到了如下切换失败：
从信令上可以看到，eNodeB 下发切换命令后很快就收到了MME 的上下文释放命令Ue context relea command ，原因为relea_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 Relea Request 消息，携带原因为Ur_Inactivity 。看来问题可能就出在Ur_Iactivity 的定时器上啦，可到底是怎么回事呢？
查看目标侧银海苑站点及周边站点的UE 常量和定时器中的控制面的Ur_Iactivity 定时器和基于移动性的UE 未激活定时器配置。银海苑站点配置的时长为默认值10s 和5s
，而其他周
边站点配置的时长为20s/20s。那么是由于周边站点配置的两个定时器时长相同导致的，还是由于目标侧银海苑站点配置的定时器时长相比周边站点太短导致的呢？我们修改参数进行验证：六角帽
（1）修改效实中学站点的两个定时器时长从20s/20s为20s/15s（黄色为修改后），发现似乎有改善，但是切换成功率提升不多，且导致切出失败的主要原因还是other。
（2）修改目标侧银海苑站点控制面的Ur_Iactivity定时器时长为不同值再进行测试，证明确实是由于目标侧站点的控制面的Ur_Iactivity定时器比周边源侧站点的时长小导致的。
3 问题原因总结小学教资面试
秘书制服
在Handover required/Handover request消息中，通过rrm_Config这个IE来告知目标侧用户在源侧的Ur_Inactivity时长。rrm_ConfigPrent=1，即表示携带了；否则即没有携带。英文句子唯美简短
ue_InactiveTime = 6 : RRM_Config_ue_InactiveTime_Root_s15，即当前定时器已经过了15s。这个里面携带的值只能是网管上可以配置的值，如果当前过了18s，那么也只能指示为15s。
如果用户在切换时，依然有数据传输，没有进入不活动状态，即Ur_Inactivity定时器未启动，那么在Handover required/Handover request消息中也是不携带rrm_Config这个IE的。
我们在全局业务开关中有Ur_Inactivity使能开关，但此开关是总开关，切不可随便关闭，否则可能导致UE无数据传输时我们也不释放承载，变为空闲态。
为什么切换走X2口后，切换成功率就正常了呢？那是因为X2的切换，源侧收到的上下文释放消息后，不检查里面携带的原因值；而且消息里也不携带任何原因值。但S1口切换，是需要判断上下文释放消息中携带的原因为handover_successful时才统计切换成功的。因此此问题不影响用户真实的切换，只影响性能统计结果。
协议36.331中有关于rrm_Config的介绍。
崇高的敬意
4 问题处理古代朝代
排查全网控制面的Ur_Iactivity定时器和基于移动性的UE未激活定时器，保证全网关于此两个定时器时长配置相同。同时也修改基于移动性的UE未激活定时器时长小于控制面的Ur_Iactivity定时器时长。
切换尽量走X2，开启全网的X2自建立自删除开关。
网管上X2的SCTP链路，使用闭塞功能无效，切换依然可以正常走X2切换；需要使用不使能来使某个X2失效。
此问题虽然是eNodeB定时器设置不同导致的问题，但核心网MME对于此种场景的处理，可能也存在不合适的地方。
