Managing Service Capability and Service Feature Interactions in the IMS of UMTS

Transcription

1 Managing Service Capability and Service Feature Interactions in the IMS of UMTS Anahita Gouya 1, Noël Crespi 1, Emmanuel Bertin 2, Lina Oueslati 1 1:{anahita.gouya,noel.crespi, lina.oueslati}@int-evry.fr, Institut National des Télécommunications (GET-INT), Evry, France 2: emmanuel.bertin@rd.francetelecom.com, France Telecom R&D, Caen, France Abstract The evolutions of UMTS toward the future wireless all-ip network mainly by the introduction of the IP Multimedia Subsystem (IMS) at the service level enable the realization of one of the foremost requisites in the Next Generation Networks (NGN): the Service Convergence. Furthermore the Service Capability based architecture of IMS characterises this subsystem as a mean for enabling the NGN services. Alongside with these remarkable gains attained by IMS, this overlay network goes through strict inadequacies in the management of the service interactions. In this paper we present insights into the so far research works in the service interaction management domain and we propose a framework for dealing with this problem in IMS. The particularity of our proposition consists of including both the traditional telephony services and the 3GPP (3 rd Generation Partnership Project) standardized services. Moreover our proposition enables a dynamic and online service interaction management mechanism and eliminates the undesired consequences of service interactions. Key Words: Service Capability and Feature Interaction Management, SIP, IMS. 1 Introduction Along with the wide deployment of 3G services in UMTS, the traditional telephony services persist extensively to satisfy the PSTN (Public Switched Telephone Networks) users. The introduction of IMS in Release 5 of 3GPP and its improvements in Releases 6 and 7, realize the coexistence of these heterogeneous networks and consent to the emergence of the service convergence concept. Hence IMS presents a generic architecture for offering multimedia services and enables the convergence of the separated application specific networks to a single service platform. In other words IMS can be regarded as a functional architecture for NGN and as a mean for enabling NGN services while: 1) it respects the layered architecture of NGN, 2) it realizes the service convergence paradigm and 3) it can be deployed based on the service capability based service architecture of NGN. In the functional architecture of IMS as illustrated in figure 1, the session control layer and the service execution layer are entirely separated and therefore the autonomy and the independent deployment of each layer is ensured. The session control layer performs multimedia session establishment, control and termination by using SIP (Session Initiation Protocol) [7]. CAMEL Server CAP IM SSF HSS C X AS SIP AS SCIM I-CSCF AS S-CSCF ISC AS OSA SCS P-CSCF Figure 1: Functional Architecture of IMS OSA AS OSA API Service Execution Layer Session Control Layer SIP proxies called Call Session Control Function (CSCF) are incorporated in this layer with the following functionalities: a) P-CSCF (Proxy-CSCF) is the first contact point to IMS and performs the network bearer resource authorization procedure, b) I-CSCF (Interrogating-CSCF) is the contact point to the IMS home network and is responsible for routing the sessions to the appropriate S-CSCF (Serving-CSCF), and c) S-CSCF performs session control and service triggering [1]. Moreover UMTS Core Network contains a database called Home Subscriber Server (HSS) that stores the subscription information of the users. During user registration procedure S-CSCF retrieves the IMS subscriber information from HSS and stores it for further session establishment procedures. The service layer entities in IMS are [2]: SIP Application Server (SIP AS) that host and execute SIP-based services. Open Service Access (OSA) [9] that allows the third-party service providers to use UMTS networks resource through an Application Programming Interface (API): OSA API. This interface interacts with the SIP-based entities (S- CSCF or SIP-AS) through an OSA gateway called OSA Service Capability Server (OSA SCS) and enables the convergence over different networks (GSM/GPRS/UMTS) and over different protocols. Customized Applications for Mobile Network Enhanced Logic (CAMEL) [5] services that are accessible via IM-SSF (IP Multimedia Service Switching Function) for enabling the reuse of legacy Intelligent Network (IN) services. Service interaction with IMS is performed through a SIP-based interface called IP Multimedia Service Control (ISC) that ties up the S-CSCF in the session control layer and the service entities of the service execution layer. For S-CSCF all of the service

