一、互联网支持科能融合应急通信
1.1 、互联网简介
互联网是由广域网、局域网及终端（包括计算机、手机等）通过交换机、路由器、网络接入设备等基于一定的通信协议连接形成的功能和逻辑上的大型网络，如图5-20所示。
图5-20 互联网网络架构
随着IP技术的迅速发展和应用的普及，互联网应用已经深入教育、政府、商业、军事等各行各业，成为重要的社会基础设施。
人们日常生活中经常能够接触到甚至依赖各种互联网应用，包括Web浏览、电子邮件、即时消息、IP语音通信、IP视频通信、FTP、公众信息发布等。如果能够利用这些应用提供部分科能融合应急通信能力，将是非常有益的。互联网对科能融合应急通信的有效支持，将有助于充分利用和整合现有资源，作为原有应急有段的有效补充。
互联网的核心设计理念是“端到端透明性”，“端到端透明性”载（与通信相关）和应用相互分离，简化网络的设计，将尽可能多的复杂性和控制放在用户终端上。著名的互联网“沙漏”模型形象的描绘了互联网的特征，如图5-21所示。
图5-21 互联网的“沙漏”模型
互联网将应用的控制权完全交给了用户，把流量的控制权交给了用户，引发了互联网安全问题和流量控制问题的凸显，同时IP网络以尽力而为（Best Effort）的方式工作，完全依靠终端的适配，难以支持需要服务质量（QoS）保证的应用和业务。基于互联网的这些特点，我们不难看出，互联网对于应急通信的支持是有限的，例如，需要保证通信质量和安全的政府机构之间的通信就不适宜借助于互联网进行通信。
1.2、互联网支持科能融合应急通信关键技术
互联网设计之初是科研团体或政府研究机构管理下的非商用网络，没有考虑任何应急通信的需求，因此，互联网缺少支持科能融合应急通信的基本架构和基本能力，随着近几年各种灾难事件的频发，科能融合应急通信的需求也提到了互联网技术研究的日程上，IETF（互联网工程任务组）建立了"基于互联网技术的应急议案工作组”（Emergency Context Resolutionwith Internet Technologies,ECRIT）,专门研究互联网的科能融合应急通信问题。
科能融合应急通信的各种需求当中，互联网首要考虑的问题应该是对最基本的紧急呼叫的支持，解决公众到政府机构之间应急通信的需求。紧急呼叫会涉及到以下3个关键问题：
1) 互联网支持科能融合应急通信的网络结构：互联网的设计没存考虑过应急通信的需求，因此缺少支持应急通信的网络架构。
2) 终端位置信息的获取：紧急呼叫采用的是就近接入的原则，呼叫应该被正确路由接入离终端最近的紧急呼叫中心，因此，互联网也需要提供一定的技术对用户的位置信息进行解析，以达到正确路由紧急呼叫的目的。
3) 紧急呼叫的路由寻址：获取到终端的位置信息后的任务就是要能够根据终端的位置信息将呼叫路由到离终端最近的紧急呼叫中心，这就涉及到如何找到最近的紧急呼叫中心的问题，也就是紧急呼叫的路由寻址。
1.互联网支持科能融合应急通信的网络结构
互联网上的用户可以通过IP语音通信、IP视频通信方式向位于互联网上的紧急呼叫中心发起紧急呼叫，也可以在互联网上通过即时消息方式与紧急呼叫中心进行紧急通信。
互联网上为了支持紧急呼叫业务，一些网络实体是必须的，一些网络功能也是要参与其中的。互联网上的紧急呼叫主要涉及以下功能实体：
1）公共安全应答点/紧急呼叫中心（PublicSafetyAnsweringPoint,PSAP）:互联网上提供紧急呼叫业务，至少要提供一个架设在互联网上的紧急呼叫中心，支持IP语音呼叫（例如，使用SIP作为呼叫控制信令，RTP作为媒体传输协议）。
2）互联网接入服务提供者（Internet Access Provider,IAP）：为广大用户和互联网之间提供物理和数据链路连接的服务提供者，例如，专线运营者、拨号接入服务运营者等，在紧急呼叫中主要负责用户位置信息的获取。
3）互联网应用服务提供者（Application Service Provider,ASP）:互联网应用层业务提供者，包括语音业务提供者（VoiceServiceProvider,VSP）、文本业务、视频业务等。
4）映射服务：负责用户的位置信息与紧急呼叫中心的URI之间的映射，直接提供离用户最近的紧急呼叫中心的URI或指向负责提供紧急呼叫中心位置的代理实体，协助路由紧急呼叫。
5）紧急呼叫路由代理（Emergency Service Renting Proxy,ESRP）:支持紧急呼叫路由的实体，负责调用位置信息映射服务功能获得合适的PSAPURI或者另一个ESRPURI,实际中紧急呼叫路由代理提供者可以由多种实体扮演，例如：理等。
图5-22 互联网路由紧急呼叫架构
图5-22是“RFC5012”当中的互联网路由紧急呼叫的架构图，当中涉及到以上介绍的一些实体。
图5-22展现了呼叫过程中实体之间可能发生的交互行为，从图中可以看出紧急呼叫实体有很多部署方案，不同的部署方案，具体的实体交互行为和信息也不尽相同，图中列岀了所有可能发生的交互行为，图中重叠的部分表示一些功能可以被分解出来由单独的实体来完成，具体的交互行为描述如下：
1）位置信息可能由终端驻地自己提供；
2）位置信息可能从互联网接入服务提供者处获得；
3）紧急呼叫者可能需要请求映射服务获得对应于自己位置的合适的PSAP（或相关信息），除了根据位置信息选择PSAP,也可以考虑其他的属性，例如，合适的语言；
4）紧急呼叫者可能获得紧急呼叫路由代理提供者的协助来路由呼叫；
5）紧急呼叫路由代理提供者需要位置信息，用于下一步请求映射服务；
6）紧急呼叫路由代理提供者可能需要请求映射服务获得紧急呼叫路由信息；
7）对于基于网络的紧急呼叫路由需要紧急呼叫路由代理提供者前转呼叫到PSAP；
8）对于基于终端的紧急呼叫路由将由终端（紧急呼叫者）自己调用映射服务和初始化连接，直接与PSAP建立连接，不需要任何中间任何支持紧急呼叫的路由实体参与。
5）紧急呼叫路由代理提供者需要位置信息，用于下一步请求映射服务；
6）紧急呼叫路由代理提供者可能需要请求映射服务获得紧急呼叫路由信息；
7）对于基于网络的紧急呼叫路由需要紧急呼叫路由代理提供者前转呼叫到PSAP；
8）对于基于终端的紧急呼叫路由将由终端（紧急呼叫者）自己调用映射服务和初始化连接，直接与PSAP建立连接，不需要任何中间任何支持紧急呼叫的路由实体参与。
2.终端位置信息的获取
用户终端位置信息包括行政位置信息和地理位置信息。行政位置信息是指通过其他一些参考系统描述的位置信息，例如行政区域名称、街道地址名称等；地理位置信息是指用经度、纬度、高度标识的终端位置信息，例如使用WGS-84坐标系（经纬度坐标系）描述位置信息。
互联网紧急呼叫中的一个关键问题就是终端位置信息的获取，那么如何以及何时添加位置信息到VoIP紧急呼叫信令消息中呢？一般情况下，有3种方式获得位置信息：
1）用户代理插入：呼叫者的用户代理插入位置信息到呼叫信令消息当中。
2）用户代理提供参考信息：呼叫者的用户代理通过固定的或暂时的标识指向位置信息，这些位置信息一般存储在专门的位置服务器中，PASP、ESRP或其他授权的实体会根据标识到位置服务器中去取。
3）代理插入：呼叫路径中的代理插入位置信息或位置参考信息，例如：ESRP。
3.紧急呼叫的路由寻址
紧急呼叫的路由寻址是指互联网上的映射服务器应具备根据紧急呼叫消息中携带的紧急呼叫的统一资源名称（Uniform Resource Name,URN）和用户终端位置信息映射为相应的紧急呼叫中心URI的能力，映射服务客户端应具备能够正确路由该呼叫的能力。
从图5・22中我们可以看到，紧急呼叫的路由根据网络部署的不同存在差异，总的来说可以分为网络负责的路由以及终端负责的路由两种方式。
（1）网络负责的路由方式
此种方式，用户代理只需要具备发起带有紧急呼叫标识（例如，11。）的紧急呼叫功能即可，应用/语音服务提供者识别出紧急呼叫标识，应将其路由到ESRP,ESRP向位置信息映射服务器发起映射请求（带有终端位置信息），位置信息服务器返回适合的PSAPURI,ESRP根据PSAPURI信息负责将紧急呼叫路由到相应的PSAP。
（2）终端负责的路由方式
此种方式，终端用户代理需要在发起紧急呼叫前或同时，向位置信息映射服务器发起映射请求（带有终端位置信息），位置信息映射服务器返回适合的PSAPURI,终端代理根据PSAPURI信息负责将紧急呼叫连接到相应的PSAP。一般情况下此方式不可取，将PSAPURI暴露给终端代理是一个非常危险的行为。当然，位置信息映射服务器也可以在返回终端映射响应的时候，只返回选定PSAP的参考信息，要借助网络才能翻译这些参考信息为PSAP的地址，将其正确路由到目的地。
无论哪种路由方式，调用位置信息映射服务的客户端（用户代理或ESRP）都需要初始化映射请求，通过映射协议发送到映射服务器。目前，比较合适的映射协议为LOST（Location-to-ServiceTranslation）,具体可参考RFC5222。
除了上述的一些关键技术，互联网上的紧急呼叫还要面临互联网上的安全问题，如何保证相关网络服务器的安全，防止信息的篡改和泄密，都是紧急呼叫架构设计和协议设计时必须重点考虑的问题。
二、下一代网络支持科能融合应急通信
2.1概述
下一代网络（Next Generation Network,NGN）最主要的特征是承载网络采用分组技术,实现了网络和业务分离，是一个能够同时提供语音、数据、多媒体等多种业务的综合性的、全开放的网络体系。NGN的概念在业界一直很难给出一个明确的界定和定义，随着网络技术和应用的发展，其含义和核心内容也在不断发生变化。目前来看，以IMS技术为核心的网络结构逐渐成为NGN的主流定义，在此概念下，NGN主要包括PSTN/ISDN仿真子系统、IP多媒体子系统和流媒体子系统等组成部分。紧急情况下，NGN利用其先进的技术架构和开放的网络体系，可实现对科能融合应急通信的有效支持，从而满足紧急情况下公众到政府或机构的科能融合应急通信需求。
2.2 NGN架构下支持科能融合应急通信的要求
随着NGN技术的逐步完善和科能融合应急通信能力需求的逐渐清晰，在NGN架构下为实现应急通信能力，网络设备和用户设备的要求也越来越明确，例如，针对紧急呼叫就近接入、用户呼叫定位和紧急情况下的路由域选择，对网络和用户设备具有如下要求：
1）就近接入：应急情况下，网络应将紧急呼叫就近路由到应急指挥中心/联动平台。
2）呼叫定位：紧急呼叫发生时，用户或网络应将用户位置信息发送给应急指挥中心/联动平台，为应急指挥中心/联动平台做出快速反映、釆取紧急措施提供准确的用户地理位置。用户位置信息的提供应遵循两点要求。
①终端获取自身位置信息要求。当终端能提供自身位置信息时，终端应将位置信息插入紧急呼叫请求；对于无法提供自身位置信息的终端，如果能够从接入网获取自身位置信息，终端应能够将位置信息插入到紧急呼叫请求中。
②网络获取终端位置信息要求。在终端没有提供自身位置信息情况下，如果网络需要详细的终端位置信息，核心网应从接入网获取终端位置信息并将其插入紧急呼叫。
3）域选择：呼叫路由的CS域或PS域选择也对终端或网络提出要求。
①用户UE能力要求：当UE只能接入CS域或PS域中的一种网络域时，则直接通过CS域或PS域发起紧急呼叫；当UE可同时附着CS域和PS域时，UE应优先选择CS域发起紧急呼叫，若UE的CS域或PS域的紧急呼叫请求被拒绝，则UE应发起另一个域的紧急呼叫。
②网络能力要求：若CS域（如PSTN）或PS域核心网能够将紧急呼叫路由到CS域（如PSTN）或PS域的应急指挥中心/联动平台，则应直接路由；反之，则需要通过MGCF路由到PS域或CS域（如PSTN）的应急指挥中心/联动平台。
2.3 基于IMS的科能融合应急通信技术应用
目前业界普遍认为，IMS是下一代网络的核心网，所以IMS对科能融合应急通信的支持能力将直接反映出下一代网络的科能融合应急通信能力。下一代网络针对科能融合应急通信釆取的策略很大程度上需依赖IMS核心网来实现，因此，本节将以IMS技术为核心对NGN支持科能融合应急通信的技术方案进行介绍，包括基于IMS技术的科能融合应急通信体系架构、应急会话业务流程、应急会话注册、建立和基于IMS的用户定位等内容。
1.IMS概述
（1）IMS技术发展概述
3GPP在R5阶段提出了分组域IMS的基本框架，并在R6、R7阶段对IMS进行了分阶段的完善。IMS技术以其接入无关性、完全的业务与控制分离的重要特点受到了业界高度关注。IMS为未来的多媒体应用提供了一个通用的业务平台，它是向全IP网业务提供体系迈 进的重要一步。
在R5中，IMS主要以UMTS（UniversalMobileTelecommunicationsSystem,通用移动通信系统）分组域网络作为其IP媒体业务的接入和承载，从R6开始，所有IP网络，包括WLAN以及所有能够通过SIP等与IMS进行交互的网络，都可以接入或连接到IMS,网络向全IP融合。R7增加了固定宽带的接入，目前正在进行研究，预计对网络结构没有影响，但对P-CSCF的功能要求需要增强，从而满足对固定宽带设备的接入能力。
从目前的研究进度来看，IMS应用于移动的标准已经成熟，但是基于IMS的网络融合技术标准还处于发展阶段。由于有线和无线网络在网络带宽、终端鉴权、位置信息和资源管理等多方面存在差异，TISPAN在这些方面对IMS加以扩展，实现固定接入。但固定和移动IMS在业务能力差异、体系架构差异、协议差异等方面的问题将成为IMS能否实现固定和移动网络融合的关键问题。
（2）IMS功能结构
IMS可以完成呼叫的发起、保持、释放等功能。另外，它还要对多媒体流进行转换控制以及对多媒体业务进行支持，所以包含更多的功能实体，它们分别完成不同的功能。支持IP多媒体应用的全套解决方案由终端、GERAN或UTRAN无线接入网、GPRS核心网、IP多媒体核心网子系统的一些特殊功能单元组成，主要包括呼叫会话控制功能（CSCF）、媒体网关控制功能（MGCF）、IP多媒体网关功能（IM.MGW）、多媒体资源功能（MRF）、签约定位功能（SLF）、出口网关控制功能（BGCF）、信令网关功能（SGW）等。IMS的功能结构如图5-23所示。
图5-23 IMS的功能结构图
2.IMS支持紧急通信的系统架构
（1）IMS紧急通信体系架构
当IMS用户漫游或游牧到非归属网络覆盖时，由于紧急呼叫不是预定业务，为了支持紧急通信，应由拜访地提供紧急呼叫服务，因此，在原有IMS网络系统架构中引入紧急呼叫会话控制功能（简称E-CSCF）实现紧急呼叫。IMS紧急通信系统架构如图5-24所示。
图5-24 IMS紧急通信体系架构
在IMS紧急通信体系架构中，有以下几点需要注意：
1）在紧急通信中P-GSCF和E-CSCF一直位于同一个网络中，当UE处于漫游状态时，实现紧急通信的网络为UE所访问网络。
2）为了简化起见，图5-24中并没有列出所有的功能实体，例如IBCF、I-CSCF.MGCF和BGCF。
3）在某些地区（如北美），有可能支持位置重获功能实体（Location Retrieval Function,LRF）,LRF可包含路由判断功能（Routing Determination Function,RDF）组件和位置服务器（如GMLC）组件。
4）基于本地策略，E-CSCF可通过ECS将IMS紧急会话路由至应急指挥中心/联动平台。
（2）IMS紧急通信相关功能实体
IMS紧急通信体系架构中，涉及的关键功能实体包括终端（UE）、代理呼叫会话控制功能（P-CSCF）、紧急呼叫会话控制功能（E-CSCF）、位置获取功能（LRF）、媒体网关控制设备（MGCF）,下面是各功能实体在紧急呼叫中的功能和作用。
♦ 终端
-UE应能够识别紧急会话建立请求；
-进行紧急注册时，UE可以在紧急会话注册请求中加入紧急公共用户标识符（Emegency Public UserIdentifier）。
-在UE已经完成IMS注册但没有进行紧急会话注册的情况下，如果UE处于归属网络（如IP-CAN不支持漫游的情况），则UE可进行IMS紧急会话建立；否则，UE需进行IMS紧急会话注册。
-UE有能力在会话请求中加入紧急业务标识。
-在“匿名用户”情况下，应在紧急会话建立请求中包含设备标识符。
-如有可能，首先尝试在CS域进行紧急呼叫。
-UE可处理带有"emergency"类型的380应答消息，该服务为可选业务。
-UE可处理带有*'IMSemergencyregistrationrequired"标识的响应消息。
-其他一些普通的UE能力要求可参考TS22.101。
另外，在UE发起紧急会话请求过程中，为了在网络中对该请求进行正确的处理，会话请求中应附带以下字段：
-紧急会话指示。
-如完成了IMS紧急会话注册，需附带紧急公共用户标识符，如没有完成IMS紧急会话注册，则可附带任意一个注册的公共用户标识符。
-应急业务类型（可选，可包含在紧急会话指示中）。
-在有能力的情况下提供UE的位置信息。
-在有能力的情况下，提供与紧急公共用户标识符相关联的TelURIO
♦ 代理呼叫会话控制功能
-处理带有“紧急公共用户标识符”的注册请求，并在用户归属网络将该请求转发到IBCF或I-CSCF中。
-检测紧急会话建立请求。
-允许或拒绝紧急会话请求。
-允许或拒绝“匿名”紧急会话请求。
-防止在非紧急会话中带有“紧急公共用户标识符”。
-可查询IP-CAN,获得位置标识符。
-在同一个网络中选择合适的E-GSCF处理紧急会话请求。
-优先处理紧急会话。
-如果UE提供了呼叫方的TelURI,则P-CSCF检查TelURI的有效性。同时，如果知道TelURI与紧急公共用户标识符相关联，则P-CSCF在会话建立请求过程中提供TelURIO
-作为紧急会话建立尝试的处理结果，P-CSCF可利用带有“IMS emergency registration requiredM标识的消息对UE进行响应。
♦ 紧急呼叫会话控制功能
-从P-CSCF接收紧急会话建立请求。
-如果在紧急会话请求中没有包含UE位置信息或有附加的位置信息需求，则E-CSCF应通过LRF获取UE位置信息。
-如果UE设备提供了位置信息，在需要的情况下，E-CSCF可请求LRF对位置信息进行验证。
-确定或查询LRF,保证正确的路由信息或应急指挥中心/联动平台目标地址。
-将包括匿名会话建立请求在内的紧急会话建立请求路由至适当的目的地。
-隹国家需要的情况下，E-CSCF可将P-assertedID或UEID内容发送至LRFO
-基于本地策略，E-CSCF可将紧急IMS呼叫路由至ECS进行进一步呼叫处理。
♦ 位置获取功能
位置获取功能实体（LRF）可获得发起IMS紧急呼叫的UE位置信息，LRF有可能包括路由判断功能组件（RDF）和位置服务器组件（如GMLC等）。
RDF为E-CSCF提供紧急呼叫路由信息，RDF与位置功能实体（如GMLC）相互作用从而处理ESQK（EmergencyServiceQueryKey）的分配和管理。应急指挥中心/联动平台利用ESQK对LRF进行查询，获取位置信息和回叫号码。
LRF发送给E-CSCF的消息中包括路由信息和其他紧急业务相关的参数，具体参数内容取决于本地的紧急通信规范。例如，在北美地区，该消息中可包括ESQK、ESRN、LRO、UE本地号码、应急指挥中心/联动平台的SIPURI或者Tel-URI等。
为了给E-CSCF提供最近的应急指挥中心/联动平台地址，LRF可能需要UE的位置变化信息。例如，可能需要向应急指挥中心/联动平台提供UE的初始估计位置，并且在需要的情况下对UE的位置信息进行更新，此时，LRF需存储E-CSCF提供的紧急会话记录并在会话结束后释放该记录。LRF发给E-CSGF的消息中（如ESQK）应包含识别LRF和LRF中紧急会话记录的相关信息，该信息在会话建立阶段通过SIPINVITE消息或MGCF发出的SS7ISUP信令消息发送给应急指挥中心/联动平台，应急指挥中心/联动平台可用这个消息向LRF请求UE的初始估计位置或对位置信息进行更新。
♦ 媒体网关控制设备
MGCF可根据本地策略判断来自CS域（如PSTN）的呼叫是否为应急指挥中心/联动平台的回叫，如果MGCF收到CS域（如PSTN）的呼叫被确定为应急指挥中心/联动平台的回叫，则MGCF可在呼叫建立请求里添加“应急指挥中心/联动平台回叫指示”。
（3）IMS紧急通信的相关接口
IMS紧急通信体系架构图中的各功能实体之间通过Gm、Mw、Mm、Mi/Mg、MI、Le、Mw、Mm/Mw等接口实现信令、路由等消息的交互，这些接口含义和使用协议如下：
-Gm（UE和P-CSCF之间的接口），Gm接口可支持UE和IMS网络之间的所有信令交互，如注册信令和会话控制信令等，接口采用SIP。
-Mw（P-CSCF和E-CSCF之间的接口），Mw接口用于代理会话控制功能实体与紧急呼叫功能实体之间交互相关的信令消息，如注册信令和会话控制信令等，接口采用SIP。
-Mm接口是E-CSCF和PS域应急指挥中心/联动平台之间的接口，E-CSCF应根据LRF提供的路由信息将紧急呼叫路由到PS域的应急指挥中心/联动平台，该接口釆用SIP。
-Mi/Mg接口是E-CSCF和BGCF/MGCF之间的接口，E-CSCF根据LRF提供的路由信息将紧急呼叫路由到CS域的应急指挥中心/联动平台（通过BGCF/MGCF）,该接口釆用SIP。
-MI接口是E-CSCF和LRF之间的接口，E-CSCF通过该接口从LRF获取UE位置信息和呼叫路由信息。
-Le接口是应急指挥中心/联动平台和LRF之间的接口。应急指挥中心/联动平台通过该接口获得UE的初始位置信息和实时更新的位置信息。
-Mw接口（S-CSCF和P-CSCF之间的接口），Mw接口用于服务会话控制功能实体和代理会话控制功能实体之间交互相关的信令消息，如会话控制信令，该接口采用SIP。
-Mm/Mw接口为PS域应急指挥中心/联动平台和S-CSCF之间的接口，应急指挥中心/联动平台通过该接口呼叫UE,该接口釆用SIP。
3.IMS紧急会话业务流程
（1）UE可以识别紧急会话的情况
在UE能够识别紧急会话请求的情况下，紧急通信业务流程如图5-25所示。
图5-25 终端设备检测紧急呼叫
具体的执行步骤如下：
1）UE检测紧急会话请求。
2）UE的性能和资源确认。如果其他正在进行的会话占用了资源导致UE无法建立紧急呼叫，则UE将中止正在进行的普通会话，释放相应的承载资源。
3）承载注册。如果需要UE进行承载注册，则UE向IP-CAN进行注册；如果UE已完成注册，则不必再次注册。根据IP-CAN的功能，UE可能会在该阶段被分配一个IP地址。
4）承载资源请求。如果需要，IP-CAN应该为相关的IMS信令传输保留承载资源，UE应标识紧急会话业务“指示”。如果IP-CAN在步骤3）没有给UE分配IP地址，则IP-CAN在承载资源请求过程中为UE分配IP地址。
5）执行P-CSCF发现步骤，也就是说，UE在归属网络中査询适用于该紧急会话的P-CSCF,P-CSCF发现步骤与IP-CAN有关。
6）IMS紧急会话注册。
IMS网络中，如果UE能够识别紧急会话，UE将利用IP地址向P-CSCF发起IMS紧急会话注册，IP地址是在步骤3）或4）分配的。IMS注册请求中应包含紧急公共用户标识符，该标识符中包含相关联的TelURI,从而可以实现PSTN对用户的反向呼叫。
P-CSCF可根据本地策略设定注册时间期限或者在注册请求过程中改变该注册时限，并增加相应的标识符。当归属网络S-GSCF接收到注册请求，S-CSCF可以从注册请求中获得注册时限，并将该注册时限告知UE。
如果UE没有能力识别紧急会话，则不发起IMS紧急注册请求，而应该按步骤7）描述的方法建立与P-CSCF的紧急会话。
7）建立紧急会话。如果进行了IMS紧急会话注册，则按照带有紧急会话“指示”及紧急公共用户标识符的会话建立流程，由UE发起IMS紧急会话；如果没有进行IMS紧急会话注册，则按照带有紧急会话“指示”及任意已注册公共用户标识符的会话建立流程，由UE发起IMS紧急会话。
上述过程是否被UE分别执行或者其中一部分自动执行，取决于终端的应用和UE的配置。例如，UE的多媒体应用能够发起应用级注册，此时，步骤2)~4)必须执行，从而支持应用程序发起的操作，这些步骤中，可能需要与UE进行交互作用。
(2)UE不能识别紧急会话的情况
如果UE不能识别紧急会话，则会话建立请求通过普通会话建立流程发送到当前访问的PLMN或本地PLMN的P-CSCF。前者主要应用于用户漫游情况，而后者既可应用于漫游情况也可用于非漫游情况。在发送会话建立请求前，UE必须通过普通会话注册流程在IMS网络中注册。当P-CSCF检测到紧急会话建立请求时，可以根据本地策略来决定釆取以下哪一种处理方法(例如，通过检查接入类型)：
1)P-CSCF可拒绝该呼叫请求并在应答中标识出该请求为紧急呼叫，UE收到该应答后，将尝试发起CS域紧急呼叫或按照“UE可以识别紧急会话的情况”的步骤重新发起紧急会话请求。
2)当UE处于非漫游状态时，本地PLMN或当前访问PLMN的P-CSCF也可以允许该紧急会话请求，并将会话请求插入紧急“标识”并发送至E-CSCF,此时，不需要通知UE会话已被标注为紧急会话，UE可将该会话视为正常的会话建立。
(3)利用LRF/RDF建立紧急会话
图5-26描述了利用LRF/RDF获取位置和路由信息建立紧急会话的流程。
图5-26 利用LRF/DRF建立紧急会话流程
1)UE发送一个包含紧急URI信息的SIPINVITE消息，发起紧急会话请求。
2)如果需要，IMS网络可以访问LRF查找UE位置信息。
3)如需要，LRF可调用RDF来确定最合适的目标应急指挥中心/联动平台，LRF向IMS网络返回必要的位置或路由信息。
4)IMS网络利用LRF返回的路由信息，将紧急会话请求路由至最佳应急指挥中心/联动平台。
另外值得注意的是，紧急会话中，如果LRF在步骤3)为IMS网络提供了ESQK或者其他的专用资源，则IMS网络应在会话释放时通知LRF,以便LRF释放相应的资源。
4.IMS紧急会话注册
3GPPTS23.228报告介绍了IMS会话注册的一般流程，为了适应紧急通信的需要，TS23.167针对IMS紧急会话情况下的注册流程做了适当改动，具体如下：
1）当同时满足以下几种条件的情况下，将由UE发起IMS紧急会话注册：
①UE没有进行IMS注册或者UE虽然已进行了IMS注册但处于异地漫游状态，并且UE不知道被指派的P-CSCF来自被访问的网络。
②UE有足够的授权鉴别IMS网络。
③UE能够识别紧急会话。
另外，如果在发起紧急会话请求后，UE收到的响应为“需进行IMS紧急会话注册”，则UE应发起IMS紧急注册。
2）在紧急注册请求中，UE应利用“紧急公共用户标识符”，该标识符可被用于应急指挥中心/联动平台和与应急指挥中心/联动平台相关联的已注册地址之间的路由调用，并利用该标识符通知归属网络取消漫游限制。
3）用户归属网络应取消紧急注册请求的漫游限制。
4）服务的发起或终止不使用“紧急公共用户标识符”。
P-CSCF对带有紧急公共用户标识符的注册请求处理方式与其他的注册请求基本一致，但在带有紧急公共用户标识符的注册请求中P-CSCF可根据本地策略设置注册时限或者改变注册时限，并继续将注册请求发送给归属网络的IBCF或I-CSCFO如果注册时限被P-CSCF修改，则归属网络的S-CSCF将获得修改后的注册时限并将该时限返回给UE。
5.IMS紧急会话建立
（1）正常服务情况下的IMS紧急会话建立
如果UE能够识别用户正在发起的是紧急会话请求，则将在紧急会话建立请求中加入紧急业务“指示”。当UE与网络的连接处于CS域时，UE将发起CS域紧急呼叫；当UE只连接在PS域并且支持IMS紧急业务时，则发起PS域紧急呼叫；如果UE与CS域和PS域同时连接，则按照网络的默认规定发起相应的紧急呼叫，在没有明确的规定时，以CS域为优先选择域。IMS核心网的紧急呼叫应在当前拜访的IMS核心网中进行。
如果向CS域发起的紧急呼叫失败，则在UE有能力的情况下应尝试发起PS域紧急会话；同样，如果向PS域发起的紧急呼叫失败，则在UE有能力的情况下应尝试发起CS域紧急会话。如果UE发起会话请求并收到标注有“紧急”指示的380响应（可选服务），则UE应重新尝试发起带有紧急“指示”的会话请求，并优先考虑CS域。
如果UE没有权限鉴别IMS网络，则UE不应发起IMS紧急注册而应直接与P-CSCF建立紧急会话，具体过程如“未注册情况下的IMS紧急会话建立”部分所述。
当P-CSCF接收到紧急会话请求后，将遵循3GPPTS23.228介绍的普通会话流程，同时针对紧急会话的特点做适当改进，具体如下：
1）首先，由IMS网络实体P-CSCF检测紧急会话。
2）当归属网络的P-CSCF能够识别出紧急号码或紧急“指示”时，将对UE做出应答并告知UE应该在拜访网络中发起紧急呼叫。
3）当紧急呼叫请求带有紧急“指示”但没有注册在IMS网络上时，参见“未注册情况下的IMS紧急会话建立”。
4）如果UE注册在IMS网络但发起请求中没有紧急“指示”，同时P-CSCF可以检测紧急会话业务请求时，执行“UE不能识别紧急会话”流程。
5）当接收到会话请求后，如果识别为紧急会话，P-CSCF将检查UE是否提供用于身份识别的TelURI,如果提供，则P-CSCF检查TelURI的有效性；如果不提供并且P-CSCF可获知TelURI与“紧急公共用户标识符”是相关联的，则在紧急会话建立请求过程中将TelURI提供给E-CSCFO
6）P-CSCF可査询IP-CAN,获得位置标识符。
7）当紧急会话和非紧急会话同时存在时，P-CSCF将优先处理紧急会话。
接收到P-CSCF发出的紧急会话请求后，E-CSCF将按以下步骤进行：
1）如果E-CSCF需要位置信息但紧急会话请求中没有包含相应信息，或者E-CSCF需要其他的附加位置信 息，E-CSCF将利用“基于IMS技术的用户位置信息获取”描述方法提取位置信息。
2）如果UE能够提供位置信息，在需要的情况下E-CSCF可以请求LRF验证该位置信息。
3）基于紧急业务类型和UE的位置信息，可利用LRF确定相应的路由信息。
4）如果路由过程中需要用到未知的UE位置信息，E-CSCF确定应急指挥中心/联动平台的默认路由目的地地址。
5）如果应急指挥中心/联动平台与IMS网络有连接点，E-CSCF将紧急会话请求直接转发至应急指挥中心/联动平台。
6）如果应急指挥中心/联动平台在PSTN/ISDN或者CS域有连接点，E-CSCF利用Tel-URI将会话请求转发至出口网关控制功能（BGCF）或媒体网关控制功能（MGCF）,从而实现在普通交换电话网（GSTN）的路由。该号码格式与CS域紧急呼叫格式相同，MGCF可插入在PSTN/CS信令中获得的任意位置信息。
（2）未注册情况下的IMS紧急会话建立
当未注册情况下UE向P-CSCF发起紧急会话请求时，该请求中将包括“匿名用户”和“紧急业务指示气基于本地策略，P-CSCF可以拒绝该“匿名用户”的紧急会话请求并发送相应的错误指示，此时，UE应停止向该网络发送紧急会话请求；如果P-CSCF接受了该“匿名用户”的紧急会话请求，则P-CSCF不再考虑UE和P-CSCF之间是否是安全的连接，并将该会话请求转发至适当的E-CSCF。
E-CSCF在路由匿名紧急会话消息时也应遵守“正常服务情况下的IMS紧急会话建立”部分介绍的规则和流程。
6.基于IMS技术的用户位置信息获取
紧急通信中，用户的位置信息获取意义重大。获得用户的位置信息将有助于知道用户的具体位置，为紧急处理中心做出快速反应，釆取紧急措施提供明确的地理位置；有助于获得用户的实时位置变化（如用户在车中或飞机上）；同时，可以有效地制定紧急通信的呼叫路由路径，避免通信线路堵塞或防止泄密。在紧急会话中，基于IMS技术的用户定位可以从以下几种情况考虑：
1）UE知道自身所处的位置；
2）UE从网络获得自身位置信息；
3）由IMS核心网获取位置信息，详细的处理流程如图5-27所示；
4）还有一种情况是，当IMS核心网中的紧急会话路由不需要位置信息时，紧急会话路由的确定和位置信息提取可通过紧急会话服务器实现（可选功能），此时IMS核心网不需要该位置信息。
图5-27 IMS紧急会话用户定位流程
1）用户发起紧急呼叫
2）如可能，UE确定其自身所在位置或位置标识符。如果UE不能获得当前位置，在有能力的情况下，UE可向IP-CAN请求其位置信息，如果IP-CAN提供该功能，则IP-CAN向UE发送UE的位置信息以及位置标识符。
3）UE设备向IMS核心网发送带有紧急会话指示的“INVITE”消息。该“INVITE”消息应包含当前终端所有的位置相关信息，可以是地理位置信息也可以是位置标识符。在UE不能提供任何位置信息的情况下，IMS核心网可向LRF査询UE的位置信息。“INVITE”消息中也可以包含定位解决方案和UE支持的定位方法等信息（可选）。
4）如果在步骤3）获得的位置信息是真实的并且足够用来确定恰当的应急指挥中心/联动平台，则可跳至步骤7）继续进行。如果出现以下几种情况，如定位信息不足、IMS核心网需要紧急路由信息、IMS核心网需要验证位置信息，或者IMS核心网需要将UE的位置标识符映射到地理位置信息中，则IMS核心网向LRF发送位置请求。该请求中应包含识别IP-CAN和UE设备的信息、接入UE设备的方法（如UE的IP地址）以及UE设备所能提供的所有位置信息。同时，位置解决方案和UE支持的定位方法也可以作为可选项包含在该请求中。
5）LRF可能已经获得IMS核心网请求的位置信息，也有可能由LRF发出UE位置信息请求。获得位置信息的方法根据UE在IMS网络中的接入技术不同而有所区别。当采用GPRS接入方式时，定义在TS23.271中的PS-NI-LR或PS・MT-LR可以应用；如果终端支持，可以采用在0MAADSUPL："安全用户平面定位架构”和。MATSULP："用户平面定位协议”中定义的SUPL流程，它有助于建立UE和SUPL服务器之间的用户平面连接。步骤4）中提到的位置解决方案和UE支持的定位方法信息也可以用来帮助LRF确定定位方法。
LRF可调用RDF将在步骤4）或步骤5）中获得的位置信息转换为应急指挥中心/联动平台路由信息，LRF可根据区域需求，在一定时间和一定范围内存储位置信息。
6）LRF向IMS核心网发送位置信息或路由信息，LRF也可获得相关的自身鉴别信息（如ESQK）和所有在步骤5）中存储的信息。
7）IMS核心网利用步骤6）提供的路由信息或选择应急指挥中心/联动平台（基于步骤3）或6）提供的位置信息），发送包含位置信息和所有可能定位相关信息的请求，例如，包含应急指挥中心/联动平台使用的定位方法等。
7a）“INVITE”信号发送给MGCF/MGW；
7b）IAM继续发送至应急指挥中心/联动平台；
7c）“INVITE，’信号直接发送至应急指挥中心/联动平台。
8）紧急呼叫建立完成。
9）应急指挥中心/联动平台可向LRF发送定位请求，获得目标UE的初始位置信息，也可请求LRF对目标UE的位置信息进行更新。应急指挥中心/联动平台可终止LRF在步骤7）中获得的位置及定位相关信息，也可以通过发送请求消息将相关信息发送到LRF。
10）LRF利用步骤5）中列出的方法获取目标UE的位置信息并获得在步骤5）中存储的UE信息。
11）LRF向应急指挥中心/联动平台返回初始位置信息或不断更新的位置信息，LRF可以在步骤9）中的定位请求前或请求后向应急指挥中心/联动平台发送初始位置信息。
12）紧急呼叫被释放。
13）IMS核心网告知LRF紧急会话结束，LRF删除步骤5）中存储的所有记录。
