� Diabelli: An IMS Simulation ToolMauricio Cortes, Jairo O. Esteban, and Hyewon Jun

The IP Multimedia Subsystem (IMS) standards, defined by the 3rd GenerationPartnership Project (3GPP), specify a large number of functional units. Thequantity and location of these units vary widely depending on networkaccess technology, services, and market size. We have developed Diabelli,an IMS simulation tool that models IMS functional units. This tool allowsnetwork designers to specify over 80 different parameters to simulatethe interaction of IMS elements. © 2006 Lucent Technologies Inc.

the simulator and its main parameters and show the

preliminary results for one architectural configura-

tion in IMS, and finally discuss future work and

enhancements.

MethodologyIn this section, we describe key abstractions in-

cluding source routing, central processing unit (CPU)

models, and transaction models. We explain some of

our implementation decisions and their impact on

simulation accuracy.

Source RoutingIn IMS, the path of a message is decided in flight.

For example, the S-CSCF uses filter criteria to deter-

mine the next hop (i.e., the next application server or

control function element to forward a message to).

In addition, an application server can act as an end-

point or a proxy depending on its application logic.

However, these functional units are under develop-

ment. To abstract these features, we use an explicit

“source routing” mechanism in which the message

path is predetermined and stored in the simulated

message header. This path is generated by a call gen-

erator at the beginning of a call, based on input

parameters such as the probability to visit each appli-

cation server. In this way, any improvement affect-

ing the message path can be adopted in the call

IntroductionThe 3rd Generation Partnership Project (3GPP)

has defined a multimedia subsystem in the core net-

work [1]. This subsystem has a large number of func-

tional units to provide blended services residing in the

Internet Protocol (IP) and public switched telephone

networks. These functional units include a number of

elements such as IMS entry/exit proxies, called proxy

call session control functions (P-CSCFs); user home

proxies, called serving call session control functions

(S-CSCFs); and service applications represented by ap-

plication servers. These functional units exchange

Session Initiation Protocol (SIP) messages to register

users and set up/tear down multimedia sessions.

Service providers must make a number of choices

to deploy IMS; they must choose, for example, the

transport layer protocols that will carry the SIP mes-

sages, the location of the elements, the number of unit

instances, and the network topology connecting these

units. In this paper, we introduce Diabelli, an IMS sim-

ulator built upon the ns-2 simulation tool [3]. Diabelli

allows users to study many possible IMS deployments

by simulating network links; S-CSCF, interrogating

CSCF (I-CSCF), and P-CSCF proxies; application

servers; and user agents. The current implementation

is extensible to incorporate other IMS components.

In this paper, we first describe the methodology

used in our design, then present an overview of

Bell Labs Technical Journal 10(4), 255–259 (2006) © 2006 Lucent Technologies Inc. Published by Wiley Periodicals, Inc.Published online in Wiley InterScience (www.interscience.wiley.com). • DOI: 10.1002/bltj.20137

256 Bell Labs Technical Journal DOI: 10.1002/bltj

Panel 1. Abbreviations, Acronyms, and Terms

3GPP—3rd Generation Partnership ProjectCPU—Central processing unitCSCF—Call session control functionDNS—Domain name systemFIFO—First in, first outI-CSCF—Interrogating CSCFIMS—IP Multimedia SubsystemIP—Internet ProtocolP-CSCF—Proxy CSCFPRACK—Acknowledgment to provisional

responsesRFC—Request for CommentsSER—SIP Express RouterSCIM—Service capability interaction managerS-CSCF—Serving CSCFSIP—Session Initiation ProtocolTcl—Tool Command Language

generator. This source route is used by each IMS com-

ponent to forward the message to the next hop. In

case of a network failure, the simulator can discover

from the source route the stateful IMS component

that needs to retransmit.

Processor Usage ModelLike most network simulators, ns-2 ignores the

processing time of a message while modeling trans-

mission, propagation, and queuing delay. This is a

valid assumption as long as the processing time is very

small. However, message processing in IMS requires

creating states, starting timers, and executing filter-

ing criteria. These steps take a significant amount of

time and limit system capacity. Furthermore, Cortes,

et.al. [2] showed that SIP proxies are CPU bound. In

Diabelli, we have implemented a processor model to

simulate the accurate delay and the resource usage

of a message procedure in a network.

Each IMS element runs in a separate simulated

machine. Each machine is modeled by a fixed amount

of memory and one or more CPUs. To simulate the

processor usage, we model two first-in, first-out (FIFO)

queues, representing an incoming message queue and

a CPU-ready queue. The incoming message queue

stores new messages, while the CPU-ready queue

stores active threads. Each node can instantiate one or

more CPUs. Idle threads become active when they

retrieve a message from the incoming message queue.

Active threads wait their turn in the CPU-ready

queue. All CPU instances serve this CPU-ready queue.

Finally, the simulation tracks the memory consumed

by requests, transactions, and messages.

Transaction ModelStandard SIP transaction stateful proxies process

one request by creating one or more transactions, in-

cluding a copy of at least one message, and scheduling

