CN103747527B - 寻呼处理方法、通信装置及通信系统 - Google Patents

Abstract

本发明实施例公开了一种能提高为用户提供的业务服务质量的寻呼处理方法、通信装置及通信系统。该寻呼处理方法，包括：移动管理网元接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；获取业务属性信息；根据所述业务属性信息对用户终端发起不同策略的寻呼。一种通信装置，包括：接收单元，用于接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；信息单元，用于获取业务属性信息；处理单元，用于根据所述业务属性信息对用户终端发起不同策略的寻呼。本发明实施例还提供相应的通信系统。

Description

寻呼处理方法、通信装置及通信系统

技术领域

本发明涉及通信技术领域，具体涉及一种寻呼处理方法、通信装置及通信系统。

背景技术

在移动通信网络中，用户终端（UE，User Equipment）附着到网络后有两种状态：连接态和空闲态。在连接态下，用户终端和网络侧之间可以直接传输用户面数据包。在空闲态下，网络侧释放为用户终端分配的资源。如果网络侧有数据包要发送给处于空闲态的用户终端，网络侧寻呼用户终端，触发用户终端发起服务请求流程，恢复网络侧与用户终端的信令连接和用户面承载。

当网络侧的服务网关（SGW，Serving Gateway）收到用户终端的下行数据包后，如果发现下行隧道无效，服务网关缓存数据包，发送下行数据通知消息给移动管理网元，下行数据通知消息一般用于指示移动管理网元恢复用户终端的无线接入承载，如果此时终端处于空闲态，即用户终端和网络的信令连接被释放，则由移动管理网元寻呼用户终端，使得用户终端根据寻呼发起服务请求流程，恢复与网络侧的信令连接和用户面承载在空口侧的无线接入承载，然后服务网关将缓存的数据包发送给用户终端。

在对此方法的研究和实践过程中，本发明的发明人发现：

现有技术中服务网关发送给移动管理网元的下行数据通知消息只包含了移动管理网元为服务网关分配的隧道端点标识（TEID，Tunnel Endpoint ID），移动管理网元可以通过TEID定位到被叫的用户终端，对用户终端进行寻呼，但是移动管理网元无法区分用户终端的业务属性，例如无法区分是用户终端的哪类业务触发寻呼，则无法对寻呼进行区分处理，只按统一原则处理，从而降低了为用户提供的业务服务质量。

发明内容

本发明实施例提供一种能提高为用户提供的业务服务质量的寻呼处理方法、通信装置及通信系统。

本发明实施例提供一种寻呼处理方法，包括：

移动管理网元接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

获取业务属性信息；

根据所述业务属性信息对用户终端发起不同策略的寻呼。

本发明实施例提供一种通信装置，包括：

接收单元，用于接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

信息单元，用于获取业务属性信息；

处理单元，用于根据所述业务属性信息对用户终端发起不同策略的寻呼。

本发明实施例提供一种通信装置，包括：

生成单元，用于生成下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

发送单元，用于发送所述生成单元生成的通知消息，以便移动管理网元根据所述业务属性信息对用户终端发起不同策略的寻呼。

本发明实施例提供一种通信系统，包括：

第一通信装置，用于发送下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

第二通信装置，用于接收所述第一通信装置发送的下行数据通知消息，获取所述下行数据通知消息中的业务属性信息，根据所述业务属性信息对用户终端发起不同策略的寻呼。

上述技术方案可以看出，本发明实施例技术方案是在下行数据通知消息中包含了数据的业务属性信息，那么在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能节省网络侧寻呼用户终端的开销。

附图说明

图1是本发明实施例一的寻呼处理方法流程图；

图2是本发明实施例二的寻呼处理方法流程图；

图3是本发明实施例三的寻呼处理方法流程图；

图4是本发明实施例四的寻呼处理方法流程图；

图5是本发明实施例五的寻呼处理方法流程图；

图6是本发明实施例的通信装置一结构示意图；

图7是本发明实施例的通信装置二结构示意图；

图8是本发明实施例的通信系统结构示意图。

具体实施方式

