PERFORMANCE TESTING OF
SIGNALING TRANSFER POINTS USED IN SIGNALING
SYSTEM 7 (SS7) NETWORKS
THESIS
Submitted in Partial Fulfillment
of the REQUIREMENTS for the
Degree of
MASTER OF SCIENCE (Telecommunications Networks)
at the
POLYTECHNIC UNIVERSITY
by
Rimma Iontel
June 2001
_________________
Advisor
_________________
Date
_________________
Department Head
_________________
Date
Copy No._______
ii
AN ABSTRACT
PERFORMANCE TESTING OF SIGNALING TRANSFER
POINTS USED IN SIGNALING SYSTEM 7 (SS7) NETWORKS
by
Rimma Iontel
Advisor: Malathi Veeraraghavan
Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science
(Telecommunications Networks)
January 2001
The goals of this project are to understand how to test STPs for protocol conformance,
interoperability and performance. Detailed technical reports have been written for
protocol conformance and interoperability tests, and listed in the references of this thesis.
Hence the focus of this thesis is exclusively on performance testing. A rapid increase in
the volume of SS7 traffic has led to higher demands on Signaling Transfer Point (STP)
performance, specifically impacting processing delays. Taking required values as a
starting point, STPs should subject to a series of tests to determine whether they exhibit
performance compatible with that demanded by the extensively deployed Advanced
Intelligent Network (AIN) services. By applying traffic from simulated nodes to a real
STP, processing delays are measured using monitoring equipment.
After analyzing
captured data, we concluded that the Tekelec Eagle STP (Release 26) is able to
perform according to specifications.
iii
Table of Contents
List of Figures…………...………………………………………………….iv
List of Tables…………...…………….…………………………………….v
1.0
Introduction…………...…………………………………………….1
2.0
SS7 Overview………………………………………….……………4
2.1
SS7 Network Architecture……….………………………… 4
2.1.1 Signaling Switching Point…………………………. 5
2.1.2 Signaling Transfer Point……………...……………. 5
2.1.3 Service Control Point………………………………. 5
2.2
SS7 Protocol………………………………………….……..9
2.2.1 Message Transfer Part……………………...……….10
2.2.1.1 Primitives……………………………..……. 10
2.2.1.2 Signal Units…………...…………………….13
2.2.1.3 Detailed View of Level 2 Functions……….. 19
2.2.1.4 Detailed View of Level 3 Functions……….. 22
2.2.2 Signaling Connection Control Part……………….... 32
2.2.3 ISDN User Part……….….………………………… 37
2.2.4 Transaction Capabilities Application Part……...….. 38
3.0
SS7 over ATM……………………………………………………... 40
3.1
SS7 over High Speed Links Protocol Details……………….40
3.1.1 AAL5 Common Part…………...…………..………. 41
3.1.2 Service-Specific Connection Oriented Protocol…… 42
3.1.3 Service-Specific Coordination Function…………… 45
3.1.4 Layer Management...………………………………. 46
4.0
Testing Methods…………...………………………………………. 48
4.1
Conformance Testing…………...………………….………. 48
4.2
Interoperability Testing…………...………….…….………. 49
4.3
Performance Testing…………...………………….…….…..50
5.0
Test Cases for STP Performance Testing…………...………………53
5.1
Test Case 1…………...………………….…………………. 56
5.2
Test Case 2…………...………………….………………….61
6.0
Conclusion…………...………………….…………………………..64
List of Acronyms…………...………………….……………………..……. 66
Appendix A: Captured MSU…………...………………….………………. 69
Appendix B: MGTS Traffic Reports for Test Case 2……………………....71
References…………...……………………….…………………………….. 75
iv
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
3.1
3.2
3.3
3.4
5.1
5.2
5.3
5.4
5.5
5.6
5.7
SS7 Network Topology……………………………………………. 6
STP Quad Configuration……………………………………………8
SS7 Protocol Stack vs. OSI Model………………………………… 11
Format of the Primitive…………………………………………….. 12
SCCP Connection Establishment…………………………………...12
Signal Unit Formats
a.
Fill-in Signal Unit………………………………………….. 17
b.
Link Status Signal Unit…………………………………….. 17
c.
Message Signal Unit……………………………………….. 17
Routing Label Format……………………………………………… 18
Load Sharing…………………………………………….…………. 19
a.
Linkset…………………………………………….………...19
b.
Combined Linkset………………………………………….. 19
User Part Unavailable Message……………………………………..23
Message Handling………………………………………………….. 24
Selected Network Management Messages Formats
a.
Changeover Signal…………………………………………..29
b.
Changeback Signal………………………………………….29
c.
Transfer Prohibit/Restricted and Allowed Signals………….29
d.
Transfer Controlled Signal…………………………………. 29
Changeover/Changeback Procedure Flow………………………..... 29
Receive Buffer Congestion Thresholds……………………………. 32
General SCCP Message Format………………………………….... 34
SCCP Connectionless Service Message Formats
a.
Unitdata Message…………………………………………... 35
b.
Unitdata Service Message………………………………….. 35
GTT Translation Example………………………………………..... 36
Basic ISUP Call Setup…………………………………………….. 37
TCAP Call Setup……………………………………………………39
High Speed Links SS7 Protocol Stack……………………………... 41
AAL5 Common Part Data Units Formats………………………….. 42
SD PDU……………………………………………………………. 43
Signal, Primitive, and PDU Exchange for SSCOP Connection…….47
Network Map for Test Case 1……………………………………… 56
10% Initial Load Delay…………………………………………….. 60
20% Initial Load Delay…………………………………………….. 60
Network Map for Test Case 2……………………………………… 61
Cross-STP Delay for SSP 1 and SSP 2…………………………….. 62
Cross-STP Delay for SSP 3 and SSP 4…………………………….. 63
Cross-STP Delay for SSP 5 and SSP 6…………………………….. 63
v
List of Tables
2.1
2.2
2.3
5.1
5.2
5.3
Status Indication Values…………………………………………… 15
Signaling Information Octet Values
a.
Sub-Service Field Values..……………….………………… 16
b.
Service Indicator..……………….…………………………. 16
Heading Codes H0 and H1………………………………………… 30
STP Node Processing Time...……………………………………… 53
Link Output and cross-STP Delays……………………………….. 55
Performance………….…………………………………………….. 59
1
1.0
Introduction
In the last hundred years telephones have become a standard item in any home,
office and on the street. No one gives a second thought to the action of picking up a
receiver, dialing a number, and hearing a voice at the other end, with all the actions
occurring within less than a minute. Very few people realize the flurry of activities
occurring in that minute.
Consider this; raising the receiver produces a dial tone;
punching in a few numbers connects you to that one unique phone, perhaps a continent
away from you. What makes this possible?
In the early days of telephony you would first call an operator sitting at the
switchboard, give the operator the telephone number of the called party and upon
determining that the other end is free and available the operator would complete the
connection, allowing you to talk. Sounds good enough if there are a few thousand
possible connections, but what happens when the number grows to millions? When the
phone networks spans around the globe and you want to talk not only to your
grandmother in Cleveland but also to your business partner in Tokyo? The job of a
person at the switchboard becomes harder and less efficient. You would not be able to
talk to Tokyo immediately. If you are lucky, you might be able to do it in an hour,
perhaps longer. Waiting hours to complete one phone call in this information era? This
era would not have arrived if we still had people sitting at switchboard.
The process of establishing connections became automated, and in the place of a
switchboard, we now have electronic switches. Switches communicate with each other
using signaling messages traveling through the network.
There are two types of
signaling: in-band and out-of-band. Until 1986, the telephone network used in-band
2
signaling, carrying signaling data over the same voice trunks that would later carry the
corresponding conversation. This method gave a reasonable assurance that trunks would
be available and voice data would go through once the connection was established. The
problem was the trunks that between switches would be in use until released even if the
destination turned out to be unavailable. No other call would be able to utilize those
trunks even though they do not carry any actual conversation. In-band signaling for
telephone networks proved to be inadequate and out-of-band signaling was adopted
instead. Out-of-band signaling is signaling that does not take place over the same path as
the conversation.
Signaling System 7 (SS7) is the currently used standard for the telephone
signaling network. It uses common channel signaling, which is a “signalling method in
which a single channel conveys, by means of labeled messages, signalling information
relating to a multiplicity of circuits or calls and other information, such as that used for
network management [1].” It means that a separate network with its own nodes and links
was built to provide support to the conventional voice network. SS7 is a digital packet
switched network that can carry information about a number of calls over the same link
simultaneously. It is responsible for connection set up, control and tear down, as well as
routing and network maintenance.
With SS7, signaling can take place during the
conversation instead of only at the beginning.
An added benefit of the SS7 network and protocol is that when combined with
Intelligent Network (IN) or Advanced Intelligent Network (AIN) SS7 can support a
number of different services that can be implemented without any modification to the
network structure.
3
Each added service, however, generates increased message load, and it is vital for
the reliable and timely network performance that nodes can handle traffic offered to
them. To ensure this, SS7 is slowly migrating to higher speed links that can carry greater
loads at the same time, increasing the processing power of the network components.
Analysis of performance and development of the methods to conduct that analysis is one
of the factors that can help the network grow in a stable and reliable manner, preventing
both over engineering and under engineering.
In the following chapters, I provide a detailed overview of the SS7 architecture
and protocol as well as the test cases for performance testing with the corresponding
analysis and conclusions. Chapter 2 contains an overview of SS7 over low speed links.
Chapter 3 reviews SS7 protocol used over high speed links. Chapter 4 covers different
testing methods that can be applied to SS7. Chapter 5 describes test cases performed in
the course of the research, and finally, Chapter 6 states or conclusions reached after the
completion of research and testing.
4
2.0
Signaling System 7 Overview
Signaling System 7 (SS7) is a connectionless packet switched network made up of
a number of different Signaling Points (SP) interconnected with 56 kbps, 64 kbps, or
1.544 Mbps transmission links. The network is used to set up and tear down calls made
by user of the Public Switched Telephone Network (PSTN). In addition, it provides
access to various databases (800 numbers, for example) and Advanced Intelligent
Network (AIN) services, such as caller ID, conference calling, call forwarding and so on.
One of the most important features of the SS7 network is its reliability. Telephone
companies can ill afford to have network failures that would leave their customers
without telephone service. Since the PSTN cannot function without its backbone SS7
network, failure in providing signaling results in failure in the phone network’s ability to
support a call.
To assure consistent service, most nodes in signaling network are
duplicated and loaded in such a way that in case of a failure, the full load of one of the
nodes can be picked up by the remaining node. The same is true for signaling links
connecting the nodes.
2.1
SS7 Network Architecture
An SS7 network (example shown in Figure 2.1) is made up of different types of
nodes, each of which serves specific signaling functions. Each node has one or more
addresses, called point codes (PCs), associated with it. Nodes communicate with each
other over the connecting links using datagrams, the headers of which carry destination
PCs.
5
2.1.1 Service Switching Point
A Service Switching Point (SSP) is a local exchange switch that is used to convert
signaling received from the voice switch into SS7 signaling messages.
2.1.2 Signaling Transfer Point
A Signaling Transfer Point (STP) provides SS7 with the functionality of a router,
it routes messages through the network to their appropriate destinations. There are three
types of STPs:

National

International

Gateway
 Used to convert between protocols
