T7定时器切换参数影响C3降级故障分析

梅 靖 中国铁路上海局集团有限公司上海通信段

1 引言

GSM-R是基于目前已经成熟、通用的公共无线通信系统GSM平台发展而来的，专门为满足铁路应用而开发的数字移动通信系统。本文对上海局将郑徐线BSC从诺基亚MSC割接至上海华为MSC之后，郑徐高铁线陆续发生列车CTCS-3（以下简称C3）降级[1-4]运行的问题，通过截取E接口、A接口信令，对列车降级原因进行分析定位，分析局间切换流程、后续切换流程、MSC局间消息传递流程进行故障定位，对今后的日常维护工作具有一定的指导意义。

2 故障现象

2018年8月10日上海通信段完成了郑徐高铁（上海局管段）BSC接入新设MSC，随即发现列车运行在徐州东站至铜山线路所区间内，上下行均多次发生列车CTCS-3降级运行。

2.1 降级区段和降级列车比例

2018年8月10日凌晨，上海局将郑徐高铁线XZBSC1从诺基亚MSC割接至上海华为MSC之后，部分列车在上海局与济南局交界处发生C3降级。

（1）徐州东往郑州方向：徐州东（上海诺基亚MSC）切换ZZ-XZD19（济南 MSC）成功，ZZ-XZD19切换 ZZ-XZD18 成功，ZZ-XZD18（济南 MSC）切换 TSXLS01A（上海华为 MSC）失败后C3降级。

（2）郑州往徐州东方向：TSXLS01A（上海华为MSC）切换ZZ-XZD18（济南 MSC）成功，ZZ-XZD18切换 ZZ-XZD19 成功，ZZ-XZD19（济南 MSC）切换 XuZhouDong（上海华为 MSC）失败后C3降级。

由此可见，列车降级时主要涉及诺基亚MSC、济南MSC、华为MSC之间的跨MSC切换，主要涉及后续切换信令流程。

根据接入新设的MSC后5天内降级车次比例进行分析，降级车次数量占总车次数量30%到48%不等，从降级次数、降级时间上看无明显规律，如表1所示。

表1 降级车次数量占比分析

2.2 测试方案

因列车降级涉及到上海诺基亚MSC、上海华为MSC、济南MSC、武汉STP、北京STP，为保证分析数据的完整性，多家单位配合共同定位故障点。在济南局MSC的E接口、A接口和BSC的Abis接口上挂信令仪。在上海局对MSC21和MSC22、XZBSC1、njBSC1的 E接口、A 接口和 Abis接口挂接信令仪，各挂接位置跟济南局MSC挂接一致。

3 故障分析

经过对降级车次数据进行综合分析，判断降级区段集中在shMSC2、济南MSC与shMSC1跨局切换区域，为进一步定位故障原因，通过对A口、E口挂表截取信令。

3.1 对诺基亚MSC分析

通过在上海MSC和北京武汉STP之间追踪到一个切换失败的记录进行分析。从信令流程中可见，切换未完成就收到华为的发REL消息，后面的切换流程中断。由于A->B->C跨局切换失败涉及到的三个局的A口和E口消息，仅仅从C局的E口消息无法判断具体的故障点，需要整个流程完整的信令消息才可用进行更进一步的分析定位。

3.2 对华为MSC分析

3.2.1 上行列车（郑州往上海）E接口信令分析

以2018年8月11日G1914次列车为例对E接口信令分析。上海局华为MSC在10：22：55收到济南局MSC的后续切换请求消息，携带目的小区LAC 0X410b以及目的MSC号码8614900411（上海诺西MSC）。华为MSC向上海诺西MSC发起切换消息，上海诺西MSC返回切换响应消息。局间连接建立完成后，10:22:57上海华为MSC给济南MSC回后续切换响应消息，此时上海华为MSC进入等待切换检测消息状态。7 s后上海华为MSC未收到上海诺西MSC发送的切换检测消息，定时器超时，主动发出ABORT消息，拆除呼叫。

3.2.2 下行列车（上海往郑州）E接口信令分析

以2018年8月12日G1879次列车为例对E接口信令分析。08:39:48上海华为MSC接收到来自上海诺西MSC的切换请求消息，上海华为MSC回切换响应消息给上海诺西MSC,华为MSC处理机制正常。

3.2.3 A接口信令分析

08:39:48上海华为MSC收到上海诺西MSC发送的切换请求消息后，上海华为MSC 08:39:48向上海BSC发送HO_Request,上海BSC返回HO_Request_ack给上海华为MSC。上海华为MSC回切换响应消息给上海诺西MSC。但是之后未收到上海郑徐线BSC发送的切换检测消息HO_DETECT消息。08:39:56上海华为MSC发clear_command消息拆除呼叫。