本发明实施例提供一种能提高为用户提供的业务服务质量的寻呼处理方法。本发明实施例还提供相应的一种通信装置及通信系统。以下分别进行详细说明。

图1是本发明实施例一的寻呼处理方法流程图，主要包括步骤：

步骤101、移动管理网元接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

步骤102、获取所述业务属性信息；

步骤103、根据所述业务属性信息对用户终端发起不同策略的寻呼。

其中，所述下行数据通知消息包含的数据的业务属性信息为以下中的至少一项：接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI；

所述根据所述业务属性信息对用户终端发起不同策略的寻呼包括：

根据所述APN、QCI或者SI对用户终端发起不同策略的寻呼；

根据所述EBI定位到承载上下文得到对应的APN或者QCI，根据所述APN或者QCI对用户终端发起不同策略的寻呼；或者，

根据所述LBI定位到承载上下文得到对应的APN，根据所述APN对用户终端发起不同策略的寻呼。

或者，

所述下行数据通知消息包含的数据的业务属性信息为由以下中的至少一项：数据包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业务类别TOS、流标签Flow Label、业务类型和业务特性；

所述根据所述业务属性信息对用户终端发起不同策略的寻呼包括：

根据所述业务类型或者业务特性对用户终端发起不同策略的寻呼；

根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终端发起不同策略的寻呼；

或者，根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用户终端发起不同策略的寻呼。

实施例一内容可以看出，本发明实施例技术方案是在下行数据通知消息中包含了数据的业务属性信息，那么在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能节省网络侧寻呼用户终端的开销。

以下对本发明实施例技术方案进行更详细介绍。

图2是本发明实施例二的寻呼处理方法流程图：

本发明以演进分组系统（Evolved Packet System）为例进行说明。图2中移动管理网元可以指移动管理实体（MME，Mobility Management Entity）或者GPRS服务支撑节点（SGSN，Serving GPRS Support Node），服务网关指SGW（Serving Gateway），用户终端指UE，数据网关指PGW（Public Data Network Gateway）。

图2主要包括步骤：

步骤201、服务网关接收数据包，获取该数据包对应的业务属性信息；

服务网关收到数据网关发送的下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项：接入点名称（APN，Access Point Name）、承载标识（EBI，EPS BearerIdentity）、服务质量等级标识（QCI，QoS Class Identifier）、缺省承载标识（LBI，LinkedBearer Identity）和服务标识（SI，Service Identifier）。

服务网关获取该数据包对应的业务属性信息可以为以下其中一种方式：

1）服务网关根据下行数据包中的隧道端点标识定位该数据包对应的用户上下文或者承载上下文，获知该数据包对应的下行隧道无效，则获取用户上下文或者承载上下文中存储的业务属性信息，例如APN、EBI、QCI和LBI中至少一项等；

2）服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及协议号等协议头部信息，匹配到服务网关上存储的下行业务数据流过滤器（SDFF，ServiceData Flow Filter）或下行流量模板（TFT，Traffic Flow Template），然后根据下行业务数据流过滤器定位对应的下行业务数据流上下文，获知数据包对应的下行隧道无效，则获取业务数据流上下文存储的业务属性信息，例如APN、EBI、QCI、LBI和SI中至少一项等；或者，根据下行流量模板定位对应的承载上下文，获知数据包对应的下行隧道无效，则获取承载上下文存储的业务属性信息，例如APN、EBI、QCI和LBI中至少一项等。

步骤202、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消息；

服务网关将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该业务属性信息为APN、EBI、QCI、LBI和SI中至少一项。

步骤203、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发送的下行数据通知消息；

步骤204－205、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。

在EPS网络中，用户终端从空闲状态转为连接状态时，将恢复用户终端的所有用户面承载的无线接入承载，也就是说，当服务网关或者数据包对应的下行隧道无效（即无线接入承载被释放）时，用户终端必然处于空闲态，即移动管理网元收到服务网关发送的下行数据通知消息时，终端必然处于空闲状态，此时移动管理网元需要对终端进行寻呼。

