HK1087271B - Method for media gateway monitoring the status of media gateway controller - Google Patents

Description

Method for realizing media gateway controller state monitoring by media gateway

Technical Field

The invention relates to the next generation network technology, in particular to a method for realizing the monitoring of the state of a media gateway controller by a media gateway.

Background

Media Gateway Controller (MGC) and Media Gateway (MG) are two key components in Next Generation Networks (NGN). The MGC is responsible for the call control function and the MG is responsible for the service bearer function, thereby implementing separation of the call control plane and the service bearer plane, thereby fully sharing network resources, simplifying equipment upgrade and service extension, and greatly reducing development and maintenance costs, as shown in fig. 1 below.

The media gateway control protocol is the main protocol for communication between MG and MGC, and there are two kinds of protocols, H.248/MeGaCo and MGCP, which are widely used at present. The MGCP protocol was developed by the IETF at 10 months 1999 and revised at 1 month 2003, and the H.248/MeGaCo protocol was developed by both the IETF and the ITU at 11 months 2000 and revised at 6 months 2003.

Taking the h.248 protocol as an example, various resources on the MG are abstractly represented as terminals (Termination). Terminals are further divided into physical terminals representing some physical entities with semi-permanent existence, such as Time Division Multiplexing (TDM) channels, and temporary terminals representing some common resources that are temporarily applied and released after use, such as real-time transport protocol (RTP) streams. The combination between terminals is abstractly represented as a Context (Context). A context may contain multiple terminals, and thus the interrelationship between the terminals is described in terms of Topology (Topology).

Based on this abstract model of the protocol, the continuation of a call is actually an operation of the terminal and the context. This is done by Command (Command) requests and responses between the MGC and MG. The parameters carried by a command, also called descriptors (descriptors), are classified into attributes (Property), signals (Signal), events (Event), statistics (statistical), and so on. Parameters with traffic dependencies are logically aggregated into packages (packages).

Because call control and traffic bearer are implemented on two separate components, namely, the MGC and the MG, which communicate with each other based on a packet network, such as NGN, it is very important that the MGC and the MG know whether the other side is operating normally or not. In particular, the MG is usually in a passive position as a controlled party, unlike the MGC that can actively query the MG controlled by the MGC in a flexible auditing manner, it is more desirable that the media gateway control protocol provides an effective means for monitoring the status of the MGC.

An Inactivity Timer (Inactivity Timer) packet defined in the h.248 protocol, an Inactivity Timeout (Inactivity Timeout) event of the packet, and a Maximum Inactivity time (Maximum Inactivity time) parameter of the event provide a means for the MG to monitor the MGC state. The mechanism is as follows:

the MGC sends an Inactivity Timeout event of an Inactivity Timer packet to a Root (Root) terminal on the MG representing the whole gateway, sets a Maximum Inactivity Time parameter of the event, and instructs the MG to start detecting whether the silence Time of a message from the MGC exceeds the parameter value. The MG detects all the incoming messages according to the information, and sends a notice message with an Inactivity Timeout event from the Root terminal to report to the MGC once the situation occurs. If the Notify message is not responded, the MG will consider the MGC as a failure and initiate an exception handling procedure, for example, register with the backup MGC.

In order for the MG to know that the state of the MG is normal, the MGC should ensure that a message interval to the MG does not exceed the set Maximum Inactivity Time parameter Value, and therefore, once no traffic control message needs to be sent during the period, the MGC needs to additionally send a message for similar testing or keeping activation, for example, an idle check Value (audio Value) message to a Root terminal on the MG.

The MG detects the MGC message quiet time in two ways: one way is to set a timer that is initially 0 and sets an upper Timeout limit, each message from the MGC will trigger the timer to reset to 0, and once the timer finally times out, the Inactivity Timeout event will be reported to the MGC. Another way is to set a message receiving flag with 0 initially and a normal timeout timer, each message from MGC will trigger the flag to be set to 1, once the timer times out and the flag is still 0, the inactivity timeout event will be reported to MGC, otherwise MG resets the flag to 0 and restarts the timer.

The above scheme has the following disadvantages:

1. the monitoring mechanism of the MGC state by the MG needs the MGC to send a corresponding packet, event and parameter before starting, if the MGC does not obtain the information because the packet is not realized, the packet is not configured to be sent, the sudden failure cannot reach the message sending, or the message sending is accidentally lost, and the like, the MG loses the effective mechanism for monitoring the MGC state.

2. The monitoring mechanism of the MG for the MGC state relies on the MGC to send a special message for non-service control to ensure that the message interval does not time out, which not only adds an extra burden to the MGC, but also adds an extra traffic to the network, however, in practice, it cannot be ensured that the MGC does not silence and time out, and the MG finally needs to make a judgment depending on whether the Notify message has a response or not.

In short, for the purpose that the MG wants to monitor the MGC status, whether the MG can achieve the goal depends on the cooperation and implementation of the MGC, in other words, depends on the status of the MGC, which are contradictory to each other.

Disclosure of Invention

The invention aims to provide a method for realizing the monitoring of the state of a media gateway controller by a media gateway, which aims to solve the problem that the monitoring is possibly invalid because the state of an MC monitoring MGC needs to depend on the cooperation of the MGC in the prior art.

In order to solve the above problems, the present invention provides the following technical solutions:

a media gateway monitors the implement method of the state of the media gateway controller, monitor the silent time of the controller message of the said media gateway through setting up the pause timer or ordinary timer and message receiving sign on the said media gateway, and send the notice message to the media gateway controller in order to trigger the media gateway controller to return the message to prove its state is normal when the silent time is out; and after the media gateway registers to the media gateway controller, starting the rest timer or the common timer to start monitoring the state of the media gateway controller according to the returned registration success message.

The initial value of the timeout duration of the inactivity timer or the common timer is a configurable default value.

When the media gateway receives the message containing the maximum rest time from the media gateway controller, the timeout duration of the rest timer or the common timer is reset according to the maximum rest time. Specifically, the timeout period of the inactivity timer may be set to the maximum inactivity time, or the timeout period of the ordinary timer may be set to one-half of the maximum inactivity time.

If a pause timer is arranged on the media gateway to monitor the media gateway controller, when the number of continuous overtime times of the pause timer reaches a preset threshold value, the media gateway starts an abnormal processing flow; if the media gateway is set with a common timer and a message receiving mark monitoring media gateway controller, when the common timer is overtime and the message receiving mark still shows that the continuous occurrence frequency of the unreceived message reaches a preset threshold value, the media gateway starts an abnormal processing flow.

If a pause timer is arranged on the media gateway to monitor the media gateway controller, a pause counter is adopted to count the continuous overtime times of the pause timer, and the pause counter is reset when the media gateway receives any message of the media gateway controller; if a common timer and a message receiving mark are set on the media gateway to monitor the media gateway controller, a stop counter is adopted to count the continuous occurrence times of the overtime common timer and the message receiving mark still showing that no message is received, and the stop counter is reset when the media gateway receives any message of the media gateway controller.

The invention has the following beneficial effects:

1. the invention starts the monitoring and testing mechanism after the MG successfully registers to the MGC, and does not need to wait for the MGC to send corresponding packets, events and parameters before starting, therefore, the monitoring of the MGC by the MG does not depend on the state of the MGC any more, and the problem of failure of the monitoring mechanism caused by abnormal MGC is avoided.

2. The invention makes MGC not need to send other similar test or keep activated message when there is no service control message to send, thus reducing the burden of MGC and network. Even if the MGC itself wants to monitor the state of the MG by sending messages like null-poll values, its control of the sending timing is not necessarily limited to the above-mentioned maximum off-time parameter.

Drawings

Fig. 1 is a schematic diagram of MG and MGC networking in an NGN;

fig. 2 is a schematic diagram of MG monitoring MGC status.

Detailed Description

In the NGN, call control and traffic bearer are implemented on separate components of the MGC and MG, respectively, and the MGC and MG communicate with each other based on a NGN packetized network, so it is very important that the MGC and MG know whether the other side operates normally or not. The invention provides a simple and reliable method for the MG to know the operation state of the MGC from the application layer in real time by enhancing the processing mechanism of the corresponding packet, event and parameter in the H.248 protocol.

