PROTOCOL PERFORMANCE MEASUREMENT METHODOLOGY - EXPERIMENTATION WITH SIGNALING SYSTEM NO 7

(1)

by

ANAND TUMKUR & AVIJIT DUTTA

atr08001@student.mdh.se & ada08001@student.mdh.se

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

(2)

Abstract

Performance is the driving force for the effective network utilization in the current telecommunication world. The thesis aims to define suitable performance measurement methodologies for communication over stack based Signalling System No 7 (SS7). This thesis also throws a quick glance on open source SS7 and Ericsson proprietary SS7 protocols, to devise performance measurement approach that can be adopted to develop sophisticated tools. We adopt a scientific experimental approach for numerical measurement of throughput and latency of the protocol stack. Our current work finishes experimentation with open source SS7 protocol (SCTP) in Fedora based two identical servers. SCTP (Stream Control Transmission Protocol) is an important transport layer protocol for communication of SS7 message over an IP network. Message communication using SCTP protocol over an IP/Ethernet network between these two identical servers has been measured and analyzed using the IPerf tool. TCP (Transmission Control Protocol) being another important transport layer protocol of TCP/IP stack, the performance of TCP is compared with SCTP. The results prove that under normal circumstances TCP gains over SCTP and our analysis support that under multi homing support, SCTP should gain over TCP when throughput is measured.

(3)

List of Figures

Figure 2.1-1: Structure of GSM network (key elements) [11]... 9

Figure 2.2-1: Horizontal and Vertical Network Architecture [18]... 10

Figure 2.2.1-1: CPP Structural Units within a Node [18] ... 12

Figure 2.2.1-2: SS7 communication between two nodes in telecom work [13] ... 13

Figure 2.3.1-1: Simple SS7 Protocol Stack [9] ... 14

Figure 2.3.2-1: Adaptation for SS7 over IP ... 15

Figure 2.3.2-2: SCTP advantage over TCP [10] ... 16

Figure 2.3.2-3: SS7 over IP [10] ... 17

Figure 2.3.3-1: Cello Signaling and transport services [14] ... 17

Figure 3.1-1: Study Selection Process ... 20

Figure 3.2-1: Sample CCSN (Common Channel Signaling system) physical network [15] [16] 21 Figure 3.2.1-1: Performance measurement methodology ... 22

Figure 3.3-1: TALI layer controls SS7 over TCP/IP network [17]... 23

Figure 3.3.1-1: Round-trip time calculation using TALI layer [17] ... 24

Figure 3.4-1: SCTP Test Bed Architecture [1] ... 25

Figure 3.4-2: Mean Signaling Message Transimission Delay Over IP Network [1] ... 26

Figure 3.5-1: CCSN (Common Channel Signaling system) physical network [3] ... 28

Figure 3.5-2: Call Scenario in Basic ISDN Calls [3] ... 28

Figure 3.6-1: RPC, Bulk_get and Conn_disc time [9] ... 30

Figure 3.7-1: CDR processing architecture [22] ... 32

Figure 3.8-1: Hybrid network architecture [23] ... 33

Figure 4.1-1: Performance measurement approach... 36

Figure 4.2-1: SS7 stack performance measurement methodology... 38

Figure 5.1-1: Experimental Setup for Performance Measurement ... 40

Figure 5.2-1: IPerf server ... 41

Figure 5.2-2: IPerf Client ... 42

(6)

Figure 5.4-1: Multi Homing Support in SCTP... 45 Figure 5.4-2: SCTP Server Response at Different Message Length... 46 Figure 5.4-3: SCTP Client initiation at Different Message Length ... 47

(7)

List of Tables

Table 1: Research Paper Selection ... 19

Table 2: Environmental Factors during Measurement - 1... 26

Table 5: Open Source Tools for SS7 Performance Analysis ... 34

Table 6: Commercial Tools for SS7 Performance Analysis ... 35

Table 7: SCTP Performance... 42

Table 8: TCP Performance... 43

Table 9: IPerf CLI Options... 58

(8)

Acknowledgements

This dissertation could not have been written without Daniel Flemström who not only guided as our supervisor but provided the inspiration and force to excel better than ever before. We are grateful to TATA Consultancy Services (TCS), India, Ericsson AB, Sweden and Mälardalen University, Sweden for providing this wonderful opportunity. We are deeply thankful to Prof. Mats Björkman for all his valuable feedback and support throughout the thesis. Thanks to Pär Apslund, Ericsson for helping us to narrow down and focus intensely on core aspect of our thesis. We appreciate Brian Bidulock (Open SS7 community) for extending their help as and when required. Thanks to Malin Rosqvist for helping us with proofreading of our manuscript. Last but not the least, we wish to thank our TCS student group at Mälardalen university for patiently listening to our thesis status presentation every week and providing valuable feedback.

(9)

1. Introduction

