Method and apparatus for providing a virtual SS7 link in a communications system

[0002] The present invention relates generally to data transport and in particular to a method and apparatus for sending and receiving messages between two nodes in a communications system.

[0003] Signaling system number 7 (SS7) is a digital signaling standard developed by the International Telecommunication Union (ITU)—Telecommunications Standard Society (TSS). SS7 is the protocol for data communications in a communications system. In communications systems, a SS7 network is present, which is separate from the voice network. The SS7 network is used solely for the purpose of switching data messages pertaining to the business of connecting telephone calls and maintaining the signaling network. Common Channel Signaling (CCS) is the technology used in SS7 networks. CCS uses a digital facility, but places signaling information in a time slot or channel separate from the voice and data to which it is related. This mechanism allows signaling information to be consolidated and sent through its own network apart from the voice network. A packing switching system is the mechanism used for transferring messages throughout the network.

[0004] All nodes in a SS7 network are called “signaling points”. A signaling point has an ability to perform message discrimination (read the address and determine if the address is for that node), as well as to route the SS7 messages to another signaling point. The main type of signaling points is a service switching point (SSP), which is a local exchange in a telephone network. A SSP may be a combination of a voice switch and a SS7 switch, or an adjunct computer connected to the local exchange's voice switch. The SSP provides the functionality of communicating with the voice switch via the use of primitives and creating packets, or signal units needed for transmission in a SS7 network. Another signaling point is a signal transfer point (STP), which serves as a router in the SS7 network. All SS7 packets travel from one SSP to another through the services of a STP. Another signaling point is a service control point (SCP), which serves as an interface to telephone company databases.

[0005] SS7 is used in cellular networks to provide signaling information required to establish and disconnect circuit connections, as well as share database information from one institute to another. A mobile switching center (MSC) in a communications system connects to the SS7 via a signaling transfer point. The SS7 network is instrumental in collocating all the cellular providers together and allowing their various databases to be shared with each other. For example, the home location register (HLR) is a database used to store information about users of a cellular network. A visitor location register (VLR) is a database used to store temporary subscriber information when that subscriber is visiting the coverage area. This information is retrieved from the subscriber's HLR. With SS7 signaling through a SS7 network, data stored in a HLR can be stored with other MSCs across the SS7 network.

[0006] With the rapid expansion of communication systems, such as cellular networks, the expansion of SS7 networks has been limited and regulated. Concerns about capacity of SS7 links and the cost associated with expanding and creating SS7 networks for communication systems has made the development and expansion of communication systems, such as cellular systems, costly. In addition, with increased traffic on SS7 networks, concerns regarding congestion and flow control are present.

[0007] Therefore, it would be advantageous to have an improved method and apparatus for transporting messages in a SS7 network.

[0008] The present invention overcomes congestion and flow concerns in signaling networks, such as SS7 networks, by providing a virtual communications link or connection between various nodes in a SS7 network. The virtual link is provided by gateways, which send SS7 messages over a network link, such as an Internet protocol link. The present invention provides a method, apparatus, and instructions for establishing a virtual communication channel between applications on different nodes in which one node may be using a communication protocol stack based on one protocol, such as SS7, and another node may be using a communication protocol stack based on another protocol, such as IP. Alternatively, a virtual communication channel may be provided between applications on different nodes in which both nodes use a communication protocol stack based on IP to communicate with each other, but carry SS7 traffic through the communication channel. A gateway is provided in which both SS7 and IP are supported. The gateway allows for logical transport of signaling messages between peer applications on different nodes. Messages for SS7 are placed in data packets for transport to a destination using an IP connection or link to the destination. Header information also is placed into the data packet to allow for routing of the messages when the packet is received at the destination.

[0009] The link or connection may be to another gateway or to a node, which extracts the message and header information from the data packet and sends it on to the appropriate node using the header information.

[0010] The mechanism of the present invention provides for internetworking addressing schemes between both SS7 and Transport Control Protocol/Internet Protocol (TCP/IP). In addition, the present invention allows for addition of nodes without requiring expansion of an existing SS7 network.

[0011] Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

[0012] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0013] FIG. 1 is a diagram of a communications system depicted in accordance with a preferred embodiment of the present invention;

[0014] FIG. 2 is a diagram of a SS7 network depicted in accordance with a preferred embodiment of the present invention;

[0015] FIG. 3 is a block diagram of a data processing system, which may be implemented as a gateway, depicted in accordance with a preferred embodiment of the present invention;

[0016] FIG. 4 is a diagram illustrating a SS7 gateway used as an interface between a SS7 network node and a SS7 network depicted in accordance with a preferred embodiment of the present invention;

[0017] FIG. 5 is a diagram of a virtual SS7 link created by gateways depicted in accordance with a preferred embodiment of the present invention;

[0018] FIG. 6 is a diagram illustrating the various components used in providing a virtual SS7 connection depicted in accordance with a preferred embodiment of the present invention;

[0019] FIG. 7 is an illustration of a data packet sent over an IP network by a gateway depicted in accordance with a preferred embodiment of the present invention;

[0020] FIG. 8 is a table of fields used in a gateway header depicted in accordance with a preferred embodiment of the present invention;

