Beyond IMS
Unconventional Wisdom

Tom Nolle, Founder and President, CIMI Corporation

A Webtorials Brief

Published August 2008, Posted August 2008

Abstract:

One of the most significant technology shifts that have accompanied “convergence” is the shift from conceptualizing service features as attributes of network devices to conceptualizing them as something hosted “above” the network. Feature hosting is an integral part of the whole convergence concept, in fact.

But what do you host them on? How does feature hosting create a service experience as reliable as the experiences offered by the PSTN, the world standard in communications services? Can the level of stability offered by telephone switch software “generics” of the past ever be replicated in the seemingly disorder space of application development? These are questions that the industry clearly needed to answer once “convergence” was accepted as a goal, and it would be nice to say that there was an explosion of innovation created to provide those answers. Nice, but not true.

The PSTN had a conceptual model called the “Advanced Intelligent Network” or AIN that defined the role of functional components like a Service Switching System, a Service Control Point, and an Intelligent Peripheral. There was no architecture defined for a converged world, and so convergence players apparently had a problem getting a handle on how the whole thing was supposed to come together. One can almost imagine all those vendors, desperate for guidance, floundering about in their labs. Then, when all was dark, came IMS.

The IP Multimedia Subsystem is perhaps the closest thing to transcendentalism that exists in networking. It’s a concept that captivates millions and has deployed essentially nothing. We can easily say that it contributes heavily to planning and zero to revenue (and at best next-to-zero in real investment). But what IMS did was create a framework in which people could visualize feature-creating applications. From IMS roots came the central element in feature hosting today, the concept of the service delivery platform or SDP.

SDPs are a kind of server, and of course servers have been increasingly a fixture within network for delivery of content, hosting, etc. One might reasonably ask what the difference between an SDP and a server is, and the answer would be hard to provide. Even if we use the strict IMS definition of SDP, about the only thing you might assert as an SDP-defining characteristic would be NEBS compliance for carrier installation.

There is no question that IMS promotes the notion of SDPs with its notion of signaling-driven feature applications. There is considerable question of whether IMS is a sufficient mission for SDPs. Why not call them “IMSDPs?” There are clearly more services than those defined by IMS, particularly in a time when IMS isn’t really defining any services at all in a revenue sense. Linking the concept of SDPs to IMS is like linking the delivery of milk to demand a year down the track. It might show strong planning, but it shows poor revenue realization.

There are already indications that at least some vendors are trying to look beyond IMS in their SDPs, and to create broader architectures (“service delivery frameworks”) to embrace more opportunities and justify more sales. Reality always wins, and that means that the current IMS fixation for SDPs will give way to something more rational. What might that be? That will be our topic for this paper.

Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Please encourage colleagues to download their own copy after registering at http://www.webtorials.com/reg/.