【VoLTE案例】UE能力处理策略不当引起eSRVCC失败
【问题描述】
进行eSRVCC测试时发现VoLTE语音业务切换到2G失败，引起掉话。
【问题分析】
1、为方便定位问题，测试过程中，EPC侧一直跟踪UE信令，通过EPC侧的信令中MME-UE-SIAP-ID（本次失败时为100727514）。
2、解析相应时间段内的CDL日志，通过ERA建立统计，找到该次过程MME-UE-S1AP-ID对应的CellID（2）和CellUeIndex（137），用于过滤该用户的信令。
3、通过CDL由RRC释放消息进行回溯分析，UE上报了B2事件，RRM判决为已知小区，说明GSM邻区参数等配置正常。AP-L3发起了HandoverRequired请求（即eSRVCC）过程，说明eSRVCC参数配置正常，但是AP-L3反馈为HANDOVER_PRE_FAIL，即切换准备失败。
4、通过上述分析，可以确定此次eSRVCC异常为基站侧准备失败引起的，且不是由于eSRVCC相关参数配置有误引起，很可能是eNodeB内部处理异常。
5、继续通过CDL分析此次接入过程，可以看到在初始上下文建立完成之后，eNodeB给UE下发了一次UE能力查询，并将UE的反馈结果转发给EPC。
1）初始上下文建立请求消息中携带了UE能力，包含了EUTRA、GERAN-CS和GERAN-PS。
2）初始上下文建立完成之后，eNodeB给UE下发的UE能力信息查询中，要求查询EUTRA和UTRA的能力，其他信令为一般的信令，无明显异常。
6、经过分析，最终确认为eNodeB在处理UE能力信息时采用了覆盖的方式，即初始上下文建立请求中携带了EUTRA、GERAN-CS、GERAN-PS能力信息，后面一次UE能力信息查询了EUTRA和UTRA能力信息，将前面存储的UE能力信息覆盖了，导致基站认为该UE没有GERAN-CS和GERAN-PS能力，当然也就认为该UE不支持eSRVCC，因此eSRVCC切换失败。
【问题定位】
eNodeB在处理UE能力信息时，当UE能力未携带全234G能力时，采用覆盖方式进行处理，将前面存储的UE能力信息覆盖了，导致基站认为该UE不支持eSRVCC，因此eSRVCC切换失败。通过将覆盖方式修改为合并方式，即可完整保存UE能力信息，从而规避该问题。