Besides routing data, STPs gather measurements that can be used to monitor
traffic and network use. Examples of data acquired at the STP are peg counts, statistical
and maintenance information as well as message types.
Because of the high reliability requirements specified for the signaling network,
STPs are usually deployed in pairs called mated pairs.
The two mates are fully
redundant, and each one is expected to be able to assume the full load of its mate in case
of failure.
2.1.3 Service Control Point
A Service Control Point (SCP) is an interface into the phone company’s
databases. It is a computer that stores information related to one or more intelligent
network based services.
companies are:
Among the most common databases used by telephone
6
E
SCP
SCP
A
SSP
A
F
SSP
STP
STP
SSP
SSP
C
SSP
SSP
D
STP
STP
D
SSP
SSP
SCP
B
SCP
STP
SSP
SSP
Figure 2.1 SS7 Network Topology
SSP
7

800 Number Translations Database

Call Management Services Database (CMSDB)

Local Number Portability (LNP)

Line Information Database (LIDB)

Business Services Database (BSDB)

Home Location Register (HLR)

Visitor Location Register (VLR)
As the Advanced Intelligent Network (AIN) services become more widespread, databases
play an increasingly important role in the telephone network. They are a focus point of
the AIN services functionality.
2.1.4 Signaling Data Links
SS7 networks use bi-directional high speed (ATM, 1.5 Mbps) or low speed (DS0,
56 kbps/64 kbps) links to interconnect signaling points. Two signaling points connected
by one link are said to be adjacent. A collection of links that connect together the same
signaling points is called a link set and each link set can contain up to 16 separate links.
A group of link sets used to reach a particular destination is called a route and a
combination of routes that can be used to reach the same destination is called a route set.
While each link should be able to handle a full load, entities are set up to load
each link only up to 40% when operating under normal conditions. Even though the link
utilization suffers from such a setup, it allows for a greater reliability. In case of a link
failure the full load from a failed link can be safely transferred to the remaining links in a
linkset with no degradation of service as long as the load on each link does not exceed
80%.
8
Links employed in the SS7 network are divided into 6 different types depending
on which two network nodes are connected by the link. Each type has a maximum
allowed and a minimum required number of links in the linkset.

A-links
Access links connect together an SSP and an STP, or an SCP and an STP. They
provide access into the network and to the databases. Each linkset has at least one
and at most 16 A links supporting it.

B-links
Bridge links connect one mated STP pair to another mated STP pair at the same
hierarchical level (two pairs of regional STPs for example). B links are always
deployed in a quad configuration shown in Figure 2.2. There can be a maximum
of eight B links connecting the pairs.
Mated pair
Figure 2.2 STP Quad Configuration

C-links
Cross links connect STP mates together. They only carry user traffic in case of
congestion or network failure but usually are reserved for network management
messages. They are always deployed in pairs for redundancy, with a maximum of
eight C links between two STPs.

D-links
9
Diagonal links connect mated STP pairs at one hierarchical level to mated STPs at
another hierarchical level. They are deployed in the same fashion as B links.

E-links
Extended links are used to connect an SSP to a remote STP. They are used when
there is a significant amount of traffic going between the nodes to avoid
congestion.

F-links
Fully associated links connect two SSPs when there is either a large amount of
traffic between the two SSPs or when the SSPs cannot be connected through an
STP.
2.2
SS7 Protocol
The SS7 Protocol provides a set of rules controlling “the way data is transmitted
and received over the data communication (SS7) network [2].” The SS7 protocol stack
approximately maps to the OSI model, as demonstrated in Figure 2.3.
SS7 protocol is divided into 4 separate layers: physical, data link, network and
user parts. The first three layers together make up Message Transfer Part (MTP) that is
responsible for transmitting messages between signaling nodes. All SSPs and STPs
terminate MTP. For database transactions STP also terminates Signaling Connection
Control Part (SCCP). MTP and SCCP combined are referred to as Network Service Part
(NSP), which serves functions similar to those of the first three layer of the OSI. SSPs
also contain User Part layers that correspond to Application layer of the OSI model.
There are different user parts defined and implemented but not all of them have to be
present in a particular switch. For example, Broadband ISDN User Part (BISUP) is
10
defined to be used with ATM facilities and hence, it does not have to be implemented in
the switch that is only used with low speed links.
Similarly, Telephone User Part (TUP) is only used in international networks and
does not have to be included in switches inside the national network, which instead use
the ISDN User Part (ISUP).
2.2.1 Message Transfer Part
MTP combines in itself functions of the first three layers of the SS7 protocol
stack. It provides message handling and traffic management functions.

Layer 1 converts digital data into a bit stream transmission of the stream over the
network. It is defined for use with various interfaces, such as DS0 (64 kbps, bipolar
non-return-to-zero format) or V.35.

Layer 2 provides error detection/correction and sequenced delivery of signaling
messages on a link-by-link basis.

Layer 3 is responsible for message routing, discrimination, and distribution in
addition to performing network management functions, including link, route and
traffic management.
2.2.1.1 Primitives
Primitives are used to pass information between protocol layers. The format is
illustrated in Figure 2.4.

X marks the originator of the primitive, it can be either MTP or N (SCCP)

Generic Name defines the type of information provided by the layer. Each layer has a
number of different primitives associated with it.
11

Specific Name describes to the receiver the action that is to take place. There are four
types of primitives:

7
6
Request is used to invoke a service from the recipient of the primitive
Transport
OMAP
Presentation
TCAP
5
Session
4
Transport
3
Network
I
S
U
P
User
Parts
SCCP
3
Level 3
NSP
2
Data Link
2
Level 2
1
Physical
1
Level 1
Figure 2.3 SS7 Protocol Stack vs. OSI Model
MTP
12

Indication is returned by a peer entity to advice that a service had been invoked
by the user or service provider

Response is used to complete a transaction between layers

Confirmation informs the request-generating layer that the request has been
completely processed [3].
X
Generic Name
Specific Name
MTP-STATUS
Indication
Parameters
Example:
X
Affected DPC, Cause
Figure 2.4 Format of the Primitive
A detailed example of the use of all four types of primitives is shown in Figure 2.5,
where two entities are trying to establish an SCCP connection, used by a connectionoriented class of service.
4 pending
7
4 pending
User
1
SCCP
2
3
MTP
Entity 1
User
5
SCCP
6
MTP
Entity 2
Figure 2.5 SCCP Connection Establishment
1.
Setup is initiated by a calling user of Entity 1 with N-CONNECT.request, which
it sends to SCCP.
2.
SCCP reviews the request and after attaching protocol control information (PCI)
to it passes the primitive on to its peer in Entity 2 using underlying MTP.
13
3.
SCCP of Entity 2 recognizes the request and sends N-CONNECT.indication to
the appropriate user letting it know that a remote point is trying to establish a
connection.
4.
At this point the connection is pending at both ends.
5.
User issues an N-CONNECT.response telling SCCP that it approves the attempt.
6.
SCCP passes the response along through MTP to its peer in the other entity after
attaching PCI field.
7.
After receiving the primitive SCCP generates an N-CONNECT.confirmation to
its user, which at last completes the connection.
2.2.1.2 Signal Units
SS7 networks are packet switched networks, and information is passed between
nodes in packets called Signal Units (SUs). There are three types of SUs: Fill-in Signal
Unit (FISU), Link Status Signal Unit (LSSU) and Message Signal Unit (MSU). They
have similar formats, presented in Figure 2.6.

FISU (Figure 2.6a)
FISUs are used for continuous error checks on the link. Since user data usually
comes in bursts, if FISUs were not used, there would be periods of silence on the links.
In an event of a malfunction or a failure the condition would not be detected until a node
attempts to transfer some data. Use of FISUs guarantees early problem detection. They
are only sent when there are no other messages waiting for transmission, which means
that no resources are taken away from users.
Fields present in FISUs that are also used by LSSUs and MSUs are:

Frame Check Sequence (FCS)
14
SS7 uses CRC-16 for error detection. Upon receiving an SU, MTP compares
the calculated CRC against the one in the FCS field and if there is a
discrepancy, it is counted against the link.

Length Indicator (LI)
LI can be 0, 1, 2 or greater. It refers to the length in octets of the information
field. FISUs don’t contain information fields, so their LI is always set to 0.
Value of the LI is used to determine the type of the SU.

Forward Indicator Bit (FIB)/Backward Indicator Bit (BIB)
These two fields are used for acknowledgment purposes. There are set to the
same value, unless a negative acknowledgement is being sent. Then, the
value of BIB is toggled and message is sent back indicating request for
retransmission from the sending MTP Level 2.

Forward Sequence Number (FSN)/Backward Sequence Number (BSN)
To acknowledge a successfully received SU, BSN of the message being
transmitted is set equal to the FSN of the received SU. When negative
acknowledgement is being sent, BSN indicates the last good SU received and
all the messages at the other end with sequence numbers greater than BSN
will be retransmitted.

Flag
Flag is a fixed bit pattern, 1 octet long, used by Level 2 to determine the
boundaries of Signal Units. The opening flag of an SU serves as the closing
flag of the previous SU.

LSSU
15
LSSUs are used to indicate the status of a link between two adjacent signaling
points. Information is transferred in LSSUs using a Status Field (SF), which carries the
status of the link on which it is being transmitted. An SF can be 8 or 16 bits long,
producing LI value of 1 or 2, but only the first 3 bits of the first octet are currently being
used, the rest are set to zeros. The way the SF is divided is shown in Figure 2.6b. Table
2.1 contains the values and corresponding link status values that the Status Indication (SI)
portion of the SF can take.
SIO warns about the loss of alignment when the received Signal Unit violates
ones density or its Signaling Information Field (SIF) exceeds 272 bytes. SIN and SIE are
only used during the alignment procedure to indicate the length of proving period. SIOS
means that SP cannot receive or transmit any MSUs but there is no processor outage. It
is also used at the start of the alignment procedure. SIPO indicates that level two cannot
reach level 3 or 4. This condition stops the SP from transmitting any MSUs, which
means that only FISUs will be sent across the links between affected point and its
CBA
000
001
010
011
100
101
Status Indication
“O”: out of alignment
“N”: normal alignment
“E”: emergency alignment
“OS”: out of service
“PO”: processor outage
“B”: busy
Table 2.1 Status Indication Values
adjacent points. If the condition persists, realignment will occur. Finally, SIB is used to
indicate congestion at level two. An SP, when it receives an SIB, stops transmitting
MSUs and waits until the congestion has abated. After 3-6, seconds if the congestion did
not subside, level two notifies level three of a link failure. To prevent excessive delay of
16
acknowledgment timer (T7) from expiring and level three from initiating realignment,
SIBs are sent every T5 (80-120 ms) to reset T7. Still, if T6 expires indicating a long
congestion period alignment will be activated.
If a received LSSU contains an error, it is not retransmitted but the error is
counted against the link.

