一种消除寻呼子信道拥塞的方法及无线网络控制设备与流程

本发明涉及移动通信技术领域，尤其涉及一种消除寻呼子信道拥塞的方法及无线网络控制设备。

背景技术：

在TD-SCDMA(Time Division-Synchronous Code Division Multiple Access，时分同步码分多址，中国提出的第三代移动通信标准)网络中，RNC(Radio Network Controller，无线网络控制器)的IU接口收到来自核心网的寻呼消息，将IU接口收到的寻呼消息转为UU口发送的消息经过ASN编码后在同一LAC(Location Area Code，位置去识别码)/RAC(Routing Area Code，路由去识别码)下的所有小区上发送。出于终端节电目的考虑，3GPP协议规定TD-SCDMA终端对寻呼消息接收采用DRX(Discontinuous Reception，非连续接收方式)接收，即只有在特定时刻终端才会读取PICH(Paging Indicator Channel，寻呼指示信道)是否有属于自己的寻呼消息，如果有属于自己的寻呼消息，则再读取和PICH配对的PCH信道(Paging Channel)的特定寻呼子信道上属于自己的寻呼消息，特定子信道由终端根据IMSI计算得出。其中，终端读取PICH数据的特定时刻称作寻呼发送时刻，是PICH帧的起点，终端根据自身IMSI(International Mobile Subscriber Identification Number，国际移动用户识别码)以及系统广播中的参数计算出要读取PICH信道信息的特定时刻，在时刻到达时读取PICH的消息。终端在PCH的某个寻呼子信道上接收寻呼消息的时刻，称作寻呼消息接收时刻，在此时刻，寻呼消息由UTRAN通过UU口在终端所在的LAC/RAC包含的所有小区发送，由对应终端接收。

TD-SCDMA系统中，按照协议规定通用无线接入网发送寻呼消息和终端收听寻呼消息的时刻是根据IMSI计算得出，而在实际放号过程中，运营商为了便于管理，对于大客户群体可能存在集中区域放号的情况，导致在网络中多次出现某一RNC下突然从某一天开始有大量寻呼拥塞，影响了用户感知并产生用户投诉，而且，寻呼拥塞均集中在某一部分寻呼子信道，由于这些IMSI计算出的寻呼接收时刻集中在某一部分寻呼子信道，寻呼消息的数量超过了寻呼子信道容量，则就会有一部分寻呼消息无法在对应的寻呼消息接收时刻通过UU口发送出去，产生寻呼拥塞，浪费RNC资源，而且，当IU接口寻呼量比较大的时候甚至会影响到RNC设备稳定。

技术实现要素：

本发明提出了一种消除寻呼子信道拥塞的方法及无线网络控制设备，以解决现有技术中由于设备内部寻呼消息量大且集中导致的设备负荷升高、寻呼信道拥塞的问题，有效提高了设备稳定性。

根据本发明的一个方面，提供了一种消除寻呼子信道拥塞的方法，该方法包括：

根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量；

获取所述寻呼子信道的寻呼容量；

当在所述寻呼子信道上需要调度发送的寻呼消息数量大于或等于该寻呼子信道的寻呼容量阈值时，查看该寻呼子信道上需要调度发送的寻呼消息的寻呼原因；其中，所述寻呼容量阈值小于所述寻呼容量；

根据每一寻呼消息的寻呼原因，按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息。

其中，所述方法还包括：

当在所述寻呼子信道上需要调度发送的寻呼消息数量大于该寻 呼子信道的寻呼容量时，统计寻呼消息中携带的国际移动用户识别码IMSI，得到统计报表；

将所述统计报表上报给核心网设备，以使核心网设备根据所述统计报表调整统计报表中IMSI对应的寻呼消息的寻呼间隔。

其中，所述根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量，包括：

当接收到核心网设备发送的寻呼消息时，根据该寻呼消息中携带的IMSI计算该寻呼消息的寻呼接收时刻以及对应的寻呼子信道；

