SS7: FAQ

Technology

What is SS7?
What can the SS7 network and protocol be used for ?
What does the SS7 signaling architecture look like ?
What are the layers in a SS7 stack ?
What is Global title translation ?

Product Information

What is Global title translation?

What standards does the SS7 stack confirm to ?
What is meant by the statement - "SS7 Stack can work in
both single-threaded and multi-threaded systems"?
What does porting the stack onto a system involve?
What can I configure using the Layer Management
Entity Interface ?
What is the functionality of the client code?
How does MTP2 handle multiple links ?

User Queries

Can multiple instances of the same stack entity run on

one processor ?

What compiler do we use for SS7 ?

Is any global data referenced by the stack entity? What

are the implications ?

Do you require virtual memory ?

On a 64bit Processor, do checksums and CRCs

calculation in the stack get impacted?

Is any system requirement functionality assumed from an

external DB?

What are the performance requirements that the HSS

SS7stack has been designed to meet?
 How is error handling implemented ?
What is the functionality of the System Management
Entity?

What is meant by 'Redundancy Management'

Ques: What is SS7?

Ans : Common Channel Signaling System No. 7 (i.e., SS7 or

C7) is a global standard for telecommunications defined by the
International Telecommunication Union (ITU)
Telecommunication Standardization Sector (ITU-T). The
standard defines the procedures and protocol by which network
elements in the public switched telephone network (PSTN)
exchange information over a digital signaling network to effect
wireless (cellular) and wireline call setup, routing and control.

Ques: What standards does the SS7 stack confirm to ?

Ans: The HSS SS7 stack allows for national variants such as the
American National Standards Institute (ANSI) and Bell
Communications Research (Bellcore) standards used in North
America and the European Telecommunications Standards
Institute (ETSI) standard used in Europe. Spanish and British
Variants are also supported

Ques: What can the SS7 network and protocol be used for?

Ans : The SS7 network and protocol can be used for:

basic call setup, management, and tear down

wireless services such as personal communications
services (PCS), wireless roaming, and mobile subscriber
authentication
local number portability (LNP)
toll-free (800/888) and toll (900) wireline services
enhanced call features such as call forwarding, calling
party name/number display, and three-way calling
efficient and secure worldwide telecommunications
Ques: What does the SS7 signaling architecture look like ?

Ans : SS7 messages are exchanged between network elements

over 56 or 64 kilobit per second (kbps) bidirectional channels
called signaling links. Signaling occurs out-of-band on
dedicated channels rather than in-band on voice channels

The Network consist of three types of Network Elements

SSP: Signal Switching Points are telephone exchanges

equipped with SS7 capable software. They are
responsible for originating, terminating or switching
calls
STP: Signal Transfer Points are packet switches that
receive and route signaling messages to their proper
destination
SCP: Signaling Control Point is a database that provides
information necessary for advanced call-processing
capabilities

Ques: What are the layers in a SS7 stack ?

Ans : The SS7 protocol stack has the following underlying

layers
Message Transfer Part

The Message Transfer Part (MTP) is divided into three levels.

The lowest level, MTP Level 1, is equivalent to the OSI
Physical Layer. MTP Level 1 defines the physical, electrical,
and functional characteristics of the digital signaling link.
Physical interfaces defined include E-1 (2048 kb/s; 32 64 kb/s
channels), DS-1 (1544 kb/s; 24 64kb/s channels), V.35 (64
kb/s), DS-0 (64 kb/s), and DS-0A (56 kb/s).
MTP Level 2 ensures accurate end-to-end transmission of a
message across a signaling link. Level 2 implements flow
control, message sequence validation, and error checking. When
an error occurs on a signaling link, the message (or set of
messages) is retransmitted. MTP Level 2 is equivalent to the
OSI Data Link Layer.

MTP Level 3 provides message routing between signaling

points in the SS7 network. MTP Level 3 re-routes traffic away
from failed links and signaling points and controls traffic when
congestion occurs. MTP Level 3 is equivalent to the OSI
Network Layer.

ISDN User Part (ISUP)