3.2.4 至武汉STP信令分析

08:39:49上海诺西MSC给上海华为发IAM消息，进行局间连接建立。08:39:49上海华为MSC给上海诺西MSC回ACM消息，但是由于上海郑徐线BSC未发送切换检测消息给华为MSC，导致上海华为MSC未发切换检测消息给上海诺西MSC，约7 s后08:39:56上海华为MSC等待切换检测定时器超时，华为MSC向上海诺西MSC发REL（拆线）消息，同时收到了上海诺西MSC发送的REL消息，拆除呼叫。

3.2.5 原因分析综述

上海诺西MSC没有发送切换检测消息(HO_DETECT)给上海华为MSC，最终导致上海华为MSC等待切换检测消息(HO_DETECT)定时器超时，呼叫被释放，后列车发生C3降级。

3.3 三接口检测数据分析

通过济南局C3三接口检测A接口和Abis接口数据分析发现济南的MSC给BSC下发了HandOverCommand（切换命令），但是BSC收到该消息后并没有将该消息发给BTS。

3.4 后续切换流程

当车载MT设备在上海诺基亚MSC下起呼郑徐RBC后，首先切换至济南MSC，后切换至上海华为MSC下，类似涉及3个MSC的跨局切换称为“后续切换”，“后续切换流程”如图1所示，MSC-A代表诺基亚MSC，2G-MSC-B代表济南MSC，2G-MSC-B'代表华为MSC。移动用户从MSC-A（诺基亚MSC）起呼，切换至2G-MSC-B（济南MSC），后续切换至2G-MSC-B'（华为MSC）。

图1 后续切换流程图

（1）BSC-B向2G-MSC-B发送切换请求消息HANDOVER REQUIRED，该消息中含有切换类型、原因、源位置信息、目标位置区小区信息等切换必须的信元。

（2）接收到切换请求消息后，2G-MSC-B根据查询所得到的目的位置区小区的位置，确定本次切换是局间切换，向2G-MSC-A发送后续切换请求MAP_PREPARE_SUBSEQUENT_HANDOVER_REQ消息，该消息中包含了目标MSC的ID、目的位置区小区等信息，2G-MSC-A收到消息后，查询消息中所携带的目的位置区小区的位置。

（3）2G-MSC-A根据目的MSC的ID判断本次切换是后续切回还是后续切换到第三方。通过查表确定本次切换为后续切换到第三方，发送MAP_PREPARE_HANDOVER_REQ消息，示意2G-MSC-B'进行切换前准备工作，在该消息中带有HANDOVER REQUIRED消息的所有信息。

（4）2G-MSC-B'请求VLR-B为本次切换分配切换号码。2G-MSC-B'根据位置区小区号查询目的位置区小区的位置，确定该小区属于本局，然后构造切换请求消息HANDOVER REQUEST，发送给目标BSC-B'，请求为本次切换分配无线资源。2G-MSC-B'向BSC-B请求无线资源和向VLR-B'请求切换号码是并行的，2G-MSC-B'只有在收到这两个请求的回复后，才会向2G-MSC-A回复消息。

（5）BSC-B'分配好无线资源，对2G-MSC-B'回复HANDOVER REQUEST ACKNOWLEDGE消息。

（6）VLR-B'分配好切换号码后，2G-MSC-B'向2G-MSC-A发送MAP_PREPARE_HANDOVER_RSP消息，通知2GMSC-A切换准备完成。该消息中含有切换号码，2G-MSC-A可以通过该号码实现到2G-MSC-B'的话路路由。

（7）2G-MSC-A对切换号码做分析，进行出局选路，选路成功后，则发送IAM消息到2G-MSC-B'。

（8）2G-MSC-B'对IAM消息中携带的号码进行被叫号码分析，确认是切换号码，则通知VLR-B'释放切换号码。该消息可以在2G-MSC-B'收到IAM消息后的任何时间发送。同时2G-MSC-B'对2G-MSC-A返回ACM（Address Complete Message）消息。

（9）2G-MSC-A 发送 MAP_PREPARE_SUBSEQUENT_HANDOVER_RSP消息，通知2G-MSC-B后续切换准备完成。

（10）2G-MSC-B发送HANDOVER COMMAND消息给BSC-B，通知MS可以发送切换了。

（11）BSC-B'检测到正确的MS后，向2G-MSC-B'发送HANDOVER DETECT消息。此时MS已经检测到新的无线信道，并且具备接入的条件，但尚未真正切入，对于语音切换，必须要建立话路。

（12）2G-MSC-B'通过 MAP_PROCESS_ACCESS_SIGNALLING消息将HANDOVER DETECT消息透传给2GMSC-A，2G-MSC-A收到该消息后，请求在MGW-A的上下文中改变端点间的流方向，并进行内部接网。