统计所述寻呼接收时刻所述寻呼子信道收到的寻呼消息数量。

其中，在按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息之前，所述方法还包括：

根据每一寻呼消息对应的业务类型的实时性要求，对寻呼消息进行寻呼优先级排序，以确定所述需要调度发送的寻呼消息中每一寻呼消息的寻呼优先级顺序；

其中，所述寻呼优先级的优先顺序依次为：

语音寻呼>除语音业务以外的业务的首次寻呼>除语音业务以外的业务的重复寻呼。

其中，所述方法还包括：

丢弃超过当前寻呼子信道的寻呼容量的寻呼消息，记录被丢弃的寻呼消息对应的IMSI信息。

其中，所述方法还包括:

当接收到核心网设备发送的寻呼消息时，判断当前寻呼消息是否属于首次寻呼。

其中，所述判断当前寻呼消息是否属于首次寻呼，具体包括：

获取当前寻呼消息中携带的IMSI和寻呼原因；

查找预设的寻呼表中是否记录有当前寻呼消息中携带的IMSI，所述寻呼表中记录有每一用户上一次发送的寻呼消息中携带的IMSI 和寻呼原因；

当所述寻呼表中不存在当前寻呼消息中携带的IMSI时，判定当前寻呼消息属于首次寻呼，并将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中；

当所述寻呼表中记录有当前寻呼消息中携带的IMSI时，判断当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因是否相同；

若相同，则判定当前寻呼消息不属于首次寻呼，丢弃当前寻呼消息；否则，判定当前寻呼消息属于首次寻呼，清除所述寻呼表中记载的寻呼原因，并将当前寻呼消息中携带的寻呼原因添加到所述寻呼表中。

其中，在所述将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中之后，所述方法还包括：

判断在预设寻呼重发定时时间内，是否收到终端发送的寻呼响应消息；

若是，则确定寻呼成功，并清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因；否则，当到达所述预设寻呼重发定时时间时，清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因。

其中，所述寻呼容量阈值的获取方式，包括：

根据设备当前负荷状态，确定容量调整系数；

将所述寻呼子信道的寻呼容量和容量调整系数的乘积作为所述寻呼子信道的寻呼容量阈值。

根据本发明的另一个方面，提供了一种无线网络控制设备，该设备包括：

数量确定模块，用于根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量；

寻呼容量获取模块，用于获取所述寻呼子信道的寻呼容量；

查看模块，用于当在所述寻呼子信道上需要调度发送的寻呼消息数量大于或等于该寻呼子信道的寻呼容量阈值时，查看该寻呼子信道上需要调度发送的寻呼消息的寻呼原因；其中，所述寻呼容量阈值小于所述寻呼容量；

发送模块，用于根据每一寻呼消息的寻呼原因，按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息。

其中，所述无线网络控制设备还包括：

IMSI统计模块，用于当在所述寻呼子信道上需要调度发送的寻呼消息数量大于该寻呼子信道的寻呼容量时，统计寻呼消息中携带的国际移动用户识别码IMSI，得到统计报表；

所述发送模块，还用于将所述统计报表上报给核心网设备，以使核心网设备根据所述统计报表调整统计报表中IMSI对应的寻呼消息的寻呼间隔。

其中，所述数量确定模块，包括：

计算单元，用于当接收到核心网设备发送的寻呼消息时，根据该寻呼消息中携带的IMSI计算该寻呼消息的寻呼接收时刻以及对应的寻呼子信道；

统计单元，用于统计所述寻呼接收时刻所述寻呼子信道收到的寻呼消息数量。

其中，所述无线网络控制设备还包括：

优先级设定模块，用于在按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息之前，根据每一寻呼消息对应的业务类型的实时性要求，对寻呼消息进行寻呼优先级排序，以确定所述需要调度发送的寻呼消息中每一寻呼消息的寻呼优先级顺序；