[0021] FIG. 9 is a block diagram of data flow for a SCCP-IP unit depicted in accordance with a preferred embodiment of the present invention;

[0022] FIG. 10 is a flowchart of a process used by a SCCP-IP in response to a request to establish a connection depicted in accordance with a preferred embodiment of the present invention;

[0023] FIG. 11 is a flowchart of a process used in sending a message by a SCCP-IP depicted in accordance with a preferred embodiment of the present invention;

[0024] FIG. 12 is a flowchart of a process for processing a message received from an IP network by a SCCP-IP depicted in accordance with a preferred embodiment of the present invention;

[0025] FIG. 13 is a flowchart of a process for releasing a connection depicted in accordance with a preferred embodiment of the present invention;

[0026] FIG. 14 is a block diagram of data flow in a gateway internetworking unit depicted in accordance with a preferred embodiment of the present invention;

[0027] FIG. 15 is a flowchart of a process for receiving messages from an IP network by a gateway internetworking component depicted in accordance with a preferred embodiment of the present invention;

[0028] FIG. 16 is a flowchart of a process used to receive SS7 messages depicted in accordance with a preferred embodiment of the present invention;

[0029] FIG. 17 is a diagram of data flow in a SCCP-IP used in establishing a single connection between a gateway and a client depicted in accordance with a preferred embodiment of the present invention;

[0030] FIG. 18 is a flowchart of a process for establishing a connection depicted in accordance with a preferred embodiment of the present invention;

[0031] FIG. 19 is a process for sending messages depicted in accordance with a preferred embodiment of the present invention;

[0032] FIG. 20 is a flowchart of a process for processing received messages depicted in accordance with a preferred embodiment of the present invention;

[0033] FIG. 21 is a block diagram of data flow in a gateway internetworking unit depicted in accordance with a preferred embodiment of the present invention;

[0034] FIG. 22 is a flowchart of a process for receiving messages depicted in accordance with a preferred embodiment of the present invention;

[0035] FIG. 23 is a process for handling SS7 messages depicted in accordance with a preferred embodiment of the present invention;

[0036] FIG. 24 is a flowchart of a process for encapsulating a message into a data packet depicted in accordance with a preferred embodiment of the present invention; and

[0037] FIG. 25 is a flowchart of a process for extracting a message from a data packet depicted in accordance with a preferred embodiment of the present invention.

[0038] With reference now to the figures, and in particular with reference to FIG. 1, a diagram of a communications system is depicted in accordance with a preferred embodiment of the present invention. Communications system 100 includes a voice network 102, signaling network 104, signaling network 106, and an Internet protocol (IP) network 108. Voice network 102 carries voice data for various calls within communications system 100. In the depicted example, signaling network 104 and signaling network 106 are SS7 networks, which are separate from voice network 102 and are used for the purpose of switching data messages pertaining to call control signaling for telecommunications services within voice network 102. Signaling network 104 uses a common channel signaling (CCS) in which a single channel conveys, by various labeled messages, signaling information relating to various circuits or other information such as that used for a network management.

[0039] In the depicted examples, messages are generated by a user or processor pertaining to call management within voice network 102 as part of the signaling in a signaling network, which is a set of transport facilities that carry signals. A SS7 network is a signaling network. Signaling network 104 and signaling network 106 are examples of a signaling network. Signaling is used to establish a connection, to monitor and supervise the status of the connection, and to terminate the connection. Signaling is the act of transferring this information between nodes. Signals, also referred to as signaling data, may include data signals, control signals, timing signals, but exclude voice. A data link is a connection between two nodes used to transfer signaling information between nodes. A data link as used herein excludes voice.

[0040] The present invention provides a mechanism in which messages using SS7 may be transferred outside of signaling network 104 to a node within signaling network 106. The messages may be sent through IP network 108 through gateway 110 and gateway 112. These gateways provide a mechanism for carrying messages from signaling network 104 to signaling network 106 in a manner that is transparent to various nodes within these SS7 networks. Gateways 110 and 112 may be used to connect two nodes over a standard transmission control protocol/Internet protocol (TCP/IP) used for data transmission of SS7 messages over networks, such as the Internet. IP is the protocol within TCP/IP that governs the breakup of data messages into packets, the routing of the packets from sender to destination network and station, and the reassembly of the packets into the original data messages at the destination. IP corresponds to the network layer in the ISO/OSI model. TCP is the protocol within TCP/IP that governs the breakup of data messages into packets to be sent via IP, and the reassembly and verification of the complete messages from packets received by IP. TCP corresponds to the transport layer in the ISO/OSI model.

[0041] Further, data may be transfer to other nodes within signaling network 104 through IP network 108. This communications link is created through gateway 110 and gateway 114. Messages within a node in signaling network 104 may be sent to another node in signaling network 104 using a communications link established through gateway 110 and gateway 114. Messages are transferred through gateway 110 onto IP network 108 to gateway 114 and to another node within signaling network 104. In this manner, additional expansion of signaling network 104 is unnecessary and communications links established between gateway 110 and gateway 114 may be used to transport data messages when congestion occurs within various points within signaling network 104.

