CN112888065B - 一种寻呼消息的处理方法及相关设备 - Google Patents

Abstract

本申请实施例公开了一种寻呼消息的处理方法及相关设备：控制设备获取对应核心网下发的寻呼消息，并将寻呼消息透传给接入网设备，接入网设备会将该寻呼消息存储在寻呼队列中，接着控制设备会获取(如，周期性获取)接入网设备发送的寻呼队列的队列余量信息，并根据队列余量信息计算接入网设备下发寻呼消息的能力，最后根据其能力决定接下来的寻呼消息以怎样的透传速率发给接入网设备。在本申请实施例中，控制设备可以通过计算接入网设备下发寻呼消息的能力来决定何时给接入网设备透传寻呼消息及以何种速率透传，这样就可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

Description

一种寻呼消息的处理方法及相关设备

技术领域

本申请涉及通信技术领域，尤其涉及一种寻呼消息的处理方法及相关设备。

背景技术

在移动通信系统中，接入网设备(如，2G/3G/4G/5G等的基站)会根据业务的不同需求向终端发送寻呼消息，例如短消息类的寻呼消息(如，系统信息更新、地震海啸预警系统消息等)或寻呼终端类的寻呼消息等。

目前，寻呼消息的下发过程是：首先，控制设备(如，2G/3G的基站控制器(BaseStation Controller,BSC)、4G的移动性管理实体(Mobility Management Entity，MME)、5G的CU/DU等)从A口或Lu-CS口收到对应网络的核心网下发的寻呼消息(Paging)，之后将该寻呼消息透传给对应的接入网设备，接入网设备据此建立寻呼队列，之后通过空口的寻呼信道将寻呼队列里的寻呼消息依次顺序的下发出去。

然而，由于接入网设备上的寻呼队列的长度有大小限制，并且由于各个寻呼消息不是匀速到达寻呼队列，若在某个时间段内大量的寻呼消息涌入寻呼队列，将会导致寻呼队列溢出，此时再由控制设备发送到接入网设备的寻呼消息就会被直接丢弃。

发明内容

本申请第一方面提供了一种寻呼消息的处理方法，具体包括：

首先，控制设备(如，2G/3G的BSC、4G的MME、5G的CU/DU等)从A口或Lu-CS口收到对应的核心网下发的寻呼消息，之后该控制设备将该寻呼消息透传给接入网设备(如，2G/3G/4G/5G等的基站)，接入网设备会将该寻呼消息存储在接入网设备的寻呼队列中(该寻呼队列中还存有之前获取到的还未从空口的PCH信道发送出去的其他寻呼消息)，接着控制设备会获取(如，周期性获取)该接入网设备发送的该寻呼队列的队列余量信息，并根据该队列余量信息计算接入网设备下发寻呼消息的能力，最后根据其能力决定接下来的寻呼消息以怎样的透传速率发给接入网设备。

在本申请上述实施例中，控制设备可以通过计算接入网设备下发寻呼消息的能力而决定什么时候给接入网设备透传寻呼消息及以什么样的速率透传，使得寻呼消息平滑下发至接入网设备，以确保PCH不空闲，每个PCH都有寻呼消息可发送，同时也不会导致过多的寻呼消息同时被透传至接入网设备，即可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

结合本申请第一方面，在本申请第一方面的第一种实施方式中，该寻呼队列的队列余量信息可以是接入网设备周期性获取到的寻呼队列的队列余量，即接入网设备会按照预设周期(如，10s、20s等)去获取寻呼队列的队列余量，并将获取到的队列余量周期性上报至控制设备；该寻呼队列的队列余量信息也可以是当寻呼队列的队列量超过预设阈值(如，寻呼队列的队列量超过80％，则此时寻呼队列的队列余量就是不足20％)时，接入网设备就会将该队列余量上报至控制设备，用于警示寻呼队列将满，具体此处对寻呼队列的队列余量信息不做限定。

在本申请上述实施方式中，具体阐述了队列余量信息的几种表现形式，具备灵活性。

结合本申请第一方面以及第一方面的第一种实施方式，在本申请第一方面的第二种实施方式中，控制设备除了可以获取寻呼队列的队列余量信息，也可以进一步获取由接入网设备周期性发送的空口的PCH数量，这样控制设备还可以进一步根据队列余量信息以及PCH数量来计算接入网设备下发寻呼消息的能力。

在本申请上述实施方式中，控制设备可以根据获取到的队列余量信息以及PCH数量来共同计算接入网设备下发寻呼消息的能力，这样计算得到的接入网设备下发寻呼消息的能力更准确。

结合本申请第一方面、第一方面的第一种实施方式至第二种实施方式，在本申请第一方面的第三种实施方式中，在控制设备将寻呼消息透传至接入网设备之前，可以先在控制设备内建立缓存队列，控制设备通过控制设备内建立的缓存队列存储未透传至接入网设备的待传寻呼消息，该待传寻呼消息为一个或多个将透传至接入网设备的寻呼消息的集合，当控制设备获取到接入网设备发送的寻呼响应时，该控制设备确定该寻呼响应对应的目标寻呼消息；若控制设备确定该目标寻呼消息存在于待传寻呼消息中，则该控制设备从缓存队列中剔除该目标寻呼消息。