其中，所述寻呼优先级的优先顺序依次为：

语音寻呼>除语音业务以外的业务的首次寻呼>除语音业务以外 的业务的重复寻呼。

其中，所述无线网络控制设备还包括：

判断模块，用于当接收到核心网设备发送的寻呼消息时，判断当前寻呼消息是否属于首次寻呼。

所述判断模块，具体包括：

获取单元，用于获取当前寻呼消息中携带的IMSI和寻呼原因；

查找单元，用于查找预设的寻呼表中是否记录有当前寻呼消息中携带的IMSI，所述寻呼表中记录有每一用户上一次发送的寻呼消息中携带的IMSI和寻呼原因；

添加单元，用于当所述寻呼表中不存在当前寻呼消息中携带的IMSI时，判定当前寻呼消息属于首次寻呼，并将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中；

第一判断单元，用于当所述寻呼表中记录有当前寻呼消息中携带的IMSI时，判断当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因是否相同；

处理单元，用于当所述第一判断单元的判断结果为当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因相同时，判定当前寻呼消息不属于首次寻呼，丢弃当前寻呼消息；当所述第一判断单元的判断结果为当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因不相同时，判定当前寻呼消息属于首次寻呼，清除所述寻呼表中记载的寻呼原因，并将当前寻呼消息中携带的寻呼原因添加到所述寻呼表中。

本发明的有益效果为：

本发明提供的消除寻呼子信道拥塞的方法及无线网络控制设备，避免由于IMSI分布不合理导致的寻呼子信道拥塞，通过从IU接口收到寻呼消息后即刻进行寻呼子信道容量判决，按照预设的寻呼优先级顺序发送需要调度发送的寻呼消息，优先保证CS业务寻呼 以及其它业务的首次寻呼，丢弃其它业务的重复寻呼，在一定程度上降低了由于设备内部寻呼消息量大导致的RNC设备负荷升高、稳定性降低的概率，有效地降低了设备内部消息数量，提高设备稳定性。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例提出的一种消除寻呼子信道拥塞的方法的流程图；

图2为本发明另一实施例提出的一种消除寻呼子信道拥塞的方法的流程图；

图3为本发明实施例提出的寻呼业务按原因进行优先级排序示意图；

图4为本发明实施例提出首次寻呼的判断步骤的流程示意图；

图5为本发明实施例提出的一种无线网络控制设备的结构框图；

图6为本发明另一实施例提出的一种无线网络控制设备的结构框图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整 数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非被特定定义，否则不会用理想化或过于正式的含义来解释。

图1示出了本发明实施例的一种消除寻呼子信道拥塞的方法的流程图。

参照图1，本发明实施例提出的消除寻呼子信道拥塞的方法，具体包括以下步骤：

S11、根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量；

S12、获取所述寻呼子信道的寻呼容量；

S13、当在所述寻呼子信道上需要调度发送的寻呼消息数量大于或等于该寻呼子信道的寻呼容量阈值时，查看该寻呼子信道上需要调度发送的寻呼消息的寻呼原因；

其中，所述寻呼容量阈值小于所述寻呼容量；

S14、根据每一寻呼消息的寻呼原因，按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息。

其中，寻呼原因可从IU接口的寻呼消息PAGING中获取到，目前核心网发送的寻呼消息中都携带了寻呼原因。

本步骤中，当要发送的寻呼消息数量大于或等于该寻呼子信道的寻呼容量阈值时，通过对寻呼消息数量按照预设的业务类型优先级排序，优先保证CS业务寻呼以及其它PS业务的首次寻呼发送。

本发明实施例，通过对超过寻呼容量的寻呼消息进行分析，优 先保证CS业务寻呼以及其它业务的首次寻呼，丢弃其它业务的重复寻呼，在一定程度上降低了由于设备内部寻呼消息量大导致的RNC设备负荷升高、稳定性降低的概率，有效地降低了设备内部消息数量，提高设备稳定性。

