See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/263778191

Design and Analysis of IP Multimedia Subsystem (IMS).

Thesis · July 2011

CITATIONS READS

0 8,095

1 author:

Wagdy Anis Aziz

Ain Shams University
24 PUBLICATIONS   17 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

High Availability Solution over Hybrid Cloud Using Failover Clustering Feature View project

Performance Evaluation of VoWiFi (Voice over WiFi) Using IMS (IP Multimedia Subsystem) View project

All content following this page was uploaded by Wagdy Anis Aziz on 10 July 2014.

The user has requested enhancement of the downloaded file.

 AIN SHAMS UNIVERSITY
FACULTY OF ENGINEERING
ELECTRONICS AND COMMUNICATIONS ENGINEERING DEPARTMENT

DESIGN AND ANALYSIS OF IP MULTIMEDIA

SUBSYSTEM (IMS)
A Thesis
Submitted for Partial Fulfillment of the Requirements of the Degree of Doctor of Philosophy
in Electrical Engineering
(Electronics and Communications Engineering)

Submitted by

Eng. Wagdy Anis Aziz

B.Sc. of Electrical Engineering Ain Shams University, 1996
M.Sc. of Electrical Engineering Ain Shams University, 2006

Supervised by

Prof . Dr. Salwa Hussein El-Ramly Prof . Dr. Magdy Mahmoud Ibrahim
Professor of Communication Engineering Professor of Communication Engineering
Electronics and Communication Engineering Dept. Electronics and Communication Engineering Dept.
Faculty of Engineering Faculty of Engineering
Ain Shams Univeristy Ain Shams Univeristy

Dr. Mohsen Tantawy

Associate Professor, Network Department ,
National Telecommunication Institute (NTI),
Cairo, Egypt

Cairo 2011
 STATEMENT

This thesis is submitted to Ain Shams University for the degree of Doctor of
Philosophy in Electrical Engineering (Electronics and communication Engineering)

The work included in this thesis was carried out by the author in the Department of
Electronics and Communication Engineering, Ain Shams University.

No Part of this thesis has been submitted for a degree or a qualification at any other
university or institute.

Name : Wagdy Anis Aziz

Signature :
Date : / / 2011
 C.V.

Name of Researcher : Wagdy Anis Aziz

Date of Birth : 23 January 1973
Nationality : Egyptian
First University Degree : B.Sc. in Electronics and Communication
Engineering. Faculty of Engineering. Ain
Shams University.
Date of Degree : 1996
Second University Degree : M.Sc. in Electronics and Communication
Engineering. Faculty of Engineering. Ain
Shams University.
Date of Degree : 2006
 ACKNOWLEDGMENT

I wish to express my sincere appreciation to my supervisors Prof. Salwa El-

Ramly, Prof. Magdy Ibrahim and Dr. Mohsen Tantawy for their precious
instructions, kind care, their constructive advices, helpful and valuable
guidance, heartfelt cooperation, strong encouragement and valuable
comments during the course of this work. Moreover, Prof. S. El-Ramly, has
a continuous guidance during the whole work through numerous
discussions and meetings from which I learnt a great deal.

I would like to express my gratitude to my employer, The Egyptian

Company for Mobile Services (Mobinil) for providing me with the needed
freedom and flexibility for working on this thesis, my managers Rabie
Kader Gad and Khaled Atta and my colleagues Ahmed Marzouk, Medhat
Shoukry and George Nashaat. Further, without the support and
encouragement of my Mother and Father this thesis would have never been
finalized. Special thanks to my wife, Eng. Vivian Wanis for her support in
reviewing the thesis and her invaluable feedback.

I would like also to express my gratitude to Tekelec, Mr. Andre Baumann

and Dr. Dorgham Sisalem, for their great help and continuous support to
complete this thesis.

Finally, I am further obliged to Patrick Ruhrig, University of Applied

Sciences – Frankfurt ,Germany, Research Group for Telecommunication
Networks, for help with configuring OpenSER and Dragos Vingarzan,
Fraunhofer Institute for Open Communication Systems - FOKUS, Berlin-
Germany , for many insightful discussions.

i
 ABSTRACT

Wagdy Anis Aziz. Design and Analysis of IP Multimedia Subsystem

(IMS). Doctor of Philosophy, Ain Shams University, Faculty of
Engineering, Electronics and Communication Engineering Department,
2010.
Over the last years the IP Multimedia Subsystem (IMS) has
continuously gained in importance as the next generation communication
network. The Session Initiation Protocol (SIP) was chosen the signaling
protocol for session establishment and control in IMS.
The IP Multimedia Subsystem (IMS) is the technology that will
merge the Internet (packet switching) with the cellular world (circuit
switching). It will make Internet technologies, such as the web, email,
instant messaging, presence, and videoconferencing available nearly
everywhere.
IP Multimedia Subsystem (IMS) has resulted from the work of the
Third Generation Partnership Project (3GPP) toward specifying an all-IP
communication service infrastructure. Mainly looking at the needs and
requirements of mobile operators, the 3GPP first specified IMS as a service
architecture combining the Internet’s IP technology and wireless and
mobility services of current mobile telephony networks. After that the IMS
architecture was extended to include fixed networks as well. By deciding to
use session initiation protocol (SIP) as the signaling protocol for session
establishment and control in IMS instead of developing its own set of
protocols, 3GPP has opened the door toward a tight integration of the
mobile, fixed and Internet worlds. Recent reports already indicate that there
are more than 200 million subscribers using the IMS technology for
telephony services.
Measuring the capacity of the (IMS) controllers is very important due
to the critical role it plays in the Next Generation Network (NGN) of the
Fixed and Mobile Networks. This thesis proposes a robust and scalable
method that can be used to measure the capacity of the IMS controllers,
Call Session Control Function (CSCF) and benchmark their different
vendors. The purpose of this method is to measure the capacity of the server
in terms of how many calls are routable into a defined time interval and
what the consequences of overloading the system are.
Evaluating the IP Multimedia Subsystem (IMS) Performance is very
important due to the critical role it plays in the Next Generation Network
(NGN) of the Fixed and Mobile Networks. This Thesis proposes robust and
scalable methods that can be used to test the performance of the IP
Multimedia Subsystem (IMS) controllers, Call Session Control Function
(CSCF) and benchmark their vendors.
In this thesis we provide also a theoretical model that can be used by
operators and network designers to determine the effects of introducing
IMS to their networks in terms of bandwidth usage for example and the
effects of losses and delays on the service quality. This model uses as the
input various traffic characteristics such as the number of calls per second
and mean holding time and network characteristics, such as losses and
propagation delays. The output of the model provides details on the
bandwidth and delay needed for successfully establishing a session when
using SIP over UDP in IMS networks.
Voice traffic in IP Multimedia Subsystem (IMS) will be served using
Internet Protocol (IP) which is called Voice over IP (VoIP). This chapter
uses the "E-Model", (ITU-T G.107), as an optimization tool to select
network and voice parameters like coding scheme, packet loss limitations,
and link utilization level in IMS Network. The goal is to deliver guaranteed
Quality of Service for voice while maximizing the number of users served.
This optimization can be used to determine the optimal configuration for a
Voice over IP in IMS network.

Key words:
U

IMS, SIP, VoIP, CSCF, SIPp, OpenSER, OPNET, MOS, E-Model.

i
Thesis supervisor:

 Prof. Dr. Salwa Hussein El-Ramly

Professor of Communication Engineering,
Electronics and Communications Engineering Department,
Faculty of Engineering,
Ain Shams University,
Cairo, Egypt.

 Prof. Dr. Magdy Mahmoud Ibrahim

Professor of Communication Engineering,
Electronics and Communications Engineering Department,
Faculty of Engineering,
Ain Shams University,
Cairo, Egypt.

 Dr. Mohsen Tantawy

Associate Professor,
Network Department National Telecommunication Institute (NTI),
Cairo, Egypt.

v
 PUBLICATION ARISING FROM THIS THESIS

JOURNAL PAPERS

1. W. A. Aziz, S. H. EL-Ramly , M. M. Ibrahim , M. M. Tantawy

“IP–Multimedia Subsystem (IMS) Performance Evaluation and
Benchmarking” Ain Shams Journal of Electrical Engineering (A S J
E E), 2010. Paper ID: #440231, Vol (1), pp: 11-20, June 2010.

2. W. A. Aziz, S. H. EL-Ramly , M. M. Ibrahim , M. M. Tantawy

“Capacity Measurement for IP–Multimedia Subsystem (IMS)
Controllers " Ain Shams Journal of Electrical Engineering (A S J E
E) , 2010. Paper ID: #450044, , Vol (1), pp: 83-89, June 2010.

3. W. A. Aziz, S. H. EL-Ramly , M. M. Ibrahim, M. M. Tantawy

“Voice over IP (VoIP) Quality Optimization in IP–Multimedia
Subsystem (IMS) " Ain Shams Journal of Electrical Engineering (A
S J E E) , 2010. Paper ID: #450043, Vol (1), pp: 31-42, June 2010.

v
CONFERENCE PAPERS (FULLY REFEREED)

1. W. A. Aziz, S. H. EL-Ramly, M. M. Ibrahim “IP–Multimedia

Subsystem (IMS) Performance Evaluation and Benchmarking ",
SIBIRCON-2010, the IEEE Region 8 International Conference on
Computational Technologies in Electrical and Electronics
Engineering. Irkutsk (Listvyanka), Russia, from 11st to 15th of July
2010.PaperID:#67.http://ieeexplore.ieee.org/search/freesearchresult.j
sp?reload=true&newsearch=true&queryText=10.1109%2FSIBIRCO
N.2010.5555343

2. W. A. Aziz, S. H. EL-Ramly, M. M. Ibrahim “Capacity

Measurement for IP–Multimedia Subsystem (IMS) Controllers ",
CIMSIM 2010.Second International Conference on Computational
Intelligent, Modeling and Simulation, Bali 28-30 September 2010.
Paper ID: #1569346511

3. W. A. Aziz, S. H. EL-Ramly , M. M. Ibrahim “Voice over IP (VoIP)

Quality Optimization in IP–Multimedia Subsystem (IMS) ",
CIMSIM 2010.Second International Conference on Computational
Intelligent, Modeling and Simulation, Bali 28-30 September 2010.
Paper ID: #1569351243

4. W. A. Aziz, S. H. EL-Ramly , M. M. Ibrahim “A Theoretical Model

to Calculate the Bandwidth of IMS Session Establishment ",
ISMS2011. 2nd International Conference on Intelligent Systems,
Modeling and Simulation, Kuala Lumpur, Malaysia, Monday 24 January
2011 and Phnom Penh, Cambodia, Thursday and Friday 27 and 28 January
2011.Paper ID: #1569376849

i
 Table of Contents

Acknowledgment i
Abstract ii
Publication Arising From This Thesis v
Table of Contents vii
List of Figures xiv
List of Tables xvii
List of Abbreviations xviii

CHAPTER 1 1
INTRODUCTION AND MOTIVATION
1.1 Introduction 1
1.2 Problem Statement 3
1.3 Thesis Contribution 3
1.4 Thesis Structure 4

CHAPTER 2 5
TELEPHONY EVOLUTION
2.1 Introduction 5
2.2 Motivation 6
2.3 Today’s Story-Exiting Technologies 9
2.3.1 GSM 10
2.3.2 GPRS 10
2.3.3 UMTS 11
2.4 Next Story-IP Multimedia Subsystem 11
2.4.1 Requirements of Communication Market 11
2.4.1.1 User Requirements 11
2.4.1.2 Enterprise Requirements 13
2.4.1.3 Operator Requirements 14
 2.4.2 What is IMS? 15
2.4.3 IMS Architecture Overview 16
2.4.4 IMS Major Components 17

CHAPTER 3 18
IP MULTIMEDIA SUBSYSTEM (IMS) ARCHITECTURE
3.1 Introduction 18
3.2 History 19
3.3 IMS Architecture 20
3.3.1 Access Network 21
3.3.2 Subscriber and User Equipment(UE) 23
3.3.2.1 User and Service in IMS 23
3.3.2.2 Subscriber Identity Modules (SIM) 25
3.3.2.3 Generation and Storage of User Identities 28
3.3.3 Signaling Components 29
3.3.3.1 Proxy Call Session Control Function (P-CSCF) 29
3.3.3.2 Interrogating Call Session Control Function (I-CSCF) 29
3.3.3.3 Serving Call Session Control Function (I-CSCF) 29
3.3.4 Interworking Components 30
3.3.4.1 Interconnection Border Control Function (IBCF) 31
3.3.4.2 Border Gateway Control Function (BGCF) 33
3.3.4.3 Media Gateway Control Function (MGCF) 34
3.3.4.4 Signaling Gateway (SGW)\ 34
3.3.4.5 Media Gateway (MGW) 34
3.3.5 QoS Related Components 35
3.3.6 Application and Service Provisioning Related Components 36
3.3.7 Database Related components 38
3.3.8 Charging in IMS 38

CHAPTER 4 41
IP MULTIMEDIA SUBSYSTEM (IMS) SIGNALING
ANALYSIS
4.1 Introduction 41
4.2 Protocols Used in IMS 41
4.2.1 Session Initiation Protocol (SIP) 41
4.2.1.1SIP Network Elements 42
4.2.1.1.1 User Agent (UA) 42
4.2.1.1.2 SIP Servers 42
4.2.1.2 SIP Request 44
4.2.1.2.1 INVITE 44
4.2.1.2.2 BYE 45
4.2.1.2.3 CANCEL 45
4.2.1.2.4 REGISTER 45
4.2.1.2.5 OPTIONS 46
4.2.1.3 SIP Response 46
4.2.1.4 SIP Session Setup 46
4.2.2 SIP in IMS 48
4.2.3Session Description Protocol (SDP) 48
4.2.4 Real-time Transport Protocol(RTP) 49
4.2.5 Real-time Transport Control Protocol(RTCP) 49
4.2.6 The Secure Real-time Transport Protocol (SRTP) 50
4.2.7 Diameter 50
4.3 IMS Interfaces or Reference Points 50

CHAPTER 5 54
CAPACITY MEASUREMENT FOR IMS CONTROLLERS
5.1 Introduction 54
5.2 Related Work 54
5.3 Experimental Test Bed 56
5.3.1 SIP Server Software 57
5.3.2 SIP Client Workload Generator 57
5.3.3 Client and Server OS Software 57
5.3.4 Hardware and Connectivity 57

x
 5.3.5 Experiments and Metrics 58
5.3.6 Restrictions, Limitations and Scope 58
5.4 Measurement Scenario 58
5.5 Results 60
5.6 Conclusion 64

CHAPTER 6 66
IP MULTIMEDIA PERFORMANCE EVALUATION
6.1 Introduction 66
6.2 Related Work 66
6.3 New Proposed Methods for IMS Performance Evaluation 67
6.3.1 FUZZING Testing (PROTOS) 68
6.3.2 Testing with Spectra 2|SE 78
6.4 Conclusion 81

CHAPTER 7 83
IMS SESSION SETUP ANALYSIS
7.1 Introduction 83
7.2 Related Work 84
7.3 Background 86
7.3.1 IMS Architecture 86
7.3.2 SIP in IMS 88
7.3.2.1 INVITE-retransmissions 90
7.3.2.2 Non-INVITE-retransmissions 90
7.4 IMS Session Establishment Phases 90
7.4.1 INVITE / 100 Trying (1-14) 92
7.4.2 Session Progress 183 / PRACK (15-26) 92
7.4.3 PRACK/ 200 OK (22-31) 92
7.4.4 UPDATE / 200 OK (32-41) 93
7.4.5 Ringing 180 / PRACK (42-52) 93
7.4.6 PRACK/ 200 OK (48-57): 93
7.4.7 Final Response (200 OK) / ACK (58-68) 93

x
 7.4.8 BYE / 200 OK 94
7.5 Modeling IMS Session Establishment 94
7.5.1 Modeling Retransmission of SIP Messages 94
7.5.1.1 Modeling the retransmission of the INVITE Request 94
7.5.1.2 Losses during INVITE Phase 97
7.5.1.3 Modeling the retransmission of the Non-INVITE Request 100
7.5.1.4 Losses during Non-INVITE phase 104
7.5.2 Bandwidth Consumption of IMS session establishment in a
Lossy Network 105
7.5.2.1 For INVITE/100 Trying phase 105
7.5.2.2 For Session Progress 183/PRACK /200 OK Phase 106
7.5.2.4 For UPDATE / 200 OK Phase 108
7.5.2.5 For Ringing 180 / PRACK / 200 OK Phase 108
7.5.2.6 For PRACK / 200 OK Phase 109
7.5.2.7 Final Response 200 OK / ACK Phase 109
7.5.2.9 Total Bandwidth Usage 110
7.5.3 Estimation of the IMS Session Establishment Delay 112
7.5.3.1 INVITE Phase Delay 112
7.5.3.2 Non-INVITE Phase Delay 113
7.5.3.3 Provisional Responses (183, 180) Delay 114
7.5.3.4 Total Delay 114
7.6 Conclusion 115

CHAPTER 8 116
VoIP Quality Optimization IN IMS Networks
8.1 Introduction 116
8.2 E-Model Parameters 118
8.3 The R-Factor 121
8.5 Description of E-Model Optimization 123
8.6 Assumptions for E-Model 124
8.6.1To Calculate The Delay Impairment Id 126

i
 8.6.2 To Calculate Equipment Impairment Ie 126
8.7 Mapping R factor Into MOS Scale 128
8.8 IMS Architecture for VoIP Quality Optimization 128
8.9 Project Setup 130
8.9.1 IMS Network Topology 131
8.9.2 Project Simulation Parameters 132
8.10 Results 132
8.10.1 Case 1 - Optimizing for Coder Selection 133
8.10.2 Case 2 - Optimizing for Coder and Packet Loss Level 137
Selection
8.10.3 Case 3 – Optimizing for Coder and Background Link 141
Utilization
8.10.4 Discussion of E-Model Optimization Results 145
8.11 Proposal to Enhance the E-Model 147
8.12 Conclusion 150

CHAPTER 9 151
CONCLUSIONS AND FUTURE WORK
9.1 Conclusions 151
9.2 Future Work 153

REFERENCES 155
 LIST OF FIGURES
Page
U

Figure 2.1 Network Evolution Trend 6

Figure 2.6 IMS Architecture 17
Figure 3.1 3GPP/TISPAN IMS Architecture Overview 20
Figure 3.2 IMS Access Networks 22
Figure 3.3 Relationships of the Private User Identity and Public 25
User Identities
Figure 3.4 UICC with ISIM and ID’s 28
Figure 3.5 Interworking of IMS with other Networks 31
Figure 3.6 Functional Structure of IBCF 33
Figure 3.7 Control and use plan correlation in IMS 36
Figure 3.8 Options for IMS Application Servers 37
Figure 3.9 Offline Charging Architecture 39
Figure 3.10 Online Charging Architecture 40
Figure 4.1 SIP Session Setup 47
Figure 4.3 IMS Interfaces 51
Figure 5.1 Test Scenario 59
Figure 5.2 Total numbers of calls created 61
Figure 5.3 Example output command “# top –d l -i -b” during the 62
Performance Test
Figure 5.4 Processor Load 63
Figure 5.5 Memory Utilization 64
Figure 6.1 Lab connection for FUZZING Test 71
Figure 6.2 PROTOS Test Scenario 71
Figure 6.3 PROTOS test trace for OpenSER Overflow-general, 'a' 72
(0x61) character overflows up to 128k
Figure 6.4 PROTOS test trace for OpenSER Overflow- general, 73
'a' (0x61) character overflows up to 128k
Figure 6.5 PROTOS test trace for OpenSER Overflow- 74
general, 'edv' (0x61) character overflows up to 128k
Figure 6.6 PROTOS test trace for OpenSER Format strings (eg. 75
%s%s%s or %.4097d)
Figure 6.7 Example output command “# top –d l -i -b” during 76
PROTOS Test
Figure 6.8 Processor Load during PROTOS test 77
Figure 6.9 Memory usages during PROTOS test 77
Figure 6.10 Lab connection for Spectra 2|SE Test 78
Figure 6.11 OpenSER Spectra2|SE Test Sample 79
Figure 6.12 OpenSER Spectra2|SE Test Result 80
Figure 6.13 Spectra 2|SE Test output 81
Figure 7.1 IMS Functional Elements 87
Figure 7.2 Basic session establishment scenario 91
Figure 7.3 The relation between R i and r at different values of l 96
Figure 7.4 The relation between R i and l at different values of r 97
Figure 7.5 The relation between le and l 98
Figure 7.6 The relation between R i and Pi at different values of 99
r
Figure 7.7 The relation between number of INVITE requests and 100
Pi + P100 at different values of r
Figure 7.8 The relation between R o and r at different values of l 103
Figure 7.9 The relation between R o and l at different values of r 104
Figure 7.10 The relation between L and η at different values of l 105
Figure 7.11 The Session Progress 183/PRACK/200 OK Phase 107
Figure 7.12 The relation between B, r and l at η = 2 and at µ = 112
5
Figure 8.1 The E-model 118
Figure 8.2 The E-model and its correlated metrics 121
Figure 8.3 E-model fault diagnosis 123
Figure 8.4 R-factor values from the E-model and corresponding 128
MOS values
Figure 8.5 IMS Functional Elements 130
Figure 8.6 IMS Network Topology 131
Figure 8.7 Average Packet End to End Delay 135
Figure 8.8 Number of Connected Calls for different codecs 136
Figure 8.9 R Value, Number of Calls vs. Coder – case 1 137
Figure 8.10 R Value and PL % vs. Coder – case (2) 140
Figure 8.11 R Value, Background link Utilization % vs. Coder – 144
case(3)
Figure 8.12 Background Link Utilization % and Id vs. Coder – 145
case (3)
Figure 8.13 PL % and Ie vs. Coder – case (2) 147
Figure 8.14 G.711 Polynomial Fit 148
Figure 8.15 G.729A Polynomial Fit 149
Figure 8.16 G.723.1 Polynomial Fit 149

v
 LIST OF TABLES
Table Page
U

Table 4.1 SIP Methods 57

Table 4.2 Response Codes 59
Table 4.3 Summary of Reference Points in IMS 76
Table 6.1 Exceptional Element Categories 109
Table 7.1 Retransmission Behavior of Invite Requests Due To 134
Network Losses in IMS Network
Table 7.2 Retransmission Behavior of Non-Invite Requests Due To 140
Losses in IMS Network
Table 7.3 Message Size For SIP Over UDP 150
Table 8.1 E-model related quality and satisfaction categories 156
Table 8.2 The R value and its correlation into subjective quality scores 156
Table 8.3 Provisional planning values for the equipment impairment
factor Ie in case of Ppl = 0 (no packet-loss) 164
Table 8.4 Provisional planning values for the equipment impairment
factor Ie and for packet-loss robustness factor Bpl 164
Table 8.5 Provisional examples for the advantage factor A 165
Table 8.6 Provisional planning values for the equipment impairment 169
factor Ie and for packet-loss robustness factor Bpl
Table 8.7 Codec Parameters 174
Table 8.8 Codec Parameters for case1-1 176
Table 8.9 Codec Parameters for case1-2 176
Table 8.10 case (1) results 181
Table 8.11 Codec Parameters for case 2 180
Table 8.12 Results for case (2) 181
Table 8.13 Results of E-Model Optimization Case (2) 182
Table 8.14 Codec Parameters for case 3 184
Table 8.15 Results for case (3) 185
Table 8.16 Results of E-Model Optimization Case (2) 187
Table 8.17 The total results of the optimization problem 188
 LIST OF ABBREVIATIONS
3G Third generation
3GPP 3rd Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
A Advantage Factor
AAA Authentication, Authorization and Accounting
ACK Acknowledgement
ACR Absolute Category Rating
AD Auditory Distance
AKA Authentication and Key Agreement Protocol
ANSI American National Standards Institute
ARPU average revenue per user
AS Application Server
ATM Asynchronous Transfer Mode
AUTN Authentication Token
B2BUA Back to Back User Agent
BGCF Breakout Gateway Control Function
BICC Bearer Independent Call Control
BPL Burst Packet Loss
bps Bit per second
BS Base Station
BSF Bootstrapping Server Function
BSN Body Sensor Networks
BU Binding Update
CAMEL Customized Applications for Mobile network Enhanced Logic
CAPEX capital expenditures
CBQ Class Based Queuing
CCI Call Clarity Index
CCR Comparison Category Rating
CDMA Code Division Multiple Access
CENS Center of Embedded Networked Sensing
CK Cipher Key
CMOS Comparison Mean Opinion Score
CN Corresponding Node
CNG Comfort Noise Generator
CODEC Compressor-Decompressor
CPU Central Processing Unit
CSCF Call Session Control Function
CVD Cardio Vascular Diseases
DCR Degradation Category Rating
Diffserv Differentiated Services
Dr D-Value of Telephone Receive Side
Ds D-Value of Telephone, Send Side
DSL digital subscriber line
DTM dual-transfer mode
ESP Encapsulating Security Payload
ETSI European Telecommunications Standards Institute
FEC Front End Clipping
FER Frame Error Rate
FFT Fast Fourier Transform
FMNB Frequency Measuring Normalizing Blocks
FR Frame Relay
FTTH fiber to the home
FWT fixed-wireless terminal
GBA Generic Bootstrapping Architecture
GGSN Gateway GPRS Support node
GoB Good or Better
GoS Grade of Service
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
HA Home Agent
HFMS Heart Failure Management System
HLR Home Location Register
HOT Hold Over Time
HRM Heart rate Monitor

