VoLTE紧急呼叫技术研究

［冯薇薇］



VoLTE紧急呼叫技术研究

［冯薇薇］

摘要

文章对VOLTE紧急呼叫技术进行了阐述，具体包括VoLTE紧急呼叫业务特征、业务架构、呼叫方案、标准及信令流程等，分析了存在的问题并对VOLTE紧急呼叫业务的发展方向提出了建议。

关键词：VOLTE EPC IMS CS紧急呼叫紧急号码列表 匿名 定位

冯薇薇

中国电信股份有限公司广东研究院工程师，长期从事移动通信领域技术研究，重点研究移动核心网相关技术。

1　VoLTE紧急呼叫业务描述和业务特征

VoLTE（Voice over LTE，基于LTE的话音呼叫）紧急呼叫业务是指在紧急情况下，VoLTE网络应满足公众的紧急呼叫需求，系统能结合VOLTE用户拨打的紧急呼叫接入号码以及用户的位置信息将紧急呼叫路由到就近的应急指挥中心/联动平台。目前国内使用的紧急呼叫接入号码包括110报警、119火警和120救护等【1】。

VoLTE紧急呼叫业务的主要业务特征包括：

(1)支持未注册用户和由于欠费等原因导致正常业务无法使用的普通受限用户使用紧急呼叫业务；

(2)就近接入，根据发起紧急呼叫时的位置信息把呼叫接入到就近的应急指挥中心或联动平台，使得用户可以尽快获得所需帮助。

(3)支持回拨，允许应急指挥中心回拨用户，根据需要对用户位置及其他信息作进一步确认，回拨功能仅适用于已注册用户发起的紧急呼叫业务。

2　VoLTE紧急呼叫业务架构

VoLTE紧急通信业务由LRF（Location Retrieval Function，位置获取功能）和E-CSCF（Emergency Call Session Control Function，紧急呼叫会话控制功能）等网元配合实现，系统架构如图1。

紧急呼叫由UE（User Equipment，用户设备）或AS（Application Server，应用服务器）代理用户发起，呼叫请求通过LTE网络接入IMS（IP Multimedia Subsystem，IP多媒体系统）网络，由P-CSCF（Proxy Call Session Control Function，代理呼叫会话控制功能）或S-CSCF（Serving Call Session Control Function，服务呼叫会话控制功能）送到E-CSCF，E-CSCF向LRF查询用户的位置信息以及紧急指挥中心的路由信息，并把呼叫路由到就近的紧急指挥中心/联动平台。

VoLTE紧急呼叫对EPC（Evolved Packet System，演进的分组核心）核心网的要求如表1。

图1　VoLTE紧急通信业务架构图【7】

表1　VoLTE紧急呼叫对EPC核心网的要求

VoLTE紧急呼叫组网涉及的IMS主要功能实体如下表2：

表2　VoLTE紧急呼叫组网IMS主要功能实体

3　VoLTE紧急呼叫方案

目前，VoLTE紧急呼叫方案可分为两类：基于IMS网络实现紧急呼叫的方案和回落到CS（Circuit Switched，电路交换）网络进行紧急呼叫的方案。

根据终端能力是否支持紧急呼叫甄别，基于IMS网络实现紧急呼叫的方案存在两种情况：（1）3GPP（3rd Generation Partnership Project，第三代合作伙伴计划）标准要求终端支持紧急号码的存储和紧急呼叫甄别，终端、EPC和IMS网络均需支持3GPP标准紧急呼叫的标准流程；（2）、对于部分无法存储紧急号码和甄别紧急呼叫的终端，终端把紧急呼叫作为普通呼叫请求发送到IMS网络，IMS网络甄别紧急呼叫、添加用户位置信息，并送往紧急呼叫会话控制网元E-CSCF/LRF来完成紧急呼叫处理并路由到紧急呼叫中心。

当由于LTE网络覆盖率低、支持IMS紧急呼叫的终端匮乏等因素影响，导致VOLTE用户无法在IMS网络实现紧急呼叫时，可采用回落到CS网络进行紧急呼叫的过渡方案，具体如表3：

表3　VOLTE紧急呼叫方案

4　标准及信令流程

4.1VoLTE紧急呼叫标准

VoLTE紧急呼叫标准基本成熟，VoLTE紧急呼叫相关标准除回叫外已经终结。VoLTE紧急呼叫相关标准如表4。

表4　VoLTE紧急呼叫标准

4.2VoLTE紧急呼叫基本信令流程