在本申请上述实施方式中，在控制设备内建立缓存队列，并通过及时从缓存队列中剔除已收到寻呼响应的寻呼消息来降低无效寻呼消息(即控制设备已获取到寻呼响应的寻呼消息)对空口资源的占用，提高了寻呼消息的下发效率。

结合本申请第一方面的第三种实施方式，在本申请第一方面的第四种实施方式中，控制设备确定寻呼响应对应的目标寻呼消息具体可以是：控制设备根据寻呼响应中携带的国际移动用户识别码(International Mobile Subscriber Identity，IMSI)或临时移动台标识(Temporary Mobile Subscriber Identity，TMSI)来识别对应的目标寻呼消息。

在本申请上述实施方式中，具体阐述了控制设备如何根据寻呼响应识别出对应的目标寻呼消息的几种实现方式，具备灵活性。

结合本申请第一方面的第三种实施方式至第四种方式，在本申请第一方面的第五种实施方式中，控制设备为几个接入网设备服务，就对应建立几个缓存队列，即缓存队列的数量与寻呼队列的数量一致。

在本申请上述实施方式中，给出了控制设备建立的缓存队列的具体实现形式，具备实操性。

本申请第二方面还提供了一种寻呼消息的处理方法，具体包括：

首先，接入网设备获取由控制设备透传的寻呼消息，该寻呼消息存储于该接入网设备的寻呼队列中；之后，接入网设备获取寻呼队列的队列余量信息，并进一步将该队列余量信息发送至控制设备，以使得控制设备根据该队列余量信息计算接入网设备下发寻呼消息的能力并根据该能力确定下一个周期内寻呼消息的透传速率。

在本申请上述实施例中，控制设备可以通过计算接入网设备下发寻呼消息的能力而决定什么时候给接入网设备透传寻呼消息及以什么样的速率透传，使得寻呼消息平滑下发至接入网设备，以确保PCH不空闲，每个PCH都有寻呼消息可发送，同时也不会导致过多的寻呼消息同时被透传至接入网设备，即可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

结合本申请第二方面，在本申请第二方面的第一种实施方式中，该寻呼队列的队列余量信息可以是接入网设备周期性获取到的寻呼队列的队列余量，即接入网设备会按照预设周期(如，10s、20s等)去获取寻呼队列的队列余量，并将获取到的队列余量周期性上报至控制设备；该寻呼队列的队列余量信息也可以是当寻呼队列的队列量超过预设阈值(如，寻呼队列的队列量超过80％，则此时寻呼队列的队列余量就是不足20％)时，接入网设备就会将该队列余量上报至控制设备，用于警示寻呼队列将满，具体此处对寻呼队列的队列余量信息不做限定。

在本申请上述实施方式中，具体阐述了队列余量信息的几种表现形式，具备灵活性。

结合本申请第二方面以及第二方面的第一种实施方式，在本申请第二方面的第二种实施方式中，接入网设备除了可以获取寻呼队列的队列余量信息，还可以进一步周期性获取空口的PCH数量，并将获取到的队列余量信息以及PCH数量发送至控制设备，以使得控制设备根据队列余量信息以及PCH数量计算接入网设备下发寻呼消息的能力并根据该能力确定下一个周期内寻呼消息的透传速率。

在本申请上述实施方式中，接入网设备可以同时将寻呼队列的队列余量信息以及空口的PCH数量发送至控制设备，从而控制设备就可以根据获取到的队列余量信息以及PCH数量来共同计算接入网设备下发寻呼消息的能力，这样计算得到的接入网设备下发寻呼消息的能力更准确。

结合本申请第二方面、第二方面的第一种实施方式至第二种实施方式，在本申请第二方面的第三种实施方式中，接入网设备获取由控制设备透传的寻呼消息具体可以包括：首先，接入网设备获取由控制设备内建立的缓存队列透传的待传寻呼消息，该待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；之后，若接入网设备获取到移动台(如，手机)上报的寻呼响应，那么接入网设备就会向控制设备发送该寻呼响应，以使得控制设备确定该寻呼响应对应的目标寻呼消息。

在本申请上述实施方式中，说明了接入网设备获取到的寻呼消息都是由控制设备内建立的缓存队列中的待传寻呼消息，并进一步阐述了接入网设备如何将寻呼消息发送至控制设备，以便控制设备能够及时从缓存队列中剔除已收到寻呼响应的寻呼消息来降低无效寻呼消息(即控制设备已获取到寻呼响应的寻呼消息)对空口资源的占用，提高了寻呼消息的下发效率。

结合本申请第二方面的第三种实施方式，在本申请第二方面的第四种实施方式中，寻呼响应中携带有IMSI或TMSI，IMSI或TMSI用于识别与寻呼响应对应的目标寻呼消息。

在本申请上述实施方式中，具体阐述了控制设备可以根据寻呼响应识别出对应的目标寻呼消息的几种实现方式，具备灵活性。