移动管理网元获取业务属性信息后，根据不同的业务属性信息例如APN或EBI等采取不同的寻呼策略寻呼空闲状态的用户终端。

如果包含的业务属性信息为APN，则对终端优先发起APN对应的IP多媒体子系统（IMS，IP Multimedia Subsystem）的业务数据流的寻呼；

如果包含的业务属性信息为QCI，则对终端优先发起QCI=6的业务数据流的寻呼或者对终端优先发起对语音电话的业务数据流的寻呼。

如果包含的业务属性信息为SI，则对终端优先发起SI级别高的业务数据流的寻呼。

如果包含的业务属性信息为EBI，则可以通过EBI定位到存储的承载上下文，从承载上下文中得到触发寻呼的下行数据包对应的APN或QCI等，再根据APN或QCI等发起不同寻呼。

如果包含的业务属性信息为LBI，则可以通过LBI定位到缺省承载上下文，从缺省承载上下文中得到触发寻呼的下行数据包对应的APN等，再根据APN等发起不同寻呼。

步骤206、用户终端收到寻呼后，发起服务请求流程，恢复与网络侧的信令连接和用户面承载，并转为连接态，；

步骤207、在下行隧道有效后，服务网关将缓存的数据包发送给用户终端。

实施例二内容可以看出，本发明实施例技术方案在发送给移动管理网元的下行数据通知消息中包含了APN、EBI、QCI、LBI和SI中至少一项等作为业务属性信息的内容，因此移动管理网元在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，还能提高寻呼成功率，减少寻呼次数，节省网络侧寻呼用户终端的开销。

图3是本发明实施例三的寻呼处理方法流程图：

图3中移动管理网元可以指MME或者SGSN，服务网关指SGW，用户终端指UE，数据网关指PGW，应用服务网关可以指应用功能实体（AF，Application Function）或者代理会话控制功能实体（P-CSCF，Proxy-Call Session Control Function）。

实施例三考虑了服务网关可能无法区分不同业务的数据包的情况。因为不同业务的数据包可能在同一承载上传输或者对应相同的下行业务数据流过滤器，因此服务网关在承载或数据流过滤器的粒度方面可能不能区分出不同业务的数据包，例如对于被叫用户终端的IP电话（VoIP，Voice over IP）的请求（Invite）消息及短消息（SMS，short Message）over IP业务，对于演进的分组交换（EPS，Evolved Packet System）网络来说都是P-CSCF发来的一条会话启动协议（SIP，Session Initiation Protocol）信令，该SIP信令在相同的承载上传输或者对应相同的下行业务数据流过滤器，因此服务网关收到封装为SIP信令的数据包后，无法根据APN、EBI、QCI、LBI和SI中至少一项等信息区分该数据包对应为语音电话的信令消息还是短消息业务，直接将这些APN、EBI、QCI、LBI和SI中至少一项等信息发送给移动管理网元，移动管理网元也无法区分出不同业务。因此，可以在服务网关或移动管理网元上预先配置其他一些参数例如数据包的IP地址、协议类型、端口号、IP安全（IPSec，IPSecurity）参数索引、区分服务码点优先级（DSCP，Differentiated Services CodepointPriority）/业务类别（TOS，Type of Service）或者流标签（Flow Label）对应的相应业务类型，或数据包的IP地址、协议类型、端口号、IP安全（IPSec，IP Security）参数索引、区分服务码点优先级（DSCP，Differentiated ServicesCodepoint Priority）/业务类别（TOS，Type of Service）或者流标签（Flow Label）对应的业务特性，根据这些参数可以实现对业务进行区分。

如图3所示，主要包括步骤：

步骤301、服务网关接收数据包，获取该数据包对应的业务属性信息；

服务网关接收从应用服务网关经数据网关发送的下行数据包。

在本实施例中，应用服务网关对语音电话的信令消息和短消息业务分别采用不同的IP地址、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项来封装下行数据包，可以在服务网关上预先配置这些参数对应的相应业务类型或业务特性，也可以在移动管理网元上预先配置这些参数对应的相应业务类型或业务特性。