Example one

A pause Timer (Inactivity Timer) is autonomously deployed on the MG, and the timeout duration of the Inactivity Timer is preset to be a configurable default value. The rest timer is different from the ordinary timer in that: the rest timer can be reset at any time and automatically restarts timing, and the ordinary timer can not be reset at any time and can reach timeout all the time. Both the inactivity timer and the ordinary timer need to be reset after the timeout to restart the timing.

When the MG successfully registers to the MGC, namely the MGC becomes a main control MGC, the MG actively starts a resting timer according to the returned successful registration message and starts to monitor the state of the MGC. When the MG receives any message from the main control MGC, whether the message is a request message or a response message, the MG is triggered to reset the inactivity timer, and the inactivity timer automatically restarts the timing.

Every time the inactivity timer times out, the MG sends a notification (notify) message with an inactivity timeout (inactivity timeout) event from a Root terminal to the MGC, and resets the inactivity timer. Since this is not an event that the MGC requested MG detection in advance, the event identification (EventID) of the event is 0.

If the message from the main control MGC includes an Inactivity Timeout (Inactivity Time out) event of an Inactivity Timer (Inactivity Timer) packet issued to a Root terminal on the MG and a Maximum Inactivity Time (Maximum Inactivity Time) parameter of the event is set, the MG records the Inactivity Time out event and an event identifier thereof on the Root terminal and sets the Timeout duration of the Inactivity Timer as a Maximum Inactivity Time parameter value. And when the MG sends a Notify message with an Inactivity Timeout event from the Root terminal to the MGC to report the event identifier of the event to the MGC every time the Inactivity timer times out, the event identifier of the event is the event identifier requested to be detected by the MGC and is not 0 any more.

The Notify message with the Inactivity Timeout event from the MG to the MGC, similar to a heartbeat trigger, will prompt the MGC to return a response as a heartbeat reflection, which, like any other message from the MGC, can be used as a flag that the MGC is in a normal state and trigger the MG to reset the Inactivity timer. However, after the Notify message is sent out, before the inactivity timer times out again, if the MG has not been able to get any message from the MGC, including a response to the Notify message, the MG may consider the MGC as a failure and initiate an exception handling procedure, such as initiating a registration with a backup MGC.

In order to avoid erroneous judgment due to a transient condition like network "flash", an Inactivity Counter (Inactivity Counter) with an initial value of 0 is additionally arranged on the MG (the principle of the Inactivity Counter is the same as that of the Inactivity timer), and the number of times of timeout of the Inactivity timer is counted. When the inactivity timer times out, the count of the inactivity counter is increased by 1; the Inactivity counter is reset to 0 each time the MG gets any message from the MGC, including a response to a Notify message with an Inactivity Timeout event. Once the current value of the inactivity counter, that is, the number of times that the inactivity timer continuously times out, exceeds a preset threshold, it may be determined that the state of the MGC is abnormal, and the MG starts an abnormal processing procedure.

Referring to fig. 2, the MG monitors the MGC as follows:

1. after receiving the registration success message returned by the MGC, the MG starts a rest timer and a rest counter, the timeout duration of the rest timer is set as a default value A, and the initial value of the rest counter is set as 0.

2. The MG resets the inactivity timer and inactivity counter upon receiving any request or reply message sent by the MGC.

3. The inactivity timer times out and sends a notification message containing an inactivity timeout event to the MGC, the event is identified as 0 and the inactivity counter is incremented by 1.

4. And the MG resets the rest timer and the rest counter after receiving the response message of the MGC.

5. After receiving a request message which is sent by the MGC and contains a rest timer packet, a rest timeout event and a maximum rest time parameter value B, the MG sets the timeout duration of the rest timer as the maximum rest time B, resets the rest timer and the rest counter, and records an event identifier X of the rest timeout event. .

6. The MG returns a response message to the MGC.

7. The MG resets the inactivity timer and inactivity counter upon receiving any request or reply message sent by the MGC.

8. The inactivity timer times out and sends a notification message containing an inactivity timeout event to the MGC, the event is identified as X, and the inactivity counter is incremented by 1.

