IMS: Architectural Elegance or Quagmire?!

[knagesh]

As a previous hard core engineer, I still get thrills from understanding and internalizing architectures that are simple, yet profound in impact. As a marketeer, I constantly look for linkages to customer and business problems. An ideal marriage between the two would create a lot of wealth for the entire value chain. Sounds simple.

Yet, we have seen time and again the dissonance between the business problems and the chosen architectural approach. When the scale is small, the gulf can be bridged by kludges. But when we are talking about the scale of networks requried to support hundreds of millions of subscribers and interface with hundreds of millions of users on other (including competitors') networks, the stakes are real high. Timing becomes everything. Slow execution would give room to market disruption.

In some sense, the IP Multimedia Subsystem (IMS) archtiecture efforts fit this story line. The elegance of distributed architecture, the decoupling of control and data planes, policy control functions for personalization, back-end integration for authorization, accounting, authentication, were all packed into the vision of IMS.  And rightly so.  SIP for signaling and session initiation and control became accepted.

Applications such as voice, SMS were elegantly supported that operators were in control, monetized their network assets, and established peering relationships or standardized roaming methods. The user network interface was largely for these simple, yet highly profitable applications.

Suddenly the web came along. Became a ubiquitous user interface for both wired and wireless access to applications. Applications to the web were created in the hundreds of thousands. Data services exploded. The notion of signaling and control being integral to the access to these applications was lost. Clearly, the correlation to bits on the network and revenue from the usage was lost. May be lost forever.

It is in the wake of these applications and innovation in the web world that I believe IMS failed to evolve from its inception in 1999. I am not a technical expert on IMS; however, I realize the equation is to monetize the SP assets. Technology is necessary but not sufficient.

We all want our SPs to be profitable so that the cycle of innovation continues. I have more questions than answers. May be the community members can have a candid dialog and extract the possibilities.

• Isn't the question on how we deliver the virtues of IMS rather than exactly how it is done?
• Should we embrace the best of both the IMS and the web world rather than wait for architectural purity?
• Would it be wiser to focus on integration rather than total control?
• Isn't web the ubiquitous UNI of choice? If so, what changes should we make in our thinking of networks, peering, service delivery?
• What does interoperability mean in this context?
• When will we have open APIs on the client/device application side?
• ....

Nagesh

[mgrayson]

Hi Nagesh

so to be clear, IMS is the only standardized architecture offering the ability for converged real time session control over wireline, cable and mobile networks. All analysis now points to the fact that, 10 years after its standardization began, IMS is being deployed, but perhaps not as the 3GPP architects originally conceived; its being deployed for regional services, not with global inter-carrier interconnect; its being deployed for enterprise SIP trunk and centrex type applications, not mobile consumer applications; its being deployed as a single functional entity, rather than decomposed x-CSCFs.

I like this quote from 2004 which perhaps epitomizes how IMS has perhaps at the top of its hype curve 5 years ago.

“The IMS (IP Multimedia Subsystem) is the technology that will merge the Internet with the cellular world. It will make Internet technologies, such as web, email, instant messaging, presence and video conferencing available nearly everywhere”[1]

---

[1] The 3G IP Multimedia Subsystem, Camarillo and Garcia-Martin, Wiley, 2004

But to your point, even 5 years ago, there was little talk of web2.0 and social networking as being competitors to IMS. What is clear is that the innovation engine that's termed web2.0 is accelerating and will continue to push the boundaries between classical session-centric IMS and data-centric web2.0. Time will tell how these two orthogonalities will learn to co-exist.

- Mark

[deanbubley]

> IMS is the only standardized architecture offering the ability for converged real time session control over wireline, cable and mobile networks

But from a user or developer point of view, is there always overwhelming value in either standardisation, or realtime applications?

Doesn't Moore's Law just make it ever-easier to interconnect proprietary, non-standardised technologies? Sure, it's a pain to have to do transcoding or protocol conversion or whatever, but the fact is that it's almost always possible - and maybe the flexibility (and speed to market, and unlocked business models) engendered outweighs that pain.

Also, Web 2.0 (and email, SMS, IM and most of social networking) seems to suggest that in many instances, realtime is a nice-to-have (or even completely irrelevant). Take video-sharing of stream from an event as an example - the chances of two people actually being able to communicate visually at any point in time are small: there is a likelihood that one is walking, driving, unsuitably-dressed, low on battery etc. Instead, there is much more value in storing the video content, then uploading it to YouTube or FaceBook so that multiple people can watch it, at their leisure.

Separately, and 4 years after I first identified it as a gap in IMS, there is *still* no standardised definition or implementation of an IMS-capable mobile handset, especially not one with any form of open API for developers. The GSMA RCS project is inadequate and does not solve the problem, in my view.

Overall, I think IMS has a few silo'd use cases, but in terms of general applicability as a mobile application & control environment, it is obsolete before it has even been deployed.

Dean Bubley

Disruptive Analysis

[knagesh]

Dean, thanks for sharing your insights!

What is your recommendation to SPs and to vendors on prioritizing the resources? What to do and what not to do?

How should we blend the virtues of IMS with the velocity of innovation provided by Web Services platform?

Nagesh

[deanbubley]

Hi Nagesh

No easy answer to this I'm afraid - there are many sets of "resources" and no simple mechanism to simultaneously optimise for all of them. What is more important to control? air interface capacity, cell-site backhaul, transport, core network elements, transit & peering..... or handset battery life, memory capacity, screen real-estate... or prepay credit, or users' time & attention-span... or assorted other variables.

A lot depends on the business model - and what I'd recommend to an operator is selecting a technology architecture which does not "hardwire" in certain models, and "freeze out" others. I don't have the answer yet to exactly what this looks like, it's a position I'm still thinking about & working with associates on. Clearly, it's a non-trivial problem.

The other design consideration must be that "bottlenecks will move". The resources that seem constrained today may be perfectly adequate tomorrow - and the problem shifts somewhere else in the value chain, right down as far as the end-user in some cases. I think that "the network" is going to have to get an awful lot smarter about all sorts of other contextual variables - eg "is the user at home?" or "do they have enough battery to download this movie?" or 1000 other scenarios.

But I do believe that IMS was not standardised with "business model flexibility" as a prime design consideration - it's clearly not well-suited for prepay usage, lots of 3rd-party developers, two-sided market models, ad-hoc (non-subscription) usage models, virtualisation (eg MVNOs) and so forth. Some of these can be cludged-in afterwards, but they all involve lots of compromises.

Some of the emerging API / web-services propositions seem to have flexibility for business model innovation front and centre. What I suspect may work best is to then add various control points *around these* rather than vice versa.

Regards

Dean

[knagesh]

Dean, your last line has immense implications! I wholeheartedly agree with your insight.

"Some of the emerging API / web-services propositions seem to have flexibility for business model innovation front and centre. What I suspect may work best is to then add various control points *around these* rather than vice versa."

How gracefully can we accomplish this coexistence and migration? Supporting interfaces to integrate with IMS core for traditional voice, SMS services, and looking at open, interoperable framework using web services will likely yield the best of both worlds. Protect investment and future proofing.

Would you agree?

Nagesh

[ajay_sahai]

Interesting discussion. My feeling is that just within voice services there can be a lot of innovation by bringing together Web 2.0 applications (including business models) and IMS. This tends to get overlooked very easily, but at least half of the world's population is illiterate and a voice interface is critical for them to benefit from Web 2.0 apps. This is where interaction between mobile, IMS, internet and SMS can help. Examples can be search for information, banking, e-governance etc.

[jdurmer]

I think Ajay's comments touch on a key point....if meaningful integration of services is essentially the "virtue of IMS" discussed here (and this is the promise that IMS holds for operators) then haven't OTT players already beaten operators to the punch?

Help me out here, because it seems service convergence is already happening in the OTT provider's data center.  Google's new line up (now including mobile voice), for example, will now enable converged access to messaging, email, voice/data collaboration and other rich media services through a single portal that they can optimize (including service availability) based on the capability of the connected endpoint you choose to use (fixed/mobile or PC/Phone).

Do I need a SIP-based control solution to apply differentiated policy/handling to multiple media streams (voice, rich data, etc.) delivered to a mobile device if a Web 2.0-enabled DC (that I log-in to once) is already doing that for me?  Maybe I am missing something here, but would be very interested in examples of IMS-enabled services propositions which could position the SP to counter this in the marketplace....

[tredman@cisco.com]

My point of view is that Google still relies on the facilities-based SP (FSP) to deliver the QoS.  In this case, they are getting QoS because they are using circuit-switched facilities to deliver the call (if my understanding of the Google service is correct) which means that Application Layer signaling is the means by which Google is invoking QoS treatment.   At some point in time, they'll have to use IP to transport the voice sessions, and I suspect that the FSP's will make sure that OTT voip sounds lousy. 

There are several ways to invoke QoS that come to mind (IMS, Policy-Peering, RSVP, etc...) , and I expect the FSP's will require Google to do it by means of IMS. 

This is quite similar to the Webex situation-- voice sessions occur when Webex dials your phone through a set of VoIP<=>TDM gateways that they own.  I would expect Webex to punt the gateways at some point and move to SIP trunking.  And at that point, we'll see Webex inter-connected (if not integrated) into the SP's IMS. If OTT voip eventually provides a quality experience, I'd expect Webex to punt the SIP trunking.

[deanbubley]

tredman wrote:

My point of view is that Google still relies on the facilities-based SP (FSP) to deliver the QoS.  In this case, they are getting QoS because they are using circuit-switched facilities to deliver the call (if my understanding of the Google service is correct) which means that Application Layer signaling is the means by which Google is invoking QoS treatment.   At some point in time, they'll have to use IP to transport the voice sessions, and I suspect that the FSP's will make sure that OTT voip sounds lousy. 

Google Voice (aka Grandcentral) still uses circuit-switched connections, as many people have free/flatrate/large-buckets of minutes for local or mobile-to-mobile calls. Many of the other mobile VoIP companies use VoIP over WiFi, coupled to callthrough/callback over circuit depending on context. A few now use full VoIP over HSPA, and obviously anyone using Skype or similar on a PC connected via a 3G datacard or dongle is doing full VoIPo3G.

In most cases, the voice sounds fine - I don't think FSPs can/will "make sure it sounds lousy" in most cases. It's easy enough to hide the voice stream in anything else, and most of the FSPs are far more worried about 2GB a month of Google Maps & YouTube traffic than they are about 50MB of voice, given it's usually for incremental rather than substitutional usage cases. Plus their compliance / SarbOx people would have a fit, if they knew about voice degradation in many countries, given the regulatory regime (or future regulatory threats).

In competitive markets, there will usually be at least one player who's VoIP-friendly. In the UK for example, you can run VoIP over 3 or Vodafone's networks, over T-Mobile's if you pay extra, and I think Orange & O2 are less keen. But Voda Germany has a different policy.

Separately, my general view is that any operator using the term "OTT player" is already dead. Anyone referring to companies they hope will be future customers in such a derogatory fashion won't last long. You don't hear Skype or Google referring to "Under The Floor" players do you? (UTF: that's where the pipes go, right?)

tredman wrote:

There are several ways to invoke QoS that come to mind (IMS, Policy-Peering, RSVP, etc...) , and I expect the FSP's will require Google to do it by means of IMS. 

The FSPs aren't in a position to "require" Google to do anything. I can imagine the second half of the conversation after the IMS suggestion. "So, how about we introduce a 3-second delay on search results to your IP address range, and give free advertising for competing ISPs who have a more enlightened policy, and offer free calls to anyone who proves they churned as a result of the ad?". Or maybe Facebook putting a popup window saying "Your ISP is trying to extort money from us. Two can play that game. We'll be cutting off access from their customers in 12 months' time, unless the ISP pays *us* instead. We suggest you churn". That's not a loyalty battle the average DSL or cable company would win.

This non-neutrality thing works both ways, and operators are going to have to deal with downsides as well as upsides if they want to play hardball.

Separately, it's worth pointing out that one of the best collaborative Internet VoIP/mobile-operator partnerships at the moment (Hutchison 3 + Skype) is not IMS-based. I don't think Fring+Mobilkom is either, nor Jajah+E-Mobile.

Dean

[deanbubley]

knagesh wrote:

How gracefully can we accomplish this coexistence and migration? Supporting interfaces to integrate with IMS core for traditional voice, SMS services, and looking at open, interoperable framework using web services will likely yield the best of both worlds. Protect investment and future proofing.

Would you agree?

Nagesh - It's too early to tell, and I don't claim to have all the answers yet. But I don't see much of a role for IMS in *mobile* voice. There's currently a lot of controversy around implementing voice & SMS for LTE, but as far as I'm concerned IMS MMtel is about the least-likely candidate.

Also Ajay:

>>This tends to get overlooked very easily, but at least half of the world's population is illiterate and a voice interface is critical for them to benefit from Web 2.0 apps. This is where interaction between mobile, IMS, internet and SMS can help

Again, I don't see the clear role of IMS here as an enabler, given that the community you're talking about will not be using VoIP down to a handset for at least 10 years. I agree with the Web 2.0 / voice interface story, but that's more likely to be integrated with CS voice, at least over the radio down to the phone. It'll use a VoIP back-end, sure, but isn't IMS overkill for that? There are already dozens of both carrier & 3rd-party Web 2.0 / Voice 2.0 solutions and APIs either in infrastructure or "in the cloud".

Dean

[tredman@cisco.com]

I think that "IMS" is a stalking horse for "Tight Control by a Facilities-Based Service Provider".   And "Web 2.0" is a stalking horse for anything that is not "IMS".  Ultimately, this is not a technology discussion, but rather a business model discussion.  If the SP's can't exert tight control over their facilities, then IMS may fall by the wayside.  The single thing that would kill IMS is a forced un-bundling of the QoS functions of the Access Link (DOCSIS loop, airlink, xDSL line, etc.).  The reason that this would kill IMS is that this would allow any ASP to get QoS treatment on the Access Link, and we could expect that the inventiveness of the ASP's to exceed that of the Facilities-Based SP. 

For your consideration:  How would "Web 2.0" look if it was used by a facilities-based SP?  I don't know exactly, but it would certainly facilitate a model in which tight control is exerted by the SP, and I think that we'd see objections to it that resemble those for IMS.  Let's say that WebEx were to be the service platform that a large LEC deployed... we'd see linkage to a policy infrastructure that allocated resources to WebEx (and likely excluded other ASP's).  We'd see that it would take a lot of work to get the client certified on all handsets.  We'd see that it would take work to peer up the collaboration services on that SP's WebEx platform with those on another SP's Collaboration platform.  (This list could go on....)

So my perspective is that IMS will absolutely work -- we know this because SIP telephony works is offered today.  And SP's will deploy it, because it works.  There are only two areas of uncertainty:

1) The set of applications that will be written for IMS.  These will include voice telephony services and video telephony services, but the rest is up in the air. 

2) QoS Regulations.  If this is unbundled through government regulation, IMS probably dies.  All of the Applications that require QoS, and that the Facilities-based SP offers, will probably die.