Implementation and performance analysis of advanced IT services based on open source JAIN SLEE

Transcription

1 4th IEEE Workshop on Wireless and Internet Services WISe 2011, Bonn Implementation and performance analysis of advanced IT services based on open source JAIN SLEE M. Femminella, R. Francescangeli, E. Maccherani, L. Monacelli Dipartimento di Ingegneria Informatica ed Elettronica - DIEI Università degli Studi di Perugia Perugia, Italy {femminella, francescangeli, maccherani, monacelli}@diei.unipg.it Abstract The standard framework proposed by the JAIN SLEE specifications is emerging as a viable alternative for the development of advanced telecom services. The Mobicents JSLEE platform is the only open source implementation of those specifications. Its tuning is not trivial since it relies on several Java technologies implemented in multiple abstract layers. In this paper, we present the implementation of two realistic benchmark services and the relevant test campaign for the performance analysis of the Mobicents JAIN SLEE platform, with the aim of optimizing the achievable system throughput, for using it in a carrier-grade environment. Index terms - JAIN SLEE; SIP; Java; Transactions; MGCP; scalability analysis I. INTRODUCTION A Service Logic Execution Environment (SLEE) is a hosting environment for telecom applications, referred to as a container in Java terminology. The SLEE has been specifically designed to fulfill the requirements of telecom services, which are typically asynchronous and impose QoS network constraints [1], implement both stateful and stateless network control [2][3]. Being composed of several layers of abstraction, which are combined in a multi-tier architecture, a SLEE simplifies the development of new value-added services by providing the non-functional features needed for their execution. The resulting benefit is that the developer can focus only on aspects related to the implementation of the service logic, since the complexity of the underlying layers is masked by high-level APIs. The Java Community, within the Java APIs for Integrated Networks (JAIN) activities, offers a set of standard frameworks and open protocol APIs for the creation of telecommunications services. Telecom providers may greatly benefit from these technologies, as the utilization of standard common interfaces simplifies the integration of new services, and improves the interoperability with multiple networks, protocols and different end-user platforms [4]. Among those activities, the JAIN SLEE (JSLEE) activity provides a set of standardized specifications [5] for the implementation of a SLEE container. This kind of service hosting server is one of the most promising candidates for the deployment of application services in the new convergent telecommunications paradigm based on the IP Multimedia Subsystem (IMS) [25]. This paper focuses on the analysis of the performance of the Mobicents SLEE [6] (MSLEE), a JSLEE open source implementation, which operates on top of the JBoss Application Server (AS) [7]. To evaluate the platform performance, we have set up a test bed and created two realistic VoIP services, based on the Session Initiation Protocol (SIP) and the Media Gateway Control Protocol (MGCP) signaling protocols, which also include a high number of database queries. In fact, to the best of our knowledge, the performance tests of this very promising open-source platform have only been carried out with a test service named Mobicents load test [12], by far too simple when compared to actual, advanced telecom services. Our test bed was based on real-world operation conditions, in order to investigate about the platform suitability for the integration in a production environment. The choice of a test service based on SIP signaling is due to the widespread use of this signaling protocol. In fact, SIP is not only the de-facto standard for the signaling in VoIP and multimedia communications, but it has been also adopted by the IMS framework as the standard signaling protocol for user sessions (also in charge to transport other signaling protocols [20]), and recently it is also being used in other signaling scenarios (e.g. online gaming). In more details, in this paper we will: show relevant results about the impact of some configuration alternatives over the system performance. In particular, we will analyze the usage of transactions as well as the role of some key set up parameters of the Java-based framework; illustrate the system behavior under traffic load with Poisson and deterministic distributed arrivals; present critical aspects regarding some key platform mechanisms, especially focusing on the JBoss Transaction Manager. The MSLEE platform has been chosen since, at the time of writing, it is the only open source implementation compliant with the JSLEE v1.1 specifications. We already have verified that this platform is suitable for carrier-grade deployment, being a viable alternative to high-cost commercial SLEE solutions (see also our previous work [8]). This paper is organized as follows. The next section provides an overview of the platform architecture. Section III describes the performance benchmark testbed and methodology. Section IV presents the relevant results. Section /11/$ IEEE 746

