5G紧急呼叫方案分析

魏 群，常 培，马瑞涛（.中国联通研究院，北京 0076；.中国联合网络通信集团有限公司，北京 00033）

1 概述

随着3GPP R15 标准的冻结，全球各大运营商已经逐步启动面向5G 网络的商业化运营布局。在标准层面，面向非独立组网（NSA）和独立组网（SA）的第1版3GPP 国际标准（R15）已相继冻结，基本完成了对5G 核心网整体架构及功能定义。对运营商来说这将是5G技术和商业方案研究、试点、实施的重要窗口期。

本文针对5G 部署初期，为保证中国联通5G 规模商用，开展5GC 网络关键技术研究，综合考虑网络现状以及技术演进要求，结合NSA、SA 大网部署方案研究基础，对紧急呼叫方案进行比较分析，分步骤提出其部署方案以及风险考虑，形成一系列对公司网络与业务发展演进具有重要价值的成果。

2 紧急呼叫概念及网络技术现状

2.1 紧急呼叫概念

紧急呼叫业务是在电话业务普及之后，网络允许移动用户在紧急情况下通过一种简单的拨号方式，及时将紧急呼叫接至离移动用户当时所处基站最近的紧急服务中心。在中国典型的紧急呼叫号码包括110、119、120、122，要求网络将呼叫转接到某一个紧急服务中心号码。此业务优先于其他业务，当用户欠费或者停机情况也能够成功呼叫，这也是运营商承担社会责任的体现。

2.2 网络技术现状

电信运营商部署的紧急呼叫业务历史久远，从电路域时代就开始提供服务。在4G 网络部署初期运营商提供的紧急呼叫一般采用CSFB 方案，具体为：终端发起普通VoLTE 呼叫，到了边界会话控制器（SBC）配置紧急呼叫列表，针对相关呼叫回复380消息，终端接收消息后进行CSFB。这种方式在如今还适用于部分地区，因此仍然需要考虑对这种组网方式的兼容。

随着4G 网络发展，为了避免CSFB 带来呼叫接续时延长影响用户体验，更多使用4G 网络提供紧急呼叫，并且继续保证用户在欠费和停机下能够享受高优先级的服务，此时4G 网络是通过IMS［1］网络提供语音服务，并且未来业务均部署在IMS 上，如RCS 业务［2］。因此现有网络提供紧急呼叫业务的方式具体为：

第0 步：VoLTE 用户接入4G 网，在ATTACH［3］和TAU 过程中，MME 向VoLTE 终端发送的Attach Accept、TAU Accept 消息中包含“IMS Emergency Service=not supported”，但不携带紧急号码列表（Emergency Number List）；以避免对CSFB 终端紧急呼叫业务的影响；VoLTE 终端识别分组域网络不支持紧急呼叫。之后步骤如图1所示。

图1 VoLTE紧急呼叫技术方案

第1步：主叫VoLTE 用户拨打的被叫号码为“紧急呼叫号码”（110、119、120、122），由于VoLTE 终端未从MME 获得紧急呼叫的号码列表，因此，仍以普通呼叫方式，通过IMS APN 默认承载将呼叫发送至VoLTE SBC。

第2步：VoLTE SBC 启动PCC 业务流程，通过DRA向PCRF发送AAR消息，包括请求建立专有承载、请求用户位置信息；PCRF 向VoLTE SBC 返回AAA 消息，其中包含用户当前位置信息（TAI+ECGI）。

第3 步：VoLTE SBC 根据TAI 和ECGI 映射为用户所在位置区域的长途区号和区域识别码填写在PANI中的sbc-domain字段后，将呼叫路由至S-CSCF。

第4 步：S-CSCF 将呼叫路由至VoLTE AS；VoLTE AS 识别被叫号码为紧急呼叫号码，从PANI 中的sbcdomain 字段提取主叫用户当前所在地的长途区号和区域识别码。VoLTE AS 将呼叫路由至S-CSCF，且被叫号码为修改后的号码。

第5 步：S-CSCF 根据被叫号码接续；S-CSCF 对于被叫号码中包含紧急呼叫号码（包括：＜紧急呼叫号码＞、＜本地长途区号＞+＜紧急呼叫号码＞、＜外地长途区号＞+＜紧急呼叫号码＞）的呼叫，不触发智能网业务SCP。

MGCF 根据被叫号码中的区号，将呼叫路由到本省或者到相应被叫省。按照现有CS 域短号码变换规则进行号码变换后送出。

紧急呼叫业务疏通原则完成后续呼叫接续。

3 5G紧急呼叫部署方案分析

2019 年运营商已经开始5G 部署工作，基于以上网络状况需要确定5G紧急呼叫技术方案，以满足商用部署所需要的基本条件。

目前5G紧急呼叫包含了以下4种方式［4-5］。

a）VoNR ECC：直接于NR上建立Emergency PDU，之后通过E-PDU 完成IMS ECC（网络端于5GMM Registration Accept中需要将EMC indicator设为True）。

