一种TD-LTE系统中紧急呼叫的识别方法

摘要

本发明公开了一种TD-LTE系统中紧急呼叫的识别方法，该方法包括：A、终端向核心网发起针对紧急呼叫业务的承载资源请求；B、核心网接收到终端的承载资源请求，核心网根据本地策略为紧急呼叫业务分配新的承载或者修改已有的承载，保存所述承载对应的业务流模板TFT、包过滤器PF与紧急呼叫业务的对应关系；C、核心网接收业务服务器发给终端的业务数据，核心网在业务数据包中提取IP信息和/或端口信息，并在终端的各个业务流模板中，与包过滤器中保存的信息做匹配；对于成功匹配的包过滤器，如果核心网保存了该包过滤器与紧急呼叫业务的对应关系，则将该业务数据包识别为紧急呼叫业务数据。本发明方案在不增加网络侧设备和成本，以及不影响核心网资源的使用率的基础上，能够使核心网对紧急呼叫业务快速有效的进行识别。

说明书

技术领域

本申请涉及移动通信技术领域，尤其涉及一种TD-LTE系统中紧急呼叫的识别方 法。

背景技术

随着通信技术以及网络架构扁平化的发展以及多种高速宽带可移动无线接入技术 的不断涌现，为了保证第三代移动通讯伙伴计划（3GPP ，3rd Generation Partnership  Project）的竞争力，并考虑演进的无线通信系统能够以更低的成本和更短的传输延时 提供更高的传输速率，同时支持3GPP内部接入系统之间的移动性以及3GPP接入系 统和非3GPP接入系统之间的移动性，提高3GPP系统能力和性能，降低成本，3GPP 提出了系统架构演进（LTE/SAE，Long Term Evolution，长期演进/System Architecture  Evolution，）的下一代通信技术和架构理念。SAE作为GPRS核心网络的演进，具有 简化架构，全IP化网络的特点，对更高吞吐量和更低等待时间的3GPP无线接入网络 （RAN，Radio Access Network）和非3GPP系统接入提供支持。

紧急呼叫（Emergency Call）业务是指用户在紧急情况下，通过终端发起的呼叫业 务。通常在一个区域内为一个固定号码，比如美国的911，中国的110/119等，运营商 也可根据自身需要配置更多的紧急呼叫号码。区别于其他业务，紧急呼叫业务对业务 的成功率要求更高，即，紧急呼叫的优先级要高于其他业务类型，在资源不足的情况 下，应优先为紧急呼叫业务进行服务；同时，紧急呼叫业务对业务的连续性要求更高， 即紧急呼叫用户的移动性管理享有优先操作权。

基于TD-LTE的系统通常由终端、基站、核心网和业务网络四部分构成，系统中 的各组成部分均需要对紧急呼叫业务进行识别。终端需要对用户发起的呼叫业务以及 接收到的被呼业务是否是紧急呼叫业务进行识别；基站需要对用户是否是因为紧急呼 叫业务而进行的无线接入进行识别，同时，基站需要对核心网进行的用户寻呼操作是 否是因为紧急呼叫业务而产生的进行识别；核心网需要能够识别对用户的业务操作是 否是紧急呼叫业务进行识别，以便能够对空闲状态的终端进行紧急寻呼操作；业务网 络需要对终端用户发起的业务是否是紧急呼叫业务进行识别和处理。

在TD-LTE系统的SAE架构下，核心网对紧急呼叫业务的识别方法主要有以下二 种：

1)基于IP多媒体子系统（IMS，IP Multimedia Subsystem）中紧急呼叫服务控制 单元（E-CSCF，Emergency-Call Server Control Function）的识别方法。

在3GPP的LTE标准中，对于支持E-CSCF的IMS系统，采用的策略是终端与IMS 中的E-CSCF建立专门用于紧急呼叫业务的IP连接接入网（IP-CAN,IP Connectivity  Access Network，）连接；同时，终端与核心网中专门用于紧急呼叫业务的接入点名称 （APN，Access Point Name）建立包数据网络（PDN，Packet Data Network）连接并 获取终端对应紧急呼叫业务所使用的IP地址。核心网通过对UE所使用的不同PDN 连接来实现对紧急呼叫业务的识别。

该方法的特点是需要为紧急呼叫业务建立专门的IP-CAN连接，终端和IMS系统 通过紧急业务服务发现过程建立紧急呼叫业务的IMS会话，并在终端和核心网提供的 专用APN之间建立PDN连接。该方法需要专门提供E-CSCF设备，同时由于该方法 对终端、核心网以及IMS子系统提出进一步要求，各设备均需要进行新的配置和功能 以实现对紧急呼叫业务的支持，这将大大增加现有系统的复杂度和维护复杂度。