结合本申请第二方面的第三种实施方式至第四种方式，在本申请第二方面的第五种实施方式中，控制设备为几个接入网设备服务，就对应建立几个缓存队列，即缓存队列的数量与寻呼队列的数量一致。

在本申请上述实施方式中，给出了控制设备建立的缓存队列的具体实现形式，具备实操性。

本申请实施例第三方面提供了一种控制设备，其具有实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第四方面还提供了一种接入网设备，其具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

本申请实施例第五方面还提供了一种控制设备，可以包括：存储器、处理器以及总线系统，该存储器和该处理器通过该总线系统连接；其中，存储器用于存储程序和指令；处理器用于调用该存储器中存储的指令执行本申请实施例第一方面以及第一方面中任意一种可能实现方式中的方法。

本申请实施例第六方面还提供了一种接入网设备，可以包括：存储器、处理器以及总线系统，该存储器和该处理器通过该总线系统连接；其中，存储器用于存储程序和指令；处理器用于调用该存储器中存储的指令执行本申请实施例第二方面以及第二方面中任意一种可能实现方式中的方法。

本申请实施例第七方面提供一种通信系统，该通信系统包括控制设备、接入网设备以及核心网，该控制设备可以为本申请实施例第三方面或第五方面所提供的控制设备，该接入网设备可以为本申请实施例第四方面或第六方面所提供的接入网设备，核心网用于向上述所述的控制设备发送寻呼消息。

本申请实施例第八方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第一方面(或第二方面)以及第一方面(或第二方面)任意一种可能实现方式的方法。

本申请实施例第九方面提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机可以执行上述第一方面(或第二方面)以及第一方面(或第二方面)任意一种可能实现方式的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：首先，控制设备(如，2G/3G的BSC、4G的MME、5G的CU/DU等)从A口或Lu-CS口收到对应的核心网下发的寻呼消息，之后该控制设备将该寻呼消息透传给接入网设备(如，2G/3G/4G/5G等的基站)，接入网设备会将该寻呼消息存储在接入网设备的寻呼队列中(该寻呼队列中还存有之前获取到的还未从空口的PCH信道发送出去的其他寻呼消息)，接着控制设备会获取(如，周期性获取)该接入网设备发送的该寻呼队列的队列余量信息，并根据该队列余量信息计算接入网设备下发寻呼消息的能力，最后根据其能力决定接下来的寻呼消息以怎样的透传速率发给接入网设备。在本申请上述实施例中，控制设备可以通过计算接入网设备下发寻呼消息的能力而决定什么时候给接入网设备透传寻呼消息及以什么样的速率透传，使得寻呼消息平滑下发至接入网设备，以确保PCH不空闲，每个PCH都有寻呼消息可发送，同时也不会导致过多的寻呼消息同时被透传至接入网设备，即可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

附图说明

图1为一个复帧周期内默认的信道设置方式的示意图；

图2为本申请实施例通信网络的系统结构的示意图；

图3为寻呼消息的下发过程的示意图；

图4为在某个时间段内大量寻呼消息涌入寻呼队列的示意图；

图5为AGCH被PCH抢占的示意图；

图6为本申请实施例寻呼消息的处理方法的一个示意图；

图7为本申请实施例寻呼消息的处理方法的另一示意图；

图8为本申请实施例寻呼消息的处理方法的另一示意图；

图9为本申请实施例控制设备的一个示意图；

图10为本申请实施例接入网设备的一个示意图；

图11为本申请实施例相关设备实体结构的一个示意图。

具体实施方式

本申请实施例提供了一种寻呼消息的处理方法，控制设备可以通过获取接入网设备的寻呼队列的队列余量信息来计算接入网设备下发寻呼消息的能力，从而决定什么时候给接入网设备透传寻呼消息及以什么样的速率透传，这样就可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

在介绍本实施例之前，首先介绍在本申请实施例中可能出现的概念。应理解的是，相关的概念解释可能会因为本申请实施例的具体情况有所限制，但并不代表本申请仅能局限于该具体情况，在不同实施例的具体情况可能也会存在差异，具体此处不做限定。

寻呼队列：用来存储寻呼消息的数据结构，根据接入网设备空口的寻呼调度周期性先进先出，寻呼队列的队列长度有大小限制。

公共控制信道(Common Control Channel，CCCH)：是一种“一点对多点”的双向控制信道，其用途是在呼叫接续阶段，传输链路连接所需要的控制信令与信息。CCCH分为两种，一种是寻呼信道(Paging Channel，PCH)，一种是接入允许信道(Access GrantChannel，AGCH)。

PCH：传输接入网设备寻呼移动台(mobile station，MS)的信息，即用于寻呼/搜索MS并下发寻呼消息，一个PCH一般可用于同时传输2至4个寻呼消息，PCH属于下行信道，点对多点方式传播。

AGCH：接入网设备在呼叫接续开始时，向MS发送分配专用控制信道的信令，即用于为MS分配一个独立专用控制信道并下发接入命令。AGCH属于下行信道，点对点方式传播。

