CN104581815A - 一种寻呼消息处理方法和设备 - Google Patents

Abstract

本申请公开了一种寻呼消息处理方法和设备，包括：当RNC确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，所述RNC判断所述次数是否达到预设的寻呼预警门限；若判断结果为是，所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息；保证了在寻呼拥塞的时候优先处理CS寻呼，提高了实时业务的用户感知和户体验。

Description

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

技术领域

本申请实施例涉及通信技术领域，特别涉及一种寻呼消息处理方法。本申请实施例同时还涉及一种寻呼消息处理设备。

背景技术

随着移动用户的不断增加，语音和数据业务的快速增长，RNC(RadioNetwork Controller无线网络控制器)设备负荷的不断增加，RNC寻呼拥塞率也在不断上升，由寻呼失败和寻呼时间延长触发的问题愈发严重，直接制约到用户体验。

由于现网中用户量不断增加以及实时通信工具等的不断引入，大量寻呼消息在RNC处理到一定程度就会产生拥塞，当拥塞达到一定程度时，RNC单板以及性能处理产生压力，对于寻呼消息的处理能力有限，在性能容量达到门限时，现有方案直接丢弃所有的后续寻呼消息(包括CS(Circuit Switching电路交换)寻呼以及PS(Packet Switching分组交换)寻呼)，直到寻呼消息低于寻呼拥塞门限；当然对于寻呼拥塞的情况，目前也可以通过优化相关系统参数，减少寻呼重发次数、优化LAC(Location Area Code位置区编码)配置来优化，当用户寻呼达到一定程度时，重发次数进行相应调整，减轻寻呼拥塞的压力；优化LAC配置，通过优化LAC以及网络配置，尽量减少在LAC中寻呼的UE(User Equipment用户设备)数目，避免寻呼消息的过多处理，根据网络中寻呼的能力进行调整，达到缓解寻呼拥塞的目的。

由此可见，目前RNC的寻呼拥塞控制方法为了保证已有业务正常的业务处理流程，寻呼次数达到门限后，RNC直接丢弃后续收到的所有寻呼消息(包括CS寻呼以及PS寻呼)，直到寻呼低于寻呼拥塞门限的次数；由于直接丢弃了CS寻呼消息，导致后续的CS被叫无法接通，在RNC的寻呼消息处理能力达到门限时，没有尽可能的保证CS寻呼消息的处理。对于实时业务类型的CS业务，现有的处理方式会使用户感知变得很差，无法在寻呼性能达到瓶颈时实现寻呼消息的优化处理。

发明内容

本发明提供了一种寻呼消息处理方法和设备，保证了在寻呼拥塞的时候优先处理CS寻呼，提高了实时业务的用户感知和户体验。

为了达到上述目的，本发明提供一种寻呼消息处理方法，包括：

当RNC确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，所述RNC判断所述次数是否达到预设的寻呼预警门限；

若判断结果为是，所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

本发明还提供一种寻呼消息处理设备，包括：

判断模块，用于当确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，判断所述次数是否达到预设的寻呼预警门限；

选择模块，用于当所述判断模块判断结果所述次数达到所述寻呼预警门限时，将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

与现有技术相比，本发明至少具有以下优点：引进寻呼预警门限的判别和处理，即在已有的寻呼控制门限基础上，增加寻呼预警门限判别。当寻呼拥塞到达寻呼预警门限的时候，丢弃之后收到的所有PS寻呼，只处理收到的CS寻呼；大于寻呼控制门限，再丢弃之后收到的所有CS和PS寻呼消息；保证了在寻呼拥塞的时候优先处理CS寻呼，提高了实时业务的用户感知和户体验。

附图说明

图1为本申请实施例中的一种寻呼消息处理方法的流程示意图；

图2为本申请中具体场景下实施例中的一种寻呼消息处理方法的流程示意图；

图3为本申请实施例中的一种寻呼消息处理设备的结构示意图。

具体实施方式

下面结合本申请的附图，对本申请的技术方案进行清楚，完整的描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例，基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

如背景技术所述，现有技术中RNC的寻呼拥塞控制方法为了保证已有业务正常的业务处理流程，在寻呼次数达到门限后，直接丢弃后续收到的所有寻呼消息(包括CS寻呼以及PS寻呼)，直到寻呼低于寻呼拥塞门限的次数。由于直接丢弃了CS寻呼消息，导致后续的CS被叫无法接通，从而无法保证CS寻呼消息的处理的方案。对此，本申请实施例一提出了一种寻呼消息处理方法，如图1所示，包括以下步骤：

步骤101，当RNC确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，所述RNC判断所述次数是否达到预设的寻呼预警门限；