具体的，在本实施例中，所述寻呼容量阈值的获取方式，包括：

根据设备当前负荷状态，确定容量调整系数；

将所述寻呼子信道的寻呼容量和容量调整系数的乘积作为所述寻呼子信道的寻呼容量阈值。

本步骤中，寻呼容量阈值由寻呼子信道的寻呼容量*百分比系数得到，该百分比系数即为容量调整系数，容量调整系数可根据RNC负荷做动态调整。比如落在某条寻呼子信道上的寻呼数量达到该子信道容量寻呼容量的90％时，启动检查寻呼原因按寻呼优先级发送功能，不超过这个时全部发送，其中:

寻呼容量阈值＝寻呼容量x 90％。

可理解的是，寻呼容量的最大值为寻呼子信道的寻呼容量。

在本发明另一实施例中，如图2所示，所述消除寻呼子信道拥塞的方法，还包括以下步骤：

S15、当在所述寻呼子信道上需要调度发送的寻呼消息数量大于该寻呼子信道的寻呼容量时，统计寻呼消息中携带的国际移动用户识别码IMSI，得到统计报表；

S16、将所述统计报表上报给核心网设备，以使核心网设备根据所述统计报表调整统计报表中IMSI对应的寻呼消息的寻呼间隔。

本发明实施例，通过计算单条寻呼子信道的寻呼容量，如果单位时间(一个寻呼周周PBP)内某个寻呼消息接收时刻对应的寻呼子信道上要发送的寻呼消息数量超过寻呼子信道容量时，统计寻呼消息中IMSI值并上报统计报表提交给网络运营商，网络运营商可以据此调整IMSI寻呼间隔。避免了由于IMSI分布不合理导致的寻呼子 信道拥塞，并且是从IU接口收到寻呼消息后即刻进行寻呼子信道容量判决，从而使得网络运营商及时地对IMSI寻呼间隔进行调整，在一定程度上降低由于设备内部寻呼消息量大且集中导致的RNC设备负荷升高、稳定性降低的概率，对于降低寻呼信道拥塞、降低设备负荷、提高设备稳定性的目的具有积极作用。

进一步地，在步骤S14中的按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息之前，所述方法还包括以下步骤：

根据每一寻呼消息对应的业务类型的实时性要求，对寻呼消息进行寻呼优先级排序，以确定所述需要调度发送的寻呼消息中每一寻呼消息的寻呼优先级顺序；

具体的，所述寻呼优先级的优先顺序依次为：

语音寻呼>除语音业务以外的业务的首次寻呼>除语音业务以外的业务的重复寻呼。

需要说明的是，本发明实施例根据不同类型业务对实时性的要求不同，把寻呼按业务按原因进行优先级排序，如图3所示，优先级最高的为重要寻呼，如语音寻呼，优先保证其寻呼调度，其次为除语音业务以外的其他业务的首次寻呼，优先级低的为不重要寻呼，如除语音业务以外的业务的重复寻呼，当判决某个寻呼子信道发生拥塞时优先考虑丢弃优先级较低的寻呼消息。

进一步地，所述方法还包括以下图中未示出的步骤：

丢弃超过当前寻呼子信道的寻呼容量的寻呼消息，记录被丢弃的寻呼消息对应的IMSI信息。

具体的，在寻呼子信道上发送的寻呼消息数量接近寻呼子信道容量阈值时，对该寻呼子信道上的寻呼调度发送优先保证语音业务(Conversational)的寻呼(包括语音业务的一次寻呼、二次寻呼、三次寻呼等寻呼)以及其它业务首次寻呼的调度发送，这两者中首先保证语音业务的寻呼，其次是除语音业务以外的业务的首次寻呼。在保 证语音业务寻呼、其它业务首次寻呼能得到调度发送的前提下，对于其它业务寻呼，如果能得到调度发送机会则发送，对于超过寻呼子信道容量的则进行丢弃，并且记录被丢弃寻呼的IMSI信息。

