JP5316318B2 - Congestion detection device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To accurately grasp a congestion state of a SIP server. <P>SOLUTION: An apparatus for detecting the congestion state of the SIP server which is to be monitored includes a means for measuring the number of cases per unit time of Initial INVITE telegrams to be inputted into the SIP server, a means for measuring internal processing time relating to the Initial INVITE telegrams of the SIP server, a means for measuring the number of cases per unit time in which timing is shifted back by the internal processing time of the Initial INVITE telegrams outputted by the SIP server, and a means for determining the presence or absence of the congestion state by comparing the number of cases of measured input telegrams with the number of cases of output telegrams. <P>COPYRIGHT: (C)2011,JPO&amp;INPIT

Description

  The present invention relates to a technique for detecting congestion of a SIP (Session Initiation Protocol) server.

  Telephone congestion in a conventional PSTN (Public Switched Telephone Networks) network has occurred in the transmission line. This is because the transmission path is insufficient when the number of calls increases because the transmission path is secured first even when the other party is speaking.

  However, in an NGN (Next Generation Network) network based on IP (Internet Protocol) communication, no congestion occurs on the transmission path. In other words, the voice bandwidth is not secured until the telephone is connected, and only the SIP control packet flows on the transmission path, which is smaller than the voice data packet. Instead, because there is room in the transmission path for the SIP server that processes SIP control packets, a large amount of SIP control packets arrive at once, and the processing is not in time, and the SIP server is congested. Will occur.

  FIG. 1 is a diagram showing a configuration example of a conventional system.

  In FIG. 1, a plurality of SIP servers 2A to 2D and a plurality of edge routers 3A to 3C are provided in the NGN network 1, and a plurality of telephones 4A to 4F are connected to the edge routers 3A to 3C.

  Assume that a call is generated from the telephone 4A → the edge router 3A → the SIP server 2A, the telephone 4B → the edge router 3A → the SIP server 2A, and the destination is under the SIP server 2B. Similarly, it is assumed that a call is generated from the telephone 4D → the edge router 3B → the SIP server 2C, and the destination is under the SIP server 2B. Similarly, it is assumed that a call is generated from the telephone 4E → the edge router 3C → the SIP server 2D and the telephone 4F → the edge router 3C → the SIP server 2D, and the destination is under the SIP server 2B. In this case, the load on the SIP server 2B becomes high, and a delay occurs in the connection processing to the telephones 4C and 4D via the edge router 3B. Congestion of telephones has a tendency that such a state is likely to occur because calls are concentrated in a specific area or a specific telephone number.

  Further, unlike a conventional exchange, the SIP server realizes a function with software logic instead of hardware logic. For this reason, it is assumed that not only an increase in calls to a specific area that is normally assumed, but also a decrease in capability due to various causes such as a setting error and a program error.

  The processing capacity of the SIP server employed in NGN is one tenth of the limit load due to wire speed. This is because the voice data occupies most of the data, and the amount of control packets to be processed by the SIP server is relatively small.

  For this reason, if requests concentrate on one specific SIP server from a plurality of SIP servers, there is a margin in wire speed, and a load of several tens of times that can be processed is applied. In that case, the SIP server cannot read the request and cannot correctly grasp the load.

Hereinafter, an example of calculating the amount of data when a load occurs will be described. As an example, the traffic volume at the time of performance limit occurrence of a SIP server with the performance of 1 million BHCA (Busy Hour / Interval Call Attempts: total number of line calls in the busy hour) is as follows become that way.
-SIP server capacity: 1 million BHCA-> 1,000,000 calls / Hr-> 278 calls / second-Number of SIP messages per call: 23-Length per message: 500 bytes-Data transmission capacity at maximum capacity : 278 × 23 × 500 → 3M bytes / second

