Methods, systems, and computer-readable media for load sharing of class 1 signaling connection control part (SCCP) messages

Abstract

A method for load balancing Type 1 SCCP messages includes receiving Type 1 SCCP messages requiring Global Code Translation (GTT). The method includes performing GTT on the message to select a load-sharing group for the message. The method further includes generating a Message Signaling Unit (MSU) load-sharing key using parameters derived from a combination of Message Transfer Part (MTP) layer parameters and Signaling Connection Control Part (SCCP) layer parameters. The method also includes using the MSU load-sharing key to select a destination address for the message from the load-sharing group. The method further includes inserting the destination address into the message. Finally, the method includes routing the message to the destination corresponding to the destination address.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 095,400, filed November 1, 2020, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The topics described in this document relate to load sharing of SS7 messages. More specifically, the topics described in this document relate to methods, systems, and computer-readable media for load sharing of class 1 SCCP messages. Background Technology

[0004] In SS7 signaling networks, the Signalling Connection Control Part (SCCP) is used to access databases and other services. Specifically, SCCP is used by the Mobile Application Part (MAP), the Transaction Capability Application Part (TCAP), and other Level 4 protocols to transmit application-level information. SCCP services are divided into five classes: Class 0, which provides basic connectionless service; Class 1, which provides ordered connectionless service; Class 2, which provides basic connection-oriented service; Class 3, which provides flow control-oriented service; and Class 4, which provides error recovery and flow control-oriented service. Currently, Classes 2, 3, and 4 are not used in telecommunications networks. Both Classes 0 and 1 are used. Class 0 provides basic transmission of TCAP and other application-layer messages when ordering is not required. Class 1 is used to provide ordered service in any case where there are more than one SCCP message for a transaction.

[0005] SCCP processing can be performed at any node in the signaling network. Typically, SCCP routing functions such as global title translation (GCR) are performed at the signal transfer point (STP). SCCP routing at the STP allows the serving exchange point to send messages to the STP, where the messages are GCR-translated and routed to their intended destination. GCR converts SCCP-level information into point codes and subsystem numbers that can be used to route messages to their destinations. Parameters other than SCCP-level information, such as the originating point code (OPC), can also be used for GCR.

[0006] Many network operators provide redundant database nodes offering the same service within their networks and load-balance messages among these redundant nodes. An example of a frequently redundantly provided database node is the Home Location Register (HLR). The HLR stores subscription information for mobile subscribers and is contacted each time a home subscriber registers at a new location to obtain routing information, thus routing call and short message service (SMS) messages to the mobile subscriber.

[0007] As the number of subscribers in the network increases, the number of HLRs may also increase, and network operators may want to distribute database processing across multiple HLRs. Load balancing at the STP can be used to achieve load balancing across multiple HLRs or other database nodes. Class 0 SCCP messages are relatively easy to load balance because Class 0 messages carry single-message transactions, such as database queries. In other words, different Class 0 SCCP messages are associated with different transactions, and therefore can be load balanced among the database nodes handling the transaction, regardless of the database nodes to which other Class 0 SCCP messages are routed.

[0008] Compared to Class 0 SCCP messages, Class 1 SCCP messages are used when there are more than one TCAP transaction carried by a Class 1 SCCP message. Load sharing of Class 1 SCCP messages can be performed across database nodes. However, load sharing must be performed in a way that routes SCCP messages that are part of the same transaction to the same database node. Existing methods for load sharing Class 1 SCCP messages across database nodes utilize MTP, SCCP, or TCAP parameters to define a load sharing key for Class 1 SCCP messages. Each of these methods has one or more problems. For example, using the SCCP called party address as the load sharing key results in all messages with the same called party address being routed to the same database node. Routing all messages with the same called party address to the same database node can overload one database node while other database nodes are underutilized.

[0009] Using TCAP transaction IDs to load balance type 1 SCCP messages across database nodes may not be effective because some type 1 SCCP messages (such as TCAP END messages) will not have a TCAP initiator transaction ID. As a result, TCAP END messages may be routed to different database nodes relative to other messages associated with the same TCAP transaction.

[0010] In another example, MTP OPC and Signaling Link Selector (SLS) can be used for load balancing of Class 1 SCCP messages. For effective load balancing to be achieved using MTP OPC and SLS, the OPC and SLS values ​​must differ. In some cases, such as when a large number of messages originate from the same Mobile Switching Center (MSC) and therefore have the same OPC, the OPC values ​​will not differ significantly. Given that load balancing algorithms rely on OPC, messages with the same OPC will tend to be routed to the same destination node, resulting in uneven load balancing. In one example where the load balancing key is based on the parameters mentioned above, a 300% traffic difference occurred between the node receiving the most traffic and the node receiving the least traffic.

[0011] Given these and other challenges, there is a need for improved methods and non-transitory computer-readable media for load balancing of Class 1 SCCP messages. Summary of the Invention

[0012] A method for load balancing Type 1 Signaling Connection Control Part (SCCP) messages includes receiving a Type 1 SCCP message requiring Global Code Translation (GTT). The method further includes performing GTT on the message to select a load-sharing group for the message. The method also includes generating a Message Signalling Unit (MSU) load-sharing key using parameters derived from a combination of Message Transfer Part (MTP) layer parameters and Signaling Connection Control Part (SCCP) layer parameters. The method further includes using the MSU load-sharing key to select a destination address for the message from the load-sharing group. The method also includes inserting the destination address into the message. Finally, the method includes routing the message to a destination corresponding to the destination address.

