CN101938727B - 一种实现紧急呼叫的方法及系统 - Google Patents

Abstract

本发明提供了一种实现紧急呼叫的方法及系统，对于一个SAE网络部署的位置服务采用的是SUPL技术，在UE接入到该SAE网络发起紧急呼叫时，由于表明了位置查询是用于紧急呼叫的，UE在接收到进行用户面初始化的通知，确定定位承载是服务于紧急呼叫的，从而发起紧急定位承载的建立。这样，实现了受限制模式下的UE接入到SAE网络的紧急呼叫。而且，由于该定位承载是专门服务于紧急呼叫的，因此，在已发起紧急呼叫的UE从非受限区域移动到受限制区域时，该紧急定位承载不会被释放，保证了紧急呼叫的连续性。

Description

一种实现紧急呼叫的方法及系统

技术领域

本发明涉及IP多媒体子系统(IMS，IP Multimedia Core Network Subsystem)域紧急呼叫技术，尤指一种当采用用户面定位服务(SUPL)技术时，用户终端(UE)接入到系统长期演进(SAE)网络下实现紧急呼叫的方法及系统。

背景技术

IMS是新一代通信网络的核心，IMS采用会话发起协议(SIP，SessionInitiation Protocol)体系，SIP规定通信与接入无关，并具备多种媒体业务控制功能与承载能力分离能力、呼叫与会话分离能力、应用与服务分离能力、业务与网络分离能力、以及移动网与英特网业务融合能力等特点。

由于IMS和接入无关的特点，IMS下的紧急业务(EMC，Emergency Call)可以建设在通用无线分组业务(GPRS，General Packet Radio Service)网络，或者系统长期演进(SAE，System Architecture Evolution)网络上，提供统一的紧急呼叫控制。

为了实现IMS下的紧急业务，定位服务是必不可少的业务，比如：需要根据UE的位置将紧急呼叫路由到合适的警局，警局出于安全、救援的目的，需要知道UE当前的位置信息等。

图1为现有UE通过接入SAE网络执行紧急业务的网络架构的示意图，如图1所示，主要包括：SAE网络部分、策略计费控制(PCC，Policy ChargingControl)部分、位置定位服务部分以及IMS紧急业务部分。其中，位置定位服务部分包括控制面定位服务(LCS，Location Service)和用户面定位服务(SUPL，Security User Plane Location)两种定位服务方式。

其中，SAE网络部分，用于提供底层的承载管理和移动性管理。SAE网络部分的网元包括增强的无线基站(eNodeB)、移动性管理实体(MME，MobilityManagement Entity)以及SAE网关(SAE GW)。eNodeB是下一代的无线接入网的主要空口资源的控制设备，可以提供更高的上下行速率，更低的传输延迟和更加可靠的无线传输。MME负责管理和存储用户设备(UE，User Equipment)的上下文，比如UE/用户标识、移动性管理状态、用户安全参数等，为用户分配临时标识，当UE驻扎在该跟踪区域或者该网络时，负责对该用户进行鉴权等。SAE GW为用户面功能实体，可以分为服务网关(S-GW，Serving GW)和分组数据网络网关(PDN GW，也称为P-GW)两种GW。S-GW是SAE系统与传统第三代合作伙伴计划(3GPP，The 3rd Generation Partnership Project)系统间的移动锚点，以及与演进的通用陆地无线接入网(E-UTRAN，EvolvedUniversal Terrestrial Radio Access Network)之间的移动锚点。P-GW是SAE与分组数据网络(PDN，Packet Data Network)的边界网关，负责PDN的接入、在SAE与PDN间转发数据等功能。

PCC部分，用于在底层承载层和上层业务层建立有效的策略、计费控制。PCC部分的网元包括策略和计费规则功能(PCRF，Policy and Charging RulesFunction)和策略和计费执行功能(PCEF，Policy and Charging EnforcementFunction)。PCRF是PCC部分的重要功能实体，用于控制策略和计费规则的获取、装配和下发等。PCEF是具体的策略和计费的执行点，通常位于GW功能中。在SAE网络中，PCEF功能位于PDN GW中。

