基站经纬度配置错误导致的呼叫失败-特殊情况.doc

基站经纬度配置错误导致的呼叫失败 问题类型：呼叫失败 问题原因：BSC的经纬度同步功能存在问题，导致AE型基站经纬度信息超出正常范围； 排查人员：周家辉，徐永军 地 点：摩洛哥WANA网络BSC1下部分AE型基站 时 间：2007年8月6日 提交人员：徐永军 审核人员： 问题描述 8月5日晚，局方反映LBI地区用户呼叫困难，从话务统计和业务观察来看该地区基站的呼叫成功率很高，但是话务量有明显降低。后台无任何严重告警。 问题分析 移动台在读取同步信道后，必须收集到一整套配置消息后才能对系统进行操作，这其中包含了所有必须的配置参数。这些配置消息为：系统参数消息，接入参数消息，CDMA信道列表消息，邻区列表消息（扩展邻区列表消息），扩展系统参数消息。 然后移动台就可以进行起呼，呼叫响应和登记等操作了。该案例中就是由于移动台抛弃了出现错误的系统参数消息，因此无法进行起呼，呼叫响应和登记等操作。 处理过程 首先我们检查了该区域基站的历史告警，发现无任何严重告警；基站数据观察也显示这些基站的RSSI值也很正常，为-110dBm左右。 由于LBI地区绝大部分基站为单载频基站，话务量较大，存在较多的由于功率资源或CE资源不足导致的呼叫失败，但之前并没有用户投诉。因此我们怀疑用户投诉的呼叫困难是由于资源不足导致的。因此我们对基站作了业务观察，但是发现这些基站的呼叫成功率非常高，只是基站下的起呼次数变少了，且所有呼叫成功的呼叫类型均为分配进入软切换。如下图所示： 然后我们通过话务统计分析发现CAS地区部分基站也存在相同的话务量明显降低的问题：BSC1下很多基站自8月3日凌晨开始出现了话务量明显下降的问题，且这些基站的类型均为AE型基站；BSC2下AE基站不存在此类问题。如下图所示： 通过对这些基站的业务观察发现，这些基站的呼叫成功率也很高,但是呼叫次数比以前下降很多,而且所有成功的呼叫全部都是分配进入软切换,无单独使用本基站信号的呼叫。通过探针观察基站下的实时用户数，发现该基站下通话的用户非常少。 接着我们对这些基站进行了信令跟踪，但是信令跟踪只收到很少的起呼消息，且起呼类型均为分配进入软切换。因此我们怀疑这些AE基站下的手机可能根本无法正常待机。 因此我们怀疑8月3日凌晨BSC1的配置数据可能做过改动，但是我们通过参数检查并未发现任何异常。因此我们决定： 将BSC1的配置数据恢复至8月3日前最近备份的配置数据； 选择离机房较近的CAS-0040基站进行前台信令的采集，并验证BSC1配置数据恢复后该问题是否得到解决； 我们使用CNT对现场情况进行了测试，我们首先选择了一个单导频区域，然后进行手动拨打测试，发现手机一直没有上报主叫消息，这也就是为什么业务观察中无任何失败的原因了；其次我们在切换区域进行拨打测试，发现如果仅仅使用本基站信号是无法进行呼叫的，但如果同时使用邻近基站同时进行起呼时，每次呼叫都能够成功。但是究竟什么原因导致手机不发送起呼消息呢？我们怀疑手机并未进入待机状态。因此我们检查手机是否收到了这些开销消息，但是发现手机的确收到了所有这些开销消息。如下图所示： 最后我们注意到手机的Debug消息中有很多的错误信息“Ignore Sys Params Msg- Range Violation”，说明手机抛弃的系统参数消息，因此手机根本无法进行呼叫操作。如下图所示： 这条消息说明System Parameter Message中的某个参数配置错误，查看系统参数消息发现消息中的GPS经纬度信息超出了正常的范围（经度：取值范围-1296000 ~ 1296000（对应-90 degree ~ 90 degree）；纬度：取值范围-2592000 ~ 2592000（对应-180 degree ~ 180 degree））。如下图所示： 后台通过修改该基站的经纬度至正常范围后，我们选择了几个AE基站进行测试和业务观察，这些基站的呼叫问题已经得到解决。 最终我们定位了GPS经纬度配置错误引起的主要原因为：在使用8.19版本OMC后台的经纬度同步功能（如下图所示）时，虽然AE基站的经经度在诊断测试中是正确的，但实际配置到系统参数中时却出现了转换错误，超出了正常范围。 经验总结 由于BSC后台无任何告警信息，业务观察和话务统计也均没有任何呼叫失败，仅仅依靠后台信令跟踪和业务观察等工具根本无法准确定位此问题；因此我们认为今后遇到此类问题还是应该首先在第一时间到现场进行测试，以更加快速地定位问题。 另一方面，我们可以看到在该问题的处理过程中，Debug消息对我们定位问题起到了重要的作用，这是因为即使系统参数消息中携带的经纬度是错误的，但只要不超出正常范围的话，对呼叫是不会造成任何影响的。