上海地铁B-TrunC(宽带集群通信)网络互联互通关键协议研究*

纪文莉 王 森 胥智鹏

(上海申通地铁集团有限公司技术中心, 201103, 上海)

为服务基于LTE(长期演进)技术的宽带数字集群通信标准化,我国宽带集群产业联盟提出B-TrunC(宽带集群通信)系列标准,支持集群语音、集群多媒体、集群数据、集群补充等业务以及各类基本操作的互联互通,并成为ITU(国际电信联盟)推荐的首个LTE宽带集群标准。目前,联盟已发布B-TrunC第一阶段21项、第二阶段40项、第三阶段3项标准,包括总体技术要求、接口技术要求、设备技术要求以及端到端信令交互流程等[1]。

近年来,B-TrunC网络也在国内各城市的轨道交通中推广建设,为运营管理提供了更丰富的集群调度功能。经统计,在调查的109 条城市轨道交通线路中,有21 条线路采用了B-TrunC网络[2]。随着城市轨道交通网络化发展,为满足日益增长的跨线和统一指挥的需求、降低建设和运维成本,在多个层面实现网络的互联互通更加重要。文献[3]介绍了上海地铁LTE不同厂商互联互通的应用效果。文献[4]分析了不同城市轨道交通线路跨核心网的宽带集群互联互通应用场景,并提出相应的实现方案。

本文基于上海地铁B-TrunC网络架构和互联互通需求,对核心网与不同厂家基站、终端实现互联互通功能的关键协议进行研究。

1 上海地铁B-TrunC网络架构及互联互通需求

1.1 网络架构

上海地铁14、15、18号线的轨行区建设了两套基站,通过基站共享技术,分别接入对应的线路核心网和线网级集群核心网(即线网级B-TrunC核心网)。线路核心网接入本线的轨行区基站和相关的TAU(列车接入单元)。线网级集群核心网目前接入了3条线所有的基站,以及手持台、固定台、集群车台、调度台等终端,后续还将接入其他线路的基站和终端。为了提高冗余性、降低故障影响,线网级集群核心网以异地热备方式建设。网络架构如图1所示。

注:eNB—演进型基站。

1.2 互联互通需求

对于分组数据业务,不同厂商LTE设备跨核心网之间的互联互通已有成熟的方案和实施案例,如重庆地铁基于LTE的信号控制互联互通,已实现相关线路的LTE TAU跨线漫游时的正常通信功能。而对于集群调度业务,行业内还没有不同厂商互联互通的实践案例。

上海地铁集群核心网需接入多条线路不同厂商的基站及终端,为使所有线路的集群调度功能均正常互联互通,需要集群核心网与基站(即S1-T)接口、基站与终端(即Uu-T)接口、核心网与终端(即NAS,非接入层协议)接口按照B-TrunC统一标准实施。其中,S1-T接口是在LTE S1接口基础上增加集群相关的功能,提供宽带集群的信令连接和数据连接。Uu-T接口是在LTE Uu接口基础上增加集群相关的无线通信功能,提供分组数据接入和宽带集群接入。NAS协议处理终端和核心网MME(移动管理实体)之间信息的传输。

上海地铁在B-TrunC标准基础上,对集群核心网与基站、终端的部分接口协议进行细化和补充设计,针对某些信令交互的实现细节进行统一。

2 B-TrunC核心网主备倒换优化方案

B-TrunC标准TS 02.006中已明确核心网与基站的接口技术要求,但未考虑核心网备份情况下的相关要求。因此,在核心网备份情况下,为实现不同厂商基站及终端的自动倒换,保证网络功能正常,提出了核心网主备倒换处理的协议要求。

2.1 核心网主备倒换总体过程

核心网主备倒换的总体过程如下:

1) 基站上电时,由核心网通知基站其主备状态;

2) 在核心网倒换后,核心网将倒换情况告知基站;

3) 用户从原主核心网迁移到新主核心网。

2.2 既有方案分析

当前行业内有两家供应商研究并提出了两种不同的核心网主备倒换解决方案。这两种方案的实现方式和优缺点分析如表1所示。

2.3 优化方案

通过分析上述两种既有解决方案的优缺点,综合这两种方案在消息重用、通知基站、用户迁移等方面的优点,对核心网主备倒换相关的实现流程和功能要求进行如下优化:主、备核心网之间需要进行关键信息同步,同步信息应至少包含IMSI和TAI(跟踪区标识)列表。

优化后核心网主备倒换主要的流程和相关功能要求如下:

1) 基站初始上电接入网络。当基站初始上电后,主、备核心网分别向基站发送S1-T SETUP RESPONSE消息,其中信元Relative MME Capacity表示eMME(增强移动管理单元)的权重,取值分别为非0和0,基站根据非0的权值判断该核心网为主核心网。终端上线后,基站收到终端的RRC连接请求,为终端选择当前的主核心网接入。终端上线的流程如图2所示。其中,在步骤4中,如果终端携带的标识是另一个核心网分配的GUTI(全球唯一临时用户设备标识),则核心网应通过步骤5和步骤6要求终端提供IMSI信息;如果终端携带的标识是当前核心网分配的GUTI或者IMSI,则步骤5和步骤6不存在。

