Intel Switch SIU520 SS7 User Manual

Application Note  
Building Fault-tolerant SS7  
Systems Using the  
®
Intel NetStructure™  
SIU520 SS7 Signaling Gateway  
Intel in  
Communications  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Table of Figures  
Figure 1 Structure of the Intel® NetStructure™ SIU520 SS7 Signaling Gateway  
2
3
4
5
6
7
8
Figure 2 Integrating the SIU520  
Figure 3 SIU Connected to Adjacent Node with Two Links in Link Set  
Figure 4 SIU520 Connected to Mated STP Pair Providing Route Resiliency  
Figure 5 Dual SIU Architecture  
Figure 6 Transmit Routing to a Single Destination  
Figure 7 Dual-resilient SIUs Connected to a Mated STP Pair in a Straight Line  
Configuration  
Figure 8 Dual-resilient SIUs Connected to a Mated STP Pair in a Crossed Link  
Configuration  
8
Figure 9 Transmit Routing Through Mated STPs  
9
Figure 10 Normal Routing for Circuit Group 0 When Controlled by SIUA  
10  
Figure 11 Routing When All Local Links Have Failed, Group 0 Controlled by SIUA 11  
Figure 12 Routing Following Failure of SIUA  
12  
13  
14  
Figure 13 Two Different Architectures for a TCAP Processing SIU System  
Figure 14 Message Flow on a Dual-resilient System Running  
the SS7 Stack up to TCAP  
Figure 15 Dual LAN Operation on the SIU520  
Figure 16 TCAP Dialogue Groups Example  
15  
16  
17  
18  
19  
20  
Figure 17 Inter-SIU Link over Crossed E-1/T-1 Cable  
Figure 18 Inter-SIU Link Set over V.11  
Figure 19 Example Configuration to an Adjacent SSP/SCP  
Figure 20 Example Configuration to an Adjacent STP Pair  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
Because of the high expectation of service reliability by  
the users of public telephone networks, equipment  
Abstract  
In order to achieve five-nines (99.999%) reliability and a  
manufacturers and system integrators demand high  
high degree of fault tolerance in an SS7 environment  
levels of fault tolerance and availability, often citing the  
®
using Intel NetStructure™ SIU520 signaling gateways,  
five-nines for availability (requiring a system to be  
an SS7 end point spread over two signaling interface  
operational for 99.999% of the time).  
units (SIUs) and multiple application servers can be  
These systems need to continue to offer service even  
when partial hardware or software failure has occurred.  
There are several well-known methods of achieving this  
type of reaction to partial failure in the signaling  
configured and deployed. Splitting the protocol  
processing functionality of a signaling point by  
implementing an SS7 node over two SIUs isolates the  
hardware processors on the chassis from each other.  
This separation lets one processor continue if the other  
fails, allowing the system to remain in service. Distributing  
application processing of a signaling point on multiple  
application servers not only increases the total capacity  
of a system, but also offers a higher level of fault  
tolerance in the user application space.  
component of communications networks, including:  
Multiple signaling paths (SS7 links and link sets) to  
each end point  
Distribution of these paths through independent inter-  
faces and cabling  
Distribution of the processing of SS7 terminations at a  
single signaling point between multiple processing  
cards in a single SIU  
Intel NetStructure SS7 products are designed for this  
dual-processor approach and provide the architecture for  
splitting a point code over two active SS7 protocol  
engines. Using this technique, the links in an SS7 link set  
can be spread between two separate chassis when Intel  
NetStructure SS7 boards are installed in each.  
Physical isolation and duplication of the SS7 interface  
for a single signaling point on independent protocol  
engines sharing a single point code  
Splitting the functionality of the application layer  
between multiple application servers  
This document describes the features of the SIU520 SS7  
signaling gateway that are available to build SS7  
solutions and reach the five-nines requirements of  
telco-grade service platforms.  
The first method can be achieved by implementing multi-  
ple links (64 Kb/s or 56 Kb/s channels) between two  
adjacent inter-communicating points. (By definition, these  
links will all be in the same link set.) The last two can be  
accomplished by using two independent, but co-operat-  
ing, SIU520s relaying the SS7 signaling to a distributed  
application layer split over multiple application hosts.  
Introduction  
This application note describes the architecture of the  
Intel NetStructure SIU520 signaling gateway, reviews the  
most common potential points of failure of an SS7  
system based on this product, and explains methods that  
can mitigate each of these potential failure points. This  
document also explains in detail the configuration and  
run-time operation considerations of a dual-resilient  
SIU520-based system.  
Note: Readers should be familiar with Signaling System  
7 (SS7) concepts. They should also be aware that the  
information contained in this application note is provided  
as a complement to the Intel NetStructure SIU520  
Developer’s Manual; hence, an understanding of the  
terms defined in the developers manual is assumed.  
1
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Application  
#1  
Application  
#N  
Application  
#0  
Ethernet  
API Layer/Ethernet Driver  
MAP or INAP or IS41  
ISUP  
TUP  
TCAP  
Configuration  
and  
Management  
SCCP  
MTP Levels 1-3  
SIU 520  
®
Figure 1. Structure of the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
The SS7 signaling may be presented from the network  
multiplexed in a timeslot on an E-1 (2.048 MB/s) or T-1  
(1.544 MB/s, also known as DS1) bearer or by a V.35  
(56/64 kb/s) synchronous serial interface.  
Overview of SIU Operation  
The Intel NetStructure SIU520 SS7 signaling gateway is  
an SS7 network access product that provides a resilient  
interface to SS7 networks via a TCP/IP local area net-  
work (LAN). As shown in Figure 1, SIU520 software  
includes SS7 protocol layers, as well as a configuration  
and management module. The SIU520 supports multiple  
SS7 signaling links within the same pulse code modula-  
tion (PCM) trunk interface or over multiple PCM trunks.  
The SIU examines the timeslots carrying the SS7 informa-  
tion and processes them accordingly, outputting this data  
to the LAN using TCP/IP. Similarly, it takes commands  
from the TCP/IP LAN and converts those to SS7 signals  
for transmission to the SS7 network. In the receive direc-  
tion, information is conveyed to the user application in  
structured messages placed in a sequential queue.  
For telephony operation (using a telephony layer 4 protocol  
such as ISUP or TUP), if the SS7 signaling is multiplexed  
onto a PCM bearer, the voice circuits may be passed  
transparently through the SIU to the application platform  
that terminates the physical circuits (see Figure 2).  
Circuit-switched API Operation  
The message-based application programming interface  
(API) operates transparently over TCP/IP Ethernet, using  
software modules provided by Intel. For circuit-switched  
(telephony) applications, each application platform termi-  
nates and hence controls a fixed range of physical cir-  
cuits, or circuit identification codes (CICs). CICs are con-  
figured in groups of up to 32, each group normally  
equating to all the circuits in a single E-1 or T-1 trunk.  
Each group is terminated on a fixed application platform  
or host processor, enabling the SIU to automatically  
direct API messages to the correct platform.  
For both circuit- and transaction-related operations, the  
SIU520 provides the ability to automatically distribute  
signaling information between a number of physically  
independent application platforms, thus providing a  
degree of fault tolerance within the application space.  
2
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
E-1 or T-1 Trunks,  
Voice Circuits  
Only  
CT Application Platform  
}
SIU520  
E-1 or T-1 Trunks  
with SS7 Channel  
and Voice Circuits  
SS7  
Information  
}
CT Application Platform  
Ethernet  
Figure 2. Integrating the SIU520  
Transaction-based API Operation  
Potential Points of Failure  
TCAP-based applications can be distributed on multiple  
application hosts using two different methods which are  
explained in details further in this document (see “Failure  
of Applications”, pg. 15). These methods imply running  
TC-user application parts (such as GSM-MAP, INAP, or  
IS-41) on each application host. When running any  
application part above TCAP on the SIU520 itself, the  
product allows operation of a single host application.  
In this section, the most critical points of failure of an Intel  
NetStructure SIU520 SS7 signaling gateway-based sys-  
tem are reviewed. The list of potential points of failure  
include:  
SS7 links  
SS7 routes  
Power supply  
Signaling interface unit  
IP subnetwork  
Application host  
Management Interface  
The SIU520 constantly monitors the state of its physical  
connections, PCM trunk inputs, the communication  
channel via TCP/IP Ethernet to the host processors and  
reports status information to an application process  
running on a user-defined host. The host elected to  
receive management messages can be selected by  
sending an API_MSG_COMMANDmanagement request.  
(See the Intel NetStructure SIU520 Developer’s Manual  
for more information.) Host 0 is used by default.  
For each of these points of failure, a solution is provided  
and implementation details are given.  
3
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
A) Load sharing between link 0 and link 1 under normal conditions  
Link id 0, slc 0  
Link id 1, slc 1  
SIU520  
SSP/SCP  
Point Code  
0x100  
Point Code  
0x200  
Link Set id 0  
B) Traffic sent over link 1 under failure of link 0  
SSP/SCP  
SIU520  
Point Code  
0x100  
Point Code  
0x200  
Figure 3. SIU Connected to Adjacent Node with Two Links in Link Set  
Link failure management is a standard MTP3 operation  
Failure of SS7 Links  
and is not an SIU520-specific feature. In other words,  
failure between links in a same link set will happen in a  
completely transparent way for the user application.  
Problem — With a single link to the adjacent signaling  
point, service is disrupted if the link goes down for some  
reason (i.e., layer 1 alarm, congestion).  
Details — In an SIU520 system configuration, two  
commands are used in config.txt to configure link sets  
and links: MTP_LINKSET and MTP_LINK. In this  
example, two SS7 links are defined between local point  
code 0x100and adjacent point code 0x200on time  
slot 16 of PCM ports 1 and 2. (Also see Figure 3.)  
Solution — Link resiliency is achieved by using multiple  
links between a local point code and an adjacent point  
code. By definition, such links are said to belong to the  
same link set, which can contain up to 16 links. Ideally,  
the links of a link set should not be carried over a unique  
physical medium (such as an E-1 or T-1 trunk) but,  
instead, should be split over independent physical trunks.  
* MTP_LINKSET <linkset_id> <adjacent_spc> <num_links> <flags> <local_spc> <ssf>  
MTP_LINKSET 0 0x200 2 0x0000 0x100 0x08  
* MTP_LINK <link_id> <linkset_id> <link_ref> <slc> <bpos> <blink> <bpos2>  
*<stream> <timeslot> <flags>  
MTP_LINK 0 0 0 0 0 0 0 0 16 0x0006  
MTP_LINK 1 0 1 1 0 1 0 1 16 0x0006  
4
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
A) Load sharing between link set 0 and link set 1 under normal  
Link Set id 0  
STPA  
Point Code  
0x200  
SSP/SCP  
SIU520  
Point Code  
0x100  
Point Code  
0x400  
STPB  
Link Set id 1  
Point Code  
0x300  
B) Traffic sent over link set 1 under failure of STP  
Link Set id 0  
SSP/SCP  
SIU520  
Point Code  
0x100  
Point Code  
0x400  
STPB  
Point Code  
0x300  
Link Set id 1  
Figure 4. SIU520 Connected to Mated STP Pair Providing Route Resiliency  
defined in an SIU520 configuration file, a choice must be  
Failure of Routes  
made between two different traffic modes: load sharing  
or failover. In load-sharing mode, traffic sent towards the  
remote signaling point is shared between the two link  
sets. In failover mode, all traffic sent towards the remote  
signaling point will normally be sent using the primary link  
set, unless this link set fails, in which case the traffic will  
use the alternative link set. See the Intel NetStructure  
SIU520 Developer’s Manual for more information on the  
selection of traffic mode in the MTP_ROUTE command.  
Problem — With a single route to a destination point  
code (DPC), service can be disrupted if all the links of the  
link set used to reach that signaling node fail. Route  
failover is a standard MTP3 operation which does not  
require any specific action from the user application.  
Solution To eliminate this single point of failure, an  
alternative link set can be provided in the SIU520 system  
configuration to reach the same DPC. Route failover is a  
standard MTP3 operation which does not require any  
specific action from the user application.  
Details — This example (see Figure 4) shows two link  
sets (each containing one link) being used in load-sharing  
mode to reach destination point code 0x400.  
Note: When an alternative route to a given DPC is  
* MTP_LINKSET <linkset_id> <adjacent_spc> <num_links> <flags> <local_spc> <ssf>  
MTP_LINKSET 0 0x200 2 0x0000 0x100 0x08  
MTP_LINKSET 1 0x300 2 0x0000 0x100 0x08  
* MTP_LINK <link_id> <linkset_id> <link_ref> <slc> <bpos> <blink> <bpos2>  
*<stream> <timeslot> <flags>  
MTP_LINK 0 0 0 0 0 0 0 0 16 0x0006  
MTP_LINK 1 0 1 1 0 1 0 1 16 0x0006  
MTP_LINK 2 1 0 0 0 2 0 2 16 0x0006  
MTP_LINK 3 1 1 1 0 3 0 3 16 0x0006  
* MTP_ROUTE <dpc> <linkset_id> <user_part_mask> <flags> <second_ls> <pc_mask>  
MTP_ROUTE 0x400 0 0x0020 0x0003 1 0x00000000  
5
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Application  
Ethernet  
Ethernet  
SIUA  
SIUB  
API Layer/Ethernet Driver  
API Layer/Ethernet Driver  
Distributed Layer 4  
MAP or INAP  
or IS41  
MAP or INAP  
Management  
or IS41  
ISUP  
TUP  
ISUP  
TUP  
TCAP  
TCAP  
SCCP  
SCCP  
Distributed MTP3  
Management  
MTP Levels 1-3  
MTP Levels 1-3  
Link Set  
Figure 5. Dual SIU Architecture  
Solution — A major feature of the SIU architecture is  
that two units can be configured to operate as a single  
entity, sharing the same local SS7 point code. In normal  
operation, signaling can be shared between two units. In  
the event of a failure, signaling is maintained by the  
remaining unit.  
Failure of Power Supply  
Problem — Ensuring that the unit survives the loss of  
one power supply and making it possible to replace a  
failed power supply without affecting the availability of the  
system.  
Solution — The Intel NetStructure SIU520 SS7 signaling  
gateway can be optionally configured with a redundant  
and hot swappable power supply.  
Details — In a dual configuration, one unit is assigned  
as SIUA, the other as SIUB. Under normal operation, the  
application uses both the resources of SIUA and SIUB  
(see Figure 5).  
Details — Please refer to Intel NetStructure SIU520/Intel  
NetStructure SG430 Hardware User Manual, Issue 3 to  
obtain part numbers for redundant power supplies for the  
SIU520.  
The distributed layer 4 management is achieved using a  
LAN connection and allows SS7 messages for any trans-  
action or call to be received by either unit, regardless of  
the unit that is actually processing the call or transaction.  
Failure of Signaling Interface Unit  
Problem — Since the SIU520 provides an SS7 interface  
to a distributed application, it is usually deployed for  
high-density service platforms. Should the SIU of a single  
SIU-based system fail, many resources (telephony cir-  
cuits to TCAP dialogues) would become unavailable and  
would cause major service disruption.  
The distributed MTP3 functionality is achieved using a  
specially configured inter-SIU link set, containing one or  
more signaling links. Transmit messages from each SIU  
are load shared between links that connect to the local  
SIU, if these are available. If all local network-facing SS7  
links have failed, transmit messages are relayed to the  
6
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
A) Normal routing case  
Single Point Code  
Inter-SIU  
Link Set  
SIUA  
SSP/SCP  
F-Links  
Link Set id 0  
SIUB  
Link Set id 1  
B) Routing under network link failure  
Single Point Code  
Inter-SIU  
Link Set  
SIUA  
SIUB  
Link Set id 0  
SSP/SCP  
Link Set id 1  
Figure 6. Transmit Routing to a Single Destination  
partner SIU across the inter-SIU link set and sent out to  
the adjacent signaling point by the partner unit. The inter-  
SIU link set also provides the capability of message  
retrieval and retransmission when a changeover operation  
occurs between the two units.  
from SIUA are sent to the destination SSP or SCP using  
local SS7 links if available. If these fail, transmit messages  
are relayed through SIUB over the inter-SIU links. In this  
case, the DPC is also the adjacent signaling point.  
Although Figure 6 shows an SIU pair connected to a sin-  
gle adjacent signaling point, the pair may be connected  
to multiple destinations.  
For circuit-switched applications, the circuit groups are  
configured on both units, letting the application select  
which SIU controls each group. In normal operation,  
the control of circuit groups is distributed between both  
the SIUA and SIUB. In the event of failure of a unit  
(or for maintenance), the application can move control  
of each circuit group from one SIU to the other.  
The number of links allocated in the inter-SIU link set has  
to be carefully calculated. Since these links will be used  
for outgoing traffic only, they can be used at a higher  
capacity than network-facing links. Moreover, since only  
half of the traffic can potentially be routed through that  
link set, a common rule is to allocate a fourth of the total  
number of network-facing links in the inter-SIU link set. In  
a fully populated pair of SIU520 (12 links per unit; 24 links  
total), 16 links will be typically allocated in the network-  
facing link set and four links will be allocated in the inter-  
SIU link set.  
For transaction-based applications, the transactions are  
shared equally between the two units.  
Routing Architectures of a Dual-resilient SIU  
System  
The routing options (i.e., straight connection to the DPC  
vs. indirect connection via a pair of STPs) described in  
this section will vary based on the actual network architec-  
ture that is being supported for a particular application.  
Routes to destinations are configured such that there is a  
primary link set (the link set from the SIU to the DPC) and  
a secondary link set (the inter-SIU link set) which is used  
only when the primary link set has failed.  
Connection to a Single Adjacent Signaling Point  
Figure 6 shows two possible routing alternatives for SIUA  
routing to an adjacent SSP or SCP. Messages issued  
7
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Single Point Code  
Link Set id 1  
Inter-SIU  
Link Set  
STPA  
STPB  
SIUA  
SIUB  
Link Set id 0  
SSP/SCP  
A-Links  
Link Set id 2  
Figure 7. Dual-resilient SIUs Connected to a Mated STP Pair in a Straight Link Configuration  
Single Point Code  
Link Set id 1  
Inter-SIU  
Link Set  
STPA  
STPB  
SIUA  
SIUB  
Link Set id 0  
SSP/SCP  
Link Set id 2  
Figure 8. Dual-resilient SIUs Connected to a Mated STP Pair in a Crossed Link Configuration  
In case (A), since the F-links all exist in the same link set,  
messages may be sent from the adjacent SSP/SCP to  
either SIUA or SIUB. If an SIU receives a message from  
the SS7 network for a circuit or transaction that it does  
not control, this receive message is passed automatically  
to the other SIU for processing via the TCP/IP LAN.  
is configured with three linksets: two link sets containing  
the links towards each STP, plus the inter-SIU link set  
(see Figure 8). The configuration of the DPC will contain  
the link set IDs of the two link sets connected to the  
STPs. Load sharing can be enabled to take advantage of  
all the system resources. In such a configuration, the  
inter-SIU link set is not used for traffic failover, but only for  
synchronization of network management messages.  
Consequently, a single link within this link set is fairly  
enough, giving an increased bandwidth for network-  
facing links.  
Connection to an Adjacent Mated STP Pair  
There are two ways of connecting a pair of SIUs to a  
mated STP pair. In the first method, the straight link  
configuration, each SIU is configured with two link sets:  
one link set containing STP-facing links, plus the  
inter-SIU link set. The straight link configuration consists  
in connecting SIUA to STPA and SIUB to STPB, as  
shown in Figure 7.  
The inter-SIU link must be carefully dimensioned as it will  
have to support the outgoing traffic of the SIU that would  
have lost its entire network-facing links, as shown in  
Figure 9. Again, a common practice is to allocate a fourth  
of the total number of network-facing links in the inter-  
SIU link set.  
The second method, the crossed link configuration,  
consists of adding crossed link connections between  
SIUA and STPB and between SIUB and STPA to the  
previous mode. In a crossed link configuration, each SIU  
8
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
A) Normal routing case (both network link sets available)  
Single Point Code  
Link Set id 1  
Inter-SIU  
Link Set  
SSP/SCP  
STPA  
SIUA  
SIUB  
Link Set id 0  
A-Links  
C-Links  
STPB  
Link Set id 2  
B) Routing under failure of network link set between SIUA and adjacent STP  
Single Point Code  
Link Set id 1  
Inter-SIU  
Link Set  
SSP/SCP  
SIUA  
SIUB  
A-Links  
Link Set id 0  
C-Links  
STPB  
Link Set id 2  
Transmit Traffic from SIUA  
Transmit Traffic from SIUB  
Figure 9. Transmit Routing Through Mated STPs  
Table 1 compares the advantages and disadvantages of these methods.  
Table 1. Comparison of a Straight Link Configuration vs. a Crossed Link Configuration  
Comparison Subject  
Straight Configuration  
Crossed Configuration  
Load sharing  
-
+
STPA can only load share traffic  
Each STP can load share between the two SIUs,  
for SIUA and vice-versa  
optimizing the resource utilization  
Network-facing links  
failure  
+
-
SIUA can rely on SIUB to send  
When an SIU loses its network-facing links, the  
outgoing traffic upon failure of its application must activate circuit groups on the  
entire network-facing links  
surviving SIU (for ISUP-based application)  
Inter-SIU link set  
dimensioning  
-
+
Need to allocate 1/4 of all  
network facing links (e.g., 16  
network facing links and four  
inter-SIU links)  
Need to allocate a single link, maximizing the  
number of network-facing links (e.g., 22 network facing  
links and one inter-SIU link). Allocating a single link means  
there are two single points of failure in the system.  
For best resilience, the inter-SIU link set should contain  
two links spread across two cards in each SIU.  
9
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
MTP1-3  
Circuit Group 0  
[Active]  
Circuit Group 1  
[Inactive]  
SIUA  
Adjacent  
Signaling  
Point  
Inter-SIU  
SS7 Link Set  
Application  
TCP/IP Ethernet  
Circuit Group 0  
[Inactive]  
Circuit Group 1  
[Active]  
MTP1-3  
SIUB  
Transmit traffic for circuits active on SIUA  
Received traffic for circuits active on SIUA  
Figure 10. Normal Routing for Circuit Group 0 When Controlled by SIUA  
signaling for each of the circuit groups it terminates. A  
circuit group activation command must be sent to the  
selected SIU for each circuit group. Any outgoing  
messages for circuits in this group must be sent to this  
SIU, as shown in Figure 10.  
Dual SIU Architecture for Circuit-Switched  
Applications  
Within the SIU environment, circuits are configured in  
groups, each group equating to all the circuits  
multiplexed onto a single E-1 or T-1 PCM trunk. The SIU  
provides the SS7 circuit control and the application  
platform (or host) terminates the physical channels,  
typically with a voice processor.  
The adjacent signaling point views the links connected to  
SIUA and SIUB as the same link set and, as such, is free  
to send messages for the circuits controlled by SIUA to  
either unit. In the case where SIUB receives a message  
for a circuit controlled by SIUA, the message is  
automatically routed to the correct controlling circuit  
group using the LAN Ethernet connection (shown by the  
shaded arrows in Figure 10).  
For normal operation, half the circuit groups are  
controlled by SIUA and half by SIUB. As each application  
platform starts up and connects to both SIUA and SIUB,  
the application must nominate which SIU is to control the  
10  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
MTP1-3  
Circuit Group 0  
[Active]  
Circuit Group 1  
[Inactive]  
SIUA  
Adjacent  
Signaling  
Point  
Inter-SIU  
SS7 Link Set  
Application  
TCP/IP Ethernet  
Circuit Group 0  
[Inactive]  
Circuit Group 1  
[Active]  
MTP1-3  
SIUB  
Transmit traffic for circuits active on SIUA  
Received traffic for circuits active on SIUA  
Figure 11. Routing When All Local Links Have Failed, Group 0 Controlled by SIUA  
If all the links between the controlling SIU and the  
adjacent signaling point fail, all transmit traffic is  
automatically routed to the adjacent signaling point  
through the inter-SIU link set as shown in Figure 11. The  
application should continue to use the SIU as before,  
directing all outgoing circuit requests to SIUA.  
Calls in a steady state (speech) will continue uninter-  
rupted.  
Outgoing calls in a set-up state during the transfer  
should be re-attempted.  
Incoming calls being set-up by the interconnected SS7  
equipment will also fail and will be re-attempted  
remotely.  
If the controlling SIU fails, the application is informed of  
the failure and should transfer control of the circuit group  
to the remaining unit.  
11  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
SIUA  
Adjacent  
TCP/IP Ethernet  
Signaling  
Point  
Application  
Circuit Group 0  
[Active]  
Circuit Group 1  
[Active]  
MTP1-3  
SIUB  
Figure 12. Routing Following Failure of SIUA  
The circuit group control will then appear as shown in  
Figure 12.  
two stages. The group should be deactivated from one  
unit (if communication with that unit is possible) before  
being activated on the partner SIU. To protect against  
control being active on both units at the same time, the  
SIU automatically issues a deactivate command to the  
partner unit in response to an activate command from  
the host application and checks the status of each circuit  
group on the partner unit. An API management event  
indication is given if dual control is detected.  
The user application software should reset all idle circuits  
following a transfer, and reset all remaining circuits as  
they become idle.  
When the failed unit recovers, control of the circuits may  
be transferred back by the application.  
Circuit group control is transferred by the application in  
12  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
A) Dual-resilient SIUs running SS7 protocol stack to TCAP  
B) Dual-resilient SIUs running SS7 protocol stack up to SCCP  
Host 0  
Host N  
Host 0  
Host N  
TC User  
TC User  
. . .  
TC User  
TC User  
. . .  
TCAP  
DTC  
TCAP  
DTC  
Ethernet  
SIUB  
SIUA  
Ethernet  
SIUB  
SIUA  
TCAP  
TCAP  
DTS  
SCCP  
MTP  
DTS  
SCCP  
SCCP  
SCCP  
MTP  
MTP  
MTP  
Figure 13. Two Different Architectures for a TCAP Processing SIU System  
In the first case, TCAP and potential layers sitting on top  
of TCAP run on the application host(s) and an additional  
piece of software is required on each SIU to distribute  
TCAP transactions to multiple application hosts. This  
software option is called distributed transaction server  
(DTS). Figure 13 depicts this architectural difference.  
Dual SIU Architecture for Transaction-based  
Applications  
There are two ways of architecting a dual-resilient  
SIU520-based system for processing TCAP transactions.  
Running the SS7 stack up to SCCP on the SIUs  
Running the SS7 stack up to TCAP on the SIUs  
13  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
SIUA  
TCAP  
instance = 0  
Ethernet  
SCCP  
MTP  
Adjacent  
Signaling  
Point  
Inter-chassis  
communication  
(RSI)  
Application  
MTP  
SCCP  
TCAP  
instance = 1  
SIUB  
Transmit message for transaction handled by TCAP B  
Message received for transaction handled by TCAP B  
Figure 14. Message Flow on a Dual-resilient System Running the SS7 Stack up to TCAP  
In the second case, each unit controls half of the total  
available transactions. (The Intel NetStructure SIU520  
SS7 signaling gateway supports up to 16,384 transac-  
tions. A dual-resilient system can consequently handle up  
to 32,768 simultaneous transactions.) Each transaction is  
processed for its entire duration by the SIU that  
processed the first TCAP message. The user application  
must therefore direct all messages for a transaction to  
the same SIU, and load balance outgoing dialogues  
between the two units. An incoming TCAP dialogue mes-  
sage other than BEGIN or QUERY is handled by the SIU  
that processed the first TCAP message for that dialogue  
received from the SS7 network. When an SIU receives a  
TCAP message that belongs to a transaction that was  
initiated on the other unit, it will pass this message to its  
peer SIU over the RSI connection. This is shown in  
Figure 14. Failure of an SIU reduces the number of avail-  
able transactions to one-half.  
In a dual-resilient transaction-based SIU system running  
the SS7 stack up to SCCP on the SIU, and TCAP (and  
above) on the application host, each host controls a fixed  
number of transactions. Each transaction is processed  
for its entire duration by the application host that  
processed the first TCAP message. Upon failure of one  
SIU unit, the TCAP capacity and ongoing transaction are  
totally unaffected.  
The architectural decision taken on where the TCAP  
module is running also has consequences on the level of  
application resiliency and total system capacity. These  
consequences are explained in more details in “Failure of  
Application”, pg. 15.  
14  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
Application  
Host  
SIU520  
Application  
Host  
Figure 15. Dual LAN Operation on the SIU520  
available to allow TCAP-based applications to failover to  
other hosts.  
Failure of IP Subnetwork  
Problem — Should one subnetwork go down due to a  
network component failure, the hosts connected to the  
SIU over the other subnetworks will remain active and  
attempt to preserve half of the total system capacity.  
Details — For TCAP-based applications, the SIU allows  
operation of multiple application hosts interfacing directly  
to TCAP, hence giving a certain level of resiliency in the  
user application space. Two methods are available for  
this purpose and are explained here.  
Solution — There are two Ethernet ports on the SIU520.  
This allows splitting the IP connections between the SIU  
and the application hosts onto two physically separated  
subnetworks, as shown in Figure 15. This eliminates the  
risk of losing all IP connectivity in the event of a  
switch/router/hub failure in the LAN.  
TCAP Resiliency Based on Dialogue Groups  
Fixed ranges of TCAP dialogues can be created in the  
SIU520 configuration file and assigned to different  
application hosts. (TCAP dialogue groups are defined  
using the TCAP_CFG_DGRPcommand in config.txt.  
More information about this command can be found in  
the Intel NetStructure SIU520 Developer’s Manual.) The  
application program running on each host must therefore  
ensure that only dialogue identifiers from the assigned  
range are used. Optionally, a TCAP-user layer such as  
MAP, INAP, or IS41 can run on each application host to  
provide some application part functionalities. Figure 16  
describes such a distributed architecture where TCAP  
transactions are handled by four different hosts, each of  
them running MAP and a MAP application. The total  
number of TCAP dialogues for the whole system is  
16,384 and this number does not depend on the number  
of hosts.  
Details — “Failure of Application”, below, shows how to  
take advantage of the dynamic configuration features  
offered by the SIU520 to failover the affected application  
hosts to the surviving subnetwork.  
Failure of Application  
Problem —The failure of an application host leads to the  
loss of a portion of system resources.  
Solution —The most basic feature ensuring this is that  
the application can be deployed on multiple hosts. In a  
software release bigger than v1.06, the SIU520 supports  
up to 64 hosts. For circuit-switched applications, failure  
of a host generally means loss of the physical trunk  
interface; hence, there is no need of transferring the logic  
to other (surviving) hosts. More sophisticated features are  
15  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Host 0  
Host 1  
Host 2  
Host 3  
Application  
Application  
Application  
Application  
Ethernet  
SIU520  
TCAP  
SCCP  
MTP  
Figure 16. TCAP Dialogue Groups Example  
each application host. Consequently, the total capacity of  
such a system depends on the number of application  
hosts, each host bringing an increment of 65,536  
simultaneous dialogues. Please refer to the Intel®  
NetStructure™ SS7 Protocols DTS User Guide, Issue 2,  
for more information on the DTS/DTC software option.  
TCAP Resiliency Based on DTS/DTC Option  
Alternatively, it is possible to distribute SCCP traffic to  
multiple application hosts using the distributed transac-  
tion server/distributed transaction client (DTS/DTC) soft-  
ware option, as shown on Part B of Figure 13. In this  
architecture, TCAP and potential application parts run on  
16  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
Signaling Card  
PCM Trunk #0  
SS7 Network  
E-1 Trunk Containing  
SS7 Signaling Only  
PCM Trunk #1  
SIUA  
PCM Trunk #2  
PCM Trunk #3  
Inter-SIU SS7 Link Set  
Signaling Card  
E-1 Trunk  
PCM Trunk #0  
SS7 Network  
E-1 Trunk Containing  
SS7 Signaling Only  
PCM Trunk #1  
SIUB  
PCM Trunk #2  
PCM Trunk #3  
Figure 17. Inter-SIU Link over Crossed E-1/T-1 Cable  
Hardware Requirements  
Configuring a Dual SIU Pair  
Configuring an SIU as one-half of a resilient pair requires  
additional hardware ports to carry the inter-SIU link set  
between SIUA and SIUB. This may be achieved using  
E-1/T-1 interfaces, as shown in Figure 17, or V.11 (V.35)  
interfaces, as shown in Figure 18. A cable, part number  
842484, can be purchased from your Intel distributor to  
interconnect two V.11 ports between signaling cards  
within the SIU. For more information, refer to the Intel  
NetStructure SIU520 Developer’s Manual.  
To create a dual-resilient configuration for the Intel  
NetStructure SIU520 SS7 signaling gateway,  
modifications are required to both the system  
configuration (done using the man machine interface  
[MMI]) and the protocol configuration (in the config.txt  
parameter file). This may be done remotely and trans-  
ferred to the SIU using FTP. More details may be found in  
the Intel NetStructure SIU520 Developer’s Manual.  
17  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Signaling Card  
SS7 Network  
PCM Trunk #0  
E-1 or T-1 Trunk Containing  
SS7 Signaling and Voice Circuits  
PCM Trunk #1  
SIUA  
V.11 Port #A  
V.11 Port #B  
Inter-SIU SS7 Link Set  
Voice  
Processing  
Platform  
Signaling Card  
SS7 Network  
PCM Trunk #0  
E-1 or T-1 Trunk Containing  
SS7 Signaling and Voice Circuits  
PCM Trunk #1  
SIUB  
V.11 Port #A  
V.11 Port #B  
Figure 18. Inter-SIU Link Set over V.11  
The inter-SIU signaling link set can be configured to use  
any signaling processor on any signaling card and may  
be carried on any of the available interfaces on the  
signaling card.  
Changes to the config.txt Parameter File  
Each SIU is configured individually. The config.txt  
parameter file held on each unit reflects the configuration  
view of the local unit only; hence, assignments of link set  
and link identities are only unique within a single unit.  
If V.11 interfaces are used to carry the SS7 signaling  
between the SIU and the network (this is typically the  
case in North America), it is possible that there will be  
free E-1/T-1 PCM ports on signaling cards. These may  
be used for the inter-SIU signaling.  
For the dual configuration, it is necessary to modify the  
protocol configuration file config.txt to assign one unit  
as SIUA and the other as SIUB using the  
SIU_INSTANCEcommand. The IP address of the other  
SIU must also be declared using the SIU_REM_ADDR  
command.  
System Configuration  
The system assignment of SIUA or SIUB is made by typ-  
ing one of these commands:  
Configuring the Inter-SIU Link  
The inter-SIU link set should be defined on both units  
using the MTP_LINKSETcommand with bit 15 of the  
<flags> parameter set to 1. This link set must have the  
same value defined for the <local_spc> and  
CNSYS:MODE=SIUA;  
or  
CNSYS:MODE=SIUB;  
<adjacent_spc> values; this will be the local point code  
of the SIU pair. Links are added to the inter-SIU link set  
The current assignment may be displayed by typing:  
CNSYP;  
18  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
Single Point  
Code  
Inter-SIU  
Link Set  
Link id 1, slc 0  
SIUA  
Link Set id 0  
SSP/SCP  
SIUB  
Link id 1, slc 1  
Link_id 0,  
slc 0  
Point  
Code 200  
Link Set id 1  
Point  
Code 100  
Figure 19. Example Configuration to an Adjacent SSP/SCP  
using the MTP_LINKcommand, assigning incrementing  
<link_ref> and <slc> values as normal. The <bpos>  
and <blink> parameters define which SS7 processor  
(there are three on each signaling card) manages each  
link. If a V.11 port is being used, <blink> must be either  
1 or 2.  
Circuit Group Configuration  
For dual operation, each SIU should contain identical  
circuit group declarations using the appropriate  
ISUP_CFG_CCTGRPor TUP_CFG_CTGRPcommands.  
These circuit group configurations do not become active  
on either unit until an Activate Circuit Group API  
command has been issued to a particular SIU.  
For a link using a PCM port, the physical location of the  
link is specified by setting stream and timeslot: stream 16  
is the PCM port closest to the green LED on the signaling  
card, stream 17 the lower PCM port. To use a serial link,  
the MTP_LINK<flags> bit 14 should be set to 1,  
<stream> and <timeslot> both to 0. One of the units  
should act as the V.11 port clock master, the other as  
slave; hence, one SIU must also have <flags> bit 13  
set to 1.  
Example Configuration  
To define routing to the DPC 200 below (which is also the  
adjacent point code), using the first E-1 port on the first  
signaling card in a SIU520, the configuration (Figure 19)  
would be  
For SIUA  
MTP_CONFIG 0 0 0x0000  
MTP_LINKSET 0 100 1 0x8000 100 0x8  
MTP_LINKSET 1 200 1 0x0000 100 0x8  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x4006  
MTP_LINK 1 1 0 0 1 2 1 2 16 0x0006  
MTP_ROUTE 100 0 0x0020  
For example, to configure an inter SIU link, on linkset_id  
0, to use V.11 port A on the first board in a SIU520, this  
command would be used to define a V.11 clock slave:  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x4006, while  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x6006would  
define a V.11 port clock master.  
MTP_ROUTE 200 1 0x0020 0x0001 0  
For SIUB  
MTP_CONFIG 0 0 0x0000  
Routing Configuration  
MTP_LINKSET 0 100 1 0x8000 100 0x8  
MTP_LINKSET 1 200 1 0x0000 100 0x8  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x6006  
MTP_LINK 1 1 0 1 1 2 1 2 16 0x0006  
MTP_ROUTE 100 0 0x0020  
A route should be defined on both SIUA and SIUB for the  
inter-SIU link set using the MTP_ROUTEcommand  
referencing the appropriate <linkset_id> with a <dpc>  
value set to the point code of the SIU pair. This route  
may only be specified to operate over a single link set.  
MTP_ROUTE 200 1 0x0020 0x0001 0  
Each DPC that may be accessed from the application  
must have an accompanying MTP_ROUTEdeclaration.  
For dual operation, each route includes a preferred link  
set, the <linkset_id> parameter, and a secondary link  
set specified by <second_ls>. linkset_id should refer-  
ence the link set connecting the SIU to the appropriate  
adjacent signaling point, second_ls must be set to the  
linkset_id assigned to the inter-SIU link set.  
(up_enable was set for ISUP, user part SI = 5 for the  
example above)  
19  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Single Point  
Point  
Code 400  
Code  
Link Set id 1  
link_id 1, slc 0  
Inter-SIU  
Link Set  
STPA  
SIUA  
SIUB  
Link Set id 0  
SSP/SCP  
Point  
Code 600  
Point  
Code 300  
Link Set id 1  
STPB  
Point  
Code 500  
Figure 20. Example Configuration to an Adjacent STP Pair  
For an SIU pair connected to a mated STP pair, carrying  
the inter-SIU link over the second E-1 port of the first  
signaling card the configuration (Figure 20) would be:  
Run-time Operations of a Dual-resilient  
SIU System  
Connecting a Host to Two SIUs  
For SIUA  
In a dual SIU system, each host should connect to both  
SIUA and SIUB at start-up. This is achieved using the  
rsicmd utility twice: first with an siu_id of 0 for SIUA and  
second with an siu_id of 1 for SIUB. For example, if  
SIUA has an IP address of 123.234.345.110 and SIUB  
an IP address of 123.234.345.220, the entry in the hosts  
system configuration file, system.txt, would be:  
MTP_CONFIG 0 0 0x0000  
MTP_LINKSET 0 300 1 0x8000 300 0x8  
MTP_LINKSET 1 400 1 0x0000 300 0x8  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x4006  
MTP_LINK 1 1 0 0 1 2 1 2 16 0x0006  
MTP_ROUTE 300 0 0x0020  
MTP_ROUTE 400 1 0x0020 0x0001 0  
MTP_ROUTE 500 1 0x0020 0x0001 0  
MTP_ROUTE 600 1 0x0020 0x0001 0  
FORK_PROCESS rsicmd 0 0xef 0  
123.234.345.110 9000  
For SIUB  
FORK_PROCESS rsicmd 1 0xef 0  
123.234.345.220 9000  
MTP_CONFIG 0 0 0x0000  
MTP_LINKSET 0 300 1 0x8000 300 0x8  
MTP_LINKSET 1 500 1 0x0000 300 0x8  
MTP_LINK 0 0 0 0 1 1 1 1 0 0x6006  
MTP_LINK 1 1 0 0 1 2 1 2 16 0x0006  
MTP_ROUTE 300 0 0x0020  
MTP_ROUTE 400 0 0x0020 0x0001 0  
MTP_ROUTE 500 1 0x0020 0x0001 0  
MTP_ROUTE 600 1 0x0020 0x0001 0  
The “concerned module id” (0xefin this case) will  
receive status indications from the rsi process for both  
connections. The id field of the MSG header is set to the  
siu_id to identify the link that each status indication  
relates to.  
The ability to communicate between a host and an SIU is  
indicated by RSI_MSG_STATUS messages received by  
the conc_id application process (0xefin this case).  
20  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
System Initialization  
Communicating with Both SIUA and SIUB  
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.  
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.  
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 applications module ID.  
GCT_set_instance  
int GCT_set_instance(unsigned int  
instance, HDR *h);  
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.  
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);  
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.  
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.  
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.  
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”).  
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  
21  
 