9. The MG resets the inactivity timer and inactivity counter upon receiving any request or reply message sent by the MGC.

10. The MG sends a notification message containing a pause timeout event to the MGC, the event is marked as X, and the pause counter is added with 1.

11. The MG sends a notification message containing a pause timeout event to the MGC, wherein the event is marked as X, and the pause counter is added with 1, and the counting value is 2 at the moment.

12. The current value of the rest counter reaches a preset threshold value n, which indicates that the rest timer has been overtime continuously for n times, and the notification messages continuously sent to the MGC by the MG before do not receive any message from the MGC, so that the MG confirms the MGC failure and starts an abnormal processing flow, for example, initiates a service change.

Example two

An initial 0 message receiving mark and a common timeout timer with a preset default value are autonomously deployed at the MG to detect the silent time of the MGC message. When the MG successfully registers to the MGC, namely the MGC becomes a main control MGC, the MG actively starts a resting timer to start timing according to the returned successful registration message, and starts to monitor the state of the MGC.

The flag is set to 1 every time the MG obtains a message from the MGC, once the timer times out and the flag is still 0, the MG reports an Inactivity Timeout event to the MGC, otherwise, the MG resets the flag to 0 and restarts the timer.

If the message from the main control MGC includes an Inactivity Timeout (Inactivity Time out) event of an Inactivity Timer (Inactivity Timer) packet issued to a Root terminal on the MG and a Maximum Inactivity Time (Maximum Inactivity Time) parameter of the event is set, the MG records the Inactivity Time out event and an event identifier thereof on the Root terminal and sets the Timeout duration of the Timer to be one half of a Maximum Inactivity Time parameter value.

In order to avoid erroneous judgment due to a transient condition like network "flash", an Inactivity Counter (Inactivity Counter) with an initial value of 0 is additionally deployed on the MG (the principle of the Inactivity Counter is the same as that in the first embodiment), the number of times that the ordinary timer times out and the message receiving flag still shows that no received message appears continuously is counted, and once the current value of the Inactivity Counter exceeds a certain preset threshold, it can be determined that the state of the MGC is abnormal, and the MG starts an abnormal processing flow. Other operations and

the embodiments are similar.

Claims (8)

1. A media gateway monitors the implement method of the state of the media gateway controller, monitor the silent time of the controller message of the said media gateway through setting up the pause timer or ordinary timer and message receiving sign on the said media gateway, and send the notice message to the media gateway controller in order to trigger the media gateway controller to return the message to prove its state is normal when the silent time is out; the method is characterized in that the media gateway registers to a media gateway controller, and the media gateway starts the resting timer or the common timer to start monitoring the state of the media gateway controller according to the returned registration success message.

2. The method of claim 1, wherein an initial value of a timeout period of the inactivity timer or the ordinary timer is a configurable default value.

3. A method as claimed in claim 1 or 2, wherein when the media gateway receives a message containing a maximum inactivity time from the media gateway controller, the timeout duration of the inactivity timer or the ordinary timer is reset according to the maximum inactivity time.

4. A method as claimed in claim 3, characterized by setting the timeout period of the inactivity timer to the maximum inactivity time or the timeout period of the ordinary timer to half the maximum inactivity time.

5. The method as claimed in claim 3, wherein if a inactivity timer is set on the media gateway to monitor the media gateway controller, the media gateway initiates an exception handling procedure when the number of consecutive timeout times of the inactivity timer reaches a predetermined threshold.

6. The method of claim 5, wherein a inactivity counter is used to count the number of consecutive timeouts of the inactivity timer and is reset when the media gateway receives any message from the media gateway controller.

7. The method as claimed in claim 3, wherein if the media gateway is provided with a normal timer and a message reception flag to monitor the media gateway controller, the media gateway starts an exception handling procedure when the normal timer expires and the message reception flag indicates that the number of times of continuous occurrence of the unreceived message reaches a predetermined threshold.

8. The method of claim 7 wherein a inactivity counter is used to count the number of consecutive occurrences that the normal timer has timed out while the message receipt indicator still indicates that no messages have been received, and the inactivity counter is reset when the media gateway receives any message from the media gateway controller.