位置定位服务部分包括控制面LCS和SUPL两部分。控制面LCS部分的网元包括增强的服务移动定位中心(E-SMLC，Enhanced SMLC)和网关移动定位中心(GMLC，Gateway Mobile Location Center)，其中，E-SMLC负责接收UE的测量报告、向UE下发定位参数、计算UE的物理位置等；GMLC负责向业务层提供位置信息、从承载层获取UE的位置信息。SUPL部分的核心网元为用户面定位平台(SLP，SUPL Location Platform)。另外，具有SUPL能力的UE被称为SET(SUPL Enabled Terminal)，也就是集成有定位模块(如A-GPS)的UE。

IMS紧急业务部分，用于控制和处理紧急呼叫的会话。IMS紧急呼叫部分包括归属用户服务器(HSS，Home Subscriber Server)、紧急呼叫会话控制功能(E-CSCF，Emergency Call Session Control Function)、位置请求功能(LRF，Location Require Function)和公共安全接入点(PSAP，Public Safety AccessPoint)。HSS位于归属网，用于管理用户的签约数据。E-CSCF位于拜访网，是控制紧急会话过程的核心网元。PSAP实际上就是警局。LRF是一个逻辑功能实体，为E-CSCF、PSAP等提供UE的位置信息，LRF可以独立部署，也可能包含在其它位置服务器中，比如集成在GMLC、SLP等中。

目前，在现有紧急呼叫的研究中，要求UE即使是在被限制服务的情况下，也应该能够发起紧急呼叫。UE被限制服务的情况有如下几种：

1、UE具有有效的普遍集成电路卡片(UICC，Universal Integrated CircuitCard)，是一个合法的IMS用户，在HSS中具备合法的用户身份，但是存在一定的服务限制，比如：在漫游地被限制服务、当前欠费不允许发起正常呼叫、在特定的小区或者路由区(Track Area)内被限制服务等。

2、UE具备有效的UICC卡，但是该卡上所记录的IMSI在HSS中是无效的。比如该UICC卡上所记录的IMSI，由于长期不使用已被HSS注销。

3、UE不具备有效的UICC卡，当然也不存在IMSI。

当UE处于上述被限制服务的情况时，在紧急呼叫中，称为受限制模式。对于受限制模式下的UE，该UE发起的正常网络附着、或业务建立请求，将会被网络所拒绝。而紧急呼叫应该能保证受限制模式的UE也能够得到紧急呼叫的支持。因此，3GPP在研究的分组演进系统(EPS，Evolved Packet System)网络对紧急呼叫的支持中，针对受限制模式的UE进行了一系列的技术改进，一个典型的改进就是促使受限制模式的UE通过紧急附着(Emergency Attach)附着到EPS网络，并建立专门用于紧急呼叫的紧急承载(Emergency Bearer)。

对于一个受限制模式下的UE，发起紧急呼叫需要执行如下主要步骤：

首先，建立紧急承载。大致包括：UE发起紧急附着，即UE在发起普通附着时，携带紧急标识，以告知承载网络当前附着是为了拨打紧急电话等紧急业务。承载网络接收到来自UE的紧急附着请求，通过紧急APN(E-APN，Emergency APN)建立专门用于紧急呼叫的缺省承载，该缺省承载主要用于信令控制。

然后，进行紧急呼叫。大致包括：UE发起紧急呼叫，即通过在一个正常的INVITE中携带紧急标识，表明当前呼叫请求是一个紧急呼叫。UE在被叫号码中填写紧急号码，如果UE在拜访地，则该紧急号码是拜访地的紧急号码；紧急呼叫被路由到E-CSCF，E-CSCF通过LRF查询PSAP的地址。LRF通过查询UE的位置信息来决定为UE服务的PSAP。E-CSCF在获得PSAP的地址后，将呼叫路由给PSAP，从而建立起紧急呼叫。其中，LRF通过查询位置服务器来获得UE的位置，并根据UE的位置信息来决定将呼叫路由到合适的PSAP。另一方面，LRF可以接受PSAP在紧急呼叫中对UE的位置查询请求，并从位置服务器获得UE的位置信息。

图2为现有技术中采用SUPL技术，SLP查询UE位置信息的流程图，如图2所示，包括如下步骤：

