The IMS Lantern: IN

Tuesday, April 17, 2007

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

Who I Am

My name is Christophe Gourraud.

I am French and France is the country I currenly live in, after having worked in Canada and in Switzerland.

I have worked for several telecommunications equipment providers and one operator. Involved in 3GPP standardization for IMS and working as a systems architect, I had for years the opportunity to develop ideas about how to use the IMS in an innovative manner. This blog was one of the outlets I used to express these ideas to the telecommunications community. During these years I filed 24 patents for two companies, wrote articles, spoke to conferences and delivered courses.

I am now a student again, having started in September 2014 an Advanced Master in Innovation & Transformation at Ecole Centrale Paris. I have the desire to help companies innovate and transform themselves.

In the next year I will be looking for a job in this complex domain, in the telecommunications sector or outside. So do not hesitate to contact me if you think I may be the right person for your company.

IEEE Article

The March 2007 special issue of the IEEE Vehicular Technology Magazine on IMS features an article I wrote, which is entitled: Using IMS as a Service Framework.

You can order the whole issue or my article.

Here is the introduction of the article:

The eventual value of IMS will be tightly linked to the number, variety and stickiness of services it will support, as well as its ability to accommodate various business models. An operator having invested in IMS should seek to make optimal use of it, which implies not arbitrarily limiting IMS to specific types of services, specific ways to implement them, or specific business models.

IMS should eventually take part in many services related to communication, content and data, not only as the host of some of these services, but also as a mediator and an added-value contributor to services delivered by 3^rd parties possibly located in the Internet.

This article aims to describe, thanks to a few examples, some of the interesting features IMS can offer as a service framework: not just a framework on which new services can be implemented, but also a framework with which numerous existing and future services can be integrated (see the IMS integration tips in the next sections).

The following sections describe the IMS service framework around the three following topics: the capabilities of SIP (Session Initiation Protocol) as a service control protocol; IMS service addressing and routing features and the new application layer architecture they can support; the ability of IMS to combine service logic distributed among multiple entities.