WO2023276001A1 - Load balancing system, load balancing method, load balancing program - Google Patents
Load balancing system, load balancing method, load balancing program Download PDFInfo
- Publication number
- WO2023276001A1 WO2023276001A1 PCT/JP2021/024577 JP2021024577W WO2023276001A1 WO 2023276001 A1 WO2023276001 A1 WO 2023276001A1 JP 2021024577 W JP2021024577 W JP 2021024577W WO 2023276001 A1 WO2023276001 A1 WO 2023276001A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- selection table
- sip
- servers
- load balancing
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 7
- 238000012546 transfer Methods 0.000 claims description 42
- 238000004891 communication Methods 0.000 abstract description 28
- 238000012423 maintenance Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 230000004044 response Effects 0.000 description 4
- 239000000969 carrier Substances 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000005764 inhibitory process Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
Definitions
- the present invention relates to a load distribution system, a load distribution method, and a load distribution program.
- 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.
- Non-Patent Document 2 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.
- the calling-side telecommunications carrier 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.
- 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.
- the selection table uses 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.
- the second communication carrier network 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.
- FIG. 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.
- 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.
- SIP packet SIP message packet
- the carrier network on the receiving side comprises a transfer device 2, multiple SLSP servers 3, multiple IBCF servers 4, and EMS5.
- 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.
- the EMS 5 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 .
- 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 .
- 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 .
- 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 .
- 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.
- 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).
- the L3SW 2 evenly distributes the received INVITE packets to either of the following SLSP servers 3A, 3B (S12).
- 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).
- 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.
- 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.
- the 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).
- 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.
- the IBCF server 4A sets its own address (for example, IP address) in the Record-Route header of the INVITE packet.
- a receiving terminal can know the route through which the INVITE has been transferred. For example, 180: Ringing) provisional response packet is sent.
- 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.
- 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.
- 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.
- the EMS 5 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.
- 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.
- 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).
- the IBCF server 4B 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.
- 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.
- the packet is discarded.
- 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.
- 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.
- network failures such as downlinks to the SLSP server 3A and BFD (Bidirectional Forwarding Detection)
- BFD Bidirectional Forwarding Detection
- 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).
- 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.
- 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.
- the selection table 35 is a table shared with other SLSP servers 3, and excludes the IBCF server 4 to be stopped.
- each SLSP server 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.
- retransmission INVITE packets related to the first INVITE packet may be divided and transmitted to another SLSP server 3.
- each SLSP server 3 holds the same selection table 35, the same call packet can be transferred to the same IBCF server 4A.
- SLSP server 3 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.
- each function of the SLSP server 3 is realized by the CPU 901 executing a predetermined program loaded on the memory 902 .
- 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.
- 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.
- 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)
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
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
本発明は、負荷分散システム、負荷分散方法、および、負荷分散プログラムに関する。
The present invention relates to a load distribution system, a load distribution method, and a load distribution program.
近年、複数の通信事業者間の相互接続が検討されている。非特許文献1には、IMS事業者網間の相互接続共通インタフェースが規定されている。また、ネットワークにおける負荷分散技術も研究および開発されている。非特許文献2には、サーバー上で動作する大規模な分散ソフトウェア・システムであるMaglevが記載されている。
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.
一般にSIPのようなステートフル通信を扱うサーバに、負荷分散装置を適用する場合には、接続状態を保持するためACT/SBY(1+1冗長)構成となる。一方、非特許文献2のようなスケーラブルなN-ACT構成が可能な負荷分散システムでは、通信状態を保持しないため、SIPには適用できないといった課題がある。
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.
また、複数の通信事業者間の相互接続における、着信側のSIPサーバに対する負荷分散では、発信側の通信事業者が着信側の通信事業者のIPアドレス等を意識する必要がある。そのため、着信側の通信事業者でSIPサーバの保守停止等を行う際は、発信側の通信事業者が、着信側の保守停止するSIPサーバへの接続を抑止する等の対応が必要になる。例えば、発信側の通信事業者が、自身の網内の各SIPサーバに、着信側事業者網の保守停止のSIPサーバへのルーテチング停止を設定する必要がある。
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.
本発明では、上記事情に鑑みてなされたものであり、本発明の目的は、SIPを用いた通信において、N-ACT構成での負荷分散を可能としつつ、第1の通信事業者網でのSIPサーバの停止に対し、第2の通信事業者網での、停止するSIPサーバへの接続抑止を不要とすることにある。
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.
上記目的を達成するため、本発明の一態様は、第1の通信事業者網の負荷分散システムであって、複数のプロキシサーバを備え、前記プロキシサーバは、転送先のSIPサーバを選択するための選択テーブルと、第2の通信事業者網から送信されたメッセージの転送先のSIPサーバを、前記選択テーブルを用いて選択する選択部と、前記選択したSIPサーバに前記メッセージを転送する転送部と、を備え、前記選択テーブルは、他のプロキシサーバと共通のテーブルであって、停止するSIPサーバが除外されている。
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.
本発明の一態様は、第1の通信事業者網の負荷分散システムが行う負荷分散方法であって、前記負荷分散システムは、複数のプロキシサーバを備え、前記プロキシサーバは、転送先のSIPサーバを選択するための選択テーブルを保持するステップと、第2の通信事業者網から送信されたメッセージの転送先のSIPサーバを、前記選択テーブルを用いて選択するステップと、前記選択したSIPサーバに前記メッセージを転送するステップと、を行い、前記選択テーブルは、他のプロキシサーバと共通のテーブルであって、停止するSIPサーバが除外されている。
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.
本発明によれば、SIPを用いた通信において、N-ACT構成での負荷分散を可能としつつ、第1の通信事業者網での、SIPサーバの停止に対し、第2の通信事業者網での停止するSIPサーバへの接続抑止を不要とすることができる。
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.
以下、本発明の実施の形態について、図面を参照して説明する。
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
図1は、本実施形態の通信システムの一例を示すシステム構成図である。図示する通信システムは、発信側の通信事業者網(第2の通信事業者網)と、着信側の通信事業者網(第1の通信事業者網)とが相互接続されたシステムである。
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.
発信側の通信事業者網は、コアネットワークに接続された複数のSIPサーバ1を有する。各SIPサーバ1は、L3SW2に割り当てられた仮想IPアドレスを宛先として、SIPメッセージのパケット(SIPパケット)を送信する。
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.
着信側の通信事業者網は、転送装置2と、複数のSLSPサーバ3と、複数のIBCFサーバ4と、EMS5とを備える。ここでは、転送装置2にレイヤ3スイッチ(以下、「L3SW」)を用いる。
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 .
L3SW2は、SIPサーバ1から送信されたSIPメッセージのパケットを、複数のSLSPサーバ3(SLSPサーバ群)に対して分散する。L3SW2は、例えばECMP(Equal Cost Multi Path)等の技術を用いてパケットを均等に分散する。ECMPは、等コストの経路が複数存在するときに、パケットを振り分ける機能である。本実施形態のL3SW2は、パケットに設定された宛先のIPアドレスを考慮せずに、受け付けたパケットを複数のSLSPサーバ3に均等に振り分ける。そのため、1つの呼に関連するパケットが、異なるSLSPサーバ3にまたがって転送される。
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 .
SLSP(Stateless SIP Proxy)サーバ3は、SIPの状態を意識しないステートレスなSIPプロキシサーバである。複数のSLSPサーバ3(N-ACT構成のSLSPサーバ3)は、IBCFサーバ4の前位に配置される。着信側の通信事業者網において、複数のSLSPサーバ3は、負荷分散システムとして機能する。SLSPサーバ3は、同じ呼に関連するパケットは、同じIBCFサーバ4に届くように転送する。
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 .
各SLSPサーバ3は、EMS5から提供される選択テーブル35を保持する。選択テーブル35は、L3SW2から受信したパケットの転送先のIBCFサーバ4を選択するためのテーブルである。本実施形態の選択テーブル35は、パケットに設定された呼識別情報(例えばCall-ID等)に対応するIBCFサーバ4のIPアドレスを特定可能なテーブルである。
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.
全てのSLSPサーバ3は、共通する同じ選択テーブル35を有する。各SLSP3は、同じ選択テーブル35を用いて、受信したパケットの転送先のIBCFサーバ4を選択するため、同一の呼に関連するパケットは、同一のIBCFサーバ4に到達することが保証される。
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 .
IBCF(Interconnection Border Control Function)サーバ4は、SIPサーバの1つであって、他の通信事業者網(ここでは、発信側の通信事業者網)とのゲートウェイとして機能する。IBCFサーバ4には、IPアドレスが割り当てられている。IPアドレスは、選択テーブル35内における転送先IBCFサーバ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 .
EMS(Element Management System)5は、着信側の通信事業者網に含まれる各機器を管理する装置管理システムである。本実施形態のEMS5は、選択テーブル35を、全てのSLSPサーバ3に提供する。また、EMS5は、あるIBCFサーバ4を保守などにより停止状態にする場合、当該IBCFサーバ4を除いた選択テーブル35を全てのSLSPサーバ3に提供する。
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.
図示する例では、IPアドレス:IP1のIBCFサーバ4を保守停止する場合、EMS5は、当該IBCFサーバ4のIPアドレス:IP1を除いた選択テーブル35を生成し、各SLSPサーバ3に提供する。これにより、通話中の呼に影響を与えることなく、停止中のIBCFサーバ4に対する接続を抑止できる。したがって、本実施形態では、発信側の通信事業者網で、着信側の通信事業者網で停止するIBCFサーバ4に対する接続抑止処理が不要となる。
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.
図2は、SLSPサーバ3の構成を示す構成図である。図示するSLSPサーバ3は、選択部31と、転送部32と、取得部33と、記憶部34とを備える。
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 .
選択部31は、発信側の通信事業者網から送信されたパケット(メッセージ)の転送先のIBCFサーバ4(SIPサーバ)を、選択テーブル35を用いて選択する。選択部31は、前記パケットに含まれる呼識別情報(Call-ID等)に対応する転送先のIBCFサーバ4を、選択テーブル35を用いて選択してもよい。
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.
転送部32は、選択されたIBCFサーバ4にパケットを転送する。転送部32は、転送先のIBCFサーバ4が付与したRecord-Routeヘッダに基づいて、前記IBCFサーバ4にパケットを転送してもよい。具体的には、転送部32は、Record-Routeヘッダに基づいて生成されたRouteヘッダが付与されたパケットを受信した場合、当該Routeヘッダに設定されたIBCFサーバ4にパケットを転送する。これにより、同じ呼識別情報を有するメッセージは、同じIBCFサーバ4に転送される。
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 .
取得部33は、EMS5(装置管理システム)から選択テーブル35を取得し、記憶部34に保持する。取得部33は、保守などによりいずれかのIBCFサーバ4を停止する場合、EMS5から停止するIBCFサーバ4を除いた選択テーブル35を受信して、記憶部34の選択テーブル35を更新する。
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 .
記憶部34には、転送先のIBCFサーバ4を選択するための選択テーブル35が記憶される。選択テーブル35は、他のSLSPサーバ3と共通のテーブルであって、停止するIBCFサーバ4が除外されている。選択テーブル35は、呼識別情報に対応するIBCFサーバ4が一意に定まるように設定されたテーブルであって、各IBCFサーバ4の識別情報としてIPアドレスが設定されていてもよい。選択テーブル35には、例えば、呼識別情報のハッシュ値を用いたハッシュテーブル、コンシステントハッシュテーブル等を用いてもよい。
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.
図3は、本実施形態の通信システムの通常時の接続処理を示すシーケンス図である。図示する例では、2つのSLSPサーバ3A、3Bと、2つのIBCFサーバ4A、4Bを備えるのものとする。
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.
各SLSPサーバ3A、3Bは、EMS5から取得した選択テーブル35を記憶部34に設定する(S10)。
Each SLSP server 3A, 3B sets the selection table 35 acquired from the EMS 5 in the storage unit 34 (S10).
SIPサーバ1は、SIPサーバ1から送信されたINVITE (SIPメッセージ)のパケットをL3SW2に送信する(S11)。L3SW2は、ECMP機能を用いて、受信したINVITE のパケットを後位のいずれかのSLSPサーバ3A、3Bに均等に分散する(S12)。ここでは、L3SW2は、S11のパケットをSLSPサーバ3Aに転送する。
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.
SIPサーバ1は、S11で送信したINVITEのパケットを、L3SW2に再送する(S13)。L3SW2は、S12と同様に、受信したINVITEのパケットをいずれかのSLSPサーバ3A、3Bに均等に分散する(S14)。ここでは、L3SW2は、S13のパケットをSLSPサーバ3Bに転送する。
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.
SLSPサーバ3Aは、S12のINVITEのパケットを受信し、選択テーブル35を用いて転送先としてIBCFサーバ4Aを選択し、IBCFサーバ4Aに当該パケットを転送する(S15)。具体的には、SLSPサーバ3Aは、パケットに含まれるCall-IDを取得し、当該Call-IDに対応する転送先として、IBCFサーバ4AのIPアドレス:IP1を選択テーブル35から取得する。そして、SLSPサーバ3Aは、INVITEのパケットをIBCFサーバ4AのIPアドレス:IP1宛てに転送する。
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.
同様に、SLSPサーバ3Bは、S14で再送されたINVITEのパケットを受信し、選択テーブル35を用いて転送先としてIBCFサーバ4Aを選択し、選択したIBCFサーバ4Aに当該パケットを転送する(S16)。
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). .
各SLSPサーバ3A、3Bは、Call-IDからIBCFサーバ4Aを決定するロジックとして、共通の選択テーブル35を保持する。このため、Call-IDが同じ複数のSIPメッセージのパケットは、異なるSLSPサーバ3A、3Bにそれぞれ到達しても、各SLSPサーバ3A、3Bは、受信したパケットを同じIBCFサーバ4Aに転送する。
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.
IBCFサーバ4Aは、INVITE のパケットを受信すると、100(Trying)の暫定応答のパケットをSIPサーバ1に送信する(S17)。
When the IBCF server 4A receives the INVITE packet, it sends a provisional response packet of 100 (Trying) to the SIP server 1 (S17).
そして、IBCFサーバ4Aは、INVITE のパケットにRecord-Routeヘッダを付与し、Record-Routeヘッダを付与したパケットを、後位のネットワーク装置(不図示)に転送する(S18)。すなわち、IBCFサーバ4Aは、通話中の後続のSIPメッセージが自身のIBCFサーバ4Aに届くように、受信したパケットにRecord-Routeヘッダを付与する(RFC3261準拠)。具体的には、IBCFサーバ4Aは、INVITEのパケットのRecord-Routeヘッダに、自身のアドレス(例えばIPアドレス等)を設定する。
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.
このRecord-Routeヘッダにより、例えば着信端末(不図示)などは、INVITEが転送されてきた経路を知ることができ、当該Record-Routeヘッダと同じ経路情報を含むRecord-Routeヘッダを設定した18x(例えば180:Ringing)の暫定応答のパケットを送信する。
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.
以降は、RFC3261に従って処理される。図示する例では、IBCFサーバ4Aは、Record-Routeヘッダが付与された18xのパケットを受信し(S19)、当該パケットをSIPサーバ1に転送する(S20)。SIPサーバ1は、Record-Routeヘッダが付与された18xの暫定応答のパケットを発信端末(不図示)に転送する。
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).
SIPサーバ1は、暫定応答に対する確認を要求するPRACK(SIPメッセージ)のパケットを送信する。ここでは、SIPサーバ1は、Record-Routeヘッダに基づいてRouteヘッダを生成し、生成したRouteヘッダをPRACKのパケットに付与する。Routeヘッダは、当該ヘッダに含まれる経路情報の装置を経由してSIPメッセージをルーチングさせるために使用される。図示する例では、Routeヘッダに、IBCFサーバ4Aのアドレスが含まれている。SIPサーバ1は、Routeヘッダを付与したPRACKのパケットを、L3SW2に送信する(S21)。
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).
L3SW2は、PRACKのパケットをいずれかのSLSPサーバ3Aに振り分ける(S22)。SLSPサーバ3Aは、Routeヘッダに基づいてPRACKのパケットをIBCFサーバ4Aに転送する(S23)。具体的には、SLSPサーバ3Aは、Routeヘッダ内に、IBCFサーバ4AのIPアドレス:IP1が付与されているため、Routeヘッダに従って当該パケットをIBCFサーバ4Aに転送する。
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.
図4は、IBCFサーバ4Aが保守停止時の接続処理を示すシーケンス図である。図示する通信システムの例では、図3と同様に、2つのSLSPサーバ3A、3Bと、2つのIBCFサーバ4A、4Bを備える。
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.
IBCFサーバ4Aを保守停止する際に、EMS5は、保守停止するIBCFサーバ4Aを除いた選択テーブル35をSLSPサーバ3A、3Bに提供する。各SLSPサーバ3A、3Bは、EMS5から選択テーブル35を取得し、記憶部34の選択テーブル35を更新する(S30)。これにより、SLSPサーバ3A、3Bは、停止されるIBCFサーバ4Aを選択しなくなる。したがって、本実施形態では、発信側の通信事業者網のSIP サーバ1において、停止されるIBCFサーバ4AへのSIPメッセージの送信を抑止する設定が不要となる。
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.
図4に示すS31~S34は、図3に示すS11~S14と同様であるため、ここでは、説明を省略する。SLSPサーバ3Aは、INVITEのパケットを受信し、当該パケットの転送先のIBCFサーバ4A、4Bを決定し、決定したIBCFサーバ4A、4BにINVITE を転送する(S35)。具体的には、SLSPサーバ3Aは、パケットに含まれるCall-IDを取得し、当該Call-IDに対応するIBCFサーバ4A、4Bを、選択テーブル35を用いて選択する。選択テーブル35には停止中のIBCFサーバ4Aが除外されているため、SLSPサーバ3Aは、IBCFサーバ4Bを選択する。
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.
同様に、SLSPサーバ3Bは、再送されたINVITEのパケットを受信し、選択テーブル35を用いて転送先のIBCFサーバ4Bを決定し、受信したパケットをIBCFサーバ4Bに転送する(S36)。
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).
IBCFサーバ4Bは、INVITEのパケットを受信すると、100(Trying)のパケットをSIPサーバ1に送信する(S37)。そして、IBCFサーバ4Bは、図3のS18と同様に、Record-Routeヘッダを付与したINVITEのパケットを後続の装置に転送する(S38)。Record-Routeヘッダには、経路情報として、IBCFサーバ4Bのアドレスが設定される。
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.
以降のS39~S43は、図3のS19~S23と同様であるため、ここでは説明を省略する。
Since S39 to S43 thereafter are the same as S19 to S23 in FIG. 3, description thereof is omitted here.
このように、本実施形態では、通話中のSIPメッセージは、Routeヘッダに従ってルーチングされるため、通話中の呼を継続することができる。すなわち、選択テーブル35には、停止中のIBCFサーバ4Aは除外されているため、IBCFサーバ4AにはINVITEのパケットは送信されず、通話中の呼に影響はない。
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.
図5は、SLSPサーバ3Aが故障時の接続処理を示すシーケンス図である。図示する通信ネットワークの例では、図3と同様に、2つのSLSPサーバ3A、3Bと、2つのIBCFサーバ4A、4Bを備える。
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.
図5に示すS50~S54は、図3に示すS10~S14と同様であるため、ここでは、説明を省略する。
Since S50 to S54 shown in FIG. 5 are the same as S10 to S14 shown in FIG. 3, their description is omitted here.
故障したSLSPサーバ3Aにパケットが送信された場合、当該パケットは破棄される。ここでは、故障したSLSPサーバ3Aは、S52でL3SW2から受信したINVITEのパケットを破棄する(S55)。SIPサーバ1のパケットの再送機能により、別のSLSPサーバ3Bへパケットが到達することを期待する。
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.
なお、L3SW2は、SLSPサーバ3Aに対するダウンリンク、BFD(Bidirectional Forwarding Detection)などのネットワーク障害を検出し、SLSPサーバ3Aへのパケットの転送を停止する。このように本実施形態では、いずれかのSLSPサーバ3Aが故障しても、通信を継続することができる。
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.
SLSPサーバ3Bは、S54で再送されたINVITEのパケットをL3SW2から受信する。SLSPサーバ3Bは、転送先のIBCFサーバ4Bを選択テーブル35を用いて選択し、選択したIBCFサーバ4BにINVITEのパケットを転送する(S56)。具体的には、SLSPサーバ3Bは、パケットに含まれるCall-IDを取得し、当該Call-IDに対応するIBCFサーバ4Bを、選択テーブル35を用いて選択する。
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.
以降のS57~S63は、図3のS17~S23と同様であるため、ここでは説明を省略する。
The subsequent S57 to S63 are the same as S17 to S23 in FIG. 3, so the description is omitted here.
以上説明した本実施形態の着信側の通信事業者網の負荷分散システムは、複数のSLSPサーバ3を備え、SLSPサーバ3は、転送先のIBCFサーバ4を選択するための選択テーブル35と、発信側の通信事業者網から送信されたパケット(メッセージ)の転送先のIBCFサーバ4を、選択テーブル35を用いて選択する選択部11と、選択したIBCFサーバ4に前記パケットを転送する転送部12と、を備え、選択テーブル35は、他のSLSPサーバ3と共通のテーブルであって、停止するIBCFサーバ4が除外されている。
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.
具体的には、本実施形態では、着信側の通信事業者網での負荷分散システムとして、IBCFサーバ4の前位にSIP状態を意識しない複数のSLSPサーバ3(ステートレスSIPプロキシサーバ)を設置し、各SLSPサーバ3はSIPメッセージのパケットの呼識別情報(Call-ID等)からIBCFサーバ4を決定するための選択テーブル35を保持し、選択テーブル35により転送先のIBCFサーバ4を決定する。
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.
これにより、複数の通信事業者網が相互接続された、SIPを用いた通信システムにおいて、N-ACT構成での負荷分散を可能としつつ、着信側の通信事業者網でのIBCFサーバ4の停止に対し、発信側の通信事業者網での停止するIBCFサーバ4への接続抑止を不要とすることができる。
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.
すなわち、着信側の通信事業者網でのIBCFサーバ4の停止に対し、着信側の選択テーブル35の設定変更だけで停止するIBCFサーバ4への接続抑止が可能となるため、発信側の通信事業者での接続抑止の処理が不要となる。
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.
また、本実施形態のL3SW2は、呼を意識せずにパケットを均等分散するため、最初のINVITEのパケットに関連する再送INVITEのパケットは、別のSLSPサーバ3に分かれて送信される場合があるが、各SLSPサーバ3は同じ選択テーブル35を保持しているため、同じ呼のパケットを同じIBCFサーバ4Aに転送することができる。
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.
上記説明したSLSPサーバ3は、例えば、図6に示すような汎用的なコンピュータシステムを用いることができる。図示するコンピュータシステムは、CPU(Central Processing Unit、プロセッサ)901と、メモリ902と、ストレージ903(HDD:Hard Disk Drive、SSD:Solid State Drive)と、通信装置904と、入力装置905と、出力装置906とを備える。メモリ902およびストレージ903は、記憶装置である。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、SLSPサーバ3の各機能が実現される。
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 .
また、SLSPサーバ3は、1つのコンピュータで実装されてもよく、あるいは複数のコンピュータで実装されても良い。また、SLSPサーバ3は、コンピュータに実装される仮想マシンであっても良い。
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.
SLSPサーバ3用のプログラムは、HDD、SSD、USB(Universal Serial Bus)メモリ、CD (Compact Disc)、DVD (Digital Versatile Disc)などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
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サーバ
2 :L3SW(転送装置)
3 :SLSPサーバ(プロキシサーバ)
31:選択部
32:転送部
33:取得部
34:記憶部
35:選択テーブル
4 :IBCFサーバ(SIPサーバ)
5 :EMS(装置管理システム) 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)
2 :L3SW(転送装置)
3 :SLSPサーバ(プロキシサーバ)
31:選択部
32:転送部
33:取得部
34:記憶部
35:選択テーブル
4 :IBCFサーバ(SIPサーバ)
5 :EMS(装置管理システム) 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 (7)
- 第1の通信事業者網の負荷分散システムであって、
複数のプロキシサーバを備え、前記プロキシサーバは、
転送先のSIPサーバを選択するための選択テーブルと、
第2の通信事業者網から送信されたメッセージの転送先のSIPサーバを、前記選択テーブルを用いて選択する選択部と、
前記選択したSIPサーバに前記メッセージを転送する転送部と、を備え、
前記選択テーブルは、他のプロキシサーバと共通のテーブルであって、停止するSIPサーバが除外されている
負荷分散システム。 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. - 前記プロキシサーバは、ステートレスSIPプロキシサーバである
請求項1に記載の負荷分散システム。 The load balancing system according to claim 1, wherein said proxy server is a stateless SIP proxy server. - 前記選択部は、前記メッセージに含まれる呼識別情報に対応する転送先のSIPサーバを、前記選択テーブルを用いて選択する
請求項1または2に記載の負荷分散システム。 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. - 前記転送部は、転送先のSIPサーバが付与したRecord-Routeヘッダに基づいて、前記SIPサーバにメッセージを転送する
請求項1から3のいずれか1項に記載の負荷分散システム。 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. - 装置管理システムから、前記選択テーブルを取得する取得部を、備える
請求項1から4のいずれか1項に記載の負荷分散システム。 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. - 第1の通信事業者網の負荷分散システムが行う負荷分散方法であって、
前記負荷分散システムは、複数のプロキシサーバを備え、前記プロキシサーバは、
転送先のSIPサーバを選択するための選択テーブルを保持するステップと、
第2の通信事業者網から送信されたメッセージの転送先のSIPサーバを、前記選択テーブルを用いて選択するステップと、
前記選択したSIPサーバに前記メッセージを転送するステップと、を行い、
前記選択テーブルは、他のプロキシサーバと共通のテーブルであって、停止するSIPサーバが除外されている
負荷分散方法。 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. - 請求項1から5のいずれか1項に記載のプロキシサーバとしてコンピュータを機能させる負荷分散プログラム。 A load balancing program that causes a computer to function as the proxy server according to any one of claims 1 to 5.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2021/024577 WO2023276001A1 (en) | 2021-06-29 | 2021-06-29 | Load balancing system, load balancing method, load balancing program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2021/024577 WO2023276001A1 (en) | 2021-06-29 | 2021-06-29 | Load balancing system, load balancing method, load balancing program |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023276001A1 true WO2023276001A1 (en) | 2023-01-05 |
Family
ID=84691590
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2021/024577 WO2023276001A1 (en) | 2021-06-29 | 2021-06-29 | Load balancing system, load balancing method, load balancing program |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2023276001A1 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060036747A1 (en) * | 2004-07-28 | 2006-02-16 | Galvin James P Jr | System and method for resource handling of SIP messaging |
JP2010003273A (en) * | 2008-06-23 | 2010-01-07 | Nippon Telegr & Teleph Corp <Ntt> | Sip message distribution method and sip message distribution device |
US20200120176A1 (en) * | 2018-10-12 | 2020-04-16 | Metaswitch Networks Ltd. | Proxying session initiation protocol (sip) communications |
-
2021
- 2021-06-29 WO PCT/JP2021/024577 patent/WO2023276001A1/en active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060036747A1 (en) * | 2004-07-28 | 2006-02-16 | Galvin James P Jr | System and method for resource handling of SIP messaging |
JP2010003273A (en) * | 2008-06-23 | 2010-01-07 | Nippon Telegr & Teleph Corp <Ntt> | Sip message distribution method and sip message distribution device |
US20200120176A1 (en) * | 2018-10-12 | 2020-04-16 | Metaswitch Networks Ltd. | Proxying session initiation protocol (sip) communications |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9602591B2 (en) | Managing TCP anycast requests | |
US8825867B2 (en) | Two level packet distribution with stateless first level packet distribution to a group of servers and stateful second level packet distribution to a server within the group | |
US9762494B1 (en) | Flow distribution table for packet flow load balancing | |
US8775628B2 (en) | Load balancing for SIP services | |
JP5436451B2 (en) | Communication terminal, communication method, program | |
JP5164953B2 (en) | Internetwork equipment | |
US8369323B1 (en) | Managing voice-based data communications within a clustered network environment | |
WO2008047920A1 (en) | Proxy server, communication system, communication method, and program | |
WO2012041604A1 (en) | Aggregation of mobile broadband network interfaces | |
US11895009B2 (en) | Intelligently routing internet traffic | |
US8972586B2 (en) | Bypassing or redirecting a communication based on the failure of an inserted application | |
JP5941434B2 (en) | Cluster system of session border controller, cluster system of application server, and SIP dialog generation method thereof | |
US11218517B2 (en) | Media gateway | |
US20080205607A1 (en) | Server for transferring a communication message | |
WO2009049538A1 (en) | Monitoring method, device and system | |
JP4868608B2 (en) | Route control method and system for dynamically switching routes consisting of a plurality of session management servers | |
WO2023276001A1 (en) | Load balancing system, load balancing method, load balancing program | |
JPWO2018207884A1 (en) | Gateway device, message transmission method and program | |
US20240171641A1 (en) | Data service management of proxy devices | |
KR101310449B1 (en) | System and method for distributing sip message | |
JP5219967B2 (en) | Internetwork equipment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 21948309 Country of ref document: EP Kind code of ref document: A1 |