[0013] According to another aspect of the subject described in this article, receiving a Type 1 SCCP message that requires GTT includes receiving a Type 1 SCCP message at the SS7 signaling transfer point (STP).

[0014] According to another aspect of the subject described herein, receiving a Type 1 SCCP message requiring GTT includes receiving a Type 1 SCCP message from a Mobile Switching Center (MSC).

[0015] According to another aspect of the subject described herein, generating the MSU load-sharing key using MTP layer parameters and SCCP layer parameters includes generating the MSU load-sharing key using the called party global code (CdGT), source point code (OPC), and signaling link selector (SLS) from the message.

[0016] According to another aspect of the subject described herein, generating an MSU load-sharing key using CdGT, OPC, and SLS from the message involves generating the MSU load-sharing key by searching an array of pseudo-randomly generated values ​​derived from CdGT, OPC, and SLS and calculating the MSU load-sharing key based on the values ​​obtained from the search.

[0017] According to another aspect of the subject described herein, an MSU load-sharing key is generated by searching an array of pseudo-randomly generated values ​​derived from CdGT, OPC, and SLS and calculating the MSU load-sharing key based on the values ​​obtained from the search. Generating the MSU load-sharing key involves using the following equation:

[0018] Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in the array, OPC is the OPC from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the SLS from the message, SLSArray is an array of pseudo-randomly generated values, CdGT is the called party global code from the message, and Max_Dests is the maximum number of destinations used for load balancing.

[0019] According to another aspect of the topic described in this article, generating MSU load-sharing keys using CdGT, OPC, and SLS involves generating MSU load-sharing keys by calculating values ​​based on CdGT and then using OPC and SLS to look up values ​​in an array of pseudo-randomly generated values.

[0020] According to another aspect of the topic described in this article, generating MSU load-sharing keys using CdGT, OPC, and SLS includes generating MSU load-sharing keys by calculating values ​​based on CdGT and using OPC and SLS to look up values ​​in an array of pseudo-randomly generated values. It also includes generating MSU load-sharing keys using the following equation:

[0021] Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in an array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, and CdGT is the called party global code from the message.

[0022] According to another aspect of the topic described in this article, using MTP and SCCP parameters to generate MSU load sharing keys includes generating the same MSU load sharing key for Class 1 SCCP messages that are part of the same Transaction Capability Application Part (TCAP) transaction.

[0023] According to another aspect of the subject described herein, routing the message to a destination corresponding to the destination address includes routing the message to a Home Location Register (HLR).

[0024] According to another aspect of the subject matter described herein, a system for load balancing Type 1 Signaling Connection Control Part (SCCP) messages is provided. The system includes an SS7 Signaling Transfer Point (STP), which includes at least one processor and a memory. The system also includes a Type 1 SCCP load balancing module implemented by the at least one processor, configured to: receive a Type 1 SCCP message requiring Global Code Translation (GTT); perform GTT on the message to select a load balancing group for the message; generate a Message Signaling Unit (MSU) load balancing key using parameters derived from a combination of Message Transfer Part (MTP) layer parameters and Signaling Connection Control Part (SCCP) layer parameters; use the MSU load balancing key to select a destination address for the message from the load balancing group; and insert the destination address into the message. The system further includes a routing module implemented by the at least one processor, configured to route the message to a destination corresponding to the destination address.

[0025] According to another aspect of the subject described herein, the Type 1 SCCP message originates from the Mobile Switching Center (MSC).

[0026] According to another aspect of the subject matter described herein, the Type 1 SCCP load-sharing module is configured to generate an MSU load-sharing key using the called party global code (CdGT), source point code (OPC), and signaling link selector (SLS) from the message.

[0027] According to another aspect of the subject matter described herein, the Type 1 SCCP load-sharing module is configured to generate an MSU load-sharing key by searching an array of pseudo-randomly generated values ​​derived from CdGT, OPC, and SLS and calculating an MSU load-sharing key based on the values ​​obtained from the search.

[0028] According to another aspect of the subject matter described herein, the Type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key using the following equation:

[0029] Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in the array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, CdGT is the called party global code from the message, and Max_Dests is the maximum number of destinations used for load balancing.

[0030] According to another aspect of the subject matter described herein, the Type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key by calculating a value based on CdGT and using OPC and SLS to search an array of pseudo-randomly generated values.

[0031] According to another aspect of the subject matter described herein, the Type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key using the following equation:

[0032] Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in an array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, and CdGT is the called party global code from the message.

[0033] According to another aspect of the subject described herein, the Type 1 SCCP load-sharing module is configured to generate the same MSU load-sharing key for Type 1 SCCP messages that are part of the same Transaction Capability Application Part (TCAP) transaction.

[0034] According to another aspect of the subject described in this article, the destination includes the Home Location Register (HLR).