本发明实施例中，如果超过寻呼子信道容量做丢弃处理，避免将寻呼消息按LAC/RAC分发到所有小区所在DSP上再判断寻呼信道是否有拥塞，采用此方法降低了设备内部消息数量，提高设备稳定性。

进一步地，所述根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量，具体包括以下图中未示出的步骤：

当接收到核心网设备发送的寻呼消息时，根据该寻呼消息中携带的IMSI计算该寻呼消息的寻呼接收时刻以及对应的寻呼子信道；

统计所述寻呼接收时刻所述寻呼子信道收到的寻呼消息数量。

可理解的是，RNC的工作机制是这样的，IU接口收到MSC/SGSN发来的寻呼消息，对每一条寻呼消息都要根据IMSI计算应该在哪条寻呼子信道上发送，在下一个寻呼周期到达时，在寻呼发送时刻通过PICH信道通知UE有寻呼消息要发送，然后在寻呼接收时刻把寻呼发出去，终端在寻呼接收时刻接收寻呼，从而实现终端的非连续接收寻呼消息。

在实际应用中，RNC的IU接口收到MSC或SGSN发过来的寻呼消息，计算寻呼时刻(Paging Occasion)以及寻呼消息接收时刻(Paging Message Receiving Occasion)，在寻呼时刻RNC在PICH信道发送被寻呼的终端信息，终端在寻呼时刻读取PICH发送的数据，收到后根据位图指示判断如果自己对应的位置为0则丢弃，等到下一个寻呼时刻再读取PICH信道，如果为1，则说明PCH信道上有属于自己的寻呼消息，终端计算寻呼消息接收时刻，并在寻呼消息接收时刻从PCH信道上读取寻呼数据。UTRAN和终端采用了相同 的公式和参数计算寻呼时刻以及寻呼消息接收时刻，因此保证了网络侧发送消息和终端接收消息时刻的一致，寻呼时刻以及寻呼消息接收时刻由如下公式计算得出：

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

Paging Message Receiving Occasion＝Paging Occasion+N_PICH+N_GAP+{(DRX Index mod Np)mod N_PCH}*2

参数说明如下：

IMSI：国际移动用户识别码，是区别移动用户的标识，存储手机在SIM卡中。

K：配置的SCCPCH信道个数，按照运行商要求目前现网各厂商都配置为1

DRX cycle length：非连续接收循环长度，现网典型值配置为64(单位为帧，TD-SCDMA系统一帧为10ms)

n:为非连续接收循环长度次数，取值0、1、2、3…，寻呼在DRX内发送。(举例说明，假如DRX为128(0～127)，第一次发送寻呼时刻为100，则第二次发送时刻为100+DRX长度128，第三次寻呼发送时刻为100+2*DRX长度128….,以此类推)；

PBP(Paging Block Periodicity)：寻呼块周期，与DRX cycle length一样均为64帧。

N_PICH：标识PICH信道占用的连续帧个数。

N_PCH:标识PCH包含的寻呼子信道个数，现网各厂商配置均按最大值8配置。

N_GAP：表示PICH块的结尾和PCH块的开头之间的帧数。

Np：每个PICH Block中包含包含的寻呼指示个数，一个无线子帧携带数据352bit，一个寻呼指示长度为8，因此Np＝352/8＝44。

Frame Offset：表示帧偏移，用于均衡负载。对于公共信道，Frame Offset总是规定为零。

RNC在PICH、PCH信道分别以寻呼指示块(PICH Block)、寻呼块(PCH Block)为单位发送寻呼指示消息以及寻呼消息，一个寻呼指示块在时域占用2*N_PICH个无线帧，一个寻呼块在时域占用2*N_PCH个无线帧，N_PCH是寻呼块中包含的寻呼子信道的个数，因此一个寻呼子信道在时域占用2个无线帧。

