STP在GSM-R网络中的主要作用及故障判断

闫慧霞，赵建国，李秀芳，杨志斌

（1.中国铁路北京局集团有限公司北京通信段，北京 100086；2.中国铁路北京局集团有限公司北京铁路通信技术中心，北京 100086）

GSM-R 铁路数字移动通信系统（简称GSM-R系统）是铁路专用移动通信系统。信令转接点（STP）负责完成各局移动交换中心（MSC）、服务GPRS 支持节点（SGSN）与全路共用设备归属位置寄存器（HLR）、智能网（SCP）的信令转接功能，是全网GSM-R 系统的心脏。目前全路STP 分设北京、武汉两地地理冗余。

全路共用GSM-R 核心设备包括北京、武汉SCP、HLR、STP 等。北京、武汉及其他16 个局的MSC、SGSN 均与STP 冗余互联，实现GSM-R线路CTCS-3 列控信息传输、车机联控、进路预告、调度命令等行车业务的运用。网络互联如图1 所示。

图1 信令转接点STP互联Fig.1 Interconnection of signaling transfer point (STP)

1 GSM-R网络STP中信令单板运用方式

GSM-R 系统STP 设备为实现信令转接功能，需要配置处理信令的单板，目前采用西门子厂家CMX-5000 型STP 设备信令单板（MP 单板）配置具有以下几种功能：分别用于网络管理及硬盘接入、信令管理、话单记录、GT 翻译、MTP 信令转接等，并将不同功能的MP 板进行功能及冗余方式的定义，如表1 所示。

表1 STP设备信令单板运用方式Tab. Signaling movement method in single board of STP equipment

其中MP11-15 用来处理MTP 二层及MTP 三层信令转接功能。每个MP 单板最多可承载127 条信令。MP 单板承载的信令主要包含与北京、武汉HLR/SCP 互联以及与各局MSC/SGSN 互联。信令链路负荷分担配置在不同的MP 单板上，避免由于某一块MP 单板异常，导致某一网元的信令不可达。因此，STP 设备在配置MP 板时实现0 侧和1 侧冗余配置的同时，还要考虑STP 与对端设备互联链路采用不同MP（11 ～15）板件来承载信令链路。

每一个完整的信令流程有近十多次的信令交互，每一次都是一个全新的选择，不会固定在某一个单板、某一个时隙上。正常情况下，某块MP 信令板故障，此单板承载的信令链路不可用，并不影响GSM-R 网络NO.7 信令的处理。如果遇到信令链路发生错误，MTP 二层信令会被重新传送，MTP 三层信令则会将故障链路上的流量转移到其他链路上，均不会影响使用。

但是如果某块MP 信令单板存在隐性故障，承载至相应局向的链路状态显示正常，其信令链路仍会被占用，信令处理会出现异常，影响GSM-R 业务。

2 GSM-R网络中STP主要功能运用

GSM-R 网络中STP 主要负责各端局MSC 至HLR、各端局SGSN 至HLR、各端局MSC 至SCP、SCP 至HLR、MSC 间跨局呼叫时的信令转接。

目前组网中将STP 与TMSC 进行了合设。TMSC主要提供跨局呼叫业务转接（根据铁路实际行车调度指挥需求，这类呼叫业务需求较少），减少了GSM-R 系统端局之间需要互通的星星组网连接。

2.1 各端局MSC/SGSN与HLR之间信令转接方式及信令消息流程

2.1.1 各端局MSC/SGSN至HLR的信令路由

1）北京、武汉端局MSC/SGSN 至HLR 信令由北京、武汉STP 采用主/备方式进行转接，以本地STP 为主、异地STP 为备。其他各端局MSC/SGSN 至HLR 的信令由北京、武汉STP 采用负荷分担的方式进行转接。

2）北京STP 至HLR 首选BJHLR21/BJHLR22两个前端节点，备用选武汉WHHLR21/WHHLR22两个前端节点；武汉STP 至HLR 首选WHHLR21/WHHLR22 两个前端节点，备用选北京BJHLR21/BJHLR22 两个前端节点。

2.1.2 HLR至各端局MSC/SGSN的信令路由