[0042] The use of IP network 108 to transport messages provides an advantage over current SS7 signaling because IP has a greater bandwidth. Currently, SS7 networks nominally have a 64K-transfer rate. In some cases, the rates may be 1.544 Mbps or 2.048 Mbps. IP networks can handle up to 100 Mbps. Further, extensive IP networks are present and available for use and do not require the same expense as expanding or creating SS7 networks.

[0043] For example, in typical SSP connection scenario, a mobile switching center (MSC) is connected to another MSC with STP functionality. In accordance with a preferred embodiment of the present invention, a TCAP encoded Mobile Application Part (MAP) message is wrapped in a special “SCCP-IP” header and transmitted over IP to an intermediate node. The intermediate node receives the payload, unwraps the “SCCP-IP” header, re-wraps it into a standard SCCP header and transmits it using Message Transfer Part (MTP) of SS7 to the destination node. The intermediate node may also transmit the message to an IP node with no modification. On this manner, the mechanism of the present invention may be used for peer to peer communication in a fashion similar to that in a SS7 network. The protocol can connect any client node to any SS7 node for connecting to the SS7 network. Further, the mechanism of the present invention may be used to connect a node that does not communicate over SS7 with a node within the SS7 network. With reference now to FIG. 2, a diagram of a SS7 network is depicted in accordance with a preferred embodiment of the present invention. In this example, signaling network 200 is a SS7 network, which includes service-switching points (SSPs) 202-210, signal transfer points (STPs) 212-218 and service control points (SCPs) 220-224. An SSP is a local exchange in a telephone network and may be a combination of a voice switch and a SS7 switch, or an adjunct computer connected to a voice switch and the local exchange. SSPs provide the functionality of communicating with the voice switch via the use of primitives and creating packets, or signaling units, needed for transmission in signaling network 200. SSP 208 and SSP 210 may establish a voice trunk between the two exchanges, but establish this trunk via a signaling path through STPs 214 and 216 within signaling network 200.

[0044] A STP serves as a router in the SS7 network. A SCP serves as an interface to a database in the communications system. Databases are typically used to store information about subscriber services, routing and special service numbers, such as 800 and 900 numbers, calling card validation, and fraud protection. For example, a home location register (HLR) contains a database, which is found in cellular networks and is used to store information regarding a cellular subscriber. The HLR stores information regarding billing, services allowed, and the current location of the cellular phone. A visitor location register (VLR) is used to store data about a subscriber whenever the subscriber is registered in the area served by that MSC whether or not the subscriber is local. HLR data is always forwarded to the VLR. The HLR from which it gets the subscriber data may be local or remote. The VLR is used to store current locations for visiting subscribers. The VLR communicates this information to the HLR to allow the HLR to track subscriber locations. In the depicted examples, VLR and HLRs are colocated with a MSC and are also SSPs.

[0045] In addition, signaling network 200 also includes gateways 226 and 228, which may be used as an alternative path to connect SCP 222 to STP 216. Alternatively, gateways 226 and 228 may be used to form a connection between STP 216 and STP 218. Gateway 228, may provide a connection between STP 218 and SCP 224, which is a SCP not normally connected to signaling network 200. Gateway 228 provides a connection between STP 218, which communicates using SS7 while SCP 224 is accessed using another protocol, such as IP. Computers are used at these signaling points to perform signaling functions.

[0046] Referring to FIG. 3, a block diagram of a data processing system, which may be implemented as a gateway, is depicted in accordance with a preferred embodiment of the present invention. Data processing system 300 may be used to implement gateways, such as gateways 110, 112, and 114 in FIG. 1 or gateways 226 and 228 in FIG. 2.

[0047] Data processing system 300 may be a symmetric multiprocessor (SMP) system including processors 302 and 304 connected to system bus 306. Alternatively, a single processor system may be employed. Also connected to system bus 306 is memory controller/cache 308, which provides an interface to local memory 309. I/O bus bridge 310 is connected to system bus 306 and provides an interface to I/O bus 312. Memory controller/cache 308 and I/O bus bridge 310 may be integrated as depicted.

[0048] Peripheral component interconnect (PCI) bus bridge 314 connected to I/O bus 312 provides an interface to PCI local bus 316. A number of modems may be connected to PCI bus 316. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to other computers or nodes in signaling network 104, signaling network 106 or IP network 108 in FIG. 1 may be provided through network adapter 318 and network adapter 320 connected to PCI local bus 316 through add-in boards. Network adapter 318 may provide communications with a SS7 network while network adapter 320 may provide communication with an IP network.

[0049] Additional PCI bus bridges 322 and 324 provide interfaces for additional PCI buses 326 and 328, from which additional modems or network adapters may be supported. In this manner, server 300 allows connections to multiple nodes on different networks. A memory-mapped graphics adapter 330 and storage unit 332 may also be connected to I/O bus 312, either directly or indirectly. Storage unit 332 may be implemented in a number of ways. For example, storage unit 332 may be a hard disk or an array of hard disks. Additionally, storage unit 332 may be a heterogeneous storage system containing devices, such as hard disks, DVD drives, and tape drives. With this system, the process of the present invention may be executed by processors 302 and 304 through instructions and data located in local memory 309 and storage unit 332.

[0050] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 3 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