寻呼子信道号由(DRX Index mod Np)mod NPCH计算得出，TS25.304协议规定DRX Index的计算公式如下：

DRX Index＝IMSI div 8192

举例说明：假设一IMSI为460027670433352，则按(DRX Index mod Np)mod N_PCH公式计算：

(((460027670433352/8192)mod 44)mod 8)＝4，则此IMSI对应的UE的寻呼消息在PCH信道的寻呼子信道4上发送。

本发明实施例，RNC的高层信令收到IU接口寻呼消息后，即刻计算寻呼消息接收时刻以及发送的寻呼子信道，并统计所述寻呼接收时刻所述寻呼子信道收到的寻呼消息数量，判断对应寻呼子信道是否会发生寻呼拥塞，而不是等到无法调度发送时再做判断，有效减少了RNC内部消息交互，提高了系统稳定性。

在本发明实施例中，该消除寻呼子信道拥塞的方法，还包括以下图中未示出的步骤：

当接收到核心网设备发送的寻呼消息时，判断当前寻呼消息是否属于首次寻呼。

进一步地，所述判断当前寻呼消息是否属于首次寻呼，如图4所示，具体包括以下步骤：

S21、获取当前寻呼消息中携带的IMSI和寻呼原因；

S22、查找预设的寻呼表中是否记录有当前寻呼消息中携带的IMSI，所述寻呼表中记录有每一用户上一次发送的寻呼消息中携带 的IMSI和寻呼原因；

其中，寻呼表中每一个单元对应一个用户UE，每个单元包含IMSI、TMSI/P-TMSI、寻呼原因等信息。

当所述寻呼表中不存在当前寻呼消息中携带的IMSI时，执行步骤S23，当所述寻呼表中记录有当前寻呼消息中携带的IMSI时，执行步骤S24；

S23、判定当前寻呼消息属于首次寻呼，并将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中；

S24、判断当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因是否相同；

若相同，执行步骤S25，否则，执行步骤S26；

S25、判定当前寻呼消息不属于首次寻呼，丢弃当前寻呼消息；

S26、判定当前寻呼消息属于首次寻呼，清除所述寻呼表中记载的寻呼原因，并将当前寻呼消息中携带的寻呼原因添加到所述寻呼表中。

更进一步地，在所述将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中之后，所述方法还包括以下步骤：

S27、判断在预设寻呼重发定时时间内，是否收到终端发送的寻呼响应消息；

若是，执行步骤S28，否则，执行步骤S29；

S28、确定寻呼成功，并清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因；

S29、当到达所述预设寻呼重发定时时间时，清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因。

本实施例中，判断是首次寻呼还是重复寻呼的流程，可根据IMSI、TMSI/P-TMSI(Temporary Mobile Subscriber Identity，临时移动用户识别码)结合核心网寻呼重发周期判断。其中，核心网的寻呼 重发周期可以从核心网配置或者RNC自行判断得到，具体方法不在此详细描述。

具体的，判断重复寻呼的步骤如下：

RNC收到IU接口寻呼消息后，根据IMSI信息查找寻呼表中是否存在。如果不存在，则认为是首次发送寻呼，保存IMSI、TMSI/P-TMSI、寻呼原因信息到寻呼表，启动寻呼重发定时器；

如果存在则说明之前发过寻呼，再判断寻呼原因和前一次是否相同，相同则认为是重复寻呼进行丢弃，否则，认为是首次发送寻呼，保存IMSI、TMSI/P-TMSI、寻呼原因信息到寻呼表，启动寻呼重发定时器。

如果在寻呼重发定时器的定时时间之内收到了终端发送的初始直传消息Initial Direct中携带的寻呼响应消息(即初始直传消息中Service type字段是Paging Response)，则认为寻呼成功，停止定时器，清除寻呼表中记载的IMSI、TMSI/P-TMSI、寻呼原因信息。