[0035] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided on which executable instructions are stored, which, when executed by a computer's processor, control the computer to perform steps. The steps include receiving a Type 1 Signaling Connection Control Part (SCCP) message requiring Global Code Translation (GTT). The steps also include performing GTT on the message to select a load-sharing group for the message. The steps further include generating a Message Signaling Unit (MSU) load-sharing key using parameters derived from a combination of Message Transfer Part (MTP) layer parameters and SCCP layer parameters. The steps also include using the MSU load-sharing key to select a destination address for the message from the load-sharing group. The steps further include inserting the destination address into the message. The steps also include routing the message to a destination corresponding to the destination address.

[0036] The subject matter described herein can be implemented using hardware, software, firmware, or any combination thereof. Therefore, as used herein, the terms “function,” “node,” or “module” refer to hardware used to implement the described features, which may also include software and / or firmware components. In one exemplary implementation, the subject matter described herein can be implemented using a computer-readable medium having computer-executable instructions stored thereon, which, when executed by a computer’s processor, control the computer to perform steps such as any one or more steps performed by the present invention. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subject matter described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0037] The subject matter described herein will now be explained with reference to the accompanying drawings, in which: Figure 1 This is a protocol layer diagram illustrating the protocol layers that can be used by SS7 message signaling units for transmission through a traditional TDM-based SS7 signaling link; Figure 2 This is a protocol layer diagram illustrating an exemplary protocol layer that can be used by SS7 message signaling units for transmission over an IP-based signaling link; Figure 3A and Figure 3B The diagrams illustrate the routing label and signaling link selection field of the SS7 message. Figure 4 This is a diagram illustrating exemplary fields that may be included in the SCCP section of a message; Figure 5 This is a block diagram illustrating an exemplary architecture for the signaling point that implements load balancing for a type 1 SCCP message; Figure 6 This is a block diagram of an exemplary detailed architecture for a signaling point capable of load balancing a type 1 SCCP message; Figure 7A This is a diagram illustrating the load sharing of a type 1 SCCP message using the first load sharing algorithm described in this document; Figure 7B This is a diagram illustrating load sharing of a type 1 SCCP message using the first load-sharing algorithm described herein; and Figure 8 This is a flowchart illustrating an exemplary process for load balancing of Type 1 SCCP messages. Detailed Implementation

[0038] The topics described herein relate to methods, systems, and computer-readable media for load balancing of Type 1 SCCP messages. As mentioned above, conventional methods that rely solely on MTP level parameters, SCCP parameters, or TCAP parameters cannot achieve the distribution of Type 1 SCCP messages with acceptable levels of traffic load variation. The topics described herein achieve load balancing of Type 1 SCCP messages with reduced traffic variation between network nodes while ensuring that Type 1 SCCP messages related to the same transaction are routed to the same destination node. In one example, such load balancing is achieved by using the SCCP Called Party Global Code (CdGT) parameter in conjunction with the MTP Level 3 Signaling Link Selector (SLS) and MTP Level 3 Source Point Code (OPC) to generate an MSU load balancing key. The MSU load balancing key is used to select a destination address for the message, and the message is routed to that destination address.

[0039] Figure 1 This diagram illustrates an exemplary protocol layer that can be used to transmit SS7 messages over a conventional Time Division Multiplexing (TDM) based SS7 signaling link. Each protocol layer corresponds to the part of the SS7 message used by the corresponding protocol to implement message transmission. Figure 1 In the SS7 protocol stack, the protocol layers include Message Passing Part 1 (MTP1) 100, Message Passing Part 2 (MTP2) 102, and Message Passing Part 3 (MPT3) 104. MTP1 100 performs physical layer functions, such as transmitting messages over physical links. MTP2 102 is the data link level of the SS7 protocol stack and performs functions such as error detection, error correction, and ordered delivery of SS7 messages. MTP3 104 performs routing of SS7 message signaling units.

[0040] As mentioned above, Figure 1 Each protocol layer in the SS7 message corresponds to a portion of the message. Each protocol layer includes various parameters used by the receiving node to process the message. One such parameter is the routing label, which exists in the MTP3 portion of the message and includes parameters that can be used for load balancing of Type 1 SCCP messages, such as the source point code (OPC) and destination point code (DPC) and the signaling link selector (SLS).

[0041] Figure 1 The protocol layer also includes the Signaling Connection Control Part (SCCP) 106. SCCP 106 includes the Called Party Global Code (CdGT), which can also be used in conjunction with MTP Level 3 parameters for load balancing, as will be described in detail below.

[0042] Figure 1 The protocol layer also includes the Transaction Capability Application Part (TCAP) 108 and the Mobile Application Part (MAP) 110. TCAP 108 performs transaction-based functions, such as communicating with database nodes. MAP 110 is the application layer that performs functions such as updating the location of mobile subscribers to the Home Location Register (HLR) and obtaining the location of mobile subscribers from the HLR.

[0043] In most networks today, SS7 messages are transmitted via IP-based signaling links, rather than via TDM-based signaling links that rely on MTP Level 1 and Level 2. Figure 2 The diagram illustrates an exemplary protocol layer that can be used to transmit SS7 messages over an IP network. Instead of MTP Levels 1 and 2, Figure 2 The protocol layers in the OSI model include Open Systems Interconnection (OSI) Level 1 200 and OSI Level 2 202, which perform functions similar to those of MTP Levels 1 and 2. However, different protocols are used. For example, in an IP network, IP Level 2 can be implemented using Ethernet. OSI Level 1 can be implemented using any suitable physical layer protocol.

