WO2005041520A1 - Method and apparatus for backhaul signaling in ip networks - Google Patents

Abstract

A method of handling a failure of a connection between a first application server process of a first network node and a network element included in a communications network determines if an application server process other than the first application server process has an active connection to the network element. If a second application server process indicates that it has an active connection, the method requests the second application server process to take over duties of the first application server process with respect to the network element. Upon confirmation of the requested take over and acknowledgement of the take over by the network element, the method handles communications for the first application server process through the second application server process.

Description

METHOD AND APPARATUS FOR BACKHAUL SIGNALING LN IP NETWORKS

Cross Reference to Related Applications The present application claims priority to provisional patent application serial number 60/513,317 filed on October 22, 2003, which is herein incorporated by reference.

Background of the Invention The embodiments described herein generally relate to communications networks and communications methods within these networks. More particularly, the embodiments relate to a system and a method for conveying telephone protocol messages over an IP network to a remote interface connected to a digital network. The Request for Comments RFC 2719 titled "Framework Architecture for Signaling Transport," October 1999, by the Network Working Group describes an architecture framework for transport of message-based signaling protocols over IP networks. The description of the architecture framework includes a description of the relationships between functional and physical entities used in signaling transport, including the framework for control of media gateways, and a description of the functional and performance requirements for signaling transport such as flow control and in-sequence delivery. A media gateway unit (MGU) includes the function of a media gateway (MG) that, among other functions, terminates media streams f om switched circuit networks (SCN) (e. g., public switched telephone networks (PSTNs) and public land mobile networks (PLMNs) that use Q.931, SS7 MTP Level 3 and SS7 Application User parts as signaling protocols), packetizes media data, and delivers packetized traffic to a packet network. A media gateway controller unit (MGCU) includes the function of a media gateway controller (MGC) that handles registration and management of resources at the media gateway. A signaling gateway unit (SGU) includes the function of a signaling agent that receives and sends SCN signaling at the boundary of the IP network. • RFC 3057 entitled "ISDN Q.921-User Adaptation Layer," February 2001, by the Network Working Group discloses that there is a need for a delivery of a switched circuit network signaling protocol from an ISDN signaling gateway (SG) to a media gateway controller (MGC) as described in the above RFC 2719. A signaling gateway supports the transport of Q.921-user (i.e., an upper layer) signaling traffic to one or more media gateway controllers. The RFC 3057 document discloses a protocol for backhauling ISDN Q.921-user messages over an IP network using a stream control transmission protocol (SCTP). That is, the signaling gateway terminates lower levels of an SCN protocol (e.g., Q.921) and backhauls the upper layer(s) (e.g., Q.931) to the media gateway controller for call processing. In addition to the elements and functions described above, networks according to RFC 2719 and RFC 3057 include interface identifiers and application servers. An interface identifier identifies the physical interface at the signaling gateway that sends or receives signaling messages. An application server (AS) is a logical entity serving a specific application instance, such as a media gateway controller handling the Q.931 and call processing for D channels terminated by the signaling gateways. Within the application server, application server processes (ASP) run, such as primary or backup media gateway controller instances. With respect to these application server processes, fail-over is the capability to re-route signaling traffic as required between related ASPs in the event of failure or unavailability of the currently used ASP (e.g., from primary MGC to back-up MGC).