2 V gives some final remarks. II. BGROUND A. JAIN SLEE The JSLEE activity specifies a Java-based, protocol-agnostic, event-oriented container for the execution of carrier grade telecom services [5]. Carrier grade advanced features cover data, user, and management planes, provide well assessed reliability and innovative features for any new type of service, such as dynamic brokering [9] and quality related pricing control, based on the actual consumed networking resources [10][11]. Various Java Enterprise Edition (JEE) technologies are employed in this framework, by adapting them to the specific needs of telecom applications. The service application logic is implemented in system components called Service Building Blocks (SBB). In operation, the JSLEE server creates a pool of SBB objects and manages them according to a well-defined lifecycle. SBBs operate asynchronously by receiving, processing, and triggering events. They can be attached to data streams called Activity Contexts, by which they receive events from other system entities. Also, SBBs may be linked together using parent-child relations, in order to implement the service logic in a modular fashion. In a JSLEE, events are internally managed by a functional element called Event Router, which delivers each event to the appropriate SBB. For what concerns the overall performance, this component plays a critical role, since it processes all system events. External network occurrences, such as SIP or other signaling protocol messages, are translated into internal Java events by so-called Resource Adaptors (RA). More generally, the set of implemented RAs constitutes an abstract interface layer that allows the SLEE to access external resources and interact with them. In practice, a developer who wants to enable service interoperability with a particular protocol stack can simply utilize the relevant RA interface methods in his service code (e.g. methods to access a particular SIP header field). Subsequently, the developer only needs to deploy the proper RA.jar file into the SLEE. B. Mobicents JAIN SLEE Server The Mobicents Communication Platform is an open source project, currently owned by Red Hat [6][13]. It includes a SLEE, a Media Server, a Presence Server, and a SIP Servlet Server. The counterparties are represented by Rhino, a commercial JSLEE by Open Cloud [22] and the Convergent Service Platform, a commercial JSLEE by Amdocs [23]. At the time of writing, the MSLEE is actively under development. In our performance tests, we have used the MSLEE version GA. This version comes with a SIP RA which is already compliant with the new JSLEE v.1.1 specifications. The MSLEE employs several JEE components, such as: Container Managed Persistence (CMP) fields, which enable data persistence for SBB objects; Java Database Connector (JDBC) drivers; Java Management Extensions (JMX) for the environment management and monitoring; Java Naming and Directory Interface (JNDI), which offers lookup functions for service registration. C. JBoss Application Server The MSLEE, as well as the other core servers of the Mobicents Platform, is installed on top of the JBoss AS [7]. JBoss acts as a hosting environment, that is to say, a container for containers. It offers capabilities such as service and SLEE configuration management, deployment, and thread pooling. D. System Configuration: Critical Aspects The resulting service platform is characterized by a considerable complexity, as it integrates the MSLEE framework, the JBoss AS, and the Java Virtual Machine (JVM). In order to achieve an efficient setup of the overall platform, some critical aspects of the architecture must be taken into account. 1) Java Memory Management Being based on the Java technology, the MSLEE relies on the automatic Java Garbage Collector (GC) mechanism for memory cleaning and defragmentation [14]. The drawback is that the developer does not have full control over the GC behavior, which may eventually lead to pauses in running applications [15]. Such pauses are clearly critical for telecom applications. As a matter of fact, the SLEE may freeze when dealing with post-pause avalanche restarts (during each pause, unprocessed messages accumulate in the event router queue). The JVM v.6 includes different GCs, in order to meet the requirements of different classes of applications [15]. In this paper, we present performance evaluated with the Parallel GC scheme only, which is the default one of the JVM. 2) Transactions In data critical environments, transactions are typically used in order to maintain a computer framework (i.e. a database, a file system or an application) in a known, consistent state, after system or database failures. As regards transactions, the MSLEE relies on the JBoss AS transaction system, which natively supports Java Transaction API (JTA), allowing any transaction manager implementation to be used. JBoss is by default configured to use the so-called JTA compatible in-vm transaction manager. It is very fast, but does have two limitations: it is incapable of automated recovery after a server crash; while it does support propagating transaction contexts with remote calls (Java Remote Method Invocation), it does not support the propagation of transaction contexts to other JVMs, so all transactional work must be done in the same JVM as the JBoss server. In some advanced telecom services, such as online banking transactions, the provider may need a transactional behavior to ensure that all operations made on the remote database (which may involve the transmission of subscriber personal information) remain consistent during all the system operation, 747

