寻呼消息的流控方法、装置和系统与流程

本发明实施例涉及通信技术，特别涉及一种寻呼消息的流控方法、装置和系统。

背景技术：

核心网(Core Network；简称CN)网元给无线接入网(Radio Access Network，简称RAN)网元发送的寻呼(paging)消息是终端入网流程的起始消息，会触发后续一系列信令流程。如果触发大量的终端同时入网，会为整个系统带来很大开销。随着无线通信的普及与发展，信令面风暴场景发生的概率不断增大，做好寻呼消息的流控机制对系统可靠性来说至关重要。

目前的寻呼消息流控机制是在出现系统信令面过载的场景，通过对寻呼消息的流控，来控制系统负载，保证已入网终端的业务，从而提高系统的可靠性。然而，这种机制应用于多运营商核心网络(Multi-operator core network；简称：MOCN)组网场景时，无法保证每个运营商业务的公平性。

技术实现要素：

本发明实施例提供了一种寻呼消息的流控方法、装置和系统，以提高在MOCN组网下每个运营商业务的公平性。

第一方面，本发明实施例提供一种寻呼消息的流控方法，应用于运营商核心网络(MOCN)系统中，该MOCN系统包括无线接入网(RAN)网元和多个运营商的核心网(CN)网元，该多个运营商的CN网元共享所述RAN网元，所述RAN网元存储有所述多个运营商之间共享所述RAN网元的资源比例，所述方法包括：

所述RAN网元接收所述多个运营商的CN网元发送的寻呼消息；

当所述RAN网元过载时，所述RAN网元根据所述资源比例对所接收到的寻呼消息进行流控。

结合第一方面，在第一方面的第一种可能的实现方式中，所述资源比例表明各运营商占用RAN网元的资源的比例，或者各运营商寻呼的终端的比例。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，当接收到的寻呼消息超过所述RAN网元的寻呼消息阈值时，所述RAN网元过载包括寻呼消息过载；所述寻呼消息阈值小于或等于所述RAN网元在预定周期内能够处理寻呼消息的个数。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，根据所述资源比例对所接收到的寻呼消息进行流控，包括：

根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值；

确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

以所述第一运营商的寻呼消息目标值为目标，对所述第一运营商进行寻呼消息的流控。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，以所述第一运营商的寻呼消息目标值为目标，对所述第一运营商进行寻呼消息的流控，包括：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的寻呼消息是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控；或者，

将所述第一运营商的寻呼消息中超过所述第一运营商的寻呼消息目标值的寻呼消息丢弃。

结合第一方面的第二种可能的实现方式，在第一方面的第五种可能的实现方式中，根据所述资源比例对所接收到的寻呼消息进行流控，包括：

根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值；

确定寻呼消息的数量超过对应的寻呼消息目标值的第一运营商，和寻呼消息的数量不超过对应的寻呼消息目标值的第二运营商；

确定所述RAN网元的寻呼消息阈值与第二运营商的寻呼消息的差值；

以所述差值为流控阈值，对第一运营商进行寻呼消息的流控。

结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，以所述差值为流控阈值，对第一运营商进行寻呼消息的流控，包括：

当所述第一运营商为一个时，丢弃所述第一运营商的多于所述流控阈值的寻呼消息；或者，

当所述第一运营商为多个时，根据所述流控阈值和所述资源比例，确定各第一运营商流控目标值；将各第一运营商多于其流控目标值的寻呼消息丢弃。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第七种可能的实现方式中，所述RAN网元过载包括处理器过载。

结合第一方面的第七种可能的实现方式，在第一方面的第八种可能的实现方式中，根据所述资源比例对所接收到的寻呼消息进行流控，包括：

根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值；

确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

对所述第一运营商进行寻呼消息的流控。

结合第一方面的第八种可能的实现方式，在第一方面的第九种可能的实现方式中，在根据所述资源比例对所接收到的寻呼消息进行流控之前，还包括：确定所述RAN网元的寻呼消息是否过载；

且在所述寻呼消息不过载且处理器过载时，根据所述资源比例对所接收到的寻呼消息进行流控。

结合第一方面的第八种或第一方面的第九种可能的实现方式，在第一方面的第十种可能的实现方式中，对所述第一运营商进行寻呼消息的流控，包括：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的处理器是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控。

结合第一方面的第七种可能的实现方式，在第一方面的第十一种可能的实现方式中，根据所述资源比例对所接收到的寻呼消息进行流控，包括：

降低所述RAN网元的寻呼消息阈值，将降低后的寻呼消息阈值作为流控阈值；

根据所述流控阈值和所述资源比例，对所接收到的寻呼消息进行流控。

第二方面，本发明实施例提供一种寻呼消息的流控装置，应用于运营商核心网络(MOCN)系统中，该MOCN系统包括无线接入网(RAN)网元和多个运营商的核心网(CN)网元，该多个运营商的CN网元共享所述RAN网元，该装置位于所述RAN网元，且该装置包括：

存储单元，用于存储多个运营商之间共享无线接入网RAN网元的资源比例；

接收单元，用于接收所述多个运营商的CN网元发送的寻呼消息；

