JP2008311944A - Congestion control system, method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a congestion control system, method and program capable of effectively eliminating the congestion of connection requests while taking it into consideration to reduce the traffic amount of the entire network. <P>SOLUTION: The congestion control system is provided with a connection processing means for transmitting provisional acknowledgment signal to a connection request message to the entire or partial senders of the received connection request messages and suppressing retransmission of the connection request message in a congestion control system for performing recovery control of congestion that can be generated by receiving a plurality of connection request messages around the same time. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a congestion control system, method, and program, and is applied to, for example, a control system, method, and program for recovering congestion when congestion occurs in a call control signal in an IP communication system employing SIP (Session Initiation Protocol). obtain.

  Generally, in a communication system, a state in which a request amount steadily exceeds a processing amount due to an excessive flow of a control signal such as a connection request from a terminal to a communication device is called a congestion state. The traffic patterns that cause congestion can be classified according to whether the source is specified or unspecified, whether the traffic changes over time, or whether it is steady or sudden.

  Conventionally, as countermeasures for these congestions, the communication device refuses connection with an error response for some connection requests, discards the connection request itself in the device, or occurs regularly. On the other hand, since there is a possibility that the network device has a chronic shortage of processing capability, congestion has been reduced by improving the processing capability such as adding devices.

  For example, a conventional congestion control method performed by the conventional call processing server 10 shown in FIG. 2 will be described with reference to FIGS. FIG. 3 is a general sequence diagram in which the call control server 10 controls a single call.

  When the call processing server 10 receives the message, the call processing server 10 temporarily stores the received message in the queue 80 and gives each message to the processing unit 30. When each message is given to the processing unit 30, in the processing unit 30, a call processing thread is generated for each message, and call processing according to the flow shown in FIG. 3 is performed.

  When a large amount of messages are given to the call processing server 10 and become congested, and the processing load of the call processing server 10 exceeds a threshold value, the call processing server 10 performs processing as shown in FIG. 4 or FIG. .

  In FIG. 4, when the call processing server 10 receives INVITE from the calling terminal (step S201), it returns 100 Trying as a response signal to the calling terminal (step S202). Thereafter, the call processing server 10 transmits an error response signal “503” to the calling terminal, thereby notifying that an error has occurred in the call processing server 10 and rejecting the connection request from the calling terminal (step S203). , S204).

  In FIG. 5, when INVITE is received from the calling terminal, a response signal is not returned and the received INVITE is discarded (step S301). That is, as shown in FIG. 5, when a large amount of INVITE is sent, all received INVITEs are discarded.

  Patent Document 1 describes a technique related to call control at a call terminal in a communication system employing SIP. Specifically, in a technique in which, after the sending terminal transmits INVITE, when Retry-After is received from the receiving terminal, the INVITE is transmitted again after the acceptable time included in this Retry-After has elapsed. is there.

JP 2004-112182 A

  By the way, in a communication system using SIP as a signal control protocol, a low-reliability protocol such as UDP (User Datagram Protocol) may be used as a transport protocol.

  Here, generally, when the transmission terminal fails to receive a response signal within a predetermined time after transmitting the connection request signal, the transmission terminal retransmits the connection request signal. In this case, if the server tries to cope with the connection request discarding method as in the above-described prior art, the call processing server discards the connection request, so that the calling terminal retransmits the connection request. Traffic volume may increase, and as a result, congestion may be promoted (see FIG. 5).

  Further, for example, when a communication impossible state such as a network failure is recovered, bursty traffic is likely to occur immediately after that. Also in such a case, there is a possibility that the server will promote congestion by increasing the number of cases where the server tries to connect again by rejecting the connection or discarding the connection request as in the prior art described above (FIGS. 4 and 5). reference).

  Japanese Patent Application Laid-Open No. 2004-228561 is a technique related to a terminal, but it is also conceivable to apply this technique to a server as a congestion avoidance means for a connection request. However, the technique described in Patent Document 1 is intended to improve the efficiency of connectivity, not to reduce the traffic volume of the entire network, and operates according to Retry-After. Since it is only a terminal, there is a problem that it cannot be applied to a server as it is.

  Therefore, a congestion control system, method, and program capable of effectively eliminating the congestion of connection requests while considering reducing the traffic amount of the entire network.

  In order to solve such a problem, a congestion control system according to the first aspect of the present invention is a congestion control system that performs recovery control of congestion that may be caused by receiving a plurality of connection request messages at the same time. (1) Received connection request A connection processing unit is provided that transmits a provisional response signal to the connection request message to all or a part of the source of the message to suppress retransmission of the connection request message.

  A congestion control method according to a second aspect of the present invention is a congestion control method for recovering and controlling congestion that may be caused by receiving a plurality of connection request messages at the same time. (1) The connection processing means receives all of the received connection request messages. Alternatively, a connection processing step of transmitting a provisional response signal to the connection request message to some of the transmission sources to suppress retransmission of the connection request message is provided.

  A congestion control program according to a third aspect of the present invention is a congestion control program for recovering and controlling congestion that may be caused by receiving a plurality of connection request messages at the same time, and sending all or part of the received connection request messages to a computer. A provisional response signal for the connection request message is transmitted to the source so as to function as connection processing means for suppressing retransmission of the connection request message.

  According to the present invention, it is possible to effectively eliminate the congestion of connection requests while considering reducing the traffic amount of the entire network.

