高速铁路通信GSM―R中智能网的异地冗余备份机制.docVIP

高速铁路通信GSM―R中智能网的异地冗余备份机制 摘 要 高速铁路通信GSM-R智能网系统为铁路提供司机与调度、调度与司机之间的呼叫，即通过智能网的位置寻址、功能寻址来实现。本文主要针对目前全国GSM-R智能网系统的异地冗余备份进行互联倒换测试，明确智能网的原理及倒换机制，为日常维护提供依据。 关键词 GSM-R；智能网；SSP；STP；异地冗余；维护 中图分类号O59 文献标识码A 文章编号 1674-6708（2013）90-0216-02 1 概述 高速铁路通信GSM-R中智能网主要提供司机与调度、调度与司机之间使用机车号、功能号的呼叫。同时提供根据位置信息呼叫管辖调度值班台。由于智能网设备为全路共用，重要级别较高，因此在设立时采用了异地冗余备份机制。分布在北京、武汉两个机房。每个机房均放置一套智能网系统。每套智能网系统有2个业务节点和一个网管节点。业务节点之间为同时在线工作互为热备，网管节点是单节点工作模式。每个业务节点由PW650主机和CX300数据库组成，业务数据都存放在CX300数据库中。2个业务节点的CX300数据库存放的数据一致，同时在线工作，互为热备份。每个业务节点的数据库对2个业务节点都有连接。每个业务节点通过2M线与MSC（SSP）连接，对MSC（SSP）的连接为热备份。网络图如下： 2地理冗余机制 SCP的地理冗余由MSC（SSP）来判断和触发。 当北京SCP发生宕机等重大灾难时，交换机会检测到主路由链路中断，转而将消息发往备份路由，即到武汉SCP，武汉SCP会立刻接受该业务请求。 当北京SCP上层应用进程吊死等也会导致SSP检测到该消息超时从而选择备份路由来触发地理冗余。 3 互联测试 为了确保真正做到SCP的地理冗余备份，对北京、武汉SCP进行了详细的互联互通性测试，具体测试测试内容以及测试结果如下： 1）北京、武汉SCP动态数据同步验证，在北京和武汉两地注册的功能号在北京、武汉SCP均能看到。操作方法：保持两SCP与MSC间LINK正常，保持两SCP间数据网链路正常； 2）北京SCP到两STP链路全部中断，武汉SCP到两STP链路全部正常，武汉SCP处于备用模式下尚未置为主用，两SCP间数据链路正常； 3）北京SCP到BJSTP和WHSTP信令链路全部中断，业务由WHSCP处理，修改BJSCP为备用，WHSCP为主用时对业务的影响； 4）当BJSCP至两地STP链路全部恢复，即BJSCP故障恢复，BJSCP仍为备用，WHSCP仍为主用； 5）将WHSCP修改为备用，BJSCP修改为主用时对业务的影响测试； 6）BJSCP为主用，WHSCP为备用，将WHSTP至BJSCP直达路由中断，通过北京STP访问BJSCP功能测试； 7）BJSCP为主用，WHSCP为备用，将BJSTP至BJSCP直达路由中断，通过武汉STP访问BJSCP功能测试； 8）测试数据网通道异常对两地SCP同步的影响； 9）两地MSC分别使用各自本地SCP时对智能网业务的影响（即关闭BJSTP――WHSCP、WHSTP――BJSCP、WHSTP――BJSTP） ； 10）备用WHSCP链路全部故障，对智能网业务的影响。 5 互联测试分析及应急操作步骤 根据以上互联测试，我们可以发现目前全国GSM-R智能网系统已完全做到了地理冗余备份机制。在日常维护中，我们还应该注意哪些方面呢。以下总结了日常应急操作方法，为日常的维护人员提供维护依据。 我们假设北京系统发生系统性灾难。 1）智能网业务将平滑过渡到武汉SCP，该切换过程没有任何业务会受到影响。交换机会自动选择备份路由将业务送到武汉系统，但是需要交换机专家在北京和武汉的MSC上，立刻在灾难发生后人为屏蔽至北京SCP的主链路路由（人为屏蔽以避免北京SCP恢复后话务任意切换回来）； 2）武汉SCP开始承担所有智能网业务，北京SCP处于系统灾难恢复中，此时没有任何数据同步（武汉系统已经在武汉SCP上，人为定义为主侧，但由于北京系统尚没启用）； 3）北京系统恢复处理业务后，在北京SCP上人为定义为备份侧开始工作，所有最新的注册/注销/强制注销消息会从武汉SCP同步到北京系统。 为了让武汉的SCP所有最新的注册消息都同步到北京系统，我们要求武汉SCP作为主侧连续工作以给予足够的数据同步的时间来更新北京SCP的数据库。这样可以避免我们人工倒回数据库操作，不会影响客户的业务。同时为了安全起见，在最终开始倒回北京为主用侧的操作之前，我们用脚本的方式导出武汉所有最新的注册功能号并和北京最新的功能号的数据库表作手工对比，以保证武汉所有的注册功能号在北京系统上都存在，此时我们认为从武汉同步到北京已经完成。（注：从武汉SCP数据同步到北京SCP数据的时间取决于双方动态数据的更新程度，更新程度越高，数据的同步率