timers to retransmit messages. Each request estab-

lishes at least two transactions—client and server. A

single INVITE request is needed to set up a call. The

proxy must create six timers and at least two transac-

tions, while a non-INVITE request message creates

four timers and two transactions.

In contrast, IMS proxies require at least three re-

quest messages—one INVITE and two PRACKs—to

establish a call. These requests will create 14 timers

and 6 transactions. The creation, updating, and dele-

tion of timers and transactions consumes a consider-

able amount of memory and processing time in each

transaction stateful proxy.

To design a scalable simulator, we trade off accu-

racy of implementation by employing a slightly dif-

ferent retransmission scheme. While our model has a

client and server transaction concept like the tradi-

tional transaction model [5], a message is retransmit-

ted only when the message or its response is lost. That

is, we simulate timer expiration, and retransmission is

triggered accordingly in the previous transaction state-

ful application. For example, a client transaction in a

transaction stateful proxy transmits an INVITE mes-

sage repeatedly until receiving some response. In our

model, the client transaction retransmits an INVITE

only when the INVITE or its corresponding 1xx re-

sponse is lost.

Our simulation does not include retransmitted

messages that are absorbed by transaction stateful el-

ements. Retransmissions take into account only those

messages or its responses that are lost in the network.

Thus, our simulator has less retransmission traffic

than a real implementation. However, our solution

provides the upper bound of system capacity and

achieves the scalability of the simulator.

DOI: 10.1002/bltj Bell Labs Technical Journal 257

IMS Simulator ImplementationDiabelli extends the ns-2 tool to simulate IMS

functional units and the interaction between them.

These units can run in different network and compu-

tational configurations.

ConfigurationOur simulator consists of two parts: C++ imple-

mentation of each component and Tcl configuration

scripts. A basic IMS component class implements the

interaction with the processor usage module and

common message procedures. This class is inherited

by specific IMS components such as S-CSCF to over-

ride message-processing methods. Tcl scripts are used

to configure simulation topologies and component-

specific parameters. Figure 1 shows one of the many

topologies supported by Diabelli. The user can specify

bandwidth, loss rate, and transport protocol for each

link and set SIP processing time, stateful/stateless

proxy and other parameters for each node.

Message FlowA caller generates INVITEs with exponentially

distributed intervals. Using source routing, INVITEs

traverse the network toward a callee. When the mes-

sages arrive, the callee sends corresponding signal

messages such as 183 Progress. Upon receiving a 183

Progress message, the caller generates the next

request message, PRACK. In this way, the 14 signaling

messages from call setup to call termination are

exchanged between caller and callee.

Major ParametersThe major parameters can be classified into four

categories:

• Network topology and traffic-related parameters, such

as the number of component instances, band-

width, and message loss rates,

• Resource-related parameters, such as the processing

time or the memory usage of different message

types,

• Architectural choices, such as simulating stateless or

stateful proxies, the probability for messages to

visit each application server, and usage of the

service capability interaction manager (SCIM), and

• Parameters to generate log files.

To simulate the CPU time necessary to process

incoming messages, we measured the processing time

AS2 AS3AS1

I-CSCFI-CSCF

DNS

Callgenerator

P-CSCF

Callee

P-CSCF

AS—Application serverCSCF—Call session control functionDNS—Domain name system

S-CSCF

I-CSCF—Interrogating CSCFP-CSCF—Proxy CSCFS-CSCF—Serving CSCF

Figure 1.One of the many topologies supported by Diabelli.

258 Bell Labs Technical Journal DOI: 10.1002/bltj

0

50

100

150

200

250

300

350

Cal

l arr

ival

rat

e (c

ps)

0 1 2 3Number of application servers

in the signaling path

4 5 6

290

160

110

80 70 60 50

Figure 2.System capacity of the simulated IMS network withzero or more application servers in the path.

of all SIP message types using the SIP Express Router

(SER) [4], a freely available SIP proxy. These meas-

urements were taken using a Sun* Enterprise

450 dual processor. We specify these measurements in

Diabelli to simulate the CPU for each incoming

message.

S-CSCF Special FeaturesCompared to other components in an IMS net-

work, the S-CSCF has more responsibilities and a

larger message load to process. This message load is

exacerbated by message spiraling, as defined in RFC

3261 [5], when one or more application servers are

involved. Thus, the S-CSCF has the potential to be-

come a major bottleneck. Diabelli’s implementation

of S-CSCF simulates a filter criteria engine and appli-

cation server message spiraling. Subscription and

notification messages are not currently simulated.

Diabelli initial results confirm that IMS system capac-

ity is limited by the S-CSCF maximum throughput.

Application Server Scalability Simulation ResultsApplication servers add flexibility and extensibility

to IMS architecture, but these come at the cost of

scalability. Cortes et. al. [2] show that an S-CSCF

processes 14 incoming messages in a basic topology

with no application servers, plus 14 extra messages per

additional application server to set up and tear down a

call. This study reports that handling SIP messages is

processor intensive. Therefore, a larger number of

application servers in the call path will increase the

