CN104837201A - 一种寻呼消息处理方法及设备 - Google Patents

Abstract

本发明公开了一种寻呼消息处理方法，当RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时，首先获取RNC设备当前的各负荷控制性能值，并依次根据各负荷控制性能值所在的阈值区间确定与各负荷控制性能值对应的寻呼消息丢弃比例，再根据各负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。通过将各个不同寻呼原因的寻呼消息调整进行发送，实现了RNC设备在大寻呼量冲击下稳定运行的同时尽量降低对用户感知的影响。

Description

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

技术领域

本发明涉及通信技术领域，特别涉及一种寻呼消息处理方法。本发明同时还涉及一种RNC。

背景技术

随着移动数据业务的发展，使用即时通讯类业务的人数越来越多，此类软件的定时更新模式(即客户端通过定时心跳消息与服务器保持连接)导致网络中PS(Packet Switch，分组交换)域的寻呼数量大幅上升，PS寻呼量的翻番极大消耗网络资源，引起RNC设备寻呼拥塞和CPU占用率变高、消息队列阻塞等情况，使RNC设备性能下降和处于过载工作状态。

如图1所示，为现有技术中RNC内寻呼流程。CN在IU口向RNC发送寻呼PAGING消息，消息中携带：寻呼域指示，UE永久标识(国际移动用户识别码IMSI)，UE临时标识、寻呼原因，寻呼区等。核心网CN通过注册、位置区(LAC)更新、路由区(RAC)更新等过程来获知UE所处的位置，因此CN知道UE处于某个LAC/RAC，但并不知道它处于哪个小区；而RNC的处理是以小区为单位的，若RNC收到CN带位置区域(LAC/RAC)的Paging消息时，RNC根据LAC/RAC和小区的映射关系将寻呼区域信息转换为LAC或者RAC包含的小区列表，然后在这个小区列表中的每个小区的PICH和PCH发送寻呼消息。当CN收到对应用户的寻呼域的Initial Ue Message消息时认为寻呼成功响应。如果CN未收到寻呼响应，CN会多次向RNC发送PAGING消息，这些二次呼或者三次呼的寻呼范围可能会扩大以增加寻呼成功率。

如上所述，当智能终端与网络交互频繁时，终端上的服务软件和网络侧服务器在应用层通过交互保持连接，典型的应用是定时心跳保持在线，这种 分组数据协议PDP长期激活和无流量小包业务释放的特性，使得寻呼消息和无线接入承载RAB建立等频繁，或者大量用户定制通知类业务，因此PS域的寻呼已经成为移动网络寻呼的主要触发源，对RNC设备造成很大负荷冲击和寻呼拥塞导致用户体验和感知降低，从而造成寻呼风暴。

由此可见，寻呼消息风暴导致RNC设备短时负载加重，CPU占用率飙升和消息队列阻塞，用户感知和关键绩效指标KPI下降明显，严重时引起设备瘫痪。因此，如何解决PS域寻呼消息在IU口大量集中下发时降低对RNC设备的冲击，成为本领域技术人员亟待解决的技术问题。

发明内容

本发明提供了一种寻呼消息处理方法，用以使RNC在IU口寻呼消息量发生风暴时，针对寻呼消息量进行负荷控制以降低寻呼消息量对RNC设备的冲击，尽量降低寻呼风暴发生时对用户感知的影响，该方法包括：

当RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时，获取所述RNC设备当前的各负荷控制性能值；

判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例，；

根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。

优选地，所述负荷控制性能值至少包括以下类型：

UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的CPU占用率、所述RNC设备当前的消息队列使用率；

其中，所述UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据 的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的CELL的PCH信道参数生成的。

优选地，所述依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃策略，具体为：

当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例；

当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例；

当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例；

当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

优选地，根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息，具体为：

查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述 比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

优选地，在根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息之后，还包括：

当所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度；

判断所述时间长度是否小于预设的时间长度阈值；

若是，在当前周期结束后为所述RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃。

相应地，本发明还提出了一种RNC设备，包括： 

获取模块，用于当所述RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时获取所述RNC设备当前的各负荷控制性能值；

判断模块，用于判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例，；

处理模块，用于根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。

