(Page 1 of 1 in this chapter) Version

Chapter 5

Developing Redundant Applications

5.1 Introduction

5.2 SS7 ISUP

: 5.2.1 Checkpointing Strategies for ISUP Applications
: 5.2.2 Checkpoint Information
: 5.2.3 Other Application Issues

5.3 SS7 TCAP

: 5.3.1 TCAP Redundancy Support
: 5.3.2 Handling TCAP Traffic
: 5.3.3 Redundancy Indications
: 5.3.4 Application Operations

5.1 Introduction

The following sections provide detailed instructions for developing redundant applications for the SS7 ISUP and TCAP layers.

5.2 SS7 ISUP

5.2.1 Checkpointing Strategies for ISUP Applications

In order to preserve stable calls across outages, it is necessary for the primary application to checkpoint circuit and hardware state information to the backup application. The backup application in turn checkpoints the received circuit state information to the ISUP stack on the backup board.
This chapter discusses some of the issues and strategies in maintaining consistent and accurate circuit state information across primary and backup applications and ISUP stacks.

5.2.2 Checkpoint Information

The following sections describe the checkpointing process. Basic information
The backup application is responsible for checkpointing circuit state information to the ISUP implementation running on the backup board. This information consists of the call processing state and circuit blocking state. This is the minimum information to be checkpointed from the primary application to backup application.
Upon receipt of checkpoint information, the backup application must checkpoint the circuit state information (call processing and circuit blocking states) to the ISUP stack on the backup board. This is accomplished through a call to ISUPStatusReq with an evntType of GRPSETREQ.
Transient State
Optionally, the primary application can checkpoint the transient state of circuit. A circuit is in a transient state during call setup and release. Checkpointing the transient state of a circuit allows the backup application to identify those circuits that were in the call setup or release states at the time of CHANGEOVER. This information is not checkpointed to the ISUP stack. Note: After CHANGEOVER, the backup (now primary) application should reset all circuits marked as transient. Incremental Checkpointing
Incremental checkpointing refers to the transmission of state information for a single circuit concurrent with a change in state for the referenced circuit.
This is the recommended checkpoint method for the following reasons: Backup application always has up to date information concerning all circuits Transient circuit checkpointing is reasonable due to timely update of information Minimum number of circuit resets upon CHANGEOVER Acceptable for all size configurations Batch Checkpointing
Batch checkpointing refers to the en mass transmission, from primary application to backup application, of state information for controlled circuits and hardware.
Periodic batch checkpointing refers to the periodic transmission of state information for all controlled circuits and hardware.
Periodic delta batch checkpointing refers to the periodic transmission of state information for controlled circuits and hardware that have changed state since the previous checkpoint. This is more efficient than normal periodic batch checkpointing.
The use of batch checkpointing is discouraged for several reasons: Large window of uncertainty, circuit activity between checkpoints is not visible to backup Depending on the time between checkpoints, transient circuit checkpointing may not be effective After CHANGEOVER, transient circuits are unusable until protocol recovery or all idle circuits reset by new primary

5.2.3 Other Application Issues

The following sections deal with other application issues, such as application startups, board failures, and CHANGEOVER. Application Startup
At startup, both the backup and primary applications must open the ISUP service via a call to ctaOpenServices (see Figure 5). Both applications must also bind to ISUP, either through an explicit call to ISUPBindReq, or automatically through the ctaOpenServices call. See the SS7 ISDN User Part Developer's Manual for more information.

Figure 5. Primary Application Startup

Note: Circuits are defaulted to flow-controlled state. Until an MTPRESUME indication is received indicating that circuits are available, requests referencing these circuits will return an error indication with cause 27: no route to destination.
Upon startup, the backup application should receive a batch checkpoint from the primary application (see Figure 6). The backup application should in turn checkpoint this information to the ISUP stack running on the backup board. Figure 6. Backup Application Startup Board Failure, Halt, or Load
Applications should close the ISUP service via a call to ctaCloseServices upon notification of board failure, halt, or load (see Figure 7).

Figure 7. Board Failure, Halt, or Load

Backup Reload
Upon notification that the backup board has been reloaded and set to backup, the backup application should reopen the ISUP service and checkpoint the state of all circuits to the ISUP stack running on the backup board (see Figure 8). Figure 8. Backup Reload Switchover
At switchover, the backup application (now primary) should reset all transient circuits if checkpointing of transient state has been implemented (see Figure 9). If transient state has not been maintained, the new primary application can do one of the following: Reset all idle circuits Allow the ISUP protocol to recover transient circuits. This could take considerable time, depending upon what state the circuit was in at time of switchover. Any attempt at using one of these circuits before the protocol has returned the circuit to idle state will result in an error being returned from ISUP. Figure 9. Switchover

5.3 SS7 TCAP

