Course on the IMS Application Layer

Through my company Arismore, I am offering a 2-day course on the IMS application layer. It can be delivered either in French or in English (all the material is in English). There are sessions regularly organized in my company's premises in Saint-Cloud, Paris, France, which are open to individuals. The course can also be delivered on site, within or outside Europe.

What makes this course unique is that, while others usually provide a litteral description of IMS specifications and essentially concentrate on the IMS core network, largely overlooking the IMS service architecture, sometimes even delivering misleading information, this one totally concentrates on this domain in which resides the true potential of IMS for differentiation and revenue generation (both for operators and suppliers). You can take this course after a regular IMS one, but my experience shows that even IMS novices can follow it without missing any core network background.

The course does not only describe IMS application-related specifications that span multiple standardization organizations (3GPP, the IETF, OMA, ETSI TISPAN). It also helps understanding what lies behind them, by providing revealing insights on how they were produced (e.g. historical timeline, assumptions, mistakes, conflicts between companies, need to address specific issues), shows in details how they effectively work, explains how they can optimally be exploited to deliver innovative services or innovatively deliver existing ones, and finally addresses the main opportunities and challenges that IMS brings to the industry. After this course, the student can understand what IMS can deliver, why there exist so many conflicting perceptions of IMS, and why IMS is as much a challenge as a promise.

Several on site sessions have been given or are planned in the near future, and the response has been so positive that these sessions usually lead to discussions about further collaboration between the customer company and Arismore.

Contact me at cgourraud@yahoo.ca if you are interested in either an on site session or in a session organized in our offices in Paris (planned dates can be found in the side bar of the blog).

Here follows a description of the course. You can also request from me a slightly more detailed powerpoint content description.

Part 1: The IMS Service Architecture

This is the most comprehensive part of the course. It addresses several objectives: understanding how the IMS service architecture works (dynamic view), getting an overview of the specifications (static view), understanding the drivers behind standardization decisions (motivations, design by accident, pending issues), understanding how the architecture can be used (application layer architecture, service patterns).

Standardized topics include:
- Overview of the architecture
- IMPUs & PSIs
- ISC usage scenarios & examples
- Details of ISC
- Service profiles and initial filter criterias (iFCs)
- OSA SCS / IM SSF / SIP AS
- MRFC/MRFP
- SCIM & Service Broker
- IMS Communication Services
- User Data Management (Sh, OMA XDM, GUP)

The service features of SIP are treated as a specific topic. It highlights the potential of the protocol when used in IMS or in other networks:
- Multimedia sessions
- Event packages
- Routing alternatives (SIP forking, callee capabilities/caller preferences), GRUUs)
- Support of Group Services
- Combination with other protocols (content indirection, SIP REFER, SIP session, body in SIP message)
- Interoperability aspects (between SIP profiles, between SIP and other protocols)

Service oriented features specific to the IMS service architecture, and complementing the intrinsic SIP ones are also detailed. This part permits to understand the value IMS adds on other SIP-based networks:
- Service composition
- Logic mutualization
- Personalization / Differentiation of user experience
- Simple access to services
- Service flexibility / agility
- Authorization to services
- Unlimited service scalability
- Multi-vendorship / Differentiation for each service
- Service anthropomorphism
- Usage of a single identity for multiple services

Part 2: IMS standardized services and enablers

This part covers IMS services and enablers standardized or under standardization in 3GPP, OMA and ETSI TISPAN. As for Part 1, background information about the standardization process is given.

User data services & enablers:
- Presence (IETF, 3GPP, OMA specifications)
- Group Management / Group Services

Voice oriented services & enablers:
OMA Push To Talk Over Cellular (Poc) V1 and V2
3GPP Combining circuit-switched and IMS services (CSI)
3GPP Voice Call Continuity (VCC)
3GPP/TISPAN Multimedia Telephony (MMTel)
3GPP IMS Centralized Services (ICS)
3GPP Conferencing

Messaging services & enablers:
OMA SIP Push
Messaging (IETF IM, 3GPP IMS Messaging, OMA SIMPLE IM)
3GPP SMS over generic IP access
OMA Converged IP Messaging (CPM) - Messaging part

Multimedia services & enablers:
OMA Converged IP Messaging (CPM) - Multimedia part
TISPAN IPTV