优选地，所述负荷控制性能值至少包括以下类型：

UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的CPU占用率、所述RNC设备当前的消息队列使用率；

其中，所述UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的CELL的PCH信道参数生成的。

优选地，所述确定模块具体用于：

当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例；

当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例；

当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例；

当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

优选地，所述处理模块具体用于：

查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

优选地，还包括：

保护模块，用于当所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度，并在判断所述时间长度小于预设的时间长度阈值时，在当前周期结束后为所述 RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃。

由此可见，通过应用本发明的技术方案，当RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时，首先获取RNC设备当前的各负荷控制性能值，并依次根据各负荷控制性能值所在的阈值区间确定与各负荷控制性能值对应的寻呼消息丢弃比例，再根据各负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。通过将各个不同寻呼原因的寻呼消息调整进行发送，实现了RNC设备在大寻呼量冲击下稳定运行的同时尽量降低对用户感知的影响。

附图说明

图1为现有技术中RNC内寻呼流程处理示意图；

图2为本发明提出的一种寻呼消息处理的流程示意图；

图3为本发明提出的一种RNC设备的结构示意图；

具体实施方式

有鉴于背景技术中所提出的技术问题，本发明提出了一种寻呼消息处理方法，由RNC根据寻呼消息中域指示、寻呼原因、寻呼区等设置不同的寻呼消息优先级且根据RNC当前空口寻呼消息量、空口寻呼拥塞率、CPU占用率、消息队列阀值等动态控制RNC可处理的寻呼消息，在保证设备稳定性的同时尽量保证用户感知。如图2所示，该方法包括以下步骤：

S201，当RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时，获取所述RNC设备当前的各负荷控制性能值。

具体地，在本发明优选的实施例中，一共提出了UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的CPU占用率、所述RNC 设备当前的消息队列使用率等四种负荷控制性能值，需要说明的是，UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的CELL的PCH信道参数生成的。

S202，判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例。

基于S201中所提出的四种负荷控制性能值，其相应的丢弃比例确定方式如下：

(1)当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例。

在本发明优选的实施例中，以上UU接口寻呼负荷门限占比的确定过程如下：

若所述UU接口寻呼负荷门限占比达到第一负荷阈值时，确认所述RNC设备的UU接口寻呼负荷门限级别为1，并获取与级别为1的UU接口寻呼负荷门限所对应的各类型寻呼原因的丢弃比例；

若所述UU接口寻呼负荷门限占比达到第二负荷阈值时，确认所述RNC设备的UU接口寻呼负荷门限级别为2，并获取与级别为2的UU接口寻呼负荷门限所对应的各类型寻呼原因的丢弃比例；

若所述UU接口寻呼负荷门限占比达到第三负荷阈值时，确认所述RNC设备的UU接口寻呼负荷门限级别为3，并获取与级别为3的UU接口寻呼负荷门限所对应的各类型寻呼原因的丢弃比例；

若所述UU接口寻呼负荷门限占比达到第四负荷阈值时，确认所述RNC设备的UU接口寻呼负荷门限级别为4，并获取与级别为4的UU接口寻呼负荷门限所对应的各类型寻呼原因的丢弃比例。

(2)当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例。

在本发明优选的实施例中，以上UU接口寻呼拥塞比率的确定过程如下：

若所述UU接口寻呼拥塞比例占比达到第一拥塞阈值时，确认所述RNC设备的UU接口寻呼拥塞级别为1，并获取与级别为1的UU接口寻呼拥塞所对应的各类型寻呼原因的丢弃比例；

若所述UU接口寻呼拥塞比例占比达到第二拥塞阈值时，确认所述RNC设备的UU接口寻呼拥塞级别为2，并获取与级别为2的UU接口寻呼拥塞所对应的各类型寻呼原因的丢弃比例

若所述UU接口寻呼拥塞比例占比达到第三拥塞阈值时，确认所述RNC设备的UU接口寻呼拥塞级别为3，并获取与级别为3的UU接口寻呼拥塞所对应的各类型寻呼原因的丢弃比例。

(3)当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例。

在本发明优选的实施例中，以上CPU占用率的确定过程如下：

