CN101841792A - 一种紧急呼叫业务的实现方法和装置 - Google Patents

Abstract

本发明实施例公开了一种紧急呼叫业务的实现方法和装置。包括：交互功能实体IWF接收用户UE发送的NAS消息，并转发给移动交换中心MSC；接收MSC发送通知消息，获知UE正在执行紧急呼叫；向策略和计费规则功能PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。由于为紧急呼叫建立紧急呼叫相关的语音承载建立流程，从而可以使得用户后续紧急呼叫业务得到保障。

Description

一种紧急呼叫业务的实现方法和装置

技术领域

本发明涉及移动通信技术，尤其涉及CSoPS架构下紧急呼叫业务的实现。

背景技术

CS域主要处理语音业务，CS域的信令面控制实体为MSC/VLR。GERAN网络中无线接入网元BSS通过A接口与MSC连接，UTRAN网络中无线接入网元RNC通过Iu-CS接口与MSC连接。

为了应对无线宽带技术的挑战，保持3GPP网络的领先优势，3GPP在2004年底制定了长期演进计划(LTE，Long Term Evolution)。在该演进计划的指导下定义了新的移动通信网络的架构，该架构与现在的GPRS/UMTS更加扁平，并且只保留了分组域，因此可以称为演进的分组网络(EPS，evolved packet system)。演进网络的核心网主要包含MME、Serving Gateway、PDN Gateway三个逻辑功能体，其中的MME是移动管理实体，负责NAS信令和NAS信令加密以及漫游、跟踪等功能，分配用户临时身份标识、安全功能等，它对应于当前UMTS系统内部SGSN的控制平面部分。

由于运营商很多业务都运行在电路域中，为了在LTE(Long Term Evolution)网络中重用现有的CS业务，因此提出了通过EPS(Evolved packet system)网络连接到CS域核心网的方法，如图1所示，UE通过IWF与传统CS核心网的MSC相连接。IWF具备模拟Iu-CS/A接口的能力，例如，IWF配置Iu-CS/A接口对应的协议栈。当UE要与MSC进行通信时，它可以发送消息给IWF，IWF可以将收到的消息转换成Iu-CS/A接口上的信令格式，并发送给MSC，从而完成UE与MSC的通信。同理，IWF可以将从MSC接收的消息转发给UE。LTE网络在这种通信模式下是作为UE与IWF之间的交互通道。在这种网络架构下，语音业务(包括紧急呼叫业务)在核心网侧的处理依然在电路域中执行，但是业务对应的承载在EPS网络下建立。

紧急呼叫业务，是为了紧急情况下通信联络的畅通而制定的一种特殊业务。与普通的呼叫业务相比，紧急呼叫业务必须得到保障的，即紧急呼叫业务的优先级大于普通的呼叫业务，当网络拥塞的时候，用户可能无法执行普通呼叫流程，但网络必须优先保障紧急呼叫业务能够顺利进行。

CSoPS的架构下，IWF需要通知PCRF业务类型(普通业务还是紧急业务)，从而PCRF为不同的语音业务建立不同的承载，即为普通语音业务建立普通承载，为紧急业务建立紧急语音承载。紧急语音承载的优先级要高于普通语音业务的承载，从而可以使得紧急语音业务的承载在EPS网络中得到保障。

现有技术中，IWF无法获知UE执行紧急呼叫，就无法通知PCEF此时UE执行的语音业务类型，因此PCRF为紧急呼叫用户建立普通语音承载。故当出现网络拥塞或者网络资源紧缺的时候，紧急呼叫的正常执行无法得到保障，影响紧急呼叫的业务体验。

发明内容

本发明实施例提供了一种实现紧急业务的方法、装置。使得在CSoPS架构下，可以保障UE执行紧急呼叫业务。

实施本发明实施例，具有如下有益效果：

本发明实施例提供了一种紧急业务的实现方法，IWF获知用户当前正在进行的是紧急呼叫业务时，将相关的紧急呼叫业务信息通知PCRF，PCRF为紧急呼叫业务建立紧急呼叫相关的语音承载，从而保障UE执行紧急呼叫业务。

附图说明

图1是EPS和CS网络的组网图；

图2是本发明实施例提供的一种紧急业务的实现方法流程图；

