Overview of IMS Application Layer Interaction

2012 IX International Symposium on Telecommunications (BIHTEL) October 25-27, 2012, Sarajevo, Bosnia and Herzegovina 978-1-4673-4876-8/12/$31.00 ©2012 IEEE Overview of IMS Application Layer Interaction Management Mirza Varatanović, Nerma Šečić-Haračić, Mirko Škrbić, Mesud Hadžialić, Elvedin Grabovica University of Sarajevo e-mail: mvaratanovic@etf.unsa.ba, nsecic@etf.unsa.ba, mskrbic@etf.unsa.ba, mhadzialic@etf.unsa.ba, elvedin.grabovica@efsa.unsa.ba Abstract–IMS (IP Multimedia Subsystem) network has high demands from perspective of multimedia, flexible and interactive communications. Fulfillment of those demands, with appropriate levels of quality, is not a simple task. As usage of services has great progress lately, there is high demand for their interaction management. Authors suggest way of Next Generation Networks application level organization and way of modeling of application level according to service responses to application requests. Main goal is to shift overload boundaries on the application layer and to show that IMS application layer interaction management is very complex, depending topic. Keywords–IMS; application; service; standalone; SOA; modeling I. INTRODUCTION IMS (IP Multimedia Subsystem) is standard NGN (Next Generation Network) architecture defined by 3GPP (3rd Generation Partnership Project) and ETSI (European Telecommunications Standards Institute). IMS architecture is shown in Fig. 1. With the basic idea of integrating different networks into one multifunctional IP - based network, IMS aims to create a unified communication environment for fixed and mobile users by offering enriched and integrated services that were fragmented before. IMS needs to offer a high level of Figure 1. Global IMS architecture [17] interaction for users - enriched calling and enhanced messaging - sharing videos, images, and other multimedia during a voice call (during one communication session), with high level of service personalization. However, this level of communication flexibility significantly complicates the management, and among other things directly influences the increase of the number of signaling messages that must be exchanged and processed [1]. Requests for proceeding are coming from control layer to application layer via S-CSCF (Serving Call Session Control Function). Mkwawa and Kouvatsos [2], using the modeling method, have proven that S-CSCF is throat of the IMS network that processes great number of messages. S-CSCF has implemented functions of routing requests to application layer. But that routing is static and that can’t satisfy demands for application/service implementation. Because of the bottleneck problems additional load on S-CSCF module is not recommended, so overload problems on service layer and dynamic interaction of services should be solved on Application Layer [1]. This paper systematically presents key problems of IMS application level modeling and management of application/service interaction. Also provides a review of previous results and current achievements in this field. First we will classify applications because implementation and management depends of application type. Then we will explain possible architecture and models which can be used for Application layer optimization. At the end we provide guidelines for solving this complex problem. II. APPLICATION CLASSIFICATION Application classifications are distinguished from different standpoints. First we have a user and their expectations from the application, then applications have their own characteristics and then network provides services to the end system as well as to the user. We can classify application on any parameter that is important for any part. It is very hard to incorporate all applications into a unique classification, which will definitely separate the application by some quantitative characteristics. Very often the characteristics of one type of applications could be a part of some other type. The overlaying is often unavoidable [3]. In this section we will explain some classifications that are relevant in IMS field. Different authors use different definitions of application and service. In this paper service is software component that is designed to be re-used by other services or applications using standard interface. Service does not include any user interface and can’t be used by an end user without an application. On the other hand, an application is software component that is not defined to be re-used by any service or application and has one or many user interfaces for end users [4]. From the above definitions applications can be classified into standalone and SOA (Service-Oriented Architecture) applications. Standalone application is application that can fulfill all required functionalities independently. SOA application can fulfill all required functionalities using one or more services and represent trend in application development. The three key drivers for implementing an SOA approach are: • Cost Reduction • Delivering solutions faster and smarter • Maximizing return on investment Even SOA concept of development is strongly built in IMS concept, standalone and SOA application are both present in it. Zagar and Rimac-Drlje in [3] classified application in three classes, based on important parameters for network transmission: • Real-time streaming is characterized by the continuous traffic pattern; • Real-time applications with block transmission transmit one or more blocks of data, and every block has to be delivered within a limited time; • Non-real-time applications - the application that does not carry time sensitive information is a non-real-time application. Also in [3] authors defined parameters that are important for applications QoS (Quality of Service) from different standpoints (user, application, and network). Chen, Farley and Ye in [5] defined QoS measures, classified for all application and for each application class defined range of QoS measures. As QoS measures they defined Response Time Expected by Users, Delay, Jitter, Data Rate, Required Bandwidth, Loss Rate and Error Rate. Their application classification is based on two technology attributes: time dependence and symmetry. Time dependence is information about timing requirements and symmetry is about resource consumption on both sides in communication. Authors divided applications in four groups: • Non Real Time & Asymmetric • Non Real Time & Symmetric • Real Time & Asymmetric • Real Time & Symmetric Also applications can be classified by the number of possible users. For modeling IMS application layer it is important if number of possible users is finite or that number is too big that can be considered as infinite. SIP (Session Initiation Protocol) is main protocol in IMS architecture for creating, modifying and terminating two-party or multiparty sessions. But that doesn’t mean that all application must have SIP support. Based on this fact we can classify two main groups of applications: SIP applications and non-SIP applications. Application classification is very important from the view of modeling, optimization and management of IMS application level. Different classes of applications have demands for different architectures and different parameters are important for optimization and management. III. APPLICATION LAYER MANAGEMENT ARCHITECTURE 3GPP in [6], [7] and [8] suggests implementation of SCIM (Service Capability Interaction Manager) module for interaction management. Many authors recognized problem of static AS (Application Server) assignment by S-CSCF and S- CSCF overload problem ( e.g. [1]), and conclude that SCIM must be independent AS and part of IMS Application layer as show Fig.2. 3GPP starts to use name Service Broker, from IT industry, instead of SCIM and evolution of SCIM to Service Broker is explained in [10]. This field is still not standardized so there are many proprietary solutions which use terms Service Broker and SCIM as modules with same functionalities. Regardless recommendation from many authors for independent Service Broker we have in practice different solutions. In [10] are presented three ways of Service Broker implementation with comparison: integrated part of AS, integrated part of S-CSCF, standalone server. Beside requests which are incoming from IMS core, requests can come from user application. In [4] author present concept of ADP (Application Delivery Platform) which allows Figure 2. IMS architecture with SCIM [9] SOA application development independent from service provider. If ADP communicates with just one Service Provider then ADP doesn’t need functionality interaction management. But ADP is designed to work with more than one service provider and there are same problems with interaction management as in case when request is coming from IMS core. 3GPP in [8] defined three types of Service Broker architectures, as shown on Fig.3., Fig.4. and Fig.5. Figure 3. Centralized Service Broker Figure 4. Distributed Service Broker Figure 5. Hybrid Service Broker Standalone application can extend their capacity very ease adding new application servers with same application. In case of more than one application server it is necessary to make algorithm of efficient processing of requests. In that case we have example of Centralized Service Broker. It is possible to have more than one application and service on one AS. There is module which takes care at least of message routing on AS. That is why we can say that there are modules on AS which makes service interaction. In [11] author explains service composition in IMS using Java EE SIP servlet containers. If we have more than one AS of this type then this is example of Distributed Service Broker that are integrated on AS. Centralized Service Broker can be bottleneck as S-CSCF, and that is why we should group AS according to application classification. For each group of AS one Service Broker is responsible. In that case we have example of Hybrid Service Broker. IV. MODELS FOR OPTIMIZATION APPLICATION LAYER Whatever classification of application is used and whatever architecture is chosen application level management must be optimized. First task is to fulfill mathematical model which will represent the system and after that model should be optimized in order to obtain the best performance for certain parameters. Different application types or management architecture has different approaches for modeling. Authors used a variety of scientific methods to investigate this issue. In this section will be presented papers, which were using queuing theory and network calculus, for IMS application layer modeling. In [12] and [13] is analyzed mathematical model for management of standalone applications. Performance behavior is described with queuing theory. If there is standalone application and one server what is shown on Fig. 6 behavior is described with the simplest queuing model M|M|1 where arrivals are distributed in a Poison manner with arrival rate λ. If arrival message rate is increased, overflow probability is increased too, what can be seen on Fig. 7. Similar graph can be seen if relationship between load and average delay is established Fig.8. Figure 6. Arrivals to a single server [12] Figure 7. Relation between arrival message rate and overflow probability [12] Figure 8. Traffic load versus average delay [12] In one moment average delay became unacceptable for defined QoS and it was necessary to increase capacity of standalone application. Authors added new AS with same functionalities. That case is presented with model M|M|S S≥1, where S is number of servers which processes requests. In practice queue is not infinite and then there is M|M|1|L or M|M|S|L[12] models. If we talk about SOA application, in paper [13] are given analogies that are presented in Table I. and as conclusion we can work with network calculus. First problem is to recognize parameters which have influence on QoS and to find optimal path for processing requests. Problem of finding path which will satisfy multi QoS requests is called Multi-Constrained Path MCP, and finding optimal path is calling Multi- Constrained Optimal Path MCOP. In [14], authors presented SCIM that is based on constant calculations and measuring CPU (Central Processor Unit) utilization, capacity utilization, RAM and bandwidth. These measurements are performed on two levels: group of AS and AS as standalone. That means that first is necessary to find a group of ASs which have the lowest utilization and then in that group, we are finding AS with the lowest utilization. Presented solution provide better solution if we are compared with TABLE I. ANALOGIES BETWEEN PACKET SWITCHED NETWORKS AND SERVICE-BASED WORKFLOWS [13] Packet switched networks Service-based workflows Path through the network Workflow Node in the network Service Packet Request Throughput Rate at which requests can be processed End-to-end delay Time until a workflow execution is complete solution without any management, but too many time and CPU we use for measurement and calculation. Many authors analyze this problem generally on IT (Information Technology) field. Some of achievements from that field can be used in IMS architecture. We will analyze some of these achievements. First authors in [15] explored model based on cost control. Cost control wasn’t interesting in telecommunications because services are used internally without any cost. In presented ADP concept application should be developed by third party and then cost control can be interesting parameter for process of choosing service provider. Then authors in [16] explored model based on prioritizing requests and that concept can be used in IMS. It is necessary to adapt requests prioritization for IMS concept. Presented concept from IT field must be adjusted to IMS concept. V. PROPOSAL FOR SOLVING IMS APPLICATION LAYER INTERACTION MANAGEMENT Analyzing papers in the domain of management and organization of IMS Application Layer can be concluded that there is no unified solution for solving of this problem. Analyses that have been done so far include certain assumptions, whereby the obtained results do not provide the complete picture of the observed problems. The complete resolution of defined problems is much more complex and must be considered in environment that is adequate for real systems. Our proposal for solving the problem is as follows: • Authors suggest using of Service Broker as independent AS as most flexible concept; • Presented architectural concepts are applicable depending on kind of applications and their capacity. Centralization of Service Broker is recommended whenever is possible. In case of great capacities it is necessary to find Hybrid Service Broker which would group ASs according to quantity of their interaction; • For real systems we must support both standalone and SOA application; • For standalone application we will use queuing theory M|M|S, S≥1; • If we have finite number of sources what we can suppose for small capacities, especially for application which have finite number of customers, then we can talk about M|M|S|S model. In that case we are talking about Engset distribution; • We suggest prioritization of application/service requests. First concept for prioritization is based on sensitivity for time delay. Second is based on SLA (Service Level Agreement). For each application/service should exist defined priority in SLA, other max time delay and other price. In that case instead of one queue we have more queues and processing of request scheduling starts in queue with biggest priority. Also we must provide mechanism of increasing priority after defined time in order to prevent too long request waiting for requests with smaller priority; • Authors think that most significant parameter is time delay. But for presented ADP concept price of service is significant parameter too; • For SOA application we suggest to describe each service with time delay and price. This access is called Restricted Shortest Path – RSP; • When we prioritize request for SOA application one service in model will be presented as new service for each priority. We will have in practice one software component as service, but in the model will be presented as different service with different time delay and price; • To avoid constant calculation and measurement of AS recourses we suggest doing that once before start work in real traffic. On this way we will have graphics as showed on Fig. 7 and Fig.8. and we will know time delay and overload probability if we measure just message arrival rate. That is not problem because request scheduling is main job for management interaction module. VI. CONCLUSION Management of application layer is very complex problem. We have different types of applications with different requests for QoS. IMS concept is conceived to provide enriched services with the promising QoS, so it is necessary to continue research and to make new progress towards solving these complex issues. Modeling of telecommunication systems is the only way of finding mathematical dependencies of the output parameters with input ones and to predict behavior of considered systems. That is why is necessary to find model that represent real system and to define the most important parameters which could be modified to fulfill required QoS. This paper gives an overview of some achievements in IMS Application Layer Interaction Management and provides a guideline for future work. Proposed methods should be the subject of the future research in order to solve the defined problem. REFERENCES [1] M. Hadzialic, M. Skrbic, N. Secic, M. Varatanovic, E. Zulic and N. Bijedic, “Problem of IMS modeling – Solving Approaches” CTRQ 2012:The Fifth International Conference on Communication Theory, Reliability, and Quality of Service , pp. 74–78, May 2012 [2] I. M. Mkwawa and D.D. Kouvatsos, “Performance Modeling and Evaluation of IP Multimedia Subsystems“, HET-NETs08, pp. 67-79, February 2008. [3] D.Zagar and S. Rimac-Drlje, “Applications Classification and QoS Requirements”, 24th Int. Conf. Information Technology Interfaces IT1 2002, June 2002. [4] Christian Menkens: „From Service Delivery to Application Delivery in the Telecommunication Industry“, GLOBECOM Workshops (GC Wkshps), IEEE, Decembar 2010. [5] Y. Chen, T. Farley and N. Ye, “QoS Requirements of Network Application on the Internet”, Journal Information-Knowledge-Systems Management Volume 4 Issue 1, pp. 55 – 76, January 2004. [6] 3GPP, “Network Architecture”, TS 23.002, Release 8, V8.2.0 [7] 3GPP, ”IP Multimedia Session Handling; IM Call Model”, TS23.218, v8.0.0 [8] 3GPP, “Study on Architecture Impacts of Service Brokering”, TS23.810, v8.0.0 [9] Kenichi Sakura, Soichiro Tange and Hisayuki Sekine, “Service Delivery Platform Implementing IP Multimedia Subsystem“, FUJITSU Sci. Tech, Vol. 45, No. 4, pp. 409-414, October 2009. [10] H. Chua and C. Tan, “Service Broker Function in IMS Architecture - Issues and Considerations”, 12th WSEAS International Conferenceon Computers, pp. 179 – 186, July 2008 [11] T. Dinsing, G. AP Eriksson, I. Fikouras, K. Gronowaki, R. Levenshteyn, P. Pettersson and P. Wiss, “Service composition in IMS using Java EE SIP servlet containers”, Ericsson Review No.3, pp. 92 – 96, 2007. [12] J.F. Hayes and T.V.J. Ganesh Babu, “Modeling and Analysis of Telecommunications Networks”, John Wiley & Sons, Inc., 2004