In contrast, the maximum number of SIP packets transferred on a 1 Gbps network is as follows.
・ Wire speed: 1 Gbps → 125 Mbytes / second ・ Number of SIP messages per call: 23 ・ Length per message: 500 bytes ・ Total amount of SIP packets at wire speed: 125 M ÷ (23 * 500) / second → 10869 calls / second

  Therefore, when requests are concentrated, a load 40 times (10869/278) the performance of the SIP server may be applied.

  A SIP server is generally provided with a function for rejecting a session exceeding a predetermined number. However, even if an Initial INVITE is rejected due to an excessive number of sessions, the SIP server performs a normal Initial INVITE opening process. Since the message analysis process is performed in the same manner as described above, it becomes a load on the SIP server. This is because the re INVITE for continuing the call arrives in the same format as the Initial INVITE, and it is necessary to perform the message analysis process without distinction.

  Therefore, the number of initial INVITE SIP messages rejected when the number of sessions exceeds is eventually increased, and the SIP messages of connected sessions are not processed, resulting in a congestion state in which all sessions are not established.

  Therefore, it is necessary to quickly detect that congestion is occurring and notify other SIP servers to suppress connection requests to the SIP servers that are congested.

  As a conventional method for detecting congestion of the SIP server, it is common to provide a monitoring function in the SIP server, and when the number of calls is counted to exceed a predetermined number, it is determined that the congestion is present.

  Patent Documents 1 to 3 disclose other techniques related to prevention of congestion in the SIP server.

JP 2008-244970 A JP 2007-267151 A JP 2008-92116 A

As described above, conventionally, various measures have been taken to detect congestion of the SIP server, but the following problems have been pointed out.
(1) The congestion state due to overload of the SIP server itself cannot be monitored normally. That is, when the SIP server itself has a monitoring function for congestion due to overloading of the SIP server and receives the report, the congestion monitoring cannot be performed normally because the SIP server itself is overloaded. Can't work.
(2) An accurate load state cannot be grasped only by counting the number of calls. In other words, unlike conventional switches, the SIP server is implemented with software logic instead of hardware logic, so not only increases in calls to specific areas that are normally assumed, but also misconfigurations, program errors, etc. It is assumed that capacity reduction due to various causes of the problem becomes a problem. Therefore, it is difficult to detect the performance degradation of the SIP server only by counting the number of Initial INVITEs per unit time and comparing it with the maximum processable number of fixed values. There is a need for a mechanism for detecting a delay in call processing by a method that can cope with changes in the processing capacity of the SIP server.

  In view of the above-described conventional problems, an object is to provide a congestion detection apparatus capable of accurately grasping a congestion state in a SIP server.

  In one embodiment of the congestion detection apparatus, the apparatus detects a congestion state of a monitored SIP server, and measures the number of initial INVITE messages input to the SIP server per unit time, and the SIP server Means for measuring the internal processing time for the initial INVITE message, means for measuring the number of cases per unit time of the initial INVITE message output by the SIP server, with the timing shifted backward by the internal processing time, and the measured input Means for determining whether or not a congestion state exists by comparing the number of messages and the number of output messages.

  In the disclosed congestion detection device, the number of initial INVITE messages input to the SIP server per unit time and the initial INVITE message output from the SIP server per unit time with the timing shifted backward by the internal processing time. Since congestion is determined using the number of cases, the congestion status can be accurately grasped.

It is a figure which shows the structural example of the system in the past. It is a figure which shows the structural example of the system concerning one Embodiment. It is a figure which shows the time relationship of the request reception of Initial INVITE in a SIP server, and HOP transmission of Initial INVITE. It is a figure which shows the example of the change of the number of Initial INVITE request receptions and the number of Initial INVITE HOP transmissions by the load of a SIP server. It is a figure which shows the relationship between retention of Initial INVITE in a TCP buffer, and SIP server processing time. It is a figure which shows the internal structural example of a congestion detection apparatus. It is a flowchart which shows the process example of a message | telegram analysis / extraction part. It is a flowchart which shows the process example of an INVITE [input] total part. It is a flowchart which shows the process example of an INVITE [output] total part. It is a flowchart which shows the process example of a residence time calculation part. It is a flowchart which shows the process example of a congestion detection part.

  Hereinafter, preferred embodiments of the present invention will be described.