图3是本发明实施例提供的一种紧急业务的实现方法流程图；

图4是本发明实施例提供的一种紧急业务的实现方法过程示意图；

图5是本发明实施例提供的一种紧急业务的实现方法流程图；

图6是本发明实施例提供的一种紧急业务的实现方法过程示意图；

图7是本发明实施例提供的一种紧急业务的实现方法过程示意图；

图8是本发明实施例提供的一种紧急业务的实现方法过程示意图；

图9是本发明实施例提供的系统结构图；

图10是本发明实施例提供的系统结构图。

具体实施方式

本发明实施例提供了一种紧急业务的实现方法，IWF获知用户当前正在进行的是紧急呼叫业务时，将相关的紧急呼叫业务信息通知PCRF，从而PCRF为紧急呼叫业务建立紧急呼叫相关的语音承载。其中该紧急呼叫相关的语音承载相对于其他的普通语音业务的承载，具有较高的优先级，例如，紧急呼叫相关的语音承载的QoS类型的优先级别要高于普通语音业务的QoS类型的优先级，当出现网络拥塞或者资源不足的时候，根据QoS类型的优先级，网络需要优先保障紧急呼叫相关的语音承载，从而保证紧急呼叫的顺利执行。

当UE在CSoPS网络架构下执行紧急呼叫时，UE通过IWF向MSC发送NAS消息(呼叫建立请求)，但是IWF执行BSS/RNC的功能，不解析NAS消息，因而IWF不获知UE执行紧急呼叫，因此IWF无法将用户当前正在进行紧急呼叫的相关业务信息通知给PCRF，因此PCRF为用户建立普通语音业务的承载。

参见图2，为本发明的实施例一种紧急呼叫业务的实现方法的流程图，包括以下步骤：

201、IWF接收用户发送的NAS消息，并转发给MSC；

202、IWF接收MSC发送通知消息，获知UE正在执行紧急呼叫；

203、向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

其中NAS消息包括呼叫建立消息，业务请求消息等等。

参见图3，本发明的另一实施例一种紧急呼叫业务的实现方法的流程图，包括以下步骤：

301、MSC接收IWF转发的用户的呼叫建立消息，根据呼叫建立消息中携带的业务类型或者被叫号码，获知UE执行紧急呼叫；

302、所述MSC通知IWF用户执行紧急呼叫，使得IWF向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

由上述实施例可见，IWF收到用户的NAS消息，将NAS消息转发给MSC，通过MSC对用户的NAS消息进行解析，发现用户正在进行的是紧急呼叫时，通知IWF用户正在进行的是紧急业务，而IWF收到消息后，通过向PCRF发送紧急呼叫的语音承载的建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。从而可以使得用户后续紧急呼叫业务得到保障。

在本实施例中，由于终端的功能不同，有的终端可以识别所拨打的号码是紧急号码，有的终端无法识别说拨打的号码是否是紧急号码。故分为以下几种情况

1、终端识别拨打的是紧急呼叫，终端发送CM Service Request消息给MSC，其中携带Service Type业务类型可以指示为紧急呼叫类型。MSC获知终端发起的可能是紧急呼叫。

终端发起呼叫建立请求，其中分为紧急呼叫建立请求，和普通呼叫建立请求。MSC对呼叫建立请求进行解析，进一步进行校验：

1)紧急呼叫建立请求：UE发起紧急呼叫建立过程，MSC解析Emergency Setup紧急呼叫建立请求消息的类型Message Type是否指示为紧急呼叫类型，与CM Service Request消息是否一致进行校验，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

2)普通呼叫建立请求：UE发起的Setup呼叫建立过程，MSC解析Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。具体的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以获知UE是否执行紧急呼叫，与CM Service Request消息是否一致进行校验，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

2终端无法识别拨打的是紧急呼叫，终端发起呼叫建立请求，为普通呼叫建立请求。MSC对呼叫建立请求进行解析：UE发起的Setup呼叫建立过程，MSC解析Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。具体的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以获知UE是否执行紧急呼叫，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

参见图4，为本发明一种紧急呼叫业务的实现方法的具体实施例的过程示意图，包括以下步骤：

401：UE与IWF执行连接建立流程；