3 as well as after a system failure. Such a guarantee comes with a great performance overhead, in the form of disk writing operations, which are directly related to the number of transactions processed by the service. Therefore, is of great importance for the provider to carefully evaluate whether to use transactions or not, in order to ensure maximum performance. In practice, the service developer can: choose to use a JTA compatible Transaction Manager capable of automatic detection of those operations that do not need a transaction (i.e. read only SELECT database queries), in order to avoid unnecessary disk writing when the shared resource is accessed; manually configure the shared resource to be accessed either in a transactional or non-transactional way, by using two different connection pools. In this way, the developer is free to choose the transaction management when needed by his service. This is accomplished by simply inserting the JNDI reference to a proper transactional database connector in the code. Also, there can be VoIP services in which transactions are not needed at all, typically when performance requirements are most stringent. This is the case for forwarding, redirect and control VoIP services, for which there is no need to change the state of shared resources. III. BENCHMARK DESCRIPTION The Mobicents community has published a set of performance results [13], obtained by an automatic answering service in which the MSLEE operates like a simple SIP User Agent Server (UAS). This service, called Mobicents load test, is included as a service example in the MSLEE package. It is made of only one SBB which responds to the incoming call, completes the SIP three way handshake, and, after a pre-defined timer expires, sends a BYE request towards the caller SIP User Agent Client (UAC). Since the included load test is too simple to give an idea of the performance of an actual carrier-grade VoIP service, we have implemented two typical VoIP services in order to properly characterize the MSLEE performance in a realistic scenario. Our reference scenario is the trusted IP network of a telecom provider which offers VoIP SIP-based services by means of a MSLEE. The MSLEE is in charge of managing the entire signaling flow, by implementing a call control service. In more details, the service implements a SIP Back-to-Back User Agent (B2BUA) signaling architecture [16], which easily allows the introduction of a third party call control mechanism, very useful when it is necessary to introduce an additional entity controlling the access to a given resource (e.g. the subscriber credit stored in a remote database). In the following, we will present our two VoIP services and the test bed used for our measurement campaign. A. CallControl Service (CCS) This service implements a SIP B2BUA, in which the MSLEE acts both as UAS and UAC, by splitting each call in two SIP dialogs over two distinct call-legs (caller-slee and SLEE-callee, see Fig. 1). In this way, the service has complete control over the ongoing call, as it manages the entire signaling flow. We will refer to this service as CallControl Service (CCS). CCS includes two different timers: the first timer (Call Duration Timer CDT) is used to control the maximum call duration; the second timer (Periodic Database Query Timer PDQT) is used to perform periodic queries to the subscriber profile database. As regards the service operation, as illustrated in Fig. 1, when the initial is received, a root SBB queries the database to retrieve the subscriber profile, including the values of CDT and PQDT timers. Upon receiving the answer to the DB query, the SBB starts the CDT timer, and activates a child SBB called CallControl. The child SBB, in turn, creates the second call leg towards the callee, by initiating a new SIP session, and establishes the RTP media session between the two end points. During the call, the service keeps on querying the database every time the PQDT timer expires. The call comes to an end when the CDT expires making the CallControl SBB send a BYE request on both call legs, which is the case illustrated in Fig. 1. Alternatively, each of the two end points can normally send a BYE message, as shown in Fig. 2, to the other to close the call, prior to the CDT expiration. In this case the MSLEE server simply forwards the BYE message to the other end point and the call is terminated. In both cases, upon call termination by the user or by the CDT, the service performs an additional, final database query. Call duration Figure 1. CCS signaling flow, termination upon CDT expiration. This service could represent an online charging system for pre-paid VoIP calls, which periodically updates the user credit in the subscriber profile by accessing a remote database (see also [21]). However, given the widespread usage of the SIP protocol in several different scenarios, it could simulate a lot of 748

