Moving the Frontier between IT and Telco (part 2)

There has been an irresistible trend in the recent years for state-of-the-art IT technologies to find a room in telecommunications network, but so far this has still been relatively contained. I think that IMS can change all this and totally redefine the frontier between the IT and more classical Telco domains.

The IMS architecture clearly distinguishes between two types of SIP servers: core network ones (the CSCFs, the media gateways) which support basic IMS access, control and SIP connectivity, and application servers, which can basically support any SIP-related logic which is not standardized as a core functionality of the network.

I think this definition of an IMS application server by default (i.e. an AS is not a core network entity) might be the most accurate you can find at the moment. For instance, I believe that the 3GPP R7 Voice Call Continuity feature, which permits a voice call to be handed over between IMS and the circuit-switched network, should be considered as a core network feature, even if 3GPP decided to host it on a SIP Application Server.

Though the decision from 3GPP to locate a feature on a SIP application server rather than in the core network might not be considered as the ultimate criterion to draw the line between the IMS core network and application layer, I think that these two layers have fundamental differences, resulting into important implementation alternatives.

Stable vs. Dynamic Servers

An IMS core network entity is heavily standardized, both in terms of behavior and supported interfaces. There is very little room for non-standard extensions of these entities, both due to their role in the architecture, and the need to permit interoperability in a multivendor environment.

On the other hand, the standardization of the application layer is very limited. Some enablers like presence or IMS messaging are standardized (in 3GPP, the IETF, OMA), but this standardization should be seen as a minimal required set of features, that can be extended at will for differentiation. Moreover, the application layer should permit the deployment of applications that are not standardized at all.

If you believe in an IMS that supports innovative services for end-users, you need an application layer made of service platforms supporting applications with very short development cycles, that can be co-located (how many services will you deploy if you need one box for each of them?), and that can evolve very rapidly according to the wishes of end-users. Does this ring an Internet-related bell?

Show me the upper part of the IMS application layer!

The network-centric nature of 3GPP standardization makes that the IMS application layer is essentially specified according to its relationship to the SIP-centric IMS core network. This may give the impression that a "SIP Application Server" is only defined according to its support of SIP. This perception may have been reinforced by the SIP-centric nature of early IMS service platforms. This does not have to be.

For me, the IMS service architecture figure from the 3GPP specifications, which places the S-CSCF at the center, and the application servers at the margin, is like the photograph of a person that would only show the legs. In the context of the IMS application layer, the upper part of the body missing on the picture is SOA and Web Services oriented. It integrates IMS applications in the IT and Web 2.0 domains. To this respect, the Parlay X type of approach, which concentrates on the exposure of telecom services to 3rd parties is only one side of the coin, as IMS applications may as much consume 3rd party services as they can expose some.

I can send my version of the complete IMS application layer photograph to those of the readers interested. Just send an email to me (see my profile). It is in color...

Different SIP Traffic Patterns for Core Network and Application Layer Entities

All IMS SIP signalling for all IMS users goes through the IMS core network entities called CSCFs (more especially the S-CSCF).

If you consider John, the proportion of SIP messages that may originate from his devices or are addressed to him and are processed by an S-CSCF serving him is simple to calculate: 100 %. Similarly, all SIP messages originated or received by IMS application servers have to transit through CSCFs. The IMS core network is the SIP connectivity network, the IMS motorway, without which there is no IMS and no accessible IMS application or IMS client. This motorway is agnostic of the services it enables, and will treat in a similar way SIP messages used to establish a voice session, a gaming session, to access or update presence, to send instant messages, or to program your VCR for tonight's TV program.

This is not the same situation for the application layer. An application server hosts a set of services that may only apply to a subset of IMS users, and to a subset of the SIP signalling associated to these users. Typically, a presence server is only interested in presence-related signalling for the users it supports (the user centric nature of IMS permits to distribute users on several server instances).

You may imagine servers hosting very popular services, inducing a lot of SIP traffic, and others serving more niche services, or which use SIP more marginally than other protocols in their service delivery.

Finally, not all IMS services will have stringent latency requirements, as not all of them will be related to real time person to person communication.

Bottomline, there might be very different requirements in terms of scalability, reliability, and latency between IMS core network and application layer entities.

IT Invasion in the IMS Application Layer!

The way I see it, the IMS core network consisting of CSCFs, the HSS, border and voice gateways, is still a very telco-centric system, being highly standardized, essentially processing signalling, processing this signalling in a very systematic, service independent manner, having to be very scalable, reliable and highly responsive.

On the other hand, the IMS application layer is where innovation has to be introduced, it has to be very dynamic, with advanced interfaces towards end-users, and a deep integration with advanced IT and Internet systems. Requirements on capacity, reliability, latency, may be (slightly or significantly) more relaxed than for core network entities.

My opinion is that the whole IMS application layer should belong to the IT domain, with eventually most if not all applications being implemented on advanced, open, standardized service platforms provided by major IT vendors (e.g. J2EE). Application themselves will be implemented by software companies, including some located in garages.

This is a big difference with the current situation, in which most of the telco application layer is still implemented on closed, telco-specific platforms, and supplied by big telco vendors.

An essential point for me is that the IT domain will start on top of SIP (whether ISC or when the AS acts as a normal SIP enpoint) and not only on top of a web services gateway. IMS applications may equally use Web Services, SIP and other relevant protocols to deliver their goodies to end users, and if IMS can bring something to the Internet and IT communities, this is by introducing SIP as a another generic service control protocol, extending SOA into a User Oriented Architecture (UOA).

Christophe