郑徐高铁CTCS-3无线超时分析

刘立海，代 赛

(中铁第四勘察设计院集团有限公司，武汉 430063)

1 概述

国内高速铁路建设已经10 年多了，GSM-R 系统作为高速铁路最重要的通信系统之一，承担着CTSC-3（简称C3）列控系统车地安全信息传送、调度通信、区间维护作业等重要无线通信业务，对高速铁路的运营与安全保障起着重要作用。经过10年多的建设和运用，网络规划设计、优化经验丰富，网络质量及服务越来越稳定。

常见的故障，如常规无线覆盖弱场、多径干扰、区间普通切换掉话等问题已经在网络设计、施工网络优化、联调联试中得到充分的化解，开通后若出现这些常见问题，维护部门也很容易排除。如果经过网络优化、联调联试、动态验收合格的网络刚开通就出现问题，则是一些非常见问题，或者说联调联试或试运行还不够充分，一些隐蔽问题还没有被发现。

本文将通过分析郑徐高铁开通初期C3 超时故障的原因，对GSM-R 网络设计、网络数据制作、联调联试工作提出一些建议，供高速铁路GSM-R网络设计、调试等参考。

2 故障现象描述

郑徐高铁于2016 年9 月10 日开通，10 日、11 日多趟列车在徐州东线路所附近的京沪高铁RBC7 向郑徐高铁RBC3 切换时，出现备用电台无法发起呼叫（电台表现无信号的脱网状态），导致C3 单电台交接；个别列车出现C3 超时提醒，司机不懂如何操作，触发制动。12 日济南局在MSC 补充制作RBC3 数据后，徐州东线路所附近故障消除。但13 ～14 日多趟车在100 多公里外的上海局和郑州局界进行无线切换时，发生切换失败，网管显示各基站设备正常，也有多趟列车切换正常，而从郑州局往徐州东方向运行的所有列车均未出现问题。

这里的故障主要涉及两个区域。一是上海局与济南局局界，即徐州东线路所附近；二是郑徐高铁上海局与郑州局局界，即砀山南站进站信号机附近。为便于分析问题，首先介绍相关线路、RBC 设置及无线覆盖基本情况。

3 无线覆盖方案及MSC、RBC管辖范围

3.1 徐州东站附近无线覆盖及MSC管辖范围

徐州东线路所附近京沪高铁与郑徐高铁线路位置关系及此区域无线覆盖情况如图1 所示。徐州东为京沪高铁建设车站，京沪高铁设计最高速度超过350 km/h，信号采用C3 级列控系统。在交叉处附近郑徐高铁线路上设置徐州东线路所，以便引入徐州东站预留的徐连场，徐连场不同期建设。郑徐高铁同为350 km/h、C3 铁路，GSM-R 网络采用冗余覆盖方案，在其开始设计时，京沪高铁已经建成，开通了GSM-R 网络，按单网交织冗余覆盖方式设计。

图1 郑徐高铁引入徐州东站无线覆盖方案示意图Fig.1 Scheme of radio coverage of Xuzhou East Station due to the access of Zhengzhou-Xuzhou High-speed Railway

考虑到京沪高铁当时采用的原诺西基站不具备分布式基站组网功能，为了减少对京沪高铁既有线运营的影响，郑徐高铁引入徐州东站方案如下。

在郑徐高铁与京沪高铁交叉处附近的徐州东线路所设置双套直放站，同时引接两相邻的京沪高铁济南局范围的既有ZZ-XZD18 和ZZ-XZD19 基站信号（经测试和网络优化后调整为仅连接ZZXZD18）。在郑徐高铁K197+462 处设置双套基站。

此区域基站与MSC 对应关系为：京沪高铁徐州东（含车站基站）至上海方向的基站接入京沪高铁在南京设置的BSC，与上海GSM-R 核心网相连；京沪高铁徐州东（不含车站基站）至北京方向的基站接入京沪高铁在济南设置的BSC，与济南GSM-R 核心网相连；郑徐高铁K197+462（含）至砀山南站（含）的基站接入郑徐高铁在徐州东新设的BSC，接入上海GSM-R 核心网。