在步骤101之前，也即在所述RNC判断所述次数是否达到预设的寻呼预警门限之前，还包括：所述RNC接收CN(Core Network，核心网)发送的寻呼消息，并判断当前已接收到的寻呼消息的次数是否达到所述控制门限，并当所述RNC确定所述次数达到所述控制门限时，所述RNC将后续接收到的寻呼消息全部丢弃。

具体的，本申请中引进双门限的概念(寻呼预警门限和控制门限，其中寻呼预警门限小于控制门限)，其中，寻呼预警门限可以通过控制门限乘以一个比例系数得到，当然也可以基于经验值而设定；在一段时间内，当寻呼的次数高于控制门限时，表示拥塞程度已经很高了，为了保证已有业务的正常进行，因此将后续接收到的所有寻呼消息都丢弃。

若在步骤101中判断所述次数达到预设的寻呼预警门限，则进行步骤102；

步骤102，所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

具体的，当寻呼的次数处于控制门限和寻呼预警门限之间时，表示拥塞程度处于一个较低的水平，可以保证一定业务的进行，而CS寻呼消息所代表的实时业务，相比较与其他的业务，如PS业务，是用户认为比较重要的，因此情况下，在接收到寻呼消息之后，将其中的PS寻呼消息丢弃，而保留CS寻呼消息，从而最大程度保证了CS业务的处理，从而提高了用户的体验。

具体的，在所述RNC判断所述寻呼消息的寻呼次数未达到所述寻呼预警门限(也即不存在拥塞的情况)，或步骤102(也即所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃并保留电路交换CS寻呼消息)之后，还包括：

所述RNC连接所述寻呼消息对应的用户；

如果所述RNC确定自身无法连接所述用户，则所述RNC以广播的方式发送用于建立业务的Pagingtyp1消息；所述Pagingtyp1消息，用于使所述用户在接收到所述Pagingtyp1消息之后进行状态跃迁，发起RRC连接并建立业务；

如果所述RNC确定自身能连接所述用户，则所述RNC向所述用户发送用于建立业务的Pagingtyp2消息；所述PagingType2消息，用于使所述用户在接收到所述PagingType2消息之后建立业务。

具体的，RNC需要将寻呼消息发送给用户，但用户的具体情况是RNC所当前尚不知晓的，如果之前用户已经建立过业务，当然有很多别的情况，只要在RNC中会存在相应记录或标识或本身就RNC已经建立好了连接，在这种情况下，RNC可以直接找到该用户，并将PagingType2消息发送给该用户，以使该用户在接收到该PagingType2消息之后直接建立业务；而当用户之前从来就没有建立过业务，并没有与RNC建立连接，在此情况下，RNC无法找到用户，因此以广播的方式进行群发Pagingtyp1消息，以使的用户接收到该Pagingtyp1消息之后，发生状态的跃迁，建立RRC连接，从空闲态跃迁为连接态，并建立业务。

由此可见，本发明通过引进寻呼预警门限的判别和处理，即在已有的寻呼控制门限基础上，增加寻呼预警门限判别。当寻呼拥塞到达寻呼预警门限的时候，丢弃之后收到的所有PS寻呼，只处理收到的CS寻呼；大于寻呼控制门限，再丢弃之后收到的所有CS和PS寻呼消息；保证了在寻呼拥塞的时候优先处理CS寻呼，提高了实时业务的用户感知和户体验。

为了进一步对本发明进行说明，如图2所示，本申请实施例二提出了一种具体场景下的寻呼消息处理方法，具体包括以下步骤：

步骤201，CN发送寻呼消息到RNC；

步骤202，RNC判断寻呼的次数是否达到控制门限；

若判断寻呼的次数达到了控制门限，则进行步骤203,；

步骤203，RNC丢弃后续接收到的所有寻呼消息；

若判断寻呼的次数没有达到控制门限，则进行步骤204；

步骤204，RNC进一步判断寻呼的次数是否达到预警门限；

若判断结果为是，则进行步骤205；

步骤205，RNC将后续接收到的所有寻呼消息中的PS寻呼消息丢弃，保留CS寻呼消息；

若步骤204中的判断结果为否，或者在步骤205之后，则进行步骤206；

步骤206，RNC判断自身能否与用户连接；

若判断结果为能，则进行步骤207；

步骤207，RNC向用户发送Pagingtyp2消息；

若判断结果为不能，则进行步骤208；

步骤208，RNC向用户发送Pagingtyp1消息；

步骤209，在步骤207，步骤208之后，用户接收到寻呼消息(Pagingtyp1消息或Pagingtyp2消息)，并建立业务，完成整个流程。