MSU
MSUs are used to transmit user data and all the information other than what is
transmitted in the LSSUs.
There are two information fields in the MSU, Service
Indicator Octet (SIO) and Signaling Information Field (SIF). SIO is used to determine
the protocol at the User Part level the message is destined to and the version of the
protocol used, national or international. Two portions of the SIO are illustrated in Figure
2.6c with the values listed in Table 2.2.
DC BA
00 xx
01 xx
10 xx
11 xx
International Network
Spare
National Network
Reserved for national use
a. Sub-Service Field
DCBA
0000
0001
0011
0100
0101
0110
0111
Protocol
Signaling Network Management
Signaling Network Testing (SNT)
SCCP
Telephone User Part (TUP)
ISUP
Data User Part(DUP), call and circuit related
DUP, facility registration and cancellations
b. Service Indicator
Table 2.2 Signaling Information Octet Values
17
Level 2
FCS
16
F
I
B
LI
2
6
B
I
B
FSN
1
7
Opening
Flag
BSN
1
7
8
Direction of
transmission
a. Fill-in Signal Unit
Level 2
FCS
16
Level 3
SF
8 or16
Spare
Level 2
2
LI
F
I
B
6
1
B
I
B
FSN
7
1
BSN
Opening
Flag
7
8
Direction of
transmission
Status Indications
b. Link Status Signal Unit
Level 2
Level 3 and above
FCS
SIF
16
8n, n>2
Sub-Service
Field
Management or User Information
Level 2
SIO
8
LI
2
Service Indicator
Routing
Label
c. Message Signal Unit
Figure 2.6 Signal Unit Formats
6
F
I
B
1
FSN
7
B
I
B
1
BSN
7
Opening
Flag
8
Direction of
transmission
18
The SIF field contains upper layer data, including a Routing Label. The SIF can
be of variable length, between 3 and 252 octets. The value of LI greater than two means
that the SU being transmitted is an MSU. The Routing label (Figure 2.7) is 56-bits long
and consists of three fields: Destination Point Code (DPC), Origination Point Code
(OPC), and Signaling Link Selection (SLS).
SLS
8
OPC
DPC
24
24
Network
Identifier
Network Cluster
Network Cluster
Member
8
8
8
Figure 2.7 Routing Label Format
DPC contains the point code of the destination signaling point, while OPC
contains the point code of the sender. They have the same format and each is 24 bits
long. The fields that make up a point code are: Network Identifier (NI), Network Cluster
(NC), and Network Cluster Member (NCM). Network Identifier can either directly
identify the network to which the point code belongs or it can contain one of the escape
codes, which were designed to increase the available number of different networks that
can be addressed. The 8-bit length of the NI field allows for a maximum of only 256
different values. When one of reserved values used for escape code is placed in the NI
field, NC is used to determine the network for which the message is intended. The
combination of NI, NC and NCM uniquely identifies a signaling point.
The SLS field is used for load balancing, i.e., to enable all the available links in a
link set to carry equal loads. Load can be shared between links in the same link set or in
a combined link set, as illustrated in Figure 2.8.
19
Link set
SLS = XXXXXXX0
SLS = XXXXXXX1
a. Linkset
SLS = XXXXXXX0
Link set
SLS = XXXXXXX1
b. Combined Linkset
Figure 2.8 Load Sharing
2.2.1.3 Detailed View of Level 2 Functions
Level 2, being a Data Link Layer, makes sure that packets flow across a correctly
functioning link between two adjacent points in an orderly, sequential manner, with no
loss of data. It is the level charged with monitoring the performance of a link and taking
appropriate actions in case of malfunction or failure.
The assigned duties of this layer are:

Signal Unit delimitation
This function is performed using a unique 8-bit pattern, flag (01111110), to
indicate the boundaries of a signal unit. Most of the time each SU has only one
opening flag, which acts as a closing flag for the previous SU. Nevertheless, an
SP should be able to handle the case when it receives two or more consecutive
flags. To prevent the flag pattern from appearing in the information field of a
signal unit, bit stuffing (inserting 0 after 5 consecutive 1s) is used before flags are
20
attached to the SU. Upon receiving an SU, MTP level 2 strips the flags and
removes 0s following five consecutive ones.

Signal unit alignment acceptance
Detects events indicating a possible loss of alignment that occurs when ones
density violation is detected (more than 7 consecutive ones received), the length
of a signal unit exceeds 272 bytes indicating the loss of a flag, or the signal unit’s
length is not a multiple of 8. Any of these events prompts a change in the error
monitoring function.

Signal unit error detection
Errors are indicated either by a discrepancy in the FCS field with the CRC-16
computation performed by the recipient or by sequence number errors.

Signal unit error correction
There are two error correction methods: “basic method” (for terrestrial
transmissions), which is more efficient, and retransmits the errored SU and all
SUs with sequence numbers following it, and “preventive cyclic retransmission
method” (for satellite transmissions), which keeps retransmitting all SUs in the
buffer until it receives an acknowledgement.

Signaling link error monitoring
Separate monitors are used when a link is in service, and during the link proving
period:

Signal Unit Error Rate Monitor (SUERM) is used when a link is in service.
21
It keeps a counter, which is incremented with every error, and decremented by
one every 256th signal unit received without an error. When the counter
reaches 64, the link is taken out of service and realigned.

Alignment Error Rate Monitor (AERM)
This monitor is used during the link proving period. A counter is incremented
with every error detected, and alignment is restarted if too many errors are
detected.

Signaling link alignment
Alignment can be performed both when the link is first brought into service and
when the link is being restored after a failure. It follows the set procedure [4]:

State 00 – idle
The procedure is suspended

State 01 – not aligned
Time-out timer T2 is associated with this state. The link is not aligned and the
SP sends SIO to the adjacent node.

State 02 – aligned
The link is aligned and SINs or SIEs are sent but the signaling point is not
receiving SINs, SIEs, or SIOS.
Decision whether to perform normal or
emergency alignment depends solely on MTP Level 3.

State 03 – proving
Validates link’s ability to carry traffic by sending FISUs over the link for T4
period. Expiration of T4 signals successful ending of proving, except when
proving had failed up to four times before.
22

Aligned/ready state
Lasts for T1 period to allow the remote end to perform four alignment
attempts.

In Service
Whenever the alignment is aborted, the signaling point returns into the idle
state and restarts the procedure.

Flow control
Flow control function is used to notify the sender of the congestion status at the
receiving end using the SIB LSSU. The sender should stop transmitting MSUs
until congestion has abated or, in case of an excessive congestion period, until
after successful alignment.
2.2.1.4 Detailed View of Level 3 Functions
Level 3 functions are divided into Signaling Message Handling and Signaling
Network Management functions, whose functions are in turn divided as follows:

Signaling Message Handling (SMH)
SMH is responsible for making sure messages originating at a User Part in one
entity are delivered to the corresponding User Part in the entity the message is
intended for (as indicated by the DPC), regardless of whether the nodes are
directly connected.

Message Discrimination
Determines whether the message is destined to the User Part in this entity, in
which case, the message is passed on to Message Distribution; if not, and the
23
SP has message routing capability, the message is transferred to Message
Routing.

Message Distribution
Determines which User Part the message should be handed to based on the
information in the SIO field of an incoming MSU.
If the User Part is
unavailable a “user part unavailable (UPU)” (Figure 2.9) message is generated
to the originator of the message indicating that the message was discarded.
UPU contains a CAUSE field that lists the reason the message could not be
delivered to the destination:
FCS
CAUSE
 User
Part function was not equipped at the destination
 User
Part function was not accessible
 User
Part function could not be reached for an unknown reason
User ID
Destination
H1
H0
Routing
Label
SIO
LI
FIB
FSN
BIB
BSN
Figure 2.9 User Part Unavailable Message

Message Routing
Message Routing determines which link an incoming message should be
routed toward in order to reach the destination. Routing is done based on the
routing label and can either be full point code routing or partial point code
routing, which includes cluster and network routing. The route is determined
by a lookup of the routing table, which is set up by the network administrator.
The routing table indicates outgoing links or link sets corresponding to
various destinations. The routes listed can include a primary route and a
Flag
24
number of alternate routes arranged in order of priority. The routing function
should pick the best route marked as available from the list of multiple routes.
The flow of traffic between message handling functions is illustrated in Figure 2.10.
User Parts or
Network Management
Distribution
MTP3
SMH
internal
Routing
external
incoming
outgoing
Discrimination
MTP Level 2
Figure 2.10 Message Handling

Signaling Network Management (SNM)
In case of link failure or congestion, SNM ensures that the network adapts to
handle the changes. There are a number of procedures defined with each SNM
function to make sure the data keeps flowing even in the presence of
malfunctions.

Signaling Traffic Management
Diverts traffic from failed or congested links/routes/SPs to links/routes/SPs
that are still available. It employs the following procedures:
1. Changeover
The Changeover procedure is initiated when a link (or a link set) becomes
unavailable due to a failure, blocking or inhibition. Traffic is rerouted to an available
25
link (picked from the routing table) in the same link set, in a combined link set or to a
completely different route, which might not be a preferred route. The goal of this
procedure is to ensure the traffic keeps flowing with messages arriving at the destination
in proper order without any losses and also without any negative effect on the traffic
already flowing on the link used for rerouting. The procedure also retrieves messages not
yet received by the other end of the failed link, and retransmits these messages on the
new route.
Changeover-order (COO) and changeover-acknowledgement (COA) signals are
used during the changeover procedure. They are transferred as a part of an MSU with
information included in the SIF field, as shown in Figure 2.11a. Spare bits are set to 0s
for low speed links and are used with some messages on 1.536 Mbps links, i.e. they are
used to accommodate a longer FSN in COO [5]. Heading codes are listed in the Table
2.3.
2. Changeback
The changeback procedure is used when a previously unavailable link becomes
available, and traffic can be return to its normal route. The changeback signal (CBD),
containing a changeback code as shown in Figure 2.11b, is used to perform the
procedure. The remote end confirms its acceptance of the procedure via a changebackacknowledgement signal (CBA). The flow and timing of the messages exchanged during
changeover/changeback procedures are shown in Figure 2.12.
3. Forced rerouting
26
Forced rerouting takes place when an SP receives a transfer-prohibited (TFP)
message indicating that a certain destination has become unavailable on a given route.
Traffic will be rerouted to a new route picked from a routing table.
4. Controlled rerouting
Controlled rerouting is initiated upon receipt of a transfer-allowed (TFA) or a
transfer-restricted (TFR) message by a signaling point. A TFA is generated when a
previously unavailable route to a destination is recovered and, a TFR message is
generated when there is a route still available to a destination but it is not a preferred
route.
5. MTP restart
MTP restart is used when a node has been isolated from the network for a period
of time and is then restored. The procedure allows the node to bring up some of its links,
sufficient to support some traffic load, before actually starting to transfer any traffic.
This protects the node from being overwhelmed by user data and going back down again
because not enough links were made available.
6. Management inhibiting
This procedure is used by the administrator during maintenance or testing and
does not take the link out of service. It remains available for network management
messages. The node can refuse the link to be inhibited if it affects the availability of the
destinations or during congestion.
7. Signaling traffic flow control
Signaling traffic flow control ensures that a node does not generate traffic that the
network cannot handle in the presence of some network failures or congestion.
27

Signaling Link Management (SLM)
Manages the status of links, activating idle links and restoring failed links by
initiating the alignment procedure, and deactivating aligned links when
needed. For example, if the number of available links exceeds the allowed
limit (a link set should contain a maximum of 16 links) extra links should be
deactivated. The SLM procedures are:
1. Signaling link activation, restoration, and deactivation
Both the link activation of a previously inactive link, and the restoration of a
failed link, go through two stages: initial link alignment and link test. In both cases,
measures are taken to prevent the link from oscillating between in-service and out-ofservice states by preventing the link from being brought into service upon failure if the
failure occurred before a corresponding timer expired.
2. Link set activation
The link set activation procedure is used when a link set contains no functioning
links in it. Either “normal” or “emergency restart” activation can take place. Emergency
restart is used when the normal procedure is deemed to be too slow; for example, the case
when activation of the link set will make a previously unavailable signaling point
accessible.
3. Automatic allocation of signaling terminals and signaling data links