维护分界：京沪高铁济南局和上海局的通信系统维护分界设置在徐州东往北京方向的出站信号机附近，徐州东站（含）至上海方向由上海局负责维护，徐州东（不含）至北京方向由济南局负责维护。郑徐高铁从徐州东（含）至砀山南站（含）均由上海局负责维护。

3.2 上海局管内RBC管辖范围

郑徐高铁在上海局管段内设置1 套（RBC3），在郑州局管段内正线设置2 套（RBC1、RBC2）。RBC管辖范围如图2 所示。上海局管内砀山南—徐州东线路所（不含）以及铜山联络线由郑徐RBC3 管辖，徐州东线路所至徐州东站由京沪高铁RBC7 管辖。

图2 郑徐高铁RBC管辖范围示意图Fig.2 Illustration of RBC administration ranges of Zhengzhou-Xuzhou High-Speed Railway

局界RBC 移交位置：京沪高RBC7 与郑徐RBC3 移交点下行线在K199+857，上行线在K200+396，呼叫点距离移交点4 509 m；郑徐RBC3 与郑徐RBC2 的移交点下行线在K311+814，上行线在K312+354，呼叫点大约在移交点前方约4.5 km。

3.3 跨MSC切换与RBC切换位置关系

从徐州东站出发往郑州方向，涉及3 个铁路局，3 次跨MSC 切换。首先是上海局MSC 与济南局MSC 间切换，发生在京沪高铁XuZhouDong与ZZX-XZD19 基站间，对应郑徐高铁里程为K188+066 与K191+051 间；接着发生济南局MSC与上海局MSC 间切换，发生在郑徐高铁ZZXXZD19/R1/R2（设置在徐州东线路所的双套直放站）与XZD-TSXLS01A/B(双套基站)间，对应里程为郑徐高铁客专K193+011 与K197+462 间；最后上海局MSC 与郑州局MSC 间切换，发生郑徐高铁DangShanNan 与DSN-SQ01 基站间，对应里程为郑徐高铁客专K298+327 与K301+277 间。

RBC 切换情况描述见3.2 节，跨MSC 切换和RBC 移交位置相对关系如图3 所示。

图3 跨MSC切换与RBC移交位置相对关系示意图Fig.3 Illustration of areas of MSC handover and RBC handover

4 故障原因分析及解决方案

4.1 备用C3电台无法发起呼叫、单电台交接问题

首先分析运营最初两天出现的在徐州东站附近C3 备用电台无法发起呼叫、C3 单电台交接问题。

经过统计分析发现，所有出现故障的车均为京沪高铁上海局方向发过来的车，而北京局方向发过来的车（在徐州东站换向）或徐州东始发车未出现问题。原因在于上海局方向发过来的列车以C3 方式通过徐州东站，而北京方向发过来在换向或徐州东始发的列车以C2 方式运行，在徐州东线路所后才转为C3。

对于上海方向运行过来的C3 列车，通过对照3.3 节跨MSC 切换及RBC 切换相对位置关系，发现京沪高铁RBC7 到RBC3 切换的C3 起呼位置刚好在济南局的两个基站范围内。分析11 日多趟出现问题的车载电台的脚本数据，如图4 所示，车载电台持续提示“Network resource not available”，经检查，是由于济南局MSC 内未制作RBC3 号码数据，导致在RBC 交接区C3 备用车载电台在济南局基站范围内无法呼叫RBC3，因此信号C3 主用电台与RBC7 连接中断后，需待列车运行到郑徐高铁基站范围后，中断后的电台才可以正常发起呼叫，故表现为单电台交接。

图4 车载电台脚本数据Fig 4. Script data of on-board radio terminals

而对于从北京方向运行过来的列车，由于需要换向运行，以C2 方式从徐州东站发车，在济南局不能发起呼叫，持续以C2 方式运行，等运行到郑徐高铁基站范围才发起呼叫。

因此出现以上现象，即上海方向过来的列车出现超时制动、单电台交接，北京方向过来的列车没有出现问题。实际上是都会出现C3 车载电台无法发起呼叫的问题，只是部分问题被掩盖了。