若所述CPU占用率占比达到第一占用率阈值时，确认所述RNC设备的CPU过载级别为1，并获取与级别为1的CPU过载所对应的各类型寻呼原因的丢弃比例；

若所述CPU占用率占比达到第二占用率阈值时，确认所述RNC设备的 CPU过载级别为2，并获取与级别为2的CPU过载所对应的各类型寻呼原因的丢弃比例；

若所述CPU占用率占比达到第三占用率阈值时，确认所述RNC设备的CPU过载级别为3，并获取与级别为3的CPU过载所对应的各类型寻呼原因的丢弃比例；

若所述CPU占用率占比达到第四占用率阈值时，确认所述RNC设备的CPU过载级别为4，并获取与级别为4的CPU过载所对应的各类型寻呼原因的丢弃比例。

(4)当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

在本发明优选的实施例中，以上消息队列使用率的确定过程如下：

若所述消息队列使用率占比达到第一使用率阈值时，确认所述RNC设备的消息队列拥塞级别为1，并获取与级别为1的消息队列拥塞所对应的各类型寻呼原因的丢弃比例；

若所述消息队列使用率占比达到第二使用率阈值时，确认所述RNC设备的消息队列拥塞级别为2，并获取与级别为2的消息队列拥塞所对应的各类型寻呼原因的丢弃比例；

若所述消息队列使用率占比达到第三使用率阈值时，确认所述RNC设备的消息队列拥塞级别为3，并获取与级别为3的消息队列拥塞所对应的各类型寻呼原因的丢弃比例。

需要说明的是，以上针对各个负荷控制性能值所提出的具体比例确定仅为本发明的优选实施方式，本领域技术人员可以在此基础上进行改进，这些都属于本发明的保护范围。

S203，根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃 已接收的寻呼消息。

基于S202中所获取的各丢弃比例，该步骤对于寻呼消息的处理过程如下：

步骤a)查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

步骤b)若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

步骤c)若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

同时，出于对RNC设备的保护考虑，在根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息之后，如果所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度，那么将判断所述时间长度是否小于预设的时间长度阈值；

若时间长度小于预设的时间长度阈值，在当前周期结束后为所述RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃；

如果时间长度不小于预设的时间长度阈值，那么将不执行对RNC设备的的预置保护间隔周期处理了。

为了进一步阐述本发明的技术思想，现结合具体的应用场景，对本发明的技术方案进行说明。由于UE对CS业务(话音，短信)的敏感度高，对于PS业务敏感度相对低一些，在PS域寻呼风暴发生时，运营商希望延迟或者拒绝PS业务的接入请求而优先发送CS寻呼消息从而提升终端客户满意度。即使是CS域的寻呼，语音相较短信感知更强烈，因此，首先对寻呼消息进行 优先级分类，CS域高于PS域，根据寻呼原因设置不同优先级。具体地，寻呼消息中寻呼原因定义如下表1所示：

表1

基于上述表1的内容，CS域寻呼原因优先级设置如下：

语音被叫Terminating Conversational Call,

语音短信接收Terminating Low Priority Signalling，

语音彩信接收Terminating High Priority Signalling。

相应地，PS域寻呼原因优先级设置如下：

手机电视，视频点播等  Terminating Streaming Call,

在线游戏，网页浏览等  Terminating Interactive Call,

图铃下载，邮件收发等  Terminating Background Call,

PS域短信(SMS)  Terminating Low Priority Signalling, 

定位业务(LCS)  Terminating High Priority Signalling。

设置完毕后，该具体实施例进行寻呼消息处理的过程分为寻呼消息接收阶段以及寻呼消息发送阶段，以下将分别进行说明：

一、寻呼消息接收阶段

由于空口寻呼能力与PCH与PICH信道的容量相关，PCH寻呼能力小于 PICH，所以RNC的寻呼能力由PCH信道容量决定。一个寻呼分组最多能放下寻呼记录数由以下公式计算：

PagingNum＝(Npch*floor((TBNum*TBLen–15)/encodelen)*1000)/PBP；

TBNum为PCH一个TTI内最大TB个数；

TBlen为PCH信道SDU长度，为240bit；

Encodelen，当寻呼标识为IMSI时为72，PTMSI/TMSI时为40；

Npch为PCH子信道个数，固定为8；