图2 终端上线附着流程截图

2) 核心网主备倒换。当核心网主备状态发生变化时,核心网通过改变自身eMME权重告知基站。基站判断发送的消息中包含信元Relative MME Capacity取值为非0的核心网为主核心网。

3) 用户迁移。核心网完成主备倒换后,新的主核心网根据同步的信息,对原主核心网的接入终端发起IMSI寻呼。终端收到寻呼后,发起IMSI附着过程,接入到新的主核心网,迁移过程如图3所示。

图3 核心网主备倒换后在线终端迁移过程截图

3 终端集群功能互联互通协议配置方案

上海地铁在14、15、18号线工程中开展了集群核心网接入不同厂商基站、终端测试,测试了集群语音、集群多媒体、集群补充业务、多媒体消息等四大类业务功能,并对集群语音与短数据并发、集群二开功能、终端双网切换功能等进行验证。

测试发现不同厂商终端大部分功能正常,但因部分协议理解和配置不一致,还存在部分功能未实现互联互通。以下简要介绍针对工程测试及功能调试中发现的部分重要问题提出的对应功能实现流程及协议配置方案。

3.1 终端加载通话组

工程调试中发现,当不同厂商终端的通话组加载数量超过20个并重新开机时,终端只保存20个通话组,无法满足终端需加载通话组的使用要求。

根据B-TrunC标准要求,在终端开机上线、动态重组或签约数据变化后,核心网会将组信息更新消息发送到终端。每个组信息更新消息指示终端对最多20个通话组进行信息更新,当终端需要加载的通话组超过20个组时,组信息更新消息分多条发送。其中,组信息更新消息中Update Type信元的取值表示对终端既有通话组列表进行覆盖操作(取值0时)或者追加操作(取值1时)。

由于两家厂商Update Type信元有效范围定义不同,导致终端收到组信息更新消息后的动作不同。通过明确组信息更新消息中的Update Type信元有效范围为本条消息,确定终端和核心网之间的对应接口消息配置,实现了终端加载通话组功能正常。

3.2 集中录音录像

上海轨道交通14、15、18号线还共享了录音录像服务器。工程调试中出现了不同厂商终端的相关录音文件在统一的回放终端无法播放的情况。

经分析发现,两家厂商音视频编解码设置不同:终端采用的是1个RTP(实时传输协议)包中含2个AMR(自适应多码率)语音帧,发包周期为40 ms;而核心网设备仅支持语音1个RTP包中含1个AMR语音帧,并采用20 ms的发包周期。

为实现集中录音录像功能正常,对相关协议配置方案进行如下优化:

1) 对于两家厂商终端参与呼叫的场景,在呼叫请求时,终端可以提出采用的发包周期,在协商后,应以核心网下发通知的发包周期为准,即终端应支持20 ms的发包周期。

2) 在过渡阶段,暂采用二次开发调度台按照40 ms发包周期保存录音。

3.3 多媒体消息互联互通

由于B-TrunC标准中未明确实现多媒体消息功能的某些细节,两家厂商多媒体消息实现存在差异,两家厂商的终端可以发送文字消息,但无法实现发送多媒体附件。为实现多媒体消息功能互联互通,提出功能实现流程和对应协议内容如下:

1) 登录过程需要携带密码,但不需用户再次输入,终端和核心网均使用核心网提供的密码。

2) 对于核心网要求多媒体消息上传附件过程的鉴权认证,由核心网公开相关接口和提供技术支持,由终端侧修改相关扩展。

3) 历史离线消息由核心网主动推送。

4) 文字消息中所带的自定义扩展字段,由核心网提供字段说明供终端解析。

4 结语

上海地铁建设的线网级集群核心网接入了两家厂商基站和终端,已实现了主备倒换场景下核心网与所有基站、终端的正常对应倒换。集群语音呼叫、实时短数据、多媒体消息功能在跨线路、两家厂商设备之间均可正常互通,视频上拉、下发功能正常。视频组呼功能使用频率相对较低,因为两家厂商对标准的理解和实现方式不同,尚未实现互通。

B-TrunC网络在城市轨道交通行业正在蓬勃发展,可以综合承载信号控制、集群调度、车载视频监控等多种业务,网络利用率、集成度高。本文针对B-TrunC网络主备核心网主备倒换的接口流程和功能要求,提出了实现终端加载通话组、集中录音、多媒体消息等功能互联互通的协议配置优化方案,可为业内其他城市轨道交通工程实践提供参考,从而推动核心网资源共享、降低建设和运营成本,并为“智慧地铁”统一调度、应急指挥提供支持。