[0051] With reference now to FIG. 4, a diagram illustrating a gateway used as an interface between a SS7 network node and a SS7 network is depicted in accordance with a preferred embodiment of the present invention. In this example, MSC/VLR 400 may communicate with SS7 node 404 through switch 406. Link interface unit (LIU) 408 and link interface unit (LIU) 410 are used to establish SS7 link 412. Messages may be sent to SS7 node 404 via gateway 414, which establishes an IP link 416 with node 404 in this example. Node 404 may be connected to a SS7 network (not shown).

[0052] Turning next to FIG. 5, a diagram of a virtual SS7 link created by gateways is depicted in accordance with a preferred embodiment of the present invention. In this example, MSC/VLR 500 may register information from mobile station 502, which is in the area managed by MSC/VLR 500. Mobile station 502 is a visitor in this area and information about mobile station 502 is stored within VLR 500. In addition, information is sent to HLR 506 so that HLR 506 may track the location of mobile station 502. In the depicted example, this information is sent over virtual SS7 link 508, which is an IP link carrying SS7 traffic using IP packets. Virtual SS7 link 508 is established between SS7 gateway 510 and SS7 gateway 512. SS7 messages are encapsulated in IP packets for transport over virtual SS7 link 508. In this instance, virtual SS7 link 508 acts as a high-capacity traffic tunnel for carrying SS7 traffic between MSC/VLR 500 andHLR 506. This link may be used when current bandwidth within a SS7 network is insufficient to support applications like LNP or due to the number of subscribers. Alternatively, the virtual SS7 link may be used as a permanent connection to carry SS7 traffic. In this manner, peer to peer communication in a fashion similar to that on a SS7 network may be provided. Thus, the present invention allows for expansion of SS7 message transport when current SS7 networks are at capacity using a less costly infrastructure.

[0053] Turning now to FIG. 6, a diagram illustrating the various components used in providing a virtual SS7 connection is depicted in accordance with a preferred embodiment of the present invention. In this example, a node 600 may exchange messages with another node 602 through a gateway 604. In this example, node 600 is connected to a SS7 network, while node 602 is connected to an IP network. Node 600 may be a node, such as MSC/VLR 406 in FIG. 4, while node 602 may be an SS7 node, such as SS7 node 404 in FIG. 4. In such an instance, a IP link, such as IP link 416, is the connection used to carry traffic between node 602 and node 604, while communications between node 600 and 604 may be established through an SS7 link, such as SS7 link 412 in FIG. 4.

[0054] Gateway 604 provides a bridge between the SS7 network and the IP network and provides the mechanism to allow transfer of SS7 messages between node 600 and node 602. Application 606 in this example is a short message service (SMS).In this example, the message is sent by application 608 using mobile application part (MAP) 610, which in this example is used for a global system for mobile communications (GSM) wireless network. MAP is used in cellular networks to provide a mechanism by which cellular subscriber information may be passed from one cellular network to another. Transaction capabilities application part (TCAP) 614 is a protocol is an encoding scheme used to allow peer applications to establish, maintain, and terminate massaging dialogs. TCAP 614's functions include functions, such as those required to connect to an external database, perform a query of the database, and retrieve information. In this example, no changes to software or protocol layers are required in the SS7 nodes. All functionality for transporting data between SS7 and IP networks is provided through the gateway. The information or data retrieved is then sent back in the form of a TCAP message to the node requesting the information. TCAP also supports remote control of other entities within a SS7 network.

[0055] Node 600 communicates using SS7 protocols. In particular, node 600 includes signaling connection control part (SCCP) 618. SCCP 618 is a protocol used for accessing remote applications and other entities. SCCP 618 provides the address necessary to route a message to the correct application, such as, for example, a database. These addresses are also called subsystem numbers and are logical addresses used by the protocols to route a message to the appropriate application entity. SCCP 618 also is considered part of layer 3 in an International Organization for Standardization Open Systems Interconnect (ISO/OSI) model. SCCP 618 relies on the services of a message transfer part (MTP), which acts as a carrier for all SS7 messages to provide reliable transfer of messages from one signaling point to another signaling point. In this example, MTP includes message transfer part level 3 (MTP3) 620, message transfer part level 2 (MTP2) 622, and message transfer part level 1 (MTP1) 624. The MTP provides the same functionality as layers 1, 2, and 3 in the ISO/OSI model. These layers are the physical, data link, and network layers in OSI. SCCP 618 provides a means for end to end routing while MTP is capable of only point to point routing. As a result, a message can be routed only on the physical links available from a signaling point. SCCP 618 provides addressing to route a message through the entire network with this information being used by each signaling point by MTP3620 to determine which link set to use. MTP2622 provides functions necessary to provide error detection and correction for signaling units. MTP1624 is a physical layer, which allows for the use of any digital type interface supporting the data rate required by the network. MTP3620 provides for message routing, message discrimination, message distribution, and network management.

