Software architecture

This topic shows the functional components and information flows for the following SS7 configurations:

Although the illustrations show a dual node system, the components for a single node system are similar. TCAP and SCCP are also similar to this call processing example.

Software architecture for a TDM configuration

The following illustration shows the functional components and information flows in the software architecture model for an SS7 TDM configuration:

The following table describes each module and its information flows relating to high availability.

Module	Description
SS7 message transfer part (MTP)	SS7 MTP layers provide the physical signaling link termination, data link control, message routing, and network management functions for the signaling nodes. In a redundant configuration, active signaling links can be terminated on both boards. Both boards can be active up through MTP layer 2. All traffic received on either board is forwarded to the MTP 3 layer on the primary board for processing. All outgoing traffic is routed to the primary board by the application for delivery. The primary MTP 3 layer distributes outgoing traffic across all available links on both boards. Changes in the status of signaling links and routes are checkpointed by the primary MTP 3 layer to the backup MTP 3 layer so the backup is in the correct state in the event that it must become the primary. Refer to the Dialogic® NaturalAccess™ MTP 2 Layer Developer's Reference Manual and the Dialogic® NaturalAccess™ MTP 3 Layer Developer's Reference Manual for more information.
SS7 ISUP	The SS7 ISUP layer provides for the establishment, supervision, and clearing of all circuit-switched connections. In a redundant configuration, the primary board handles all live traffic. The backup ISUP layer remains in a state ready to assume control when needed. To preserve active calls in the case of a failure of the primary board, the call processing application can checkpoint updates of circuit states to the backup ISUP layer (through SS7 ISUP) as calls progress or as circuits become blocked and unblocked. SS7 ISUP includes a sample call processing application, isupdemo, which demonstrates the checkpointing of circuit states in various situations. For more information, refer to ISUP demonstration program overview. Refer to the Dialogic® NaturalAccess™ ISUP Layer Developer's Reference Manual for more information.
SS7 SCCP	SS7 SCCP provides services for routing non-circuit related traffic, including global title translations. In a redundant configuration, the primary node receives all live SCCP traffic. The backup SCCP takes over if there is a primary failure or switchover. The SCCP task checkpoints relevant routing information without any application involvement. Refer to the Dialogic® NaturalAccess™ SCCP Layer Developer's Reference Manual for more information.
SS7 TCAP	SS7 TCAP provides services for non-circuit related messaging, often destined for databases such as local number portability lookups. In a redundant configuration, the primary node receives all live TCAP traffic. The backup TCAP takes over if there is a primary failure or switchover. The TCAP task is configured to checkpoint some or all transactions. This is done automatically without any application responsibilities. SS7 TCAP includes a sample redundant application, tcapdemo, which demonstrates application behavior during transactions and switchovers. For more information on tcapdemo, refer to TCAP demonstration program overview. Refer to the Dialogic® NaturalAccess™ TCAP Layer Developer's Reference Manual for more information.
SS7 TUP	The SS7 TUP layer provides for the establishment, supervision, and clearing of all circuit-switched connections. In a redundant configuration, the primary board handles all live traffic. The backup TUP layer remains in a state ready to assume control when needed. To preserve active calls in the case of a failure of the primary board, the call processing application can checkpoint updates of circuit states to the backup TUP layer (through the standard TUP API) as calls progress or as circuits become blocked and unblocked. SS7 TUP includes a sample call processing application, tupdemo, which demonstrates the checkpointing of circuit states in various situations. For more information on tupdemo, refer to TUP demonstration program overview. Refer to the Dialogic® NaturalAccess™ TUP Layer Developer's Reference Manual for more information.
TX monitor (txmon)	The TX monitor (txmon) is a board-resident task that provides the health management functions on the TX boards. txmon functions include: Monitoring the status of all registered SS7 tasks on the board and reporting any failures to the health management interface on the host. Distributing and synchronizing the execution of board state requests (SET backup, SET primary, and so on) from the host. Reporting changes in the status (connected, isolated) of the inter-board communications link to both the registered board-resident tasks and the health management interface. Implementing the board side of the keep alive function that allows the health management interface to detect a board failure.
Health Management Interface (HMI) service	The Health Management Interface (HMI) is a host-based service (Windows) or daemon process (UNIX) that provides the actual execution of control functions requested by applications using the Health Management system. It supports multiple applications and distributes asynchronous board events to all registered applications. It also continuously monitors all configured boards to detect board failures.
Health Management service (HM API)	The Health Management service provides functions for applications to monitor and control the state of TX boards on their local machine. It provides functions to download a board, halt a board, retrieve the current state of a board, and set a board into primary or backup state. In addition, applications can register to receive asynchronous events indicating changes in the state of a board. These events include notifications that a board has failed, been downloaded or halted, set into the primary or backup states, or has become connected to or isolated from its mate board. The RMG demonstration program, included in the HMI distribution package, demonstrates the use of the Health Management service. The RMG demonstration program performs the role of the management application. For more information, refer to RMG demonstration program overview.