[0044] Figure 2 The protocol layer also includes IP layer 204, which performs IP networking functions, and Stream Control Transmission Protocol (SCTP) layer 206, which provides transport-level connectivity between SS7 nodes. Figure 2 The protocol layer also includes an MTP3 User Adaptation (M3UA) layer 208 that enables the transmission of SS7 messages over the underlying IP network. The M3UA layer 208 also performs MTP Level 3 functions, such as dot-code based routing.

[0045] Figure 2 The remaining protocol layers and corresponding message structures in Figure 1Those are the same. As a result, when the underlying transport layer is as follows... Figure 1 The example shown is based on SS7 or as follows Figure 2 As shown in the IP-based example, the SCCP load balancing algorithm described in this paper can be used to load balance Class 1 SCCP messages.

[0046] As mentioned above, a set of parameters that may be useful when performing load balancing for Type 1 SCCP parameters is the OPC and SLS parameters located in the MTP Level 3 section of the SS7 message. Figure 3A and Figure 3B The diagrams illustrate the MTP3 portion of an SS7 message and its routing label, which contains both SLS and OPC values. (See reference...) Figure 3A The MTP3 portion 300 of the message includes a signaling information field 302 and a service indicator octet 304. The signaling information field 302 is divided into user data 306 and a routing label 308. The routing label 308 is further divided into a signaling link selection (SLS) field 310, a source point code field 312, and a destination point code field 314. As will be described in detail below, the value derived from the value stored in the SLS field 310 can be used in conjunction with other parameters to generate a load-sharing key for load-sharing of Class 1 SCCP messages.

[0047] Figure 3B The illustration shows details of the bits in the SLS, OPC, and DPC fields of the routing label for an SS7 message in the International Telecommunication Union (ITU) format. It should be noted that although the message format shown in 3B is the ITU SS7 message format, the load-sharing algorithms described herein can be used with other SS7 message formats without departing from the scope of the topics described herein. For example, the load-sharing algorithms described herein can also be used with the American National Standards Institute (ANSI) SS7 message format where the SLS is 5 bits or 8 bits.

[0048] Figure 4 The diagram illustrates the portion of an SCCP message that contains the global code digits or address. (See reference...) Figure 4The SCCP portion of the message includes an address indicator 400, which contains various indicators regarding the type of SCCP address included in the SCCP portion of the message and the type of SCCP routing performed. In the illustrated example, the address indicator 400 includes a dot code indicator 402, a subsystem number indicator 404, a global code indicator 406, and a routing indicator 408. The dot code indicator 402 indicates whether a dot code exists in the SCCP address. The SSN indicator 404 indicates whether an SSN exists in the SCCP address. The global code indicator 406 indicates whether a global code address exists, and if so, indicates the type of global code address. The routing indicator 408 indicates the type of routing to be performed on the SCCP message (global code-based routing or dot code and subsystem number-based routing).

[0049] Dot code 410 stores the SS7 node. Subsystem number 412 stores a value indicating the application or subsystem to which the message is destined. Transition type 414 is a 1-byte parameter used to set whether an intermediate or final global code conversion will be performed. Numbering scheme 416 indicates the number type of the global code address.

[0050] Encoding scheme 418 indicates how the bits of the global code address are encoded. For example, a commonly used encoding scheme is binary-coded decimal (BCD). Property 420 of the address indicator indicates the type of number represented by the bits, such as national or international. Bit 422 is the called party global code, which is another parameter among those used in the algorithm described herein for load balancing of Class 1 SCCP messages.

[0051] Figure 5 This is a network diagram of STP capable of load balancing Type 1 SCCP messages. (Refer to...) Figure 5 The STP 500 includes at least one processor 502 and memory 504. Although the detailed internal architecture of the STP 500 will be described below, in the illustrated example, the functions performing the steps described herein for load balancing of Type 1 SCCP messages are the SCCP Type 1 load balancing module 506 and the routing module 508. The SCCP load balancing module 506 uses values ​​derived from various message parameters to access the load balancing array 509 to select a destination address for a received Type 1 SCCP message and insert that destination address into the message. The routing module 508 routes the message to the outbound signaling link associated with the destination.

[0052] In the illustrated example and Figure 5In this network, MSCs 510, 512, and 514, and HLRs 516, 518, 520, and 522, are involved. MSCs 510, 512, and 514 initiate Type 1 SCCP messages destined for HLRs 516, 518, 520, and 522. STP 500 load-distributes these Type 1 SCCP messages based on a combination of OPC, SLS, and CdGT. This load-distribution by STP 500 ensures that messages related to the same transaction are distributed and routed to the same HLR. For example, an SCCP message originating from MSC1 might include OPC 1, SLS X, and CdGT A. Such a message would be load-distributed by STP 500 to one of HLRs 516, 518, 520, and 522. Additional messages related to the same transaction from MSC1 should be routed to the same HLR. Similarly, a message from MSC2 512 might have OPC 2, SLS Y, and CdGT B. Such messages will be load-distributed by STP 500 to one of HLRs 516, 518, 520, and 522, and may be load-distributed to a different HLR than messages originating from MSC1 510. Similar load-distribution is performed based on messages from MSC3 514, as these messages may include different parameters than messages originating from MSCs 510 and 512.