This is a D-level Master Thesis report in Software Engineering at the School of Innovation, Design and Engineering at Mälardalen University, Sweden. The thesis is carried out at Industrial Research and Innovation Lab (IRIL) provided by the university with immense support from Ericsson AB, Älvsjö, Sweden. The academic supervisor is Daniel Flemström and industrial supervisor is Pär Asplund. This thesis has been written during 20 weeks from January 2009 to June 2009. The report aims at providing the reader with background knowledge of communication protocols in telecommunication systems and the new measurement approaches & aspects of performance.

1.1. Outline

The report is organized to give the reader a brief introduction to the basics in telecommunication and communication protocol in Section 2. Section 3 highlights the related work carried out previously in the field of experimentation with protocol performance measurement in a controlled environment. Section 4 deals with our proposal for protocol measurement of the entire SS7 measurement and individual protocol layer measurement. Section 5 is the result and analysis of our experimentation with Open source signaling system #7 protocol stack. Summary and conclusion is represented in Section 6 with future work in Section 7. Appendix A provides the list of acronyms used in the document. Appendix B provides Open SS7 installation and trouble shooting. Appendix C and Appendix D provides the command lines interface options of IPerf and NetPerf protocol performance measurement tools respectively.

1.2. Prerequisite Knowledge

The reader is not expected to have in-depth knowledge in the telecom domain as the initial chapter provides a brief introduction to the GSM mobile network. The basics of computer communication network will be help to understand signaling system #7 protocol stack. The experiment is carried out in a Linux environment and hence to repeat the experiment, the reader is required to know user basic skills of the Linux operating system.

(10)

2. Background

This section is intended to provide an overview of the telecommunication system. Telecommunication nodes (sub systems) are built on platforms which support various node applications. CPP (Connectivity Packet Platform) is an Ericsson proprietary platform of their telecommunication sub-systems. Signaling System # 7 is a core protocol stack used for internode communication in telecom system.

2.1. Telecommunication Mobile #etwork

Figure 2.1-1 is a simple mobile network, depicted for easy understanding of the proceeding sections. Each element like BTS (Base Transceiver Station), MSC (Mobile Switching Center), HLR (Home Location Register) are called nodes in a mobile network. BTS is the telecom node that connects the wireless mobile devices with the network. The wireless devices can be a mobile handset (GSM & CDMA), WLL (Wireless local loop), VOIP devices (Voice over internet protocol). The main component of network sub system is Mobile Switching Center (MSC) which provides normal switching functionality for PSTN (Public Switched Telephone Network) and ISDN (Integrated Switch Digital Networks). For mobile users, MSC provide additional functionality like registration, authentication and call location. Home Location Register (HLR) is the database to register all mobile users and usually there is one HLR per network. Each mobile SIM card issued is recorded in HLR using a primary key called IMSI (International Mobile Subscriber Identity).

For voice calls or data access using mobile phones, base station subsystem takes care of radio communication via over-the-air interface. Once the mobile enters the BTS region, the BTS updates the VLR/HLR database. When the user makes a call, a call setup request is sent the nearest mobile network via BTS. Within the network, MSC checks with VLR to authenticate whether the user has sufficient credits and other records. After authentication, MSC sets up the call using global PSTN network if the call is towards a landline.

(11)

Figure 2.1-1: Structure of GSM network (key elements) [11]

Platform: A versatile development of software for these nodes (network subsystem) requires

component based design. In component based design, the application and platform are separately development and their interaction is governed by well defined interfaces. The application, interface and platform together constitute the software running on the node. The platform consists of reusable software that can be used across various nodes of the mobile network. Ericsson’s mobile platform (AXE, CPP) is the base for any telecom nodes for its functionality in the mobile network. Nodes like Mobile Switching Center (MSC), High Location Register (HLR) uses Ericsson AXE platform. However, Radio Base Stations (RBS), Radio Network Controllers (RNC), Media Gateways (MGW) uses Ericsson CPP platform.

(12)

2.2. CPP Platform

When Ericsson started designing telecom system for Wideband Code Division Multiple Access system (WCDMA), a platform was necessary to build different application. This would help in utilizing the platform across various applications like Radio Network Controller (RNC), Radio Base Station (RBC) and Media Gateways (MGW). A common platform helped in designing a horizontal structure (Figure 2.2-1) that had significant advantage over vertical structure. In horizontal design, the different layers communicated through well defined interfaces and hence the applications were able to share the resources at lower level. To be able to communicate with different services, the “connectivity” in Figure 2.2-1 needs to have a strong platform for any application built. CPP (Connectivity Packet Platform) is a strong platform designed by Ericsson to support application software on telecom nodes.

Figure 2.2-1: Horizontal and Vertical #etwork Architecture [18]

2.2.1. CPP Platform for 3G mobile network

(13)

exposed interfaces. Platform includes software for fulfilling functionalities like operation and maintenance (O&M), control, redundancy, switching that resides in-between applications and OSE-DELTA RTOS used in CPP. This software is used for fulfilling node functionalities like remote maintenance, platform maintenance, and fail-over. Interfaces are used for interaction between applications and platform software.