i
HSPA high-speed packet access
HSS Home Subscriber Server
HTTP Hypertext Transport Protocol
IBCF Interconnection Border Control Function
ICS IMS centralized services
I-CSCF Interrogating-Call/Session Control Function
Id Delay Impairment Factor
IDE Integrated Development Environment
Ie Equipment Impairment Factor
IETF Internet Engineering Task Force
IK Integrity Key
IM Instant Messaging
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IMS-MGW IP Multimedia Subsystem-Media Gateway
IM-SSF IP Multimedia Service Switching Function
INMD In-service Non-intrusive Measurement Device
IP Internet Protocol
IPsec IP Security
Is Simultaneous Impairment Factor
ISDN Integrated Service Digital Network
ISIM IP Multimedia Subscriber Identity Module
ISP Internet Service Provider
ISUP ISDN User Part
ISWC International Symposium on Wearable Computers
ITU International Telecommunication Union
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LSTR Listener Side tone Rating
LTE 3GPP Long Term Evolution
MAA Multimedia Authentication Answer
MAR Multimedia Authentication Request
MC Multipoint Controller
MCU Multipoint Control Unit
MEGACO Media Gateway Control Protocol
MGCF Media Gateway Control Function
MIME Multipurpose Internet Mail Extension
MIP Mobile IP
MMD Multimedia Domain
MMTel IMS multimedia telephony services
MN Mobile Node
MNB Measuring Normalizing Blocks
MOS Mean Opinion Score
MP Multipoint Processor
MPA Mobile Phone Application
MRF Media Resource Function
MRFC Media Resource Function Controller
MRFP Multimedia Resource Function Processors
MSC Mobile Switching Center
MSRP Message Session Relay Protocol
MTU Maximum Transmit Unit
NAF Network Application Function
NAI Network Access Identifiers
NAT Network Address Translator
Nc Circuit Noise referred to 0 dBr-point
Nfor Noise Floor at the Receive Side
NINA Non-Intrusive Network Assessment
NIQA Non-Intrusive Quality Assessment
NNI network-to-network interface
NP Network Performance
OLR Overall Loudness Rating
OMA Open Mobile Alliance
OPEX operating expenses
OSA-SCS Open Service Access-Service Capability Server
PA Presence Agent
PAMS Perceptual Analysis Measurement System

x
PBX Private branch exchange
PC Personal computer
PCM Pulse Code Modulation
P-CSCF Proxy-Call Session Control Function
PDA Personal Digital Assistant
PDF Policy Decision Function
PDP Policy Decision Point
PDV Packet Delay Variation
PESQ Perceptual Evaluation of Speech Quality
PESQM Perceptual Echo and Sidetone Quality Measure
PGM Presence and Group Management
PLB Packet Loss Burst
PLC Packet Loss Concealment
PoC Push-to-Talk over Cellular
PoW Poor or Worse
Ppl Random Packet-loss Probability
Pr Room Noise at the Receive Side
PRACK Provisional Acknowledgement
PS Presence Server
Ps Room Noise at the Send Side
PSOM Perceptual Single-Ended Objective Measure
PSQM Perceptual Speech Quality Measurement
PSTN Public Switched Telephone Network
PTT Push-to-Talk
PUA Presence User Agent
qdu Number of Quantization Distortion Units
QoS Quality of Service
R Overall transmission quality rating
RAN Radio Access Network
RAND Random challenge
RCS Rich Communication Suite
RLR Receive Loudness Rating
RLS Resource List Server
Ro Basic signal to noise ratio
RPID Rich Presence Information Data Format
RSVP Resource Reservation Protocol
RTCP Real-Time Transport Control Protocol
RTP Real-time Transport Protocol
SAA Server Assignment Answer
SAR Server Assignment Request
SCN Switched Communication Networks
S-CSCF Serving- Call/Session Control Function
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
SGSN Serving GPRS Support node
SGW Signaling Gateway
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SLF Subscriber Location Function
SLR Send Loudness Rating
SMS Short Messaging Service
SMTP Simple Mail Transport Protocol
SNR Signal-to-Noise Ratio
SPP Serial Port Profile
SPU Signaling and Processing Unit
SQ Speech quality
SQN Sequence number
SQUAD Speech Quality Detector
SRTP Secure Real-time Transport Protocol
SR-VCC single radio voice call continuity
SSI Simple Sensor Interface
STMR Side tone Masking Rating
STQ Speech processing, transmission and quality aspects
T Mean one-way Delay of the Echo Path
Ta Absolute Delay in echo-free Connections
TCP Transmission Control Protocol
TELR Talker Echo Loudness Rating
THD Total Harmonic Distortion
TIA Telecommunications Industry Association
TIPHON Telecommunications and Internet Protocol Harmonization
Over Networks
TMNB Time Measuring Normalizing Blocks
ToS Type of Service
TOSQA Telecommunication Objective Speech Quality Assessment
Tr Round Trip Delay in a 4-wire Loop
TRU Transmit/Receive Unit
TTL Time to Live
UA User Agent
UAA User Authentication Answer
UAC User Agent Client
UAR User Authentication Request
UART Universal Asynchronous Receiver/Transmitter
UAS User Agent Server
UDP User Datagram Protocol
UE User Equipment
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identifier
USIM Universal Subscriber Identity Module
UTRAN Umts Terrestrial Radio Access Network
VAD Voice Activity Detection
VLR Visited Location Register
VoIP Voice transmission over the Internet Protocol
VPN Virtual Private Network
WAN Wide Area Network
WCBQ Weighted Class Based Queuing
WEPL Weighted Echo Path Loss
WFQ Weighted Fair Queuing
XCAP XML Configuration Access Protocol

i
XDMC XML Document Management Client
XDMS XML Document Management Server
XML Extensible Mark up Language
XRES Expected Response
Chapter 1 Introduction and Motivation

CHAPTER 1
INTRODUCTION AND MOTIVATION

1.1 Introduction

The Internet and mobile telephony services have been the two major
driving forces in the communication area in the last twenty years. On the one
side, the Internet has evolved from a tool for research and academia to a
commodity that is the basis for entertainment, communication and data
exchange in various aspects of our daily life today. Mobile phones, on the
other side have moved from an expensive gadget available only to a few
people to an affordable appliance that is used by people of various ages,
nationalities and wealth.

The IP Multimedia Subsystem (IMS) has resulted from the work of the
Third Generation Partnership Project (3GPP) toward specifying an all-IP
communication service infrastructure. The 3GPP is a collaboration agreement
that was established in December 1998 between a numbers of
telecommunications standards bodies. Mainly looking at the needs and
requirements of mobile operators, the 3GPP first specified IMS as a service
architecture combining the Internet’s IP technology and wireless and mobility
services of current mobile telephony networks. 3GPP has introduced IMS in
few phases (release 5, 6, 7 and release 8) [1-6]. Through the work of the
Telecoms and Internet converged Services and Protocols for Advanced
Networks (TISPAN), the IMS architecture was extended to include fixed
networks as well.

1
Chapter 1 Introduction and Motivation

The IMS concept was introduced to address the following network and
user requirements:

 Deliver person-to-person real-time IP-based multimedia

communications (e.g. voice or video-telephony) as well as person-to-
machine communications (e.g. gaming service).
 Fully integrate real-time with non-real-time multimedia
communications (e.g. live streaming and chat).
 Enable different services and applications to interact (e.g. combined use
of presence and instant messaging).
 Easy user setup of multiple services in a single session or multiple
simultaneous synchronized sessions [1-6].

Therefore, the IMS is the technology that will merge the Internet
(packet switching) with the cellular world (circuit switching). It will make
Internet technologies, such as the web, email, instant messaging, presence, and
videoconferencing available nearly everywhere. One of the reasons for
creating the IMS was to provide the Quality of Service (QoS) required for
enjoying, rather than suffering, real time multimedia sessions. The IMS takes
care of synchronizing session establishment with QoS provision so that users
have a predictable experience. Another reason for creating the IMS was to be
able to charge multimedia sessions appropriately. Furthermore, the aim of IMS
is not only to provide new services but also to provide all the services, current
and future, that the Internet provides. In addition, users have to be able to
execute all their services when roaming as well as from their home networks.
To achieve these goals, the IMS uses Internet technologies and Internet
protocols. So a multimedia session between two users over Internet is
established using exactly the same protocol. It is to be mentioned that, the IMS
does not depend on the circuit-switched domain [1-6].

2
Chapter 1 Introduction and Motivation

1.2 Problem Statement:

1. The capacity of IMS servers need to be dimensioned in terms of how

many calls or session per second could be supported by the IMS servers
and how to benchmark the different vendors of IMS.
2. The performance and the compliance of IMS servers need to be tested
in order to know the behavior of the IMS servers with respect to the
standard.
3. The design and analysis of IMS session set up is needed to be identified.
4. Voice traffic in IP Multimedia Subsystem (IMS) will be served using
Internet Protocol (IP) which is called VoIP, the quality of VoIP need to
be optimized.

1.3 Thesis Contribution:

This thesis covers the topic of design, analysis and QoS of IMS. The
primary contributions of this dissertation are as follows:
1. Proposing a robust and scalable method that can be used to measure the
capacity of the IMS controllers, Call Session Control Function (CSCF)
and benchmark their different vendors.
2. Introducing two methods that can be used to test the performance of the
IMS controllers.
3. Developing a theoretical model to dimension IMS session establishment
in terms of the needed Bandwidth and the estimated Delay of IMS
Session Setup.
4. Optimizing the VoIP quality over IMS Network using a new technique.

3
Chapter 1 Introduction and Motivation

1.4 Thesis Structure:

The rest of the thesis is organized as follows. In chapter 2, the evolution

of telephony networks is presented. The IMS architecture is introduced in
chapter 3. The IMS Signaling Protocols, Interfaces and IMS call scenarios are
presented in chapter 4.chapter 5 depicts a robust and scalable method that can
be used to measure the capacity of the IMS controllers. Two methods that can
be used to test the performance of the IMS controllers are presented in chapter
6. A theoretical model to dimension IMS session establishment is proposed in
chapter 7. A new mechanism is introduced to optimize the VoIP quality over
IMS is described in chapter 8. Finally, chapter 9 concludes the thesis with
recommendations for future work.

4
 Chapter 2 Telephony Evolution

CHAPTER 2
TELEPHONY EVOLUTION

2.1 Introduction

More than a hundred years later, telephones are a practical necessity,

along with an occasional annoyance. We all have at least two phones and even
children of elementary school age firmly believe that a mobile phone is one of
the most important gadgets they need to survive everyday life.
The vast majority of the telephony services used today is still broadly
based on the system envisioned by Graham Bell and use the concept of circuit
switching. In circuit switched networks, also known as public switched
telephone network (PSTN), the communicating parties are connected through a
circuit or channel with fixed bandwidth for the entire duration of the call. The
first experiments with transmitting voice over IP networks were conducted in
the early 1970s [7]. First commercial applications and devices appeared in the
mid nineties based on proprietary protocols. H.323 [8] was first published in
1996 and was the first widely deployed VoIP standard. The Session Initiation
Protocol (SIP) was first published in 1999 [9] and then updated in 2002 [10].
In recent years, SIP has increasingly gained in popularity and has become the
de-facto standard for public VoIP offerings and was adopted under the name of
IP Multimedia Subsystem (IMS) by the mobile telephony networks as the
signaling protocol for next generation networks.
This chapter describes the mobile communication technologies which
include 2G GSM, 2.5G GPRS, 3G UMTS and NGN. The core content is the
introduction of IP Multimedia Subsystem (IMS) about its major components,
architecture, protocols and service control mechanism. Reveal the reason why

4
 Chapter 2 Telephony Evolution

the industry gives IMS such a high expectation from the advantage of basic
architecture of service control feasibility.

2.2 Motivation

First of all, let's take a look at this network evolution diagram. We could
see the biggest architecture change is more clearly layered architecture. We
know that the network evolution brings us the boom of handset devices and
more wireless technology, and the users want richer content and mobile
experiences. The convergence of fixed and mobile even internet seems to be
the key for this demand, The division of application, control and connection
layers make the more and more complexes multi domain network simplified to
some extent. So what architecture do we have now for this division, how to
realize it?

Figure 2.1 Network evolution trend

In pace with more and more end-users equip themselves with the newest
high tech handsets and the understanding of what benefits the new generation
network can bring to them, customers would tend to consider real-time

5
 Chapter 2 Telephony Evolution

information and multi-media services as basic services. They require not only a
steady voice communications, but also to ask for data and multimedia
communications in various forms and more practical and commercial use. That
makes the operators must not only meet user needs, but also to changes in the
current era of communication to ensure their own strengths. This requires
operators to build a strong foundation for operation support network, to a rapid
increase in new business to improve the permeability and reduce the loss of
customers, maintaining its core competitiveness.

Here comes to some new creative ideas such as 3G, 4G, NGN (Next
Generation Network), and so on. The technology developers and operators
promise to offer voice, Internet access, video conferencing and access to
traditional broadcasting services to their subscriber and the provision of mobile
content and applications prospers, convergence would result at many levels
and opportunities would arise. For example, mobile network operators and
service providers will soon become information service providers. From the
users' point of view, a mobile phone will soon become a digital assistant and
an entertainment tool in addition to a host of other value-added functions.

In response to these demands and expectation, 3GPP advances the version

of the IMS standards. IMS is distributed and had nothing to do with access and
operational control of the joints characterized by open standards. The current
control of the industry thinks about the integration platform which is concern
about by major standards organizations and equipment providers and
operators. Currently, the 3GPP IMS, 3GPP2, ETSI, ITU-T standards have a
place in the group, to develop and improve the relevant standards are being
carried out, the world’s leading equipment suppliers like Alcatel, Siemens have
introduced commercial IMS products or trial, some operators have begun to
test for the IMS business or commercial pilot. IMS will gradually become the
core of the next generation network layer.

6
 Chapter 2 Telephony Evolution

There are a number of trend that we can identify related to new next
generation applications with the core of IMS:

1. We will be confronted with a large diversity of devices, such as:

 Handheld and mobile (Cellular phones, PDA’s, webpads, portable
computers)
 Wearable computing devices (on the body and in clothing)
 Embedded smart devices, sensors and actuators

2. There will be evolution in networks, such as:

 Several variants of wireless networks (indoor and outdoor) with their
own characteristics with respect to bandwidth, set-up, etc. and which
offer ad-hoc as well as controlled (managed) connections.
 Several types of wired networks, within scenarios such as the home,
car and public buildings and also for access networks
 More and more networks will move to the always-on connected type;
these networks will require permanent IP addresses (unlike the
temporary IP addresses assigned to dial-up devices).
 Bandwidth as well as quality of service will continue to improve.
However, there needs to be national government action to push
deployment of broadband Internet such as xDSL. Quality of service can
come from networks capacity over-provisioning, as well as classic IP
QoS techniques (e.g. differentiated services).
 Roaming of mobile devices across networks is needed; this includes
horizontal handover across cells from a network as well as vertical
handover across different networks. Users may expect to roam from a
wireless LAN network where it is available to a GSM, GPRS or 3G
network if a faster, cheaper alternative is not available. This has an
impact on available bandwidth and connection charges for the user.

7
 Chapter 2 Telephony Evolution

 GRID networks, where high-capacity links are put in place to enable

widely distributed processor clusters to handle and exchange data. The
GRID philosophy views the network and associated computing
resources as a "power-like" utility service. Research in optical
networking will lead to new, very high-speed networking.

3. There will be new types of services:

 Infotainment services offering all kinds of media formats in need of
support for non-streaming as well as streaming data including real time
captured streaming data.
 Multimedia communications service, including video-conferencing
and shared applications (e.g. shared viewing with Instant Messaging or
audio/video conference).
 Location-based services for people on the move, and allowing
location-specific content to be offered and delivered to users.
 An increase in push-based services.
 Inter-device communications, with the introduction of smart, agent-
based systems.
 Mobility of users as well as devices and applications is required.

So, will all of these prediction be realized in the future and bring so many
benefits for users and business? How to coordinate among mobile operators,
service providers and content providers and how to make the multi domain
service running robustly? And is there any guarantee for another crucial
problem- Security? These still needs further consideration.

2.3 Today's Story - Existing Technologies

There are several mobile wireless solutions for operators using Global
System of Mobile communication (GSM), General Packet Radio Service

8
 Chapter 2 Telephony Evolution

(GPRS) and Universal Mobile Telecommunication System (UMTS) access

technologies. This subchapter provides an overview of these technologies and
their roles in the evolution from second-generation (2G) to third-generation
(3G) mobile wireless networks.

2.3.1 GSM

Now GSM is a term that not only used in professional technology field,
but also a wide accepted fashion word when people enjoy all the fun brought
by modern mobile communication. GSM is Global System of Mobile
communication. It is, well known, currently the most widely used mobile
phone standard. Globally, more than 200 countries and regions and more than
one billion people use GSM phones. Compared with the previous standard, the
biggest difference of GSM is that the signaling and voice channels are digital.
GSM therefore is seen as second-generation (2G) mobile phone system.

From the point of view of the consumers, the key advantage of GSM
systems has been higher digital voice quality and low cost alternatives to
making calls such as text messaging. The advantage for network operators has
been the ability to deploy equipment from different vendors because the open
standard allows easy inter-operability. Like other cellular standards GSM
allows network operators to offer roaming services which mean subscribers
can use their phones all over the world.

2.3.2 GPRS

GPRS stands for General Packet Radio Service. GPRS is a non-voice

(data) service that allows information to be sent and received across a mobile
telephone network.

01
 Chapter 2 Telephony Evolution

It provides end-to-end, wireless IP WAN link. In short, GPRS is a high-speed

data-processing technology; the methodology is based on "clusters" in the form
of data transmission. Network capacity allocated only when needed, not when
released, such as CLR mode of delivery. At present, the GPRS mobile phone
network transmission speeds 115k/s. [11]

2.3.3 UMTS

The Universal Mobile Telecommunication System (UMTS) is a third

generation (3G) mobile communications system. UMTS could offer a quantity
of broadband wireless services to mobile communications. The UMTS delivers
low-payment, mobile communications at data rates of up to 2 Mbps. It
perpetuates the global roaming capability of second generation GSM/GPRS
networks and provides new enhanced capabilities [11]. The UMTS is designed
to deliver pictures, graphics, video communications, and other multimedia
information, as well as voice and data, to mobile wireless subscribers.

2.4 Next Story - IP Multimedia Subsystem

In this subchapter we will stress the ink to our core concept IMS. Stared
from the requirements from users, operators, enterprises, the paper will show
blueprint of the technology.

2.4.1 Requirements of communication market

2.4.1.1 User requirements

Today's telecom users are increasingly demanding. They are more

individualistic, independent, informed and involved than ever before, and
welcome services that appeal to their emotions as well as their practical needs.

00
 Chapter 2 Telephony Evolution

New, exciting services and enhancements to existing services have a key role
to play in making the communications experience much more like interacting
face-to-face. New advanced terminals and communication mechanisms
adapted for user needs will enable this and hide technical complexity [15].

 Affluent User Experience

Users are now used to obtain access of information, fun and other
content-rich services through a variety of channels. Telecom operators have a
great opportunity to integrate and extend the multimedia experience through
new highly personalized person-to-person, person-to-content and group
services. The widespread adoption of mobile telephony, SMS and Instant
Messaging shows how readily users adopt services that fulfill an emotional
need to communicate in a variety of ways. Operators can help users extend
such behavior with enriched services that enable users to discuss and
communicate in real time using any combination of voice, video, picture and
messages.

 Convenience and Ease of Use

Any new service has to be natural and intuitive to use if it is to be a

mass-market success. Today's subscribers are used to using mobile and fixed
phones anywhere in the world to call anyone. Similarly, they will expect new
services to offer a seamless experience across multiple access technologies,
devices and locations, whether wire line or wireless; narrowband, wideband or
broadband; business or personal. The user experience should also be consistent
across different device types. Interoperability between terminals and operators
is key . End-users are not concerned which operator their friends use, they
simply want the service to work. Voicemail, e-mail, mobile phones and
wireless LANs have already revolutionized how accessible subscribers are.

01
 Chapter 2 Telephony Evolution

Now subscribers are looking for ways to manage this reach ability or their
presence, so that they can control how, where, when and by whom they can be
reached. For example, research has shown that they would value simply being
able to see in advance who they can contact, and how.

 Safe Communication

Telephony services have always been reliable and largely immune from
curses of intrusion, viruses and spam attacks that have come to characterize the
Internet. IP-based multimedia communications services must be safe for
people to use. Free from malware or malicious attacks whether through their
mobile or fixed terminals. Users will also want reassurance that others cannot
gain unauthorized access to their personal services and information.

2.4.1.2 Enterprise requirements

Enterprise is always chasing lower costs and searching for ways of

operating their business more efficiently. Enterprises want to have control and
will demand flexibility in the way they handle their services such as
modifying, adding, and changing user information. Enterprises are made up of
individuals who have the same needs as those outline. However, there are
some requirements that are specific to or more obvious, the enterprise world.
Those needs are tailored to their work group or work environment.
New technologies are enabling new more flexible ways of working. For
example, the remote employee is a relatively new concept but is becoming
more common. Working at home, at airports or on the road is very convenient
when one has access to the same services as in the office- including presence
and stored information. It should be possible to reach remote employees using
a single address or number, regardless of location or access device.

02
 Chapter 2 Telephony Evolution

With the growth in distance working and international business

relationships, enterprise users need intelligent ways of bridging the distance
with smart tools like collaborative working and file sharing. Discussing a
document or having a conference remotely should be as natural as if both
parties were sitting in the same meeting room.
Security is an important requirement mainly from the IT departments.
The employees need to have secure access to functionality in the IT
environment from their mobile devices and the provisioning and management
of applications needs to be done in an efficient and secure way.

2.4.1.3 Operator requirements

In general, operators are looking for quick and flexible ways to respond
to new business opportunities. As users expand their voice telephony behavior
into multimedia services, operators want to be able to deliver a seamless and
consistent user experience wherever and however the services are accessed
[12].

 Spread Out Service Offerings And Revenues

There is one way to support service expansion by evolving the packet-

switched infrastructure that enables the creation and delivery of new user-to-
user multimedia services. This could be done in a way that protects the
operator business model and generates new revenue. Operators need to be able
to respond to new business opportunities flexibly and swiftly.

For third-party which develops to supply operators with a range of new

services need to meet customer demand and strong competition. This demands
service creation capabilities that are well connected to the service delivery
mechanisms.

03
 Chapter 2 Telephony Evolution

 Controlled Subscriber And Business Relationships

Both fixed and mobile operators face the permanent problem of

subscriber, and the issue is only increase as new service providers offer cheap,
or free, calls over the Internet. One key way to attract and retain subscribers is
to offer differentiation in areas like personalization, service bundling, co-
branding, business-to-business relationships, tariffs, single sign-on and quality
of service. The ability to bundle content and services in a way that is attractive,
fresh and flexible provides a strategic advantage. Mechanisms to handle
relationships with content and service providers need to be in place so that the
operator can stay in control of the end-user relationship and manage new
business models in a favorable way.

 Service Interoperability For Mass-Market Services

Experience shows that creating and expanding a mass market requires

standards-based solutions that enable interoperability in several dimensions.
Terminal-to-terminal interoperability is essential to create convenience and
clarity in users’ expectations of person-to-person communications services. At
the same time, interoperability between operators is necessary to give users the
freedom to roam between different networks. [13]

2.4.2 What is IMS?

Due to the various independent of networks, this has to become

competitive. In such cases, network integration technology has become a hot
topic [13]. Telecom experts hope to find a technology to bring all the network
access technology together to provide a unified business. To achieve such an
integrated network, it requires a network control technology. And this network

04
 Chapter 2 Telephony Evolution

control technology is independent of access network and the upper layer

application. Currently, most standards organizations have agreed on IMS.s
ability to achieve this network integration.
IMS (IP Multimedia Subsystem), is the technical standard originally
developed by 3GPP for the 3G core network which now has been approved by
ITU-T and ETSI (European Telecommunications Standardization Committee)
and added into the NGN (next generation network) in the core framework of
standards as an important basis of the future FMC (fixed / mobile network
integration). So far there are R5, R6, R7 and R8 four versions published by
3GPP. The R5 proposed All-IP network architecture using SIP control, mobile
management, and multimedia conversational signaling to achieve end-to-end
IP applications.
Although the IMS architecture was first specified by the Third
Generation Partnership Project (3GPP/3GPP2), it is now being embraced by
other standards bodies such as ETSI/TISPAN. IMS-based architectures and
services can be used across multiple access types, including GSM, WCDMA,
CDMA2000, xDSL, Ethernet and Wireless LAN. For most operators, the value
proposition for an IMS-based architecture lies in the ability to reuse common
functions across multiple applications. The layered IMS architecture allows
service providers to roll out new applications and services faster by reusing
well-structured and well-defined common functions such as service
provisioning, billing, group management, presence, and so on.

2.4.3 IMS architecture overview

3GPP IMS architecture is shown as figure 2.2. IMS applies SIP as core
call control protocol and provides multimedia call control business (such as
video phone Mandarin Tone). An IMS main entity includes CSCF, MGCF,
BGCF, MGFC, MRFP and HSS [1].

05
 Chapter 2 Telephony Evolution