®
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 applications module  
ID.  
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”.  
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).  
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.  
There are two failure modes that can cause loss of  
communication:  
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  
applications knowledge of the current circuit state. This  
is achieved by sending three CGSC requests to the  
secondary SIU.  
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 applications 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.  
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.  
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  
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.  
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.  
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.  
The SIU processes single commands in sequence;  
22  
 
®
Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway Application Note  
Recovery of the Failed Unit  
When all existing calls are completed (all the circuits are  
therefore idle), the application should deactivate the circuit  
group by sending an API_MSG_COMMAND message  
with cmd_type of 9 to the secondary unit. When the  
acknowledgement that this command has been success-  
fully processed has been received, the groups should be  
activated on the primary unit by sending an  
The host application is informed of recovery of the  
communication to the SIU with the same method used  
for notification of the failure. The RSI_MSG_LINK_  
STATUS message in this case contains a status value of  
1 (link to SIU recovered).  
The host nominated to receive management  
indications (normally host 0) will also receive an  
API_MSG_SIU_STATUS message with status value 31  
(decimal) indicating a host link has recovered to the  
specified host ID.  
API_MSG_COMMAND message with cmd_type of 8.  
Once the acknowledgement of the activation has been  
received by the application, all affected circuits should be  
reset. This will force the circuits to a known (idle) state  
and remove the blocking status. When the reset is  
acknowledged from the terminating switch (by receipt of  
a circuit group supervision control confirmation message)  
the application may begin exchanging call traffic with  
the SIU.  
Transferring Control Back  
Immediately following re-establishment of communication  
with the primary SIU, the application should send  
deactivate circuit group messages to this SIU to ensure  
that groups are only active on the secondary unit (this  
may be the case if the inter-SIU link had also failed). If the  
primary unit has recovered from a complete failure, no  
circuit groups will be active. This deactivate command  
will fail if the groups were not active and the application  
should ignore any acknowledgement of this command  
with a status value indicating processing failure. A “busy”  
response should cause the application to reattempt the  
deactivate.  
Circuit Group Conflict  
Both SIUs in a dual-resilient configuration periodically poll  
each other to determine which circuit groups are active  
on each unit. If a group is active on both units at the  
same time, an API_MSG_USER_EVENT message is  
issued by the unit that detects the conflict, indicating the  
group ID of the affected circuit group. The controlling  
application host should issue a deactivate command to  
the SIU that should not be controlling the circuit group  
and re-synchronize the circuits in the group (on the  
correct SIU) by issuing a reset.  
When communication with the primary SIU has been  
re-established, the application should allow sufficient time  
to ensure that the communication is stable, thus avoiding  
repeatedly transferring circuits between units. After this  
time has expired, the application should transfer control  
of the affected circuit groups back to the original SIU.  
The SIUs prevent this situation from arising by  
automatically sending a deactivate circuit group  
command to the other unit on receipt of the activate  
command. If the nature of the failure is such that  
inter-SIU communication is lost, it may be impossible for  
the SIU to issue the automatic deactivate command.  
Under this circumstance, when the failed SIU recovers,  
circuit groups may be active from the time before the  
initial failure. This situation is handled by the application  
sending a deactivate command for all of the previously  
active groups immediately following restoration of the  
communication with the SIU.  
This is achieved by deactivating the groups on the  
secondary SIU and re-activating the ones on the primary  
SIU. However, before the groups are deactivated, the  
circuits in that group should be maintenance blocked.  
(Using the Circuit Group Supervision Control API  
message). This does not affect any calls in progress, but  
will prevent these circuits from being selected for any  
new incoming calls. The application should also ensure  
that none of the affected circuits are selected for new  
outgoing calls.  
23  
 