以DSCP/TOS或者Flow Label为例，可以通过DSCP/TOS或者Flow Label字段中不同的比特表示不同的业务类型，如字段中第一比特置为1表示为语音电话的信令消息，第二比特置为1表示为短消息业务的消息；或者通过DSCP/TOS或者Flow Label字段的枚举值来区分，如值为10表示语音电话的信令消息，值为17表示短消息业务的消息等。

服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项：数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、Flow Label、业务类型和业务特性。具体内容如下：

1）服务网关根据下行数据包中的隧道端点标识定位该数据包对应的用户上下文或者承载上下文，获知该数据包对应的下行隧道无效，则直接从下行数据包中获取数据包的IP地址、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项作为业务属性信息。服务网关可以根据数据包长度或者特性进行深度报文解析后，获取到上述业务属性信息。本方法中服务网关获取内层IP中的DSCP/TOS或者Flow Label作为业务属性信息。所述内层IP为目的地址为用户终端的IP地址的IP层。

2）服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及协议号等协议头部信息，匹配到服务网关上存储的下行业务数据流过滤器（SDFF，ServiceData Flow Filter）或下行流量模板（TFT，Traffic Flow Template），然后根据下行业务数据流过滤器定位对应的下行业务数据流上下文，获知数据包对应的下行隧道无效，则直接从下行数据包中获取数据包的IP地址、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项作为业务属性信息；或者，根据下行流量模板定位对应的承载上下文，获知数据包对应的下行隧道无效，则直接从下行数据包中获取数据包的IP地址、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项作为业务属性信息。服务网关可以根据数据包长度或者特性进行深度报文解析后，获取到上述业务属性信息。

进一步的，服务网关根据下行业务数据流上下文或者承载上下文或者用户上下文中存储的信息，例如APN，可以获知该数据包对应的连接类型。对应特定的连接类型，如IMS业务的连接类型，服务网关可以根据数据包长度或者特性进行深度报文解析，获取该数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项。

3）服务网关在上述1）或2）的基础上，根据数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与具体业务类型的对应关系，获知业务类型，将获知的业务类型作为业务属性信息。

4）服务网关在上述1）或2）的基础上，根据数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与具体业务特性的对应关系，获知业务特性，将获知的业务特性作为业务属性信息。

步骤302、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消息；

服务网关将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该业务属性信息为数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、Flow Label、业务类型和业务特性中至少一项。

业务类型可以由一个枚举值表示，如枚举值10表示语音电话的信令消息，枚举值17表示短消息业务、由字段中的不同比特来表示，如第一比特置1表示语音电话的信令消息，第二比特置1表示短消息业务。

业务特性（如高优先级业务，低等待时长业务）可以由一个枚举值表示，如枚举值1表示高优先级或等待时长较短业务，枚举值2表示低优先级或等待时长较长业务等；或者由字段中的不同比特来表示，如第一比特置1表示高优先级或等待时长较短业务，第二比特置1表示低优先级或等待时长较长业务等，本实施例不予限定。

步骤303、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发送的下行数据通知消息；

步骤304－305、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。

移动管理网元获取业务属性信息后，根据不同的业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。对于根据业务属性信息区分出的语音电话和短消息业务，在资源拥塞时，则对终端优先发起语音电话的业务数据流的寻呼，对语音电话的寻呼可以开始就在整个跟踪区域表（TA List，Tracking Area list）内下发，而对短消息的寻呼先在TAList内用户终端所在概率大的TA内下发。

如果包含的业务属性信息为数据包的IP地址、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项的情况，移动管理网元上需要预先配置这些参数对应的业务类型，或预先配置这些参数对应的业务特性，则根据对应关系可以区分出业务类型或业务特性，再根据业务类型或业务特性采取不同的寻呼策略寻呼空闲状态的用户终端。

步骤306、用户终端收到寻呼后，发起服务请求流程，恢复与网络侧的信令连接和用户面承载，并转为连接态，；

步骤307、在下行隧道有效后，服务网关将缓存的数据包发送给用户终端。