Figure 2.2 IMS Architecture

2.4.4 IMS Major Components

In IMS Core:
• S-CSCF (Serving Call Session Control Function) － the key point in the
home network
• I-CSCF (Interrogating Call Session Control Function) －providing topology
hiding
• P-CSCF (Proxy Call Session Control Function) －entry point into IMS
world
• MS (Media Server). Media server hosting special resources
• MGF (Media Gateway) －interworking with legacy networks
• PDF (Policy Decision Function) － QoS Control using Policies (COPS)
In IMS Application Layer:
• HSS (Home Subscriber System) －maintaining subscriber and AS profiles
• AS (Application Server Function) －hosting applications
• IMS enablers specific ASs with generic functions [1]
The details for IMS architecture and the function of each component
will be presented in Chapter 3, IMS signaling analysis with more focus on SIP
protocol will be described in Chapter 4.

06
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

CHAPTER 3
IP MULTIMEDIA SUBSYSTEM (IMS)
ARCHITECTURE

3.1 Introduction

The IP Multimedia Subsystem (IMS) is an architectural framework

for delivering Internet Protocol (IP) multimedia services. It was originally
designed by the wireless standards body 3rd Generation Partnership Project
(3GPP), as a part of the vision for evolving mobile networks beyond GSM. Its
original formulation (3GPP R5) represented an approach to delivering
"Internet Services" over GPRS. This vision was later updated by 3GPP, 3GPP2
and TISPAN by requiring support of networks other than GPRS, such as
Wireless LAN, CDMA2000 and fixed line.

To ease the integration with the Internet, IMS uses IETF protocols
wherever possible, e.g. Session Initiation Protocol (SIP). According to the
3GPP [14], IMS is not intended to standardize applications but rather to aid the
access of multimedia and voice applications from wireless and wireline
terminals, i.e. create a form of fixed-mobile convergence (FMC). This is done
by having a horizontal control layer that isolates the access network from the
service layer. From a logical architecture perspective, services need not have
their own control functions, as the control layer is a common horizontal layer.
However in implementation this does not necessarily map into greater reduced
cost and complexity.

Alternative and overlapping technologies for access and provisioning of

services across wired and wireless networks include combinations of Generic

81
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Access Network, soft switches and "naked" SIP. It is easier to sell services
than to sell the virtues of "integrated services", but additionally the task to sell
an IMS based on a single service is also difficult as there are often (cheaper)
alternatives to creating and deploying that particular service.

Since it is becoming increasingly easier to access content and contacts

using mechanisms outside the control of traditional wireless/fixed operators,
the interest of IMS is being challenged [15].

3.2 History

 IMS was originally defined by an industry forum called 3G.IP, formed

in 1999. 3G.IP developed the initial IMS architecture, which was
brought to the 3rd Generation Partnership Project (3GPP), as part of
their standardization work for 3G mobile phone systems in UMTS
networks. It first appeared in Release 5 [2] (evolution from 2G to 3G
networks), when SIP-based multimedia was added. Support for the
older GSM and GPRS networks was also provided.
 3GPP2 (a different organization from 3GPP) based their CDMA2000
Multimedia Domain (MMD) on 3GPP IMS, adding support for
CDMA2000.
 3GPP release 6 [6] added interworking with WLAN, Inter-operability
between IMS using different IP-connectivity networks, routing group
identities, multiple registration and forking, presence, speech
recognition and speech-enabled services (Push to talk).
 3GPP release 7 [1] added supports for fixed networks, by working
together with TISPAN release R3.1, the function of AGCF (Access
Gateway control function) and PES (PSTN Emulation Service) are
introduced to the wire-line network for the sake of inheritance of
services which can be provided in PSTN network. Also added voice call

81
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

continuity between circuit switching and packet switching domain

(VCC), fixed broadband connection to the IMS, interworking with non-
IMS networks, Policy and Charging Control (PCC), emergency
sessions.
 3GPP release 8 [5] added supports for Long Term Evolution (LTE),
System Architecture Evolution (SAE), Multimedia Session Continuity,
Enhanced emergency sessions and IMS centralized services.

3.3 IMS Architecture

As illustrated in Fig. 3.1, the IMS architecture consists of a fairly large

number of components. These components should be seen as logical functions
and not as separate physical components, as more than one of those
components could be provided by a single physical device.

Figure 3.1 3GPP/TISPAN IMS Architecture over view [14]

02
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

These components can be roughly divided into the following functional areas:

• Access Network
• User equipment (UE): The UE is a SIP user agent with IMS specific
features such as support for QoS reservations and the IMS authentication
methods as well as the capability of accessing 3GPP network technology.
• Signaling Components: The IMS supports different call session control
functions that are responsible for routing the SIP messages between the
caller and callee.
• Interworking Components: The interworking components enable the
IMS subscribers to communicate with subscribers of other IMS or SIP-
based networks as well with legacy circuit switched (CS) networks.
• QoS: The QoS related components enable the signaling components to
interact with the underlying transport network.
• Application and Service Provisioning Servers
• Charging in IMS

The different components of an IMS network are illustrated in Fig. 3.1.

The communication between different components in IMS is described in
terms of reference points. A reference point indicates which protocols and the
message flows and contents used when two components communicate with
each other. The reference points will be described in details in Chapter 4.

3.3.1 Access Network

The user can connect to an IMS network in various ways, most of which
use the standard Internet Protocol (IP). IMS terminals (such as mobile phones,
personal digital assistants (PDAs) and computers) can register directly on an
IMS network, even when they are roaming in another network or country (the
visited network). The only requirement is that they can use IP and run Session
Initiation Protocol (SIP) user agents. Fixed access (e.g., Digital Subscriber

08
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Line (DSL), cable modems, Ethernet), mobile access (e.g. W-CDMA,

CDMA2000, GSM, GPRS) and wireless access (e.g. WLAN, Wi-MAX) are all
supported. Other phone systems like plain old telephone service (POTS—the
old analogue telephones), H.323 and non IMS-compatible VoIP systems, are
supported through gateways as shown in figure 3.2.

Figure 3.2 IMS Access Networks

00
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

3.3.2 Subscriber and User Equipment (UE)

The user equipment (UE) represents the devices and applications used by
the subscriber to initiate and receive multimedia sessions in IMS. In general,
the UE resembles a user agent (UA) as defined in [16] with a number of
extensions required for IMS networks. These extensions include a number of
SIP extensions that are mandatory for IMS as well as the support for IMS
related security and networking technologies.

3.3.2.1 User and Service Identities in IMS

In order to make sure that a call is routed to the correct user, the user must
have a unique identity that cannot be shared by any other user. In the PSTN,
these identities are phone numbers. Hence, when a certain phone number is
dialed in PSTN, a phone that belongs to a certain user will ring. While in
PSTN user devices, i.e., phones, are assigned unique identities, in IMS, the
users’ themselves are assigned unique identities. These identities are then
mapped to one or more devices through an explicit registration process. IMS
supports two kinds of user identities: public and private identities. The public
identity is used to route a call to the right user. Private identities are used by
the operator for internal purposes such as generating billing records.

 IMS Public User Identity (IMPU) Similar to a phone number or email

address, the IMS public user identity is a unique address that can be used
by a caller to contact the subscriber. Each IMS subscriber will have one or
more public identities. These identities can take the form of a SIP or SIP
SURI or a TelURI. The public identities are used by the IMS components
for routing SIP requests from a caller to a callee as well as for identifying
certain services used by the callee. Hence, in some sense the public
identity resembles the MSISDN (Mobile Subscriber ISDN Number) in

02
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

GSM [17]. Before the user is able to receive or initiate a call at least one
public identity must be registered with the IMS network. As the
subscriber might have several public identities, IMS defines implicit
registration sets. An implicit registration set consists of a number of
public identities. Once any one of the public identities in the set is
registered or deregistered all other identities of the set are registered or
deregistered as well.

 IMS Private User Identity (IMPI) The private user identity is used by
the network operator for various internal operations mainly concerning
user authentication, authorization, and accounting and administration
purposes. Each subscriber will have at least one unique identity and
possible more. The private identity has the format of a network address
identifier (NAI) [18] .That is, a private identity can be presented as
[email protected] for example. Unlike the public identity, a user’s
private identity is not used for routing purposes and is probably not even
known to the user. In some sense it resembles the usage of the IMSI
(International Mobile Subscriber Identity) in GSM [17].

 Public Service Identities (PSI) Public service identities are defined by

3GPP so as to enable users to directly access public services such as a
conferencing bridge or voice box. These identities can be a SIPURI or a
TelURI and indicate a certain service at an application server. Unlike
public user identities, a PSI is not related to a certain user. Relationship of
the Private User Identity and Public User Identities is presented in
figure3.3

02
 Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Figure 3.3 Relationships of the Private User Identity and Public User Identities

3.3.2.2 Subscriber Identity Modules (SIM)

The 3GPP specifications discuss not only IMS services but also IP based
services and 2G services. Each of these services has specific requirements
regarding the information needed for user authentication and controlling the
access to the services as well as the features supported at the user equipment.
Hence, 3GPP defines different identity modules for each type of service. These
modules have rather similar requirements in terms of processing needs,
memory and encryptions schemes. The Universal Integrated Circuit Card
(UICC) as shown in figure 3.4 is a microcontroller based access module that
provides the platform for the different identity module [19]. These identity
modules are:

 Subscriber Identity Module (SIM): The SIM module [20] is required for
accessing 2G services, i.e., circuit switched based GSM services. While in 2G

02
 Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

devices there was no distinction between the SIM and UICC, in 3G equipment
SIM is only an application running on top of the UICC and needs only to be
present on the device if it is to also access GSM services . The SIM stores
information required for accessing GSM services such as the phone number
and passwords.

 Universal Identity Module (USIM): The USIM [21] can be used by 3G

equipment to access both circuit switched and packet switched services, e.g.
2G and 3G services. It runs as an application on top of the UICC and stores
among other the following information:
– International Mobile Subscriber Identity (IMSI): The IMSI is a globally
unique identity, i.e., each IMSI is only allocated to one subscriber. The
IMSI is a private identity used by the operator for uniquely identifying
the user and for internal administrative purposes and is hence generally
not even known to the user. The first three digits on an IMSI are the
Mobile Country Code (MCC), and the next digits (2 in Europe and 3 in
North America) for are the Mobile Network Code (MNC).
– Mobile Subscriber Integrated Services Digital Network Number
(MSISDN): The MSISDN is the subscriber’s phone number.
– Authentication functions and information: The user is authenticated
towards the operator by proving that he knows a certain secret. The
USIM stores along term secret that in conjunction with a number of
cryptographic functions enables the user to authenticate himself towards
the operator.
– Ciphering and integrity keys: The ciphering and integrity keys are used
for securing the traffic sent by the user equipment. The USIM uses
separate keys for accessing packet and circuit switched services.
– Provider and access information: The provider and access information
indicate the name of the user’s provider, the preferred roaming partners
and list of forbidden access networks.

02
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

– Billing and charging information: The USIM might include information

indicating the price of a calling unit and the number of consumed
calling units.
– Special phone numbers: This includes numbers used for emergency
calls, special service numbers or barred phone numbers.
– Short message service (SMS): The USIM can include the list of
received and sent short messages as well as various related information
such as the address of the short message center to use or the supported
protocols.
– Multimedia message service (MMS): Similar to the short message
service, the USIM provides storage for sent and received multimedia
messages as well as various configuration parameters for this service.
– Various application related information such as Email address,
phonebook entries and configuration and location information.
– Administrative information such as the user’s preferred language and
parameters used for various access technologies.

 IMS Subscriber Identity Module (ISIM): The ISIM [22] is the identity
module used for accessing IMS services. The ISIM contains the following
information:
– Authentication functions and information: Similar to the USIM the
ISIM includes the necessary secrets and crypto graphic functions
needed for authenticating the subscriber towards the operator.
– IMS Private User Identity (IMPI): The ISIM stores one private user
identity.
– IMS Public User Identity (IMPU): The ISIM can store one or more
public user identities.
– Home network domain name: The SIPURI of the user’s home
domain.

02
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

– P-CSCF: In general it is expected that the UE would discover a close-

by P-CSCF to use. However, especially during the early deployment
of IMS, users might roam to networks in which no P-CSCFs are
deployed. In such a case the UE is expected to contact a P-CSCF in
home domain of the subscriber. As such P-CSCFs cannot be
discovered dynamically, the ISIM can be configured with the names
of one or more P-CSCFs to be used by the subscriber.

Figure 3.4 UICC with ISIM and ID’s

3.3.2.3 Generation and Storage of User Identities

In case the UE contains an ISIM application, then the user’s public and
private identities will be stored in the ISIM. However, especially during the
early deployment stages of IMS it is also possible to have a 3G UE with only a
USIM application. To still be able to participate in the IMS authentication
procedure, the IMPI and home network domain name will have to be generated
using the IMSI.

01
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

3.3.3 Signaling Components

The IMS components responsible for processing and forwarding SIP

messages are called” Call Session Control Function” (CSCF). Depending on
their functionality we can distinguish three types of CSCFs, namely proxy (P-
CSCF), interrogating (I-CSCF) and serving (S-CSCF). The communication
between control functions is conducted over the Mw reference point.

3.3.3.1 Proxy Call Session Control Function (P-CSCF)

The P-CSCF acts as the outbound proxy and the first point of contact for
the subscriber’s user equipment (UE). Hence, all SIP traffic sent or received
by the UE will traverse the P-CSCF. The communication between the UE and
the P-CSCF is conducted over the Gm reference point [23].Once a P-CSCF
was discovered all SIP traffic sent or received by the UE will traverse the
discovered P-CSCF.

3.3.3.2 Interrogating Call Session Control Function (I-CSCF)

In release 5 and release 6 as well as the first drafts of release 7, the I-

CSCF was the entry point of an IMS domain towards other IMS networks.
That is, if a request was destined to [email protected], then the DNS
resolution of example.com would lead to an I-CSCF belonging to the operator
of example.com. Since Version 7.2.0 of the I-CSCF is only the first entry point
[24].

3.3.3.3 Serving Call Session Control Function (S-CSCF)

The S-CSCF acts as the central component in an IMS network. Similar to

a SIP proxy, the major task of an S-CSCF is to receive requests, check the user
location and forward the requests to the callee or application servers.

01
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

When a user registers a SIP identity, an S-CSCF is allocated to the user and
this S-CSCF act as the home S-CSCF to this user for the duration of the user’s
registration.

The procedure for assigning a certain S-CSCF to a certain user is not

defined and is left to the provider. When a registration request is received at
the S-CSCF, the S-CSCF downloads authentication information from the HSS
and uses this information to authenticate the user. Once a user is authenticated,
all requests generated by this user or destined to this user will traverse the
user’s home S-CSCF.

3.3.4 Interworking Components

As IMS networks will only be gradually deployed, they will have to

interact not only with other IMS networks but also with the current dominant
technologies, namely circuit switched networks, e.g., SS7 based PSTN
networks, and SIP services conforming to [16]

As illustrated in Fig.3.5 two types of interworking components exist;

namely components are connecting the IMS network to circuit switched (CS)
networks which include the BGCF, MGCF, SGW and MGW and components
connecting the IMS network to other IMS networks or networks conforming to
the SIP specifications [16] which include the IBCF.

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Figure 3.5 Interworking of IMS with other networks [20]

3.3.4.1 Interconnection Border Control Function (IBCF)

The IBCF as shown in figure 3.6 acts as the interconnection component

between IMS networks and other IMS or SIP networks [25] . To be able to
accommodate different kinds of interaction scenarios, the IBCF provides the
following functionalities:

28
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

 TrGW (Transmission Gateway): Early designs of IMS specified IPv6 as

the network protocol for IMS based communication. This was mainly
driven by the assumption that due to the shortage of IPv4 addresses, IPv6
will be needed in order to support large numbers of IMS terminals. With
the advance of NAT traversal solutions for SIP, and the slow introduction
of IPv6, 3GPP decided to also allow the usage of IPv4 in IMS. The
transmission gateway (TrGW) is a NAT-PT/NAPT-PT (Network Address
Port Translator-Protocol Translator) [26]. The TrGW has a range of IPv4
and IPv6 address that it dynamically allocates to IMS sessions. The
TrGW also translates the IP headers at the media level (RTP/RTCP).

 IMS-ALG (Application Level Gateway): With the application level

gateway (ALG) functionality the IBCF acts as a back-2-back user agent
(B2BUA). The IMS-ALG maintains two independent signaling legs: one
toward the internal IMS network, i.e., the network to which the IBCF
belongs to, and the other toward another IMS or SIP network.

 Security related features: The IBCF is also tasked with screening SIP
messages and rejecting messages which do not fulfill certain operator
defined rules, e.g., include headers that are not allowed in the operators’
network. Further, the IBCF can remove certain IMS related headers such
as charging and authorization headers when sending messages to a non-
trusted network. Finally, the IBCF can provide the topology hiding
functionality (THIG).

The IBCF interacts with the session control functions over the Mx
reference point. The IMS-ALG communicates with the TrGW over the Ix
reference point. This reference point is described in details in Chapter 4.

20
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Figure 3.6 Functional structure of the IBCF

3.3.4.2 Border Gateway Control Function (BGCF)

The BGCF is a SIP proxy that routes SIP requests destined to a user in the
circuit switched domain using a dial plan. This dial plan indicates which
PSTN/CS gateways or other networks serve a certain phone number. When a
phone number is served by another network, then the BGCF forwards the
request to a BGCF in that network over the Mk reference point. Otherwise, the
request gets forwarded to an MGCF in the same network as the BGCF over the
Mj reference point.

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

3.3.4.3 Media Gateway Control Function (MGCF)

The MGCF is responsible for mapping of the session establishment

protocols between IMS and CS networks. The MGCF converts SIP signaling
into ISUP [27] over IP or BICC over IP [28]. On the IMS side, the MGCF acts
as an IMS UE that initiates and terminates SIP sessions. Besides converting the
protocols, the
MGCF also triggers the establishment of a media path at the Media Gateway
(MGW). The protocol between the MGCF and the MGW is H.248 [29].

3.3.4.4 Signaling Gateway (SGW)

While the MGCF is responsible for converting the SIP messages into
ISUP/BICC and vice versa the SGW performs lower layer protocol conversion.
The SGW translate the SCTP/IP transport [30] used in IMS with into MTP
[31] used in SS7 networks. The SGW does not interpret the application layer
messages but may have to interpret the underlying layer to ensure proper
routing of the signaling.

3.3.4.5 Media Gateway (MGW)

While the MGCF converts the signaling part of a call between an IMS
user and a CS user, the MGW converts the media, e.g. audio or video,
exchanged between the two. The MGW terminates the CS bearer and generates
Real Time Transport Protocol (RTP) [32] packets based on the received
content and vice versa. Besides unpacking the media content from the one
technology and packing it into the other, the MGW might perform transcoding
in case the codec used by the IMS terminal is not supported by the CS
terminal.

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

3.3.5 QoS Related Components

As already mentioned previously, one of the major differentiators of

IMS compared to plain VoIP services is the ability of the IMS providers to not
only provide session establishment but also offer the network resources needed
to guarantee the QoS of the established sessions. To achieve this, the IMS
signaling components, i.e., control plane, will have to be able to communicate
with the components responsible for providing the user with the IP access, i.e.,
user plane [33]. Access to IP resources in a UMTS network [34] is controlled
by the Gateway GPRS Support Node (GGSN). A user that wants to send and
receive IP packets over a UMTS network must establish a PDP (Packet Data
Protocol) context with the GGSN. As shown in figure 3.7, during the
establishment of the PDP context the GGSN authenticates the UE and
authorizes the QoS resources requested by the UE. As these resources should
mirror the media description signaled in the SDP part of the SIP messages a
close correlation between the session establishment process and the PDP
context establishment must exist. This correlation is achieved with the policy
decision function (PDF) which mediates between the P-CSCF and the GGSN.
When the P-CSCF receives a request for session establishment it informs the
PDF about the SDP content in the SIP messages over the Gq reference point
[35] which is based on the DIAMETER protocol [36]. When a GGSN receives
a PDP context activation or modification request from the UE it checks with
the PDF whether the requested resources mirror those that were signaled in the
SDP body during the session establishment. The communication between the
PDF and GGSN is achieved over the Go reference point which is based on the
Common Open Policy Service (COPS) protocol [37]. The PDF authorizes the
request based on local policies and provides its decision to the signaling and
transport components [38].

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Figure 3.7 Control and user plane correlation in IMS

3.3.6 Application and Service Provisioning Related Components

Application servers (AS) are SIP servers that host and execute services.
Application servers interface the S-CSCF over the SIP based Service Control
Interface (ISC). In general one can distinguish between native SIP application
servers that host and execute services based on SIP and application servers that
provide an interface between the IMS and legacy service infrastructures such
as the OSA-SCS and the IM-SSF. The Open Service Access-Service
Capability Server (OSA-SCS) provides an interface to the OSA framework
application server [39] which offers the capability to access the IMS securely
from external networks as shown in figure 3.8. The IP Multimedia Switching
Function (IM-SFF) [40] allows the IMS to reuse CAMEL (Customized
Applications for Mobile networks Enhanced Logic) [41] developed for GSM.
Both the OSA-SCS and IM-SSF act toward the IMS as SIP application servers
and as native OSA or CAMEL entities toward the OSA or CAMEL
infrastructures.

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Figure 3.8 Options for IMS Application Servers

A special kind of an application server is the Multimedia Resource

Function (MRF). The MRF provides media services such as multi party
conferencing sessions, announcements and transcending services and consists
of two components:

 Multimedia resource function processor (MRFP): This component

provides the resources needed for mixing streams for conferencing,
generating media streams for announcements or processing the streams
for transcending.
 Media resource function controller (MRFC): This component deals with
the signaling required for enabling the media services such as the
conference establishment. Based on the signaling requests, the MRFC
triggers the MRFP to actually provide the media services. The MRFC
controls the MRFP via the M preference point which is based on the
H.248 protocol.
The MRF communicates with the S-CSCF or an AS over the Mr reference
point which uses SIP.

22
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

3.3.7 Database Related Components

In IMS there are two main databases: the Home Subscriber Server
(HSS) and the Subscription Locator Function (SLF).
The HSS is the main database for storing all subscriber information and
service-related data. This includes the subscriber’s identity, the access
information needed for authenticating the subscriber and the subscriber service
profile which describes which services the user is subscribed to, which
application servers should be used when the subscriber is called or is
establishing a call. Further, the HSS maintains the subscriber’s registration
status and the address of the S-CSCF the subscriber is registered with. The
subscriber’s access, registration and profile information are used by the S-
CSCF for authenticating and authorizing the subscriber’s requests for services.
The I-CSCF, S-CSCF and AS contact the HSS when they need to
authenticate or authorize a request or require some subscriber-related
information. In case more than one HSS is deployed in an IMS network, the
SLF acts as a resolution mechanism that enables the I-CSCF, S-CSCF and AS
to find the HSS that holds the subscriber data for a certain user identity.
The I-CSCF and SCSCF communicate with the HSS via the Cx
reference point and with the SLF via the Dx reference point [42]. The AS
communicates with the HSS via the Sh reference point and with the SLF via
the Dh reference point [43]. The Cx, Dx, Sh, Dh reference points are based on
the DIAMETER protocol [44].

3.3.8 Charging in IMS

Offline charging is applied to users who pay for their services

periodically (e.g., at the end of the month). Online charging, also known as
credit-based charging is used for prepaid services, or real-time credit control of
postpaid services. Both may be applied to the same session.

21
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

Charging function addresses are addresses distributed to each IMS entities and
provide a common location for each entity to send charging information.
Charging Data Function (CDF) addresses are used for offline billing and
Online Charging Function (OCF) for online billing.
 Offline Charging: All the SIP network entities (P-CSCF, I-CSCF, S-
CSCF, BGCF, MRFC, MGCF, AS) involved in the session use the
Diameter Rf interface to send accounting information to a CDF located
in the same domain. The CCF will collect all this information, and build
a Call Detail Record (CDR), which is sent to the billing system (BS) of
the domain as shown in figure 3.9.
Each session carries an IMS Charging Identifier (ICID) as a unique
identifier generated by the first IMS entity involved in a SIP transaction
and used for the correlation with CDRs. Inter Operator Identifier (IOI)
is a globally unique identifier shared between sending and receiving
networks. Each domain has its own charging network. Billing systems
in different domains will also exchange information, so that roaming
charges can be applied.

Figure 3.9 Offline Charging Architecture

21
Chapter 3 IP Multimedia Subsystem (IMS)
Architecture

 Online charging: The S-CSCF talks to a Session Charging Function

(SCF) which looks like a regular SIP application server. The SCF can
signal the S-CSCF to terminate the session when the user runs out of
credits during a session. The AS and MRFC use the Diameter Ro
interface towards an OCF as shown in figure 3.10.
– When Immediate Event Charging (IEC) is used, a number of
credit units is immediately deducted from the user's account by
the ECF and the MRFC or AS is then authorized to provide the
service. The service is not authorized when not enough credit
units are available.
– When Event Charging with Unit Reservation (ECUR) is used,
the ECF first reserves a number of credit units in the user's
account and then authorizes the MRFC or the AS. After the
service is over, the number of spent credit units is reported and
deducted from the account; the reserved credit units are then
cleared.

Figure 3.10Online Charging Architecture

22
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