Floor为向下取整操作；

PBP为寻呼周期，一般为640ms。

以15为PAGING TYPE 1消息中UE Identity子IE前其它子IE ASN.1编码占用bit数目为例，典型现网PCH选择1*240传输格式，采用TMSI编码格式时，PCH每秒可发送寻呼数目为：

(8*floor((1*240-15)/40)*1000)/640＝62.5个。

因此，根据RNC设备配置的CELL的PCH信道参数，计算空口能力可发送的最大寻呼消息数目，设置空口寻呼负荷门限LimitUU＝5秒(可配置)*PagingNum。设置空口寻呼负荷门限LimitUU后，可根据该门限进行寻呼接入频度控制，如果在IU口5秒内收到寻呼数目超过LimitUU后，对后续收到寻呼消息进行丢弃处理。为保证用户感知，高优先级寻呼需优先发送，因此，在单位时间内收到寻呼消息数目达到UU接口门限LimitUU的不同百分比时，根据需要丢弃低优先级寻呼，达到消除寻呼峰值作用的同时又可尽量保证CS域寻呼优先发送。在IU口收到寻呼数目超过UU接口寻呼负荷门限的不同百分比时，各种原因PS寻呼5秒内丢弃比例按如表2所示的寻呼负荷控制表设置来进行，且负荷控制表针对PS域多RAC分别控制。

表2

为避免在设置的5秒周期的后半段集中达到UU接口负荷门限和下一个周期的开始寻呼消息量突发，增加保护间隔，记录达到UU接口负荷门限寻呼量时刻距离当前周期的结束时间，如果小于一个阀值，增加预置保护间隔周期，在预置保护间隔周期内收到寻呼全部丢弃。在新周期开始后，重新统计寻呼数目。

二、寻呼消息发送阶段

UU接口在发送寻呼时，UE计算寻呼时刻时，使用以下公式：

Paging Occasion＝{(IMSI div K)mod(DRX cycle length div PBP)}*PBP 

+n*DRX cycle length+Frame Offset

其中，n＝0,1,2…as long as SFN is below its maximum value.；

K为承载PCH的SCCPCH信道个数；

PBP为寻呼块周期，它等于PICH的重复周期(SIB5中给出)；

Frame Offset为PICH的物理信道偏移(SIB5中给出)；

DRX cycle length为非连续接收周期；

上述公式中只有IMSI是变值，其他值相对固定，因此，即使在PCH空口容量未达最大时，由于IMSI可能过于集中，在网络中可能发生寻呼时刻冲突而导致寻呼拥塞发生(IMSI冲突只能调度一个UE)。如核心网在早晚固定时刻针对定制用户集中发送寻呼进行推送业务。

在现有技术中，一种现网寻呼拥塞统计示例如下：

时间：5分钟粒度； 

DT_寻呼成功率：94.22％；

DT_寻呼次数：9876962；

DT_寻呼拥塞率：5.78％；

DT_寻呼拥塞次数：570710。

在发生空口拥塞时，如果寻呼不区分寻呼原因和优先级，按照寻呼的先后顺序处理，对用户感知影响较大，因此需要采取措施对拥塞和延迟敏感的CS寻呼优先发送，对容忍度较好的PS延迟发送。因此当RNC统计到UU接口寻呼拥塞率高于10％时，对PS的寻呼进行临时限制。每5秒(可设置)进行重新判断来决定是否继续控制PS的接入。在寻呼拥塞比率高于10％时进行PS寻呼控制，由于在现网CS寻呼采用二次呼叫，即使拥塞率10％，两次也就1％，高峰期间丢弃1％是可以接收的，因此可有效控制PS寻呼对系统的影响，在寻呼拥塞发生时，各种原因PS寻呼5秒内丢弃比例按如下表3所示的寻呼负荷控制表设置来进行。

表3

在RNC设备CPU占用率高于门限时，为避免大量PS寻呼消息成功响应后UE大量接入引起RNC设备CPU进一步抬升，可根据RNC设备CPU占用率处于不同级别时，根据寻呼原因的重要性，对携带不同原因的寻呼消息进行按比例丢弃，各种原因PS寻呼在CPU不同过载级别丢弃比例按如表4所示的寻呼负荷控制表设置来进行。

