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

专利名称：寻呼处理方法、通信装置及通信系统的制作方法
技术领域：
本发明涉及通信技术领域，具体涉及一种寻呼处理方法、通信装置及通信系统。
背景技术：
在移动通信网络中，用户终端(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
7对用户终端发起不同策略的寻呼；或者，根据所述LBI定位到承载上下文得到对应的APN，根据所述APN对用户终端发起不 同策略的寻呼。或者，所述下行数据通知消息包含的数据的业务属性信息为由以下中的至少一项数据 包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业务 类别T0S、流标签Flow Label、业务类型和业务特性；所述根据所述业务属性信息对用户终端发起不同策略的寻呼包括根据所述业务类型或者业务特性对用户终端发起不同策略的寻呼；根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/ TOS或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终 端发起不同策略的寻呼；或者，根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、 DSCP/T0S或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用 户终端发起不同策略的寻呼。实施例一内容可以看出，本发明实施例技术方案是在下行数据通知消息中包含了 数据的业务属性信息，那么在获取这些业务属性信息后，就可以根据业务属性信息对用户 终端发起不同策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致 的缺陷，使得一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业 务服务质量，又能节省网络侧寻呼用户终端的开销。以下对本发明实施例技术方案进行更详细介绍。图2是本发明实施例二的寻呼处理方法流程图本发明以演进分组系统(Evolved Packet System)为例进行说明。图2中移动管 理网元可以指移动管理实体(MME，Mobility Management Entity)或者GPRS服务支撑节点 (SGSN, Serving GPRS Support Node)，服务网关指 SGW (Serving Gateway)，用户终端指UE， 数据网关指 PGW(Public Data NetworkGateway)。图2主要包括步骤步骤201、服务网关接收数据包，获取该数据包对应的业务属性信息；服务网关收到数据网关发送的下行数据包后，获知该数据包对应的下行隧道无 效，则缓存该数据包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以 下中的至少一项接入点名称(APN，Access Point Name)、承载标识(EBI，EPS Bearer Identity)、服务质量等级标识(QCI, QoS ClassIdentif ier)、缺省承载标识(LBI, Linked Bearer Identity)和服务标识(Si, Service Identifier)。服务网关获取该数据包对应的业务属性信息可以为以下其中一种方式1)服务网关根据下行数据包中的隧道端点标识定位该数据包对应的用户上下文 或者承载上下文，获知该数据包对应的下行隧道无效，则获取用户上下文或者承载上下文 中存储的业务属性信息，例如APN、EBI、QCI和LBI中至少一项等；2)服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口 号及协议号等协议头部信息，匹配到服务网关上存储的下行业务数据流过滤器(SDFF，Service Data Flow Filter)或下行流量模板(TFT，Traffic FlowTemplate)，然后根据 下行业务数据流过滤器定位对应的下行业务数据流上下文，获知数据包对应的下行隧道无 效，则获取业务数据流上下文存储的业务属性信息，例如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，应用服务网关可以指应用功能实体(AFJpplicationFunction)或者代理会话 控制功能实体(P-CSCF，Proxy-Call Session ControlFunction)。实施例三考虑了服务网关可能无法区分不同业务的数据包的情况。因为不同业务 的数据包可能在同一承载上传输或者对应相同的下行业务数据流过滤器，因此服务网关在 承载或数据流过滤器的粒度方面可能不能区分出不同业务的数据包，例如对于被叫用户终 端的 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, IP Security)参数索引、区分服务码点优先级(DSCP, Differentiated Services Cod印ointPriority)/业务类别(T0S, Type of Service)或者流标签(Flow Label)对应 的相应业务类型，或数据包的IP地址、协议类型、端口号、IP安全(IPSec，IP Security)参 数索引、区分服务码点优先级(DSCP，Differentiated ServicesCodepoint Priority)/业 务类别(T0S，Type of Service)或者流标签(FlowLabel)对应的业务特性，根据这些参数 可以实现对业务进行区分。如图3所示，主要包括步骤步骤301、服务网关接收数据包，获取该数据包对应的业务属性信息；服务网关接收从应用服务网关经数据网关发送的下行数据包。在本实施例中，应用服务网关对语音电话的信令消息和短消息业务分别采用不同 的IP地址、端口号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项来封装下行数据 包，可以在服务网关上预先配置这些参数对应的相应业务类型或业务特性，也可以在移动 管理网元上预先配置这些参数对应的相应业务类型或业务特性。以DSCP/T0S或者Flow Label为例，可以通过DSCP/T0S或者Flow Label字段中 不同的比特表示不同的业务类型，如字段中第一比特置为1表示为语音电话的信令消息， 第二比特置为1表示为短消息业务的消息；或者通过DSCP/T0S或者Flow Label字段的枚 举值来区分，如值为10表示语音电话的信令消息，值为17表示短消息业务的消息等。服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据 包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项数据 包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S、Flow Label、业务类型和业务 特性。具体内容如下1)服务网关根据下行数据包中的隧道端点标识定位该数据包对应的用户上下文 或者承载上下文，获知该数据包对应的下行隧道无效，则直接从下行数据包中获取数据包 的IP地址、端口号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项作为业务属性信息。服务网关可以根据数据包长度或者特性进行深度报文解析后，获取到上述业务属性信 息。本方法中服务网关获取内层IP中的DSCP/T0S或者Flow Label作为业务属性信息。所 述内层IP为目的地址为用户终端的IP地址的IP层。2)服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口 号及协议号等协议头部信息，匹配到服务网关上存储的下行业务数据流过滤器(SDFF， Service Data Flow Filter)或下行流量模板(TFT，Traffic FlowTemplate)，然后根据 下行业务数据流过滤器定位对应的下行业务数据流上下文，获知数据包对应的下行隧道无 效，则直接从下行数据包中获取数据包的IP地址、端口号、IPSec参数索引、DSCP/T0S和 Flow Label中至少一项作为业务属性信息；或者，根据下行流量模板定位对应的承载上下 文，获知数据包对应的下行隧道无效，则直接从下行数据包中获取数据包的IP地址、端口 号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项作为业务属性信息。服务网关可 以根据数据包长度或者特性进行深度报文解析后，获取到上述业务属性信息。进一步的，服务网关根据下行业务数据流上下文或者承载上下文或者用户上下文 中存储的信息，例如APN，可以获知该数据包对应的连接类型。对应特定的连接类型，如IMS 业务的连接类型，服务网关可以根据数据包长度或者特性进行深度报文解析，获取该数据 包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项。3)服务网关在上述1)或2)的基础上，根据数据包的IP地址、协议类型、端口号、 IPSec参数索引、DSCP/T0S或者Flow Label与具体业务类型的对应关系，获知业务类型，将 获知的业务类型作为业务属性信息。4)服务网关在上述1)或2)的基础上，根据数据包的IP地址、协议类型、端口号、 IPSec参数索引、DSCP/T0S或者Flow Label与具体业务特性的对应关系，获知业务特性，将 获知的业务特性作为业务属性信息。步骤302、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消 息；服务网关将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该 业务属性信息为数据包的IP地址、协议类型、端口号、IPSec参数索弓|、DSCP/T0S、Flow Label、业务类型和业务特性中至少一项。业务类型可以由一个枚举值表示，如枚举值10表示语音电话的信令消息，枚举值 17表示短消息业务、由字段中的不同比特来表示，如第一比特置1表示语音电话的信令消 息，第二比特置1表示短消息业务。业务特性(如高优先级业务，低等待时长业务)可以由一个枚举值表示，如枚举值 1表示高优先级或等待时长较短业务，枚举值2表示低优先级或等待时长较长业务等；或者 由字段中的不同比特来表示，如第一比特置1表示高优先级或等待时长较短业务，第二比 特置1表示低优先级或等待时长较长业务等，本实施例不予限定。步骤303、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发 送的下行数据通知消息；步骤304-305、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状 态的用户终端。移动管理网元获取业务属性信息后，根据不同的业务属性信息采取不同的寻呼策
11略寻呼空闲状态的用户终端。对于根据业务属性信息区分出的语音电话和短消息业务，在 资源拥塞时，则对终端优先发起语音电话的业务数据流的寻呼，对语音电话的寻呼可以开 始就在整个跟踪区域表(TA List,Tracking Arealist)内下发，而对短消息的寻呼先在TA List内用户终端所在概率大的TA内下发。如果包含的业务属性信息为数据包的IP地址、端口号、IPSec参数索引、DSCP/T0S 和Flow Label中至少一项的情况，移动管理网元上需要预先配置这些参数对应的业务类 型，或预先配置这些参数对应的业务特性，则根据对应关系可以区分出业务类型或业务特 性，再根据业务类型或业务特性采取不同的寻呼策略寻呼空闲状态的用户终端。步骤306、用户终端收到寻呼后，发起服务请求流程，恢复与网络侧的信令连接和 用户面承载，并转为连接态，；步骤307、在下行隧道有效后，服务网关将缓存的数据包发送给用户终端。实施例三内容可以看出，本发明实施例技术方案在发送给移动管理网元的下行数 据通知消息中包含了数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、Flow Label、业务类型和业务特性中至少一项等作为业务属性信息的内容，因此移动管理网元在 获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同策略的寻呼，从 而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得一些重要及需要 优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量，又能减少网络侧 寻呼用户终端的开销。图4是本发明实施例四的寻呼处理方法流程图。图4中移动管理网元可以指MME或者SGSN，服务网关指SGW，用户终端指UE，数据 网关指PGW，应用服务网关可以指AF或者P-CSCF。服务网关作为策略执行点，实现现有的 策略控制架构中策略执行点的功能。实施例四与上述实施例二和实施例三不同，是从下行业务数据流上下文或者承载 上下文中获取存储的业务类型或业务特性信息。如图4所示，主要包括步骤步骤401、服务网关接收数据包，获取该数据包对应的业务属性信息；服务网关接收从应用服务网关经数据网关发送的下行数据包。在本实施例中，应用服务网关对语音电话的信令消息和短消息业务分别采用不同 的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项来封装 下行数据包。服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据 包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项业务 类型和业务特性。具体内容如下与上述实施例不同，因为本发明实施例中网络侧的策略决策点是根据应用服务网 关发送的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S和FlowLabel中至少一项 来对语音电话的信令消息或者短消息业务生成不同的下行业务数据流过滤器，并将不同的 下行业务数据流过滤器发送给服务网关，因此服务网关在承载或业务数据流的粒度方面可 以区分出不同业务的数据包。服务网关可以根据不同的下行业务数据流过滤器生成不同的 下行流量模板。服务网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及协议号等协议头部信息，匹配到已经存储的下行业务数据流过滤器或下行流量模板， 再根据下行业务数据流过滤器定位对应的下行业务数据流上下文，获知该数据包对应的下 行隧道无效，则获取下行业务数据流上下文中存储的与下行业务数据流过滤器对应的业务 类型或业务特性，将获取的业务类型或业务特性作为业务属性信息；或者，根据下行流量模 板定位对应的承载上下文，获知该数据包对应的下行隧道无效，则获取承载上下文存储的 与下行流量模板对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性 fn息ο进一步的，服务网关根据下行业务数据流上下文或承载上下文或用户上下文中存 储的信息，例如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/T0S和Flow Label中至少一项来封装 下行数据包。数据网关收到下行数据包后获取该数据包对应的业务属性信息。该业务属性信息 可以为以下中的至少一项业务类型和业务特性。具体内容如下1)本发明实施例中网络侧的策略决策点可以根据应用服务网关发送的IP地址、 协议类型、端口号、IPSec参数索引、DSCP/T0S和Flow Label中至少一项来对语音电话的信 令消息或者短消息业务生成不同的下行业务数据流过滤器，并将不同的下行业务数据流过 滤器发送给数据网关，数据网关可以根据不同的下行业务数据流过滤器生成不同的下行流 量模板。数据网关根据下行数据包中的源IP地址、目的IP地址、源端口号、目的端口号及 协议号等协议头部信息，匹配到已经存储的下行业务数据流过滤器或下行流量模板，再根 据下行业务数据流过滤器定位下行业务数据流上下文，并获取其中存储的与下行业务数据 流过滤器对应的业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息； 或者，根据下行流量模板定位对应的承载上下文，获取其中存储的与下行流量模板对应的 业务类型或业务特性，将获取的业务类型或业务特性作为业务属性信息。进一步的，数据网关根据下行业务数据流上下文或承载上下文或用户上下文中存 储的信息，例如APN，可以获知该数据包对应的连接类型。对应特定的连接类型，如IMS业务 的连接类型，获取下行业务数据流上下文存储的与下行业务数据流过滤器对应的业务类型 或业务特性，或者获取承载上下文存储的与下行流量模板对应的业务类型或业务特性。数据网关根据获取的业务类型或业务特性，在给接收到的下行数据包封装外层IP 层时，将外层IP中DSCP/T0S或者Flow Label字段值设置为相应的业务属性对应的值。其中将下行数据包中的DSCP/T0S或者Flow Label字段值设置为相应的业务属 性对应的值，可以是通过不同枚举值或不同比特区分，如枚举值10表示语音电话的信令消 息，枚举值17表示短消息业务的消息，或者如第一比特置1表示语音电话的信令消息，第二 比特置1表示短消息业务的消息。2)应用服务网关对语音电话的信令消息和短消息业务分别采用不同DSCP/T0S或 者Flow Label来封装数据包。网络侧的策略决策点对语音电话的信令消息或者短消息业 务的不进行特殊处理，还是生成相同的下行业务数据流过滤器，并发送给数据网关。此种情况下，数据网关在给接收到的下行数据包封装外层IP层时，将外层IP中 DSCP/T0S或者Flow Label字段值设置为相应的接收的下行数据包的IP层的DSCP/T0S或者 Flow Label 值。步骤502、数据网关向服务网关发送数据包；步骤503、服务网关接收数据包，获取该数据包对应的业务属性信息；服务网关收到下行数据包后，获知该数据包对应的下行隧道无效，则缓存该数据 包，并获取该数据包对应的业务属性信息。该业务属性信息可以为以下中的至少一项 DSCP/TOS.Flow Label、业务类型和业务特性。具体内容如下1)服务网关直接从下行数据包的外层IP层中获取数据包的DSCP/T0S或者Flow Label作为业务属性信息。服务网关可以根据数据包长度或者特性进行深度报文解析后，获 取到上述业务属性信息。所述外层IP层为数据网关接收到下行数据包后封装在该下行数 据包外面的IP层。2)服务网关在上述1)的基础上，根据数据包的DSCP/T0S或者Flow Label与具体 业务类型的对应关系，获知业务类型，将获知的业务类型作为业务属性信息。3)服务网关在上述1)的基础上，根据数据包的DSCP/T0S、Flow Label与具体业 务特性的对应关系，获知业务特性，将获知的业务特性作为业务属性信息。步骤504、服务网关向移动管理网元发送包含业务属性信息的下行数据通知消 息；SGff将业务属性信息包含在下行数据通知消息中发送给移动管理网元。该业务属 性信息为数据包的DSCP/TOS、Flow Label、业务类型和业务特性中至少一项。业务类型可以由一个枚举值表示，如枚举值10表示语音电话的信令消息，枚举值 17表示短消息业务的消息，或者由字段中的不同比特来表示，如第一比特置1表示语音电 话的信令消息，第二比特置1表示短消息业务的消息。业务特性(如高优先级业务，低等待时长业务)可以由一个枚举值表示，如枚举值 1表示高优先级或等待时长较短业务，枚举值2表示低优先级或等待时长较长业务等；或者 由字段中的不同比特来表示，如第一比特置1表示高优先级或等待时长较短业务，第二比 特置1表示低优先级或等待时长较长业务等，本实施例不予限定。步骤505、移动管理网元向服务网关发送下行数据确认消息，确认收到服务网关发 送的下行数据通知消息；步骤506-507、移动管理网元根据业务属性信息采取不同的寻呼策略寻呼空闲状 态的用户终端。移动管理网元获取业务属性信息后，根据不同的业务属性信息采取不同的寻呼策 略寻呼空闲状态的用户终端。对于根据业务属性信息区分出的语音电话和短消息业务，则 对终端优先发起语音电话的业务数据流的寻呼，在资源拥塞时，对语音电话的寻呼可以开 始就在整个TA List内下发，而对短消息的寻呼先在TA List内用户终端所在概率大的TA 内下发。如果包含的业务属性信息为数据包的DSCP/T0S或者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/业务类别T0S、流标签Flow Label、业务类型和业务特性；所述处理单元63包括第一处理单元631和第二处理单元632。第一处理单元631，用于根据预先配置的所述数据包的IP地址、协议类型、端口 号、IPSec参数索引、DSCP/TOS、Flow Label与业务类型的对应关系，获知业务类型，或者， 根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/TOS、Flow Label与业务特性的对应关系，获知业务特性；第二处理单元632，用于根据所述第一处理单元631得到的所述业务类型或者业 务特性对用户终端发起不同策略的寻呼；或者所述处理单元63包括第三处理单元633，用于根据接收单元61接收的通知消息中 的所述业务类型或者业务特性对用户终端发起不同策略的寻呼。图7是本发明实施例的通信装置二结构示意图。
16
如图7所示，通信装置包括生成单元71，用于生成下行数据通知消息，所述下行数据通知消息包含数据的业 务属性信息；发送单元72，用于发送所述生成单元71生成的通知消息，以便移动管理网元根据 所述业务属性信息对用户终端发起不同策略的寻呼。通信装置还包括处理单元73。实施方式一处理单元73，用于在接收数据包后，从数据包对应的用户上下文、承载上下文或者 业务数据流上下文中获取数据的业务属性信息，所述业务属性信息为以下中的至少一项 接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI ；将所述获取的业务属性信息发送给所述生成单元71。实施方式二处理单元73，用于接收数据包；直接从数据包中获取业务属性信息，所述业务属性信息为数据包的IP地址、协议 类型、端口号、IPSec参数索引、DSCP/T0S和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/业务类别T0S、流标签Flow Label、业务类型和业务特性；所述第二通信装置82可以用于据所述业务类型或者业务特性对用户终端发起不 同策略的寻呼；根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索弓|、DSCP/ TOS或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终 端发起不同策略的寻呼；或者根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/ TOS或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用户终 端发起不同策略的寻呼。第二通信装置82具有上述图6所示的结构，具体参见前面描述。综上所述，本发明实施例技术方案是在下行数据通知消息中包含了数据的业务属 性信息，那么在获取这些业务属性信息后，就可以根据业务属性信息对用户终端发起不同 策略的寻呼，从而解决现有技术中无法区分业务而采用统一寻呼策略所导致的缺陷，使得 一些重要及需要优先考虑的业务能够优先建立，从而提高了为用户提供的业务服务质量。本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可 以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存 储介质可以包括只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。以上对本发明实施例所提供的寻呼处理方法、通信装置及通信系统进行了详细介 绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只 是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发 明的思想，在具体实施方式
及应用范围上均会有改变之处，综上所述，本说明书内容不应理 解为对本发明的限制。
权利要求
一种寻呼处理方法，其特征在于，包括移动管理网元接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；获取业务属性信息；根据所述业务属性信息对用户终端发起不同策略的寻呼。
2.根据权利要求1所述的寻呼处理方法，其特征在于所述下行数据通知消息包含的数据的业务属性信息为以下中的至少一项接入点名称 APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI ； 所述根据所述业务属性信息对用户终端发起不同策略的寻呼包括 根据所述APN、QCI或者SI对用户终端发起不同策略的寻呼；根据所述EBI定位到承载上下文得到对应的APN或者QCI，根据所述APN或者QCI对用 户终端发起不同策略的寻呼；或者，根据所述LBI定位到承载上下文得到对应的APN，根据所述APN对用户终端发起不同策 略的寻呼。
3.根据权利要求2所述的寻呼处理方法，其特征在于，还包括服务网关从用户上下文、承载上下文，或者业务数据流上下文中获取所述业务属性信 息，向移动管理网元发送所述下行数据通知消息，所述下行数据通知消息中包含所述业务属性信息。
4.根据权利要求1所述的寻呼处理方法，其特征在于所述下行数据通知消息包含的数据的业务属性信息为以下中的至少一项数据包的 IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业务类别 T0S、流标签Flow Label、业务类型和业务特性；所述根据所述业务属性信息对用户终端发起不同策略的寻呼包括 根据所述业务类型或者业务特性对用户终端发起不同策略的寻呼； 根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终端发 起不同策略的寻呼；或者根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用户终端发 起不同策略的寻呼。
5.根据权利要求4所述的寻呼处理方法，其特征在于，还包括服务网关接收数据网关发送的数据包，所述数据包中包含业务属性信息，服务网关从 数据包中获取所述业务属性信息，向所述移动管理网元发送所述下行数据通知消息，所述 下行数据通知消息包含所述业务属性信息，其中所述业务属性信息为数据包的IP地址、协 议类型、端口号、IPSec参数索引、DSCP/T0S和Flow Label中的至少一项；服务网关根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、 DSCP/T0S或者Flow Label与业务类型的对应关系获知业务类型，向所述移动管理网元发 送所述下行数据通知消息，所述下行数据通知消息包含所述业务类型；服务网关根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S或者Flow Label与业务特性的对应关系获知业务特性，向所述移动管理网元发 送所述下行数据通知消息，所述下行数据通知消息包含所述业务特性；服务网关根据不同的业务数据流过滤器对应的业务数据流上下文，或不同的下行流量 模板对应的承载上下文获取所述业务类型，向所述移动管理网元发送所述下行数据通知消 息，所述下行数据通知消息包含所述业务类型；或者服务网关根据不同的业务数据流过滤器对应的业务数据流上下文，或不同的下行流量 模板对应的承载上下文获取所述业务特性，向所述移动管理网元发送所述下行数据通知消 息，所述下行数据通知消息包含所述业务特性。
6.根据权利要求5所述的寻呼处理方法，其特征在于，还包括所述数据网关根据不同的业务数据流过滤器对应的业务数据流上下文中的信息，或者 根据不同的下行流量模板对应的承载上下文中的信息，确定业务类型后设置DSCP/T0S或 者Flow Label,向服务网关发送数据包，所述数据包中包含所述设置的DSCP/T0S或者Flow Label ；所述数据网关根据不同的业务数据流过滤器对应的业务数据流上下文中的信息，或者 根据不同的下行流量模板对应的承载上下文中的信息，确定业务特性后设置DSCP/T0S或 者Flow Label,向服务网关发送数据包，所述数据包中包含所述设置的DSCP/T0S或者Flow Label ；或者所述数据网关向服务网关发送数据包，所述发送的数据包是将所述数据网关接收的数 据包中IP层的DSCP/T0S或者Flow Label作为发送的数据包中外层的DSCP/T0S或者Flow Label。
7.一种通信装置，其特征在于，包括接收单元，用于接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性 fn息；信息单元，用于获取业务属性信息；处理单元，用于根据所述业务属性信息对用户终端发起不同策略的寻呼。
8.根据权利要求7所述的通信装置，其特征在于所述接收单元接收的通知消息中包含的数据的业务属性信息为以下中的至少一项接 入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI ；所述处理单元包括第一处理单元和第二处理单元第一处理单元，用于根据所述EBI定位到承载上下文得到对应的APN或者QCI，或者，根 据所述LBI定位到承载上下文得到对应的APN ；第二处理单元，用于根据所述第一处理单元得到的所述APN或者QCI对用户终端发起 不同策略的寻呼；或者所述处理单元包括第三处理单元，用于根据接收单元接收的通知消息中的所述APN、 QCI或者SI对用户终端发起不同策略的寻呼。
9.根据权利要求7所述的通信装置，其特征在于所述接收单元接收的通知消息中包含的数据的业务属性信息为以下中的至少一项数 据包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点优先级DSCP/业 务类别T0S、流标签Flow Label、业务类型和业务特性；所述处理单元包括第一处理单元和第二处理单元第一处理单元，用于根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec 参数索引、DSCP/T0S、Flow Label与业务类型的对应关系，获知数业务类型，或者，根据预先 配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S、Flow Label与 业务特性的对应关系，获知业务特性；第二处理单元，用于根据所述第一处理单元得到的所述业务类型或者业务特性对用户 终端发起不同策略的寻呼；或者所述处理单元包括第三处理单元，用于根据接收单元接收的通知消息中的所述业务类 型或者业务特性对用户终端发起不同策略的寻呼。
10.一种通信装置，其特征在于，包括生成单元，用于生成下行数据通知消息，所述下行数据通知消息包含数据的业务属性 fn息；发送单元，用于发送所述生成单元生成的通知消息，以便移动管理网元根据所述业务 属性信息对用户终端发起不同策略的寻呼。
11.根据权利要求10所述的通信装置，其特征在于，还包括处理单元，用于在接收数据包后，从数据包对应的用户上下文、承载上下文或者业务数 据流上下文中获取数据的业务属性信息，所述业务属性信息为以下中的至少一项接入点 名称APN、承载标识EB、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI ； 将所述获取的业务属性信息发送给所述生成单元。
12.根据权利要求10所述的通信装置，其特征在于，还包括 处理单元，用于接收数据包；直接从数据包中获取业务属性信息，所述业务属性信息为数据包的IP地址、协议类 型、端口号、IPSec参数索引、DSCP/T0S和Flow Label中的至少一项；根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务类型的对应关系，获取业务类型作为数据的业务属性信息；根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务特性的对应关系，获取业务特性作为数据的业务属性信息；或者，根据不同的业务数据流过滤器对应的业务数据流上下文或不同的下行流量模板对应 的承载上下文获取业务属性信息，所述业务属性信息为业务类型或者业务特性； 将所述获取的业务属性信息发送给所述生成单元。
13.—种通信系统，其特征在于，包括第一通信装置，用于发送下行数据通知消息，所述下行数据通知消息包含数据的业务 属性信息；第二通信装置，用于接收所述第一通信装置发送的下行数据通知消息，获取所述下行 数据通知消息中的业务属性信息，根据所述业务属性信息对用户终端发起不同策略的寻 呼。
14.根据权利要求13所述的通信系统，其特征在于所述第一通信装置发送的下行数据通知消息中包含的数据的业务属性信息为以下中 的至少一项接入点名称APN、承载标识EBI、服务质量等级标识QCI、缺省承载标识LBI和服务标识SI ；所述第二通信装置具体用于根据所述APN、QCI或者SI对用户终端发起不同策略的寻呼；根据所述EBI定位到承载上下文得到对应的APN或者QCI后，根据所述APN或者QCI 对用户终端发起不同策略的寻呼；或者根据所述LBI定位到承载上下文得到对应的APN，根据所述APN对用户终端发起不同策 略的寻呼。
15.根据权利要求13所述的通信系统，其特征在于所述第一通信装置发送的下行数据通知消息中包含的数据的业务属性信息为以下中 的至少一项数据包的IP地址、协议类型、端口号、IP安全IPSec参数索引、区分服务码点 优先级DSCP/业务类别T0S、流标签Flow Label业务类型和业务特性； 所述第二通信装置具体用于根据所述业务类型或者业务特性对用户终端发起不同策略的寻呼； 根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务类型的对应关系，获知业务类型，根据所述业务类型对用户终端发 起不同策略的寻呼；或者根据预先配置的所述数据包的IP地址、协议类型、端口号、IPSec参数索引、DSCP/T0S 或者Flow Label与业务特性的对应关系，获知业务特性，根据所述业务特性对用户终端发 起不同策略的寻呼。
全文摘要
本发明实施例公开了一种能提高为用户提供的业务服务质量的寻呼处理方法、通信装置及通信系统。该寻呼处理方法，包括移动管理网元接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；获取业务属性信息；根据所述业务属性信息对用户终端发起不同策略的寻呼。一种通信装置，包括接收单元，用于接收下行数据通知消息，所述下行数据通知消息包含数据的业务属性信息；信息单元，用于获取业务属性信息；处理单元，用于根据所述业务属性信息对用户终端发起不同策略的寻呼。本发明实施例还提供相应的通信系统。
文档编号H04W28/24GK101932040SQ20091014842
公开日2010年12月29日 申请日期2009年6月26日 优先权日2009年6月26日
发明者戚彩霞, 银宇 申请人:华为技术有限公司