4.2 IMS Service Creation

Transcription

1 4.2 IMS Service Creation 63 IMS service layer application servers IMS basic telephony Simulation servers Subscriber data HSS -AS #1 -AS #2 MMTel application servers Cx IP access network Gm P-CSCF Mw S-CSCF Mw phone Media plane FIGURE 4.2 IMS core network -AS in the IMS network. Key: AS, application server; Cx, reference point between CSCF and HSS; Gm, reference point between user agent (terminal) and P-CSCF; HSS, home subscriber system;, IMS service control interface; Mw, reference point between CSCF and CSCF; -AS, application server. The -AS is logically connected to the: Serving CSCF (S-CSCF) Interrogating CSCF (I-CSCF) Multimedia resource control function (MRF) Home Subscriber System (HSS). Whenever a terminal registers with the network, the S-CSCF fetches the service profile of the subscriber from the HSS. A core element of this data is called initial filter criteria (IFC). The S-CSCF uses information stored in the IFC to decide which IMS applications or constituent components thereof to invoke and how to reach the -AS that host these applications. The interface between the S-CSCF and -AS is called the IMS service control interface (). The signaling carried over is enhanced compared to vanilla, e.g. to ensure that messages sent from S-CSCF to -AS can be returned to the S-CSCF. Subsequent to the invocation of a -AS, the CSCF routes call-related signaling through it for the particular session. The linking of the -AS to the session flow gives the -AS full control over the session (Figure 4.3). The Session Description Protocol (SDP), which describes the media for a session, is included in the transparent signaling through the -AS. By pushing a route on to the route header (in much the same way as the CSCF routes to an IMS application server), the application router may also instruct the container to route the request to a application deployed on another server. A detailed description of this mechanism is provided in the following section of this chapter. CH004.indd 63 6/30/ :45:07 PM

2 64 CHAPTER 4 Applications in the IP Multimedia Subsystem WS External entity Java EE AS Business Logic AR application 1 interface application 2 servlet container AS CSCF FIGURE 4.3 Infl uencing AS chaining. Source: Ericsson Review, No. 3, Service composition in IMS using Java EE servlet containers. Consequently, IMS applications may be invoked by and subsequently control any type of session- and non-session-related communication service in the IMS network, such as but not limited to voice calls, video calls, messaging, and chat sessions. A -AS may thus influence how media is used and routed for a communication session. Applications may be invoked for originating sessions ( initiated by a served IMS subscriber) and for terminating sessions ( destined for a served IMS subscriber). 4.3 IMS SERVICE COMPOSITION This section gives an overview of the different possibilities available for composing applications in IMS and their peculiarities Initial Filter Criteria Upon receipt of an INVITE, the S-CSCF forwards it to the appropriate AS based on the service profile of the user and the information stored therein. This profile is retrieved in advance by the S-CSCF upon registration of the terminal from the HSS. For the purpose of selecting an AS, the main content of the service profile is the initial filter criteria (IFC) list. CH004.indd 64

3 4.3 IMS Service Composition 65 IFCs trigger on service point triggers (SPTs) in order to send the request to the correct AS. Filter criteria contain the following information: Address of the AS Sequence of the filter criteria Trigger points composed of service point triggers (SPTs) SPTs chained through Boolean operators Default handling Optional info to be added to the message body. The following SPTs are possible: Initial methods (e.g. INVITE) Registration type (initial/re-registration/de-registration) Existence of specific headers Content of specific headers or Request-URI ID of the user mobile originated (MO) or mobile terminated Session description information. The IFC may only address an individual AS; since an end-user will very likely be subscribed to multiple services deployed on different AS, multiple IFCs are needed, one per AS. Moreover, IFCs may not address individual services on the AS; consequently, a workaround is needed in order to accommodate for multiple applications hosted on the same AS. Typically this issue creates the need for significant additional logic inside the AS. This logic may be seen as a meta application that attempts to infer which service is appropriate based on the properties of the signaling. This application would receive all signaling and then decide which application on the AS will handle it. This typically will be part of the implementation of the application router on the JSR289 container. Unfortunately, this implies that the AR implementation needs to be extended with every new application deployed on the AS. A programmable implementation of the AR that may be programmed to execute different orchestrations solves this problem. Another way to deal with this issue is to deploy multiple AS that cater for different user groups with different service configurations. An in-depth description of the IFC mechanism is provided in the following chapters Two-Tier Composition and the Service Capability Interaction Manager IMS foresees rudimentary and manual service interaction coordination through the IFC mechanism. However, for cases with larger numbers of services or frequently changing services, the IFC mechanism is time-consuming, complex, and expensive. Due to the limitations of the IFC mechanism and the strong requirements for a composition mechanism that may efficiently support the creation of enhanced value-added IMS applications, an orchestrating entity, the Service Capability Interaction Manager (SCIM), CH004.indd 65