®
Application Note Building Fault-tolerant SS7 Systems Using the Intel NetStructure™ SIU520 SS7 Signaling Gateway  
Q: Do I need to activate circuit groups on a single  
Appendix A: Frequently Asked Questions  
Q: How can I tell if an SIU fails?  
SIU configuration?  
A: No.  
A: The status of the communication between the host  
and the SIU is indicated by RSI_MSG_STATUS  
messages.  
Q: How many links should I configure in the  
inter-SIU link set?  
A: The inter-SIU link set should have sufficient capacity  
to enable it to carry the maximum traffic exchanged  
between a single SIU and the adjacent signaling  
point. To eliminate single points of failure, more than  
one link may be configured in the link set, each link  
connecting to a different signaling card.  
Q: What happens if an SS7 message for a circuit  
or transaction is received by an SIU that does  
not control that circuit or transaction?  
A: The message is automatically passed to the partner  
SIU using the TCP/IP LAN.  
Q: If a single SS7 link to the network fails on one  
of my SIUs, does my application need to take  
any action?  
Appendix B: For More Information  
Intel® NetStructure™ SIU520 Developer’s Manual, Issue  
support/ss7/siu520/u06siu02.pdf  
A: No. If there are other links remaining on that unit, the  
traffic will changeover to one of these; otherwise, the  
traffic will be automatically passed to the other unit  
via the inter-SIU SS7 link set.  
Intel® NetStructure™ SIU520/Intel® NetStructure™  
SG430 Hardware User Manual, Issue 3, available at  
ProductSpecific/SG430/HardwareUserManual/  
U05SIU03.pdf  
Q: If all of the SS7 links to one of the SIUs fails do  
I need to take any action?  
A: No. The SIU will automatically re-route transmit traffic  
via the inter-SIU SS7 link set.  
Intel® NetStructure™ SS7 Protocols DTS User Guide,  
Issue 2, available at http://resource.intel.com/  
telecom/support/ss7/cd/GenericInfo/  
Q: If an SIU fails do I need to take any action?  
GeneralDocumentation/U24SSS02-DTS-UG.pdf  
A: Yes. For switched-circuit applications, the circuit  
groups controlled by the failed unit should be  
activated on the remaining unit. Further information  
may be found in the Intel NetStructure SIU520  
Developer’s Manual.  
Appendix C: Abbreviations  
API  
Application programming interface  
Circuit identification code  
Destination point code  
Distributed transaction client  
Distributed transaction server  
Local area network  
CIC  
DPC  
DTC  
DTS  
LAN  
MMI  
PCM  
SIU  
Q: What happens if an inter-SIU SS7 link fails?  
A: The SIU will changeover to use other SS7 links in the  
inter-SIU link set.  
Q: What happens if the Ethernet interfaces fail on  
an SIU?  
Man machine interface  
Pulse code modulation  
Signaling interface unit  
Signaling system 7  
A: This will cause failure of all of the connections  
between the hosts and the SIU. The SIU will react by  
deactivating all connected SS7 links, preventing any  
more signaling information from being received from  
the SS7 network. The host applications will receive  
an indication indicating failure of the SIU and should  
transfer any circuit groups controlled by this SIU to  
the remaining unit, the effective result being as  
though the complete unit had failed.  
SS7  
24  
 
