一次two-way引起的异常硬切换掉话.docVIP

问题分析： 为验证软切换最大分支参数对网络性能的影响，嘉兴网优中心5月18日对嘉兴BSC1的软切换最大支路由3路调整为6路。调整前后对桐乡市区进行了对比测试，其中5月19日调整后的测试中发生了一次掉话，第三方网优人员递交上来的报告把掉话原因定位为导频污染，并提出相应的天线调整措施。从报告截图上看，问题点的EcIo似乎不错，不至于因为无主导频产生掉话，于是我们对路测数据进行了重新分析。 从指标上看，掉话前手机处于相对良好的无线环境当中，Rx、Tx、EcIo各项指标均属于正常范围，并未产生恶化。 通过信令分析，我们发现掉话前系统下发了一条往160频点的切换指导消息。 切换指导消息指向于PN102（桐乡电信大楼_1）的160频点，似乎是一条正常的硬切换指导消息。 但事实是，桐乡市区及周边相邻没有小区开设160频点，在该区域不应当触发任何往160频点的切换。于是，我们检查切换前激活集中所有小区的硬切换开关，我们发现除桐乡气象局_1_201（PN45）打开handdown下切开关外，其余的硬切换开关全部关闭。硬切换的发生，至少需要激活集中的一支打开某硬切换开关。而切换前手机占用的频点是283，所有的硬切换开关全部关闭，因此从参数设置上看完全没有理由触发往160的硬切换。 由于路测软件中显示的基站是根据小区的PN及工参数据库来对应，显示的小区并不一定是系统真实分配信道的小区。因此，我们怀疑此时激活集中的真实小区是否就是路测软件所显示的小区。 带着疑问，我们从信令流程上检测了各路PN进入激活集的过程，从切换前的某次邻区列表更新消息中，我们发现了两个相同的PN102： 很显然，在此次邻小区合并的时候，两个相同的PN102进入了邻区列表，形成了所谓的two-way。 查看这次NLUM所对应的HCM中存在4个小区，桐乡天丝服装厂_3（PN381）,桐乡天丝服装厂_1（PN45），桐乡气象局_1（PN15），桐乡80局_3（PN453）。 检查激活集中各路PN的邻小区，发现桐乡气象局_1（PN15）和桐乡天丝服装厂_1（PN45）的邻小区中分别添加了一个PN102的小区。 经查，桐乡河山为桐乡-湖州边界基站，设置了以160为过渡频点的HTC切换，打开了handown开关，且目标指向为160频点。 因此，我们可以判断，手机在测量到桐乡电信大楼_1的PN102足够强时，向系统发送了psmm消息。而基站在数据库中存放着两个pn102，在接收到psmm消息后，错误地把信道分配的目标指向了桐乡河山_1的PN102。此时，系统分配的是桐乡河山_1的信道，手机接收的却是桐乡电信大楼_1的信号。根据华为的handdown算法，激活集中的最强的PN打开了handdown开关，且达到切换门限时，便触发handdown硬切换。当桐乡电信大楼_1的PN102强度衰落到低于触发门限时，系统便触发了往桐乡河山_1的handdown硬切换。之后手机转向解调160频点的PN102，发现无信道可用，FER抬升，产生了一次掉话。 考察桐乡气象局_1与桐乡河山_1邻区关系的合理性，从地图上看，两个小区之间相隔15km，并无做邻区关系的必要，判断为添加脚本误操作。因此建议删除这条邻区数据。 5月22日，我们再对此路段进行复测，情况良好，无掉话。 问题总结： 从问题看来，在新建基站大批量入网的情况下，华为方的脚本制作显得粗糙，在大量添加邻区关系的情况下，对于多余的邻区没有及时清理。在邻区优化时，根据psmm消息上报PN估算邻小区，由于PN复用的存在，加上部分基站的经纬度配置误差较大，导致在邻区判断的时候PN对应错误的基站，这些都要人为区检查并判断合理性。 相对于最大3路软切换分支，6路最大软切换分支对于two-way的问题更加敏感，在BSC软切换分支参数改变的情况下，邻区合并的模型发生了改变，邻区的配置需要更加仔细合理。