4 个HLR 前端节点至各端局MSC/SGSN 信令路由通过北京、武汉STP 负荷分担方式进行转接。即BJHLR21/BJHLR22、WHHLR21/WHHLR22至各端局MSC/SGSN 信令均通过北京、武汉STP负荷分担方式进行转接。

2.1.3 各端局MSC/SGSN与HLR之间信令消息

1）全新用户第一次开机上线，做位置更新。信令消息包含鉴权加密信息（MAP-SENDAUTHENTICATION），一次4 组鉴权相量；位置更新MAP-UPDATE-LOCATION；用户签约信息的插入MAP-INSERT-SUBSCRIBER。这些信息交互完成之后就会存在相应的VLR 内。移动用户位置更新及用户签约信息流程如图2 所示。

图2 位置更新及用户签约信息流程Fig.2 Information flow of location update and subscriber sign-up

2）终端用户关机48 h MSC/VLR/SGSN 自动删除该用户、人为手动对用户进行删除操作。HLR 将用户位置信息删除时，信令消息包含鉴权加密信息(MAP-SEND-AUTHENTICATION)，一次4 组鉴权相量；位置更新MAP-UPDATELOCATION；用户签约信息的插入MAP-INSERTSUBSCRIBER。这些信息交互完成之后就会存在相应的VLR 内。

3）跨MSC 位置更新时，移动用户会找HLR进行位置更新，信令消息包含位置更新MAPUPDATE-LOCATION 和用户签约信息的插入（MAP-INSERT-SUBSCRJBER）。而鉴权相量是找原MSC/VLR 要，身份识别信息（MAP-SENDIDENTIFICATION），如果够用就不需要找HLR。

4）HLR 执行RESET 之后，移动用户进行活动如开关机、做主叫时，需要交互两类信息：位置更新MAP-UPDATE-LOCATION；用户签约信息的插入MAP-INSERT-SUBSCRIBER。

5）注册、注销功能号时，＊＊214＊086+FN 字符串信令消息为非对称结构化请求（UUS，MAPPROCESS-UNSTRUCTURED-SS-REQUEST），会先找HLR 进行补充业务时，在HLR 中会对086 进行处理，指向对应的SCP。

6）MS 做被叫时，需找HLR 要漫游号码信息，信令消息为请求路由信息（SRI，MAP-SENDROUTING INFORMATION）和提供漫游号码（PRN，MAP-PRIVIDE-ROAMING-NUMBER）。SRI:MSC 根据MS 发起呼叫携带的被叫号码（MSISDN）向被叫MS 归属HLR 查询用户当前的路由信息。该消息通常包含：MSISDN、IMSI、MSRN、VMSC 地址、CAMEL 签约信息、位置信息、用户状态和GMSC 地址等。PRN：HLR 向当前用户所在的MSC 发起请求用户的漫游号码。该消息通常包含：IMSI、MSISDN、MSRN、MSC地址、GMSC 地址和相关信令消息等。

7）由于HLR 鉴权信息一次给4 组，每次开关机、位置更新都会消耗鉴权相量，4 组用完之后会找HLR 再要4 组鉴权相量。有剩余鉴权相量时开关机、呼叫RBC、呼叫短号码、呼叫固话，均不需要与HLR 有任何交互信令。

2.2 各端局MSC与SCP之间信令转接方式信令消息流程

2.2.1 各端局MSC至SCP信令路由

1）各端局MSC/SGSN 至SCP 的信令负荷由北京、武汉STP 采用主备方式进行转接，其中北京STP 为主用，武汉STP 为备用。现网武汉、昆明MSC 设置至SCP 的信令转接主用为武汉STP，备用为北京STP。其余各局均按北京STP 主用，武汉STP 备用进行配置。

2）STP 至SCP 的信令路由为主/备方式，北京SCP 为主用，武汉SCP 为备用，或武汉SCP 为主用，北京SCP 为备用。根据运维需求，北京、武汉SCP 主/备运用实施季度倒换方式。如北京SCP为主用时，则北京STP 设置BJSCP21BJSCP22为主用（北京SCP 两个节点为负荷分担方式），WHSCP21、WHSCP22 分 别 设 置 为BJSCP21、BJSCP22 的备用。

