VoLTE用户紧急呼叫的实现技术研究

时间:2022-06-27 09:00:33

VoLTE用户紧急呼叫的实现技术研究

【摘要】基于现役IMS网络紧急呼叫实现技术及存在问题的分析,研究满足volte用户要求的紧急呼叫系统架构及呼叫实现流程。通过对IMS固定用户和移动VoLTE用户的紧急呼叫实现技术进行比较,提出VoLTE用户紧急呼叫业务实现存在的问题,建议运营商尽快结合本地管制政策明确紧急呼叫的需求,从而促进设备厂商和终端厂商的产品研发及应用部署。

【关键词】IMS VoLTE 紧急呼叫 实现技术

doi:10.3969/j.issn.1006-1010.2015.03.000 中图分类号:TN915.43 文献标识码:B 文章编号:1006-1010(2015)03-0000-00

引用格式:朱晓洁. VoLTE用户紧急呼叫的实现技术研究[J]. 移动通信, 2015,39(3/4): 00-00.

Research on the Implementation of Emergency Call for VoLTE Users

ZHU Xiao-jie

(Guangzhou Research Institute of China Telecom Co., Ltd., Guangzhou 510630, China)

[Abstract]According to the analysis on the troubles in the technical implementation of emergency call in existing IMS network, the system architecture and implementation flow of emergency call for VoLTE users are researched in this paper. By comparing the technical implementations of both fixed IMS and mobile VoLTE users, the problems in the implementation of emergency call for VoLTE users are presented. It is suggested that operators should specify the requirements for emergency call in the light of local regulatory policy to promote the product research, development, application and deployment for equipment and terminal enterprises.

[Key words]IMS VoLTE emergency call technical implementation

1 引言

紧急呼叫是指用户在紧急情况下,通过手机或固定电话等通信终端拨打报警或求救号码而发起的呼叫请求,通信网络则根据用户所在的位置信息把呼叫连接到就近的紧急特服中心。目前中国大陆使用的紧急特服号码包括110(报警)、119(火警)和120(救护)等。

传统固定电话网络根据用户拨打的紧急特服号码直接从本地汇接局路由到就近的紧急特服中心,现役移动网络则根据用户接入的基站信息判断用户地理位置,再由网络接续到就近的紧急特服中心。在LTE环境下,紧急呼叫可以有电路域回落方案(如回落到GSM、CDMA 1X等)和VoLTE方案这2种实现方式。其中,电路域回落方案是LTE语音终端检测到紧急呼叫号码则由电路域发起呼叫,沿用现有移动网络的实现模式,可以作为LTE覆盖不完善时提供紧急呼叫服务的一种过渡方案;VoLTE系统方案则由终端、EPC和IMS配合实现紧急呼叫服务,是VoLTE环境下紧急呼叫的目标方案。

随着LTE网络的部署,移动用户的数据业务逐渐迁移到4G网络,基于IMS的LTE话音业务(VoLTE)成为业界公认的LTE环境下话音业务目标解决方案。由于电路域逐步退网,因此回落电路域的紧急呼叫方案仅适用于过渡阶段,而VoLTE系统实现紧急呼叫的方案成为LTE环境下紧急呼叫的目标方案,由终端、EPC与IMS相配合,根据发起呼叫的用户位置信息把紧急呼叫接续到就近的紧急特服中心。

紧急呼叫的连接与用户位置信息的获取密切相关,因此必须准确判断用户位置信息才能为用户提供精准的服务。在VoLTE环境下,由于用户漫游后仍存在连接到漫游前所附着网络的可能性,导致用户实际位置与其所连接的网络位置信息不匹配,必须要通过特殊机制重新把用户连接到就近的网络,才能通过就近网络连接到就近的紧急特服中心,完成紧急呼叫接续服务。本文通过分析VoLTE环境下紧急呼叫存在的问题,研究VoLTE用户紧急呼叫的实现机制。

2 现役IMS网络紧急呼叫实现技术及问题

当前IMS网络的部署重点解决FTTx用户接入及传统PSTN网络的替代问题,用户使用传统POTS终端或SIP软/硬终端,采用固定接入的方式,用户位置与网络位置信息相匹配,不存在用户漫游发生位置变化的问题,无需动态获取用户的位置信息。

现役IMS网络用户的接入主要存在AGCF与可信任H.248 AG结合接入传统POTS终端、可信任SIP AG接入传统POTS终端、SBC接入SIP软/硬终端或不可信任SIP AG/IAD带POTS终端等方式。如图1所示:

图1 现役IMS网络的紧急呼叫实现架构

方式一:AGCF与H.248 AG接入POTS终端,用于解决传统PSTN网络替代,为用户提供传统网络话音服务。H.248 AG作为网络的可信任设备提供用户接入服务。