Summary of Certain Inventive Aspects A general requirement of networks, such as IP network, is to sustain stable calls through fail-over events. Further, certain applications require a scalable solution to carrier density requirements ranging above 1000 ports. Prior art systems fail to fully address these requirements since they lack support for redundant systems and their IP interfaces, often need system reboots to recover from anomalous events, and are applicable only to low density systems. For example, a network according to RFC 3057 has tightly coupled dependencies. That is, the media gateway becomes dependent on another element, the media gateway controller, for fulfilling line card redundancy requirements of 1 : 1 and N: 1. This dependency makes it difficult to keep ongoing functional correctness, due to the expanded scope of software that has to work cooperatively for redundancy to function as designed. Further, a network according to RFC 3057 does not address the scalability issues. The Q.931 layer of the software must be executed outside of the media gateway, i.e., on the media gateway controller. This centralization comes at the cost of performance. The performance burden increases linearly with the number of line cards in each media gateway controlled by a media gateway controller. This could result in a 1 Ox performance burden beyond what would be found with distributed processing of Q.931 , for example, performed on line cards instead of media gateway controllers. It is therefore an objective to provide a system and method that provide for an improved behavior with respect to connection failure situations. Accordingly, the various inventive embodiments described herein enable a call processor to use an IP network to convey telephone protocol messages to a remote interface connected to an ISDN network. One application may be in converged voice and data networks where soft switches communicate to PSTN gateways. In one embodiment, ISDN telephone signaling is applied. Accordingly, one aspect involves a method of handling a failure of a connection between a first application server process of a first network node and a network element included in a communications network, wherein the communication network includes other network nodes and wherein each network node includes at least one application server process. The method determines if an application server process other than the first application server process has an active connection to the network element. If a second application server process indicates that it has an active connection, the method requests the second application server process to take over duties of the first application server process with respect to the network element. Upon confirmation of the requested take over and acknowledgement of the take over by the network element, the method handles communications for the first application server process through the second application server process. Another aspect involves a communications network having a network element and at least one network node including at least one application server process. The network node is coupled for communications with the first network element. A first application service process determines a connection failure to the first network element, and if an application server process other than the first application server process has an active connection to the network element. A second application server process indicates that it has an active connection and the first application service process requests the second application server process to take over duties of the first application server process with respect to the network element. The second application service process then handles communications for the first application server process. In addition to the foregoing, a series of messages, methods, and procedures are implemented that employ a mapping database that enables controllers and gateways to operate with multiple IP connections in support of distributed software processes. The series of implemented messages are for managing application server software processes, IP connection health status, IP connection updates and PRI registration (PRI: Primary Rate Interface in ISDN). Implemented methods re-synchronize a certain state when outages go beyond protocol timer limits, distribute ISDN-PRI processing across line cards thereby improving scalability to next-generation densities. The embodiments described herein detect a connection failure between a media gateway controller and a gateway, and dispatch messages over multiple IP connections in support of distributed software processes. Further, the embodiments maintain database integrity and stable calls through fail-over of redundant elements, and provide scalability of backhaul processing to carrier-class subscriber densities. In addition, the embodiments avoid creating dependencies on the media gateway controller for non facility associated signaling (NFAS) and D-channel backup features. With respect to a network according to RFC 3057, the embodiments do not add a performance burden to the media gateway controller because Q.931 is processed by line cards that are distributed in the media gateway. The embodiments are better scalable (for example, by an order of magnitude). Hence, at the low-end it is an enabler to lower cost media gateway controllers because performance requirements are less. At the high-end, it is an enabler to very high density deployments often found in carrier networks. Further, the embodiments have no dependencies on external equipment to fulfill line card redundancy as applied to ISDN call control. This includes D-channel backup, and NFAS features. Hence, line card redundancy features can be sustained and evolved without integrating with another box. This enables quicker product validation and rollout cycles.

Brief Description of the Several Views of the Drawings These and other aspects, advantages and novel features of the embodiments described herein will become apparent upon reading the following detailed description of certain inventive embodiments and upon reference to the accompanying drawings. In the drawings, same elements have the same reference numerals. Figure 1 shows a schematic illustration of one embodiment of a communication network, Figure 2 illustrates one embodiment of a media gateway in communication with a media gateway controller, Figure 3 is a first swim lane diagram illustrating a message flow occurring during a standard connection, Figure 4 is a second swim lane diagram illustrating a message flow occurring during failure of a connection, and Figure 5 is a third swim lane diagram illustrating a message flow occurring during recovery of a connection. Detailed Description of Certain Inventive Embodiments The following description and attached drawings describe certain inventive embodiments with reference to an exemplary use and application within a communication network. More particularly, the description and drawings describe in one embodiment a system and a method for conveying telephone protocol messages over an IP network to a remote interface connected to a digital network, such as ISDN. Such an exemplary use and application may be in relation to a voice-enabled data Next-Generation Network (NGN) that supports both existing voice services and evolving applications such as integrated access, Virtual Private Network (VPN), Internet call waiting, click to dial, unified messaging, enhanced roaming, or the like. Accordingly, Figure 1 shows a schematic illustration of one embodiment of a communication network 1. The network 1 includes an IP network 6, gateway units 2, 4 and ISDN networks 8, 10. The gateway unit 2 couples the ISDN network 8 to the IP Network 6, and the gateway unit 4 couples the ISDN network 10 to the IP network 6. In the illustrated embodiment, a terminal 12 is located at the premises of a subscriber B and coupled to the

