User Customisation of Service Request Routing for the IP Multimedia Subsystem

User Customisation of Service Request Routing for the IP Multimedia Subsystem Richard Spiers and Neco Ventura University of Cape Town, Rondebosch, South Africa 021 650 5296 Email: {rspiers,neco}@crg.ee.uct.ac.za Abstract The IP Multimedia Subsystem (IMS) is a framework standardised by the 3rd Generation Partnership Project (3GPP) to provide next generation multimedia services. The control protocol used in the IMS is the Session Initialisation Protocol (SIP), and service creation entails the creation of a SIP Application Server (AS). The AS communicates with the IMS framework through SIP messages. The IMS framework, most notably the Serving Call Session Control Function (S-CSCF), determines which SIP messages to forward from the end user to which particular AS. These decisions are driven by the concept of Initial Filter Criteria (ifc). These filters contain a list of items to compare to the SIP message together with the AS to forward the message to if it matches. This list is statically configured by the network operator, and each filter is assigned a rank or priority. These priorities determine the order in which they are compared to the incoming request, and hence which AS actually gets triggered to provide the service first. The incoming request is then forwarded to the next matching AS once the first AS finishes its service execution, forming a chain of different AS. The purpose of this paper is to present a mechanism to allow the end user to control this message flow, and thereby allow them control over how their services get invoked. Several new entities are added to allow this functionality. These modifications allow the end user to customise their service usage, as well as providing offline conflict detection resolution. Index Terms IP Multimedia Subsystem, JSON, Service Capability Interaction Manager, Session Initial Protocol, I. INTRODUCTION The IP Multimedia Subsystem (IMS) is a Next Generation Network (NGN) that provides multimedia services to the end user. The International Telecommunication Union (ITU) defines a NGN as a packet-based network that is able to use multiple broadband, QoS-enabled transport technologies. The service related functions must be kept separate from the actual transport mechanism used [1]. The IMS fulfils these criteria by utilising the Session Initiation Protocol (SIP) as the control protocol, which can be transported over several different transport mechanisms over the packet switched IP core [2]. Part of the motivation for moving to a new telecommunication framework is to allow the network operator to become more cost effective in offering new services. The IMS can be used to achieve this as it allows the service developer to reuse This work was supported in part by Telkom SA, Nokia Siemens, the National Research Foundation and the Department of Trade and Industry common functionality, decreasing the initial capital and time required to develop the service. It also decreases the cost of ongoing maintenance as there is only one common platform to maintain. Standard functionality provided by the IMS platform includes user Authentication, Authorisation and Accounting as well as the necessary mechanisms to allow for specific Quality of Service (QoS) guarantees [3]. There is also work being done by the Open Mobile Alliance (OMA) to provide more advanced service capabilities, such as Presence and Location building blocks [4], [5]. While there has been work done on integrating legacy services such as the Customised Applications for Mobile networks Enhanced Logic (CAMEL) with the IMS, the most common model is to provide services through SIP Application Servers (AS) [6], and it is this architecture that will be used for the rest of this paper. This architecture does not allow the end user to determine the order in which their services get triggered. It is controlled by the network operator through the priority field in Initial Filter Criteria (ifc), which will be explained in Section II. The end user can not decide which services take priority and which services are active based on contextual information such as time of day or the end user s location or presence information. A new architecture is presented in Section IV which allows these features to be added to the IMS framework. This is done through the addition of four new entities. Two of these are related to the end user s activities, namely the User Service Policy Server (USPS) and the Context Server (CS), while the other two entities deal with the actual services and routing intelligence. These are the Service Capability Interaction Manager (SCIM) and the Service Repository Server (SRS). These elements will be discussed in depth further on. The paper is concluded by Section IV in which further areas of research are identified. II. REQUIREMENTS AND EXISTING WORK While the current release standard of the IMS architecture does not allow for end user customisation of service triggering, it has been identified by the 3GPP as a general requirement for future research. They state that the architecture should allow users to personalise and control their services the architecture should allow end users to personalise and control how applications work together, but find that this area is beyond the scope of the current release [7]. Several other

