紀文莉 王 森 胥智鵬

(上海申通地鐵集團有限公司技術(shù)中心, 201103, 上海)

為服務(wù)基于LTE(長期演進)技術(shù)的寬帶數(shù)字集群通信標(biāo)準化,我國寬帶集群產(chǎn)業(yè)聯(lián)盟提出B-TrunC(寬帶集群通信)系列標(biāo)準,支持集群語音、集群多媒體、集群數(shù)據(jù)、集群補充等業(yè)務(wù)以及各類基本操作的互聯(lián)互通,并成為ITU(國際電信聯(lián)盟)推薦的首個LTE寬帶集群標(biāo)準。目前,聯(lián)盟已發(fā)布B-TrunC第一階段21項、第二階段40項、第三階段3項標(biāo)準,包括總體技術(shù)要求、接口技術(shù)要求、設(shè)備技術(shù)要求以及端到端信令交互流程等[1]。

近年來,B-TrunC網(wǎng)絡(luò)也在國內(nèi)各城市的軌道交通中推廣建設(shè),為運營管理提供了更豐富的集群調(diào)度功能。經(jīng)統(tǒng)計,在調(diào)查的109 條城市軌道交通線路中,有21 條線路采用了B-TrunC網(wǎng)絡(luò)[2]。隨著城市軌道交通網(wǎng)絡(luò)化發(fā)展,為滿足日益增長的跨線和統(tǒng)一指揮的需求、降低建設(shè)和運維成本,在多個層面實現(xiàn)網(wǎng)絡(luò)的互聯(lián)互通更加重要。文獻[3]介紹了上海地鐵LTE不同廠商互聯(lián)互通的應(yīng)用效果。文獻[4]分析了不同城市軌道交通線路跨核心網(wǎng)的寬帶集群互聯(lián)互通應(yīng)用場景,并提出相應(yīng)的實現(xiàn)方案。

本文基于上海地鐵B-TrunC網(wǎng)絡(luò)架構(gòu)和互聯(lián)互通需求,對核心網(wǎng)與不同廠家基站、終端實現(xiàn)互聯(lián)互通功能的關(guān)鍵協(xié)議進行研究。

1 上海地鐵B-TrunC網(wǎng)絡(luò)架構(gòu)及互聯(lián)互通需求

1.1 網(wǎng)絡(luò)架構(gòu)

上海地鐵14、15、18號線的軌行區(qū)建設(shè)了兩套基站,通過基站共享技術(shù),分別接入對應(yīng)的線路核心網(wǎng)和線網(wǎng)級集群核心網(wǎng)(即線網(wǎng)級B-TrunC核心網(wǎng))。線路核心網(wǎng)接入本線的軌行區(qū)基站和相關(guān)的TAU(列車接入單元)。線網(wǎng)級集群核心網(wǎng)目前接入了3條線所有的基站,以及手持臺、固定臺、集群車臺、調(diào)度臺等終端,后續(xù)還將接入其他線路的基站和終端。為了提高冗余性、降低故障影響,線網(wǎng)級集群核心網(wǎng)以異地?zé)醾浞绞浇ㄔO(shè)。網(wǎng)絡(luò)架構(gòu)如圖1所示。

注:eNB—演進型基站。

1.2 互聯(lián)互通需求

對于分組數(shù)據(jù)業(yè)務(wù),不同廠商LTE設(shè)備跨核心網(wǎng)之間的互聯(lián)互通已有成熟的方案和實施案例,如重慶地鐵基于LTE的信號控制互聯(lián)互通,已實現(xiàn)相關(guān)線路的LTE TAU跨線漫游時的正常通信功能。而對于集群調(diào)度業(yè)務(wù),行業(yè)內(nèi)還沒有不同廠商互聯(lián)互通的實踐案例。

上海地鐵集群核心網(wǎng)需接入多條線路不同廠商的基站及終端,為使所有線路的集群調(diào)度功能均正?；ヂ?lián)互通,需要集群核心網(wǎng)與基站(即S1-T)接口、基站與終端(即Uu-T)接口、核心網(wǎng)與終端(即NAS,非接入層協(xié)議)接口按照B-TrunC統(tǒng)一標(biāo)準實施。其中,S1-T接口是在LTE S1接口基礎(chǔ)上增加集群相關(guān)的功能,提供寬帶集群的信令連接和數(shù)據(jù)連接。Uu-T接口是在LTE Uu接口基礎(chǔ)上增加集群相關(guān)的無線通信功能,提供分組數(shù)據(jù)接入和寬帶集群接入。NAS協(xié)議處理終端和核心網(wǎng)MME(移動管理實體)之間信息的傳輸。

