Many thanks to MobileStance, this week's curator of the Carnival roundup of mobile blog posts, for including my IMS/LTE post.
See the rest of the week's articles here
It's been interesting to get some back-channel feedback on the post. I've had a couple of emails along the lines of "Oh no, IMS is alive and well and coming to an operator near you", and quite a few more messages and phone calls amused and agreeing with my sentiments.
Interesting that relatively few people are willing to openly comment on the post itself, though.... it wonder if I will be made to suffer from having broken the "code of silence"....
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
13 comments:
I would be interested to know what the profile is of the kind of people who agree with your stance? My experience is that product marketing and commercial managers still have little idea what IMS is/offers and poo-poo it at every opportunity whereas those in engineering related areas have accepted it with varying degrees of enthusiasm. I don't think it's as simple as the usual tech love of the new (especially as IMS can hardly be described as "new" anymore).
Two groups in particular:
1) Radio access people trying to sell LTE kit, who are keen to justify its viability and saleability to operators who don't want IMS.
Optimising LTE to work best with IMS, is like Fiat mandating that its Ferrari arm optimises a new car to work best with a 2-ton boat anchor, rather than ceramic brakes.
2) Strategists and financial analysts trying to work out any profitable new revenue streams that IMS investment might deliver.
Anonymous,
You should not generalize about who supports IMS and who does not. I am a network design engineer and I think IMS is a huge waste of time and money.
Fair enough Anon, that's your opinion, it's just my experience that the techs get it and the marketing bods (LTE guys aside!) don't. YMMV.
The fixed line IMS business case is sound, for an operator with fixed and mobile looking towards FMC the business case can work but it's tough.
Dean's point about LTE & IMS is well made, I don't know what the fuss is about either, I expect it will be a long time before anyone bothers with voice on LTE at all.
> whereas those in engineering related areas have accepted it with varying degrees of enthusiasm.
I am a service developer and I understand IMS. Although I see the logic in the design principals I also believe it is a waste of money.
The service layer of IMS is just to complex to deliver the flexibility needed to be competitive to Internet services.
Anon: "I am a service developer and I understand IMS. Although I see the logic in the design principals I also believe it is a waste of money."
A waste of money for what reasons? the fixed line IMS business case is easy to make (i.e. not a waste of money).
Anon: "The service layer of IMS is just to complex to deliver the flexibility needed to be competitive to Internet services."
I disagree, there are numerous service delivery platform options for IMS with developer-friendly SDEs. I agree that internet services are more flexible and innovative but it does not follow that IMS services can't be competitive.
Anon said: I disagree, there are numerous service delivery platform options for IMS with developer-friendly SDEs.
Yes there are. The problem is not the tooling. Part of the problem is SIP.
SIP has been transformed from a simple protocol for setting up sessions to become some sort of super multi purpose protocol.
SIP was never designed to be used in the use cases operators want to achieve with IMS. SIP has become a weakly specced protocol open to the interpretation of developers, hence all the efforts that are needed to make IMS services interoperable.
"Yes there are. The problem is not the tooling. Part of the problem is SIP."
Interesting article you link to about SIP interop, I wouldn't disagree with any of that. However - a couple of things - the whole point of a SCE is that it shields the developer from needing to know what's going on with SIP i.e. you expect the interop to have been completed prior to handing over the SCE.
3GPP IMS SIP is far more tightly controlled than pure 3261 and the IMS interop plugfests seem to have gone well.
"SIP was never designed to be used in the use cases operators want to achieve with IMS."
This is not the case, it was designed with such extensibility from the beginning (see RFC2543).
Thanks for your response.
I have to admit, you are right (to a certain extend :-) in both cases.
3GPP IMS SIP is far more tightly controlled than pure 3261 and the IMS interop plugfests seem to have gone well.
This is not the case, it was designed with such extensibility from the beginning (see RFC2543).
This is both true for call related cases. I would say for handling media sessions only SIP is good way to go. At least it was designed with this in mind. The thing with IMS is that it promisses more than handling media sessions only. Presence, for example, there are still issues that due to the fact that SIP was never designed with the requirements of presence in mind. I fully support Dean's statement that not everything in human communication can be caught into a 'session'.
When using SIP only for call control an operator could just go for any (open source) SIP server instead of deploying a full IMS.
About your statement on SCE: I do not know what SCE means but I assume it is programming environment for SIP services?
Developers of core services (like presence) have to know SIP. I have experience with a couple of SIP SDKs and as a developer you still need to program the values of SIP headers. So the SDKs are not shielding this for the developer completely IMO.
Anon: "I fully support Dean's statement that not everything in human communication can be caught into a 'session'."
I agree too, however it does not necessarily follow that IMS as a whole is a failure because it cannot address every aspect of communication.
Anon: "When using SIP only for call control an operator could just go for any (open source) SIP server instead of deploying a full IMS. "
Sorry, I'm a huge fan of Open Source Software but this is not a realistic option for any large operator.
Anon:"About your statement on SCE: I do not know what SCE means but I assume it is programming environment for SIP services?"
SCE: Service Creation Environment.
Anon: "Developers of core services (like presence) have to know SIP. I have experience with a couple of SIP SDKs and as a developer you still need to program the values of SIP headers. So the SDKs are not shielding this for the developer completely IMO."
You are correct, but in general, when considering application development one is not looking at building core services but ancilliary services that build upon that core. This is where a SCE comes in that can abstract all this lower level stuff so that developers don't have to worry about it.
Anon: "I fully support Dean's statement that not everything in human communication can be caught into a 'session'."
Anon2: I agree too, however it does not necessarily follow that IMS as a whole is a failure because it cannot address every aspect of communication.
The risk that I see is that value (ie what customers want to do, and what makes them "loyal") moves predominantly to non-SIP applications and services.
At that point, it makes no sense to have the main control or charging mechanisms of the network based on "minority" applications.
It would be like an airport using Cargo tariffs, routes & loading mechanisms for passengers as well. An airline *could* price human flights per kilo of weight, and bunch people into aluminium containers, but it's unlikely to be a commercial success.
DB: "The risk that I see is that value (ie what customers want to do, and what makes them "loyal") moves predominantly to non-SIP applications and services."
This I think, is the core of your argument against IMS. I disagree strongly that customers will move predominantly to non-IMS service in future, I guess we will have to wait and see for sure though!
DB: "It would be like an airport using Cargo tariffs, routes & loading mechanisms for passengers as well. An airline *could* price human flights per kilo of weight, and bunch people into aluminium containers, but it's unlikely to be a commercial success."
Ryanair called, they want their business plan back.
I see quite some resemblance between IMS and TICA-C. Both are scientifically well thought trough, in theory everything is great. But is this the platform that service developers are waiting for? I don't think so.
Why is it that the Telco industry believes it knows what users and service developers want or need?
Post a Comment