[0053] It should be understood that, Figure 5 The message parameters in the table are for illustrative purposes and may include different combinations of parameters in a Class 1 SCCP message originating from the same MSC. For example, the OPC in a message originating from a given MSC will be the same. However, the CdGT may vary depending on the message type and the identity of the mobile device to which the message is being sent.

[0054] Figure 6 This is a block diagram illustrating an exemplary internal architecture of the STP 500. (Refer to...) Figure 6 The STP 500 includes multiple message processors 600, 602, 604, and 606. Each message processor 600, 602, 604, and 606 may be a printed circuit board including at least one processor 502 and a memory 504. Message processors 600, 602, 604, and 606 may be interconnected via an inter-processor message transmission medium 607. In one example, the inter-processor message transmission medium 607 may be a backplane connector, and Ethernet may be a data link layer transport protocol used for transmitting messages between message processors 600, 602, 604, and 606.

[0055] Message processors 600 and 602 each include a SIGTRAN layer 608 and an SS7 layer 610. SIGTRAN layer 608 adapts SS7 messages for IP transport. In alternative implementations, either SIGTRAN layer 608 can be replaced by MTP Level 1 and Level 2 without departing from the scope of the subject matter described herein. SS7 layer 610 performs message discrimination to determine whether a received message requires further STP processing or if the message simply needs to be routed. For messages routed based on global codes, SS7 layer 610 forwards the message to one of message processors 604 and 606 for further processing by STP 500. If the message only requires routing, SS7 layer 610 routes the message to a message processor associated with one of the outbound signaling links 612 and 614.

[0056] Message processors 604 and 606 each include an SCCP Class 1 load balancing module 506 for load balancing of Class 1 SCCP messages and a routing module 508 for routing messages after load balancing and associated global code conversion processing.

[0057] exist Figure 6 In the message flow shown, in step 1, message processor 602 receives an SS7 message with OPC, SLS, and CdGT based on global code routing. In step 2, the SS7 layer 610 of message processor 602 forwards the message to message processor 606 for global code translation processing. In step 3, load balancing module 506 on message processor 606 performs global code translation processing, which includes performing a GTT lookup in a GTT table or array using the CdGT in the message to identify the load balancing group corresponding to the destination address array for the message, generating an MSU load balancing key for the SS7 message, using the MSU load balancing key to perform a lookup in the destination address array for the load balancing group to select a destination point code for the message, and inserting the destination point code into the message. As used herein, a load balancing group is a set of destination addresses corresponding to network nodes capable of processing a given message. For example, a network operator can configure load balancing groups for a set of HLRs in the operator's network that can process messages related to the mobility of the operator's subscribers. Load balancing groups can be implemented using an array of destination addresses that contain the addresses of the load balancing groups.

[0058] In step 4, the routing module 508 of message processor 606 routes the message to a message processor associated with an outbound signaling link, which is selected based on the destination point code in the message after global code conversion. In step 5, the message processor 600 associated with outbound signaling link 612 sends the message to its destination via outbound signaling link 612.

[0059] As described above, load balancing module 506 performs load balancing of Class 1 SCCP messages in a manner that increases the uniformity of SCCP message distribution among destination nodes and ensures that messages related to the same transaction are routed to the same node. In one approach, load balancing module 506 uses values ​​derived from OPC, SLS, and CdGT to look up values ​​in an array of pseudo-randomly generated values ​​(e.g., generated using a random number generation function). In one example, the algorithm is as follows: (1)

[0060] In Equation 1 above, MSUKEY is the MSU load-sharing key used for lookup in the destination array. MOD is a modulo function that returns the remainder when the first argument of a function is divided by the second argument. For example, in Equation 1, MOD(OPC, 100) returns the remainder when the OPC value in the message is divided by 100. Equation 1 is configured for load balancing of up to 100 destinations. To extend Equation 1 to an arbitrary number of destinations, the constant 100 can be replaced by Max_Dests, which indicates the maximum number of load-sharing destinations, as shown in Equation 2 below: (2)

[0061] Continuing with the explanation of Equations 1 and 2, the function VLOOKUP(x,y) returns the value stored at element x in array y. For example, in Equation 1, the function MOD(OPC, 100), OPCArray, returns the value at element (MOD(OPC, 100)) in the OPC array. The OPC array is an array of size Max_Dests, which is 100 in this example. Each element in the array stores the value used to calculate the MSU key. In one example, the values ​​stored in the array could each be pseudo-randomly generated numbers within the range [0, Max_Dests-1]. Table 1 below shows an example of an OPC array used for load balancing across 100 destination nodes.

[0062]

[0063] …

[0064] Table 1: Example OPC Array