4.2 C3无线超时问题

发现问题后，济南局补充制作了相关数据，徐州东线路所附近超时制动、单电台RBC 交接问题得到解决，但出现新的问题，即几乎所有从徐州往郑州方向运行的列车运行至上海局与郑州局局界跨MSC 切换处（DangShanNan 与DSN-SQ01 基站间）出现中断。查看交换子系统和无线子系统网管，未发现设备故障，分析接口监测信令数据，相关基站信号正常，而且此处从郑州往徐州方向跨MSC 切换正常，分析上海局接口跟踪的现象如图5 所示。

图5 接口监测系统记录Fig.5 Records captured by the interface monitoring system

切换从郑徐高铁在徐州东站设置的xzBSC1发起，请求切换到郑徐高铁在郑州东站设置的zzBSC6，但是被MSC 拒绝，其后的所有尝试都失败。继续检查呼叫信令，可以发现这个呼叫是从另一个MSC 切换而来，如图6 所示。

此处能与上海MSC 进行切换的MSC 只有济南MSC，C3 呼叫是在济南MSC 下发起的，切换至上海MSC 后继续运行，然后再次切换至郑州MSC 时失败，失败的拒绝消息来自济南MSC。

基于以上分析，怀疑济南MSC 中未制作郑徐高铁郑州段的外部LAC，导致故障发生。经在济南MSC 中补充郑徐高铁郑州范围的位置区（LAC）数据问题得到解决。

此原因为3GPP 协议规定，所有跨MSC 切换，需要由最初发起呼叫的MSC 来管理。而郑徐高铁从徐州至郑州方向运行的列车向RBC3 发起C3 呼叫在济南局范围，运行至上海局与郑州局局界跨MSC 切换时，需要发起的MSC 来管理该连接，要检查目的基站的LAC，在自身数据库中查找。而济南MSC 中未制作郑徐高铁郑州段的外部LAC，从而导致上海局与郑州局跨MSC 切换处中断。举个例子，若从北京西站发起一个长呼一直到深圳北，这中间需要跨越郑州局、武汉局、广铁MSC，每次跨MSC 切换均需北京局MSC 来管理，需要检查切换的目的LAC。

图6 切换信令跟踪记录Fig.6 Records of tracing handover signals

问题的表面原因是在济南局和郑州局MSC 相关数据未制作，深层次的原因是，编号数据与各路局需要制作的数据在范围和内容上没有一一对应关系，而且也没有相关规范或规定进行明确，施工单位的调试、测试和联调联试及试运行均未发现此问题。

5 建议

出现问题后，原铁路总公司电务部组织铁路局、设计、施工、厂家分别进行故障分析，并在北京召开专题会议。这次涉及的问题比较特殊，平时很难碰到，即使大家对RBC 的管辖范围很明确，可以避免济南局漏做数据的问题，但也很难避免第二个问题，还需要联调联试来发现问题，因此各方面提出以下建议。

工程设计方面：在编制GSM-R 网络编号方案文件时，需说明RBC 的覆盖范围、切换点、起呼点位置，以及与GSM-R 网络的对应关系，标记跨MSC 切换位置。这些位置及范围在联调联试中可能会调整，因此编号要考虑这种可能性，范围可以重叠一些、大一些。

数据制作方面：制定数据制作相关的规范，明确需要制作的数据种类、内容和关联数据范围等。在施工调试阶段，做好通信信号的集成调试工作，根据批复的编号方案和信号的方案提出具体核心网和无线网的设备数据制作内容，并进行调试、试验、测试。

联调联试及试运行方面：在C3 线路中，由于C3 中断、C3 兼容C2，建议通信按C3 区段的任何位置均应满足可以重新发起C3 呼叫考虑，这一场景一定要试验到，因此建议对照RBC 管辖范围，进行实际RBC 连接试验。同时，建议信号的试验与通信结合起来，考虑到信号运用的各种场景，按实际运营场景的用例进行联调联试和试运行，以期尽早发现问题。