CHAPTER 4
IP MULTIMEDIA SUBSYSTEM (IMS)
SIGNALING ANALYSIS

4.1 Introduction

In this chapter the Signaling protocols used in IMS in addition to the

interfaces between IMS Network Elements are presented. The IMS call/session
scenarios are also presented.

4.2 Protocols used in IMS

3GPP has adopted a number of different protocols, each with their

specific usage and functionality for IMS. The most relevant protocols for this
thesis work will be mentioned below.

4.2.1 Session Initiation Protocol (SIP)

The SIP protocol’s latest specification is contained in the Internet

Engineering Task Force (IETF) SIP Working Group’s RFC 3261 [45]. SIP is a
text-encoded protocol based on elements from the Hypertext Transport
Protocol (HTTP) and the Simple Mail Transport Protocol (SMTP). SIP’s main
purpose is to manage sessions, specifically to establish, modify, and terminate
multimedia sessions. An example of a session would be an Internet telephony
call. SIP can also be used to invite participants to existing sessions, such as
conferences. Media streams can be added or removed from an existing session;
this media can be audio, video, text, etc. SIP transparently supports name
mapping and redirection services, these features enable user mobility.

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

Therefore users can maintain a single visible identifier regardless of their

network location. A typical SIP system is based upon three main elements: SIP
User Agents, SIP servers, and location servers. For detailed information the
reader is encouraged to read the latest SIP RFC, as updated by RFC 3853[46]
and RFC 4320 [47].

4.2.1.1 SIP Network Elements

4.2.1.1.1 User Agents (UA)

Are the end components in a SIP network, they make SIP requests to
establish media sessions; they may also send and receive media. A UA can be
a SIP phone or SIP client software installed on a PC or other system. UAs
generally contain both a client and a server part. The UA client (UAC)
generates SIP requests, while the UA server (UAS) responses to received SIP
requests.

4.2.1.1.2 SIP servers

Are SIP intermediaries that are located within a SIP network (i.e., the
network of devices which understand SIP). These servers assist the UAs in
session establishment and in other functions (such as routing of SIP requests
and responses). SIP servers can be divided into Proxy servers, Redirect servers,
and Registrar servers.

- Proxy servers receive SIP requests from UAs or other proxies and
forwards or proxy the request to another destination. A proxy server can also
authenticate and authorize users for services, implement provider call-routing
policies, and assist users with features that will control the behavior of the
proxy for subsequent sessions (for example, defining what is to be done with

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

calls from a certain source, defining what is to be done with calls at different
times or the day or on different days, etc.).

- Redirect servers send routing information back in response to a client’s

request, thereby redirecting further messages related to this request (for
example, when a user's proxy has moved to a new location because the callee
has changed SIP provider). When the originator of the request receives the
redirect, it will send a new request to a different address, based on the Uniform
Resource Identifier (URI) it has received from the redirect server.

- Registrar servers receive SIP registration requests from a UA and

update the user's location information (by storing the new location at a location
server), this information is used by the proxy servers when they wish to locate
the user's current user agent(s).

SIP proxies, redirect, and registrar servers are purely logical SIP
elements. They have no media capabilities and do not initiate requests - except
on behalf of UAs. They can be implemented in one machine or replicated over
many nodes (for increased reliability, availability, and capacity).

- Location servers are not SIP entities, but they are an important part of
a SIP network’s architecture. A location server stores, and returns the
location(s) of the user's user agent(s) when queried by a SIP server. The
location server can make use of information from registrars or other databases.
Most registrars upload location updates to a location server upon reception of
new location information. The location server's database may store information
about the user's user agent(s) such as their URIs, IP addresses, features, and
other information. It may also contain routing information.

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

UAs do not interact directly with the location server, but rather do so via
a registrar server. SIP servers use a non-SIP protocol to query, update, and
retrieve records from the location servers (some servers uses the Lightweight
Directory Access Protocol (LDAP) [48]).

4.2.1.2 SIP Request

The standard SIP implementation implements 6 different methods, but

there are several extensions to the standard that have been implemented over
the years, adding features enabling richer communication capabilities (e.g.,
Presence services and Instant messaging (IM)). SIP requests consist of headers
and a message body. The standard SIP methods are shown in table 4.1.

Table 4.1 SIP Methods

4.2.1.2.1 INVITE

This request is used to invite a user’s to participate in a session. The

INVITE body contains a description of the session.

11
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

4.2.1.2.2 BYE

This request is used to leave a session. When the session is only a two-
party session, a BYE message will cause the session to end. In a multicast
scenario, however, a BYE request from one of the participants simply indicates
that a particular participant has left the session, but the session itself is not
affected, unless this was the last participant - in which case the session should
be terminated.

4.2.1.2.3 CANCEL

This request terminates pending transactions. If a SIP server has received

an INVITE, but has not returned a final response, then the CANCEL message
will stop the server from processing the INVITE; but if the final response for
the INVITE has already been returned, then the CANCEL request will have no
effect on the transaction.

4.2.1.2.4 REGISTER

The REGISTER request is used when a user wants to inform their SIP
domain of the current location of one of this user's UAs. This is done by
sending a REGISTER requests to a registrar server. The information that the
registrar receives through the REGISTER request is stored in this SIP domain's
location server(s), thus making the new information available for other SIP
servers in this SIP domain. The registrar service offers flexibility, for instance
a user can register a location until a certain time of the day, and after that the
calls will be redirected to another of the currently registered locations.

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

4.2.1.2.5 OPTIONS

This request is used to query a server about its capabilities. For example,
what methods, encodings, and session description protocols it supports.

4.2.1.3 SIP Response

Many of the SIP response codes have been inspired by HTTP. The SIP
response codes are divided into six classes, identified by the first digit of the
code, as shown in table 4.2.
Table 4.2 Response codes

4.2.1.4 SIP session setup

Figure 4.1 illustrates a SIP session setup procedure. In this example a

user called Bob registers his location through a REGISTER request (message

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

1) with the Registrar server, which updates its location server. The Registrar
server acknowledges Bob's UA's registration (message 2).

When later Alice tries to call Bob (using SIP URI [email protected]),
her UA must first find the proxy server that can handle the request, this is done
by querying a DNS server to find the in-coming SIP proxy for Bob's SIP
domain, based upon the string to the right of the at-sign in Bob's SIP URI
(message 3). An INVITE request (message 5) is forwarded to the proxy server
who must decide where to forward the request; the proxy first queries
(message 7) the location server to determine the callee’s current location(s). If
the proxy server can at this stage directly forward the request, it will, otherwise
it will query (message 9) a DNS to resolve the domain’s address, this may
result in forwarding the request to another proxy server, that will repeat the
process (not shown in the figure 4.1).

Once the address of Bob’s UA is determined, the INVITE request

(message 11) is forwarded to the UA(s). The session is considered successfully
established after a three way handshake is complete, steps from (message 11)
to (message 15). In step (message 16) the data session is initiated directly
between Alice's UA and Bob's UA (probably using RTP or SRTP).

Figure 4.1 SIP session setup

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

Note: Messages 7 and 8 are not SIP messages (they could be an LDAP
query and response). Similarly the DNS queries and responses of messages 3,
4, 9, and 10 are not SIP messages.

4.2.2 SIP in IMS

By deciding to use SIP as the signaling protocol for session establishment

and controlling IMS instead of developing its own set of protocols, 3GPP has
opened the door to ward a tight integration of the mobile, fixed and Internet
worlds. However, for a SIP based solution to replace the current mobile and
fixed telecommunication infrastructure it needs to offer the same capabilities;
namely secure and efficient access to high quality multimedia services
regardless of the user’s location. To achieve this goal, IMS introduces a
number of additional SIP headers [49] and requires specific deployment
architecture. While these additions can be generally used in an ISP and VoIP
provider environment as well, they are tailored to meet the requirements of
traditional providers of telecommunication services.

4.2.3 Session Description Protocol (SDP)

The SDP protocol was defined by the IETF in RFC 4566 [50]. SDP is
purely a format for session description. A session description could include
information such as the purpose of the session, the media and the codec’s used
in the session. SDP can use various transport protocols among them SIP. SDP
is not intended to support negotiation of session content or media encoding.
[50]

14
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

4.2.4 Real-time Transport Protocol (RTP)

IMS utilizes RTP for media sessions. This protocol was developed by the
IETF and defined in RFC 3550 [51]. RTP was primarily designed to satisfy the
needs of multi-participant multimedia conferencing, but today it is used for
many different types of applications. RTP provides end-to-end delivery
services for data with real-time characteristics, such as audio and video. RTP
typically runs on top of UDP, no specific ports are defined for this purpose, but
rather an even port and the next higher odd port are used (the later is used by
the Real-time Transport Control Protocol (RTCP) to provide feedback on the
RTP transported data). RTP does not provide any Quality of Service (QoS)
guarantees at all. However, it does allow transmission imperfections such as
packet loss or jitter to be detected with the help of the sequence numbers and
time stamps in the RTP packets and the sender and receiver reports sent in
RTCP. [51]

4.2.5 Real-time Transport Control Protocol (RTCP)

RTCP was defined by the IETF in RFC 3550 [51]. The primary function
of this protocol is to provide information to monitor the quality of service for
RTP flows. This information includes the number of bytes sent, packets sent,
lost packets, jitter, and round trip delay. RTCP also transmits control packets to
participants in a multimedia streaming session, so that the participants can
learn who the other participants are. An application may use RTCP
information to increase the quality of service perhaps by limiting flow,
switching to a low compression coder-decoder (CODEC) instead of a high
compression CODEC, turning off specific types of media (for example, turning
off video), etc. For a description of this see [52].

14
 Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

There are several types of RTCP packets: Sender report packet, Receiver
report packet, Source Description RTCP Packet, Goodbye RTCP Packet, and
Application Specific RTCP packets as defined in RFC 3550 [51].

4.2.6 The Secure Real-time Transport Protocol (SRTP)

The secure real-time transport protocol (SRTP) was defined by the IETF
in RFC 3711 [53]. SRTP is a profile of RTP. It can provide confidentiality,
message authentication, and replay protection to the RTP traffic and to RTCP.
For further details see [54].

4.2.7 Diameter

The 3GPP standards body has adopted Diameter as the primary signaling
protocol for authentication, authorization, and accounting (AAA) in IMS.
Diameter was developed and standardized by IETF as described in RFC 3588
[55]. Diameter is used by IMS’s SIP servers (CSCFs) to perform
authentication using information provided by the HSS and to determine if a
client is authorized to access the services provided by the server.

4.3 IMS Interfaces or Reference Points

In previous chapter “IMS Architecture” we have explained the IMS

operational approach and evaluate core elements of IMS core network with
their specific functionality. There is another important notion in this
context called Reference Points. It specifies that what type of connections
and protocols are used to connect the IMS elements and what kind of
functions they perform.

45
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

The connections between the different elements of IMS are called

interfaces or reference points and each interface has its own functions
and protocols they operate on. These Interfaces are shown in Figure 4.3
[56].

Figure 4.3 IMS Interfaces [56]

44
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

Table 4.3 Summery of Reference Points in IMS [56]

Interface
IMS entities Description Protocol
Name
MGCF, IM-
Mn Allows control of user-plane resources H.248
MGW

Mp MRFC, MRFP Allows an MRFC to control media stream resources provided by an MRFP. H.248

Mr S-CSCF, MRFC Used to exchange information between S-CSCF and MRFC

SIP
Mr' AS, MRFC Used to exchange session controls between AS and MRFC
Used for the interworking with another IMS network, when the BGCF has
BGCF/CSCF,
Mx determined that a breakout should occur in the other IMS network to send SIP SIP
IBCF
message from BGCF to the IBCF in the other network
P-CSCF, I-CSCF,
Mw Used to exchange messages between CSCFs SIP
S-CSCF
SIP, In
Used by the AS to request that media resources be assigned to a call when Query mode
Rc MRB, AS
utilizing MRB In-Line mode or In Query mode (Not
specified)
P-CSCF, I-CSCF,
S-CSCF, BGCF,
Rf Used to exchange offline charging information with CCF Diameter
MRFC, MGCF,
AS
AS, MRFC,
Ro Used to exchange online charging information with ECF Diameter
S-CSCF
Used to exchange policy and charging related information between P-CSCF
Rx P-CSCF, PCRF and PCRF Diameter
Replacement for the Gq reference point
Used to exchange User Profile information (e.g. user related data, group lists,
user service related information or user location information or charging
AS (SIP AS, function addresses (used when the AS has not received the third party
Sh Diameter
OSA SCS), HSS REGISTER for a user)) between an AS (SIP AS or OSA SCS) and HSS. Also
allow AS to activate/deactivate filter criteria stored in the HSS on a per
subscriber basis
Transports CAMEL subscription information including triggers for use by
Si IM-SSF, HSS MAP
CAMEL based application services information.

Sr MRFC, AS Used by MRFC to fetch documents (scripts and other resources) from an AS HTTP

UE, AS (SIP AS,

Facilitates the management of subscriber information related to services and HTTP(s),
Ut OSA SCS,
settings XCAP
IM-SSF)

Used by MRFC to fetch documents (e.g. scripts, announcement files and other TCP/SCTP
Cr MRFC, AS
resources) from an AS. Also used for media control related commands. channels

(I-CSCF, Used to send subscriber data to the S-CSCF; including Filter criteria and their
Cx Diameter
S-CSCF), HSS priority. Also used to furnish CDF and/or OCF addresses.

44
Chapter 4 IP Multimedia Subsystem (IMS)
Signaling Analysis

Table 4.3 Summery of Reference Points in IMS [56]

Interface
IMS entities Description Protocol
Name
AS (SIP AS, Used by AS to find the HSS holding the User Profile information in a multi-
Dh OSA, IM-SSF) <- HSS environment. DH_SLF_QUERY indicates a IMPU and DX_SLF_RESP Diameter
> SLF return the HSS name.
(I-CSCF or Used by I-CSCF or S-CSCF to find a correct HSS in a multi-HSS
Dx S-CSCF) <-> environment. DX_SLF_QUERY indicates a IMPU and DX_SLF_RESP return Diameter
SLF the HSS name.
Gm UE, P-CSCF Used to exchange messages between UE and P-CSCF SIP
COPS
Allows operators to control QoS in a user plane and exchange charging (Rel5),
Go PDF, GGSN
correlation information between IMS and GPRS network Diameter
(Rel6+)
Used to exchange policy decisions-related information between P-CSCF and
Gq P-CSCF, PDF Diameter
PDF

Reference point between S-CSCF and AS. Main functions are to :

- Notify the AS of the registered IMPU, registration state and UE capabilities
ISC S-CSCF <-> AS SIP
- Supply the AS with information to allow it to execute multiple services
- Convey charging function addresses

Used to exchange messages between an IBCF and another IBCF belonging to a

Ici IBCFs SIP
different IMS network.
Used to forward media streams from a TrGW to another TrGW belonging to a
Izi TrGWs SIP
different IMS network.
Main functions are to:
- Forward SIP requests which are designated to a Public Service Identity
hosted by the AS
Ma I-CSCF <-> AS SIP
- Originate a session on behalf of a user or Public Service Identity, if the AS
has no knowledge of a S-CSCF assigned to that user or Public Service Identity
- Convey charging function addresses
MGCF -> I,S-
Mg ISUP signaling to SIP signaling and forwards SIP signaling to I-CSCF SIP
CSCF
S-CSCF ->
Mi Used to exchange messages between S-CSCF and BGCF SIP
BGCF
Used for the interworking with the PSTN/CS Domain, when the BGCF has
Mj BGCF -> MGCF determined that a breakout should occur in the same IMS network to send SIP SIP
message from BGCF to MGCF
Used for the interworking with the PSTN/CS Domain, when the BGCF has
Mk BGCF -> BGCF determined that a breakout should occur in another IMS network to send SIP SIP
message from BGCF to the BGCF in the other network
I-CSCF, S-CSCF,
Mm external IP Used for exchanging messages between IMS and external IP networks SIP
network

44
Chapter 5 Capacity Measurement for IMS Controllers

CHAPTER 5
CAPACITY MEASUREMENT FOR IMS
CONTROLLERS

5.1 Introduction

Measuring the capacity of the (IMS) controllers is very important due

to the critical role it plays in the Next Generation Network (NGN) of the
Fixed and Mobile Networks. This chapter proposes a robust and scalable
method that can be used to measure the capacity of the IMS controllers,
Call Session Control Function (CSCF) and benchmark their different
vendors. The purpose of this method is to measure the capacity of the server
in terms of how many calls are routable into a defined time interval and
what the consequences of overloading the system are.

5.2 Related Work

There are some methods and tools provided by different vendors that
could be used to measure the capacity of IMS controllers like:

1. Performance Measurement Tools for SIP Server by Samit Jain from

Columbia University, New York. This method needs to be
performed over real life SIP servers [57].

2. SIPstone - Benchmarking SIP Server Performance by Henning

Schulzrinne, Sankaran Narayanan, Jonathan Lennox and Michael
Doyle from Columbia University, Ubiquity. April 12, 2002.This
method is depending also on measuring the capacity of the real SIP
servers [58].

45
Chapter 5 Capacity Measurement for IMS Controllers

3. Testing Session Initiation Protocol. (SIP) Saturation . The University

of New Hampshire, Interoperability Laboratory © 2005.This method
is depending also on measuring the capacity of the real SIP
servers [59].

4. Intel and Open Cloud performed the SIP Application Server tests in
May 2006. This method was designed for a special SIP servers
developed by Intel called SIP Application Server running on Intel®-
based Modular Communications Platforms [60].

The novelty in our method is that it is the first time to use the
simulation tool OpenSER [61] to measure the IMS servers capacity and also
in the development of the SIPp [62] tool to generate calls and increase the
number of generated calls till overloading the IMS server.

The benefits of our method are:

1. Easy to use and could be implemented on any PC.

2. The Software used in the test is available.
3. This method could be used for any type of SIP server independent of
the hardware or the software of the server.
4. This Method could be used to benchmark different vendors of IMS
servers and ensure the designed capacity of the IMS server.
5. This method also could be used to dimension the IMS network
capacity.

IMS is a system consisting of many SIP servers, the most important

servers in this system are called Call Session Control Function (CSCF) or
IMS Controllers.

The Capacity here means how many calls can be handled by one of the
IMS controllers at the same time, what the consequences of overloading the

44
Chapter 5 Capacity Measurement for IMS Controllers

Server are and the behavior of the Server after overloading it with
maximum number of calls.

This method is tested using a simulation tool called Open SIP Express
Router (OpenSER).This tool is installed on a PC to simulate one of the IMS
servers which we want to measure its capacity.

We developed another tool called SIPp to act as SIP workload

generator which generates the calls to server and by developing this tool to
increase the number of generated calls to overload the server to measure
how many calls can be served by the server at the same time.

This chapter proposes a robust and scalable method that could be used
to measure the capacity of the IMS SIP servers Call Session Control
Function (CSCF) and benchmark their different vendors.

This method is used to know how many calls are routable into a
defined time interval and what the consequences of overloading the system
are.

These issues are studied experimentally, using Open SIP Express

Router (OpenSER) [61], a high-performance open-source SIP server and
SIPp, the de-facto standard for SIP performance benchmarking [62].

The chapter also provides the test results for Open SIP Express Router
(OpenSER).

5.3 Experimental Test Bed

In this Section we describe the software and hardware utilized in our

experiments.

45
Chapter 5 Capacity Measurement for IMS Controllers

5.3.1 SIP Server Software

We use the Open SIP Express Router version 1.3-2 (Open-SER) [61],
a freely-available, open source SIP proxy server. OpenSER is a “fork” of
SIP Express Router (SER) [63], sharing much of its code base.

Both proxies are written in C, use standard process-based concurrency

with shared memory segments for sharing state, and are considered to be
highly efficient. Each proxy has large feature sets, considerable user bases,
active mailing lists, and third-party contributions (e.g., from sip.edu and
onsip.org). We chose OpenSER over SER due its better documentation, but
we believe our results will hold with SER as well.

5.3.2 SIP Client Workload Generator

We use the SIPp [62] SIP workload generator, another freely available
open-source tool. SIPp allows a wide range of SIP scenarios to be tested,
such as user-agent clients (UAC), user-agent servers (UAS) and third-party
call control (3PCC). SIPp is also extensible by writing third-party XML
scripts that define new call flows.

5.3.3 Client and Server OS Software

The OpenSER is running on Intel Pentium 4 CPU with 5.20 GHz and
1 GB RAM. The operating system is Debian/Linux with Kernel version
2.6.18-6-686.

5.3.4 Hardware and Connectivity

All machines including OpenSER PC (IUT), SIPp PC of (UAC) and

SIPp PC of (UAS) are connected on a 100 Mb/s Ethernet LAN network.

46
Chapter 5 Capacity Measurement for IMS Controllers

5.3.5 Experiments and Metrics

This is to measure the capacity of the IP Multimedia Subsystem (IMS)

controllers Call Session Control Function (CSCF) to know how many calls
or sessions are routable into a defined time interval and what the
consequences of overloading the servers are. Figure 5.2 shows the
performance test scenario.

Performance is measured by clients using the open source SIP testing

tool SIPp which is an XML injector [62] that creates according to given
parameters SIP messages and send it to the announced destination with its
various options of the messages configuration.

SIPp in this test runs as SIP User Agent Server (UAS) and SIP User
Agent Client (UAC) on separated computers which allow differentiating
between the sent messages and the received messages.

5.3.6 Restrictions, Limitations, and Scope

Note that our setup by no means covers the entire space of

configurations for SIP. We do not consider non-VoIP scenarios such as
Instant Messaging or Presence. In addition, there are many VoIP situations
not measured by our experiments, including outbound proxying, PSTN
gatewaying, ENUM processing, SCTP as a transport layer, or error
processing for unregistered or unauthenticated users. Each of these presents
opportunities for future work.

5.4 Measurement Scenario

In this scenario which illustrated in figure 5.1, the UAC wishes to

establish a session with the second UAS and sends an INVITE message to

47
Chapter 5 Capacity Measurement for IMS Controllers

the proxy. The proxy responds with a 100 TRYING message to inform the
UAC that the message has been received.

The proxy then looks up the contact address for the SIP URI of the
UAS and forwards the message. The UAS in turn, acknowledges receipt of
the message and informs the proxy that it is notifying the user via the 180
RINGING message.

Figure 5.1 Test Scenario

The proxy then forwards that message to the initiator of the INVITE,
informing the client that the end host has received the message and that the
line is ringing. The user on the UAS then accepts the call, generating a 200
OK message, which is sent to the proxy which forwards it on to the UAC.

The UAC then generates an acknowledgment. Having established the

session, the two endpoints communicate directly, peer-to-peer, using a
media protocol such as RTP. However, this media session does not traverse
the proxy.

48
Chapter 5 Capacity Measurement for IMS Controllers

When the conversation is finished, the user hangs up and generates a

BYE message that the proxy forwards to the second user.

The second user then responds with a 200 OK which is forwarded

back to the user. SIP allows the use of multiple transport protocols,
including UDP, TCP and SCTP however this test was run over UDP only.

The purpose of this test is to measure the capacity of the IMS

controllers, Call Session Control Function (CSCF) in terms of how many
calls are routable into a defined time interval and what the consequences of
overloading the system are.

5.5 Results

The purpose of this method is to measure the capacity of IMS

controllers in terms of how many sessions or calls are routable into a
defined time interval and what the consequences of overloading the system
are.

Figure 5.2 Shows that the OpenSER can at maximum handle 150 calls
or sessions per sec and after that when overloading the OpenSER, it
reboots.

In our test we have used a work load generator which generates calls
and increases the number of generated calls till the IMS server stop
handling any call.

From our measurement we found that that IMS server stop handling
any call and reboot when the maximum number of call generated in the
second was 150 calls per second then the server reboot.

56
Chapter 5 Capacity Measurement for IMS Controllers

The results achieved for the simulation test showed that the IMS
Server with software OpenSER when it was running on a specific Hardware
Server (Intel Pentium 4 CPU with 5.20 GHz and 1 GB RAM) the maximum
number of calls at the same time could be handled by this server is 150
Calls per sec and after that the server did reboot.

From the observation, it is noticed that the processor load reached 40%
and the memory utilization reached 65% which were a good indicator
because there was no crash in the server or it was no down after
overloading.

The above results were achieved when we run this method for this
type of hardware however this result could be changed if the test run on
different server with different processor and memory and in this case we
can achieve another result for the maximum number of calls, the processor
load and the memory utilization.

The novelty in this chapter is the method itself in measuring the

capacity of IMS servers which could be applied to any type of servers.

Figure 5.2 Total number of calls created

56
Chapter 5 Capacity Measurement for IMS Controllers

Processor Load (CPU profile) and memory usage of the server are
used to measure the consequences of overloading the system.

CPU profile and memory usage of the server were examined during
the test. The tool for measurement is command “# top –d l -i -b” for CPU
and memory.
Command “# top –d l -i -b” was used and repeated each second and
delivers the output at the console which was redirected into the file for the
test measurement. Figure 5.3 shows an Example output command “# top –
d l -i -b”.

Example output command “# top –d l -i -b” :

top - 16:42:49 up 11:02, 1 user, load average: 1.00, 0.50, 0.69

Tasks: 101 total, 2 running, 99 sleeping,0 stopped, 0 zombie
Cpu(s): 1.5%us, 1.7%sy, 0.0%ni, 94.9%id, 0.2%wa, .6%hi, 1.1%si, 0.0%st
Mem: 516864k total, 322532k used, 194332k free, 49836k buffers
Swap: 240932k total, 0k used, 240932k free, 122444k cached