<Configuration>
FIG. 2 is a diagram illustrating a configuration example of a system according to an embodiment.

  In FIG. 2, the NGN network 1 includes a plurality of SIP servers 2A to 2D and a plurality of edge routers 3A to 3C, and a plurality of telephones 4A to 4F are connected to the edge routers 3A to 3C. Further, a SPAN tap 5A is provided between the SIP server 2A and the edge router 3A, a SPAN tap 5B is provided between the SIP server 2B and the edge router 3B, and a SPAN tap 5C is provided between the SIP server 2C and the edge router 3B. A SPAN tap 5D is provided between the SIP server 2D and the edge router 3C. And the congestion detection apparatus 6 which makes the SIP server 2B monitoring object is connected to the SPAN tap 5B.

  FIG. 3 is a diagram showing a temporal relationship between the initial INVITE request reception and the initial INVITE HOP transmission in the SIP server 2 (2A to 2D).

  When the SIP server 2 of interest receives an Initial INVITE from another SIP server, the initial INVITE HOP is transmitted to the other SIP server 2 as a processing result. Initial INVITE request reception and Initial INVITE HOP transmission can be monitored by copying and taking out IP packets entering and leaving the SIP server 2 by the SPAN tap 5.

  The initial INVITE received by the SIP server 2 is INVITE [input], the initial INVITE transmitted from the SIP server 2 is HOP transmitted, and the number of each is counted and measured.

  When the SIP server 2 is not congested, the number of INVITE [input] counted for a certain period is equal to the number of INVITE [out] counted for a certain period after the internal processing time.

  FIG. 4 is a diagram showing an example of changes in the number of received Initial INVITE requests and the number of Initial INVITE HOP transmissions due to the load on the SIP server.

  In SIP server 2, the number of INVITE [input] per unit time t (number of requests) is n, and the number of INVITE [out] per unit time t after t 'is the internal processing time in SIP server 2 (number of HOPs) ) Is m.

  In this case, when the SIP server 2 is not overloaded and not congested, as shown in FIG. 4A, the request number n is the same as the HOP number m after the internal processing time t ′. That is, the values of n and m are equal while the processing is not delayed.

  On the other hand, when the SIP server 2 becomes congested due to overload processing, the number m of HOPs after the internal processing time t ′ becomes smaller than the number n of requests as shown in FIG. That is, when the process is delayed, n> m.

  In this way, when the number of INVITE [on] per unit time is compared with the number of INVITE [on] per unit time shifted by the internal processing time of the SIP server 2, It can be determined that a processing delay has occurred.

  If INVITE [ON] and INVITE [OUT], which is the processing result of INVITE [ON], can be associated with each other, the internal processing time t ′ can be measured from the difference in acquisition time, and the above-described congestion determination can be performed. Can be used. However, in the case of a B2BUA type SIP server that is widely used, input / output Initial INVITE cannot be associated. That is, since a call ID different from the input Initial INVITE is attached to the output Initial INVITE, the two cannot be associated with each other. Therefore, a device is required to measure the internal processing time t ′. Hereinafter, a method for measuring the internal processing time will be described.

  FIG. 5 is a diagram showing the relationship between the retention of Initial INVITE in the TCP buffer and the SIP server processing time.

  As shown in FIG. 5A, the Initial INVITE input to the SIP server 2 is stored in the TCP buffer, and then extracted from the head and processed.

  In this case, as shown in FIG. 5 (b), after receiving the Initial INVITE, the SIP server 2 immediately responds with 100 Trying after a dwell time t2 ′ in the TCP buffer, and thereafter the pure processing time. An initial INVITE is sent to another opposing SIP server via t1 ′. Therefore, the internal processing time t ′ is the sum of the residence time t2 ′ and the pure processing time t1 ′.

  Here, even in the B2BUA type that is generally popular as a SIP server, since the same call ID is attached to 100 Trying that is replied to the received Initial INVITE, the residence time t2 ′ can be measured. Normally, the 100Trying response is responded immediately after receiving the Initial INVITE. Therefore, the residence time t2 ′ is a small value in a non-congested state. However, when the load on the SIP server 2 increases, a large residence time occurs from the reception of the Initial INVITE (registration to the TCP buffer queue) to the 100 Trying response, and the residence time t2 ′ increases. The pure processing time t1 ′ is a substantially fixed time determined by the specifications of the SIP server 2.

  Therefore, an accurate internal processing time t ′ can be obtained by adding the residence time t2 ′ and the pure processing time t1 ′. Note that the pure processing time t1 ′ is a small value (eg, 2 to 3 ms) and is negligible compared to the residence time t2 ′ (eg, several seconds) when congestion occurs, so the internal processing time t ′ is The residence time may be regarded as t2 ′.

  FIG. 6 is a diagram illustrating an internal configuration example of the congestion detection apparatus 6.

  6, the congestion detection device 6 includes a capture unit 61, a message analysis / extraction unit 62, an INVITE [input] totaling unit 63, an INVITE [out] totaling unit 64, a residence time calculation unit 65, a congestion detection unit 66, and a congestion control. Part 67.

  The capture unit 61 has a function of acquiring data from the data copied by the SPAN tap 5.

  The message analysis / extraction unit 62 has a function of analyzing and extracting a message from the data acquired by the capture unit 61. The message analysis / extraction unit 62 outputs the INVITE [ON] notification with the occurrence time to the INVITE [ON] counting unit 63 as the measurement target data # 1. In addition, a notification of INVITE [output] with the occurrence time is output to the INVITE [output] totaling unit 64 as the measurement target data # 2. In addition, as measurement target data # 3, notifications of INVITE [input] and 100 Trying [output] with the occurrence time are output to the INVITE [output] counting unit 64.

  The INVITE [input] counting unit 63 has a function of receiving the notification of the occurrence of INVITE [input] from the message analysis / extraction unit 62 and counting the number of INVITE [input] per unit time.

  The INVITE [output] counting unit 64 has a function of receiving the notification of occurrence of INVITE [output] from the message analysis / extraction unit 62 and counting the number of INVITE [output] per unit time.

  The residence time calculation unit 65 receives notification of occurrence of INVITE [on] and 100 Trying [out] from the message analysis / extraction unit 62, and calculates the residence time from the time difference between INVITE [on] and the corresponding 100 Trying [out]. It has a function to do.

  The congestion detection unit 66 includes the number of INVITE [input] per unit time counted by the INVITE [input] totaling unit 63, the number of INVITE [out] per unit time calculated by the INVITE [out] totaling unit 64, Based on the residence time calculated by the residence time calculation unit 65, it has a function of determining whether or not congestion occurs in the monitored SIP server.

  The congestion control unit 67 has a function of notifying the SIP server in which congestion has occurred and peripheral SIP servers to take measures such as suppressing connection requests.

