90
AUTOMATING SS7 STP INTEROPERABILITY TEST RESULTS ANALYSIS
THESIS
Submitted in Partial Fulfillment
of the Requirements for the
Degree of
MASTER OF SCIENCE (Electrical Engineering)
at the
POLYTECHNIC UNIVERSITY
by
Ramesh Badri
October 2001
Approved:
______
Co-Advisor Advisor
______
Date Date
______
Department Head
______
Date
Copy No. _____
Vita
January 25, 1978 ……………………………….. Born – Hyderabad, India
July, 1995 - June, 1999 ………………………… B. Tech. Electrical Engg., Indian
Institute of Technology, Madras, India
August, 1999 – October, 2001 …………………. M. S. Electrical Engineering,
Polytechnic University, Brooklyn, NY
Acknowledgments
I would like to thank my advisor Dr. Malathi Veeraraghavan for giving me an opportunity to work on this project. I also thank her for all that I learnt from her in the past two years. I would also like to thank my co-advisor Dr. Tim Moors for all the time he spent discussing and improving this work. I would also like to record my sincere thanks to the other members of the project team, Jeff Tao, Xuan Zheng, and Tao Li. The project was made possible by a CATT (Center for Advanced Technology in Telecommunication) research contract funded by Verizon Communications. Many documents that were used to develop the thesis were provided by Verizon. However, these being proprietary, they are not explicitly referenced in the thesis. I would finally like to thank Verizon Communications for allowing us to use their Systems Integration and Testing lab at Silver Spring to gather data to test our software.
AN ABSTRACT
AUTOMATING SS7 STP INTEROPERABILITY TEST RESULTS ANALYSIS
by
Ramesh Badri
Advisor: Malathi Veeraraghavan
Co-Advisor: Tim Moors
Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Science
(Electrical Engineering)
October 2001
The Public Switched Telephone Network (PSTN) uses a protocol standard called Signaling System Number 7 (SS7) for signaling and to provide features like 800 number calls, credit card authentication, caller I.D., wireless roaming services etc. SS7 is a packet switched network and the datagram switches in SS7 networks are called Signaling Transfer Points (STPs). STPs are maunfactured by a number of vendors, each issuing a new software release almost every year. Before a new STP is deployed, it has to be tested to verify that it can function correctly as a part of the network consisting of other STPs. This testing is termed STP interoperability testing and is usually performed manually. Manual testing leads to a slow deployment of the STPs in the field and prevents the service provider from offering services based on the new features quickly. Manual testing is also cumbersome and error-prone. Testing consists of four phases: setting up the test configuration, executing the test steps, retrieving the test results and analyzing the test results. This thesis considers the task of automating the analysis of STP interoperability test results. We develop an analysis methodology suitable to be automated and implement this methodology in software. The analysis involves comparing the actual behavior of the STPs in response to the tests with their expected behavior as per the specifications. The software is written in the programming language Perl and is called ASTRA (Automated SS7 Test Result Analyzer). ASTRA was used to analyze the results of a few STP tests that were conducted by our industry sponsor. The time required to analyze the test results was reduced to a few minutes from several hours typically needed for manual analysis. The correctness of the analysis was also greatly improved.
Table of Contents
Acknowledgments iii
List of Figures………………………………………………………………………………..vii
List of Tables.……………………………………………………………………………….viii
1 Introduction 1
2 Background 3
2.1 SS7 Overview 3
2.1.1 SS7 Network Elements 3
2.1.2 SS7 Signaling Links 4
2.1.3 Basic SS7 Network Architecture 5
2.1.4 SS7 Protocol Stack 6
2.1.5 A brief review of MTP Level 3 network management 8
2.1.6 Comparison with IP 9
2.2 SS7 Interoperability Testing 11
2.3 The Testing Procedure 12
2.3.1 Set up 12
2.3.2 Execution 13
2.3.3 Data Retrieval 13
2.3.4 Analysis 13
2.4 Need for Automation 13
3 Overview of the Analysis Methodology and Software Architecture 15
3.1 Analysis Methodology 15
3.1.1 Introduction 15
3.1.2 Analysis methodology 16
3.2 Overview of Automated SS7 Test Results Analyzer (ASTRA) 18
3.2.1 Naming scheme for configuration components 20
3.2.2 Inputs to the software 21
3.2.3 Choice of the programming Language 26
4 Expressing the Expected Behavior for Automation 28
4.1 Expected Behavior Format 29
4.1.1 Identifiers 29
4.1.2 Timing relationships between events 31
4.1.3 Control mechanisms 32
4.1.4 Test Action events 34
4.1.5 Expected behavior 34
4.2 Example of Expected Behavior for a test 36
5 Data Formatting 38
5.1 Description 38
5.1.1 Filtering 38
5.1.2 Abstraction to form Generic Events 38
5.1.3 Establishing consistency 38
5.1.4 Integration of event records 39
5.1.5 Preparing for analysis 39
5.2 Implementation 39
5.3 Usage 43
5.3.1 Requirements 43
5.3.2 Command Usage 43
5.3.3 Inputs 43
5.3.4 Output produced 44
6 The Matching Process 47
6.1 The Translator 47
6.1.1 Introduction 47
6.1.2 Operation and Implementation 48
6.1.3 Usage 63
6.2 Specific Analyzer 64
6.2.1 Requirements 64
6.2.2 Usage 64
6.2.3 Inputs 64
6.2.4 Outputs produced 65
6.3 Matching Library 72
6.3.1 Requirements 73
6.3.2 Interface with the Specific Analyzer 73
6.3.3 The matching procedure 73
6.3.4 The Functions 75
7 Event Summarizer 82
7.1 Operation 82
7.1.1 Produce the Unexpected Event List 82
7.1.2 Calculate event statistics 82
7.2 Command Usage 83
7.3 Inputs 83
7.4 Outputs produced 84
7.4.1 Unexpected Event List: 84
7.4.2 Event Numbers File 85
8 Report Generator 88
8.1 Implementation 88
8.1.1 Report event statistics 88
8.1.2 Obtain and organize parameter observations 88
8.1.3 Write timer observations 89
8.1.4 Produce the detailed analysis table 90
8.2 Usage and Inputs 90
8.3 Output Produced 91
8.3.1 Classification of test results 91
8.3.2 Color coding of test results 91
8.3.3 Overview level of reports 92
8.3.4 Detailed analysis 97
9 Conclusion and future work 100
Appendix A: File naming scheme 101
Appendix B: File structure format 102
Appendix C: Example Test Network Configuration 104
Appendix D: Allowable message types and parameters for findmsg() 105
Appendix E: ASTRA source code 105
References 161
List of Figures
Figure 2.1: SS7 network elements 3
Figure 2.2: Various types of SS7 links 4
Figure 2.3 Basic SS7 network 6
Figure 2.4 SS7 Protocol layers shown in relation with the OSI model and TCP/IP protocol stack 7
Figure 3.1 ASTRA software architecture 19
Figure 3.2: Excerpt of a Test Action List. 24
Figure 3.3: Excerpt of a Recorded Times of Test Actions file. 25
Figure 5.1 Inputs and output of the data formatter 44
Figure 6.1 Relationship between Expected Behaviour, Translator and Specific Analyzer 47
Figure 6.2 Ordering of the Expected Behaviour tree by the Translator……………………..
Figure 6.3 Simple events and compound events
Figure 6.4 Depth first tree traversal and timing information
Figure 6.5 Expansion of the foreach loop
Figure 6.6 Expansion of the while loop
Figure 6.7 Inputs and output of the Translator
Figure 6.8 Inputs and output of the Specific Analyzer
Figure 6.9 The matching procedure
Figure 7.1 Procedure of producing the Unexpected Event List 82
Figure 7.2 Inputs and outputs to the Event Summarizer 84
Figure 8.1 Inputs and output of the Report Generator 90
List of Tables
Table 1 : Notation used in the analysis methodology 16
Table 2: Names of intermediate files and their file handle names 51
Table 3: Description of colour codes 92
90
1 Introduction
Signaling System No. 7 (SS7) is a global standard for telecommunications defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T). The standard defines the procedures and protocol by which network elements in the public switched telephone network (PSTN) exchange information over a digital signaling network to effect wireless (cellular) and wire-line call setup, routing and control.
The SS7 network and protocol are used for:
· Basic call setup, management, and tear down
· Wireless services such as personal communications services (PCS), wireless roaming, and mobile subscriber authentication
· Local number portability (LNP)
· Toll-free (800/888) and toll (900) wire-line services
· Enhanced call features such as call forwarding, calling party name/number display, and three-way calling
An important part of the SS7 networks are the Signaling Transfer Points (STPs), which are produced by various vendors. Each new release of an STP needs to be tested to ensure that it performs properly, and can interoperate with existing network components. This testing is called interoperability testing. Interoperability testing needs to be repeated for each new release of a STP (multiple times per year) and with STPs from different vendors. SS7 STP tests can benefit greatly from automation because they need to be repeated often, and are labor intensive.
There are four parts in the STP testing process: setting up of the test network configuration, performing the test steps, retrieving the test results from the test elements and analyzing the test results to determine whether the STP passed or failed the test.
The goal of this thesis is to automate the analysis of SS7 STP interoperability test results. Chapter 2 provides the necessary background regarding SS7 protocol and SS7 testing, and also elaborates on the need to automate the testing process. Chapter 3 develops a methodology to analyze the test results and describes the software architecture. The essence of the methodology consists of predicting the expected behavior of the STPs for the various tests, and then comparing the actual behavior of the STPs during the tests to the expected behavior. Chapter 4 provides a language to formally describe the response of STPs to the tests. Chapter 5 explains the pre-processing of the test data and Chapter 6 describes the matching of the expected behavior to this pre-processed data. Chapters 7 and 8 describe how the results of the matching process is presented so as give important information in an easily understandable format. Chapter 9 provides a conclusion, and lists future work.
2 Background
This chapter introduces aspects of the Signaling System 7 (SS7) that are pertinent to this thesis. Section 2.1 gives an overview of SS7 network structure and protocol and compares it with the Internet Protocol (IP). Section 2.2 explains the concept of interoperability testing and Section 2.3 explains the testing procedure in detail. Section 2.4 elaborates on the need to automate interoperability testing.
2.1 SS7 Overview
2.1.1 SS7 Network Elements
SS7 defines both a network structure and a packet switched protocol suite. There are three different kinds of network elements in an SS7 network: SSPs (Service Switching Points), STPs (Signal Transfer Points) and SCPs (Service Control Points). Each signaling point in the SS7 network is uniquely identified by a numeric point code. Point codes are 3 bytes long and are carried in signaling messages exchanged between signaling points to identify the source and destination of each message. Each signaling point uses a routing table to select the appropriate signaling path for each message. The three kinds of network elements are shown, using the symbols normally used to depict them, in Figure 2.1.
Figure 2.1: SS7 network elements
These three kinds of network elements are described in the following sections:
2.1.1.1 Service Switching Point (SSP)
SSPs are switches that originate or terminate calls. An SSP sends signaling messages to other SSPs to setup, manage, and release voice circuits required to complete a call. An SSP may also send a query message to a centralized database (an SCP) to determine how to route a call (e.g., a toll-free 1-800/888 call).
2.1.1.2 Signal Transfer Point (STP)
STPs are datagram switches in an SS7 network. They receive and route incoming signaling messages towards the proper destination. They also perform specialized routing functions. They are analogous to routers in an IP network. STPs are generally deployed in “mated pairs” in order to provide fault tolerance.
2.1.1.3 Signal Control Point (SCP)
SCPs are databases that provide information necessary for advanced call-processing capabilities like 1-800 calls, credit card number verification, etc.
2.1.2 SS7 Signaling Links
SS7 messages are exchanged between network elements over bi-directional signaling links that generally operate at 56 or 64 kilobit per second (kbps). Signaling occurs out-of-band on these dedicated links rather than in-band on voice channels. SS7 signaling links are named according to their use in the signaling network.
Figure 2.2: Various types of SS7 links
The SS7 link types are described below:
2.1.2.1 A Links
An "A" (access) link connects a signaling end point (e.g., an SCP or SSP) to an STP. Only messages originating from or destined to the signaling end point are transmitted on an "A" link.
2.1.2.2 B/D Links
A "B" (bridge) link connects an STP to another STP in the same level of the switching network hierarchy, where as "D" (diagonal) links connect STPs that are in different levels of the hierarchy (e.g. local and regional STPs).
2.1.2.3 C Links
A "C" (cross) link connects STPs in a mated pair. A "C" link is used only when an STP has no other route available to a destination signaling point due to link failure(s).
2.1.2.4 E Links
An "E" (extended) link connects an SSP to an alternate STP. "E" links provide an alternate signaling path if an SSP's "home" STP cannot be reached via an "A" link.
2.1.2.5 F Links
An "F" (fully associated) link connects two signaling end points (i.e., SSPs and SCPs).
2.1.3 Basic SS7 Network Architecture
Figure 2.3 shows an example of how the basic elements of an SS7 network are deployed to form two interconnected networks.
Figure 2.3 Basic SS7 network
As the SS7 network is critical to call processing, SCPs and STPs are usually deployed in mated pair configurations in separate physical locations to ensure network-wide service in the event of an isolated failure. The mated STPs perform identical functions. For example, in the figure, STPs A and B and SSPs 1 and 2 are mated pairs. Links between signaling points are also provisioned in pairs. Traffic is distributed evenly across all links in the link-set. If one of the links fails, the signaling traffic is rerouted over another link in the link-set. The SS7 protocol provides both error correction and retransmission capabilities to allow continued service in the event of signaling point or link failures.