流控单元，用于当所述RAN网元过载时，根据所述资源比例对所接收到的寻呼消息进行流控。

结合第二方面，在第二方面的第一种可能的实现方式中，所述资源比例表明各运营商占用RAN网元的资源的比例，或者各运营商寻呼的终端的比例。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，当所述接收单元接收到的寻呼消息超过所述RAN网元的寻呼消息阈值时，所述RAN网元过载包括寻呼消息过载；所述寻呼消息阈值小于或等于所述RAN网元在预定周期内能够处理的最大寻呼消息的数量。

结合第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，还包括：

确定单元，用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，其还用于确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

所述流控单元，用于以所述第一运营商的寻呼消息目标值为目标，对所述第一运营商进行寻呼消息的流控。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，所述流控单元用于：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的寻呼消息是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控；或者，

将所述第一运营商的寻呼消息中超过所述第一运营商的寻呼消息目标值的寻呼消息丢弃。

结合第二方面的第二种可能的实现方式，在第二方面的第五种可能的实现方式中，还包括：

确定单元，用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，确定寻呼消息的数量超过对应的寻呼消息目标值的第一运营商和寻呼消息的数量不超过对应的寻呼消息目标值的第二运营商，以及还用于确定所述RAN网元的寻呼消息阈值与第二运营商的寻呼消息的差值；

所述流控单元，用于以所述差值为流控阈值，对第一运营商进行寻呼消息的流控。

结合第二方面的第五种可能的实现方式，在第二方面的第六种可能的实现方式中，所述流控单元用于：

当所述第一运营商为一个时，丢弃所述第一运营商的多于所述流控阈值的寻呼消息；或者，

当所述第一运营商为多个时，根据所述流控阈值和所述资源比例，确定各第一运营商流控目标值，且将各第一运营商多于其流控目标值的寻呼消息丢弃。

结合第二方面、第二方面的第一种可能的实现方式，在第二方面的第七种可能的实现方式中，所述RAN网元过载包括处理器过载。

结合第二方面的第七种可能的实现方式，在第二方面的第八种可能的实现方式中，还包括：

确定单元，用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，还用于确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

所述流控单元，用于对所述第一运营商进行寻呼消息的流控。

结合第二方面的第八种可能的实现方式，在第二方面的第九种可能的实现方式中，还包括：

过载确定单元，用于确定所述RAN网元的寻呼消息是否过载；

所述流控单元，用于在所述过载确定单元确定出所述寻呼消息不过载且处理器过载时，根据所述资源比例对所接收到的寻呼消息进行流控。

结合第二方面的第八种或第二方面的第九种可能的实现方式，在第二方面的第十种可能的实现方式中，所述流控单元用于：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的处理器是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控。

结合第二方面的第七种可能的实现方式，在第二方面的第十一种可能的实现方式中，所述流控单元用于：

降低所述RAN网元的寻呼消息阈值，将降低后的寻呼消息阈值作为流控阈值；

根据所述流控阈值和所述资源比例，对所接收到的寻呼消息进行流控。

第三方面，本发明实施例提供一种寻呼消息的流控系统，包括：无线接入网RAN网元和多个运营商的核心网CN网元，该多个运营商的CN网元共享所述RAN网元，所述RAN网元包括如第二方面、第二方面的第一种至第二方面的第十一种任一种可能的寻呼消息的流控装置。

本发明实施例提供的寻呼消息的流控方法、装置和系统，通过在RAN网元处设定共享该RAN网元的运营商之间的资源比例，根据该资源比例对各运营商的寻呼消息分别进行流控，使得寻呼消息的流控符合运营商之间的资源比例，从而提高业务的公平性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种MOCN系统的架构示意图；

图2为本发明寻呼消息的流控方法实施例一的流程示意图；

图3为本发明寻呼消息的流控方法实施例二的流程示意图；

图4为本发明寻呼消息的流控方法实施例三的流程示意图；

图5为本发明寻呼消息的流控方法实施例四的流程示意图；

图6为本发明寻呼消息的流控方法实施例五的流程示意图；

图7为本发明提供的寻呼消息的流控装置实施例一的结构示意图；

图8为本发明提供的寻呼消息的流控装置实施例二的结构示意图；

图9为本发明提供的寻呼消息的流控装置实施例三的结构示意图；

图10为本发明提供的寻呼消息的流控装置实施例四的结构示意图；

图11为本发明实施例提供的一种RAN网元的结构示意图。

具体实施方式

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

MOCN组网是一种多运营商CN共享RAN的机制，即一个RAN可以连接到多个运营商的CN网元，例如，可以由多个运营商合作共建RAN，也可以是其中一个运营商单独建设RAN，而其他运营商租用该运营商的RAN。

请参考图1，其为本发明实施例提供的一种MOCN系统的架构示意图。如图1所示，该MOCN系统中包括至少两个运营商的CN网元12，它们共享RAN网元11。在此，为了说明简便，以两个运营商A和B为例，更多运营商的场景与之类似。