number of messages per call to be handled by S-CSCF,

significantly reducing the system capacity.

In order to determine the impact of the number of

application servers on the system capacity, we used

our simulation tool to determine the maximum

throughput achieved by the S-CSCF while varying the

number of application servers in the path. We define

the call setup time as the elapsed time between the is-

suance of the initial INVITE message and the caller’s

receipt of the corresponding 200 OK response. We de-

fine the maximum throughput as the maximum load

that a S-CSCF is able to process using 70% or less of

CPU time and an overall call setup time of 10 seconds

or less.

Figure 2 depicts the system capacity of the simu-

lated IMS network with zero or more application

servers in the path. As the number of application

servers increases, the maximum throughput de-

creases. For example, without any application servers

in the message paths, the maximum throughput

is 290 cps. When one application server is added,

the maximum throughput is reduced to 160 cps.

Therefore, the system capacity can be estimated as

System capacity � Co�(1 � n),

where Co is the capacity of the basic topology and n is

the number of application servers in the path.

Conclusions and Future WorkIn this paper, we describe Diabelli, a new IMS

simulation tool. The current version of Diabelli mod-

els the main IMS components, including S-CSCF,

P-CSCF, application servers, SCIM, and domain name

system (DNS). We present preliminary simulation

results on application server scalability. As expected,

call-setup time increases as the number of application

servers increases due to message spiraling on the

S-CSCF. The maximum throughput of the S-CSCF is

inversely proportional to the average number of

application servers in the signaling path. Since the

S-CSCF is one of the major bottlenecks in the IMS

network, any gains in S-CSCF throughput will

increase the overall system performance.

Diabelli can be used to investigate architectural

choices, mechanisms for reducing message processing

DOI: 10.1002/bltj Bell Labs Technical Journal 259

time, and scheduling algorithms for SIP messages.

We plan to enhance Diabelli by adding new IMS com-

ponents, simulating application servers for instant

messaging and presence, and adding support for SUB-

SCRIBE/NOTIFY messages in the S-CSCF. These

enhancements will allow users to simulate complex

IMS networks and examine their behavior before

incurring in deployment costs.

*TrademarksSun is a registered trademark of Sun Microsystems, Inc.

References[1] 3rd Generation Partnership Project, “IP

Multimedia Call Control Protocol Based onSession Initiation Protocol (SIP) and SessionDescription Protocol (SDP); Stage 3,” Rel. 5,3GPP TS 24.229, V 5.10.0, Sept. 2004,<http://www.3gpp.org/ftp/Specs/html-info/24-series.htm>.

[2] M. Cortes, J. R. Ensor, and J. O. Esteban, “On SIPPerformance,” Bell Labs Tech. J., 9:3 (2004),155–172.

[3] Information Sciences Institute, USC ViterbiSchool of Engineering, “The NetworkSimulator–ns-2,” <http://www.isi.edu/nsnam/ns/index.html>.

[4] Iptel.org, “SER: SIP Express Router,”<http://www.iptel.org/ser/>.

[5] J. Rosenberg, H. Schulzrinne, G. Camarillo,A. Johnston, J. Peterson, R. Sparks, M. Handley,and E. Schooler, “SIP: Session InitiationProtocol,” IETF RFC 3261, June 2002,<http://www.ietf.org/rfc/rfc3261.txt?number=3261>.

(Manuscript approved August 2005)

MAURICIO CORTES is a member of technical staff in theConverged Networks and Services ResearchLab at Bell Labs in Murray Hill, New Jersey.His responsibilities include developing coreSIP technologies. He received a B.S. degreein computer science from Universidad de los

Andes, Bogotá, Colombia, and M.S. and Ph.D. degreesin computer science from the State University ofNew York at Stony Brook. His research interests havefocused on distributed systems, high-performanceInternet servers, and collaborative applications.Dr. Cortes has published more than 20 papers injournals and international conference and workshopproceedings. He is a member of ACM.

JAIRO O. ESTEBAN is a member of technical staff in theConverged Networks and Services ResearchLab at Bell Labs in Holmdel, New Jersey.His responsibilities include research anddevelopment of new techniques to build SIPelements. He received a B.S. degree incomputer science from Universidad de los

Andes, Bogotá, Colombia, and an M.B.A. degree fromUniversidad Externado de Colombia, Bogotá, Colombia.His research interests have focused on distributedsystems, high-performance software techniques,and SIP applications.

HYEWON JUN was formerly a summer intern in theConverged Networks and Services ResearchLab at Bell Labs in Holmdel, New Jersey. Shereceived her B.S. and M.S. degrees inmathematics from Yonsei University inSeoul, Korea. She is currently a Ph.D.

candidate in computer science at the Georgia Instituteof Technology in Atlanta. Her research interests includeenergy-efficient sensor and ad-hoc network design,applications using wireless networks, the integration ofwired and wireless networks, the fault tolerance ofdistributed systems, mobility support and connectionmigration, multimedia service and content distribution,3G IP multimedia subsystems (IMS) architecture, andgeneral distributed systems and networkingarchitectures. �