4 other services, also beyond the IP telephony world. In addition, being the MSLEE compliant with JSLEE specifications v1.1, it is also suitable for a variety of application domains demanding event driven architecture for high volume and low latency signaling, even if originally conceived as a VoIP platform. Call duration Figure 2. CCS signaling flow, termination by user. B. CallControl with Media Announcement Service (CCMAS) The second service we implemented is more VoIP oriented than the first one, and it also showcases the protocol-agnostic capabilities of the JSLEE container. This service, called CallControl with Media Announcement Service (CCMAS) makes use of two different network signaling entities: the MSLEE and the Mobicents Media Server (MMS). The MMS is implementable by using an MSLEE with multimedia streams handling functions and supporting various media server endpoints like: announcement, Interactive Voice Response (IVR), packet relay, conference, and loop. All these capabilities are controlled by a local Media Server Controller (MSC) API which can be used within a normal MSLEE SBB. In order to realize the CCMAS, we have implemented a MSC [26] which, by taking advantage of the deployed MGCP RA, decodes MGCP messages and, after some processing, converts them in local MSC API calls. Also, our MSC component can be controlled remotely and it can be deployed in any network architecture that utilizes the MGCP protocol for media gateway control. In this service scenario, the CCMAS establishes and controls a communication between a UAC and a UAS by using the same B2BUA architecture of the CCS described in section III.A. In CCMAS, the B2BUA exploits the additional MGCP support in order to provide audio announcements during the call to the caller (see Fig. 3). These audio announcements are typically used in carrier-grade VoIP services as remaining credit reminders and as call termination messages. As in CCS, this service makes use of two timers also called CDT and PQDT having the same behavior of the CCS ones. For what concerns the signaling flow, when the initial is received, a root SBB queries the database to retrieve the subscriber profile, including the values of CDT and PQDT timers. Upon receiving the answer to the DB query, the SBB starts the CDT timer, and activates the CallControlMAS child SBB. The child SBB completes the SIP session setup as illustrated in Fig. 3. While the call is active, upon reaching a pre-configured threshold (for example a remaining level of credit in the subscriber profile), the CallControlMAS SBB redirects the UAC session to the MMS using a SIP re-. The re- session handshake triggers an MGCP message exchange that results in the creation of a new RTP session between the UAC and the MMS for the audio announcement (Fig. 3). In particular, an MGCP Create Connection command (CRCX) is sent to the MMS. The CRCX contains the Session Description Protocol (SDP) parameters that are included in the re- message and the particular MMS Endpoint to be used (Announcement, in our case). The MMS processes the CRCX command, creates the Endpoint according to the SDP, and responds to the MSLEE with a (Transaction Executed) message that contains the Endpoint SDP and a Connection Identifier, in order to properly setup the media streaming flow. At this point, the MSLEE proceeds with the 3-way handshake with the client and, when the SIP session is established, a Notification Request command (RQNT) is sent to the MMS in order to start the audio streaming. With the RQNT the service specifies the URL of the particular audio file to be played and the request to notify the MSLEE when the announcement is completed. The MMS answers the RQNT and starts to play the announcement message, by sending RTP packets directly to the client. Once completed, the MMS sends a Notify (NTFY) command to the MSLEE to indicate that the RTP flow has ended. The MSLEE replies with a response and sends a Delete Connection (DLCX) command to release the resources used by the endpoint-connection link. Upon the audio stream termination, another SIP re- handshake is used to restore the original UAC-UAS session. During the audio announcement the CDT and PDQT timers are paused until the end of the audio message. As already pointed out for CCS in section III.A, the call comes to an end either when the CDT expires or when one of the two clients sends a BYE message. In the former, as soon as the timer expires, another re- connects the UAC to the MMS that plays another audio stream used to inform the user about the end of the credit while the UAS is disconnected with a BYE message. C. Testbed Topology and Configuration As regards the transport protocol, we have adopted UDP, since it is the common choice in most SIP configurations. We plan to investigate the usage of TCP in a server-server (between MSLEE and MMS) scenario as future work. The testbed topology used in our test campaign is depicted in Fig. 4. The MSLEE and MMS, based on Mobicents v GA and deployed on JBoss v GA, have been installed on Fujitsu-Siemens server-class machines PRIMERGY TX300 S4 with dual Intel Xeon 2.33 GHz (i.e. 8 CPU cores) and 16GB RAM. Servers OS were Arch Linux x64 (kernel ). 749