The ISDN User Part (ISUP) defines the protocol used to set-up,
manage, and release trunk circuits that carry voice and data
between terminating line exchanges (e.g., between a calling
party and a called party). ISUP is used for both ISDN and non-
ISDN calls. However, calls that originate and terminate at the
same switch do not use ISUP signaling.
Telephone User Part (TUP)

In some parts of the world (e.g., China, Brazil), the Telephone

User Part (TUP) is used to support basic call setup and tear-
down. TUP handles analog circuits only. In many countries,
ISUP has replaced TUP for call management.
Signaling Connection Control Part (SCCP)

SCCP provides connectionless and connection-oriented network

services and global title translation (GTT) capabilities above
MTP Level 3. SCCP is used as the transport layer for TCAP-
based services.
Transaction Capabilities Applications Part (TCAP)

TCAP supports the exchange of non-circuit related data between

applications across the SS7 network using the SCCP
connectionless service. Queries and responses sent between
SSPs and SCPs are carried in TCAP messages. For example, an
SSP sends a TCAP query to determine the routing number
associated with a dialed 800/888 number and to to check the
personal identification number (PIN) of a calling card user. In
mobile networks (IS-41 and GSM), TCAP carries Mobile
Application Part (MAP) messages sent between mobile switches
and databases to support user authentication, equipment
identification, and roaming.
Ques: What is Global title translation?

Ans : A global title is an address (e.g., a dialed 800 number,

calling card number, or mobile subscriber identification number)
which is translated by SCCP into a destination point code and
subsystem number. A subsystem number uniquely identifies an
application at the destination signaling point.

Ques : What is meant by the statement - "SS7 Stack can work in both
single-threaded and multi-threaded systems"?

Ans : The SS7 Stack entities (MTP2, MTP3, ISUP SCCP&

TCAP) can be compiled and run as a single thread. This is
possible because of the coding guidelines which ensure
uniqueness of function names and global variables.

In addition, each SS7 Stack Entity can execute as a separate

thread. This is possible because each stack entity is independent
and does not share any data structures with other stack entities.
Communication between two stack entities is through a message
based interface.
Ques : What does porting the stack onto a system involve?

Ans : Porting the stack onto a system involves the following :

Porting the OS calls

Porting error handler & printing of trace messages
Porting System Management Entity
Porting redundancy

Porting the OS calls is dependent on the Operating System &

involves :

Memory management
Timer management
IPC mechanism between stack entities / stack entity &
service user

Porting error handler is dependent on the Users System & is

based on how the errors are to be reported.

Porting the printing is dependent on the Users System & is

based on how / where the trace messages are to be displayed.

Porting System Management Entity involves developing an User

Interface (GUI / other) for managing the stack entities using the
Layer Management APIs (Provisioning, Statistics, Controlling
Error Reporting and Traces etc.).

SS7 stack can be ported unto any customer platform

Ques: What can I configure using the Layer Management Entity

Interface ?

Ans: Given below are some examples of parameters

configurable from LME

Linksets configuration

Link configuration

Route configuration
 Timer configuration

Trace Levels

E1/T1 card configuration

Congestion levels

Other parameters e.g. Call Control configuration parameters,

CICs provisioning / unprovisioning etc can be included as per
the customer's requirements

Ques: What is the functionality of the client code?

Ans : The client codes parses all the APIs coming to the stack. It
forms an interface between the stack and the user / service layer.

Ques : How does MTP2 handle multiple links ?

Ans : MTP2 has a well defined interface (in the form of

functional calls) with the hardware, which is to be ported. This
is explained in detail, in the MTP2 Porting Guide.

The multiple SS7 links are handled by the hardware in any

fashion (polling in round robin or any other manner/ interrupt
driven) MTP2 places no restriction on this.

MTP2hardware interface consists of a set of functions, which

are invoked by the hardware as needed :

Whenever the hardware is ready to transmit, it will

invoke a well-defined MTP2 function.
Whenever the hardware has received a signaling unit, it
will invoke another MTP2 function.

Ques : Can multiple instances of the same stack entity run on one
processor ?

Ans : This depends upon the operating system.

In OS like Solaris, Windows NT etc., where each instance /
execution of the stack entity has its own data area, this is
possible.

In RTOS like VxWorks etc., the global variables are mapped to