如果在寻呼重发定时器超时之前没有收到对应的寻呼响应消息(Paging Response)，则清除寻呼表中保存IMSI、TMSI/P-TMSI、寻呼原因信息。

需要说明的是，寻呼重发定时器设置要比核心网的寻呼重发定时器略微长，但又必须小于核心网2次重发寻呼的总体时长，以保证此定时器超时前核心网的寻呼重发定时器超时。否则可能会出现RNC的定时器先超时将对应寻呼表UE信息清除，而核心网寻呼重发定时器后超时重发寻呼，RNC的寻呼表由于找不到对应的UE信息而错误认为是首次寻呼。

本发明避免了由于IMSI分布不合理导致的寻呼子信道拥塞，有效降低设备负荷，提高设备稳定性。

图5示出了本发明实施例的一种无线网络控制设备的结构框图。

参照图5，本发明实施例提出的无线网络控制设备，具体包括 数量确定模块101、寻呼容量获取模块102、查看模块103以及发送模块104，其中：

所述的数量确定模块101，用于根据IU接口收到的寻呼消息数量，确定寻呼子信道上需要调度发送的寻呼消息数量；

所述的寻呼容量获取模块102，用于获取所述寻呼子信道的寻呼容量；

所述的查看模块103，用于当在所述寻呼子信道上需要调度发送的寻呼消息数量大于或等于该寻呼子信道的寻呼容量阈值时，查看该寻呼子信道上需要调度发送的寻呼消息的寻呼原因；其中，所述寻呼容量阈值小于所述寻呼容量；

所述的发送模块104，用于根据每一寻呼消息的寻呼原因，按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息。

本发明实施例，通过对超过寻呼容量的寻呼消息进行分析，优先保证CS业务寻呼以及其它业务的首次寻呼，丢弃其它业务的重复寻呼，在一定程度上降低了由于设备内部寻呼消息量大导致的RNC设备负荷升高、稳定性降低的概率，有效地降低了设备内部消息数量，提高设备稳定性。

在本发明另一实施例中，所述无线网络控制设备，如图6所示，还包括：IMSI统计模块105；

IMSI统计模块105，用于当在所述寻呼子信道上需要调度发送的寻呼消息数量大于该寻呼子信道的寻呼容量时，统计寻呼消息中携带的国际移动用户识别码IMSI，得到统计报表；

所述发送模块104，还用于将所述统计报表上报给核心网设备，以使核心网设备根据所述统计报表调整统计报表中IMSI对应的寻呼消息的寻呼间隔。

本发明实施例，通过计算单条寻呼子信道的寻呼容量，如果单位时间(一个寻呼周周PBP)内某个寻呼消息接收时刻对应的寻呼子 信道上要发送的寻呼消息数量超过寻呼子信道容量时，统计寻呼消息中IMSI值并上报统计报表提交给网络运营商，网络运营商可以据此调整IMSI寻呼间隔。避免了由于IMSI分布不合理导致的寻呼子信道拥塞，并且是从IU接口收到寻呼消息后即刻进行寻呼子信道容量判决，从而使得网络运营商及时地对IMSI寻呼间隔进行调整，在一定程度上降低由于设备内部寻呼消息量大且集中导致的RNC设备负荷升高、稳定性降低的概率，对于降低寻呼信道拥塞、降低设备负荷、提高设备稳定性的目的具有积极作用。

本实施例中，所述数量确定模块，包括计算单元和统计单元，其中：

所述的计算单元，用于当接收到核心网设备发送的寻呼消息时，根据该寻呼消息中携带的IMSI计算该寻呼消息的寻呼接收时刻以及对应的寻呼子信道；

所述的统计单元，用于统计所述寻呼接收时刻所述寻呼子信道收到的寻呼消息数量。

本实施例中，所述无线网络控制设备还包括：优先级设定模块；