Signaling Route Management
Distributes information about the status of the network and the availability of
routes using the following procedures:
1. Transfer-prohibited procedure
28
A signaling node initiates the transfer-prohibited procedure to notify its neighbors
nodes about its inability to route messages to a certain signaling point or cluster. The
format of transfer-prohibit (TFP) message is shown in Figure 2.11c. The reception of a
TFP message may set off forced rerouting procedure, and, in turn, generate additional
TFP messages.
2. Transfer-allowed procedure
When a route through a signaling node to an affected SP becomes available,
transfer-allowed (TFA) messages are issued to adjacent nodes, which might return
previously diverted traffic to its normal route and notify other nodes of the route
availability through TFA messages. The TFA has the same format as a TFP.
3. Transfer-restricted procedure
With the help of transfer-restricted (TFR) messages, a node notifies its adjacent
nodes that, if possible, they should use a different route to reach a specified destination.
The procedure is invoked if a node has to use a lower priority alternative route to reach
the destination or when the employed route experiences congestion. In the first case
upon switching from the preferred to an alternate route, the node starts timer T11, and
when the timer expires, broadcasts TFR messages to all adjacent routes. Also, if the
route is in the danger of being congested, the node issues TFR messages in response to
receiving a message directed to the concerned destination. The format of TFR messages
is illustrated in Figure 2.11c.
4. Signaling-route-set-test procedure
The procedure is used to test the current availability of the destination and a node
invokes it upon receiving a TFP or TFR message from the adjacent node. Route-set-test
29
FSN of last
accepted MSU
SLC
H1
H0
7
4
4
4
5
Routing Label
56
a. Changeover Signal
Changeback
Code
SLC
H1
H0
8
4
4
4
4
Routing Label
56
b. Changeback Signal
Destination
24
H1
H0
4
4
Routing Label
56
c. Transfer Prohibit/Restricted and Allowed Signals
Status
6
2
Destination
24
H1
H0
4
4
Routing Label
56
d. Transfer Controlled Signal
Figure 2.11 Selected Network Management Messages Formats
SP A
SP B
Link 1 fails
COO (link2)
Start T2
Traffic diverted
to link 2
COA
Traffic flows over link 2
Link 1
restored
Start T4
Traffic diverted
back to link 1
Traffic will be diverted either
when COA is received or
when T2 expires.
CBD
CBA
Traffic flows over link 1
If T4 expires before CBA is
received CBD is transmitted
again and T5 starts. Traffic
will not be diverted until CBA
is received.
Figure 2.12 Changeover/Changeback Procedure Flow
30
DCBA
Signal Codes
H0
0001
Changeover and
changeback
0010
Emergency changeover
0011
TFC and RSCM
0100
TFP, TFA, and TFR
DCBA
0001
0010
0011
0100
0101
0110
0001
0010
0010
0001
0001
0010
0101
0110
0011
0100
0001
0101
Signaling-route-set-test
0110
Management inhibiting
0111
Traffic restart
1000
Signaling-data-linkconnection
1010
MTP user flow control
0010
0011
0100
0001
0010
0011
0100
0101
0110
0111
1000
0001
0010
0001
0010
0011
0100
0001
Table 2.3 Heading Codes H0 and H1
Signal Codes
H1
Changeover order
Changeover acknowledgment
Extended changeover order
Extended changeover acknowledgment
Changeback declaration
Changeback acknowledgment
Emergency changeover order
Emergency changeover acknowledgment
Transfer-controlled
Signaling-route-set-congestion-test
Transfer-prohibited
Transfer-cluster-prohibited
Transfer-allowed
Transfer-cluster-allowed
Transfer-restricted
Transfer-cluster-restricted
Signaling-route-set-test for prohibited
destination
Signaling-route-set-test for restricted
destination
Signaling-route-set-test for prohibited cluster
Signaling-route-set-test for restricted cluster
Link inhibit
Link uninhibit
Link inhibit acknowledgment
Link uninhibit acknowledgment
Link inhibit denied
Link force uninhibit
Link local inhibit test
Link remote inhibit test
Traffic restart allowed
Traffic restart waiting
Signaling-data-link-connection-order
Connection-successful
Connection-not-successful
Connection-not-possible
User part unavailable
31
(RSM) messages are sent every T10 and upon receiving one, signaling node
compares the status in the message to the current status of the route. It they are the same,
no action is taken, otherwise TFA, TFP, or TFR may be sent as appropriate.
5. Transfer-controlled procedure
Transfer-controlled (TFC) messages (Figure 2.11d) are used to prevent the adjacent
nodes from sending traffic below or equal to a specified priority in order to prevent
message discard. The priority set in the TFC message refers to the congestion status. It
ranges between 0 and 3 with zero indicating no congestion. Transmit buffers at the nodes
are designed in such a way that they go through different levels of congestion as they are
filled with messages (Figure 2.13).
Congestion status is set to zero if the buffer
occupancy is below engineered normal level. As the buffer fills up, congestion status
reflects the value of the highest congestion onset level crossed (i.e., if the current buffer
occupancy were between n and n + 1 congestion onset thresholds, congestion status
would be n.) Congestion abatement thresholds associated with each level are set below
the corresponding onset level, and, for n = 1, above normal occupancy level. Message
discard n thresholds are located before the n + 1 congestion onset threshold, to achieve
greater congestion control. As congestion abates and buffer use decreases, congestion
status changes in the opposite direction. With each n congestion abatement threshold
crossed, status value becomes n-1.
Actual threshold values are implementation
dependant [Ibid.].
6. Signaling-route-set-congestion-test procedure
32
Signaling points use signaling-route-set-congestion-test messages to determine
the current congestion status of the link in order to decide whether messages with a given
priority will be delivered to the specified destination.
L3 message
discard
L3 congestion
abatement
L2 congestion
onset
L1 message
discard
L1 congestion
abatement
input
L3 congestion
onset
L2 message
discard
L2 congestion
abatement
L1 congestion
onset
Normal
occupancy
Figure 2.13 Receive Buffer Congestion Thresholds
2.2.2 Signaling Connection Control Part
Signaling Connection Control Part (SCCP) enables signaling points to perform
database transactions. Each SP employed in the national SS7 network, including STPs
that do not support any Level 4 capabilities, should terminate this part. It provides SPs
with ability to perform end-to-end signaling and allows STPs to do Global Title
Translation (GTT).
SCCP is defined to perform both connection-oriented and connectionless services
divided into four protocol classes:
Class 0: basic connectionless
Class 1: sequenced (MTP) connectionless
Class 2: basic connection oriented
Class 3: flow-controlled connection oriented
Currently only classes 0 and 1 (connectionless services) have been implemented
by most equipment vendors.
Connection-oriented services, if implemented, would
require set up and tear down of a connection.
Parts of this process had been
demonstrated during the discussion of primitives (Section 2.2.1.1).
33
Class 0 is used for pure connectionless transfer of messages when the originator
does not care whether messages are delivered in sequence or not, since each message is
independent of its predecessors. Class 1 offers an option of requesting that messages
coming from the same source be delivered in sequence, in which case all messages
corresponding to the same stream would be assigned the same SLS field value. When
SCCP messages of class 1 are routed through the network, every node should ensure that
the sequence of messages is maintained, barring the unexpected occurrences of errors,
network failures, or congestion.
A number of different messages are defined for use in various SCCP procedures.
The general format for all SCCP messages is shown in Figure 2.14. Messages are
divided into groups based on which class of service (connection-oriented or
connectionless) uses the messages. For example Connection Request (CR) or Release
Complete (RLC) are only used with classes 2 and 3. To transfer data between users in
class 0 and 1 services, SCCP uses Unitdata (UDT), Extended Unitdata (XUDT), and
Long Unitdata (LUDT) messages. Since SCCP uses underlying MTP layers to transfer
the data, and MTP may discard messages under certain conditions, if the user wants to be
notified about messages getting dropped with the reason for the discard, it would have to
set “Return Option” in the primitive for SCCP. In this case Unitdata Service (UDTS) (or
Extended or Long Unitdata Service) messages would be returned when discard occurs.
UDT and UDTS messages contain the routing label, three pointers and parameters
as shown in Figure 2.15. Message type is “0000 1001” for UDT and “0000 1010” for
UDTS. Protocol class in UDT can be 0 or 1. Called Party Address (CPA) and Calling
Party Address (CgPA) both have the same general format except that CgPA may contain
34
7
6
5
4
3
2
1
0
Routing Label
Message Type Code
Mandatory Parameter A
…
Mandatory Parameter F
Mandatory
fixed
part
Pointer to Parameter M
…
Pointer to Parameter P
Pointer to Optional Part
Length Indicator of Parameter M
Parameter M
…
Mandatory
variable
part
Length Indicator of Parameter P
Parameter P
Parameter Name = X
Length Indicator of Parameter X
Parameter X
…
Parameter Name = Z
Length Indicator of Parameter Z
Parameter Z
End of Optional Parameters
Figure 2.14 General SCCP Message Format [6]
Optional
part
35
7
Octet 1
6
1
5
4
3
1
2 -252
2 or greater
3 or greater
1
1
Data
Calling Party
Address
Called Party
Address
Protocol
Class
Message
Type
2
1
0
Standard
Indicator
Point Code
Indicator
Global Title Indicator
SSN
Indicator
Address Indicator
Octet 2
…
Routing
Indicator
octets
1
1
4
1
Address
Octet n
7
6
1
5
4
3
1
2
1
0
Subsystem Number
Signaling Point Code
Global Title
a. Unitdata Message
Data
Calling Party
Address
Called Party
Address
Return
Cause
Message
Type
2 -252
2 or greater
3 or greater
1
1
b. Unitdata Service Message
Figure 2.15 SCCP Connectionless Service Message Formats
1
36
fewer fields. Address Indication Octet contains directions on which addressing method
should be used for routing:

Set Subsystem Number (SSN) Indicator means SSN is included in Address Field

Set PC Indicator means PC is included in Address Field

Global Title Indicator can assume three states
0000 no Global Title
0001 GT includes translation type, numbering plan and encoding scheme
0010 GT includes translation type
When GT is used SSN is set to “0000 0000” before the translation.

Routing Indicator 0 means routing should be done using GTT, 1 means routing
should be done using DPC and SSN