This part ends with a description of the Rich Communication Suite (RCS) initiative

Part 3: Opportunities & Challenges

This final part addresses essential topics which go beyond IMS specifications.

It is structured around the following topics:
- Fixed Mobile Convergence (from technical to user oriented convergence: opportunities and challenges)
- Which role(s) for the operators (e.g. bitpipe provider, intelligent pipe/channel provider, service provider with more or less control)
- Exploiting IMS Capabilities (e.g. User Oriented Architecture, Distributed Service Architecture, need for optimizing the IMS service architecture)
- Service Platforms (e.g. black boxes vs. open platforms, JAIN SLEE, J2EE)
- IMS as a service integration framework (different types of IMS services, how to integrate non-IMS services into IMS, relationship to 3rd party service providers)

Christophe

IMS Service Routing: ISC for IMS Application Server

After a long summer break, here is a fourth post on the details of the IMS service architecture related to the handling of SIP signalling. While the previous post described ISC from the perspective of the IMS core network (S-CSCF), this one concentrates on the other side of the interface: the IMS Application Server.

The details of the procedures to be supported by an IMS application server for ISC can be found in chapter 5.7 of TS 24.229. This post does not intend to describe all the details of the IMS AS procedures (for instance I will not address such specific issues as the handling of GRUUs, local numbering or carrier selection - the reader is invited to read the specification for this). I will only provide my own description of the basics, sometimes summarizing the specification, sometimes going beyond them or placing them in a larger context.

In the following, I decided to distinguish between two cases.

In the first one, the IMS application server receives a SIP request that was originated by another SIP entity. This entity could be an IMS client (e.g. phone, TV set, home PC) or an IMS application server (e.g. a messaging server, a multimedia content server). It could be located in the same operator domain as the IMS application server, or in a different one (e.g. an IMS client or an IMS application server of operator X issues a SIP request received by an IMS application server of operator Y).

This entity could also be a client or application server located in a non-IMS network, like an enterprise network or the Internet. A SIP request originated from outside the IMS and routed to it can be discriminated from an IMS-issued request, and the IMS application server can adapt its behavior to this origination. For instance, a request originated from the Internet was not authenticated by the IMS, and has to be processed accordingly.