Figure 1. Evaluation of ifc in the IMS requirements have also been identified [8], namely that any changes to the service triggering architecture must be flexible and have a low impact on the existing architecture. With the capacity to handle over 207.9 million IMS subscribers already deployed by the end of the first half of 2010 [9], any further improvements on the architecture must be seen as incremental and backwards compatible. Any additional functional entities must be capable of communicating with the existing architecture [10]. Flexibility is important as multimedia services are not standardised by the 3GPP in the IMS framework. Network operators are free to develop and deploy services as they wish, as long as they conform to the standard set of interfaces provided in the framework. Thus there is a need to allow a great deal of freedom in the routing of service requests to handle the wide range of potential services. While the authors are currently not aware of any published work relating to end user customisation of the service triggering architecture in the IMS, several papers have been published relating to the extension of this architecture for either performance improvements, more flexibility in the routing of initial service requests or issues relating to service conflict detection and resolution. These areas have influenced the proposed architecture as can be seen later on, and such will be discussed briefly. HSS, and are downloaded to the S-CSCF when the end user registers with the network. These ifc contain a list of fields that are compared with the initial SIP request to determine if the ifc as a whole matches the SIP request. If the ifc matches the request, it is forwarded on to the AS that is specified as part of the ifc. The ifc has a priority field which is used to determine which ifc is triggered if more than one ifc match the request. Once the first AS has handled the request it may carry on to the next matching AS depending on how the request was handled by the first AS [10]. This can be seen in Figure 2. The three main problems with this architecture as it relates to this work are: 1) The routing decision is based solely on the contents of the SIP message. There are no mechanisms in place to make this decision based on information provided by third parties, such as the end user s current status or presence. This limits the flexibility of the architecture. There is no way to control the next service in line to be triggered depending on the result of the first service. In other words, there is no state or history used in the routing decisions. 2) The priorities of the ifc are set by the operator of the network. The end user does not have control over this, and cannot customise their services. It is not possible to have a different set of services active at particular times of the day or location specific services in the general framework. 3) There is no mechanism used for conflict detection and resolution. Due to the current way the ifc work, with no intelligence about the actual content of a service beyond the priority ordered list of filters, it is possible to activate two or more services in a chain that conflict with each other. This will lead to unpredictable results which may result in a low Quality of Experience (QoE) for the end user. This can also lead to the end user being charged incorrectly should the conflicting services both issue charges. A. 3GPP Standardised Architecture This architecture utilises the following entities when providing a service to the end user: 1) Proxy Call Session Control Function (P-CSCF) 2) Serving Call Session Control Function (S-CSCF) 3) Application Server (AS) 4) Home Subscriber Server (HSS) The P-CSCF is the first point of contact for the end user. It receives the initial SIP request, and forwards it on to the S- CSCF. The S-CSCF examines the message and forwards it to the appropriate AS depending on the ifc that are valid for the specific request and specific user. The AS is the entity that actually performs the desired service, and the HSS is the entity that stores the end user s information. The ifc are stored in the Figure 2. Service chaining in the IMS

