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

The Beatles & The Stones

The summary of a new report by Light Reading titled Telco Web 2.0 Mashups: A New Blueprint for Service Creation makes me think of the Beatles v. Stones battle.

Obviously, in the 60's the Beatles and the Rolling Stones were foes to death, and history can tell that only one of these two bands was great. Which one?

The report apparently highlights the need for operators to rapidly embrace a web services and service mashups approach. Fine, I totally agree with this.

My problem is when IMS and SIP are presented as an alternative to this approach. In this report this is clearly the bad one, as everybody knows that you cannot implement both web services and SIP/IMS and combine the two for an optimal usage.

When will the industry stop looking for the silver bullet? The unique technical solution, the unique business model that will answer all problems?

A core thesis I am trying to develop in this blog is that SOA/web services and IMS/SIP can be combined together to form a new paradigm (User Oriented Architecture) which, like the bands cited above would be more than the sum of its parts.

Another summary of the report cites JAIN SLEE as the service creation/execution environment in the context of IMS. I like JAIN SLEE and I think it can play an interesting role in IMS and across IMS and other networks.

However, it would be more interesting if the summary mentioned Java EE (J2EE) as well, as it could show that the Web Services / SIP picture is not that black and white. J2EE platforms fit very well in a web services world and I know at least three of the main J2EE platform suppliers which include SIP servlet support at the core of their platform. This means that there exist on the market platforms that can be used to implement services that are both web services and SIP/IMS centric. Unless of course this is strictly forbidden by both IMS and Web Services purists (I already had the opportunity to write about the artificial separation between IMS and Web Services chapels).

Why should the telecom industry just follow the steps of Internet companies and not try to bring its own contribution to the future, by integrating and enriching what exists today?

Christophe

Here is my SCIM

I am far from convinced that the SCIM, as it is usually promoted by suppliers, or as it is currently being standardized by 3GPP under the name of Service Broker, is an essential feature for an IMS that does not limit itself to the reimplementation of legacy telephony over IP.

It can be argued that what I am going to describe in this post is not a SCIM. I would prefer to give it another less ambiguous name, such as Service Dispatcher (Service Broker is already taken). The concept was already discussed with a big IT supplier, and may eventually be implemented as part of their service platform.

Personalized Service Chaining

For me, one of the great features of the IMS service architecture is the possibility to chain services on the SIP signalling path and to have this chaining personalized for each user.

IMS service chaining is based on service profiles, stored in the HSS, and associated to IMS Public User Identities (IMPUs). In practice the same service request originated by or addressed to two different IMPUs can be chained totally differently for each of these IMPUs. The two IMPUs may either be associated to different users, or may implement different personas for the same user.

Service chaining can be very interesting for composing IMS services. There might be several cases (see also this post):
- Two chained services may exert control on the same end-to-end SIP transaction or dialogue, without having to be aware of each other. This is for instance the case when a voice call continuity service (VCC) is composed with other session management services. As long as VCC and the other session management features are chained in the right order, end-to-end behavior will remain consistent. In practice, many typical service interaction management use cases can be solved through a proper chaining of services on SIP signalling.
- A service may impact end-to-end signalling with the knowledge of how service logic further down the chain will react to the change.
- A service may initiate new SIP interactions as a consequence of being in the SIP signalling path (e.g. send an IM to a user)
- A service may monitor SIP signalling without any intention to impact it (e.g. a messaging archive).

It is important to note that service chaining on SIP signalling is very interesting, but is not the panacea to address all service composition use cases. More especially, it may need to be complemented with more classical web service orchestration higher up in the service logic.

Need to Complement S-CSCF Service Chaining

I do not support the opinion that the current specification for service profiles (initial filter criterias) and for service chainiing by the S-CSCFare too limited and should be extended to handle more criteria such as time or presence information. I find that the current mechanism is both efficient and reasonably simple. If more advanced mechanisms are necessary, they should be implemented in the IT-centric application layer, possibly in the SCIM.

