WO2023276001A1

WO2023276001A1 - Load balancing system, load balancing method, load balancing program

Info

Publication number: WO2023276001A1
Application number: PCT/JP2021/024577
Authority: WO
Inventors: 篤蓮沼
Original assignee: 日本電信電話株式会社
Priority date: 2021-06-29
Filing date: 2021-06-29
Publication date: 2023-01-05

Abstract

This load balancing system of a first communication carrier network is provided with multiple proxy servers 3. The proxy servers 3 are provided with a selection table 35 for selecting a forwarding destination SIP server, a selection unit 31 which uses the selection table 35 to select a SIP server 4 to which to forward messages received from a second communication carrier network, and a forwarding unit 32 which forwards the aforementioned messages to the selected SIP server, wherein the selection table 35 is shared with the other proxy server 3, and excludes SIP servers 4 that are stopped.

Description

Load balancing system, load balancing method, and load balancing program

The present invention relates to a load distribution system, a load distribution method, and a load distribution program.

In recent years, interconnection between multiple telecommunications carriers has been considered. Non-Patent Document 1 defines an interconnection common interface between IMS operator networks. Also, network load balancing technology is being researched and developed. Non-Patent Document 2 describes Maglev, a large-scale distributed software system that runs on servers.

In general, when applying a load balancer to a server that handles stateful communication such as SIP, an ACT/SBY (1+1 redundancy) configuration is used to maintain the connection state. On the other hand, a load distribution system capable of a scalable N-ACT configuration, such as Non-Patent Document 2, has a problem that it cannot be applied to SIP because it does not maintain the communication state.

In addition, when distributing the load on the SIP server on the receiving side in interconnection between multiple telecommunications carriers, it is necessary for the calling-side telecommunications carrier to be aware of the IP address, etc. of the receiving-side telecommunications carrier. Therefore, when the service provider on the receiving side suspends maintenance of the SIP server, the service provider on the sending side needs to prevent the service provider from connecting to the SIP server for which maintenance is suspended. For example, the originating carrier needs to set each SIP server in its own network to stop routing to the SIP server for maintenance stop of the called carrier's network.

The present invention has been made in view of the above circumstances, and an object of the present invention is to enable load distribution in the N-ACT configuration in communication using SIP, while enabling load distribution in the first communication carrier network. To eliminate the need to suppress connection to a stopped SIP server in a second communication carrier network when the SIP server stops.

In order to achieve the above object, one aspect of the present invention is a load balancing system for a first telecommunications carrier network, comprising a plurality of proxy servers, the proxy servers for selecting a destination SIP server. a selection table for selecting a SIP server to which a message transmitted from a second communication carrier network is to be transferred using the selection table; and a transfer unit for transferring the message to the selected SIP server. and , wherein the selection table is a table shared with other proxy servers and excludes the stopped SIP server.

One aspect of the present invention is a load balancing method performed by a load balancing system of a first telecommunications carrier network, wherein the load balancing system includes a plurality of proxy servers, and the proxy servers are forwarding destination SIP servers. using the selection table to select a SIP server to which a message transmitted from the second carrier network is to be transferred; forwarding the message, wherein the selection table is a table common to other proxy servers, excluding SIP servers to be stopped.

One aspect of the present invention is a load balancing program that causes a computer to function as the proxy server.

According to the present invention, in communication using SIP, while enabling load distribution in the N-ACT configuration, when the SIP server stops in the first communication carrier network, the second communication carrier network It is possible to eliminate the need to suppress connection to the stopped SIP server.

It is a figure which shows the structural example of the communication system of embodiment of this invention. 2 is a block diagram showing a configuration example of an SLSP server; FIG. FIG. 10 is a sequence diagram showing connection processing in normal time; FIG. 10 is a sequence diagram showing connection processing when the IBCF server is stopped for maintenance; FIG. 10 is a sequence diagram showing connection processing when an SLSP server fails; It is a hardware configuration example.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a system configuration diagram showing an example of a communication system according to this embodiment. The illustrated communication system is a system in which a calling-side telecommunications carrier's network (second telecommunications carrier's network) and a called-side telecommunications carrier's network (first telecommunications carrier's network) are interconnected.

