VoLTE國際漫游緊急呼叫方案探討

2020-02-22 12:25:59 移動通信 2020年1期

朱曉潔 林俐

【摘? 要】為了探討在RAVAL和S8HR兩種國際漫游方式下,VoLTE緊急呼叫業務的實現方案存在的問題,提出與拜訪網絡能力和漫游VoLTE終端能力一致的緊急呼叫方案建議,以及基于拜訪運營商VoLTE網絡實現的正常緊急呼叫和GIBA鑒權緊急呼叫業務流程,研究證明,參考所提出的業務流程,可解決SIP協議對3GPP業務流程無法支持的問題。

【關鍵詞】VoLTE;國際漫游;緊急呼叫

doi:10.3969/j.issn.1006-1010.2020.01.016? ? ? ? 中圖分類號:TN919.8

文獻標志碼:A? ? ? ? 文章編號:1006-1010(2020)01-0086-06

引用格式:朱曉潔,林俐. VoLTE國際漫游緊急呼叫方案探討[J]. 移動通信, 2020,44(1): 86-91.

0? ?引言

VoLTE業務國際漫游包括RAVEL(Roaming Architecture for Voice over IMS with Local Breakout)和S8HR(S8

Home Routing)兩種實現方式。在RAVEL方式下,歸屬運營商(HPLMN)與拜訪運營商的IMS網絡進行漫游互聯,IMS語音由拜訪運營商(VPLMN)的IMS網絡提供分流。在S8HR方式下,VoLTE用戶的歸屬運營商與拜訪運營商雙方的EPC網絡采用數據漫游連接,雙方的IMS網絡之間不連接。VoLTE業務在漫游時,雙方運營商之間只需要EPC網絡漫游互聯,不需要IMS網絡漫游互聯,此時漫游終端涉及到的IMS信令和媒體均作為LTE數據進行漫游[2]。

國際漫游VoLTE用戶在撥打緊急呼叫時,VoLTE網絡應滿足VoLTE用戶到政府或機構的緊急呼叫接續要求[5],結合用戶撥打的緊急呼叫號碼以及用戶的位置信息將緊急呼叫路由到就近的應急指揮中心/聯動平臺,包括公共安全、火警和醫學救護等[1]。

采用RAVEL方式可以通過標準的業務流程從拜訪地VoLTE網絡就近連接到拜訪網絡的緊急呼叫中心提供拜訪地緊急業務,但需要互聯的兩個運營商之間進行VoLTE網絡及VoLTE終端業務的互聯接口對接測試,實現復雜,因此目前運營商間VoLTE漫游基本采用S8HR方式。采用S8HR方式實現漫游業務時,由于迂回到拜訪用戶的歸屬VoLTE網絡提供業務,因此無法通過正常流程通過拜訪地網絡接入到拜訪地緊急呼叫中心,緊急呼叫業務難以實現。

本文探討在RAVAL和S8HR兩種國際漫游方式下VoLTE緊急呼叫業務實現方案存在的問題,并針對S8HR方式提供緊急呼叫業務提出優化方案。

1? ?基于RAVEL架構的 VoLTE緊急呼叫業務實現

1.1? RAVEL方式緊急呼叫業務架構

RAVEL方式的緊急業務架構如圖1所示。

RAVEL方式下歸屬運營商與拜訪運營商雙方的IMS網絡可以通過IPX(IP交換網絡)或直接進行漫游互聯。RAVEL方式下,VoLTE業務采用本地分流方式,由拜訪運營商網絡的PGW來分配IP地址,正常VoLTE業務涉及到的IMS網絡由拜訪運營商和歸屬運營商共同來提供,P-CSCF由拜訪運營商提供,I/S-CSCF由歸屬運營商提供。另外,拜訪運營商和歸屬運營商之間通過雙方的國際IBCF/TrGW功能來提供雙方IMS網絡域之間的互聯互通。