2.2.2 SCP至各端局MSC信令路由

SCP 至各端局MSC 信令路由采用主/备方式由北京、武汉STP 转接：至以北京STP 为第一归属的MSC，北京STP 为主用，武汉STP 为备用；至以武汉STP 为第一归属的MSC，武汉STP 为主用，北京STP 为备用（以北京STP 为第一归属的MSC：北京、沈阳、哈尔滨、济南、太原、呼和浩特、乌鲁木齐、兰州、西宁和拉萨；以武汉STP 为第一归属的MSC：武汉、上海、南昌、广州、郑州、南宁、西安、昆明和成都）。

2.2.3 各端局MSC与SCP之间信令消息流程

智能业务呼叫（功能号呼叫、短号码呼叫）启动检测点（Initial DP，IDP），智能网用户进行呼叫后，MSC 发给归属用户SCP 用于触发智能业务流程。该消息通常包含：业务键、位置信息、用户状态、主被叫号码。该信令消息可在7 号信令中查CAP 话单或CAP 信令。

1）功能号或短号码的呼叫，从端局发起找SCP（信令通过STP 转接）。

2）短号码呼叫，SCP 根据主叫用户携带的小区信息，智能网直接查询静态数据，将小区对应的FAS 号码返回MSC 端局，端局根据返回号码进行接续FAS 用户。真正接续时为ISUP 信令和话务通信。

3）功能号呼叫，SCP 根据被叫功能号码，智能网直接查询移动用户注册的功能号码信息，进行任意时间查询（Any Time Interrogation，ATI），SCP 向HLR 发起查询用户位置信息的请求（该信息包含LAC/CI 等信息），HLR 再找端局MSC 查询用户信息，提供用户信息（Provide Subscriber Information，PSI）流程，HLR 回复SCP 具体的LACCI 信息，SCP 根据位置信息与主叫用户的调度辖区DA 值是否一致进行判断应该建立与哪个149 号码移动用户之间的呼叫。之后执行是被叫流程，建立之后就属于ISUP 信令和话务通信。

2.3 SCP与HLR之间信令转接

2.3.1 SCP至HLR之间的信令路由

目前新共用设备SCP 中制作情况为：北京SCP做主用时，至HLR 信令采用北京STP 主用，武汉STP 备用。武汉SCP 做主用时，至HLR 信令采用武汉STP 主用，北京STP 备用。

2.3.2 HLR至SCP之间的信令路由

HLR 至SCP 信令路由采用北京STP、武汉STP 负荷分担的方式。

2.3.3 SCP至HLR之间信令消息

基于位置呼叫限制，在FAS 呼叫车次、机车功能号时，会启用基于位置呼叫限制。被叫号码为2xxxxxxxx 功能号时，MSC-STP-SCP，SCP 翻译2xxxxxxxx 对应86149 号码，并提示要进行基于位置呼叫限制流程，这时SCP 就会去HLR 中查询ATI 消息，返回所有注册该功能号的149 号码。HLR 根据149 号码向相应的VLR 查询具体的LAC CI，即PSI 消息，返回给SCP。SCP 进行主被叫DA 的判断之后，允许则进行接续，不允许则拒绝，如图3 所示。

图3 任意时间查询信息流程Fig.3 Information flow of any time interrogation

2.3.4 HLR至SCP之间的信令消息

HLR 至SCP 之间的信令消息有注册、注销功能号信息，消息类型为MAP 信令，在7 号信令监测系统可以查询MAP 话单或MAP 信令。具体应用为终端用户发送注册（register）消息，消息里带有主叫IMSI，根据GT 翻译将其通过STP转接至HLR。HLR 判断该用户是否有Follow Me 功能，根据用户数据侧086 补充业务，指向SCP 的GT 号码，向SCP 发送USSD 字符串（如＊＊214＊086FN＊＊＊#）。HLR 至SCP 之间请求UUS信息流程如图4 所示。

图4 请求UUS信息流程（HLR至SCP之间）Fig.4 Process of UUS information request (from HLR to SCP)

2.4 各端局MSC之间信令转接