所述的优先级设定模块，用于在按照预设的寻呼优先级顺序发送所述需要调度发送的寻呼消息之前，根据每一寻呼消息对应的业务类型的实时性要求，对寻呼消息进行寻呼优先级排序，以确定所述需要调度发送的寻呼消息中每一寻呼消息的寻呼优先级顺序；

其中，所述寻呼优先级的优先顺序依次为：

语音寻呼>除语音业务以外的业务的首次寻呼>除语音业务以外的业务的重复寻呼。

本发明实施例中，RNC从IU接口接收到寻呼消息，按照IMSI、以及寻呼参数计算寻呼时刻、寻呼消息接收时刻，如果单位寻呼周期PBP内落在某个寻呼子信道上的寻呼消息达到寻呼子信道的寻呼容量，则对超过寻呼容量的寻呼消息进行分析，优先保证CS业务寻 呼以及其它业务的首次寻呼，丢弃其它业务的重复寻呼。

本实施例中，所述无线网络控制设备还包括：判断模块；

所述的判断模块，用于当接收到核心网设备发送的寻呼消息时，判断当前寻呼消息是否属于首次寻呼。

进一步地，所述判断模块，具体包括获取单元、查找单元、添加单元、第一判断单元以及处理单元，其中：

所述的获取单元，用于获取当前寻呼消息中携带的IMSI和寻呼原因；

所述的查找单元，用于查找预设的寻呼表中是否记录有当前寻呼消息中携带的IMSI，所述寻呼表中记录有每一用户上一次发送的寻呼消息中携带的IMSI和寻呼原因；

所述的添加单元，用于当所述寻呼表中不存在当前寻呼消息中携带的IMSI时，判定当前寻呼消息属于首次寻呼，并将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中；

所述的第一判断单元，用于当所述寻呼表中记录有当前寻呼消息中携带的IMSI时，判断当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因是否相同；

所述的处理单元，用于当所述第一判断单元的判断结果为当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因相同时，判定当前寻呼消息不属于首次寻呼，丢弃当前寻呼消息；当所述第一判断单元的判断结果为当前寻呼消息中携带的寻呼原因和寻呼表中记载的寻呼原因不相同时，判定当前寻呼消息属于首次寻呼，清除所述寻呼表中记载的寻呼原因，并将当前寻呼消息中携带的寻呼原因添加到所述寻呼表中。

更进一步地，所述判断模块还包括：第二判断单元；

所述第二判断单元，用于在所述将当前寻呼消息中携带的IMSI和寻呼原因添加到所述寻呼表中之后，判断在预设寻呼重发定时时 间内，是否收到终端发送的寻呼响应消息；

相应的，所述处理单元，还用于当所述第二判断单元的判断结果为在预设寻呼重发定时时间内，收到终端发送的寻呼响应消息时，确定寻呼成功，并清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因；当到达所述预设寻呼重发定时时间时，清除所述寻呼表中记录的当前寻呼消息中携带的IMSI和寻呼原因。

进一步地，本实施例中，还包括：寻呼容量阈值计算单元，用于根据设备当前负荷状态，确定容量调整系数，并将所述寻呼子信道的寻呼容量和容量调整系数的乘积作为所述寻呼子信道的寻呼容量阈值。

此外，对于无线网络控制设备实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

综上所述，本发明实施例提供的消除寻呼子信道拥塞的方法及无线网络控制设备，避免由于IMSI分布不合理导致的寻呼子信道拥塞，通过从IU接口收到寻呼消息后即刻进行寻呼子信道容量判决，通过对超过寻呼容量的寻呼消息进行分析，按照预设的寻呼优先级顺序发送需要调度发送的寻呼消息，优先保证CS业务寻呼以及其它业务的首次寻呼，丢弃其它业务的重复寻呼，在一定程度上降低了由于设备内部寻呼消息量大导致的RNC设备负荷升高、稳定性降低的概率，有效地降低了设备内部消息数量，提高设备稳定性。

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

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

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

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。