[0065] For simplicity, rows 18-90 are omitted from the OPC array. In Table 1, the first column is the array index, the second column contains pseudo-random values ​​between 0 and 99 in decimal representation stored at each array index, and the third column contains the values ​​of the second column in hexadecimal representation. Therefore, the result of the item VLOOKUP(MOD(OPC, 100),OPCArray) is a pseudo-randomly generated value between 0 and 99 selected based on the value derived from the OPC in the message. For example, if the OPC in the message is 11392 (decimal), then MOD(11392,100) returns 92. The value of VLOOKUP(92,OPCArray) is 58 or 3a in hexadecimal.

[0066] Continuing with the second term in Equation 1, VLOOKUP(SLS, SLSArray) uses the value of SLS from the received message to look up the value in SLSArray. According to... Figure 3B SLS is a 4-bit value, meaning there are 16 possible SLS values. Therefore, an SLS array can be an array of size 16 that uses the SLS as a lookup key to return one of the 16 possible pseudo-random values. Table 2 shows an example of an SLS array for ITU networks with a 4-bit SLS. In ANSI networks with an 8-bit SLS, the SLS array would consist of 2^8 or 256 bits.

[0067]

[0068] Table 2: Example SLS arrays

[0069] In Table 2, the first column contains array indices, each corresponding to one of 16 possible SLS values. The second column contains pseudo-randomly generated values ​​stored in the array elements. Therefore, if the SLS value is 0, VLOOKUP(0,SLSArray) will return 60.