本申请实施例三提出了一种寻呼消息处理设备，如图3所示，包括：

判断模块301，用于当确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，判断所述次数是否达到预设的寻呼预警门限；

选择模块302，用于当所述判断模块判断结果所述次数达到所述寻呼预警门限时，将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

具体的，寻呼消息处理设备还包括：

接收模块，用于接收CN发送的寻呼消息，并判断当前已接收到的寻呼消息的次数是否达到所述控制门限。

丢弃模块，用于当确定所述次数达到所述控制门限时，将后续接收到的寻呼消息全部丢弃。

连接模块，用于连接所述寻呼消息对应的用户；

发送模块，用于当所述RNC确定自身无法连接所述用户时以广播的方式发送用于建立业务的Pagingtyp1消息；以及当所述RNC确定自身能连接所述用户时向所述用户发送用于建立业务的Pagingtyp2消息。

其中，所述Pagingtyp1消息，用于使所述用户在接收到所述Pagingtyp1消息之后进行状态跃迁，发起RRC连接并建立业务；

所述PagingType2消息，用于使所述用户在接收到所述PagingType2消息之后建立业务。

与现有技术相比，本发明至少具有以下优点：引进寻呼预警门限的判别和处理，即在已有的寻呼控制门限基础上，增加寻呼预警门限判别。当寻呼拥塞到达寻呼预警门限的时候，丢弃之后收到的所有PS寻呼，只处理收到的CS寻呼；大于寻呼控制门限，再丢弃之后收到的所有CS和PS寻呼消息；保证了在寻呼拥塞的时候优先处理CS寻呼，提高了实时业务的用户感知和户体验。

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

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

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

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

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

Claims (10)

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

当RNC确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，所述RNC判断所述次数是否达到预设的寻呼预警门限；

若判断结果为是，所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

2.如权利要求1所述的方法，其特征在于，在所述RNC判断所述次数是否达到预设的寻呼预警门限之前，还包括：

所述RNC接收CN发送的寻呼消息，并判断当前已接收到的寻呼消息的次数是否达到所述控制门限。

3.如权利要求2所述的方法，其特征在于，还包括：

当所述RNC确定所述次数达到所述控制门限时，所述RNC将后续接收到的寻呼消息全部丢弃。

4.如权利要求1所述的方法，其特征在于，在所述RNC判断所述寻呼消息的寻呼次数未达到所述寻呼预警门限，或所述RNC将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃并保留电路交换CS寻呼消息之后，还包括：

所述RNC连接所述寻呼消息对应的用户；

如果所述RNC确定自身无法连接所述用户，则所述RNC以广播的方式发送用于建立业务的Pagingtyp1消息；

如果所述RNC确定自身能连接所述用户，则所述RNC向所述用户发送用于建立业务的Pagingtyp2消息。

5.如权利要求4所述的方法，其特征在于，

所述Pagingtyp1消息，用于使所述用户在接收到所述Pagingtyp1消息之后进行状态跃迁，发起RRC连接并建立业务；

所述PagingType2消息，用于使所述用户在接收到所述PagingType2消息之后建立业务。

6.一种RNC设备，其特征在于，包括：

判断模块，用于当确定当前已接收到的寻呼消息的次数未达到预设的控制门限时，判断所述次数是否达到预设的寻呼预警门限；

选择模块，用于当所述判断模块判断结果所述次数达到所述寻呼预警门限时，将后续接收到的寻呼消息中的分组交换PS寻呼消息丢弃，并保留电路交换CS寻呼消息。

7.如权利要求6所述的设备，其特征在于，还包括：

接收模块，用于接收CN发送的寻呼消息，并判断当前已接收到的寻呼消息的次数是否达到所述控制门限。

8.如权利要求7所述的设备，其特征在于，还包括：

丢弃模块，用于当确定所述次数达到所述控制门限时，将后续接收到的寻呼消息全部丢弃。

9.如权利要求6所述的设备，其特征在于，还包括：

连接模块，用于连接所述寻呼消息对应的用户；

发送模块，用于当所述RNC设备确定自身无法连接所述用户时以广播的方式发送用于建立业务的Pagingtyp1消息；以及当所述RNC设备确定自身能连接所述用户时向所述用户发送用于建立业务的Pagingtyp2消息。

10.如权利要求9所述的设备，其特征在于，

所述Pagingtyp1消息，用于使所述用户在接收到所述Pagingtyp1消息之后进行状态跃迁，发起RRC连接并建立业务；

所述PagingType2消息，用于使所述用户在接收到所述PagingType2消息之后建立业务。