4.2.1VoLTE紧急呼叫的号码获取过程【3】【4】

当UE发起附着请求或TAU（Tracking Area Update，跟踪区更新）请求时，EPC网络中的MME（Mobility Management Entity，移动管理实体）通过Attach Accept消息或TAU Accept消息将配置的紧急呼叫号码列表发送给UE，UE将该号码保存在终端中，以便发起紧急呼叫时能正确识别。当UE漫游到某地或重启，都会重新进行网络附着，此时新的MME也会将新的紧急呼叫号码列表返回UE，UE同样需要刷新本地存储的号码列表。

网络下发紧急号码流程如图2：

图2　网络下发紧急号码流程

过程如下：

（1）附着流程：

①：UE向MME发起附着请求。

②附着成功后，MME向UE发送Attach Accept消息，携带Emergency Number List信元，其中包含本地紧急呼叫号码列表。

③UE将紧急呼叫号码保存在本地，并向MME返回Attach Complete消息，完成附着流程。

（2）TAU流程：

①UE向MME发起TAU请求。

②TA（Tracking Area）更新成功后，MME向UE发送TAU Accept消息，携带Emergency Number List信元，其中包含本地紧急呼叫号码列表。

③UE将紧急呼叫号码保存在本地，并向MME返回TAU Complete消息，完成更新流程。

4.2.2VoLTE普通用户紧急呼叫的紧急专用承载建立过程【5】

正常签约且能正常使用业务的VoLTE用户建立紧急专用承载的流程如图3：

图3　VoLTE普通用户建立紧急专用承载流程

1.终端在创建PDN专有承载时，指示请求类型为紧急会话，信元Request Type取值为“Emergency”，表示紧急呼叫建立PDN连接。

2～3.S-GW/P-GW建立紧急承载请求。针对紧急专用承载，MME可以选择特定的PDN-GW，应优选本地的PDN-GW。

4～5.紧急承载的QoS策略控制，PCRF提供特殊的PCC规则和认证，保证该会话资源不被其他业务占用。

6～7.S-GW/P-GW建立紧急承载响应。

8～13.无线承载建立。

14～17.S-GW/PGW的承载修改。

4.2.3VoLTE受限用户紧急呼叫的紧急专用承载建立过程【5】

受限用户紧急呼叫的紧急专用承载建立流程如图4。受限用户包括：（1）普通受限用户：正常的签约用户，但是由于某种原因呼叫受限（比如欠费或者不在该运营商的位置区）；（2）有USIM卡（Universal Subscriber Identity Module，全球用户识别卡）的受限用户：用户有USIM卡，但是USIM卡鉴权失败的用户，使用IMEI （International Mobile Equipment Identity，国际移动设备标识）进行紧急呼叫；（3）无USIM卡的受限用户：用户没有USIM卡，使用IMEI进行紧急呼叫。

1 ～ 2.UE向MME发起附着请求Attach Request消息，其中信元Attach Type和Request Type取值为“Emergency”，表示为紧急附着。

图4　VoLTE受限用户紧急呼叫的紧急专用承载建立过程

3～5.MME对UE进行鉴权，并获取用户信息（可选）。

6～11.MME进行紧急资源承载创建。

12～15.无线承载建立。

16～17.UE收到Attach Accept消息，获取PDN地址信息后，开始通过eNodeB向S-GW/P-GW发送上行分组数据包。

18～19.S-GW向UE发送缓存的下行分组数据包

4.2.4VoLTE紧急呼叫的IMS紧急注册过程【6】

如图5：

（1）终端创建紧急呼叫专用承载过程成功后，使用紧急呼叫专用承载的IP地址和端口发起紧急注册。

（2） P-CSCF（BAC）通过Register消息中Contact头域携带的参数“sos”识别该注册为紧急注册。

（3）I-CSCF查询HSS，获取合适的S-CSCF地址。

（4）I-CSCF根据HSS返回的S-CSCF地址，将呼叫路由到S-CSCF。

（5）S-CSCF注册成功，下载用户签约数据，同时不影响可能已经存在的普通承载注册信息，实现双注册。

图5　VoLTE紧急呼叫的IMS紧急注册流程

4.2.5VoLTE紧急呼叫的IMS会话建立过程【7】如图6

（1）LTE终端发起紧急呼叫的会话请求，携带位置信息。

①如果UE有用户号码信息，UE应该使用P-Preferred-Identity头域携带用户的IMPU。

