Patent Grant
11902725
The subject matter described herein relates to load sharing SS7 messages. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for load sharing class 1 SCCP messages.
In SS7 signaling networks, the signaling connection control part (SCCP) is used by applications to access databases and other services. In particular, SCCP is used by the mobile application part (MAP) and the transaction capabilities application part (TCAP), as well as other level four protocols to communicate application level information. SCCP service is divided into five classes. The classes are class 0, which provides basic connectionless service, class 1, which provides sequenced connectionless service, class 2, which provides basic connection oriented service, class 3, which provides flow controlled connection oriented service, and class 4, which provides error recovery and flow controlled connection oriented service. Currently, classes 2, 3, and 4 are not used in telecommunications networks. Both class 0 and class 1 are used. Class 0 services provide for the basic transport of TCAP and other application layer messages when sequencing is not required. Class 1 is used to provide sequenced service whenever more than one SCCP message exists for a transaction.
SCCP processing can be performed at any node in a signaling network. Typically, SCCP routing functions, such as global title translation, are performed at signal transfer points (STPs). Performing SCCP routing at STPs allows service switching points to send messages to the STPs where the messages are global title translated and routed to their intended destinations. Global title translation translates SCCP level information into a point code and subsystem number that can be used to route a message to its destination. Parameters other than SCCP level information, such as the originating point code (OPC), can also be used in the global title translation.
Many network operators provision redundant database nodes in their networks that provide the same service and load share messages among the redundant database nodes. One example of a database node that is often provided redundantly is the home location register (HLR). HLRs store subscription information for mobile subscribers and are contacted any time a home subscriber registers at a new location and to obtain routing information to route calls and short message service (SMS) messages to mobile subscribers.
As the number of subscribers in a network increases, the number of HLRs may likewise increase, and the network operator may desire to distribute the database processing among multiple HLRs. Load sharing processing among multiple HLRs or other database nodes can be implemented using load sharing at the STP. Class 0 SCCP messages are relatively easy to load share because the transactions carried by class 0 messages are single message transactions, such as database query. Stated differently, different class 0 SCCP messages are related to different transactions and thus can be load balanced among database nodes that process the transactions without regard to the database nodes to which other class 0 SCCP messages are routed.
In contrast to class 0 SCCP messages, class 1 SCCP messages are used when more than one message exists for a TCAP transaction carried by the class 1 SCCP messages. Class 1 SCCP messages can be load shared among database nodes. However, the load sharing must be performed in a manner 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 among database nodes utilize MTP, SCCP, or TCAP parameters to define the load sharing key for class 1 SCCP messages. Each of these messages has at 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 may result in the one database node being overloaded while the other database nodes are underutilized.
Using the TCAP transaction ID to load share class 1 SCCP messages among database nodes may not be effective because some class 1 SCCP messages, such as a TCAP END message, will not have the TCAP originator transaction ID. As a result, the TCAP END message may be routed to a different database node to other messages associated with the same TCAP transaction.
In another example, the MTP OPC and signaling link selector (SLS) may be used to load share class 1 SCCP messages. To achieve effective load sharing using the MTP OPC and SLS, there must be variation in the OPC and SLS values. OPC values will not vary widely in some cases, such as when a large number of messages originate from the same mobile switching center (MSC) and thus have the same OPC. Given that the load sharing algorithm relies on the OPC, messages with the same OPC would tend to be routed to the same destination node, resulting in uneven load balancing. In one example where load sharing keys were based on the above-described parameters, a difference in 300% in traffic occurred between the node receiving the most traffic and the node receiving the least traffic.
In light of these and other challenges, there exists a need for improved, methods, and non-transitory computer-readable media for load sharing class 1 SCCP messages.
A method for load sharing class 1 signaling connection control part (SCCP) messages includes receiving a class 1 SCCP message requiring global title translation (GTT). The method further includes performing GTT for the message to select a load sharing group for the message. The method further includes generating a message signal 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. The method further includes using the MSU load sharing key to select a destination address from the load sharing group for the message. The method further includes inserting the destination address into the message. The method further includes routing the message to a destination corresponding to the destination address.
According to another aspect of the subject matter described herein, receiving a class 1 SCCP message requiring GTT includes receiving the class 1 SCCP message at an SS7 signal transfer point (STP).
According to another aspect of the subject matter described herein, receiving a class 1 SCCP message requiring GTT includes receiving the class 1 SCCP message from a mobile switching center (MSC).
According to another aspect of the subject matter described herein, generating the MSU load sharing key using the MTP layer parameters and the SCCP layer parameters includes generating the MSU load sharing key using a called party global title (CdGT), an originating point code (OPC), and a signaling link selector (SLS) from the message.
According to another aspect of the subject matter described herein, generating the MSU load sharing key using the CdGT, the OPC, and the SLS from the message includes generating the MSU load sharing key by using values derived from the CdGT, the OPC, and the SLS to perform lookups in arrays of pseudorandomly generated values and computing the MSU load sharing key from values obtained from the lookups.
According to another aspect of the subject matter described herein, generating the MSU load sharing key generating the MSU load sharing key by using values derived from the CdGT, the OPC, and the SLS to perform lookups in arrays of pseudorandomly generated values and computing the MSU load sharing key from values obtained from the lookups includes generating the MSU load sharing key using the following equation:
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+VLOOKUP(MOD(CdGT,Max_Dests),OPCArray),Max_Dests),
where MSUKEY is the MSU load sharing key, MOD is a modulo function, VLOOKUP is a lookup function that performs a lookup in an array, OPC is the OPC from the message, OPCArray is an array of pseudorandomly generated values, SLS is the SLS from the message, SLSArray is an array of pseudorandomly generated values, and GdGT is the called party global title from the message and Max_Dests is the maximum number of destinations for load sharing.
According to another aspect of the subject matter described herein, generating the MSU load sharing key using the CdGT, the OPC, and the SLS includes generating the MSU load sharing key by computing a value from the CdGT and using the OPC and the SLS to perform lookups in arrays of pseudorandomly generated values.
According to another aspect of the subject matter described herein, generating the MSU load sharing key using the CdGT, the OPC, and the SLS includes generating the MSU load sharing key by computing a value from the CdGT and using the OPC and the SLS to perform lookups in arrays of pseudorandomly generated values includes generating the MSU load sharing using the following equation:
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+MOD(CdGT,Max_Dests),Max_Dests),
where MSUKEY is the MSU load sharing key, MOD is a modulo function, VLOOKUP is a lookup function that performs a lookup in an array, OPC is the originating point code from the message, OPCArray is an array of psuedorandomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudorandomly generated values, and CdGT is the called party global title from the message.
According to another aspect of the subject matter described herein, generating the MSU load sharing key using MTP and SCCP parameters includes generating the same MSU load sharing key for class 1 SCCP messages that are part of the same transaction capabilities application part (TCAP) transaction.
According to another aspect of the subject matter described herein, routing the message to a destination corresponding to the destination address includes routing the message to a home location register (HLR).
According to another aspect of the subject matter described herein, a system for load sharing class 1 signaling connection control part (SCCP) messages is provided. The system includes an SS7 signal transfer point (STP) including at least one processor and a memory. The system further includes a class 1 SCCP load sharing module implemented by the at least one processor for receiving a class 1 SCCP message requiring global title translation (GTT), performing GTT for the message to select a load sharing group for the message; generating a message signal 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, using the MSU load sharing key to select a destination address from the load sharing group for the message, and inserting the destination address into the message. The system further includes a routing module implemented by the at least one processor for routing the message to a destination corresponding to the destination address.
According to another aspect of the subject matter described herein, the class 1 SCCP message is from a mobile switching center (MSC).
According to another aspect of the subject matter described herein, the class 1 SCCP load sharing module is configured to generate the MSU load sharing key using a called party global title (CdGT), an originating point code (OPC), and a signaling link selector (SLS) from the message.
According to another aspect of the subject matter described herein, the class 1 SCCP load sharing module is configured to generate the MSU load sharing key by using values derived from the CdGT, the OPC, and the SLS to perform lookups in arrays of pseudorandomly generated values and compute the MSU load sharing key from values obtained from the lookups.
According to another aspect of the subject matter described herein, the class SCCP load sharing module is configured to generate the MSU load sharing key by using the following equation;
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+VLOOKUP(MOD(CdGT,Max_Dests),OPCArray),Max_Dests),
where MSUKEY is the MSU load sharing key, MOD is a modulo function, VLOOKUP is a lookup function that performs a lookup in an array, OPC is the originating point code from the message, OPCArray is an array of pseudorandomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudorandomly generated values, and GdGT is the called party global title from the message and Max_Dests is the maximum number of destinations for load sharing.
According to another aspect of the subject matter described herein, the class 1 SCCP load sharing module is configured to generate the MSU load sharing key by computing a value from the CdGT and using the OPC and the SLS to perform lookups in arrays of pseudorandomly generated values.
According to another aspect of the subject matter described herein, the class 1 SCCP load sharing module is configured to generate the MSU load sharing key using the following equation:
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+MOD(CdGT,Max_Dests),Max_Dests),
where MSUKEY is the MSU load sharing key, MOD is a modulo function, VLOOKUP is a lookup function that performs a lookup in an array, OPC is the originating point code from the message, OPCArray is an array of psuedorandomly generated values, SLS is the signaling link selector from the message, SLSArray is an array of pseudorandomly generated values, and CdGT is the called party global title from the message.
According to another aspect of the subject matter described herein, the class 1 SCCP load sharing module is configured to generate the same MSU load sharing key for class 1 SCCP messages that are part of the same transaction capabilities application part (TCAP) transaction.
According to another aspect of the subject matter described herein, the destination comprises a home location register (HLR).
According to another aspect of the subject matter described herein, a non-transitory computer readable medium having stored thereon executable instructions that when executed by a processor of a computer control the computer to perform steps is provided. The steps include receiving a class 1 signaling connection control part (SCCP) message requiring global title translation (GTT). The steps further includes performing GTT for the message to select a load sharing group for the message. The steps further include generating a message signal 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. The steps further include using the MSU load sharing key to select a destination address from the load sharing group for the message. The steps further include inserting the destination address into the message. The steps further include routing the message to a destination corresponding to the destination address.
The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms “function” “node” or “module” as used herein refer to hardware, which may also include software and/or firmware components, for implementing the feature being described. In one exemplary implementation, the subject matter described herein may be implemented using a computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms.
The subject matter described herein will now be explained with reference to the accompanying drawings of which:
The subject matter described herein relates to methods, systems, and computer readable media for load sharing class 1 SCCP messages. As described above, conventional methods that rely on MTP level parameters alone, SCCP parameters alone, or TCAP parameters alone fail to achieve a distribution of class 1 SCCP messages with an acceptable level of variance in traffic load. The subject matter described herein achieves load balancing of class 1 SCCP messages with reduced variation in traffic among network nodes while ensuring that class 1 SCCP messages relating to the same transaction are routed to the same destination node. In one example, such load balancing is achieved using the SCCP called party global title (CdGT) parameter in combination with the MTP level 3 signaling link selector (SLS) and the MTP level 3 originating point code (OPC) to generate an MSU load sharing key. The MSU load sharing key is used to select a destination address for a message, and the message is routed to the destination address.
As stated above, each of the protocol layers in
The protocol layers in
The protocol layers in
In most networks today, SS7 messages are transmitted over IP-based signaling links instead of TDM-based signaling links that rely on MTP levels 1 and 2.
The protocol layers in
The remaining protocol layers and corresponding message structure in
As stated above, one set of parameters that may be useful in performing load sharing of class 1 SCCP parameters are the OPC and SLS parameters, which are located in the MTP level 3 portion of the SS7 message.
Point code 410 stores an SS7 node. Subsystem number 412 stores a value that indicates an application or subsystem to which the message is destined. Translation type 414 is a 1 byte parameter used to set whether an intermediate or final global title translation will be performed. Numbering plan 416 indicates the number type of the global title address.
Encoding scheme 418 indicates how the digits of the global title address are encoded. For example, one encoding scheme commonly used as binary-coded decimals (BCD). Nature of address indicator 420 represents the type of number, such as national or international, represented by the digits. Digits 422 are the called party global title, which is another of the parameters used by the algorithms described herein for load sharing class 1 SCCP messages.
In the example illustrated and
It is understood that the message parameters in
Message processor 600 and 602 each include a SIGTRAN layer 608 and SS7 layer 610. SIGTRAN layer 608 perform adaptation of SS7 messages for IP transport. In an alternate implementation, either of SIGTRAN layers 608 could be replaced by MTP levels 1 and 2 without departing from the scope of the subject matter described herein. SS7 layers 610 perform message discrimination to determine whether further processing by STP is required for a received message or if the message is to be routed only. For messages that are sent route on global title, SS7 layer 610 forward the messages to one of message processors 604 and 606 for further processing by STP 500. If a message requires routing only, SS7 layers 610 route the message to the message processor associated with one of outbound signaling links 612 and 614.
Message processors 604 and 606 each include SCCP class 1 load sharing module 506 for performing load sharing of class 1 SCCP messages and routing modules 508 for routing the messages after the load sharing and associated global title translation processing is performed.
In the message flow illustrated in
In step 4, routing module 508 of message processor 606 routes the message to the message processor associated with the outbound signaling link, which is selected based on the destination point code in the message after global title translation. In step 5, message processor 600, which is associated with outbound signaling link 612, sends the message to the destination via outbound signaling link 612.
As stated above, load sharing module 506 performs load sharing of class 1 SCCP messages in a manner that increases the evenness of distribution of the SCCP messages among destination nodes and that ensures that messages related to the same transaction or routed to the same node. In one method, load sharing module 506 uses values derived from the OPC, SLS, and CdGT to perform lookups in arrays of pseudorandomly generated (e.g., generated using a random number generation function) values. In one example, this algorithm is as follows:
MSUKEY=MOD(VLOOKUP(MOD(OPC,100),OPCArray)+VLOOKUP(SLS,SLS Array)+VLOOKUP(MOD(CdGT,100),OPCArray),100) (1)
In Equation 1 above, MSUKEY is the MSU load sharing key used to perform the lookup in the destination array. MOD is the modulo function, which returns the remainder when the first argument of the 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 arbitrary numbers 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:
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+VLOOKUP(MOD(CdGT,Max_Dests),OPCArray),Max_Dests) (2)
Continuing with the explanation of Equations 1 and 2, the function VLOOKUP(x,y) returns the value in array y stored at array element x. For example, in Equation 1, the function MOD(OPC, 100), OPCArray) returns the value located at element (MOD(OPC, 100)) in the OPC array. The OPC array is an array of size Max_Dests, which in this case is 100. Each element in the array stores a value that is used to compute the MSU Key. In one example, the values of stored in the array may each be a number pseudorandomly generated within the range [0, Max_Dests−1]. Table 1 shown below is an example of an OPC array for load sharing between 100 destination nodes.
For simplification, rows 18-90 are omitted from the OPC array. In Table 1, the first column is the array index, the second column includes the pseudorandomized values between 0 and 99 in decimal stored at each array index, and the third column contains the value of the second column in hexadecimal. Thus, the result of the term VLOOKUP(MOD(OPC, 100),OPCArray) is a psuedorandomly generated value between 0 and 99 that is selected based on a value derived from the OPC in the message. For example, if the OPC in the message is 11392 (in decimal), MOD(11392,100) returns 92. The value of VLOOKUP(92,OPCArray) is 58 or 3a in hexadecimal.
Continuing with the second term in Equation 1, VLOOKUP(SLS, SLSArray) performs a lookup in SLSArray using the value of the SLS in the received message. From
In Table 2, the first column includes the array indices, each corresponding to one of the 16 possible SLS values. The second column includes the pseudorandomly generated values stored in the array elements. Thus, if the SLS value is 0, VLOOKUP(0, SLSArray) will return 60.
The next term in Equation 1 is VLOOKUP(MOD(CdGT, 100), OPCArray). This term performs a lookup based on a value derived from the 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 ranging from 0 to 99 based on the CdGT. Depending on the message type, the called party global title can be the B party (called party) number or a routing number corresponding to an HLR. Assuming that that the called party in the message is 12345600, the last term of Equation 1 will return the following value:
It can be seen from Equations 1 and 2 that the same arrays are used to perform the lookups using the values derived from the OPC and the CdGT. However, the subject matter described herein is not limited to using the same array to perform these lookups. In an alternate implementation, a value derived from the OPC in the message may be used to perform a lookup in a first array of psuedorandomly generated values, and a value derived from the CdGT in the message may be used to perform a lookup in a second array of pseudorandomly generated values that is different from the first array.
The terms inside the outermost parentheses in Equation 1 are added together, and the sum forms the first term in the outermost MOD function. Continuing with the examples above, the values returned by the three array lookups (OPC, SLS, and CdGT) are 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 for the load sharing. Thus, the effect of the outermost MOD function us to compute a number between 0 and 99, where the resulting number can be used to perform a lookup in the destination address table. Continuing with the example, the value of MOD(173,100) is 73, so the MSU key value of 73 would be used to perform the lookup in the destination address array for the load sharing group identified in the GTT lookup:
The lookup in the destination address array using the MSU key 73 as the lookup key would return the destination point code of 2-2-0. SCCP class 1 load sharing module 506 inserts the destination point code from the destination address array into the message, Routing module 508 uses the DPC value to perform a lookup in an MTP level 3 or M3UA routing table, selects an outbound linkset for the message, and forwards the message to the message processor associated with the outbound signaling link. The message processor associate with the outbound signaling link forwards the message to its destination over the outbound signaling link.
In the examples above, the MSU key value is used unmodified to perform the lookup in the destination array. In an alternate implementation, to reduce the size of the destination address array, SCCP class 1 load sharing module 506 may compute MSUKeyMOD(x), where x is the number of entries in the destination address array, and use the result to perform the lookup in the destination array.
In an alternate implementation, load sharing module 506 uses a value computed from CdGT from the message (without performing a lookup in an array of pseudorandomly generated values using the CdGT as input) in combination with values obtained from the OPC and SLS arrays. Equation 3 shown below illustrates the alternate algorithm.
MSUKEY=MOD(VLOOKUP(MOD(OPC,100),OPCArray)+VLOOKUP(SLS,SLS Array)+MOD(CdGT,100),100) (3)
In Equation 3, the functions and the terms have the same meanings as Equation 1. Hence, a description of these terms will not be repeated. As with Equation 1, Equation 3 is designed for load sharing among a maximum of 100 destinations. However, the concept of Equation 3 can be applied to an arbitrary number of destinations by replacing the constant 100 in Equation 3 with Max_Dests, a constant equal to the maximum number of destinations for load sharing, as indicated by Equation 4.
MSUKEY=MOD(VLOOKUP(MOD(OPC,Max_Dests),OPCArray)+VLOOKUP(SLS,SLS Array)+MOD(CdGT,Max_Dests),Max_Dests) (4)
The difference between Equations 3 and 4 is that in the last addend, rather than using the CdGT to perform a lookup in an array of pseudorandomly generated values, the MOD of the CdGT and Max_Dests is used. Using the same OPC, SLS and CdGT values from the example above for the first algorithm, OPC=11392, SLS=0, and CdGT=12345600, the results of the lookups in the OPC and SLS arrays would be the same and respectively return 58 and 60. The third term of Equation 3 would be determined as follows:
The MSUKey from Equation 3 would be:
The value of the MSU key is then used to perform a lookup in the destination address array and yields a destination point code, which is inserted in the message. The message is then routed to the destination associated with the destination point code.
In step 801, the process includes performing GTT for the message to select a load sharing group for the message. For example, load sharing module 506 may perform a lookup in a GTT table based on the CdGT digits and possibly other parameters in the message to identify a load sharing group. The load sharing group corresponds to a destination address array configured with addresses of nodes capable of processing the message.
In step 802, the process includes generating an MSU load sharing key from a combination of MTP3 layer parameters and signaling connection control part layer parameters in the message. For example, load sharing module 506 may compute the MSU load sharing key using either of Equations 2 and 4 above.
In step 804, the process includes using the MSU load sharing key to select a destination address for the message. For example, load sharing module 506 may perform a lookup in destination address array 706 for the load sharing group to determine the destination point code for the message.
In step 806, STP 500 inserts the destination address in the message. For example, load sharing module 506 may insert the DPC that matches the MSU load sharing key value in the destination point code field of the message.
In step 808, the process includes routing the message to the destination corresponding to the destination address. For example, routing module 508 may perform a lookup in an MTP3 routing table which maps destination point codes to linksets and route the class 1 SCCP message to the message processor associated with the outbound linkset corresponding to the destination point code value in the message.
Using the load sharing algorithms illustrated above by Equations 1-4, an STP can effectively load share messages between destination nodes while ensuring that messages relating to the same TCAP transaction are sent to the same destination node. It should be noted that the algorithms subscribed herein can be implemented on a physical STP product that is deployed on premises at a network operator's physical location or as a virtual STP product deployed in a cloud network.
It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4752924 | Darnell et al. | Jun 1988 | A |
| 5008929 | Olsen et al. | Apr 1991 | A |
| 5384840 | Blatchford et al. | Jan 1995 | A |
| 5481673 | Michelson | Jan 1996 | A |
| 5550914 | Clarke et al. | Aug 1996 | A |
| 5592477 | Farris et al. | Jan 1997 | A |
| 5592530 | Brockman et al. | Jan 1997 | A |
| 5708702 | De Paul et al. | Jan 1998 | A |
| 5740234 | Black et al. | Apr 1998 | A |
| 5898667 | Longfield et al. | Apr 1999 | A |
| 6018515 | Sorber | Jan 2000 | A |
| 6119000 | Stephenson | Sep 2000 | A |
| 6175574 | Lewis | Jan 2001 | B1 |
| 6226289 | Williams et al. | May 2001 | B1 |
| 6282191 | Cumberton et al. | Aug 2001 | B1 |
| 6324279 | Kalmanek, Jr. et al. | Nov 2001 | B1 |
| 6327267 | Valentine et al. | Dec 2001 | B1 |
| 6327270 | Christie et al. | Dec 2001 | B1 |
| 6377674 | Chong et al. | Apr 2002 | B1 |
| 6535746 | Yu et al. | Mar 2003 | B1 |
| 6577723 | Mooney | Jun 2003 | B1 |
| 6628672 | Cabello | Sep 2003 | B1 |
| 6662017 | McCann et al. | Dec 2003 | B2 |
| 6683881 | Mijares et al. | Jan 2004 | B1 |
| 6757538 | Howe | Jun 2004 | B1 |
| 6785378 | Mar | Aug 2004 | B2 |
| 6792100 | Nekrasovskaia et al. | Sep 2004 | B2 |
| 6795546 | Delaney et al. | Sep 2004 | B2 |
| 6836477 | West, Jr. et al. | Dec 2004 | B1 |
| 6839336 | Tiedemann, Jr. et al. | Jan 2005 | B2 |
| 6842506 | Bedingfield | Jan 2005 | B1 |
| 6940866 | Miller et al. | Sep 2005 | B1 |
| 7046692 | Gradischnig | May 2006 | B1 |
| 7088728 | Delaney et al. | Aug 2006 | B2 |
| 7139388 | Rao | Nov 2006 | B2 |
| 7260086 | Delaney et al. | Aug 2007 | B2 |
| 7864943 | Davidson et al. | Jan 2011 | B2 |
| 8041021 | Xu et al. | Oct 2011 | B2 |
| 20020054674 | Chang et al. | May 2002 | A1 |
| 20020071543 | Williams | Jun 2002 | A1 |
| 20020131427 | Niermann | Sep 2002 | A1 |
| 20020186702 | Ramos et al. | Dec 2002 | A1 |
| 20030202491 | Tiedemann, Jr. et al. | Oct 2003 | A1 |
| 20030206562 | Yi | Nov 2003 | A1 |
| 20040004956 | Gilmour et al. | Jan 2004 | A1 |
| 20040015964 | McCann et al. | Jan 2004 | A1 |
| 20040081206 | Allison | Apr 2004 | A1 |
| 20040096049 | Delaney et al. | May 2004 | A1 |
| 20040114533 | Angermayr et al. | Jun 2004 | A1 |
| 20040137904 | Gradischnig | Jul 2004 | A1 |
| 20040141493 | Delaney et al. | Jul 2004 | A1 |
| 20040264674 | Delaney et al. | Dec 2004 | A1 |
| 20050013290 | Allison et al. | Jan 2005 | A1 |
| 20050013427 | Breiholz et al. | Jan 2005 | A1 |
| 20050152278 | Schantz | Jul 2005 | A1 |
| 20060039546 | Davidson et al. | Feb 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 0 912 068 | Apr 1999 | EP |
| 1 111 940 | Jun 2001 | EP |
| 1 521 484 | Apr 2005 | EP |
| WO 9711563 | Mar 1997 | WO |
| WO 9967928 | Dec 1999 | WO |
| WO 0067491 | Nov 2000 | WO |
| WO 0213545 | Feb 2002 | WO |
| WO 2006023801 | Mar 2006 | WO |
| WO 2007030257 | Mar 2007 | WO |
| Entry |
|---|
| “Database Administration—GTT User's Guide,” Oracle Communications EAGLE, E63573 Revision 1, pp. 1-942 (Jul. 2015). |
| Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US2021/041698 (dated Nov. 29, 2021). |
| Notice of Abandonment for U.S. Appl. No. 11/218,290 (dated Jun. 6, 2011). |
| Supplemental Notice of Allowability for U.S. Appl. No. 10/922,593 (dated Nov. 30, 2010). |
| Final Official Action for U.S. Appl. No. 11/218,290 (dated Nov. 29, 2010). |
| Interview Summary for U.S. Appl. No. 11/218,290 (dated Nov. 9, 2010). |
| Notice of Allowance and Fee(s) Due for U.S. Appl. No. 10/922,593 (dated Sep. 2, 2010). |
| Interview Summary for U.S. Appl. No. 10/922,593 (dated Jun. 8, 2010). |
| Official Action for U.S. Appl. No. 11/218,290 (dated May 5, 2010). |
| Final Official Action for U.S. Appl. No. 10/922,593 (dated Feb. 26, 2010). |
| Interview Summary for U.S. Appl. No. 10/922,593 (dated Oct. 30, 2009). |
| Official Action for U.S. Appl. No. 10/922,593 (dated Oct. 14, 2009). |
| Final Official Action for U.S. Appl. No. 10/922,593 (dated May 18, 2009). |
| Official Action for U.S. Appl. No. 10/922,593 (dated Oct. 29, 2008). |
| Notification Concerning Transmittal of International Preliminary Report on Patentability for International Application No. PCT/US2006/031168 (dated Mar. 13, 2008). |
| Notification of Transmittal of the International Search Report and the Written Opinion of the International Searchig Authority, or the Declaration for International Application No. PCT/US06/31168 (dated Apr. 25, 2007). |
| Notification Concerning Transmittal of International Preliminary Report on Patentability for International Application No. PCT/US2005/029670 (dated Mar. 1, 2007). |
| Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration in International Application No. PCT/US05/29670 (dated Feb. 7, 2006). |
| Russell, “Signaling System #7: Sequence Numbering,” Chapter 5, pp. 170-171 (Copyright 2000). |
| “Signalling System No. 7—ISDN User Part Functional Description,” ITU-T, Q.762 (Dec. 1999). |
| “Signalling System No. 7—ISDN User Part Functional Description,” ITU-T, Q.761 (Dec. 1999). |
| Tekelec, “Eagle® Feature Guide,” PN/9110-1225-01 (Jan. 1998). |
| Comer, “Internetworking with TCP/IP vol. I: Principles, Protocols, and Architecture: 13.22 Initial Sequence Numbers,” p. 217 (Copyright 1995). |
| Communication pursuant to Article 94(3) EPC for European Application No. 04 702 497.1 (dated Sep. 22, 2010). |
| Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration for International Application No. PCT/US06/22875 (dated Sep. 13, 2007). |
| Notice of Allowance for U.S. Appl. No. 10/397,774 (dated Jun. 28, 2007). |
| Official Action for U.S. Appl. No. 10/397,774 (dated Mar. 6, 2007). |
| Supplemental Notice of Allowability for U.S. Appl. No. 10/345,632 (dated Jul. 3, 2006). |
| Supplemental Notice of Allowability for U.S. Appl. No. 10/345,632 (dated May 2, 2006). |
| Notice of Allowance and Fee(s) Due for U.S. Appl. No. 10/345,632 (dated Apr. 11, 2006). |
| Supplementary European Search Report in European Application No. EP 04 70 2497 (dated Feb. 13, 2006). |
| Official Action for U.S. Appl. No. 10/345,632 (dated Sep. 8, 2005). |
| Notification Concerning Transmittal of International Preliminary Report on Patentability (Chapter 1 of the Patent Cooperation Treaty) in International Application No. PCT/US2004/001004 (dated Aug. 4, 2005). |
| Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration in International Application No. PCT/US04/00999 (dated Apr. 6, 2005). |
| European Search Report in European Application No. EP 04 70 2535 (dated Apr. 10, 2006). |
| Supplementary European Search Report in European Application No. EP 04 70 2535 (dated Mar. 22, 2006). |
| Official Action for U.S. Appl. No. 10/345,632 (dated Nov. 16, 2004). |
| Notice of Publication for European Patent Application Serial No. 21758839.1 (dated Aug. 23, 2023). |
| Number | Date | Country | |
|---|---|---|---|
| 20220150605 A1 | May 2022 | US |