帧：将时间分割成周期性的一小段。在全球移动通信系统(Global System forMobile Communication，GSM)中，帧可以分为超高帧、超帧、复帧、TDMA帧。一个超高帧＝2048个超帧；一个超帧＝51个复帧或者26个复帧；一个复帧＝26个TDMA帧或者51个TDMA帧，一个TDMA＝8个时隙；时隙是基本的通信单位，其中1个时隙的时间约等于0.577ms。

复帧：在GSM系统中，由26个TDMA帧或51个TDMA帧组成的帧称之为复帧，其中，26帧的用于承载业务信道(Traffic Channel，TCH)，51帧的用于承载控制信道(ControlChannel，CCH)。以GSM为例，每个小区在主广播控制信道(Broadcast Control Channel，BCCH)下行的CCCH下发寻呼消息，在每个复帧周期(0.235s)有9个CCCH，请参阅图1，一般来说，默认的设置是这9个CCCH包括有2个AGCH和7个PCH(厂商也可以是其他设置，此处不予赘述)，其中，只有PCH用于传输寻呼消息，因此，理论计算1小时空口的极限的寻呼消息的发送速率为357089寻呼/小时。

本申请实施例提供的寻呼消息的处理方法可以应用于各种通信网络，例如，可以应用于2G通信网络，也可以应用于3G、4G或5G通信网络，还可以应用于未来通信网络，例如，6G网络、7G网络等，且上述涉及的网元名称/设备名称不限定，均可以替换成在未来通信网络中具备相同或相似功能的网元名称/设备名称，本申请并不做限定。为便于理解，下面对本申请实施例通信网络的系统结构进行说明，具体可如图2所示，该通信网络采用三级网络架构，具体可以包括：核心网、控制设备、接入网设备，其中，核心网的主要作用是把A口或Lu-CS口上的呼叫请求或数据请求，接续到不同的网络上；接入网设备区分与MS有关的话音和控制信令，并通过各自信道传给控制设备；控制设备是接入网设备和核心网之间的连接点，为接入网设备和核心网之间交换信息提供接口，一个控制设备通常控制几个接入网设备，其主要功能是进行无线信道管理、实施呼叫和通信链路的建立和拆除，并为本控制区内MS的过区切换进行控制等。例如，若图2为2G网络的系统架构，则对应的控制设备就为基站控制器(Base Station Controller，BSC)，接入网设备就为对应2G网络的基站收发信机(Base Transceiver Station，BTS)，该基站可以是一体式基站架构的BTS，也可以是分布式基站架构的BTS，具体此处不做限定，需要说明的是，若为分布式基站架构的BTS，则该BTS就包括远端射频模块(Remote Radio Unit，RRU)和室内基带处理单元(Building BasebandUnit，BBU)。类似的，若图2为3G网络的系统架构，则对应的控制设备就为无线网络控制器(Radio Network Controller，RNC)，接入网设备就为对应3G网络的基站。在4G、5G等通信网络中，控制设备、接入网设备以及核心网就为对应网络的网元结构，具体此处不予赘述。

目前寻呼消息的下发过程一般如图3所示，首先，核心网通过A口(或Lu-CS口)向控制设备发送寻呼消息Pn，控制设备获取到该寻呼消息Pn后，就会将其透传给与之对应的各个接入网设备(可以是一个，也可以是多个，此处不做限定，如图2中通信网络中的控制设备就对应有4个接入网设备)，接入网设备上建立有寻呼队列，该寻呼队列中按顺序存储由控制设备透传过来的寻呼消息(如，图3中的寻呼队列中已存储有之前就已透传过来的寻呼消息P1、P2、……)，之后，接入网设备再将寻呼队列中的寻呼消息依次在空口的PCH中下发，如图3中正在空口PCH上下发的是寻呼消息Px，Px为寻呼队列中P1、P2……中的寻呼消息。然而，由于接入网设备上的寻呼队列的长度有大小限制，并且由于各个寻呼消息不是匀速到达寻呼队列，若在某个时间段内大量的寻呼消息涌入寻呼队列，将会导致寻呼队列溢出，如图4所示，在某个时间段大量的寻呼消息被透传至寻呼队列，导致寻呼队列满(如图4中寻呼队列中已经被寻呼消息P1、P2、……Pn占满)，那么新的寻呼消息Pn+1由于无法透传至寻呼队列而被直接丢弃。此外，由于AGCH能够自动抢占PCH，如图5所示，PCH被AGCH抢占就会导致可用的PCH减少，那么空口下发速率也就相应减少，在接入网设备的寻呼周期内(如，5s)寻呼队列中没有及时下发到PCH信道的寻呼消息(如，图5中的P1、P2、P3、……、Pn、Pn+1、Pn+2)也将全部被丢弃。

基于此，为解决上述所述的问题，本申请实施例提供了一种寻呼消息的处理方法，具体请参阅图6：

601、核心网向控制设备发送寻呼消息。

首先，核心网通过A口或Lu-CS口向控制设备发送寻呼消息。

602、控制设备将寻呼消息透传至接入网设备。

控制设备获取到核心网下发的寻呼消息后，就会将该消息透传至对应的接入网设备，与控制设备对应的接入网设备可以是一个，也可以是多个(如，图2中与控制设备对应的接入网设备就为4个)，具体此处不做限定。