Standard indicates whether national or international addressing format is used
An example of messages, with corresponding parameters, exchanged between entities in
the GTT process is shown in Figure 2.16.
OPC = X
DPC = Y
GT routing
AIO: 1000 1001
GT = 800-Nxx-Nxxx
SSN = 0
CgPA = X
TCAP: 800 translation
GTT translation
STP
SSP
X
Y
OPC = Y
DPC = Z
SSN routing
AIO: 1100 1011
GT = 800-Nxx-Nxxx
SSN = 254
CgPA = X
TCAP: 800 translation
SCP
Z
OPC = Z
DPC = X
No GTT required
TCAP: NPA-Nxx-Nxxx
Figure 2.16 GTT Translation Example
Transaction Capabilities Application Part (TCAP) primarily uses SCCP as described in
section 2.2.4.
37
2.2.3 ISDN User Part
ISDN User Part (ISUP) is used for call setup/teardown services. An example is
procedure illustrated in Figure 2.17.
Phone 1 is trying to establish a voice connection with Phone 2 at (516)555-9721. Using
Dual Tone Multifrequency (DTMF) signaling Phone 1 supplies the address of the
destination (Phone 2) to its local office. SSP uses ISUP messages sent over the signaling
links to reserve the trunks for the call. The final destination is resolved step-by-step and
routed according to the dialed digits coded based on location of the phone.
SSP4
SSP1
SSP3
5
ring
3
1
3
DTMF
Signaling
Phone 1
301-555-3864
IAM
ACM
ANM
IAM
8
7
response
6
Phone 2
516-555-9721
2
ACM
ANM
4
Voice Trunk
SSP2
Signaling Link
Figure 2.17 Basic ISUP Call Setup
1. SSP1 recognizes that code 516 is not its local code and sends Initial Address Message
(IAM) to the SSP2, whose code is 516.
38
2. SSP2 accepts the IAM but determines that it does not terminate trunks to the 555
phones so it sends IAM message to SSP3. As IAMs pass between SSPs, trunks that
would be used during the voice call get reserved, but at this point they are still
unused.
3. SSP3 looks at the last four digits and recognizes the address of the phone; it response
with an Address Complete Message (ACM) to SSP2.
4. SSP2 informs SSP1 that address had been resolved successfully by sending it an
ACM message.
5. At this time SSP3 alerts Phone 2 to the fact that somebody is trying to establish a call
by sending it a RING signal.
6. When the receiver of the phone is picked up the response is generated. SSP3 notes
that the loop was complete and current is flowing between TIP and RING, indicating
that the Phone 2 is ready to participate in the call.
7. SSP3 generates an Answer Message (ANM) towards SSP2.
8. SSP2 passes the ANM to SSP1 and SSP1 completes the call setup.
9. At this point Phone 1 and Phone 2 are connected and can communicate over the voice
trunks.
2.2.4 Transaction Capabilities Application Part
Transaction Capabilities Application Part (TCAP) messages are used to invoke
calls with services, such as 800 and 888 number, Local Number Portability and other
services. The procedure is illustrated in Figure 2.18.
A local SSP receives a dialed 800 number from a phone. It transfers the number
to the STP for GTT translation. After querying its local SCP, STP determines that the
39
number belongs to a long distance carrier. The information is returned to the local SSP,
which then transfers the number to a long distance SSP. The procedure of translating the
address repeats with long distance Signaling Points until the number is resolved to be
(516)555-1278. From that point the call gets completed in the same manner as a basic
ISUP call.
SCP
STP
STP
SSP
SSP
800-555-4400
Local Carrier
Long Distance
Long distance carrier
SCP
800-555-4400
STP
Local Carrier
800-555-4400
516-555-1278
SSP
Signaling links
Voice trunks
800-555-3480
Figure 2.18 TCAP Call Setup
STP
SSP
SCP
ring
516-555-1278
40
3.0
SS7 Over ATM
A boost in demand for SS7 network resources resulted from the addition of
various AIN services, and an increase in the number of customers. This prompted the
development of a high-speed interface that can handle the extra SS7 load. Asynchronous
Transfer Mode (ATM) was chosen to be this interface. SS7 was adapted to function in
the new ATM environment.
To allow SS7 to be transmitted over ATM without losing any of the functions
built into the signaling system required adding an intermediate Signaling ATM
Adaptation Layer (SAAL) between ATM layer and MTP layer 3 to emulate MTP 2.
3.1
SS7 over High Speed Links Protocol Details
Since ATM layers used to substitute MTP Levels 1 and 2 were designed for a
packet switched connection oriented network, in contrast to connectionless narrowband
SS7 network, provisions had to be made to adopt the signaling points to a new mode of
operation without losing any of the functions stipulated by the requirements for SS7. The
new protocol stack (Figure 3.1) introduces layers and sublayers that take on the tasks
previously performed by the eliminated MTP levels.
The User Parts layer, independent of underlying layers of the protocol stack,
communicates with MTP 3.
Since MTP3 did not undergo any major changes to
accommodate the high-speed links (HSLs), the migration from low speed links to HSLs
is transparent to the User Parts. Since MTP2/MTP1 were replaced by SAAL/ATM/T1,
the latter will be the main focus of discussion here.
41
SSCS
SSCF
User Parts
ATM
AAL5 CP
SAAL
AAL5 CPCS
Layer Management
SSCOP
MTP Level 3
AAL5 SAR
T1
Figure 3.1 High Speed Links SS7 Protocol Stack
3.1.1 AAL5 Common Part
ATM Adaptation Layer 5 (AAL5) Common Part (CP) is divided into two parts.
AAL5 Segmentation and Reassembly (SAR) sublayer is responsible for fragmenting the
Protocol Data Units (PDUs) received from upper layer (Figure 3.2) into ATM cells and
for reassembling received cells back into complete PDUs. An ATM cell contains 48
bytes of data and 5 bytes of header information. When a PDU is delivered to the SAR
layer, it is divided into 48-byte-long chunks that are then placed in the payloads of the
cells. Next, the ATM layer attaches a header with routing information and the complete
cell is passed on to the Physical layer for transmission.
AAL5 Common Part Convergence Sublayer (AAL5 CPCS) is responsible for
error detection. Since the length of the data unit used with high speed links could be
greater than in LSL SS7, 32 bits are used for error detection instead of 16. CPCS PDU
also contains information about the length of data field, User to User (UU) information
42
field, and Pad of variable length used to ensure that the PDU is a multiple of 48 bytes, for
ATM cell payload insertion.
AAL5 CPCS PDU
AAL5 CPCS SDU
AAL5 CPCS
AAL5 SAR
4
2
1
1
CRC - 32
Length
Rsvd
UU
Information
Field
Pad
Information
Field
48
Data
Information
Field
48
ATM
1-65,535
0-47
48
…
Information
Field
48
Header
5
Figure 3.2 AAL5 Common Part Data Units Formats
3.1.2 Service-Specific Connection Oriented Protocol
Service-Specific Connection Oriented Protocol (SSCOP) in addition to
performing regular functions of MTP Level 2, such as sequence integrity, error
correction, flow control and transfer of user data, performs connection control function
and reports errors to Layer Management (LM).
Sequence integrity is kept at the SSCOP sublayer by means of a sequence number
field N(S) in the Sequenced Data PDUs (Figure 3.3) and POLL and STAT/USTAT
PDUs. Before being transmitted, each PDU is assigned a 24-bit-long sequence number,
which is then used by the destination to either acknowledge the receipt of a valid PDU or
to inform the sender that the received PDU contained an error. The source verifies the
delivery of PDUs by generating POLLs to the destination at regular intervals of
43
Timer_POLL. When the destination receives a POLL, it issues a STAT in response.
STAT provides the sender with the sequence number of the PDU the receiver is
expecting to receive next, VR(R). VR(R) indicates that every PDU with a sequence
number smaller than or equal to VR(R) has been received successfully. In case PDUs are
received out of order (one or more PDU in a sequence is missing), the destination issues
an unsolicited STAT (USTAT) containing the sequence numbers of the missing PDUs.
This mechanism provides for error correction using selective retransmissions and unlike
in MTP2, only the missing PDUs will be retransmitted instead of all the PDUs with
sequence numbers greater than that of the negatively acknowledged PDU.
1
2
3
4
Data
Pad (0-3 octets)
PL
8
1
Rsvd
7
6
PDU type
N(S)
5 4 3 2 1
Figure 3.3 Sequenced Data (SD) PDU [7]
SSCOP performs flow control on a peer-to-peer basis using a credit mechanism.
The receiver provides the transmitter with a window size indicating the number of PDUs
that can be transmitted without waiting for an acknowledgement in the form of a range of
sequence numbers that will be accepted by the receiver. The mechanism works as
follows:
The receiver keeps three counters [8]:
1. VR(R) is next expected sequence number (all PDUs with smaller sequence
numbers have been received and acknowledged)
44
2. VR(H) is the highest expected sequence number (the highest sequence number
received so far is VR(H)-1)
3. VR(MR) is the highest sequence number that will be accepted by the receiver
The granted credit thus is [VR(R), VR(MR)-1]; any PDU with a sequence number
outside of this range will be discarded.
The transmitter also keeps three counters [Ibid.]:
1. VT(A), which is equal to the VR(R), contained in a STAT/USTAT
2. VT(S) is the next sequence number to be transmitted
3. VT(MS) is the highest sequence number that can be transmitted based on the
granted credit
If VT(S) is equal to the VT(MS), then the credit is zero and transmitter cannot
send any PDUs to the destination. When this situation occurs, Timer_NO-CREDIT is
started at the transmitter, and if no credit is granted before the timer expires, SSCOP
informs LM of the event and the link is subsequently taken out of service.
An aspect of SSCOP is that it is connection-oriented. Upon request from an
upper layer protocol, SSCOP exchanges PDUs with the peer entity to establish a
connection. PDUs used for this task are BGN, BGAK and BGREJ. The last one is used
if for some reason the peer is not able to start the connection. In this case the originator
keeps transmitting BGN PDUs until it either receives BGAK or the timer T2, started with
initial connection establishment attempt, expires. BGNs are sent in groups of size set by
the MaxCC parameter; BGNs within a group are sent every Timer_CC; T1 intervals
separate each group. Since all these parameters are user configurable, SSCOP will
ng 
T2
Timer _ CC  MaxCC  T 1
45
transmit groups of BGN PDUs before giving up. The connection gets established when
the peer issues an acknowledgment, and it stays up until one of the entities request a
termination. When there is no actual exchange of data, POLL/STAT transfers are used as
“heart beats” to keep the connection alive. END and ENDAK PDUs are exchanged to
tear down the connection. These procedures involve additional interaction inside the
entity both between SAAL sublayers, and between SAAL and the higher layer, with
details provided in subsequent sections.
3.1.3 Service-Specific Coordination Function
Service-Specific Coordination Function (SSCF) participates in procedures of two
types: with no peer-to-peer messages and with peer-to-peer messages. In the former case,
SSCF maps SSCOP signals into primitives that can be understood by MTP level 3,
provides links status information to both the SSCOP and MTP3 layers, does flow control
within the node based on the four congestion levels defined in MTP 3 section. SSCF also
provides LM with information concerning the current status of SSCOP connection and
participates in the failure detection procedure by informing LM about the number of
errored PDUs. Peer-to-peer functions include emulation of the LSSU functionality of
MTP2. (For example: out of service, processor outage, normal/emergence alignment,
etc.)
Another procedure where SSCF plays a key role is alignment. SSCF participates
in the procedure by informing local LM of the detected errored PDUs and by providing
the peer with the status of the local entity. The message flow, including the details on
exchanged primitives and active timers, used during alignment is provided in Figure 3.4.
46
Alignment gets initiated by an MTP 3 in a request type primitive [9, 68]. In
response SSCF issues a PDU to its peer and then progresses through alignment states
until the “In Service” state is reached. In the process, SSCF cycles through the “Proving”
state that requires close cooperation with the LM. Similar to the LSL MTP 2 procedure,
SSCF generates a number of proving messages, and if the error monitor located at LM
does not indicate excessive number of detected errors, a primitive gets issued to LM
requesting the end of proving and a PDU is transmitted to the SSCF peer informing it of
the success of the procedure. A positive acknowledgment of this PDU places SSCF in
service.
3.1.4 Layer Management
SSCS relies on Layer Management to provide support for error monitoring,
measurements, processor outage, and link quality determination during alignment and
link operation [10]. LM makes decision about successful or failed alignment basing it on
the applicable error-monitoring tools. LM processes information supplied by the SSCOP
and SSCF about the detection of errored PDUs and the status of SSCOP connection and
then signals of the appropriate action to be taken. In addition to participating in the
alignment procedure described in 3.1.2 and illustrated in Figure 3.4, LM has the authority
to initiate emergency alignment, in which case proving period does not take place. This
option exists in order to prevent link oscillation. Upon bringing the link into service LM
starts a timer and if the same link goes out of service before the timer expires, emergency
alignment is used.
Layer Management keeps track of statistics pertaining to each link: time in
service, number of failures, presence of congestion, and number of congestion threshold
47
crossings, and so on [9, 71]. This information is vital for OAM functions, and smooth
performance of SSCS.
Entity A
MTP
Entity B
SSCOP
SSCF
AAL-START.req
SSCOP
SSCF
MTP
AA-ESTABLISH.req
BGN
AA-ESTABLISH.ind
MAAL-REPORT.ind
AA-RELEASE.res
BGREJ
AA-RELEASE.ind
MAAL-REPORT.ind
AA-ESTABLISH.req
T1 expires
BGN
AA-ESTABLISH.ind
Start Alignment
AA-ESTABLISH.res
AA-ESTABLISH.conf
MAAL-PROVING.ind
BGAK
AA-DATA.req
T3 expires,
C1>0
SD
AA-DATA.ind
POLL
AA-DATA.req
T3 expires,
C1>0
AA-DATA.req
SD
AA-DATA.ind
SD
AA-DATA.ind
Timer_POLL
T3 expires,
C1>0
Proving
POLL
STAT
Restart
Timer_NO-RESPONCE
…
AA-DATA.req
MAALSTOP_PROVING.ind
T3 expires,
C1=0
SD
AA-DATA.ind
AAL-IN_SERVICE.ind
MAAL-REPORT.ind
SD
AAL-IN_SERVICE.ind
Aligned Ready
AA-DATA.ind
MAAL-REPORT.ind
I n Service
Data
MAAL-STOP.req
AA-RELEASE.req
END
MAAL-REPORT.ind
AA-RELEASE.conf
AA-RELEASE.ind
ENDAK
LM
Figure 3.4 Signal, Primitive and PDU Exchange for SSCOP Connection
Connection
Tear Down
LM
48
4.0
Testing Methods
Most products require testing before they are made available to the customer. It is
especially true for any electronic equipment, above all one that supports vitally important
communication networks. Before any telephony equipment is deployed into the field, it
has to be thoroughly tested, assuring both the ability of the given piece of equipment to
perform its task reliably and accurately and its ability to work with equipment already in
the field.
Each SS7 node, of the types described in details in the previous chapters, is
subject to rigorous testing before being deployed in a Central Office. The goal of testing
is to minimize potential failures during network. Specifically, we tested equipment
compliance with standard protocols. There are three aspects for standards compliance
testing: conformance, interoperability and performance.
4.1
Conformance Testing
Conformance testing compares a new implementation to a standard specification.
In other words, after applying a certain set of inputs to entity, the tester expects a
predetermined response consistent with the protocol specifications. Conformance testing
treats each System Under Test (SUT) as an “isolated entity [11]”; external inputs are
generated by a simulator and the responses get captured by a monitor. Specifically an
SS7 entity is being subjected to conformance testing, the tester tries to determine whether
the SS7 protocol stack implemented performs as per the SS7 protocol specifications. For
example, Signaling Transfer Point (STP) that had received a Transfer Prohibited (TFP)
message should start transmitting route-set-prohibit-test (RSP) messages with parameters
consistent with a TFP message. Protocol layers communicate with each other through
49
defined primitives. Since primitives themselves cannot be observed, they are assumed to
be implemented correctly if the corresponding messages are generated appropriately.
Test plans for conformance testing are designed so that each primitive and each
message defined in the protocol are tested. Different procedures, from link alignment to
output buffer congestion and various network failures, should be tested. Conformance
testing also includes tests for alarms, such as congestion threshold alarms, operation
support systems and user interfaces. After each test on the list is run there is an assurance
that the entity performs according to the specifications. However, this fact does not
imply that this entity will be able to interoperate with other entities in the network since
each standard can produce slightly different implementations. The next section describes
interoperability testing.
4.2
Interoperability Testing
Different implementations of the same protocol are similar to two people
speaking the same language with slightly dissimilar accents. But unlike the case with
human interaction, for interworking it’s important that both protocol flavors understand
each other exactly despite the discrepancies, since any variations might result in network
failures.
Interoperability testing makes sure protocols from different vendors can talk to
each other in a consistent manner. Such testing assumes each entity conforms to the
protocol; so the goal of these test cases is to create interaction between different
implementations and confirm that network integrity is preserved despite any differences
in implementations.
50
As with conformance testing, interoperability testing involves applying input
signals to a system under test and monitoring the results. Unlike conformance testing,
interoperability testing requires the system under test to interact with another real
network element. In case of SS7 STP testing, most often a quad configuration of two
mated pairs from different vendors is used. Each pair subtends its own cluster of SSPs
and/or SCPs.
For more extensive testing, i.e., to produce a setting more closely
resembling a real network, it is possible to have products from more than just two
vendors.
Input signals are applied to cause message exchange, requiring STPs to
communicate with each other. For example, a D link failure test should result in the
changeover procedure. The node that first detected the failure transmits a COO and
expects to receive a COA. Another example is the notification of a far end about a route
failure through a TFP message, with an expected response of periodic RSP messages. A
test run of these two examples would allow a tester to determine whether two vendors’
STPs recognize each other’s messages and consequently invoke the correct procedures.
Interoperability testing is targeted at creating an environment where equipment
from different vendors can prove their ability to seamlessly interoperate. In the course of
working on this thesis, I took part in the interoperability testing with the results reported
in [11].
4.3
Performance Testing
It can be argued that in the case of SS7 implementations performance testing is a
part of the conformance-testing suite since requirements for performance are specified in
protocol documents along with the rest of the standard. However, we treat this form of
testing as separate since the processing capacity of STPs are often not determined by
51
customer testing. Instead vendor-provided numbers are usually accepted. The speed
with which an STP can process each message it receives, and the number of messages it
can process in a given time, was not considered critical.
With widespread
implementation of AIN services, concerns for STP performance may become greater as
more calls will require additional signaling; for example database accesses and GTT
translations.
Performance can be of a particular concern to SS7 gateways, which are mostly but
not always used to connect separate networks. SS7 gateways are STPs with a gateway
screening function, a process in which an STP examines the contents of incoming
messages and determines whether the message should be accepted or rejected (i.e.,
whether it is authorized or not) based on criteria specified by network administration. The
gateway screening process allows network administrators to control the flow of SS7
messages into or through a signaling network. If a message is accepted, it is passed to the
MTP (for routing and distribution) or SCCP to perform GTT. If a message is rejected, it
is discarded.
The gateway screening process involves a sequence of “screening steps” similar
to packet filtering in IP networks. Gateway screening is provisioned on a per link basis
hence, the same set can be used on multiple links or a different set can be used for
individual links. The advantage of this is that you can tailor the screening set to reflect
the agreement between individual users (other service providers) of your network. The
fields in an SS7 message that may be checked during the screening process are:
• MTP Parameters:

Originating Point Code (OPC)
52

Destination Point Code (DPC)

Service Information Octet (SIO)

Affected Destination in MTP Network Management messages.
• SCCP Fields:

Calling Party Address (CgPA)

Message Type (UDT, XUDT, etc.)

Called Party Address (CdPA) (including Translation Type)

Affected Point Code/Subsystem Number (PC/SSN) in SCCP Management
messages.
• ISUP Parameters:

Message Type (e.g., IAM, ACM, etc.)
When gateway screening is activated, an STP may be faced with a situation,
where each processed message requires screening based on multiple fields at each layer
then followed by GTT. While at the moment this scenario may seem farfetched there is a
growing interest for smaller independent companies connecting their networks to larger
phone networks. For security reasons each message at the point of connection might
require both a screening check as well as GTT translation associated with some AIN
service. An STP’s performance in such environment becomes important, and methods
for testing STP performance should be developed.
53
5.0
Test Cases for STP Performance Testing
STP performance can be defined using either STP node processing time or cross-
STP delay as a criteria.
cross-STP delay = link output delay + processing time, where
link output delay = queuing delay + message emission time
Link output delay does not depend on STP implementation since both of its components
are functions of traffic mix and message lengths, therefore STP node processing time is
the parameter of interest for performance testing [13].
Performance requirements for STPs terminating low speed links are specified in
[Ibid]. They are listed in Table 5.1 with requirement R9-9 being defined as:
R9-9 The observed STP node processing time values shall be less than or
equal to the corresponding STP node processing time values in Table 93, regardless of the traffic mix or type of STP processing required on
the individual messages.
STP Node Processing
Loading
Time (ms)
Mean
95%
Normal (40%)
43
 79
Failure (80%)
80
 202