B. Related work on Flexibility To increase the flexibility of the architecture, Fangyi et al. propose modifying SIP to include an additional header [11]. They call this the Service-State header and use it to provide and keep state in the actual SIP messages being routed. It includes a list of values that can be set by a service as well as the unique identifier for that particular service. This header, together with the necessary changes to the ifc allows for intelligent message routing based on the results of the first service s execution. This is one method for allowing service history to be kept, but requires modifications to the SIP protocol as well as each individual AS and the S-CSCF. It cannot work with currently implemented AS. The proposed solution in this paper moves the state tracking mechanism to a new functional entity, allowing it to be implemented with currently deployed AS without modifying either SIP, the current ifc or the currently existing AS. Another solution that aims to improve the flexibility of the current architecture by modifying the ifc is proposed by Krishnamoorthy et al. [12]. Here they propose adding various actions to the ifc specification that allows the S- CSCF to perform function such as adding or removing SIP headers, changing the body of the message, removing Session Description Protocol parameters etc. They also allow these modified ifc to contain a list of AS to route the message to sequentially instead of having needing one unique ifc per each AS as is necessary in the standard architecture. Further work done by Goveas et al. [13] follows the work done by Gouya et al. [14] in utilising a static model of all possible service combinations. However, here they use acyclic graphs together with external information about the end user to determine which service is appropriate. This is the first work showing service routing decisions being made based on contextual information from the end user. The end user however does not have any control over how this information is used. C. Related Work on Service Conflict Detection There are two main types of conflict detection. The first type is know as offline, where all possible service combinations are examined prior to the actual service triggering. Any combinations that would result in a conflict are disabled ahead of time. Gouya et al. propose such a system that utilises a full model of all possible services in the IMS network [14]. This would require the network operator to know the details of each service in advance and configure the network each time a new service is added. It does have the advantage of disabling conflicting services without any real time penalty, but it comes with a high cost of management overhead and does not scale well. The inefficiency stems from the need to reconfigure the system each time a new service is added, with the time taken increasing exponentially due to the fact that each service can interact negatively with the other services. Thus for the addition of a new service, every service combination needs to be re-examined. A better solution to the service detection problem is suggested by Nakajima et al. [15]. Classification is used to determine services which are likely to interact with each other in a negative fashion. They group services by similar features into different categories, and only allow one service from a particular category to be active in any service flow. This still leads to management overhead in classifying the services, but it is less taxing then building a model of all service interactions, and it scales much better as each service can be examined on its own without determining its relationship with other services. The second type of conflict detection is known as online conflict detection. This is where the conflict detection occurs in real time, in-line with the service requests from the end user. It has the advantage of being more flexible and adaptable than offline mechanisms, but often incurs a performance penalty as extra work is done during the session setup. A notable online conflict detection mechanism has been proposed by Kolberg et al. [16]. Their proposal involves creating a buffer before each service, that catches any inbound or outbound communication before the actual service logic. Their approach is similar to the work discussed earlier by Fangyi et al. where SIP is modified with the addition of another header. However here the history tracking is used to detect conflicts, rather than being used to determine the next destination for the SIP routing. This buffer between the services is used to examine the SIP messages to see if a service conflicting service has already been activated. If it has and the current service has a higher priority, the session establishment is repeated, but with the additional header instructing the buffer to disable the original service. This is inefficient as the length of the signalling path is kept the same no matter how many services are disabled. Chiang et al. solve this problem for an IMS implementation by moving the buffer to functional entities performing the same function as a Service Capability Interaction Manager (SCIM) [17], [18]. This results in reduced signalling overhead from the end users terminal, but does not eliminate the redundant messaging inside the IMS core network. III. PROPOSED ARCHITECTURE We propose adding several new functional elements to the architecture to enable the customisation of the end user s service flow, or in other words allowing them to customise their particular service chains. The first two, namely the Context Server (CS) and the User Service Policy Server (USPS) are responsible for handling information generated by the end user s actions. The CS is used to aggregate all contextual information about the end user. This can include presence information, location information or any information stored in their user profile which is pulled from the HSS. The CS gathers this information using the standard IMS mechanism such as subscribing to the end users presence information. It then passes this information to the Service Capability Interaction Manager (SCIM) after a specific time interval has elapsed. The USPS is used to store the customisations that are made by the end user. The end user interacts with it through an HTTP interface, communicating the desired order of services. Once the end user has chosen his or her particular chain of services, it is examined for any potential conflicts. If no service