方式二:SIP AG接入POTS终端,用于解决传统PSTN网络替代,为用户提供传统话音服务。SIP AG作为网络的可信任设备直接连接到IMS网络或作为不可信任设备通过会话边缘控制器(SBC)接入到IMS网络。

方式三:SIP软/硬终端和SIP IAD通过SBC接入,终端通过FTTx等宽带接入模式接入IMS网络,为用户提供音视频多媒体通信服务。SIP软/硬终端和SIP IAD作为不可信任终端需要通过SBC实现与网络之间的安全隔离。

在用户位置信息的获取上,由于POTS终端和SIP软/硬终端均无法准确提供用户的位置信息,因此现役IMS网络中用户的位置信息采用网络提供的模式。对于可信任设备/终端接入方式,由AGCF或SIP AG提供用户的位置信息;对于不可信任设备/终端接入方式,则由SBC完成用户位置信息的提供,用户开户时即通过静态配置方式设置好位置信息(如H.248 AG标识、SIP AG标识、虚拟SBC标识等用户所连接的网络设备标识)。

用户发起紧急呼叫时,根据用户的接入方式,由AGCF、SIP AG或SBC甄别紧急呼叫并在呼叫请求中加插用户的位置信息,然后把呼叫路由到紧急呼叫的会话处理和路由设备E-CSCF,E-CSCF再根据用户位置信息把呼叫路由到就近的紧急呼叫特服中心,从而实现紧急呼叫的就近接入。

在现行的紧急呼叫实现机制中,由于用户位置信息采用静态配置的方式,因此无法满足用户漫游及位置动态更新的要求。为了解决此问题,在VoLTE用户接入IMS系统时,需要引入新的机制实现用户位置信息的动态更新。

此外,由于各国采用的紧急呼叫号码差异较大,而用户漫游地点的不确定性,要求网络及终端能够支持不同国家和地区的紧急呼叫号码识别。

3 VoLTE紧急呼叫系统架构

第三代合作伙伴计划(3GPP)对VoLTE用户接入IMS的紧急呼叫系统架构如图2所示:

图2 3GPP定义IMS紧急呼叫系统架构

紧急呼叫业务需要终端、EPC和IMS配合实现,IMS核心主要由位置资源功能(LRF)和紧急呼叫会话控制设备(E-CSCF)等网元配合完成相关处理。网络和终端的主要功能如下:

(1)IMS核心网

P-CSCF:会话控制网元,是用户接入IMS网络的入口点,提供紧急会话和紧急注册的接入功能,能识别并标记紧急会话,且提供QoS控制。

S-CSCF:服务会话控制网元,负责处理用户的正常注册和紧急注册管理以及正常呼叫的SIP会话控制。

E-CSCF:紧急呼叫会话控制网元,负责处理紧急呼叫会话控制,将紧急呼叫会话路由到正确的紧急呼叫特服中心。

LRF:提供紧急呼叫用户的位置信息,目前多与E-CSCF采用合设方式。

BGCF/MGCF:IMS与软交换/PSTN网络的互通网元,当紧急呼叫特服中心部署在软交换/PSTN网络时,负责把紧急呼叫路由到软交换/PSTN网络。

IBCF:IMS与其他IP网络的互通网元,负责把紧急呼叫连接到部署在其他IP网络的紧急呼叫特服中心。

EATF:负责紧急呼叫的会话连续性业务处理,提供会话锚定、分组域会话到电路域会话切换的功能。

(2)EPC核心网:负责用户签约数据存储、移动性管理和数据交换。用户正常附着或跟踪区更新时,EPC处理相关请求并在结果中返回预配置的当地紧急呼叫号码,且处理用户发起的紧急附着请求。

(3)UE:VoLTE手机终端,存储用户附着网络的紧急呼叫号码信息,并根据存储号码甄别紧急呼叫,发起紧急注册和紧急呼叫请求。

4 VoLTE用户紧急呼叫的实现流程

根据现行的LTE用户附着流程,用户附着并通过附着地的EPC建立了IMS默认PDN承载后,漫游到新的拜访地时,在用户关开机前并不更新PDN连接,因此用户漫游后仍通过原有IMS默认承载接入IMS网络。例如,用户在广州附着连接到IMS后坐火车抵达北京,在北京漫游的过程中仍使用原有的广州IMS连接(假定全过程手机终端没有开机重启),因此若用户在北京发起110等紧急呼叫时,网络仍通过广州的EPC和P-CSCF完成接续,无法快速准确地把呼叫接续到北京的紧急特服中心。此外,各国使用紧急呼叫号码有差异,需要解决漫游时终端所存储的紧急号码有效性问题。

