IMS Walking in IN's Footsteps

By Richard "Zippy" Grigonis
Twenty years ago, the Intelligent Network (IN) was the telecom industry's hope for rapid deployment of new services. While IMS and IN are technically very different, there is much IMS can learn from the history of IN. While IMS proponents claim it will enable operators to easily deploy rapidly launched, high-value services that will increase Average Revenue Per User (ARPU), questions remain about when its widespread adoption will occur.

The same problems that limited the IN to about five "killer apps" — complexity and the lack of open standards for the service creation environment — may limit IMS' potential. Key players that should be working together aren't on the same page. Network equipment providers want to lock operators onto their proprietary standards. Application developers want interoperability so that services such as video sharing can extend beyond the AT&T network. Operators just want to be first to market.

Of course there is no ironclad way to accurately predict IMS' overall impact 10 to 20 years from now. But its initial evolution closely resembles the stutter steps the IN made toward widespread adoption. The implications for operators, Network Equipment Providers (NEPs), value-added service providers and subscribers are far-reaching.

Network Smarts

The IN gained traction in the late 1980s and early 1990s as operators who were locked into using one equipment provider's products sought a more flexible architecture that would make it easier to change, add or subtract services. At the time, the only way an operator could add voicemail for example, was to go back to Lucent or Nortel , depending on which equipment they had. Deployment time depended on equipment providers' timescales for configuring, deploying, testing and launching the service — sometimes as long as a year or more.

The IN infrastructure defined trigger points in traditional call flow and then leveraged Signaling System #7 (SS7) to transfer information and control to independent computer systems (called Service Control Points). This meant that new services could be launched independently of the original switch vendor, thereby shortening launch time and giving operators more flexibility in determining what new services to deploy.

In the early 1990s, proponents tagged IN as the next-generation network that would deliver a raft of new communications services that stretched the imagination, and provide a more streamlined approach to application deployment and management.

There is no question that the IN has had some wildly successful applications:

• 800 and 900 numbers — The IN enabled the flexible billing behind toll-free and premium rate services so prevalent   today.

• Mobility — Mobile telephony is now measured in billions…as in subscriptions (3.3 billion, according to Informa and   revenues ($100 billion in text messaging alone in 2007, according to Informa).

• Voicemail — The IN allowed operators to set up innovative applications, such as voicemail, from third parties.

• Prepaid calling services — This is another innovative application developed by third parties that determines if a   subscriber has enough money to pay for the call, or whether the system should divert the call to an interactive system that   tries to sell more credits.

• Ringback tones — The IN enabled this third-party application to get control of the "alerting" phase of call setup, matching   an inbound phone number with pre-determined ring tones.

But that's it. We did not see the hundreds and thousands of new services that were predicted.

It's true we gained innovations that will be a crucial part of how we communicate for years to come. Mobility alone has had more global impact than any prior telecom innovation. But, while the applications that succeeded are widely deployed, there are only a few of them, hardly living up to he hype that fueled such lofty expectations for IN's potential.

Why didn't the IN reach its expected zenith? First and foremost, the network complexity that enabled the above services also made new service development prohibitive. Putting the "intelligence" into the network to allow different nodes to send and receive signals based on standard protocols inherently made the network more complex. As the network grew (i.e., more interoperating nodes and switches and more protocols), the more complex it became.

So when an operator wanted to add a new service, the first step prior to deployment was extensive regression testing. Ensuring new services would not only perform as they're supposed to, but also not affect other services, was a time-consuming undertaking that cost millions of dollars. For many operators, it was too big of a bullet to bite. Why would they risk spending that much money to develop, test and launch a new service if there wasn't a big enough market for it?

Ultimately, that chicken-and-egg scenario limited the IN's potential.

Sliced Bread Anyone?

So far, IMS appears to be headed down the same path. It has certainly attracted the same kind of initial hype and stratospheric expectations as the IN.

Like the IN, early-stage IMS promises a platform on which operators can deploy innumerable new revenue-generating services based on the session initiation protocol (SIP) and Real-time Transport Protocol (RTP) standards and open interface specifications. The premise is to provide fine-grained control of sessions so operators can guarantee QoS (and bill) on a per-session basis. Doing so should enable applications like video sharing, which needs some reasonably constant minimum bandwidth to stream video.

IMS is promoted as the technology to enable Push-to-talk over Cellular (PoC) and the video portion of video sharing (the voice part of the call uses existing voice telephony). Eventually, Fixed-Mobile Convergence (FMC) will leverage IMS using voice call continuity (VCC), but today, most deployed FMC implementations actually use pre-IMS technology, i.e. Universal Mobile Architecture (UMA). To the extent instant messaging (IM) is available on mobile, it also relies on pre-IMS standards, at least for now.

Some IMS proponents foresee a full menu of services as future IMS success stories, including: interactive applications such as gaming and shared folders/sync data; voice/multimedia unified messaging; IMS-enabled voice and video telephony; video conferencing; IPTV/IMS service blending; enterprise routing services.

That said, last fall I moderated a Connect 2007 panel featuring executives from Ericsson and Nokia and industry pundits discussing what's next for IMS. The panelists, all IMS advocates, agreed that for the present, actual IMS deployments are very few, and limited to specific applications like video sharing.

Making Dumb Pipes Smart

As with the IN, the IMS infrastructure's inherent complexity will likely limit its showcase applications that achieve global adoption to just a handful. The complexity comes from attempting to add intelligence and fine-grained control to the Internet. With the Internet, devices connect directly to each other. With IMS, devices ask the network to provide a specific connection to another device.

In an IMS infrastructure, a session begins when a SIP proxy on the IMS system receives a signal from a caller's device. That proxy server transfers information and control through a series of servers that determine who the call recipient is and where that person is, and whether there is enough network capacity to provide the desired bandwidth and latency (for example for a video sharing session). All of this occurs before the call or session is connected. The same system works to ensure accurate billing after the call is over, when it's time to tear down the session.

But having this greater control over the session comes at a price, which is complexity, and which in turn drives cost. So IMS will not be used for traditional voice telephony until IMS has been proven with new revenue-generating applications. Why? Because the cost of IMS is high and potential savings are modest. Why would operators want to take the risk and pay the expense when their existing voice networks are generating revenue and working fine? It's only the potential for new revenue sources that can justify IMS deployments.

A final parallel between IMS and the IN is the lack of standard service creation environments. IMS standards define a standard communications network that could potentially support a variety of applications. But IMS does not inherently provide standards for service development or service deployment. It does not say anything about the Application Programming Interfaces (APIs), databases, programming languages or other tools that an application developer might use to create new services.

Instead, this development support comes from service deployment platform vendors. Because the APIs only work with specific equipment providers' systems, developers can only build applications that run on specific equipment providers' gear. So again, operators are forced to use proprietary IMS service deployment platforms. This in turn will slow widespread adoption, much as it did with the IN.

We won't know for perhaps a decade whether IMS proves more successful than the IN in delivering on its promises. What we do know is that for IMS deployment to gain momentum, someone needs to develop one really successful new revenue source or several moderately successful new revenue streams based on the infrastructure. Until then, application development, new services offering and subscriber adoption will creep forward at a slow pace.

Brough Turner is Senior VP of Technology, CTO and Co-Founder of NMS Communications. For more information, please visit the company online at www.nmscommunications.com.

IMS Magazine Table of Contents