实施例三内容可以看出，本发明实施例技术方案在发送给移动管理网元的下行数据通知消息中包含了数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、FlowLabel、业务类型和业务特性中至少一项等作为业务属性信息的内容，因此移动管理网元在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能减少网络侧寻呼用户终端的开销。

图4是本发明实施例四的寻呼处理方法流程图。

图4中移动管理网元可以指MME或者SGSN，服务网关指SGW，用户终端指UE，数据网关指PGW，应用服务网关可以指AF或者P-CSCF。服务网关作为策略执行点，实现现有的策略控制架构中策略执行点的功能。

实施例四与上述实施例二和实施例三不同，是从下行业务数据流上下文或者承载上下文中获取存储的业务类型或业务特性信息。

如图4所示，主要包括步骤：

步骤401、服务网关接收数据包，获取该数据包对应的业务属性信息；

服务网关接收从应用服务网关经数据网关发送的下行数据包。

在本实施例中，应用服务网关对语音电话的信令消息和短消息业务分别采用不同的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项来封装下行数据包。

服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项：业务类型和业务特性。具体内容如下：

与上述实施例不同，因为本发明实施例中网络侧的策略决策点是根据应用服务网关发送的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项来对语音电话的信令消息或者短消息业务生成不同的下行业务数据流过滤器，并将不同的下行业务数据流过滤器发送给服务网关，因此服务网关在承载或业务数据流的粒度方面可以区分出不同业务的数据包。服务网关可以根据不同的下行业务数据流过滤器生成不同的下行流量模板。服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及协议号等协议头部信息，匹配到已经存储的下行业务数据流过滤器或下行流量模板，再根据下行业务数据流过滤器定位对应的下行业务数据流上下文，获知该数据包对应的下行隧道无效，则获取下行业务数据流上下文中存储的与下行业务数据流过滤器对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息；或者，根据下行流量模板定位对应的承载上下文，获知该数据包对应的下行隧道无效，则获取承载上下文存储的与下行流量模板对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息。

进一步的，服务网关根据下行业务数据流上下文或承载上下文或用户上下文中存储的信息，例如APN，可以获知该数据包对应的连接类型。对应特定的连接类型，如IMS业务的连接类型，服务网关获取下行业务数据流上下文存储的与下行业务数据流过滤器对应的业务类型或业务特性，或者获取承载上下文存储的与下行流量模板对应的业务类型或业务特性。

步骤402、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消息；

服务网关将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该业务属性信息为业务类型和业务特性中至少一项。

业务类型可以由一个枚举值表示，如枚举值10表示语音电话的信令消息，枚举值17表示短消息业务的消息，或者由字段中的不同比特来表示，如第一比特置1表示语音电话的信令消息，第二比特置1表示短消息业务的消息。

业务特性（如高优先级业务，低等待时长业务）可以由一个枚举值表示，如枚举值1表示高优先级或等待时长较短业务，枚举值2表示低优先级或等待时长较长业务等；或者由字段中的不同比特来表示，如第一比特置1表示高优先级或等待时长较短业务，第二比特置1表示低优先级或等待时长较长业务等，本实施例不予限定。

步骤403、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发送的下行数据通知消息；

步骤404－405、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。

移动管理网元获取业务属性信息后，根据不同的业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。对于根据业务属性信息区分出的语音电话和短消息业务，在资源拥塞时，则对终端优先发起语音电话的业务数据流的寻呼，对语音电话的寻呼可以开始就在整个TA List内下发，而对短消息的寻呼先在TA List内用户终端所在概率大的TA内下发。

步骤406、用户终端收到寻呼后，发起服务请求流程，恢复与网络侧的信令连接和用户面承载，并转为连接态；

步骤407、在下行隧道有效后，服务网关将缓存的数据包发送给用户终端。

实施例四内容可以看出，本发明实施例技术方案在发送给移动管理网元的下行数据通知消息中包含了业务类型和业务特性中至少一项等作为业务属性信息的内容，因此移动管理网元在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能减少网络侧寻呼用户终端的开销。