2.4.1 MSC间跨局呼叫的信令转接

端局与邻局虽有互联电路，但只开话路，不开信令链路，信令仍旧依靠北京、武汉STP 进行转接。

类似的呼叫包含：1）CTCS-3 业务的跨局呼叫，属于长呼业务，ATP 车载移动用户呼叫固定用户RBC 号码，通常RBC 与本局MSC 实施互联，车载ATP 在移动网络下有跨局呼叫邻局RBC 的需求，会形成MSC 间的跨局呼叫业务；2）通常FAS系统与本局MSC 实施互联，同样存在FAS 调度用户呼叫邻局网络下局界列车的需求，也会形成MSC间的跨局呼叫业务。

2.4.2 MSC间跨局呼叫的信令路由

北方局使用北京STP 主用，武汉STP 备用。北方局包含北京、沈阳、哈尔滨、济南、太原、呼和浩特、乌鲁木齐、兰州、西宁、拉萨。

南方局使用武汉STP 主用，北京STP 备用。南方局包含武汉、上海、南昌、广州、郑州、南宁、西安、昆明和成都。

2.4.3 MSC间跨局呼叫的信令消息

MSC 间跨局呼叫时的信令为ISUP 信令消息。

3 GSM-R网络如何通过呼叫测试、信令消息分析判断故障点

在GSM-R 网络中，一般设备故障网管会有声光告警提示，根据网管告警维护人员可以做到及时应急处置。但有时也会发生设备没有任何告警提示，但业务受到影响的设备隐性故障，此时需要进行模拟测试并结合信令消息判断故障并查找原因，及时进行应急处置。

3.1 智能网故障判断

3.1.1 通过模拟呼叫测试判断故障点

一是为准确判断故障点，需北京、武汉核心网共同测试；二是北京、武汉核心网各需2 台可以注册功能号的移动终端，并注册测试功能号；三是测试基站小区标识在智能网关联测试1200/1300 并对应相关测试FAS 号码；四是判断故障时两地需同时呼叫拨打1200/1300 短号码，收集北京、武汉测试结果并进一步判断故障点。

1) 如果当前为北京智能网SCP 主用，北京、武汉核心网均测试短号码呼叫异常，则判断可能为北京SCP 系统故障。

2) 如果当前为武汉智能网SCP 主用，北京、武汉核心网均测试短号码呼叫异常，则判断可能为武汉SCP 系统故障。

综合测试情况分析，如仅有一方测试异常，非智能网设备故障。北京、武汉两方都测试异常，判断智能网SCP 故障。同样可以对功能号注册、注销、功能号呼叫等进行业务的测试，进一步判断智能网SCP 是否存在异常情况。

3.1.2 通过接口监测信令消息判断故障点

通过核查NO.7 信令监测系统，选择同一个时间段查看CAP 和MAP 话单，若查询的MAP 话单正常，但CAP 话单中功能寻址、位置寻址出现大量不成功结果，则判断智能网业务异常。通过查看“超时”话单的详细信令消息中的“目的信令点编码”，可进一步确定具体的故障智能网节点。

3.2 HLR故障判断方法

3.2.1 通过模拟呼叫测试判断故障点

由于HLR 系统北京、武汉4 个信令节点同时都在处理业务，当由于HLR 异常影响业务时，判断4 个节点中哪一个异常需要进行大量的呼叫并进行信令的分析，在短时间内判断故障存在一定的难度。因此为保证出现上述问题后能够迅速定位故障节点，北京STP 系统在应预案方面进行了如下完善。

1）在北京STP 中制作4 个号码GT 数据分别指向北京、武汉4 个HLR 前端节点，其中149XXX99022指向BJHLR21，149XXX99023 指向BJHLR22，149XXX99024 指向WHHR21，149XXX99025 指向WHHLR22。

2）当反应部分呼叫等业务异常时，北京核心网第一时间使用铁路固定电话进行多次呼叫测试上述4个移动号码，如呼叫无异常，排除HLR 系统问题。

3）如多次测试某个号码有异常情况，则本号码所指向的HLR 存在问题，可及时将异常HLR 与STP 进行断链操作，网内3 个节点运行，并进一步对问题节点进行排查。