<Operation>
FIG. 7 is a flowchart showing a processing example of the message analysis / extraction unit 62.

  In FIG. 7, the message analysis / extraction unit 62 performs Ether-level packet analysis as L2 (Layer 2) analysis on the capture data input from the capture unit 61, and extracts only IP packets (step S21).

  Next, the message analysis / extraction unit 62 performs IP level packet analysis as L3 (Layer 3) analysis, and extracts packets that enter and exit the monitored SIP server (step S22).

  Next, the message analysis / extraction unit 62 performs TCP / UDP level packet analysis as L4 (Layer 4) analysis, and assembles SIP transmission / reception data (step S23).

  Then, the message analysis / extraction unit 62 performs SIP procedure level message analysis as SIP message analysis, extracts INVITE [IN], INVITE [OUT], and 100 Trying [OUT] messages to be analyzed. (Step S24). That is, the occurrence of INVITE [input] is notified to the INVITE [input] totaling unit 63 and the residence time calculation unit 65, the occurrence of INVITE [out] is notified to the INVITE [out] totalization unit 64, and the occurrence of 100 Trying [out] is determined as the residence time. The calculation unit 65 is notified.

  FIG. 8 is a flowchart showing a processing example of the INVITE [input] totaling unit 63.

  In FIG. 8, when receiving the notification of occurrence of INVITE [ON] from the message analysis / extraction unit 62, the INVITE [ON] counting unit 63 counts the number of INVITE [ON] per unit time as INVITE [ON] counting. (Step S31).

  That is, if the current occurrence time is the same total unit time as the previous occurrence time, the number counter is counted up.

Also, if the current occurrence time is not the same total unit time as the previous occurrence time,
・ When the number of records is exceeded, purge the oldest record data, count the total number and record the number counter, and set 1 to the number counter.

  On the other hand, when the congestion detection unit 66 specifies the reference start / end time and the number of INVITE [ON] requests per unit time is requested, the INVITE [ON] counting unit 63 uses the specified time as the INVITE [ON] reference. The number of INVITE [input] is referred to, and the number of INVITE [input] generated between the reference start time and end time is summarized and responded (step S32).

  FIG. 9 is a flowchart showing a processing example of the INVITE [output] totaling unit 64.

  In FIG. 9, when receiving the notification of occurrence of INVITE from the message analysis / extraction unit 62, the INVITE [out] totaling unit 64 totals the number of INVITE [out] per unit time as INVITE [out] totaling. (Step S41).

  That is, if the current occurrence time is the same total unit time as the previous occurrence time, the number counter is counted up.