4 66 CHAPTER 4 Applications in the IP Multimedia Subsystem was defined by the 3GPP envisioned to act between the S-CSCF and the various other application servers over ( Figure 4.4 ). The SCIM is an entity in the application layer of IMS that was introduced by 3GPP as part of the REL-5 version of the 3G network. Capabilities interaction management refers to co-ordinated execution of potentially conflicting services. Its original purpose was the co-ordination of service interaction. However, the introduction of the SCIM allows for increased flexibility through its compositional capacity. The SCIM may be triggered multiple times in the course of a session, before or after any AS, in order to execute additional services, perform some manipulation, consult external databases, or perform any other task as part of the composition. Effectively the SCIM introduces an additional point of in direction that enables a second level of composition above that of the S-CSCF. It should be emphasized that the strict application of this design pattern may also introduce a potential bottleneck, since it requires all signaling to traverse the SCIM, even for sessions that have no value-added functionality. In order to avoid this bottleneck, IMS architecture application servers (AS) that offer high-performance basic services need to be directly accessible from the S-CSCF, bypassing the SCIM in case no composition is required. Such an AS should also be able to seamlessly integrate itself in a composition executed by the SCIM in order to make its basic services part of a larger value-added use-case. MMTel (Multimedia Telephony) supporting basic telephony and supplemental features in IMS is such a basic high-volume service that needs to be offered directly to millions of AS AS SCIM Application Server Sh HSS Cx Si S-CSCF OSA service capability server (SCS) OSA API OSA application server MAP IM-SSF CAP Camel Service Environment FIGURE 4.4 SCIM according to 3GPP. Source: 3GPP TS v7.1.0, fi gure 6a GPP TM TSs and TRs are the property of ARIB, ATIS, CCSA, ETSI, TTA and TTC who jointly own the copyright in them. They are subject to further modifications and are therefore provided to you as is for information purposes only. Further use is strictly prohibited. CH004.indd 66

5 4.3 IMS Service Composition 67 subscribers, while in other cases it will certainly be useful as part of a larger composition. An MMTel AS can be deployed as an AS in parallel to the SCIM so that, based on mechanisms such as IFCs and service identifiers, the S-CSCF may route traffic directly to the AS when the service does not require composition Unifi ed Web Services and IMS Composition The design principles discussed in the previous section allow developers to reduce the complexity of component design and to build reusable application building blocks. The ability to rapidly develop a rich portfolio of value-added IMS applications by focusing on implementing a business process, rather than signaling flows, analogous to the SOA way of working increasingly implemented by Enterprise systems hinges on the existence of a platform to facilitate rapid application composition out of constituent components. The aggregation of such composable constituent components into coherent applications is a task that may be achieved through a variety of means. A number of mechanisms have been standardized for telecom service composition. Previous sections have introduced the use of the Service Capability Interaction Manager (SCIM) as defined by the 3GPP to enable the creation of enhanced value-added IMS applications, an orchestrating entity for IMS over the interface. This chapter will further discuss in great detail the servlet API based on Java Enterprise Edition for the implementation of and IMS applications. Moreover, given the proliferation of SOA-inspired systems both in the Enterprise and on the Internet, there exists a need to efficiently and effectively closely integrate IMS applications with web services of different types (SOAP, REST, etc.). Invariably, IMS applications need to be composed out of web services and applications to form value-added services that synergistically combine telecom functionality with the wealth of data accessible via web service APIs. This composition of web services with telecom services is called unified composition (Bond et al., 2009). Refer to Figure 4.5. One example of unified composition would Business Logic CEA WS CEA JSR289 AR JSR224 JAX WS org.servlet.sip.ar. SipApplicationRouterInterface app app WS WS INVITE Servlet Container JEE Container SOAP invocation FIGURE 4.5 Unifi ed web services and IMS composition. CH004.indd 67