The platform uses OSE-delta real time operating system (RTOS) that includes the SS7 protocol stack. Applications communicate among different nodes in the telecom network through the platform. Initially, CPP was supporting only SS7 over ATM and SS7 over TDM transport in asynchronous transfer mode. But in the present time, support has also been added for SS7 over IP transport for better scalability and cost-to-performance ratio. For Quality of Service (QOS), intially ATM was considered the only option for mobile networks. But in the present time due to a lot of research in IP technology and increased investments in IP networks along with the internet popularity, telecom operators are looking for reduced cost and it has been noticed that it is possible to replace ATM with pure IP networks [14].

SS7 communication mainly assures [12].

• Basic call set-up, management and control

• Efficient and secure worldwide telecommunication • Wireless roaming and subscriber authentication

The Cello Packet Platform of Ericsson has evolved as the Connectivity Packet Platform that has been projected considering 3G (3rd Generation) and LTE (Long Term Evolution) of future generation mobile networks. The 5 structural units of CPP as depicted in Figure 2.2.1-1 are:

• Core • CADE

• O&M (Operation and Maintenance)

• IP & C (Internet Protocol and Connectivity) • Signalling

The core consists of OSE Delta as the real time operating system. The Java execution platform is provided for the application management. Core supports during system upgrade. The CADE (CPP Application Development Environment) part provides the software development

(14)

environment for both application software and CPP software. CADE helps in debugging and building load modules. IP & Connectivity provides the services of transporting over the ATM and IP networks and network synchronization. The Operation and Maintenance part of a Cello based node provides the management of services, interface support and application support. The signaling System Area provides the service for sending the signaling messages between the nodes in a network.

Figure 2.2.1-1: CPP Structural Units within a #ode [18]

Figure 2.2.1-2 depicts SS7 communication between two nodes in a telecom network. Here both node A and B are built on CPP. ‘A’ denotes HLR and ‘B’ denote the local area mobile node (MSC or VLR) where a subscriber is roaming with his mobile device. As soon as the mobile device comes under a cell (controlled by a mobile tower i.e. radio base station), the corresponding MSC/VLR communicates with the HLR using SS7 protocol, informing HLR to authenticate and enlist the details of the mobile system for further communication (call set-up or release) with this mobile device.

(15)

Figure 2.2.1-2: SS7 communication between two nodes in telecom work [13]

2.3. Signaling System #o 7

2.3.1. Open Signaling System #o 7

Figure 2.3.1-1: depicts a simple protocol stack. The SS7 stack consists of 4 levels and is often compared with the layers of TCP/IP based on the functional similarities of the levels. The SS7 signaling protocol is used for inter-node communication in mobile networks.

The first level is called MTP 1 (Message Transfer Part). This is the physical layer used for communication. MTP2 is a signaling link which together with MTP3 provides reliable transfer of signaling messages between two directly connected signaling points. MTP2 provides signaling link error monitoring, error correction by retransmission, and flow control. MTP3 performs two operations, Signaling Message Handling (SMH) and Signaling Network Management (SNM). SMH transmits the incoming messages to their destination User Part and routes outgoing messages toward their intended destination. MTP3 uses point code (PC) to route the incoming and out going messages towards their destination. Origination Point Code (OPC) and a DPC (Destination Point Code) are included in each message during transmission. The MTP3 level will insert to recognize the signalling point. This will help in identifying the message origination location. DPC is also inserted by MTP3 to identify the address of destination signaling point. Routing tables within an SS7 node are used to route messages. SNM monitors linksets and routesets. The status about the traffic is given to network to reroute traffic in congestion. SNM

(16)

also provides procedure actions when a failure occurs. This also provides a self-healing to the SS7 network. TUP and ISUP help is setting up, maintaining and tearing down calls.

ISUP is replaced by TUP is many countries as ISUP supports ISDN which TUP does not. In addition, the SCCP provides a more flexible means of routing and provides mechanisms to transfer data over the SS7 network. Such additional features are used to support non-circuit-related signaling, which is mostly used to interact with databases (SCPs). It is also used to connect the radio-related components in cellular networks. TCAP allows applications (called subsystems) to communicate with each other (over the SS7 network) using agreed-upon data elements. These data elements are called components. Components can be viewed as instructions sent between applications. For example, when a subscriber changes VLR location in a global system for mobile communication (GSM) cellular network, his or her HLR is updated with the new VLR location by means of an UpdateLocation component. TCAP also provides transaction management, allowing multiple messages to be associated with a particular communications exchange, known as a transaction

Figure 2.3.1-1: Simple SS7 Protocol Stack [9]

2.3.2. SS7 over IP

The convergent world of voice, video and data required a transition from a circuit switched network to packet switch network. In packet switched network, the channel is shared between different traffic rather having a dedicated channel. This next generation architecture require the

(17)

transmission of SS7 data over IP. There were three architectural design changes required to implement SS7 over IP. Figure 2.3.2-1 depicts the adaptation necessary for SS7 over IP [10].

• Introduction of adaptation layer to meet the requirements of signaling system protocol

• A transport layer protocol that transfers the telephony signals at the same efficiency and performance.

• IP Network protocol.

Figure 2.3.2-1: Adaptation for SS7 over IP

The popular protocols for transport layer were TCP and UDP which were unsuitable for this purpose because of the following reasons.

