Title of Invention | THE METHOD OF CONTROLLING CALL LOAD IN SOFT SWITCH SYSTEM |
---|---|
Abstract | The method of controlling call load in Soft Switch system in present invention comprises the steps of: basic calling module receives the congestion direction message; judge whether the system congestion indicated by said congestion direction message is sporadic or sustaining; control the switching of user calling load according to the judgement whether the system congestion indicated by said congestion direction message is sporadic or sustaining. The aggressive effectiveness brought by present invention are: the system has the higher stability and reliability ; when the traffic overload state occurs, the setup of maximum calling number can be guaranteed and the system can also restore to the normal load state. Soft module doesn't influence the setup of normal calling, nor does the setup of urgency special service calling; the system possesses good adaptability, the controlling of load is efficient and stable, and has the self-adapting overload controlling capability. |
Full Text | follows: A method of controlling call load in a soft switch system, characterized by comprising: receiving a congestion indication message in a basic calling module; deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration with the help of the basic calling module; and implementing control for starting call load by basic calling module according to the decision of the burst or duration type for the system congestion. Preferably, the step of deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration is implemented by using timer Tl and T2; the timer Tl is a shorter duration timer; the timer T2 is a longer duration timer. Preferably, the step of receiving a congestion indication message in a basic calling module further includes as follows: deciding whether or not it is first time for the basic calling module to receive a congestion indication message; if yes, setting a traffic load status as a lowest level of overload status, and initiating the timer Tl and T2. Preferably, the step of deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration, further includes: deciding whether the timer Tl and T2 is overtime or not; if the timer Tl is not overtime, implementing a normal call process in the basic calling module; if the timer Tl is overtime but the timer T2 is not overtime, which indicates that the system congestion indicated by the congestion indication message may be in a type of duration, reinitiating the timer Tl and T2; if the timer Tl is overtime but the timer T2 is not overtime, and the traffic load status is the highest level of overload status, sending a congestion alarm to an operation and maintenance system (OAM) from the basic calling module; if both the timer Tl and the timer T2 are overtime, whicii indicates that the system congestion indicated by the congestion indication message is in a type of burst, reinitiating the timer T2; if both the timer Tl and the timer T2 are overtime and the traffic load status reaches normal status, implementing a normal call process in the basic calling module. Preferably, the step of implementing control for starting call load, further includes the steps as follows; refusing to accept non-emergency calls, when the system congestion indicated by congestion indication message is in a type of duration; and dropping the traffic load status down one level and decreasing a rate of refusing calls, when the system congestion indicated by congestion indication message is in a type of burst. Preferably, the step of refusing to accept non-emergency calls, further includes the steps as follows: moving the traffic load status up one level; counting a number of call requests received; working out a rate of refusing calls by using a traffic load controlling algorithm; refusing to accept non-emergency calls according to the rate of refusing calls. Preferable, the rate of refusing calls is in direct proportion to a number of calls that should be refused to accept except emergency calls; the rate of refusing calls is in inverse proportion to a number of calls that is counted subsequently after the current call requests is started to count; the number of calls that should be refused to accept except emergency calls is bigger than or equal to the number of calls that is counted subsequently after the current call request is started to count. Preferably, the traffic load control algorithm is calculated in accordance with a process load of the soft switch system in the IP network, and load of related data bearer network. Preferably, the process load of the soft switch system is obtained according to the following parameters: a rate of time occupied by CPU inside the soft switch system; traffic of communication for each software module inside the soft switch system; a average time delay for access of database inside the soft switch system; a memory capacity occupied by the call processing inside the soft switch system, and a percentage of free memory; and a process load percentage and message forwarding delay of communication process equipments inside the soft switch system. Preferably, the load of related data bearer network is obtained according to the following parameters: a traffic percentage of each date port, a communication delay in each router, a communication jitter in each router, a communication packet lost rate in each router, and » adjacent network traffic. •5" Preferably, the following conditions must be satisfied for controlling the traffic load by the traffic load control algorithm: emergency calls is ensured unblocked; calls from important users and priority users are ensured; calls from normal users are limited by a four level mode, in which call restraint rates are 50%, 75%, 87.5% and 100%; when traffic load is caused by a media stream, the soft switch system should shunt traffic of related date network, though soft switch itself is not overloaded; when traffic congestion is caused by a media stream, the coding mode of the media stream is controlled to reduce media traffic, for example, original G711 coding mode providing voice quality is changed into G732 or G729 mode adopting high compression rate. The active effect brought by the present invention is that the system has higher stability and reliability. Once traffic overload status occurs, connections with the maximum number of calls are ensured, and the system could be recovered to normal load status quickly. Normal call connections are not interrupted by soft modules, and connections for emergency calls for special services are not blocked by overloaded traffic. This method is suitable for wide. sk applications, and its traffic load control is smooth and effective with a adaptive overload control capability. Example embodiments will be described in details below with reference to the accompanying drawings for further and comprehensive understanding for the object, characteristics and merits about the present invention. BRIEF DESCRIPTION OF THE DRAWING FIG l i s a flow chart depicting a basic calling module of a soft switch system in traffic overload status; and FIG 2 is a flow chart depicting a call process of a basic calling module. DETAILED DESCRIPTION OF THE INVENTION When the call traffic received by the soft switch system has exceeded the traffic load capability that the system can handle, a congestion indication message is sent to a basic calling module. No action is taken for all congestion indication messages received during timer Tl, and its purpose is to make ensure no quick drop for the system traffic and also be able to effectively identify whether the system is overloaded within duration of very short time. The present invention will be further described below with reference to the accompanying drawings. As shown as Fig.l, in step 101, it is checked whether or not the congestion indication message is received by the basic calling module for the first time. If yes, change the traffic load status of system and set it as the lowest level (step 102), and also set the two timers, Tl with a shorter duration and 12 with a longer duration (step 103). If no, it is checked whether the timer Tl is overtime and T2 is not overtime (step 104); if yes, the traffic load status of basic calling module is moved one level up (step 105), and then it is checked whether the traffic load added is beyond the maximum threshold or not (step 106); If yes, the timers Tl and T2 is reinitiated (step 107); if no, which is explained that the system still has the congestion indication message although the traffic load status of the basic calling module has reached to the highest level, send the congestion indication message to OAM (step 108) ; then end the current service flow, and enter to a status of waiting message. If in step 104, the timer T2 is overtime, which is indicated that the congestion indication message has not been received during a duration of T2, the traffic load status is dropped one level down, and T2 is reinitiated; if at this time the T2 is overtime again, the traffic load status is dropped one level down again, until the traffic load status is recovered to a normal status; it is further checked whether neither the two timers Tl and T2 are overtime (step 109); if yes, enter directly to a waiting status; if no, the two timers Tl and T2 are reinitiated (step 110), and then enter to a waiting status. As shown as Fig.2, firstly it is checked whether the basic calling module has received a congestion indication message, namely whether currently the system has been in a status of traffic overload (step 201); if no, process calls normally (step 202); if yes, which is indicated that the system now has been in an overload status, set a current traffic load level (step 203), then set the corresponding algorithm according to the traffic load level (step 204) to work out the rate of refusing to accept non-emergency calls. The detail algorithm is as follows: starting from the current call, m calls should be refused to accept within subsequent n calls, (mS n), in which emergency calls should not be included in the m calls. Therefore, the rate of refusing to accept calls is: p = m/n The traffic load levels can be preset according to actual performance of the soft switch equipment. In general, p = 0, namely no calls need be refused. When the traffic load increases up to the status on which traffic load should be controlled, the value of p should be adjust to p > 0. If at this time the traffic load still increases continuously, p should be increased continuously. When p = 1, it is indicated that all calls (except emergency calls) are restricted, in this way the system could always run in a preset safe range. Then run the step of refusing to accept non-emergency calls (step 205). Thus, the service flow is ended and the system enters into a status of waiting message. In the present invention, the algorithm for controlling traffic load is worked out according to the process load of the soft switch itself and the load of related data bearer network. The process load of the soft switch itself can be obtained according to the following parameters: a rate of time occupied by CPU inside the soft switch system; a traffic of communication for each software module inside the soft switch system; a average time delay for access of database inside the soft switch system; a memory capacity occupied by the call processing inside the soft switch system, and the percentage of free memory; and « a process load percentage and message forwarding delay of communication process -ftequipment inside the soft switch system. The load of related data bearer network can be obtained according to the following parameters: a traffic percentage of each date port; a communication delay in each router; a communication jitter in each router; a communication packet lost rate in each router; and adjacent network traffic. The following principles should be included for controlling traffic load by the traffic load control algorithm: emergency calls (such as 110,119, 112) should be ensured unblocked; calls from important users and priority users (such as government departments, armed forces, and polices) should be ensured; calls from normal users are limited by a four level mode, in which call restraint rates are 50%, 75%, 87.5% and 100%; when traffic load is caused by a media stream (in a soft switch system, the soft switch solely completes call process, while the media stream switch is completed by data network), the soft switch system should shunt traffic of related date network though soft switch itself is not overloaded; and when traffic congestion is caused by a media stream, the coding mode of the media stream is controlled to reduce media traffic, for example, original G.711 coding mode providing voice quality is changed into G.732 or G.729 mode adopting high compression rate. All above description is only preferable embodiments of the present invention, which should not be seen as a limitation for the invention, and the scope of the invention claimed for protection shall not limited to these description. According to the technologies disclosed by the invention, any equivalent modifications and variances made by a person skilled in the art should fall into the scope claimed by the invention. We claim: 1. A method of controlling call load in soft switch system characterized by comprising: receiving a congestion indication message by a basic calling module ; deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration with the help of the basic calling module; and implementing control for starting call load by basic calling module according to the decision of the burst or duration type for the system congestion. 2. The method as claimed in claim 1, wherein the step of deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration is implemented by using timer Tl and T2. 3. The method as claimed in claim 2, wherein the timer Tl is a shorter duration timer, and the timer T2 is a longer duration timer. 4. The method as claimed in claim 2 or 3, wherein the step of receiving a congestion indication message in a basic calling module comprises the steps of: deciding whether or not it is first time for the basic calling module to receive a congestion indication message ; if yes, setting a traffic load status is as a lowest level of overload status, and initiating the timer Tl and T2 . 5. The method as claim 2 or 3, wherein the step of deciding whether the system congestion indicated by the congestion indication message is in a type of burst or duration, comprises the steps of: deciding whether the timer Tl and T2 is overtime or not; if the timer Tl is not overtime, implementing a normal call process in the basic calling module; |
---|
3352-delnp-2005-abstract-(06-06-2008).pdf
3352-delnp-2005-Abstract-30-05-2008.pdf
3352-delnp-2005-Claim-30-05-2008.pdf
3352-delnp-2005-claims-(06-06-2008).pdf
3352-delnp-2005-Correspondence(Others)-30-05-2008.pdf
3352-delnp-2005-correspondence-others-(06-06-2008).pdf
3352-delnp-2005-correspondence-others.pdf
3352-delnp-2005-description (complete).pdf
3352-delnp-2005-description(complete)-06-06-2008.pdf
3352-delnp-2005-description(Complete)-30-05-2008.pdf
3352-delnp-2005-Drawing-30-05-2008.pdf
3352-delnp-2005-Form-2-30-05-2008.pdf
Patent Number | 221058 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indian Patent Application Number | 3352/DELNP/2005 | ||||||||||||
PG Journal Number | 31/2008 | ||||||||||||
Publication Date | 01-Aug-2008 | ||||||||||||
Grant Date | 13-Jun-2008 | ||||||||||||
Date of Filing | 27-Jul-2005 | ||||||||||||
Name of Patentee | ZTE CORPORATION | ||||||||||||
Applicant Address | ZTE PLAZA, KEJI ROAD SOUTH, JI-TECH INDUSTRIAL PARK, NANSHAN DISTRICT, SHENZHEN CITY, GUANGDONG 518057, PR CHINA. | ||||||||||||
Inventors:
|
|||||||||||||
PCT International Classification Number | H04M 3/36 | ||||||||||||
PCT International Application Number | PCT/CN2003/001108 | ||||||||||||
PCT International Filing date | 2003-12-23 | ||||||||||||
PCT Conventions:
|