如背景技术中提及的，在MOCN组网下，如果出现系统信令面过载的现象，多个运营商共享的RAN网元会统一的对所有运营商进行寻呼消息的流控，以控制系统负载。但是，多个运营商之间可能会出现业务的不对称性，如果采用统一的流控机制，可能会损害某个或某些运营商的利益，无法保证MOCN组网下业务的公平性。举例来说，图1所示的运营商A和运营商B的CN共享RAN的资源，在实际应用中，A和B运营商的寻呼消息数量往往不同，如果寻呼消息过载现象全部或者绝大部分由A贡献，RAN网元11统一对运营商A和运营商B进行寻呼消息丢弃性惩罚，必然损害了运营商B的利益，无法保证业务的公平性。

本申请充分考虑到以上问题，在RAN网元处设定共享该RAN网元的运营商之间的资源比例，根据该资源比例对各运营商的寻呼消息分别进行流控，使得寻呼消息的流控符合运营商之间的资源比例，从而提高业务的公平性。

以上资源比例是各运营商约定好的资源比例，其表明各运营商可以占用RAN网元的资源的比例，或者表明各运营商可以寻呼的终端的比例。且以上流控方法在RAN网元发生过载时进行，这里的过载可以包括RAN网元的处理器过载，还可以包括寻呼消息过载。

以下结合几个实施例对以上过载情形下的流控过程进行详细描述：

图2为本发明寻呼消息的流控方法实施例一的流程示意图。该方法应用于MOCN系统中，该MOCN系统包括RAN网元和多个运营商的CN网元，该多个运营商的CN网元共享所述RAN网元，该方法由RAN网元执行，且该RAN网元存储有多个运营商之间共享该RAN网元的资源比例。

在上述图1所示系统架构的基础上，如图2所示，本实施例的方法可以包括：

步骤201、RAN网元接收多个运营商的CN网元发送的寻呼消息。

步骤202、RAN网元统计接收到的寻呼消息的数量，该寻呼消息的数量为各运营商的寻呼消息的数量的总和。

在本实施例中，各运营商的CN网元向RAN网元发送寻呼消息后，RAN网元将统计所有接收到的寻呼消息的个数，在具体的实现过程中，RAN网元可以直接统计所有运营商的CN网元发送的寻呼消息的总和，也可以先统计各个运营商的CN网元分别发送的寻呼消息，再根据各运营商的寻呼消息，计算出所有接收到的寻呼消息的总和，对于具体的统计方式，本发明对此不作限制。

此外，针对寻呼消息的流控，可以设置一个周期，该寻呼消息的统计即在该预定周期内进行。

步骤203、当接收到的寻呼消息超过RAN网元的寻呼消息阈值时，RAN网元确定寻呼消息过载，则启动对寻呼消息的流控。

该寻呼消息阈值是根据RAN网元对寻呼消息的处理能力确定的。例如，该寻呼消息阈值可以等于RAN网元在预定周期内能处理的最大寻呼消息的数量，也可以小于RAN网元在预定周期内能处理的最大寻呼消息的数量。另外，RAN网元在预定周期内能够处理的最大寻呼消息的数量与RAN网元的型号或者相关参数有关，其中，预定周期可以根据实际情况或者经验进行设置，例如可以为1s等，对于预定周期的具体取值，本发明实施例对此不作限制。

步骤204、RAN网元根据以上资源比例，对接收到的寻呼消息进行流控。

在本实施例中，当RAN网元判断出接收到的寻呼消息的数量不超过寻呼消息阈值时，运营商可以共享RAN网元的寻呼能力，因此RAN网元可以直接根据各运营商的寻呼消息对终端进行寻呼，而不会对寻呼消息做流控处理。

当RAN网元判断出接收到的寻呼消息的数量超过寻呼消息阈值时，说明已发生寻呼消息过载现象。此时，RAN网元根据预设的各运营商共享RAN网元的资源比例以及接收到的各运营商的CN网元发送的寻呼消息的数量，确定需要丢弃的寻呼消息，以达到流控的目的。其中，以上资源比例为各个运营商约定的资源比例，其表明各运营商占用RAN网元的资源的比例，或者各运营商寻呼的终端的比例，将该资源比例存储于RAN网元，以在RAN网元发生寻呼消息过载时，依据该资源比例进行过载流控，以保证业务的公平性。

图3为本发明寻呼消息的流控方法实施例二的流程示意图，请参考图3，以上步骤204、即RAN网元根据以上资源比例对接收到的寻呼消息进行流控，可以包括如下步骤：

步骤2041、根据RAN网元的寻呼消息阈值和以上资源比例，确定各运营商的寻呼消息目标值。

在本实施例中，RAN网元可以根据设定的各运营商共享RAN网元的资源比例以及RAN网元的寻呼消息阈值，确定出每个运营商的寻呼消息目标值。举例来说，假设在MOCN组网中，有两个运营商A和B，其中，运营商A和运营商B共享RAN网元的资源比例为x％：(1-x％)，RAN网元在预定周期内能够处理寻呼消息的个数为P，为了便于说明，本发明中均以P作为RAN网元的寻呼消息阈值，则对于运营商A，其寻呼消息目标值为P*x％，对于运营商B，其寻呼消息的目标值则为P*(1-x％)。对于MOCN组网中包含两个以上的运营商时，确定每个运营商寻呼消息目标值的方式，与包含两个运营商时的方式类似，此处不再赘述。