表4

如果在忙时，由于用户接入过多，RNC设备的处理能力如消息队列达到一定阀值，由于寻呼消息大量下发，将消息队列占满，导致其他消息无法处理而溢出。例如PS路由区RAC包含300个CELL，在IU口收到一个寻呼消息，RNC需要将1个IU口寻呼消息转发到300个CELL取处理，即1条IU口寻呼消息转化为300个消息。因此，需要RNC设备根据呼叫不同过程的BHCA，来计算RNC设备消息队列的占用率，在消息队列达到RNC设备设置的预警阀值时，在IU口开始丢弃PS寻呼。各种原因PS寻呼在消息队列拥塞各级别丢弃比例按如下寻呼负荷控制表设置来进行。

表5

RNC设备在收到寻呼时，基于空口寻呼负荷门限LimitUU百分比级别和拥塞门限百分比级别、CPU占用率级别以及消息队列过载级别，按照配置的比例根据寻呼原因丢弃PS域寻呼。具体实现方式如下：

假设某种原因的寻呼以A％拒绝，则： 

if(0＝＝UU接口寻呼负荷门限级别&&0＝＝UU接口寻呼拥塞级别&&0＝＝CPU过载级别&&0＝＝消息队列拥塞级别){负荷均不超标，RNC处理该寻呼消息RNC}；

else if(GMT_Time MOD 100<A){/*任一门限超负荷，RNC按照公式GMT_Time MOD 100<A判断，多门限超负荷，按以下优先级顺序处理：CPU过载级别>消息队列拥塞级别>UU接口寻呼负荷门限级别>UU接口寻呼拥塞级别*/如果产生随机数小于丢弃比例A％，RNC丢弃该寻呼消息}

else{如果产生随机数大于等于丢弃比例A％，RNC处理该寻呼消息}

其中，GMT_Time为RNC收到该寻呼消息的设备GMT时间，单位为秒。

以上空口寻呼负荷门限LimitUU百分比和拥塞门限百分比、CPU占用率以及消息队列使用率对应的级别可以根据设备能力灵活设置。级别设置粒度越小，寻呼控制越精准，最大可设置10级。

针对CS域的不同原因的寻呼，在四种过载情况发生时，优先发送语音寻呼，短信寻呼其次，每种寻呼原因丢弃个数可单独配置在CS域寻呼负荷控制表中。

通过以上过程可以看出，本发明在IU口发生寻呼消息风暴或者突发时，根据寻呼原因定义寻呼消息优先级，再依据四个门限值确定是否需要进行寻呼消息的负荷控制，在任一门限达到设定级别时，采用相应的负荷控制策略进行寻呼消息量消峰处理，尽量保证感知强烈的寻呼优先发送和避免寻呼消息对设备稳定性的冲击。与此同时，根据UU接口PCH寻呼容量、当前空口拥塞率、RNC设备当前CPU占用率、RNC设备当前消息队列使用率基础上根据设置的不同负载级别按设定的比例丢弃不同原因的IU口寻呼。利用寻呼负荷控制表可灵活调整适应RNC设备在不同负载情况下可处理的寻呼消息量，保证RNC设备在大寻呼量冲击下稳定运行的同时尽量降低对用户感知的影响。

为达到以上目的，本发明还提出了一种RNC设备，如图3所示，包括： 

获取模块310，用于当所述RNC设备处于寻呼消息接收阶段或寻呼消息 发送阶段时获取所述RNC设备当前的各负荷控制性能值；

判断模块320，用于判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例，；

处理模块330，用于根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。

在具体的应用场景中，所述负荷控制性能值至少包括以下类型：

UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的CPU占用率、所述RNC设备当前的消息队列使用率；

其中，所述UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的CELL的PCH信道参数生成的。

在具体的应用场景中，所述确定模块具体用于：

当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例；

当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例；

当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例；

当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

在具体的应用场景中，所述处理模块具体用于：

查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

在具体的应用场景中，还包括：

保护模块，用于当所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度，并在判断所述时间长度小于预设的时间长度阈值时，在当前周期结束后为所述RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (10)

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

当无线网络控制器RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时，获取所述RNC设备当前的各负荷控制性能值；

