Conflicting Views on the IMS Service Architecture

The two figures above both depict the IMS Service Architecture.

The first one is taken from the 3GPP specifications and is therefore the primary basis for anyone to understand the IMS Service Architecture.

The second one is my own representation of the IMS service architecture, based on the exact same specifications, and is therefore only accessible by the readers of this blog. As I have not seen so far a similar representation anywhere else, you can assume that this is not at the moment the mainstream perception of the IMS service architecture in the telco community.

IMS as a New Intelligent Network (IN)

The 3GPP representation of the IMS service architecture is network centric. It represents the IMS application layer solely according to its interface to the IMS core network, placed at the center of the figure with the S-CSCF.

This representation is potentially misleading as technicians with a classical telecom background can perceive the IMS service architecture as an IP replica of the Intelligent Networks that can be found in all existing fixed and mobile circuit-switched networks. Actually, I have seen this view supported numerous times, both by these people who know everything about telecommunications and by alleged IMS experts.

This IN perception of the IMS service architecture is re-inforced by the fact that two of the IMS application server types represented in the figure are tightly linked to IN: the IM SSF is a gateway between IMS and an IN application server, and the OSA gateway is usually (and rightly) perceived as being essentially an API on top of IN. Adding to the confusion, the terminology used for the IMS service architecture (e.g. trigger points) heavily borrows from IN (to be frank, some companies participating to IMS standardization did see this architecture as an IN one).

In an IN network, the (fixed or mobile) switch interfaces with the application server through a dedicated control interface (e.g. INAP, CAP, an IS.41 subset), which permits the application server to control the switch by issuing instructions to it. These instructions essentially serve the purpose to control voice calls, as the circuit-switched network is voice centric.

In such an architecture, the basic voice services are supported by the core network, which is complemented by application servers for the delivery of "supplementary" or "value-added" services.

With this kind of background, it is easy to perceive ISC as the IMS equivalent to INAP/CAP and the IMS application servers as an extension to the core network. Some might even argue that the IMS application layer is not needed, if you can implement all the required supplementary services within the S-CSCF.

IMS as a Totally New Service Architecture

However, the IN-oriented interpretation of the IMS service architecture does not resist a thorough analysis of the specifications that I tried to describe in past posts (here, there, there and there).

First, with the exception of the user registration part of the ISC reference point (which permits the S-CSCF to notify application servers about registration events, but does not permit the AS to block registrations), ISC cannot be seen as a logical interface between the S-CSCF and the application server.

On the contrary, ISC is only one branch in an end-to-end SIP interaction between the application server and other application-related entities. In such an interaction, the S-CSCF and the whole IMS core network only act as intermediaries and service-related routing functions between application-related entities. This is why I tend to represent the whole IMS core network as a SIP-oriented service bus supporting the IMS application layer (I will come back on this in a future post). This bus is essential for the IMS application layer, but its significance is close to zero from a service perspective. Suffice to say that it duly supports its service bus role, and that the best additional value it can offer to applications is to be totally transparent to them.

The second essential characteristic of IMS that dismisses the claims of an IN replica is that SIP is not the equivalent of SS7 over IP:
- SIP sessions are not voice calls. They are much more generic service sessions, which may even not include any voice or person-to-person communication component.
- SIP is not only about SIP sessions. Other SIP methods make SIP a very generic service control protocol.

With such a knowledge in mind, it is irrelevant to represent the IMS service architecture without representing what is on the other side of ISC (and other SIP-relate reference points supported in the IMS core network). My figure tries to represent all the possibilities.

However, this figure is still incomplete, as it focuses on the SIP dimension of the IMS service architecture. For a more complete view, look at this previous post.

The End-To-End IMS Service Architecture (SIP Dimension)

Many possibilities exist, that I already described in the past (here, there and there), but I will summarize below (note that the examples are very basic).

An IMS endpoint (terminal, endpoint application server) in the operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An IMS endpoint (terminal, endpoint application server) in another operator's domain initiates a SIP service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence.

An endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. enterprise network, the Internet) initiates a service interaction with the IMS application server. ISC is the last branch used in this interaction. Example: user accesses presence. Note that the non-IMS endpoint may either use SIP or another protocol to initiate the interaction. In the latter case, a protocol converter (e.g. Jabber to SIP) will translate the initial request into SIP.
Specific case: the non-IMS endpoint is an application server (e.g. Internet application requiring user's presence).

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in the same operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user.

The application server initiates a SIP service interaction with an IMS endpoint (terminal, endpoint application server) in another operator's domain. ISC is the first branch used in this interaction. Example: application server sends instant message to user of another operator.

The application server initiates a SIP service interaction with an endpoint (terminal, endpoint application server) in a non-IMS domain (e.g. in an enterprise network or in the Internet). ISC is the first branch used in this interaction. Example: application server sends instant message to user in the Internet. Note that the non-IMS endpoint may either accept SIP requests or not. In the latter case, a protocol converter (e.g. SIP to Jabber) will translate the initial request to the required protocol.
Specific case: the non-IMS endpoint is an application server (e.g. presence server).

The application server initiates a SIP service interaction with another IMS application server in the same operator's domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

The application server initiates a SIP service interaction with another IMS application server in another operator's IMS domain. ISC is both the first and last branch used in this interaction. Example: presence-based application accesses user's presence.

An IMS application server acts as an intermediary in any of the interactions listed above, plus the essential case where none of the service interaction endpoint is an IMS application server (e.g. two IMS devices, an IMS device and a non-IMS device, an IMS device and a non-IMS endpoint application server). The idea is for the intermediary AS to either control or add-value to the end-to-end interaction. ISC is a branch somewhere in the middle of the SIP signalling path. Note that several IMS ASs can be inserted as intermediaries in the signalling path, forming a chain of combined services. Examples: IMS AS authorizes and/or charges for access to service, IMS application server inserts media plane intermediary to improve user experience (e.g. media mixing, media transcoding).

User Oriented Service Routing

The SIP dimension of the IMS service architecture relies on two SIP routing mechanims:
1) Standard SIP routing (labelled in the figure as IETF SIP routing) based on the resolution of the target SIP address towards an endpoint.
2) IMS User Oriented and Service Profile based routing (labelled in the figure as user profile based routing), which permits to dynamically alter SIP routing on a user-per-user basis towards IMS application servers. The service profiles stored in the HSS can be seen as service routing routing under the control of the operator and modifiable over time. This permits to incrementally modify SIP routing as applications are added or removed from the network, and this without impacting endpoints.

This draws a service architecture which is very flexible in terms of service logic location (in service entities like application servers in the network, endpoint application servers, devices), very flexible in terms of location of service entities in different domains (the operator's domain, another operator's domain, an enterprise domain, the Internet) and very agile in its possibility to dynamically modify service logic at work in the network.

Christophe

Standardization: SCIM & Service Broker

Here is a first post of a series dedicated to the SCIM concept, which is part of IMS specifications.

In this post, I will describe how the concept was introduced, how it has been handled and actually how it is currently being addressed under a new name: Service Broker.

The SCIM

SCIM stands for "Service Capability Interaction Manager". This entity was first proposed in 3GPP in April 2001, in a contribution made by one of the major telco suppliers.

The purpose of the SCIM was "service capability coordination" (nothing more concrete). The contribution proposed the SCIM as a standalone entity located between the S-CSCF and the IMS application servers. It interfaced with the S-CSCF and the application servers through the same SIP+ reference point (which would later become ISC). Reasons given for its definition as a separate entity from the S-CSCF were that it logically belonged in the application layer and that, unlike the S-CSCF, it would use non standardized data to perform its duties.

This SCIM was clearly derived from the "service interaction management" issue, which is well known in Intelligent Networks, and deals with the coordinated execution of potentially conflictual call control -related services (e.g. call forwarding and call screening). The new IMS entity owed its name to the fact that 3GPP had just decided to standardize "service capabilities" instead of "services".

The contribution caused a little bit of trouble, as service interaction management is considered as a serious matter in telecommunications, and cannot be dismissed like that. However, other vendors did not want to start standardizing a SCIM in 3GPP, maybe because of the complexity of the issue, or because some already felt that IMS was not simply a voice-centric network.

The result was that two of the other vendors proposed to move up the SCIM in the service architecture, and instead of defining it as a standalone entity, they managed to get it located inside of the SIP Application Server. In a standardization body whose role is to standardize boxes and protocols between them, placing a box inside another box is a simple and diplomatic way to kill it from a standardization perspective.

As a consequence, the standardization of the SCIM was limited to a few fluffy sentences in a couple of 3GPP specifications. The SCIM could then be forgotten.

However, years later, as the IMS hype started, some operators started to ask for SCIMs, and some suppliers started to propose something called "SCIM".

It seems that, as the IMS application layer was under-defined, the SCIM became for some the magic box that would answer all the unresolved questions. This is to the point that there exists a Wikipedia entry for it (July 3rd 2007 update: the SCIM definition has been much extended since I originally wrote this post).

The Service Broker

At the begining of 2005, a new work item for 3GPP R7 was defined, which aimed at specifying a service broker in the context of OSA/Parlay, in order to "enable detection and resolution of service interaction". The work item proposal mentioned that the service broker could also support the IMS SCIM, but this was removed from the final version. However, the technical report initiated by 3GPP CT5 (OSA/Parlay) stated that the service broker "should be able of brokering non OSA applications, such as those hosted by a SIP AS and/or legacy services." In clear, the intention was to standardize the SCIM, and to make it part of an OSA/Parlay solution.

