ELEKTROTEHNIŠKI VESTNIK 79(3): 99-104, 2012 ENGLISH EDITION Structuring the RCS services on the IMS application layer Part I: Description and comparison parameters Valerij Grašič 1 , Andrej Kos 2 1 Iskratel d.o.o., Ljubljanska c. 24a, 4000 Kranj, Slovenia 2 Univerza v Ljubljani, Fakulteta za elektrotehniko, Tržaška cesta 25, 1000 Ljubljana, Slovenia E-mail: valerij.grasic@iskratel.si Abstract. One of the challenges in the today's open telecommunications networks which are characterized by a multitude of different services is how to place a specific set of RCS services and users on the application servers in a cost efficient way. Our work is reported in two papers. In each of them we proceed from the IMS testing environment consisting of three application servers and five call-based and non-call-based services placed on four different configurations. In the first paper we define parameters providing the basis for description, comparison and optimization of configurations for an arbitrary behavior of scenarios and habits of users and enabling us to determine general parameters of users, time, server traffic, basic calls and normed parameters. In the second paper we will analyse the impact of each of the services on the server traffic and compare the configurations by using the given parameters and the cost function. Keywords: RCS, structuring of services, service triggering, IMS, application server 1 INTRODUCTION The IMS (IP Multimedia Subsystem) [1] defines in detail the architecture of the transport and control layer, but the standards [2], [3] leave many questions open about how to structure the application layer [4]. The challenge that arises is how to place a specific set of services and users to place on the RCS (Rich Communication Suite) [5] application servers in a cost- efficient way. This can be done by comparing and evaluating configurations and scenarios after the parameters that describe the configurations have been defined. This challenge is treated in two papers. In the first paper we define the parameters used to describe and compare an arbitrary configuration and behavior of scenarios, irrespective of the type of services which can be either voice or RCS-based. When defining the description parameters we first analyse five services placed into three application servers and evaluated in four different configurations. In the second paper we will analyse the impact of each service on traffic to the servers and compare the configurations on the basis of the given parameters and the cost function. The work made so far has been primarily based on the research of the Service Broker or SCIM (Service Capability Interaction Manager), dealing with interactions at the service layer [6]. In [7] a general approach to the interactions among the services is proposed. Triggering is analysed also in [8] and [9], where suggestions are given for improving the basic call delay. In [8] is proposed a distributed SCIM (DSCIM) to reduce the session setup time in case of chaining. Analyses and simulations in [9] and [10] show that the S-CSCF (Serving-Call Session Control Function) is the biggest bottleneck for the configuration traffic and that the number of application servers in the chain and user traffic affects this bottleneck. In [11] measurements are made of a real traffic for the basic call in case of one application server. In [12] the possibilities are analysed for structuring the configurations and in [13] simulations are made for one configuration. In our case a wider range of parameters is analysed and the simulations are made for more use cases. For SIP (Session Initiation Protocol) the protocol time performance metrics are defined in RFC 6076 [14] providing the basis on which the SIP infrastructure metrics [15] are defined. In [16], [17], [18] the time and other performance metrics are defined for IMS/NGN (Next Generation Network) and IMS/PES (PSTN/ISDN Emulation Sub-system). In our analysis we extend these time performance metrics (parameters) and add traffic and other parameters. By analysing 20 different sessions and 6 routing scenarios in [19], the IMS traffic model for servers is defined. In [20] two transport models are defined, namely the Poisson (with no bursts) and Pareto (with bursts). In [21] the signals and traffic are analysed using the HSS (Home Subscriber Server) and the Diameter protocol. In our case this is not the network we are dealing with, but the application layer. We do not set the transport model, but we define the parameters to Received June 8, 2012 Accepted September 12, 2012 100 GRAŠIČ, KOS describe the configuration, enabling us to set a model for services. In [22] an example is shown of the environment for the presence service that combines presence information from different sources and for different users. The analysis of the presence service in [23] proposes three amendments to improve the scalability and quality. In [24] NOTIFY is found to cause the largest traffic load, for which a model of the system resources is proposed. In [25] are analysed examples of logging, changing the user status, refreshing the user for the presence service and a mathematical model of the behavior throughout the day is shown. Our analysis is expanded with the presence service, instant messaging service and services based on the voice call. It includes parameters describing configurations to be used for having configurations compared. 2 STRUCTURING THE APPLICATION LAYER FOR RCS So far, the networks have been vertically integrated and based on signaling SS7 (Signaling System No. 7) and IN (Intelligent Network). These networks are closed and their telecommunication services are centralized, one- dimensional and based on the voice call and services around it. Figure 1. Yesterday's and today's reality – from the vertical (one service) into the horizontal networks (more services) We move now into horizontally structured networks. Fig. 1 shows these two realities. We are dealing now with the IMS core network and service platform SDP (Service Delivery Platform). New services are instant messaging (IM, Instant Messaging), sending short (SMS, Short Message Service) and multimedia (MMS, Multimedia Messaging Service) messages, presence and location services, internet television (IPTV, Internet Protocol Television), hybrid services (Mashup), dial services (C2D, Click to Dial), various Web 2.0 applications, games, video sharing, content sharing, as well as services such as SaaS (Software as A service). 2.1 RCS RCS [5] has been initiated by industry. It uses IMS to provide the services for mobile phones. This means that these are not only the voice call and call control that are used, but also the possibility of new RCS services, such as instant messaging, address book and presence service. Most of the RCS capabilities are already available by the internet service providers. RCS reuses the IMS network capabilities and the IMS service platform. 2.2 Service triggering to the application servers At the IMS service layer it is only the service triggering method that is defined. It is based on the initial filter criteria iFC (Initial Filter Criteria) [1], [3]. The iFCs are stored in the database UPSF (User Profile Server Function) (HSS). By using iFC, each message received by the S-CSCF is parsed and directed to the defined application server located outside the core network where the services are then executed. For the voice- based and video-based services, the server is called TAS (Telephony Application Server) and is implemented comply by either with the TS 22.173 [26] standard or the RCS [5] definition. 3 PARAMETERS USED TO DESCRIBE AND COMPARE THE APPLICATION LAYER CONFIGURATIONS 3.1 Dilemmas of structuring the application layer The RCS and IMS standards do not define the rules neither for structuring the application layer nor for comparing the various configurations. The parameters or the metrics to be used as well as determination of the optimal configuration are also modified. The first dilemma when structuring the application layer is the question of the services. In general, on a given application server there may be one, several or all the services for a specific configuration. Also, the behavior of the services is different from that of the TDM world since it is no longer associated only with the basic voice call. The second dilemma concerns the users because on a given application server there may reside only some of the users or all of them. Another dilemma is the fact that the user habits change over time. Such an example is the increase in the use of RCS services from 20% to 30% of users. The question is what does this mean for a specific configuration and behavior scenarios, how and to what extent they are affected. It can happen that in one moment is optimal a certain configuration, but within the time when the user habits change, it is some other configuration that becomes optimal. Each of the above challenges is being dealt with our paper. We try to determine which configuration is optimal at a given time, or which of the configurations is less appropriate for a particular user behavior and habits. Another challenge is how to compare and evaluate configurations and which parameters to use. We define the parameters important for describing, comparing and evaluating configurations and scenarios. We analyse five services placed on three application servers and evaluate them at four different Vertical networks Horizontal networks Services, content Service capabilities Network, transport VoIP Mobile PSTN STRUCTURING THE RCS SERVICES ON THE IMS APPLICATION LAYER PART I: DESCRIPTION AND COMPARISON… 101 configurations. This is done on a test bed with a compact CSCF (Call Session Control Function). The test bed is shown in Fig. 2. 3.2 Analysed services To analyse the parameter definitions, we use a set of five call-based and non-call-based services [1], [23]. These services are the presentation number (OIP/TIP, Originating Identification Presentation / Terminating Identification Presentation), diversion (CDIV, Communication Diversion), alerting (CAT, Customized Alerting Tones), instant messaging (IM, Instant Messaging) and presence (Presence). Besides analysing these services we also analyse registration and subscription. Table 1. Grouping of the analysed services Service TAS basic TAS plus TAS RCS IM RCS P RCS OIP/TIP - - - - CAT - - - - CDIV - - - - IM - - - - Presence - - - - Execution of the multiple services is taken into account at once. For the services related to the voice call this can lead to chaining on the INVITE path. As a service can be executed on the first application server (e.g. OIP for user A) and then on the second (e.g. TIP for user B), third (e.g. the CDIV service for user B) and so on, delays and also additional traffic on the servers are introduced. 3.3 Grouping of services and users for selected configurations There are many possible combinations for grouping the services. In our case the most basic option is chosen. The services are grouped with regard to the source, separately TAS (TAS basic, TAS plus, TAS) and separately RCS (RCS IM, RCS Presence, RCS) (see Table 1) service. The users (N users) are placed on each of the application servers: on each only one-third (N = 1/3) or half (N = 1/2) of the users. From the set of the possible configurations four configurations (K1, K2, K3, K4) are selected (see Table 2). These are the most basic options for structuring the RCS application layer in terms of placement of services and subscribers. Table 2. Service and user grouping for selected configurations K Name AS1 AS2 AS3 K0 TDM - - - K1 AS all 3x TAS, RCS N=1/3 TAS, RCS N=1/3 TAS, RCS N=1/3 K2 RCS IM&P TAS RCS-IM RCS-P K3 TAS plus TAS basic TAS plus RCS K4 TAS 2x TAS N=1/2 TAS N=1/2 RCS On the application server, there can be either all the services (K1), only the TAS services or only the RCS services (K2, K3, K4) executed. This can be done either for all the users (K2, K3) or only some of them (K1, K4). Configuration K0 is used to compare the services executed on the S-CSCF server. Figure 2: Testing environment for analysis 3.4 Description parameters The parameters important to describe certain configurations are described. To the best of our knowledge such parameters have not yet been defined. The only exception are some of the time parameters. The parameters describing various configurations are: general user parameters, time parameters, server traffic parameters, basic call parameters and normed parameters on the S-CSCF server and on the user traffic. Table 3 lists each of the parameters used to describe the configurations. 3.4.1 Assumptions used in defining the description parameters Assumptions used in our definiting the description parameters of the possible configurations are: • Application servers can support all the services, • The term RCS services generally means both the RCS and the TAS services, • Each execution, assumption and definition is related to the busy hour, • Each definition is related to the signaling traffic with regard to the S-CSCF and application servers, • Signaling traffic can be described as the number of signals or traffic (input, output or a sum), • In our case, the number of signals (the total number of signals) is assumed for the traffic. 3.4.2 General user parameters The general user parameters are used to describe the users and their properties. Using these parameters, the traffic generated by users can be determined. Frequency (F) and the number of signals (S) are determined for each phase of the session separately, e.g., for registration, session creating, instant messaging, publishing, service execution and other. To calculate the traffic on the user (TU, Traffic on User), the sum of all AS1 UE-1 UE-N UPSF S/P/I-CSCF AS2 AS3 UE-2 UE-3 102 GRAŠIČ, KOS the signals and frequency of changes for each phase (F1 * F2 * S1 + S2 + ..) is determined. For voice-call-based services this is the sum of the SIP messages for creating, modifying and terminating the session (INVITE, 100, 180, ..) multiplied by the number of sessions in the busy hour. The same applies for instant messaging (MESSAGE, 200) and registration (REGISTER, 401, 200). For the presence service, the number and frequency of publication states (PUBLISH, 200, NOTIFY), and the number and frequency of the receiving notification about the publishing states (NOTIFY, 200) are taken into account. The use-of-service parameter (u) determines the actual proportion of a certain service use. For services based on the voice call, such as the TIP/OIP u=100%, for others, such as CAT, it can be u=20%, and for instant messaging u=70%. For the presence service there are two additional parameters. The first is the share of the users publishing the states (p) (e.g. 70%) and the second is the share of the users receiving notifications about the state publishing (w) (e.g. 50 watchers). 3.4.3 Time parameters The time parameters are used to evaluate the time behavior of a certain configuration. Some of them are defined in [14], [17], [18]. According to RFC 6076 [21], these are the SRD (Session Request Delay), SDD (Session Disconnect Delay), SDT (Session Duration Time) and RRD (Registration Request Delay) parameters. The first three are related to the basic call, and the last ones to registration. SRD refers to the session request delay (between INVITE and 180, for user A) and is the same as the Post Selection Delay parameter, it is known from the TDM world and is defined in E.721 [24]. SDD is the session disconnect delay (between BYE and 200), SDT is the session duration time (between 200 and BYE), and RRD is the registration request delay (between REGISTER and 200). In our case, the existing SRD and SDD parameters are expanded by a minimum and maximum value (SRDmin, SRDmax, SDDmin and SDDmax). The data about the minimum and maximum delay when creating or terminating the session provides a more precise information about the configuration. In a service chain this can be the number of application servers (one, two, three, ..) and the delay of one set can differ from that of the other set of services. To allow for a more detailed description of the configuration, we define some other still unstandardised time parameters, related to the services such as the delay to subscribe for service (SSD, Subscribe Session Delay), the delay for instant messaging (SMD, Session Messaging Delay), and the delay to publish the presence status (SPD, Session Publish Delay). 3.4.4 Traffic parameters of servers The traffic parameters are used to evaluate the traffic of servers and to compare the traffic. We define the traffic on each application server (TAS, Traffic on Application Server) and the average traffic on all the application servers (TASavg). We define the traffic on the maximally (TASmax) and the minimally loaded server (TASmin) and their ratio (TASmm). This allows us to determine the extent at which the application servers are equally loaded. We also determine the traffic on all the application servers (TASall), on the S-CSCF (TS) and on the entire configuration (C, Configuration) (TC). 3.4.5 Basic call parameters Basic call parameters (BC, Basic Call) are used to evaluate the servers according to the basic voice calls. In the TDM world, these are metrics that are based on the basic voice call. The basic voice call is an important information also for RCS when comparing the total traffic. Defining the basic call in the TDM world is easy. Here, the path of the basic call is the same as the path in supplementary services and it usually goes only through one exchange. In RCS, the situation is different. Here it is assumed that the basic calls are also the basic services based on the basic voice call on the application servers. In our case, the basic TAS (TAS basic or TAS) group is taken for the basic call. The Basic call parameters (BC, Basic Call) define the number of the signals (S, Signals) of the basic call on the user (BCSU), on S-CSCF (BCSS), and the number of basic calls (C, Calls) on the user (BCCU). The basic call parameters define the number of basic calls on S- CSCF (BCS) and on all application servers (BCASall), where the basic call goes through two application servers (user side A and B). 3.4.6 Normed parameters on the S-CSCF server The normed parameters on the S-CSCF server (NS, Normed on S-CSCF) define the parameters when there is only the S-CSCF server in the chain. These parameters define the increase in the traffic or in the delay. The parameters define the actual delays and traffic for cases with just S-CSCF in the chain: the SRD (NSSRD) delay, the average traffic per application server (ratio TASavg/TS) (NSTASavg), the maximum traffic on the application server (ratio TASmax/TS) (NSTASmax) and the whole traffic of the traffic on the S-CSCF (ratio A*TASavg/TS) (NSTASall). 3.4.7 Normed parameters for the user traffic The normed parameters for the user traffic (NU, Normed on User) define the traffic parameters according to the user. They define the traffic on the user for each application server (NUTAS), average traffic on application servers (UTASavg), traffic on the maximally (NUTASmax) and minimally (NUTASmin) STRUCTURING THE RCS SERVICES ON THE IMS APPLICATION LAYER PART I: DESCRIPTION AND COMPARISON… 103 loaded application server, traffic on all application servers (NUTASall), traffic on S-CSCF (NUTS) and traffic on the whole configuration (NUTC). Table 3. Description parameters Name General users parameters F Frequency of changes S Number of signals for each change N, TU Number of users, traffic per user u Proportion of service use p, w Proportion of users publishing states (p) and receiving notifications (w) about publishing Time parameters RRD Registration time (REGISTER till 200) SSD Subscription time (SUBSCRIBE till 200) SRD Session establishing time (INVITE till 180) (also SRDmin, SRDmax) SDT Session time (200 till BYE) SDD Session terminating time (BYE till 200) (also SDDmin, SDDmax) SMD Messaging time (MESSAGE till 200) SPD Publishing time (PUBLISH till 200) Traffic parameters of servers TAS Traffic for each AS A Number of all AS TASavg Average traffic on AS (regarding all AS) TASmax Traffic on maximally loaded AS TASmin Traffic on minimally loaded AS TASall Traffic on all AS TASmm Ratio between the maximally and minimally loaded AS (ratio TASmax/TASmin ) TS Traffic on S-CSCF TC Traffic on the whole configuration (TS+ A*TASavg) Basic call parameters BCSU Number of signals for basic call per user BCSS Number of signals for basic call on S-CSCF BCCU Number of basic calls per user BCS Number of basic calls on S-CSCF BCASall Number of basic calls on all AS Normed parameters on the S-CSCF server (if there is just S-CSCF in the chain) NSSRD SRD on S-CSCF (actual SRD/SRD if only S- CSCF in the chain) NSTASavg Average traffic on AS (ratio TASavg/TS) NSTASmax Maximum traffic on AS (ratio TASmax/TS) NSTASall Traffic on all AS (ratio A*TASavg/TS) Normed parameters for the user traffic NUTAS Traffic on user for each AS (ratio TAS/N) NUTASavg Traffic per user for average traffic on AS (ratio TASavg/N) NUTASmax Traffic per user on the maximally loaded AS (ratio TASmax/N) NUTASmin Traffic per user on minimally loaded AS (ratio TASmin/N) NUTASall Traffic per user on all AS (ratio TASall/N) NUTS Traffic per user on S-CSCF (ratio TS/N) NUTC Traffic per user on whole configuration (ratio TC/N) 3.5 Parameters used in comparing configurations and scenarios To compare configurations and scenarios, we use the above described parameters. The parameters enabling us to compare and evaluate various configurations and scenarios. The following three types of the parameters are used: the time, traffic of servers and parameters normed on the user traffic (see Table 4). Table 4. Parameters used in our comparison Name Time parameters SRD Session establishing time (INVITE till 180) SRDmax Maximum session establishment time (INVITE till 180) Traffic parameters of servers TS Traffic on S-CSCF TASmax Traffic on maximally loaded AS TASall Traffic on all AS TASmm Ratio between most and minimally loaded AS Normed parameters on the user traffic NUTASmax Traffic per user on the maximally loaded AS (ratio TASmax/N) NUTASall Traffic per user on all AS (ratio TASall/N) NUTS Traffic per user on S-CSCF (ratio TS/N) Each of the above time parameters is important as they allow us to evaluate the delay of the system. By using traffic parameters, the traffic through the servers of the configuration can be evaluated. Also the traffic parameters can be used to analyse the changes in the traffic through the servers when there is an increase in the use of the presence service (by 30%). The normed parameters on user traffic are used to evaluate the traffic for a given user. Moreover, the normed parameters on the user traffic can be used to determine the processing power needed for S-CSCF and application servers when the number of users increases. There are three possible ways of making a comparison on the basis of the above parameters. The first option is to use one of the parameters (e.g. an average SRD delay). The second is to use all the parameters for a given set of parameters (e.g. traffic parameters). The third is to use multiple parameters (e.g. each of the comparison parameters). Based on thus obtained comparison results, the optimal configuration or several optimal configurations for one or more parameters can be defined. 4 CONCLUSION In the first of the two papers on our work we define the parameters used to describe configurations needed when structuring the application layer for any of the services on IMS and RCS. We define about forty parameters, containing the data to describe the configurations. Parameters enabling the configurations to be compared and evaluated are selected. In absence of rules and standards for structuring the application layer, and having configurations compared 104 GRAŠIČ, KOS with one another, the given parameters are a step towards a more systematic approach to structuring the application layer. In the second paper, the configurations and scenarios will be compared by using the given set of parameters and the optimal configuration using the cost function will be defined. The focus of our future research will be on analysing the configurations and scenarios for a greater number of use cases. This will be done on a real traffic as by simulating scenarios. REFERENCES [1] G. Camarilla, M.A. Garcia-Martin, The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds, Second Edition, John Wiley & Sons Ltd, 2006. [2] 3GPP TS 23.002, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Network architecture. [3] 3GPP TS 23.228, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2. [4] T. Magedanz, N. Blum, S. Dutkowski, Evolution of SOA Concepts in Telecommunications, Computer, pp. 46-50, Nov. 2007. [5] GSM World - Rich Communications, http://www.gsma.com/rcs/, (25.10.2012). [6] A. Gouya, N. Grespi, E. Bertin, SCIM (Service Capability Interaction Manager) Implementation Issues in IMS Service Architecture, Communications, ICC '06. IEEE International Conference, pp. 748 – 1753, 2006. [7] H. Liu, F. Yang, A Generic Approach to Service Conflict Control in IMS, Fifth International Conference on Networking and Services, ICNS '09, pp. 444 - 449 , 2009. [8] Q. Qi, J. Liao, X. Zhu, Y. Cao, DSCIM: A Novel Service Invocation Mechanism in IMS, IEEE GLOBECOM proceeding, pp. 1577-1581, 2008. [9] Z. Xun, J. Liao, X. Zhu, On Performance of 3GPP Service Triggering Mechanism in IMS Network, Software Engineering and Advanced Applications, SEAA 2008, 34th Euromicro Conference (IEEE), pp. 150 – 155, 2008. [10] Z. Xun, J. Liao, X. Zhu, C. Wang, Y. Cao, A Group Based Service Triggering Algorithm for IMS Network, IEEE International Conference on Communications, ICC '09, pp. 1-5, 2009. [11] V. Grašič, L. Zebec, A. Kos, Analiza vpliva proženja v IMS storitvenem sloju, Zbornik devetnajste mednarodne Elektrotehniške in računalniške konference ERK 2010, Portorož, Slovenija, zv. A, str. 249-252, 2010. [12] V. Grašič, Analysis of structuring call and non-call services on trial RCS implementation, Next Generation Services-RCS, VoLTE and Beyond, Workshop, Kranj, Slovenia , 2012. [13] V. Grašič, A. Kos, Analiza postavljanja storitev RCS na aplikacijskem sloju IMS, Zbornik enaindvajsete mednarodne Elektrotehniške in računalniške konference ERK 2012, Portorož, Slovenija, zv. A, str. 73-76, 2012. [14] IETF RFC 6076, Basic Telephony SIP End-to-End Performance Metrics, January 2011. [15] SPEC SIP Infrastructure 2011, http://www.spec.org/sipinf2011/ (25.10.2012). [16] ETSI TS 186 008, Technical Specification, Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN), IMS/NGN Performance Benchmarks, 2007. [17] ETSI TS 186 025 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS/PES Performance Benchmark, 2011-12. [18] ETSI TS 101 563 Speech and multimedia Transmission Quality (STQ), IMS/PES exchange performance requirements, 2012. [19] J.Xiao, C. Huang, J. Yan, A Flow-based Traffic Model for SIP Messages in IMS, IEEE Global Telecommunications Conference, GLOBECOM 2009, pp. 1 – 7, 2009. [20] I.I. Kuzmin, O.A. Simonina, Signaling flows distribution modeling in the IMS, IEEE International Conference on Computer as a Tool, EUROCON '09, pp. 1866 – 1869, 2009. [21] V.S. Abhayawardhana, R. Babbage, A Traffic Model for the IP Multimedia Subsystem (IMS), IEEE 65th Vehicular Technology Conference, VTC2007-Spring, pp. 783 – 787, 2007. [22] K. Peternel, L. Zebec, A. Kos, Using presence information for an effective collaboration, 6th International Symposium on Communication Systems, Networks and Digital Signal Processing, CNSDSP 2008, pp. 119 – 123, 2008. [23] P. Bellavista, A. Corradi, L. Foschini, IMS-based presence service with enhanced scalability and guaranteed QoS for interdomain enterprise mobility, IEEE Wireless Communications, Volume 16, Issue 3, June 2009, pp. 16 – 23, 2009. [24] C. Chi, R. Hao, D. Wang, Z. Cao, IMS Presence Server: Traffic Analysis &Performance Modelling, 18th IEEE International Conference on Network Protocols, ICNP 2008, pp. 63-72, 2008. [25] Z. Cao, C. Chi, R. Hao, Y. Xiao, User Behavior Modeling and Traffic Analysis of IMS Presence Servers, IEEE Global Telecommunications Conference, IEEE GLOBECOM 2008, pp. 2469-2473, 2008. [26] 3GPP TS 22.173, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IMS Multimedia Telephony Service and supplementary services; Stage 1. [27] ITU-T, E.721, Network grade of service parameters and target values for circuit-switched services in the evolving ISDN. Valerij Grašič obtained his B.Sc. and M.Sc. degrees from the Faculty of Electrical Engineering of Ljubljana (Slovenia) in 1994 and 2002, respectively. Since 1994 he has been with Iskratel. His work includes research, development, design, and testing of traditional and IP telecommunications protocols, and research in the field of integration of modern heterogeneous networks. Andrej Kos is an associate professor at the Faculty of Electrical Engineering of Ljubljana (Slovenia). The focus of his scientific research is on telecommunications, multimedia and internet networks and systems on access, aggregation and backbone layer, testing, traffic analysis and optimization of resources, control protocols and development of converged multimedia services.