[0056] In contrast, node 602 communicates using an IP protocol. Node 602 includes a SCCP-IP 626, which defines a mechanism for establishing and maintaining connections for the application on the TCP/IP stack and provides an interface for message transport. Transmission control protocol (TCP) 628 and Internet protocol (IP) 630 form the protocol that governs the breakup of data messages into packets to be sent via IP and the reassembling and verification of the complete messages from packets received by IP. TCP 628 corresponds to a transport layer in the ISO/OSI model, while IP 630 corresponds to the network layer within the ISO/OSI model. Ethernet 632 provides the physical interface for transmitting data over an IP network. Of course, the data may be transferred by another mechanism used to communicate over an IP network.

[0057] Gateway 604 includes the necessary components to communicate with both types of networks. In particular, gateway 604 includes SCCP 634, MTP3636, MTP2638, and MTP1640, which are used to provide communications with a SS7 network. In addition, gateway 604 also includes SCCP/IP 642, TCP 644, IP 646, and Ethernet 648 which provide the components necessary to communicate on an IP network. TCAP can either be connection oriented or connectionless. MAP makes use of mainly the connection oriented capabilities of TCAP. SCCP can be either connection oriented on connectionless. MAP/TCAP mainly uses the connectionless facilities of SCCP. TCAP is used to provide the connection to the MAP protocol. The SCCP-IP components illustrated in FIG. 6 provide connection management with the TCP components. In addition, SCCP header encoding and decoding is provided by this particular component. Also, this component provides an application program interface to the application, such as application 608.

[0058] Internetworking 650 is a gateway TCP message handling mechanism that provides for receiving and sending of TCP messages. Internetworking 650 provides the mechanism used to place SS7 messages into an IP packet and to remove SS7 from IP packets. In addition, internetworking 650 allows for SS7 message handling. Internetworking 650 provides signaling message internetworking along with SS7 to TCP connection maintenance internetworking, such as error control, congestion control, and connection status propagation. A pair of gateways, such as gateway 604, may be used to provide a virtual SS7 link between two nodes that communicate using SS7. Alternatively, a single gateway is sufficient depending on the implementation. TCAP 614 is a mechanism that provides transaction management with its peer TCAP 616, both of which serve the MAP application SMS (606 and 608) in this example. TCAP 614 and TCAP 616 communicate using the communication protocol and mechanism described in the previous paragraphs.

[0059] With reference now to FIG. 7, an illustration of a data packet sent over an IP network by a gateway is depicted in accordance with a preferred embodiment of the present invention. Data packet 700 includes a header 702, which is a standard 8 byte IP header. The payload area of data packet 700 contains a short gateway header 704, which is 34 bytes in this example. In the depicted example, gateway header 704 is a header for a short message service (SMS) MAP message. In addition, a message 706 is contained within the payload of data packet 700. In this example, message 706 is a SMS MAP message. This message is a variable TCAP message in the depicted example.

[0060] Turning next to FIG. 8, a table of fields used in a gateway header is depicted in accordance with a preferred embodiment of the present invention. Table 800 depicts data that may be used in SMS gateway header 704 in data packet 700. These fields within gateway header 704 are used to process the message within the IP packet when the IP packet is received by a gateway. In the depicted example, these fields are used with a short message service (SMS) as well as with other protocols. The gateway header is application independent. The fields are used to place the message within the IP packet with the gateway header containing the information necessary to extract the message from the packet and then route it on to the destination. In particular, gateway header 704 in FIG. 7 would include a network type 802, a protocol version 804, a universal data type (UDT) data format 806, a sequence control 808, SCCP class 810, return information 812, called party address 814, calling party address 816, spare 818, and data length 820.

[0061] Network type 802 provides information as to how the message is encoded. This field provides an indication of the network to which the message is being transferred. Protocol version 804 is used to correspond implementations of the protocol between the gateway and the remote application. UDT data format 806 is a field that provides a data format for decoding of messages. Sequence control 808, SCCP class 810, return information 812, calling party address 816, and data length 820 are fields that are normally found in a SCCP header.

[0062] The information in the gateway header as illustrated in table 800 is selected as a minimal set of information from SCCP header information that is available in a SS7 node at either end of the connection created by a gateway. The amount of information within the gateway header is selected to be sufficient to allow a SS7 node to continue routing the message associated with the gateway header.

[0063] The gateway may provide connections to one or more clients over an IP link. The gateway maintains a table of addresses used to translate an SS7 address of a SS7 node to form an IP address. In essence, the gateway acts as a multiplexer in which the chosen representation is a session on the gateway that uniquely identifies each connection. The sessions are required for all TCP connections as well as clients or SS7 nodes registered to the gateway. The implementation described in FIGS. 9-16 refers to an implementation in which the SCCP-IP acts both as a sever and client. In FIG. 17-25, the implementation depicted is one in which the SCCP-IP is always only a server on the gateway.

[0064] In FIG. 9, a block diagram of data flow for a SCCP-IP unit is depicted in accordance with a preferred embodiment of the present invention. SCCP-IP 900 may be implemented either in SCCP-IP 642 in gateway 602 or in SCCP-IP 626 in node 604 in FIG. 6. SCCP-IP 900 interfaces between an application and an IP network. The application may be an application, such as application 608 in node 602 or internetworking 650 in gateway 604. SCCP-IP 900 may both act as a server and a client. The gateway has knowledge of SCCP-IP applications, which are transaction oriented and a connection is established at either end for a new TCAP transaction. In this instance, SCCP-IP is a server on the gateway and a client on the application.