b）EPSFB ECC：尝试于NR 上建立Eemrgency PDU，网络主动触发HO或是Redirection程序，将UE带往LTE，之后通过Emergency PDN 完成IMS ECC（网络端 在5GMM Registration Accept 中 将EMC indicator 设为True）。

c）ESFB ECC：UE 直接发出Service Request，网络主动触发HO或是Redirection 程序，将UE带往LTE，之后通过Emergency PDN 完成IMS ECC（网络端在5GMM Registration Accept 中 将EMC indicator 设 为False，并将EMF indicator设为True）。

d）Direct LTE ECC：UE 主动回落LTE，于LTE 上建立Emergency PDN 并完成IMS ECC（网络端在5GMM Registration Accept 中需要将EMC/EMF indicator设为False，或者要求UE直接忽略EMC/EMF）。

但以上4 种方案均需要IMS 和LTE 网络支持紧急呼叫，这对VoLTE 用户数开始稳步提升的运营商提出了网络改造要求，进而可能影响现网用户使用体验。因此，本文提出5G网络部署紧急呼叫业务的分步实施方法。

第1 步，5G 部署初期复用VoLTE 紧急呼叫方案，包括EPS Fallback 短号以及VoNR 短号，并且根据网络情况可以首先部署EPS Fallback短号。

第2 步，VoNR 商用，沿用VoLTE 紧急呼叫方案为4G/5G提供紧急呼叫业务。

第3 步，随网络演进需求，逐步部署IMS ECC 紧急呼叫，同时实现4G、5G 紧急呼叫及互操作，或者只开启VoLTE紧急呼叫。

表1给出了3步方案的多角度对比分析。

表1 3步方案多角度对比分析

从表1 可以看出，第1、2 步方案的工程改造非常有限，若5G 部署时间紧则可以采用第1、2 步方案。而第3 步不仅要求网络改造，而且需要修改现网设备配置，而这可能影响网络稳定性和用户体验，主要包括：

a）部署5G 紧急呼叫，同时4G 部署VoLTE 紧急呼叫，可能对原有现网方案的4G用户产生影响。

（a）5G紧急呼叫方案需要IMS支持标准VoLTE紧急呼叫流程，若标准的紧急呼叫和原有现网使用同一个SBC，则SBC 无法通过号码区分送往E-CSCF 还是S-CSCF，所以现网方案和标准方式在流程上有一定冲突，无法同时实现。

（b）EPC：如果UE 发起紧急业务，PS 就按照紧急业务处理，如果不是紧急业务，就按照正常业务处理，分组域本身没有区别。

b）部署5G 紧急呼叫，同时4G 不部署VoLTE 紧急呼叫，可能对原有现网方案的4G用户产生影响。

（a）5G紧急呼叫方案需要IMS支持标准VoLTE紧急呼叫流程，标准的紧急呼叫和原有现网使用同一个SBC，则SBC 无法通过号码区分送往E-CSCF 还是SCSCF，所以短号方案和标准方式在流程上有一定冲突，无法同时实现。

（b）EPC：该场景也无影响和区别。

为了防止在VoLTE 用户逐步迁移过程中网络性能的震荡，建议采取在一定时间内实施第1 步、第2 步满足5G 初期商用的策略。对比4G 现网设置，5G 网络需要修改的数据配置如表2所示。

表2 5G网络与现网数据配置对照表

4 5G紧急呼叫向目标方案演进

对于表1 中第3 步需要综合考虑运营商不同情况，以及国际运营商部署VoLTE紧急呼叫进展，VoLTE国际漫游等多种因素适时引入。目前5G 4 种紧急呼叫详细技术方案如图2所示。

a）方案A 部署于VoNR 覆盖范围，需要IMS、5GC、EPC 均支持紧急呼叫，且支持4G、5G 紧急呼叫的连续性，EMC配置为Y，EPSB配置为N。

图2 5G紧急呼叫方案对比图

b）方案C 部署于非VoNR 覆盖范围，需要IMS、5GC、EPC 均支持紧急呼叫，EMC 配置为N，EPSB 配置为Y。

c）方案B 和方案D 的EMC/EMF 指示位分别与A、C方案冲突。因此不能同时使用。

5G紧急呼叫的过程如下。

第0 步：注册部分，UE 向IMS 拜访网络入口PCSCF 发送Register 消息请求紧急注册。消息中Contact 头域的URI 参数携带“sos”标识，指示紧急注册。该参数中还携带紧急注册的地址，该地址为紧急呼叫缺省承载建立过程中P-GW 分配的终端的地址，并且不能使用与正常注册相同的IP+Port。之后步骤如图3所示。

图3 5G紧急呼叫建立技术方案

第1 步，发起紧急呼叫，UE 在紧急呼叫APN 上发起紧急呼叫会话请求。

第2步，P-CSCF 根据被叫号码识别该呼叫为紧急呼叫，向PCRF发送AAR消息，请求建立紧急呼叫专有承载。P-CSCF 通过AAR 消息向PCRF 获取用户位置信息，并通过P-Access-Network-Info 头域将该信息发送到E-CSCF/PSAP。