图5是本发明实施例五的寻呼处理方法流程图：

图5中移动管理网元可以指MME或者SGSN，服务网关指SGW，用户终端指UE，数据网关指PGW，应用服务网关可以指AF或者P-CSCF。与实施例四不同，本实施例中数据网关作为策略执行点，实现现有的策略控制架构中策略执行点的功能。

如图5所示，主要包括步骤：

步骤501、数据网关接收数据包，获取该数据包对应的业务属性信息；

数据网关接收从应用服务网关发送的下行数据包。

在本实施例中，应用服务网关对语音电话的信令消息和短消息业务分别采用不同的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项来封装下行数据包。

数据网关收到下行数据包后获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项：业务类型和业务特性。具体内容如下：

1）本发明实施例中网络侧的策略决策点可以根据应用服务网关发送的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中至少一项来对语音电话的信令消息或者短消息业务生成不同的下行业务数据流过滤器，并将不同的下行业务数据流过滤器发送给数据网关，数据网关可以根据不同的下行业务数据流过滤器生成不同的下行流量模板。数据网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及协议号等协议头部信息，匹配到已经存储的下行业务数据流过滤器或下行流量模板，再根据下行业务数据流过滤器定位下行业务数据流上下文，并获取其中存储的与下行业务数据流过滤器对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息；或者，根据下行流量模板定位对应的承载上下文，获取其中存储的与下行流量模板对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息。

进一步的，数据网关根据下行业务数据流上下文或承载上下文或用户上下文中存储的信息，例如APN，可以获知该数据包对应的连接类型。对应特定的连接类型，如IMS业务的连接类型，获取下行业务数据流上下文存储的与下行业务数据流过滤器对应的业务类型或业务特性，或者获取承载上下文存储的与下行流量模板对应的业务类型或业务特性。

数据网关根据获取的业务类型或业务特性，在给接收到的下行数据包封装外层IP层时，将外层IP中DSCP/TOS或者Flow Label字段值设置为相应的业务属性对应的值。

其中将下行数据包中的DSCP/TOS或者Flow Label字段值设置为相应的业务属性对应的值，可以是通过不同枚举值或不同比特区分，如枚举值10表示语音电话的信令消息，枚举值17表示短消息业务的消息，或者如第一比特置1表示语音电话的信令消息，第二比特置1表示短消息业务的消息。

2）应用服务网关对语音电话的信令消息和短消息业务分别采用不同DSCP/TOS或者Flow Label来封装数据包。网络侧的策略决策点对语音电话的信令消息或者短消息业务的不进行特殊处理，还是生成相同的下行业务数据流过滤器，并发送给数据网关。

此种情况下，数据网关在给接收到的下行数据包封装外层IP层时，将外层IP中DSCP/TOS或者Flow Label字段值设置为相应的接收的下行数据包的IP层的DSCP/TOS或者Flow Label值。

步骤502、数据网关向服务网关发送数据包；

步骤503、服务网关接收数据包，获取该数据包对应的业务属性信息；

服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项：DSCP/TOS、Flow Label、业务类型和业务特性。具体内容如下：

1）服务网关直接从下行数据包的外层IP层中获取数据包的DSCP/TOS或者FlowLabel作为业务属性信息。服务网关可以根据数据包长度或者特性进行深度报文解析后，获取到上述业务属性信息。所述外层IP层为数据网关接收到下行数据包后封装在该下行数据包外面的IP层。

2）服务网关在上述1）的基础上，根据数据包的DSCP/TOS或者Flow Label与具体业务类型的对应关系，获知业务类型，将获知的业务类型作为业务属性信息。

3）服务网关在上述1）的基础上，根据数据包的DSCP/TOS、Flow Label与具体业务特性的对应关系，获知业务特性，将获知的业务特性作为业务属性信息。

步骤504、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消息；

SGW将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该业务属性信息为数据包的DSCP/TOS、Flow Label、业务类型和业务特性中至少一项。

