Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

Related

Code

Package

Manual

Manual Pages

References

Conformance

Performance

Design

Status

Overview

Scope

FAQ

Browse Source

Applications

SS7 Stack

ISDN Stack

SIGTRAN Stack

VoIP Stack

MG Stack

SS7/ISDN Devices

IP Transport

Embedded Systems

Operating System

Resources

Packages

Sys Req

Repositories

Download

Mailing Lists

Browse Source

CVS Archive

Bug Reports

Library

Hardware

Vendor Links

Home

Overview

Status

Documentation

Resources

About

News

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:

SS7 Stack Applications Bearer Independent Call Control (BICC) Integrated Services Digital Network (ISDN) User Part (ISUP) Base Station System Application Part (BSSAP) Transaction Capabilities Application Part (TCAP) Signalling Connection Control Part (SCCP) Message Transfer Part (MTP) Level 3 (MTP3) Message Transfer Part (MTP) Level 2 (MTP2) SS7 Stack Manager
Bearer Independent Call Control (BICC)

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.

The BICC multiplexing driver handles Unequippped Circuit Identification Codes automagically and incorporates partial (non-circuit specific) state machines for BICC.

The BICC multiplexing driver is used primarily by the CS/AIN Call Model, OpenSwitch and Asterisk PBX integration applications. (See "Applications"). You can view the BICC code directory here.

Integrated Services Digital Network (ISDN) User Part (ISUP)

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.

The ISUP multiplexing driver handles Unequipped Circuit Identification Codes automagically and incorporates partial (non-circuit specific) state machines for ISUP.

The ISUP multiplexing driver is used primarily by the CS/AIN Call Model, OpenSwitch and Asterisk PBX integration applications. (See "Applications"). You can view the ISUP code directory here.

Transaction Capabilities Application Part (TCAP)

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.

Signalling Connection Control Part (SCCP)

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.

Message Transfer Part (MTP) Level 3 (MTP3)

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.

SS7 Stack Manager

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:

  1. Portability to more Operating Systems and architectures.
  2. Support for embedded systems and RT operating systems.
  3. Close control over congestion and flow control withing the SS7 stack.
  4. Separation of performance issues and considerations from the underlying kernel architecture.
  5. Separation from GPL'ed kernels via the LGPL'ed LiS STREAMS package permitting linking of proprietary applications.
Last modified: Sun, 19 Oct 2014 13:44:53 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.