5.3.1 TCAP Redundancy Support

Two TX boards may be configured as a redundant pair. In this configuration, one board is designated "Primary", and the other is designated "Backup". The TCAP task on the Backup board is ready to take over the TCAP service in the event that the Primary board fails or is taken out of service.
To enable the Backup TCAP task to take over the TCAP service, the Primary and Backup TX boards are connected by a private Ethernet connection. The Primary TCAP task sends transaction information to the Backup TCAP task, and this process is known as transaction checkpointing. If the Primary board fails, or is taken out of service, the Backup TCAP task has a complete list of open TCAP transactions so that it may properly handle TCAP traffic.
A TCAP application may control transaction checkpointing by configuring default checkpoint behavior, or by specifying checkpoint behavior for each transaction (see the SS7 TCAP Developer's Manual).
The TCAP user application must also monitor several new indications that inform the application of the underlying board's state. These indications allow a user application to correctly handle board failures, planned outages, etc.

5.3.2 Handling TCAP Traffic

In a redundant system, the TCAP application should perform a ctaOpenServices call on both the Primary and Backup Boards. TCAP traffic can only be sent and received on the Primary board. By monitoring the Run State indications from the TCAP service, the TCAP application can always determine over which board to send TCAP traffic.

5.3.3 Redundancy Indications

For TCAP user applications, several new indications have been added to support TCAP redundancy. Some of these indications are generated by the TCAP task, and are sent to TCAP user applications. The other set of redundancy indications are generated by the Health Management (HM) service.
A TCAP user application should open the TCAP service, as well as the HM service. TCAP Task indications
Once a TCAP application has opened the TCAP service, it receives a Run State indication, either Primary, Backup, or Standalone, from the TCAP task. If the board state changes (i.e. from Backup to Primary), another Run State indication is sent to the application from the TCAP task.
A fourth Run State indication, Backup Ready, is only sent by the backup TCAP task after it has reconnected to the Primary board, or been reloaded. This indication signifies the backup task has a complete copy of the Primary TCAP task's open transactions. Health Management Indications
The Health Management service provides many indications that are useful for monitoring board status.
The following HM run state indications should generally be ignored. A TCAP application should wait for the Run State indication from the TCAP task before modifying its behavior. However, the HM run state indication may be useful as a signal to open the TCAP service after a board loads. Now Primary Now Backup Now Standalone
The user application will close the TCAP service if any of the following HM indications are received. The STOP indication is only be received when a Compact PCI board is removed from its chassis. Board Dead Board Halted Board Loading Task Dead Stop
These following indications monitor the state of the Primary TX board to Backup TX board private Ethernet link. If an Isolated indication is received, the checkpointing of active transactions is not occurring. Connected Isolated Note: The indications listed above are not a complete list of the available HM indications, but only those applicable to TCAP applications.

5.3.4 Application Operations

This section describes the various scenarios where indications occur, and the appropriate user application action for these indications. Board Load
After loading a board, and upon receiving a HM Run State indication (Primary, Backup, or Standalone), a TCAP application may open the TCAP service. Once the TCAP service has been successfully opened, a Run State indication from the TCAP task is received. At this point, TCAP traffic may begin on the Primary (or Standalone) board. Figure 10. Board Load Board Failure
There are several indications where a TCAP application should close the TCAP service. These indications include: Board Dead, Board Loading, Board Halted, Task Dead, and Stop. In any of these cases, the TCAP application should close the TCAP service, and begin the process of reloading the board.
The TCAP application should only close the TCAP service once to a TX board. This can be performed when a failure occurs, or when the board is reloaded. Figure 11. Board Failure Switchover
The Primary board and Backup board may be switched in response to a user application request. This is known as a switchover.
When the Primary Run State indication is received from the TCAP task, the TCAP application then sends all traffic to the new Primary board. The HM Primary indication should be ignored in this case. Figure 12. Switchover Backup Reload
When a failed board is reloaded, the TCAP application should close the TCAP service on that board, if it hasn't been closed already when the failure occurred.
When the HM Backup indication is received, the TCAP application may reopen the TCAP service to the board. A Backup Run State indication is received from the TCAP service after the Open Service has completed.
When the Backup board is reloaded, it no longer contains a valid set of open transactions. After the backup board is reloaded, it requests an update of the open transactions from the Primary board. When this process is complete, a Backup Ready Run State indication is sent to the TCAP application. Figure 13. Backup Reload Backup Isolation
If the backup board becomes isolated from the Primary board, it no longer contains a valid set of open transactions. After the backup board is reconnected, it requests an update of the open transactions from the Primary board. When this process is complete, a Backup Ready Run State indication is sent to the TCAP application. Figure 14. Backup Isolation

(Page 1 of 1 in this chapter) Version

tech_support@nmss.com