RAVEL方式下,根據拜訪運營商VoLTE網絡和漫游VoLTE終端的能力,漫游VoLTE用戶的緊急呼叫業務優選由拜訪運營商VoLTE網絡提供,在拜訪運營商VoLTE網絡不支持緊急呼叫時回落2G/3G網絡提供。

1.2? RAVEL方式緊急呼叫業務的方案選擇

RAVEL方式漫游用戶基于拜訪運營商VoLTE網絡提供緊急呼叫時,終端需支持3GPP標準TS23.167[3]的VoLTE緊急呼叫業務流程。但實際部署中拜訪地網絡能力和終端能力不一,單憑TS23.167定義的流程無法為所有終端提供緊急通信服務。需要根據網絡能力和終端能力的組合為用戶選擇合適的緊急業務提供方式來實現緊急呼叫業務。表1提出RAVEL方式下,拜訪運營商VoLTE網絡能力和漫游VoLTE終端能力的不同組合時采用不同緊急呼叫業務提供方案的建議。

1.3? RAVEL方式緊急呼叫業務的部署問題

RAVEL方式可通過標準的業務流程通過拜訪地網絡就近連接到拜訪地緊急呼叫中心提供緊急呼叫業務,對拜訪地網絡和歸屬網絡均無額外功能要求。

但RAVEL漫游方式在運營商VoLTE網絡間部署涉及大量的網絡接口、業務互通和終端能力協同方面的測試,在運營商VoLTE網絡間鮮有部署,因此基于RAVEL方式為拜訪用戶提供緊急呼叫業務的方案也少有啟用。相信將來運營商間VoLTE網絡業務功能和終端能力差異縮小時,隨著VoLTE互聯難度的降低,該方案會隨著RAVEL方式的部署應用逐步啟用。

2? ?基于S8HR架構的VoLTE緊急呼叫業務實現

2.1? S8HR方式緊急呼叫業務架構

S8HR方式的緊急呼叫業務架構如圖2所示。

S8HR方式下,拜訪運營商通過SGW和MME等網元與歸屬運營商互聯,提供LTE數據漫游連接服務。提供VoLTE業務的IMS APN采用歸屬地路由方式,由歸屬運營商網絡的PGW來分配IP地址。正常VoLTE業務涉及到的IMS網絡全部由歸屬運營商來提供。

S8HR方式漫游VoLTE用戶的緊急呼叫由圖2的VPLMN網絡提供,UE附著時EPC網絡為用戶下發緊急呼叫號碼列表,國際漫入UE檢測到用戶撥打緊急呼叫號碼時,執行緊急附著并建立緊急PDN,基于緊急呼叫PDN發起緊急注冊,P-CSCF終結緊急注冊請求并根據網絡支持GIBA(GPRS-IMS捆綁認證)[6]的能力情況對注冊請求進行響應。

根據3GPP TS 24.229[4]的定義,對于支持GIBA認證的P-CSCF,IMS認證根據用戶的IP地址和IMSI將IMS注冊與用戶的EPS認證進行關聯,P-CSCF在Gm上執行GIBA過程。對于不支持GIBA認證的P-CSCF,UE可進行匿名緊急會話,用戶的回撥號碼可通過PCRF獲取。

為S8HR方式漫游VoLTE用戶提供基于IMS的緊急呼叫業務對拜訪地VoLTE網絡的P-CSCF等網元有額外要求。拜訪地網絡不支持VoLTE緊急呼叫時,S8HR方式漫游VoLTE用戶的緊急呼叫業務通過回落2G/3G網絡提供。

2.2? S8HR方式緊急呼叫業務的方案選擇

S8HR方式漫游用戶基于拜訪運營商VoLTE網絡P-CSCF等網元提供緊急呼叫時,拜訪地網絡和終端均需支持GIBA鑒權等額外能力要求。實際部署中拜訪地網絡能力和終端能力不一,需要根據網絡能力和終端能力的組合為用戶選擇合適的緊急業務提供方式來實現緊急呼叫業務。表2提出S8HR方式下拜訪運營商VoLTE網絡能力和漫游VoLTE終端能力的不同組合時采用不同緊急呼叫業務提供方案的建議。