The originating carrier's network has multiple SIP servers 1 connected to the core network. Each SIP server 1 transmits a SIP message packet (SIP packet) to the virtual IP address assigned to the L3SW 2 as a destination.

　The carrier network on the receiving side comprises a transfer device 2, multiple SLSP servers 3, multiple IBCF servers 4, and EMS5. Here, a layer 3 switch (hereinafter referred to as “L3SW”) is used for the transfer device 2 .

The L3SW 2 distributes the SIP message packets sent from the SIP server 1 to multiple SLSP servers 3 (SLSP server group). L3SW2 evenly distributes packets using a technique such as ECMP (Equal Cost Multi Path). ECMP is a function that distributes packets when there are multiple equal-cost routes. The L3SW 2 of this embodiment evenly distributes received packets to a plurality of SLSP servers 3 without considering the IP address of the destination set in the packet. Therefore, packets related to one call are transferred across different SLSP servers 3 .

The SLSP (Stateless SIP Proxy) server 3 is a stateless SIP proxy server that is unaware of the state of SIP. A plurality of SLSP servers 3 (SLSP servers 3 with N-ACT configuration) are arranged in front of the IBCF server 4 . A plurality of SLSP servers 3 function as a load distribution system in the communication carrier network on the receiving side. The SLSP server 3 forwards packets related to the same call so that they reach the same IBCF server 4 .

Each SLSP server 3 holds a selection table 35 provided by the EMS 5. The selection table 35 is a table for selecting the IBCF server 4 to which the packet received from the L3SW 2 is transferred. The selection table 35 of this embodiment is a table that can specify the IP address of the IBCF server 4 corresponding to the call identification information (for example, Call-ID, etc.) set in the packet.

All SLSP servers 3 have the same selection table 35 in common. Each SLSP 3 uses the same selection table 35 to select the IBCF server 4 to which a received packet is to be forwarded, so packets related to the same call are guaranteed to reach the same IBCF server 4 .

The IBCF (Interconnection Border Control Function) server 4 is one of the SIP servers and functions as a gateway to another telecommunications carrier's network (here, the calling-side telecommunications carrier's network). The IBCF server 4 is assigned an IP address. The IP address is used as a network identifier of the transfer destination IBCF server 4 in the selection table 35 .

The EMS (Element Management System) 5 is a device management system that manages each device included in the communication carrier network on the receiving side. The EMS 5 of this embodiment provides the selection table 35 to all SLSP servers 3 . Further, when the EMS 5 suspends a certain IBCF server 4 for maintenance or the like, the EMS 5 provides all the SLSP servers 3 with the selection table 35 excluding the IBCF server 4 in question.

In the illustrated example, when maintenance of the IBCF server 4 with IP address: IP1 is suspended, the EMS 5 generates a selection table 35 excluding the IP address: IP1 of the IBCF server 4 and provides it to each SLSP server 3 . As a result, connection to the stopped IBCF server 4 can be suppressed without affecting calls in progress. Therefore, in this embodiment, the communication carrier network of the originating side does not need connection inhibition processing to the IBCF server 4 that is stopped in the communication carrier network of the receiving side.

FIG. 2 is a configuration diagram showing the configuration of the SLSP server 3. The illustrated SLSP server 3 includes a selection unit 31 , a transfer unit 32 , an acquisition unit 33 and a storage unit 34 .

Using the selection table 35, the selection unit 31 selects the IBCF server 4 (SIP server) to which the packet (message) transmitted from the originating carrier's network is transferred. The selection unit 31 may use the selection table 35 to select the transfer destination IBCF server 4 corresponding to the call identification information (Call-ID, etc.) included in the packet.

The transfer unit 32 transfers the packet to the selected IBCF server 4. The transfer unit 32 may transfer the packet to the IBCF server 4 based on the Record-Route header added by the IBCF server 4 as the transfer destination. Specifically, when receiving a packet with a Route header generated based on the Record-Route header, the transfer unit 32 transfers the packet to the IBCF server 4 set in the Route header. Messages having the same call identification information are thereby forwarded to the same IBCF server 4 .