步骤2042、确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商，其中，该第一运营商可以为一个也可以为多个。

步骤2043、以第一运营商的寻呼消息目标值为目标，对第一运营商进行寻呼消息的流控。

以上步骤2043的流控可以通过多种方式实现：

第一、步进式：即，以步进的方式丢弃第一运营商的寻呼消息，且每次丢弃之后，判断RAN网元的寻呼消息是否过载，如果过载，继续以步进的方式丢弃第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控；需要说明的是，每次丢弃的寻呼消息的数量可以是一个设定值，且保持不变；也可以在每次丢弃之后，重新调整丢弃值，例如第一次丢弃的寻呼消息的数量比较大，而后根据寻呼消息过载的情况，调整丢弃的寻呼消息的数量，比如，在第一次丢弃之后，RAN网元的寻呼消息过载得以减轻，且与寻呼消息阈值的差距缩小，此时，可以减少下次流控中丢弃的寻呼消息的数量，继续进行寻呼消息的流控。因此，每次丢弃的寻呼消息的数量相同或依次变化。

这种步进式的寻呼消息流控方式，可以最大化的利用RAN网元的资源。例如，当存在多个第一运营商的寻呼消息超过其寻呼消息目标值时，且它们超过目标值的寻呼消息的总和可能大于RAN网元的过载的寻呼消息数量，此时，如果直接将每个第一运营商的超过寻呼消息目标值的寻呼消息都删除，将不能最大化利用RAN网元的资源，使得某些可以被处理的寻呼消息被删除。

第二、直接将第一运营商的寻呼消息中超过第一运营商的寻呼消息目标值的寻呼消息丢弃。

例如，当RAN网元判断出其接收到的寻呼消息的数量大于寻呼消息阈值时，RAN网元判断每个运营商的寻呼消息的数量是否都超过了各自对应的寻呼消息目标值，若所有运营商的寻呼消息的数量都超过了各运营商对应的寻呼消息目标值，则RAN网元对每个运营商的寻呼消息分别进行处理，将各运营商的寻呼消息中超过各自对应的寻呼消息目标值数量的寻呼消息丢弃，由此保证了MOCN组网中，业务的公平性。举例来说，若确定出运营商A的寻呼消息目标值为P*x％，运营商B的寻呼消息目标值为P*(1-x％)，假设RAN网元实际接收到运营商A的寻呼消息为PA个，运营商B的寻呼消息为PB个，若RAN网元判断出PA＞P*x％，且PB＞P*(1-x％)，此时，RAN网元将运营商A的超过P*x％数量的寻呼消息丢弃，将运营商B的超过P*(1-x％)的寻呼消息丢弃。当有两个以上的运营商时，确定需要丢弃的各运营商的寻呼消息的方式，与只有两个运营商时的确定方式类似，此处不再赘述。

以上对各运营商寻呼消息的识别可以通过传播途径进行识别，也可以通过标识信息进行识别，本发明实施例不做任何限制。例如，由于不同的运营商通过不同的CN，例如，长期演进(Long Term Evolution；简称：LTE)网络中的移动性管理实体(Mobility Management Entity；简称：MME)，传输通道向RAN网元发送寻呼消息，因此，RAN网元可以根据CN传输通道识别寻呼消息所对应的运营商；另外，RAN网元也可以根据寻呼消息中携带的公共陆地移动网络(public land mobile network；简称：PLMN)识别寻呼消息所对应的运营商，当然，RAN网元也可以根据其他方式识别寻呼消息对应的运营商，对于RAN网元识别寻呼消息对应运营商的具体方式，本实施例在此不作限制。

本发明实施例提供的寻呼消息的流控方法，通过统计接收到的寻呼消息的数量，当寻呼消息的数量大于寻呼消息阈值时，RAN网元根据预设的各运营商共享RAN网元的资源比例进行寻呼消息的流控，解决了统一的对各运营商的寻呼消息进行流控时，会损害某些运营商共享利益的问题，从而保证了MOCN组网下业务的公平性。

图4为本发明寻呼消息的流控方法实施例三的流程示意图，该方法应用于MOCN系统中，该MOCN系统包括RAN网元和多个运营商的CN网元，该多个运营商的CN网元共享所述RAN网元，该方法由RAN网元执行，且该RAN网元存储有多个运营商之间共享该RAN网元的资源比例。

在上述图1所示系统架构的基础上，如图4所示，本实施例的方法可以包括：

步骤401、RAN网元接收多个运营商的CN网元发送的寻呼消息。

步骤402、RAN网元统计接收到的寻呼消息的数量，该寻呼消息的数量为各运营商的寻呼消息的数量的总和。

步骤403、当接收到的寻呼消息超过RAN网元的寻呼消息阈值时，RAN网元确定寻呼消息过载，则启动对寻呼消息的流控。

步骤401-步骤403与步骤201-步骤203类似，此处不再赘述。

步骤404、RAN网元根据以上资源比例，对接收到的寻呼消息进行流控。

图5为本发明寻呼消息的流控方法实施例四的流程示意图，请参考图5，以上步骤404、即RAN网元根据以上资源比例对接收到的寻呼消息进行流控，可以包括如下步骤：