建立连接，后续UE可以向IWF发送NAS消息。

402：UE发送NAS消息，业务请求消息CM Service Request到IWF；

业务请求消息可以包含在UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)。

403：IWF从UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER获取NAS消息(CM Service Request)，并将所述NAS消息转发给MSC。由于CM Service Request消息是NAS消息，故IWF不解析，转发给MSC。通知MSC用户需要进行业务。

所述CM Service Request消息中携带Service Type业务类型可以指示为紧急呼叫类型，例如，当UE感知当前进行紧急业务(根据手机的配置，手机可以存储紧急呼叫号码)。对应的，后续UE可以发送NAS消息Emergency Setup紧急呼叫建立消息给MSC，通知MSC建立紧急呼叫。或者

Service Type业务类型指示可以为UE发起的呼叫类型，例如，UE无法感知当前进行紧急业务，例如，一个漫游用户在漫游地，所述用户并不知道当地的紧急呼叫号码，用户终端也没有配置漫游地的紧急号码信息，则当前Service Type业务类型指示为UE发起的呼叫类型。后续UE可以发送NAS消息Setup呼叫建立消息给MSC，通知MSC建立UE发起的呼叫。

404：用户发起呼叫业务(紧急呼叫)。

UE通过IWF发送Emergency Setup紧急呼叫建立请求给MSC，向MSC提供紧急呼叫建立的详细信息。所述消息的类型Message Type指示为紧急呼叫类型，所述消息中携带Emergency category紧急呼叫类别指示所述紧急呼叫对应的具体类型信息，例如，火警(中国：119)，紧急急救(中国：120)等等。所述呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。或者

UE通过IWF发送普通Setup呼叫建立请求给MSC，向MSC提供UE发起的呼叫建立的详细信息。所述消息携带Called party number指示为所述呼叫的被叫号码。其中呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。

405：MSC接收UE的呼叫(紧急呼叫或者UE发起的呼叫)建立请求，通过IWF转发呼叫处理Call Proceeding消息给UE，通知UE执行呼叫处理。所述消息包含在UE与IWF之间的UE-IWF DL DIRECT TRANSFER中发送给UE。

406：MSC确认UE执行紧急呼叫，MSC发送资源分配请求Assignment Request消息给IWF，要求IWF为紧急呼叫准备资源，同时所述消息中指示IWF，此时UE正在进行紧急呼叫。

MSC获知UE执行紧急呼叫的方式如下：

1)MSC通过UE发送的NAS消息，CM Service Request消息中业务类型Service Tpye指示紧急呼叫类型可以获知UE执行紧急呼叫；

2)MSC通过UE发送的NAS消息，Setup呼叫建立请求消息中UE提供的被叫号码可以获知UE执行紧急呼叫。MSC通过被叫号码获知UE当前执行紧急呼叫的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

另外，当UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示为紧急呼叫类型，MSC校验UE执行紧急呼叫的方式如下：

1)如果之后UE发起紧急呼叫建立过程，MSC校验Emergency Setup紧急呼叫建立请求消息的类型Message Type是否指示为紧急呼叫类型，以及消息中携带Emergency category紧急呼叫类别是否指示所述紧急呼叫的具体类型信息，从而可以确认UE是否执行紧急呼叫。

2)如果之后UE发起的Setup呼叫建立过程，MSC检验Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。校验的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

通过校验MSC可以确认UE执行紧急呼叫。

如果UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示UE发起的呼叫，MSC通过上述被叫号码解析方式获知UE执行紧急呼叫业务，此时不需要校验。

MSC通过资源分配请求消息指示IWF当前UE执行紧急呼叫的方式如下：

1)MSC发送资源分配请求消息给IWF，消息中携带紧急呼叫类型指示，例如，EMC indicator，IWF根据所述紧急呼叫类型指示获知UE执行紧急呼叫。

2)采用配置特殊QoS的方法：MSC发送资源分配请求消息给IWF，消息中携带紧急呼叫对应的QOS，IWF根据所述消息中携带的QoS获知UE执行紧急呼叫。

