Filter
Top Products
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.
Application Note Building Fault-tolerant SS7 Systems Using the Intel
®
NetStructure™ SIU520 SS7 Signaling Gateway
22