步骤200：SLP接收到位置请求后，向短信中心(或WAP网关)发送SUPL定位初始化(SUPL INIT)消息。在该SUPL INIT消息中，携带有SUPL会话标识(ID)、SLP支持的定位方式、SLP的运行模式等信息。

步骤201：短信中心(或WAP网关)将SUPL INIT包装成短消息(或WAP消息)。

步骤202：短信中心(或WAP网关)将包装后的SUPL INIT消息发送给带有SUPL定位能力的UE(SET)。

步骤203：SET接收到包装后的SUPL INIT消息后，主动向网络发起用于定位的用户面承载建立的过程。可选地，在SET和SLP之间进一步建立IPSec安全链接隧道。

步骤204：SET向SLP发送SUPL定位初始化响应(SUPL POS INIT)消息。在该SUPL POS INIT消息中，携带有SUPL会话ID、SET的SUPL能力等。

步骤205：在SET与SLP之间交互后续的定位消息。

步骤206：SLP向SET发送SUPL定位结束(SUPL END)消息，完成对SET的定位。

图2所示的流程中，如果SET接入到GERAN/UTRAN网络，则SLP可以通过短信网关或WAP网关向SET发送消息，在消息中包装SUPL INIT消息，以触发UE自行建立定位用的承载。根据图2所示的流程，在SET接入到SAE下，所建立的定位用承载是非紧急的。此外，在SLP发起的定位流程中，如果SET通过IP网络接入的情况下(如SET通过Wifi接入)，且SLP和SET之间存在Lup接口，则SLP可以通过Lup口直接向SET发送SUPL INIT消息，以触发定位过程的建立。

前面提到，控制面LCS和SUPL是当前两个主流的位置定位技术，其中，LCS技术，其定位信息、位置信息均承载在控制信道中；SUPL技术，其基本出发点是在UE和SLP之间建立一个用户面隧道，定位消息、位置信息均承载在该用户面隧道上。由于SUPL定位技术不依赖于具体的接入和承载网络，已经获得了广泛的应用。SUPL技术只需要在SLP和UE之间建立用于定位的用户面隧道(即用户面承载)，因此，SUPL技术可以灵活地部署在多种网络中，如GERAN、UTRAN、E-UTRAN等，因此现在已经获得了广泛的应用。

如果一个SAE网络部署的位置服务采用的是SUPL技术，则UE接入到该SAE网络发起紧急呼叫时，用于定位的承载创建过程存在的问题是，定位承载在某些情况下根本就不能创建。因为，现有SUPL技术下，用于定位的承载是由UE创建的，SLP通过短信中心或WAP网关通知UE创建定位用承载。但是，在受限制模式下，短信、WAP消息由于服务限制是不能发送给UE的，因此，当SAE网络部署的位置服务采用的是SUPL技术时，受限制模式下的UE接入到该SAE网络是不能实现紧急呼叫的。

即使是UE在非受限制模式(正常模式)下，采用SUPL技术来服务于紧急呼叫也可能会出现如下问题：即使UE能够创建定位用的承载，但是，该承载没有被标识为紧急的(即服务质量、优先级等没有被标记为紧急的)，这样，如果UE从非受限区域移动到受限制区域，所有的非紧急承载将被释放，也就是说，此时服务于紧急呼叫的定位承载(非紧急承载)也将被认为是非紧急承载而被释放。由此可见，当SAE网络部署的位置服务采用的是SUPL技术时，已发起紧急呼叫的UE，如果从非受限区域移动到受限制区域，是无法保证紧急呼叫下所需要的位置服务的连续性的，从而导致紧急呼叫切换的失败。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现紧急呼叫的方法，当采用SUPL技术，UE接入到SAE网络时，能够实现紧急呼叫，而且保证其连续性。

本发明的另一目的在于提供一种实现紧急呼叫的系统，当采用SUPL技术，UE接入到SAE网络时，能够实现紧急呼叫，而且保证其连续性。

为达到上述目的，本发明的技术方案是这样实现的：

一种实现紧急呼叫的方法，该方法包括：

用户面定位平台SLP接收到与紧急呼叫相关的位置查询，通知用户设备UE进行用户面定位初始化；

