CN1301626C - 一种对移动交换中心进行***负荷控制的方法 - Google Patents

一种对移动交换中心进行***负荷控制的方法 Download PDF

Info

Publication number
CN1301626C
CN1301626C CNB2004100090733A CN200410009073A CN1301626C CN 1301626 C CN1301626 C CN 1301626C CN B2004100090733 A CNB2004100090733 A CN B2004100090733A CN 200410009073 A CN200410009073 A CN 200410009073A CN 1301626 C CN1301626 C CN 1301626C
Authority
CN
China
Prior art keywords
overload
professional number
interval
professional
refusal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CNB2004100090733A
Other languages
English (en)
Other versions
CN1571538A (zh
Inventor
王振
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CNB2004100090733A priority Critical patent/CN1301626C/zh
Publication of CN1571538A publication Critical patent/CN1571538A/zh
Application granted granted Critical
Publication of CN1301626C publication Critical patent/CN1301626C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

本发明涉及一种对移动交换中心进行***负荷控制的方法,包括如下步骤:建立一个过负荷控制进程,独立运行于***,为***的各业务模块提供统一的调用接口,进入初始状态,并在***启动或由备机转为主机时,进行数据初始化,进入工作状态;支撑***设置一超级定时器,用于向过负荷控制进程发送定时器消息;检测***CPU占用率,统一确定***过负荷或者过负荷解除,以确定是否需要进行过负荷控制,并判断是否接受或者限制某次业务;在需要进行过负荷控制时,在预定间隔时间内设定允许接入的业务数,对超过数量的业务进行限制。该方法降低了***负荷控制复杂度,便于统一管理与维护,减少了负荷控制中的负荷波动,避免了负荷控制失效等问题。

Description

一种对移动交换中心进行***负荷控制的方法
技术领域
本发明涉及一种***负荷控制的方法,尤其涉及一种对CDMA(码分多址)通信***中的MSC(移动交换中心)进行过负荷控制的实现方法。
背景技术
在CDMA移动通信***中,MSC处于核心位置(如图1所示),它通过信令与其它实体实时交互,与其它实体共同构成七号信令网。MSC是对位于其所覆盖区内的移动台(MS)进行控制、交换的功能实体,也是移动通信***与公共电话网(PSTN)、综合业务数字网(ISDN)、分组交换网(PSPDN)以及其他移动交换网的接口。MSC除了完成固定网中交换中心所完成的呼叫控制等功能外,还要完成无线资源管理、移动性管理等功能。另外,为了建立至移动台的呼叫路由,每个MSC还应能完成入口(GMSC)的功能,即查询移动台位置信息的功能。
MSC为了完成上述功能,需要与其它实体间交互大量的信令消息,各种消息的流量是动态变化的,在7号信令网中并没有提供明确有效的流量控制方法,所以,MSC可能会由于在短时间内收到大量的消息造成***过负荷,导致***性能急剧下降甚至瘫痪,在给用户带来不便的同时,也给局方造成很大的经济损失,更为重要的是损坏了公司形象,影响了产品的销售。这对每一方来说,都是不愿看到的。因此,必须对MSC的***负荷进行有效地控制,使其在处理最大限度的消息数量的情况下能平稳地度过消息高峰期,从而保证***的正常运行。
在中国专利号为99117082.2的“一种在移动交换中心应用层中实现过负荷控制的方法”中,提供了一种过负荷的控制方法,此专利的特点是:(1)定时确定相应的流量级别;(2)比较确定实施流量控制级别;(3)判定MSC是否过载;(4)收到业务初始消息根据流量级别采用相应的流量控制方法。其缺点是:(1)确定流量级别的方式复杂,容易导致***失控;(2)定时器的设置缺乏保护,当定时器设置失败时,***失去负荷控制能力;(3)各个模块都有一套自己的过负荷控制方式,不利于统一管理和维护。这些缺点在***的实际运行中均有所体现。
另外,在中国专利号为00127306.X的“码分多址蜂窝移动通信***中过负荷控制的方法”中,也提出一种过负荷控制方法,其控制方法与上述的专利类似,也是采用按流量级别进行控制的方法,其特点是(1)流量级别的判别方法是根据CPU的占有率,简化了流量级别的确定方法;(2)当***流量控制级为最低流量控制级时,把消息全部接入;(3)当***流量控制级为最高流量控制级时,把消息全部拒绝;(4)当***流量在最低流量控制级和最高流量控制级之间时,任取一随机数与最高流量级减去***流量控制级再加1求模。其缺点是:未从根本上解决过负荷控制机制过于复杂的弊端,而且在过负荷控制过程时,允许***处理的消息数量有较大的波动,不利于***的稳定,尤其是在***流量控制级为最高流量控制级且定时器设置失败时,所有业务均被拒绝,造成***假死状态。
发明内容
本发明所要解决的技术问题在于提供一种对移动交换中心进行***负荷控制的方法,采用集中检测、分散控制的方式,建立一个独立的过负荷控制进程,由此进程为各业务模块提供统一的调用接口,便于统一管理和维护。
本发明的另一目的在于提供一种对移动交换中心进行***负荷控制的方法,采用CPU的占用率作为过负荷状态的唯一判断条件,降低对***是否处于过负荷状态的判断条件的复杂度。
本发明的又一目的在于提供一种对移动交换中心进行***负荷控制的方法,增加拒绝间隔的控制机制,进一步减小***在处于过负荷控制期间的负荷波动。拒绝间隔是一个数量值,它是指上一次允许接入业务后,后继相应数量的业务将会被拒绝,然后,再次允许接入下一次业务。
本发明的再一目的在于提供一种对移动交换中心进行***负荷控制的方法,使用超级定时器,由支撑***定时给过负荷控制进程发送定时器超时消息,避免了因定时器设置失败引起负荷控制失效以及***拒绝所有业务的严重后果。支撑***是指在分层软件中,处于底层的负责进程调度,消息管理,内存管理等功能的程序,支撑***对上层程序提供相应的接口,屏蔽内部实现细节。超级定时器是相对于一般定时器来说的,一般定时器是上层程序中设置的,超时之后此定时器就失效了。而超级定时器是由底层支撑程序提供的,它定时向设定好的进程发送超时消息,永远生效,所以叫做超级定时器。
为了实现上述目的,本发明提供了一种对移动交换中心进行***负荷控制的方法,该方法包括如下步骤:
步骤一,建立一个过负荷控制进程,独立运行于所述移动交换中心***,为所述移动交换中心***的各业务模块提供统一的调用接口,进入初始状态,并在所述***启动或由备机转为主机时,进行数据初始化,进入工作状态;
步骤二,所述过负荷控制进程由支撑***设置一超级定时器,在工作状态时,每隔一个预定时间间隔由支撑***给所述过负荷控制进程发送一次超级定时器消息;
步骤三,检测***CPU占用率,统一确定***过负荷或者过负荷解除,以确定是否需要进行过负荷控制,并判断是否接受或者限制某次业务;步骤四,在需要进行过负荷控制时,在所述预定时间间隔内,设定允许接入的业务数,对超过数量的业务进行限制;
上述的对移动交换中心进行***负荷控制的方法,其特点在于,在所述预定时间间隔内,所述过负荷进程对接受的业务数以及拒绝的业务数按业务类型分别统计,并在收到所述超级定时器消息后,根据预定时间间隔内各项统计值及***当前的CPU占用率,对过负荷控制参数进行动态调整。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,对所述超过数量的业务进行限制是通过采用增加拒绝间隔来限制业务数,并将限制的业务数尽量均匀地分散到整个时间间隔内。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,在步骤三中,所述***根据CPU占用率,分别设置四个门限值:低负荷门限值<正常门限值<预警门限值<过负荷门限值,并将***负荷状态分为五个区域:低负荷区、正常负荷区、缓冲区、预警负荷区和过负荷区。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,在步骤三中,判断***过负荷或者过负荷解除,以确定是否进行过负荷控制的判决条件为:
当***CPU占用率超过预警门限值时,***进入过负荷状态,开始进行过负荷控制;
当***CPU占用率小于预警门限值时,且***没有丢弃消息时,解除***过负荷状态,不再进行过负荷控制;
若***前一时间间隔内处于过负荷状态,且存在丢弃消息,即使CPU占用率小于预警门限值,也仍然处于过负荷状态,需要进行过负荷控制。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,所述过负荷控制进程通过调用其支撑接口,获取CPU占用率,结合***数据区记录的***负荷状态、以及限制的业务数,来判断当前***负荷状态并进行相应控制和调整:
当***CPU占用率超过预警门限值时,但***数据区未记录有过负荷,则判断***进入过负荷状态,并设置过负荷控制参数的初始值;
当***CPU占用率超过预警门限值时,且***数据区记录有过负荷,则***一直处于过负荷状态,调整过负荷控制参数;
当***CPU占用率小于预警门限值时,且***数据区记录有过负荷,则判断是否存在限制的业务数,若有限制的业务数,则保持过负荷状态,调整过负荷控制参数;若没有限制的业务数,则解除***过负荷状态;
当***CPU占用率小于预警门限值时,且数据区未记录有过负荷,则一直处于正常状态。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,所述过负荷控制参数至少包括拒绝间隔、预定时间间隔内允许接入的最大业务数、前一预定时间间隔内接受的业务数、当前预定时间间隔内接受的业务数、因拒绝间隔而限制的业务数、以及因允许接入的业务数而限制的业务数其中的一个或多个。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,对预定时间间隔内允许接入的最大业务数的调整方法为:
当CPU占用率超过过负荷门限值时,以整下降步长减少允许接入的业务数;
当CPU占用率在预警门限值与过负荷门限值之间时,以半下降步长减少允许接入的业务数;
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率在正常门限和预警门限值之间时,不调整允许接入的业务数。
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率在低负荷门限值与正常门限值之间时,以半上升步长增加允许接入的业务数。
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率小于低负荷门限值时,以整上升步长增加允许接入的业务数。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,对拒绝间隔的大小的调整方法为:
***刚进入过负荷状态时,若CPU占用率大于过负荷门限值,则采用一第一初始值作为拒绝间隔的初始值;
***刚进入过负荷状态时,若CPU占用率在预警门限值与过负荷门限值之间,则采用一第二初始值作为拒绝间隔的初始值,且所述第二初始值大于所述第一初始值;
***处于过负荷的状态下,每个预定时间间隔超时后,根据前一个预定时间间隔内拒绝业务的情况,调整拒绝间隔;
当拒绝间隔大于一预设值且***负荷低于预警门限时,则不使用拒绝间隔进行业务限制;
所述拒绝间隔最小值为2,最大值为50。
上述的对移动交换中心进行***负荷控制的方法,其特点在于,所述统计过程包括如下步骤:
所述各业务模块的业务进程在收到新的业务消息时,调用所述过负荷控制进程提供的接口函数,根据本次接入的业务类型,以及当前***的负荷状态,决定是否限制本次业务;所述统一的调用接口提供接口函数,根据当前的***负荷状态、允许接入的业务数以及拒绝间隔,确定是否限制本次业务,返回相应值给各业务模块以继续接续或者限制本次业务,并在接受本次业务时,将与本次业务类型对应的当前单位时间间隔内接受的业务数加1,在限制本次业务时,将与本次业务类型对应的因拒绝间隔而限制的业务数或因允许接入的业务数而限制的业务数加1;
在收到所述超级定时器消息后,取前一预定时间间隔内接受的业务数与当前单位时间间隔内接受的业务数的平均值更新到前一单位时间间隔内接受的业务数;
在进行完所述过负荷控制参数的调整后,清除当前预定时间间隔内的所有统计值,以便于下一个预定时间间隔的统计。
另外,本发明的对移动交换中心进行***负荷控制的方法,所述过负荷控制进程在进入过负荷或者解除过负荷时,均向***的后台告警,并在过负荷状态下,按照设定的日志记录间隔,向后台发送通知,上报当前的负荷状态,以及各业务被接受和拒绝的次数,用于后台记录日志文件。本发明方法所涉及的业务种类包括:A口语音起呼、A口起呼短消息、A口位置更新、MAP终呼短消息、TCAP对话ID、TUP入局呼叫、ISUP入局呼叫,以及CAS入局呼叫。
同时,本发明的所述过负荷控制进程在进入工作状态或者初始状态时,还包括一对过负荷控制参数进行检查的步骤,在通过检查后才启动过负荷控制进程,所述过负荷控制参数采用***后台配置。并且,对需要进行过负荷控制的接入业务,实行丢弃消息处理。对不同业务类型通过设置不同的上升和下降的步长,实现对不同业务类型进行不同优先级的控制。
本发明的***负荷控制方法,以CPU占用率作为过负荷状态的唯一判断条件,降低了对***是否处于过负荷状态的判断条件的复杂度;并通过采用集中检测、分散控制的方式,建立一个独立的过负荷控制进程,由此进程为各业务模块提供统一的调用接口,便于统一管理和维护。另外,还增加了拒绝间隔的控制机制,进一步减小了***在处于过负荷控制期间的负荷波动,并通过使用定时器,由支撑***定时给过负荷控制进程发送定时器消息,避免了因定时器设置失败引起的过负荷控制失效以及***拒绝所有业务的严重后果。
以下结合附图和具体实施例对本发明进行详细描述,但不作为对本发明的限定。
附图说明
图1是CDMA数字蜂窝移动通信***各逻辑功能实体图;
图2是本发明的***负荷门限图;
图3是本发明的***接入业务示例图;以及
图4是本发明的一较佳的过负荷控制工作流程图。
具体实施方式
过负荷控制包含两个关键因素,过负荷状态的检测和过负荷控制数据的调整。
过负荷控制需要检测***当前的负荷状态,以确定是否需要进行过负荷控制。从试验室测试结果,以及商用局经验来看,内存占用率和数据区占用率等都不能够作为有效的***负荷检测指标,影响***稳定运行的指标主要是CPU占用率,因此本发明把CPU占用率作为唯一的***负荷状态的检测指标。考虑到CPU占用率不断变化,检测的及时性对有效控制负荷的影响,以及频繁的检测动作对***性能的影响,可采用2秒时间间隔作为预定时间间隔,定期检测CPU占用率,并判断是否需要过负荷控制。
并且,由于***负荷主要是由业务产生的,因此负荷的控制就是对业务进行控制,并且需要从业务的源头上进行控制。对于MSC来说,主要是控制A口、MAP、TUP/ISUP/CAS的业务,以及TCAP的对话ID。***的处理能力往往采用BHCA来衡量,也就是单位时间间隔内能够处理的业务数量,因此,过负荷控制也采用限制单位时间间隔内的业务次数来进行。
并且,为了有效地设计过负荷控制的算法,本发明可以从以下几个方面来考虑:
(1)控制接入***的业务量,需要在业务接入***的源头处进行控制,即在A口、MAP、TCAP和TUP/ISUP/CAS处进行控制,控制的业务种类包括:A口语音起呼、A口起呼短消息、A口位置更新、MAP终呼短消息、TCAP对话ID、TUP入局呼叫、ISUP入局呼叫,以及CAS入局呼叫。
(2)从用户的拨号习惯来看,如果一次呼叫不成功,大多数情况下,会立即发起新的呼叫,因此需要延长用户重新拨号的时间,以免在短时间内加大***话务量。这样,对需要进行过负荷控制的呼叫,不是立即失败,而是进行丢弃消息处理,不回应任何响应消息。
(3)过负荷控制需要维持一定的业务处理能力,对被叫半呼叫不应该进行控制,否则反而造成新的重复试呼。
(4)相对于及时解除过负荷控制来讲,保证***稳定运行是最紧要的,因此采取快速控制,缓慢恢复的策略,避免过负荷控制解除过快,造成新的过负荷。
综上所述,本发明的过负荷控制方法,主要采用集中检测、分散控制的方式,以便于维护和扩充。其主要包括如下步骤:
步骤一,建立一个过负荷控制进程,独立运行于所述移动交换中心***,为所述移动交换中心***的各业务模块提供统一的调用接口,进入初始状态,并在所述***启动或由备机转为主机时,进行数据初始化,进入工作状态。所述过负荷控制进程在由主机转为备机时进入初始状态。
步骤二,所述过负荷控制进程由支撑***设置一超级定时器,在工作状态时,每隔一个预定时间间隔给所述过负荷控制进程发送一次超级定时器消息。为了避免因定时器设置失败引起的过负荷控制失效以及***拒绝所有业务的严重后果,本发明较佳的采用了超级定时器,并较佳的以2秒作为一预定时间间隔,由支撑***定时给过负荷控制进程发送定时器消息。超级定时器是由支撑***来设置或释放,不需过负荷控制进程来设置或释放,也就不存在设置定时器失败的情况。当然,也可采用一般的定时器实现本发明的效果,这些并不作为对本发明的限制。一般的定时器由过负荷控制进程或业务层来设置或释放,若设置失败,可能会引起较严重的后果(如造成资源吊死或***瘫痪)。
步骤三,检测***CPU占用率,统一确定***过负荷或者过负荷解除,以确定是否需要进行过负荷控制,并判断是否接受或者限制某次业务。为了降低对***是否处于过负荷状态的判断条件的复杂度,本发明较佳的以CPU的占用率作为过负荷状态的唯一判断条件。
步骤四,在需要进行过负荷控制时,在所述预定时间间隔内,设定允许接入的业务数,对超过数量的业务进行限制。其中,当需要进行过负荷控制时,可较佳的以2秒钟作为该预定时间间隔,设定允许接入的业务数,对超过数量的业务进行限制。
较佳的,在步骤四的同时,在所述预定时间间隔内,所述过负荷进程对接受的业务数以及拒绝的业务数按业务类型分别统计,并在收到所述超级定时器消息后,根据预定时间间隔内各项统计值及***当前的CPU占用率,对过负荷控制参数进行动态调整,从而有效地控制负荷。其中所述过负荷控制参数至少包括拒绝间隔、单位时间间隔内允许接入的最大业务数、前一单位时间间隔内接受的业务数、当前单位时间间隔内接受的业务数、因拒绝间隔而限制的业务数、以及因允许接入的业务数而限制的业务数其中的一个或多个。本发明对过负荷控制参数的调整主要是调整当前允许接入的最大业务数及当前拒绝间隔的大小,其调整方法详见后述的具体实施例。
如图4所示,为本发明的一较佳的过负荷控制工作流程图。其包括如下步骤:
步骤401,***的过负荷控制进程处于初始始态;
步骤402,若***启动,即主机发生上电事件,或***发生由备机转主机事件,则进入步骤404;
步骤403,若***发生除步骤402所述事件以外的其它事件,则进入步骤405;
步骤404,数据初始化,然后进入步骤406;
步骤405,过负荷控制进程进入初始始态;
步骤406,过负荷控制进程进入工作状态;
步骤407,若主机转备机,则进入步骤409;
步骤408,若发生超级定时器事件,则进入步骤410;
步骤409,过负荷控制进程进入初始始态;
步骤410,进行过负荷控制相关参数检查;
步骤411,进行过负荷控制数据调整;
步骤412,恢复至过负荷控制进程工作态。
在本发明中,如图2所示,考虑到程序处理的简洁、有效,以及过负荷控制的有效性,本发明根据CPU占用率,取4个门限值,低负荷门限值<正常门限值<预警门限值<过负荷门限值,将***负荷状态分为5个区域:低负荷区、正常负荷区、缓冲区、预警负荷区和过负荷区。其中,各个CPU占用率的门限值,以及“上升步长”和“下降步长”,由后台配置确定。为了方便控制,步长用百分比表示,表示增加或者减少当前2秒内“允许接入的业务数”的比例。为了实现对不同的业务进行不同优先级的控制,可以分别设置不同的上升和下降步长。
并且,在正常情况下,***CPU占用率小于预警门限,判断***过负荷和解除的条件为:
(1)当***CPU占用率超过预警门限时,判断***进入过负荷状态,开始进行过负荷控制。
(2)当***CPU占用率小于预警门限,且***没有丢弃消息时,解除***过负荷状态,不再进行过负荷控制。
(3)若***前一时间间隔内处于过负荷状态,且存在丢弃消息,即使CPU小于预警门限,也仍然处于过负荷状态,需要进行过负荷控制。
本发明的MSC***在工作态,收到超级定时器消息后,所述过负荷控制进程调用其支撑接口,并获取CPU占用率,结合数据区记录的***负荷状态、以及(“因拒绝间隔而限制的业务数”+“因允许接入的业务数而限制的业务数”),判断当前MSC***状态并进行相应控制和调整:
(1)若CPU高于预警门限,但数据区未记录过负荷,则判断***进入过负荷,向后台告警,设置“允许接入的业务数”和“拒绝间隔”等过负荷控制参数的初值。
(2)若CPU高于预警门限,且数据记录有过负荷,则一直处于过负荷状态,调整“允许接入的业务数”和“拒绝间隔”等过负荷控制参数。
(3)若CPU低于预警门限,但数据区记录有过负荷,则判断(“因拒绝间隔而限制的业务数”+“因允许接入的业务数而限制的业务数”),若有限制的业务数,则保持过负荷状态,调整“允许接入的业务数”和“拒绝间隔”等;若没有限制的业务数,则解除过负荷状态,且向后台发送告警恢复。
(4)若CPU低于预警门限,且数据区未记录过负荷,则一直处于正常状态。
在***过负荷期间,收到超级定时器消息后,过负荷控制进程根据当前CPU占用率,调整“允许接入的业务数”。其调整方法为:
(1)当CPU占用率超过过负荷门限时,以整下降步长减少“允许接入的业务数”。
(2)当CPU占用率在预警门限与过负荷门限之间时,以半下降步长减少“允许接入的业务数”。
(3)当***处于过负荷状态(未解除,仍然有限制的业务),CPU占用率在缓冲区内时,不调整“允许接入的业务数”。
(4)当***处于过负荷状态(未解除,仍然有限制的业务),CPU占用率在低负荷门限与正常门限之间时,以半上升步长增加“允许接入的业务数”。
(5)当***处于过负荷状态(未解除,仍然有限制的业务),CPU占用率小于低负荷门限时,以整上升步长增加“允许接入的业务数”。
另外,由于本发明采用控制一定时间间隔内允许接入的业务数量来控制***负荷后,在每个时间间隔内,将在前半个时间段内接受业务,后半个时间段内拒绝业务,接受的业务相当集中,会对***处理造成冲击,仍然不利于降低***负荷,因此,本发明还增加了拒绝间隔控制机制,采用增加一定的拒绝间隔来限制业务数,同时,为了在不同的话务量情况下合理地设置此“拒绝间隔”值,将限制的业务数尽量均匀地分散到整个时间间隔中,并且需要对此间隔进行一定程度的调整:
(1)***刚进入过负荷状态时,若CPU占用率大于过负荷门限,则采用一第一初始值作为拒绝间隔的初始值,如为2,即每2次业务拒绝一次业务。
(2)***刚进入过负荷状态时,若CPU占用率在预警门限与过负荷门限之间,则采用一第二初始值作为拒绝间隔的初始值,如为4,即每4次业务拒绝一次业务。
(3)***处于过负荷的状态下,每个时间间隔超时后,根据前一个时间间隔内拒绝业务的情况,调整“拒绝间隔”,为了防止受业务数量波动的影响,每次对此间隔以一定的百分比进行调整。
(4)当***负荷低于预警门限时,由于以拒绝的消息数作为解除过负荷的条件,拒绝间隔的存在可能使得拒绝消息一直存在,除非“拒绝间隔”大于时间间隔内的业务总数。因此,当“拒绝间隔”大于一预设值且***负荷低于预警门限时,则不使用拒绝间隔进行业务限制。例如,当“拒绝间隔”大于20且***负荷低于预警门限时,则不使用拒绝间隔进行业务限制。
(5)拒绝间隔应有一定的范围,最小值为2,最大值为50。
过负荷情况下,采用“拒绝间隔”对接入的业务进行限制后,在每个时间间隔内,***接入业务的情况如图3所示。如图3所示,假设***的单位时间间隔内接入的总业务量为A,设置的拒绝间隔为B,允许接入的业务数为C,因拒绝间隔而限制的业务数为D,因允许接入的业务数而限制的业务数为E,且该拒绝间隔B将拒绝的业务数均匀的分散到整个单位时间间隔中,并且,A=B+C+D+E。
下面将以一具体实施例详细说明本发明,其中,以2秒为单位时间间隔,超级定时器每2秒发送一次超时消息。
为了对不同的业务进行业务量统计和过负荷控制,过负荷进程提供接口函数供A口等业务进程调用,A口等业务进程在收到新的业务消息时,调用此函数接口,并根据返回值确定是否继续接续。函数接口为:
BYTE IsServiceLimited(BYTE wServiceType)
其中返回值为0和1,0表示业务不受限制而正常接续,1表示业务受限制。
在接口函数中,根据本次接入的业务类型,以及当前的***负荷状态,决定是否限制本次业务,同时对每2秒内的业务量进行统计,维护过负荷控制进程的数据,如下表(过负荷控制数据表)所示:
  业务类型   前2秒内接受的业务数   当前2秒内接受的业务数   因拒绝间隔而限制的业务数   因允许接入的业务数而限制的业务数   拒绝间隔   允许接入的业务数
  A口语音起呼   50   50   10   20   5   50
  A口短信起呼
  A口位置更新
  MAP短信终呼
  TUP入呼
  ISUP入呼
  CAS入呼
  TCAP对话ID
其中,“前2秒内接受的业务数”统计业务的流量,用于过负荷时作为“允许接入的业务数”的初始值;“当前2秒内接受的业务数”用于更新“前2秒内接受的业务数”;拒绝的业务数统计用于作为解除过负荷的判断条件,“因允许接入的业务数而限制的业务数”用于作为调整“拒绝间隔”的依据,若太大,则说明需要减小“拒绝间隔”;“拒绝间隔”和“允许接入的业务数”在每个时间间隔超时后,由过负荷控制进程进行调整。
函数被调用时,正常情况下,向业务类型对应的“当前2秒内接受的业务数”加1。收到超级定时器消息后将“当前2秒内接受的业务数”更新到“前2秒内接受的业务数”,为了防止业务数波动,取(“前2秒内接受的业务数”+“当前2秒内接受的业务数”)/2。过负荷情况下,根据***过负荷的级别计算出“允许接入的业务数”,并据此控制新接入业务的数量。
由于过负荷控制采用了后台配置的控制变量,参数的设置非常重要,否则可能在启用过负荷控制时,造成***运行紊乱,因此必须对这些参数进行检查,判断其是否在设定的范围内,以及各参数的大小顺序是否合理,否则不启用过负荷控制,且向后台告警。过负荷控制进程在MSC启动或者主备倒换时检查这些参数,若发现错误则以后每2秒检查一次;当检查通过后,以后每10分钟检查一次。当检查通过后,实际引用这些控制参数时,不再进行检查。
过负荷控制模块提供接口函数,根据当前的***负荷状态,以及“允许接入的业务数”和“拒绝间隔”,确定是否限制本次业务,若接受本次业务,向业务类型对应的“当前2秒内接受的业务数”加1;若限制本次业务,向“因允许接入的业务数而限制的业务数”加1,或者向“因拒绝间隔而限制的业务数”加1。
MSC处于工作态,收到超级定时器消息后,取(“前2秒内接受的业务数”+“当前2秒内接受的业务数”)/2,更新到“前2秒内接受的业务数”。所述过负荷控制进程调用其支撑接口,并获取CPU占用率,结合数据区记录的***负荷状态、以及(“因拒绝间隔而限制的业务数”+“因允许接入的业务数而限制的业务数”),判断当前MSC***状态并进行相应控制和调整:
(1)若CPU高于预警门限,但数据区未记录过负荷,则判断***进入过负荷,向后台告警,设置“允许接入的业务数”和“拒绝间隔”等过负荷控制参数的初值。
(2)若CPU高于预警门限,且数据记录有过负荷,则一直处于过负荷状态,调整“允许接入的业务数”和“拒绝间隔”等过负荷控制参数。
(3)若CPU低于预警门限,但数据区记录有过负荷,则判断(“因拒绝间隔而限制的业务数”+“因允许接入的业务数而限制的业务数”),若有限制的业务数,则保持过负荷状态,调整“允许接入的业务数”和“拒绝间隔”等;若没有限制的业务数,则解除过负荷状态,且向后台发送告警恢复。
(4)若CPU低于预警门限,且数据区未记录过负荷,则一直处于正常状态。
最后清除当前2秒内的所有统计值,以便于下一个时间间隔的统计。
过负荷控制进程在进入过负荷和解除过负荷时,向后台告警。另外,在过负荷状态下,按照设定的日志记录间隔,向后台发送通知,上报当前的负荷状态,以及各业务被接受和拒绝的次数,用于后台记录日志文件。
综上所述,本发明实现了一种过负荷控制的方案,采用了多个新的措施来保证方案能有效的发挥作用。通过在实际***中使用,表明这是一种简单且有效的过负荷控制方法,使***保持了较高的数据处理能力,并使整个***的性能在过负荷控制期间保持为一个较为平滑的曲线,很好的保证了***的稳定运行。
当然,本发明还可有其他多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1、一种对移动交换中心进行***负荷控制的方法,其特征在于,包括如下步骤:
步骤一,建立一个过负荷控制进程,独立运行于所述移动交换中心***,为所述移动交换中心***的各业务模块提供统一的调用接口,进入初始状态,并在所述***启动或由备机转为主机时,进行数据初始化,进入工作状态;
步骤二,所述过负荷控制进程由支撑***设置一超级定时器,在工作状态时,每隔一个预定时间间隔给所述过负荷控制进程发送一次超级定时器消息;
步骤三,检测***CPU占用率,统一确定***过负荷或者过负荷解除,以确定是否需要进行过负荷控制,并判断是否接受或者限制某次业务;
步骤四,在需要进行过负荷控制时,在所述预定时间间隔内,设定允许接入的业务数,对超过数量的业务进行限制。
2、根据权利要求1所述的对移动交换中心进行***负荷控制的方法,其特征在于,在所述预定时间间隔内,所述过负荷进程对接受的业务数以及拒绝的业务数按业务类型分别统计,并在收到所述超级定时器消息后,根据预定时间间隔内各项统计值及***当前的CPU占用率,对过负荷控制参数进行动态调整。
3、根据权利要求1所述的对移动交换中心进行***负荷控制的方法,其特征在于,对所述超过数量的业务进行限制是通过采用增加拒绝间隔来限制业务数,并将限制的业务数尽量均匀地分散到整个时间间隔内,所述拒绝间隔是一个数量值,指上一次允许接入业务后,后继相应数量的业务将会被拒绝。
4、根据权利要求2所述的对移动交换中心进行***负荷控制的方法,其特征在于,在步骤三中,所述***根据CPU占用率,分别设置四个门限值:低负荷门限值<正常门限值<预警门限值<过负荷门限值,并将***负荷状态分为五个区域:低负荷区、正常负荷区、缓冲区、预警负荷区和过负荷区。
5、根据权利要求4所述的对移动交换中心进行***负荷控制的方法,其特征在于,在步骤三中,判断***过负荷或者过负荷解除,以确定是否进行过负荷控制的判决条件为:
当***CPU占用率超过预警门限值时,***进入过负荷状态,开始进行过负荷控制;
当***CPU占用率小于预警门限值时,且***没有丢弃消息时,解除***过负荷状态,不再进行过负荷控制;
若***前一时间间隔内处于过负荷状态,且存在丢弃消息,即使CPU占用率小于预警门限值,也仍然处于过负荷状态,需要进行过负荷控制。
6、根据权利要求5所述的对移动交换中心进行***负荷控制的方法,其特征在于,所述过负荷控制进程通过调用其支撑接口,获取CPU占用率,结合***数据区记录的***负荷状态、以及限制的业务数,来判断当前***负荷状态并进行相应控制和调整:
当***CPU占用率超过预警门限值时,但***数据区未记录有过负荷,则判断***进入过负荷状态,并设置过负荷控制参数的初始值;
当***CPU占用率超过预警门限值时,且***数据区记录有过负荷,则***一直处于过负荷状态,调整过负荷控制参数;
当***CPU占用率小于预警门限值时,且***数据区记录有过负荷,则判断是否存在限制的业务数,若有限制的业务数,则保持过负荷状态,调整过负荷控制参数;若没有限制的业务数,则解除***过负荷状态;
当***CPU占用率小于预警门限值时,且数据区未记录有过负荷,则一直处于正常状态。
7、根据权利要求6所述的对移动交换中心进行***负荷控制的方法,其特征在于,所述过负荷控制参数至少包括拒绝间隔、预定时间间隔内允许接入的最大业务数、前一预定时间间隔内接受的业务数、当前预定时间间隔内接受的业务数、因拒绝间隔而限制的业务数、以及因允许接入的业务数而限制的业务数其中的一个或多个。
8、根据权利要求7所述的对移动交换中心进行***负荷控制的方法,其特征在于,对预定时间间隔内允许接入的最大业务数的调整方法为:
当CPU占用率超过过负荷门限值时,以整下降步长减少允许接入的业务数;
当CPU占用率在预警门限值与过负荷门限值之间时,以半下降步长减少允许接入的业务数;
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率在正常门限值和预警门限值之间时,不调整允许接入的业务数。
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率在低负荷门限值与正常门限值之间时,以半上升步长增加允许接入的业务数。
当***处于过负荷状态,且仍然有限制的业务数,CPU占用率小于低负荷门限值时,以整上升步长增加允许接入的业务数。
9、根据权利要求7所述的对移动交换中心进行***负荷的控制方法,其特征在于,对拒绝间隔的大小的调整方法为:
***刚进入过负荷状态时,若CPU占用率大于过负荷门限值,则采用一第一初始值作为拒绝间隔的初始值;
***刚进入过负荷状态时,若CPU占用率在预警门限值与过负荷门限值之间,则采用一第二初始值作为拒绝间隔的初始值,且所述第二初始值大于所述第一初始值;
***处于过负荷的状态下,每个预定时间间隔超时后,根据前一个预定时间间隔内拒绝业务的情况,调整拒绝间隔;
当拒绝间隔大于一预设值且***负荷低于预警门限时,则不使用拒绝间隔进行业务限制;
所述拒绝间隔最小值为2,最大值为50。
10、根据权利要求7所述的对移动交换中心进行***负荷控制的方法,其特征在于,所述统计过程包括如下步骤:
所述各业务模块的业务进程在收到新的业务消息时,调用所述过负荷控制进程提供的接口函数,根据本次接入的业务类型,以及当前***的负荷状态,决定是否限制本次业务;
所述统一的调用接口提供接口函数,根据当前的***负荷状态、允许接入的业务数以及拒绝间隔,确定是否限制本次业务,返回相应值给各业务模块以继续接续或者限制本次业务,并在接受本次业务时,将与本次业务类型对应的当前单位时间间隔内接受的业务数加1,在限制本次业务时,将与本次业务类型对应的因拒绝间隔而限制的业务数或因允许接入的业务数而限制的业务数加1;
在收到所述超级定时器消息后,取前一预定时间间隔内接受的业务数与当前单位时间间隔内接受的业务数的平均值更新到前一单位时间间隔内接受的业务数;
在进行完所述过负荷控制参数的调整后,清除当前预定时间间隔内的所有统计值,以便于下一个预定时间间隔的统计。
CNB2004100090733A 2004-05-10 2004-05-10 一种对移动交换中心进行***负荷控制的方法 Expired - Fee Related CN1301626C (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNB2004100090733A CN1301626C (zh) 2004-05-10 2004-05-10 一种对移动交换中心进行***负荷控制的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNB2004100090733A CN1301626C (zh) 2004-05-10 2004-05-10 一种对移动交换中心进行***负荷控制的方法

Publications (2)

Publication Number Publication Date
CN1571538A CN1571538A (zh) 2005-01-26
CN1301626C true CN1301626C (zh) 2007-02-21

Family

ID=34477797

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2004100090733A Expired - Fee Related CN1301626C (zh) 2004-05-10 2004-05-10 一种对移动交换中心进行***负荷控制的方法

Country Status (1)

Country Link
CN (1) CN1301626C (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100433711C (zh) * 2005-06-08 2008-11-12 杭州华三通信技术有限公司 一种报文限速方法
CN1984474B (zh) * 2006-05-30 2010-05-12 华为技术有限公司 实现移动用户数据安全备份的方法及***
CN100596104C (zh) * 2007-02-01 2010-03-24 华为技术有限公司 一种限呼方法和装置
CN101217561B (zh) * 2008-01-15 2012-11-28 杭州华三通信技术有限公司 一种增强网络存储可靠性的方法和一种网络设备
CN101583148B (zh) * 2008-05-16 2012-07-25 华为技术有限公司 一种通信设备过载处理方法及装置
CN101729285B (zh) * 2008-10-13 2014-04-02 大唐移动通信设备有限公司 提高设备可靠性的方法和通信设备
CN101547157B (zh) * 2009-04-22 2012-07-04 成都市华为赛门铁克科技有限公司 一种过载检测的方法、装置及***
CN101895980B (zh) * 2009-05-18 2013-02-13 大唐移动通信设备有限公司 任务同步的方法和设备
CN101674611A (zh) * 2009-09-16 2010-03-17 中兴通讯股份有限公司 一种短消息中心过负荷控制的方法和***
CN102301783A (zh) * 2011-05-17 2011-12-28 华为技术有限公司 流量控制方法及装置
CN107241761B (zh) * 2016-03-28 2019-11-19 大唐移动通信设备有限公司 一种基站的拥塞控制方法及装置
CN109358961B (zh) * 2018-08-14 2021-12-21 深圳市先河***技术有限公司 一种资源调度方法及其装置和具有存储功能的装置
CN110196766B (zh) * 2019-05-31 2021-07-13 中车青岛四方机车车辆股份有限公司 任务调度和处理方法及装置、存储介质和处理器
CN112308354A (zh) * 2019-07-31 2021-02-02 中兴通讯股份有限公司 ***过负荷控制方法及装置
CN117580089B (zh) * 2024-01-15 2024-04-05 东方通信股份有限公司 一种amf过载检测及控制的实现方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1184399A (zh) * 1996-11-30 1998-06-10 现代电子产业株式会社 数字移动通信***的动态过负载控制装置及其方法
JP2001309036A (ja) * 2000-04-20 2001-11-02 Fujitsu Ltd 通信装置及び輻輳規制制御方法
JP2001339434A (ja) * 2000-05-29 2001-12-07 Ishikawajima Harima Heavy Ind Co Ltd データ通信方法
CN1327645A (zh) * 1998-12-18 2001-12-19 诺基亚网络有限公司 通信网中的一种业务负载控制方法
CN1350374A (zh) * 2000-10-19 2002-05-22 华为技术有限公司 Cdma蜂窝移动通信***中多业务负载监测和预测的装置及其计算方法
WO2002049237A2 (en) * 2000-12-15 2002-06-20 Telefonaktiebolaget L M Ericsson (Publ) Congestion control in a cdma-based mobile radio communications system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1184399A (zh) * 1996-11-30 1998-06-10 现代电子产业株式会社 数字移动通信***的动态过负载控制装置及其方法
CN1327645A (zh) * 1998-12-18 2001-12-19 诺基亚网络有限公司 通信网中的一种业务负载控制方法
JP2001309036A (ja) * 2000-04-20 2001-11-02 Fujitsu Ltd 通信装置及び輻輳規制制御方法
JP2001339434A (ja) * 2000-05-29 2001-12-07 Ishikawajima Harima Heavy Ind Co Ltd データ通信方法
CN1350374A (zh) * 2000-10-19 2002-05-22 华为技术有限公司 Cdma蜂窝移动通信***中多业务负载监测和预测的装置及其计算方法
WO2002049237A2 (en) * 2000-12-15 2002-06-20 Telefonaktiebolaget L M Ericsson (Publ) Congestion control in a cdma-based mobile radio communications system

Also Published As

Publication number Publication date
CN1571538A (zh) 2005-01-26

Similar Documents

Publication Publication Date Title
CN1301626C (zh) 一种对移动交换中心进行***负荷控制的方法
CN1086095C (zh) 蜂窝电信***中分组交换无线电信道容许控制
CN1092905C (zh) 蜂窝电信***中分组交换业务的管理
CN1842024A (zh) 无线网络控制器存储资源监控方法及***
CN1859791A (zh) 一种无线通信网络中实现切换的方法和***及其基站
CN1882166A (zh) 一种根据负载状况选择服务节点的方法
CN1691827A (zh) 分配方法和控制器
CN1370022A (zh) 呼叫接受控制装置及方法
CN1681348A (zh) 控制移动终端非实时业务数据传输的方法
CN1765140A (zh) 多频率cdma移动网络中硬切换目标的生成
CN1553609A (zh) 实现cdma邻区列表的自动优化方法
CN1731870A (zh) 一种计费信息处理的方法
CN101043704A (zh) 一种更新用户设备位置信息的方法、网络及装置
CN1245389A (zh) 蜂窝移动通信***中前向功率控制的方法
CN101060471A (zh) 令牌资源流控方法
CN1095301C (zh) 在个人通讯服务***中处理位置注册的方法
CN101039263A (zh) 核心网节点过载的处理方法及移动交换设备和通信***
CN1905413A (zh) 自适应多速率业务调速方法及其***
CN1214555C (zh) 公共陆地移动网(plmn)分组网中统一管理资源的一种方法
CN1859785A (zh) 位置更新及用户归属的移动交换中心切换方法
CN1681349A (zh) 一种分层小区结构中的负载平衡方法
CN1723731A (zh) 无线接入网络控制方法和无线接入网络
CN1901741A (zh) Cdma***中无线空口寻呼信道自适应调整方法
CN1823541A (zh) 通信***、通信单元和其中的能力节省方法
CN1589051A (zh) 基于寻呼区的动态流量控制方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20070221

Termination date: 20140510