The acquisition unit 33 acquires the selection table 35 from the EMS 5 (equipment management system) and retains it in the storage unit 34 . When one of the IBCF servers 4 is stopped for maintenance or the like, the acquisition unit 33 receives the selection table 35 excluding the IBCF server 4 to be stopped from the EMS 5 and updates the selection table 35 in the storage unit 34 .

The storage unit 34 stores a selection table 35 for selecting the transfer destination IBCF server 4 . The selection table 35 is a table shared with other SLSP servers 3 and excludes the IBCF servers 4 to be stopped. The selection table 35 is a table set so as to uniquely determine the IBCF server 4 corresponding to the call identification information, and an IP address may be set as the identification information of each IBCF server 4 . For the selection table 35, for example, a hash table using hash values of call identification information, a consistent hash table, or the like may be used.

FIG. 3 is a sequence diagram showing normal connection processing of the communication system of this embodiment. In the illustrated example, two

SLSP servers

3A, 3B and two

IBCF servers

4A, 4B are provided.

Each

SLSP server

3A, 3B sets the selection table 35 acquired from the EMS 5 in the storage unit 34 (S10).

The SIP server 1 sends the INVITE (SIP message) packet sent from the SIP server 1 to the L3SW 2 (S11). Using the ECMP function, the L3SW 2 evenly distributes the received INVITE packets to either of the following

SLSP servers

3A, 3B (S12). Here, the L3SW2 transfers the packet of S11 to the SLSP server 3A.

The SIP server 1 resends the INVITE packet sent in S11 to L3SW2 (S13). The L3SW 2 evenly distributes the received INVITE packets to either

SLSP server

3A or 3B, as in S12 (S14). Here, the L3SW2 transfers the packet of S13 to the SLSP server 3B.

The SLSP server 3A receives the INVITE packet of S12, selects the IBCF server 4A as the transfer destination using the selection table 35, and transfers the packet to the IBCF server 4A (S15). Specifically, the SLSP server 3A obtains the Call-ID included in the packet, and obtains the IP address of the IBCF server 4A: IP1 from the selection table 35 as the transfer destination corresponding to the Call-ID. Then, the SLSP server 3A transfers the INVITE packet to the IP address of the IBCF server 4A: IP1.

Similarly, the SLSP server 3B receives the INVITE packet retransmitted in S14, selects the IBCF server 4A as the transfer destination using the selection table 35, and transfers the packet to the selected IBCF server 4A (S16). .

Each

SLSP server

3A, 3B holds a common selection table 35 as logic for determining the IBCF server 4A from the Call-ID. Therefore, even if multiple SIP message packets with the same Call-ID reach

different SLSP servers

3A and 3B, each of the

SLSP servers

3A and 3B transfers the received packets to the same IBCF server 4A.

When the IBCF server 4A receives the INVITE packet, it sends a provisional response packet of 100 (Trying) to the SIP server 1 (S17).

Then, the IBCF server 4A adds a Record-Route header to the INVITE packet, and transfers the packet with the Record-Route header to the subsequent network device (not shown) (S18). That is, the IBCF server 4A attaches a Record-Route header to the received packet so that the subsequent SIP message during the call reaches its own IBCF server 4A (RFC3261 compliant). Specifically, the IBCF server 4A sets its own address (for example, IP address) in the Record-Route header of the INVITE packet.

With this Record-Route header, for example, a receiving terminal (not shown) can know the route through which the INVITE has been transferred. For example, 180: Ringing) provisional response packet is sent.

After that, it will be processed according to RFC3261. In the illustrated example, the IBCF server 4A receives the 18x packet to which the Record-Route header is attached (S19), and transfers the packet to the SIP server 1 (S20). The SIP server 1 transfers the 18x provisional response packet to which the Record-Route header is added to the calling terminal (not shown).

The SIP server 1 sends a PRACK (SIP message) packet requesting confirmation of the provisional response. Here, the SIP server 1 generates a Route header based on the Record-Route header, and adds the generated Route header to the PRACK packet. A Route header is used to route a SIP message through the device whose routing information is contained in the header. In the illustrated example, the Route header contains the address of the IBCF server 4A. The SIP server 1 transmits a PRACK packet with a Route header to the L3SW 2 (S21).