UE发起紧急定位承载的建立，并通过建立起的紧急定位承载服务后续紧急呼叫。

所述SLP接收到与紧急呼叫相关的位置查询，通知用户设备UE进行用户面定位初始化具体包括：

所述SLP判断所接收的位置查询请求中是否携带有紧急标识，如果携带有，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

该方法之前还包括：预先设置用于处理紧急呼叫处理的实体；

所述SLP接收到与紧急呼叫相关的位置查询，通知用户设备UE进行用户面定位初始化具体包括：所述SLP接收到位置查询请求，判断发起所述位置查询请求的实体是否为用于处理紧急呼叫处理的实体，如果是，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

所述SLP通过短信网关或WAP网关将所述用户面定位初始化消息SUPLINIT发送给UE。

所述用户面定位初始化消息经短信中心或WAP网关包装成短消息或WAP消息后，发送给所述UE。

所述用户面定位初始化消息包含在下行数据中。

所述UE被通知进行用户面定位初始化之后，发起承载建立过程，建立服务于紧急呼叫的紧急定位承载的建立之前，该方法还包括：

所述UE判断所述用户面定位初始化消息中是否携带有紧急标识，如果携带有，则所述UE主动发起服务于紧急呼叫的紧急定位承载的建立；

或者，所述UE确定自身是否是执行的紧急附着，如果是，则所述UE主动发起紧急定位承载的建立；

或者，所述UE判断出所述用户面定位初始化消息中未携带紧急标识，但所述UE确定自身是执行的紧急附着，则所述UE主动发起紧急定位承载的建立。

所述UE通过指定所述紧急定位承载的服务质量等级或其它信息，来表明所述承载是服务于紧急定位的，并向移动性管理实体MME发起紧急定位承载的建立过程。

一种实现紧急呼叫的系统，至少包括用户设备UE和用户面定位平台SLP，其中，

SLP，用于在接收到与紧急呼叫相关的位置查询，通知UE进行用户面定位初始化；

UE，用于发起紧急定位承载的建立，并通过建立起的紧急定位承载服务后续紧急呼叫。

所述SLP还用于，

判断发起所接收的位置查询请求中是否携带有紧急标识，如果携带有，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

所述SLP还用于，

查询发起所述位置查询请求的实体是否为预设的用于处理紧急呼叫处理的实体，如果是，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

还包括短信网关或WAP网关；

所述SLP通过短信网关或WAP网关将所述用户面定位初始化消息发送给UE。

还包括PDN GW网关；

所述SLP通过PDN GW向UE发送下行数据，在下行数据中包含发送给UE的所述用户面定位初始化消息。

所述UE还用于，

判断所述用户面定位初始化消息中是否携带有紧急标识，如果携带有，则所述UE主动发起服务于紧急呼叫的紧急定位承载的建立。

所述UE还用于，

确定自身是否是执行的紧急附着，如果是，则所述UE主动发起服务于紧急呼叫的紧急定位承载的建立。

从上述本发明提供的技术方案可以看出，对于一个SAE网络部署的位置服务采用的是SUPL技术，在UE接入到该SAE网络发起紧急呼叫时，由于表明了位置查询是用于紧急呼叫的，UE在接收到进行用户面初始化的通知，确定定位承载是服务于紧急呼叫的，从而发起紧急定位承载的建立。这样，实现了受限制模式下的UE接入到SAE网络的紧急呼叫。而且，由于该定位承载是专门服务于紧急呼叫的，因此，在已发起紧急呼叫的UE从非受限区域移动到受限制区域时，该紧急定位承载不会被释放，保证了紧急呼叫的连续性。

附图说明

图1为现有UE通过接入SAE网络执行紧急业务的网络架构的示意图；

图2为现有技术中采用SUPL技术，SLP查询UE位置信息的流程图；

图3为本发明实现紧急呼叫的方法的流程图；

图4为本发明实现紧急呼叫的第一实施例的流程图；

图5为本发明实现紧急呼叫的第二实施例的流程图。

具体实施方式

图3为本发明实现紧急呼叫的方法的流程图，如图3所示，包括：