Figure 5.3 Example output command “# top –d l -i -b” during the Performance
Test

For CPU: The column “%us” is important, because here is displayed

the usage of the CPU by the routing processes (processes started by a user,
e.g. by an incoming SIP Request)

For Memory: The column “used” is important, because here is

displayed the usage of the memory by all the processes. The memory
utilization is calculated as follows:

MemUsed*100 / MemTotal= User_Mem % (1)

56
Chapter 5 Capacity Measurement for IMS Controllers

Figure 5.4 shows the processor load during the test and its maximum
load about 40% and after the total number of calls reached 150 calls or
sessions per sec and after that when overloading the OpenSER, it reboots.

The Processor Load reached 40% while the server reached the
maximum number of calls at the same time. The observation results during
the test showed that the IMS server remained stable although it reached the
maximum number of calls.

The memory usage did not exceed 65% as shown in figure 5.5.The
memory utilization reached 65% while the server reached the maximum
number of calls at the same time. The observation results during the test
showed that the IMS server remained stable although it reached the
maximum number of calls.

Figure 5.4 Processor Load

56
Chapter 5 Capacity Measurement for IMS Controllers

Figure 5.5 Memory Utilization

5.6 Conclusion

Measuring the capacity of the IP Multimedia Subsystem (IMS)

controllers is very important due to the critical role it plays in the Next
Generation Network (NGN) of the Fixed and Mobile Networks.

The purpose of this test is to know how many calls are routable into a
defined time interval and what the consequences of overloading the system
are.

This chapter proposed robust and scalable method that can be used to
measure the capacity of the IP Multimedia Subsystem (IMS) controllers,
Call Session Control Function (CSCF) and benchmark their vendors.

55
Chapter 5 Capacity Measurement for IMS Controllers

The novelty in our method is that it is the first time to use the
simulation tool OpenSER to measure the IMS servers capacity and also in
the development of the SIPp tool to generate calls and increase the number
of generated calls till overloading the IMS server.

The benefits of our method are:

1. Easy to use and could be implemented on any PC.

2. The Software used in the test is available.
3. This method could be used for any type of SIP servers’
independent of the hardware or the software of the server.
4. This Method could be used to benchmark different vendors of IMS
servers and ensure the designed capacity of the IMS server.
5. This method also could be used to dimension the IMS network
capacity.

These issues are studied experimentally, using Open SIP Express

Router (OpenSER), a high-performance open-source SIP server, and SIPp,
the de-facto standard for SIP performance benchmarking.

This method could be used to benchmark the different vendors of IMS

servers to know the exact capacity of each server in term of the maximum
number of calls or sessions could be handled at the same time.
Measurement results for OpenSER showed that its maximum capacity is
150 calls or sessions per sec and after that when overloading the OpenSER,
it reboots.

54
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

CHAPTER 6
IP–MULTIMEDIA SUBSYSTEM (IMS)
PERFORMANCE EVALUATION

6.1 Introduction

Evaluating the IP Multimedia Subsystem (IMS) Performance is very

important due to the critical role it plays in the Next Generation Network
(NGN) of the Fixed and Mobile Networks. This chapter proposes two robust
and scalable methods that can be used to evaluate the performance, the
Compliance of the IMS controllers Call Session Control Function (CSCF)
and benchmark their different vendors. These methods are, FUZZING Test
and the test using Spectra 2|SE tool. These issues are studied
experimentally, using Open SIP Express Router (OpenSER), a high
performance open source SIP server and SIPp, the de-facto standard for SIP
performance benchmarking.

6.2 Related Work

There are some methods and tools provided by different vendors that
could be used to measure the performance of IMS as described in section
5.2.

IMS is a system consisting of many SIP servers, the most important

servers in this system is called Call Session Control Function (CSCF) or
IMS Controllers.

These methods are tested using a simulation tool called Open SIP
Express Router (OpenSER) which can simulate the Call Session Control
Function (CSCF) or IMS Controllers.

66
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

This chapter proposes robust and scalable methods that can be used
to evaluate the performance of the IMS SIP servers and benchmark their
different vendors.

These issues are studied experimentally, using Open SIP Express

Router (OpenSER), a high-performance open-source SIP server and
SIPp, the de-facto standard for SIP performance benchmarking. The
chapter also provides the test results for Open SIP Express Router
(OpenSER).

The first method is the FUZZING Testing. This test suite focuses
the robustness and security testing of the Implementation Under Test
(IUT) when receiving malformed INVITE requests. The test fails if the
IUT stops running, hangs up, crashes, restarts and consumes all CPU
or/and memory for a long time [64].

The second method is the testing with Spectra2|SE .It is a

compliance test to evaluate the behavior and the response of the system
to the standard SIP requests[65].

6.3 New proposed Methods for IMS Performance ,

Compliance Tests and Benchmarking

This chapter proposes robust and scalable methods that can be used
to evaluate the performance of the IMS SIP servers and benchmark their
different vendors.

These issues are studied experimentally, using Open SIP Express

Router (OpenSER), a high-performance open-source SIP server and
SIPp, the de-facto standard for SIP performance benchmarking. The
chapter also provides the test results for Open SIP Express Router
(OpenSER).

67
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

The first method is the FUZZING Testing. This test suite focuses
the robustness and security testing of the Implementation Under Test
(IUT) when receiving malformed INVITE requests. The test fails if the
IUT stops running, hangs up, crashes, restarts and consumes all CPU
or/and memory for a long time [64].

The second method is the testing with Spectra2|SE .It is compliance

test to evaluate the behavior and the response of the system to the
standard SIP requests [65].

6.3.1 FUZZING Testing (PROTOS)

The FUZZING tests are in total extracted out of the "PROTOS

Test-Suite: c07-sip" of the University of OULU [64].
PROTOS defines a test suite which was a by-product of “PROTOS
–Security Testing of Protocol Implementations“ funded and supported by
the “Red Skins“ project of the University of OULU [64].

The main focus of this test suite is how the implementation of a

User Agent (UA) or a SIP Proxy Server handles INVITE requests.

This test suite focuses on the robustness and security testing of the
Implementation Under Test (IUT) receiving malformed and INVITE
requests. The test suite tests SIP via UDP only due to the fact that it is
not recommended that the IUT supports TCP. To provoke failures the
sent INVITE Messages contain one or more of the exceptional elements

PROTOS Project is to provoke failures to the sent INVITE

Messages contains one or more of exceptional elements (e.g. overflow-
general -'a' (0x61) character overflows up to 128k)

68
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

• Exceptional element categories are defined as follows in Table

6.1:

Table 6.1 Exceptional Element Categories [ 64]

Name Description
empty Omitted (empty) element content
ipv4-ascii Exceptional IPv4 addresses in ascii
overflow-general 'a' (0x61) character overflows up to 128k
overflow-slash Overflows of '/' up to 128 kbytes
overflow-colon Overflows of ':' up to 128 kbytes
overflow-space Overflows of ' ' up to 128 kbytes
overflow-null Overflows of 0x61 and nulls (0x00) mixed
overflow-leftbracket Overflows of '<' up to 128k
overflow-rightbracket Overflows of '>' up to 128k
overflow-at Overflows of '@' up to 128k
overflow-equal Overflows of '=' up to 128k
fmtstring Format strings (eg. %s%s%s or %.4097d)
utf-8 Malformed UTF-8 sequences
integer-ascii Pos/Neg ASCII encoded integers
ansi-escape Malformed ANSI escape sequences
sip-version Malformed "SIP/2.0"
content-type Malformed "application/sdp"
sip-URI Malformed SIP-URI
sip-tag Malformed tags
crlf Arrangements of CR (0x0d) and LF (0x0a)

• Failure criteria:
1. A device undergoes a fatal failure and stops functioning
normally
2. A process or a device crashes or hangs and needs to be
restarted manually
3. (A process or a device crashes and restarts automatically)
4. A process consumes almost all CPU and/or memory
resources for an exceptionally long or indefinite time
• The test fails if one of the above mentioned failures occurs due to
receiving an INVITE containing one or more of the exceptional
elements

69
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

• The test suite enfolds 4527 SIP INVITE tests which are
subdivided into 54 sub-category
• Due to the fact that a detailed test set-up is not available, two
major kinds and three different sub-kinds of measurements are
issued
• The two major kinds are:
1. With a 2000 ms delay between each test and optional
teardown/validcase, the two seconds space makes it easy to
find out later if there any issue occurred
2. With 100 ms between each test and optional
teardown/validcase

• The three sub-kinds are:

1. Measurement with the commands "teardown“ (sends after
the test case a CANCEL -and a ACK to terminate the calls
- recommended) "validcase“ (to verify if the IUT still
works - optional)
2. Measurement with the command "teardown“ only
3. Measurement without any additional command

All machines including OpenSER PC (IUT), PROTOS PC of

(UAC) and PC of (UAS) are connected on a 100 Mb/s Ethernet LAN
network as Shown in figure 6.1

These issues are experimentally studied with the OpenSER running

on Intel Pentium 4 CPU with 3.20 GHz and 1 GB RAM.The operating
system is Debian/Linux with Kernel version 2.6.18-6-686. Figure 6.8
shows the PROTOS test scenario.

The tool SIPp is used to simulate the terminating UA, SIPp is

running and just notice if an INVITE received. If the message is different
to INVITE it sends the corresponding reply e.g. if receiving a CANCEL
it sends back a 200 OK.

70
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Figure 6.1 Lab connection for FUZZING Test

The PROTOS test suite simulates the originating UA (UAC). It

sends out all INVITE messages due to the test cases, (If selected sends
out CANCEL and ACK).

Figure 6.2 PROTOS Test Scenario

71
 Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

The tool SIPp is used to simulate the terminating User Agent

(UAS), SIPp is running and just notices if an INVITE is received and if
the message is different to INVITE it sends the corresponding reply e.g.
if receiving a CANCEL it sends back a 200 OK.Just to make sure, on
each PC a Wireshark [66] capturing was started and the terminal output
was saved for the test suite.Figure 6.3 shows a Wireshark trace as one
example for one of the exceptional elements categories tested during the
experiment.
The test was to provoke the INVITE message with 'a' character
overflows, OpenSER responded correctly to this error and replied with
404 Not Found. By this the test was passed successfully for OpenSER.

SIP Request:
aaaaaaaa sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP rx-desktop:5060;branch=z9hG4bK00003000003
From: 3 <sip:user@rx-desktop>;tag=3
To: Receiver <sip:[email protected]>
Call-ID: 3@rx-desktop
CSeq: 1 INVITE
Contact: 3 <sip:user@rx-desktop>
Expires: 1200
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 120
v=0
o=3 3 3 IN IP4 rx-desktop
s=Session SDP
c=IN IP4 127.0.1.1
t=0 0
m=audio 9876 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP Response:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP rx-desktop:5060;branch=z9hG4bK00003000003;received=192.168.1.235
From: 3 <sip:user@rx-desktop>;tag=3
To: Receiver <sip:[email protected]>;tag=fa997f81440371de71ab448ebdb9af56-6192
Call-ID: 3@rx-desktop
CSeq: 1 INVITE
Server: OpenSER (1.3.2-notls (i386/linux))
Content-Length: 0

Figure 6.3 PROTOS test trace for OpenSER Overflow-general,

'a' (0x61) character overflows up to 128k

72
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Figure 6.4 shows a Wireshark trace as one example for one of the
exceptional elements categories tested during the experiment.
The test was to provoke the INVITE message with 'a' character
overflows, OpenSER responded correctly to this error and replied with
404 Not Found. By this the test was passed successfully for OpenSER.

Figure 6.4 PROTOS test trace for OpenSER Overflow-

general, 'a' (0x61) character overflows up to 128k

73
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Figure 6.5 shows a Wireshark trace as one example for one of the
exceptional elements categories tested during the experiment.

The test was to provoke the INVITE message with 'edv' character
overflows, OpenSER responded correctly to this error and replied with
404 Not Found. By this the test was passed successfully for OpenSER.

Figure 6.5 PROTOS test trace for OpenSER Overflow-

general, 'edv' (0x61) character overflows up to 128k

74
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Figure 6.6 shows a Wireshark trace as one example for one of the
exceptional elements categories tested during the experiment.

The test was to provoke the INVITE message with Format strings
(eg. %s%s%s or %.4097d), OpenSER responded correctly to this error
and replied with 404 Not Found. By this the test was passed successfully
for OpenSER.

Figure 6.6 PROTOS test trace for OpenSER Format strings (eg.
%s%s%s or %.4097d)

CPU profile and memory usage of the server were examined during
the test. The tool for measurement is command “# top –d l -i -b” for CPU
and memory. Command “# top –d l -i -b” was used, repeated each

75
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

second and delivers the output at the console which was redirected into
the file for the test measurement. Figure 6.7 shows an Example output
command “# top –d l -i -b”.

Example output command “# top –d l -i -b” :

top top - 05:38:46 up 23:58, 1 user, load average: 0.10, 0.04, 0.01
Tasks: 100 total, 1 running, 99 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 95.8%id, 0.1%wa, 0.4%hi, 0.7%si, 0.0%st
Mem: 516864k total, 405052k used, 111812k free, 56292k buffers
Swap: 240932k total, 0k used, 240932k free, 189336k cached

Figure 6.7. Example output command “# top –d l -i -b” during PROTOS

Test

For CPU: The column “%us” is important, because here is

displayed the usage of the CPU by the routing processes (processes
started by a user, e.g. by an incoming SIP Request)
For Memory: The column “used” is important, because here is
displayed the usage of the memory by the all processes. The memory
utilization is calculated as follow:

MemUsed*100 / MemTotal= User_Mem %

From the measurement file, the CPU load and the memory usage
are calculated. These two measurements are enough because due to the
failure criteria the IUT stops running, hangs up, crashes, restarts and
consumes all CPU or/and memory for a long time. Figure 6.8 shows the
Processor Load during PROTOS test and Figure 6.9 shows Memory
utilization during PROTOS test.

From these figures, PROTOS test suite has been passed

successfully over the OpenSER. This is because nothing appeared from
the failure criteria where the memory load was stable and it was about
80% and no crash happened to the processor with maximum processor
load of 50%.

76
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Fig. 6.8. Processor Load during PROTOS test

Fig. 6.9. Memory usages during PROTOS test

77
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

6.3.3 Testing with Spectra2|SE

The Spectra 2|SE software testing solution is a Windows PC based

software application that provides users with the capability to test IMS
and VoIP networks from their laptops or desktops [65]. Spectra 2|SE is
an industry leading easy to learn and easy to use scripting
interface.Spectra2|SE delivers pre installed possibilities and Enables
defining of tests.

Testing with the Spectra2|SE standard comply using ETSI TS 102

027-2 V6.1.1 [67] or RFC 3261 [67].This test was experimentally
studied with the OpenSER running on Intel Pentium 4 CPU with 3.20
GHz and 1 GB RAM.The operating system is a Debian/Linux with
Kernel version 2.6.18-6-686.The Spectra 2|SE PC and the OpenSER PC
are connected on a 100 Mb/s Ethernet LAN network as shown in figure
6.10.

Figure 6.10 Lab connection for Spectra 2|SE Test

The following test cases were extracted and done according to ETSI
TS 102 027-2 V6.1.1:

78
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

1. Test for Messaging

SIP_MG_PR_V_0XX
SIP_MG_PR_I_0XX

2. Test for call control

SIP_CC_PR_MP_RQ_I_00X
SIP_CC_PR_MP_RQ_V_0XX
SIP_CC_PR_MP_RS_V_0XX
SIP_CC_PR_TR_CL_TI_0XX
SIP_CC_PR_TR_CL_V_0XX
SIP_CC_PR_TR_SE_TI_0XX
SIP_CC_PR_TR_SE_V_0XX

3. Test for Querying for Capabilities Series

SIP_QC_PR_V_0XX

Figure 6.11 shows one test of the Proxy test extracted from ETSI
TS 102 027-2 V6.1.1 for call control. This test was one of the tests
applied on OpenSER using Spectra 2| SE tool.

TPId: IP_CC_PR_MP_RQ_V_032
Status: Mandatory
Ref: RFC 3261 [2] sections 16.3, item 3 and 16.10.
Purpose: Ensure that the IUT on receipt of a CANCEL request that does
not correspond to an existing context including a Max-Forwards header set
to 0, sends a Too many hops (483 Too many hops) request failure
response.

Figure 6.11 OpenSER Spectra2|SE Test Sample [101]

Figure 6.12 is a Wireshark trace for this test show that the test was
passed successfully and the server response was according to the
standard.

79
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

SIP Request: CANCEL

sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP192.168.1.87:5060;branch=z9hG4bK3776328-bdcc3b69
Max-Forwards: 0
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 0 CANCEL
Content-Length: 0

SIP Response:
SIP/2.0 483 Too Many Hops
Via:SIP/2.0/UDP192.168.1.87:5060;branch=z9hG4bK3776328-bdcc3b69
From: sip:[email protected]
To:sip:[email protected];tag=e42c76af37d5792c84fff6077ad77fa8.7a49
Call-ID: [email protected]
CSeq: 0 CANCEL
Server:OpenSER (1.3.2-notls (i386/linux))
Content-Length: 0

Figure 6.12 OpenSER Spectra2|SE Test Result

Spectra2|SE selected tests were also passed successfully over the

OpenSER as it responded to the SIP request according to RFC 3261
standard. Figure 6.13 shows the output from Spectra2|SE tool during the
tests.

80
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

Figure 6.13 Spectra 2|SE Test output.

6.4 Conclusion

Evaluating the IP Multimedia Subsystem (IMS) Performance is

very important due to the critical role it plays in the Next Generation
Network (NGN) of the Fixed and Mobile Networks. This chapter
proposes robust and scalable methods that can be used to test the
performance of the IP Multimedia Subsystem (IMS) controllers, Call
Session Control Function (CSCF) and benchmark their vendors.
These issues are studied experimentally, using Open SIP Express
Router (OpenSER), a high-performance open-source SIP server, and
SIPp, the de-facto standard for SIP performance benchmarking.

81
Chapter 6 IP–Multimedia Subsystem (IMS)
Performance Evaluation

The novelty in our method is that it is the first time to use the
simulation tool OpenSER to measure the IMS servers performance and
also in the development of the SIPp tool to generate calls and increase
the number of generated calls till overloaded the IMS server.The benefits
of our methods are:

1. Easy to use and could be implemented on any PC.

2. The Software used in the test is available.
3. These methods could be used for any type of SIP servers
independent on the hardware or the software of the server.
4. These Methods could be used to benchmark different vendors of
IMS servers and ensure the compliance of these servers with ETSI
and IETF standards.

These tests are studied experimentally in lab, using Open SIP

Express Router (OpenSER), a high-performance open-source SIP server,
and SIPp, the de-facto standard for SIP performance benchmarking.

The first method is the FUZZING Testing. This test suite focuses
the robustness and security testing of the Implementation Under Test
(IUT) when receiving malformed INVITE requests. The test fails if the
IUT stops running, hangs up, crashes, restarts and consumes all CPU
or/and memory for a long time .PROTOS test suite has been passed
successfully over the OpenSER. This is because nothing appeared from
the failure criteria. The novelty in this method is that the use of
FUZZING Test proposed by the university of Olou in Finland practically
in our test and provide the test results for OpenSER SIP server.
The second method is the testing with Spectra2|SE to test the
behavior and the response of the system to the standard SIP
requests.Spectra2|SE selected tests were also passed successfully over
the OpenSER as it responded to the SIP request according to RFC 3261
standard. The novelty in this test is using Spectra2|SE tool practically in
measuring the IMS performance according to RFC 3261 standard.

82
CHAPTER 7 IMS Session Setup Analysis

CHAPTER 7
IMS SESSION SETUP ANALYSIS

7.1 Introduction

Over the last years the IP Multimedia Subsystem (IMS) has

continuously gained in importance as the next generation communication
network. The Session Initiation Protocol (SIP) was chosen the signaling
protocol for session establishment and control in IMS. Losses caused by
network or server overload would cause retransmissions and delays in the
session establishment and would hence reduce the perceived service quality
of the users. In order to be able to take counter measures network and
service planers require detailed models that would allow them to predict
such effects in advance. This chapter presents a theoretical model of SIP
that can be used for determining various parameters such as the delay and
the number of messages required for establishing a call in IMS networks
when taking losses and delays into account. The model also provides a
method to calculate the bandwidth required for session establishment in
IMS.

IP Multimedia Subsystem (IMS) has resulted from the work of the

Third Generation Partnership Project (3GPP) toward specifying an all-IP
communication service infrastructure [68]. Mainly looking at the needs and
requirements of mobile operators, the 3GPP first specified IMS as a service
architecture combining the Internet’s IP technology and wireless and
mobility services of current mobile telephony networks. After that the IMS
architecture was extended to include fixed networks as well. By deciding to
use session initiation protocol (SIP) as the signaling protocol for session
establishment and control in IMS instead of developing its own set of
protocols, 3GPP has opened the door toward a tight integration of the
mobile, fixed and Internet worlds. Recent reports already indicate that there

38
CHAPTER 7 IMS Session Setup Analysis

are more than 200 million subscribers using the IMS technology for
telephony services [69].

SIP can be used over various transport protocols such as UDP, TCP
or SCTP. To enable the reliable transmission of SIP messages even when
used over UDP, SIP supports application level retransmission mechanisms.
That is in case no response was received for a sent request then after a
timeout the request is retransmitted. Thereby, losses due to overloaded
servers or lossy links would cause delays in the session establishment and
hence reduce the perceived service quality.

In this chapter we provide a theoretical model that can be used by

operators and network designers to determine the effects of introducing
IMS to their networks in terms of bandwidth usage for example and the
effects of losses and delays on the service quality. This model uses as the
input various traffic characteristics such as the number of calls per second
and mean holding time and network characteristics, such as losses and
propagation delays. The output of the model provides details on the
bandwidth and delay needed for successfully establishing a session when
using SIP over UDP in IMS networks. In Sec. II we provide the related
work to this chapter and present a brief overview of the literature
concerning modeling of SIP. In Sec. III the IMS and SIP in IMS are
presented. In Sec. IV the IMS session establishment phases is presented.
The SIP model for IMS session establishment is presented in Sec. V. The
conclusion and future work in addition to suggestions for further
refinements are discussed in Sec. VI.

7.2 Related Work

With the success of SIP, there have already been a number of studies
addressing aspects of performance evaluation and modeling of SIP.

38
CHAPTER 7 IMS Session Setup Analysis

Chebbo et al. describe in [70] a modeling tool with which it is possible

to estimate the number of required SIP entities for supporting certain traffic.

Gurbani et al. present in [71] a theoretical model of a SIP server using

queuing theory. This model is then used to evaluate the performance of a
SIP server in terms of response time and number of served requests.

Wu et al. analyze in [72] the usage of SIP for carrying telephony

information in terms of queuing delay and delay variations.

In general, these studies aim at investigating the performance of SIP

servers in terms of the number of SIP sessions that can be supported by a
SIP server or the processing delays at such servers. In contrast, in our work
we do not aim at modeling the performance of a SIP server but to
investigate the performance of SIP in terms of the number of messages and
amount of time needed by SIP for establishing a session in lossy
environments.

Fathi et al.[73] present a model of SIP in VoIP networks and

investigate the effects of mobility on the performance of session
establishment using SIP. The used model is however rather simplified and
is only applicable to stateless SIP proxies which have no notion of
transactions.

Alam et al. [74] discuss different performance model for SIP

deployment scenarios in mobile networks. This involves providing models
for evaluating the performance of push-to-talk applications or the effects of
different mobility concepts. The work does not however provide for a
model of how SIP itself deals with losses.

Sisalem et al. [75] provided a theoretical model of the effects of losses

and delays on the performance of SIP. While that work is providing the
basis for our work here, it is rather limited to simple SIP networks as are

38
CHAPTER 7 IMS Session Setup Analysis

discussed in IETF. The work in this chapter takes the multi-hop nature of
IMS into account as well as the SIP specifications.

7.3 Background

In this section, a description of the IP Multimedia Sub system (IMS)

architecture including the function of the key components and SIP function
in IMS is also presented.

7.3.1 IMS Architecture

3GPP has standardized the IP Multimedia Subsystem specifications

[68]. IETF also collaborates with them in developing protocols that fulfill
their requirements.

Figure 7.1 shows the common nodes included in the IMS .These nodes are:

1. CSCF (Call/Session Control Function): CSCF is a SIP server which

processes SIP signaling in the IMS. There are three types of CSCFs
depending on the functionality they provide:

A- Proxy Call Session Control Function (P-CSCF)

B- Interrogating Call Session Control Function (I-CSCF)
C-Serving Call Session Control Function (S-CSCF).

 P-CSCF (Proxy-CSCF): The P-CSCF is the first point of contact

between the IMS terminal and the IMS network. All the requests
initiated by the IMS terminal or destined to the IMS terminal traverse
the P-CSCF.

38
CHAPTER 7 IMS Session Setup Analysis

Figure 7.1 IMS Functional Elements

 I-CSCF (Interrogating-CSCF): It has an interface to the SLF

(Subscriber Location Function) and HSS (Home Subscriber Server).
This interface is based on the Diameter protocol (RFC 3588
[76]).The I-CSCF retrieves user location information and routes the
SIP request to the appropriate destination, typically an S-CSCF.

 S-CSCF (Serving-CSCF): It maintains a binding between the user