例如，运营商约定某种特定的QoS对应紧急呼叫的QoS，即将传统呼叫的QoS与紧急呼叫的QoS进行区分。当MSC获知用户执行的是紧急业务时；通过CM Service Request携带所述的紧急呼叫的Qos通知IWF；IWF获取MSC向其提供的QoS获知此时UE执行紧急呼叫。具体地，可以将此QoS信息同时配置在MSC和IWF上以进行判断和处理。所述配置特殊QoS的方法，具体实现可以是，配置QoS中的ARP参数，例如ARP参数配置为某一特定值，即代表紧急呼叫的QoS。

3)通过某些信元的某些尚未使用的比特位进行标识：MSC发送资源分配请求消息给IWF，消息中携带原因值Cause，IWF根据所述消息中携带的所述Cause获知UE执行紧急呼叫。

利用所述资源分配请求请求中的Cause IE(信元)来指示此时UE执行紧急呼叫，具体地，可以将此Cause信息同时配置在MSC和IWF上以进行判断和处理。所述配置Cause信元的方法，具体实现可以是，约定Cause信元所对应的某一尚未使用的比特位指示此时UE执行紧急呼叫业务。

4)通过资源分配请求消息中的优先级Priority IE(信元)：MSC发送资源分配请求消息给IWF，消息中携带业务优先级；所述IWF根据所述消息中携带的所述业务优先级获知UE执行紧急呼叫。

定义所述信元的某一取值或者某一区域取值代表紧急呼叫。具体地，可以将此Priority信息同时配置在MSC和IWF上以进行判断和处理。所述配置Priority信元的方法，具体实现可以是：例如可以定义Priority的取值为1代表此时执行紧急呼叫。当IWF接收MSC的资源分配请求消息，发现消息中所述Priority的取值为1，则或者UE执行紧急业务。

407：IWF向PCRF发送紧急业务指示(IP-CAN session Modification Request(EMC indicator))。

通过步骤6所述方式，IWF通过与MSC交互获知UE执行紧急呼叫，IWF通知PCRF发起紧急呼叫相关的语音承载建立流程，例如，IWF在IP-CAN会话修改请求消息中携带紧急呼叫指示信息(service information)给PCRF，触发PCRF发起紧急呼叫相关的语音承载建立流程

408：PCRF发起EPS网络中紧急呼叫用户面承载建立流程。

参见图5，是本发明实施例提供的一种紧急呼叫业务的实现方法的流程图。

501、IWF接收UE发送的呼叫建立消息；

502、解析所述呼叫建立消息，获知UE发起的是紧急业务；

503、向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

由上述实施例可见，本实施例通过对IWF进行改进，使得IWF对NAS进行解析。IWF收到UE发送给MSC的呼叫建立消息，进行NAS消息解析，获知UE发起的是紧急业务，通过向PCRF发送紧急呼叫的语音承载的建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。从而可以使得用户后续紧急呼叫业务得到保障。

在本实施例中，由于终端的功能不同，有的终端可以识别所拨打的号码是紧急号码，有的终端无法识别说拨打的号码是否是紧急号码。故分为以下几种情况

1、终端识别拨打的是紧急呼叫，终端发送CM Service Request消息给IWF，其中携带Service Type业务类型可以指示为紧急呼叫类型。IWF获知终端发起的可能是紧急呼叫。

终端发起呼叫建立请求，其中分为紧急呼叫建立请求，和普通呼叫建立请求。IWF对呼叫建立请求进行解析，进一步进行校验：

1)紧急呼叫建立请求：UE发起紧急呼叫建立过程，IWF解析Emergency Setup紧急呼叫建立请求消息的类型Message Type是否指示为紧急呼叫类型，与CM Service Request消息是否一致进行校验，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

2)普通呼叫建立请求：UE发起的Setup呼叫建立过程，IWF解析Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。具体的方法可以是，IWF本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与IWF配置紧急呼叫相关的号码进行比对的方式便可以获知UE是否执行紧急呼叫，与CM Service Request消息是否一致进行校验，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

2终端无法识别拨打的是紧急呼叫，终端发起呼叫建立请求，为普通呼叫建立请求。IWF对呼叫建立请求进行解析：UE发起的Setup呼叫建立过程，IWF解析Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。具体的方法可以是，IWF本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与IWF配置紧急呼叫相关的号码进行比对的方式便可以获知UE是否执行紧急呼叫，如果是紧急呼叫类型，则确认终端发起的是紧急呼叫。