步骤300：SLP接收到与紧急呼叫相关的位置查询，通知UE进行用户面定位初始化。

本步骤中，SLP识别接收到的是与紧急呼叫相关的位置查询，可以采用两种方式来实现：一种是，在SLP接收到的位置查询请求中携带有紧急标识；另一种是，SLP预先设置或存储用于处理紧急呼叫处理的实体的地址，而与紧急呼叫相关的位置查询来自于用于处理紧急呼叫处理的实体如指定的LRF。

步骤301：UE发起紧急承载的建立，要求建立服务于紧急呼叫的紧急定位承载的建立，并通过建立起的紧急定位承载服务后续紧急呼叫。

本步骤中，当UE接收到用户面定位初始化的消息时，如果用户面定位初始化消息中携带有紧急标识，则UE主动发起服务于紧急呼叫的紧急定位承载的建立；如果用户面定位初始化消息中未携带紧急标识，则UE进一步确定自身是否是紧急附着状态，如果是，UE主动发起服务于紧急呼叫的紧急定位承载的建立。

如果用户面定位初始化消息中未携带紧急标识，而且UE判定自身不是紧急附着状态，则按照现有流程执行即可。

从本发明方法可见，如果一个SAE网络部署的位置服务采用的是SUPL技术，在UE接入到该SAE网络发起紧急呼叫时，由于表明了位置查询是用于紧急呼叫的，UE在接收到用户面定位初始化的消息时，确定定位承载是服务于紧急呼叫的，从而发起紧急定位承载的建立。这样，实现了受限制模式下的UE接入到SAE网络的紧急呼叫。而且，由于该定位承载是专门服务于紧急呼叫的，因此，在已发起紧急呼叫的UE从非受限区域移动到受限制区域时，该紧急定位承载不会被释放，保证了紧急呼叫的连续性。

下面结合实施例，对本发明方法进行详细描述。

图4为本发明实现紧急呼叫的第一实施例的流程图，第一实施例中，假设拜访网部署了SUPL功能，SLP通过在下行数据中携带紧急标识来通知UE发起紧急定位承载的建立。如图4所示，包括：

步骤400：UE发起一个紧急呼叫，该紧急呼叫被路由到E-CSCF。

步骤401：E-CSCF向LRF发起位置查询请求，并要求LRF根据位置信息分配合适的PSAP。

步骤402：LRF向SLP发送位置查询请求。由于该位置查询请求服务于紧急呼叫，本实施例中，假设LRF在位置查询请求中携带紧急标识，以明确告知SLP，当前的位置查询请求是一个用于紧急呼叫的位置查询请求。

步骤403：SLP收到LRF发送的位置查询请求，根据位置查询请求中携带的紧急标识，获知该位置查询请求是服务于紧急呼叫的。

需要说明的是，如果步骤402中，LRF向SLP发送位置查询请求中未携带紧急标识，SLP可以根据预先设置的用于处理紧急呼叫处理的实体(如对应这些实体的地址)，查询该LRF是否为用于处理紧急呼叫处理的实体(如果在预先设置的地址中能找到该LRF的地址，则认为该LRF为用于处理紧急呼叫处理的实体)，从而获知该位置查询请求是否是服务于紧急呼叫的。

步骤404：SLP向P-GW发送下行数据，在该下行数据中包含SUPL INIT消息，并且，本实施例中，在该SUPL INIT消息中还携带有紧急标识。

步骤405：P-GW接收到来自SLP的下行数据后，如果UE处于空闲(IDLE)态，则首先将该UE激活，然后接收到的下行数据转发给UE。

步骤406：UE接收到下行数据后，从其中的SUPL INIT消息中获得紧急标识后，主动发起紧急定位承载的建立过程。

UE向MME发起紧急承载的建立过程，并通过指定该紧急承载的服务质量等级(QCI)、或其它信息，来表明该紧急承载是服务于紧急定位的。

需要说明的是，在步骤404中，UE可以仅判断自身是否是紧急附着状态，从而主动发起紧急定位承载的建立过程；或者，UE可以先检测在SUPL INIT消息中未携带紧急标识(即在SLP下发的下行数据中不包含紧急标识)后判断自身是紧急附着状态，从而，UE同样主动发起紧急定位承载的建立过程。