ISDN network 8, and a terminal 14 is located at the premises of a subscriber A and coupled to the ISDN network 10. The terminals 2, 4, 5 maybe conventional telephones, wireless phones, computers, modems, fax machines, video phones, multimedia devices, or other voice and/or data communication devices. It is contemplated that the ISDN networks 8, 10 comprise switches and other network elements to route calls within the networks 8, 10 and to the IP network 6. Such switches are based on conventional switching technology that is known by those of ordinary skill in the art. Briefly, each switch has a plurality of input ports coupled to mcoming links and a plurality of output ports coupled to outgoing links. The input ports and the output ports are implemented on line cards that act as interfaces between the physical lines and the switch fabric. Incoming signals are in one embodiment first stored in input buffers to give the processor enough time to process the signals. For routing purposes, the processing includes obtaining and reading a signal's destination address. The processor fetches data relating to a from the input buffers, analyzes the destination addresses, and forwards the signals to the appropriate output buffers. Further, it is contemplated that the IP network 6 comprises network elements such as soft switches. Figure 2, schematically illustrates one embodiment of a gateway unit 2, 4 comprising a media gate way controller 22 and a signaling gateway 20 configured for communications with the media gateway controller 22. The various inventive embodiments described herein are based on a client/server communication architecture where the signaling gateway 20 is the server, and the media gateway controller 22 is the client. In one embodiment, the media gateway controller 22 is configured for ISDN traffic and includes in the illustrated embodiment two nodes providing high availability of the communications network 1. It is contemplated that in other embodiments, the media gateway controller 22 may have one or more than two nodes. Each node contains in one embodiment two software processes A and B or C and D, that are capable of handling ISDN traffic. Each of these software processes A, B, C, D is called an application server process (ASP). Each of these processes A, B, C, D maintains two connections to the signaling gateway 20. The first connection is to a first dedicated port for a "heartbeat" traffic. In one embodiment, the first dedicated port is a port known as port 9898. The first connection is therefore for a heartbeat connection that carries defined messages, e.g., BACKHAUL_TCP_HEARTBEAT messages. These messages allow the application server process to monitor their connections at high frequency to ensure uninterrupted operation. The second connection is to a second dedicated port that carries the rest of the ISDN backhaul traffic. In one embodiment, the second dedicated port is a port known as port 9899. Each application server process on the media gateway controller 22 independently establishes its connections to all available signaling gateways. The presence of each application server process is monitored by all other application server processes to ensure uninterrupted traffic. If one of the application server processes fails or is taken out of service, other application service processes get notified and take over the duty of the "disappearing" application server process. If one of the application server processes loses communication to one of its signaling gateways 20 that application server process requests the help of other application server processes available in the system to take over its duties provided any other application server process on the system still has communication capabilities to the signaling gateway 20. All application server processes undertake best efforts to communicate to their signaling gateways 20. If a fail over of a connection occurs from one application server process to another, the application server process that loses communication will try to re- establish that connection immediately after the other application server process takes over its duties. All application server processes on the system act as active processes. In addition, each application server process acts as a backup process to another application server process. If one application server process fails, the backing-up application server process takes over the failing application server process's duties for all the signaling gateways 20 the failing application server process communicates to. The application server processes operate according to a communications protocol between themselves to achieve continuous communication to their signaling gateways 20. In one embodiment, this protocol includes the following messages: ASP_ConnectionLoss: This message gets broadcasted to all available application server processs on the Media Gateway Controller, indicating that an application server process has lost communication to a particular Signaling Gateway. This message is sent from the application server process that loses the communication. ASP ConnectionHealthy: This message is the response to ASP_Connection_Loss message. It gets sent by all application server processs that has communication to the indicated Signaling Manager in the received ASP_Connection_Lόss message. ASPjConnectionTakeover: ASPjConnectionTakeover message asks a particular application server process to take over the duties of another application server process that no longer has a healthy communication to a given Signaling Gateway. This message gets sent to the application server process of the first responder to the ASP_ConnectionLoss message, which responds by the ASP_ConnectionHealthy message. ASP OutOfService: Each application server process on the system is backed by another application server process. This message is sent by the system to a backup application server process, if its backed up pair fails. Upon receipt of this message, the application server process will takeover the duties of the failing application server process for all of its Signaling Gateways. Figure 3 is a first swim lane diagram illustrating a message flow occurring during a standard connection. Swim lane diagrams may show the relationship and typical messaging sequencing among "actors" or "components". The components of the swim lane diagram include an originating end equipment (e.g., media gateway controller 22 including the application server processes) and a corresponding terminating end equipment (e.g., the signaling gateway 20). In the embodiment illustrated in Figure 3, a node includes two application server processes ASPl, ASP2 that happen to come into service at the same time. Note that this may not happen in all situations since ASPl and ASP2 are separate entities, and none of the requests or responses are dependent between ASPl and ASP2. That is, if in Figure 3 ASP2 is taken out the messaging of ASPl remains the same. Likewise, if in Figure 3 an ASP3 is added the messaging of ASPl and ASP2 does not change and the ASP3 messaging is in one embodiment similar to the ASPl and ASP2 messaging. Referring to a step SI, the ASPl and ASP2 clients attempt to establish a TCP communication to the signaling gateway 20. In a step S2, both connections are accepted by the signaling gateway 20. In a step S3, the ASPl and ASP2 send BACKHAUL_ASP„CONNECTION_UPDATE messages to associate their logical presence to the TCP connection. In a step S4, the signaling gateway 20 associates each application server process ASPl, ASP2 to their corresponding connection and acknowledge their requests through B ACKHAUL_ASP_CONNECTION_UPDATE_ACK messages. In a step S5, the ASPl and ASP2 declare themselves as being in the UP state through BACKHAUL_ASP_UP messages. In a step S6, the signaling gateway 20 sets the ASPl and ASP2 states as UP and acknowledges the BACKHAUL_ASP_UP messages through BACKHAUL_ASP_UP_ACK messages. At this stage, the signaling gateway 20 is ready for PRI (primary rate interface) registration for each application server process ASP 1 , ASP2. In a step S7, the ASPl and ASP2 send their first batches of PRI associations to the signaling gateway 20 through BACKHAUL_ASP_PRI_REGISTER messages. In a step S8, the signaling gateway 20 associates the PRI objects to the ASPs by processing the BACKHAUL_ASP_PRI_REGISTER requests from ASPl an ASP2. The signaling gateway 20 acknowledges the requests by sending BACKHAUL_ASP_PRI_REGISTER_ACK messages. In a step S9, the ASPl and ASP2 continue to register the remaining PRI objects by repeating the BACKHAUL_ASP_PRI_REGISTER procedure. The registration process may repeat as many times as needed, until all PRIs are registered to the corresponding application server processes on the signaling gateway 20. In a step S 10, the signaling gateway 20 processes every BACKHAUL_ASP_PRI_REGISTER message and acknowledges each one of these messages by sending BACKHAUL_ASP_PRI_REGISTER_ACK messages. In a step SI 1, the ASPl and ASP2 complete their PRI registrations and declare themselves as active through sending BACKHAUL_ASP_ACTIVE messages. In a step S12, upon receipt of the BACKHAUL_ASP_ACT1VE messages, the signaling gateway 20 marks the application server processes as ACTIVE states and sends BACKHAUL_ASP_ACTrvΕ_ACK messages. Referring to a step S12, since both application service processes ASPl, ASP2 declared themselves as ACTIVE, bi-directional ISDN traffic begins between the ASPl and the signaling gateway 20 and the ASP2 and the signaling gateway 20. Figure 4 is a second swim lane diagram illustrating a message flow occurring during failure of a connection. As mentioned with reference to Figure 3, the illustrated embodiment includes two application server processes ASPl and ASP2. For illustrative purposes, it is assumed that the ASPl loses the connection to the signaling gateway 20 and fails-over its communications to the ASP2. Referring to a step SI, heartbeat messaging takes place. That is, the application server processes ASP 1 , ASP2 send BACKHAUL_TCP_HEARTBEAT messages to the signaling gateway 20. In a step S2, the signaling gateway 20 acknowledges each heartbeat request by sending BACKHAUL_TCP_HEARTBEAT_ACK messages back to the application server processes ASPl, ASP2. Referring to a step S3, the ASPl does not receive the last B ACKHAUL_TCP_HEARTBEAT_ACK message. The failure to receive that message indicates a communication failure. The ASPl sends an ASP_ConnectionLoss (ASP1,SG_1) message to all other application server processes in the system to find out if any other application server process has a connection active to the signaling gateway 20. In a step S4, the ASP2 receives the ASP_Connection_Loss message from the ASPl and immediately pings the signaling gateway 20 by sending a BACKHAUL_TCP_PING (ASP2) message to independently test its connection to the signaling gateway 20. In a step S5, the signaling gateway 20 acknowledges the BACKHAUL_TCPJPING message indicating that the connection from the ASP2 to the signaling gateway 20 is still working ("healthy"). The ASP2 sends an ASP_ConnectionHealthy message to the ASPl . In a step S6, on receipt of the ASP_ConnectionHealthy message from the ASP2, the