②如果UE无用户号码信息，UE应该使用P-Preferred-Identity头域携带用户的设备标识(IMEI)。

③如果用户有合法的卡，用户应该携带IMPU。

（2）P-CSCF（SBC）根据请求目的地址和头域Priority:emergency识别为紧急呼叫，支持根据接入域、接入类型、接入位置、目的地址配置选择E-CSCF，并前传请求。

①如果用户未注册，获取P-Preferred-Identity头域携带用户的身份标识生成P-Asserted-Identity。

②P-CSCF识别出紧急呼叫会话后，支持在Rx接口通过Service-URN通知PCRF执行紧急呼叫的承载控制策略。

③P-CSCF将呼叫路由到用户注册时分配的E-CSCF。

（3）E-CSCF根据需要选择执行和LRF交互，获取位置和路由信息。

（4）E-CSCF查询LRF或本地配置的紧急呼叫中心表和号码路由信息表，将呼叫经MGCF路由到PSAP（EC）。

图6　VoLTE紧急呼叫的IMS会话建立过程

5　挑战及发展方向

目前，VoLTE紧急呼叫技术已基本成熟并得到应用，但还面临挑战、存在需要解决的问题，包括匿名紧急呼叫回拨、紧急呼叫精确定位、特殊场景无法发起紧急呼叫等：

VoLTE用户终端发起紧急呼叫之前没有向IMS注册(无卡)或者注册未成功（鉴权失败）时，将发起匿名紧急呼叫，如果用户是匿名呼叫用户,紧急呼叫处理中心如何能够回拨给这个用户是一个有待解决的问题,毕竟在处理紧急情况时,回拨用户了解更多情况是非常必要的。

为了在紧急情况下更好地为公众提供救助服务,对紧急呼叫进行定位是网络支持应急通信的一个很重要的功能，在部分国家,已经要求通信网络必须具备对紧急呼叫进行定位的能力。移动定位的主要问题是很难做到精确定位,特别是在某些偏远地区,一个基站的覆盖半径往往达到数公里,在这么大的范围内定位基本失去了意义,而在这些地方发生的紧急情况又恰恰最需要定位。新的技术可以结合GPS（Global Position System，全球定位系统）定位、终端信号的强度和方向等信息实现比较精确的定位,但是要真正将这些技术运用到VoLTE网络中,还需要大量的研究【2】。

在传统紧急呼叫实现方案中，网络侧把已配置的紧急呼叫号码列表下发给终端，终端将该列表临时保存在终端内存中，并依据该表确认所拨打号码是否为紧急号码。在终端鉴权失败、无卡终端首次发起呼叫等情况下，网络侧不会向终端下发已配置的紧急呼叫号码列表，同时，终端内置的紧急号码可能与所拨打紧急号码或所处区域网络的紧急号码列表不匹配，导致紧急呼叫无法实现。要解决该问题，还需要采用新的专利思路、技术方案来实现。

与VoLTE网络面临的其它挑战一样,对应急通信的支持也是在VoLTE网络研究中必须重视的一个领域,需要为应急通信中存在的这些问题找到比较好的解决方法。只有战胜了这些挑战,以LTE和IMS为基础的VoLTE网络才能真正走向成熟。

参考文献

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

2曹远.应急通信-下一代网络面临的又一挑战.世界电信,2006,19(6):41-43

33GPP TS 22.101 V14.1.0 3rd generation partnership Project;technical specification group services and system aspects;Service aspects;Serviceprinciples(Release 14).2015-09

43GPP TS 24.008 V13.4.0,3rd generation partnership project;technical specification group core network and terminals;mobile radio interface layer 3 specification; Core network protocols; Stage 3(Release 13).2015-12

53GPP TS 23.401V13.5.0,3rd generation partnership project;technical specification group services and system aspects;General Packet Radio Service(GPRS)enhancements for evolved universal terrestrial radio access network(E-UTRAN)access(Release 13).2015-12

63GPP TS 24.229 V13.4.0.3rd generation partnership project;technical specification group core network and terminals;IP multimedia call control protocol based on session initiation protocol(SIP)and session description protocol(SDP); Stage 3(Release 13).2015-12

73GPP TS 23.167 V13.1.0.3rd generation partnership project;technical specification group services and system aspects;IP multimedia subsystem(IMS)emergency sessions(Release 13).2015-12

收稿日期：（2016-02-16）

DOI:10.3969/j.issn.1006-6403.2016.03.013