603、接入网设备获取寻呼队列的队列余量信息。

接入网设备获取到控制设备透传过来的寻呼消息，就会将该寻呼消息存储在接入网设备上的寻呼队列中，寻呼队列中的寻呼消息时依照先后接收到的时间顺序排列的。接入网设备会获取寻呼队列的队列余量信息。

需要说明的是，该寻呼队列的队列余量信息可以是接入网设备周期性获取到的寻呼队列的队列余量，即接入网设备会按照预设周期(如，10s、20s等)去获取寻呼队列的队列余量，并将获取到的队列余量周期性上报至控制设备；该寻呼队列的队列余量信息也可以是当寻呼队列的队列量超过预设阈值(如，寻呼队列的队列量超过80％，则此时寻呼队列的队列余量就是不足20％)时，接入网设备就会将该队列余量上报至控制设备，用于警示寻呼队列将满，具体此处对寻呼队列的队列余量信息不做限定。

604、接入网设备将队列余量信息发送至控制设备。

之后，接入网设备就将获取到的队列余量信息发送至控制设备。

需要说明的是，在本申请的一些实施方式中，接入网设备还可以进一步按照预设周期获取空口的PCH数量，并将获取到的上述PCH数量也按照预设周期发送至控制设备。

605、控制设备根据队列余量信息计算接入网设备下发寻呼消息的能力。

控制设备获取到接入网设备发送的队列余量信息之后，将根据该队列余量信息计算接入网设备当前周期下发寻呼消息的能力，也就是说，根据队列余量信息评估接入网设备下发寻呼消息的速率。

需要说明的是，在本申请的一些实施方式中，若控制设备还获取到接入网设备周期性发送的空口的PCH数量，那么控制设备还可以进一步根据队列余量信息以及PCH数量来计算接入网设备下发寻呼消息的能力，这样计算得到的接入网设备下发寻呼消息的能力更准确。

606、控制设备根据上述能力确定下一周期内寻呼消息的透传速率。

最后，控制设备根据计算得到的上述能力确定下一个周期内寻呼消息的透传速率，之后，就可按照确定的透传速率将下一轮获取到的寻呼消息透传至接入网设备。

在本申请上述实施例中，控制设备可以通过计算接入网设备下发寻呼消息的能力而决定什么时候给接入网设备透传寻呼消息及以什么样的速率透传，使得寻呼消息平滑下发至接入网设备，以确保PCH不空闲，每个PCH都有寻呼消息可发送，同时也不会导致过多的寻呼消息同时被透传至接入网设备，即可以控制寻呼队列中寻呼消息的数量，始终保持寻呼队列不会溢出，从而解决了发送到接入网设备的寻呼消息可能被直接丢弃的问题。

需要注意的是，通信网络中的控制设备一般都对应多个接入网设备(可参阅图2)，每个接入网设备又可以为一个或多个小区服务，而寻呼消息是广播消息，在同一个位置区码(location area code，LAC)下所有的小区对应的接入网设备均会下发相同的寻呼消息，然而不同的接入网设备下发寻呼消息的速率不同，有些寻呼消息已经通过某个接入网设备上报寻呼响应，但该寻呼消息可能仍然在其他接入网设备的寻呼队列中排队。以图5为例，假设寻呼消息P2、P3已经通过其他接入网设备下发，并且MS(如，手机)已经成功接入并上报了寻呼响应，但寻呼消息P2、P3仍在图5中的接入网设备的寻呼队列中排队，等待依次下发，这类无效的寻呼消息依然占用有限的空口PCH资源，当寻呼量过载时，真正有效的寻呼消息反而可能被丢弃。实际上，若寻呼量达到200000寻呼/小时，就会出现空口过载，远远低于理论值357089寻呼/小时，如果情况进一步加剧，会导致寻呼消息反复发送，空口过载进一步严重，导致寻呼雪崩，形成呼叫无法接通的事故级问题。

基于此，为解决上述所述问题，在本申请的一些实施方式中，在控制设备将寻呼消息透传至接入网设备之前，可以先在控制设备内建立缓存队列，该控制设备为几个接入网设备服务，就对应建立几个缓存队列，即缓存队列的数量与寻呼队列的数量保持一致。如，图2中的控制设备对应有4个接入网设备，那么控制设备内就对应建立有4个缓存队列，控制设备每次从核心网获取到的寻呼消息，都对应先存储至各个接入网设备对应的缓存队列，再由各个缓存队列透传至对应的接入网设备的寻呼队列，存储至各个缓存队列中的寻呼消息可以称为待传寻呼消息，待传寻呼消息就是一个或多个即将透传至接入网设备的寻呼消息的集合。当某个接入网设备获取到MS上报的寻呼响应(说明某个目标寻呼消息被对应的MS获取到)时，接入网设备会将该寻呼响应发送至控制设备，控制设备根据该寻呼响应去各个缓存队列中查找是否有对应的目标寻呼消息还存在于待传寻呼消息中，若确定还有目标寻呼消息存在于待传寻呼消息中，则控制设备就从对应的缓存队列中剔除该目标寻呼消息。

