G侧所加G邻区的RAC值配置错误导致eSRVCC切换成功率低案例.docxVIP

榆林公司4G侧所加2G邻区的RAC值配置错误导致eSRVCC切换成功率低案例 【问题描述】 榆林现卡特区域eSRVCC切换成功率指标较低，只有10%左右，主要原因为部分站点eSRVCC切换成功率较低导致。 榆林卡特全网连续一周eSRVCC切换指标统计如下： 榆林区域总_0 (3512) eSRVCC切换请求次数 eSRVCC切换成功次数 eSRVCC切换成功率 03/20/2016 219 21 9.59% 03/21/2016 271 26 9.59% 03/22/2016 97 18 18.56% 03/23/2016 302 21 6.95% 03/24/2016 281 29 10.32% 03/25/2016 404 20 4.95% 03/26/2016 224 21 9.38% 03/27/2016 354 25 7.06% 典型站点ao751连续一周eSRVCC切换指标统计如下： 日期 eSRVCC切换请求次数 eSRVCC切换成功次数 eSRVCC切换成功率 03/20/2016 9 3 33.33% 03/21/2016 33 1 3.03% 03/22/2016 13 1 7.69% 03/23/2016 77 0 0.00% 03/24/2016 36 0 0.00% 03/25/2016 83 0 0.00% 03/26/2016 69 2 2.90% 03/27/2016 0 0 Nerr 【问题分析】 现场跟踪典型站点ao751的calltrace发现：ao751向2G侧发起了切换请求后，但很快MME向基站侧回复了切换准备失败的消息，失败的原因为未知的目标小区（unknown-targetID），发起请求的信令截图如下： MME回复切换准备失败的信令截图如下： 现场进行CDS验证时，也只上报B2事件，但是没有执行切换的Handover Command消息，导致无法切换至2G。现场CDS信令截图如下： eSRVCC完整信令流程如下： 根据空口的信令流程来看，只是说明无线环境质量达到了B2门限，也就是说上述流程中的第一步满足条件，从空口信令以及以上eSRVCC流程来看，不切换有如下可能原因： 1、由于基站未开启eSRVCC测量开关等原因，eNB 没有收到MeasurementReport（B2）导致切换流程无法继续。 2、4-2G邻区问题，通过UE上报的频点信息以及eNB内部的2G邻区信息（LAC RAC CI），MME或者MSC无法找到对应2G小区导致失败。 3、eNB收到MeasurementReport（B2）后，没有向MME发起handover Required消息。 4、MME收到handover Required之后，没有向MSC交互后续信息。 5、MME和MSC之间信息交互失败。 所以，不切换的原因可能是基站eSRVCC相关的开关测量未正确配置导致，或者是上端核心网参数配置错误导致。后台对该站的eSRVCC相关参数再次核查，开关都已打开，测量也已配置，但在核查2G邻区信息时发现，部分2G邻区里的RAC值与2G现网的RAC值不一致（榆林卡特区域2G的RAC值为3，华为区域的2GRAC值为0）。查看所跟踪calltrace信令，终端发起eSRVCC切换请求消息中上报的的目标2G RAC值为0（2G小区为36969_45426）,而36969_45426实际的RAC值为3。怀疑为RAC配置错误导致eSRCCC切换失败。Calltrace中切换请求上报目标2G信息截图如下： 【问题解决】 为了验证2G邻区RAC值对eSRVCC的影响，后台将ao751的2G邻区36969_45426的RAC值由0修改为3，修改RAC后，现场验证可以正常进行eSRVCC切换(连续验证10次均切换成功)。修改RAC后，现场验证可正常切换的信令截图如下： 修改RAC后，后台跟踪相应时间段的calltrace,calltrace中可正常切换的信令截图如下： 现场于3月29日对全网2G邻区的RAC值进行规整，规整后，全网eSRVCC切换指标有明显提升，修改前后，全网eSRVCC切换指标统计如下： 榆林区域总_0 (3512) eSRVCC切换请求次数 eSRVCC切换成功次数 eSRVCC切换成功率 03/20/2016 219 21 9.59% 03/21/2016 271 26 9.59% 03/22/2016 97 18 18.56% 03/23/2016 302 21 6.95% 03/24/2016 281 29 10.32% 03/25/2016 404 20 4.95% 03/26/2016 224 21 9.38% 03/27/2016 354 25 7.06% 03/28/2016 224 30 13.3