梅 靖
(中国铁路上海局集团有限公司上海通信段,上海 200080)
中国铁路上海局集团有限公司核心网GSM-R 割接改造工程自2018 年1 月27 日起至2019 年1 月10 日止,利用了16 个施工点,将上海局管内符夹线、衢九线、合芜线、京九线、阜六线、宁西线、郑徐高铁线、淮萧线、宁启线、杭长高铁线、宁安线、京沪高铁线、沪宁城际线、沪杭客专线、合宁线、合武线、南环线、合福高铁线、合蚌高铁线、宁杭高铁线、杭甬高铁线、杭深线、金温线共计23套GSM-R 无线子系统割接至上海新建核心网,包含15 套BSC 及APN、FAS、PSTN、GRIS 系统。其中C3 线路9 条,C2 线路24 条。本次核心网割接施工共计调整18 个BSC 至MSC、SGSN 间2 M 电路247 条;MSC 至FAS 间2 M 电路22 条。新增局内2 M 电路42 条;跨局2 M 电路30 条,涉及武汉局、郑州局、某局、北京局、济南局。
本文对合福高铁线割接过程中发现的HSBWY01 基站发起210 组呼失败技术难题进行分析,说明排查过程、处理经验,并结合信令、3GPP 协议规范对问题进行分析,定位问题原因,为其他局割接无线子系统提供经验参考。
铁路GSM-R 组呼(VGCS)数据配置中包含组呼成员、组呼小区、组呼级别、组呼主控局、组呼被控局等具体网络参数。210 组呼实现了车站值班员、司机(移动用户)之间的群呼呼叫。299 组呼实现了列车调度员、车站值班员、司机(移动用户)三者之间的群呼呼叫。具体术语如下。
GSM-R 网络中的组呼即群组呼叫,指一个主叫用户对属于预定在该组呼区内和组号内的目标用户建立群呼呼叫。通常铁路GSM-R 组呼属性包括组呼成员、组呼小区、组呼级别、组呼主控局、组呼被控局。具体数据制作依据以北京铁路通信技术中心印发的GSM-R 网络数据审核意见为准。
当一个组呼涉及两个MSC 时,需要协商主、被控参数。通常组呼发起基站所处的局为主控局(Anchor MSC),组呼接收基站所处的局为被控局(Relay MSC)。主控MSC 与被控MSC 分别负责组织各自管辖范围内的移动用户及FAS 用户建立群呼呼叫。
1)本局组呼信令流程
以本局移动用户发起组呼为例,组呼流程如图1所示。
a.移动用户发起210 组呼后,BSC 发送VGCS Setup 至MSC,VGCS Setup 中包含主叫号码、被叫号码、组呼ID、组呼用户所在小区GCI、组呼属性等参数。
图1 本局组呼信令流程Fig.1 Local group call signaling procedures
b.MSC 收到VGCS Setup 消息后,根据VGCS Setup 消息中携带的组呼参数,查询组呼寄存器(GCR),验证VGCS Setup 消息中携带的组呼参数是否合法,并给与反馈。若GCR 查询得到VGCS Setup 消息中携带的组呼参数符合GCR 中的数据配置,则将结果反馈至MSC。
c.在GCR 反馈确认消息之后,MSC 向BSC 发送CONNECT 消息,建立组呼呼叫。
2)跨局组呼信令流程
图2 跨局组呼信令流程Fig.2 Cross bureau group call signaling procedures
以被控局下移动用户发起组呼为例,组呼流程如图2 所示。
a.被控局下移动用户发起组呼后,被控局向主控局发送初始地址消息(IAM),IAM 消息中包含主叫号码、被叫号码、组呼SA、组呼级别、组呼成员、组呼用户所在小区GCI、组呼属性等参数。
b.主控局收到IAM 消息后,根据IAM 消息中携带的组呼参数,查询GCR,验证IAM 消息中携带的组呼参数是否合法,并给与反馈。若GCR 查询得到IAM 消息中携带的组呼参数符合GCR 中的数据配置,则将结果反馈至主控局。
c.在GCR 反馈确认消息之后,主控局向被控局发送地址权消息(ACM),建立组呼呼叫。
11 月22 日合福高铁线hfBSC2 割接至shMSC2后,在某局基站HSB-WY01 下发起跨局210 组呼,上海华为MSC 做为Anchor MSC,南昌诺基亚MSC 做为Relay MSC 时,GSM-R 手持台在某局诺基亚MSC 下发起组呼失败。
依据《北京铁路通信技术中心关于印发杭昌高速GSM-R 网络数据审核意见的通知》(京通函[2018]17 号),在HuangShanBei 基站下存在SA:39022 的210 组呼,其中组呼发起小区含某局基站HSB-WY01。查询上海局MSC 组呼数据,发现组呼成员、组呼小区、组呼级别均配置无误。编号方案如表1 所示。0086149503902221,主叫号码为1495039022210,被叫号码不正确,缺少一位0。
为进一步定位问题点,11 月24 日联系南昌核心网,在南昌MSC 与上海MSC 之间进行挂表截取信令,并还原当时故障场景再次进行测试,在华为核心网shMSC2 网管对主叫用户进行信令跟踪,具体信令如图4 所示。
图4 第二次拨测信令跟踪Fig.4 Second dial test signaling tracking
如图4 所示,南昌诺基亚MSC 发起组呼后,发送IAM 消息给上海华为MSC,其中携带的被叫号码为0086149503902221,主叫号码为1495039022210,其中被叫号码异常,缺少一位0,
表1 车站基站区组呼数据表Tab.1 Data sheet of group call in the station base station area
1)上海局信令分析
为进一步定位故障原因,在华为核心网shMSC2 网管对主叫用户进行信令跟踪,具体信令如图3 所示。
图3 第一次拨测信令跟踪Fig.3 First dial test signaling tracking
如图3 所示,南昌诺基亚MSC 发起组呼后,发送IAM消息给上海华为MSC,其中IAM 消息中携带的被叫号码为之后南昌诺基亚MSC 继续向上海华为MSC 发后续地址消息(SAM),里面含了一位号码0。上海华为MSC 判断为被叫号码异常后拆除呼叫。
2)某局信令分析
某局用信令仪表抓取的信令跟踪,与上海华为MSC 系统自带消息跟踪记录一致。如图5 所示。
图5 某局信令跟踪Fig.5 Signaling tracking of a bureau
某局诺基亚MSC 发起组呼后,发送IAM消息给上海华为MSC,其中携带的被叫号码为0086149503902221,主叫号码为1495039022210。其中被叫号码异常,缺少一位0,之后南昌诺基亚MSC 继续向上海华为MSC 发SAM 消息,里面携带了1 个号码0。之后上海华为MSC 判断为被叫号码异常后拆除呼叫。
3)3GPP 协议规范对比
根据信令分析可以判断由于上海局与某局MSC设备对被叫号码的处理方式不一致,导致210 组呼无法建立。询问华为、诺基亚厂家,对比各MSC 所使用的3GPP 协议版本,发现存在版本不一致问题。
上海华为MSC 使用3GPP 43068-b00 版本协议。3GPP 老版本协议43068-b00 规定Relay 发起时,主叫号码应该是Relay MSC 号码。
南昌诺基亚MSC 使用3GPP 43068-b20 版本协议。规定Relay 发起时,主叫号码应该是组呼参考。
在之前的组呼测试中,南昌送过来的IAM 消息中被叫号码异常,导致呼叫拆线,从协议规范来看,华为MSC 和南昌诺基亚MSC 均符合3GPP 标准协议。
根据信令跟踪得到的结果,可行的解决措施主要有以下两种。
1)南昌MSC 在IAM 消息中补全0086149503 9022210,而不是在SAM 消息里单独送一个0。SAM 消息补全号码的处理方式会增加信令传递、处理时延。
2)南昌MSC 和华为MSC 使用相同的3GPP协议,则可以避免此类问题的发生。目前shMSC2华为软交换ATCA 版本兼容3GPP 的43068-b00 版本和43068-b20 版本两种协议。
因当时上海局华为MSC 相比南昌MSC 承载现网业务较少,决定由上海华为MSC 添加43068-b20版本协议适配,华为MSC 兼容43068-b20 版本协议后,210 组呼复测结果正常,GSM-R 手持台在某局诺基亚MSC 下能够正常发起210 组呼,上海局基站下移动用户与FAS 车站值班台能够正常接收组呼。
在通过信令跟踪、参照协议规范以及某局核心网的配合下,合福高铁线跨局组呼呼叫失败问题得到圆满解决。在故障处理过程中遇到不少问题,也提高了此类故障处理的经验,主要有以下几点。
1)跨局组呼数据配置需及时和邻局进行沟通,明确数据制作规范以及对接参数。
2)当遇到组呼相关的技术难题时,需详实地了解出现问题的拨测环境,有助于还原故障场景使故障复现。
3)当查询数据配置不能有效定位问题点时,及时采用信令跟踪手段进行分析,能够有效定位问题点。
4)故障处理时加强全程全网思想观念,以保障现网业务为首要目标,采取对现网影响最小的措施对故障进行排查、处理。在处理后及时进行拨测验证,对故障进行闭环。