错配相同扰码的邻区导致小区掉话率升高问题分析.doc

案例名称： 错配相同扰码的邻区导致小区掉话率升高问题分析 现象描述： 亚太某运营商 RNC404的13439小区在25.09.2007日起掉话率突然大幅度攀升,查看该小区的RTWP正常，无告警，RF无线环境没有任何变化。 原因分析： 图1 分析RNC404的小区13439的CHR打印，大部分掉话都是SRB复位造成 图2 图3 对掉话CHR记录进行逐个分析，发现大部分掉话时候target激活集中都存在RNC504的11288小区。 图4 但是从mapinfo上查到，cell 11288距离cell 13439非常远,理论上不应该能加入激活集。 相隔这么远的距离为什么会被加入邻区呢?于是查看脚本,并想确认这个邻区关系是否配置正确,于是有了一个重要的的发现.13439到11288的邻区关系以前是不存在的，是25日白天添加的,而掉话率的突变也是在25日，并于26日达到了高峰。在25日这天现场是根据Nastar的1A检测集邻区核查功能来添加这条邻区的。 由此看来有可能就是因为添加了这条邻区导致掉话率突然攀升，但是为什么添加了一个距离比较远的邻区会导致掉话呢？联想到Nastar的1A检测集核查功能是根据UE的检测集扰码上报次数来统计邻区漏配信用度，问题很可能出现和扰码有关。 于是查看图2，图3的激活集中小区41018，50570的邻区扰码。结果如下： 图6 图7 查看以上截图中的激活集中的小区 41018和50570的邻区扰码. 果然他们的邻区都有和小区11288(PSC=51)扰码相同的小区41678。 图8 查看小区41678的位置，发现该小区距离13439很近，约600m.，而且cell13439和cell41678之间没有邻区关系。问题得到定位。这是一个典型的错配邻区导致PSC冲突掉话问题。具体掉话过程是： 1 RNC根据错误配置的邻区列表下发测量控制让UE测量11288小区（PSC＝51）。 2 UE检测到了PSC＝51的扰码（cellID=41678）并上报给RNC。 3 RNC根据UE上报的PSC＝51和邻区列表以及信号质量，索引出PSC＝51的扰码信号质量满足加入激活集门限，于是下发激活集中更新给UE，让UE同步PSC＝51的小区。 4 UE于是会同步小区41678，而SRNC是给RNC504的cell11288下发的资源准备，所以UE是不可能和cell11288同步上的，最后无线链路同步失败，当激活集小区信号质量进一步恶化的情况下，就会发生掉话。 图9 处理过程： 图10 根据分析结果，于27日凌晨删除了13439到11288小区的邻区关系，考虑到目前RNC版本具有邻区合并功能，且13439到41678小区之间已经有两个站点，就不再添加两者之间的邻区关系。删除邻区之后掉话率恢复正常（如图10） 建议与总结： 1 该案例是一个典型的典型的错配邻区导致PSC冲突掉话问题。和香港案例集中《扰码相同造成错加邻区而导致的掉话案例》类似，但是分析问题的思路确不一样，香港的案例是从路测信令跟踪数据分析入手，而本案例是从CHR和脚本核查分析入手，本案例分析定位问题方法能节省路测时间，减少车辆人力资源消耗，有助于问题的快速定位解决。 2 目前Nasar1A检测集核查邻区功能有点问题，根据经纬度和PSC匹配得到CELL ID这个功能有问题，有可能匹配得到一个相同扰码但是距离很远的一个小区，并建议添加邻区。针对这种情况，对Nastar给出的检测集核查结果，需要人工在mapinfo上进行核查。 3 咨询研发，研发提到根据现有的邻区合并算法，对于激活集中小区的所有邻区进行合并时候，如果发现激活中小区的邻区有相同扰码的情况，那么RNC在下发测量控制时候就会同时丢失这两个小区，不在测量控制中下发，这也有可能造成掉话。本案例中的掉话率升高也可能和这个有关，但是现场没有跟踪到出现这种情况的信令，CHR中也没有找到，所以不在本案例中列出。