2 entities in the service execution layer i.e. SIP AS, OSA SCS and IM-SSF behave as SIP AS on ISC and in the interaction of these ASs with IMS no distinction is considered regarding the logic behind these AS. Furthermore each of these service entities can be regarded as a modular self contained service building blocks called Service Capability that are independent service entities competent to be composed for implementing different Integrated Services. Examples of Service Capabilities are Presence [3], Multimedia Messaging [4] or Conferencing [6]. Moreover 3GPP had introduced a SIP AS called Service Capability Interaction Manager (SCIM) for orchestrating the interactions between service capabilities. But today the specifications and standards have not yet defined the functionalities of SCIM and so far the means for coordinating multiple service interactions by SCIM are not clear. Developing the functionalities of SCIM is considered for us as a proceeding step towards the service convergence aims of NGN and motivates us to deal with the IMS shortcomings at the service interaction management phase. The remainder of this paper is organized as follows: In section 2 we develop the service interaction management issues including a review of the so far research works, the benefits that they bring to the service architecture and their limitations and shortcomings. In section 3 we propose our framework for SCIM for enabling service orchestration and interaction management. Finally we conclude this paper by presenting the advantages of our framework and discussing about the reaming development issues of SCIM. 2 Service Interaction Management Satisfying the service providers, operators and subscribers in the heterogeneous networks is faced to the service interaction management problem. Service interaction occurs when each service behaves correctly separately and independent of other services, but not when running together. In this section we focus on two service interaction management issues: the feature interaction management and the service capability interaction management: 2.1 Feature Interaction Management In the traditional telecommunication services the term of Service Feature is defined as a service unit provided by network to the users. Call Waiting and Call Forwarding are two examples of the telecommunication service features. The feature interaction management has been widely studied in the traditional telephony services and different management mechanisms have been proposed. Managing the feature interactions consists of: understanding, avoiding, detecting and resolving the feature interactions [10] Understanding the Feature Interactions A comprehensive overview of feature interactions as well as their causes is presented in [11, 12]. These causes include particularly the violation of feature assumption as well as the network support limitations [10] Feature Interaction Avoidance One way to manage the feature interactions is to prevent their occurrence. [13] proposes a SIP-based interaction avoidance approach in which the SIP end users negotiate their available services by using the proposed SIP SUGGEST request before that the session is established. This approach provokes a number of reproaches: First of all in this approach the service interaction management is not transparent to the end users and they are forced to be engaged in the service interaction management procedure. Secondly the end users must trust each other for exchanging their service profile. Finally the end users must contain a uniform understanding of various services in order to perform the service profile negotiation accurately. This approach can be improved by delegating the service profile exchange and the service negotiation procedure to the network entities related to the end parties rather than the end parties themselves. Consequently the service interaction management procedure remains transparent for the end users and applying some filtering mechanisms over the service profiles resolves the confidentiality problem. Nevertheless postponing the service invocations for preventing the occurrence of service interactions increases excessively the session establishment time. Furthermore all the service interactions are not predictable and they may occur once the services are invoked Feature Interaction Detection and Resolution Another way to manage the feature interactions consists of detecting the interactions between the features and providing a mechanism to resolve the detected interactions. In the related research works, the feature interaction detection and resolution mechanisms are classified as: Offline and Online. In Offline mechanism, the feature interactions are detected and resolved before service deployment. [14] proposes an offline feature interaction detection and resolution mechanism based on a formal service specification method for defining the feature interactions states. This proposition is extensible by integrating any new kinds of undesirable feature interactions to the formal service specification method. [15] proposes another offline feature interaction detection and resolution mechanism by using an event driven transition system that contains the service properties (applied for detecting the feature interactions) as well as the feature interaction resolution rules. However not all of the feature interactions can be resolved by the Offline methods. Moreover due to the vast introduction of the innovative services in the 3G networks as well as the introduction of new

