634.2 IMS Service Creation

IP accessnetwork

SIP phone

Gm Mw Mw

HSS

Subscriberdata

SIP application servers Simulation servers

MMTel applicationserversSIP-AS #2SIP-AS #1

IMS service layer

IMS core network

IMS basic telephony

Cx ISC

ISC

ISC

P-CSCF S-CSCF

Media plane

FIGURE 4.2

SIP-AS in the IMS network. Key: AS, application server; Cx, reference point between CSCF and HSS; Gm, reference point between SIP user agent (terminal) and P-CSCF; HSS, home subscriber system; ISC, IMS service control interface; Mw, reference point between CSCF and CSCF; SIP-AS, SIP application server.

The SIP-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 profi le of the subscriber from the HSS. A core element of this data is called initial fi lter 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 SIP-AS that host these applications.

The interface between the S-CSCF and SIP-AS is called the IMS service control inter-face (ISC). The SIP signaling carried over ISC is enhanced compared to vanilla SIP, e.g. to ensure that SIP messages sent from S-CSCF to SIP-AS can be returned to the S-CSCF.

Subsequent to the invocation of a SIP-AS, the CSCF routes call-related SIP signaling through it for the particular session. The linking of the SIP-AS to the SIP session fl ow gives the SIP-AS full control over the SIP session (Figure 4.3). The Session Description Protocol (SDP), which describes the media for a SIP session, is included in the transparent SIP signaling through the SIP-AS.

By pushing a route on to the SIP 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 SIP application deployed on another server. A detailed description of this mechanism is provided in the following section of this chapter.

CH004.indd 63CH004.indd 63 6/30/2011 12:45:07 PM6/30/2011 12:45:07 PM

64 CHAPTER 4 Applications in the IP Multimedia Subsystem

ISC

CSCF

ISC

AS

ARinterface

Business Logic

SIPapplication 1

SIPapplication 2

SIP servlet container

Java EE AS

WS

Externalentity

FIGURE 4.3

Infl uencing AS chaining. Source: Ericsson Review, No. 3, 2007. Service composition in IMS using Java EE SIP 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 SIP-AS may thus infl u-ence how media is used and routed for a SIP communication session. Applications may be invoked for originating SIP sessions ( initiated by a served IMS subscriber) and for terminat-ing SIP sessions ( destined for a served IMS subscriber).

4.3 IMS SERVICE COMPOSITION This section gives an overview of the different possibilities available for composing SIP applications in IMS and their peculiarities.

4.3.1 Initial Filter Criteria Upon receipt of an INVITE, the S-CSCF forwards it to the appropriate AS based on the service profi le of the user and the information stored therein. This profi le 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 profi le is the initial fi lter criteria (IFC) list.

CH004.indd 64CH004.indd 64 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM

654.3 IMS Service Composition

IFCs trigger on service point triggers (SPTs) in order to send the SIP request to the correct AS. Filter criteria contain the following information:

● Address of the AS ● Sequence of the fi lter 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 SIP methods (e.g. INVITE) ● Registration type (initial/re-registration/de-registration) ● Existence of specifi c headers ● Content of specifi c 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 sub-scribed 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 work-around is needed in order to accommodate for multiple applications hosted on the same AS. Typically this issue creates the need for signifi cant 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 SIP signaling and then decide which application on the AS will handle it. This typically will be part of the imple-mentation of the application router on the JSR289 SIP 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 dif-ferent 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 confi gurations.

An in-depth description of the IFC mechanism is provided in the following chapters.

4.3.2 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 serv-ices, the IFC mechanism is time-consuming, complex, and expensive.

Due to the limitations of the IFC mechanism and the strong requirements for a compo-sition mechanism that may effi ciently support the creation of enhanced value-added IMS applications, an orchestrating entity, the Service Capability Interaction Manager (SCIM),

CH004.indd 65CH004.indd 65 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM

66 CHAPTER 4 Applications in the IP Multimedia Subsystem

HSS

Sh

SCIM

ISC

S-CSCF

Cx

Si

MAP

ISC

ISC

IM-SSF

CAP

Camel ServiceEnvironment

SIP ApplicationServer

AS AS

