Title of Invention

A METHOD FOR CONTROLLING OVERLOAD OF MEDIA GATEWAY

Abstract

The present invention relates to N~ taco Protocol used between Media Gateway Controller (MGC) and Media Gateway (MG/MGW). Particularly this invention relates to intimate MGC about MG overloading. More particularly the present invention relates to a method and system for detecting/controlling overload of media gateway wherein when the load at an MGW is above Cutoff-Overload Value for Overload Duration time, MGW sends Notify to MGC and starts an Overload Timer.

Full Text

FIELD OF THE INVENTION The present invention relates to Megaco Protocol used between Media Gateway Controller (MGC) and Media Gateway (MG/MGW). Particularly this invention relates to intimate MGC about MG overloading. More particularly the present invention relates to a method and system for detecting/controlling overload of media gateway. DESCRIPTION OF RELATED ART MG overload: "MG Overload" means that the MG (or virtual MG) is close to being unable to respond to MGC transactions in a sufficiently timely manner to avoid the calling customer abandoning the call in set-up. Existing mechanism for overload control: Actions at overloaded MG (or virtual MG) An MG (or virtual MG) should be capable of detecting when it is in overload. Since different suppliers' switches are likely to have different architectures, the precise way MG Overload is detected is likely to be implementation-specific. Overload detection could, for example, be based on the use of processor occupancy thresholds, or queue thresholds or internal delay thresholds. An overloaded MG (or overloaded virtual MG) that receives an ADD command from an MGC shall: a) Continue normal processing of that transaction; and b) As soon as possible, notify the MGC that it is overloaded (by sending a Notify Request with event "MGOverload" to the MGC). Control initiation at an MGC Control at an MGC shall be activated (as quickly as possible) towards an MG when: a) the rate of MG_Overloads per second the MGC receives from the MG exceeds the TargetMG_Overload Rate ; and b) no control is currently activated from the MGC to the MG. When control is activated one of the leaky bucket algorithms defined in H.248.11 will be used to reduce the load. Termination of control at an MGC Control of load towards an MG (or virtual MG) shall be terminated at an MGC only when both a) the rate the MG sends MG_Overloads to the MGC; and b) the rate the MGC leaky bucket restrictor rejects calls to the MG have been zero for a sufficiently long period (the Termination Pending Period, measured in seconds) to indicate that the overload has abated. NOTE - This is essential to prevent the control repeatedly and rapidly ending and restarting (at its initial, potentially low, admitted rate) where an MG is only slightly overloaded. The following package is used for overload control. This package is defined in H.248.11. Overload Control Package Package Name: OCP PackagelD: ocp, 0x0051 Version: 1 Extends: None Properties None. Events MG_Overload Event name: MG_Overload EventID: mg_overload, (0x0001) Description: This event occurs only when the MG (or virtual MG) receives an ADD command from an MGC and the MG has determined it is overloaded. The event is ordered by the MGC or provisioned. Events Descriptor Parameters: None ObservedEvetsDescriptor Parameters: None Signals None. Statistics None. The related art works in the following manner: 1. When an overloaded MGW receives an AddRequest, it sends a Notify (Overload) message to MGC and continues normal processing of AddRequest. 2. When rate of Notify (Overload) received by MGC exceeds TargetMG_OverloadRate (defined as MGOverloads/second), MGC initiates Overload control mechanism. 3. For overload control, MGC uses one of the three leaky bucket algorithms defined inlTU-TH.248.11. 4. The overload control at MGC terminates when rate of Notify (Overload) and rate of call rejection by leaky bucket restrictor remains zero for sufficiently long period. The drawbacks in the existing art are following: 1. Normally 2 Add requests are used per call. When MGW is overloaded, it will have to send one notify for each Add Request which will increase the overhead on already overloaded MGW. 2. These notify will increase the network traffic between MGW and MGC which may congest the network. 3. MGC needs to process (decoding / counting notify frequency etc) these notify messages (2 notify per call) which will increase the load on MGC as well. SUMMARY OF THE INVENTION The purpose of new overload control mechanism is to minimize the overhead on MGW/MGC due to the existing overload control mechanism. In new overload control mechanism, when MGW is overloaded, it sends Notify (overload, %load) at a regular interval in contrast with the existing mechanism where MGW sends Notify (Overload) for every AddRequest received during Overload situation. The Notify message contains an additional parameter called % load which indicates the load at MGW. Accordingly the present invention relates to a method and system for controlling overload at Media Gateway (MG) by sending a self-initiated overload indication to Media Gateway Controller (MGC) with percentLoad parameter, indicating amount of load at MG. Accordingly the present invention relates to a method and system wherein said MGC can optionally use the load parameter sent by MGC to decide the call rejection rate. Accordingly the present invention further relates to a method and system for terminating overload control at Media Gateway Controller (MGC) by sending a self-initiated overload indication from Media Gateway (MG) with percentLoad parameter as zero. Accordingly the present invention relates to a method and system wherein said MGC uses overload termination indication sent by MG, to terminate overload control action initiated earlier. Accordingly the present invention relates to a method and system where a self-initiated overload notification received from MG is used for: a. MGC to initiate overload control actions. b. Reducing network traffic and congestion c. Reducing decoding overhead at MGC d. Reducing frequency of Notify(overloadEvent) at MG Accordingly, this invention explains a method for controlling overload of media gateway wherein when the load at an MGW is above Cutoff__Overload Value for OverloadDuration time, MGW sends Notify to MGC and starts an Overload Timer. When MGC receives the said notification, MGC initiates Overload control mechanism. In overload control mechanism, when MGW is overloaded, MGW sends Notify at a regular interval where the Notify message contains a parameter called % load which indicates the load at MGW. For overload control, MGC uses leaky bucket algorithms. MGC uses the value of %load parameter to decide the initial call rejection rate. When Overload Timer expires in MGW and if load is above Cutoff_OverloadValue, MGW sends another notify to MGC with current MGW load. MGC uses the current MGW load information to tune the call rejection rate. When MGW load remains below Cutoff_OverloadValue for sufficiently long time, MGW sends Notify to MGC with the value of %load parameter set to ZERO. When MGC receives Notify with %load value set to zero, and if call rejection rate is zero for sufficiently long period then MGC terminates overload control where else MGC waits for its call rejection rate to become zero and then MGC terminates the Overload Control. Accordingly, this invention further explains a system for controlling overload of media gateway wherein when the load at an MGW is above Cutoff_Overload Value for OverloadDuration time, MGW sends Notify to MGC and starts an Overload Timer. The other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 describes the messages exchanged between MGW and MGC for Overload Control according to H.248.11.lt also tells the trigger condition of those messages and a brief deschption of the actions taken when a message is received. Figure 2 describes the messages exchanged in the proposed mechanism. It also tells the trigger condition of those messages and a brief description of the actions taken when a message is received. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Figure 1 describes the messages exchanged between MGW and MGC for Overload Control according to H.248.11.lt also tells the trigger condition of those messages and a brief description of the actions taken when a message is received. Figure 2 describes the messages exchanged in the proposed mechanism. . It also tells the trigger condition of those messages and a brief description of the actions taken when a message is received. Proposed mechanism for overload control: Actions at overloaded MG (or virtual MG) An overloaded MG (or overloaded virtual MG) will periodically check its overload status. When MGW load is above Cutoff__OverloadValue (An operator configurable parameter) for sufficiently long time, MGW will: a) Send Notify Request to MGC. Notify will contain one additional parameter which contains the percent load at MGW. Control initiation at an MGC Control at an MGC shall be activated (as quickly as possible) towards an MG when: a) MGC receives NotifyRequest(MGW__Overload, %load); and b) no control is currently activated from the MGC to the MG. When control is activated one of the leaky bucket algorithms defined in H.248.11 will be used to reduce the load. MGC will use %load parameter to decide initial call rejection rate (e.g. if %load is very high then reject more calls). Termination of control at an MGC When an overloaded MGW becomes normal, it will send one more notification to MGC with percent load parameter value set to ZERO. The overloaded MGW must send this Notification only when its load is normal for a sufficiently long period. Control of load towards an MG (or virtual MG) shall be terminated at an MGC only when a) Last received Notify (Overload, %load) had value ZERO for %load parameter; and b) The rate the MGC leaky bucket restrictor rejects calls to the MG has been zero for a sufficiently long period (the TerminationPendingPeriod, measured in seconds). NOTE - This is essential to prevent the control repeatedly and rapidly ending and restarting (at its initial, potentially low, admitted rate) where an MG is only slightly overloaded. Following package can be used for proposed Overload control mechanism. Overload Control Package with overload level Package Name: MGOCP PackagelD: mgocp, OxOOAO Version: 1 Extends: None Properties None. Events MG_Overload Event name: MG_Overload EventID: mg^overioad, (0x0001) EventsDescriptor Parameters: None ObservedEvetsDescriptor Parameters: Parameter Name: percentLoad ParameterlD:percentLoad, (0x0001) Type: Integer Possible Values: 0-100 Signals None. Statistics None. The invention operates in the following steps: 1. When the load at an MGW is above Cutoff_OverloadValue for OverloadDuration (operator configurable value measured in seconds) time, MGW will send Notify (Overload, %load) to MGC and it will start one Overload Timer. 2. When MGC receives this notification, MGC initiates Overload control mechanism. 3. For overload control, MGC uses one of the three leaky bucket algorithms defined in ITU-T H.248.11 4. MGC uses the value of %load parameter to decide the initial call rejection rate. 5. When Overload Timer expires in MGW and its load is still above Cutoff_OverloadValue , it sends another notify to MGC with current MGW load. 6. MGC uses this new load information to tune the call rejection rate. 7. When MGW load remains below Cutoff_OverloadValue for sufficiently long time, MGW sends Notify to MGC with the value of %load parameter set to ZERO. 8. When MGC receives Notify with %load value set to zero, if call rejection rate is zero for sufficiently long period then it terminates overload control else it waits for its call rejection rate to become zero and then it terminates the Overload Control. The following are the advantages of the present invention: 1. In case of overload, number of notifies sent to MGC will be very less because MGW will not send Notify for each AddRequest. 2. MGC can use %load parameter to decide call rejection rate (If %load is very high then reject more calls). 3. Reduction in number of Notify (Overload) will reduce Notify (Overload) message parsing/processing overhead on MGC. 4. For a comparison between two mechanisms a. If MGW can support 500,000 BHCA (Busy hour call attempts) without getting overloaded. Then in overload condition it will be handling more than 500,000 calls per hour. b. Suppose during overload, MGC drops 30% of new calls then during overload new call rate will be 350,000 Calls per hour or 97 calls per second c. So in old mechanism, MGW will send 97*2 = 194 notify per second (2 AddReq per call so 2 Notify (Overload) per call). d. But if we use new mechanism, and the overload Timer value is 1 second then MGW will send 1 Notify (Overload) per second. e. Suppose it takes 5 min. (300 second) to come out of overload condition then new mechanism will send 300 Notify (Overload) in contrast with the previous mechanism which will send 194*300 = 58,200 messages. 5. The invention has potential to get into the standards. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom. GLOSSARY OF TERMS AND DEFINITIONS THEREOF Media Gateway (MG or MGW): The media gateway converts media provided in one type of network to the format required in another type of network. For example, a MG could terminate bearer channels from a switched circuit network (e.g. TDM) and media streams from a packet network (e.g. RTP streams in an IP network). Media Gateway Controller (MGC): Controls the parts of the call state that pertain to connection control for media channels in a MG. WE CLAIM 1. A method for controlling overload of media gateway wherein when the load at an MGW is above Cutoff_Overload Value for OverloadDuration time, MGW sends Notify to MGC and starts an Overload Timer. 2. A method as claimed in claim 1 wherein when MGC receives the said notification, MGC initiates Overload control mechanism. 3. A method as claimed in claim 1 wherein in overload control mechanism, when MGW is overloaded, MGW sends Notify at a regular interval where the Notify message contains a parameter called % load which indicates the load at MGW. 4. A method as claimed in claim 1 wherein for overload control, MGC uses leaky bucket algorithms. 5. A method as claimed in claim 1 wherein MGC uses the value of %load parameter to decide the initial call rejection rate. 6. A method as claimed in claim 1 wherein when Overload Timer expires in MGW and if load is above Cutoff_Overtoad Value, MGW sends another notify to MGC with current MGW load. 7. A method as claimed in claim 1 wherein MGC uses the current MGW load information to tune the call rejection rate. 8. A method as claimed in claim 1 wherein when MGW load remains below Cutoff_OverloadValue for sufficiently long time, MGW sends Notify to MGC with the value of 7oload parameter set to ZERO. 9. A method as claimed in claim 1 wherein when MGC receives Notify with %load value set to zero, and if call rejection rate is zero for sufficiently long period then MGC terminates overload control where else MGC waits for its call rejection rate to become zero and then MGC terminates the Overload Control. 10. A system for controlling overload of media gateway wherein when the load at an MGW is above Cutoff_Overload Value for OverloadDuration time, MGW sends Notify to MGC and starts an Overload Timer. 11. A system as claimed in claim 10 wherein when MGC receives the said notification, MGC initiates Overload control mechanism. 12. A system as claimed in claim 10 wherein in overload control mechanism, when MGW is overloaded, MGW sends Notify at a regular interval where the Notify message contains a parameter called % load which indicates the load at MGW. 13. A system as claimed in claim 10 wherein for overload control, MGC uses leaky bucket algorithms. 14. A system as claimed in claim 1 wherein MGC uses the value of %load parameter to decide the initial call rejection rate. 15. A system as claimed in claim 10 wherein when Overload Timer expires in MGW and if load is above Cutoff_OverloadValue, MGW sends another notify to MGC with current MGW load. 16. A system as claimed in claim 10 wherein MGC uses the current MGW load information to tune the call rejection rate. 17. A system as claimed in claim 10 wherein when MGW load remains below Cutoff_OverloadValue for sufficiently long time, MGW sends Notify to MGC with the value of %load parameter set to ZERO. 18. A system as claimed in claim 10 wherein when MGC receives Notify with %load value set to zero, and if call rejection rate is zero for sufficiently long period then MGC terminates overload control where else MGC waits for its call rejection rate to become zero and then MGC terminates the Overload Control. 19. A method for controlling overload of media gateway substantially described particularly with reference to the accompanying drawings. 20. A system for controlling overload of media gateway substantially described particularly with reference to the accompanying drawings.

Documents:

1463-CHE-2004 CORRESPONDENCE OTHERS 03-10-2013.pdf

1463-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 20-09-2013.pdf

1463-CHE-2004 FORM-13 19-06-2006.pdf

1463-CHE-2004 POWER OF ATTORNEY 03-10-2013.pdf

1463-CHE-2004 POWER OF ATTORNEY 20-09-2013.pdf

1463-CHE-2004 AMENDED CLAIMS 20-09-2013.pdf

1463-CHE-2004 AMENDED PAGES OF SPECIFICATION 20-09-2013.pdf

1463-CHE-2004 FORM-1 20-09-2013.pdf

1463-CHE-2004 FORM-13 20-09-2013.pdf

1463-CHE-2004 OTHER PATENT DOCUMENT 20-09-2013.pdf

1463-che-2004-abstract.pdf

1463-che-2004-claims.pdf

1463-che-2004-correspondnece-others.pdf

1463-che-2004-description(complete).pdf

1463-che-2004-description(provisional).pdf

1463-che-2004-drawings.pdf

1463-che-2004-form 1.pdf

1463-che-2004-form 13.pdf

1463-che-2004-form 26.pdf

1463-che-2004-form 5.pdf