PROTOCOL PERFORMANCE MEASUREMENT METHODOLOGY - EXPERIMENTATION WITH SIGNALING SYSTEM NO 7 by ANAND TUMKUR & AVIJIT DUTTA [email protected] & [email protected]A THESIS Submitted in partial fulfillment of the requirements for the degree MASTER OF SOFTWARE ENGINEERING School of Innovation, Design and Engineering MÄLARDALEN UNIVERSITY Västerås, Sweden 1st June 2009 Approved by: Academic Supervisor: Daniel Flemström Ericsson Mentor: Pär Asplund Examiner: Mats Björkman
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Figure 4.2-1 depict the SS7 protocol stack that will undergo performance measurement using a
monitor message by stamping local timer value. This timer value will be written either in a
common database or in a log file that will be read by an application in the SS7 application layer
to compute timing requirement of each layer for signaling message packet manipulation.
When the signaling node (Figure 4.2-1) receives a monitor message packet at MTP1 layer, it will
write ‘start time’ either in a database table or in a log file the local timer value and starts
processing on it.
Once the processing is completed by MTP1 layer, it will deliver the message to the upper layer
(MTP2) and again write the ‘end time’ in the database table or in the log file. A sample database
table or the log file content can be formulated as depicted in Figure 4.2-1. Similarly all the layers
in the stack will perform the same activity for ‘start time’ and ‘end time’ when a layer receives a
message packet and delivers it to the upper layer respectively. Now a test application at the SS7
application layer, will read the database table or the log file when it receives the message packet
from its below layer as portrayed in Figure 4.2-1. This test application will compute the timing
requirement for each protocol in SS7 stack for processing.
39
5. An Experimental Approach to Measure Performance
5.1. Experimentation
The experimental setup is based on client-server architecture. Client and server machines are
having an identical configuration. The client and server are connected by an Ethernet 100 Base-T
cable with a transmission capacity of 100 Mbits/second. The straight cable is used and hence a
switch is required in the LAN connection. An 8 port Gigabit switch is used for cross over. A
twisted Ethernet cable can eliminate the use of a switch. The two systems are configured with IP
addresses. Below are the hardware, software and test configurations.
• Hardware configuration
� Processor – Intel Pentium IV, 3GHz processor
� Cable - 100 Base T
� Switch – NetGear 8 port Gigabit Switch
� Interface card – Network Interface Card for IP communication
• Software configuration
� Operating system – Fedora 9
� Kernel version – 2.16.25-14.fc9.i686
� Open SS7 version - openss7-0.9.2.G
� IPerf version – iperf-2.0.8
� Netperf version – netperf-2.3.7
• Test configuration
� Message size - $n, this is a variable
� Test duration – 10 seconds
� Protocol measured – SCTP and TCP
� Bit rate - Output at different values of $n
� Port number – 5001
� Measured aspects – Throughput – Bytes of data sent per second (Mbps)
� Server IP: 130.243.75.14
� Client IP: 130.243.75.15
40
Figure 5.1-1: Experimental Setup for Performance Measurement
Figure 5.1-1 depicts the architectural view of the experimentation with a client-server. At the
client side, the IPerf client runs as the application over the Open SS7 kernel module. When the
test is performed, the client injects the test data into the stack and then to the physical medium.
The server is listening for the response at port 5001(default port).
5.2. IPerf Performance Measurement Tool
IPerf is a common network performance tool developed in C++ used to measure TCP and UDP
protocols. The release iperf-2.0.8 by Open SS7 community supports SCTP protocol
measurement. IPerf allows the user to set various network parameters like buffer size, message
length, time interval and various other parameters as shown in Table 9. IPerf has client-server
architecture with the tool running on one system as client and the other system as server. Figure
5.2-1 represents the IPerf server application listening at port number 5001 for a SCTP
communication. Figure 5.2-1 depicts the server command line inputs with the following options.
• Option –s: Represents IPERF in server mode and ready to accept the incoming
data.
• Option –B: Binds the server to the current IP for SCTP communication.
• Option –z: Depicts the SCTP communication.
41
• Option –w: Sets the protocol communication window size.
The output shows the successful binding, the port number on which the server is listening and
the window size set. Once the server is configured, the client needs to initiate the communication
to find the network performance.
Figure 5.2-1: IPerf server
Figure 5.2-2 depicts the IPerf client command line options:
• Option –c: Represents IPERF in client mode and the server IP is expected to
follow.
• Option –l: Represents the message length. The test can be performed at various
message lengths.
• Option –B: Binds the client to the current IP for SCTP communication.
• Option –z: Depicts the SCTP communication.
• Option –w: Sets the protocol communication window size.
The initial output shows that the server connected to the client, the client IP to which the client
bound, the SCTP port number and the window size. After 10 seconds the throughput and the
total bytes of messages transferred is displayed. The time interval can be varied with –I option
followed with the time in seconds.
42
Figure 5.2-2: IPerf Client
5.3. Results
The throughput of the SCTP and TCP protocol are measured. The throughputs at different
message lengths are tabulated in Table 7 and Table 8 respectively. The experiment was
conducted at a window size of 108KB (Kilo Bytes). We could prove that the change in window
size had negligible effect and hence was not considered as a variable parameter to measure the
performance at different window size.
Table 7: SCTP Performance
Message Length Mega bytes transferred Throughput (Mbps)
8 2.71 2.27
16 5.39 4.52
32 10.7 8.95
64 21.4 18
128 120 100
256 211 177
512 282 236
1024 389 326
2048 384 322
4096 509 427
8192 579 486
43
Message Length Mega bytes transferred Throughput (Mbps)
16384 614 578
32768 678 569
Table 8: TCP Performance
Message Length Mega bytes transferred Throughput (Mbps)
8 18.5 15.5
16 43.2 36.2
32 80.7 67.7
64 144 121
128 276 232
256 386 324
512 644 514
1024 894 750
2048 1090 939
4096 1080 931
8192 1090 937
16384 1090 936
32768 1090 938
Figure 5.3-1 show that the performance of TCP under our test scenario is better compared to
SCTP at higher data rate. Figure 5.4-2 and Figure 5.4-3 shows the server and client responses at
different message size during experimentation.
44
Figure 5.3-1: Throughput Comparison of SCTP and TCP
5.4. Analysis
SCTP is a relatively new protocol compared to TCP which has evolved over a long period of
time. A lot of effort is made towards making the protocol gain complete functionality. In [25],
the performance of SCTP is compared with TCP to conclude that TCP outperforms SCTP in
throughput over long period of time. The results in [25] show that over a period of 3600 seconds,
data transferred through TCP is 160000 Mega bytes as against 20000 Mega bytes over SCTP.
The analysis provided that SCTP is a comparatively new protocol and a lot of effort is dedicated
towards adding features. Hence a little effort is made towards improving the performance of
SCTP. In [26], a 46 mobile nodes were placed in a random way point mobility model to measure
the performance of SCTP and TCP. The results concluded that for a MANET system, TCP and
SCTP performed similarly but TCP had a slight advantage over SCTP when the throughput was
measured. The analysis reveals that the selective acknowledgement of SCTP consumes more
bandwidth than TCP. In [27], the measurement results that TCP is effective in bandwidth
utilization and hence has a better performance as compared to SCTP. The analysis reveals that
45
the best and worst case time delivery of packets were at 11% and 61% as compared to SCTP
which has 60% and 89% as its best and worst case results in case of one in every 10 packets lost.
The most interesting results are produced in [24] with the performance of SCTP and TCP being
almost the same when a single Network Interface Card (NIC) is used. The measurements were
carried out with two experimental setups, one with a single NIC and one with two NIC. When
two NIC were used, the performance of SCTP outperformed TCP with almost double
throughput.
A further analysis revealed that the performance of SCTP can be significantly improved over
TCP in multiple path networks. In a multiple path network SCTP is supported by multiple
homing. Figure 5.4-1 depicts a SCTP host 1 and host 2 with a multiple interconnection. Let us
assume, host 1 is to send data to host 2 on network IP1-IP3, this is called the primary path. If a
packet gets dropped on the primary path, the sender immediately sends the data on the alternative
path i.e. on IP2-IP4 path. This mechanism reduces the failure recovery time.
Figure 5.4-1: Multi Homing Support in SCTP
46
Figure 5.4-2: SCTP Server Response at Different Message Length
47
Figure 5.4-3: SCTP Client initiation at Different Message Length
48
6. Summary and Conclusion
This report introduces the reader to the basic call set-up in a mobile communication and the
various telecommunication sub systems involved in the call set-up scenario. The focus in the
initial chapter is to depict the communication protocol involved in the telecommunication
network. The open source communication protocols and Ericsson proprietary communication
protocols are dealt in detail with their analogy. The analogy reveals that the CPP Signaling
system supports different types of networks for SS7 communication. These two protocol stacks
are seen as black boxes due to the unavailability of their design and internal architecture. SCTP
being an important transport layer protocol of SS7 over the IP network, the performance of the
SCTP protocol is of importance. TCP is the most popular transport layer protocol which was not
suited for SS7 over IP due to the fact that TCP has strict sequential delivery of packets and has
large timeout granularity. The experimentation was carried out to check whether SCTP has
evolved to the level of performance that TCP promises.
The experimentation carried out with the hardware set-up in the lab does a throughput
performance measurement of SCTP and TCP. The experimental results show that TCP performs
better than SCTP with a single NIC (Network Interface Card) but the analysis yields that SCTP
can outperform TCP with the multi homing support. SCTP provides major advantage of
unordered delivery and reassembly at the receiving end, SCTP support multiple stream and multi
homing which is not supported in TCP. The experiment also revealed that the window size did
not have a large effect on throughout for both SCTP and TCP.
7. Future Work
This thesis sets a platform for further comparison of protocol stack of the open source
community and Ericsson proprietary. The various alternatives for future work are as follows:
The Open SS7 could be tried out on a CPP node to test the performance of SS7 communication
on a CPP node with OSE Delta Operating system running on it. In this perspective, the current
thesis differs only with respect to the platform as we have tried on a Pentium IV processor. This
would lead to performance comparison of a non-real time operating to a real time operating
system.
49
The current thesis has the limitation of having open SS7 and CPP SS7 on a different platforms.
Hence the open SS7 and Ericsson proprietary SS7 performance can not be compared. By
installing Open SS7 on a node will ensure that the environmental factors for both types of SS7 is
the same and their performance purely depend on the design and implementation of protocol
stack. The importance of this approach is to compare protocol with protocol in two different
stacks and find the better one.
The two proposed methodologies of measuring stack and individual protocol are of specific
importance to find the bottle neck in the network. The methodologies use the method of time
stamping the message traversal through different layers of the protocol stack. The importance of
this aspect is to find the layer where the time is spent a lot in the network and hence work
towards better design of the layer.
50
References
[1] A. Chukarin and N. Pershakov, Performance Evaluation of the Stream Control Transmission Protocol, In IEEE MELECON 2006, May 16-19, Benalmádena (Málaga), Spain. 1-4244-0088-0/06.
[2] K. Gradischnig and M. Tüxen, “Signaling Transport over IP-based Networks using IETF Standards,” DRCN, 2001.
[3] Min Young Chung and etal, Performance Analysis of Common Channel Signaling Networks, Based on Signaling System #7. In IEEE Transactions on Reliability, vol. 48, no. 3, 1999 September. 0018-9529/99
[4] Brian W. Unger and Greg A. Lomow. The Telecom Framework: A Simulation Environment For Telecommunications. In Proceedings of the 1993 Winter Simulation Conference.
[5] Lite 3000/3000E, SS7 Protocol Functionality. Available: http://multi-layers.com/docs/spec_sheet_lite_3000_e_ss7_protocol_functionality.pdf. [Accessed: 2009-02-18].
[8] SS7 Simulation and Testing. Available: www.sunrisetelecom.com. [Accessed: 2009-02-18]. [9] Mats Bjorkman and etal. Application Protocols and Performance Benchmarks. In June 1989 -
IEEE Communications Magazine. 0 163-6804/89/0006-003 [10] Lee Dryburgh and Jeff Hewett, Signaling System No. 7 (SS7/C7): Protocol, Architecture,
and Services. Cisco Press, 2004. ISBN: 1-58705-040-4. [11] Tobias Engel [email protected], “Locating Mobile Phones using Signalling System #7” -
http://www.mobilein.com/Mobile%20Networking.pdf [Accessed: 2009-02-23] [14] Lars-orjan kling, Ake Lindholm, Lars Marklund and Gunnar B. Nilsson, ”CPP – Cello
[15] Mahamed Atoui, “Performance Measurement of the SS7/Intelligent Network”, Telecommunications Systems Department, Mclean, Virginia, ‘ieeexplore.ieee.org/iel2/534/6548/00258366.pdf?arnumber=258366’.
[16] Min Young Chung and etal, “Performance Analysis of Common Channel Signaling Networks, Based on Signaling System #7”. In IEEE Transactions on Reliability, vol. 48, no. 3, 1999 September. 0018-9529/99
[17] Robby Darren Benedyk, David Michael Sprague, Dan Alan Brendes – “ Methods and Systems for Communicating SS7 Messages over Packet-Based Network using Transport Adapter Layer Interface“,Publication Date: 02/07/2007 , ‘http://www.freepatentsonline.com/EP1192758.html’
[18] Cello Platform Survey, Student Text, EN/LZT 123 6795 R1B. Ericsson Radio Systems. [19] Christopher M White and etal, A Network Performance Application for Modeling,
Simulation, and Characterization of Packet Network Behavior. In IEEE Conference 2003. 0-
51
7803-8104-1/03. [20] John N. Sahalos and etal, A Test Lab for the Performance Analysis of TCP over Ethernet
LAN on Windows Operating System. In IEEE TRANSACTIONS ON EDUCATION, VOL. 48, NO. 2, MAY 2005. 0018-9359.
[21] Netperf: A Network Performance Benchmark. Revision 2, Information network division. Hewlett-Packard Company. February 15, 1995.
[22] Richard James Spangler, Steven Michael Freedman – “Methods and Systems for Collecting and processing signaling system 7 (SS7) message signal unit (MSUs)” -http://www.patentstorm.us/patents/6327350/claims.html, published on 28 Mar 2000.
[23] Barry L. Nelson, W. David Kelton, Gordon M. Clark – “A Teletraffic simulator for circuit switched and signaling intelligent network with SS7” http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=185674, Proceeding of the 1991 Winter Simulation Conference.
[24] Open SS7 official website, http://www.openss7.org/ [Accessed on 2009-05-19] [25] SCTP Performance Tests, http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm.
[Accessed on 2009-05-23] [26] Ashwini Kumar and Lilykutty Jacob, SCTP vs TCP: Performance Comparison in
MANETs. In the Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks. 0742-1303/04.
[27] Henrik Osterdahl. A Comparison of TCP and SCTP Performance using HTTP Protocol. 800606-0290, D-01
52
Appendix A - Acronyms
Acronym or
abbreviation Definitions
ATM Asynchronous Transfer Mode
BTS Base Transceiver Station
CADE CPP Application Development Environment
CCS# Common Channel Signaling System
CDMA Code Division Multiple Access
CPP Connectivity Packet Platform
DPC Destination Point Code
FTP File Transfer Protocol
GSM Global System for Mobile Communications
HLR Home Location Register
IMSI International Mobile Subscriber Identity
I# Intelligent Network
IP Internet Protocol
IRIL Industrial Research and Innovation Lab
ISD# Integrated Services Digital Networks
ISUP ISDN User Part
LTE Long Term Evolution
M3UA MTP 3 User Adaptation Layer
MGC Media Gateway Controller
MGW Media Gateway
MSC Mobile Switching Centre
MSU Message Signalling Unit
MTP Message Transfer Part
#IF Nodal Interworking Function
O&M Operation and Maintenance
53
Acronym or
abbreviation Definitions
OPC Origination Point Code
PC Point Code
PST# Public Switched Telephone Network
QOS Quality of Service
RBS Radio Base Station
R#C Radio Network Controller
RTOS Real Time Operating System
SCCP Signaling Connection Control Part
SCP Service Control Point
SCTP Stream Control Transmission Protocol
SEP Signaling End Point
SG Signaling Gateway
SIM Subscriber Identity Module
SMH Signalling Message Handling
S#M Signalling Network Management
SP Signaling Point
SS7 Signaling System # 7
STP Signal Transfer Points
TALI Transport Adapter Layer Interface
TCAP Transaction Capabilities Application Part
TCP Transmission Control Protocol
TDM Time-division multiplexing
TUP Telephone User Part
VLR Visitor Location Register
VOIP Voice over Internet Protocol
WLL Wireless local loop
54
Appendix B - Open SS7 Installation and Troubleshooting
Release Packages
Open SS7 has five major master package releases in the recent time. openss7-0.9.2.G.tar.bz2
being the latest release is considered for installation. Open SS7 master packages are not released
often but the sub packages are released frequently. To embed a sub-package release into the
master package, the sub package should be placed within the master package. Once the directory
is replaced, the master package has to be recompiled. The downloads are available at [24].
1. openss7-0.9.2.C.tar.bz2
2. openss7-0.9.2.D.tar.bz2
3. openss7-0.9.2.E.tar.bz2
4. openss7-0.9.2.F.tar.bz2
5. openss7-0.9.2.G.tar.bz2
Apart from master package releases openss7 has individual ss7 stack releases. These packages
have dependencies on other package releases. The binary compiled packages are also available
for download.
1. strss7-0.9a.8-1.noarch.rpm
Operating systems
The installation was carried on three different operating systems. All three were in accordance to
the system requirement specified in the installation manual of openss7. Open SS7 is supported
by kernel version 2.4 and 2.6. Later, the installation was concentrated on fedora system because
of easy availability of the dependent packages as listed in the next section “Package
Dependencies”.
1. Fedora 9 with kernel version 2.6.25-14.fc9.i686
2. Ubuntu 8.10 with kernel version 2.6.27
3. Ubuntu 8.04 with kernel version 2.6.24
System requirements
The below are the system requirement to be satisfied before installing open SS7.
55
• A fairly LSB compliant GNU/Linux distribution.1
• Linux 2.4 kernel (2.4.10 - 2.4.27), or
• Linux 2.6 kernel (2.6.3 - 2.6.26)
• glibc2 or better.
• GNU grof (for man pages).2
• GNU texinfo (for info les).
• GNU bison and ex (for cong programs).
• net-snmp (for SNMP agents).
Package dependencies
As openss7 installation is kernel module installation, a lot of development packages dependency
exists which are not available with the normal operating system installation. The below depicts
the package dependencies. The below installation were performed with downloading the specific
version of package compatible to the kernel version 2.6.25-14.fc9.i686 of Fedora 9 operating
system.
1. GCC compiler package
2. Kernel development package
3. Net SNMP agent package
56
4. Net SNMP development package.
5. elfutils development package.
6. openssl development package
7. rpm development package.
57
Installation Process
The openss7 installation was tried on all three operating system with installing appropriate
packages to satisfy all dependencies. For Red Hat based UNIX system, RPM packages were
installed and for debian based UNIX, DEB packages were installed.
2. Installing DEB packages sudo dpkg –I package_name.deb
Once the dependent packages were installed, successfully, the package was unpacked to obtain
the source code to compile. A new folder was created by name “openss7-0.9.2.G” when
unpacked. Create a new build directory with the unpacked folder. Change directory to build.
Execute the configure file to check for all configuration to be correct. Later execute the make file
to install openss7. Make command has various inputs while installation, to verify the proper
installation. The complete installation is verified by executing all the 3000 user installation test
cases provided within the package.
1. tar –xjvf openss7-0.9.2.G.tar.bz2 2. cd openss7-0.9.2.G 3. mkdir build 4. pushd build 5. ../strss7-0.9a.8-1/configure --enable-autotest 6. make 7. make install 8. make installcheck
58
Appendix C - IPerf Commands
IPerf is a network performance measurement tool that can be installed on both windows and
Linux based systems. Table 9 shows the different client and servers CLI options available during
measurement. The IPerf server has to be first started in server mode followed by the binding
address and window size or the buffer size.
• iperf –s –B local_ip_addr –w window_size
Later, the IPerf client has to be started to initiate the communication with the below command.