参见图6，为本发明一种紧急呼叫业务的实现方法的具体实施例的过程示意图，

601：为传输NAS消息，UE与IWF执行连接建立流程；

执行所述流程，UE可以通过IWF发送NAS消息到MSC。

602：UE发送NAS消息到IWF，例如，CM Service Request消息，所述消息包含在UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)。

603：IWF从UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)获取NAS消息，并将所述NAS消息转发给MSC。

所述CM Service Request消息中携带Service Type业务类型可以指示为紧急呼叫类型，例如，当UE感知当前进行紧急业务(根据手机的配置，手机可以存储紧急呼叫号码)。对应的，后续UE可以发送NAS消息Emergency Setup紧急呼叫建立消息给MSC，通知MSC建立紧急呼叫。或者

Service Type业务类型指示可以为UE发起的呼叫类型，例如，UE无法感知当前进行紧急业务，例如，一个漫游用户在漫游地，所述用户并不知道当地的紧急呼叫号码，用户终端也没有配置漫游地的紧急号码信息，则当前Service Type业务类型指示为UE发起的呼叫类型。后续UE可以发送NAS消息Setup呼叫建立消息给MSC，通知MSC建立UE发起的呼叫。

604：用户发起呼叫业务(UE发起的呼叫或者紧急呼叫)。

UE通过IWF发送Emergency Setup紧急呼叫建立请求给MSC，向MSC提供紧急呼叫建立的详细信息。所述消息的类型Message Type指示为紧急呼叫类型，所述消息中携带Emergency category紧急呼叫类别指示所述紧急呼叫对应的具体类型信息，例如，火警(中国：119)，紧急急救(中国：120)等等。所述呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。或者

UE通过IWF发送Setup呼叫建立请求给MSC，向MSC提供UE发起的呼叫建立的详细信息。所述消息携带Called party number指示为所述呼叫的被叫号码。其中呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。

605：MSC接收UE的紧急呼叫或者呼叫建立请求，通过IWF转发呼叫处理Call Proceeding消息给UE，通知UE执行呼叫处理。所述消息包含在UE与IWF之间的UE-IWF DL DIRECT TRANSFER中发送给UE。

606：MSC发送资源分配请求Assignment Request消息给IWF，要求IWF为业务准备资源。

607：IWF执行NAS消息解析功能。

IWF获知UE执行紧急呼叫的方式如下：

1)IWF通过UE发送的NAS消息，CM Service Request消息中业务类型Service Tpye指示紧急呼叫类型可以获知UE执行紧急呼叫；

2)IWF通过UE发送的NAS消息，Setup呼叫建立请求消息中UE提供的被叫号码可以获知UE执行紧急呼叫。IWF通过被叫号码获知UE当前执行紧急呼叫的方法可以是，IWF本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

另外，当UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示为紧急呼叫类型，IWF校验UE执行紧急呼叫的方式如下：

1)如果之后UE发起紧急呼叫建立过程，IWF校验Emergency Setup紧急呼叫建立请求消息的类型Message Type是否指示为紧急呼叫类型，以及消息中携带Emergency category紧急呼叫类别是否指示所述紧急呼叫的具体类型信息，从而可以确认UE是否执行紧急呼叫。

2)如果之后UE发起的Setup呼叫建立过程，IWF检验Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。校验的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

通过校验IWF可以确认UE执行紧急呼叫。

如果UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示UE发起的呼叫，IWF通过上述被叫号码解析方式获知UE执行紧急呼叫业务，此时不需要校验。

IWF通过解析NAS消息确认UE执行紧急呼叫，IWF通知PCRF发起紧急呼叫相关的语音承载建立流程，例如，IWF在IP-CAN会话修改请求消息中携带紧急呼叫指示信息给PCRF。

如果IWF通过解析发现UE并未执行紧急呼叫，而执行普通的语音呼叫，那么IWF通知PCRF发起普通语音业务相关的语音承载建立流程。

608：PCRF发起EPS网络中紧急呼叫用户面承载建立流程。

参见图7，为本发明一种紧急呼叫业务的实现方法的具体实施例的过程示意图，本实施例中通过

