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:

• 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"

Apps are in the "new stuff" category - things like triggering reminders or messages, or performing other actions when a user gets home and registers onto their femto. Or perhaps exploiting the differential speed or price of connection on femto vs. macro ("upload this video from my phone via femto, as it's not realtime-urgent"). Undoubtedly there will be a range of more imaginative ones as well - some of the demonstrations at the launch event yesterday demonstrated home control (eg phone=TV remote), or even VoIP softphones enabled directly on the device.

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.