Filter
Top Products
Communicating with Both SIUA and SIUB
The user application exchanges information with the SIU
via API messages (MSG). In a dual SIU environment,
each time the user application sends a message to the
SIU, this should be directed to either SIUA or SIUB using
a library function GCT_set_instance. In the receive
direction, the application can determine the SIU that sent
a MSG using the library function GCT_get_instance.
Function definitions may be found in the header
file sysgct.h.
GCT_set_instance
int GCT_set_instance(unsigned int
instance, HDR *h);
This function sets the destination instance number (SIU
identity or siu_id) prior to sending a message and returns
0 on success, non-zero otherwise (currently no failure
conditions are defined). SIUA is instance 0 and SIUB is
instance 1, assigned by the siu_id parameter provided to
the rsicmd utility. This function should be called
immediately before GCT_send.
GCT_get_instance
unsigned int GCT_get_instance(HDR *h);
This function returns the instance number (SIU identity or
siu_id) after receiving a message. The parameter h is a
pointer to the HDR structure at the start of the received
MSG. The returned value will be either 0 or 1. SIUA is
instance 0 and SIUB is instance 1, as assigned by the
siu_id parameter provided to the rsicmd utility.
Transferring Control of a Circuit Group between
SIUs
Activating and Deactivating Circuit Groups
Configuration commands for all circuit groups must be
present on both SIUs. At run time, the application running
on each host should select which SIU is currently in con-
trol of each group by “activating” and “deactivating”
groups on a particular SIU.
Circuit groups are activated and deactivated using the
API_MSG_COMMAND message (type 0x7f0f), with a
cmd_type of 8 to activate a group and a cmd_type of 9
to deactivate a group. The format of this message is
detailed in the Intel NetStructure SIU520 Developer’s
Manual. This message should be issued with a request
for a response (an acknowledgement); this will be
returned to the requesting application with a status value
of zero (indicating “success”) or non-zero values (indicat-
ing “busy” or “failure”).
System Initialization
When the system starts-up, the host establishes
communication with both SIUA and SIUB, either by using
the rsicmd utility or by issuing RSI configuration API
messages directly from within the application.
When the communication between the host and the SIU
is established, the RSI task on the host issues an
RSI_MSG_LINK_STATUS API message with a status
value set to 1 (link to SIU recovered) to a destination task
conc_id on the host (conc_id is set when the RSI link
was started). This message will only be received by the
application if the RSI link is configured with the conc_id
set to the application’s module ID.
The ID field of this message is set to 0 to indicate SIUA
and 1 to indicate SIUB. When the link to the SIU that
normally controls a circuit group (the primary SIU)
becomes active, the application should issue an activate
group command to that SIU, specifying that circuit group
(using its group ID). The SIU processes API commands
sequentially and the application must wait for an
acknowledgement of this command before proceeding.
An acknowledgement that indicates “busy” should cause
the application to re-attempt the activate command.
The application should wait for a period of time sufficient
to establish communication to the preferred SIU before
deciding that the preferred unit is not available and
activating circuit groups on the non-preferred or
secondary SIU.
Once the acknowledgement of the activation of a circuit
group is received, the circuits should be reset to force the
circuits into a known, idle state. This is achieved using
the Circuit Group Status Control (CGSC) Request
API message, detailed in the appropriate Programmer’s
Manual. The circuit reset is acknowledged by the
terminating exchange; this acknowledgement is passed
to the user application as a circuit group status
confirmation API message. On receipt of this, the
application may commence using the associated circuits
for calls.
Failure Detection
The event that triggers the application to transfer circuit
groups from one SIU to another is loss of communication
between the application and the SIU.
When the failure occurs, the RSI task on the affected
host detects the loss of communication and issues an
RSI_MSG_LINK_STATUS API message with a status
value set to 2 (link to SIU lost) to a destination task
Building Fault-tolerant SS7 Systems Using the Intel
®
NetStructure™ SIU520 SS7 Signaling Gateway Application Note
21