location and the user’s SIP address of record (also known as Public
User Identity). Like the I-CSCF, the S-CSCF also implements a
Diameter interface to the HSS.

2. SIP AS (Application Server): The AS is a SIP entity that hosts and

executes IP Multimedia Services based on SIP.

3. ENUM (E.164 NUmber Mapping): The ENUM allows telephone

numbers to be resolved into SIP URLs using the Domain Name
System (DNS) [77].

38
CHAPTER 7 IMS Session Setup Analysis

4. MRF (Media Resource Function): The MRF provides a source of

media in the home network. It is further divided into a signaling
plane node called the MRFC (Media Resource Function Controller)
and a media plane node called the MRFP (Media Resource Function
Processor). The MRFC acts as a SIP User Agent and contains a SIP
interface towards the S-CSCF. The MRFC controls the resources in
the MRFP via an H.248 interface [78].

5. BGCF (Breakout Gateway Control Functions): BGCF a SIP server

that includes routing functionality based on telephone numbers.

6. SGW (Signaling Gateway): SGW performs lower layer protocol

conversion.

7. MGCF (Media Gateway Control Function): MGCF implements a

state machine that does protocol conversion and maps SIP to either
ISUP (ISDN User part) over IP or BICC (Bearer Independent Call
Control) over IP. The protocol used between the MGCF and the
MGW is H.248 [79].

8. MGW (Media Gateway): The MGW interfaces the media plane of

the PSTN. On one side the MGW is able to send and receive IMS
media over the Real-Time Protocol (RTP) [80]).

9. The Home Subscriber Server (HSS) contains all the user related
subscription data required to handle multimedia sessions.

7.3.2 SIP in IMS

All IP voice and multimedia call signaling in IMS will be performed

by SIP providing a basis for rapid new service introductions and integration
with fixed network IP services.

33
CHAPTER 7 IMS Session Setup Analysis

With regard to the SIP messages we distinguish between requests and

responses. A request indicates the user’s wishing to start a session (INVITE
request) or terminate a session (BYE request). We further distinguish
between session initiating requests and in-dialog requests.

The INVITE request used to establish a session between two users is a

session initiating request. The BYE sent for terminating this session would
be an in-dialog request. Responses can either be final or provisional.

Final responses can indicate that a request was successfully received

and processed by the destination. Alternatively, a final response can indicate
that the request could not be processed by the destination or by some proxy
in between or that the session could not be established for some reason.

Provisional responses indicate that the session establishment is in

progress, e.g., the destination phone is ringing but the user did not pick up
the phone yet.

A SIP proxy acts in either stateful or stateless mode. In the stateful

mode, the proxy forwards an incoming request to its destination and keeps
state information about the forwarded request until either a response is
received for this request or a timer expires. When used over an unreliable
transport protocol such as UDP, if the proxy did not receive a response after
some time, it will resend the request. In the stateless mode, the proxy would
forward the request without maintaining any state information. In this case
the user agent would be responsible for retransmitting the request if no
responses were received.

SIP uses an exponential retransmission behavior. So if a sender of a

SIP message does not receive a response after some time, it will resend the
request after some waiting time. In case no response was received for the
retransmission, the sender increases the waiting time and tries again and so

38
CHAPTER 7 IMS Session Setup Analysis

up to a certain number of retransmissions, [81] [82].In general one can

distinguish between two retransmission modes in SIP:

7.3.2.1 INVITE-retransmissions

This behavior applies for INVITE requests as well as some other

messages exchanged during session establishment. If this mode is used
then the sender retransmits a message if no confirmation was received
after T1 seconds. The retransmission timer is then increased
exponentially up to a maximum retransmission timer (Timer B). Once
this timer is reached the sender drops the message and stops the
retransmission.

7.3.2.2 Non-INVITE-retransmissions

This behavior applies to all requests other than INVITE. In this

mode the sender retransmits a message if no confirmation was received
after T1 seconds. The retransmission timer is then increased
exponentially up to a maximum retransmission timer called T2. Once
this timer is reached the sender continues retransmitting the request
every T2 up to a maximum timer (TimerF). Once this timer is reached
the sender drops the message and stops the retransmission.

7.4 IMS Session Establishment Phases

Figure 7.2 illustrates a basic session establishment in the IMS with the
caller and callee roaming to foreign networks. The example is based on the
scenario provided in [83].

The session establishment in IMS is triggered by the sending of an

INVITE request. In general, the session establishment can be considered as
consisting of eight phases, namely:

89
CHAPTER 7 IMS Session Setup Analysis

Figure 7.2 Basic session establishment scenario [83]

89
CHAPTER 7 IMS Session Setup Analysis

7.4.1 INVITE / 100 Trying (1-14):

This phase is initiated with the sending of an INVITE request and is

terminated when the client receives a provisional or final response. This
phase actually consists of multiple parts, the communication between the
UA client and the P-CSCF, P-CSCF and S-CSCF. Once the P-CSCF
receives the INVITE request from the client it replies with a provisional
response, e.g., 100 or 180 to the client. The same applies then on each hop
till the INVITE reaches the receiver. In case the INVITE or the provisional
response are lost, the client will retransmit the request after the expiration of
a timeout value called T1. If the INIVTE sent by the P-CSCF to the S-
CSCF or the provisional response sent by the S-CSCF to the P-CSCF are
lost, the P-CSCF will retransmit the INVITE after T1 seconds. The same
applies on all hops till the receiver. Note that the INVITE request is the
only case in which the acknowledgments are sent hop-by-hop. In all the
other phases described here the user equipment (UE) are responsible for
generating the appropriate acknowledgements in an end-to-end manner.

7.4.2 Session Progress 183 / PRACK (15-26):

In this phase the caller and callee negotiate the audio and video codes
to be used as well as the QoS criteria. The 183 provisional response is sent
reliably. That is, the callee will retransmit it using the INVITE-
retransmission mode until a PRACK was received

7.4.3 PRACK/ 200 OK (22-31):

In this phase the caller acknowledges the reception of the 183

response. The PRACK request will be retransmitted by the caller until a 200
OK is received using the Non-INVITE-retrnsmission mode.

89
CHAPTER 7 IMS Session Setup Analysis

Note that the PRACK will start its retrsanmission timer as soon as it
receives the 183 response. Further, the PRACK will not be retransmit each
time a 183 is retransmitted but only when a retransmission timer is
triggered (i.e., T1, 3T1…).

7.4.4 UPDATE / 200 OK (32-41):

In this phase the caller and callee compete the code and QoS
negotiations. In case the UPDATE request or the 200 Ok acknowledgement
were lost the caller will retransmit the UPDATE request until a 200 OK is
received using the Non-INVITE-retrnsmission mode.

7.4.5 Ringing 180 / PRACK (42-52):

In this phase the callee informs the caller that the user is being alerted
about the call. The 180 provisional response is sent reliably. That is, the
callee will retransmit it using the INVITE-retransmission mode until a
PRACK was received.

7.4.6 PRACK/ 200 OK (48-57):

In this phase the caller acknowledges the reception of the 180

response. The PRACK request will be retransmitted by the caller until a 200
OK is received using the Non-INVITE-retrnsmission mode.

7.4.7 Final Response (200 OK) / ACK (58-68):

In this phase the callee informs the caller that the call was accepted. In
case the response or the ACK were lost, the callee will retransmit the 200
OK response using the Non-INVITE-retransmission mode until an ACK
was received.

88
CHAPTER 7 IMS Session Setup Analysis

7.4.8 BYE / 200 OK:

During this phase one of the users terminates the call. In case the
BYE or the acknowledging 200 OK response are lost the sender of the BYE
request will retransmit the BYE until a 200 OK is received in a the Non-
INVITE-retransmission mode.

7.5 Modeling IMS Session Establishment

In this section we will provide a theoretical model for SIP

retransmission techniques in lossy network, bandwidth calculation for IMS
session set up and estimation of IMS session set up delay. Fig.7.2. shows
that the calls traverse five SIP proxies. Each link of the depicted network
has a loss rate of ( ) and has a propagation delay of (D) seconds.

7.5.1 Modeling Retransmission of SIP Messages

7.5.1.1 Modeling the retransmission of the INVITE Request

For the case of INVITE requests, the exponential retransmission

behavior is used up to a timer called TimerB. That is a request is
retransmitted at time points T1, 3T1, 7T1, 15T1 and up to TimerB. This can
be represented as a series in the form of:

(7.1)

With . Thereby the maximum number of

retransmitted INVITE requests ( ) is
(7.2)

88
CHAPTER 7 IMS Session Setup Analysis

With a loss rate of , out of r issued INVITE requests per seconds (r

x l) packets would be lost on average. These would be retransmitted T1
seconds later. The retransmitted packets would also suffer from a loss and
will have to be retransmitted later. Hence, the call generation rate (Ri) can
be depicted is shown in Table 7.1.

Table 7.1 Retransmission Behavior of Invite Requests Due To Network

Losses in IMS Network [75]

At time point 0, r requests are sent per T1 seconds. After T1 seconds

the senders will continue generating r new INVITE requests per T1 second
and will retransmit the lost (l x r) requests, e.g, (r + (l x r)) will be sent. Out
of those (l x (r + (l x r)) will be lost. These would be retransmitted at time
3T1.

At time 2T1 r new requests will be sent plus the requests that were lost
T1 seconds ago, e.g., (l x r) requests. Out of the sent request (l x (r + (l x r))
will be lost. These would be retransmitted at time 4T1 and so on.

The number of INVITE requests (Ri) sent by the sender at any time
point (n) can, hence, be determined as:

88
CHAPTER 7 IMS Session Setup Analysis

(7.3)

with ( ). n can be maximally ( ).

Figure 7.3 and Figure 7.4 show the relation between and at different
values of and the relation between and at different values of
respectively.

Figure 7.3 The relation between and at different values of

88
CHAPTER 7 IMS Session Setup Analysis

Figure 7.4 The relation between and at different values of

At this stage the number of new losses, e.g. losses of newly generated
requests, would become equal to the number of retransmissions that will be
terminated as the maximum number of attempts was already tried. Hence, at
this stage the system reaches a steady state.

7.5.1.2 Losses during INVITE Phase

As already described, an INVITE is sent reliably on a hop-by-hop

basis. Hence if the INVITE sent by the Caller UE or the 100 response sent
by the first proxy in originating visited network (P-CSCF) request were lost
then the Caller UE would retransmit the INVITE. The same applies
between the each two proxies and between the last proxy in terminating
home network (P-CSCF) and the Callee UE. Hence, we can consider the six
hops as independent from each other. For each hop a request is considered
to be successfully sent if the request and its response arrive at their

88
CHAPTER 7 IMS Session Setup Analysis

destinations successfully. Thereby, one needs to consider the losses in both

directions as shown in figure 7.5, e.g., an end-to-end loss (l) of

(7.4)

Figure 7.5 The relation between and

The number of INVITE requests needed for setting up a SIP session

(Pi) can be determined as the number of messages sent after reaching the
steady state divided by the number of original, e.g., not retransmitted,
messages sent. So for example if in the steady state 10 messages are sent
per second where as the transmission rate is 5 messages per second then it
would mean that on average 2 messages have to be sent to get one through.

(7.5)

with N = .
Figure 7.6 shows the relation between and at different values of

83
CHAPTER 7 IMS Session Setup Analysis

Figure 7.6 The relation between and at different values of

The transmission of responses will only be triggered after the

reception of an INVITE. With a one way losses of l and a steady
transmission rate of , only ( ) INVITE requests can be
received. Hence the number of responses sent during a session
establishment can be determined as

(7.6)

Thereby, for successfully sending an INVITE request across η hops,

on the average (η x + η x ) SIP messages would have to be
transmitted. Note, however, that this is kind of a worse case calculation as
shown if figure 7.7.

88
CHAPTER 7 IMS Session Setup Analysis

Figure 7.7 The relation between number of INVITE requests and

at different values of

7.5.1.3 Modeling the retransmission of the Non-INVITE Request

The Non-INVITE requests use the exponential retransmission

behavior up to a timer called T2 and then every T2 seconds up to the so
called TimerF. That is a request is retransmitted at time points T1, 3T1,
7T1, 15T1 and up to T2. Then at 2T2 , 3T2, and up to TimerF. This can be
represented as a series in the form of:

1 (7.7)

with
The number of retransmissions ( ) conducted in the exponential
manner up to the T2 Timer is determined as:

999
CHAPTER 7 IMS Session Setup Analysis

(7.8)

After T2 seconds, the retransmission timeout is kept constant to T2.

The maximum number of retransmissions of a Non-INVITE request
(Nn) can then be determined as the sum of in the exponential part and
of the linear part:

(7.9)

with ( ) indicating the time point at which the sender

goes from exponential backup to a constant timeout value. For Non-
INVITE requests, the transmission behavior is slightly different, see Table
7.2.

999
CHAPTER 7 IMS Session Setup Analysis

Table 7.2 Retransmission Behavior of Non-Invite Requests Due To Losses

in IMS Network [75]

With the value of T2 set to 4 seconds and T1 set to 0.5 seconds. In this
case, the number of Non-INVITE requests ( ) sent by the sender at any
time point ( ) can be determined as:

(7.10)

with ( ) while ( ), e.g., k would be maximally

equal to .

(7.11)

which ensures that q is incremented every T2 seconds.

999
CHAPTER 7 IMS Session Setup Analysis

Note that the maximum value of n here is ( ) at which stage the

steady state is reached, e.g., number of new retransmissions equals the
number of terminated retransmissions.

Figure 7.8 and Figure 7.9 show the relation between and at different
values of and the relation between and at different values of
respectively.

Figure 7.8 The relation between and at different values of

998
CHAPTER 7 IMS Session Setup Analysis

Figure 7.9 The relation between and at different values of

7.5.1.4 Losses during Non-INVITE phase

After sending a final response, the UA server expects to receive a

reply, e.g., an ACK, before T1 seconds. Hence, the relation between the
final response and the ACK is similar to that between an INVITE and a
provisional response. Unlike the INVITE requests, the relation between the
final response and the ACK is an end-to-end one, e.g., the proxies in
between would not retransmit the lost messages. Hence for determining the
number of final response ( ) and ACK requests ( ) needed on the average
for setting up a session, one can use the same equations as previously but by
taking into account the end-to-end delay. Assuming that all requests follow
the same path, e.g., the proxies record-route themselves in the SIP requests
and with a loss rate of l on each link, the one way end to end loss (L) of a
request traversing the η links would be
(7.12)
Figure 7.10 shows the relation between and at different values of

998
CHAPTER 7 IMS Session Setup Analysis

Figure 7.10The relation between and at different values of

The end-to-end loss for a request plus response would in this case be

= (7.13)

7.5.2 Bandwidth Consumption of IMS session establishment in a

Lossy Network

Before we start calculating the Bandwidth Consumption of SIP

Signaling of IMS call establishment in a Lossy Networks, we have to
distinguish between the eight phases of call establishment in terms of
INVITE or Non-INVITE retransmission type.

7.5.2.1 For INVITE/100 Trying phase (INVITE)

= (7.14)
( INVITE Retransmission with two ways Losses)

998
CHAPTER 7 IMS Session Setup Analysis

(7.15)
( INVITE Retransmission with one way Losses)

7.5.2.2 For Session Progress 183/PRACK/200 OK Phase

For a provisional response which is to be sent reliably, the UAC

creates a new request, with a method of PRACK, used to acknowledge the
provisional response. The PRACK request is like any other Non- INVITE
request sent within a call.
Like any other Non-INVITE request, the PRACK request is
retransmitted periodically up to a maximum of a four second interval. Note
that the PRACK request SHOULD NOT be retransmitted when
retransmissions of the provisional response are received. When the UAS
receives the PRACK request, it knows that the provisional response has
been received. The UAS then ceases retransmission of that provisional
response. It also generates a 200 OK response to the PRACK, and sends it
to the UAC. As with any other Non-INVITE request, the 200 response to
the PRACK request MUST be retransmitted when retransmissions of the
PRACK request are received .As shown in figure 7.11.
When the UAC receives the 200 response (or any other final
response) to the PRACK, it stops retransmitting the PRACK. This is
standard behavior for Non-INVITE requests. The UAS MUST NOT
generate an additional reliable provisional response until the first is
acknowledged. After the first is acknowledged, the UAS MAY send
subsequent reliable provisional responses without waiting for
acknowledgements of the previous. However, for purposes of congestion
control, it is RECOMMENDED that a UAS wait for the
acknowledgement of a provisional response before sending the next. This
effectively means that reliable provisional responses can be sent at a rate
of at most per one per RTT (it may be less if there is loss).

998
CHAPTER 7 IMS Session Setup Analysis

Figure 7.11The Session Progress 183/PRACK/200 OK Phase

The reliable provisional response is retransmitted periodically,

even if sent over TCP. The retransmission interval starts at 500 ms, and
doubles after each retransmission, up to a maximum of 32 seconds. This
mirrors the behavior of INVITE responses in [RFC 3261]. If no PRACK is
received for that response after 96 seconds, it is considered a network or
endpoint failure. Behavior at that point is at the discretion of the
implementer.

= = (7.16)
( INVITE Retransmission with one way End to End Losses)

(7.17)
(7.18)
(7.19)
(7.20)

(7.21)

998
CHAPTER 7 IMS Session Setup Analysis

= = (7.22)
( Non-INVITE Retransmission with two ways End to End
Losses)

= = (7.23)
( Non-INVITE Retransmission with one way End to End Losses)

(7.24)

(7.25)

= (7.26)

7.3.2.3 For UPDATE / 200 OK Phase

= = (7.27)
( Non-INVITE Retransmission with two ways End to End
Losses)

= = (7.28)
( Non-INVITE Retransmission with one way End to End Losses)

(7.29)

(7.30)

= (7.31)

993
CHAPTER 7 IMS Session Setup Analysis

7.3.2.4 For Ringing 180 / PRACK / 200 OK Phase

= = (7.32)
( INVITE Retransmission with one way End to End Losses)

(7.33)

(7.34)

(7.35)
= = (7.36)
( Non-INVITE Retransmission with two ways End to End
Losses)

= = (7.37)
( Non-INVITE Retransmission with one way End to End Losses)
(7.38)

(7.39)

= (7.40)

7.3.2.5 Final Response 200 OK / ACK Phase (Non-INVITE)

= = (7.41)
Non-INVITE Retransmission with two ways End to End Losses)

= = (7.42)
( Non-INVITE Retransmission with one way End to End Losses)

998
CHAPTER 7 IMS Session Setup Analysis

(7.43)

7.3.2.6 Total Bandwidth Usage:

The total amount of bandwidth (B) that would be caused by the SIP
signaling for IMS call establishment rate of r , η hops and an SIP packet
size of S as shown in Table IV. The message sizes for session sequences are
provided in Table 7.3. These values are consistent with [84, 85, and 86]
(these chapters evaluated SIP-based session performance under UDP in
different types of networks for instance UMTS etc.).

Table 7.3 Message Size for SIP Over UDP [84]

999
CHAPTER 7 IMS Session Setup Analysis

B= )

(7.44)

: is the probability of losses between two hops (Assume is the constant).

: is the one way End to End Losses.
: is the two ways End to End Losses.
is the SIP Message Size.
: is the number of hops.
is the number of ringing.
r : is the number of Calls or Sessions per Second.
B: The Bandwidth needed for IMS Sessions Establishment.

From Table 7.3 and Equation7.44, the Bandwidth is function of r,

B=
)

(7.45)

Figure 7.12 shows the relation between B, r and and 5

999
CHAPTER 7 IMS Session Setup Analysis

Figure 7.12 The relation between B, r and and 5

7.5.3 Estimation of the IMS Session Establishment Delay

In this section we estimate the session establishment delay when

network losses cause the retransmission of SIP requests. The delay is
determined as the time needed for completing all the INVITE and Non-
INVITE phases.

7.5.3.1 INVITE Phase Delay

The INVITE requests can be retransmitted by each component

traversed by the request. However, each component does not wait till the
previous component has successfully received a response. For example the
caller UE sends an INVITE to P-CSCF. P-CSCF receives the INVITE and
sends back a 100 response. If the 100 response is lost, the caller UE would

999
CHAPTER 7 IMS Session Setup Analysis

retransmit the request after T1 seconds. However, P-CSCF does not need to
consider this and would forward the INVITE to S-CSCF and start its own
retransmission timeout. Hence, for determining the delay of the INVITE
requests, one needs to consider the one-way loss (l) between the hops.
Thereby, the delay of the INVITE phase ( ) on the hops between the caller
UE and P-CSCF as well as P-CSCF and S-CSCF can be estimated as
follows:

(7.45)
(7.46)

7.5.3.2 Non-INVITE Phase Delay

The Non-INVITE phases are conducted in an end-to-end manner.

Thereby, the delay incurred by these phases would be equal to the delay
caused by the round trip propagation delay with hops (2 D) plus
the time between the retransmissions. Thereby the average delays for
completing the Non-INVITE phase ( ) can be estimated as:

(7.47)
(7.48)
(7.49)
(7.50)

Where is the number of Non-INVITE requests needed for session

set up. With the first term of the equation describing the round trip delay,
the second the delay caused by the retransmission during the exponential
back off phase and the last describing the delay when retransmitting the
request every T2 seconds. Note that the loss of the response messages
would result in the retransmission of the request, and hence any additional

998
CHAPTER 7 IMS Session Setup Analysis

delay caused by the loss is already accounted for in the increased number of
request retransmissions. Hence, sending of the response only adds
propagation delay to the total delay. We can apply Eqn. (7.32) for
PRACK/200 OK, UPDATE / 200 OK, Final Response 200 OK / ACK and
BYE phase (BYE / 200 OK) with delays , and

7.5.3.3 Provisional Responses (183, 180) Delay

(7.51)
Where:
(7.52)

(7.53)

(7.54)
Where:
(7.55)

(7.56)

7.5.3.4 Total Delay

Thereby the average total session establishment delay in case of

hops is then determined as:

(7.57)

998
CHAPTER 7 IMS Session Setup Analysis

7.6 Conclusion

In this chapter we presented a theoretical model for evaluating the

performance of SIP signaling in IMS lossy network environments to
establish IMS session. Using this model various parameters were calculated
such as the bandwidth needed for the signaling messages and the session
establishment delay. In this chapter we provide a theoretical model that can
be used by operators and network designers to determine the effects of
introducing IMS to their networks in terms of bandwidth usage for example
and the effects of losses and delays on the service quality.

998
CHAPTER 8 VoIP Quality Optimization in IMS Networks

CHAPTER 8
VoIP QUALITY OPTIMIZATION IN IMS
NETWORKS

8.1 Introduction

Voice traffic in IP Multimedia Subsystem (IMS) will be served using

Internet Protocol (IP) which is called Voice over IP (VoIP). This chapter
uses the "E-Model", (ITU-T G.107) [87], as an optimization tool to select
network and voice parameters like coding scheme, packet loss limitations,
and link utilization level in IMS Network. The goal is to deliver guaranteed
Quality of Service for voice while maximizing the number of users
served.This optimization can be used to determine the optimal
configuration for a Voice over IP in IMS network. OPNET is the
optimization tool that is used in this chapter. The chapter also provides new
equations that relate packet loss to the level of Equipment Impairment (Ie)
with different codecs. These equations can be added to enhance the E-
Model.

The E-Model, is a model that allows users to relate network

impairments to voice quality. This model allows impairments to be
introduced and voice quality to be assessed.

The IP Multimedia subsystem (IMS) is an overlay system that is

serving the convergence of mobile, wireless and fixed broadband data
networks into a common network architecture where all types of data
communications are hosted in all IP environments using the session
initiation protocol (SIP) protocols infrastructure [88].

IMS is logically divided into two main communication domains,

one for data traffic, i.e., real time protocol packets consisting of audio,

116
CHAPTER 8 VoIP Quality Optimization in IMS Networks

video and data and the second one is for SIP signaling traffic. This chapter
focuses on the VoIP Quality of Service over IMS using SIP as a signaling
protocol.

Quality is a subjective factor, which makes it difficult to measure.

Taking an end to end perspective of the network further complicates the
QoS measurements. The reasons for low quality voice transmission are due
to degrading parameters like delay, packet delay variation, codec related
impairments like speech compression, echo and most importantly packet
loss. Large research efforts have been made to solve the vital quality of
service issues. There are some models were developed to measure the VoIP
end to end QoS. The output of these models is generally a single quality
rating correlated to the subjective Mean Opinion Score (MOS score) which
represents the QoS for Voice calls [89].

Many of the developed models for measuring VoIP quality of

service are inappropriate for smaller, private networks. They may take too
much process resource, are intrusive on the regular traffic or contain very
complicated test algorithms. One of the best models used for measuring
VoIP quality of service is the E-model, which is a parameter-based model.

The E-Model, (ITU-T G.107) [87], is a model that allows users to

relate Network impairments to voice quality. This model allows
impairments to be introduced and voice quality to be assessed. Three cases
are considered to demonstrate the effectiveness of optimizing the VoIP over
IMS network using E-Model. New equations were also provided to enhance
E-Model that can be used to relate packet loss to the level of Equipment
Impairment (Ie) with different codecs.

The objective function for all cases is to maximize the number of

calls that can be active on a link while maintaining a minimum level of
voice quality. The cases considered are:

117
CHAPTER 8 VoIP Quality Optimization in IMS Networks

