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

Moving the Frontier between IT and Telco (part 1)

The recent years have seen an evolution of telecommunications systems from being implemented on telco-specific hardware and operating systems with telco (and supplier) -specific programming languages to increasingly relying on more standard IT platforms and technologies.

This evolution permitted new suppliers to enter the telecommunications business, for instance in the OSS/BSS (often called "IT") layer and in the parts of the application layer which are drifting away from classical telecom services (e.g. platforms for mobile portals, IPTV, media servers). Lately, even traditional telco areas have been made candidates for advanced IT-zation, as fortresses like IN and network databases (e.g. HLRs) are now under siege. The former is attacked by standard and open Java platforms (JAIN SLEE) while the latter is evolving from monolithic implementations to multi-tiered architectures making use of standard and open data repositories in the backend.

New entrants in the telecommunications domain tend to offer more features for a fraction of the cost associated to a large telco supplier alternative. The carrier-gradeness of products is less and less a distinctive feature of the old guard. On the other hand, there usually still remain important differences in the support offered to customers, which is a fundamental component of the telecommunications industry, with distinctive telco traits compared to other domains. However, new suppliers are more and more attractive for increasingly cost-obsessed operators, and this will certainly lead to a redefinition of the whole telecommunications supply chain in the years to come.

At the moment, most "core" telecommunication equipments (network, application layer) are still supplied by large telco vendors, which have an interest to adopt enough of standard IT to improve their productivity, optimize their development costs and satisfy their customers, but not too much in order to preserve as long as possible the largest share of the telecom cake.

Actually, the situation varies a lot depending on the suppliers. Some have already embraced the IT-ization of the telecommunications domain, by actively preparing their transformation from equipment supplier to software supplier, by acting increasingly as an integrator, and by relying more and more on strategic partnership with complementary companies. On the other end of the spectrum, there are suppliers which still resist this evolution, possibly because they have more to lose than others in a more open market.

Large telco vendors typically sell black boxes, with the difficulty for the customer to modify, customize or add features without having to beg and (over)pay for it.

I make a distinction between 2G and 3G black boxes. In a 2G black box, an entity specified in a telecom specification is implemented as one application vertically integrated with the platform it runs on. On the other hand, 3G black boxes are based on a more advanced IT architecture, which permits the supplier to implement and co-locate various standard entities on the same platform. The game is then to close the box and sell all these applications as a monolithic omnipotent product, instead of explaining to the customer that each application is independent and could be purchased without the others.

Another important leveraging element for traditional telco suppliers to maintain their footprint with operators is to keep as much control as possible on the OSS/BSS tools, by counting on both the resistance of operators' OSS/BSS employees to changes, but also by ensuring that provisioning interfaces remain as proprietary as possible. The OSS/BSS tools of the supplier will be the optimal ones to operate the products of the same supplier. In this context, 3GPP was never able to go very far in the standardization of management interfaces.

A technology like OSA/Parlay (the original version, Parlay Classic) was very interesting for these telco suppliers, as it permitted to define a clear frontier between the IT and Telco worlds in the application layer. The IT world started on top of the Parlay gateway, which implicitly meant that the gateway itself and everything below it was owned by the telco domain. Moreover, this frontier (the OSA/Parlay APIs) was defined according to the telco vendor's terms, as IT companies had very little if anything to do with the specification of OSA/Parlay.

The evolution towards all-IP networks and IMS, which essentially imports IETF specifications instead of re-inventing new telecom protocols based on an IETF baseline (see MMS or OMA IMPS as examples of telco-ization of Internet protocols), might lead to a new distribution of roles between legacy telco suppliers, mainstream IT vendors, and all companies in-between.

This prospect is not necessarily easy to accept for operators (or some of their organizations). Many of them have been used for years to rely on a few vendors for everything. This often leads to a strange and somehow unhealthy relationship, in which the vendor is sometimes in the position to think and decide on behalf of its customer. These days, an operator often has to chose between technically and financially superior solutions that also come with a set of challenges and risks (linked to novelty and the need for the operator to take more responsibilities), and the comfortable alternative to simply give more money to the legacy supplier who will take care of everything.

In a future post, I will more precisely speak about how I see the frontier between the IT and Telco domains in IMS.

Christophe