I’ve been challenged by a source working for a mobile operator whether my view of IMS is too pessimistic. He writes:
The big reason for carriers to implement IMS is not merely a matter of re-structuring our services in a TCP/IP-oriented fashion, or being able to do seamless provisioning. […]
It is the “enabling” portion of it that matters. Moving to IMS will let mobile operators (for instance) deploy integrated services that can tie together core enablers such as a profile database, a presence server, billing hooks, etc. to build a whole new service with theoretically less time and effort. Essentially, it’s about moving from monolithic, one-piece, vertical services into a component-oriented approach.
Of course, current demo services aren’t that enticing — mostly because this entails a new way of thinking about service design that hasn’t really sunk in yet, and there is the usual amount of experimentation going on. I personally think this will throw up a few good ideas in a year’s time (or even less) as telcos open up to outside partners doing the actual development.
So, the yellow brick road that takes us back to happy, profitable telecomland seems to have a fork. Turn left, kill wicked witch, deploy new services, become rich. Turn right, open up our platform, let the scarecrow and tin man work out what the best services are, click heels, get rich.
Unfortunately, this wizard can’t offer a happy ending for either direction.
Can the carriers deliver on the promise of great new application services?
One way is that they themselves research and discover them. But the precedents are mixed at best. Take MMS (again). What could be simpler than getting users to exchange pictures? But it was a commercial flop. It misunderstood what the value proposition was in the eyes of the user. As I said before, people wanted to share experiences — as sense of “being there”, not just pictures. This means sharing a whole sequence of pictures during a day, and unintrusively allowing a whole string of receipients not at the party/zoo/bar mitzvah to keep up with the event. MMS didn’t define a photo repository API, make sharing across mobile and PC devices simple, etc. Recipients had no easy way of saving and organising the pictures. They couldn’t track things at their leisure.
And at the prices charged, sharing a whole day’s “roll of film” was just prohibitively expensive. You didn’t even get a little stack of pictures to hide in a shoebox under the stairs! MMS’s immediacy wasn’t enough to overcome its deficiencies in competing with the Kodak experience. Flickr got it, telcos didn’t.
So even the simplest of services turned out to be a screw-up. On the other hand, Sha-mail was a success. Sprint’s picture service, which did incorporate Flickr-like features (outsourced to Lightsurf) was a success. Funnily enough, these are the products that didn’t fall out of a standards committee.
[Insider knowledge: picture messaging was a low priority in the Sprint PCS Vision launch, and it only made the cut because the handset folks were only being offered camera phones by the main Korean and Japanese suppliers. There weren’t any non-camera models around to stock, so there was no choice in having a picture messaging product! The big news was supposed to be Java downloads and ringtones, but these turned out to be much less compelling to the users. And instant messaging never made the launch, despite being the most in-demand feature requested by the target youth/early adopter demographic! I look forward to contradictory reminiscences from former Sprint colleagues…]
So there’s good reason to believe that joint efforts of telcos to develop new services will face an uphill struggle. And stand-alone efforts, as noted previously, are limited by your connectivity user base and are in competition against those of Internet giants.
Rather than ‘build’, how about ‘buy’? Can’t you just wait to see what takes off and then buy your way in? Well, that sounded like a nice theory, at least until last week. Then we got to see the price of that strategy. Ouch!
So being the owner of the end application didn’t work. What else is there? Well, you can shred your business model into itsy bitsy chunks, turn yourself into a platform, open up, charge some access fees, and let someone else take the credit.
This is an attractive proposition, and one I’ve promoted extensively. It’s just a shame IMS doesn’t deliver on it. All the key bits — federated identitity, profile, billing — aren’t covered by IMS, which is stuck in a old-skool mindset of the services living inside a telco-owned application server working to telco-owned customer data. You don’t need much sophistication in privacy and permissions control when you federate with yourself. There’s no unified developer program. The architecture is horifically complex. It cuts out the cheap P2P delivery options. It mandates specific technologies (e.g. SIP) when others (e.g. IAX) may be more appropriate for some tasks. No doubt it’ll be a lowest common denominator in presence — your “Away on vacation” status may not be supported, never mind “Needs cheering up”. So I’m not exactly optimistic that this route will play out well for the telcos either.
Mobile operators have a better excuse for IMS than fixed ones. There’s still a scarcity of capacity that requires some form of QoS rationing — at least some of the time. As networks get faster, that need decreases. (All those Skype calls on EV-DO seem to work fine without IMS!) But application-specific ways of tying connectivity and service together to do QoS aren’t the way to do it.
UPDATE: A reader challenges me to say what I would do and say something constructive for once. It’s hard to give a snappy response since my approach would probably try to blow apart many of the assumptions of how we build and finance networks. It’s more than just the technology. For example, the way we license spectrum divides the resource up and limits the statistcal gain we would have from sticking more traffic into one bigger pipe. But forgetting all that, what should a carrier today do? Well, it’s a bit like my 3G advice: no bid on an overpriced license, improve the stuff you’ve got, buy up an over-leveraged competitor later in the business cycle if necessary. Increasing capacity and lowering latency is obviously one first step. (Just increasing capacity alone doesn’t help your QoS problem — check your queueing theory text book.) Embrace user-owned networks, get as much traffic off the WWAN onto WLANs as possible. Avoid the IMS tax by deploying simpler QoS technologies already developed, even if it means doing layer 1/2 optimisations. Encourage innovation by opening up some of your platform using cheap web services APIs. (Application logic does not run in the telco.) Focus on other ‘convergence’ issues like getting MP3 players embedded in your handsets. And so on.
Posted by Martin Geddes at 08:12 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/572.
Interesting post. You are very eloquent in your criticisms.
However, what would you recommend a MNO do right now? Skip IMS and do what? Keep their old stuff and just build a wireless data network? It is all well and good to criticize but often it is better to offer an economically and technically alternate vision, which I do not think you have yet to fully and convincingly articulate.
PS - Maybe all those Skype calls on Sprint EVDO work so well since there's hardly anyone doing it. What if every single phone did it for voice comms? Doubt they have the network capacity, right?
Posted by: at October 6, 2005 09:58 PMEven though a person wouldn't know it if all their information on IMS is coming from VON conferences ... but there are good things in the IMS standards about "all the key bits — federated identitity, profile, billing"
You might not like the output of the GUP work (I seem to remember you making some negative comments on Liberty Alliance in the past), but what standard would you pick to align with?
And one of the things that IMS brought to the IETF SIP world was an extensive and extensible billing framework. Again, you can quibble with the collection of all those events and the choice of Diameter ... but I find the most interesting part of the IMS billing standard is that it breaks the old model that realtime rating and prepaid are equivalent instead of orthogonal like they should be.
Plus, don't blame the IMS standards if an "IMS Network" doesn't convey "Needs cheering up." The capability is there.
Just like many (most?) (all?) of the standards these days seem "horifically complex" - IMS is especially not immune (not with all that money at stake). But, assuming that an IMS application developer needs to know about the internal IMS protocols ( for example the I-CSCF to HSS interactions uses the "Cx" Interface ) is as much use as assuming a web app writer need to know about BGP.
What I'd do - quit, and start up a firm to roll out a broadband mobile IP network using either UMTS TDD in unpaired leftover spectrum or 802.16e. Two policy rules - Pay your bill, and if we get complaints of spam or malware originating at one of our IPs, you get two warnings and out.
Mission - To provide a (in the first step) 1X1Mbps link wherever in the UK you are. Or, if you pay more, a virtual T1.
I'm thinking of calling it nethead.co.uk...
Posted by: at October 9, 2005 01:56 PMI agree IMS is crap. The 3GPP solution was designed by a committee of several thousands engineers. Not all of them on IMS but sufficient to bodge it up. The original intent was good, unfortunately commercial pressures forced the walled garden approach and has prevented the designers to fix mistakes. With this huge pressure to forge ahead (paid billions for the right to use airwaves we need to introduce the service double-quick) and flawed business assumptions, we are now left with a pile of technology that is barely usable on the closed 3G network (well closed until you get viruses on the 3G phones....) but moving it to the fixed network is a disaster. See also the whitepaper here (http://www.eemvalley.nl/unified-networking.com/publications/Unified%20Networking-%20capturing%20revenue%20in%20the%20NGN.pdf).
BTW: I am working on a consultancy job doing a Thread Vulnerability & Risk Assessment on SIP+ENUM. We recently published the interim results and they do not look pretty. We came up with some 2 dozen critical risks where anyone who can read the RFCs and has access to the Internet can make a program to bring down a SIP+ENUM network in short order. (For those with access to the ETSI docbox, look for TISPAN 08TD229 and 228.) So all IMS and all SIP-based next gen service solutions have these critical issues threatening stability!
Why was this discovered only now? Well because no-one wanted to think about this. Anyone who has some understanding of telecom and internet technology can look at the specs and point out issues, however these voices are ignored. At conferences like VON senior execs have been told that SIP is great and they tell their techs to use this SIP thing because it will be important. The techs today no longer can say when something is a bad idea or they will be replaced by other who will not question orders.
Now a dumb network is also not the solution! As Einstein said, things should be as simple as possible but not simpler. The current Internet infrastructure is too simple. With some 1500 automated hack attempts per day at any IP address in the world we have a serious problem and it stems directly from the too dumb design of the Internet. If your machine connects directly to the Internet after having been installed with, say Windows XP, you do not have the time to load all the security fixes onto it; it will be hacked before then.
The solution is somewhere in the middle. You need an open network to make it interesting to end-users (ask yourself; why again did the Internet become so popular?) But you need to provide this with security. (That is btw where peer-to-peer applications fall down, they require you to leave a backdoor open so others can contact you!)
Are there any standards to address this? NO! The IMS bandwagon interrupted the work on such a solution that was happening in ETSI. I founded my company to deliver a proper solution despite the fact that the bandwagons all driving to the swamp. Once they are stuck there I hope to launch my solution to give the end-users an alternative that works and hope to find a way to publish the tech to do it at the same time.
Hmmm....I remember saying that a telecoms system reliant on DNS ENUM was a really bad idea...and I'm not an engineer..
BTW, I recently received a press release from Alcatel boasting that they'd demonstrated IMS in a WiMax network. What's the point? That's like putting mud in your beer.
Posted by: at October 11, 2005 10:39 AMNice whitepaper, btw.
Posted by: at October 11, 2005 11:03 AMFrom what I see above, I think that you may be another fellow skeptic on IMS. My favorite comparison is to take a Central Office switch diagram from 20+ years ago, cut the boxes out with scissors and arrange them on a table. Voila! IMS!
I think IMS is a great re-telling of the "Emperor's New Clothes" frankly. There has been plenty of effort up until now with system integrators to fix interoperability problems. If everyone does the same thing, why would I want to buy any platform over another? So, we lose innovation, and the big NEP companies get to sell yet another generation of equipment to naive operators so they can stay in business over the small really innovative companies that have appeared over the past several years.
Don't get me wrong though, there definitely is a need for interoperability and some sort communication standard between all these devices, but I do not believe this is it!
Posted by: at January 26, 2006 05:14 PMIMS does include standardized Web services for app development outside the walled garden. They are, in fact, actually being used by enterprise customers of a US operator to build apps customized to their needs and integrated with their existing data systems.
The problem is that when you say IMS, everybody immediately thinks SIP and SIP app servers for the service piece. Because SIP app servers play directly with the signaling stream, they are doomed to live in the walled garden, and we all know where that leads.
But IMS also incorporates the Parlay/OSA specifications (though there are many who seem almost willfully to forget that), part of which are the Parlay X Web Services for such things as call control, messaging, and location. It is those IMS Web services that are being offered by at least a few carriers. Parlay X in its current form may not offer everything people want, but it is growing steadily and its developers welcome input (and volunteers to do the heavy lifting of fleshing out good ideas).
Another advantage of Parlay and Parlay X is that they can be targeted at IMS, AIN, GSM, whatever, just as the Standard C Libraries have been ported to UNIX, Windows, Mac, and many other platforms. To the extent the Parlay APIs and Web services can be mapped onto a specific protocol, your code can be leveraged across multiple networks. To carry the C Library analogy further, even as the underlying hardware architectures changed dramatically, the libraries themselves stayed the same (from a programmer's point of view). I've got C programs I wrote for DEC hardware in the 80s that I can still run on Windows XP, MacOS X, Linux, you name it today. In the same way, Parlay and Parlay X apps needn't be discarded when new protocols are inevitably introduced to address the shortcomings of what we have now because Parlay and Parlay X can be targeted at these. Much better than writing a SIP-specific app that you have to throw away when the next generation of engineers eager to make their mark on the work takes a look at SIP (or whatever), decides "We can do better than that," and designs RSIP (Rational SIP).
That said, I do have criticisms of certain aspects of Parlay, many of them aesthetic. But at least the core idea is right and if followed through on, especially if operators open up Parlay X interfaces to wide audiences, they might be pleasantly surprised at what it could do to their bottom line and the huge number of niche services, even manifestly silly ones, they'd find springing up in their network Petri dishes.
Posted by: at January 26, 2006 09:02 PM