上海地鐵在B-TrunC標(biāo)準基礎(chǔ)上,對集群核心網(wǎng)與基站、終端的部分接口協(xié)議進行細化和補充設(shè)計,針對某些信令交互的實現(xiàn)細節(jié)進行統(tǒng)一。

2 B-TrunC核心網(wǎng)主備倒換優(yōu)化方案

B-TrunC標(biāo)準TS 02.006中已明確核心網(wǎng)與基站的接口技術(shù)要求,但未考慮核心網(wǎng)備份情況下的相關(guān)要求。因此,在核心網(wǎng)備份情況下,為實現(xiàn)不同廠商基站及終端的自動倒換,保證網(wǎng)絡(luò)功能正常,提出了核心網(wǎng)主備倒換處理的協(xié)議要求。

2.1 核心網(wǎng)主備倒換總體過程

核心網(wǎng)主備倒換的總體過程如下:

1) 基站上電時,由核心網(wǎng)通知基站其主備狀態(tài);

2) 在核心網(wǎng)倒換后,核心網(wǎng)將倒換情況告知基站;

3) 用戶從原主核心網(wǎng)遷移到新主核心網(wǎng)。

2.2 既有方案分析

當(dāng)前行業(yè)內(nèi)有兩家供應(yīng)商研究并提出了兩種不同的核心網(wǎng)主備倒換解決方案。這兩種方案的實現(xiàn)方式和優(yōu)缺點分析如表1所示。

2.3 優(yōu)化方案

通過分析上述兩種既有解決方案的優(yōu)缺點,綜合這兩種方案在消息重用、通知基站、用戶遷移等方面的優(yōu)點,對核心網(wǎng)主備倒換相關(guān)的實現(xiàn)流程和功能要求進行如下優(yōu)化:主、備核心網(wǎng)之間需要進行關(guān)鍵信息同步,同步信息應(yīng)至少包含IMSI和TAI(跟蹤區(qū)標(biāo)識)列表。

優(yōu)化后核心網(wǎng)主備倒換主要的流程和相關(guān)功能要求如下:

1) 基站初始上電接入網(wǎng)絡(luò)。當(dāng)基站初始上電后,主、備核心網(wǎng)分別向基站發(fā)送S1-T SETUP RESPONSE消息,其中信元Relative MME Capacity表示eMME(增強移動管理單元)的權(quán)重,取值分別為非0和0,基站根據(jù)非0的權(quán)值判斷該核心網(wǎng)為主核心網(wǎng)。終端上線后,基站收到終端的RRC連接請求,為終端選擇當(dāng)前的主核心網(wǎng)接入。終端上線的流程如圖2所示。其中,在步驟4中,如果終端攜帶的標(biāo)識是另一個核心網(wǎng)分配的GUTI(全球唯一臨時用戶設(shè)備標(biāo)識),則核心網(wǎng)應(yīng)通過步驟5和步驟6要求終端提供IMSI信息;如果終端攜帶的標(biāo)識是當(dāng)前核心網(wǎng)分配的GUTI或者IMSI,則步驟5和步驟6不存在。

圖2 終端上線附著流程截圖

2) 核心網(wǎng)主備倒換。當(dāng)核心網(wǎng)主備狀態(tài)發(fā)生變化時,核心網(wǎng)通過改變自身eMME權(quán)重告知基站?；九袛喟l(fā)送的消息中包含信元Relative MME Capacity取值為非0的核心網(wǎng)為主核心網(wǎng)。

3) 用戶遷移。核心網(wǎng)完成主備倒換后,新的主核心網(wǎng)根據(jù)同步的信息,對原主核心網(wǎng)的接入終端發(fā)起IMSI尋呼。終端收到尋呼后,發(fā)起IMSI附著過程,接入到新的主核心網(wǎng),遷移過程如圖3所示。

圖3 核心網(wǎng)主備倒換后在線終端遷移過程截圖

3 終端集群功能互聯(lián)互通協(xié)議配置方案

上海地鐵在14、15、18號線工程中開展了集群核心網(wǎng)接入不同廠商基站、終端測試,測試了集群語音、集群多媒體、集群補充業(yè)務(wù)、多媒體消息等四大類業(yè)務(wù)功能,并對集群語音與短數(shù)據(jù)并發(fā)、集群二開功能、終端雙網(wǎng)切換功能等進行驗證。

測試發(fā)現(xiàn)不同廠商終端大部分功能正常,但因部分協(xié)議理解和配置不一致,還存在部分功能未實現(xiàn)互聯(lián)互通。以下簡要介紹針對工程測試及功能調(diào)試中發(fā)現(xiàn)的部分重要問題提出的對應(yīng)功能實現(xiàn)流程及協(xié)議配置方案。

3.1 終端加載通話組

工程調(diào)試中發(fā)現(xiàn),當(dāng)不同廠商終端的通話組加載數(shù)量超過20個并重新開機時,終端只保存20個通話組,無法滿足終端需加載通話組的使用要求。

