generator. This source route is used by each IMS component to forward the message to the next hop. In case of a network failure, the simulator can dis

Transcription

1 Diabelli: An IMS Simulation Tool Mauricio Cortes, Jairo O. Esteban, and Hyewon Jun The IP Multimedia Subsystem (IMS) standards, defined by the 3rd Generation Partnership Project (3GPP), specify a large number of functional units. The quantity and location of these units vary widely depending on network access technology, services, and market size. We have developed Diabelli, an IMS simulation tool that models IMS functional units. This tool allows network designers to specify over 80 different parameters to simulate the interaction of IMS elements Lucent Technologies Inc. Introduction The 3rd Generation Partnership Project (3GPP) has defined a multimedia subsystem in the core network [1]. This subsystem has a large number of functional 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 application 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 messages, 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 simulator 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 the simulator and its main parameters and show the preliminary results for one architectural configuration in IMS, and finally discuss future work and enhancements. Methodology In this section, we describe key abstractions including source routing, central processing unit (CPU) models, and transaction models. We explain some of our implementation decisions and their impact on simulation accuracy. Source Routing In IMS, the path of a message is decided in flight. For example, the S-CSCF uses filter criteria to determine 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 endpoint or a proxy depending on its application logic. However, these functional units are under development. 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 generator at the beginning of a call, based on input parameters such as the probability to visit each application server. In this way, any improvement affecting the message path can be adopted in the call Bell Labs Technical Journal 10(4), (2006) 2006 Lucent Technologies Inc. Published by Wiley Periodicals, Inc. Published online in Wiley InterScience ( DOI: /bltj.20137

2 generator. This source route is used by each IMS component 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 Model Like most network simulators, ns-2 ignores the processing time of a message while modeling transmission, 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 filtering 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 Model Standard SIP transaction stateful proxies process one request by creating one or more transactions, including a copy of at least one message, and scheduling timers to retransmit messages. Each request establishes 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 transactions, while a non-invite request message creates four timers and two transactions. In contrast, IMS proxies require at least three request messages one INVITE and two PRACKs to Panel 1. Abbreviations, Acronyms, and Terms 3GPP 3rd Generation Partnership Project CPU Central processing unit CSCF Call session control function DNS Domain name system FIFO First in, first out I-CSCF Interrogating CSCF IMS IP Multimedia Subsystem IP Internet Protocol P-CSCF Proxy CSCF PRACK Acknowledgment to provisional responses RFC Request for Comments SER SIP Express Router SCIM Service capability interaction manager S-CSCF Serving CSCF SIP Session Initiation Protocol Tcl Tool Command Language establish a call. These requests will create 14 timers and 6 transactions. The creation, updating, and deletion of timers and transactions consumes a considerable amount of memory and processing time in each transaction stateful proxy. To design a scalable simulator, we trade off accuracy of implementation by employing a slightly different retransmission scheme. While our model has a client and server transaction concept like the traditional transaction model [5], a message is retransmitted only when the message or its response is lost. That is, we simulate timer expiration, and retransmission is triggered accordingly in the previous transaction stateful application. For example, a client transaction in a transaction stateful proxy transmits an INVITE message repeatedly until receiving some response. In our model, the client transaction retransmits an INVITE only when the INVITE or its corresponding 1xx response is lost. Our simulation does not include retransmitted messages that are absorbed by transaction stateful elements. 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. 256 Bell Labs Technical Journal DOI: /bltj

3 IMS Simulator Implementation Diabelli extends the ns-2 tool to simulate IMS functional units and the interaction between them. These units can run in different network and computational configurations. Configuration Our simulator consists of two parts: C++ implementation 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 override message-processing methods. Tcl scripts are used to configure simulation topologies and componentspecific 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 Flow A caller generates INVITEs with exponentially distributed intervals. Using source routing, INVITEs traverse the network toward a callee. When the messages 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 Parameters The major parameters can be classified into four categories: Network topology and traffic-related parameters, such as the number of component instances, bandwidth, 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 AS1 AS2 AS3 P-CSCF I-CSCF S-CSCF I-CSCF P-CSCF Call generator DNS Callee AS Application server CSCF Call session control function DNS Domain name system I-CSCF Interrogating CSCF P-CSCF Proxy CSCF S-CSCF Serving CSCF Figure 1. One of the many topologies supported by Diabelli. DOI: /bltj Bell Labs Technical Journal 257

4 of all SIP message types using the SIP Express Router (SER) [4], a freely available SIP proxy. These measurements 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 Features Compared to other components in an IMS network, 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 become a major bottleneck. Diabelli s implementation of S-CSCF simulates a filter criteria engine and application server message spiraling. Subscription and notification messages are not currently simulated. Diabelli initial results confirm that IMS system capacity is limited by the S-CSCF maximum throughput. Application Server Scalability Simulation Results Application 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 issuance of the initial INVITE message and the caller s receipt of the corresponding 200 OK response. We define 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. Call arrival rate (cps) Number of application servers in the signaling path Figure 2. System capacity of the simulated IMS network with zero or more application servers in the path. Figure 2 depicts the system capacity of the simulated IMS network with zero or more application servers in the path. As the number of application servers increases, the maximum throughput decreases. 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 C o (1 n), where C o is the capacity of the basic topology and n is the number of application servers in the path. Conclusions and Future Work In this paper, we describe Diabelli, a new IMS simulation tool. The current version of Diabelli models 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 258 Bell Labs Technical Journal DOI: /bltj

5 time, and scheduling algorithms for SIP messages. We plan to enhance Diabelli by adding new IMS components, 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. *Trademarks Sun is a registered trademark of Sun Microsystems, Inc. References [1] 3rd Generation Partnership Project, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3, Rel. 5, 3GPP TS , V , Sept. 2004, < 24-series.htm>. [2] M. Cortes, J. R. Ensor, and J. O. Esteban, On SIP Performance, Bell Labs Tech. J., 9:3 (2004), [3] Information Sciences Institute, USC Viterbi School of Engineering, The Network Simulator ns-2, < ns/index.html>. [4] Iptel.org, SER: SIP Express Router, < [5] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, SIP: Session Initiation Protocol, IETF RFC 3261, June 2002, < 3261>. JAIRO O. ESTEBAN is a member of technical staff in the Lab at Bell Labs in Holmdel, New Jersey. His responsibilities include research and development of new techniques to build SIP elements. He received a B.S. degree in computer science from Universidad de los Andes, Bogotá, Colombia, and an M.B.A. degree from Universidad Externado de Colombia, Bogotá, Colombia. His research interests have focused on distributed systems, high-performance software techniques, and SIP applications. HYEWON JUN was formerly a summer intern in the Lab at Bell Labs in Holmdel, New Jersey. She received her B.S. and M.S. degrees in mathematics from Yonsei University in Seoul, Korea. She is currently a Ph.D. candidate in computer science at the Georgia Institute of Technology in Atlanta. Her research interests include energy-efficient sensor and ad-hoc network design, applications using wireless networks, the integration of wired and wireless networks, the fault tolerance of distributed systems, mobility support and connection migration, multimedia service and content distribution, 3G IP multimedia subsystems (IMS) architecture, and general distributed systems and networking architectures. (Manuscript approved August 2005) MAURICIO CORTES is a member of technical staff in the Lab at Bell Labs in Murray Hill, New Jersey. His responsibilities include developing core SIP technologies. He received a B.S. degree in computer science from Universidad de los Andes, Bogotá, Colombia, and M.S. and Ph.D. degrees in computer science from the State University of New York at Stony Brook. His research interests have focused on distributed systems, high-performance Internet servers, and collaborative applications. Dr. Cortes has published more than 20 papers in journals and international conference and workshop proceedings. He is a member of ACM. DOI: /bltj Bell Labs Technical Journal 259