（13）新的话路已经建立，用户继续通话或进行其他业务，BSC-B'向2G-MSC-B'发送HANDOVER COMPLETE消息上报切换完成。

（14）2G-MSC-B'通过MAP_SEND_END_SIGNAL_REQ消息将HANDOVER COMPLETE消息透传给2G-MSC-A，通知2G-MSC-A切换已经完成。

（15）2G-MSC-B'向 2G-MSC-A 发送 ANM（Answer Message）消息，切换完成。该消息没有实际意义，其目的是为了和局间中继信令保持一致。

（16）2G-MSC-A 向 2G-MSC-B 发送 REL（Release）消息，通知释放局间切换时建立的局间电路。

（17）2G-MSC-A向 2G-MSC-B发送 MAP_SEND_END_SIGNAL_RSP消息，释放局间切换时占用的MAP（Mobile Application Part）资源。

（18）2G-MSC-B对BSC-B发送CLEAR COMMAND消息，通知其释放资源。

（19）BSC-B释放完地面资源和无线资源后，对2G-MSCB回复CLEAR COMPLETE消息。

（20）通话结束，2G-MSC-A向2G-MSC-B'发送REL消息，释放呼叫以及局间电路。

（21）2G-MSC-A 向 2G-MSC-B'发送 MAP_SEND_END_SIGNAL_RSP消息，释放局间MAP资源。

3.5 综合分析

3.5.1 信令分析

综合信令仪测试手机的数据分析，得出以下结论：

（1）华为MSC作为主控MSC时，没有收到上海诺基亚MSC发送的切换检测消息(HO_DETECT)；

（2）诺基亚MSC作为主控MSC时，也没有收到上海华为MSC发送的切换检测消息(HO_DETECT)，而华为MSC没有发该消息，是因为没有收到郑徐BSC发送的切换检测消息HO_DETECT消息；

（3）从三接口检测数据看，济南BSC没有发HandOver Command给BTS，因此可以很自然的推测出：济南收到上海回的“切换响应”消息后，BSC没有将“切换命令”下发给ATP，导致ATP没有在上海的小区下发送“HO ACCESS”消息，上海侧网元等待消息超时，拆除切换流程，切换失败。

因此，定位问题的关键节点在济南MSC和BSS之间。

3.5.2 故障定位

对接入新MSC后4天内所有C3降级车次的信令进行逐一分析，发现华为MSC从收到济南切换请求，到往济南方向发出切换响应消息，至少需要1.4 s以上（不含到武汉到济南的回程传输时间以及武汉STP和济南MSC的消息处理时间），同时降级车次的切换响应时长基本在1.5 s以上，如表2所示。

根据切换成功与失败的相应时间对比，初步判断列车跨局切换降级的原因为济南京沪高BSC的T7计时器配置[5-7]存在问题，并结合接口检测看到的切换执行时长数据中，切换失败的时长都大于2 s，可能导致济南局京沪高BSC T7计时器超时。

3.5.3 BSC T7定时器参数说明

T7计时器在流程中的起止位置：出BSC切换时，BSC上报切换请求消息后，T7定时器启动；在T7定时器超时前，如果BSC收到切换请求应答消息，T7定时器停止；T7定时器超时后，BSC进行出BSC切换失败处理。其位置如图2所示。

该定时器设置过长，可能会浪费信道资源，造成拥塞；该定时器设置过短，可能会影响切换成功率。根据不同设备厂家提供的产品手册显示，华为BSC，T7定时器默认值为10 s，无需修改。而诺西BSC设备其产品手册中有如下描述,“特别在MSC之间切换时，等待HO CMD消息的时间可能超过3 s”，因此跨MSC切换时建议该值设置不低于3 s，具体值看实际情况。

表2 切换响应时间对比

4 处理措施

因为济南局核心网京沪高BSC T7定时器的设置为2 s，在总公司通信中心指导下，济南局将济南京沪高BSC T7定时器设定为3.5 s后，经过5天的验证，郑徐高铁线跨MSC切换时未再发生C3降级。

5 总结

本次故障的定位主要通过截取E口、A口信令，深入分析局间切换流程、后续切换流程、MSC局间消息传递流程以及信令中的异常环节，最终定位列车C3故障原因为济南局BSC的T7计时器设置过短导致。同时通过对此次故障处置，发现对于跨3个不同厂家的MSC切换场景，如果BSC T7定时器设定为2 s过短，会导致一部分车次由于T7定时器超时，BSC即使收到了切换命令（HandOver Command）也将其丢弃而不处理，导致后续的切换流程无法继续执行，从而导致切换失败。通过对此类故障的排查流程，以及处置措施，对今后的日常维护工作具有一定的指导意义。

图2 T7计时器在流程中的起止位置