5 UAC 180 Ringing OK OK OK OK BYE OK SLEE UAS UAC RTP Stream CDT/PQDT start Signal threshold End of Credits 180 Ringing OK CREATE CX REQ NOTIFY RTP Stream NOTIFY DELETE CX BYE OK CREATE CX REQ NOTIFY RTP Stream NOTIFY DELETE CX Callee UAS Policy Selector query Billing database query request Billing database query request Billing database query request Billing database query request Media Server Figure 3. CCMAS signaling flow (SIP messages in black arrows, MGCP messages in red arrows). Database The MySQL connector can be manually configured to use or not transactions. This is achieved by properly configuring the datasource mysql-ds.xml file contained in the JBoss deploy folder. Moreover, we have used the prepared statement cache option for data sources in order to improve the execution of frequent MySQL queries [19]. In order to configure the JVM heap (setting the equal max and min values as recommended in [19]) and select the Parallel GC we have added the following command line flags to the configuration script of the JBoss AS, in this case setting a 6GB heap: -Xms6000m -Xmx6000m -XX:+UseTLAB We have used the Mobicents JAIN SIP RA v and we have tuned it by increasing the number of concurrent threads, in order to allow a greater number of events to be processed at once. As regards the MGCP RA, version GA has been used. We also have run the JAIN SLEE 1.1 Technology Compatibility Kit (TCK) on the MSLEE server, which have successfully passed all tests. All logs have been disabled during the execution of the tests to improve MSLEE and JBOSS AS performance. As for the traffic statistics, the SIPp UAC has been set to generate new SIP calls with both a deterministic and a Poisson arrival rate distribution with an average rate equal to. Every test has been carried out by using a constant value for 60 minutes. The value for the CDT timer has been set to 3 minutes, which represents also the maximum call duration. By default, the UAC SIPp scenario has been configured to let the MSLEE to close the call on CDT expiration. The default value for the PQDT timer has been set equal to. Before collecting statistics, we have performed a warm up sessions of 15 minutes to allow the Java GC to be executed at least once and avoid both JVM and MSLEE transient effects. Figure 4. Testbed configuration. The JVM was the v.1.6.0_11 64-bit Server. In addition, we have used the following software tools: the SIPp traffic generator [18] to simulate the UAC and the UAS end points, installed on two Linux-based PCs with Ubuntu v.8.0.4; the MySQL database server v a, and the MySQL Connector/J v JDBC for the database access, deployed on a remote Linux box. Each database interrogation relied on an object-relational mapping by using an Enterprise Java Bean 3.0 object, which is implemented through the Hibernate technology. This function is provided by the JBoss application server. IV. NUMERICAL RESULTS In the following, we present the performance results obtained for the CCS and CCMAS services evaluated with the test bed shown in Fig. 4. We have considered a number of possible conditions which are likely to occur in production environments. In more detail, in section IV.A, we have tested the impact of the frequency of queries during a call, and the influence of the amount of Java heap allocated to the JVM. In section IV.B, we evaluated how the MSLEE behaves when a non-deterministic pattern of arrivals is present. In section IV.C, we have analyzed the impact of the usage of transactions associated to database queries, which is an option that can be required by specific services. Finally, in section IV.D, we have investigated the performance of the MSLEE when dealing with multiple underlying signaling protocols measuring the throughput of the CCMAS, described in section III.B. In all tests the metric used to assess performance is the maximum call throughput, defined as the maximum load ensuring at least a 95% of successful calls. A. Server Scalability and JVM Tuning In order to verify the SLEE scalability, we have tested the 750