ASPl asks the ASP2 to take over its duties relating to the signaling gateway 20. The ASPl sends a ASP_ConnectionTakeover message to the ASP2. In a step S7, the ASP2 sends a BACKHAUL_ASP_CONNECTION_UPDATE message to the signaling gateway 20 to associate its own communications channel for the ASP 1 as well. From this point on, the ASP2 acts as the ASP2 and the ASP 1. In a step S8, the signaling gateway 20 acknowledges the connection update by sending a BACKHAUL_ASP_CONNECTION_UPDATE_ACK to the ASP2 and starts diverting all ISDN traffic for the ASPl via the ASP2 connection. In a step S9, the ASP2 sends a Connection_Takeover_Complete message to the ASPl indicating that the ASP2 is now handling all traffic for the ASPl . In a step S10, the ASPl starts trying to recover its own communication to the signaling gateway 20 by sending a TCP_CONNECT message to the signaling gateway 20. The TCP_CONNECT messaging is as described with reference to Figure 3. Referring to a step SI 2, until the ASPl has recovered its own connection to the signaling gateway 20, all ISDN traffic goes through the ASP2 without any call interruption. Figure 5 is a third swim lane diagram illustrating a message flow occurring during recovery of a connection. As mentioned with reference to Figures 3 and 4, the illustrated embodiment includes two application server processes ASPl and ASP2. For illustrative purposes, it is assumed that the ASPl lost its connection to the signaling gateway 20 and that the ASP2 is handling the communication for the ASPl as well. The ASPl continues to recover its connection and finally is able to succeed. Referring to a step SI, the ISDN traffic for both the ASPl and the ASP2 goes through the ASP2 because the ASP 1 lost its connection to the signaling gateway 20. The ISDN traffic is indicated in Figure 5 through ISDN TRAFFIC messages. Referring to a step S2, the ASPl continues trying to establish a connection to the signaling gateway 20. Figure 5 shows for illustrative purposes three attempts by the ASPl through sending TCP_CONNECT messages, as described with reference to Figure 3. In a step S3, the communication path clears and the signaling gateway 20 receives a

