苏州高铁北站TD室分问题处理报告new.docxVIP

苏州高铁北站TD室分问题处理报告一、概述：8月26日收到领导投诉，反映苏州高铁北站占用TD信号无法接听电话，存在短信呼情况，且在10点20分左右，占用苏州京沪高铁北站TD室分小区存在频繁注册现象。该站与8月23日凌晨进行了割接，割接后现场测试无法下载，已通过在SGSN添加RAC数据解决，由于割接后当天仅做了语音主叫业务正常，被叫问题未能发现。针对该问题，安排测试人员现场测试验证，另一方面进行后台数据核查。二、处理情况1. 首先针对小区数据进行了核查，无异常情况；2. 根据投诉现象，用户占用该室分小区无法做被叫，出现短信呼的情况，怀疑核心网方面数据可能存在异常，导致用户占用到该小区无法响应寻呼。3. 由于割接后苏州京沪高铁北站_1室分小区所在SUZHRNC45存在使用2个不同LAC的情况，初步怀疑为核心网中数据定义问题，核查核心网中在MobileTelephony(GSMandUMTS)Functions检查与RNC相关参数指令，主要涉及如下指令数据定义情况：MGLAP/MGLAE/MGLAI:用于在核心网中查询/删除/增加定义LAI；MGRIP/MGRIE/MGRII/MGRIC:用于在核心网中查询/删除/增加定义/修改RNC数据；MGMAP/MGMAE/MGMAI:用于在核心网中查询/删除/增加LAI与RNC之间的连接数据（用于根据实际需求决定是否指定RNC中下发对某个LAI的寻呼消息（或对某个LAI的寻呼是否在指定的RNC进行下发）。4. 针对LAI、RNC定义数据进行核查，均有在交换中正确定义，而通过MAMAP查询涉及寻呼相关的LAI与RNC连接数据定义情况，发现苏州京沪高铁北站_1所在的MSCPOOL(SZPOOL2:WUXGS16/17/18/31/54/66）中未定义在SZHRNC45与LAI=460-00-20680之间关联数据；怀疑占用北站TD室分小区无法做被叫问题与此有关，因此后台人员在涉及的MSCPOOL中增加SZHRNC45与LAI=460-00-20680之间的连接数据定义，完成添加数据后，现场人员占用室分可接听电话正常。5. 为再次验证该问题原因与RNC与LAI的连接数据定义相关，10:18:45逐步开始针对已添加的SZHRNC45与LAI=460-00-20680之间关联数据删除，删除后拨打现场测试人员测试终端（占用TD苏州京沪高铁北站_1小区），存在短信呼情况。然后在10:28:38完成对已删除的数据恢复，恢复后拨打现场测试终端成功，现场多次进行主、被叫业务均正常。详细调整验证脚本如下：根据张总、陆工话单情况，在10:22:50至10:25:53期间出现在苏州京沪高铁北站_1与专网小区朱泾R_1间频繁注册的情况，与进行删除核心网中RNC与LAI之间的关联数据调整验证的时段吻合，且在完成验证恢复数据添加之后，现场测试未出现频繁注册的现象，因此频繁注册的应为数据调整导致。现场测试各车站检票入口，重选及业务态切换均正常，详细情况如下：三、小结根据本次TD室分割接造成的问题处理情况来看，由于本次割接的TD小区属性上较为特殊：1、 割接后小区所在的RNC存在2个LAC（53260和20680）；2、 割接后小区使用的LAC存在多个RNC/BSC中（SZM16B3、SUZ-HBSC-6900-01、SZHRNC43、SZHRNC45）因此核心网数据相对正常的数据定义要更为复杂，后期在RNC进行类似情况下的小区割接/新开小区时务必做好流程确保数据定义完善，需完成确认定义的如下数据：1、 RNC侧：需增加新的位置区信息、路由区信息、小区的RAC数据定义；2、 核心网侧：需增加新的LAI与RNC之间的关联数据定义；3、 SGSN侧：需在RNC所在的SGSN中增加新的RAI数据；四、考核鼎利2主要问题：1. 测试未按照规范，未测被叫，导致问题未能及时发现。2. TD相关能力特别是核心网数据定义能力不够，需大力提升。3. 割接前未由负责TD，负责高铁的相关技术人员审核方案可行性，匆忙割接导致问题。8月鼎利2考核扣5分 由奥联朱建党负责培训TD割接核心网数据添加 今后割接前需要提供详细的割接方案（包括测试方案，应急倒回方案等），必须经相关人员审核确保无问题后方可实施割接。 完善测试表格