2)基于深度报文检测（DPI，Deep Packet Inspection）的识别方法。

深度报文检测的方式是指核心网在PDN网关中对终端使用的用户面数据进行协 议解析，从用户面数据报文中获取协议信息，分析并识别呼叫业务以及紧急呼叫业务， 从而实现对紧急呼叫业务的识别。

该方法的特点是核心网中的PDN网关需要对终端的用户面数据报文进行截取和 协议分析。由于核心网是LTE系统中的核心处理设备，其维护了大量的终端设备和海 量的用户面数据，该方法需要核心网对其维护的每一个终端的全部用户面数据进行解 析，这将造成核心网资源的严重浪费，大大增加核心网的负荷和处理复杂度，严重降 低数据交换处理能力和业务承载能力。

发明内容

本申请提供了一种TD-LTE系统中紧急呼叫的识别方法，在不增加网络侧设备和 成本，以及不影响核心网资源的使用率的基础上，能够使核心网对紧急呼叫业务快速 有效的进行识别。

本申请实施例提供的一种TD-LTE系统中紧急呼叫的识别方法，该方法包括：

A、终端向核心网发起针对紧急呼叫业务的承载资源请求；

B、核心网接收到终端的承载资源请求，核心网根据本地策略为紧急呼叫业务分 配新的承载或者修改已有的承载，保存所述承载对应的业务流模板TFT、包过滤器PF 与紧急呼叫业务的对应关系；

C、核心网接收业务服务器发给终端的业务数据，核心网在业务数据包中提取IP 信息和/或端口信息，并在终端的各个业务流模板中，与包过滤器中保存的信息做匹配； 对于成功匹配的包过滤器，如果核心网保存了该包过滤器与紧急呼叫业务的对应关系， 则将该业务数据包识别为紧急呼叫业务数据。

较佳地，业务服务器中设置专用于紧急呼叫业务的IP地址和/或端口；步骤A包 括：

A1、终端发起业务注册过程，业务注册服务器在业务注册响应信令中将业务服务 器中紧急呼叫业务的IP地址和/或端口通知终端；

A2、终端保存获得的紧急呼叫业务IP地址和/或端口信息，并根据上述信息向核 心网发起针对紧急呼叫业务的承载资源请求。

较佳地，步骤A所述终端向核心网发起针对紧急呼叫业务的承载资源请求包括： 终端在承载资源请求的业务流模板包含对应紧急呼叫业务的包过滤器，所述包过滤器 的第一字节的第7位设置为用于表示紧急呼叫业务的值；将所述包过滤器中的包过滤 器上下文中的远端IP地址和/或远端端口设置为紧急呼叫服务器的IP地址和/或端口信 息。

从以上技术方案可以看出，通过终端和核心网之间的专有承载建立过程或者专有 承载修改过程，在终端和核心网之间建立可以供紧急呼叫业务使用的专有承载，并使 核心网中的PDN网关通过TFT和PF快速识别紧急呼叫业务。与传统的紧急呼叫业务 识别方法相比，本申请提出的方法有效利用了现有TD-LTE标准中的信息解决了核心 网对紧急呼叫业务的快速识别，在不增加网络侧设备和成本，不影响核心网资源的使 用率的基础上，没有增加核心网额外的负荷和处理复杂度，不会对核心网数据交换处 理能力和业务承载能力造成影响，简单快捷的实现了核心网对紧急呼叫业务识别。

附图说明

图1为本申请实施例提供的紧急呼叫业务的识别原理示意图；

图2为本申请实施例提供的紧急呼叫业务识别方法流程示意图。

具体实施方式

本申请提供的TD-LTE系统中紧急呼叫的识别方法，其核心技术构思为：有效利 用TD-LTE标准中终端和核心网之间使用的业务流模板（TFT，Traffic Flow Template） 以及其中的包过滤器（PF，Packet Filter），通过终端和核心网之间的专有承载建立过 程或者专有承载修改过程，在终端和核心网之间建立可以供紧急呼叫业务使用的专有 承载，并使核心网中的PDN网关通过TFT和PF快速识别紧急呼叫业务。

为使本申请技术方案的技术原理、特点以及技术效果更加清楚，以下结合具体实 施例对本申请技术方案进行详细阐述。