6 system with the CCS, by setting the PQDT to 3, 10 and 30 seconds. For each run considered in this subsection, the traffic arrival pattern was deterministic. The call duration, equal to 3 minutes, has been set by configuring the UAC SIPp scenario to let the MSLEE to close the call upon CDT expiration. In this test the MySQL connector has been configured with DB transactions enabled. Fig. 5 depicts the throughput achieved versus offered load, both expressed in calls per second (cps). Five curves are showed. The curve with the black-square bullets represents the theoretical throughput when no calls are lost. Let us focus on the curves with Java heap equal to 6 GB. The trend shown in the figure confirms our expectations: the higher the frequency of database queries, the higher the number of events processed by the Event Router, thus the lower the throughput. In addition, since we use database transactions, this implies also the presence of a process which writes data on the hard disk for each query. To sum up, the maximum throughput achievable by the MSLEE is scalable with the complexity of the deployed service. Also, we have compared the system performance with two different values of the JVM heap (7 GB and 6 GB), having the PQDT set equal to. Fig. 3 points out how the MSLEE performance increases with a larger amount of allocated memory. In more detail, increasing the Java heap from 6 GB to 7 GB, the maximum throughput goes from 6 cps to 15, thus the service is really sensible to the amount of memory allocated to JVM. In all following sections, measurement tests have been run using the 7 GB heap setup with the PDQT set to 10s. B. Poisson vs. Deterministic Arrivals We have compared the system throughput performance as a function of offered traffic load with deterministic and Poisson distributed arrivals. This choice is motivated by the fact that the Poisson process is a good model for real arrival patterns, especially of VoIP calls, as shown in the work [17]. SIPp generates each SIP call by parsing an external script file called scenario, which may include actions like sending and receiving a SIP message, as well as pauses. By default, SIPp only offers constant rate call generation, set by the proper command line option, eventually further spaced in time by pauses characterized by some common probability distribution, but does not include the Poisson arrival process. To overcome this limitation, we have created a custom scenario applying the following strategy. A Poisson arrival process implies a set of exponentially distributed interarrival times, with average rate. In a given time interval [0, T] where T>>1/, it is known that a Poisson arrival process distributes any given set of arrivals uniformly over T. Thus, in order to produce a Poisson process with rate, we have to generate a number of T arrivals, each of them with a uniform distributed probability to occur in a time instant x ranging in [0, T]. In practice, we have generated all the T calls in a very short time interval [0, t] at the beginning of the test, where t<<t (t is set to ), and delayed the sending of the message by inserting a random pause, uniformly distributed in [0, T-t], so as to have all arrivals in [t, T]. This approach follows the description provided in section 2.5 of [27]. We have verified, through an extensive analysis of traffic traces, that the obtained arrival process actually approximates very closely the Poisson distribution. Fig. 6 reports, on the abscissa, the interarrival times (in seconds) and, on the ordinate, the estimated pdf (on a logarithmic scale). Clearly, a straight line represents a pure Poisson process. Our approximation is valid up to 10-5 which is reasonable since we used 1,500,000 samples. Both interarrival times average, equal to s, and the standard deviation, equal to s, are very close to the theoretical value of 0.04s, corresponding to =25 cps. In this specific test, for calls with Poisson arrivals, we adopted both deterministic and exponentially distributed call durations. In case of exponentially distributed call duration, the average value has been set equal to 180 seconds. This means that about 37% of the calls are closed by the MSLEE and last for 3 minutes, while the remaining calls are shorter and closed by the UAC. The resulting average call duration, due to the effect of tail truncation by the MSLEE, is equal to s. Fig. 7 shows the throughput (in cps) versus the arrival rate (cps) of the CCS. One curve is the classic theoretical one, which indicates the ideal behavior without losses. The one with the plus-shaped bullets is the same curve already seen in Fig. 6. The other two curves represent a test with Poisson arrivals and call length fixed to 3 minutes (star bullets), and Poisson arrivals and call length exponentially distributed (cross bullets). As expected, since a Poisson distribution of the arrival process offers a bursty traffic pattern, a performance drop takes place with respect to the all deterministic scenario. A further comment is necessary to explain the behavior of the Poisson arrivals with exponential call duration curve. In fact, since using an exponential distribution for the call duration leads to a shorter value of average call length, given a value of the abscissa (in cps) the resulting offered load (measured in erlang = cps x call duration) for the relevant curve is lower than the one of the other curves as shown in Fig. 8. Throughput (cps) HEAP = 7 GB, Timer 10s HEAP = 6 GB, Timer 3s 2 HEAP = 6 GB, Timer 10s HEAP = 6 GB, Timer 30s Theoretical - No losses Arrival rate (cps) Figure 5. CCS Scalability benchmark. 751