The L3SW2 distributes the PRACK packet to one of the SLSP servers 3A (S22). The SLSP server 3A transfers the PRACK packet to the IBCF server 4A based on the Route header (S23). Specifically, the SLSP server 3A transfers the packet to the IBCF server 4A according to the Route header, since the IP address of the IBCF server 4A: IP1 is given in the Route header.

FIG. 4 is a sequence diagram showing connection processing when the IBCF server 4A is stopped for maintenance. The illustrated communication system example includes two

SLSP servers

3A, 3B and two

IBCF servers

4A, 4B, as in FIG.

When suspending the IBCF server 4A for maintenance, the EMS 5 provides the

SLSP servers

3A and 3B with the selection table 35 excluding the IBCF server 4A subject to maintenance suspension. Each

SLSP server

3A, 3B acquires the selection table 35 from the EMS 5 and updates the selection table 35 in the storage section 34 (S30). As a result, the

SLSP servers

3A and 3B no longer select the stopped IBCF server 4A. Therefore, in this embodiment, the SIP server 1 of the communication carrier network on the originating side does not need to be set to suppress the transmission of the SIP message to the stopped IBCF server 4A.

Since S31 to S34 shown in FIG. 4 are the same as S11 to S14 shown in FIG. 3, description thereof is omitted here. The SLSP server 3A receives the INVITE packet, determines the

IBCF servers

4A and 4B to which the packet is to be transferred, and transfers the INVITE to the

determined IBCF servers

4A and 4B (S35). Specifically, the SLSP server 3A acquires the Call-ID included in the packet, and selects the

IBCF servers

4A and 4B corresponding to the Call-ID using the selection table 35. FIG. Since the selection table 35 excludes the stopped IBCF server 4A, the SLSP server 3A selects the IBCF server 4B.

Similarly, the SLSP server 3B receives the retransmitted INVITE packet, determines the transfer destination IBCF server 4B using the selection table 35, and transfers the received packet to the IBCF server 4B (S36).

When the IBCF server 4B receives the INVITE packet, it sends a packet of 100 (Trying) to the SIP server 1 (S37). Then, the IBCF server 4B transfers the INVITE packet to which the Record-Route header is added to the subsequent device, as in S18 of FIG. 3 (S38). The address of the IBCF server 4B is set in the Record-Route header as route information.

Since S39 to S43 thereafter are the same as S19 to S23 in FIG. 3, description thereof is omitted here.

Thus, in this embodiment, the SIP message during the call is routed according to the Route header, so the call during the call can be continued. That is, since the IBCF server 4A which is inactive is excluded from the selection table 35, the INVITE packet is not sent to the IBCF server 4A, and the call in progress is not affected.

FIG. 5 is a sequence diagram showing connection processing when the SLSP server 3A fails. The illustrated communication network example includes two

SLSP servers

3A, 3B and two

IBCF servers

4A, 4B, as in FIG.

Since S50 to S54 shown in FIG. 5 are the same as S10 to S14 shown in FIG. 3, their description is omitted here.

If a packet is sent to the failed SLSP server 3A, the packet is discarded. Here, the failed SLSP server 3A discards the INVITE packet received from the L3SW 2 in S52 (S55). The packets are expected to reach another SLSP server 3B by the packet retransmission function of the SIP server 1. FIG.

Note that the L3SW 2 detects network failures such as downlinks to the SLSP server 3A and BFD (Bidirectional Forwarding Detection), and stops forwarding packets to the SLSP server 3A. Thus, in this embodiment, communication can be continued even if one of the SLSP servers 3A fails.

The SLSP server 3B receives the INVITE packet retransmitted in S54 from L3SW2. The SLSP server 3B selects the transfer destination IBCF server 4B using the selection table 35, and transfers the INVITE packet to the selected IBCF server 4B (S56). Specifically, the SLSP server 3B acquires the Call-ID included in the packet, and selects the IBCF server 4B corresponding to the Call-ID using the selection table 35. FIG.

The subsequent S57 to S63 are the same as S17 to S23 in FIG. 3, so the description is omitted here.

