CN104853331A - 一种被叫紧急呼叫处理方法及系统 - Google Patents

Abstract

本发明提供了一种被叫紧急呼叫处理方法及系统，该方法包括：主叫UE发送紧急呼叫建立请求；MME接收紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1AP寻呼消息，其中，紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，第一紧急标识用来标识当前寻呼为紧急寻呼；基站接收到紧急S1AP寻呼消息后，在RRC发送紧急寻呼消息，其中，紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；被叫UE接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。通过本发明提供的方法及系统，能够使被叫UE请求紧急RRC连接建立。

Description

一种被叫紧急呼叫处理方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种被叫紧急呼叫处理方法及系统。

背景技术

当前3GPP（The3rd Generation Partnership Project，第三代合作伙伴计划）中定义紧急呼叫均为紧急呼叫有线呼叫中心，如110，120，119等。而在集群业务中紧急呼叫不仅限于此类型的呼叫，而且包含两个移动终端之间的紧急呼叫。而在当前3GPP和CCSA（ChinaCommunications Standards Association，中国通信标准化协会）协议中没有相关协议支持此类的呼叫。

在3GPP36.413协议中的寻呼消息，没有通知eNB（evolved Node B，演进型基站）当前寻呼为紧急寻呼，因此，eNB也无法通过寻呼消息通知UE（User Equipment，用户设备）此寻呼为紧急寻呼。因此，被叫UE发起RRC（Radio Resource Control，无线资源控制协议）连接建立时，无法携带紧急标识，无法请求紧急呼叫处理。

当前3GPP和CCSA标准协议中，没有被叫UE为移动终端的紧急呼叫实现方案。如果紧急呼叫的被叫UE处于空闲状态，无法在RRC连接建立请求中携带紧急标识，通知网络侧此RRC连接建立为紧急呼叫RRC连接。

发明内容

本发明提供了一种被叫紧急呼叫处理方法及系统，能够使被叫UE请求紧急RRC连接建立。

本发明提供了一种被叫紧急呼叫处理方法，该方法包括：

主叫用户设备UE发送紧急呼叫建立请求；

移动性管理实体MME接收所述紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1应用协议S1AP寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

基站接收到所述紧急S1AP寻呼消息后，在无线资源控制协议RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

被叫UE接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

进一步地，所述方法还包括：

基站在接收到所述被叫UE发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。

本发明提供了一种被叫紧急呼叫处理系统，所述系统包括：

主叫用户设备UE、移动性管理实体MME、基站、被叫UE；

所述主叫UE，用于发送紧急呼叫建立请求；

所述MME，用于接收所述主叫UE发送的紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1应用协议S1AP寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

所述基站，用于接收到所述紧急S1AP寻呼消息后，在无线资源控制协议RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

所述被叫UE，用于接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

进一步地，所述基站还用于，

在接收到所述被叫UE发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。

本发明实施例提供的一种被叫紧急呼叫处理方法及系统，通过紧急寻呼消息通知基站当前寻呼为紧急寻呼，基站通过紧急寻呼消息通知被叫UE当前寻呼为紧急寻呼，被叫UE发送携带了紧急标识的RRC连接建立请求，能够使被叫UE请求紧急RRC连接建立。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种被叫紧急呼叫处理方法的流程图；

图2是本发明实施例提供的一种被叫紧急呼叫处理方法的信息交互示意图；

图3是本发明实施例提供的一种被叫紧急呼叫处理系统的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供了一种被叫紧急呼叫处理方法，参见图1，该方法具体包括：

步骤101：主叫UE发送紧急呼叫建立请求；

步骤102：MME（Mobility Management Entity，移动性管理实体）接收所述紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1AP（S1Application Protocol，S1应用协议）寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

步骤103：基站接收到所述紧急S1AP寻呼消息后，在RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

步骤104：被叫UE接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

本发明实施例提供的一种被叫紧急呼叫处理方法，通过紧急寻呼消息通知基站当前寻呼为紧急寻呼，基站通过紧急寻呼消息通知被叫UE当前寻呼为紧急寻呼，被叫UE发送携带了紧急标识的RRC连接建立请求，能够使被叫UE请求紧急RRC连接建立。

