Intel SIU520 SS7 Transferring the Circuit Group, Re-synchronization of Circuit State Information

Application Note Building Fault-tolerant SS7 Systems Using the Intel® NetStructure™ SIU520 SS7 Signaling Gateway

conc_id on the host (conc_id is set when the RSI link was started, optionally by rsicmd). This message will only be received by the application if the RSI link is con- figured with the conc_id set to the application’s module ID.

At the same time, the affected SIU (if it can), will issue an API_MSG_SIU_STATUS message with status value 30 (decimal) indicating a host link failure on the specified host ID. This message is sent to the host configured to receive management messages (host 0 by default).

There are two failure modes that can cause loss of communication:

■Complete failure of one SIU in a dual-resilient pair

■Partial TCP/IP failure causing loss of communication between the host and one SIU of the pair via the TCP/IP LAN

From the application’s point of view, there is no difference in these cases since the RSI link fails in either case. From a system point of view, the main difference is that in the second case, the inter-SIU communication may still be functioning.

If the affected SIU loses communication with all of its hosts, it automatically deactivates all SS7 signaling links, preventing any messages from being processed by any remaining active circuit groups.

Transferring the Circuit Group

If any of the circuit groups terminating on the host are currently active on the affected SIU, the host application must transfer control of each affected circuit group from the failed SIU (the primary SIU) to the remaining SIU (the secondary SIU). Transferring a circuit group normally involves deactivating the group on the controlling SIU then reactivating it on the other. However, since the host is unable to communicate with the failed SIU, the application is only required to send an API_MSG_COMMAND message to the secondary SIU with cmd_type of 8 (activate circuit group) for each affected group.

The activate circuit group command should be issued with a request for a response and the application should not send any call processing or circuit management commands until the response (acknowledgement) has been received from the secondary SIU.

The SIU processes single commands in sequence;

therefore, if an activate command is received while a previous command is executing, the response will be received with a non-zero status (in this case, a value

of 4 indicating “equipment busy”). The application should reattempt the activate command on receipt of a response indicating “busy”.

Since the failure may affect SIUA and SIUB, the host may choose to wait for a period of time following notification of the failure to determine if communication with the other unit remains stable. The circuit groups may then be transferred after this timeout if the communication to the secondary unit remains active.

Re-synchronization of Circuit State Information

Once the circuit group activation(s) are acknowledged from the secondary SIU, the application needs to resynchronize the circuit state information based on the application’s knowledge of the current circuit state. This is achieved by sending three CGSC requests to the secondary SIU.

Circuits that were in a call set-up state or idle (i.e., any circuit that was not in the steady state “speech” or “answered” state) should be RESET. Circuits that were in the speech stage of an incoming call should be forced to INCOMING ACTIVE; circuits that were in the speech state of an outgoing call should be forced to OUTGOING ACTIVE. The forcing of the circuit state to either INCOMING ACTIVE or OUTOING ACTIVE is achieved using the CGSC Request API message, with ptype set to 14 (decimal) for INCOMING ACTIVE and 15 (decimal) for OUTGOING ACTIVE.

Calls that were in outgoing set-up prior to the transfer should be re-attempted following successful completion of the transfer. The application should be able to re-attempt a failed outgoing call attempt, as this may occur under normal operating conditions. The originating switch will automatically reattempt calls that were in incoming set-up. When these commands are acknowledged, the application may resume normal

call activity.

Note: The TUP protocol does not currently support forcing of circuit states to INCOMING ACTIVE or OUTGOING ACTIVE, this step should therefore be omitted. No additional signaling should be exchanged for TUP calls that were in the answered state following the transfer. In this case, OUTGOING ACTIVE calls should be released (at the appropriate time) with a circuit reset.

22