[0070] The next term in Equation 1 is VLOOKUP(MOD(CdGT, 100), OPCArray). This term is a lookup based on the value derived from CdGT in the message. Since the output of XMODY has Y-1 possible values ​​ranging from 0 to Y, the value of CdGTMOD(100) is a number based on CdGT ranging from 0 to 99. Depending on the message type, the called party global code can be either the routing number corresponding to the HLR or the B-party (called party) number. Assuming the called party in the message is 12345600, the last term in Equation 1 will return the following value: VLOOKUP(MOD(12345600(100), OPCArray) =VLOOKUP(0,OPCArray) =55 As can be seen from Equations 1 and 2, the same arrays are used for lookups using values ​​derived from OPC and CdGT. However, the subject matter described herein is not limited to using the same arrays for these lookups. In an alternative implementation, a first array of pseudo-randomly generated values ​​can be used to look up values ​​derived from OPC in the message, and a second array of pseudo-randomly generated values, different from the first array, can be used to look up values ​​derived from CdGT in the message.

[0071] The terms within the outermost parentheses in Equation 1 are added together, and this sum forms the first term in the outermost MOD function. Continuing the example above, the three array lookups (OPC, SLS, and CdGT) return values ​​of 58, 60, and 55, respectively. The sum of these three terms is 173. The second term of the outermost MOD operation is 100, the maximum number of destinations used for load balancing. Therefore, the outermost MOD function calculates a number between 0 and 99, which can be used for lookups in the destination address table. Continuing the example, MOD(173,100) has a value of 73, so the MSU key value of 73 will be used to look up the destination address array for the load-sharing group identified in the GTT lookup:

[0072] …

[0073] …

[0074] Table 3: Example Destination Address Array

[0075] A lookup in the destination address array using MSU key 73 as the lookup key returns a 2-2-0 destination location code. SCCP Class 1 load balancing module 506 inserts the destination location code from the destination address array into the message. Routing module 508 uses the DPC value to look up the MTP Level 3 or M3UA routing table, selects an outbound link set for the message, and forwards the message to the message processor associated with the outbound signaling link. The message processor associated with the outbound signaling link forwards the message to its destination via the outbound signaling link.

[0076] In the example above, the MSU key value is used unmodified for lookup in the destination array. In an alternative implementation, to reduce the size of the destination address array, the SCCP Class 1 load-sharing module 506 can calculate MSUKeyMOD(x) (where x is the number of entries in the destination address array) and use that result for lookup in the destination array.

[0077] Figure 7A The diagram illustrates an overview of the load-sharing algorithm used to generate MSU key 1. (Refer to...) Figure 7A In step 1, load balancing module 506 performs GTT to select a load balancing group corresponding to the destination address array for the message. In step 2, load balancing module 506 searches the OPC array 700 using the value derived from the message's OPC. In step 3, OPC array 700 returns the first load balancing value Result_1. In step 4, load balancing module 506 searches the SLS array 702 using the value derived from the message's SLS. In step 5, SLS array 702 returns Result_2. In step 6, load balancing module 506 searches the OPC array 700 using the value derived from the message's CdGT. In step 7, OPC array 700 returns Result_3. In step 8, load balancing module 506 uses Result_1, Result_2, Result_3, and Equation 1 above to calculate the MSU key. In step 9, load-sharing module 506 uses the MSU key to look up the destination address array 704, which maps MSU key values ​​to destination point codes. In step 10, the lookup result is the destination point code of the message's destination. As described above, load-sharing module 506 inserts the destination point code into the message, and routing module 508 routes the message to the message processor associated with the outbound signaling link. The message processor associated with the outbound signaling link forwards the message to its destination, which in one example is the HLR.

[0078] In an alternative implementation, the load-sharing module 506 combines the value calculated based on the CdGT from the message (without using the CdGT as input to look up in an array of pseudo-randomly generated values) with the values ​​obtained from the OPC array and the SLS array. Equation 3 shown below illustrates this alternative algorithm.

[0079] (3)

[0080] In Equation 3, the functions and terms have the same meaning as in Equation 1. Therefore, the description of these terms will not be repeated. Like Equation 1, Equation 3 is designed for load balancing among a maximum of 100 destinations. However, as shown in Equation 4, by replacing the constant 100 in Equation 3 with Max_Dests, a constant equal to the maximum number of destinations used for load balancing, the concepts in Equation 3 can be applied to any number of destinations.

[0081] (4)

[0082] The difference between Equations 3 and 4 lies in the last addend. Instead of using CdGT to search through an array of pseudo-randomly generated values, it uses a MOD of CdGT and Max_Dests. Using the same OPC, SLS, and CdGT values ​​as in the example used for the first algorithm above, with OPC=11392, SLS=0, and CdGT=12345600, the search results in the OPC and SLS arrays will be the same, returning 58 and 60 respectively. The third term of Equation 3 will be determined as follows: MOD(CdGT,100) =MOD(12345600,100) =0 The MSUKey from Equation 3 will be: MSUKey=MOD(58+60+0,100) =MOD(118,100) =18.

[0083] The value of the MSU key is then used to look up the destination address array and generate a destination point code, which is inserted into the message. The message is then routed to the destination associated with the destination point code.

[0084] Figure 7B This diagram illustrates how the load-sharing module 506 uses the algorithms in Equations 3 and 4 to calculate and use the MSUKey message flow. (Refer to...) Figure 7BIn step 1, load balancing module 506 performs a GTT on the message to select a load balancing group corresponding to the destination address array for the message. In step 2, load balancing module 506 searches the OPC array 700 using the value derived from the OPC in the message. In step 3, OPC array 700 returns Result_1. In step 4, load balancing module 506 searches the SLS array 702 using the value derived from the SLS in the message. In step 5, SLS array 702 returns Result_2. In step 6, load balancing module 506 uses a modular function to calculate Result_3 based on the CdGT in the message, instead of searching the array. In step 7, load balancing module 506 calculates the MSU key based on Result 1-3 using Equation 3 or Equation 4. In step 8, load balancing module 506 searches the destination address array 706 using the MSUKey, and in step 9, the destination address array 706 returns the DPC value. Then, the load-sharing module 506 inserts the DPC value into the message and passes the message to the routing module 508. The routing module 508 routes the message to the message processor associated with the outbound signaling link. The message processor associated with the outbound signaling link forwards the message to its intended destination.

[0085] Figure 8 This is a flowchart illustrating exemplary steps for load balancing of Type 1 SCCP messages. (Refer to...) Figure 8 In step 800, the process includes receiving a Type 1 SCCP message that requires global code conversion. For example, the STP 500 can receive a Type 1 SCCP message for which a routing indicator indicates a global code-based route. The receive message processor in the STP 500 forwards the message to the Type 1 SCCP load balancing module 506.

[0086] In step 801, the process includes performing a GTT on the message to select a load-sharing group for the message. For example, the load-sharing module 506 may identify the load-sharing group by looking up the CdGT digits in the message and possibly other parameters in the message in a GTT table. The load-sharing group corresponds to an array of destination addresses configured with the addresses of nodes capable of processing the message.

[0087] In step 802, the process includes generating an MSU load-sharing key based on a combination of MTP3 layer parameters and signaling connection control part layer parameters from the message. For example, load-sharing module 506 can use either Equation 2 or Equation 4 above to calculate the MSU load-sharing key.

[0088] In step 804, the process includes using the MSU load balancing key to select a destination address for the message. For example, the load balancing module 506 can look up the destination address array 706 for the load balancing group to determine the destination location code of the message.

[0089] In step 806, STP 500 inserts the destination address into the message. For example, load balancing module 506 can insert a DPC that matches the MSU load balancing key value into the destination location code field of the message.

[0090] In step 808, the process includes routing the message to the destination corresponding to the destination address. For example, routing module 508 may look up the destination point code in an MTP3 routing table that maps the destination point code to the link set and route the Type 1 SCCP message to the message processor associated with the outbound link set corresponding to the destination point code value in the message.

[0091] Using the load-sharing algorithm described in Equations 1-4 above, STP can effectively distribute message load among destination nodes while ensuring that messages related to the same TCAP transaction are sent to the same destination node. It should be noted that the subscription algorithm described in this paper can be implemented on physical STP products deployed on-premises at the network operator's physical location, or it can be implemented as a virtual STP product deployed in a cloud network.

[0092] It should be understood that various details of the currently disclosed subject matter can be changed without departing from the scope of the currently disclosed subject matter. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for load balancing of Type 1 Signaling Connection Control Part (SCCP) messages, the method comprising: Receive Class 1 SCCP messages that require Global Code Translation (GTT); Global code translation (GTT) is performed on the message to select a load-sharing group for the message; The Message Signalling Unit (MSU) load sharing key is generated using a combination of parameters from the Message Passing Part (MTP) layer and the Signaling Connection Control Part (SCCP) layer. This generation of the MSU load sharing key using MTP and SCCP layer parameters includes generating the MSU load sharing key using the called party global code (CdGT), source point code (OPC), and signaling link selector (SLS) from the message. Use the MSU load balancing key to select a destination address for the message from the load balancing group; Insert the destination address into the message; as well as The message is routed to the destination corresponding to the destination address.

2. The method of claim 1, wherein receiving a Type 1 SCCP message requiring GTT includes receiving the Type 1 SCCP message at the SS7 Signal Transmission Point (STP).

3. The method according to claim 1 or 2, wherein receiving a Type 1 SCCP message requiring GTT includes receiving the Type 1 SCCP message from a Mobile Switching Center (MSC).

4. The method of claim 1, wherein generating the MSU load sharing key using the CdGT, OPC, and SLS from the message comprises generating the MSU load sharing key by searching in an array of pseudo-randomly generated values ​​derived from the CdGT, OPC, and SLS and calculating the MSU load sharing key based on the value obtained from the search.

5. The method of claim 4, wherein generating the MSU load-sharing key by searching in an array of pseudo-randomly generated values ​​derived from CdGT, OPC, and SLS and calculating the MSU load-sharing key based on the values ​​obtained from the search comprises generating the MSU load-sharing key using the following equation: Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in the array, OPC is the OPC from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the SLS from the message, SLSArray is an array of pseudo-randomly generated values, CdGT is the called party global code from the message, and Max_Dests is the maximum number of destinations used for load balancing.

6. The method of claim 1, wherein generating the MSU load-sharing key using CdGT, OPC, and SLS comprises generating the MSU load-sharing key by calculating a value based on CdGT and using OPC and SLS to look up the value in an array of pseudo-randomly generated values.

7. The method of claim 6, wherein generating the MSU load-sharing key by calculating a value based on CdGT and searching in an array of pseudo-randomly generated values ​​using OPC and SLS comprises generating the MSU load-sharing key using the following equation: Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in an array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, and CdGT is the called party global code from the message.

8. The method of claim 1 or 2, wherein using MTP and SCCP parameters to generate the MSU load sharing key includes generating the same MSU load sharing key for Class 1 SCCP messages that are part of the same Transaction Capability Application Part (TCAP) transaction.

9. The method of claim 1 or 2, wherein routing the message to a destination corresponding to the destination address includes routing the message to a Home Location Register (HLR).

10. A system for load balancing of Type 1 Signaling Connection Control Part (SCCP) messages, the system comprising: Includes at least one SS7 signal transfer point (STP) for a processor and memory; A Type 1 SCCP load-sharing module implemented by the at least one processor is configured to: receive a Type 1 SCCP message requiring Global Code Transformation (GTT); perform GTT on the message to select a load-sharing group for the message; generate a Message Signaling Unit (MSU) load-sharing key using parameters from a combination of Message Transfer Part (MTP) layer parameters and Signaling Connection Control Part (SCCP) layer parameters; use the MSU load-sharing key to select a destination address for the message from the load-sharing group; and insert the destination address into the message, wherein the Type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key using the called party global code (CdGT), source point code (OPC), and signaling link selector (SLS) from the message; as well as A routing module implemented by the at least one processor is used to route the message to a destination corresponding to the destination address.

11. The system according to claim 10, wherein the Type 1 SCCP message originates from the Mobile Switching Center (MSC).

12. The system of claim 10, wherein the type 1 SCCP load sharing module is configured to generate an MSU load sharing key by searching an array of pseudo-randomly generated values ​​derived from CdGT, OPC, and SLS and calculating an MSU load sharing key based on the values ​​obtained from the search.

13. The system of claim 12, wherein the type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key using the following equation: Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in the array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, CdGT is the called party global code from the message, and Max_Dests is the maximum number of destinations used for load balancing.

14. The system of claim 10, wherein the type 1 SCCP load-sharing module is configured to generate an MSU load-sharing key by calculating a value based on CdGT and searching in an array of pseudo-randomly generated values ​​using OPC and SLS.

15. The system of claim 14, wherein the type 1 SCCP load-sharing module is configured to generate the MSU load-sharing key using the following equation: Where MSUKEY is the MSU load balancing key, MOD is the modulo function, VLOOKUP is the lookup function for searching in an array, OPC is the source point code from the message, OPCArray is an array of pseudo-randomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudo-randomly generated values, and CdGT is the called party global code from the message.

16. The system of claim 10 or 11, wherein the type 1 SCCP load-sharing module is configured to generate the same MSU load-sharing key for type 1 SCCP messages that are part of the same Transaction Capability Application Part (TCAP) transaction.

17. The system of claim 10 or 11, wherein the destination includes a Home Location Register (HLR).

18. A non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions controlling the computer to perform the following steps when executed by a computer's processor: Receive Type 1 Signaling Connection Control Part (SCCP) messages that require Global Code Translation (GTT); Perform GTT on the message to select a load-sharing group for the message; The Message Signalling Unit (MSU) load sharing key is generated using a combination of parameters from the Message Passing Part (MTP) layer and the Signaling Connection Control Part (SCCP) layer. This generation of the MSU load sharing key using MTP and SCCP layer parameters includes generating the MSU load sharing key using the called party global code (CdGT), source point code (OPC), and signaling link selector (SLS) from the message. Use the MSU load balancing key to select a destination address for the message from the load balancing group; Insert the destination address into the message; as well as The message is routed to the destination corresponding to the destination address.

Images