are transferred to the SCIM, which examines incoming session requests for valid service chains. This architecture can be seen in Figure 3. Please note that some interfaces have been left out for clarity. Figure 3. New functional Elements for customised service triggering in the IMS conflicts are detected, the service chain is stored under that particular user s profile. Although the service conflict detection happens in real time depending on the choices the end user has made, it can still be considered an offline mechanism as it takes place before the actual service request gets executed. The other two elements form part of the supporting infrastructure that are not directly involved with the end user. Before the end user can customise their services, they need to have information about which services are currently available in the network. This is where the Service Repository Server (SRS) comes in. It gathers information about the currently available services by receiving custom SIP Publish methods, using the current standardised methods for presence in the IMS network [5]. The information is stored in a custom extension to the Presence Information Data Format (PIDF) [19]. An example of the SIP signalling is shown in Figure 4. Part of this information is also used for detecting service conflicts. The SRS uses a similar classification as found in [15] to determines which category each service belongs in. This information is then communicated to the USPS to allow it to detect service conflicts. In order for the execution of these customised service chains to actually take place, a new routing mechanism is needed. This is provided by a Service Capability Interaction Manager (SCIM). The stored service chains from the USPS A. Operation of the User Service Policy Server (USPS) The USPS relies on the concept of service blocks to represent service chains. Each service block consists of either a condition or a service. The condition blocks consist of a type and value. For example, a condition block could be of type Presence and the value could be Idle. Another example would be of type Time and the value could be 08:00-09:00. The service blocks consists of a particular service, together with the appropriate responses available. For each particular response chosen the service block contains the next service to be executed, but by default each response s next service to be executed is left blank. Once the end user has finished customising their service chain, a unique id is assigned to each block, allowing the service chain to be stored as a list of service blocks with condition specific pointers to the next block required. The SCIM works with this list of blocks when redirecting service requests, allowing it to dynamically send messages to the appropriate service depending on the result of the current service being executed. To understand how the USPS allows the end user to build their customised service chain, we will look at an example use case. Suppose that Alice only wants to be contacted by Bob during office hours if her presence status is not set to busy. She also wants to log information about all callers, and she wants to be notified by email if Bob tries to call her if her status is set to busy. Alice would visit the USPS using any normal browser, log in using her user account and proceed to Figure 4. The Server Presence Signalling Flow