[0065] SCCP-IP 900 may receive, connect, disconnect, and send message requests from an application. These request translate into TCP connect, TCP close, and send message requests that are sent on to an IP network by SCCP-IP 900. In response to receiving a message from the IP network, SCCP-IP 900 will send a received message to the application. In response to establishing a connection, SCCP-IP 900 may send the application connection status information. Errors also may be sent to the application by SCCP-IP 900.

[0066] The figures and flowcharts 10-13 illustrate processes employed by SCCP-IP 900 in FIG. 9.

[0067] With reference now to FIG. 10, a flowchart of a process used by SCCP-IP 900 in response to a request to establish a connection is depicted in accordance with a preferred embodiment of the present invention. The process begins by receiving a connection request from the application (step 1000). Thereafter, a determination is made as to whether the request contains a global title (GT) translation or point code (PC) and subsystem number (SSN) (step 1002). The request made by the application for a connection is made by providing either a SCCP address either as a global title or a point code and subsystem number. When the address is a global title, such as an 800 number, then a global title translation is performed to obtain the point code and subsystem number (step 1004).

[0068] Thereafter, the point code and subsystem number is used to determine the gateway server address (step 1006). This process proceeds directly to this step from step 1002 if the request includes a point code and subsystem number. Step 1006 provides an IP address for the gateway server. Global title translation is a standard SS7 function that may be used to change signaling addresses to obtain a destination, which is identified by the point code, and an application at the destination, which is identified by the subsystem number. This information is preset for particular destinations. The identification may be made by interrogating a database containing the appropriate IP address for a particular point code and subsystem number.

[0069] Next, a TCP socket is opened with a keep-alive option (step 1008). In the depicted example, the keep-alive option is used to maintain the connection after establishment of the connection. In these examples the option is part of the IP protocol. This keep-alive option may be implemented in a number of ways depending on the design. For example, a timer may be set to a number of seconds on both ends of the communications link and on the expiration of the timer, each side will register the length as out of service and start a recovery procedure and repeat the procedure until successful. Detection of traffic on the length may cause the timer to be reset without expiring.

[0070] Then, a connection is made to a SS7 gateway server (step 1010). This connection is performed using known IP connection processes to send a message and receive a response to the message in the form of an acknowledgement. In response to a connection being made with the gateway server, then the socket is recorded against the transaction ID (step 1012) with the process terminating thereafter. In this instance, the point code and subsystem number is recorded along with the socket to allow translating a connection from SS7 to IP. At this point, a connection has been established.

[0071] With reference now to FIG. 11, a flowchart of a process used in sending a message by a SCCP-IP is depicted in accordance with a preferred embodiment of the present invention. This process is used to transport SS7 messages, such as a message encoded using TCAP rules. The process begins by receiving a message from the application (step 1100). The message is encoded according to TCAP encoding rules. Upon receiving the message from the application, a gateway header is encoded and the message from the application also is encoded as data into a packet for transport on the IP network (step 1102). Thereafter, the encoded message is sent (step 1104). This encoded message is an IP data packet, such as data packet 700 in FIG. 7.

[0072] With reference now to FIG. 12, a flowchart of a process for processing a message received from an IP network by a SCCP-IP is depicted in accordance with a preferred embodiment of the present invention. This process is used to process messages received from an IP network by the SCCP-IP. The process begins by receiving a message (step 1200). This message is in the form of a data packet used for transport on an IP network. The gateway header is decoded and the message is extracted from the data field in the data packets (step 1202). Thereafter, the message is sent to the application (step 1204) with the process terminating thereafter.

[0073] Turning next to FIG. 13, a flowchart of a process for releasing a connection is depicted in accordance with a preferred embodiment of the present invention. The process begins by receiving requests to disconnect connection (step 1300). Thereafter, the TCP connection is closed with the far end identified by the TCP socket (step 1302). Then, the socket is released along with transaction resources used in maintaining the socket (step 1304) with the process terminating thereafter.

[0074] Turning next to FIG. 14, a block diagram of data flow in a gateway internetworking unit is depicted in accordance with a preferred embodiment of the present invention. In this example, gateway internetworking 1400 may well send messages between a SS7 network and an IP network. Gateway internetworking 1400 may receive SS7 messages and SCCP management (SCMG) messages from a SS7 network. Gateway internetworking 1400 may send SS7 messages and also send SCMG messages to a SS7 network. In addition, gateway internetworking 1400 may connect and close TCP connections along with sending messages onto the IP network as well as received messages from the IP network.

[0075] The flowcharts in FIGS. 15 and 16 illustrate processes used by gateway internetworking 1400 in FIG. 14.

[0076] With reference now to FIG. 15, a flowchart of a process for receiving messages from an IP network by a gateway internetworking component is depicted in accordance with a preferred embodiment of the present invention. This process is used to identify connections to another node or gateway on the IP network. The process begins by receiving an IP message (step 1500). Thereafter, the gateway header is decoded and the message is extracted from the data field of the IP message (step 1502). A determination is then made as to whether a transaction ID has been recorded for this message (step 1504). If a transaction ID has not been recorded, then a transaction ID is recorded against the TCP socket (step 1506). The determination is made by querying a database of connections for known sockets to see if the transaction ID is associated with the particular socket. If the transaction ID has been recorded, then after the recording of the transaction ID a SCCP header is encoded (step 1508) and a SS7 message is then sent (step 1510) with the process terminating thereafter.