3 types of feature interactions, applying the offline mechanisms that are based on the foresees feature definitions, predefined feature interaction detection databases and static feature interaction resolution rules will not be efficient; whereas the predefined feature interaction detection databases must be regularly updated and the feature interaction resolution rules must be frequently adapted to the new features. Contrary to the Offline mechanisms, in the Online mechanisms the detection and resolution of the feature interactions are performed at the service run time. [16, 17] propose an online service interaction detection mechanism by integrating a Service Interaction Manager Agent between the end user and SIP proxies. This agent traces the current session processing context and detects the occurrence of the incompatibilities between the already running and newly loaded services. Yet two issues remain to be tackled in this proposition: firstly the service interaction manager agent is introduced as a central (and not distributed) network manager and secondly this research work lacks of suggestion for dealing with the service interaction resolution mechanisms. Outlining the shortcomings of the proposed service interaction management mechanisms leads us to clarify the need for providing an online service interaction management for IMS. 2.2 Service Capability Interaction Management Service Capability is defined in various standardization organisations including 3GPP, OMA and FG NGN of ITU-T as modular and self contained service building blocks within the service operator s network and reusable by different service providers for implementing different services. The service capabilities are thus relatively stable and their implementation should obey the standard specifications. However providing the service providers the possibility of reusing the service capabilities of IMS for offering different services to their users reclaims once more the introduction of a service capability interaction manager. For example a service provider may offer a Voic AS by integrating the Presence and Messaging service capabilities. Another service provider may share this Presence service capability and use a Conferencing service capability in order to offer a Chatting or an Online Discussion Forum AS. Offline mechanisms can be applied to manage the interactions between these service capabilities. These interactions may even be managed during the standardisation process. Nevertheless we focus here on the interactions between the services that were not standardized as service capabilities or for a service that is composed of many service capabilities. Following to our research works in [8, 18] where we have studied various architectural and functional aspects of SCIM, in the next section we propose a detailed 3 A framework for SCIM In our proposed framework, SCIM intervenes in the following service and session handling functionalities: a) service capability compositions, b) IMS subscriber information registration, c) user registration and d) session establishment. 3.1 Service Capability (SC) Composition: Following schema gives an outline of the Service Capability Profile (SCP) created gradually in SCIM. Initially this schema is created at the service creation phase in order to represent the association of the service capabilities composed in an AS. Other instances will be included at user registration and session establishment stages. Id Public User Identity 1 Application Server Name Service Capability Service Capability Profile Priority ifc Triggering point Method Using SCP offers several advantages for service interaction management: 1) Enables different service providers with a common and flexible service presentation template, 2) Realizes a service profile exchange mechanism between the caller and callee in order to compare these profiles and to see if there are incompatibilities between service profiles that provoke service interactions, 3) Masks the confidential information of the subscriber (directly retrieved from HSS) and exchanges only necessary (and not confidential) information. 3.2 IMS Subscriber Information Registration: Network operator registers the IMS subscriber information in HSS. This information contains a unique IMS subscriber identity and one or more Private User Identity that each are associated to one or more service profiles. Each service profile is related to one or more Public User Identity (PUI) for which one (or more) prioritized initial Filter Criteria (ifc) are defined. Each ifc is composed of zero or one Trigger Point that describes the trigger points to be checked in order to find out if the indicated AS should be invoked or not. Trigger Point contains a set of Service Point Triggers (SPT) that are defined as boolean expressions related with AND, OR and NOT. Figure 2 presents the IMS subscription information of user1. The STPs in group 1 and 2 indicate consequently that any request from tel: , and any

