WO2023276001A1 - Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge - Google Patents

Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge Download PDF

Info

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
Application number
PCT/JP2021/024577
Other languages
English (en)
Japanese (ja)
Inventor
篤 蓮沼
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/024577 priority Critical patent/WO2023276001A1/fr
Publication of WO2023276001A1 publication Critical patent/WO2023276001A1/fr

Links

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

Ce système d'équilibrage de charge d'un premier réseau porteur de communication est pourvu de multiples serveurs mandataires 3. Les serveurs mandataires 3 sont pourvus d'une table de sélection 35 pour sélectionner un serveur SIP de destination d'acheminement, une unité de sélection 31 qui utilise la table de sélection 35 pour sélectionner un serveur SIP 4 auquel transmettre des messages reçus en provenance d'un second réseau porteur de communication, et une unité de transfert 32 qui transmet les messages susmentionnés au serveur SIP sélectionné, la table de sélection 35 étant partagée avec l'autre serveur mandataire 3, et excluant les serveurs SIP 4 qui sont arrêtés.
PCT/JP2021/024577 2021-06-29 2021-06-29 Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge WO2023276001A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/024577 WO2023276001A1 (fr) 2021-06-29 2021-06-29 Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/024577 WO2023276001A1 (fr) 2021-06-29 2021-06-29 Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge

Publications (1)

Publication Number Publication Date
WO2023276001A1 true WO2023276001A1 (fr) 2023-01-05

Family

ID=84691590

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/024577 WO2023276001A1 (fr) 2021-06-29 2021-06-29 Système d'équilibrage de charge, procédé d'équilibrage de charge, programme d'équilibrage de charge

Country Status (1)

Country Link
WO (1) WO2023276001A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
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 (ja) * 2008-06-23 2010-01-07 Nippon Telegr & Teleph Corp <Ntt> Ｓｉｐメッセージ振分方法およびｓｉｐメッセージ振分装置
US20200120176A1 (en) * 2018-10-12 2020-04-16 Metaswitch Networks Ltd. Proxying session initiation protocol (sip) communications

Patent Citations (3)

* Cited by examiner, † Cited by third party
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 (ja) * 2008-06-23 2010-01-07 Nippon Telegr & Teleph Corp <Ntt> Ｓｉｐメッセージ振分方法およびｓｉｐメッセージ振分装置
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 (ja) 通信端末、通信方法、プログラム
JP5164953B2 (ja) インタネットワーク装置
US8369323B1 (en) Managing voice-based data communications within a clustered network environment
WO2008047920A1 (fr) Serveur proxy, système et procédé de communication et programme
WO2012041604A1 (fr) Agrégation d&#39;interfaces d&#39;un réseau à large bande mobile
US10356138B2 (en) Method and nodes for configuring a communication path for a media service
US11895009B2 (en) Intelligently routing internet traffic
US8972586B2 (en) Bypassing or redirecting a communication based on the failure of an inserted application
JP5941434B2 (ja) セッション・ボーダ・コントローラのクラスタシステム、アプリケーション・サーバのクラスタシステム、および、そのｓｉｐダイアログ生成方法
US11218517B2 (en) Media gateway
US20080205607A1 (en) Server for transferring a communication message
WO2009049538A1 (fr) Procédé, dispositif et système de surveillance
JP4868608B2 (ja) 複数のセッション管理サーバからなる経路を動的に切り替える経路制御方法及びシステム
WO2023276001A1 (fr) Système d&#39;équilibrage de charge, procédé d&#39;équilibrage de charge, programme d&#39;équilibrage de charge
JPWO2018207884A1 (ja) ゲートウェイ装置、メッセージの送信方法及びプログラム
US20240171641A1 (en) Data service management of proxy devices
KR101310449B1 (ko) Ｓｉｐ 메시지의 분배 시스템 및 그 방법
JP5219967B2 (ja) インタネットワーク装置

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