SS7 Stack

Description: OpenSS7 Signalling System No. 7 (SS7) Stack Code

This page provides a roadmap to the STREAMS SS7 Stack code and the (now
deprecated) Linux Native Kernel (Sockets) code. This code presented here is
a (possibly outdated) snap-shot of our OpenSS7 working directories. This is
provided for browsing only to get a feel for the OpenSS7 stack code. Please
read our licensing terms before using
any of the code viewed here.

STREAMS SS7 Stack Code

The main directory for the LiS STREAMS version of OpenSS7 can be viewed here.
Or, you can select one of the specific modules from the diagram below,
or from the section headings of the list below:

BICC (Bearer Independent Call Control) is a relatively new addition to the
OpenSS7 SS7 stack. This multiplexing driver permits BICC users to open BICC
streams and bind them to BICC Circuit Identifier ranges between specific Local
and Remote Point Codes. This permits a BICC user stream to represent a BICC
"Trunk Group".

This multiplexing driver has MTP streams linked underneath it by the SS7
Configuration Daemon, either a priori or on demand. BICC Users can
also open and link MTP streams for their own use. Linked MTP streams can be
SS7 MTP, SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP
or SCTP). MTP3b version of SS7 MTP and TALI MTP streams are also supported.

ISUP (Integrated Service Digital Network [ISDN] User Part) is an integral part
of the OpenSS7 SS7 stack. This multiplexing driver permits ISUP users to open
ISUP streams and bind them to ISUP CIC ranges between specific Local and
Remote Point codes. This permits an ISUP user stream to represent one or more
ISUP Trunk Groups.

The ISUP multiplexing driver has MTP streams linked underneath it by the SS7
configuration daemon, either statically, or on demand. ISUP users can also
open and link MTP streams for their own use. Linked streams can be SS7 MTP,
SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP or SCTP).
MTP3b version of SS7 MTP and TALI MTP streams are also supported.

TCAP (Transaction Capabilities Application Part) is an integral part of the
OpenSS7 SS7 stack. This multiplexing driver permits TC- or TR-users to open
TCAP streams and bind them to SCCP Global Titles for specific Subsystem
Numbers and Point Codes. This permits an TC- or TR- user stream to represent
a range of Global Titles for a specific Subsystem Number representing a range
of TCAP subscriber services.

The TCAP multiplexing driver has SCCP streams linked underneath it by the SS7
configuration daemon, either statically, or on demand. TC- and TR-users can
also open and link SCCP streams for their own use. Linked streams can be SS7
SCCP or SIGTRAN SUA (over SCTP or SSCOP-MCE). MTP3b and TALI versions of SS7
SCCP are also supported via the MTP and TALI muxes.

The TCAP multiplexing driver handles dialogues and non-existent transaction
identifiers automagically. It includes full TCAP TC and TR state machines.
The interface to TCAP is modelled on the STREAMS OSI Transport Provider
Interface (TPI).

The TCAP multiplexing driver is used primarily by the HLR, SMSC, IN, LNP and
CS/AIN Call Model applications. (See
"Applications").
You can view the TCAP code directory here.

SCCP (Signalling Connection Control Part) is an integral part of the OpenSS7
SS7 stack. This multiplexing driver permits SCCP users to open SCCP streams
and bind them to SCCP Global Titles for specific Subsystem Numbers and Point
Codes. It fully supports protocol class 0, 1, 2, and 3 operation. This
allows SCCP users to represent a range of subscribers and users of an SCCP
subsystem.

The SCCP multiplexing driver has MTP streams linked underneath it by the SS7
configuration daemon, either statically, or on demand. SCCP users can also
open and link MTP streams for their own use. Linked streams can be SS7 MTP,
SIGTRAN M3UA (over SCTP or SSCOP-MCE) or TALI MTP streams (over TCP or SCTP).
MTP3b versions of SS7 MTP and TALI MTP streams are also supported.

The SCCP multiplexing driver handles protocol class 0, 1, 2 and 3 operations.
It includes full SCCP state machines. The interface to the SCCP modules is
modelled on the STREAMS OSI Network Provider Interface (NPI).

The SCCP multiplexing driver is used primarily in direct support of TCAP.
You can view the SCCP code directory here.

MTP3 (Message Transfer Part [MTP] Level 3) is an integral part of the OpenSS7
SS7 stack. This multiplexing driver permits MTP users to open MTP streams and
bind them to local MTP Point Codes and Service Indicators. It fully supports
sequenced and unsequenced delivery. This allows MTP users to represent a
service indicator at a signalling point.

The MTP multiplexing driver has Signalling Link (SL) streams linked underneath
it by the SS7 configuration daemon, either statically or dynamically. MTP
users can also open and link SL streams for their own use. Link streams can
be SS7 MTP2, MTP3b (over SSCOP-MCE), SIGTRAN M2PA (over SCTP), and SIGTRAN M2UA
(over SCTP or SSCOP-MCE) streams.

The MTP multiplexing driver handles full MTP procedures including the
"Transfer Function". In includes full MTP state machines. The interface to
the MTP modules is modelled after the STREAMS OSI Network Provider Interface
(NPI) Connectionless (CL) interface.

The MTP multiplexing driver is used primarily in direct suppor of SCCP, ISUP
and BICC.
You can view the MTP code directory here.

The SS7 Stack Manager is an SS7 configuration deamon that runs in user space
with sufficient priviledge and opens control streams to the SS7 multiplexing
drivers, modules and drivers to maintain and manage the configuration of the
SS7 stack. It is executed from system init scripts at startup to bring up the
SS7 stack at boot time and uses a number of configuration files to peform its
function.

The SS7 configuration deamon is not required to be able to use the SS7 stack,
but it removes the need for an application to peform its own stack
configuration. It is supported by all of the SS7 components.
You can view the SS7CONF code directory here.

Old SS7 Stack Code

If you are interested in browsing the old Linux Native Kernel implementation
from the openss7-0.7.2.tgz release, you can
walk through the directory here. Note that this
approach was abadonned in favor of the STREAMS implementation that can be
viewed from the diagram and lists above. The reasons for abandonning the
Linux Kernel Native (Sockets) approach were as follows:

Portability to more Operating Systems and architectures.

Support for embedded systems and RT operating systems.

Close control over congestion and flow control withing the SS7 stack.

Separation of performance issues and considerations from the underlying
kernel architecture.