1. Find voice coder given link bandwidth, packet loss level, and link
utilization level.
2. Find voice coder and packet loss level given link bandwidth and
background link utilization.
3. Find voice coder and background link utilization level given link
bandwidth and packet loss level

OPNET and MATLAB are the optimization tools that are used in
this chapter.

8.2 E-Model Parameters

In this section all relevant factors affecting the R value are described.
The R-value is calculated according to the E-model formula [90]:

R = Ro – Is – Id – Ie,eff + A (8.1)

Figure 8.1: The E-model [90]

118
CHAPTER 8 VoIP Quality Optimization in IMS Networks

The factor R0 is defined as the basic signal-to-noise ratio, estimated

at the virtual centre, the 0dB reference point.

The factor Is is the sum of all impairments that occur more or less
simultaneously with the voice transmission. The simultaneous impairment
factor is divided into three subdivisions:
Is  Iolr  Ist  Iq
Iolr represents the decrease in quality due to too-low values
of OLR, also called excessive loudness.
Ist is the impairment caused by non-optimum side tone effects.
Iq represents the impairment caused by quantizing distortion.

The factor Id is the delay impairment factor that can be divided into
three parts [137]:

Id = Idte + Idle +Idd (8.2)

1. Idte is an estimation of the impairments due to talker echo

2. Idle corresponds to impairments caused by listener echo.
3. Idd represents the impairment caused by an absolute delay, Ta that is
too long. Ta can become too long even when using perfect echo
canceling.

The Ie parameter represents the equipment impairment and is the

most complex of all parameters in the E-model.

The Ie factor was earlier represented by tabulated values depending

on the codec used and introducing different amounts of degradations. The
factor has today been improved to also include packet loss degradations,
which has resulted in the Ie,eff factor defined by the following formula
[114]:

(8.3)

119
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Ie is the equipment impairment factor.

Bpl is called the packet-loss robustness factor, which depends on the
Used codec.
Ie,eff represents the packet loss dependent effective equipment
Impairment factor, derived from the value of Ie depending on codec
And at zero packet loss.
Ppl is the packet loss probability.

The parameter A is called the advantage factor or the expectation

factor and can be used to correlate the result from the formula according to
non-technical parameters. For instance, customer expectations or
requirements can affect the perceived transmission quality.

The combination of different impairments can also have a smaller

impact than what is assumed by adding them together. The A factor can
include factors like these into the calculations to achieve a better quality
prediction but is however not recommended for usage when measuring IP
connections. The recommended advantage factor value is 0 for VoIP
measurements and the resulting formula therefore becomes:

R = Ro – Is – Id – Ie,eff (8.4)

A summary of the interconnections between the metrics and the E-

model are shown in the flowchart as shown in Figure 8.2

120
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Figure 8.2: The E-model and its correlated metrics

8.3 The R factor

The main output from the E-model is the single R value, produced
by an equation combining all relevant impairments. The R factor ranges
from 0-100 but is basically unacceptable below 50. It is recommended for
most networks to arrive at a score above 70 when measuring.

When measuring end to end performance, the overall quality in

private networks can sometimes be affected negatively by unknown
impairments induced by the connection to public networks. A user should
therefore always reach for an R value as high as possible for all possible
connections. Table 8.1 describes the various quality and satisfaction
categories related to the E-model factor R [90].

121
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Table 8.1: E-model related quality and satisfaction categories [90]

The trend in planning is to use E-model scores R. With equations described

in the ITU-T recommendation G.107 the R factor can be converted into
non-linear scales of the subjective metrics MOS, %GoB and %PoW [114].

Table 8.2: The R value and its correlation into subjective quality scores [90]

In some cases not only the R score is important but also some of the
specific impairment values Is, Id or Ie. Their individual contribution can be
interesting when determining major impairments or when testing different
impairment solutions. By using these metrics and combining all information
gathered for a connection, a fault diagnosis generally ranging from 0-1 can
be made to indicate the most likely reason for the impairment.

122
CHAPTER 8 VoIP Quality Optimization in IMS Networks

The relationships between the impairments and the E-model factors

are shown in Figure 8.3.

Figure 8.3: E-model fault diagnosis.

8.5 Description of E-Model Optimization

The E-Model has several qualities that interact with each other. For
example, subjective tests have shown that there is a tradeoff between
bandwidth and quality when looking at compression methods. There is also
a relationship between delay and quality [89].

The E-Model [90] is extremely complex with 18 inputs that feed

interrelated components. These components feed each other and recombine
to form an output (R).An example of this complexity is that the delay
parameter is used to generate the simultaneous impairment component as
well as delay impairment component. The recommendation ITU-T G.108
[90] gives a thorough description on how to carry out an E-model QoS
calculation within VoIP networks.

123
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.6 Assumptions for E-Model

Several assumptions are made with this optimization. First, we can

assume the impairments due to echo (Idte and Idle) are not significant
(typically < 3). The impairment due to delay (Idd) is the primary
component that affects the model as implemented for this project. It is the
impairment due to absolute delay (even with perfect echo cancellation)
[89].

Idte=0 (8.35)
Idle=0 (8.36)
And since
Id=Idte+Idle+Idd (8.37)
So
Id=Idd (8.38)
For Ta  100 ms:

Idd  0
For Ta  100 ms:

 1 
  X  6  6 

 
1
Idd  25 1  X 6 6 – 31     2 (8.39)
  3  
 
 
With:

 Ta 
log 
X  100 
(8.40)
log 2
Second, the Advantage (A) is assumed to be equal to zero.

A=0 (8.41)

124
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Third, One portion of the Simultaneous Impairment factor (Is) is

influenced by round trip delay. Since we assume that high quality echo
suppression devices are used, this impairment is very minimal for all cases.
However, the full set of equations for the Is parameter are implemented in
this model.

Is=0 (8.42)

Due to the complexity of the E-Model, the approach used here is to try
to identify which E-Model parameters are fixed and which parameters are
not. In the context of this research the only parameters of the E-Model that
are not fixed are:

 T, and Ta – Delay variables

 Ie – Equipment Impairment
 Coder Type

Where T is the mean one way delay of the echo path, Ta is the absolute
delay in echo free conditions [89]. In addition, parameters that affect delay
Id and Ie are introduced:

 PL - Packet Loss %
 ρ- Link Utilization
 Coder Type

Next, the relationship between these parameters is identified. Since, we

are making the assumption that the echo cancellers are on the end and are
very good, we can say that T = Ta and Ie is directly related to a particular
coding scheme and the packet loss ratio.
According to the above assumption, R-Factor equation can be reduced to
the following expression:

R = 93.2 – Id (Ta) – Ie (codec, packet loss) (8.43)

125
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.6.1To Calculate The Delay Impairment Id [90]:

For Ta  100 ms:

Id= Idd  0 (8.44)

For Ta  100 ms:

 1

  X 6 6 

 
1
Id= Idd  25 1  X 6 6 – 31     2 (8.45)
 3 
   
 
With:
 Ta 
lg 
X  100 
lg2

8.6.2 To Calculate Equipment Impairment Ie [90]:

The loss impairment Ie captures the distortion of the original voice

signal due to low-rate codec, and packet losses in both the network and the
play out buffer. Currently, the E-Model can only cope with speech
distortion introduced by several codecs i.e. G.729 [91] or G.723 [92].

Specific impairment factor values for codec operation under random

packet-loss have formerly been treated using tabulated, packet-loss
dependent Ie-values. Now, the Packet-loss Robustness Factor Bpl is defined
as codec specific value.

The packet-loss dependent Effective Equipment Impairment Factor

Ie-eff is derived using the codec specific value for the Equipment
Impairment Factor at zero packet-loss Ie and the Packet-loss Robustness
Factor Bpl, both listed in Table 8.6 for several codecs. With the Packet-loss
Probability Ppl, Ie-eff is calculated using the formula (8.46)

126
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Ie  eff  Ie  95  Ie 
Ppl
(8.46)
Ppl  Bpl

As can be seen from this formula (8.46), the Effective Equipment

Impairment Factor in case of Ppl = 0 (no packet-loss) is equal to the Ie
value defined in Table 8.1.

Ie represents the effect of degradation introduced by codecs, Packet

Loss. G.113 provides parameters for use in calculating Ie from codec type
and Packet Loss rate [89].

Table 8.6– Provisional planning values for the equipment impairment

factor Ie and for packet-loss robustness factor Bpl [89]

Packet Size Ie
Codec Rate (Kbps) Bpl
(msec) (no packet loss)

G 711 64 10 0 25.1
G.729A + VAD 8 20 11 19.0
G.723.1+VAD 8.3 30 15 18.1

Coming to the VoIP traffic Characterization, Human speech is

traditionally modeled as sequence of alternate talk and silence periods
whose durations are exponentially distributed and referred as to ON-OFF
model.
On the other hand all of the presently available codecs with VAD
(Voice Activity Detection) have the ability to improve the speech quality by
reproducing Speakers back ground by generating special frame type called
SID (Silence Insert Descriptor). SID frames are generated during Voice
Inactivity Period.

127
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.7 Mapping R factor Into MOS Scale

We can map R into MOS scale by the following equations [90]

For R < 0:
MOS = 1 (8.47)
For 0 <R <100:
MOS = 1 + 0.035 R + 8.10-6 R(R-60)(100-R) (8.48)
For R > 100:
MOS = 4.5 (8.49)
The mapping of R into MOS scale was shown in Figure 8.4.

Figure 8.4 R-factor values from the E-model and corresponding MOS values

8.8 IMS Architecture for VoIP Quality Optimization

IP Multimedia Subsystem is defined by 3rd-Generation Partnership

Project (3GPP) which defines IMS standards as a network domain
dedicated to the control and integration of multimedia services. IMS builds
on Internet Engineering Task Force (IETF) protocols like Session Initiation

128
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Protocol (SIP), Session Description Protocol (SDP) [68] and Diameter

protocol. Figure 8.5 shows the common nodes included in the IMS. These
nodes are:

1) P-CSCF (Proxy-CSCF): The P-CSCF is the first point of

contact between the IMS terminal and the IMS network. All the
requests initiated by the IMS terminal or destined to the IMS
terminal traverse the P-CSCF.
2) I-CSCF (Interrogating-CSCF): It has an interface to the SLF
(Subscriber Location Function) and HSS (Home Subscriber
Server). This interface is based on the Diameter protocol
[76].The I-CSCF retrieves user location information and routes
the SIP request to the appropriate destination, typically an S-
CSCF.
3) S-CSCF (Serving-CSCF): It maintains a binding between the
user location and the user’s SIP address of record (also known
as Public User Identity). Like the I-CSCF, the S-CSCF also
implements a Diameter interface to the HSS.
4) SIP AS (Application Server): The AS is a SIP entity that hosts
and executes IP Multimedia Services based on SIP.
5) The Home Subscriber Server (HSS): contains all the user related
subscription data required to handle multimedia sessions.

129
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Fig. 8.5 IMS Functional Elements

8.9 Project Setup

The simulation is done using OPNET simulation tool IT Guru Academic

Edition 9.1 for VoIP in IMS network using SIP Protocol.

The network consists of IP-Telephones (VoIP or IMS Clients)

connected to the Internet by routers which act as IP gateway, the network is
managed by the SIP proxy server (act as P-CSCF) which uses the SIP
protocol to establish the voice calls (VoIP) on the IMS network as shown in
figure 8.6.

The links between the routers and the Internet are T1 with link speed
1.544 Mbps and the links between the dialer, dialed, Proxy Server and the
routers are 1000 Base-x. The idea is to configure the network with a certain
parameters and run the simulation then getting from the tool the result
values which used in E-Model equations to measure the Quality of service
Factor R.

130
CHAPTER 8 VoIP Quality Optimization in IMS Networks

The objective function for all cases is to maximize the number of calls
that can be active on a link while maintaining a minimum level of voice
quality (R). The cases considered are:

1. Find the optimal voice coder given link bandwidth, packet loss level,
and background link utilization level.
2. Find the optimal voice coder and the optimal packet loss level given
link bandwidth and background link utilization.
3. Find the optimal voice coder and the optimal background link
utilization level given link bandwidth and packet loss level.

Standard parameters for each codec used in the analysis are listed in
Table 8.7.

8.9.1 IMS Network Topology

Figure 8.6 IMS Network Topology

131
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.9.2 Project Simulation Parameters

For the 3 cases mentioned previously, the network links' speed is T1

(1.544 Mbps) and the layer 2 protocol is Point to Point Protocol (PPP).
Table (8.7) shows standard parameters for each codec used in the analysis

Table 8.7 Codec Parameters

Codec
Infor- Bandwidth Calculations
mation
Number
Codec Voice Packets Bandwidth
Voice of Voice MTU
& Bit Payload Per with
Payload Frames Size
Rate Size Second RTP/UDP/IP/
Size (ms) per (Bytes)
(Kbps) (Bytes) (PPS) PPP Header
Packet
G.711
207
(64 160 Bytes 20 ms 1 50 82.8 Kbps
Bytes
Kbps)
G.729 67
20 Bytes 20 ms 1 50 28.8 Kbps
(8 Kbps) Bytes
G.723.1
71
(8.3 24 Bytes 30 ms 1 34 18.9 Kbps
Bytes
Kbps)

8.10 Results

In this part the results of the 3 cases are presented and also the
comments for this results.

The results are divided into three general cases. For all cases, the aim
is to maximize the number of calls that can be carried on a link while
maintaining a minimum voice quality level (R > 70).If two combinations

132
CHAPTER 8 VoIP Quality Optimization in IMS Networks

produce the same number of calls, the highest R value will be considered the best
selection.

8.10.1 Case 1 - Optimizing for Coder Selection

The goal of this case is to find the optimal voice coder given link
bandwidth, packet loss level, and background link utilization level.

Table 8.8 and Table 8.9 are containing the coding parameters used
in Case1-1 of the simulation. OPNET is configured by these parameters
which are according to the ITU-T G.107 [87]

Table 8.8 shows the main differences between the codecs

G.711,G.729 and G.723.1 with respect to the coding type, coder bit rate,
frame length , number of voice frames per packet and finally the Ie for each
coder in case of no packet loss.

Table 8.9 also shows other differences between voice codes G.711,
G.729 and G.723.1 with respect to the bandwidth calculations like voice
payload size, number of packets per second and the bandwidth required
after adding the headers of other protocols.

For Case 1 with a link speed of 1.544 Mbps, The simulation was run
for 2 hours and 4 hours and in all cases G.723.1 gave the max. Number of
calls with R value more than 70, so G.723.1 was selected as the optimum
Coder.

133
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Table 8.8 Codec Parameters for case1-1 [87] [90]

Frame Number
Codec Voice
Look length of Voice IE
Bit Frame
Standard Type ahead (ms) Frames No
Rate Length
(ms) Packet per PL
(kbps) (ms)
Length Packet
G.711 PCM 64 0.125 0 20 1 0
CS-
20 2 11
G.729 ACELP 8 10 5
MP-
G.723.1
MLQ 8.3 30 7 30 1 15

Table 8.9 Codec Parameters for case1-2

Codec
Infor- Bandwidth Calculations
mation
Number
Codec Voice Packets Bandwidth
Voice of Voice MTU
& Bit Payload Per with
Payload Frames Size
Rate Size Second RTP/UDP/IP/
Size (ms) per (Bytes)
(Kbps) (Bytes) (PPS) PPP Header
Packet
G.711
207
(64 160 Bytes 20 ms 1 50 82.8 Kbps
Bytes
Kbps)
G.729 87
20 Bytes 20 ms 2 50 34.8 Kbps
(8 Kbps) Bytes
G.723.1
71
(8.3 24 Bytes 30 ms 1 34 18.9 Kbps
Bytes
Kbps)

For Case 1 with a link speed of 1.544 Mbps, The simulation was run
for 2 hours and 4 hours and in all cases G.723.1 gave the max. Number of
calls with R value more than 70, so G.723.1 was selected as the optimum
Coder.

134
CHAPTER 8 VoIP Quality Optimization in IMS Networks

For G.711 gave the max. Quality of service (Highest R value) but the
lowest number of calls, G.729 gave middle number of calls between G.711
and G.723 and also middle R value. As shown in Table 8.10

Figure 8.7 shows the average packet end to end delay for different
codecs and figure 8.8 shows the number of connected calls for different
coders.

Figure 8.7 Average Packet End to End Delay

135
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Figure 8.8 Number of Connected Calls for different codecs

The following table (8.10) contains data collected from OPNET in this case
of 4 hours observation

Table 8.10 case (1) results

Delay
PL
CODEC (TA) ID IE R MOS Calls
Ratio (ms)
G.711 115 2.76 0 90.44 4.33 28

0% G729a 89 0 11 82.776 4.02 30

G723.1 97 0 15 78.2 3.86 39

The results of this case are shown in Figure 8.9 not surprising, as
G.723.1 is a more efficient but lower quality of voice.

136
CHAPTER 8 VoIP Quality Optimization in IMS Networks

R-Value and Number of Calls Vs. Coder

100
90
80
Number of Calls

70
R-Value

60 R-Value
50 Number of Calls
40 Thershold R-Value
30
20
10
0
G.711 G.729 G.723
Coder

Figure 8.9 R Value, Number of Calls vs. Coder – case (1)

For Case 1 with a link speed of 1.544 Mbps, G.723.1 was selected as
the optimum coder by the OPNET tool. It found 15 calls in 2 hours
simulation and 39 calls for 4 hours observations.

Table 8.5 contains data collected from the OPNET program. It

clearly shows that the optimization selected the correct coder. The results of
this case are not surprising, as G.723.1 is a more efficient but lower quality
of voice.
An interesting observation is that the results generated for both the R
value and number of calls is similar except for the scale.

8.10.2 Case 2 - Optimizing for Coder and Packet Loss Level

Selection

The goal of this case is to find the optimal voice coder and the
optimal packet loss level given link bandwidth and background link
utilization.

137
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Table 8.11 contains the parameters used for case 2 of the simulation
which is according to the ITU-T recommendation G.113 [89].

Table 8.11 Codec Parameters for case 2 [89]

Codec Rate (Kbps) Packet Size Ie Bpl

(ms) With no
PL
G 711 64 10 0 25.1
G.729A+VAD 8 20 11 19.0
G.723.1+VAD 8.3 30 15 18.1

The OPNET simulation is configured by the above parameters like

the codec bit rate and the packet size and the number of voice frames per
packet but other values like Ie and Bpl are coming from ITU-T G.107 and
G.113 for the mentioned codecs.

The simulation was run for 1 hour, 2 hours and 4 hours and for the 3
coders G.711, G.729 and G.723 with different values of packet loss ratio.

For the 3 coders G.711.G.729 and G.723 with different values of

packet loss ratio (0.5 %, 1 %, 1.5 %, 2 % and 5 %) knowing that the
maximum allowable ratio is 2% but the simulation was run for PL% equal
5% to observe the network behavior in case of big crisis as shown in Figure
8.10.

The test was run with a link speed of 1.544 Mbps. The maximum
number of calls was 29 calls. G.723.1 with packet loss of 0.5% was the
combination chosen and the same combination was chosen till packet loss
of 1.5 %.

138
CHAPTER 8 VoIP Quality Optimization in IMS Networks

When packet loss ratio reached 2 %, G.723.1 became not feasible as

its R value is less than 70 and G.729 with packet loss 2% was the
combination chosen.

For packet loss more than 2 % G.723.1 and G.729 became not
feasible and the only feasible coder is G.711.G.711 with packet loss more
than 2 % was the combination chosen. The results for case 2 is listed in
table 8.12
Table 8.12 Results for case (2)

Delay
PL
CODEC (Ta) ID IE R MOS Calls
Ratio
(ms)
G.711
142 0.054 1.855 91.29 4.36 27

G729a
0.50% 86 0 13.15 80.05 4.02 28
VAD+
G723.1
91 0 18.4 75.8 3.7 29
VAD+
G.711
141 0.053 3.64 89.51 4.3 27

G729a
1.00% 86 0 15.2 78 3.8 28
VAD+
G723.1
91.4 0 19.678 73.522 3.6 35
VAD+
G.711
141 0.053 5.36 88.78 4.2 25

G729a
1.5% 87 0 18.15 78.05 3.8 29
VAD+
G723.1
93 0 21.82 71.38 3.6 33
VAD+
G.711
140 0.053 0118. 88.136 4.2 27

G729a
2% 87 0 19 74.99 3.7 29
VAD+
G723.1
92 0 23.839 69.153 3.5 34
VAD+
G.711
137 0.052 15.78 74.732 3.7 28

G729a
5% 86 0 28.5 64.7 3.3 26
VAD+
G723.1
91 0 33.95 59.25 3.04 27
VAD+

139
CHAPTER 8 VoIP Quality Optimization in IMS Networks

From the results in table (8.13) we can notice that:

1-With Packet Loss 2% G.723 is not feasible as its R-value < 70.
2-With Packet Loss more than 3.5% G.723 and G.729 are not feasible as
their R-value < 70 and you have no choices because G.711 is the only
feasible coder with R >70.

The optimization Results for case (2) is listed in Table (8.13)

Table 8.13 - Results of E-Model Optimization Case (2)

Packet
Case # loss% Optimum Coder
1 0.5% G.723.1
2 1% G.723.1
3 1.5% G.723.1
4 2% G.729
5 > 3.5% G.711

Fig. 8.10 R Value and PL % vs. Coder – case (2)

140
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.10.3 Case 3 – Optimizing for Coder and Background Link

Utilization

The goal of this case is to find the optimal voice coder and the
optimal background link utilization level given link bandwidth and packet
loss level.

The simulation was run for link speed T1 1.544 Mbps with
variable background link utilization (90%, 92%, 94% and 95%) and
different coders; the packet loss ratio was considered 0 % in all cases.

G.711 with back ground link utilization 90 % was the combination

chosen as the all coders gave the same number of calls and G.711 gave the
highest R-value which means the highest quality. With back ground link
utilization 92%, 94% and 95% , G.723.1 became the chosen coder. With
back ground link utilization 95% , G.711 became not feasible as its R value
was below 70 and the feasible coders were G.729 and G.723.1 , as shown in
figure 9.

It was shown that that all three coders were in a feasible range until
background link utilization reached approximately 94%.

In Figure 8.11, R remains constant for all coders until a point

where R declines rapidly. This is important because it suggest that there is
optimal link utilization where the system can be operated prior to the R
value decline.

The sudden decrease in R is due to the fact that as utilization

values approach 100%, the delay becomes unbounded, which negatively
affects the R value. It is noticed that at 90% background Link utilization
that all coders give the same number of calls, so the selection in this case is
based on the R-Value which is the highest for G.711.

141
CHAPTER 8 VoIP Quality Optimization in IMS Networks

It is also noticed that the most affected parameter in this case is the
Id , as the Background Link Utilization is affecting the Delay (Id)
parameters as shown in Figure 10. The optimization results for case (3) are
listed in Table 8.14

Table 8.14 Codec Parameters for case 3

Frame Number
Codec Voice
Look length of Voice IE
Bit Frame
Standard Type ahead (ms) Frames No
Rate Lenght
(ms) Packet per PL
(kbps) (ms)
Length Packet
G.711 PCM 64 0.125 0 20 1 0
CS-
20 2 11
G.729 ACELP 8 10 5
MP-
G.723.1
MLQ 8.3 30 7 30 1 15

The test was run with a link speed of 1.544 Mbps and the simulation
was run for 2 hours.

G.711 with Back ground link utilization 90 % was the combination

chosen as the all coders gave the same number of calls and G.711 gave the
highest R-value which means the highest quality.

With Back ground link utilization 92%, 94% and 95%, G.723.1
became the chosen coder.

With back ground link utilization 95% G.711 became not feasible as
its R value was below 70 and the feasible coders were G.729 and G.723.1.

Table 8.15 contains the results obtained for case 3; the variables in
this case are the Background Link Utilization and the coder type.

142
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Looking at Figure 8.11 we can see that all three coders were in a
feasible range until background link utilization reached approximately 94%.

Table 8.15 Results for case (3)

Background
Delay
Link
Utilization Codec (Ta)
ID IE R MOS Calls
% (ms)
G.711
132 0.02 0 93.18 4.4 13
G729A
90%
91 0 11 82.2 4.1 13
G723.1
97 0 15 78.2 3.9 13
G.711
148 0.13 0 93.07 4.4 14
G729A
92%
94 0 11 82.2 4.1 18
G723.1
104 0 15 78.2 3.9 19
G.711
278 12.28 0 80.9 4 17
G729A
94%
97 0 11 82.2 4.1 14
G723.1
106 0 15 78.2 3.9 18
G.711
2326 49.4 0 43.79 2.2 22
G729A
95%
123 0.004 11 82.196 4.1 8
G723.1
124 0.004 15 78.196 3.9 15

143
CHAPTER 8 VoIP Quality Optimization in IMS Networks

In Figure 8.10, R remains constant for all coders until a point where
R declines rapidly.

This is important because it suggest that there is optimal link

utilization where the system can be operated prior to the R value decline.
The sudden decrease in R is due to the fact that as utilization values
approach 100%, the delay becomes unbounded, which negatively affects
the R value.

Figure 8.11 R Value, Background link Utilization % vs. Coder – case (3)

It is noticed that at 90% background Link utilization that all coders

give the same number of calls, so the selection in this case is based on the
R-Value which is the highest for G.711.

It is also noticed that the most affected parameter in this case is the
Id which is expected as the Background Link Utilization is affecting the
Delay (Id) parameters as shown in Figure 8.12.