步骤4041、根据RAN网元的寻呼消息阈值和资源比例，RAN网元确定各运营商的寻呼消息目标值。

步骤4041与步骤2041类似，此处不再赘述。

步骤4042、确定寻呼消息的数量超过对应的寻呼消息目标值的第一运营商，和寻呼消息的数量不超过对应的寻呼消息目标值的第二运营商。

RAN网元在接收到每个寻呼消息时可以识别接收到的寻呼消息所对应的运营商；也可以在预定时间到达后统一识别接收到的寻呼消息所对应的运营商，从而统计各个运营商的寻呼消息的数量，以确定第一运营商和第二运营商。其中，第一运营商的数量可以是一个也可以是多个；第二运营商的数量可以是一个也可以是多个。由于不同的运营商通过不同的CN传输通道向RAN网元发送寻呼消息，因此，RAN网元可以根据CN传输通道识别寻呼消息所对应的运营商；另外，RAN网元也可以根据寻呼消息中携带的PLMN识别寻呼消息所对应的运营商，当然，RAN网元也可以根据其他方式识别寻呼消息对应的运营商，对于RAN网元识别寻呼消息对应运营商的具体方式，本实施例在此不作限制。

RAN网元识别出每个寻呼消息所对应的运营商之后，即可确定出各个运营商发送的寻呼消息的数量。其中，RAN网元可以在统计出所有寻呼消息的数量，并在判断出接收到的寻呼消息大于寻呼消息阈值时，通过上述方式确定各个寻呼消息对应的运营商，从而确定各运营商的寻呼消息的数量。

值得说明的是，RAN网元可以在接收到每个寻呼消息时，直接识别寻呼消息对应的运营商，从而确定出各个运营商的寻呼消息的数量，继而根据各运营商的寻呼消息的数量，统计接收到的所有的寻呼消息的个数。

步骤4043、确定RAN网元的寻呼消息阈值与第二运营商的寻呼消息的差值。

当第二运营商为多个时，这里面第二运营商的寻呼消息就是所有第二运营商的寻呼消息的总和。以两个第二运营商B1和B2为例，RAN网元接收到的它们的寻呼消息的数量分别为PB1和PB2，则RAN网元的寻呼消息阈值P与第二运营商的寻呼消息的差值为：P-(PB1+PB2)。

步骤4044、以该差值为流控阈值，对第一运营商进行寻呼消息的流控。

具体地，当预定周期到达时，RAN网元判断出其接收到的寻呼消息的数量大于寻呼消息阈值，且判断出至少有一个运营商的寻呼消息的数量不大于该运营商对应的寻呼消息目标值时，RAN网元首先确定出寻呼消息不大于寻呼消息目标值的第二运营商，计算出RAN网元寻呼消息阈值与第二运营商的寻呼消息的数量的差值。RAN网元根据计算得到的差值进行寻呼消息流控。

若只有一个第一运营商，则直接以以上差值作为第一运营商流控的目标值，丢弃第一运营商中超过以上差值的寻呼消息。举例来说，运营商A和B共享RAN网元的资源，且它们之间的资源比例x％：(1-x％)。则运营商A的寻呼消息目标值为P*x％，运营商B的寻呼消息目标值为P*(1-x％)，其中，P为RAN网元的寻呼消息阈值，即在预定周期内能够处理的寻呼消息的数量。假设RAN网元实际接收到运营商A的寻呼消息为PA个，运营商B的寻呼消息为PB个，且PA＜P*x％，PB＞P*(1-x％)。RAN网元确定出运营商A的寻呼消息的数量不大于运营商A的寻呼消息目标值，也即判断出PA＜P*x％，则RAN网元计算出RAN网元的寻呼阈值与运营商A的寻呼消息的数量之间的差值P-PA。由于此时寻呼消息过载，则运营商B的寻呼消息的数量PB大于P-PA，则以P-PA作为新的流控阈值，将运营商B的超过P-PA数量的寻呼消息丢弃。若运营商B的寻呼消息的数量不大于运营商B的寻呼消息目标值，而运营商A的寻呼消息的数量大于运营商A的寻呼消息目标值时，RAN网元确定丢弃的运营商A的寻呼消息的方式，与上述方式类似。

若有多个第一运营商，则以以上差值作为第一运营商流控的目标值，丢弃第一运营商中超过以上差值的寻呼消息。举例来说，运营商A、B1和B2共享RAN网元的资源，且它们之间的资源比例x1％：x2％：(1-x1％-x2％)。则运营商A的寻呼消息目标值为P*x1％，运营商B1的寻呼消息目标值为P*x2％，运营商B2的寻呼消息目标值为P*(1-x1％-x2％)，其中，P为RAN网元的寻呼消息阈值，即在预定周期内能够处理的寻呼消息的数量。假设RAN网元实际接收到运营商A的寻呼消息为PA个，运营商B1的寻呼消息为PB1个，运营商B2的寻呼消息为PB2个；且PA＜P*x1％，PB1＞P*x2％，PB2＞P*(1-x1％-x2％)。RAN网元确定出运营商A的寻呼消息的数量不大于运营商A的寻呼消息目标值，也即判断出PA＜P*x％，则RAN网元计算出RAN网元的寻呼消息阈值与运营商A的寻呼消息的数量之间的差值P-PA。由于此时寻呼消息过载，则运营商B1和B2的寻呼消息的数量之和必然大于P-PA，需要对其进行流控，则以P-PA作为新的流控阈值，将运营商B1和B2超过P-PA数量的寻呼消息丢弃。此时，对运营商B1和B2的流控方式同以上实施例一，区别在于流控阈值不再是P，而是P-PA。