701：UE执行紧急呼叫，UE发送请求消息到IWF，消息中指示IWF此时进行紧急呼叫，例如，UE-IWF Request消息中携带紧急呼叫类型指示(EMCCall)。

702：IWF获知UE即将执行紧急呼叫，回复接受UE-IWF Accetp消息给UE。

703：UE发送NAS消息到IWF，例如，CM Service Request消息，所述消息包含在UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)。

704：IWF从UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)获取NAS消息，并将所述NAS消息转发给MSC。

705：用户发起呼叫业务(UE发起的呼叫或者紧急呼叫)。

UE通过IWF发送Emergency Setup紧急呼叫建立请求给MSC，向MSC提供紧急呼叫建立的详细信息。所述消息的类型Message Type指示为紧急呼叫类型，所述消息中携带Emergency category紧急呼叫类别指示所述紧急呼叫对应的具体类型信息，例如，火警(中国：119)，紧急急救(中国：120)等等。所述呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。或者

UE通过IWF发送Setup呼叫建立请求给MSC，向MSC提供UE发起的呼叫建立的详细信息。所述消息携带Called party number指示为所述呼叫的被叫号码。其中呼叫建立请求消息是NAS消息，故IWF不解析，转发给MSC。

706：MSC接收UE的紧急呼叫或者呼叫建立请求，通过IWF转发呼叫处理Call Proceeding消息给UE，通知UE执行呼叫处理。所述消息包含在UE与IWF之间的UE-IWF DL DIRECT TRANSFER中发送给UE。

707：MSC发送资源分配请求Assignment Request消息给IWF，要求IWF为业务准备资源。

708：IWF执行NAS消息解析功能。

IWF获知UE执行紧急呼叫的方式如下：

1)IWF通过UE发送的NAS消息，CM Service Request消息中业务类型Service Tpye指示紧急呼叫类型可以获知UE执行紧急呼叫；

2)IWF通过UE发送的NAS消息，Setup呼叫建立请求消息中UE提供的被叫号码可以获知UE执行紧急呼叫。IWF通过被叫号码获知UE当前执行紧急呼叫的方法可以是，IWF本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

另外，当UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示为紧急呼叫类型，IWF校验UE执行紧急呼叫的方式如下：

1)如果之后UE发起紧急呼叫建立过程，IWF校验Emergency Setup紧急呼叫建立请求消息的类型Message Type是否指示为紧急呼叫类型，以及消息中携带Emergency category紧急呼叫类别是否指示所述紧急呼叫的具体类型信息，从而可以确认UE是否执行紧急呼叫。

2)如果之后UE发起的Setup呼叫建立过程，IWF检验Setup呼叫请求消息UE提供的被叫号码是否与紧急呼叫号码匹配。校验的方法可以是，MSC本地配置紧急呼叫相关的号码，通过将UE提供的被叫号码与MSC配置紧急呼叫相关的号码进行比对的方式便可以校验UE是否执行紧急呼叫。

通过校验IWF可以确认UE执行紧急呼叫。

如果UE发送给MSC的NAS消息，CM Service Request消息中业务类型Service Tpye指示UE发起的呼叫，IWF通过上述被叫号码解析方式获知UE执行紧急呼叫业务，此时不需要校验。

IWF通过解析NAS消息确认UE执行紧急呼叫，IWF通知PCRF发起紧急呼叫相关的语音承载建立流程，例如，IWF在IP-CAN会话修改请求消息中携带紧急呼叫指示信息给PCRF。

如果IWF通过解析发现UE并未执行紧急呼叫，而执行普通的语音呼叫，那么IWF通知PCRF发起普通语音业务相关的语音承载建立流程。

709：PCRF发起EPS网络中紧急呼叫用户面承载建立流程。

参见图8，为本发明一种紧急呼叫业务的实现方法的具体实施例的过程示意图，本实施例中通过：

801：UE执行呼叫业务，UE发送请求消息到IWF，消息中指示IWF此时进行呼叫业务，例如，UE-IWF Request消息中携带紧急呼叫类型指示(MOCall)。

802：IWF获知UE即将执行呼叫业务，回复接受UE-IWF Accetp消息给UE。

803：UE发送NAS消息到IWF，例如，CM Service Request消息，所述消息包含在UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)。