Also, if the current occurrence time is not the same total unit time as the previous occurrence time,
・ When the number of records is exceeded, purge the oldest record data, count the total number and record the number counter, and set 1 to the number counter.

  On the other hand, when the reference start / end time is specified from the congestion detection unit 66 and the number of INVITE [out] cases per unit time is requested, the INVITE [out] totaling unit 64 uses the specified time as the INVITE [out] reference. The number of INVITE [out] is referred to, and the number of INVITE [out] generated between the reference start time and end time is summarized and responded (step S42).

  FIG. 10 is a flowchart illustrating a processing example of the residence time calculation unit 65.

  In FIG. 10, when the residence time calculation unit 65 receives notification of the occurrence of INVITE [ON] and 100 Trying [OUT] from the message analysis / extraction unit 62, INVITE [ON] and the corresponding 100 Trying [ The time difference is measured (step S51).

That is, if the status is not measured and INVITE is received,
・ Records the occurrence time of INVITE [ON] and call ID ・ Changes the status during measurement ・ Records the INVITE [ON] occurrence time + timeout time as the timeout time

Also, if you receive 100 Trying [Out] with a call ID that is the same value as the call ID that is being recorded and recorded,
・ Record the occurrence time of 100 Trying [Out] as the residence calculation time and record the difference between the occurrence time of INVITE [On] and 100 Trying [Out] as the residence time (only the latest one)
・ Purge INVITE occurrence time and call ID ・ Change status to unmeasured.

In addition, when the occurrence time of the message received during measurement exceeds the timeout time,
・ Purge INVITE occurrence time and call ID ・ Change status to unmeasured.

  In other cases, the notification is discarded (does nothing).

  On the other hand, when the reference is made from the congestion detection unit 66, the residence time calculation unit 65 refers to the latest measured residence time and the measurement time as the residence time reference, and records the residence time and the measurement time. Respond.

  FIG. 11 is a flowchart illustrating a processing example of the congestion detection unit 66.

  In FIG. 11, the congestion detection unit 66 starts processing periodically by an interval timer.

  That is, as acquisition of the residence time, the latest residence time and its measurement time are referred to (step S61). That is, the latest residence time and its measurement time are acquired using the residence time calculation unit 65.

  Next, as a measurement time update confirmation, it is confirmed whether the measurement time is different from the previous time (step S62). That is, when the measurement time is the same as the stored measurement time, the process ends. If the measurement time is different from the saved measurement time, the current measurement time is set as the saved measurement time and the process is continued.

  Next, as the INVITE [out] acquisition, the number of INVITE [out] cases for the specified time is referred to (step S63). That is, the INVITE [out] totaling unit 64 is used to obtain the number of INVITE [out] that occurred during the period, with the reference start as the measurement time and the end as the measurement time + measurement period.

  Next, as the INVITE [input] acquisition, the number of INVITE [input] for the specified time is referred to (step S64). That is, the INVITE [input] totaling unit 63 is used to obtain the number of INVITE [input] that occurred in the meantime with the reference start as measurement time-dwell time and the end as measurement time + measurement period-dwell time.

  Next, as congestion determination, congestion is determined by comparing the number of INVITE [out] and the number of INVITE [in] (step S65). That is, if INVITE [in] number / INVITE [out] number <congestion threshold, the process ends. In cases other than the above, the congestion control unit 67 is notified together with the IP address of the SIP server in which congestion occurs, using the INVITE [input] number / INVITE [out] number as the congestion coefficient.

  The congestion control unit 67 notifies the SIP server in which congestion has occurred and neighboring SIP servers, and takes measures such as suppressing connection requests to the SIP server in congestion.

<Summary>
As described above, according to the present embodiment, there are the following advantages.
(1) Judgment of congestion using the number of Initial INVITEs input to the SIP server per unit time and the number of Initial INVITEs output from the SIP server per unit time shifted in timing by the internal processing time Therefore, the congestion situation can be accurately grasped.
(2) Since the measurement is performed by a device different from the SIP server to be monitored, the congestion situation can be accurately grasped even if the SIP server is overloaded.
(3) It is not necessary to set a threshold for the number of initial INVITEs for each SIP server to be monitored, and since the number of input / output cases for the initial INVITE can be directly measured and determined, operations such as threshold setting for each device become unnecessary.

The present invention has been described above by the preferred embodiments of the present invention. While the invention has been described with reference to specific embodiments, various modifications and changes may be made to the embodiments without departing from the broad spirit and scope of the invention as defined in the claims. Obviously you can. In other words, the present invention should not be construed as being limited by the details of the specific examples and the accompanying drawings.
(Appendix 1)
An apparatus for detecting a congestion state of a SIP server to be monitored,
Means for measuring the number of Initial INVITE messages input to the SIP server per unit time;
Means for measuring the internal processing time for the Initial INVITE message of the SIP server;
Means for measuring the number per unit time of the Initial INVITE message output by the SIP server, the timing being shifted backward by the internal processing time;
A congestion detection apparatus comprising: means for determining whether or not a congestion state occurs by comparing the measured number of input messages and the number of output messages.
(Appendix 2)
In the congestion detection device according to attachment 1,
The congestion detection apparatus, wherein the internal processing time is measured based on a difference between an input time of an Initial INVITE message input to the SIP server and an output time of a 100 Trying response output from the SIP server.
(Appendix 3)
In the congestion detection apparatus according to any one of Appendix 1 or 2,
A congestion detection apparatus, wherein a message to be input / output to / from the SIP server is acquired from a SPAN tap inserted between the SIP server and an edge router.
(Appendix 4)
A method for detecting a congestion state of a SIP server to be monitored,
A step of measuring the number of Initial INVITE messages input to the SIP server per unit time;
Measuring internal processing time for the Initial INVITE message of the SIP server;
A step of measuring the number of cases per unit time of the Initial INVITE message output by the SIP server with the timing shifted backward by the internal processing time;
A congestion detection method comprising: a step of determining whether or not a congestion state occurs by comparing the measured number of input messages and the number of output messages.
(Appendix 5)
In the congestion detection method according to attachment 4,
A congestion detection method, comprising: measuring the internal processing time based on a difference between an input time of an Initial INVITE message input to the SIP server and an output time of a 100 Trying response output from the SIP server.
(Appendix 6)
In the congestion detection method according to any one of appendix 4 or 5,
A congestion detection method comprising: obtaining a message to be input / output to / from the SIP server from a SPAN tap inserted between the SIP server and an edge router.

DESCRIPTION OF SYMBOLS 1 NGN network 2, 2A-2D SIP server 3, 3A-3C Edge router 4, 4A-4F Telephone 5, 5A-5D SPAN tap 6 Congestion detection apparatus 61 Capture part 62 Message analysis / extraction part 63 INVITE [input] total part 64 INVITE [out] totaling unit 65 residence time calculating unit 66 congestion detection unit 67 congestion control unit

Claims (4)

An apparatus for detecting a congestion state of a SIP server to be monitored,
Means for measuring the number of Initial INVITE messages input to the SIP server per unit time;
Means for measuring the internal processing time for the Initial INVITE message of the SIP server;
Means for measuring the number per unit time of the Initial INVITE message output by the SIP server, the timing being shifted backward by the internal processing time;
A congestion detection apparatus comprising: means for determining whether or not a congestion state occurs by comparing the measured number of input messages and the number of output messages. The congestion detection device according to claim 1,
The congestion detection apparatus, wherein the internal processing time is measured based on a difference between an input time of an Initial INVITE message input to the SIP server and an output time of a 100 Trying response output from the SIP server. In the congestion detection apparatus according to any one of claims 1 and 2,
A congestion detection apparatus, wherein a message to be input / output to / from the SIP server is acquired from a SPAN tap inserted between the SIP server and an edge router. A method for detecting a congestion state of a SIP server to be monitored,
A step of measuring the number of Initial INVITE messages input to the SIP server per unit time;
Measuring internal processing time for the Initial INVITE message of the SIP server;
A step of measuring the number of cases per unit time of the Initial INVITE message output by the SIP server with the timing shifted backward by the internal processing time;
A congestion detection method comprising: a step of determining whether or not a congestion state occurs by comparing the measured number of input messages and the number of output messages.

Images