OSA servicecapability server

(SCS)

OSA API

OSAapplication

server

FIGURE 4.4

SCIM according to 3GPP. Source: 3GPP TS 23.002 v7.1.0, fi gure 6a. © 2010 3GPP 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 modifi cations and are therefore provided to you “as is” for information

purposes only. Further use is strictly prohibited.

was defi ned by the 3GPP envisioned to act between the S-CSCF and the various other appli-cation servers over ISC ( 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 confl icting services. Its original purpose was the co-ordination of service interaction. However, the introduction of the SCIM allows for increased fl exibility through its compositional capacity. The SCIM may be triggered mul-tiple 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 intro-duce a potential bottleneck, since it requires all signaling to traverse the SCIM, even for ses-sions 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

CH004.indd 66CH004.indd 66 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM

674.3 IMS Service Composition

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 mecha-nisms such as IFCs and service identifi ers, the S-CSCF may route traffi c directly to the AS when the service does not require composition.

4.3.3 Unifi ed Web Services and IMS Composition The design principles discussed in the previous section allow developers to reduce the com-plexity 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 implement-ing a business process, rather than SIP signaling fl ows, analogous to the SOA way of work-ing 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 defi ned by the 3GPP to enable the creation of enhanced value-added IMS appli-cations, an orchestrating entity for IMS over the ISC interface. This chapter will further discuss in great detail the SIP servlet API based on Java Enterprise Edition for the imple-mentation of SIP and IMS applications.

Moreover, given the proliferation of SOA-inspired systems both in the Enterprise and on the Internet, there exists a need to effi ciently and effectively closely integrate IMS applica-tions with web services of different types (SOAP, REST, etc.). Invariably, IMS applications need to be composed out of web services and SIP 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 “unifi ed com-position” (Bond et al., 2009). Refer to Figure 4.5. One example of unifi ed composition would

Business Logic

SIP CEA

SIPapp

SIP INVITE

org.servlet.sip.ar.SipApplicationRouterInterface SIP

app

SIP ServletContainer

WS WS

JEEContainer SOAP

invocation

JSR289 AR JSR224 JAX WS

WS CEA

FIGURE 4.5

Unifi ed web services and IMS composition.

CH004.indd 67CH004.indd 67 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM

68 CHAPTER 4 Applications in the IP Multimedia Subsystem

be a customized service that displays the social network personal profi le of a caller (Web 2.0 service) for an incoming call (SIP application).

A composition function that fulfi lls the requirements toward an SCIM may be imple-mented based on the foundation provided by the converged SIP servlet container as stand-ardized in JSR289. Two examples of such unifi ed composite applications created out of SIP and web services constituent components using the application router (AR) interface and the Java API provided by JSR289 are presented in detail in Chapter 5.

4.3.4 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 environ-ment 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 specifi c 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 serv-ice 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 suffi cient 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, serv-ice interaction becomes crucial. As with pure GSM, also in this context different services may provide different, possibly confl icting, 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 con-siderably 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 bene-fi t from VAS capability in IMS to build fl exible, 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 68CH004.indd 68 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM

694.4 IMS Application Servers

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 SIP-AS with respect to IMS application development starting from the triggering of an AS via the initial fi lter crite-ria, continuing with the industry standard converged SIP servlet container technology used on Java Enterprise Edition application server platforms to develop and execute SIP applica-tions and the chaining mechanisms used thereupon.

4.4.1 The Converged SIP 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-specifi c standard; and the SIP servlet API based on Java Enterprise Edition, the standard enterprise middleware platform across many industries.

This section will introduce developers to the concepts of SIP 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 SIP container, as well as across multiple AS within IMS. Examples of specifi c IMS applica-tions built using this technology are detailed in the following chapter.

SCP #2

Legacy IN services

SCP #1

CAP CAP

Serviceadaptation

ISC ISC ISC ISC

SIPSIP S-CSCF

SIP-AS #1 SIP-AS #2 SIP-AS #3

IMS services

FIGURE 4.6

Multiple service invocations, GSM services and IMS services combined.

CH004.indd 69CH004.indd 69 6/30/2011 12:45:08 PM6/30/2011 12:45:08 PM