TCPjCONNECT message, i.e., the connection request from the ASPl . The signaling gateway 20 accepts the connection request and sends the TCP_ACCEPT message. In a step S4, the ASPl broadcasts an ASPjConnectionTakeoverComplete message to all other application server processes in the system to informing that it is taking over the duties of the ASPl through its own connection. The ASP2 receives this message and stops sending messages to the signaling gateway 20 on behalf of the ASPl . In a step S5, the ASPl is at this point free to send messages to the signaling gateway 20. The signaling gateway, however, still sends messages to the ASP2. To get the signaling gateway 20 to send messages to the ASPl again, the ASPl sends a BACKHAUL_ASP_CONNECTION_UPDATE message to the signaling gateway 20. In a step S6, the signaling gateway 20 acknowledges the request by sending a BACKHAUL_ASP_CONNECTION_UPDATE_ACK message to the ASP 1. The BACKHAUL_ASP_CONNECTION_UPDATE_ACK message contains information relating to ASP's current state, as known by the signaling gateway 20. Further, it contains the number of PRI elements registered by the ASP. This allows the ASPl to recover its current state known by the signaling gateway 20 so that it can take proper action to recover its connection. If the signaling gateway 20 indicates that the state of the ASPl is DOWN, the ASPl sends a BACKHAUL_ASP_UP message to the signaling gateway 20 and start registering its PRIs. If the signaling gateway 20 indicates that the state of the ASPl is ACTIVE, the ASPl checks how many PRIs are already registered with the signaling gateway 20. If there is a mismatch of the registered PRIs compared to the actual PRIs assigned for the ASPl, the ASPl restarts its PRI registration. From step S6 on, the signaling gateway 20 starts sending ASPl -related ISDN traffic to the ASPl's connection. As such, in a step S7, bi-directional ISDN traffic relating to the ASPl flows again through the ASPl's connection. The ASP2's own traffic is not affected and still flows through its own connection. It is apparent that there has been disclosed an apparatus and method that fully satisfy the objects, means, and advantages set forth hereinbefore. While specific embodiments of the apparatus and method have been described, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description.

