The quest for the killer app for IP multimedia subsystem, or IMS, continues at a feverish pace these days, fueled by successes in the Web applications space from companies such as YouTube. Operators and applications developers, based on the Web application development model, have realized that trying to build vertically integrated systems and closed systems will never lead to that elusive killer app, while layering, specialization and openness are key attributes of entities that enable killer apps. With subscribers demanding faster innovation, while accessing the network using many modes and many devices, operators must adopt a different approach to building their network so as to be flexible, nimble and have the ability to experiment with new services so that a killer app may arise.
Operator attitudes toward IMS
IMS as a standard came into effect in 2002 within the 3GPP standards body. Its assumptions were geared toward mobile networks. Subsequently, other standards bodies such as ETSI TISPAN extended the standard for fixed networks, followed by a harmonization of the TISPAN and 3GPP versions of the IMS standard. The harmonization efforts between the two bodies have made the two versions of the standards remarkably similar. Today, PacketCable has adopted the harmonized form in its PacketCable 2.0 Architecture.
One of the major drawbacks of the IMS architecture is that various access methodologies specify a different access network element (see illustration).
Currently, the other drawback of IMS is that the focus is on getting the core infrastructure right rather than on the applications. This is leading to confusion about what applications can be deployed over IMS. More important, it has been leading to discussions about a killer application that will kick-start IMS infrastructure investments.
While on the one hand, that is a prudent approach to planning for capital investment in new infrastructure, there is another school of thought that essentially says that one cannot commission an artist to produce a masterpiece--instead, create the infrastructure to enable multiple applications to be built and deployed on top of it. In fact, since the advent of the Internet, there are more examples of the latter. The way operators have started to deal with the latter scenario is by specializing, thereby making their investments pay off sooner.
However, operators today are waiting for IMS standards to shake out and stabilize. Currently, there are a number of IMS versions that operators have to deal with--3GPP, TISPAN and PacketCable--and the perception is that none of them is complete. There are many initiatives under way to prove each approach to the standard, as well as to ensure that the standards are stable enough to actually start deploying services.
A number of best practices organizations such as the Multi-Service Forum (MSF), and trade associations such as the GSM Association (GSMA), have started to look into not only the interoperability of IMS networks, but also what types of applications can be deployed on IMS. The MSF performs biennial Global Multiservice Interop (GMI) events in multi-vendor and multi-operator settings to explore interoperability issues, as well as look at bridging currently deployed architectures to IMS architectures. The GSMA has a global initiative called IP Interworking to prove global interoperability of IP-based services. These initiatives serve an essential purpose of “debugging” the standard.
Operators eager to embrace IMS have been looking at trial or pilot deployments for evidence of success. These trials provide many benefits--first, the operator obtains an understanding of what type of applications and back-end systems are required to begin service rollout; second, it gives operators an idea of the amount of reuse of network elements possible in the infrastructure part of the network; third, the operator acquires an understanding of service reach challenges by looking at the interconnect issues. These studies provide the operator with good insight into the real cost of deploying IMS infrastructure in their network.
Operators’ motivation for IMS
With the continually increasing deployment of IP networks, real-time services over these networks provide opportunities for operators to increase revenues and expand their subscriber base. Because there were no early standards, voice-over-IP (VoIP) architectures were driven by best practices and protocols such as session initiation protocol (SIP) were undergoing transformation, standardization and acceptance within these architectures. Now, with the introduction of the IMS architecture, operators have an opportunity to rationalize their current investments and deploy an accepted global standard. IMS also promises operators an opportunity to invest and build one infrastructure that can then be used to deploy and deliver multiple applications, thus providing increased network efficiency, as well as a reduction of the capital expenditure per subscriber.
The complexity of IMS
This is not to say there are not issues related to IMS architectures. IMS is truly a subsystem--that is, it is not intended to be an end-to-end architecture. It builds upon standard protocols such as SIP for session setup and teardown, Diameter for querying policy, and H.248 for control of elements. The IMS architecture itself is specified in terms of functional blocks connected by named interfaces whose behavior and interaction is well specified which were done with any real-time application in mind.
Implementing IMS is far from simple. Even though the functions and the interfaces have been standardized, the challenge now rests on the integration of these functional blocks into network elements and the interoperability between networks for a given application. There may also be tactical issues with testing the implemented interfaces against compliance with the given standard.
Interop issues in IMS
Interop issues abound in IMS, most of which center on the application. Different applications seem to emphasize different aspects of the underlying protocols and systems, hence there is a fear that not all applications will run as well as another on a given IMS infrastructure. To verify this, several standards bodies such as the Open Mobile Alliance (OMA) have set up “Test Fests” to not only test the specification, but to also test implementations for interoperability. The MSF GMI testing is another such effort to promote interoperability between networks as well as applications to IMS networks.
A larger issue is that IMS-based networks are not going to exist in isolation, and pure IMS networks are going to be hard to deploy. This statement implies bridging between IMS-based networks and older architectures is going to be a huge challenge. The new network has to be in dual-mode, supporting both IMS-based and non-IMS-based services. Operators do not want to strand existing customers as they move to IMS.
VoIP: the IMS killer app
Given the potential interoperability issues that could creep into IMS, one of the applications that operators can use today to determine interoperability of networks is VoIP. Voice as a service has existed for a while, and with IMS networks, voice can be turned into an application that can be embedded into other services. Thus, VoIP and the IMS infrastructure will enable richer collaboration between subscribers. Voice services traditionally have had global reach, and VoIP as an IMS-based application should also have global reach--this implies global IMS network interoperability. Not only does VoIP become an essential ingredient of any killer app that IMS is able to foster, but because of its ubiquitous reach, VoIP itself becomes the first killer app of IMS.
To take advantage of IMS architectures today, operators of all types, including incumbents, independents, wireless operators and service providers, are zeroing in on what they know best--voice. Enhanced telephony services are emerging as the biggest applications opportunity--with VoIP at the top of the list--and operators are looking to bundle services such as voice mail and messaging under VoIP as a means to create subscriber stickiness, increase revenues and reduce the barrier to experiment for the subscriber. IP-based service bundles are easier to deploy and manage, and IMS is an attractive way to achieve this. Other applications of interest include fixed/mobile convergence (FMC), presence and instant messaging (IM).
To make the IMS vision a reality, operators must seek value and deploy interoperable IMS components into their network. Because of the standardization of interfaces, operators can deploy best-of-breed components and solutions. IMS enables service roaming for all services, and hence it is important for inter-operator network compatibility and interoperability for service reach purposes. Deploying the most interoperable solutions for secure peering with other networks, whether IMS or otherwise, is an important consideration for the operators.
It was here all along
As operators continue to search for the killer app for IMS, others are starting to realize they had the killer app all along on their traditional network--voice, or more specifically, VoIP. VoIP is the one killer app for the immediate future. It is an application that can easily bridge the existing legacy public network infrastructure with the future IMS environment bringing traffic and revenue to carrier networks as they roll out the technology. VoIP can be embedded in new collaboration applications that leverage presence, location and the Web. In time, as IMS becomes more pervasive, other applications such as video, gaming and services we cannot yet envision will begin to take off, but for now, the killer app remains VoIP.
Sridhar Ramachandran is co-founder and chief technology officer of NexTone.