判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例；

根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。

2.如权利要求1所述的方法，其特征在于，所述负荷控制性能值至少包括以下类型：

UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的中央处理器CPU占用率、所述RNC设备当前的消息队列使用率；

其中，所述UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的小区CELL的寻呼信道PCH信道参数生成的。

3.如权利要求2所述的方法，其特征在于，所述依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃策略，具体为：

当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例；

当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例；

当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例；

当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

4.如权利要求3所述的方法，其特征在于，根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息，具体为：

查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

5.如权利要求1-4任一项所述的方法，其特征在于，在根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息之后，还包括：

当所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度；

判断所述时间长度是否小于预设的时间长度阈值；

若是，在当前周期结束后为所述RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃。

6.一种无线网络控制器RNC设备，其特征在于，包括：

获取模块，用于当所述RNC设备处于寻呼消息接收阶段或寻呼消息发送阶段时获取所述RNC设备当前的各负荷控制性能值；

判断模块，用于判断各所述负荷控制性能值所在的阈值区间，并依次根据各所述负荷控制性能值所在的阈值区间确定与各所述负荷控制性能值对应的寻呼消息丢弃比例，所述寻呼消息丢弃比例指示了对于携带各不同类型的寻呼原因的寻呼消息的丢弃比例，；

处理模块，用于根据各所述负荷控制性能值对应的寻呼消息丢弃比例处理或丢弃已接收的寻呼消息。

7.如权利要求6所述的RNC设备，其特征在于，所述负荷控制性能值至少包括以下类型：

UU接口寻呼负荷门限占比、UU接口寻呼拥塞比率、所述RNC设备当前的中央处理器CPU占用率、所述RNC设备当前的消息队列使用率；

其中，所述UU接口寻呼负荷门限占比为单位时间内收到寻呼消息数据的数目与UU接口寻呼负荷门限的比值，所述UU接口寻呼负荷门限是根据所述RNC设备配置的CELL的寻呼信道PCH信道参数生成的。

8.如权利要求7所述的RNC设备，其特征在于，所述确定模块具体用于：

当所述负荷控制性能值为所述UU接口寻呼负荷门限占比时，确定当前的UU接口寻呼负荷门限占比所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼负荷门限级别，获取与所述寻呼负荷门限级别对应的各类型寻呼原因的第一丢弃比例；

当所述负荷控制性能值为所述UU接口寻呼拥塞比率时，确定当前的UU接口寻呼拥塞比率所在的阈值区间，查询与所述阈值区间对应的UU接口寻呼拥塞级别，获取与所述UU接口寻呼拥塞级别对应的各类型寻呼原因的第二丢弃比例；

当所述负荷控制性能值为所述CPU占用率时，确定当前的CPU占用率占比所在的阈值区间，查询与所述阈值区间对应的CPU过载级别，获取与所述CPU过载级别对应的各类型寻呼原因的第三丢弃比例；

当所述负荷控制性能值为所述消息队列使用率时，确定当前的消息队列使用率占比所在的阈值区间，查询与所述阈值区间对应的消息队列拥塞级别，获取与所述消息队列拥塞级别对应的各类型寻呼原因的第四丢弃比例。

9.如权利要求8所述的RNC设备，其特征在于，所述处理模块具体用于：

查询所述寻呼消息对应的寻呼原因分别在各所述丢弃比例中的比例值；

若所述寻呼原因在各所述丢弃比例中的比例值均为0，处理所述寻呼消息；

若所述寻呼原因在各所述丢弃比例中的比例值不同，则根据所述寻呼消息到达时刻所对应的GMT时间与各所述比例值之间的大小关系，以及各所述比例值的优先级顺序，确定处理或丢弃所述寻呼消息。

10.如权利要求6-9任一项所述的RNC设备，其特征在于，还包括：

保护模块，用于当所述RNC设备的UU接口寻呼负荷门限占比到达所述UU接口负荷门限时，获取当前时刻距离当前周期的结束时间的时间长度，并在判断所述时间长度小于预设的时间长度阈值时，在当前周期结束后为所述RNC设备增加预置保护间隔周期，以使所述RNC设备将在所述预置保护间隔周期内收到的寻呼消息全部丢弃。