[0077] With reference now to FIG. 16, a flowchart of a process used to receive SS7 messages is depicted in accordance with a preferred embodiment of the present invention. The process begins by receiving a SS7 message (step 1600). Thereafter, a determination is made as to whether the subsystem number (SSN) in the message is equal to zero (step 1602). A zero would indicate that a SCMG message has been received. If this determination is yes, then a determination is made as to whether the message is a subsystem test (SST) message (step 1604). A subsystem test message is used to inquire whether a remote peer SCCP application is available.

[0078] If the message is a subsystem test message then the point code and subsystem number are used to determine an SS7 application server address (step 1606). A determination is then made as to whether the maintenance connection is active (step 1608). If the maintenance connection is active, then a subsystem allowed message (SSA) is sent for the particular subsystem number as a SCMG message (step 1610) with the process terminating thereafter. If the connection is not alive, the SSP for the SSN is sent (step 1611) with the process then terminating. In SS7, subsystem number zero is a reserved number that corresponds to a SCCP management SCMG message.

[0079] With reference again to step 1604, if the determination made as to whether the message is a subsystem test message is no, then the process determines whether the message is a subsystem allowed message (step 1612). This determination is used to handle non-SST subsystem messages. If the message is a subsystem allowed message, the process then marks the point code and subsystem number as being available at the remote SS7 node (step 1614) with the process terminating thereafter. Otherwise, the point code subsystem number is marked as being prohibited or unavailable at the remote SS7 node (step 1616) with the process terminating thereafter.

[0080] With reference again to step 1602, if the subsystem number is not equal to zero, then the SCCP header is decoded (step 1618). A determination is then made as to whether a global title or a point code is contained within the header (step 1620). If a global title (GT) is present, then a global title translation is performed to obtain a SS7 point code (step 1622). Thereafter, the point code and subsystem number are used to determine a SS7 application server address (step 1624). With reference again to step 1620, if a point code is present, the process proceeds directly to step 1624.

[0081] Next, a determination is made as to whether a transaction ID has been recorded for this particular socket (step 1626). If a transaction ID has not been recorded, the process then opens a TCP socket with a keep-alive option (step 1628). Thereafter, a connection is made with the application server (step 1630).

[0082] When the connection has been established, a SCCP-IP header is encoded along with the application message being placed in a data packet as data (step 1632). Thereafter, the encoded message is sent resulting in the sending of the message on the IP network (step 1634) with the process terminating thereafter.

[0083] With reference to step 1626, if a transaction ID has been recorded, the process then proceeds to step 1632 as described above.

[0084] FIGS. 17-25 illustrate and embodiment in which the SCCP-IP is always a server on the gateway. Next in FIG. 17, a diagram of data flow in a SCCP-IP used in establishing a single connection between a gateway and a client is depicted in accordance with a preferred embodiment of the present invention. SCCP-IP 1700 may receive a message to be sent from an application. In addition, SCCP-IP may open and close TCP connections along with sending messages to the IP network on opened TCP connections. SCCP-IP may receive messages on the connection and send the message on to an application in addition to providing the application with the connection status and identification of errors.

[0085] The processes illustrated in FIGS. 18-20 are those used by an SCCP-IP in establishing a single connection. In addition, this single connection may be established between two gateways.

[0086] With reference now to FIG. 18, a flowchart of a process for establishing a connection is depicted in accordance with a preferred embodiment of the present invention. The process begins by finding a server address for the particular point code and subsystem number combination (step 1800). Thereafter, a TCP socket for the server address is opened with the keep-alive option (step 1802). Thereafter, a connection is made with the SS7 gateway server (step 1804). The socket is recorded with the point code and subsystem number (step 1806). Thereafter, a determination is made as to whether additional point code and subsystem number combinations are present for processing (step 1808). If additional point code and subsystem number combinations are present for processing, the process then returns to step 1802. Otherwise, the process terminates.

[0087] With reference now to FIG. 19, a process for sending messages is depicted in accordance with a preferred embodiment of the present invention. This figure illustrates the process used by SCCP-IP 1700 in FIG. 17 to send messages received from an application. The process begins by receiving a message from the application to be sent to a destination (step 1900). The message received is an encoded message from the application. The message is encoded using TCAP encoding rules. In addition, an SCCP address is provided either as a global title or point code and SCCP subsystem number. In step 1902, a determination is made as to which type of address has been provided. If the address is a global title, then a global title translation is performed to obtain the is SS7 point code (step 1904). The process then uses the point code and subsystem number to identify a gateway server address (step 1906). The process proceeds directly to step 1906 from step 1902 if the address provided by the application is a point code. Next, the SCCP-IP header is encoded along with decoding the application message as data within a data packet for transport on an IP network (step 1908). Thereafter, the decoded message is then sent to the IP network (step 1910) with the process terminating thereafter.