4 request from any one other than tel: will cause the invocation of AS1. <IMSSubscription xmlns : xsi= " www. w3.org/2001/ XMLSchema-instance" xsi:nonamespaceschemalocation= "~/ifc/cxdatatype.xsd"> <PrivateID>user1privateid@homedomain.com</PrivateID> <ServiceProfile> <PublicIdentity> <Identity> sip:user1@homedomain.com </Identity> </PublicIdentity> <PublicIdentity> <Identity> tel: </Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>1</ConditionTypeCNF> <Group>0</Group> <Method>REGISTER</Method> <Group>1</Group> <Method></Method> <Group>1</Group> <Header>FROM</Header> <Content> tel: </Content> <Group>2</Group> <Method></Method> <ConditionNegated>1</ConditionNegated> <Group>2</Group> <Header>From</Header> <Content> tel: </Content> </TriggerPoint> <ApplicationServer> <ServerName>sip:AS1@SP1.com</ServerName> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> Figure 2: An Example of IMS Subscriber Information 3.3 User Registration Suppose that user1 intends to register to IMS. According to the 3GPP registration procedure, P- CSCF of the network wherein user1 is located discovers the entry point to the home network i.e. I- CSCF and forwards the REGISTER request. Then the I-CSCF associates a S-CSCF to user1 and sends the request to the associated S-CSCF. On the reception of the REGISTER request, S- CSCF retrieves the subscription information of user1 from HSS and if one or more triggering points defined in ifc are met, it forwards the request to the relevant ASs (AS1 in ifc of figure 1).As in our proposed framework SCIM plays an intermediary role between S-CSCF and ASs, therefore S-CSCF forwards the REGISTER request as well as the subscription information of user1 to SCIM for updating the user s SCP. The update procedure includes: associating the triggering points of the ifcs (group by group) to the relevant AS and adding the public user identities of the user in SCP. Therefore in case of successful registration i.e. on reception of OK answer to REGISTER from the ASs; SCIM creates the following SCP that will be exchanged with the other end party. It should be noted that service composition information as confidential information remains in SCIM and will not be communicated between end parties. <ServiceCapabilityProfile> <PublicIdentity id= sip:user1@homedomain.com/> <PublicIdentity id= tel: /> <ifc priority = 0> <Triggering Point Methode= REGISTER/> <TriggeringPoint Methode= > <Header>FROM</Header> <Content> tel: </Content> <TriggeringPoint Methode= > <ConditionNegated>1</ConditionNegated> <Header>FROM</Header> <Content> tel: </Content> <ApplicationServer name = sip:as1@sp1.com/> </ifc> </ServiceCapabilityProfile> Figure 3: Service Capability Profile of user1 3.4 Session Establishment Figure 4 illustrates our proposed service invocation and session establishment mechanism by the intermediate of SCIM. In this figure we suppose that user A intends to establish a session with user B. On the reception of the request from A, the S-CSCF of A checks which Service Point Trigger (SPT) of the ifc matches with the request. Once the triggering points are met S-CSCF adds an indication (dialog-id) to the request which will allow the S-CSCF to identify the message on the incoming side and forwards the request via the ISC interface to the AS indicated in the current ifc. Step 1: The transmission of the request from S-CSCF to AS(s) will be performed by the intermediate of SCIM in order to enable SCIM for further service interaction management actions. SCIM dispatches the request to the related AS(s). Step 2: On the reception of the request the AS(s) relevant to A (referred as Originating Services) perform the service logic as a 3 rd party call control or as Proxy. In the former case AS sends back a new request (with new Call- ID) to S-CSCF in order to check the SPTs related to

