Patent Grant
7092505
The present invention relates to methods and systems for providing routing address translation service selection in a communications network. More particularly, the present invention relates to methods and systems for universal, automatic routing address translation service selection in a telecommunications signaling network.
In the modern public switched telephone network (PSTN) and wireless telecommunication networks, an out-of-band common channel signaling (CCS) network is employed to facilitate the setup and tear down of voice and/or data communication sessions between telephone service subscribers. This signaling network is typically referred to as the signaling system 7 (SS7) network. The SS7 network utilizes a number of different signaling messages to perform call setup, call tear down, and database services. These signaling messages include ISDN user part (ISUP) messages for PSTN call setup and tear down, transaction capabilities application part (TCAP) messages for accessing database services, mobile application part (MAP) messages for providing mobile communications services, and signaling connection control part (SCCP) messages for carrying TCAP and MAP messages.
It is often the case within a signaling network that signaling messages require intermediate routing address translation prior to reaching their final destinations. The most common example of such intermediate routing address translation is referred to in the telecommunications industry as global title translation (GTT). GTT is defined in Telcordia Technologies Specification of Signalling System Number 7 Number, GR-246-CORE, Issue 07, Dec. 2, 2002 (hereinafter, “GR-246-CORE”), the disclosure of which is incorporated herein by reference in its entirety. As defined in GR-246-CORE, GTT provides network elements, such as wireline and wireless end office nodes (e.g., CLASS 5 switches, mobile switching centers, etc.), with the ability to send SCCP messages, such as SCCP messages carrying 800 number service queries, calling name (CNAM) delivery service queries, home location register (HLR) queries, short message service (SMS) messages, etc., into a signaling network without knowledge of the point code and subsystem number of the network entity that can provide the necessary service. In typical GTT processing, a global title address value is extracted from the SCCP called party address field of a message and is translated into a destination point code and subsystem number.
Within a signaling network, GTT processing may be performed by a service control point (SCP) or by a network routing node, such as a signal transfer point (STP) or Internet-protocol-capable signaling gateway (SG). Given the wide variety of services that may be concurrently supported by a signaling network, routing address translation data and applications may be separated according to service type. For example, one routing address translation application may translate HLR queries, while another routing address translation application may translate CNAM queries. Thus, one problem with performing routing address translations is determining which service or type of routing address translation processing is appropriate and where the appropriate routing address translation service can be obtained. Once again, routing address translation services may be provisioned on SCPs or STPs. In the former case, service selection may include identifying an SS7 point code and subsystem number associated with an SCP node that will perform the routing address translation. In the latter case, service selection may involve identifying a routing address translation data set and the logical or physical location of the translation data set within the network routing node.
In conventional service selection in ANSI networks, an SCCP parameter referred to as translation type (TT) is used to select the block of global title translation data associated with a particular service. For example, one translation type value may indicate a block of data for wireline number portably translations. Another translation type value may indicate the location of global title translation data for calling name translations. Yet another translation type may indicate the location of global title translation data for mobile communications services.
In
In the network illustrated in
U.S. Pat. No. 6,577,723 discloses a system for using the TCAP protocol type, i.e., whether the message is ANSI TCAP or ITU TCAP, in order to determine how to process the SCCP portion of the message. The TCAP protocol type is determined by analyzing the first two bits in the TCAP portion of the message. Using the TCAP protocol type to control processing of an SCCP message allows SCCP messages that carry ANSI TCAP messages to be processed differently from SCCP messages that carry ITU TCAP messages. However, the TCAP protocol type does not indicate the application layer message type being carried by the TCAP message. In addition, ITU application layer messages can be carried by ANSI TCAP messages and ANSI application layer messages can be carried by ITU TCAP messages. Thus, selecting SCCP processing based on the TCAP protocol type fails to yield a universally applicable solution for service selection.
Accordingly, there exists a long felt need for improved methods and systems for universal, automatic service selection in a telecommunications signaling network.
The present invention includes methods and systems for universal, automatic service selection. In one exemplary implementation, the present invention performs universal, automatic service selection based on an application identifier in a message. As used herein, the term “application identifier” refers to a parameter in a message that identifies the application layer message type. The term “application layer,” as used herein, refers to the layer at the destination responsible for terminating and processing a message. In SS7 networks, an example of an application layer is the mobile application part (MAP) layer. An example of an application identifier for the MAP layer is the TCAP opcode, which identifies the MAP message type. In SS7 over IP networks, application identifiers may be selected from SIGTRAN protocol layers used to carry application layer messages. In IP telephony signaling networks, examples of application layers include session initiation protocol layers, short message delivery point to point layers, and H.323 layers. The application identifiers for these layers may be parameters within the application layers or in lower layers used to carry the application layers.
In performing universal, automatic service selection, an STP may receive a signaling message requiring a routing address translation. In order to select the proper set of routing address translation data, the STP may decode an application identifier from the message. The application identifier may be used alone or combination with other parameters to select the appropriate routing address translation service. For example, the application identifier may be used in combination with any of the SCCP parameters mentioned above, including the translation type.
Using an application identifier that identifies an application layer message type to select the appropriate routing address translation service increases the likelihood that the message will be translated correctly and sent to the appropriate service providing node. For example, the opcodes used to indicate MAP message types are standardized. As a result, network operators use the same opcodes to identify the same message types. Thus, using an application to select the appropriate routing address translation service in these networks provides a more robust solution than using conventional SCCP selection parameters alone.
As used herein, the term “routing address translation” refers to translation of a parameter in a message into a routable destination address. In SS7 networks, one example of a routing address translation is GTT, which translates a called party address into a point code and subsystem number. Another example of a routing address translation includes a local number portability translation where the dialed digits in a message are translated into the LRN of an end office associated with the recipient exchange. The term “service selection” refers to processing for selecting the appropriate type of routing address translation service. For example, service selection may include identifying a global title translation application and/or data set to be used for processing a received message.
Accordingly, it is an object of the invention to provide methods and systems for universal, automatic service selection.
It is another object of the invention to provide methods and systems for service selection that do not rely solely on conventional SCCP selector parameters and/or the TCAP protocol type.
Some of the objects of the invention having been stated hereinabove, and which are addressed in whole or in part by the present invention, other objects will become evident as the description proceeds when taken in connection with the accompanying drawings as best described hereinbelow.
Preferred embodiments of the invention will now be described with reference to the accompanying drawings of which:
Disclosed herein are several embodiments of the present invention, which may include an underlying hardware platform similar to that of a signal transfer point (STP) or an SS7-over-Internet protocol signaling gateway.
Application subsystem 206 includes application cards or printed circuit boards capable of communicating with the other cards through the IMT communications bus or network. Numerous types of application cards can be included in SG 200. Exemplary application cards include an SS7 link interface module (LIM) 208 that provides SS7 links and X.25 links, a data communication module (DCM) 210 that provides an Internet protocol (IP) signaling interface to external nodes, and a high-speed asynchronous transfer mode (ATM) communication link module (HSL) 212. An application or database service module (DSM) 214 may host one or more signaling message processing applications, such as global title translation for different applications, number portability translation, call screening, pre-paid calling service, mobile services (e.g., home location register, short message service center, mobile authentication center, equipment identity register, or location-based service), 800 number service, caller identification service, and other applications that involve routing or application layer signaling message processing.
The architecture illustrated in
A number of distributed processing communication and application modules or cards may be coupled to IMT bus 302. In
As illustrated in
For received signaling messages that require MTP routing, routing function 320 is responsible for examining these messages and determining on which outbound signaling link or IP signaling link equivalent these messages are to be transmitted. Routing function 320 may transmit the messages to the outbound communication module (e.g., the LIM, the DCM, or HSL) associated with the selected signaling link via IMT bus 302.
If discrimination function 318 determines that a received signaling message requires processing by an internal application processor or subsystem of SG node 300, then the message is passed to message distribution function 320. In the embodiment illustrated in
In one embodiment, one or more DSMs in SG 300 may be configured to support one or more routing address translation or resolution services. Examples of such routing address translation or resolution services include local number portability (LNP) service and various types of global title translation service. These types of global title translation service may include conventional GTT service, which involves translating the SCCP called party address into a point code and subsystem number by performing a lookup in a GTT database that includes entries indexed by ranges of global title addresses and by individual global title addresses.
Yet another type of global title translation service that may be provisioned on a DSM is individual subscriber (10 digit) global title translation service for messages directed to HLRs or short message service centers. Yet another type of global title translation service that may be provisioned on a DSM is a combination of individual subscriber global title translation service and range based global title translation service for messages directed to HLRs or short message service centers. Still another type of global title translation service that may be provisioned includes G-Port® service, available from Tekelec of Calabasas, Calif. Briefly, G-Port® service includes responding to requests for routing information for ported-out mobile subscribers on behalf of a donor HLR and relaying messages for ported-in mobile subscribers to a recipient HLR.
In
The present invention is not limited to the specific architecture illustrated in
Table 1 shown below illustrates exemplary data structures that may be used by service selection function 324 in selecting the appropriate routing address translation service according to one embodiment of the present invention.
In Table 1, the exemplary translation service selector data includes a domain identifier, a global title indicator, an application identifier, a translation type, a numbering plan, a nature of address indicator, and a subsystem number. These parameters may be extracted from the SCCP and/or the TCAP/MAP portions of a message to determine the appropriate service type. Table 1 also includes a service identifier associated with the selected service type. The service identifier identifies the particular routing address translation service that will be performed for the signaling message.
As illustrated in Table 1, one parameter that may be used to select the appropriate routing address translation service is an application identifier. One example of an application identifier is the TCAP opcode. In ANSI SS7 networks, the TCAP opcode is a two-octet parameter located in the TCAP portion of the message used to provide instructions to application entities for processing the message. The two-octet parameter is divided into the operation family and the operation specifier. The operation family includes a seven-bit field that identifies the group or category related to the operation. The remaining bit of the operation family indicates whether or not a response is expected. The second octet of the operation code consists of the operation specifier, which is used to identify the operation being requested of the remote application. Because opcodes are standardized for certain operations or operation message types, these values may be used by routing address translation function 324 to reliably select a routing address translation service for a received signaling message. Because opcodes are standardized for other purposes, service selection based on these or similar parameters is automatic.
One type of opcode that may be used by service selection function 324 to select an appropriate routing address translation application includes opcodes that represent MAP message types. For example, in IS-41 networks, the opcode in a TCAP message that carries a MAP message is coded as private TCAP with a private TCAP specifier that defines the message type of the payload. For IS-41, the operation family is coded as 9, and bit H (the most significant bit) of the operation family is always coded as 0. Table 2 shown below illustrates exemplary private TCAP specifiers that may be used to identify specific MAP IS-41 message types:
Exemplary IS-41 messages in Table 2 that may require special types of routing address translations include registration notification messages, registration cancellation messages, location request messages, and routing request messages. These messages have specific TCAP opcodes as defined in the relevant IS-41 industry standards documents. Accordingly, service selection function 324 may use the TCAP opcode in order to identify the specific IS-41 MAP message type and direct the message to a routing address translation application associated with IS-41 routing address translation service.
GSM MAP also uses the translation capabilities application part to carry MAP messages. Accordingly, the TCAP opcode may be used to select the appropriate routing address translation services for GSM MAP messages. Exemplary GSM MAP opcodes that identify specific GSM MAP message types are defined in Digital Cellular Telecommunications System (Phase 2+); Mobile Application Part (MAP) Specification (3GPP TS 09.02 Version 7.6.0 Release 1998), the disclosure of which is incorporated by reference herein its entirety. One difference between ANSI and GSM opcodes is that GSM opcodes do not include a family identifier and thus consist only of 1 octet or byte of information. For mobile communications services, GSM MAP opcodes that correspond to send routing information messages, update location messages, and send routing information for SMS messages may be used to select a specific type of routing address translation services associated with GSM mobile networks.
In order to simultaneously support universal, automatic service selection for both ANSI and GSM networks, service selection function 324 may determine whether the MAP portion of the message is GSM or IS-41 MAP. This determination may be made by examining the MAP layer itself to determine whether the MAP protocol type is IS-41 or GSM. If a message is IS-41 MAP, service selection function 324 may decode a two octet opcode in the message. For the IS-41 MAP message, service selection function 324 may use data similar to that illustrated above in Table 2 to select the appropriate routing address translation service. If the message is GSM MAP, service selection function 324 may decode a one-octet opcode and use GSM MAP opcodes to select the service type. Thus, by identifying the appropriate message type, the universal, automatic service selection function of the present invention is capable of universal, automatic service selection in multiple different types of networks.
It is understood that although the translation type is listed as one of the selector parameters in Table 1, service selection function 324 may omit the translation type or any of the other SCCP parameters in Table 1 without departing from the scope of the invention. As indicated above, even though SS7 industry standards recommend the use of the translation type parameter for global title translation, many operators either ignore the translation type or associate the translation types with non-standard global title translation services. By using different combinations of parameters, in addition to or other than the translation type, the present invention provides a service selection function that is universally applicable to different networks. In addition, because the service selection may be based on an application identifier that identifies the application layer message type, and application layer message types are standardized, the universal, automatic service selection function of the present invention is more robust than conventional service selection functions that rely solely on SCCP parameters and/or the TCAP protocol type.
As discussed above, service selection may be based on an application identifier in the message received by the SG node 300. For instance, in one embodiment of the present invention, all GSM MAP UpdateLocation messages (opcode=2) received by the SG 300 may be directed to a global title translation application for HLR address translations. By using application identifiers, service selection is more universally applicable than conventional service selection applications that rely solely on SCCP layer parameters and/or the TCAP protocol type.
Table 3 shown below illustrates the structure of an ANSI TCAP message containing an invoke component. In the TCAP protocol, the invoke component consists of fields used to invoke a particular operation at the TCAP destination.
In Table 3, the invoke component includes the fields from the component type identifier through the parameters. The invoke component also includes an operation code. As stated above, the operation code may identify the message type carried by the TCAP message. Exemplary MAP opcodes that may be of interest to the present invention are described above with respect to Table 2. By decoding the operation code, service selection function 324 can determine the type of routing address translation to be performed for a received message.
Once the appropriate service has been selected, the routing address translation may be performed using the global title address stored in the SCCP called party address or digits present in the TCAP part of a message. For IS-41 MAP messages, digits used for routing address translations may be stored in the parameter set field of the TCAP message as indicated above in Table 3.
Because service selection function 324 may perform service selection based on an application identifier that identifies an application layer message type, service selection function 324 is capable of performing intelligent service selection in networks where the translation type is ignored or always set to the same value. In addition, service selection function 324 is capable of intelligently selecting the appropriate routing address translation service, even when messages are received from networks that use different or non-standard SCCP service selection values.
As indicated in
In the embodiment illustrated in
Once a particular routing translation application has been selected by LIM 310, the signaling message is distributed to the appropriately provisioned DSM 604, which resides at IMT bus address 1206. Routing address translation processing is performed by DSM 604 in a manner similar to that described above, and the translated message is routed via LIM 312 to the specified destination.
In the embodiment illustrated in
The selected service identifier may be used to select an available DSM processor that is configured to support APP2 routing address translation processing. Application processor identifier mappings similar to those shown above in Table 4 may be used by SSM 702 to distribute the signaling message to DSM 604, which resides at IMT bus address 1206. Routing address translation processing may then be performed by DSM 604. After routing address translation, the message may then be routed via LIM 312 to its intended destination.
Thus, by performing universal, automatic service selection based on application identifiers, the present invention provides a more robust solution than conventional service selection functions that rely solely on SCCP selection parameters and/or the TCAP protocol type. A service selection function according to the present invention examines an application identifier and optionally SCCP parameters to select the appropriate routing address translation service. Since many of these parameters are standardized for other purposes, such as application layer operations, service providers are required to use particular operation codes to invoke particular operations by applications. The service selection function of the present invention uses these parameters to select a routing address translation service. Performing service selection based on application layer parameters alone or in combination with SCCP parameters increases the efficiency of routing address translation service and increases the likelihood that messages will be sent to the appropriate routing address translation application and routed to the correct destination.
It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation—the invention being defined by the claims.
This application is a continuation-in-part of 1) U.S. patent application Ser. No. 09/759,743, filed Jan. 12, 2001, now U.S. Pat. No. 6,662,017, which is a continuation-in-part of U.S. patent application Ser. No. 09/471,946 filed Dec. 23, 1999, now U.S. Pat. No. 6,836,477 and which further claims the benefit of U.S. Provisional Patent Application No. 60/177,523 filed Jan. 21, 2000, and 2) U.S. patent application Ser. No. 09/747,070, filed Dec. 22, 2000, now U.S. Pat. No. 7,035,239, which is also a continuation-in-part of U.S. patent application Ser. No. 09/471,946 filed Dec. 23, 1999, now U.S. Pat. No. 6,836,477, the disclosures of each of which are incorporated herein by reference in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4310727 | Lawser | Jan 1982 | A |
| 4754479 | Bicknell et al. | Jun 1988 | A |
| 5089954 | Rago | Feb 1992 | A |
| 5237604 | Ryan | Aug 1993 | A |
| 5247571 | Kay et al. | Sep 1993 | A |
| 5251248 | Tokunaga et al. | Oct 1993 | A |
| 5400390 | Salin | Mar 1995 | A |
| 5422941 | Hasenauer et al. | Jun 1995 | A |
| 5423068 | Hecker | Jun 1995 | A |
| 5430719 | Weisser, Jr. | Jul 1995 | A |
| 5442683 | Hoogeveen | Aug 1995 | A |
| 5455855 | Hokari | Oct 1995 | A |
| 5457736 | Cain et al. | Oct 1995 | A |
| 5481603 | Gutierrez et al. | Jan 1996 | A |
| 5502726 | Fischer | Mar 1996 | A |
| 5504804 | Widmark et al. | Apr 1996 | A |
| 5526400 | Nguyen | Jun 1996 | A |
| 5579372 | Åström | Nov 1996 | A |
| 5590398 | Matthews | Dec 1996 | A |
| 5594942 | Antic et al. | Jan 1997 | A |
| 5623532 | Houde et al. | Apr 1997 | A |
| 5689548 | Maupin et al. | Nov 1997 | A |
| 5706286 | Reiman et al. | Jan 1998 | A |
| 5711002 | Foti | Jan 1998 | A |
| 5819178 | Cropper | Oct 1998 | A |
| 5832382 | Alperovich | Nov 1998 | A |
| 5854982 | Chambers et al. | Dec 1998 | A |
| 5878347 | Joensuu et al. | Mar 1999 | A |
| 5890063 | Mills | Mar 1999 | A |
| 5953662 | Lindquist et al. | Sep 1999 | A |
| 5953663 | Maupin et al. | Sep 1999 | A |
| 5983217 | Khosravi-Sichani et al. | Nov 1999 | A |
| 6006098 | Rathnasabapathy et al. | Dec 1999 | A |
| 6011803 | Bicknell et al. | Jan 2000 | A |
| 6014557 | Morton et al. | Jan 2000 | A |
| 6049714 | Patel | Apr 2000 | A |
| 6097960 | Rathnasabapathy et al. | Aug 2000 | A |
| 6115463 | Coulombe et al. | Sep 2000 | A |
| H1895 | Hoffpauir et al. | Oct 2000 | H |
| 6128377 | Sonnenberg | Oct 2000 | A |
| 6137806 | Martinez | Oct 2000 | A |
| 6138016 | Kulkarni et al. | Oct 2000 | A |
| 6138023 | Agarwal et al. | Oct 2000 | A |
| 6144857 | Price et al. | Nov 2000 | A |
| 6148204 | Urs et al. | Nov 2000 | A |
| 6192242 | Rollender | Feb 2001 | B1 |
| 6226517 | Britt et al. | May 2001 | B1 |
| 6411632 | Lindgren et al. | Jun 2002 | B1 |
| 6424832 | Britt et al. | Jul 2002 | B1 |
| 6535746 | Yu et al. | Mar 2003 | B1 |
| 6574481 | Rathnasabapathy et al. | Jun 2003 | B1 |
| 6577723 | Mooney | Jun 2003 | B1 |
| 6594258 | Larson et al. | Jul 2003 | B1 |
| 6683881 | Mijares et al. | Jan 2004 | B1 |
| 6950441 | Kaczmarczyk et al. | Sep 2005 | B1 |
| Number | Date | Country |
|---|---|---|
| 0 512 962 | Nov 1992 | EP |
| 0 944 276 | Sep 1999 | EP |
| 9512292 | May 1995 | WO |
| 9611557 | Apr 1996 | WO |
| 9733441 | Sep 1997 | WO |
| 9911087 | Mar 1999 | WO |
| 0016583 | Mar 2000 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20040081206 A1 | Apr 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60177523 | Jan 2000 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09759743 | Jan 2001 | US |
| Child | 10631586 | US | |
| Parent | 09471946 | Dec 1999 | US |
| Child | 09759743 | US | |
| Parent | 09747070 | Dec 2000 | US |
| Child | 09471946 | US | |
| Parent | 09471946 | Dec 1999 | US |
| Child | 09747070 | US |