步骤407：在UE建立好紧急定位承载后，向SLP回复SUP POS INIT消息。

步骤408～步骤410：之后，SLP向UE发起后续定位请求，并从UE处获得具体的位置信息。当SLP获得了UE的位置信息后，SLP向LRF发送位置查询响应，以告知UE的位置信息。LRF获得UE的位置信息后，根据UE的位置信息决定合适的PSAP地址，返回给E-CSCF，E-CSCF执行后续紧急呼叫流程。本步骤的具体实现与现有技术完全一致，这里不再赘述。

图4所示的第一实施例，可以应用于有PCC、无PCC服务于紧急呼叫的场合，并且SLP和P-GW之间可以部署Lup接口或者增强的Lup接口。如果SLP和P-GW之间部署Lup接口，则SLP可以通过Lup接口发送下行数据给UE。如果SLP和P-GW之间没有部署Lup接口或者增强的Lup接口，则SLP可以通过标准IP通道向UE发送下行数据，由于P-GW负责处理UE的上下行数据，P-GW通过现有机制将下行数据发送给UE。UE根据在下行数据中所包含的SUPL INIT消息或者UE是紧急附着的，发起紧急定位承载的建立过程。

图5为本发明实现紧急呼叫的第二实施例的流程图，第二实施例中，假设拜访网部署了SUPL功能，SLP通过在下行数据中携带紧急标识来通知UE发起紧急定位承载的建立。如图5所示，包括：

步骤500：UE发起一个紧急呼叫，该紧急呼叫被路由到E-CSCF。

步骤501：E-CSCF向LRF发起位置查询请求，并要求LRF根据位置信息分配合适的PSAP。

步骤502：LRF向SLP发送位置查询请求。由于该位置查询请求服务于紧急呼叫，本实施例中，假设LRF在位置查询请求中携带紧急标识，以明确告知SLP，当前的位置查询请求是一个用于紧急呼叫的位置查询请求。

步骤503：SLP收到LRF发送的位置查询请求，根据位置查询请求中携带的紧急标识，获知该位置查询请求是服务于紧急呼叫的。

需要说明的是，如果步骤502中，LRF向SLP发送位置查询请求中未携带紧急标识，SLP可以根据预先设置的用于处理紧急呼叫处理的实体(如对应这些实体的地址)，查询该LRF是否为用于处理紧急呼叫处理的实体(如果在预先设置的地址中能找到该LRF的地址，则认为该LRF为用于处理紧急呼叫处理的实体)，从而获知该位置查询请求是否是服务于紧急呼叫的。

步骤504：SLP接收到位置查询请求后，向短信中心(或WAP网关)发送SUPL INIT消息。本实施例中，在该SUPL INIT消息中还携带有紧急标识。

步骤505～步骤506：短信中心(或WAP网关)将该SUPL INIT消息包装成短消息(或WAP消息)，并发送给带有SUPL定位能力的UE。

步骤507：UE接收到包装后的SUPL INIT消息后，从其中的SUPL INIT消息中获得紧急标识后，主动发起紧急定位承载的建立过程。进一步地，UE和SLP之间还可以建立IPSec安全链接隧道。

UE向MME发起紧急承载的建立过程，并通过指定该紧急承载的QCI、或其它信息，来表明该紧急承载是服务于紧急定位的。

需要说明的是，在步骤507中，UE可以仅判断自身是否是紧急附着状态，从而主动发起紧急定位承载的建立过程；或者，UE可以先检测在SUPL INIT消息中未携带紧急标识(即在SLP下发的下行数据中不包含紧急标识)后判断自身是紧急附着状态，从而，UE同样主动发起紧急定位承载的建立过程。

步骤508：在UE建立好紧急定位承载后，向SLP回复SUP POS INIT消息。

步骤509～步骤511：之后，SLP向UE发起后续定位请求，并从UE处获得具体的位置信息。当SLP获得了UE的位置信息后，SLP向LRF发送位置查询响应，以告知UE的位置信息。LRF获得UE的位置信息后，根据UE的位置信息决定合适的PSAP地址，返回给E-CSCF，E-CSCF执行后续紧急呼叫流程。本步骤的具体实现与现有技术完全一致，这里不再赘述。

