This topic explains how the hardware and software is configured and managed. It includes information about:
In general, each signaling board is loaded and configured independently. Each configuration utility and function call sends configuration packets to the target board. Configuration requests are not explicitly exchanged between boards. Each node in a multiple node signaling subsystem must have its own copy of each SS7 configuration file or database or be able to access a common file or database through networking. Similarly, each dynamic configuration function call must be executed on both boards.
The configurations downloaded to the SS7 layers are identical on both boards in a pair. To support configuration changes without a service outage, it is sometimes necessary to download a backup board with a new configuration, make it the primary board, and then reload the other board with the new configuration. In this case, the configurations on the two boards are out of synchronization for some time period. This is allowed during the checkpointing of state information between boards.
Control, status, and statistics requests are applied individually to each board in a mated pair. Control requests (enable or disable signaling links, block or unblock voice circuits, and so on) can only be issued to the primary board. Control requests issued to the backup board are rejected with an invalid state indication.
Status type requests can be issued to either the primary or the backup board. The results returned by a board reflect the status of the entity as currently viewed by that board. Thus, status requests issued to the backup board can be used to determine if an event, such as a call being answered, was checkpointed correctly to the backup.
Statistics requests can also be issued to either the primary or backup board. The statistics returned reflect events that occurred on that board only; no attempt is made to collate statistics between the primary and backup boards.
Each board generates its own alarms. In a dual node signaling subsystem, the MTP 2 alarms associated with a particular link appear on the node that the link terminates on, not necessarily the active node. MTP 3, SCTP, M3UA, SCCP, TCAP, TUP, and ISUP alarms relating to operational events typically appear only on the active node.
The txmon task on each board generates alarms relating to the state of that board:
Transitions between primary and backup mode
Failures of tasks on the board
Changes in the status of the inter-board link