On the other hand, taken in isolation, S-CSCF -based service chaining is not enough, and it has the following issues:
1) It may lead to a heavy processing by the S-CSCF of SIP interactions with application servers, in addition to the other tasks it already has, i.e. virtually doing everything in the IMS core network (e.g. user registration & authentication, end-to-end SIP routing, generation of charging information, etc).
2) Multiple SIP based interactions between the S-CSCF and application servers may lead to bad end-to-end latency for service delivery. These latency issues may potentially lead the operator to limit service chaining for the sake of service usability.
3) Chaining actually concerns application servers, and not individual services hosted by each of these application servers.

Issues #1 and #2 should be addressed via service co-location. It should be possible for an operator to co-locate on the same server, for a given user, services that are likely to be chained together or that generate other SIP interactions (e.g. presence based service accesses presence).

This requires a change of mindset for service topology from a service centric to a user centric approach. Instead of having a server = service(s) approach in which, for instance, presence is implemented a dedicated server aiming at serving all users, personal services should be deployed as much as possible according to a server = users approach. In this context, presence, which is the prototype personal service, could be implemented as an application co-located with other applications using it as an enabler, on application server instances each serving a subset of the users.

Such a service co-location approach reinforces the need for the adoption of standard and open IT-centric service platforms that I already mentioned.

#3 requires the possibility to chain services together at a finer granularity than the S-CSCF, and to do it inside the application server itself. Service co-location makes this need even more essential.

Main Features of the SCIM

In this context, the SCIM performs in the application server, and at service level, what the S-CSCF does in the network and at application server level. Its role is therefore to select and chain the services that need to be executed when a SIP standalone or initial request reaches the application server.

The SCIM exploits and complements the IMS capability to have a personalized chaining (composition) of services on the signalling path associated to a SIP request. Of course, SIP requests may relate to a large variety of services, and are not limited to telephony or even to session control.

The SIP chaining mechanism of the SCIM is very similar to the one supported by the S-CSCF. The user "service profile" used by the SCIM might have similarities and differences with the initial filter criteria of the service profile used by the S-CSCF. All potential enrichments desired for chaining decisions can be implemented at the SCIM level.

The SCIM is one of the orchestration mechanisms supported by an IMS application server, which is SIP centric. Web Services oriented service orchestration is to be supported by a complementary component of the platform.

The platform is typically implemented as a JAIN SLEE or Java EE (J2EE) server supporting SIP servlets. In the latter case, the SCIM can be implemented as an application router in JSR 289.

Such a SCIM aims at enriching the user oriented nature of the IMS service architecture and at providing a highly customizable and differentiated service experience between IMS users. At the same time, it can fulfill many typical service interaction management use cases that are targeted by service broker standardization.

Other Potential Features for the SCIM

I like the idea of keeping a SCIM well focused and simple enough to be managed. However, the core functionality described above can be extended directly in the SCIM, or through some complementary components added to it.

Here follow some examples.

An IMS application server needs to follow some rules when interacting with the IMS core network. For instance, when a service initiates a SIP request out of the blue, it needs to include relevant information such as a an original ID for the SIP dialogue/transaction or a charging vector, and it may be mandated to route the request to a specific S-CSCF when this request is initiated on behalf of a user. This task may be handled by the SCIM, if it is not by another component or by the application itself.

As part of its service selection and chaining task, the SCIM may forward a SIP message to remote application servers. By doing so it partly takes over the responsibility of the S-CSCF and permits to offload the IMS core network from a part of application layer related SIP interactions.

A remote application server may not comply with IMS extensions to SIP, and may therefore not be able to exploit them (for instance, a non IMS application server may not be able to extract the asserted identity of the request initiator from the 3GPP specific P-Asserted-Identity header). In this case the SCIM may adapt SIP messages between between IMS and the non-IMS application server.

A remote application server may belong to a 3rd party service provider. The SCIM or a complementary component may support policies for interactions with this 3rd party.

The SCIM may possibly translate SIP requests into web service requests or other application-related interfaces.

July 6th 2007 update: I made another post on this subject, with figures.

Christophe