5 this request. In our framework as SCIM is equipped with the SPTs, the triggering point matching will be delegated to SCIM where the newly created requests will be resend to the related ASs to verify if these ASs are compatible with the new requests. Example: Suppose that B is in Black List (BL) of A and therefore A is not allowed to call B. However A tries to call B by using Operator Services (OS): Once the request from A to OS is dispatched by SCIM to BL and OS, BL verifies the black list and accepts the request (since A calls OS and not B) although OS creates a new request from A to B. According to our proposition, on the reception of the new request, SCIM resends it to BL and BL rejects the request. S-CSCF A SCIM A AS A S-CSCF B AS B Step 1: Step 2: Step 3 + SCP of A + SCP of A SCIM B Step 4 Step 5 Response Step 6 Figure 4 : Proposed Service Interaction Management Framework In the later case (AS acts as proxy) the same incoming request will be send back to SCIM. In other words the service logic action will not be visible in the returned SIP message but however the AS includes its address in the via header in order to receive the successive responses to the request. Step 3: SCIM merges the answers of the dispatched requests, adds the SCP of A in the body part of the request, adds its address in the via header and forwards the to S-CSCF. S-CSCF of A takes the host part of the public user identity of B indicated in the request URI and resolves a SIP server in that domain from DNS in order to receive the I-CSCF(s) that are located in the home network of B. S-CSCF of A forwards the to one of the resolved I-CSCF. I-CSCF queries HSS to find the S-CSCF that serves B (Not shown in the figure). Whether B is registered and I- CSCF finds its related S-CSCF or B is not registered but it has subscribed to some services related to unregistered state. Two examples of these services are call redirection to CS domain and voice mailbox services [1]. (If B is not registered and does not have any services related to unregistered state, I-CSCF will send back a 480 Temporary Unavailable answer). Supposing that the request arrives to the S-CSCF of B, and once more after the triggering point verification; S-CSCF sends the request to related AS(s) via SCIM of B. Step 4: Before dispatching the request to the related AS(s) SCIM of B compares the service triggering points of the SCP of A and B. This verification will be mostly practical for session control layer specific services that once applicable will be incorporated in the triggering points. In the verification procedure we consider that the SPT of the ifc present a condition and the relevant AS invocation to this SPT is the related action. One possible approach for comparing the SCPs consists of detecting an identical condition in different triggering points that is defined for different actions. For example suppose that the SCP of A contains two following triggering point: <TriggeringPoint Methode= > <Header>TO</Header> <Content> B </Content> <ApplicationServer name= sip:as1@sp1.com/> And the SCP of B contains: <TriggeringPoint Methode= > <Header>FROM</Header> <Content> A </Content> <ApplicationServer name=sip:as2@sp1.com/> In this example same condition (inviting B from A) is defined for invoking AS1 and AS2. Detecting the interactions between AS1 and AS2 without being aware of their service logic requires realizing a mechanism to equip SCIM with a straightforward service description (without describing the service logic). Even though this mechanism reclaims concrete considerations about the service aspects and even if it still remains for us as an open subject we believe that this approach must be included as one of the primary aspects of the functionalities of SCIM for further service interaction management. Step 5: After verifying the service profile of A and B, SCIM of B dispatches the request to the related ASs and depending on the AS logic receives the messages back. Same as the verification of the compatibilities between the Originating Services, SCIM of B verifies the compatibilities between the Terminating Services. Example: Suppose that B is a BL service subscriber and all calls from B to A are forbidden.

