大唐eSRVCC概率性失败-

问题描述：VoLTE测试期间，在运营中心(610版本)地下车库进行eSRVCC测试，发现切换到2G失败，终端显示到EDGE，而非GSM，然后掉话。

问题分析：测试人员为IMS工程师，没有无线侧的测试软件和测试终端，为方便定位问题，测试过程中，EPC侧一直跟踪UE信令，通过EPC侧的信令中MME-UE-SIAP-ID(本次失败时为100727514)。

解析相应时间段内的CDL日志，通过ERA建立统计，找到该次过程MME-UE-S1AP-ID对应的CellID（2）和CellUeIndex（137），用于过滤该用户的信令。

通过CDL由RRC释放消息往上分析：UE上报了B2事件，RRM判决为已知小区，说明GSM邻区参数等配置正常。AP–L3发起了HandoverRequired请求(即eSRVCC)过程，说明eSRVCC参数配置正常，但是AP–L3反馈为HANDOVER_PRE_FAIL，即切换准备失败。

通过上述分析，可以确定此次eSRVCC异常为基站侧准备失败引起的，且不是由于eSRVCC相关参数配置有误引起，很可能是ENB内部处理异常，再继续通过CDL往上分析此次接入过程。可以看到在初始上下文建立完成之后，ENB给UE下发了一次UE能力查询，并将UE的反馈结果转发给EPC。

初始上下文建立请求消息中携带了UE能力，包含了EUTRA、GERAN-CS和GERAN-PS

初始上下文建立完成之后，ENB给UE下发的UE能力信息查询中，要求查询EUTRA和UTRA的能力，此外，其他信令为一般的信令，无明显异常。

经过研发分析，最终确认为ENB在处理UE能力信息时采用了覆盖的方式，即初始上下文建立请求中携带了EUTRA、GERAN-CS、GERAN-PS能力信息，后面一次UE能力信息查询了EUTRA和UTRA能力信息，将前面存储的UE能力信息覆盖了，导致基站认为该UE没有GERAN-CS和GERAN-PS能力，当然也就认为该UE不支持eSRVCC，因此eSRVCC切换失败。

问题原因：

ENB在处理UE能力信息时，当UE能力未携带全234G能力时，ENB采用了覆盖方式引起的，所以通过修改为合并的方式，即可完整保存UE能力信息，即可规避该问题。在实验室构造测试环境对修改后的版本测试，测试通过，并将该方案合并入620版本。

问题解决：

修改相应的处理机制，升级基站版本，此问题在620版本解决。

本文整理自网络，文章版权归原作者所有，如有侵权，请联系我们进行删除。小编微信（gprshome201101）