本申请实施例提供的TD-LTE系统中紧急呼叫的识别方法中，终端通过注册信令 和业务注册服务器进行业务注册过程。对于支持紧急呼叫业务的业务运营商，其业务 注册服务器在业务注册响应信令中将业务服务器中紧急呼叫业务的IP地址和/或端口 通知终端，该IP地址和/或端口信息应该独立于其他业务，即，业务服务器可以通过 该IP地址和/或端口信息区分业务是紧急呼叫业务。终端通过与核心网间的承载资源 分配过程或者承载资源修改过程，向核心网请求紧急呼叫业务所使用的承载资源和无 线资源。通过信令中所携带的业务流信息，终端向核心网指示该承载资源将用于紧急 呼叫业务。

以下给出一种终端通过业务流信息向核心网指示该承载资源将用于紧急呼叫业务 具体方式：

3GPP协议所规定的业务流模板结构和包过滤器结构分别如表1和表2所示，其中 包过滤器结构中第一个字节的第7位为空闲位。通过将第一字节的第7位定义为紧急 业务标识（Emergency Flag），可以快速指示核心网当前所请求的资源为紧急呼叫业务 所使用，本申请实施例提供的修改后的结构如表3所示。

终端将从业务注册服务器获取的紧急呼叫业务所使用的IP地址和/或端口信息， 作为包过滤器上下文（Packet Filter Contents）的远端IP地址和/或远端端口参数，传递 给核心网。

表13GPP协议24.008中TFT结构表

表23GPP协议24.008中Packet Filter结构表

表3修改后的Packet Filter结构表

核心网在承载资源分配或者承载资源修改过程收到终端的请求信令，通过识别包 过滤器中的紧急业务标识，核心网可以确认终端是因紧急呼叫业务而申请承载资源。 核心网根据本地策略可以为紧急呼叫业务分配专用的新的承载资源，也可以修改已有 承载资源为终端提供紧急呼叫业务的承载。核心网保存业务流模板并记录业务流模板 中的包过滤器与紧急呼叫业务的对应关系。

本申请实施例提供的紧急呼叫业务的识别原理如图1所示。当核心网检测到业务 服务器发给终端的业务数据包时，核心网解析业务数据包中的IP和/或端口信息，并 依次与终端的各个业务流模板中的包过滤器保存的IP和/或端口信息进行匹配。对于 成功匹配的包过滤器，核心网根据包过滤器与紧急呼叫业务对应关系确认为紧急呼叫 业务，则核心网将该业务识别为紧急呼叫业务。

图2为本申请实施例提供的紧急呼叫业务识别方法流程，包括如下步骤：

步骤201：终端发起业务注册过程，业务注册服务器在业务注册响应信令中将业 务服务器中紧急呼叫业务的IP地址和/或端口通知终端。本申请实施例中的业务注册 服务器支持紧急呼叫业务，并且业务服务器中紧急呼叫业务所使用的IP地址和/或端 口信息应该独立于其他业务。

步骤202：终端保存获得的紧急呼叫业务IP地址和/或端口信息，并根据上述信息 向核心网发起针对紧急呼叫业务的承载资源请求。

在步骤202中，终端向核心网发起承载资源分配请求或者承载资源修改请求，终 端需要将请求信令的业务流模板设置对应紧急呼叫业务的包过滤器。终端需要将包过 滤器中的紧急业务标识进行置位，以便通知核心网当前的承载资源申请是为紧急呼叫 业务进行的。终端需要在包过滤器中的包过滤器上下文中设置紧急呼叫服务器的IP地 址和/或端口信息为远端IP地址和/或远端端口。

步骤203：核心网接收到终端的承载资源请求，核心网可根据本地策略为紧急呼 叫业务分配新的承载或者修改已有的承载，保存TFT、PF与紧急呼叫业务的对应关系。

在步骤203中，核心网解析并在选定的承载中保存业务流模板，对于终端标识为 紧急呼叫业务的包过滤器，核心网保存业务流模板、包过滤器与紧急呼叫业务的对应 关系。

步骤204：核心网接收业务服务器发给终端的业务数据，核心网在业务数据包中 提取IP信息和/或端口信息，并在终端的各个业务流模板中，与包过滤器中保存的信 息做匹配。对于成功匹配的包过滤器，如果核心网保存了该包过滤器与紧急呼叫业务 的对应关系，则将该业务数据包识别为紧急呼叫业务数据，从而实现对紧急呼叫业务 的识别。

通过以上的处理，在不增加网络侧设备和成本的基础上，简单快捷的实现了核心 网对紧急呼叫业务的识别。该方法没有增加核心网的负荷和处理复杂度，也不会对核 心网数据交换处理能力和业务承载能力造成影响。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请的保护范围， 凡在本申请技术方案的精神和原则之内，所做的任何修改、等同替换、改进等， 均应包含在本申请保护的范围之内。