PCRF 进行紧急呼叫业务检查，将紧急呼叫会话和相应的IP-CAN 会话进行承载绑定，并生成紧急呼叫的QoS 规则，通过RAR 消息下发给P-GW。P-GW向PCRF 返回RAA 消息，随后建立紧急呼叫语音专有承载。PCRF向P-CSCF返回成功的AAA消息，其中携带PCRF返回的用户位置信息。

第3步，P-CSCF 根据被叫号码识别该呼叫为紧急呼叫，则将该呼叫路由到E-CSCF。E-CSCF 返回100 Trying给P-CSCF。

E-CSCF 解析紧急呼叫请求中的被叫号码及PAccess-Network-Info 头域中的UE 位置信息。根据被叫号码和UE 位置信息，E-CSCF 查找本地路由表确定紧急呼叫中心地址，将紧急呼叫路由到适合的紧急呼叫中心。

第4 步，UE 和PSAP 之间的紧急呼叫成功建立。UE和PSAP之间的紧急呼叫通话结束后，UE发送BYE消息到PSAP 结束会话。P-CSCF 向PCRF 下发STR 消息，释放承载会话。PCRF 收到STR 消息后，删除相关流信息，并向P-GW 下发RAR（携带Remove QoS Rules）指示删除专有承载。P-GW 收到RAR 后，根据Remove QoS Rules 指示，删除专有承载并返回RAA 消息给UPCC。UPCC 收到RAA 响应，向AF 返回STA 响应消息。语音流专有承载的删除过程完成。PSAP 返回BYE消息。

4 种方案建立紧急呼叫的基本流程是类似的，但触发方式以及对设备的要求和配置是不同的，如表3所示。

根据以上分析，可以得出对于向标准方案演进的主要思路如下。

a）在运营商VoNR 覆盖条件较好的情况下，选择方案A是毋庸置疑的。

表3 5G紧急呼叫4种方案对比分析

b）若在一定时期内VoNR不作为主要的语音承载网络，则需要考虑其他3种方案。

c）方案D 主要以终端操作为主，可以作为一种补充方案。

d）方案B 和方案C 则视部署时期终端成熟度，并且考虑设备成熟度以及互操作性方可确定。

5 终端技术要求

网络紧急呼叫的方案同时需要终端在技术要求中加以配合，需要5G 终端支持现网方案，并且考虑到对未来的兼容，要求支持软升级到标准方案。另外，5G 终端能够灵活配置，支持不同运营商使用不同紧急呼叫方案。以下为针对紧急呼叫终端的具体建议。

a）现网方案终端要求，要求不保存紧急号码。

b）5G 紧急呼叫方案终端要求。VoNR 终端应支持拨打110、119、120、122 等紧急呼叫号码；如果这些号码与用户识别卡中EF（ECC）文件中存储的或终端注册时网络下发的紧急呼叫号码列表中的号码相匹配，终端应以紧急呼叫流程发起紧急呼叫；否则终端以普通业务类型发起呼叫。

VoNR终端应支持如下紧急呼叫方式。

a）当网络下发的Registration Accept 消息中，紧急业务支持（Emergency service support）指示支持在5G核心网下的基于NR 的紧急呼叫时，VoNR 终端应直接在NR 建立紧急呼叫PDU 会话；若网络支持在5GC 下建立紧急PDU 承载，则终端完成紧急呼叫PDU 的建立并发起紧急呼叫；若网络将终端切换或者重定向至LTE，则终端应在LTE上发起紧急呼叫。

b）当网络下发的Registration Accept 消息中，紧急业务支持（Emergency service support）指示不支持紧急呼叫业务，且紧急业务回落（Emergency service fallback）指示支持在5G 核心网下基于NR 的紧急呼叫回落时，VoNR 终端应发起携带紧急业务回落指示的Service Request 消息，网络将终端切换或重定向至LTE，终端在LTE上发起紧急呼叫。

c）当网络下发的Registration Accept 消息中，紧急业务支持指示不支持在5G 核心网下的基于NR 的紧急呼叫，而且紧急业务回落（Emergency service fallback）指示不支持在5G 核心网下基于NR 的紧急呼叫回落时，VoNR 终端应主动回落LTE 并于LTE 上发起紧急呼叫。

6 结论及建议

本文针对中国联通5G 发展期，对5G 紧急呼叫业务部署的关键问题进行了研究。通过对现网的深入分析，结合网络改造和设备支持程度等提出5G紧急呼叫分步骤部署方案，进而阐述了不同方案的改造重点、改造风险和详细数据配置。之后深入研究目前标准中提出的各种方案，从多角度对比各方案的优劣势和与现网方案的差异性，提出向标准方案演进的主要思路。并且结合网络的主要技术需求对5G 终端在商用定制中的要求进一步明确。形成对运营商网络与业务发展演进具有重要价值的技术建议。

综上所述，5G 紧急呼叫在5G 部署之际，其技术方案非常重要，需要尽早明确，而且在4G 网络发展的前提下需要考虑对以往技术的兼容，网络的稳定性以及后续技术的演进，这对支持多个制式的运营商提出了更高的技术要求。未来移动网络发展趋势和层出不穷的新需求，会给运营商带来更多新的要求和挑战。