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
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
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,
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
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 is dependent on the Operating System & involves
Porting the OS calls
Porting error handler & printing of trace messages
Porting System Management Entity
Porting error handler is dependent on the User’s System & is based
on how the errors are to be reported.
IPC mechanism between stack entities / stack entity & service user
Porting the printing is dependent on the User’s 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
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
Other parameters e.g. Call Control configuration parameters,
CICs provisioning / unprovisioning etc can be included as per the customer's
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.
MTP2–hardware 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
Whenever the hardware has received a signaling unit, it will invoke another
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 :
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.
Microtek MCC68K compiler
Borland C compiler
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 :
(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?
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 client’s thread of control (calling application). This implies that
whenever possible, the stack code should be executed in the stack’s thread
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
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
The SS7 stack includes a primitive System Management entity. The functionality
of system management entity consists of the following:
Provisioning, initialization and maintenance of SS7 stack entities.
Debug and trace management of SS7 stack entities.
Solicited and periodic statistics collection/reporting.
Redundancy management of SS7 stack entities.
Ques: What is meant by 'Redundancy Management'
Ans: Redundancy management if implemented shall mean the following
SS7 stack shall have two operating states ONLINE and STANDBY.
An interface shall be provided for redundancy data updation.
A mechanism shall be provided to indicate to the system management entity
for triggering the redundancy data updation to all the redundant components.
System management entity shall have the control for changing the state
of the SS7 stack.
Compile time flag to control the inclusion/exclusion of redundancy features
shall be provided.