• The basic requirements of reliability and in-order transfer of packets were not met by UDP

• TCP met the basic requirements but posed a problem of greater delay in case of packet loss. A 1% packet loss expected to create 9% delay which was unacceptable.

• The retransmission timer in TCP was large and hence any packet retransmission was not tunable.

(18)

SCTP (Stream Control Transmission Protocol) addresses these issues hence developed to meet the requirements of transporting SS7 over IP. Figure 2.3.2-2 depicts the advantage of SCTP over the TCP protocol by having multiple stream while data transferring which ensures the delivery of the later packets in case if the earlier packets are not delivered. In TCP, as it is an in-order delivery, the later packets will not be delivered. SCTP defines a primary and secondary path for transmission by which the failure recovery is high compared to TCP.

Figure 2.3.2-2: SCTP advantage over TCP [10]

A typical usage of SS7 over IP is seen between Signaling Gateway (SG) and Media Gateway Controller (MGC). Figure 2.3.2-3 depicts the protocol stack at various nodes in the communication. The communication channel between SEP (Signaling End Point) and SG (Signaling Gateway) is pure SS7 network. The communication between SG and MGC is pure IP network. The implementation is dependent on NIF (Nodal Interworking Function) that allows the MGC to exchange SS7 signaling messages over SS7 based on SEP. The message distribution from MGC to SEP or from SEP to MGC is performed by M3UA (MTP3 User Adaptation layer). The distribution is based on matching the incoming message against the Routing Keys. When a Routing Key is selected, the Application Server state is checked to see if it is active. As discussed earlier, SCTP is the transport layer protocol that handles the reliable transmission of telephony signals over an IP network.

(19)

Figure 2.3.2-3: SS7 over IP [10]

2.3.3. Analogy of Open SS7 and CPP SS7

Figure 2.3.3-1 depicts detailed communication through a signaling stack at high-level. CPP provides built-in support for SS7 communication for IP, ATM, and TDM. The operation and maintenance activities as depicted in 2.2.1 using SS7 over IP service. We see that the signaling communicatio in CPP has multiple options available,

• To send pure SS7 over TDM.

• The SS7 over ATM is supported by ATM adaptation layer.

• The SS7 over IP is supported by MTP 3 User Adaptation layer and SCTP.

NIF (Nodal Interworking Function) helps in message exchange over different types of networks. It is evident that the CPP has utilized the available forms of network communication.

(20)

Comparing Figure 2.3.3-1 and Figure 2.3.1-1, we find that when both the SS7 stacks are seen as a black box, there is no difference for the SS7 message over TDM network. Comparing Figure 2.3.3-1 and Figure 2.3.2-1, we find that the adaptation required by SS7 over IP as depicted in the discussion Section 2.3.2 is used in CPP signaling. The SS7 application message (SCCP message) is marshaled over M3UA (MTP3 User Adaptation Layer) to SCTP (new transport layer protocol) to an IP network. This concludes that, baring the application layer of SS7 stack, the lower levels of Open SS7 and CPP SS7 are the same when viewed as a black box.

(21)

3. Related Work

3.1. Literature review methodology

A broad and systematic search in the following databases was performed to obtain credible information.

• ACM Digital Library (<portal.acm.org>) • IEEE eXplore (<ieeexplore.ieee.org>)

The keywords used for searching were generic to a cover broad area of the database. “Network performance measurement”, “protocol measurement “signaling system performance”, “Signaling system 7”, “SS7 in mobile network” the keywords were used.

A systematic study selection process is depicted in Figure 3.1-1. Initially, the keywords resulted in 2960 research papers, all of which were not related to our thesis. Hence by reading the title, the papers were easily filtered based on the title. We read the abstract of the 90 papers. This resulted in 18 papers which were selected for complete study. During the study of these 18 papers, we found more interesting research papers related to the topic. Validation of these papers was not required as they were selected from either IEEE or ACM databases which are trusted world wide. Table 1 depicts the number of papers which were the result of the keyword based search. The search filter did not include a “on or after date clause” to cover a larger database.

Table 1: Research Paper Selection Search criteria Database Resulted no of

papers Papers selected for study Network performance measurement IEEE 43 1

Protocol measurement ACM 2775 1

Signaling system performance

IEEE 21 1

(22)

Search criteria Database Resulted no of papers

Papers selected for study

SS7 in mobile network ACM 83 2

Figure 3.1-1: Study Selection Process

3.2. Performance Measurement of SS7/Intelligent #etwork.

SS7 is the commonly used protocol for voice call set-up in the telecom industry. Even IN (Intelligent Network) systems are being proposed to include SS7 communication instead of X.25 network due to various constraints [15]. The essence of this protocol can be visualized by “A

case in point being the recent CSP network failures caused by computer executing the SS7 in the East and West coasts and to the ATST (January, 1990) network which suffered a wide-spread SS7 related outage caused by timing interactions between recovery programs in its Intelligent *etwork (I*)” [15]. Author delineates that the SS7 network failure can be severe and lead to

