上海地鐵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網絡主備核心網主備倒換的接口流程和功能要求,提出了實現終端加載通話組、集中錄音、多媒體消息等功能互聯互通的協議配置優化方案,可為業內其他城市軌道交通工程實踐提供參考,從而推動核心網資源共享、降低建設和運營成本,并為“智慧地鐵”統一調度、應急指揮提供支持。