7 Estimated PDF throughput when transactions are disabled. The PQDT is still set to 10s, the Java heap to 7 GB, and the traffic statistic is completely deterministic in arrival rate and call length. As expected, the related disk writing operations have a major impact on the system performance and represent a real system bottleneck, even if high speed disks are being used in the testbed (Serial Attached SCSI at 15,000 rpm). The maximum throughput rises from 15 cps to 60 cps when transaction are disabled. Throughput (cps) 1e-05 1e-06 1e Interarrival times (seconds) Figure 6. Assessment of Poisson properties for call arrivals Det. arrivals, Det. duration Poisson arrivals, Exp. duration Poisson arrivals, Det. duration Theoretical - No losses Arrival rate (cps) Figure 7. CCS Poisson vs. Deterministic arrival process (cps). This is a first explanation for the apparent better behavior of the Poisson curve. In addition, having an average shorter call length means less database queries (fewer PQDT expirations) and also to avoid the CDT expiration and processing, thus a lower load for the MSLEE Event Router and for the DB connector, which in this test uses transactions. In any case, when curves are plotted in erlang, as in Fig. 8, so as to neglect the impact of call duration, the best performing configuration is again the deterministic one. To sum up, the performance loss due to bursty arrivals is not so severe, and thus the MSLEE seems to be robust also with respect to more bursty, realistic arrival patterns. A further observation is that the presence of bursts in Poisson patterns causes a sudden system crash, as it enters the overload condition. C. System Performance: Utilization of Transactions In this test, we have evaluated the impact of transactions and the consequent disk writing operations. In Fig. 9, shows three curves: the usual ideal curve corresponding to the no loss condition; the throughput when transactions are enabled; the D. CCMAS System Performance In this subsection we present preliminary results about system performance, calculated as call throughput, of the MSLEE when running the CCMAS service. As in section IV.C, the PQDT is set to 10s, the Java heap is set to 7 GB, and the traffic statistic is deterministic in arrival rate and call length (3 minutes). Given the service type, the JTA transaction system has been disabled. Under these conditions, the maximum call throughput reached with CCMAS has been 24cps. This result is perfectly reasonable since, as illustrated in Fig. 9, the same service without the audio announcements (CCS), under the same test conditions, reached a maximum throughput of 60 cps. The reason of the performance drop can be found in the higher number of SIP transactions processed. In fact, in CCS there are only 4 SIP transactions (2 s, 2 BYEs) whereas in CCMAS there are 7 SIP transactions, nearly the double. Also, the additional SIP transactions are of the re- type, which require a lot of internal processing. In addition to the increase in SIP transactions, there is also the MGCP exchanges management to take into account that weigh on the MSLEE. V. CONCLUSION This paper illustrates how advanced networked services can be effectively provisioned in a converged telecommunications architecture by using a completely open source solution, implementing the JSLEE specifications, the Mobicents Communication Platform. This solution is able to work as a carrier-grade service container within different service frameworks (SOA, IMS, or custom ones). Its capabilities of managing sessions have been illustrated through the implementation of two real-world services, CCS and CCMAS, able to handle signaling for advanced, multimedia scenarios. Moreover, we have provided an overview of critical issues in the deployment and in the operation phases of the MSLEE, by describing some configuration options along with the relevant criticalities. The performance test campaign also resulted in useful indications so as to improve performance, defined as the maximum call throughput, of the MSLEE server under real-world operating conditions. Finally, the security vs. performance compromise has also been investigated through the analysis of the impact of the database transactions on the system performance. To further improve performance, more virtual instances of the MSLEE server can be run in parallel within the same physical machine. This is of actual interest for service operators, since it is a further motivation to consolidate servers and it is thoroughly examined in [24]. 752