需要进行说明的是，通过以上方法确定需要丢弃的寻呼消息的过程中，可以始终保持RAN网元在实际处理所有的运营商的寻呼消息的数量与RAN网元在预定周期内能够处理寻呼消息的个数相等，以避免资源的浪费，提高资源利用率。

本发明实施例提供的寻呼消息的流控方法，通过统计接收到的寻呼消息的数量，当寻呼消息的数量大于RAN网元的寻呼消息阈值时，RAN网元根据预设的各运营商共享RAN网元的资源比例和各运营商的寻呼消息的数量，确定需要丢弃的寻呼消息。由于RAN网元根据预先设定的资源各运营商共享RAN网元的资源比例对各运营商的寻呼消息进行流控，解决了统一的对各运营商的寻呼消息进行流控时，会损害某些运营商共享利益的问题，从而保证了MOCN组网下业务的公平性。另外，RAN网元通过比较各运营商的寻呼消息目标值和各运营商的寻呼消息的数量，确定出每个运营商需要丢弃的寻呼消息的数量，保证了在多个运营商业务不对称或者当多个运营商共享资源存在比例要求等场景下，寻呼流控对业务的公平性。

图6为本发明寻呼消息的流控方法实施例五的流程示意图。本实施例与以上实施例的区别在于，将寻呼消息的流控用于控制RAN网元的处理器过载。

在上述图1所示系统架构的基础上，如图6所示，本实施例的方法可以包括：

步骤601、RAN网元确定处理器是否过载。

在本实施例中，引起处理器过载的原因有很多种，例如：终端的切换、接入等过程中的信令和寻呼消息共同引起的过载。该处理器是对该RAN网元起总的控制作用的处理器。通常RAN网元可以包括多个处理部件，这些部件的协作可以通过该起总的控制作用的处理器来实现，例如，可以是RAN网元的中央处理单元(Central Processing Unit，简称CPU)。对该处理器的过载的监控可以通过处理器的利用率的监控来实现，例如当CPU占用率超过80％时，可以认为该CPU过载。该CPU占用率的阈值比例仅为举例，具体可以根据实际需要进行设置，本发明实施例不做限制。若处理器过载，RAN网元可以优先对寻呼消息处理能力比例高于其约定的资源比例的运营商进行步进下调。拥塞恢复后，寻呼消息处理能力放开到寻呼消息处理规格。也可以整体降低RAN网元的流控阈值，即对RAN网元的寻呼消息阈值进行调整，以降低该阈值，得到信道流控阈值，以该新的流控阈值，并依据以上实施例提供的流控方法，对寻呼消息进行流控。

第一种方式，如图6所示，包括如下步骤：

步骤602、根据RAN网元的寻呼消息阈值和以上资源比例，确定各运营商的寻呼消息目标值。

步骤603、确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商。

步骤604、对第一运营商进行寻呼消息的流控。

该流控过程较佳的采用步进式流控，同以上实施例步进式流控的描述，区别在于，每次步进流控丢弃寻呼消息之后，判断处理器是否还过载，且如果处理器不过载，停止流控；如果处理器还过载，则继续进行流控，直到第一运营商的寻呼消息少于或等于其寻呼消息目标值。当然，如果此时处理器还过载，也可以继续进行寻呼消息流控，可以以最接近其寻呼消息目标值的运营商开始流控，或者，对其它信令或消息进行流控，本发明对此不做约束。

第二种方式，如图6所示，包括如下步骤：

步骤605、RAN网元将寻呼消息阈值进行调整，且该调整为降低该寻呼消息阈值，即降低处理器对寻呼消息的处理能力，并将降低后的寻呼消息阈值作为流控阈值。

在本实施例中，若RAN网元判断出处理器处于过载状态，则RAN网元将寻呼消息阈值进行调整，以解决处理器过载的现象。当处理器过载现象消除之后，RAN网元可以将寻呼消息阈值调整为原来的值。另外，RAN网元在对寻呼消息阈值进行调整的时候，如果调整太快，会影响系统的最大容量，而如果调整太慢，则可能无法及时减轻系统压力，因此，本实施例中可以通过步进式调整的方式进行调节，例如：假设寻呼消息阈值为在预定周期内能够处理寻呼消息的数量，若将向下调整的步长设置为每秒处理400次寻呼消息，向上调整的步长设置为每秒75次，若RAN网元在预定周期内能够处理寻呼消息的能力为每秒处理1000次，则下调400次后，RAN网元每秒可以处理600次寻呼消息。

