Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Looking for a provocative & influential keynote speaker, an experienced moderator/chair, or an effective & diligent workshop facilitator? To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Tuesday, May 01, 2007

When is an IMS not an IMS?

...when it's an "R4 IMS".

For those of you not deeply involved in 3GPP's acronymic world, IMS is part of Release 5 of its huge standards programme. Releases 6 and 7 provide enhancements to it.

One of the original ideas behind IMS was to stop operators wasting money on "reinventing the wheel", deploying new "silos" of equipment dedicated to each new application, when various of the components were essentially duplicated. Why should email, voicemail, IM and SMS all have separate boxes, with separate customer databases, and separate authentication, for example? Why have multiple instances of audio processing engines through the operator for different applications, when they could all be concentrated in one place - and maybe even outsourced to a 3rd party?

Obviously there's a lot more to IMS in terms of improved opex of an IP underlying network as well (a sort of bottom-up business case), but certainly the "top down" efficient application-layer argument is still used regularly.

But as Brough Turner from NMS eloquently describes in the exampled linked to above, there's a big gap between the theory (elegant though it may be) and the practical reality of creating applications. He uses ringback tones as an example, and constructs a compelling argument about why it still makes sense to have dedicated audio processing and subscriber engines within the individual application, rather than having them all centralised. Cost allocation, ringfencing vendor responsibility, optimising latency and so forth all point towards not sharing everything.

And this is all for an application that doesn't need a specific client on the phone. Extend this argument further and you have the issue I've discussed before - the complexity of mixing "full IMS" and "non-IMS" on the end devices.

The other interesting angle that Brough mentions is that around the R4 issue. Softswitches - building blocks of IMS, are also used in other "related" communications architectures (3GPP R4, MSF, TISPAN, Packetcable etc). They've been around for some time, and these separate architectures are (broadly) converging over the next few years, notably in R7. But not yet.

R4 isn't IMS, except in a marketing sense. Sure, it brings in some of the benefits of IP, but so do lots of other things. I'll make sure I grill any vendors or operators that claim "IMS deployments" on exactly what they mean.

1 comment:

Martin said...

When I heard about R4-IMS a long time ago I first thought it must be a joke. Turns out they were dead serious about it. But in the end it's like admitting you can't yet make VoIP over wireless work and thus having to fall back on good old circuit switched technology (on the air interface at least).