Software architecture for an IP configuration

The following illustration shows the functional components and information flows in the software architecture model for an SS7 IP configuration:

The following table describes each module and its information flows relating to high availability.

Module	Description
M3UA and SCTP	There are no checkpoint or data messages flowing between mate boards. Refer to the Dialogic® NaturalAccess™ SIGTRAN Stack Developer's Reference Manual for more information.
SS7 ISUP	The SS7 ISUP layer provides for the establishment, supervision, and clearing of all circuit-switched connections. In a redundant configuration, the primary board handles all live traffic. The backup ISUP layer remains in a state ready to assume control when needed. To preserve active calls in the case of a failure of the primary board, the call processing application can checkpoint updates of circuit states to the backup ISUP layer (through SS7 ISUP) as calls progress or as circuits become blocked and unblocked. SS7 ISUP includes a sample call processing application, isupdemo, which demonstrates the checkpointing of circuit states in various situations. For more information, refer to ISUP demonstration program overview. Refer to the Dialogic® NaturalAccess™ ISUP Layer Developer's Reference Manual for more information.
SS7 SCCP	SS7 SCCP provides services for routing non-circuit related traffic, including global title translations. In a redundant configuration, the primary node receives all live SCCP traffic. The backup SCCP takes over if there is a primary failure or switchover. The SCCP task checkpoints relevant routing information without any application involvement. Refer to the Dialogic® NaturalAccess™ SCCP Layer Developer's Reference Manual for more information.
SS7 TCAP	SS7 TCAP provides services for non-circuit related messaging, often destined for databases such as local number portability lookups. In a redundant configuration, the primary node receives all live TCAP traffic. The backup TCAP takes over if there is a primary failure or switchover. The TCAP task is configured to checkpoint some or all transactions. This is done automatically without any application responsibilities. SS7 TCAP includes a sample redundant application, tcapdemo, which demonstrates application behavior during transactions and switchovers. For more information on tcapdemo, refer to TCAP demonstration program overview. Refer to the Dialogic® NaturalAccess™ TCAP Layer Developer's Reference Manual for more information.
SS7 TUP	The SS7 TUP layer provides for the establishment, supervision, and clearing of all circuit-switched connections. In a redundant configuration, the primary board handles all live traffic. The backup TUP layer remains in a state ready to assume control when needed. To preserve active calls in the case of a failure of the primary board, the call processing application can checkpoint updates of circuit states to the backup TUP layer (through the standard TUP API) as calls progress or as circuits become blocked and unblocked. SS7 TUP includes a sample call processing application, tupdemo, which demonstrates the checkpointing of circuit states in various situations. For more information on tupdemo, refer to TUP demonstration program overview. Refer to the Dialogic® NaturalAccess™ TUP Layer Developer's Reference Manual for more information.
TX monitor (txmon)	The TX monitor (txmon) is a board-resident task that provides the health management functions on the TX boards. txmon functions include: Monitoring the status of all registered SS7 tasks on the board and reporting any failures to the health management interface on the host. Distributing and synchronizing the execution of board state requests (SET backup, SET primary, and so on) from the host. Reporting changes in the status (connected, isolated) of the inter-board communications link to both the registered board-resident tasks and the health management interface. Implementing the board side of the keep alive function that allows the health management interface to detect a board failure.
Health Management Interface (HMI) service	The Health Management Interface (HMI) is a host-based service (Windows) or daemon process (UNIX) that provides the actual execution of control functions requested by applications using the Health Management system. It supports multiple applications and distributes asynchronous board events to all registered applications. It also continuously monitors all configured boards to detect board failures.
Health Management service (HM API)	The Health Management service provides functions for applications to monitor and control the state of TX boards on their local machine. It provides functions to download a board, halt a board, retrieve the current state of a board, and set a board into primary or backup state. In addition, applications can register to receive asynchronous events indicating changes in the state of a board. These events include notifications that a board has failed, been downloaded or halted, set into the primary or backup states, or has become connected to or isolated from its mate board. The RMG demonstration program, included in the HMI distribution package, demonstrates the use of the Health Management service. The RMG demonstration program performs the role of the management application. For more information, refer to RMG demonstration program overview.