需要说明的是，在本申请的一些实施方式中，寻呼响应中携带有IMSI或TMSI，该IMSI或TMSI用于识别与寻呼响应对应的目标寻呼消息，即控制设备获取到寻呼响应之后，通过识别该寻呼响应中携带的IMSI或TMSI，就可知道对应该寻呼响应的目标寻呼消息是哪个。

为便于理解，下面以图7为例对上述实施所涉及的步骤进行详细说明，图7中以一个控制设备以及一个接入网设备为例，说明接入网设备如何周期性上报寻呼队列的队列余量信息以及空口的PCH数量。首先，控制设备上建立有缓存队列，接入网设备中存在寻呼队列，控制设备通过A口或Lu-CS口从核心网获取寻呼消息Px，并将该寻呼消息先存储至控制设备的缓存队列(图7中的缓存队列中已顺序排列有Pn+1、Pn+2、……)，接入网设备中的寻呼队列中顺序排列有P1、P2、……、Pn，每隔一定的预设周期(如，5s)，接入网设备获取该寻呼队列的队列余量信息(如，队列余量还剩余60％可存储寻呼消息)以及空口的PCH数量，并将该队列余量信息以及PCH数量周期性上报至控制设备，控制设备据此计算接入网设备下发寻呼消息的能力，以便于得到下一轮寻呼消息透传至接入网设备的透传速率，实现平滑下发缓存队列中的寻呼消息(即Pn+1、Pn+2、……)，从而解决了瞬时大量的寻呼消息涌入接入网设备的寻呼队列导致的寻呼消息丢弃的问题。

图7是以一个控制设备以及一个接入网设备为例说明接入网设备如何周期性上报寻呼队列的队列余量信息以及空口的PCH数量，下面以图8为例，说明当一个控制设备对应多个接入网设备(图8中示意的是3个接入网设备，也可以是更多或更少的接入网设备，此处不做限定)时，如何在控制设备的缓存队列中剔除已经收到寻呼响应对应的目标寻呼消息。首先，在控制设备上建立有3个缓存队列，分别记为缓存队列1、缓存队列2、缓存队列3，每个缓存队列对应一个接入网设备的寻呼队列，缓存队列1对应接入网设备1上的寻呼队列1、缓存队列2对应接入网设备2上的寻呼队列2、缓存队列3对应接入网设备3上的寻呼队列3，从图8中可知，寻呼队列1中顺序排列有寻呼消息P2、P3、……,缓存队列1中顺序排列有P11、P12、……；寻呼队列2中顺序排列有寻呼消息P20、P21、……,缓存队列2中顺序排列有P30、P31、……；寻呼队列3中顺序排列有寻呼消息P5、P6、……,缓存队列3中顺序排列有P12、P13、……，需要说明的是，核心网下发的最新的寻呼消息Py将顺序排列在缓存队列1至缓存队列3中的最后。当控制设备获取到接入网设备2上报的与寻呼消息P12对应的寻呼响应时，就可以根据寻呼响应中的TMSI或IMSI识别出该寻呼响应对应的是寻呼消息P12，那么控制设备就会在缓存队列1、缓存队列3中查找是否还存在有寻呼消息P12，由图8可知缓存队列1、缓存队列3中是存在寻呼消息P12还未下发至各自对应的寻呼队列的，因此控制设备就会将缓存队列1、缓存队列3中的寻呼消息P12及时进行剔除，从而降低了无效寻呼消息(即控制设备已获取到寻呼响应的寻呼消息)对空口资源的占用，提高了寻呼消息的下发效率，缓解了寻呼消息实际下发量远低于理论下发量的情况，如，实际接入网设备每小时可以下发20万个寻呼消息，使用上述寻呼消息的处理方法后，每小时下发寻呼量可以接近理论值每小时35万个寻呼消息。

本申请实施例还可以根据上述寻呼消息的处理方法的示例，对通信网络的相关设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

例如，图9示出了一种控制设备的示意图，本申请实施例提供的控制设备可以包括：

第一获取模块901，用于获取由核心网发送的寻呼消息；

透传模块902，用于将所述寻呼消息透传至接入网设备，所述寻呼消息存储于所述接入网设备的寻呼队列中；

第二获取模块903，用于获取由所述接入网设备发送的所述寻呼队列的队列余量信息；

计算模块904，用于根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力；

确定模块905，用于根据所述能力确定下一个周期内寻呼消息的透传速率。

优选的，在本申请的一些实施方式中，所述队列余量信息包括：由所述接入网设备周期性发送的所述寻呼队列的队列余量；或，达到预设值的所述寻呼队列的队列余量。

优选的，在本申请的一些实施方式中，所述第二获取模块903，还用于获取由所述接入网设备周期性发送的PCH数量；

所述计算模块904，还用于根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力。

优选的，在本申请的一些实施方式中，所述透传模块902，还用于在将所述寻呼消息透传至接入网设备之前，通过所述控制设备内建立的缓存队列存储未透传至所述接入网设备的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

所述确定模块905，具体用于当获取到所述接入网设备发送的寻呼响应时，确定所述寻呼响应对应的目标寻呼消息，若所述目标寻呼消息存在于所述待传寻呼消息，则从所述缓存队列中剔除所述目标寻呼消息。

