浙江：EnodeB上报PLMN不全导致切换准备失败.docx

杭州电信EnodeB上报PLMN不全导致切换准备失败案例 ---- 浙江公司无线网优中心【问题描述】通过KPI指标查看，杭州电信4月份切换出成功率异常偏低，对小区级指标进行分析发现，83%的切换出失败集中在100个小区左右，全网小区在4500个左右，问题小区相对比较集中，且切换失败原因主要集中在”目标侧准备失败”上：开始时间结束时间系统内同频切换出成功率(百分比)系统内异频切换出成功率(百分比)[FDD]同频切换出失败次数[FDD]异频切换出失败次数2014-04-25 2014-04-26 93.34%62.17%375616932014-04-26 2014-04-27 93.24%62.13%321910832014-04-27 2014-04-28 94.85%60.23%208411212014-04-28 2014-04-29 94.89%64.38%22659192014-04-29 2014-04-30 95.81%84.35%16583922014-04-30 2014-05-01 92.19%73.38%266810822014-05-01 2014-05-02 93.02%64.97均值　93.91%67.37件是一周内小区级切换失败次数较多的小区：【问题分析】1、由于近期2.1G宏站替换为1.8G的站点较多，怀疑替换过程中，邻区关系添加错误，或者存在配置错误的冗余邻区所致。我们对全网的邻区定义进行了检查，发现确实存在部分定义错误的邻区，但优化后观察指标发现，切换成功率没有明显好转，仍然在93%左右。2、随后我们筛选了切换失败次数较多的下沙警官学院(ID:311609,PCI:69)和下沙6号大街和11号大街交叉口(ID:312544,PCI:192)站点，现场进行测试，并让核心网配合进行信令跟踪。现场测试发现，当UE占用下沙6号大街和11号大街交叉口-1小区时，MR上报了下沙警官学院-1小区的较强邻区，但没有进行切换，同时UE一直上报MR，最终发起重建立请求并失败，造成掉线：查看核心网跟踪的IMSI信令，核心网在收到Handover Required后，回复了一条Handover PreparationFailure消息，原因值为ho-failure-in-target-EPC-eNB-or-target-system：经核心网同事查看发现，切换的目标基站下沙警官学院(ID:311609)在EPC上的动态数据库里只关联了一个PLMN：46011，而核心网收到的Handover Required消息中，在selected-TAI字段里，目标小区关联的PLMN是46003，造成核心网认为找不到目标小区：3、由于浙江电信前期放了部分46003的号段，所以要求核心网和无线侧都必须配置双PLMN，即46011+46003，而查看我们基站侧的参数配置，下沙警官学院基站也确实配置了双PLMN，但核心网侧没有生效，原因需要进一步核查：4、根据协议规定，核心网维护的基站的PLMN配置，是基站侧上报的，而基站开通后通过S1口会上报一个S1 SETUP REQUEST消息，携带基站的PLMN配置，核心网也根据收到的该消息进行维护。为了验证我们的基站上报S1 SETUP REQUEST消息时，携带的PLMN是否正确，我们选取了萧山潘水南苑(ID:311767）现场进行抓包验证。将该站点传输断开，等待一段时间后重新连接，发现基站上报了S1 SETUP REQUEST消息，且在broadcastPLMNs字段里携带了46011和46003，说明基站上报的消息是正确的。而核心网维护的站点PLMN不全的原因，可能是由于前期站点调整PLMN配置时没有复位，不会上报S1 SETUP REQUEST消息，造成核心网侧没有更新基站PLMN配置所致。【验证测试】为了验证复位是否能够解决该问题，我们首先对下沙警官学院(ID:311609)进行了网元复位，发现操作后确实切换出准备失败消失：开始时间小区名称邻区关系系统内同频切换出请求次数系统内同频切换出失败次数eNB间S1口小区间同频切换出准备失败次数，目标侧准备失败2014-4-17 下沙6号大街和11号大街交叉口_1(49)311609:494334342014-4-18下沙6号大街和11号大街交叉口_1(49)311609:495948472014-4-19下沙6号大街和11号大街交叉口_1(49)311609:495539392014-4-20下沙6号大街和11号大街交叉口_1(49)311609:498878772014-4-21下沙6号大街和11号大街交叉口_1(49)311609:491071011012014-4-22下沙6号大街和11号大