8 Throughput (erl) Throughput (cps) Det. arrivals, Det. CHT 500 Poisson arrivals, Exp. CHT Poisson arrivals, Det. CHT Theoretical - No losses Offered load (erl) Figure 8. CCS Poisson vs. Deterministic arrival process (erl) Transactions on, timer Transactions off, timer Theoretical - No losses Arrival rate (cps) Figure 9. Transaction impact on CCS throughput. REFERENCES [1] C. Casetti, M. Gerla, S.S.Lee, G. Reali, Resource Allocation and Admission Control Styles in QoS DiffServ Networks, International Workshop on QoS in Multiservice IP Networks (QoS-IP 1), Rome, Italy January, 1. [2] N. Blefari-Melazzi, M. Femminella, "Stateful vs. Stateless Admission Control: which can be the gap in utilization efficiency?," IEEE GLOBECOM 2, November, 2, Taipei, Taiwan. [3] N. Blefari-Melazzi, JN Daigle, N Femminella,"Stateless admission control for QoS provisioning for VoIP in a DiffServ domain", 18th International Teletraffic Congress (ITC 18), 31 August - 5 September, 3, Berlin, Germany. [4] R. M. Perea, Internet Multimedia Communications Using SIP, Morgan Kaufmann, 8. [5] JSR 240, JAIN SLEE v1.1 Web Site [6] Mobicents Web Site, available at: [7] JBoss Web Site, available at: [8] M. Femminella, R. Francescangeli, F. Giacinti, E. Maccherani, A. Parisi, G. Reali, Design, Implementation, and Performance Evaluation of an Advanced SIP-based Call Control for VoIP Services, IEEE ICC 9, Dresden, Germany. [9] D. Di Sorte, G. Reali, Pricing and brokering services over interconnected IP networks, Journal of Network and Computer Applications, 28 (5) [10] N. Blefari-Melazzi, D. Di Sorte, G. Reali: Usage-based Pricing Law to Charge IP Network Services with Performance Guarantees, IEEE International Conference on Communications (ICC) 2, New York, USA, 2 [11] Di Sorte, M. Femminella, G. Reali, A QoS Index for IP Services to Effectively Support Usage-based Charging IEEE Communications Letters, Vol. 8, No. 11, November 4. [12] M. Femminella, R. Francescangeli, F. Giacinti, E. Maccherani, A. Parisi, G. Reali, Scalability and Performance Evaluation of a JAIN SLEEbased Platform for VoIP Services, 21st International Teletraffic Congress (ITC 21), Paris, September 9. [13] Mobicents Google Pages Web Site, available at: http :// groups.google.com/group/mobicents-public/web?pli=1. [14] Java SE 6 HotSpot Virtual Machine GC Tuning, Web Site: ailable_collectors. [15] Bruno Van Den Bossche et al., J2EE-based Middleware for Low Latency Service Enabling Platforms, proceedings of Global Telecommunications Conference, 6. [16] J. Rosenberg et al., SIP: Session Initiation Protocol, IETF RFC [17] R. Birke, M. Mellia, M. Petracca, Understanding VoIP from Backbone Measurements, IEEE INFOCOM 7, Anchorage, USA, 7. [18] SIPp Web Site: [19] J. Jamae, P. Johnson, JBoss in Action, Manning, 9. [20] C. Gourraud, Using IMS as a Service Framework, IEEE Vehicular Technology Magazine, March 7, pp [21] 3GPP TS IP Multimedia Subsystem (IMS) Charging (Release 8), V8.5.0, [22] Open Cloud Web Site, available at: [23] Amdocs Web Site, available at: Service-Platform/Pages/index.aspx. [24] M. Femminella, E. Maccherani, G. Reali, Performance Management of Java-based SIP Application Servers, IM 2011, Dublin, May [25] Khlifi H., Gregoire J.-C., IMS Application Servers: Roles, Requirements, and Implementation Technologies, Internet Computing, IEEE, May-June 8, Volume: 12, Issue: 3, pp [26] M. Femminella, R. Francescangeli, F. Giacinti, E. Maccherani, A. Parisi, G. Reali, Implementation of third party media server controller for IMS networks, MobiMedia 9, London, UK, September 9. [27] L. Kleinrock, "Queueing Systems, Volume I: Theory", J. Wiley&Sons,