业务类型可以由一个枚举值表示，如枚举值10表示语音电话的信令消息，枚举值17表示短消息业务的消息，或者由字段中的不同比特来表示，如第一比特置1表示语音电话的信令消息，第二比特置1表示短消息业务的消息。

业务特性（如高优先级业务，低等待时长业务）可以由一个枚举值表示，如枚举值1表示高优先级或等待时长较短业务，枚举值2表示低优先级或等待时长较长业务等；或者由字段中的不同比特来表示，如第一比特置1表示高优先级或等待时长较短业务，第二比特置1表示低优先级或等待时长较长业务等，本实施例不予限定。

步骤505、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发送的下行数据通知消息；

步骤506－507、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。

移动管理网元获取业务属性信息后，根据不同的业务属性信息采取不同的寻呼策略寻呼空闲状态的用户终端。对于根据业务属性信息区分出的语音电话和短消息业务，则对终端优先发起语音电话的业务数据流的寻呼，在资源拥塞时，对语音电话的寻呼可以开始就在整个TA List内下发，而对短消息的寻呼先在TA List内用户终端所在概率大的TA内下发。

如果包含的业务属性信息为数据包的DSCP/TOS或者Flow Label的情况，移动管理网元上需要预先配置这些参数对应的业务类型或业务特性，则根据对应关系可以区分出业务类型或业务特性，再根据业务类型或业务特性采取不同的寻呼策略寻呼空闲状态的用户终端。

步骤508、用户终端收到寻呼后，发起服务请求流程，恢复与网络侧的信令连接和用户面承载，并转为连接态；

步骤509、在下行隧道有效后，服务网关将缓存的数据包发送给用户终端。

实施例五内容可以看出，本发明实施例技术方案在发送给移动管理网元的下行数据通知消息中包含了DSCP/TOS、Flow Label、业务类型和业务特性中至少一项等作为业务属性信息的内容，因此移动管理网元在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能减少网络侧寻呼用户终端的开销。

上述内容详细介绍了本发明实施例的寻呼处理方法，相应的，本发明实施例提供一种通信装置和通信系统。

图6是本发明实施例的通信装置一结构示意图。

如图6所示，通信装置包括：

接收单元61，用于接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

信息单元62，用于获取业务属性信息；

处理单元63，用于根据所述业务属性信息对用户终端发起不同策略的寻呼。

进一步的，所述接收单元61接收的通知消息中包含的数据的业务属性信息为由以下中的至少一项：接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI；

所述处理单元63包括：第一处理单元631和第二处理单元632。

第一处理单元631，用于根据所述EBI定位到承载上下文得到对应的APN或者QCI，或者，根据所述LBI定位到承载上下文得到对应的APN；

第二处理单元632，用于根据所述第一处理单元631得到的所述APN或者QCI对用户终端发起不同策略的寻呼；或者

所述处理单元63包括第三处理单元633，用于根据接收单元61接收的通知消息中的所述APN、QCI或者SI对用户终端发起不同策略的寻呼。

或者是，所述接收单元61接收的通知消息中包含的数据的业务属性信息为以下中的至少一项：数据包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业务类别TOS、流标签Flow Label、业务类型和业务特性；

所述处理单元63包括：第一处理单元631和第二处理单元632。

第一处理单元631，用于根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、Flow Label与业务类型的对应关系，获知业务类型，或者，根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、FlowLabel与业务特性的对应关系，获知业务特性；

第二处理单元632，用于根据所述第一处理单元631得到的所述业务类型或者业务特性对用户终端发起不同策略的寻呼；或者

所述处理单元63包括第三处理单元633，用于根据接收单元61接收的通知消息中的所述业务类型或者业务特性对用户终端发起不同策略的寻呼。

图7是本发明实施例的通信装置二结构示意图。

如图7所示，通信装置包括：

生成单元71，用于生成下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

发送单元72，用于发送所述生成单元71生成的通知消息，以便移动管理网元根据所述业务属性信息对用户终端发起不同策略的寻呼。

通信装置还包括：处理单元73。

实施方式一：

处理单元73，用于在接收数据包后，从数据包对应的用户上下文、承载上下文或者业务数据流上下文中获取数据的业务属性信息，所述业务属性信息为以下中的至少一项：接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI；