(A) First Embodiment Hereinafter, a first embodiment of the congestion control system, method and program of the present invention will be described with reference to the drawings.

  In the first embodiment, a case where the present invention is applied to a call processing server configuring an IP communication system employing SIP will be described as an example.

(A-1) Configuration of the First Embodiment FIG. 1 is an internal configuration diagram showing main internal functions of the call processing server of the first embodiment. As shown in FIG. 1, the call processing server 1 according to the first embodiment is configured to include at least a receiving unit 2, a processing unit 3, and a delay management unit 4.

  Although a description of the hardware configuration of the call processing server 1 is omitted, the call processing server 1 generally includes, for example, a CPU, a ROM, a RAM, an EEPROM, a communication unit, and the like. The functions of the call processing server 1 described below are realized by software processing.

  The receiving unit 2 receives SIP messages M1 to M3, which are control signals related to call processing, through a communication line. The receiving unit 2 has a queue 8, and once the received message is stored, the temporarily stored message is given to the processing unit 3.

  The processing unit 3 generates a call processing thread for each message from the receiving unit 2 and performs call processing. Thereby, the process according to each message can be performed in parallel.

  Further, when the processing unit 3 receives a message, it temporarily returns a response signal to the transmitting terminal. Thus, since a response signal can be returned to the message originator, it is possible to eliminate retransmission of the message from the message originator. Even when a large number of messages are received at once, response signals can be returned to as many messages as possible. As a result, message retransmission can be reduced as compared with the prior art. Therefore, the traffic amount of the entire network can be reduced, and congestion can be avoided.

  Further, after the provisional response signal is transmitted, the processing unit 3 requests the delay management unit 4 to set a delay timer, and temporarily interrupts the call processing. When the delay management unit 4 is notified that the set delay timer time has been reached, the processing unit 3 resumes the call processing. Thus, the processing load on the processing unit 3 can be reduced by intentionally interrupting the call processing.

  When receiving a request for setting a delay timer from the processing unit 3, the delay management unit 4 sets a notification time to be notified to the processing unit 3 for each request. When the notification time for each request comes, the delay management unit 4 notifies the processing unit 3 that the timer time for the request has come.

  Here, the timer time (delay time) is set within a timeout (for example, within several tens of seconds) determined by the call processing protocol. As a result, the setting can be made within the range of the call processing protocol.

  The delay management unit 4 manages the time for each time setting request. The time may be set and changed according to the congestion state as long as it is within the time-out range determined by the call processing protocol. For example, if the amount of INVITE received within a unit time is large and exceeds the threshold, the time may be set large.