whole network (mainly prepaid mobile services) failure.

A node in a SS7 network is called signaling point (SP). There are several signaling points such as Service Control Points (SCP), Signal Transfer Points (STP) (Figure 3.2-1). SCP is generally a database used for transaction control purposes of different services. A signaling point generally sends queries to SCP and corresponding responses are returned back [15].

Whereas STP is a signaling switch that routes & transports SS7 message packets by manipulating the received message and based upon its configured routing table. As in Figure 3.2-1, STP’s are generally designed in parallel of two or more for redundancy, so that if one STP fails the other node (redundant ones) can take over the load during failure scenario [15].

(23)

Figure 3.2-1: Sample CCS# (Common Channel Signaling system) physical network [15] [16]

When a call is initiated from an end point, it is required to identify proper SCP for information purposes. Identifying or addressing the SCP is handled in a special way using SS7 addressing mechanism [15]. Each SCP in the network is identified through a unique code which is assigned for that node [15]. Each message signal unit (MSU) that contains a SS7 message, ships with routing table information, calling or called address and SCCP address to decide a proper SCP node [15].

3.2.1. Measurement Approach

Atoui delineates response time measurement methodology for SCP by using the SS7 network with respect to a signaling point. As described in section 1, performance of a SCP is very important along with SS7 network with the Figure 3.2-1 design approach to be considered for IN systems.

As depicted in Figure 3.2.1-1, assume that “source signaling point” initiates a transaction query request at time T1. This request traverses through the SS7 network (passing through switches and signal transfer points) and reaches the target SCP at time T2. SCP application services take

(24)

its own time to process the query request and response back to the network at time T3. This response via SS7 network is returned back to originator signaling point [15].

Figure 3.2.1-1: Performance measurement methodology

Total round trip time for processing a query at signaling point end = (T4-T1) unit

Time taken by SCP application services to process a query and generate a response = (T3-T2) unit

Time taken by SS7 network for processing this query = (T4- T1)-(T3-T2) unit

The total response time is the sum of time taken by the network and time taken by the SCP services for processing the request. Generally, the signaling point waits for 3 or 4 seconds after sending a query request before being timed out [15].

3.3. Methods for Communicating SS7 Messages over a

Packet-Based #etwork Using a TALI

A US patent on SS7 message communication [17] using packet based network through transport adapter layer interface (TALI) defines a fascinating mechanism of using stream based TCP/IP network for telecommunication purposes.

Traditional telecommunication requires a SS7 signaling network for communication establishment and termination. A signaling telecom network includes signaling nodes such as service switching point (SSP), signal transfer points (STP) and service control points (SCP) [17]. Traditional TCP/IP communication is more reliable and takes immense time for connection establishment, termination and error handling. But telecommunication networks require fast network activity.

Although the SS7 signaling network is very suitable for telecommunication with reliability, it requires the user’s fixed bandwidth without considering traffic volume which becomes much

(25)

more expensive to bear [17]. However, TCP/IP network is more widely used, less expensive; bandwidth is possible to share among multiple users [17].

To make proper use of the TCP/IP network in telecommunication, this patent introduces another layer called TALI that ships in between SS7 and the TCP/IP protocol stack as per Figure 3.3-1. The TALI layer takes control over TCP/IP, to handle communication establishment, termination and message packet handling.

Figure 3.3-1: TALI layer controls SS7 over TCP/IP network [17]

3.3.1. Measurement Approach

The patent exhibits performance measurement of the round-trip time for end-to-end communication in a signaling network between two nodes. The measurement methodology has been portrayed using an algorithm as in Figure 3.3.1-1 [17].

(26)

Figure 3.3.1-1: Round-trip time calculation using TALI layer [17]

If we consider two signaling nodes as node-1 and node-2, to establish a connection, node-1 sends one monitor message packet that contains local TALI layer timer value, over TCP/IP network. This message packet is being received by signaling node-2 from TCP/IP network and TALI layer of node-2 responds with acknowledgement message with the timer timestamp of node-2 TALI layer.

Once node-1 TALI layer receives the acknowledgement message, it reads local timer value and computes the round-trip time as depicted in Figure 3.3.1-1.

3.4. Performance Evaluation of the Stream Control

Transmission Protocol

(27)

improvements include order of arrival delivery, multiple messages packed into single SCTP packet and inclusion of network level fault tolerance. The higher performance requirement of SS7 is matched with inclusion of these changes in SCTP.

In [1], the author presents an analytical and numerical method for analyzing the performance of SCTP (Stream Control Transmission Protocol). Here, we will concentrate on the numerical analysis pf performance rather the analytical model. Figure 3.4-1 depicts the test bed for the performance measurement of SCTP. An open source SCTP prototype implementation (SCTPlib) was used to generate the required data. The test bed consists of a SCTP-client and a SCTP-server connected over LAN. The signaling traffic generated by the client is sent over the LAN to the server. The server responds to it by a termination call. The client performs the statistical calculation of performance. It is acknowledged that the delay analysis (performance) is an important criterion for QoS (Quality of Service) of SS7 [2].

