PN_INC不同引起的切换失败.docVIP

PAGE 第 PAGE 1 页 PN_INC不同引起的切换失败 问题类型：PN_INC不同引起的切换失败 问题原因：PN_INC不同 排查人员：董儒山、何剑锋、刘海 地 点：河北石家庄 时 间：200 提交人员：刘海 审核人员： 问题描述 2009年7月9号，石家庄对全市的PN进行修改，由原来的PN_INC=4修改为PN_INC=3；保定维持PN_INC=4不变；石家庄与保定交界的第一层基站PN全部改为12的倍数；保定与石家庄使用IBBE互联；修改当晚，派出路测队伍进行边界切换验证测试，结果如下： 1)、在保定定州顺利起呼 2）、往石家庄方向行进，顺利进行切换 如下图，切换前激活集只有保定定州的PN，切换后激活集有保定定州及石家庄新乐的PN； 图表 SEQ 图表 \* ARABIC 1 切换前激活集 图表 SEQ 图表 \* ARABIC 2 切换后激活集 到此，好像一切都进行得很顺利，似乎并无不妥；别着急，让我们再往前走一段； 3）、切换失败 路测人员继续往前走，穿越石家庄第一层边界，此时，手机检测到更强的非12倍数的PN，上报PSMM，却一直得不到基站回复的切换指示；为什么呢？难道是邻区漏配造成的？ 问题分析 首先对新乐田村铺的邻区进行检查，发现邻区并没有漏配。 邻区没有漏配，那还有什么原因会造成手机收不到BSC下发的切换指示呢？1）、上行有干扰，导致基站侧收不到手机发过去的PSMM消息；2）、下行有干扰，导致手机收不到BSC下发的切换指示；但是，手机每次发PSMM消息，基站侧都有确认消息，以上两种可能都可以排除。 还有一种可能，就是BSC判决出了问题。 让我们回顾一下切换的处理过程： 1）、手机搜索到新的PN，上报PSMM，包含PN_PHASE； 2）、BSS收到PSMM消息，根据手机上报的PN_PHASE进行判决，公式如下： 3）、BSS根据算出来的PN，在linkcell中查找，找到即进行切换； 那么，以上案例，当手机搜索到PN_PHASE=0X0870=2160，上报PSMM，BSS侧会使用哪个PILOT_INC进行PN计算呢？ 看看发送PSMM前的扩展邻区列表更新消息，其中的PILOT_INC=4。 由此可见，BSS应该使用PILOT_INC=4进行PN计算。因为保定与石家庄采用IBBE互联，即使从保定切换到石家庄，石家庄的BSS也不会负责判决，只是负责把数据透传给保定的BSC，由保定的BSC进行判决；然后再交回石家庄BSC进行查找、切换。 按照如上，由保定BSC计算出来的PN=[(2160+32*4)/(64*4)]*4=32，再由石家庄的BSC进行查找，当然查找不到PN=32的邻区。这样切换失败就是理所当然的了。 如果采用的是硬切换，就不会出现以上的情况，硬切换之后，BSS的判决权也由源BSC转交给目标BSC了。 处理过程 要解决以上的问题，有几种方法： 1）、把所有的PN都改为12的倍数； 2）、将边界切换改为硬切换； 3）、将保定的PN修改为INC=3； 第一种方法明显不可行；第二种方法不能体现IBBE互联对边界切换的好处，治标不治本，只能暂时规避问题；第三种方法能最好地解决此问题，因此需要对保定进行全网PN规划。 经验总结 1)、修改PILOT_INC需要特别注意边界切换的测试调整； 2）、了解BSS的算法的重要性，有助于问题的分析解决；