The load balancing system of the communication carrier network on the receiving side of the present embodiment described above includes a plurality of SLSP servers 3. The SLSP servers 3 each include a selection table 35 for selecting the IBCF server 4 as a transfer destination, A selection unit 11 that selects an IBCF server 4 to which a packet (message) transmitted from a local carrier network is to be transferred using a selection table 35, and a transfer unit 12 that transfers the packet to the selected IBCF server 4. , and the selection table 35 is a table shared with other SLSP servers 3, and excludes the IBCF server 4 to be stopped.

Specifically, in this embodiment, multiple SLSP servers 3 (stateless SIP proxy servers) that are unaware of the SIP state are installed in front of the IBCF server 4 as a load distribution system in the carrier network on the receiving side. , each SLSP server 3 holds a selection table 35 for determining the IBCF server 4 from the call identification information (Call-ID, etc.) of the packet of the SIP message.

As a result, in a communication system using SIP in which a plurality of telecommunications carrier networks are interconnected, it is possible to distribute the load in the N-ACT configuration, and stop the IBCF server 4 in the telecommunication carrier network on the receiving side. On the other hand, it is possible to make it unnecessary to suppress the connection to the stopped IBCF server 4 in the communication carrier network on the calling side.

That is, when the ICBF server 4 is stopped in the communication carrier network of the called party, it is possible to suppress the connection to the stopped IBCF server 4 simply by changing the setting of the selection table 35 of the called party. This eliminates the need for connection suppression processing by the user.

In addition, since the L3SW 2 of this embodiment evenly distributes packets without being aware of calls, retransmission INVITE packets related to the first INVITE packet may be divided and transmitted to another SLSP server 3. However, since each SLSP server 3 holds the same selection table 35, the same call packet can be transferred to the same IBCF server 4A.

For the SLSP server 3 described above, for example, a general-purpose computer system as shown in FIG. 6 can be used. The illustrated computer system includes a CPU (Central Processing Unit, processor) 901, memory 902, storage 903 (HDD: Hard Disk Drive, SSD: Solid State Drive), communication device 904, input device 905, and output device. 906. Memory 902 and storage 903 are storage devices. In this computer system, each function of the SLSP server 3 is realized by the CPU 901 executing a predetermined program loaded on the memory 902 .

Also, the SLSP server 3 may be implemented by one computer, or may be implemented by a plurality of computers. Also, the SLSP server 3 may be a virtual machine implemented in a computer.

Programs for the SLSP server 3 can be stored on computer-readable recording media such as HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), DVD (Digital Versatile Disc), etc., or can be downloaded via a network. It can also be distributed.

It should be noted that the present invention is not limited to the above embodiments, and many modifications are possible within the scope of the gist.

1: SIP server 2: L3SW (transfer device)
3 : SLSP server (proxy server)
31: Selection unit 32: Transfer unit 33: Acquisition unit 34: Storage unit 35: Selection table 4: IBCF server (SIP server)
5: EMS (equipment management system)

Claims

A load balancing system for a first telecommunications carrier network,
comprising a plurality of proxy servers, the proxy servers comprising:
a selection table for selecting a destination SIP server;
a selection unit that selects, using the selection table, a SIP server to which a message transmitted from the second carrier network is to be transferred;
a forwarding unit that forwards the message to the selected SIP server,
The selection table is a table shared with other proxy servers, and the stopped SIP servers are excluded from the load balancing system.
The load balancing system according to claim 1, wherein said proxy server is a stateless SIP proxy server.
3. The load distribution system according to claim 1, wherein the selection unit selects a transfer destination SIP server corresponding to the call identification information included in the message using the selection table.
4. The load balancing system according to any one of claims 1 to 3, wherein the transfer unit transfers the message to the SIP server based on a Record-Route header added by the destination SIP server.
The load distribution system according to any one of claims 1 to 4, further comprising an acquisition unit that acquires the selection table from a device management system.
A load distribution method performed by a load distribution system of a first telecommunications carrier network,
The load balancing system comprises a plurality of proxy servers, the proxy servers comprising:
maintaining a selection table for selecting a destination SIP server;
selecting, using the selection table, a SIP server to which messages sent from the second carrier network are forwarded;
forwarding the message to the selected SIP server;
The load balancing method, wherein the selection table is a table shared with other proxy servers and excludes SIP servers to be stopped.
A load balancing program that causes a computer to function as the proxy server according to any one of claims 1 to 5.