将所述获取的业务属性信息发送给所述生成单元71。

实施方式二：

处理单元73，用于接收数据包；

直接从数据包中获取业务属性信息，所述业务属性信息为数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS和Flow Label中的至少一项；

根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务类型的对应关系，获取业务类型作为数据的业务属性信息；

根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务特性的对应关系，获取业务特性作为数据的业务属性信息；或者，

根据不同的业务数据流过滤器对应的业务数据流上下文或不同的下行流量模板对应的承载上下文获取业务属性信息，所述业务属性信息为业务类型或者业务特性；

将所述获取的业务属性信息发送给所述生成单元71。

图8是本发明实施例的通信系统结构示意图。

如图8所示，通信系统包括：

第一通信装置81，用于发送下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；

第二通信装置82，用于接收所述第一通信装置81发送的下行数据通知消息，获取业务属性信息；根据所述业务属性信息对用户终端发起不同策略的寻呼。

所述第一通信装置81发送的下行数据通知消息中包含的数据的业务属性信息为以下中的至少一项：接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI；

所述第二通信装置82可以用于根据所述EBI定位到承载上下文得到对应的APN或者QCI后，根据所述APN或者QCI对用户终端发起不同策略的寻呼；或者

根据所述LBI定位到承载上下文得到对应的APN，根据所述APN对用户终端发起不同策略的寻呼。

或者是，

所述第一通信装置81发送的下行数据通知消息中包含的数据的业务属性信息为以下中的至少一项：数据包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业务类别TOS、流标签Flow Label、业务类型和业务特性；

所述第二通信装置82可以用于据所述业务类型或者业务特性对用户终端发起不同策略的寻呼；

根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终端发起不同策略的寻呼；或者

根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用户终端发起不同策略的寻呼。

第二通信装置82具有上述图6所示的结构，具体参见前面描述。

综上所述，本发明实施例技术方案是在下行数据通知消息中包含了数据的业务属性信息，那么在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器（ROM，Read Only Memory）、随机存取存储器（RAM，RandomAccess Memory）、磁盘或光盘等。

以上对本发明实施例所提供的寻呼处理方法、通信装置及通信系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (7)

1.一种寻呼处理方法，其特征在于，包括：

移动管理网元接收下行数据通知消息，所述下行数据通知消息包括区分服务码点优先级DSCP/业务类别TOS

所述移动性管理网元获取所述DSCP/TOS对应的寻呼策略；

所述移动性管理网元应用所述寻呼策略对用户终端发起寻呼。

2.根据权利要求1所述的寻呼处理方法，其特征在于，

所述DSCP TOS是服务网关从数据网关发送的所述数据包中获取的。

3.一种移动管理网元，其特征在于，包括：

接收单元，用于接收下行数据通知消息，所述下行数据通知消息包含包括区分服务码点优先级DSCP/业务类别TOS；

处理单元，用于获取所述DSCP/TOS对应的寻呼策略，应用所述寻呼策略对用户终端发起寻呼。

4.根据权利要求3所述的移动管理网元，其特征在于，

所述DSCP/TOS是服务网关从数据网关发送的所述数据包中获取的。

5.一种服务网关，其特征在于，包括：

生成单元，用于生成下行数据通知消息，所述下行数据通知消息包括区分服务码点优先级DSCP/业务类别TOS；

处理单元，用于在接收数据网关发送的数据包后，从所述数据包获取所述DSCP/TOS；

发送单元，用于发送所述下行数据通知消息至移动性管理网元，以便所述移动管理网元应用所述DSCP/TOS对应的寻呼策略对用户终端发起寻呼。

6.根据权利要求5所述的服务网关，其特征在于，还包括：

处理单元，用于在接收数据网关发送的数据包后，从所述数据包对应的用户上下文、承载上下文或者业务数据流上下文中获取数据的所述EBI。

7.一种通信系统，其特征在于，包括：

如权利要求3或4所述的移动管理网元和权利要求5或6所述的服务网关。