(A-2) Operation of the First Embodiment Next, the operation of the congestion control process in the call processing server 1 of the first embodiment will be described with reference to the drawings.

  First, processing in the call processing server 1 of the first embodiment will be described with reference to FIG.

  When the messages M1 to M3 are given to the call processing server 1 (step S701), the received message is temporarily stored in the queue 8 of the receiving unit 2 (step S702). Thereafter, the temporarily stored message is given to the processing unit 3 (step S703). In the processing unit 3, a call processing thread is generated for each message, and each call processing is performed (step S704).

  Here, FIG. 9 is a flowchart showing processing in the processing unit 3. In FIG. 9, when the processing unit 3 receives a message from the receiving unit 2 (step S801), the processing unit 3 analyzes the received signal (step S802).

  Here, the processing unit 3 analyzes information regarding a transmission source and a destination, a message type, a response to the received message, and the like. At this time, the processing unit 3 performs a reply process of a provisional response signal (for example, 100 Trying) (step S803).

  If the received signal is a request message (for example, INVITE) from the transmission source, the processing unit 3 requests the delay management unit 4 to set a timer (step S804, S705 in FIG. 1). At this time, the processing unit 3 waits for a timer notification from the delay management unit 4 (step S805), and the processing unit 3 interrupts the call processing during the timer notification waiting period.

  On the other hand, the delay management unit 4 performs the processing shown in FIGS. In FIG. 10, the delay management unit 4 receives a timer setting request from the processing unit 3 (step S811), and waits for a timer setting request from the processing unit 3.

  When the delay management unit 4 receives a timer setting request from the processing unit 3 (step S812), it sets a notification time for the request (step S813), registers a timer event (step S814), and sets the next timer setting. The request is waited (step S815).

  Further, as shown in FIG. 11, the delay management unit 4 periodically monitors the registered timer event (step S816), determines whether or not the current time information is the notification time information, and notifies The presence / absence of an event is determined (step S817).

  If there is no notification event, the process returns to step S816 and the process is repeated. If there is a notification event, the processing unit 3 is notified of a timer for the request (step S818, S707 in FIG. 1).

  As shown in FIG. 9, when a timer notification is given from the delay management unit 4 to the processing unit 3 (step S806), the processing unit 3 transmits a response signal to the request message (step S807). Thereafter, other signal processing necessary for call processing is performed, and the processing is continued (steps S808 and S809).

  Next, a processing flow when the call processing server 1 performs a single call processing will be described with reference to FIG. FIG. 6 is a flowchart showing a processing flow of a single call performed by the call processing server 1.

  First, when INVITE transmitted from the calling terminal is given to the call processing server 1 (step S101), the processing unit 3 of the call processing server 1 returns a response signal 100 Trying to the caller (step S102).

  When the call processing server 1 transmits the response signal 100 Trying, the call processing server 1 intentionally interrupts the call processing for a predetermined time and delays the transmission of “407 (Proxy Authentication Required)” that is originally transmitted thereafter. (Step S401).

  Then, when a predetermined time has elapsed, the call processing server 1 transmits “407 (Proxy Authentication Required)” to the caller (step S103). Thus, by temporarily interrupting the processing of the processing unit 3, the load on the entire processing unit 3 can be reduced.

  Subsequent processing is similar to normal call processing, when ACK is given from the caller (step S104), and INVITE from the caller terminal is given to the call processing server 1 (step S105), the processing unit of the call processing server 1 3 returns a response signal 100 Trying to the caller (step S106) and interrupts the processing for a predetermined time (step S402) as described above.

  Then, when the predetermined time has elapsed, the call processing server 1 transmits INVITE to the destination (step S107).

  Subsequent processing is the same as normal call processing. That is, 100 Trying is given from the destination (step S108), and when 180 Ringing is received from the destination (step S109), the received 180 Ringing is transmitted to the source (step S110). When 200 OK is given to the call processing server 1 from the destination (step S111), the call processing server 1 transmits the received 200 OK to the caller (step S112). Then, by transmitting an ACK from the caller to the callee (steps S113 and S114), communication between the caller and the callee is realized.

  When communication between the caller and the callee ends and BYE is given to the call processing server 1, the communication is completed by transmitting BYE to the partner terminal and returning 200 OK from the partner terminal ( Steps S115 to S118).

  As described above, even when performing call processing for a single call, after returning a provisional response signal to the received message, the processing is intentionally interrupted for a predetermined time and then the subsequent processing is continued. By doing so, the load on the processing unit 3 of the call processing server 1 can be reduced.

  Next, the processing in the call processing server 1 when there is an unauthorized access such as when there is a request for connection of an unspecified number of destinations from a specific source (so-called “one cut”) is shown in FIG. This will be described with reference to FIG.

  The process of FIG. 7 corresponds to the process shown in FIG. 4, and the process of FIG. 8 corresponds to the process shown in FIG. Further, for example, it is possible to flexibly determine to perform the processing of FIG. 7 or FIG. 8 according to the amount of INVITE received per unit time.

  In FIG. 7, when INVITE from the caller is given to the call processing server 1 (step S201), the processing unit 3 of the call process server 1 returns 100 Trying to the caller (step S202).

  At this time, when 100 Trying is returned, the call processing server 1 intentionally interrupts the processing for a predetermined time, and when the predetermined time has elapsed (step S501), transmits an error response signal “503” to the transmission source. The call processing server 10 is notified that an error has occurred, and the connection request from the calling terminal is rejected (steps S203 and S204).

  In FIG. 8, when INVITE from the caller is given to the call processing server 1 (step S601), the processing unit 3 of the call process server 1 returns 100 Trying to the caller (step S602). At this time, the call processing server 1 returns 100 Trying, which is a provisional response signal, and then discards the received INVITE.

  As described above, when the call processing server 1 replies 100 Trying tentatively when receiving INVITE from the transmission source, the transmission source uses the same line unless the transmission source is disconnected (step S603). It is impossible to make another call (calling the next INVITE). Therefore, the number of INVITE transmissions per unit time from this specific transmission source can be effectively reduced.

