Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-10-22
2003-09-30
Baderman, Scott (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S004110
Reexamination Certificate
active
06629263
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to signaling systems in telecommunications and more particularly to network elements for a Common Channel Signaling system having fault tolerance capability.
BACKGROUND OF THE DESCRIPTION
The need for more and more services leads to the reorganization of telecommunication networks with a separation between the voice transmission functions and the signaling functions. In modern networks, based around the concept of Common-Channel Signaling (CCS), the information that is transported between the different exchanges forming parts of the networks, is conveyed on a dedicated separated signaling channel that is different from that used for the speech path. This separation occurs both within the Exchanges in the telecommunication networks and external to the Exchanges, thus allowing optimization of the control processes, the switch blocks and the signaling systems. CCS systems form a major part in the drive towards all-digital networks. Networks which offer end-to-end digital communications between customers are termed ‘Integrated Services Digital Networks’ (ISDN).
SS7 is now the reference in the definition of common channel signaling systems. General background information relevant to the systems and protocols which are involved in CCITT No 7, and more generally with CCS, be found in document ‘Common-channel signaling’ by R. Manterfield, Institution of Electrical Engineers, Telecommunications series 26, 1991. An example of implementation of a CCITT No 7 signaling network is found in the article ‘
The HP OpenCall SS
7
Platform
’ by Denis Pierrot et al, Hewlett Packard Journal, August 1997, p. 58-64.
The modern trend is to provide ISDNs and the ISDN User Part (ISUP) protocol is designed primarily to control the set-up and release of calls in such networks. Because of the flexible nature of the ISDNs, the supplementary services defined within the ISUP are more comprehensive, and use more advanced techniques than those that were originally designed for the analog telephone networks. The ISUP defines the messages and procedures for the control of switched services in ISDNs, whereby a communication is allowed between a local application and a remote network element. The ISUP covers both voice (e.g. telephony) and non-voice (e.g. circuit-switched data) applications. As telecommunication networks evolves towards ISDN, the ISUP will obviate the need for the previous Telephone User Part (TUP) and Data User Part (DUP).
Other protocols can be used for achieving high value services in signaling systems involving communication between an application located in a local network element and a remote network element. Such protocols may include Transaction Capabilities Application Part (TCAP) for controlling non-circuit-related information transfer between two or more signaling nodes in a signaling network, and Q931 for the establishing, maintaining, and clearing of network connections at the ISDN user-network interface.
As with other essential parts of the telecommunication networks, there is a need for reliability and security of the signaling systems in general and the protocol stack in particular. The protocol stack—whatever it is ISUP, TCAP or Q.931 must be robust and must allow an effective way of ensuring high reliability. Hence, when an ISUP connection is established, for instance, it is crucial to protect it until its processing completes.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a fault tolerant network element for a Common Channel Signaling system allowing a robust implementation of a telecommunication protocol stack responsible for the management of structured message exchanges (hereinafter referred to as dialogs) between the local application and remote network elements, such as an ISUP protocol stack, a Q.931 protocol stack or a TCAP protocol stack, and which allows the node to continue the on-going dialogs established between a local application and a remote network element despite the failure of one component in the local node.
This and other objects are achieved by the process and apparatus which are defined in the claims.
Basically the fault tolerant network element of the invention comprises two similar peer systems which are organized in a fault tolerant configuration, with a former operating as an active system and the latter standing in a standby configuration. Each peer system has a local application which runs therein and which has an access to a common highly available database that is used for storing application information. Further, each peer system includes a protocol stack, such as ISUP, Q.931 or TCAP for handling dialogs between the local application and remote network elements.
In accordance with the present invention the protocol stack is enhanced by two additional functions: a first Get_dialog_state( ) available for the local application to request the protocol stack to provide the current state of a given dialog; a Set_dialog_state( ) which is issued by the application to update the state of a given dialog in the protocol stack. The first function is used, at appropriate instants which are defined by the application, to regularly retrieve, for any dialog, the state of its associated protocol stack state machine. This allows the application to store the latter into the common database, together with its own critical information. An automatic failure detection mechanism is used in each peer system for detecting the occurrence of a failure and, in response to this detection, the application running in the backup peer system, which has access to the common database, can retrieve all the states of all on-going dialogs and, further, for each dialog, can issue a Set_dialog_state( ) to the local associated protocol stack so that the latter can be updated and can resume the dialog with the remote network element until its completion.
This arrangement results in substantial advantages. Firstly it is the application which decides at which instant the replication should occur, i.e. at which instants the Get_dialog_state( ) should be issued. The application keeps overall control of the replication operation. This allows the application to store in the database, for any on-going dialog, the protocol stack state and the related application data. This provides a consistent view to the peer application in the case of a failure. The application may decide that the Get_dialog_state( ) is used at some particular critical instants of the dialog, e.g. when the dialog is established and when the dialog is terminated. This avoids to increase the complexity of the protocol stack being considered, either ISUP, Q.931 or TCAP, and further permits the latter to be used in combination with a large variety of applications, where each application can choose a different policy for replicating the dialog states. In the invention, the application performs all database accesses and the protocol stack has no direct connection to the database.
Preferably, the database is an in-memory highly available database allowing rapid access by the application running in the respective active and backup system.
REFERENCES:
patent: 6058424 (2000-05-01), Dixon et al.
patent: 6134673 (2000-10-01), Chrabaszcz
patent: 6205449 (2001-03-01), Rastogi et al.
patent: 6247141 (2001-06-01), Holmberg
http://www.cisco.com/univercd/cc/td/doc/product/tel_pswt/vco_prod/ss7_fund/ss7fun03.pdf.*
http://www.protocols.com/pbook/tcpip.htm.
Baderman Scott
Hewlett--Packard Company
Lohn Joshua
LandOfFree
Fault tolerant network element for a common channel... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Fault tolerant network element for a common channel..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Fault tolerant network element for a common channel... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3042375