上述方法可以及时准确定位全网4 个HLR 节点的运用情况，日常应急预案完善到位，为应急预案启动、压缩故障延时提供了条件。

3.2.2 通过接口监测信令消息判断故障点

通过核查NO.7 信令监测系统，选择一个时间段查看MAP 话单，若查询的话单中出现大量不成功结果，则判断HLR 业务异常。通过查看“超时”话单的详细信令消息中的“目的GT 值”，可进一步确定具体的故障HLR 节点。

3.3 STP故障判断方法

3.3.1 通过模拟呼叫测试判断故障点

北京核心网利用测试手机多次拨打济南局跨局FAS 号码（7401XX09）；利用模拟ATP 呼叫济南局跨局RBC 号码9243XX01、郑州跨局测试RBC号码9253XX99，如果均存在呼叫不通的现象。但拨打北京局PSTN 号码9010212XX76 正常。

由于上述跨局呼叫FAS 和RBC 号码均需要通过STP 进行信令转接，而且与SCP/HLR 无关，同时呼叫测试又在北京MSC 端局下，所以上述跨局呼叫均通过北京STP 转接。结合北京MSC 端局下呼叫PSTN 正常，再通过接口监测及信令跟踪消息分析，初步判断北京STP/TMSC 系统问题。立即启动将北京STP/TMSC 系统退网应急倒带，暂时将业务恢复，再进一步判断北京STP/TMSC 故障原因。

3.3.2 通过接口监测信令消息判断故障点

同样通过核查NO.7 信令监测系统，选择同一个时间段查看CAP、MAP 以及ISUP 话单，若查询的三类话单中均出现大量不成功结果，则判断STP 业务异常。立即启动将北京STP/TMSC 系统退网应急倒带，暂时将业务恢复，再进一步判断北京STP/TMSC 故障原因。

3.4 MSC故障判断方法

3.4.1 通过模拟呼叫测试判断故障点

判断端局业务是否正常，可以进行如下测试。

1）已开机的语音用户终端、模拟测试ATP 用户终端呼叫本局RBC、呼叫固话、呼叫本局FAS；

2）已开机的GPRS 用户PDP 激活及进路预告下发；

3）有剩余鉴权相量（共有4 个鉴权相量）的用户终端时开关机、呼叫RBC、呼叫FAS、呼叫固话均不受影响。

3.4.2 通过接口监测信令消息判断故障点

如果2 条CTCS-3 列控线路均存在如下监测信息，若A 接口查询的信令中同时出现大量MSC 向BSC 发起的原因值为“Resource Unavailable”的拆链请求；查看PRI 接口信令，如出现大量的车地间数据交互正常的情况下，MSC 向RBC 发送DISCONNECT 拆链，并且拆链无156 号包和39号包，初步判断端局MSC 异常。

立即排查北京MSC 端局有无异常告警，首先确定是MSERVER 问题还是MGW 问题，其次采取冗余板件切换措施，最后采取主/备系统倒换等应急措施。

4 北京 STP入网恢复链路的顺序

北京STP 故障脱网修复之后入网时，需恢复与武汉STP、北京武汉共用设备SCP、HLR 以及各局MSC/SGSN 之间的互联电路。为减少对业务的影响，恢复互联电路须遵循以下顺序。

如果优先恢复北京STP 至各局端局MSC/SGSN 的互联，由于BJSTP 与SCP、HLR 为断开状态，此时会影响各端局通过北京STP 访问SCP或HLR 业务，所以需优先恢复BJSTP 至WHSTP之间的互联电路。其次恢复至SCP、HLR 的互联，最后恢复至各端局MSC/SGSN 的互联。

5 总结

STP 在GSM-R 网络中承担着承上启下的作用。全路GSM-R 共用设备与各局互联均通过STP 进行转接。在日常维护过程中，由于设备机制等原因，设备隐性故障将可能影响全路GSM-R 业务运用。本文结合GSM-R 实际网络组网，通过详细分析研究信令路由及信令消息的转接，对各网元间信令转接消息进行详细阐述，重点是希望通过实际业务影响范围判断故障点，并进行应急处置。