优选的，在本申请的一些实施方式中，所述确定模块905具体还用于：根据所述寻呼响应中携带的国际移动用户识别码IMSI或临时移动台标识TMSI识别对应的目标寻呼消息。

优选的，在本申请的一些实施方式中，所述缓存队列的数量与所述寻呼队列的数量一致。

图9对应的实施例中的控制设备具体的功能以及结构用于实现前述图6至图8中由控制设备进行处理的步骤，具体此处不予赘述。

此外，图10还示出了一种接入网设备的示意图，本申请实施例提供的接入网设备可以包括：

第一获取模块1001，用于获取由控制设备透传的寻呼消息，所述寻呼消息存储于所述接入网设备的寻呼队列中；

第二获取模块1002，用于获取所述寻呼队列的队列余量信息；

发送模块1003，用于将所述队列余量信息发送至所述控制设备，以使得所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

优选的，在本申请的一些实施方式中，所述队列余量信息包括：所述接入网设备周期性获取到的所述寻呼队列的队列余量；或，达到预设值的所述寻呼队列的队列余量。

优选的，在本申请的一些实施方式中，所述第二获取模块1002，还用于周期性获取PCH数量；

所述发送模块1003，具体用于将所述队列余量信息以及所述PCH数量发送至所述控制设备，以使得所述控制设备根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

优选的，在本申请的一些实施方式中，所述第一获取模块1001，具体用于获取由所述控制设备内建立的缓存队列透传的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

所述发送模块1003，还用于向所述控制设备发送寻呼响应，以使得所述控制设备确定所述寻呼响应对应的目标寻呼消息。

优选的，在本申请的一些实施方式中，所述寻呼响应中携带有IMSI或TMSI，所述IMSI或所述TMSI用于识别与所述寻呼响应对应的所述目标寻呼消息。

优选的，在本申请的一些实施方式中，所述缓存队列的数量与所述寻呼队列的数量一致。

图10对应的实施例中的接入网设备具体的功能以及结构用于实现前述图6至图8中由接入网设备进行处理的步骤，具体此处不予赘述。

如图11所示，为本申请实施例相关设备(可以是接入网设备，也可以是控制设备)的另一示意图，为便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该设备1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在设备1100上执行存储介质1130中的一系列指令操作。

设备1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述图6至图7对应的实施例中由控制设备所执行的步骤可以基于该图8所示的结构实现，上述图6至图7对应的实施例中由接入网设备所执行的步骤也可以基于该图8所示的结构实现，具体此处不做限定。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

Claims (28)

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

控制设备获取由核心网发送的寻呼消息；

所述控制设备将所述寻呼消息透传至接入网设备，所述寻呼消息存储于所述接入网设备的寻呼队列中；

所述控制设备获取由所述接入网设备发送的所述寻呼队列的队列余量信息；

所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力；

所述控制设备根据所述能力确定下一个周期内寻呼消息的透传速率。

2.根据权利要求1所述的方法，其特征在于，所述队列余量信息包括：

由所述接入网设备周期性发送的所述寻呼队列的队列余量；

或，

达到预设值的所述寻呼队列的队列余量。

3.根据权利要求1-2中任一项所述的方法，其特征在于，在所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力之前，所述方法还包括：

所述控制设备获取由所述接入网设备周期性发送的空口的寻呼信道PCH数量；

所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力包括：

所述控制设备根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力。

4.根据权利要求1-2中任一项所述的方法，其特征在于，在所述控制设备将所述寻呼消息透传至接入网设备之前，所述方法还包括：

所述控制设备通过所述控制设备内建立的缓存队列存储未透传至所述接入网设备的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

当所述控制设备获取到所述接入网设备发送的寻呼响应时，所述控制设备确定所述寻呼响应对应的目标寻呼消息；

若所述目标寻呼消息存在于所述待传寻呼消息，则所述控制设备从所述缓存队列中剔除所述目标寻呼消息。

5.根据权利要求4所述的方法，其特征在于，所述控制设备确定所述寻呼响应对应的目标寻呼消息包括：

所述控制设备根据所述寻呼响应中携带的国际移动用户识别码IMSI或临时移动台标识TMSI识别对应的目标寻呼消息。

6.根据权利要求4所述的方法，其特征在于，所述缓存队列的数量与所述寻呼队列的数量一致。

7.一种寻呼消息的处理方法，其特征在于，包括：

接入网设备获取由控制设备透传的寻呼消息，所述寻呼消息存储于所述接入网设备的寻呼队列中；

所述接入网设备获取所述寻呼队列的队列余量信息；

所述接入网设备将所述队列余量信息发送至所述控制设备，以使得所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

8.根据权利要求7所述的方法，其特征在于，所述队列余量信息包括：

所述接入网设备周期性获取到的所述寻呼队列的队列余量；

或，

达到预设值的所述寻呼队列的队列余量。

9.根据权利要求7-8中任一项所述的方法，其特征在于，所述方法还包括：

所述接入网设备周期性获取空口的PCH数量；

所述接入网设备将所述队列余量信息发送至所述控制设备，以使得所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率包括：