(A-1) Effects of the First Embodiment As described above, according to the first embodiment, when the connection request INVITE is received, a provisional response signal is transmitted to the transmission source. Thus, retransmission of INVITE from the transmission source can be suppressed.

  Further, according to the first embodiment, after the provisional response signal is transmitted, the time is set within a timeout period determined by a predetermined connection processing protocol, and the processing is temporarily interrupted during that time period. The processing load of the entire processing unit can be reduced.

  Furthermore, according to the first embodiment, when a large amount of INVITE is given at the same time, a temporary response signal is transmitted, and then the received INVITE is discarded, so that It is possible to prevent unnecessary transmission of INVITE.

  As described above, since the amount of signals flowing on the network can be reduced, congestion of the entire network can be eliminated.

(B) Other Embodiments In the first embodiment, the processing unit and the delay management unit included in the call processing server 1 have been described as being physically included in the same server, but can be connected through a network. As long as the function described in the first embodiment can be realized, the present invention can be applied to those that are distributedly arranged.

  In the first embodiment, the description has been made assuming an IP communication network adopting SIP, but the protocol for establishing a session is not limited to SIP and can be widely applied.

  As described above, it is assumed that the processing function of the call processing server 1 of the first embodiment is realized by software processing. That is, each function of the processing unit 3 described in the first embodiment is stored in a ROM as a processing program, for example, and the CPU reads each processing program and processes it using data necessary for the processing. It is realized by executing a program. Note that the processing function of the call processing server may be realized by hardware if possible.

It is a figure which shows the internal structure of the call processing server of 1st Embodiment, and the flow of whole processing. It is a figure which shows the internal structure of the conventional call processing server, and the flow of the whole process. It is a flowchart which shows the call processing of the single call by the conventional call processing server. It is a flowchart which shows the corresponding process with respect to the unauthorized access by the conventional call processing server (the 1). It is a flowchart which shows the response process with respect to the unauthorized access by the conventional call processing server (the 2). It is a flowchart which shows call processing of the single call by the call processing server of 1st Embodiment. It is a flowchart which shows the response process with respect to the unauthorized access by the call processing server of 1st Embodiment (the 1). It is a flowchart which shows the response process with respect to the unauthorized access by the call processing server of 1st Embodiment (the 2). It is a flowchart which shows the process in the process part of 1st Embodiment. It is a flowchart which shows the timer event registration process in the delay management part of 1st Embodiment. It is a flowchart which shows the timer event notification process in the delay management part of 1st Embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Call processing server, 2 ... Reception part, 3 ... Processing part, 4 ... Delay management part, 8 ... Queue.

Claims (6)

In a congestion control system that performs recovery control of congestion that may be caused by receiving a plurality of connection request messages at the same time,
A connection processing unit is provided that transmits a provisional response signal to the connection request message to all or a part of the source of the received connection request message to suppress retransmission of the connection request message. Congestion control system.   The congestion control system according to claim 1, wherein the connection processing unit temporarily interrupts the connection processing after transmitting the provisional response signal.   When a request for setting a timer for a predetermined time is received from the connection processing means, a timer event for counting the predetermined time is registered, and when the predetermined time is reached, a time for notifying the connection processing means to that effect The congestion control system according to claim 2, further comprising management means.   4. The congestion control system according to claim 1, wherein the connection processing unit discards the received connection request message after transmitting the provisional response signal. In a congestion control method for recovering and controlling congestion that may be caused by receiving a plurality of connection request messages at the same time,
A connection processing step in which the connection processing means transmits a provisional response signal to the connection request message to all or a part of the source of the received connection request message to suppress retransmission of the connection request message. A congestion control method comprising: In a congestion control program for recovery control of congestion that may be caused by receiving a plurality of connection request messages at the same time,
Function as connection processing means for transmitting a provisional response signal to the connection request message to all or a part of the source of the received connection request message to the computer and suppressing retransmission of the connection request message Congestion control program.

Images