804：IWF从UE与IWF之间的上行直传消息中UE-IWF UL DIRECT TRANSFER(CM Service Request)获取NAS消息，并将所述NAS消息转发给MSC。

805：UE发送Setup呼叫建立请求消息给MSC，提供呼叫建立的详细信息。消息的类型Message Type指示为紧急呼叫类型，消息携带Called party number指示为所述呼叫的被叫号码。所述消息包含在UE与IWF之间的UE-IWF UL DIRECT TRANSFER中，发送到IWF，IWF转发Setup消息给MSC。

806：MSC接收UE的呼叫请求，发送呼叫处理Call Proceeding消息给UE，通知UE执行呼叫处理。所述消息包含在UE与IWF之间的UE-IWF DL DIRECT TRANSFER中发送给UE。

807：MSC发送资源分配请求Assignment Request消息给IWF，要求IWF为呼叫准备资源。

808：正常情况下，IWF不解析NAS消息，当步骤1中UE指示执行UE发起的呼叫，IWF需要执行呼叫业务解析功能。IWF通过解析后续UE发送的Setup呼叫建立过程中UE提供的被叫号码可以获知UE执行紧急呼叫。IWF通过被叫号码获知紧急呼叫的方法可以是，IWF配置紧急呼叫相关的号码，通过查询UE提供的被叫号码的方式便可以确认UE是否执行紧急呼叫。

IWF通过解析确认UE执行紧急呼叫，IWF通知PCRF发起紧急呼叫相关的语音承载建立流程，例如，IWF在IP-CAN会话修改请求消息中携带紧急呼叫指示信息给PCRF，触发PCRF发起紧急呼叫相关的语音承载建立流程；

如果IWF通过校验发现UE并未执行紧急呼叫，那么IWF通知PCRF发起普通语音业务相关的语音承载建立流程。或者拒绝UE的呼叫请求。

809：PCRF发起EPS网络中紧急呼叫用户面承载建立流程。

参见图9，是本发明实施例提供的系统示意图，包括：用户UE91、交互功能实体IWF92、移动交换中心MSC93、策略和计费规则功能PCRF94。其中，MSC93进一步包括接收单元931，判断单元932，通知单元933，IWF92进一步包括接收单元921，获知单元922，发送单元923。

IWF92的接收单元921接收来自UE91的NAS消息，发送单元923将所述NAS消息发送给MSC93的接收单元931。

MSC93的接收单元931接收来自IWF92的UE的NAS消息，MSC93的判断单元932判断用户发起的是否是紧急呼叫，当判断单元932判断用户发起的是紧急呼叫时，MSC93的通知单元933向IWF92的接收单元921发送通知消息，通知IWF92为用户准备紧急呼叫资源。

IWF92的获知单元921从MSC93接收的通知消息获知用户发起的是紧急呼叫，IWF92的发送单元923向PCRF94发送紧急呼叫的语音承载建立请求，触发PCRF94发起紧急呼叫相关的语音承载建立流程。

参见图10，是本发明实施例提供的另一系统结构图，包括：用户UE101、交互功能实体IWF102、移动交换中心MSC103、策略和计费规则功能PCRF104。其中，IWF进一步包括接收单元1021，解析单元1022，发送单元1023。

IWF的接收单元1021接收来自UE101的NAS消息，解析单元1022解析用户的NAS消息，获知用户发起的是否是紧急呼叫，如果是紧急呼叫，当IWF的接收单元1021接收来自MSC的资源分配请求时，IWF的发送单元1023向PCRF104发送紧急呼叫的语音承载建立请求，触发PCRF104发起紧急呼叫相关的语音承载建立流程。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的硬件平台的方式来实现，当然也可以全部通过硬件来实施。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上所揭露的仅为本发明一种实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (10)

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

IWF接收用户发送的NAS消息，并转发给MSC；

接收MSC发送通知消息，获知UE正在执行紧急呼叫；

向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

2.如权利要求1所述的紧急呼叫业务的实现方法，特征在于，接收MSC发送请求消息，获知UE正在执行紧急呼叫具体包括以下方式至少一种：

A：接收MSC发送资源分配消息，消息中携带紧急呼叫类型指示；所述IWF根据所述紧急呼叫类型指示获知UE执行紧急呼叫；