下面将举例说明在处理器过载时，RAN网元将如何调整寻呼消息阈值。在MOCN组网中，假设RAN网元在预定周期内能够处理寻呼消息的个数为P，设定步进式调整的步长为P1，当RAN网元确定出实际接收到的寻呼消息的个数不大于P，且处理器处于过载状态时，RAN网元将寻呼消息阈值可以调整为P-P1，即RAN网元在预定周期内能够处理寻呼消息的个数为P-P1，以缓解处理器的过载现象。此时，RAN网元将继续判断接收到的寻呼消息的个数是否大于调整之后的预设数量P-P1，如果大于，则RAN网元根据约定的资源比例和各运营商的寻呼消息的数量，确定出需要丢弃的寻呼消息。当RAN网元发现过载现象消除后，则可以将寻呼消息阈值重新调整为P。

步骤606、根据流控阈值和资源比例，对所接收到的寻呼消息进行流控。

在本实施例中，将寻呼消息阈值进行调整，并将调整后的寻呼消息阈值作为新的流控阈值，则将依据以上实施例提供的流控方法，根据新的流控阈值和约定的资源比例对接收到的寻呼消息进行流控。

本发明实施例提供的寻呼消息的流控方法，在处理器过载时，RAN网元根据各运营商共享RAN网元的资源比例对寻呼消息进行流控，从而避免网络拥塞的现象，提高了系统的可靠性。

图7为本发明提供的寻呼消息的流控装置实施例一的结构示意图，所述寻呼消息的流控装置10应用于MOCN系统中，该MOCN系统包括RAN网元和多个运营商的CN网元，该多个运营商的CN网元共享所述RAN网元，该装置10位于RAN网元侧，可以设置于RAN网元中，也可以独立于RAN网元单独设置，如图7所示，所述装置10可以包括：存储单元11、接收单元12和流控单元13。

其中，存储单元11用于存储多个运营商之间共享所述RAN网元的资源比例；

接收单元12用于接收所述多个运营商的CN网元发送的寻呼消息；

流控单元13用于当所述RAN网元过载时，根据所述资源比例对所接收到的寻呼消息进行流控。

本实施例的装置，可以用于执行图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

其中，以上资源比例是各运营商约定好的资源比例，其表明各运营商可以占用RAN网元的资源的比例，或者表明各运营商可以寻呼的终端的比例。

进一步地，当所述接收单元12接收到的寻呼消息超过所述RAN网元的寻呼消息阈值时，所述RAN网元过载包括寻呼消息过载；所述寻呼消息阈值小于或等于所述RAN网元在预定周期内能够处理的最大寻呼消息的数量。

图8为本发明提供的寻呼消息的流控装置实施例二的结构示意图，在图7所示装置的基础上，如图8所示，本发明实施例的装置10还包括：

确定单元14用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，且还用于确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

所述流控单元13用于以所述第一运营商的寻呼消息目标值为目标，对所述第一运营商进行寻呼消息的流控。

其中，该第一运营商可以为一个也可以为多个。

可选地，所述流控单元13用于：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的寻呼消息是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控；或者，

将所述第一运营商的寻呼消息中超过所述第一运营商的寻呼消息目标值的寻呼消息丢弃。

对寻呼消息进行流控时，可以采用多种方式实现，第一、步进式：即，以步进的方式丢弃第一运营商的寻呼消息，且每次丢弃之后，判断RAN网元的寻呼消息是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控；需要说明的是，每次丢弃的寻呼消息的数量可以是一个设定值，且保持不变；也可以在每次丢弃之后，重新调整丢弃值，例如第一次丢弃的寻呼消息的数量比较大，而后根据寻呼消息过载的情况，调整丢弃的寻呼消息的数量，比如，在第一次丢弃之后，RAN网元的寻呼消息过载得以减轻，且与寻呼消息阈值的差距缩小，此时，可以减少下次流控中丢弃的寻呼消息的数量，继续进行寻呼消息的流控。

第二、直接将第一运营商的寻呼消息中超过第一运营商的寻呼消息目标值的寻呼消息丢弃。例如，当RAN网元判断出其接收到的寻呼消息的数量大于寻呼消息阈值时，RAN网元判断每个运营商的寻呼消息的数量是否都超过了各自对应的寻呼消息目标值，若所有运营商的寻呼消息的数量都超过了各运营商对应的寻呼消息目标值，则RAN网元对每个运营商的寻呼消息分别进行处理，将各运营商的寻呼消息中超过各自对应的寻呼消息目标值数量的寻呼消息丢弃，由此保证了MOCN组网中，业务的公平性。

本实施例的寻呼消息的流控装置，可以用于执行图1-图3所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图9为本发明提供的寻呼消息的流控装置实施例三的结构示意图，在图7所示装置的基础上，如图9所示，本发明实施例的装置10还包括：

确定单元15用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，确定寻呼消息的数量超过对应的寻呼消息目标值的第一运营商和寻呼消息的数量不超过对应的寻呼消息目标值的第二运营商，以及还用于确定所述RAN网元的寻呼消息阈值与第二运营商的寻呼消息的差值；

所述流控单元13用于以所述差值为流控阈值，对第一运营商进行寻呼消息的流控。

可选地，所述流控单元13用于：

当所述第一运营商为一个时，丢弃所述第一运营商的多于所述流控阈值的寻呼消息；或者，

