The signaling subsystem initialization phase involves:
Setting it into the appropriate state (either primary or backup)
Call hmiLoadBoard to initiate board download. Once a board download is initiated (including configuration), a HMI_EVN_LOADING event is sent to all applications registered with the HMI, including the application that initiated the download. Once the download is complete and the board is ready for operation, the application receives a HMI_EVN_STARTING event (or HMI_EVN_STANDALONE event, if the board is not operating in a redundant configuration).
The HMI cannot detect certain types of board download failures. Applications must time for the HMI_EVN_STARTING (or HMI_EVN_STANDALONE) event to detect a failed download. The duration of the timer could be anywhere from five seconds (for a normal sized configuration) to ten seconds or longer for a large configuration.
After download, each board is initially in the starting state, waiting for hmiPrimary or hmiBackup. In the starting state, protocol tasks can be configured and bind requests can be honored, but links are not enabled and data traffic is not accepted. During this time, txmon attempts to establish communication with its mate board.
The application determines which board should be primary and which should be backup. Once determined, the application issues a hmiPrimary [hmiBackup] command to each board, as appropriate, through the HMI. Once the command is accepted, an HMI_EVN_NOWPRIMARY [HMI_EVN_NOWBACKUP] event is sent to all applications registered with the HMI, including the application that initiated the request.
During this period each application also binds to its service provider layer through the appropriate function call. For example, call processing applications bind to the ISUP or TUP layer; direct MTP 3 applications bind to the MTP 3 layer. On a single node signaling subsystem, the application typically binds to its service provider on the primary board and the backup board. On a dual node signaling subsystem, the primary application binds to the primary board and the backup application binds to the backup board.
Upon a successful bind, the service user (application) is notified of the board status (primary or backup) through a status indication event. The service user must wait for the now primary status indication event before starting data traffic. This event precedes any incoming data traffic delivered to the service user and signals that normal data transfer can begin in either direction.