B：接收MSC发送资源分配消息，消息中携带紧急呼叫类型的QoS；所述IWF根据所述消息中携带的QoS获知UE执行紧急呼叫；

C：接收MSC发送资源分配消息，消息中携带原因值Cause；所述IWF根据所述消息中携带的所述Cause获知UE执行紧急呼叫；

D：接收MSC发送资源分配消息，消息中携带业务优先级；所述IWF根据

所述消息中携带的所述业务优先级获知UE执行紧急呼叫。

3.一种紧急呼叫业务的实现方法，其特征在于，包括，

MSC接收IWF转发的用户的呼叫建立消息，根据呼叫建立消息中携带的业务类型或者被叫号码，获知UE执行紧急呼叫；

所述MSC通知IWF用户执行紧急呼叫，使得IWF向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

4.如权利要求1所述的紧急呼叫业务的实现方法，特征在于，所述MSC通知IWF用户执行紧急呼叫具体为以下方式至少之一：

A：所述MSC向IWF发送资源分配消息，消息中携带紧急呼叫类型指示；

B：所述MSC向IWF发送资源分配消息，消息中携带紧急呼叫类型的QoS；

C：所述MSC向IWF发送资源分配消息，消息中携带原因值Cause表示紧急呼叫；

D：所述MSC向IWF发送资源分配消息，消息中携带业务优先级表示紧急呼叫。

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

IWF接收UE发送的呼叫建立消息；

对呼叫建立消息进行解析，获知UE发起的是紧急呼叫；

向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

6.如权利要求6所述的紧急呼叫业务的实现方法，其特征在于，IWF接收UE发送的呼叫建立消息之前还包括：

IWF接收UE发送给MSC业务请求消息时，IWF获知UE执行紧急呼叫，则对呼叫建立消息进行解析，获知UE发起的是紧急业务具体为：

IWF对呼叫建立消息进行解析，校验UE发起的呼叫是否与业务请求消息一致为紧急呼叫，如果是紧急呼叫，则进入下一步骤。

7.如权利要求1或6所述的紧急呼叫业务的实现方法，其特征在于，对呼叫建立请求进行消息解析，获知UE发起紧急业务具体包括以下方式至少一种：

A、当UE发送的呼叫建立消息为紧急呼叫建立消息时，检查UE发送的紧急呼叫建立消息中所携带的业务类型指示是否是紧急呼叫类型；如果是，则获知UE发起的是紧急业务；

B、当UE发送的呼叫建立消息为普通呼叫建立消息时，解析UE发送的呼叫建立请求中包含的被叫号码是否对应紧急号码。

8.一种MSC，其特征在于，包括：接收单元，判断单元，通知单元，其特征在于，

所述接收单元，用于接收来自IWF的用户的呼叫建立请求；

所述判断单元，用于根据用户的呼叫建立请求，判断用户发起的是否是紧急呼叫，

所述通知单元，用于当判断单元判断用户发起的是紧急呼叫时，向IWF发送通知消息，通知IWF为用户准备紧急呼叫资源。

9.如权利要求7所述的MSC，其特征在于，所述通知单元具体用于：

向IWF发送携带紧急呼叫类型指示的资源分配消息，通知IWF为用户准备紧急呼叫资源；或者

向IWF发送携带紧急呼叫类型的QoS的资源分配消息，通知IWF为用户准备紧急呼叫资源；或者

向IWF发送携带表示紧急呼叫原因值Cause的资源分配消息，通知IWF为用户准备紧急呼叫资源；或者

向IWF发送携带表示紧急呼叫业务优先级的资源分配消息，通知IWF为用户准备紧急呼叫资源。

10.一种IWF，其特征在于，包括：接收单元，解析单元，更新单元，存储单元，其特征在于，

所述接收单元，用于接收来自用户的呼叫建立请求；

所述解析单元，用于解析用户的呼叫建立请求，判断用户发起的是否是紧急呼叫，

所述发送单元，用于当判断单元判断用户发起的是紧急呼叫，接收单元收到MSC发送的资源分配请求时，向PCRF发送紧急呼叫的语音承载建立请求，触发PCRF发起紧急呼叫相关的语音承载建立流程。

Images