Table 5.1 STP Node Processing Time
The implications of the cited requirement are that regardless of whether each message
processed by STP can be simply routed based on OPC/DPC or whether each message has
to go through a screening process and GTT, the delay observed should not exceed the
specified values. Thus, a good setup for a test to verify SUT’s compliance to R9-9 would
be to run three different types of mixes through an STP:
1.
Pure ISUP messages with OPC/DPC routing
2.
A random combination of ISUP/TCAP messages with some GTT required
54
3.
All TCAP messages with each message requiring a significant amount of
processing.
For cases two and three, gateway screenings can be used to generate additional load on
STP processors. The three test cases mentioned above would create a clear picture of STP
performance under various traffic conditions.
However, the available testing environment imposed certain limitations that had
to be taken into account when implementing test cases for performance testing. In
addition to not having resources to create optimally diverse loads, the monitoring and
measuring equipment also limited the types of measurements taken.
The MGTS
(Message Generation Test System) does not measure link output delay and STP node
processing time separately since these delays cannot be separated without monitoring
internal interfaces of STPs. It only provides value for cross-STP delay, which in this case
is defined as “the delay time in milliseconds for MSUs from transmission time to receive
time [14].” MSUs used for this delay measurement are special test MSUs, generated by
the SSP-NPLT (Network Performance Load Testing) package. Each test MSU has an ID
assigned to it by the originating node before transmission; when the destination receives
such an MSU it generates a response with the same ID and sends it back to the source.
Thus, the originator can calculate the cross-STP delay as half of the round trip time
experienced by the test MSU:
cross-STP delay = (receive time – transmit time)/2
It is evident that this calculation does not subtract the time it takes for the MGTS to
process the time-stamped MSU before determining whether an acknowledgement should
be generated. It also does not account for any possible discrepancy between messages
55
traveling in opposite directions; for example, the acknowledgment could encounter
longer delays than the original messages or vice versa. The final result produced by the
MGTS gives the average delay experienced by many test MSUs over a period of time of
the experiment.
Table 5.2 contains values for link output delay and cross-STP delay. Link output
delay values were computed using following criteria: lower bound contain 15-octet-long
messages only, typical message was assumed to be 120 octets long, and upper bound was
for 279 octets messages. For a traffic consisting of a mix with different message lengths,
delays would fall within the boundaries. Normal link occupancy is considered to be 0.4
Earlang, and failure conditions are for 0.8 Earlang of traffic on the link [13]. Cross-STP
delay, then, is the sum of values from Table 5.1 and corresponding link output delays.
These values are of an interest for this study since the results obtained during testing
include link output delays.
Range
Lower Bound
Typical
Message
Upper Bound
Loading
Normal
Failure
Normal
Failure
Normal
Failure
Link output delay
Mean
95%
3
6
7
17
23
40
52
118
55
102
122
310
cross-STP delay
Mean
95%
46
82
87
211
66
106
132
271
98
155
202
422
Table 5.2 Link Output and cross-STP Delays
The following two sections contain test cases for limited STP performance
testing, including test setup, description and results.
56
5.1
Test Case 1
Configuration: Figure 5.1
A2-0
A2-1
246-3-1
SSP1
A1-0
STPA
246-242-0
SSP 2
246-3-2
SSP 3
246-3-3
SSP 4
246-3-4
SSP 5
246-3-5
SSP 6
246-3-6
A2-2
A2-3
A2-4
Figure 5.1 Network Map for Test Case 1
System Under Test: Tekelec Eagle STP, Release 26
Purpose: To obtain cross-STP delay values for performance testing
Description: Traffic flowed through STP A from SSP 1 towards SSPs 2 to 6 and back.
SSP 1 was programmed to send traffic randomly to the rest of the SSPs while SSP 2 – 6
transmitted traffic exclusively to SSP 1. STP A performed traffic routing between the
SSPs. To obtain a distribution of delay values, load toward SSP 1 was varied in two
ways: SSPs were programmed to generate individual loads in the range between 0.1 to
0.8 Erlangs and the number of simultaneously transmitting SSPs changed at each test
step. Consequently, depending on how many SSPs were activated and on the load
programmed for those SSPs, traffic processed by the STP ranged from 10 to 400 percent.
Since SSPs 2 through 6 were programmed to send traffic only to SSP 1 the load on links
A2-0 through A2-4 in the direction of STP A was the programmed load (10, 20, 40 or
57
80%). Link A1-0 in the direction from STP A contained a composite load, all the traffic
generated by SSP 2 to 6 and processed by the STP.
Traffic Mix: Consisted of test MSUs of length varying from 20 to 200 bytes.
Results: The performance numbers in Table 5.3 were calculated using the Traffic
Reports generated by the MGTS for the load on A1-0 towards SSP 1. Each column in the
table is described below:
Load (%):
is the sum of individual loads generated by each SSP2-6.
It is not
necessarily the load on A1-0 since with increasing traffic, the STP drops a
certain number of MSUs.
#MSUs TX: is the total number of test MSUs generated by SSPs 2 through 6 destined
for SSP1. It does not include the MSUs generated by these SSPs for
management purposes.
#MSUs RX: is the total number of test MSUs received by SSP1.
Loss (%):
the percentage difference between the number of test MSUs transmitted to
SSP1 and the number of MSUs actually received.
Average Delay (ms): cross-STP delay for test MSUs. This number in the Traffic Report
is composed of the emission delay and processing delay.
Emission _ delay 
message _ length  8bits
link _ rate
Example
Emission _ delay 
150bytes  8bits
 21.4ms
56kbps
58
Since all the SSPs were emulated by the same MGTS (which means the same
clock was used for timing) to verify the average delay numbers in the Traffic Reports, the
same message was captured twice, first when it was transmitted from SSP 1 and then at
its arrival at SSP 2. Traffic load was kept at 10% during this test step. Forward
Sequence Number (FSN) and Backward Sequence Number (BSN) fields were used to
make sure the same message was captured both on egress and ingress.
The MSU with FSN 7 (Appendix A) was transmitted by SSP 1 (OPC 246-3-1) at
00:01:20.423 and received by SSP 2 (OPC 246-3-2) at 00:01:20:432. It took 9 ms for
this message to get processed by the STP without taking into account negligible link
output delays. This number proved to be consistent with data obtained from the Traffic
Report.
Highlighted portions in the table indicate the loads at which the number of
transmitted MSUs is grossly different from the number of received MSUs.
The
discrepancy is due to two factors: output buffer overflow at the STP, which was indicated
by the Transfer Control (TFC) messages, seen on the links coming from STP to SSPs 2-6
and A1-0 link overload (it cannot handle over 80% total load in one direction). Figures
5.2 and 5.3 demonstrate average delays experienced by messages transmitted to SSP 1
and from SSP 1 with different traffic loads offered to the STP. The line reflecting delays
for messages delivered from SSP 1 to SSP 2 shows very small variance, which is due to
the fact that messages of varying length were being transmitted. At instances when
greater number of short messages was transmitted, the experienced delay would be
slightly smaller, and vice versa. Taking this fact into an account, the line produced by
SSP 1 to SSP 2 cross-STP delay values can be considered to be a flat line, even under
59
100% link load. This observation gives the proof that the high loads did not affect STP
processing and the increasing delays observed at higher loads for the opposite direction
were due to the link congestion.
 Load*
(%)
10
20
30
40
50
20
40
60
80
100
40
80
120
160
200
80
160
240
320
400
*Note:
# MSUs TX
# MSUs RX
Loss (%)
Avg. Delay (ms)
289
612
864
1166
1568
572
1142
1720
2294
2917
1133
2313
3881
4975
7652
2200
4625
7140
9114
12403
289
612
863
1168
1568
571
1140
1719
2293
2838
1133
2314
3007
3133
3900
2200
2532
2512
2437
2647
0.00
0.00
0.12
0.00
0.00
0.17
0.18
0.06
0.04
2.71
0.00
0.00
22.52
37.03
49.03
0.00
45.25
64.82
73.26
78.66
11.07
13.47
15.33
17.00
21.43
11.82
16.30
23.00
30.18
40.09
14.24
28.76
39.10
37.97
37.46
24.29
36.51
36.03
36.17
37.34
 Load is a sum of individual loads from SSP2-6.