在步骤104之后，还包括：基站在接收到所述被叫UE发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。

参见图2，为本发明实施例中的一种被叫紧急呼叫处理方法的信息交互示意图。其中，MME接收到主叫UE发送的紧急呼叫建立请求后，并在检测到被叫UE处于空闲状态，则MME向基站发送紧急S1AP寻呼消息，基站接收该紧急S1AP寻呼消息后，向被叫UE发送紧急寻呼消息，被叫UE接收到该紧急寻呼消息后，向基站发送携带了第三紧急标识的RRC连接建立请求，基站按照紧急RRC连接建立处理被叫UE的RRC连接建立请求，最终完成RRC连接的建立。

其中，本发明实施例中的紧急S1AP寻呼消息可以通过以下方式实现：在标准3GPP36.413协议定义的S1AP寻呼消息中增加一个紧急寻呼标识，可选信元用于指示此寻呼消息为紧急寻呼消息。

本发明实施例中的紧急寻呼消息可以通过以下方式实现：在3GPP36.331标准寻呼消息定义中，在寻呼记录列表信元定义中，增加可选紧急标识。

本发明实施例提供的了一种被叫紧急呼叫处理系统，参见图3，该系统包括：

主叫UE301、MME302、基站303、被叫UE304；

所述主叫UE301，用于发送紧急呼叫建立请求；

所述MME302，用于接收所述主叫UE发送的紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1应用协议S1AP寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

基站303，用于接收到所述紧急S1AP寻呼消息后，在无线资源控制协议RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

被叫UE304，用于接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

所述基站303还用于，在接收到所述被叫UE304发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。

通过上述描述可见，本发明实施例具有如下有益效果：

本发明实施例提供的一种被叫紧急呼叫处理方法及系统，通过紧急寻呼消息通知基站当前寻呼为紧急寻呼，基站通过紧急寻呼消息通知被叫UE当前寻呼为紧急寻呼，被叫UE发送携带了紧急标识的RRC连接建立请求，能够使被叫UE请求紧急RRC连接建立。

需要说明的是，在本文中，诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个······”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储在计算机可读取的存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。

最后需要说明的是：以上所述仅为本发明的较佳实施例，仅用于说明本发明的技术方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (4)

1.一种被叫紧急呼叫处理方法，其特征在于，该方法包括：

主叫用户设备UE发送紧急呼叫建立请求；

移动性管理实体MME接收所述紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1应用协议S1AP寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

基站接收到所述紧急S1AP寻呼消息后，在无线资源控制协议RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

被叫UE接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

基站在接收到所述被叫UE发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。

3.一种被叫紧急呼叫处理系统，其特征在于，所述系统包括：

主叫用户设备UE、移动性管理实体MME、基站、被叫UE；

所述主叫UE，用于发送紧急呼叫建立请求；

所述MME，用于接收所述主叫UE发送的紧急呼叫建立请求，并检测到被叫UE处于空闲状态后，发送紧急S1应用协议S1AP寻呼消息，其中，所述紧急S1AP寻呼消息为携带了第一紧急标识的S1AP寻呼消息，所述第一紧急标识用来标识当前寻呼为紧急寻呼；

所述基站，用于接收到所述紧急S1AP寻呼消息后，在无线资源控制协议RRC发送紧急寻呼消息，其中，所述紧急寻呼消息为携带了第二紧急标识的寻呼消息，所述第二紧急标识用来标识当前寻呼为紧急寻呼；

所述被叫UE，用于接收到所述紧急寻呼消息后，发送携带了第三紧急标识的RRC连接建立请求，所述第三紧急标识用来标识当前RRC连接建立为紧急RRC连接。

4.根据权利要求3所述的系统，其特征在于，所述基站还用于，

在接收到所述被叫UE发送的所述携带了第三紧急标识的RRC连接建立请求后，按照紧急RRC连接建立处理所述被叫UE的RRC连接建立请求。