2.3? 支持GIBA的VoLTE緊急呼叫業務流程

3GPP TS 23.167定義了S8HR方式下緊急呼叫的業務流程,該流程要求P-CSCF在SIP INVITE中轉發從PCRF接收到的MSISDN派生的回撥參數(CallBackPar),但在SIP協議中并沒有相應做回撥參數的擴展,且通過User ID已經能滿足為緊急呼叫中心提供回撥號碼的需求,因此本文建議對3GPP流程進行優化,取消重復傳送回撥號碼且目前SIP協議不支持的回撥參數的傳送。優化后,漫游用戶撥打緊急號碼后,基于拜訪運營商VoLTE網絡提供VoLTE緊急呼叫時,VoLTE終端進行緊急附著、緊急PDN建立、緊急注冊和緊急呼叫流程如圖3所示。

S8HR漫入用戶VoLTE緊急呼叫業務優化流程包括以下步驟:

(1)用戶撥打緊急號碼,終端請求緊急附著,為IMS緊急呼叫申請PDN連接。

(2)MME從HSS獲取用戶的IMSI、IMEI和MSISDN。

(3)MME/SGSN向PGW發送包括IMSI、IMEI和MSISDN的創建會話請求。

(4)PGW建立與PCRF的IP-CAN會話,IP-CAN會話通過與IMS緊急服務的PDN連接相關聯的UE的IPv4/IPv6地址前綴來標識。作為IP-CAN會話建立的一部分,IMSI、IMEI和MSISDN被傳遞給PCRF。

(5)UE完成附著及請求的PDN連接過程。

步驟6~12適用于UE基于滿足運營商要求的GIBA鑒權條件進行IMS緊急注冊的情況,例如,UE具有足夠的IMS認證信息。

(6)UE通過發送SIP REGISTER發起IMS緊急注冊,已經完成普通IMS業務注冊時To域填寫網絡下發的IMPU,未完成普通IMS業務注冊時To域填寫UE基于IMSI推導的臨時IMPU。

(7A)在接收到SIP REGISTER消息時,P-CSCF確認沒有與用戶歸屬域進行IMS互聯,通過Rx會話建立請求向PCRF請求與UE的IP地址相關聯的EPS級標識,包括IMSI、IMEI和MSISDN等。

(7B)PCRF基于UE的IP地址/前綴執行會話綁定,并向P-CSCF提供一個或多個EPC級別身份,包括IMSI、IMEI和MSISDN。P-CSCF對PCRF提供的IMSI/IMEI與從UE提供的公共用戶身份導出的IMSI/IMEI進行驗證。

(8)基于運營商配置,P-CSCF有以下三種響應及后續處理方式。

方式A(步驟9~12),如果網絡支持通過Gm接口的GIBA流程(如支持步驟7A和7B流程且驗證成功),則P-CSCF返回420響應,在其中Unsupported頭域攜帶sec-agree值,可添加是否支持匿名IMS緊急會話的指示。

方式B(步驟13~15),UE嘗試匿名IMS緊急會話:

1)P-CSCF已經在步驟8中響應403(禁止);

2)P-CSCF在步驟8中響應420,但UE不支持GIBA;

3)UE跳過了IMS緊急注冊的情況下,則應用步驟13~15。

方式C(步驟16),若網絡不支持GIBA及VoLTE匿名緊急呼叫,則P-CSCF直接回復380響應指示終端回落或在終端嘗試匿名呼叫失敗后回落CS域。

方式A(步驟9~12):

不管在步驟8中是否包括匿名IMS緊急會話支持的指示,如果UE支持GIBA過程作為緊急IMS注冊的一部分,步驟9~12適用于P-CSCF已經在步驟8中以420響應作出回復的場景。

(9)根據TS 24.229,UE向P-CSCF發送攜帶IMPU的SIP REGISTER消息發起新的不啟用安全機制的初始注冊。