针对上述问题,3GPP引入终端存储当地紧急号码和针对紧急呼叫重新发起IMS注册机制来保障紧急呼叫的就近接入以及紧急号码准确性。VoLTE用户紧急呼叫的总体实现流程如图3所示:

(1)终端存储紧急号码

当终端发起附着请求或跟踪区更新请求时,EPC通过附着成功消息或跟踪区更新成功消息将配置的本地紧急呼叫号码列表发送给终端。

终端保存该紧急呼叫号码列表用于紧急呼叫的准确甄别,通过这种动态下发的方式来解决不同国家和地区的紧急通信号码不同的问题。

(2)终端甄别紧急呼叫

用户拨打紧急号码,终端根据所存储的紧急号码列表甄别出该呼叫为紧急呼叫。

(3)建立紧急呼叫的专有承载

终端甄别出紧急呼叫后,根据用户的VoLTE业务状态不同采取相应处理机制,具体如下:

若用户为普通用户,则终端请求创建PDN专有承载,指示请求类型为紧急会话,信元Request Type取值为“Emergency”,表示为紧急呼叫建立PDN连接,EPC根据请求选择就近的PGW完成紧急呼叫专有承载的建立。

若用户为受限用户(如欠费或USIM卡无法鉴权的用户等),则向EPC发起紧急附着和建立紧急呼叫的专有承载连接请求,其中信元Attach Type和Request Type取值为“Emergency”,表示为紧急附着,EPC根据请求完成紧急附着以及紧急承载的建立。

(4)UE发起紧急注册

终端创建紧急呼叫专用承载过程成功后,使用紧急呼叫专用承载的IP地址和端口向本地PGW提供的本地P-CSCF发起紧急注册,建立用户到本地P-CSCF的连接。

(5)UE发起紧急会话请求,IMS把呼叫连接到就近的紧急呼叫中心

LTE终端发起紧急呼叫的会话请求,携带位置信息。如果UE有用户号码信息,则UE使用用户的IMPU;如果UE无用户号码信息,则UE应该使用用户的设备标识(IMEI)。

5 VoLTE和固定用户的紧急呼叫实现技术比较及建议

基于紧急呼叫需要根据用户位置信息接入就近紧急呼叫特服中心的要求,由于移动用户漫游但未发起重新注册时用户连接的P-CSCF不变,因此需要引入紧急注册机制保障用户从就近的P-CSCF连接到漫游地的紧急特服中心,导致VoLTE紧急呼叫实现流程要比IMS网络固定用户的紧急呼叫流程复杂。固定IMS用户和VoLTE用户的紧急呼叫实现技术比较如表1所示:

从表1可见,VoLTE的紧急呼叫技术实现涉及终端、EPC和IMS网络的相互配合,需要从终端和网络层面推进相关功能的研发,才具备在网络中部署应用的条件。当前IMS支持紧急注册、EPC支持紧急号码下发和终端支持紧急号码存储甄别等功能尚在研发之中,而各国有差异的本地化需求更有待运营商明确。针对目前LTE部署加快的局面,建议运营商根据政府管制情况尽快明确紧急呼叫相关需求,推动终端和设备厂商完善相关功能,以便在将来VoLTE正式商用部署时具备紧急呼叫的能力。

6 结束语

基于IMS的LTE话音业务(VoLTE)被业界认为是未来移动话音业务的发展方向,随着LTE网络的部署,VoLTE的应用将越来越广泛,紧急呼叫业务作为基础语音服务的一部分,必定要在VoLTE业务中得以保障。尽管3GPP在标准中提出了紧急呼叫实现的技术框架,但是由于各国对紧急呼叫的管制政策不同,需要运营商根据本国的管制特点制定详细的技术方案,推进网络设备厂商和终端厂商的产品研发,以便于在VoLTE商用部署中顺利实现紧急呼叫业务的继承。

参考文献:

[1] YD/T 1406-2005. 公用电信网间紧急特种业务呼叫的路由和技术实现要求[S]. 2005.

[2] YD/T 2541-2013. 基于统一IMS的紧急呼叫业务技术要求(第一阶段)[S]. 2013.

[3] 3GPP TS 23.167 V11.6.0. IP Multimedia Subsystem (IMS) Emergency Sessions[S]. 2012.

[4] ETSI ES 282 004 V3.3.0. Network Attachment Sub-System (NASS)[S]. 2008.

[5] 3GPP2 X.S0060 Version 1.0. HRPD Support for Emergency Service[S]. 2008.

[6] 3GPP TS 24.301 V11.2.0. General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access[S]. 2013.

[7] 3GPP TS 23.271 V12.0.0. Functional Stage 2 Description of LCS[S]. 2013.

上一篇:一种视频监控系统中心跳机制的实现方法 下一篇:TD―LTE异构网覆盖以及干扰的研究