6 68 CHAPTER 4 Applications in the IP Multimedia Subsystem be a customized service that displays the social network personal profile of a caller (Web 2.0 service) for an incoming call ( application). A composition function that fulfills the requirements toward an SCIM may be implemented based on the foundation provided by the converged servlet container as standardized in JSR289. Two examples of such unified composite applications created out of and web services constituent components using the application router (AR) interface and the Java API provided by JSR289 are presented in detail in Chapter Next-Generation Intelligent Networks and Migration to IMS Value-added services in IMS and the evolution of legacy value-added services toward all- IP and IMS are generally termed the Next-Generation Intelligent Network (NG-IN). NG-IN embodies the service environment in next-generation networks. It is this service environment that makes it possible to control (a) calls in circuit-switched networks, such as GSM and PSTN/ISDN, and (b) calls and sessions in packet-switched networks, such as IMS. NG-IN helps operators to safeguard investments made in legacy value-added services. The Intelligent Network standard adheres to the principle of single point of control. This implies that not more than one IN service may, at a specific moment, control a call in the GSM network. Nevertheless, operators do wish to deploy multiple IN services in their network, with these multiple IN services working on a call. Vendors often apply proprietary multiple service invocation techniques for this method, usually a glue service that combines the original services or for the simplest cases different services triggered in sequence (service chaining). Simple rules for invocation priorities allow sufficient control with reasonable effort, when using such glue logic. Using proprietary methodology has, by its nature, the limitation that it can be used in one network only and often requires extensive system integration and testing. When migrating from GSM to IMS and deploying legacy IN in the IMS network, the above-described issue of multiple IN service invocation needs to be addressed as well. An operator may want to combine legacy IN service invocation with IMS VAS. An architecture for multiple service invocation is given in Figure 4.6. When multiple services need to be invoked for a single call or multimedia session, service interaction becomes crucial. As with pure GSM, also in this context different services may provide different, possibly conflicting, instructions to the IMS core network. Service composition is needed to coordinate the instructions in this case. Also, careful provisioning of subscriber data is needed, to ensure that services are invoked in the appropriate order. There are several reasons why the need for multiple service invocation becomes even more profound when migrating from GSM to IMS. One reason is the fact that MMTel simulation services and online charging are themselves invoked as VAS. But even more importantly, as in IMS, a service environment is foreseen where the total number of available services is considerably higher compared to IN. Also, the environment is expected to become more dynamic in the sense that available services change more frequently. Thus, operators want to benefit from VAS capability in IMS to build flexible, short-time-to-market services. So, multiple services may need to be invoked in IMS. When a legacy IN service is applied in the IMS CH004.indd 68

7 4.4 IMS Application Servers 69 Legacy IN services SCP #1 SCP #2 CAP CAP IMS services -AS #1 -AS #2 -AS #3 Service adaptation S-CSCF FIGURE 4.6 Multiple service invocations, GSM services and IMS services combined. network, this legacy IN service will have to be combined with IMS service(s). In addition, a (mutual) dependency between the legacy IN service and the services in IMS may exist. 4.4 IMS APPLICATION SERVERS This section will give an overview of technologies related to IMS -AS with respect to IMS application development starting from the triggering of an AS via the initial filter criteria, continuing with the industry standard converged servlet container technology used on Java Enterprise Edition application server platforms to develop and execute applications and the chaining mechanisms used thereupon The Converged Servlet Container From the multitude of mechanisms available for telecom service composition, a few have been standardized for the implementation of telecommunications applications over IP: at the architecture level, the 3GPP IMS standard; within application servers the JAIN SLEE, a Java implementation of the Service Logic Execution Environment, a telecommunications-specific standard; and the servlet API based on Java Enterprise Edition, the standard enterprise middleware platform across many industries. This section will introduce developers to the concepts of application composition based on the mechanisms of JSR289 and its predecessor JSR116. These mechanisms may be used to compose services into more complex composite applications, both within a single container, as well as across multiple AS within IMS. Examples of specific IMS applications built using this technology are detailed in the following chapter. CH004.indd 69