customise her services. The choice to start a new service chain would be selected. The first choice she would make would be to select a Service type block. She is then presented with list of available services, together with the available responses for that service. She would select the log caller information service from a drop-down box as her first choice, leaving the response options to the default (all available responses). She would then select a condition type block, and select the type of the condition block to be of the Time type. She would then be presented with options allowing her to indicate the particular time she wants the new service chain to be active, and she would choose 08:00-17:00. Once this is done she is returned to the service chain page showing her the call logging service followed by the time condition service block. In the first row she would select another condition block, of type Contact and enter in Bob s SIP URI. She would then select another condition service block of the Presence type. She would enter in the appropriate presence status. This would be followed by a service block for the email notification service. This would be followed by the terminate service chain option. Normal routing conditions would take place after any condition is not met in this service chain. When the SCIM is following this particular service chain for Alice, the following events occur. 1) All calls are logged. 2) If the time is currently not between 08:00 and 17:00 the service request is routed according to the default SIP routing rules. 3) If the time is currently between 08:00 and 17:00, and the caller is Bob, and her status is not set to Busy, the service request is routed according to the default SIP routing rules 4) If the time is currently between 08:00 and 17:00, and the caller is Bob, and her status is set to Busy, she will get an email notification and the request will be terminated. Thus the USPS allows the end user to create and execute custom scenarios that are not currently possible in the standard architecture. IV. CONCLUSIONS This paper has detailed four new functional elements for triggering services in the IMS framework, with the main focus on how end users could customise their services. The proposed architecture allows previously impossible scenarios with a minimal impact on existing functional nodes. An offline conflict detection mechanism is introduced, together with the necessary supporting infrastructure to provide the information that this mechanism uses. The classification system is rather broad at the moment, needs to be enhanced with more categories. Future work in this area involves the investigation of the performance implications of the additional functionality. A way to better represent the responses of each individual service needs to be created, as the current mechanism relies too heavily on SIP response codes which the end user would not know. REFERENCES [1] ITU-T Recommendation Y.2001, General overview of NGN, Dec. 2004. [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, SIP: Session Initiation Protocol. RFC 3261 (Proposed Standard), June 2002. Updated by RFCs 3265, 3853, 4320, 4916, 5393. [3] 3GPP TS 23.002, Network architecture; release 10, Mar. 2011. [4] Open Mobile Alliance, OMA Mobile Location Service V1.2. Candidate Enabler Release, Oct. 2010. [5] Open Mobile Alliance, Presence Simple Version 2.0. Candidate Enabler Release, Dec. 2010. [6] 3GPP TS 22.228 V11.2.0, Service requirements for the Internet Protocol (IP) Multimedia core network subsystem, Mar. 2011. [7] 3GPP, 23.810 v8.0.0, On Architecture Impacts of Service Brokering, (Release 8)(SA2), Sept. 2008. [8] R. Spiers, R. Good, and N. Ventura, Service Orchestration in the IP Multimedia Subsystem, in Service Delivery Platforms: Developing and Deploying Converged Multimedia Services, pp. 175 193, Taylor & Francis Ltd. First Edition, March 2011. [9] Global IMS Market 2010, ZTE Technologies, Jan. 2011. [10] 3GPP TS 23.218 V10.0.0, IP Multimedia (IM) session handling; IM call model; Stage 2, Mar. 2011. [11] W. Fangyi, L. Xia, and Z. Hua, SSTM: a state based IMS service triggering mechanism, in Communications and Mobile Computing (CMC), 2010 International Conference on, vol. 1, pp. 508 512, 2010. [12] S. Krishnamoorthy and J. Torres, IMS enhanced filter and action criteria, in IP Multimedia Subsystem Architecture and Applications, 2007 International Conference on, pp. 1 3, 2007. [13] R. Goveas, R. Sunku, and D. Das, Centralized Service Capability Interaction Manager (SCIM) architecture to support dynamic-blended services in IMS network, in Proc. 2nd International Conference on Internet Multimedia Services Architecture and Applications IMSAA 2008, p. 1 5, Dec. 2008. [14] A. Gouya, N. Crespi, and E. Bertin, SCIM (Service Capability Interaction Manager) Implementation Issues in IMS Service Architecture, in Proc. IEEE International Conference on Communications, vol. 4, p. 1748 1753, June 2006. [15] M. Nakajima, M. Kaneko, M. Hirano, and H. Sunaga, SIP servlet dialogue handling for NGN Service Capability Interaction Manager, in Proc. APSITT Information and Telecommunication Technologies 7th Asia-Pacific Symposium on, p. 41 46, Apr. 2008. [16] M. Kolberg and E. H. Magill, Managing feature interactions between distributed sip call control services, Computer Networks, vol. 51, no. 2, pp. 536 557, 2007. [17] W. Chiang and C. Tseng, Handling feature interactions for multiparty services in 3GPP IP multimedia subsystem, in Proc. International Conference on IP Multimedia Subsystem Architecture and Applications, p. 1 5, Dec 2007. [18] W. Chiang and K. Chang, Design and implementation of a distributed service invocation function for the IP multimedia subsystem, Computer Communications, vol. 34 Issue 9, June, 2011. [19] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, and J. Peterson, Presence Information Data Format (PIDF). RFC 3863 (Proposed Standard), Aug. 2004. Richard Spiers is studying for his PhD at the University of Cape Town, having graduated with a B.Sc. in Electrical and Computer Engineering. His previous work in this area involves research on IMS-based IPTV systems, video conferencing systems using the IMS platform as well as dynamic service orchestration.