To learn more, visit our site on the World Wide Web at http://www.intel.com.  
1515 Route Ten  
Parsippany, NJ 07054  
Phone: 1-973-993-3000  
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR  
IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT, EXCEPT  
AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALES FOR SUCH PRODUCTS. INTEL ASSUMES NO LIABILITY WHAT-  
SOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS,  
INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRIGE-  
MENT OF ANY PATENT, COPYRIGHT, OR ANY OTHER INTELLECTUAL PROPERTY RIGHT.  
Performance tests and ratings are measured using specific computer systems and/or components and reflect the approximate perfor-  
mance of Intel products as measured by those tests. Any difference in system hardware or software design or configuration may affect  
actual performance. Buyers should consult other sources of information to evaluate the performance of systems or components they  
are considering purchasing. For more information on performance tests and on the performance of Intel products, reference  
The Intel products referred to in this document are intended for standard commercial use only. Customer is solely responsible for  
assessing the suitability of the product for use in particular applications.  
Intel may make changes to specifications, product descriptions, and plans at any time, without notice.  
*Other names and brands may be claimed as the property of others.  
Intel, Intel NetStructure, and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United  
States and other countries.  
Copyright © 2004 Intel Corporation  
Printed in the USA  
Copyright © 2004 Intel Corporation  
All rights reserved.  
Printed on recycled paper.  
08/04 00-9206-001  
e
 

Intellinet Network Solutions Switch 524100 User Manual
Jaguar Automobile 5HP24 User Manual
Jenn Air Appliance Trim Kit W10588274A User Manual
JVC Digital Camera 0810YMH AL VM User Manual
Kenmore Vacuum Cleaner 11627614 User Manual
Kenwood Stereo System VR 6060 User Manual
Kidde Smoke Alarm 0918K User Manual
KitchenAid Cooktop KGCV566R User Manual
KitchenAid Ventilation Hood KHTU100 User Manual
Krell Industries CD Player Evolution 505 User Manual