Figure 3.4-1: SCTP Test Bed Architecture [1]

Figure 3.4-2 depicts the performance of SCTP under the exponential service time and constant service time. The graph is drawn with transmission delay (in millisecond) against the arrival rate (messages per millisecond). Poisson defines the inter-arrival time as exponential when the distribution of the inter-arrival time and service follow an exponential distribution.

(28)

Figure 3.4-2: Mean Signaling Message Transimission Delay Over IP #etwork [1] Observation: The transmission delay in high when the arrival rate of messages is less as well as

very high. During the experiment, the SS7 message length was 279 bytes, the IP header was 32 bytes. The maximum transmission unit was of 1500bytes and hence 4 messages were packaged into one SCTP packet. The experiment tests only the SCTP (network layer protocol) of the stack. The author performs the end-to-end delay measurement. There is no specific mention to the effect of an operating system call on the performance of the SCTP. This experiment is pure measurement of SCTP and no specific application oriented measurement is mentioned. Table 2 depicts our observation of the experimental setup.

Table 2: Environmental Factors during Measurement - 1

Sl #o `Q Specification

1. Measurement Transmission delay (Performance) of SCTP protocol 2. Network architecture As shown in Figure 3.4-2. Client-Server

architecture.

3. Effect of operating system No mention to effect of OS as this parameter is kept constant.

4. Machine No mention to hardware (Expected to be a normal desktop)

(29)

Sl #o `Q Specification

7. Network IP network (Local area network)

8. Network load Measured for exponential and normal service time. 9 Machine load Dedicated machine with no other user/program.

3.5. Performance Analysis of CCS#, based on SS#7

The Signaling System #7 (SS7) protocol forms the backbone of ISDN (Integrated Services Digital Networks) and IN (Intelligent Networks) in call controls and inter-exchange message signaling. SS7 hold fast a high QoS (Quality of Service) in call communication. Performance and reliability form an important aspect of QoS. The physical architecture of signaling network consists of SEP (Signaling end point), STP (Signaling transfer point) and Linksets. In ISDN, each SEP consists of MTP, SCCP, ISDN-UP and TCAP layers. STP consists of MTP and SCCP. These are the layers of SS7 that exists in SEP.

In [3], the author evaluates the mean end-to-end delay of single-mate pair (SMP) CCSN (Common Channel Signaling Networks). This evaluation is performed under normal state as well as under different failure states. The paper also analyses the failure rate of STP. The author represents a comparative analysis of SS7 with OSI model, followed by a mathematical and numerical model of performance analysis. Our area of focus is the numerical analysis of performance in the CCSS systems.

Figure 3.5-1 depicts the considered physical network of the performance analysis. The network consists of 16 Linksets with four SEPs and 4 STPs. The links between the STPs and SEP is as shown in Figure 3.5-1.

(30)

Figure 3.5-1: CCS# (Common Channel Signaling system) physical network [3]

Figure 3.5-2 depicts the basic ISDN call setup. It consists of call setup, conversation and call release phases. In the call setup phase, the originating SEP sends IAM (Initial Address Message) which is transmitted to the destination SEP over two STPs. Each of this transmission adds delay. This is acknowledged by the ACM (Address Complete Message) and ANM (Answer message) message from the terminating SEP. Similarly during the call release phase, REL (Release) and RLC (Release Complete) messages are exchanged.

Figure 3.5-2: Call Scenario in Basic ISD# Calls [3]

Observation: The result is the mean end-to-end delay in ISDN under various call arrival rate.

(31)

instead the call setup time is measured. The author measures the performance and reliability together with emphasis on if the measurement are made on different setup then the QoS cannot be verified.

Table 3: Environmental Factors during Measurement - 2 Sl #o Environment Specification

1. Measurement Mean end-to-end delay in a SS7 network 2. Network architecture As shown in Figure 3.5-1. Network with 16

Linksets, 4 SEPs and 4 STPs

3. Effect of operating system Measured on Nodes with no specific mention to OS

4. Machine Single processor machine

5. Operating System Node OS (No specific mention)

6. Memory Single queue buffer in node

7. Network Linksets

8. Network load Tested under different call arrival rate 9 Machine load Dedicate nodes used with varied load

3.6. Application Protocols and Performance Benchmarks

FTP (File Transfer Protocol) is a well know application layer protocol in TCP/IP stack used for file transfer over internet. FTAM is an application layer protocol standard for OSI (Open System Interconnection). SunRPC and ROSE are two well known providers of transaction services for comparison. An interesting aspect of comparison is that ROSE and FTAM are standard OSI formats whereas FTP and ROSE do not meet the standard of OSI.

The author in [8], measures the performance and throughput of these four protocols in a systematic manner. The setup consists of initiator-responder architecture. SPIMS (SICS Protocols Implementation Measurement System) is the tool used for measurement. There are 3 phases of measurement starting with setup of the experiment with two or more computers. The

(32)

second generates the messages that are passed through the protocol stack. The third stage measures different parameters at the initiator’s end. There are 3 measurement parameters in the tool. The tool has RPC (Remote Procedure Call) to find the response time. Bulk_Get measures the throughput from responder to initiator. Conn_disc measures the connection open and connection disconnection time.