Claims

We claim:

1. A method of handling a failure of a connection between a first application server process (ASPl) of a network node (22) and a network element (20) comprised in a communications network (1 ), wherein the communication network (1 ) includes other network nodes and wherein each network node (22) includes at least one application server process, the method comprising: determining if an application server process other than the first application server process (ASPl) has an active connection to the network element (20); if a second application server process (ASP2) indicates that it has an active connection, requesting the second application server process (ASP2) to take over duties of the first application server process (ASPl) with respect to the network element (20); and upon confirmation of the requested take over and acknowledgement of the take over by the network element (20), handling communications for the first application server process (ASPl) through the second application server process (ASP2).

2. The method of Claim 1, further comprising sending connection requests from the first application server process (ASPl) to the network element (20) to try to recover the failed connection.

3. The method of Claim 2, further comprising upon receiving a connection request from the first application server process (ASPl) by the network element (20), acknowledging the receipt to the first application server process (ASP 1).

4. The method of Claim 3, further comprising notifying the other application service processes (ASP2) that the first application service process (ASPl) is available to take over its duties with respect to the network element (20).

5. The method of Claim 4, further comprising terminating communications from the second application service process (ASP2) to the network element (20) on behalf of the first application service process (ASPl).

6. The method of Claim 4, further comprising notifying the network element (20) that the first application service process (ASPl) is available to take over its duties in order to cause the network element (20) to communicate with the first application server process (ASPl).

7. A communication network (1) comprising: a network element (20); and at least one network node (22) comprising at least one application server process (ASPl, ASP2), the network node (22) coupled for communications with the first network element (20), wherein a first application service process (ASP 1 ) determines a connection failure to the first network element (20), and if an application server process other than the first application server process (ASPl) has an active connection to the network element (20), wherein a second application server process (ASP2) indicates that it has an active connection and the first application service process (ASPl) requests the second application server process (ASP2) to take over duties of the first application server process (ASPl) with respect to the network element (20), and wherein the second application service process (ASP2) handles communications for the first application server process (ASPl).