Table 5.3 Performance
60
10% Initial Load Delay
from SSP2 to SSP1
from SSP 1 to SSP2
25
21.43
Delay (ms)
20
17
15.33
15
13.47
11.07
10
10.6
9.48
10.75
9.1
8.9
40
50
5
0
10
20
30
Load (%)
Figure 5.2 10% Initial Load Delay
20% Initial Load Delay
from SSP 2 to SSP1
from SSP1 to SSP2
45
40.09
Delay (ms)
40
35
30.18
30
25
20
15
10
5
23
16.3
11.82
8.42
8.57
9.02
8.36
9.55
20
40
60
80
100
0
Load (%)
Figure 5.3 20% Initial Load Delay
61
5.2
Test Case 2
Configuration: Figure 5.4
246-2-1
246-2-2
SSP 1
A1
A3
246-2-3
A2
STPA
A4
SSP 3
246-2-4
SSP 4
A5
246-2-5
SSP 2
246-242-0
A6
SSP 5
246-2-6
SSP 6
Figure 5.4 Network Map for Test Case 2
System Under Test: Tekelec Eagle STP, Release 26
Purpose: To obtain cross-STP delay values for performance testing
Description: To eliminate the output buffer bottleneck experienced in Test Case 1,
SSPs were programmed to exchange traffic in the following manner: SSP 1  SSP 2,
SSP 3  SSP 4, SSP 5  SSP 6. Loads produced by each SSP ranged from 0.1 Erlang
to 1 Erlang, with 0.1 Erlang increase at each test step. Therefore, the largest load
experienced by the STP in each direction was 3 links each operating at full (100%) load.
Traffic Mix: Test MSU with fixed length of 150 bytes.
Results: The delays experienced by the MSUs were not only consistent with the results
acquired in the previous test case but also significantly below the threshold set by the R99 requirement. Even with links loaded at 100%, the maximum delay observed was under
50ms. As can be seen from Figures 5.5 through 5.7 delay increases after 0.7 Erlang was
applied to each link. The figures below also compare delays for traffic in opposite
directions. Traffic Reports containing depicted values are given in Appendix B. From
the graphs there seems to exist some kind of relationship between the delays in opposite
62
directions, however there is no discernable reason why the relationship would exist. One
explanation could be that the same processor was used to transfer messages from port
connecting link A2-1 and port connecting link A1-1 in both directions. In this case, the
processor busy with handling one direction would neglect for a short period messages
arriving from the other direction, letting them accumulate in the input buffer, thus adding
to the delay.
cross-STP Delay for SSP1 and SSP2
SSP1
SSP2
42.25
45
40
41.42
Delay (ms)
35
30
26.03
25
18.18
20
15
10
13.53
13.74
13.33
13.85
14.4
12.8
13.48
13.17
11.05
11.51
10.8
11.29
10
20
30
40
11.9
19.11
14.76
11.75
5
0
50
60
70
Load (%)
Figure 5.5 Cross-STP Delay for STP 1 and STP 2
80
90
100
63
cross-STP Delay for SSP3 and SSP4
Delay (ms)
SSP3
50
45
40
35
30
25
20
15
10
5
0
SSP4
43.49
40.74
23.88
13.26
13.77
13.15
13.39
13.1
12.43
10.79
12.14
12.15
40
50
14.32
13.78
13.8
10.79
10
10.94
11.08
20
30
60
21.41
17.18
70
80
90
100
Load (%)
Figure 5.6 Cross-STP Delay for STP 3 and STP 4
cross-STP Delay for SSP5 and SSP6
SSP5
SSP6
50
46.42
Delay (ms)
45
40
37.75
35
30
25.19
25
20
15
10
20.39
14.56
13.74
13.53
11.89
11.64
11.8
12.63
12.83
12.82
11.34
12.19
11.24
50
60
20.11
14.18
12.97
16.25
5
0
10
20
30
40
70
Load (%)
Figure 5.7 Cross-STP Delay for STP 5 and STP 6
80
90
100
64
6.0
Conclusion
The Signaling System 7 (SS7) network plays a crucial role in the functionality of
the Public Switched Telephone Network (PSTN).
Inter-switch calls would not be
completed if Service Switching Points (SSPs) could not exchange signaling messages.
Therefore, to ensure consistent and reliable service, the SS7 architecture was developed
with built-in redundancy where most important nodes, such as Signal Transfer Points
(STPs) and databases, are deployed in pairs or even quads. The SS7 protocol also
embeds in its layered structure multiple error checks and procedures to prevent or quickly
recover from any link, hardware, or software failure. The importance of consistent
service even extends to the data links, whose load is engineered to not exceed forty
percent under normal conditions. In case of link failures, this “over engineering” allows
remaining links to pick up the load from failed links with no loss of data. SS7 provides
more than “best-effort service” end-to-end message delivery.
In the network that places a high value on reliability, performance is also of great
importance. Over years of telephone service availability, users have become accustomed
to connection delays of mere seconds. To meet customers’ expectations, response time
should not increase with increase of signaling traffic resulting from constantly added new
services. Traffic keeps increasing because more and more transactions performed in the
network require at least one database access. Examples of services that have led to the
increase in signaling traffic are Advanced Intelligent Network (AIN) services, Local
Number Portability (LNP), etc.
Most messages that flow through the network pass through at least one STP,
which takes care of routing and network management. It is imperative, then, that the STP
keeps up with offered traffic. Insufficient speed of the STP processor can make the node
a bottleneck that would result in performance degradation. STP processing power will
become of an even greater concern once SS7 networks have been upgraded with High
Speed Links (HSLs). With HSL interconnected nodes, traffic will flow through links at
65
the rate of 1.544 Mbps as opposed to the current 56 kbps. In that environment line speed
or almost wire speed processing becomes critical.
The goal of tests carried out in this project was to determine whether STPs that
are currently deployed in the field are able to provide consistent cross-STP delay for high
volumes of traffic. The laboratory environment forced certain limitations on the extent
and accuracy of the performed tests. Possible improvements to the tests are listed along
with the test results and analysis. The collected data allows to draw a conclusion that the
System Under Test, Tekelec® Eagle™ STP (Release 26), does satisfy current network
requirements. Performance curves, presented in Chapter 5, show that observed delays are
below the corresponding numbers listed in the specifications defined for STPs deployed
in SS7 networks. Continuous upgrades with newly available technology should keep the
SS7 network flexible and reliable so that the service it offers remains consistent and
reliable.
66
Acronyms
AAL
ACM
AERM
ANM
ATM
BIB
B-ISDN
B-ISDN-UP (B-ISUP)
BSN
CBA
CBD
CCS
CO
COA
COO
CP
DPC
DUP
ECA
ECM
ECO
ERR
FIB
FISU
FSN
H0
H1
IAM
ISDN
ISDN-UP (ISUP)
L1
L2
L3
L4
LATA
LI
LSB
LSLA
LSLD
LSLR
LSSU
MSB
MSU
MTP
NACK
ATM adaptation layer
Address complete message
Alignment error rate monitor
Answer message
Asynchronous transfer mode
Backward indicator bit
Broadband integrated services digital network
Broadband integrated services digital network
Backward sequence number
Changeback acknowledgment signal
Changeback declaration signal
Common channel signaling
Connection-oriented
Changeover acknowledgment signal
Changeover-order signal
(AAL) common part
Destination point code
Data user part
Emergency changeover acknowledgment signal
Emergency changeover message
Emergency changeover order signal
Protocol data unit error
Forward indicator bit
Fill-in signal unit
Forward sequence number
Heading code
Heading code
Initial address message
Integrated services digital network
Integrated services digital network user part
Level 1 (physical/electrical interface)
Level 2 (signaling link functions)
Level 3 (signaling network functions)
Level 4 (e.g., ISDN user part)
Local access and transport area
Length indicator
Least significant bit
Signaling link activation
Signaling link deactivation
Signaling link restoration
Link status signal units
Most significant bit
Message signal unit
Message transfer part
Negative acknowledgment
67
NI
NNI
OA&M
OMAP
OPC
OSS
PDU
PSTN
QRY
RCP
RCR
RCT
REL
RLC
RSM
RSP
RSR
SAAL
SCCP
SCP
SDU
SF
SI
SIB
SIE
SIF
SIN
SIO
SIOA
SIOS
SIPO
SLC
SLM
SLS
SLTA
SLTC
SLTM
SMH
SP
SPC
SPDU
SRM
SS7
SSCF
SSCOP
SSF
Network Indicator
Network node interface
Operation, administration and maintenance
Operations, Maintenance and Administration Part
Originating point code
Operation support system
Protocol data unit
Public Switched Telephone Network
Query
Signaling-route-set-test cluster-prohibited signal
Signaling-route-set-test cluster-restricted signal
Signaling-route-set-congestion-test signal
Release message
Release complete message
Signaling-route-set-test message
Signaling-route-set-test prohibited signal
Signaling-route-set-test restricted signal
Signaling ATM adaptation layer
Signaling connection control part
Service Control Point
Service data unit
Status field
Service indicator
Status indication "B" ("Busy")
Status indication "emergency alignment"
Signal information field
Status indication "normal alignment"
Service information octet
Status indication "out of alignment"
Status indication "out of service
Status indication "processor outage"
Signaling link code
Signaling link management
Signaling link selection code
Signaling link test message acknowledgment
Signaling link test control
Signaling link test message
Signaling message handling
Signaling point
Signaling point code
Session protocol data unit
Signaling route management
Signaling system no. 7
Service specific coordination function
Service specific connection oriented protocol
Sub-service field
68
SSN
SSP
STP
SU
SUERM
TB
TC
TFP
TFR
TUP
UDT
UDTS
UP
VC
VCC
VCI
VPC
Subsystem number
Service Switching Point
Signaling transfer point
Signal unit
Signal unit error rate monitor
Transmission buffer
Transaction capabilities
Transfer-prohibited signal
Transfer-restricted signal
Telephone user part
Unitdata message
Unitdata service message
User part
Virtual channel
Virtual channel connection
Virtual channel identifier
Virtual path connection
69
Appendix A
70
71
Appendix B
10%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
269
0
269
0
269
0
269
0
269
0
269
-TIME STAMPEDTX
RX
267
0
267
0
267
0
267
0
267
0
267
267
0
267
0
267
0
267
0
267
0
267
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
14.56
0.00
13.74
0.00
11.05
0.00
13.53
0.00
13.26
0.00
10.79
DIFF
MISRTE
RX
AVG ACK
DLY-MS
1
0
1
0
1
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
11.89
0.00
11.64
0.00
13.74
0.00
11.51
0.00
10.94
0.00
13.77
20%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
558
0
558
0
558
0
558
0
558
0
558
-TIME STAMPEDTX
RX
556
0
556
0
556
0
556
0
556
0
556
555
0
555
0
555
0
555
0
555
0
555
30%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
781
0
780
0
781
0
-TIME STAMPEDTX
RX
779
0
779
0
779
0
779
0
779
0
779
0
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
0
0
0
0
0
0
0
0
0
0
11.80
0.00
13.53
0.00
10.80
0.00
72
7
8
9
10
11
780
0
781
0
780
779
0
779
0
779
779
0
779
0
779
0
0
0
0
0
0
0
0
0
0
13.33
0.00
13.15
0.00
11.08
DIFF
MISRTE
RX
AVG ACK
DLY-MS
1
0
1
0
1
0
1
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
12.63
0.00
11.34
0.00
13.85
0.00
11.29
0.00
10.79
0.00
13.39
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
12.19
0.00
12.83
0.00
11.90
0.00
14.14
0.00
13.10
0.00
12.14
DIFF
MISRTE
RX
AVG ACK
DLY-MS
-1
0
-1
0
0
0
0
0
11.24
0.00
12.82
0.00
40%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
1325
0
1325
0
1325
0
1325
0
1325
0
1325
-TIME STAMPEDTX
RX
1322
0
1322
0
1322
0
1322
0
1322
0
1322
1321
0
1321
0
1321
0
1321
0
1321
0
1321
50%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
4276
0
4276
0
4276
0
4276
0
4276
0
4276
-TIME STAMPEDTX
RX
4270
0
4270
0
4270
0
4270
0
4270
0
4270
4270
0
4270
0
4270
0
4270
0
4270
0
4270
60%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
2984
0
2984
0
-TIME STAMPEDTX
RX
2981
0
2981
0
2982
0
2982
0
73
5
6
7
8
9
10
11
2984
0
2984
0
2984
0
2984
2981
0
2981
0
2981
0
2981
2982
0
2982
0
2982
0
2982
-1
0
-1
0
-1
0
-1
0
0
0
0
0
0
0
11.75
0.00
12.80
0.00
12.15
0.00
12.43
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
12.97
0.00
14.18
0.00
13.17
0.00
13.48
0.00
13.80
0.00
14.32
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
16.25
0.00
20.39
0.00
14.76
0.00
18.18
0.00
17.18
0.00
13.78
DIFF
MISRTE
RX
AVG ACK
DLY-MS
0
0
20.11
70%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
4672
0
4672
0
4672
0
4672
0
4673
0
4672
-TIME STAMPEDTX
RX
4668
0
4668
0
4668
0
4668
0
4669
0
4668
4668
0
4668
0
4668
0
4668
0
4668
0
4668
80%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
2367
0
2367
0
2367
0
2367
0
2367
0
2367
-TIME STAMPEDTX
RX
2365
0
2365
0
2365
0
2365
0
2365
0
2365
2365
0
2365
0
2365
0
2365
0
2365
0
2365
90%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2731
-TIME STAMPEDTX
RX
2729
2729
74
2
3
4
5
6
7
8
9
10
11
0
2731
0
2731
0
2730
0
2731
0
2730
0
2729
0
2729
0
2728
0
2729
0
2728
0
2730
0
2729
0
2729
0
2729
0
2729
0
-1
0
0
0
-1
0
0
0
-1
0
0
0
0
0
0
0
0
0
0
0.00
25.19
0.00
19.11
0.00
26.03
0.00
21.41
0.00
23.88
DIFF
MISRTE
RX
AVG ACK
DLY-MS
-1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
37.75
0.00
46.42
0.00
41.42
0.00
42.25
0.00
40.74
0.00
43.49
100%
TIME-STAMPED MSU SUMMARY
PORT
TOTAL
TX
1
2
3
4
5
6
7
8
9
10
11
2792
0
2794
0
2794
0
2794
0
2794
0
2794
-TIME STAMPEDTX
RX
2790
0
2792
0
2792
0
2792
0
2792
0
2792
2791
0
2792
0
2792
0
2792
0
2792
0
2792
75
References
[1]
Bellcore: Bell Communications Research Specification of Signaling System
Number 7, GR-246-CORE, T1.110.10, Glossary-1, Issue 3, December 1998
[2]
Russell, Travis: “Signaling System 7,” 2nd edition, McGraw-Hill, 1995
[3]
Bellcore: Bell Communications Research Specification of Signaling System
Number 7, GR-246-CORE, T1.110.1, 4-6, Issue 3, December 1998
[4]
Bellcore: Bell Communications Research Specification of Signaling System
Number 7, GR-246-CORE, T1.113.3, Issue 3, December 1998
[5]
Bellcore: Bell Communications Research Specification of Signaling System
Number 7, GR-246-CORE, T1.111.4, Issue 3, December 1998
[6]
Bellcore: Bell Communications Research Specification of Signaling System
Number 7, GR-246-CORE, T1.112.3, Issue 3, December 1998
[7]
American National Standards Institute: B-ISDN ATM Adaptation Layer – Service
Specific Connection Oriented Protocol (SSCOP), T1.637, 16, 1994
[8]
Bellcore: Generic Requirements for CCS Nodes Supporting ATM High-Speed
Signaling Links (HSLs), GR-2878-CORE, Issue 3, December 1998
[9]
Black, Uyless D., “ISDN and SS7: Architectures for Digital Signaling
Networks,” Prentice Hall, 1st edition, 1997
[10]
American National Standards Institute: B-ISDN Signaling ATM Adaptation Layer
– Layer Management for the SAAL at the NNI, T1.652, 1, 1996
[11]
M. Malek, S. Dibuz: “Pragmatic Method for Interoperability Test Suite
Derivation”, Proc. 24th Euromicro Conference, pp. 838-44, 1998
[12]
R. Badri, et al: Methodology for Analysis of STP Test Results, May 15, 2000
[13]
Bellcore: Signaling Transfer Point (STP) Generic Requirements, GR-82-CORE,
9-8, Issue 2, Revision 2, 1998
[14]
Tekelec: “CCS7/MGTS User Manual,” December 1998