6 B is also an Automatic Call Back (ACB) service subscriber and once A calls B and B is in call with C the ACB service records the ID of A and when the line of B becomes free, ACB calls A and ignores that calling to B is forbidden by BL. According to our proposition after the request from A to B arrives at SCIM, SCIM dispatches the request to BL and ACB: BL verifies the black list and accepts the request (since A is not in BL of B) while ACB records the ID of A for creating a new request from B to A once B is no more busy. On the reception of the new request from ACB ( A from B) SCIM sends the request to BL where it will be rejected by BL. Supposing that the Terminating Services are compatible and ASs include their address in the via header and SCIM merge and send back the request to S-CSCF of B. Step 6: Once the request is forwarded to the terminating end party and the answer is sent back to S-CSCF, the response must be forwarded respectively to AS(s) of B and A. Depending on the answer, AS B and AS A will consequently achieve their service logic and in case of success announced by AS(s) the session establishment procedure will be accomplished. In the following we present an example in which the AS of A refuses the service logic performed by AS of B and rejects the request: Example: Suppose that the AS of B is a Call Forward on Busy Subscriber Service to C and AS of A is a Call Barring Service to C. On the reception of 486 Busy here answer from B, S- CSCF of B forwards the answer to AS of B where a new request ( C From A) and a provisional response and a final response (181 call being Forwarded and 302 Call is forwarded) will be created. S-CSCF of B forwards the request to C and the 181 response to SCIM of A. C in its turn, will answer a 183 Session Progress answer (related to the request C from A) to S-CSCF of A that as well will be sent respectively to SCIM of A and the Call Barring service where the request will be rejected. 4 Discussion and Future Works The SCIM framework that we present in this paper brings the following advantages to IMS: 1) Feature and service capability interaction management procedures will be accomplished during the user registration and session establishment procedures and therefore they will be performed dynamic and online. 2) The framework respects the service capability based architecture of NGN for realizing the service convergence paradigm in IMS. 3) The development propositions to SCIM as an intermediate between the service and session control layer remove the feature and service capability interaction management tasks from the service and the session control layer and enable the independent extensions of each layer. In our following works we will improve the functionalities of SCIM in following phases:1) Handling the service invocation by other SIP initial requests such as Publish, Subscribe, Notify and Message. 2) Extending the functionalities of SCIM in order to deal with other causes of the occurrence of feature interactions particularly the interactions due to the terminal and network component limitations. 3) Improving the functionality of SCIM at the service capability composition phase. References [1] 3GPP, IP Multimedia Subsystem (IMS), TS [2] 3GPP, IP Multimedia session handling; IM call model, TS [3] 3GPP, Presence service using the IP Multimedia (IM) Core Network (CN) subsystem ; TS [4] 3GPP, Messaging using the IP Multimedia (IM) Core Network (CN) subsystem; TS [5] 3GPP, Customised Applications for Mobile network Enhanced Logic (CAMEL), TS [6] 3GPP, Conferencing using the IP Multimedia Core Network (CN) subsystem, TS [7] IETF RFC 3261, SIP: Session Initiation Protocol [8] Gouya A. and Crespi N. SCIM (Service Capability Interaction Manager) Implementation Framework in IMS, submitted to The Forth International conference on Mobile Systems, Applications and Services, submitted to MobiSys [9] es/poc.html [10] E.J.Cameron et al, A Feature-Interaction Benchmark for IN and Beyond, IEEE Communication Magazine, March [11] M. Calder et al, Feature Interaction: A Critical Review and Considered Forecast, Elsevier, May [12] D.O.keck et al, The Feature and Service Interaction Problem in Telecommunications Systems: A Survey, IEEE Transactions on Software Engineering, October [13] M. Kolberg and E.H.Magill, Handling Incompatibilities between Services deployed on IP-based Networks, IEEE Intelligent Networks 2001 [14] A. Khoumsi, Detection and Resolution of Interactions between Services of Telephone Networks, interne report, University of Montreal, 1997 [15] J.Pang, L. Blair, An Adaptive Run Time Manager for the Dynamic Integration and Interaction Resolution of Features, IEEE ICDCSW 2002 [16] Z. Chentouf et al, Implementing online Feature Interaction detection in SIP environment: early results, IEEE ICT 2003 [17] Z. Chentouf et al, Mapping SIP onto a Feature Interaction Management Language, ConTEL 2003 [18] Gouya A., Crespi N. and Bertin E. SCIM (Service Capability Interaction Manager) Implementation Issues in IMS Service Architecture, IEEE International Conference on Communications, ICC 2006.