Figure 3.6-1: RPC, Bulk_get and Conn_disc time [9]

Observation: As a result, the graph of response time to user message size is drawn to see the

latency (delay) of the application layer protocol under different user message sizes. The measurement is carried out under a strict environment with keeping most of them constant to avoid the effect. The measurement tool has an independent part which is measurement of the response time and throughput. The system dependent part generates the traffic to push it through the stack to the responder.

Table 4: Environmental Factors during Measurement - 3 Sl #o Environment Specification

1. Measurement Application layer protocols (FTP, FTAM, SunRPC, ROSE). Measurement of throughput

(33)

Sl #o Environment Specification

2. Network architecture Initiator-Responder 3. Effect of operating system Not part of experiment

4. Machine SUN 3/60 (diskless)

5. Operating System Standard SunOS 3.5

6. Memory 4MB

7. Network Ethernet

8. Network load Some sample routing traffic (No network load measured)

9 Machine load Single user machine with no other application running

3.7. Processing and measuring SS7 message signal units

(MSU’s)

A US patent on collecting and processing SS7 message signal units (MSU’s) portrays processing mechanism of call data records (CDR’s) for telecom billing perspective [22].

CDR is the ultimate unit of performing billing activity in telecom systems i.e. how much to bill a particular customer. Hence generating these CDR’s is a challenge for telecom networks. Telecom systems make use of SS7 MSU’s to generate these CDR as described in Figure 3.7-1.

(34)

Figure 3.7-1: CDR processing architecture [22] Processing Methodologies:

Telecom nodes 104 and 106 are the signal transfer points (STP) that are used for SS7 communication in telecom networks. 102 and 100 are the links i.e. physical links to other STPs. There are two monitoring devices 108 and 110 that are used for collecting MSU’s that travel through physical links 100 & 102. 114 and 112 are the listeners that monitors the physical path and picks up SS7 MSU’s and forwards to 116 and 118 CDR generator component inside the monitoring device.

Here, each STP node in the network is associated with one monitoring device for CDR capturing and processing. However, there is one main STP node 124 that resides at the service provide premises and download CDRs from each monitoring devices such as 108 and 110. Finally it maintains the whole subscriber bases CDRs for forwarding to billing systems in its database.

(35)

3.8. Tele-traffic simulator with SS7 for circuit switched and

intelligent network

The Signaling System no 7 has been widely used by intelligent networks and circuit switched networks for voice call performance in telecommunication network. Figure 3.8-1 portrays a hybrid network architecture that delineates how the SS7 protocol is being used for voice call set-up and tearing down a connection in a network. The author delineates how this paradigm has been used to build a simulator for real life telecom network performance and guides for real time measurement.

Figure 3.8-1 depicts that customer premises are connected with end offices (EO). When a customer makes a call, it connects with toll-offices that build a trunk for voice calls. As soon as an EO gets a connection establishment request from customer premises, it takes help of the SS7 protocol by requesting a nearby service switching point (SSP) to establish the connection. SSP again takes benefit of a signal transfer point (STP) and a signal control point (SCP) to locate the recipient and establishing voice trunk as depicted in Figure 3.8-1.

Figure 3.8-1: Hybrid network architecture [23]

The author introduces one simulator based upon the architecture in Figure 3.8-1 that simulates real life telecommunication network and measures end-to-end performances by means of the SS7 protocol.

(36)

The simulator provides a user interface (UI) based display that allows the user to experiment with different control switches that can be regulated according to real life scenarios. However, the simulator does not simulate all the protocol layers of SS7. Rather concentrate only on SCCP and TCAP as the other layers are used mainly for data framing, transport and application services.

Simulator depends on two factors. Dynamic factors can be represented through creation, execution and termination of processes, whereas static factors typically are system resources like storage, memory.

3.9. Tools on SS7 Performance Analysis:

Table 6 presents the commercially available tools for measurement of the SS7 protocol. As these are commercially available, we have chosen not to present them in this report. In a later stage, the different measurement aspects of these commercial tools can be considered as an input while we carry out measurement of the SS7 protocol stack.

Table 5 depicts two protocol performance measurement open source tools namely, IPerf and NetPerf which are widely used for throughput and latency measurement of SCTP, TCP and UDP protocols.

Table 5: Open Source Tools for SS7 Performance Analysis

Sl #o Tool #ame Protocol Measured Company Reference

1 IPerf SCTP (transport layer of SigTran), TCP and UDP

Open Source (An HP Associate)

[24]

2 NetPerf SCTP, TCP and UDP Open Source (National Laboratory for Applied Network Research)

(37)

Table 6: Commercial Tools for SS7 Performance Analysis Sl #o Tool #ame Protocol

Measured Company Reference 1 Jade simulation environment, SS7 performance Jade Simulations International [4] 2 Lite 3000/3000E SS7 Protocol functionality SS7 performance NetTest A/S [5] 3 UniSS7 SS7 performance TELOGIC [6] 4 Acterna 8620 SS7. Network management performance SS7 performance ACTERNA [7] 5 SS7 Simulation Suite SS7 Simulation and testing Sunrise Telecom [8]