根據(jù)B-TrunC標(biāo)準要求,在終端開機上線、動態(tài)重組或簽約數(shù)據(jù)變化后,核心網(wǎng)會將組信息更新消息發(fā)送到終端。每個組信息更新消息指示終端對最多20個通話組進行信息更新,當(dāng)終端需要加載的通話組超過20個組時,組信息更新消息分多條發(fā)送。其中,組信息更新消息中Update Type信元的取值表示對終端既有通話組列表進行覆蓋操作(取值0時)或者追加操作(取值1時)。

由于兩家廠商Update Type信元有效范圍定義不同,導(dǎo)致終端收到組信息更新消息后的動作不同。通過明確組信息更新消息中的Update Type信元有效范圍為本條消息,確定終端和核心網(wǎng)之間的對應(yīng)接口消息配置,實現(xiàn)了終端加載通話組功能正常。

3.2 集中錄音錄像

上海軌道交通14、15、18號線還共享了錄音錄像服務(wù)器。工程調(diào)試中出現(xiàn)了不同廠商終端的相關(guān)錄音文件在統(tǒng)一的回放終端無法播放的情況。

經(jīng)分析發(fā)現(xiàn),兩家廠商音視頻編解碼設(shè)置不同:終端采用的是1個RTP(實時傳輸協(xié)議)包中含2個AMR(自適應(yīng)多碼率)語音幀,發(fā)包周期為40 ms;而核心網(wǎng)設(shè)備僅支持語音1個RTP包中含1個AMR語音幀,并采用20 ms的發(fā)包周期。

為實現(xiàn)集中錄音錄像功能正常,對相關(guān)協(xié)議配置方案進行如下優(yōu)化:

1) 對于兩家廠商終端參與呼叫的場景,在呼叫請求時,終端可以提出采用的發(fā)包周期,在協(xié)商后,應(yīng)以核心網(wǎng)下發(fā)通知的發(fā)包周期為準,即終端應(yīng)支持20 ms的發(fā)包周期。

2) 在過渡階段,暫采用二次開發(fā)調(diào)度臺按照40 ms發(fā)包周期保存錄音。

3.3 多媒體消息互聯(lián)互通

由于B-TrunC標(biāo)準中未明確實現(xiàn)多媒體消息功能的某些細節(jié),兩家廠商多媒體消息實現(xiàn)存在差異,兩家廠商的終端可以發(fā)送文字消息,但無法實現(xiàn)發(fā)送多媒體附件。為實現(xiàn)多媒體消息功能互聯(lián)互通,提出功能實現(xiàn)流程和對應(yīng)協(xié)議內(nèi)容如下:

1) 登錄過程需要攜帶密碼,但不需用戶再次輸入,終端和核心網(wǎng)均使用核心網(wǎng)提供的密碼。

2) 對于核心網(wǎng)要求多媒體消息上傳附件過程的鑒權(quán)認證,由核心網(wǎng)公開相關(guān)接口和提供技術(shù)支持,由終端側(cè)修改相關(guān)擴展。

3) 歷史離線消息由核心網(wǎng)主動推送。

4) 文字消息中所帶的自定義擴展字段,由核心網(wǎng)提供字段說明供終端解析。

4 結(jié)語

上海地鐵建設(shè)的線網(wǎng)級集群核心網(wǎng)接入了兩家廠商基站和終端,已實現(xiàn)了主備倒換場景下核心網(wǎng)與所有基站、終端的正常對應(yīng)倒換。集群語音呼叫、實時短數(shù)據(jù)、多媒體消息功能在跨線路、兩家廠商設(shè)備之間均可正常互通,視頻上拉、下發(fā)功能正常。視頻組呼功能使用頻率相對較低,因為兩家廠商對標(biāo)準的理解和實現(xiàn)方式不同,尚未實現(xiàn)互通。

B-TrunC網(wǎng)絡(luò)在城市軌道交通行業(yè)正在蓬勃發(fā)展,可以綜合承載信號控制、集群調(diào)度、車載視頻監(jiān)控等多種業(yè)務(wù),網(wǎng)絡(luò)利用率、集成度高。本文針對B-TrunC網(wǎng)絡(luò)主備核心網(wǎng)主備倒換的接口流程和功能要求,提出了實現(xiàn)終端加載通話組、集中錄音、多媒體消息等功能互聯(lián)互通的協(xié)議配置優(yōu)化方案,可為業(yè)內(nèi)其他城市軌道交通工程實踐提供參考,從而推動核心網(wǎng)資源共享、降低建設(shè)和運營成本,并為“智慧地鐵”統(tǒng)一調(diào)度、應(yīng)急指揮提供支持。