As an entity under the control of a group dedicated to OSA/Parlay, the service broker had no chance to be accepted as a SCIM. IMS is standardized by other 3GPP groups, and more especially 3GPP SA2 for its architecture. Some of the companies supporting the service broker therefore proposed to extract it from CT5 and to have it standardized by another group. 3GPP SA2 was reluctant to standardize it (same situation as in 2001 for the SCIM), but was asked to proceed.

The sample use cases given to motivate the need to standardize a service broker for IMS were totally voice-centric, thus clearly positioning the service broker in the same "service interaction management" context as the initial SCIM. I personally found that the use cases were artificial and exhibited a lack of knowledge of how the IMS service architecture works.

Progress on the service broker, documented in TR 23.810 as part of 3GPP R8, has been quite slow until now. At the time I am writing, the content of the TR (version 0.4) is still very high level, and nothing ensures that it will lead to anything concrete. The TR systematically refers to "SIP sessions", and the only example given is totally voice centric (freephone, voice activated dialling, call barring). Different architecture alternatives are given, including one (service broker in AS) which could lead to the conclusion that 3GPP should not further standardize the concept.

I am personally concerned when I see 3GPP devoting so much effort (OK, maybe not that much) to standardize a function without a clear understanding of the problems it is supposed to solve. There already exist parts of 3GPP specifications which are useless, and I would not be surprised if the service broker was also one of these, assuming that the current effort leads to a concrete outcome.

An example of dispensable 3GPP concept is the "subsequent filter criteria". sFCs were introduced at the same time as initial filter criteria (iFCs) and in theory permit an application server to dynamically set filter criteria in the S-CSCF after having been triggered through initial filter criteria. sFCs are the equivalent to dynamic triggers in IN, that permit an IN application to dynamically set new trigger points in the switch. The only problem with subsequent filter criteria is that they do not make sense with the decision to base ISC on SIP, because the concept is incompatible with basic SIP routing mechanisms. Though introduced in 3GPP R5, subsequent filter criteria have never been standardized and are likely to never be. I am citing subsequent filter criteria because the TR for the service broker mentions them (section 5.2), which seems to confirm the IN culture of contributors to the concept.

In the next post I will expose why I do not like ideas usually associated to the SCIM / Service Broker concept.

Christophe

Beware of IMS Service Architecture Prejudices!

It is very easy to wrongly describe the IMS service architecture as an IP replicat of the Intelligent Network architecture.

The analogy can be the following:
- SIP is a call control protocol like ISUP
- The Serving Call/Session Control Function (S-CSCF) is a softswitch
- IMS applications are the equivalent of IN Service Control Points. Actually, two of the IMS application servers types, the IM SSF (gateway to CAMEL) and the OSA/Parlay gateway (typically used as an IN extension), explicitly refer to IN.
- The application servers are invoked through triggers stored in the HSS (equivalent to the HLR). Though these triggers are called "Initial Filter Criterias" (iFCs), they include so-called Service Trigger points (STPs).
- There is an "IMS Service Control" (ISC) interface between the S-CSCF and the application server, which is the equivalent of INAP or CAP.

A first argument against this analysis is that SIP is very different from ISUP, and can support much more than voice or even session control.

A second one is that the Initial Filter Criterias that form service profiles are very different from IN triggers. These are actually generic rules that can apply to any (existing or future) SIP messages and analyze the direction of the message (did it originate from or is it addressed to the user?), the method (is it an INVITE, a SUBSCRIBE, a MESSAGE?), the existence of headers, and the value of these headers (including the possibility to use wildcards).

Finally, the most important aspect is that ISC is not a control protocol that permits an application server to instruct the S-CSCF to do this or that. ISC is just SIP, and its role is to extend SIP reachability to IMS application servers.

When the S-CSCF receives a SIP message and applies iFCs to it, the potential consequence is that this SIP message may be forwarded to one or more application servers. Similarly, when an application server generates a SIP message, the role of the S-CSCF will be to route it to another SIP entity (application server or device). In this interaction, the S-CSCF only acts as a proxy between two SIP entities. The real service control is what may happen between these two SIP entities.

Consequently, in the IMS service architecture, when you combine normal SIP routing and iFC -based routing, the S-CSCF simply acts as a SIP service router, which can support SIP-based interactions between IMS clients and IMS application servers. These interactions may relate to session control, but not necessarily.

The potential for this service architecture is huge, and I will come back on it over and over.

Christophe