There seems to be a common assumption among mobile broadband operators that when they put bandwidth caps on their offerings, most users will still only exploit a fraction of their allowance.
This is probably just as well, as there are strong signs that the underlying per-GB cost of many HSPA networks stacks up rather poorly against the revenues per-GB if customers do actually use all their allocation. In the UK, 3 is giving away 15GB per month for £15, for example.
At that price, I'm wondering if there's a risk that operators start attracting the "wrong" sort of customers.... for example other operators. OK, it might not be ideal to run GSM voice tunneled over HSPA, but imagine if that 3 dongle (with its 15GB per month) was hooked up to one of Vodafone UK's new femtocells.... not a bad way for Vodafone to improve its backhaul economics, perhaps? Especially where its customer doesn't have an ADSL line.
OK, I'm sure there's some stuff in the terms of service which would prohibit this. But it wouldn't surprise me if some operators unexpectedly become wholesalers of capacity, if they price their retail services too low, in the hope of winning the marketing "who's got the biggest cap" war...
Report: Mobile Broadband Computing
Friday, June 26, 2009
I love the smell of phones in the morning....
Forget about data plans, IM, mobile TV, LTE, two-sided markets, widgets, advertising, ringtones or payments, I've discovered the company with the best way to enhance ARPU and derive more customer loyalty.
OK OK, it's Friday afternoon, but I couldn't pass a chance to make a reference to this company. Ladies and gentlemen, I give you the next stage of mobile handset personalisation: smell.
I'd certainly pay £10 to make my phone smell of Wild Cherries. And I'm sure the crowds at Wimbledon will want their handsets redolent of strawberries and cream. Not so sure about "subtle" or "teen spirit" though.....
OK OK, it's Friday afternoon, but I couldn't pass a chance to make a reference to this company. Ladies and gentlemen, I give you the next stage of mobile handset personalisation: smell.
I'd certainly pay £10 to make my phone smell of Wild Cherries. And I'm sure the crowds at Wimbledon will want their handsets redolent of strawberries and cream. Not so sure about "subtle" or "teen spirit" though.....
Thursday, June 25, 2009
NFC in all phones next year? Dream on....
There's a quote from an Ericsson representative about NFC and RFID-enabled handsets reported here.
Apparently, "A year from now basically every new phone that's sold will have NFC. It's a two-way, bi-directional RFID communication link that makes this device work as a tag or as a reader." [I wasn't there, so I'm assuming the quote is correct]
If someone from Ericsson would like to take a spreadbet with me about NFC uptake in 2010, I'm a seller. I'd like to think I'm a fair man, so I won't hold them to the letter of "basically every" - how about merely about half? What about we say 0.00001p per handset, each way from 500m?
And as for the idea of "enabling the phone to take on other roles, such as the keys for your car or house" that's really not the greatest of concepts, if as currently seems likely, the secure element of NFC is controlled by the operator.
"Oh, I'm sorry that you've decided to churn Mr Bubley. No, unfortunately you can't transfer the key account to another operator. But we have a special deal with a local locksmith, we can use your location API to send him to meet you now if you'd like? But next year, we'll be launching a key portability service, which should work fine with only a 3-day transfer period when you'll be unable to use it"
Apparently, "A year from now basically every new phone that's sold will have NFC. It's a two-way, bi-directional RFID communication link that makes this device work as a tag or as a reader." [I wasn't there, so I'm assuming the quote is correct]
If someone from Ericsson would like to take a spreadbet with me about NFC uptake in 2010, I'm a seller. I'd like to think I'm a fair man, so I won't hold them to the letter of "basically every" - how about merely about half? What about we say 0.00001p per handset, each way from 500m?
And as for the idea of "enabling the phone to take on other roles, such as the keys for your car or house" that's really not the greatest of concepts, if as currently seems likely, the secure element of NFC is controlled by the operator.
"Oh, I'm sorry that you've decided to churn Mr Bubley. No, unfortunately you can't transfer the key account to another operator. But we have a special deal with a local locksmith, we can use your location API to send him to meet you now if you'd like? But next year, we'll be launching a key portability service, which should work fine with only a 3-day transfer period when you'll be unable to use it"
Wednesday, June 24, 2009
Femtocell applications - APIs and platform choice
Yesterday the Femto Forum announced its Services Initiative to help drive both adoption and consistency for femto-based applications.
In general, femto use cases can be categorised in three ways:
The Femto Forum's new special interest group is working on some standard APIs for developers, which I'd definitely say is essential for all but the most important "bespoke" apps for the largest operators.
But in my view it's critical that the femto APIs align with other initatives on devices or in the networks. Realistically, we're only going to get a certain level of femto penetration in any given market.
If you're writing an app for a delivery company, for example, it's unlikely that you'll only want to know when 5% or 17% of your customers get home - you'd like 100%, or at least 50%. So you'll probably want to combine lots of ways of getting that "at home" trigger: femto-based alerts, perhaps browser widgets accessing GPS on phones that have the capability, network-based location APIs, maybe WiFi-based location sensing as well. You'd also want it to work across all operators' femtos in a given country.
In other words, writing a general "tell me when my customers get home" app is likely to involve many different APIs - an iPhone version, one based on GSMA's OneAPI set, perhaps OMTP's BONDI and so on. In some cases, the same user might be identifiable by 3 of these, so there's going to be competition for API mindshare and perceptions of "coolness" by the developers.
Another thing is important for femto applications & APIs - trying to compete head-on with WiFi in the home is a non-starter. I heard lots of excuses about the battery impact of WiFi and complex logons - but frankly that's a story from 2006. How many iPhone users do you know who haven't managed to set up their device to access their home WiFi by now? Or who complain so bitterly about power consumption they've switched the WiFi off? Now, I certainly agree that not all 3G phones have WiFi, and that some of those that do are more tricky to set up than the Apple. But that's not a static situation.
I reckon that really successful femto apps will use some of the unique characteristics - such as the operator's data about you as a subscriber, or its ability to connect you to other services or a payment mechanism. Turning your phone into a remote control for your toaster is equally achievable via WiFi or even Bluetooth - the femto adds no extra value, and may even reduce value if the ToasterMatic app has to be approved by your operator.
(A couple of times yesterday I heard the notion that people would want operator-approved apps for "security" or "reliability" reasons. I'm sorry, but I can't imagine anyone wanting important services for use *in your own home* and *between your own devices & equipment* that's controlled by a third party who charges for the privilege and revokes the capability when you churn. It's like saying you're safer having your PC's printer driver provided by your broadband ISP. There is a role for operator-controlled apps here - but it needs to be implemented intelligently).
I also think that there's a lot of work to be done on handset connection manager software. What happens if you have a multitasking smartphone with both 3G and WiFi - and some apps that are optimised for one network, and some for the other. How do you manage that?
Overall, some definite good stuff. But I think there's a significant amount of work needed to make sure femto apps fit well into the rest of the network/device/app ecosystem.
In general, femto use cases can be categorised in three ways:
- Basic improved indoor coverage (as seen in yesterday's Vodafone announcement)
- Data traffic offload from the macro network, either indoor or in hotspots
- "Cool new stuff"
The Femto Forum's new special interest group is working on some standard APIs for developers, which I'd definitely say is essential for all but the most important "bespoke" apps for the largest operators.
But in my view it's critical that the femto APIs align with other initatives on devices or in the networks. Realistically, we're only going to get a certain level of femto penetration in any given market.
If you're writing an app for a delivery company, for example, it's unlikely that you'll only want to know when 5% or 17% of your customers get home - you'd like 100%, or at least 50%. So you'll probably want to combine lots of ways of getting that "at home" trigger: femto-based alerts, perhaps browser widgets accessing GPS on phones that have the capability, network-based location APIs, maybe WiFi-based location sensing as well. You'd also want it to work across all operators' femtos in a given country.
In other words, writing a general "tell me when my customers get home" app is likely to involve many different APIs - an iPhone version, one based on GSMA's OneAPI set, perhaps OMTP's BONDI and so on. In some cases, the same user might be identifiable by 3 of these, so there's going to be competition for API mindshare and perceptions of "coolness" by the developers.
Another thing is important for femto applications & APIs - trying to compete head-on with WiFi in the home is a non-starter. I heard lots of excuses about the battery impact of WiFi and complex logons - but frankly that's a story from 2006. How many iPhone users do you know who haven't managed to set up their device to access their home WiFi by now? Or who complain so bitterly about power consumption they've switched the WiFi off? Now, I certainly agree that not all 3G phones have WiFi, and that some of those that do are more tricky to set up than the Apple. But that's not a static situation.
I reckon that really successful femto apps will use some of the unique characteristics - such as the operator's data about you as a subscriber, or its ability to connect you to other services or a payment mechanism. Turning your phone into a remote control for your toaster is equally achievable via WiFi or even Bluetooth - the femto adds no extra value, and may even reduce value if the ToasterMatic app has to be approved by your operator.
(A couple of times yesterday I heard the notion that people would want operator-approved apps for "security" or "reliability" reasons. I'm sorry, but I can't imagine anyone wanting important services for use *in your own home* and *between your own devices & equipment* that's controlled by a third party who charges for the privilege and revokes the capability when you churn. It's like saying you're safer having your PC's printer driver provided by your broadband ISP. There is a role for operator-controlled apps here - but it needs to be implemented intelligently).
I also think that there's a lot of work to be done on handset connection manager software. What happens if you have a multitasking smartphone with both 3G and WiFi - and some apps that are optimised for one network, and some for the other. How do you manage that?
Overall, some definite good stuff. But I think there's a significant amount of work needed to make sure femto apps fit well into the rest of the network/device/app ecosystem.
Subscribe to:
Posts (Atom)
Posts