所述接入网设备将所述队列余量信息以及所述PCH数量发送至所述控制设备，以使得所述控制设备根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

10.根据权利要求7-8中任一项所述的方法，其特征在于，所述接入网设备获取由控制设备透传的寻呼消息包括：

所述接入网设备获取由所述控制设备内建立的缓存队列透传的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

所述方法还包括：

所述接入网设备向所述控制设备发送寻呼响应，以使得所述控制设备确定所述寻呼响应对应的目标寻呼消息。

11.根据权利要求10所述的方法，其特征在于，

所述寻呼响应中携带有IMSI或TMSI，所述IMSI或所述TMSI用于识别与所述寻呼响应对应的所述目标寻呼消息。

12.根据权利要求10所述的方法，其特征在于，所述缓存队列的数量与所述寻呼队列的数量一致。

13.一种控制设备，其特征在于，包括：

第一获取模块，用于获取由核心网发送的寻呼消息；

透传模块，用于将所述寻呼消息透传至接入网设备，所述寻呼消息存储于所述接入网设备的寻呼队列中；

第二获取模块，用于获取由所述接入网设备发送的所述寻呼队列的队列余量信息；

计算模块，用于根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力；

确定模块，用于根据所述能力确定下一个周期内寻呼消息的透传速率。

14.根据权利要求13所述的控制设备，其特征在于，所述队列余量信息包括：

由所述接入网设备周期性发送的所述寻呼队列的队列余量；

或，

达到预设值的所述寻呼队列的队列余量。

15.根据权利要求13-14中任一项所述的控制设备，其特征在于，

所述第二获取模块，还用于获取由所述接入网设备周期性发送的PCH数量；

所述计算模块，还用于根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力。

16.根据权利要求13-14中任一项所述的控制设备，其特征在于，

所述透传模块，还用于在将所述寻呼消息透传至接入网设备之前，通过所述控制设备内建立的缓存队列存储未透传至所述接入网设备的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

所述确定模块，具体用于当获取到所述接入网设备发送的寻呼响应时，确定所述寻呼响应对应的目标寻呼消息，若所述目标寻呼消息存在于所述待传寻呼消息，则从所述缓存队列中剔除所述目标寻呼消息。

17.根据权利要求16所述的控制设备，其特征在于，所述确定模块具体还用于：

根据所述寻呼响应中携带的国际移动用户识别码IMSI或临时移动台标识TMSI识别对应的目标寻呼消息。

18.根据权利要求16所述的控制设备，其特征在于，所述缓存队列的数量与所述寻呼队列的数量一致。

19.一种接入网设备，其特征在于，包括：

第一获取模块，用于获取由控制设备透传的寻呼消息，所述寻呼消息存储于所述接入网设备的寻呼队列中；

第二获取模块，用于获取所述寻呼队列的队列余量信息；

发送模块，用于将所述队列余量信息发送至所述控制设备，以使得所述控制设备根据所述队列余量信息计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

20.根据权利要求19所述的接入网设备，其特征在于，所述队列余量信息包括：

所述接入网设备周期性获取到的所述寻呼队列的队列余量；

或，

达到预设值的所述寻呼队列的队列余量。

21.根据权利要求19-20中任一项所述的接入网设备，其特征在于，

所述第二获取模块，还用于周期性获取PCH数量；

所述发送模块，具体用于将所述队列余量信息以及所述PCH数量发送至所述控制设备，以使得所述控制设备根据所述队列余量信息以及所述PCH数量计算所述接入网设备下发寻呼消息的能力并根据所述能力确定下一个周期内寻呼消息的透传速率。

22.根据权利要求19-20中任一项所述的接入网设备，其特征在于，

所述第一获取模块，具体用于获取由所述控制设备内建立的缓存队列透传的待传寻呼消息，所述待传寻呼消息为一个或多个将透传至所述接入网设备的所述寻呼消息的集合；

所述发送模块，还用于向所述控制设备发送寻呼响应，以使得所述控制设备确定所述寻呼响应对应的目标寻呼消息。

23.根据权利要求22所述的接入网设备，其特征在于，所述寻呼响应中携带有IMSI或TMSI，所述IMSI或所述TMSI用于识别与所述寻呼响应对应的所述目标寻呼消息。

24.根据权利要求22所述的接入网设备，其特征在于，所述缓存队列的数量与所述寻呼队列的数量一致。

25.一种控制设备，其特征在于，包括：处理器和存储器；

所述存储器用于存储程序；

所述处理器用于执行所述程序，以实现如权利要求1-6中任意一项所述的方法。

26.一种接入网设备，其特征在于，包括：处理器和存储器；

所述存储器用于存储程序；

所述处理器用于执行所述程序，以实现如权利要求7-12中任意一项所述的方法。

27.一种通信系统，其特征在于，包括：控制设备、接入网设备以及核心网；

所述控制设备，用于实现如权利要求1-6中任意一项所述的方法；

所述接入网设备，用于实现如权利要求7-12中任意一项所述的方法；

所述核心网，用于向所述控制设备发送寻呼消息。

28.一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1-12中任一项所述的方法。

Images