a fixed location in memory (flat memory structure). Hence,
multiple instances of the stack entity access the same data area
for globals, leading to clash.

Ques : What compiler do we use for SS7 ?

Ans : The SS7 development environment is Solaris, with GNU

C (gcc) compiler.

We also compile our source code using the following compilers,

before a release :

Microtek MCC68K compiler

Borland C compiler

If a customer is planning to use a different compiler than the

above, the source code can be compiled using that compiler
before the release.

Ques : Is any global data referenced by the stack entity? What are the
implications ?

Ans : The database and a few other variables maintained by each

stack entity are defined as global definitions. This has no
implication in OS like Unix, which do not share memory across
tasks. However, in case of RTOS (like Vxworks, PSOS) which
have a flat memory space, there is only one copy of this data
irrespective of number of tasks or processes started. e.g. if two
instances of ISUP are running on the same board they will be
referring to the same copy of data.

This will be fixed in future releases of stack the solution will

be as decided in the Protocol Development framework, which
would be one of the following :
 Keep global database indexed by the instance number of
the module.

Define the database as local to the stack entity and pass

the reference to it with each call of stack and down to all
levels. All the database references will be done with
respect to this reference.

Ques : Do you require virtual memory ?

Ans : There is no assumption in the stack with respect to type of

memory - it can be virtual or physical. But as explained in
previous question, there is a problem when multiple instances of
a stack entity are executing and accessing the same copy of data
in case of flat memory systems.

So if we assume that virtual memory models will keep the stack

global space along with the stack task(process) context, we can
support multiple instances of each entity on the same board.

Ques : On a 64bit Processor, do checksums and CRCs calculation in the

stack get impacted ?

Ans : All the checksums calculated in SS7 (i.e. CRC in MTP2)

are 16-bit CRC. They will not be affected by a 64-bit processor.

All the stack entities operates on following basic types :

U8bit
U16bit
U32bit
S8bit
S16bit
S32bit

(where U is for unsigned and S for Signed) These definitions

are defined in a header file & can be changed if needed.
Ques : Is any system requirement functionality assumed from an
external DB?

Ans. : Database maintained by each stack entity is local to it and

has got no external dependency. The database maintained by
each entity has got a static part (which is initialized by
provisioning) and a dynamic part (which is updat5ed at run-time
by the stack entity).

The interface of each stack entity with its database module is a

well defined functional interface (read/write/access/modify). If
there is a need to use an external database, this functional
interface has to be ported.

Ques: What are the performance requirements that the HSS SS7stack
has been designed to meet?

Ans:

The protocol stack (and each constituent entity) will be

so designed so as to allow porting on the target platform
with minimal real-time overload on the clients thread of
control (calling application). This implies that whenever
possible, the stack code should be executed in the stacks
thread of control.

Keeping in mind the strong time and memory constraints

in telecom systems, the stack design and code will be
developed for maximum time and memory efficiency.
Wherever messages need to be exchanged across
entities, stack architecture will be so designed so as to
minimize the bandwidth requirement.

Ques: How is error handling implemented ?

Ans: All errors are indicated through an uniform interface.

Handling of errors is the responsibility of the system
management entity. All possible errors that might occur in
processing (including SS7 protocol procedural errors) is
numbered and globally defined. All the SS7 protocol processing
entity modules maintain a global error flag (global to a module)
which reflects last error encountered in the processing.
Ques: What is the functionality of the System Management Entity?

Ans:

The SS7 stack includes a primitive System Management entity.

The functionality of system management entity consists of the
following:

1. Provisioning, initialization and maintenance of SS7 stack

entities.
2. Debug and trace management of SS7 stack entities.
3. Solicited and periodic statistics collection/reporting.
4. Redundancy management of SS7 stack entities.

Ques: What is meant by 'Redundancy Management'

Ans: Redundancy management if implemented shall mean the

following

o SS7 stack shall have two operating states

ONLINE and STANDBY.
o An interface shall be provided for redundancy
data updation.
o A mechanism shall be provided to indicate to the
system management entity for triggering the
redundancy data updation to all the redundant
components.
o System management entity shall have the control
for changing the state of the SS7 stack.
o Compile time flag to control the
inclusion/exclusion of redundancy features shall
be provided.