图5所示的第二实施例，典型应用于网络中存在短信网关、WAP网关可以服务于紧急呼叫的场景。由于短信服务、WAP短消息服务的特性，该方法不能应用于UE无卡、UE无有效IMSI的紧急呼叫。对于UE存在有效IMSI，但是IMSI被限制的场景，如果拜访地运营商允许为这种状态下的UE开放短信服务、WAP短消息服务，则该方法可以应用。在该场景下，SLP通过短信网关、WAP网关将SUPL INIT消息发送给UE，促使UE根据SUPL INIT消息创建用于定位的紧急承载。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种实现紧急呼叫的方法，其特征在于，该方法包括：

用户面定位平台SLP接收到与紧急呼叫相关的位置查询，通知用户设备UE进行用户面定位初始化；

UE确定用户面定位初始化消息中携带有紧急标识或确定自身是紧急附着状态时，发起服务于紧急呼叫的紧急定位承载的建立，并通过建立起的紧急定位承载服务后续紧急呼叫；

其中，所述用户面定位平台SLP接收到与紧急呼叫相关的位置查询包括：

SLP接收到携带有紧急标识的位置查询；或者，

SLP预先设置或存储用于处理紧急呼叫处理的实体的地址，SLP接收到来自于处理紧急呼叫处理的实体的位置查询。

2.根据权利要求1所述的方法，其特征在于，所述通知用户设备UE进行用户面定位初始化具体包括：

所述SLP确定所接收的位置查询请求中携带有紧急标识时，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

3.根据权利要求1所述的方法，其特征在于，所述通知用户设备UE进行用户面定位初始化具体包括：所述SLP接收到位置查询请求，确定发起所述位置查询请求的实体为用于处理紧急呼叫处理的实体时，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

4.根据权利要求2或3所述的方法，其特征在于，所述SLP通过短信网关或WAP网关将所述用户面定位初始化消息SUPL INIT发送给UE。

5.根据权利要求4所述的方法，其特征在于，所述用户面定位初始化消息经短信中心或WAP网关包装成短消息或WAP消息后，发送给所述UE。

6.根据权利要求2或3所述的方法，其特征在于，所述用户面定位初始化消息包含在下行数据中。

7.根据权利要求1所述的方法，其特征在于，所述UE通过指定所述紧急定位承载的服务质量等级或其它信息，来表明所述承载是服务于紧急定位的，并向移动性管理实体MME发起紧急定位承载的建立过程。

8.一种实现紧急呼叫的系统，其特征在于，至少包括用户设备UE和用户面定位平台SLP，其中，

SLP，用于在接收到与紧急呼叫相关的位置查询，通知UE进行用户面定位初始化；

UE，用于确定用户面定位初始化消息中携带有紧急标识或确定自身是紧急附着状态时，发起服务于紧急呼叫的紧急定位承载的建立，并通过建立起的紧急定位承载服务后续紧急呼叫；

其中，所述SLP接收到与紧急呼叫相关的位置查询包括：

SLP接收到携带有紧急标识的位置查询；或者，

SLP预先设置或存储用于处理紧急呼叫处理的实体的地址，SLP接收到来自于处理紧急呼叫处理的实体的位置查询。

9.根据权利要求8所述的系统，其特征在于，所述SLP还用于，

判断发起所接收的位置查询请求中是否携带有紧急标识，如果携带有，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

10.根据权利要求8所述的系统，其特征在于，所述SLP还用于，

查询发起所述位置查询请求的实体是否为预设的用于处理紧急呼叫处理的实体，如果是，所述SLP向UE发送用户面定位初始化消息，并在该消息中携带紧急标识。

11.根据权利要求9或10所述的系统，其特征在于，还包括短信网关或WAP网关；

所述SLP通过短信网关或WAP网关将所述用户面定位初始化消息发送给UE。

12.根据权利要求9或10所述的系统，其特征在于，还包括PDN GW网关；

所述SLP通过PDN GW向UE发送下行数据，在下行数据中包含发送给UE的所述用户面定位初始化消息。