VoLTE国际漫游紧急呼叫方案探讨

朱晓洁　林俐

【摘  要】为了探讨在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网络的规划、建设及管理工作。