In the second case, the IMS application server issues a SIP request to another SIP entity. This SIP request may be the consequence of the initial reception of a SIP request (first case), but it is not directly related to it. For instance, upon the reception of a call set up request for user A, the IMS application server issues an instant message to user A (or B). It may also be generated out of the blue, or through an initial interaction based on, e.g. web services or the access of a user to a web page. The SIP request may be addressed to an IMS client or IMS application server located in the same or a different operator domain (e.g. a service from operator X accesses the presence of an IMS user located in operator Y's domain). Alternatively, it may be addressed to a client or a server located in a non-IMS network, like an enterprise network or the Internet.

Note that, through the usage of appropriate gateways, the IMS application server may use SIP to interact with entities which do not reside in the IMS and do not support the SIP protocol.

IMS Application Server Receiving SIP Requests from the Network

SIP Roles

When an IMS application server receives a SIP request from the core network - request which may have been initiated by an IMS client, a non-IMS client or an entity in a non-IMS network - it may support one of four different roles.

Acting as a SIP User Agent, the IMS application behaves as an endpoint for the SIP request. The request may have been addressed to a service or service feature supported by the IMS application Server (typically when the request-uri is a Public Service Identity or PSI), or it may have been addressed to an IMS user (the request-uri is an IMS Public User Identity, also known as IMPU). In this latter case, the service logic hosted by the IMS application server decides to terminate the request on behalf of the user it is addressed to. This is typically the case for presence requests terminated at a presence server (the presence request is addressed to the user whose presence is sought). Other examples include a call termination service or an IMS messaging store that decide that the destination user cannot accept the call or the message right now.

Acting as a SIP redirect, the IMS application server will redirect the initiating party to another destination. I do not expect an IMS application server to extensively support this (feature-poor) role.

The IMS application may also decide to act as an intermediary in the end-to-end SIP interaction that takes place between two SIP entities (e.g. client to client, client to other AS, other AS to other AS, other AS to client).

Acting as a SIP proxy server, the IMS application server has very little opportunity to impact the end-to-end interaction. This behavior is adequate in cases where the AS hosts service logic that has to apply only prior to enabling the end-to-end interaction (e.g. authorization, target selection): the AS performs its logic, then lets end-to-end SIP signalling go on without any interference. It can also be used when the AS hosts service logic that monitors end-to-end SIP signalling without any intention to interfere.

When the AS hosts service logic that requires greater control on the end-to-end SIP interaction, it has to support the so-called routeing back-to-back user agent (routeing B2BUA) behavior. As a B2BUA, the AS acts as an endpoint to both parties in the SIP interaction. Doing so, it may decide to explicitly appear as an endpoint to them (by inserting a PSI as recipient / originator of the SIP interaction) or to remain transparent to the endpoints. Here are examples of situations where service logic needs to rely on a Routeing B2BUA role: need to modify the body of a SIP request (e.g. change a codec in session description), potential need to transfer a session during its course (e.g. to another party, to an announcement), need to insert a media plane intermediary in a multimedia session (e.g. to mix/adapt/control content, to insert advertizement).

I expect the latter example of the insertion of a media plane intermediary in an end-to-end multimedia session to be a fundamental IMS service use case in the future.

Direction of Requests

This is possibly the most important feature of the IMS service architecture when you want to integrate a non-IMS SIP application server with an IMS network, more especially in the context of VoIP services: the ISC interface (more especially the initial filter criteria that govern the forwarding of SIP requests over ISC) distinguishes between requests that originate from a certain IMS identity (IMPU or PSI) and those that terminate to this IMS identity. Moreover, it permits to distinguish between the case where the IMS identity is currently registered with IMS or not (only from 3GPP R7 for requests originating from a non-registered identity, i.e. requests initiated on behalf of a non-registered user by an IMS application server).

This architectural feature (shared with IN) permits to execute different service logic depending on the direction of a request. For instance, taking classical call control services, it permits to execute an outgoing call screening service only for originating call requests, and call forwarding services only for terminating call requests. It also permits to forward an IMS instant message to a store and forward messaging AS only in the case where the recipient of the message is currently not registered with IMS, and therefore unreachable through IMS connectivity.

A clear distinction between originating and terminating parties (and their respective services) is mandatory in a multi-operator environment, in which the parties might be subscribed to different operators. However, most of VoIP application servers that exist on the market today were implemented for a closed, single service provider, environment like the enterprise. They therefore tend to execute both originating and terminating services at once. Such a behavior is incompatible with the IMS service architecture, and must be corrected when the AS is ported on IMS. On the other hand, the direction of SIP requests is not a issue when porting a presence server on IMS (the presence logic depends on the SIP requests more than their direction).

Note that, while the direction of a request (originating, originating unregistered, terminating, terminating unregistered) is an information used to determine how SIP requests should be forwarded to IMS application servers, it is not specified how to convey this information in the SIP request that is to be forwarded. A typical approach to make the AS aware of the direction is to define a distinct AS SIP URI for each direction in the initial filter criterias (IFCs), or to add a specific parameter in the AS address. In both case, the information about the direction is made explicit when provisioning AS addresses for iFCs in the HSS.

Authentication

Authentication aspects are clearly described in section 5.7.1.4 of TS 24.229.

In short, a SIP request may originate from an authenticated identity that required privacy (it will be considered as "anonymous"), from an authenticated identity whose identity can be found in a 3GPP-specific header called P-Asserted-Identity, or from a non-authenticated identity (typically originating from a non-IMS network) that either set itself as "anonymous" or to a certain value. The IMS application server is then supposed to act according to the case it handles. For instance, if a non-authenticated identity was provided in the request, it may challenge it for authentication, typically in an Internet manner (e.g. using SIP digest). In another example, the AS may host service logic that applies to anonymous users or not.

Is is an important IMS feature, that SIP requests initiated from IMS entities are authenticated by the IMS core network, and that the authenticated identity is transported across IMS entities and IMS networks sharing a security trust relationship. This implies that a SIP request issued by a subscriber of operator X can reach an IMS application server from operator Y, without the need for the AS to authenticate the user, as it was already authenticated by operator X and the fact that it was authenticated as well as the authenticated identity are transported in the SIP request. This can be seen as a cross-network single sign on feature of the IMS network, that benefits all IMS services reached through SIP.

P-Headers

As already described in a previous post, a SIP request reaching an IMS application server includes a set of IMS-specific headers ("P-" headers) which are either important for the proper behavior of the IMS application server (e.g. the already mentioned P-Asserted-Identity header, the two headers related to charging) or which can benefit the logic it supports (e.g. information about the access technology currently used by the IMS client).

With the direction of the request, this is the other part of ISC which may require an evolution of a SIP application server to be ported on IMS.

What is Possible, What is Not

In the case where a SIP request initiates a dialogue (e.g. a session, subscription to events), the initial filter criterias and associated procedures at the S-CSCF may make that this request is forwarded to an IMS application server (or several). The IMS application server may either decide that it will only process this initial request (including the responses to it) or that it will process the whole dialogue initiated by this request until the end.

This means that the following cases are not possible:

- An AS cannot get involved in the middle of an ongoing dialogue: it has to be involved from the start.

- An AS cannot cherry pick the SIP signalling it wants. Either it handles the initial request and its responses, or it handles the whole signalling in the dialogue.

- Once it has decided to be involved in a dialogue past the initial request, an AS cannot drop an ongoing dialogue it is involved in before the end.

Any deviation from this approach would be a betrayal of core SIP routing procedures. This implies that what would be gained (an alleged flexibility in the relationship between the IMS core network and the IMS application layer) would be at the expense of the integrity of the SIP protocol, and everything it can bring to the delivery of next generation services.

This feature of the IMS service architecture is sometimes regarded as one of its "limitations". My belief it that those who think this is a limitation of the IMS service architecture are only projecting their own thinking limitations upon the IMS. They would like to engineer an IMS application layer exactly the same way they would engineer a circuit-switched application layer, instead of creating an application layer optimized around and making use of the unique features of IMS and the SIP protocol.

This feature also implies that the concept of "subsequent filter criteria", initially introduced in IMS specifications and never defined afterwards will never come to a reality, as they would violate the basic SIP routing procedures used over ISC. Subsequent filter criteria were introduced to mimic dynamic triggers in the Intelligent Network, which permit an application server to dynamically inform the switch about the events it is interested in.

Registration Case

The IMS application server may reeive 3rd party registration requests from the S-CSCF, indicating that an IMPU has registered/re-registered/de-registered with the IMS core network. this implies that in that case the AS acts as a SIP registrar.

As the 3rd party registration provides little details about the registration (for instance the capabilities of the IMS client are not provided), the IMS AS may need to automatically SUBSCRIBE to the registration event package asociated to the IMPU as soon as it has received the 3rd party REGISTER indicating it has registered.

IMS Application Server Initiating SIP Requests to the Network

An IMS application server can issue SIP requests on its own, without this request being tightly related to a request the AS previously received. The generated request might be a side effect of one or several SIP requests previously received by the AS, of interactions with an end-user performed through a non-SIP interface (e.g. web page, SMS), of interactions with a 3rd party service (e.g. web services), but these are only examples: anything can do, and the more intelligent the service is, the more spontaneous the generation of SIP requests can be.

SIP Roles

The IMS application server can act as a SIP User Agent. It is the initiator of the request and it will support the end-to-end SIP interaction with its SIP peer, whether this is an IMS client, an IMS application server, or another SIP entity outside of the IMS.

The IMS application server can also act as the 3rd party initiator of a dialogue between two other SIP endpoints, like two IMS clients or an IMS client and an IMS application server. In this case, the AS acts as an initiating back-to-back user agent (initiating B2BUA). This role can be used for example by a service to automatically set up a call between two users or implement a click-to-dial-back feature supported by a web page (the user clicks on a link to get called back by an operator. the service logic selects the operator and establishes the call between the two).

Note that an alternative way to implement 3rd party control is for the application server to use SIP REFER towards one of the SIP entities it wants to involve in the dialogue (e.g. the AS asks user A to set up a session with user B). This approach is simpler to implement from an application server perspective, as it does not require the usage of an initiating B2BUA, but it also requires the support of the REFER method by the SIP client, which is not a given in current SIP networks. The approach may also have an impact on how charging will be performed.

Originating IMS Identity

When it initiates a SIP request towards another IMS or non-IMS entity, the IMS application server (more precisely the service logic it hosts) has the choice between two possibilities.

The AS may act on behalf of an IMS user, and use an IMPU of this user as the identity initiating the request. Doing so, the AS can impersonate a user it serves, and for instance send an instant message or subscribe to the presence of a 3rd party just like the user would.

Note that this ability of an AS to issue a SIP request on behalf of a user (which may not be registered with the network at the time the request is initiated) is the reason why 3GPP had to introduce the initiating unregistered session case in the R7 specifications of initial filter criterias.

The AS may alternatively populate the P-Asserted-Identity header with a PSI, thus endorsing an identity associated with the service logic that initiates the request. For instance, an application server may initiate a request as a specific conference, voice mail account, or chat room.

Because it has a secure connection with the IMS core network and it is part of the IMS trust domain, the AS can directly set up the P-Asserted-Identity header with the IMPU of the user whose behalf it acts on or a PSI, ensuring that the IMS request was duly authenticated by the IMS network.

Routing of the Request

3GPP initially tended to be very restrictive about how the routing towards the IMS core network of a SIP request initiated by an AS could be performed. Fortunately, the latest specifications permit room for variants.

When the request is sent on behalf of a user, the AS may have to route the request to an S-CSCF serving the IMPU of the user, in order for originating services associated to the user to be executed (in this case the AS has to insert the "orig" parameter to indicate this is an originating request). The routing of the request to this S-CSCF might be direct, which implies that the AS knows the address of an S-CSCF serving the IMPU (possibly through a previously received request, or by retrieving it from the HSS via Sh), or through an entry point to the network serving the IMPU (which is less efficient but requires less knowledge from the AS).

Alternatively, and if the operator policy allows it, the AS may directly route the request to the network serving the destination address, thus bypassing potential originating services and charging procedures associated to the IMPU. This flexibility was not part of initial 3GPP ideas, but I always supported it as a simpler approach placing fewer constraints on the AS, and which is certainly adequate for some services.

The procedure for the case where the request is initiated by a PSI is similar, except that when the request is routed to an S-CSCF serving the PSI in order to apply originating procedures and execute originating services, the address of this S-CSCF is a priori static and can be configured in the AS (but it can also be retrieved from the HSS as well).

Note that the case where the AS has to route the request to a S-CSCF serving the IMPU or PSI requires an IMS-specific behavior that will impact non-IMS SIP application servers when they are ported on IMS.

P-Headers

This is another constraint associated to an IMS application server, and which needs to be considered when porting a non-IMS AS on IMS: the IMS AS is responsible for generating and inserting 3GPP-specific headers in the SIP request prior to forwarding it to the IMS core network.

Beside the already mentioned P-Asserted-Identity header, the AS has to insert a P-Charging-Vector header including a unique id for the transaction/dialogue (called icid) as well as an identifier for the network the request originates from (called orig-ioi). It will also have to process 3GPP-specific information coming from responses, like the identity of the terminating network (term-ioi).

Non-SIP Interfaces

Just a reminder: SIP is only one of the protocols that may be used by an IMS client to access an IMS application server. Therefore, this post is focusing on just one part of the inclusion of the IMS application server in its environment.

An IMS Application Server in Context

The figure above (click to enlarge) shows how an IMS application server can fit in a service delivery context that includes a legacy telecommunications environment, the Internet, the IT environment of the users it provides services to, and (of course) the IMS.

This picture might not be perfect (though I like the shades of blue), but let me know if you can find much better in the current IMS literature.

A specific instance of an IMS application server may only implement a subset of the features shown in this figure, depending on the capabilities of the platform supporting it, and its potential specialization based on the logic it supports.

It is not the purpose of this post to discuss the technologies that can be used to support such an IMS application server. However, if you look for platforms able to support most of what is implied here, J2EE and JAIN SLEE are certainly the best candidates, and a combination of both might be the winning ticket right now.

Pre-IMS Context (white boxes, black arrows)

The white boxes and black arrows represent the typical pre-IMS context of an application server, that applies to most current Service Delivery Platforms (SDPs).

Applications implemented on the application server can make use of a set of network capabilities such as call control, location, SMS, MMS.

Each set of capabilities is supported by a dedicated network server (e.g. switch, location server) and through a specific network to network interface (e.g. INAP, MLP).

On top of these protocols, the typical SDP provides for the service logic it hosts such features as horizontalization (e.g. hiding of the underlying stove pipes), homogenization (e.g. via a set of similar APIs), simplification (e.g. hiding details of ugly telecom protocols), and abstraction (e.g. permitting to manipulate a call at a high level).

It also exposes the capabilities to 3rd party service providers, through CORBA APIs (e.g. Parlay Classic) or web services (e.g. Parlay X).

The set of capabilities available to service logic in the SDP and to 3rd party service providers is limited and static. It followed a very slow standardization and implementation process, starting with the standardization of the network enabler (e.g. IN), and finishing with the implementation of (standardized) web services (e.g. call control). This means several years.

IMS, and more generally the move to all-IP can change all this and make the picture more colorful.

Where is the IMS Core Network? (lower part)

You might have noticed that the figure does not show any IMS core network entity (e.g. CSCFs, HSS, gateways).

This is not because they are not there or they are not important to the IMS service architecture. Actually, without them, the IMS service architecture would not exist at all!

The point is that the IMS core network itself is of limited relevance from an application perspective, compared to the sophisticated SIP routing mechanisms it provides. This is an aspect that is usually overlooked, as the IMS core network is often the tree that hides the forest to those who try to understand the IMS service architecture.

For instance, I believe that ISC (IMS Service Control) should not be considered as an interface between the S-CSCF and the IMS application server, like INAP is an interface between a switch and an Intelligent Network server. ISC is just the SIP road that permits to connect the IMS application server to the IMS/SIP motorway that connects all the blue entities in the lower half of the picture.

One of my core beliefs is that, among all the benefits the IMS core network can provide to its application layer, one of the most important should be its transparency. An application should only care about what the IMS architecture can provide to it, not about the sophisticated details of how this is done. The application should only know that by issuing this SIP message to this user identity, it will be able to magically access this enabler (e.g. the presence information of this user), and that is all. This is unfair for the hundreds of pages that specify the IMS core network, and the thousands of workers that implement or will operate it, but life is unfair.

SOA and UOA (upper vs. lower parts)

As I wrote in an earlier post, the IMS service architecture as it is depicted in 3GPP specifications is like a picture of a person which would only show its lower half. The reason for this is that 3GPP IMS specifications are core network centric, and only address the relationship between the IMS application server and the core network.

Whereas the pre-IMS application server only exposes a few web services to (hypothetical) 3rd party applications, the future application server should be an integral part of a service oriented architecture, in which applications deployed in the operator's domain could as much be consumers of 3rd party services as they expose some, and could as well integrate with the user's IT environment (e.g. calendar, applications running at home or in the office).

This Internet and IT -centric dimension of the application layer is complemented with its IMS and SIP counterpart (SIP is not the only service protocol that will be used in the IMS, and IMS is not the only network making use of SIP), which adds user orientation to the global service architecture.

To over-simplify, the service oriented architecture routes service requests according to the identity of services, while the user oriented architecture enabled by IMS and SIP can route service requests according to user identities, service identities, or a combination of both. As a consequence, the identity of a user placed in a SIP message (as originator or recipient) may impact service routing and direct the SIP service request to network-based applications serving the user, client or endpoint applications serving the user, or the user itself.

In terms of semantic, it is time for the large part of the telecom industry that still ignores it to understand that the concept of SIP session is much broader than its legacy "call" counterpart, and that SIP is not limited to session control. There are other SIP methods and mechanisms which could be of great interest in the future application layer (e.g. SIP event packages), and which sometimes overlap with the semantic usually associated to web services (e.g. will you use a web service or a SIP SUBSCRIBE to access user information?).

IMS Capabilities: Numerous, Dynamic and Everywhere (lower part left)

The semantic power of SIP, as well as its extreme extensibility and versatility compared to telecom protocols (just look at the rate new SIP drafts pop up in the IETF) make that capabilities usable by applications can be varied, dynamic and multiple.

These capabilities will seldomly be located in standardized network servers like today.

Some will be located in IMS application servers. Every new IMS application exhibiting a SIP interface to end users might be usable as an enabler by other applications using the same SIP interface. Some of these applications could themselves be used as enablers, and so on,

Other capabilities will be located in endpoint servers and devices connected to the IMS, including those associated to end users in a fixed mobile converged environment (e.g. mobile phone, PC at home, home gateway, set top box, fixed phone). Every new application deployed in these endpoints and devices may give birth to new enabling capabilities usable by the IMS application layer. Just to take an example, there exists today a SIP event package that can be used to monitor the activity of a user on a keyboard.

Access to these enablers located in network application servers, IMS devices and enpoint servers, can cross network boundaries. This is, an application located in operator X's network can access an enabler located in or registered with operator Y's network or in the Internet. For instance, an application associated to John, subscriber of operator X, can access the presence of Alice, subscriber of operator Y, and the presence of Bob, located in the Internet.

Web Services, SOA: Much More Possibilities (upper part center)

The multiplicity and dynamicity of IMS service capabilities permits the operator to offer a much richer and differentiated set of IMS services to 3rd party service providers.

Besides the usual communication-related suspects, a large portion of these services are likely to be informational: information about the user, its preferences, its data, its applications, its devices, its activity, etc. It will be the responsibility of the operator to preserve the intimacy and privacy of the users.

The dynamic approach implies that operators will have to rely less on standards and more on differentiation in order to attract third party service providers. This is one example, among others, about the need for the telecom industry to find a new balance between standardization and differentiation.

Web services are not the only way to integrate 3rd party services in the operator's offer. This integration can also be performed on a more horizontal axis.

3rd Party Services Integrated Through End-to-End SIP (bottom part right)

3rd party applications located in the IMS (e.g. in a different operator's network) or in a non-IMS network (e.g. the Internet) can have an end-to-end SIP interaction with the IMS clients of the operator's subscribers. These rd party applications may either be network-based (e.g. implemented in an IMS application server) or device/endpoint server based.

This end-to-end service interaction can be placed under the control of the IMS application server, as soon as the service profile of the user is provisioned with an initial filter criteria that identifies end-to-end SIP signaling between the user and the 3rd party application.

For instance, routing of SIP signaling to the IMS application server may be determined by the fact that the SIP request is addressed to a specific SIP URI (e.g. sip:this_service@3P_SP.com), a specific SIP URI domain (e.g. 3P_SP.com), or because the SIP request explicitly identifies a 3rd party application in a SIP header or in an SDP (session description protocol) body. For instance, the name of a game could appear in the session description of a SIP INVITE aiming at starting a gaming session.

Service logic inserted in the signaling path between the user and the 3rd party service can serve various purposes: control, charging, monitoring, adding value. Do not overlook the latest item: telecommunications should not be only about control and charging.

3rd Party Services Through SIP Indirection or Inclusion in SIP Session (same)

This is just a variant of the previous one.

This case differs from the one above because SIP interaction only takes place between the user and the service logic hosted in the IMS application server.

The 3rd party logic or content is accessed/controlled through other protocol(s) than SIP (e.g. HTTP, RTSP, web services).

I already gave an example of such an integration through SIP indirection. In the future, I will post another one showing inclusion of 3rd party content in a SIP session controlled by the operator.

The Ut Reference Point (lower part left)

The picture shows the support of the Ut interface which, in the IMS service architecture, permits an IMS client to interface with the IMS Application Server using XCAP (HTTP-based protocol that manipulates XML documents) for service data management.

I extended this interface to HTTP in general, as it is very important to permit that IMS clients interact with service logic through advanced web-based user interfaces. Other relevant protocols may be added as needed.

Conversion Between SIP and Non-IMS Protocols (upper part right)

It can be rightfully argued that this should not be part of the SOA layer, but please bear with it.

The IMS service architecture makes it very convenient to detect and divert SIP signaling which needs to be converted into another protocol (e.g. Jabber/XMPP, OMA IMPS CSP) to an IMS application server serving as gateway towards this other protocol. Conversely, the IMS Application Server can receive non-IMS messages and convert them towards SIP for interaction with IMS clients.

This approach is currently used in 3GPP for the support of SMS over generic IP access (which encapsulates legacy SMS's into SIP IMS Messaging).

Note that the IMS core network only supports protocol conversion from/to legacy circuit-switched networks for voice calls. The rest is up to the application layer.

Christophe