(10)P-CSCF接受注冊請求返回200 Ok,并且基于步驟7b中從PCRF接收到的MSISDN,P-CSCF通過P-Associated-URI頭域傳送該MSISDN相應的tel-URI給UE。從UE角度,該流程與TS 24.229中為GIBA(GPRS-IMS捆綁認證)流程規定的流程相同。

(11)UE發送SIP INVITE消息建立IMS緊急會話,攜帶IMPU(tel-URI,即圖中UserID 3)。

(12)P-CSCF驗證SIP INVITE消息中指示的IMPU是否符合提供給UE的tel-URI。如果符合,則P-CSCF將SIP INVITE轉發到應急通信中心,在P-Asserted-Identity頭域填寫該tel-URI。該過程在此結束。

方式B(步驟13~15):

(13)UE發起SIP INVITE消息中包括“匿名用戶”參數的未經認證的IMS緊急會話。

(14)在接收到SIP會話建立請求時,P-CSCF在內部檢索UE IP地址是否存有在步驟7b中接收到的一個或多個EPC級別身份和MSISDN,無則再次執行步驟7。

(15)P-CSCF將SIP INVITE轉發給緊急呼叫中心。tel-URI格式的UserID-4從在步驟7b或步驟14中接收的身份標識MSISDN導出,在P-Asserted-Identity頭域填寫該tel-URI。

方式C(步驟16):

在步驟8中收到380(Alternative Service)類型為“emergency”、或者終端不支持420的GIBA要求、或者在匿名SIP INVITE嘗試之后,終端可以在CS域中嘗試緊急呼叫。

3? ?結束語

隨著VoLTE業務的商用部署范圍不斷擴大,VoLTE業務的國際漫游需求日益迫切,不同運營商的VoLTE網絡間實現漫游互聯也逐步提上日程。運營商可根據自身VoLTE網絡能力,對端VoLTE網絡能力和VoLTE終端能力選擇REVEL或S8HR漫游方式為用戶提供VoLTE國際漫游服務,同時可參考本文方案建議,根據拜訪地網絡能力及用戶終端能力的組合選擇合適方案為漫游用戶提供緊急呼叫業務。此外,部署S8HR漫游方式為用戶提供緊急通信服務時,參考本文提出的業務流程可解決SIP協議對3GPP業務流程無法支持的問題,有效推進S8HR漫游方式提供緊急呼叫業務方案的商用部署。

參考文獻:

[1]? ? ?YD/T 2541-2013. 基于統一IMS的緊急呼叫業務技術要求(第一階段)[S]. 北京: 工業信息化部, 2013.

[2]? ? GSMA. IR.65 IMS Roaming and Interworking Guidelines v22[S]. 2016.

[3]? ? ?3GPP. 3GPP TS 23.167 V15.4.0: IP Multimedia Subsystem (IMS) emergency sessions[S]. 2018.

[4]? ? ?3GPP. 3GPP TS 24.229 V16.0.0: IP multimedia call control protocol based on SIP and SDP; stage 3[S]. 2018.

[5]? ? 3GPP. 3GPP TS 23.228 V15.2.0: 3rd Generation Partner-ship Project; Technical Specification Group Services and Systems Aspects; IP Multimedia Subsystem (IMS); Stage 2[S]. 2018.

[6]? ? 3GPP. 3GPP TS 23.401 V15.5.0. General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access[S]. 2018.

作者簡介

朱曉潔(orcid.org/0000-0001-5967-9028):高級工程師,現任職于中國電信股份有限公司智能網絡與終端研究院移動通信研究所,從事網絡技術及國內外標準研究工作,研究方向包括IMS、VoLTE、SDN/NFV及5G語音等。

林俐:高級工程師,碩士畢業于中山大學,現任職于中國電信股份有限公司廣東分公司,從事信令網、PSTN、軟交換網絡、IMS網絡、移動CDMA核心網、VoLTE網絡的規劃、建設及管理工作。

江南高纤股票分析