当所述第一运营商为多个时，根据所述流控阈值和所述资源比例，确定各第一运营商流控目标值，且将各第一运营商多于其流控目标值的寻呼消息丢弃。

本实施例的寻呼消息的流控装置，可以用于执行图1-图5所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图10为本发明提供的寻呼消息的流控装置实施例四的结构示意图，在图7所示装置的基础上，若所述RAN网元过载包括处理器过载时，如图10所示，本发明实施例的装置10包括：

确定单元21用于根据所述RAN网元的寻呼消息阈值和所述资源比例，确定各运营商的寻呼消息目标值，还用于确定接收到的寻呼消息的数量超过寻呼消息目标值的第一运营商；

所述流控单元13用于对所述第一运营商进行寻呼消息的流控。

若处理器过载，RAN网元可以优先对寻呼消息处理能力比例高于其约定的资源比例的运营商进行步进下调。拥塞恢复后，寻呼消息处理能力放开到寻呼消息处理规格。

可选地，所述装置10还包括：

过载确定单元22，用于确定所述RAN网元的寻呼消息是否过载；

所述流控单元13，用于在所述过载确定单元22确定出所述寻呼消息不过载且处理器过载时，根据所述资源比例对所接收到的寻呼消息进行流控。

本实施例的寻呼消息的流控装置，可以用于执行图1-图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选地，所述流控单元13用于：

以步进的方式丢弃所述第一运营商的寻呼消息，且每次丢弃的寻呼消息的数量相同或依次变化，且每次丢弃之后，判断所述RAN网元的处理器是否过载，如果过载，继续以步进的方式丢弃所述第一运营商的寻呼消息，如果不过载，停止寻呼消息的流控。

本实施例的寻呼消息的流控装置，可以用于执行图1-图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

可选地，所述流控单元13用于：

降低所述RAN网元的寻呼消息阈值，将降低后的寻呼消息阈值作为流控阈值；

根据所述流控阈值和所述资源比例，对所接收到的寻呼消息进行流控。

若处理器过载，可以整体降低RAN网元的流控阈值，即对RAN网元的寻呼消息阈值进行调整，以降低该阈值，得到信道流控阈值，以该新的流控阈值，并依据以上实施例提供的流控方法，对寻呼消息进行流控。

本实施例的寻呼消息的流控装置，可以用于执行图1-图6所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

本发明还提供一种寻呼消息的流控系统，包括RAN网元和多个运营商的CN网元，该多个运营商的CN网元共享所述RAN网元，其中，所述RAN网元包括上述任一实施例所述的寻呼消息的流控装置。

本发明实施例还提供一种可选的实施方式，即一种RAN网元，包括上述图7-图10所示的寻呼消息的流控装置，所述RAN网元的结构和技术效果同前，此处不再赘述。

需要说明的是，上述实施例中，接收单元12可以为RAN网元的接口电路，用于实现与CN网元之间连接，以接收CN网元发送的数据。流控单元13可以为单独设立的处理器，也可以集成在RAN网元的某一个处理器中实现，此外也可以以程序代码的形式存储于RAN网元的存储器中，由RAN网元的某一个处理器调用并执行以上流控单元13的功能，这里所述的处理器可以是一个CPU或者是特定集成电路(Application Specific Intergrated Circuit，简称：ASIC)或者是被配置成实施本发明实施例的一个或多个集成电路。以上确定单元14的实现与流控单元13类似，且可以与流控单元13集成在一起，也可以单独实现。确定单元21的实现与流控单元13类似，且可以与流控单元13集成在一起，也可以单独实现。确定单元21和过载确定单元22的实现与流控单元13类似，且可以与流控单元13集成在一起，也可以单独实现，且确定单元21和过载确定单元22可以独立实现，也可以集成在一起。

请参考图11，其为本发明实施例提供的一种RAN网元的结构示意图。如图11所示，该RAN网元包括处理器1101和接口电路1102，图中还示出了存储器1103和总线1104，该处理器1101、接口电路1102和存储器1103通过总线1104连接并完成相互间的通信。

其中，存储器1103用于存储多个运营商之间共享所述RAN网元的资源比例；通过接口电路1102接收所述多个运营商的核心网CN网元发送的寻呼消息，当所述RAN网元过载时，处理器1101根据存储器1103中存储的资源比例和通过接口电路1102接收到的寻呼消息进行流控。

需要说明的是，这里的处理器1101可以是一个处理器，也可以是多个处理元件的统称。例如，该处理器可以是CPU，也可以是ASIC，或者是被配置成实施本发明实施例的一个或多个集成电路，例如：一个或多个微处理器(digital singnal processor，简称：DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称：FPGA)。

存储器1103可以是一个存储装置，也可以是多个存储元件的统称，且用于存储可执行程序代码或RAN网元运行所需要参数、数据等。且存储器1103可以包括随机存储器(RAM)，也可以包括非易失性存储器(non-volatile memory)，例如磁盘存储器，闪存(Flash)等。

总线1104可以是工业标准体系结构(Industry Standard Architecture，简称：ISA)总线、外部设备互连(Peripheral Component，简称：PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称：EISA)总线等。该总线1104可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。