(38)

4. Protocol Performance Measurement Methodology

4.1. Complete Stack Measurement

To perform SS7 stack performance measurement, sample architecture could be as portrayed in Figure 4.1-1. Source application in signaling node 1 is the application, service or tool that injects request message to the SS7 protocol stack. Time stamping service is a service that writes timestamp in a log before dispatching a SS7 message packet to the network and after receiving a SS7 message packet from network. Target application in signaling node 2 is the application, service or tool that processes SS7 request messages and generates response messages.

Figure 4.1-1: Performance measurement approach

According to Figure 4.1-1, at T1 time period a sample message is generated and injected through SS7 stack which propagates through Time stamping service. This time stamping service writes timestamp T2 in a log before dispatching it to the network.

Similarly, at signaling node 2, the time stamping service writes timestamp T3 in a log after receiving a message packet from the network and before forwarding it to the upper layer.

• At time period T4, the target application or service receives the request message and starts processing of the same.

(39)

• At T5, this target application or service generates response message and responds to the caller.

• At T6, time stamping service writes timestamp T6 in a log before dispatching the response packet to the network.

• Again at T7, the response packet is received by signaling node 1 and its time stamping service writes T7 in its log.

• At T8, the initiating application or service in signaling node 1 receives the response. • Time taken to forward a request message by SS7 stack in signaling node 1 = (T2-T1) unit • Time taken to receive the response message by source application (after processing of

SS7 stack) in signaling node 1 = (T8-T7) unit

• Time taken by signaling node 2 after receiving a request message and generating response = (T6-T3) unit

• Time taken by target application in signaling node 2 to process a request message = (T5-T4) unit

• Time taken by network = (T3-T2) + (T7-T6) unit

• Round trip time required for processing a request by the source application in signaling node 1 = (T8-T1) unit

4.2. Stack Layer Measurement

A hypothetical measurement methodology is portrayed in Figure 4.2-1 and derived from the concept depicted in Figure 3.3.1-1.

(40)

Figure 4.2-1: SS7 stack performance measurement methodology

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.

(41)

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

(42)

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.

(43)

• 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.

(44)

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

(45)

16384 614 578

32768 678 569

Table 8: TCP Performance

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.

(46)

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

(47)

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.

(48)

(49)

(50)

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

(51)

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.

(52)

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].

[6] UniSS7 Network Monitoring and Management Solution, Available:

http://www.telogic.com.sg/PDF/UniSS7%20Brochure.pdf. [Accessed: 2009-02-18]. [7] Acterna 8620 SS7. Network management performance. Available:

http://www.telintech.ru/data/pdf/a8620.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 tobias@ccc.de, “Locating Mobile Phones using Signalling System #7” - http://berlin.ccc.de/~tobias/25c3-locating-mobile-phones.pdf [Accessed: 2009-02-23] [12] “SS7 tutorial” - http://pt.com/page/tutorials/ss7-tutorial [Accessed: 2009-02-23] [13] Gerry Kirstensen, “Mobile Networking” -

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 Packet Platform” -

http://www.ericsson.com/ericsson/corpinfo/publications/review/2002_02/files/2002023.pdf [Accessed: 2009-02-23]

[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,

(53)

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

(54)

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

(55)

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

PROTOCOL PERFORMANCE MEASUREMENT METHODOLOGY - EXPERIMENTATION WITH SIGNALING SYSTEM NO 7

Abstract

Table of Contents

List of Figures

List of Tables

Acknowledgements

1. Introduction

1.1.

Outline

1.2.

Prerequisite Knowledge

2. Background

2.1.

Telecommunication Mobile #etwork

2.2.

CPP Platform

2.2.1. CPP Platform for 3G mobile network

2.3.

Signaling System #o 7

2.3.1. Open Signaling System #o 7

2.3.2. SS7 over IP

2.3.3. Analogy of Open SS7 and CPP SS7

3. Related Work

3.1.

Literature review methodology

3.2.

Performance Measurement of SS7/Intelligent #etwork.

3.2.1. Measurement Approach

3.3.

Methods for Communicating SS7 Messages over a

Packet-Based #etwork Using a TALI

3.3.1. Measurement Approach

3.4.

Performance Evaluation of the Stream Control

Transmission Protocol

3.5.

Performance Analysis of CCS#, based on SS#7

3.6.

Application Protocols and Performance Benchmarks

3.7.

Processing and measuring SS7 message signal units

(MSU’s)

3.8.

Tele-traffic simulator with SS7 for circuit switched and

intelligent network

3.9.

Tools on SS7 Performance Analysis:

4. Protocol Performance Measurement Methodology

4.1.

Complete Stack Measurement

4.2.

Stack Layer Measurement

5. An Experimental Approach to Measure Performance

5.1.

Experimentation

5.2.

IPerf Performance Measurement Tool

5.3.

Results

5.4.

Analysis

6. Summary and Conclusion

7. Future Work

References

Appendix A - Acronyms