Seeing as every other mobile analyst & blogger has been pontificating about the iPhone, I might as well add my opinion as well.
1) Yes, it's very cool
2) Apple seems to have done a great job getting AT&T to agree to its own private activation & application strategy
3) Apple fans will love obviously it
4) Fashionistas will love it for about 3.5 weeks and then move onto the next shiny thing
5) Nearly everyone who buys one will probably use a second device, probably a "boringphone"
6) The US mobile market may be galvanised by Apple's "game-changing" approach
7) SMS will be a pain with the touchscreen
8) Success in Europe & Asia is dependent on iPhone v2 and v3
9) If it launches in current form in Europe, it stacks up badly feature-for-feature against its high-end peers (camera, no 3G or GPS etc)
10) Distribution in Europe is still up for grabs. Voda might make sense, given it's professed desire for better PC/mobile integration - the iPhone looks classleading in that respect
11) It damn expensive, especially on a 2-year (!) contract
12) Enterprise users - only if bought for personal use & then used for work. Forget about corporate email support and especially VoWLAN / FMC for at least 12 months
13) OK OK OK I was wrong when I guess that Apple wouldn't put music in it. I'd thought they'd want to sell you a phone AND an musicplayer, but they've succumbed to the convergence hype.... (wrong move Steve - the future's about lots of devices & multiplicity)
Bottom line: I'd say it'll be a winner in the US, do OK in Europe - but that I'm waiting for Apple's 2nd move to see if it's actually got a real strategy rather than just a pretty product.
And me? I wouldn't swap my main, personal, SonyEricsson K800i for an iPhone as I like the 3MP camera with a flash, and the ultra-quick UI. But I would use it as my 2nd/3rd/phone if it offered a better email/Internet experience (and maybe 'content' although personally I think video isn't of use to me)
Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event
Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here
Friday, June 29, 2007
OMTP handset VoIP settings requirements - pretty sensible
The OMTP have issued their requirements document for VoIP settings on subsidised mobile phones. I talked through it the other day with them - in general, it seems to make a good amount of sense.
In general, I have sympathy with the notion that if a phone is subsidised, then within reason the company offering the subsidy has some authority to tell the user how they can use it. In a truly competitive market, the user should be able to choose between various subsidised-but restricted combinations, or standalone unsubsidised-but-flexible ones.
The general thrust of the OMTP's recommendations is around those phones which are (a) subsidised, and (b) come with a pre-installed 'native' VoIP client.
Basically, if the phone comes with native VoIP, it should be able to have the operator's own VoIP service settings installed and 'locked'. It should also be unlockable after the contract expires, and critically, it should also be possible to load in 3rd party VoIP clients & settings, as long as they work alongside the operator's.
At present, 3rd-party VoIP vendors have 2 main options:
In general, I have sympathy with the notion that if a phone is subsidised, then within reason the company offering the subsidy has some authority to tell the user how they can use it. In a truly competitive market, the user should be able to choose between various subsidised-but restricted combinations, or standalone unsubsidised-but-flexible ones.
The general thrust of the OMTP's recommendations is around those phones which are (a) subsidised, and (b) come with a pre-installed 'native' VoIP client.
Basically, if the phone comes with native VoIP, it should be able to have the operator's own VoIP service settings installed and 'locked'. It should also be unlockable after the contract expires, and critically, it should also be possible to load in 3rd party VoIP clients & settings, as long as they work alongside the operator's.
At present, 3rd-party VoIP vendors have 2 main options:
- Use the native VoIP app (which is usually well-integrated with phonebook, messaging etc) and use it with new settings and a new "upper layer" (eg Truphone)
- Ignore the native VoIP app and do everything from scratch (eg Fring)
With OMTP's stipulations, Option 1 becomes more difficult for a subsidised phone in-contract. That said, there's nothing to stop the handset vendor pre-loading two identical VoIP clients, or having one added on a memory card or downloadable when connected to a PC. Then VoIP#1 can have operator settings locked, but VoIP#2 could be open to all.
Other good stuff in the document:
- Basically, the settings-lock is similar to SIM-locking. It's intended to combat the risk of 100 operators locking phones in 100 different ways. Instead the idea is that they're all locked in a consistent fashion - which helps everyone. With this, there's absolutely no question of locking down the SIP stack outright, for instance.
- An enterprise should (in theory) be able to install its own VoIP applications and have them locked - essentially acting like an operator. So if Acme Inc goes out and installs dual-mode VoWLAN clients from Cisco, Avaya, Divitas or whoever, then John the Salesman shouldn't be able to muck around with the settings if he wants to play around with Skype or whatever on his company phone. Mind you, exactly how this is done is another matter - I was with Cisco's VoIP guys yesterday, and nobody had bothered to tell them that this type of option was going to be enabled, or how it might be achieved....
Wednesday, June 27, 2007
Netgear + Ubiquisys : necessary but not sufficient for femtocells
Good to see one of the first concrete signs of integrating femtocells with broadband routers. There will be some markets in which the mobile operators also have fixed/broadband sister companies or partners, so they can hope to offer an integrated device in the future.
However.... I really don't buy the idea of a single service provider for multi-person households for broadband+mobile. In a family you may find that each family member is on a different contract phasing, so you can't migrate everyone to a single operator. One adult may have a company-provided phone. Little Johnny might want a specific handset on a particular MVNO. Any or all of the family members might have 2 or 3 separate mobile devices or service providers.
Add to this the legacy issues - most homes already have a broadband provider, quite possibly with either an integrated WiFi capability or separate AP. Not many people churn broadband provider - it's particularly a pain if you've got ISP-named email accounts - or, in the future, IPTV or other services locking consumers in. Not many people are keen on throwing away their existing WiFi box for fear of having to set up all their device configurations anew.
Bottom line is that "one box" households are implausible, especially for the more valuable customer segments. Until there's a good way to link up, configure & manage multiple APs, routers, femtocells - as well as integrate them into single units - the market won't grow.
More specifically on the Netgear announcement - available for testing Q4 2007 for commercial deployment early 2008? Not a chance. Expect at least 9-12 months of large-scale testing, both technical (eg what happens if you have 1000 femtos in a square mile?), and commercial/user testing (price, packaging, setup, support etc). Probably add in another 12 months to optimise billing systems and handsets. Mid-2009 maybe, assuming everything's going well.
Like the representatives of Netgear & Ubiquisys, I too will also be speaking at the International Conference on Home Access Points and Femtocells, taking place in London from July 3-5
However.... I really don't buy the idea of a single service provider for multi-person households for broadband+mobile. In a family you may find that each family member is on a different contract phasing, so you can't migrate everyone to a single operator. One adult may have a company-provided phone. Little Johnny might want a specific handset on a particular MVNO. Any or all of the family members might have 2 or 3 separate mobile devices or service providers.
Add to this the legacy issues - most homes already have a broadband provider, quite possibly with either an integrated WiFi capability or separate AP. Not many people churn broadband provider - it's particularly a pain if you've got ISP-named email accounts - or, in the future, IPTV or other services locking consumers in. Not many people are keen on throwing away their existing WiFi box for fear of having to set up all their device configurations anew.
Bottom line is that "one box" households are implausible, especially for the more valuable customer segments. Until there's a good way to link up, configure & manage multiple APs, routers, femtocells - as well as integrate them into single units - the market won't grow.
More specifically on the Netgear announcement - available for testing Q4 2007 for commercial deployment early 2008? Not a chance. Expect at least 9-12 months of large-scale testing, both technical (eg what happens if you have 1000 femtos in a square mile?), and commercial/user testing (price, packaging, setup, support etc). Probably add in another 12 months to optimise billing systems and handsets. Mid-2009 maybe, assuming everything's going well.
Like the representatives of Netgear & Ubiquisys, I too will also be speaking at the International Conference on Home Access Points and Femtocells, taking place in London from July 3-5
T-Mobile launches UMA US-wide... and another launch as well
I see that T-Mo has finally launched its UMA service nationwide in the US, just 17 months after announcing it. It has a huge range of 2 fairly basic [VGA camera?!] phones from Nokia & Samsung, although from one of the comments on Engadget suggests that other phones [Curve? and Pearl 2 - presumably a BlackBerry] are rumoured to be on the way.
Interestingly there's also a comment that Cincinnati Bell has also launched UMA, which appears indeed to be true - although the poster is rather less than effusive.
Interestingly there's also a comment that Cincinnati Bell has also launched UMA, which appears indeed to be true - although the poster is rather less than effusive.
Monday, June 25, 2007
WiFi in the Baltics - showing how it's done properly
A few days ago Martin Geddes wrote this piece about his experience of WiFi in Lithuania's capital Vilnius.
By coincidence, I'm currently sitting in a cafe in its neighbouring capital of Riga in Latvia. I ordered a very good cup of coffee for about £1.70, along with a one-hour WiFi prepaid card from Lattelecom for £1. The waitress, who knew exactly what WiFi was, brought the card to my table and added it to my bill. Username & password are a user-friendly 6 characters long, the login process equally simple.
My hotel last night also had a Lattelecom hotspot covering both public areas & rooms. Again, a very simple, memorable, hotel-wide login, with the cost covered by my room price.
I'll guess that in both cases, the cafe & hotel use Lattelecom's broadband services, and get provided with WiFi by default.
This is how public WiFi should be done. Take note, price-gougers at Swisscom Eurospot & peers.
By coincidence, I'm currently sitting in a cafe in its neighbouring capital of Riga in Latvia. I ordered a very good cup of coffee for about £1.70, along with a one-hour WiFi prepaid card from Lattelecom for £1. The waitress, who knew exactly what WiFi was, brought the card to my table and added it to my bill. Username & password are a user-friendly 6 characters long, the login process equally simple.
My hotel last night also had a Lattelecom hotspot covering both public areas & rooms. Again, a very simple, memorable, hotel-wide login, with the cost covered by my room price.
I'll guess that in both cases, the cafe & hotel use Lattelecom's broadband services, and get provided with WiFi by default.
This is how public WiFi should be done. Take note, price-gougers at Swisscom Eurospot & peers.
Thursday, June 21, 2007
AT&T video sharing. Not new, and what's the point anyway?
There have been various IMS/almost-IMS video sharing trials and deployments over the past 18 months. Nokia's one with CSL in Hong Kong was an early example.
So quite why AT&T thinks it's somehow special is beyond me. Almost as far beyond me as why anyone else thinks that video sharing (or "see what I see" as some wince-inducing marketing people put it) satisfies any consumer needs whatsoever.
Leaving aside the fact that it doesn't work across networks, or on any but a handul of phones, or that people who are walking or driving can't watch inbound video, let's think about the practicalities.
1) I see something cool/interesting.
2) I call you up "Hey, I'm watching something cool/interesting, check this out!"
2b) 97% of the time you're on the wrong network, wrong phone, out of coverage or too busy to watch video
3) Miraculously, you watch what I can see, in realtime, over the network. Awesome!
4) I meet up with 10 other friends in the pub that evening "Hey, I saw something really cool/interesting today!" .... "Wow dude, did you record it?".... "Errrr. No. I expensively sent it to Eric in realtime, so I can't show it to you guys. Or upload it to Youtube. Or email it to my aunt. Damn".
And yes, I know the hypothetical scenarios of a business traveller being called by their spouse to see what their little child is up to. Given point (2b) above, this will only work on a call at a pre-scheduled time. When you might as well stick the little blighter in front of a PC & webcam and do it for free via Yahoo or Skype....
It's a solution looking for a problem.
So quite why AT&T thinks it's somehow special is beyond me. Almost as far beyond me as why anyone else thinks that video sharing (or "see what I see" as some wince-inducing marketing people put it) satisfies any consumer needs whatsoever.
Leaving aside the fact that it doesn't work across networks, or on any but a handul of phones, or that people who are walking or driving can't watch inbound video, let's think about the practicalities.
1) I see something cool/interesting.
2) I call you up "Hey, I'm watching something cool/interesting, check this out!"
2b) 97% of the time you're on the wrong network, wrong phone, out of coverage or too busy to watch video
3) Miraculously, you watch what I can see, in realtime, over the network. Awesome!
4) I meet up with 10 other friends in the pub that evening "Hey, I saw something really cool/interesting today!" .... "Wow dude, did you record it?".... "Errrr. No. I expensively sent it to Eric in realtime, so I can't show it to you guys. Or upload it to Youtube. Or email it to my aunt. Damn".
And yes, I know the hypothetical scenarios of a business traveller being called by their spouse to see what their little child is up to. Given point (2b) above, this will only work on a call at a pre-scheduled time. When you might as well stick the little blighter in front of a PC & webcam and do it for free via Yahoo or Skype....
It's a solution looking for a problem.
Wednesday, June 20, 2007
Thanks, Jonny, much appreciated
I'm feeling a little self-congratulatory this morning, having been ranked #11 in Technobabble 2.0's analyst bloggers table, (and, it seems, the highest-placed wireless analyst) courtesy of Jonny Bentwood at Edelman.
Thinking about it, though, I feel a little bit uneasy too, as I don't really identify myself as a "blogger" as such. I write here for a few reasons - it gives me a chance to put an analytical stake in the ground on topics I'm opinionated about, but that I won't get a chance to write up in a full report. I often find writing posts a good way to crystallise my thoughts on various topics. And quite frankly it generates a significant amount of business from both new and existing clients, which means I can justify the time quite easily. Plus I often learn a lot from the comments on my posts.
But I eschew much of the trendier blogging tools and "furniture". I can't be bothered with things like Digg or del.icio.us or tag clouds, I'm using a boring off-the-shelf Blogger template, and I'm terrible about updating basic things like external links. I've never looked at the Technorati site until today, so I don't even know what the significance of Jonny's use of it in his ranking is. I'm not even that bothered about publicising the blog to widely - my perception is that it has a smallish but self-selected group of "the right people" reading it.
So maybe I should use this opportunity to ask for some feedback: does anyone actually care that about all those cool up-to-the-minute blogosphere features? Could I make the blog easier to use? Or is it just "all about the content" and it's fine the way it is?
Thinking about it, though, I feel a little bit uneasy too, as I don't really identify myself as a "blogger" as such. I write here for a few reasons - it gives me a chance to put an analytical stake in the ground on topics I'm opinionated about, but that I won't get a chance to write up in a full report. I often find writing posts a good way to crystallise my thoughts on various topics. And quite frankly it generates a significant amount of business from both new and existing clients, which means I can justify the time quite easily. Plus I often learn a lot from the comments on my posts.
But I eschew much of the trendier blogging tools and "furniture". I can't be bothered with things like Digg or del.icio.us or tag clouds, I'm using a boring off-the-shelf Blogger template, and I'm terrible about updating basic things like external links. I've never looked at the Technorati site until today, so I don't even know what the significance of Jonny's use of it in his ranking is. I'm not even that bothered about publicising the blog to widely - my perception is that it has a smallish but self-selected group of "the right people" reading it.
So maybe I should use this opportunity to ask for some feedback: does anyone actually care that about all those cool up-to-the-minute blogosphere features? Could I make the blog easier to use? Or is it just "all about the content" and it's fine the way it is?
Tuesday, June 19, 2007
Truphone and T-Mobile Interconnect - I see the argument, but they are both on thin ice here
The ongoing spat between T-Mobile and Truphone about interconnecting between VoIP and circuit-switched mobile is an interesting one. (See Truphone's side of the argument here)
In a nutshell -Truphone has managed to persuade the UK regulator to issue it with mobile numbers (07xxx) although it doesn't own/operate a cellular network. It argues that the increasing practicality & ubiquity of VoWLAN enables it to offer a "mobile telephony" service without a conventional mobile network.
The problem is that while this decision gives Truphone some unarguably reasonable things (a mobile number - ie the primary one that people tend to save in address books, and use for things like SMS), it also comes with some less-reasonable elements. In particular, as termination fees for calls to mobile phones are supposedly cost-based, it's unreasonable to expect the inbound operator to receive the same money for terminating on (cheaper) WiFi than on a cellular network. Thus T-Mobile resents paying the same to terminate calls on a Truphone number as it does on Vodafone or Orange numbers. It appears to be using a recent Ofcom ruling on mobile interconnect rates that contains the phrase "for connecting calls on their mobile networks".
I've written before about the likely complexities of numbering & interconnect in an FMC world. Given that there are plenty of VoWLAN providers that operate software on handsets, I'm not convinced that there should be any difference between those that manage to argue their way to an 07xxx number range, versus the others.
So at one level I can sort of see T-Mobile's point - and I can also see Truphone's point that T-Mo appears to be acting in a unilateral, heavy-handed fashion. And so this wouldn't be quite so much of a problem if it was just that Truphone didn't get full-whack interconnect fees for VoWLAN termination, but just the measly 0.21p per minute that T-Mo has reportedly offered. The real problem is that in some cases, Truphone incurs a lot more costs by forwarding the call to the user's "underlying" GSM number on the same phone when it's out of WiFi coverage. This is expensive, and therefore all forwarded calls cost Truphone much more than it gets out of T-Mo to begin with (" even when Truphone's costs are 9p per minute to terminate the call"). Mind you - that's actually terminating the call on someone else's mobile network, not Truphone's , so it's still not cut & dried.
But I reckon T-Mobile is in serious danger of painting itself into a corner on this, unless it is hoping to prompt a much wider review of FMC and wVoIP interconnect.
In order not to appear hypocritical, T-Mobile will also have to refuse to pay full-rate interconnect fees for BT Fusion or Orange Unik (or, er, T-Mobile US' UMA service) when they're in WiFi coverage, as that's also much cheaper to complete calls. Or to any of the mobile operators looking to extend their brand & number range out to PC-based VoIP clients.
And in response, any fixed operator would be well within their rights to refuse to pay mobile termination fees to T-Mobile for the privilege of completing those calls which divert to a voicemail server (again, cheap), rather than connecting to an actual end user over the cellular network.
And T-Mobile is also therefore implicitly staking a claim to only 0.21p per minute interconnect, when it transitions its cellular network to all-IP LTE, presumably around 2011. That will have to use VoIP, as circuit-switched telephony isn't supported. Put that date in your diaries, interconnect managers at Vodafone, Orange, O2 & 3 - as soon as it starts to support VoIPo3G, feel free to slash your payments. They've made their bed; let them lie in it.
Basically, T-Mobile's short-term hissy fit (although in some ways understandable) has long term ramifications. Up until now, everyone had operated on the unspoken principle of "mutually assured destruction" about the real complexities of interconnect and termination in an IP world. We had a standoff, with all players knowing that calling-party-pays, mobile vs fixed numbering, and VoIP interconnect were likely casualties of the fallout.
T-Mobile UK has just pressed the big red button withoiut thinking of the longer-term issues.
In a nutshell -Truphone has managed to persuade the UK regulator to issue it with mobile numbers (07xxx) although it doesn't own/operate a cellular network. It argues that the increasing practicality & ubiquity of VoWLAN enables it to offer a "mobile telephony" service without a conventional mobile network.
The problem is that while this decision gives Truphone some unarguably reasonable things (a mobile number - ie the primary one that people tend to save in address books, and use for things like SMS), it also comes with some less-reasonable elements. In particular, as termination fees for calls to mobile phones are supposedly cost-based, it's unreasonable to expect the inbound operator to receive the same money for terminating on (cheaper) WiFi than on a cellular network. Thus T-Mobile resents paying the same to terminate calls on a Truphone number as it does on Vodafone or Orange numbers. It appears to be using a recent Ofcom ruling on mobile interconnect rates that contains the phrase "for connecting calls on their mobile networks".
I've written before about the likely complexities of numbering & interconnect in an FMC world. Given that there are plenty of VoWLAN providers that operate software on handsets, I'm not convinced that there should be any difference between those that manage to argue their way to an 07xxx number range, versus the others.
So at one level I can sort of see T-Mobile's point - and I can also see Truphone's point that T-Mo appears to be acting in a unilateral, heavy-handed fashion. And so this wouldn't be quite so much of a problem if it was just that Truphone didn't get full-whack interconnect fees for VoWLAN termination, but just the measly 0.21p per minute that T-Mo has reportedly offered. The real problem is that in some cases, Truphone incurs a lot more costs by forwarding the call to the user's "underlying" GSM number on the same phone when it's out of WiFi coverage. This is expensive, and therefore all forwarded calls cost Truphone much more than it gets out of T-Mo to begin with (" even when Truphone's costs are 9p per minute to terminate the call"). Mind you - that's actually terminating the call on someone else's mobile network, not Truphone's , so it's still not cut & dried.
But I reckon T-Mobile is in serious danger of painting itself into a corner on this, unless it is hoping to prompt a much wider review of FMC and wVoIP interconnect.
In order not to appear hypocritical, T-Mobile will also have to refuse to pay full-rate interconnect fees for BT Fusion or Orange Unik (or, er, T-Mobile US' UMA service) when they're in WiFi coverage, as that's also much cheaper to complete calls. Or to any of the mobile operators looking to extend their brand & number range out to PC-based VoIP clients.
And in response, any fixed operator would be well within their rights to refuse to pay mobile termination fees to T-Mobile for the privilege of completing those calls which divert to a voicemail server (again, cheap), rather than connecting to an actual end user over the cellular network.
And T-Mobile is also therefore implicitly staking a claim to only 0.21p per minute interconnect, when it transitions its cellular network to all-IP LTE, presumably around 2011. That will have to use VoIP, as circuit-switched telephony isn't supported. Put that date in your diaries, interconnect managers at Vodafone, Orange, O2 & 3 - as soon as it starts to support VoIPo3G, feel free to slash your payments. They've made their bed; let them lie in it.
Basically, T-Mobile's short-term hissy fit (although in some ways understandable) has long term ramifications. Up until now, everyone had operated on the unspoken principle of "mutually assured destruction" about the real complexities of interconnect and termination in an IP world. We had a standoff, with all players knowing that calling-party-pays, mobile vs fixed numbering, and VoIP interconnect were likely casualties of the fallout.
T-Mobile UK has just pressed the big red button withoiut thinking of the longer-term issues.
Thursday, June 14, 2007
OMTP IMS requirements - killing the "bearer agnostic" myth
I got a chance to wade through the OMTP's new IMS handset requirements document in full, on a flight yesterday. There's some good stuff - and some less good stuff in there.
Best of all is that it wants to make handset applications "bearer aware". I've been banging on about this for as long as I can remember. The notion that advanced handset apps on highly-intelligent devices should be ignorant of what network is being used as transport is ludicrous.
I've argued passionately & at length about why applications should behave differently over cellular and over WiFi, for example, because of different bandwidths, latencies, contexts, ownership, cost, security and so on.
I know that some handset ecosystem participants (eg Symbian) are already up-to-speed on this, and that some operators (eg BT) have also been ahead of the curve. So it's nice to see OMTP spell all this out in black and white as a standard requirement:
"IMS-1160 The UE MUST provide an API to allow an application to request the list of all available radio access technologies supported by the UE (e.g. WiFi, EDGE, UMTS, GPRS, etc)"
"IMS-1180 The UE MUST offer an API to allow an application to choose the bearer (from the list provided in IMS-1160) for a media connection subject to Bearer Policy."
I've given a lot of thought to the possible use cases of this type of capability, and it should significantly improve user experience.
(Incidentally - the "less good" stuff in the document? How much time & money is going to be wasted on implementing & testing the useless PoC capabilities of future phones? Why couldn't the OMTP have just killed that stone dead? Also... no mention of how to deal with multitasking-capable phones)
Best of all is that it wants to make handset applications "bearer aware". I've been banging on about this for as long as I can remember. The notion that advanced handset apps on highly-intelligent devices should be ignorant of what network is being used as transport is ludicrous.
I've argued passionately & at length about why applications should behave differently over cellular and over WiFi, for example, because of different bandwidths, latencies, contexts, ownership, cost, security and so on.
I know that some handset ecosystem participants (eg Symbian) are already up-to-speed on this, and that some operators (eg BT) have also been ahead of the curve. So it's nice to see OMTP spell all this out in black and white as a standard requirement:
"IMS-1160 The UE MUST provide an API to allow an application to request the list of all available radio access technologies supported by the UE (e.g. WiFi, EDGE, UMTS, GPRS, etc)"
"IMS-1180 The UE MUST offer an API to allow an application to choose the bearer (from the list provided in IMS-1160) for a media connection subject to Bearer Policy."
I've given a lot of thought to the possible use cases of this type of capability, and it should significantly improve user experience.
(Incidentally - the "less good" stuff in the document? How much time & money is going to be wasted on implementing & testing the useless PoC capabilities of future phones? Why couldn't the OMTP have just killed that stone dead? Also... no mention of how to deal with multitasking-capable phones)
Wednesday, June 13, 2007
Finally, some standardisation for IMS handsets
Almost exactly a year ago, I published a report on the severe problems involved in getting IMS-capable mobile phones to market. At the time, I'd been tracking the area for around 18 months - it was blindingly obvious that the 3GPP and other standards bodies had effectively abdicated all responsibility for actually making sure IMS actually worked on handsets in the hands of the user. Yes, the basic plumbing like SIP signalling was standardised. But there were dozens of companies trying to develop their own, proprietary software and UI frameworks for IMS, usually with a bunch of in-house applications.
The standards had been driven largely by network infrastructure people, who had simply assumed that phones would "naturally follow" and would have a user interfaces "defined by the market". That might have been true in the early days of GSM, when handset software was confined to a dialler and phonebooks, but is woefully inadequate today, where phones OS, application and UI software runs to millions of lines of code, with a high % of the pain of any handset development project related to software integration and testing.
It was clearly a poor situation for most operators, handset OEMs and application/service developers, and has contributed to the dearth of serious IMS rollout in the mobile industry. What was supposed to be a cellular core IP technology has instead been adopted more quickly in the fixed-VoIP and even WiMAX sectors.
So yesterday's announcement by the OMTP (a group of operators that try and harmonise handset user interface requirements) that they have finally published a requirements document for IMS-capable handsets is very welcome, but about 3 years overdue. To be fair to the OMTP, they recognise that the standardisation process has been lacking "In its current form the IMS proposition fails to sufficiently address these four key areas and falls short of the full end-to-end experience that is required".
I haven't had a chance to read the full spec yet, but I spoke to the OMTP recently and it certainly seems as though they've tackled some of the main deficiencies, although I suspect that there will need to be a couple of subsequent iterations before the IMS on-handset experience is truly integrated with all the other non-IMS functions of the phone.
As the organisation is specifically about phones, it also doesn't address the issue of IMS application development and distribution. For me, one of the worst things about IMS is that it doesn't support the type of broad innovation and ultrarapid, viral, cross-network uptake that drives the Internet / Web 2.0 world. A small startup in Santa Clara or Bangalore cannot develop a cool IMS app, "put it out there" in beta form, and have 10m people around the world download it and forward a link to their friends (irrespective of their operator) by next Wednesday.
Incidentally, for those readers new to the OMTP, you might be interested to check out the list of work items here. Especially the one innocuously called "Multipath Routing", which is actually about controlling VoIP clients on handsets, and which includes the rather unambiguous objective to "ensure that terminal platforms have the capability to offer mobile operators the opportunity to uphold current business practise". Supposedly, this will only apply to subsidised handsets though.
Lastly... a word of advice to OMTP. Rename yourself OMDP or OMHP (Device, or Handset). The word "terminal" ought to be expunged from the mobile industry - it's exactly why things like IMS are in the troubled state we have here. People from the network side still routinely ignore the fact that millions of handsets with 200MHz-1GHz processors now constitute the overwhelming proportion of intelligence in the mobile ecosystem. "Terminal" comes from a centralised, 1970s mainframe/green-screen view of the world. Wake up and listen to Moore's Law.
The standards had been driven largely by network infrastructure people, who had simply assumed that phones would "naturally follow" and would have a user interfaces "defined by the market". That might have been true in the early days of GSM, when handset software was confined to a dialler and phonebooks, but is woefully inadequate today, where phones OS, application and UI software runs to millions of lines of code, with a high % of the pain of any handset development project related to software integration and testing.
It was clearly a poor situation for most operators, handset OEMs and application/service developers, and has contributed to the dearth of serious IMS rollout in the mobile industry. What was supposed to be a cellular core IP technology has instead been adopted more quickly in the fixed-VoIP and even WiMAX sectors.
So yesterday's announcement by the OMTP (a group of operators that try and harmonise handset user interface requirements) that they have finally published a requirements document for IMS-capable handsets is very welcome, but about 3 years overdue. To be fair to the OMTP, they recognise that the standardisation process has been lacking "In its current form the IMS proposition fails to sufficiently address these four key areas and falls short of the full end-to-end experience that is required".
I haven't had a chance to read the full spec yet, but I spoke to the OMTP recently and it certainly seems as though they've tackled some of the main deficiencies, although I suspect that there will need to be a couple of subsequent iterations before the IMS on-handset experience is truly integrated with all the other non-IMS functions of the phone.
As the organisation is specifically about phones, it also doesn't address the issue of IMS application development and distribution. For me, one of the worst things about IMS is that it doesn't support the type of broad innovation and ultrarapid, viral, cross-network uptake that drives the Internet / Web 2.0 world. A small startup in Santa Clara or Bangalore cannot develop a cool IMS app, "put it out there" in beta form, and have 10m people around the world download it and forward a link to their friends (irrespective of their operator) by next Wednesday.
Incidentally, for those readers new to the OMTP, you might be interested to check out the list of work items here. Especially the one innocuously called "Multipath Routing", which is actually about controlling VoIP clients on handsets, and which includes the rather unambiguous objective to "ensure that terminal platforms have the capability to offer mobile operators the opportunity to uphold current business practise". Supposedly, this will only apply to subsidised handsets though.
Lastly... a word of advice to OMTP. Rename yourself OMDP or OMHP (Device, or Handset). The word "terminal" ought to be expunged from the mobile industry - it's exactly why things like IMS are in the troubled state we have here. People from the network side still routinely ignore the fact that millions of handsets with 200MHz-1GHz processors now constitute the overwhelming proportion of intelligence in the mobile ecosystem. "Terminal" comes from a centralised, 1970s mainframe/green-screen view of the world. Wake up and listen to Moore's Law.
Wednesday, June 06, 2007
Operators will have to be open about usage policies - and enforcement
I've written before about the differing policies that mobile operators are employing with regard to their 3G flatrate and other data services. There are widely varying monthly caps - in the UK, Voda's new one is 120MB, in contrast to Orange's measly 30MB and T-Mobile's generous 1GB. Some are permitting VoIP, others prohibit it, some charge more. The whole N95 saga has illustrated just how different certain operators' phones are, even when they're notionally the same model.
Many operators also use forms of traffic shaping, packet inspection and other stuff in the data path, usually hidden to the end user. There's an assumption that this might also throttle download speeds, interfere with specific applications (P2P, VoIP etc). It certainly happens in the fixed-broadband world.
The interesting thing is that by and large, disclosure is poor. Operators will often deny that they're doing anything, or else customer service staff will not have been given adequate information by the technical guys.
I'm predicting that the skulduggery will have to stop.
Operators will need to be upfront about what their usage terms are (in plain English) as comparisons become more readily available. Unless they get exclusives, operators are also likely to need to compete on how their version of customers' chosen handsets perform. I expect to see comparison charts of features / speed / lock-downs between different carriers' versions of phones and the "vanilla" variants. And, lastly, I expect that operators will need to start to divulge more about their traffic-shaping policy. Otherwise they'll find that other people will reverse-engineer it and do it for them.
Based on a few discussions I've had recently, this is also an area where I expect pressure to be put on regulators or business standards bodies by consumer groups.
Many operators also use forms of traffic shaping, packet inspection and other stuff in the data path, usually hidden to the end user. There's an assumption that this might also throttle download speeds, interfere with specific applications (P2P, VoIP etc). It certainly happens in the fixed-broadband world.
The interesting thing is that by and large, disclosure is poor. Operators will often deny that they're doing anything, or else customer service staff will not have been given adequate information by the technical guys.
I'm predicting that the skulduggery will have to stop.
Operators will need to be upfront about what their usage terms are (in plain English) as comparisons become more readily available. Unless they get exclusives, operators are also likely to need to compete on how their version of customers' chosen handsets perform. I expect to see comparison charts of features / speed / lock-downs between different carriers' versions of phones and the "vanilla" variants. And, lastly, I expect that operators will need to start to divulge more about their traffic-shaping policy. Otherwise they'll find that other people will reverse-engineer it and do it for them.
Based on a few discussions I've had recently, this is also an area where I expect pressure to be put on regulators or business standards bodies by consumer groups.
Tuesday, June 05, 2007
Orange "flat"rate looks a bit mountainous to me
David Meyer at ZDnet has some interesting comments on Orange UK shooting itself in the foot with a supposed "flatrate" tariff at £8 / month which it's capped at 30MB. Which is the same cap that T-Mobile offered about 15 months ago on Web'n'Walk - mostly over 2G devices at the time - for a broadly comparable price.
Funny, I could have sworn the intervening period has had several HSDPA launches, and much faster ramp-up of WCDMA, which vastly reduce the cost-per-MB to deliver Internet access.
30MB is fine for email & some very limited WAP & HTML browsing. I know, as I've got that pre-flatrate Web'n'Walk tariff and 2G device I use for that purpose. But it's not useful for any decent usage of a decent browser on a decent phone with a decent connection - I got hit with substantial over-use charges when I swapped the SIM into a 3G Nokia with a good browser for a month.
I hate to think what the roaming charges are.
Funny, I could have sworn the intervening period has had several HSDPA launches, and much faster ramp-up of WCDMA, which vastly reduce the cost-per-MB to deliver Internet access.
30MB is fine for email & some very limited WAP & HTML browsing. I know, as I've got that pre-flatrate Web'n'Walk tariff and 2G device I use for that purpose. But it's not useful for any decent usage of a decent browser on a decent phone with a decent connection - I got hit with substantial over-use charges when I swapped the SIM into a 3G Nokia with a good browser for a month.
I hate to think what the roaming charges are.
Subscribe to:
Posts (Atom)