144
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Figure 8.12 Background Link Utilization % and Id vs. Coder – case (3)

The optimization Result for case (3) is listed in Table (8.16)

Table 8.16 - Results of E-Model Optimization Case (3)

Background
Case # Link Utilization Optimum Coder
1 90% G.711
2 92% G.723
3 94% G.723
4 95% G.723

8.10.4 Discussion of E-Model Optimization Results

This chapter utilized the E-Model to assist with the selection of

parameters important to Design VoIP Network.
These include the voice coder, allowable packet loss and the
allowable background link utilization. It was based on the concept that
maximization of the link usage with respect to the number of calls which is
important to the user.

145
CHAPTER 8 VoIP Quality Optimization in IMS Networks

An important finding of this research is that an optimization of the

E-Model is possible and useful. Table 8.17 reviews the total results of the
optimization problem.

All three cases found that G.723.1 is optimal depending on the

Circumstances. G.723.1 looks more favorable due to the fact that G.723.1
uses less bandwidth per audio stream.

Case 2 found that G.723.1 with 0.5%, 1% and 1.5% packet loss was
optimal but with packet loss 2 % it was not feasible and G.729 was the
optimum coder.

Case3 G.711 coder was selected in case of background link

utilization of 90% but in all other cases till 95% g.723.1 was the optimal
coder giving the maximum number of calls with R Value more than 70%.

Table8.17 The total results of the optimization problem.

Case # Variables Optimum Solution

1 Coder G.723.1
2 Coder, Packet Loss % G.723.1 with 0.5% PL
3 Coder, Packet Loss % G.723.1 with 1% PL
4 Coder, Packet Loss % G.723.1 with 1.5% PL
5 Coder, Packet Loss % G.729 with 2% PL
6 Coder, Packet Loss % G.711 with 5% PL
7 Coder, Background Link utilization G.711With Link Utilization 90%
8 Coder, Background Link utilization G.723 With Link Utilization 92%
9 Coder, Background Link utilization G.723 With Link Utilization 94%
10 Coder, Background Link utilization G.723 With Link Utilization 95%

Although this model has potential to be very useful in helping to

select coders and allowable parameters like utilization and packet loss, it is
not without weaknesses. In all three tests, G.729A and G.723.1 were near

146
CHAPTER 8 VoIP Quality Optimization in IMS Networks

enough to an R Value of 70 that any error in the estimates for delay or

packet loss may cause an error in the optimization. In these situations, the
optimization is considered to be sensitive to changes in those parameters.

The ability to analyze various coders, delay, packets loss and the
effect of background link utilization is vital to the design of VoIP network.
The optimization of the E-Model provides a tool that is useful for this
purpose.

8.11 Proposal to Enhance the E-Model

In this section we propose some new equations developed by us

using MATLAB could be added to E-Model equations to enhance E-Model
performance.
It is noticed that the most affected parameter in case (2) when
trying to find the best coder in different packet losses condition is the Ie
which is expected as the PL is affecting the Ie parameters as shown in
Figure 8.13.

Figure 8.13 PL % and Ie vs. Coder – case (2)

Case 2 required additional analysis because not all of the packet loss
percentages have been tested and recorded (as shown in Table 8.7).

147
CHAPTER 8 VoIP Quality Optimization in IMS Networks

A polynomial fit was completed for each of the three coders.

For G.711, the following polynomial was generated, where x

represents the level of packet loss and y represents the level of impairment
(Ie).
y = 0.0046 x3 - 0.156x2 + 3.8x - 0.00035

Figure 8.14 shows a graph of the observed versus the curve fit.

Figure 8.14 G.711 Polynomial Fit

For G.729A, the following polynomial was generated:

y = 0.0081x3 - 0.22x2 + 4.4x + 11

Figure 8.15 shows a graph of the observed data versus the curve fit.

148
CHAPTER 8 VoIP Quality Optimization in IMS Networks

Figure 8.15 G.729A Polynomial Fit

For G.723.1, the following polynomial was generated:

y = 0.084x3 - 0.74x2 + 5.2348x + 15

Figure 8.16 shows a graph of the observed data versus the curve fit.

Figure 8.16 G.723.1 Polynomial Fit

149
CHAPTER 8 VoIP Quality Optimization in IMS Networks

8.12 Conclusions

IP Multimedia Subsystem (IMS) is very important due to the

critical role it plays in the Next Generation Network (NGN) of the Fixed
and Mobile Networks. Voice traffic in IMS will be served using Internet
protocol (IP) which is called Voice over IP (VoIP). This chapter uses the
"E-Model" developed by ITU-T as design tool to select network and voice
parameters like coding scheme, packet loss limitations, and link utilization
level in IMS Network.
The objective function for all cases is to maximize the number of
calls that can be active on a link while maintaining a minimum level of
voice quality (R< 70).
The cases considered are:
1. Find voice coder given link bandwidth, packet loss level, and link
utilization level.
2. Find voice coder and packet loss level given link bandwidth and
background link utilization.
3. Find voice coder and background link utilization level given link
bandwidth and packet loss level
OPNET and MATLAB are the optimization tool that is used in this
chapter.
In case 1, we found that G.723.1 is the optimized coder as it gives
the maximum number of calls keeping its R factor more than 70. The
quality of speech is generally higher with G.729A and G.711. But G.729A
and G.711 uses more bandwidth than G.723.1.
In Case 2, both G.729A and G.723.1 were sensitive to changes in
packet loss, but G.711 was not as sensitive.
In Case 3, voice quality was not sensitive to changes in the link load
until the link load grew above approximately 94%.
The chapter also provides new equestrians can be added to enhance
E-Model to relate packet loss to the level of Equipment Impairment (Ie)
with different codecs.

150
CHAPTER 9 Conclusions and Future Work

CHAPTER 9
CONCLUSIONS AND FUTURE WORK

9.1 Conclusions

IP Multimedia Subsystem (IMS) has resulted from the work of the

Third Generation Partnership Project (3GPP) toward specifying an all-IP
communication service infrastructure. Mainly looking at the needs and
requirements of mobile operators, the 3GPP first specified IMS as a service
architecture combining the Internet’s IP technology and wireless and mobility
services of current mobile telephony networks. After that the IMS architecture
was extended to include fixed networks as well. By deciding to use session
initiation protocol (SIP) as the signaling protocol for session establishment and
control in IMS instead of developing its own set of protocols, 3GPP has
opened the door toward a tight integration of the mobile, fixed and Internet
worlds. Recent reports already indicate that there are more than 200 million
subscribers using the IMS technology for telephony services.

Measuring the capacity of the (IMS) controllers is very important due to

the critical role it plays in the Next Generation Network (NGN) of the Fixed
and Mobile Networks. This thesis proposes a robust and scalable method that
can be used to measure the capacity of the IMS controllers, Call Session
Control Function (CSCF) and benchmark their different vendors. The purpose
of this method is to measure the capacity of the server in terms of how many
calls are routable into a defined time interval and what the consequences of
overloading the system are.

Evaluating the IP Multimedia Subsystem (IMS) Performance is very

important due to the critical role it plays in the Next Generation Network

151
CHAPTER 9 Conclusions and Future Work

(NGN) of the Fixed and Mobile Networks. This Thesis proposes robust and
scalable methods that can be used to test the performance of the IP Multimedia
Subsystem (IMS) controllers, Call Session Control Function (CSCF) and
benchmark their vendors.

In this thesis we provide also a theoretical model that can be used by

operators and network designers to determine the effects of introducing IMS to
their networks in terms of bandwidth usage for example and the effects of
losses and delays on the service quality. This model uses as the input various
traffic characteristics such as the number of calls per second and mean holding
time and network characteristics, such as losses and propagation delays. The
output of the model provides details on the bandwidth and delay needed for
successfully establishing a session when using SIP over UDP in IMS networks.

Voice traffic in IP Multimedia Subsystem (IMS) will be served using

Internet Protocol (IP) which is called Voice over IP (VoIP). This chapter uses
the "E-Model", (ITU-T G.107), as an optimization tool to select network and
voice parameters like coding scheme, packet loss limitations, and link
utilization level in IMS Network. The goal is to deliver guaranteed Quality of
Service for voice while maximizing the number of users served. This
optimization can be used to determine the optimal configuration for a Voice
over IP in IMS network.

The E-Model is a model that allows users to relate Network

impairments to voice quality. This model allows impairments to be introduced
and voice quality to be assessed. Three cases are considered to demonstrate the
effectiveness of optimizing the VoIP network using E-Model.

151
 CHAPTER 9 Conclusions and Future Work

The objective function for all cases is to maximize the number of calls that
can be active on a link while maintaining a minimum level of voice quality
(R< 70).

The cases considered are:

1. Optimization: Find voice coder given link bandwidth, packet loss level,
and link utilization level.
2. Optimization: Find voice coder and packet loss level given link
bandwidth and background link utilization.
3. Optimization: Find voice coder and background link utilization level
given link bandwidth and packet loss level

OPNET is the optimization tool that is used in this thesis.

In case one, we found that G.723.1 is the optimized coder as it gives the
maximum number of calls keeping its R factor more than 70. The quality of
speech is generally higher with G.729A and G.711. But G.729A and G.711
uses more bandwidth than G.723.1. In Case 2, both G.729A and G.723.1 were
sensitive to changes in packet loss, but G.711 was not as sensitive. In Case 3,
voice quality was not sensitive to changes in the link load until the link load
grew above approximately 94%.

9.2 Future Work

In many areas, further research and enhancements is possible because in

this new field of research for example, the following issues can be addressed in
future research:
 In Chapter 7 we presented a theoretical model for evaluating the performance
of IMS Session Signaling in lossy environments. Using this model various
parameters were calculated such as the bandwidth needed for the signaling

151
 CHAPTER 9 Conclusions and Future Work

messages and the session establishment delay. The presented theoretical model
will need to be verified more thoroughly using more elaborated loss models,
different usage scenarios, traffic models as well as investigate the effects of
overloaded servers.

 Further, the presented models in Chapter 7 assume using UDP as the transport
protocol and do not consider TCP. As TCP uses its own retransmission
mechanisms, the number of sent messages and the delay would differ from the
results presented here. With SIP gaining in complexity the message sizes are
increasing as well leading to possible message fragmentation. This can further
change the loss characteristics and needs to be considered in our future work.
Additionally, we only considered calls to single destinations. SIP supports so
called forking that would allow a proxy to forward a request to different
destinations and wait for their responses. This would add additional
complexities in determining the loss behavior and delay values.

 The tests applied in this thesis in chapter 8 for VoIP Quality Optimization in
IMS used a well known codecs (G.711, G.729 and G.723.1) and in future we
are looking forward to apply the same optimization model on Adaptive multi-
rate (AMR) codec. AMR has been chosen by 3GPP as a mandatory codec and
is widely used in current 3G mobile handsets. AMR is a multi-mode codec
with eight modes (AMR475 to MR122) with bit rates between 4.75 Kb/s to
12.2 Kb/s. In current 3G mobile handsets, a fixed bit rate AMR codec (e.g.,
12.2 Kb/s) is normally used.

 The approach discussed in this thesis chapter 8 for VoIP Quality Optimization
in IMS to deal with QoS problems for VoIP can be extended towards different
types of applications, such as video services and web browsing, amongst others.

151
 REFERENCES

[1] 3GPP, Technical Specification Group Services and System Aspects, IP

Multimedia Subsystem (IMS) - Stage 2 (Release 5), TS 23.228 v5.6.0, 2002-
09.
[2] 3GPP, Technical Specification Group Services and System Aspects: QoS Concept
and Architecture (Release 5), TS 23.207 v5.6.0, 2002-09.
[3] 3GPP, Technical Specification Group Core Network; Signaling flows for the IP
multimedia call control based on SIP and SDP; Stage 3 (Release 5), TS 24.228
v5.2.0,2002-09.
[4] 3GPP, TSG SSA, IP Multimedia Subsystem (IMS) – Stage 2 (Release 6), TS 23.228
v.6.3.0, 2006-03.
[5] 3GPP, TSG SSA, IP Multimedia Subsystem (IMS) – Stage 2 (Release 7),
TS23.228 v.7.3.0, 2006-03.
[6] 3GPP, TSG SSA, IP Multimedia Subsystem (IMS) – Stage 1 (Release 8), TS 22.228
v.8.1.0, 2006-09.
[7] Cohen, D; Specifications for the Network Voice Protocol (NVP) RFC 741,
(1977).
[8] ITU-T, 1998, Packet-Based Multimedia Communication Systems. ITU-T.
[9] Handley, M; Schulzrinne, H; Schooler, E; and Rosenberg, J; 1999 SIP: Session
Initiation Protocol RFC 2543.
[10] Rosenberg, J; Schulzrinne, H; Camarillo, G; Johnston, A; Peterson, J; Sparks,
R; Handley, M; and Schooler, E; 2002b SIP: Session Initiation Protocol RFC
3261.
[11] Josef F. Huber. The GSM Evolution to UMTS. Vice Chairman UMTS, 2004.
[12] Bharat Kumar- Lucent- IMS Vision: Building a Services Enhancement Layer
on top of the IMS Core Standards - Network Data and Services Research Bell
Labs, Lucent Technologies - Oct. 2005.
[13] Ericsson Company - IMS - IP Multimedia Subsystem- White paper - Oct.2004.
[14] Technical Specification Group Services and System Aspects (2006), IP
Multimedia Subsystem (IMS), Stage 2, TS 23.228, 3rd Generation Partnership
Project

155
[15] Alexander Harrowell, (October 2006), A Pointless Multimedia Subsystem?,
Mobile Communications International.
[16] Rosenberg, J; and Schulzrinne, H; 2002b Reliability of Provisional Responses
in Session Initiation Protocol (SIP) RFC 3262.
[17] 3GPP, Technical Specification Group Core Network and Terminals ; Numbering,
addressing and identification, TS 23.003,2008
[18] Aboba, B and Beadles, M; 1999 The Network Access Identifier RFC 2486
[19] 3GPP, Technical Specification Group Core Network and Terminals; General
Universal Mobile Telecommunications System (UMTS) architecture, TS
23.101, 2007.
[20] 3GPP, Technical Specification Group Core Network and Terminals; Specification
of the Subscriber Identity Module - Mobile Equipment (SIM-ME) Interface,
TS 11.11, 2007.
[21] 3GPP, Technical Specification Group Core Network and Terminals;
Characteristics of the Universal Subscriber Identity Module (USIM)
application, TS 31.102,2008
[22] 3GPP, Technical Specification Group Core Network and Terminals;
Characteristics of the IP Multimedia Services Identity Module (ISIM)
application, TS 31.103,2008
[23] 3GPP, Technical Specification Group Core Network and Terminals; Signaling
flows for the IP multimedia call control based on session initiation protocol
(SIP) and session description protocol (SDP),TS 24.228,2007.
[24] 3GPP, Technical Specification Group Core Network and Terminals; IP multimedia
call control protocol based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); Stage 3 (Release 7).TS 24.229,2005.
[25] 3GPP, Technical Specification Group Core Network and Terminals; Interworking
between the IM CN subsystem and IP networks; TS 29.162, 2008.
[26] Tsirtsis, G; and Srisuresh, P; Network Address Translation - Protocol
Translation (NAT-PT) RFC 2766 (2000).
[27] ITU-T Rec. Q.761, Signaling System No. 7 - ISDN User Part functional
description. Technical report, ITU-T, 1999.

156
[28] ITU-T Rec. Q.1902.3, Bearer independent call control protocol (Capability Set
2) and Signaling System No. 7 ISDN user part: Formats and codes. Technical
report, ITU-T, 2003.
[29] H.248.1 Gateway control protocol. Technical report, ITU-T, ITR 2005.
[30] Stewart, R; Stream Control Transmission Protocol RFC 4960 (2007).
[31] ITU-T Rec. Q.701, Functional description of the message transfer part (MTP)
of Signaling System No. 7. Technical report, ITU-T, 1993.
[32] Schulzrinne, H; Casner, S; Frederick, R; and Jacobson, V; RTP: A Transport
Protocol for Real-Time Applications RFC 3550 (2003).
[33] 3GPP, Technical specification group core network and terminals, End-to-end
Quality of Service (QoS) signaling flows, TS 29.208, 2007.
[34] 3GPP, Technical specification group core network and terminals, General
Universal Mobile Telecommunications System (UMTS) architecture, TS
23.101, 2007.
[35] 3GPP, Technical specification group core network and terminals, Policy
control over Gq interface, TS 29.209, 2007.
[36] Calhoun, P; Loughney, J; Guttman, E; Zorn, G; and Arkko, J; Diameter Base
Protocol RFC 3588 (2003).
[37] Durham, D; Boyle, J; Cohen, R; Herzog, S; Rajan, R; and Sastry, A; The
COPS (Common Open Policy Service) Protocol RFC 2748 (2000). Updated by
RFC 4261.
[38] 3GPP, Technical specification group core network and terminals, Policy
control over Go interface. TS 29.207, 2005.
[39] 3GPP, Open Service Architecture (OSA) Application Programming Interface
(API) - Part 1, TS 29.198 ,2001
[40] 3GPP, Technical specification group core network and terminals, Customized
Applications for Mobile network Enhanced Logic (CAMEL); CAMEL
Application Part (CAP) specification for IP Multimedia Subsystems (IMS). TS
29.278, 2005.
[41] Noldus, R; CAMEL: Intelligent Networks for the GSM, GPRS and UMTS
Network. John Wiley &Sons, 2006.

157
[42] 3GPP, Technical specification group core network and terminals, IP
Multimedia (IM) Subsystem Cx and Dx Interfaces; Signaling flows and
message contents. TS 29.228, 2008.
[43] 3GPP, Technical specification group core network and terminals, IP
Multimedia Subsystem (IMS) Sh interface; Signaling flows and message
contents. TS 29.328, 2008.
[44] Calhoun, P; Loughney, J; Guttman, E; Zorn, G; and Arkko, J; Diameter Base
Protocol RFC 3588 (2003).
[45] J. Rosenberg , H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R.
Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol,
RFC3261. IETF, June 2002.
[46] J. Peterson. S/MIME Advanced Encryption Standard (AES) Requirement for
the Session Initiation Protocol (SIP), RFC 3853. IETF, July 2004.
[47] R. Sparks. Actions Addressing Identified Issues with the Session Initiation
Protocol's (SIP) Non-INVITE Transaction, RFC 4320. IETF, January 2006.
[48] K. Zeilenga. Lightweight Directory Access Protocol (LDAP): Technical
Specification Road Map, RFC 4510. IETF, June 2006.
[49] Garcia-Martin, M; Henrikson, E; and Mills, D ; Private Header (P-Header)
Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation
Partnership Project (3GPP) RFC 3455 (2003).
[50] M. Handley, V. Jacobson, and C. Perkins. Session Description Protocol (SDP).
RFC 4566. IETF, July 2006.
[51] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A Transport
Protocol for Real-Time Applications. Request for Comments: 3550. IETF, July
2003.
[52] X. Yi. Adaptive Wireless Multimedia Services. Wireless Center, KTH, May
2006.
[53] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The
Secure Real-time Transport Protocol (SRTP), Request for Comments: 3711.
IETF, March 2004.
[54] E.Carrara. Security for IP Multimedia Applications over Heterogeneous
Networks. [Online] [Cited: September 12, 2008]

158
[55] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. Diameter Base
Protocol, Request for Comments: 3588. IETF, September 2003.
[56] Miikka Poikselkä, Georg Mayer, The IP Multimedia Concepts and Services,
3rd Eidtion, 2009 John Wiley & Sons Ltd, ISBN 978-0-470-72196-4
[57] Performance Measurement Tools for SIP Server by Samit Jain from Columbia
University, New York, 2008.
[58] SIPstone - Benchmarking SIP Server Performance by Henning Schulzrinne,
Sankaran Narayanan, Jonathan Lennox and Michael Doyle from Columbia
University, Ubiquity. April 12, 2002.
[59] Testing Session Initiation Protocol.(SIP) Saturation . The University of New
Hampshire, Interoperability Laboratory © 2005.
[60] Intel and Open Cloud performed the SIP Application Server tests in May 2006.
[61] The open SIP express router (OpenSER) http://www.openser.org.
[62] R. Gayraud and O. Jacques. SIPp. SIPp Tool (http://sipp.sourceforge.net).
[63] iptel.org. SIP express router (SER).http://www.iptel.org/ser.
[64] “PROTOS Security Testing of Protocol Implementations” University of
Oulu.www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip
[65] Spectra2|SE2 Software-only IMS and VoIP Testing Solution. Functional and
Load Testing from Your Laptop. Solution Note |
www.tektronix.com/spectra2SE.
[66] Wireshark Network Protocol Analyzer, www.wireshark.org
[67] Methods for Testing and Specification (MTS); Conformance Test Specification
for SIP (IETF RFC 3261); Part 1: Protocol Implementation Conformance
Statement (PICS), ETSI TS 102 027-1 V4.1.1 (2006-07).
[68] 3GPP, Internet Protocol (IP) multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
(Release 9), TS 24.229 V9.2.0 (2009-12).
[69] http://www.ilocus.com/content/report/global-voip-market-2010-11th-annual-
update
[70] H. Chebbo and W. M, “Traffic and load modeling of an IP mobile network,” in
Fourth International Conference on 3G Mobile Communication Technologies,
London, UK, June 2003.

159
[71] V. K. Gurbani, L. Jagadeesan, and V. B. Mendiratta, “Characterizing session
initiation protocol (SIP) network performance and reliability.” In ISAS, ser.
Lecture Notes in Computer Science, M. Malek, E. Nett, and N. Suri, Eds.
Springer, pp. 196–211.
[72] J.-S. Wu and P.-Y. Wang, “The performance analysis of SIP-T signaling
system in carrier class voip network,” in AINA ’03: Proceedings of the 17th
International Conference on Advanced Information Networking and
Applications. Washington, DC, USA: IEEE Computer Society, 2003, p. 39.
[73] H. Fathi, S. S. Chakraborty, R. Prasad, “On SIP session setup delay for VoIP
services over correlated fading channels,” IEEE Transactions on Vehicular
Technology, vol. 55, no 1, pp. 286–295, January 2006.
[74] Muhammad T. Alam (2005). “An Optimal Method for SIP-Based Session
Establishment over IMS” 2005 International Symposium on Performance
Evaluation of Computer And Telecommunication Systems (SCS 2005), July
24-28, Hilton Cherry Hill/Philadelphia, Philadelphia, Pennsylvania, Sim
Series.,Vol 37, No. 3, pp: 692-698.
[75] Sisalem, D.; Liisberg, M.; Rebahi, Y., "A Theoretical Model of the Effects of
Losses and Delays on the Performance of SIP", Globecom 2008, New Orleans,
December 2008
[76] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “Diameter Base
Protocol.” RFC 3588, Internet Engineering Task Force, Sep 2003.
[77] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000
[78] ITU-T, Gateway control protocol: Version2.Recommendation.
[79] H.248, International Telecommunications Union, May 2002.
[80] H. Schulzrinne, S. Casner, S. Frederick, and R . Jacobson, "RTP: a Transport
Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[81] J. Rosenberg, H. Schulzrinne , G. Camarillo, A. Johnston, J. Peterson, R.
Sparks, M. Handley, E. Schooler, “SIP: Session Initiation Protocol.” Internet
Engineering Task Force, RFC 3261, June 2002.
[82] “Signaling flows for the IP multimedia call control based on session initiation
protocol (SIP) and session description protocol (SDP),” 3rd Generation

160
 Partnership Project, Technical Specification Group Core Network and
Terminals, 2007.
[83] Sisalem, D.; Floroiu, J.; Kuthan, J.;Abend,U.; H. Schulzrinne, " SIP Security
", 2009
[84] V. Kueh, R. Tafazolli, B. Evans, “Performance evaluation of SIP-based
session establishment over satellite-UMTS.” Vehicular Technology
Conference, 2003. VTC 2003-Spring. The 57th IEEE Semiannual, Vol: 2, 22-
25 Apr 2003, pp: 1381 – 1385.
[85] H. Fathi, S. S. Chakraborty, R. Prasad, “Optimization of SIP session setup
delay for VoIP in wireless networks,” IEEE Transactions on Mobile
Computing, vol. 5, no 9, pp. 1121–1132, September 2006
[86] 3GPP TSG GERAN, “A Comparison between Packet-Switched Call Setup
Using SIP and GSM Circuit-Switched Call Setup Using RIL3-CC, RIL3-MM,
RIL3-RR, and DTAP,” GP-000508, Nortel Networks, Nov 2000.
[87] ITU-T Recommendation G.107, “The E-model, a Computational Model for use
in Transmission Planning”, Mar. 2005.
[88] 3GPP, TSG SSA, IP Multimedia Subsystem (IMS) – Stage 2 (Release 9), TS
23.228 V9.2.0 (2009-12).
[89] ITU-T Recommendation G.113, “Transmission impairments due to speech
processing”, (11/2007).
[90] ITU-T Recommendation G.108, “Application of the E-model: A planning
guide”, Sep., 1999
[91] ITU-T Recommendation G.729, "Coding of Speech at 8 kbit/s Using
Conjugate-Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP)",
(01/2007).
[92] ITU-T Recommendation G.723, " Dual rate speech coder for multimedia
communications transmitting at 5.3 and6.3 kbit/s)", (05/2006)

161

View publication stats