[0088] Turning to FIG. 20, a flowchart of a process for processing received messages is depicted in accordance with a preferred embodiment of the present invention. This flowchart is used to describe the processing of messages received from an IP network. The process begins by receiving a message (i.e., IP data packet) from the IP network (step 2000). Thereafter, the gateway header is decoded and the message is extracted from the data field of the data packet received from the IP network (step 2002). Thereafter, the message is forwarded to the application (step 2004) with the process terminating thereafter.

[0089] With reference now to FIG. 21, a block diagram of data flow in a gateway internetworking unit is depicted in accordance with a preferred embodiment of the present invention. Gateway internetworking unit 2100 may receive SS7 messages and SCCP management messages from a SS7 network. In response, gateway internetworking unit 2100 may send IP messages onto the IP network. In addition, IP messages may be received and sent to destinations on the SS7 network. Also, TCP connect and TCP close request may be received by gateway internetworking unit 2100.

[0090] In FIG. 22, a flowchart of a process for receiving messages is depicted in accordance with a preferred embodiment of the present invention. The process begins by receiving an IP data packet from the IP network (step 2200). Thereafter, the gateway header is decoded and the message is extracted from the data field of the IP data packet received from the IP network (step 2202). A determination is then made as to whether the address is a global title or point code and subsystem number address (step 2204). If the address is a global title address, a global title translation is performed to derive a SS7 point code address (step 2206). Thereafter, the process encodes a SS7 SCCP header (step 2208). The process also proceeds directly to step 2208 from step 2204 if the address has a point code address. Next, a message is sent to the node identified by the point code and subsystem number (step 2210) with the process terminating thereafter.

[0091] With reference now to FIG. 23, a process for handling SS7 messages is depicted in accordance with a preferred embodiment of the present invention. The process begins by receiving a SS7 message (step 2300). Thereafter, a determination is made as to whether the subsystem number in the message is equal to zero (step 2302). A zero would indicate that a SCMG message has been received. If this determination is yes, then a determination is made as to whether the message is a subsystem test (SST) message (step 2304). If the message is a subsystem test message then the point code and subsystem number are used to determine a SS7 application server address (step 2306). A determination is then made as to whether the connection is alive (step 2308). If the connection is alive, then a subsystem allowed message is sent for the particular subsystem number as a SCMG message (step 2310) with the process terminating thereafter. If the connection is not alive in step 2308, the SSP for the SSN is sent (step 2311) with the process then terminating. In SS7, subsystem number zero is a reserved number that corresponds to a SCCP management (SCMG) message. A subsystem test message is used to verify that a connection is present between peer SCCP and applications, send a message between peers to establish a connection in this example.

[0092] With reference again to step 2304, if the SS7 message is not a subsystem test message, a determination is made as to whether the message is a subsystem allowed (SSA) message (step 2312). If the message is a subsystem allowed message, the process then marks the point code and subsystem number as being available at the remote SS7 node (step 2314) with the process terminating thereafter. Otherwise, the point code and subsystem number is marked as being prohibited or unavailable at the remote SS7 node (step 2316) with the process terminating thereafter.

[0093] With reference again to step 2302, if the SCCP subsystem is not equal to zero, then the SS7 message is parsed and the SCCP header is decoded (step 2318). Thereafter, a determination is made as to whether the header includes a global title or point code address (step 2320). If the address is a global title, the process then performs a global title translation to obtain the SS7 point code (step 2322). Thereafter, the point code and subsystem number are used to determine a SS7 application server address (step 2324).

[0094] With reference again to step 2320, if the address is a point code address, the process proceeds to step 2324 as described above. Next, a gateway header is encoded along with the application message into the data field of an IP data packet (step 2326). The encoded messages are then sent on the connection established for the particular IP nodes (step 2328) with the process terminating thereafter.

[0095] In FIG. 24, a flowchart of a process for encapsulating a message into a data packet is depicted in accordance with a preferred embodiment of the present invention. This process is used to create data packets for transport on an IP network using messages designed for transport on a SS7 network. The process begins by receiving a message that is to be sent over an IP connection (step 2400). A gateway header is created for the message (step 2402). This gateway header contains information such as that found in table 800 in FIG. 8. A destination on the IP network is identified for the message (step 2404). This destination is in the form of an IP address. With this IP address, a data packet header is created for the data packet (step 2406). Thereafter, the gateway header and message are placed into the payload of the data packet (step 2408) with the process terminating thereafter.

[0096] With reference now to FIG. 25, a flowchart of a process for extracting a message from a data packet is depicted in accordance with a preferred embodiment of the present invention. This process begins by receiving a data packet (step 2500). The gateway header and message are extracted from the payload portion of the data packet (step 2502). With the information from the gateway header, a SCCP address is formatted (step 2504) with the process terminating thereafter. At this point, the message may be routed to the appropriate node or application using the SCCP address. This message may be placed into existing SCCP interfaces in the SS7 network for routing.

[0097] It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

[0098] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. For example, although the depicted examples illustrate the use of TCP in handling the transport of messages over an IP link, other protocols also may be used, such as universal datagram protocol (UDP). UDP is a connectionless protocol within TCP/IP that corresponds to the transport layer in the ISO/OSI model. UDP converts data messages generated by an application into packets to be sent via IP but does not verify that messages have been delivered correctly. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.