Making handsets bearer-aware or location-aware for FMC

One of the biggest fallacies about IMS (and UMA and some other FMC approaches) is that applications should be "bearer agnostic" - ie work the same irrespective of whether a device is connected over cellular, WiFi, fixed broadband and so on, and irrespective of location. It's all just "a connection"; it shouldn't matter to the user, so the story goes. For pico/femtocells there's a related fallacy, "you can use a completely cellular normal handset".

This is of course total nonsense, on several grounds:

1) Some bearers only offer connectivity through an operator's network (eg cellular), while others also offer connectivity direct to the Internet or local resources owned by the end-user (eg WiFi, fixed broadband, LAN). Clearly it makes sense for some applications to be aware that, if the device is connected via WiFi for example, it may have access to IT or consumer-electronics capabilities outside the operator's control (eg a PC, printer, server, IP-PBX, TV, game console, hifi etc)

2) Different bearers have different characteristics - bandwidth, latency, quality, security, ownership, power consumption and obviously price. Applications (and sometimes the end user) should monitor bearers and make appropriate decisions. When Microsoft announces Service Pack 1 for Vista in a year's time, you'd rather have the download manager app know what network you're connected to. If it detects that you're roaming on GPRS at $10 per MB, it should wait until you're on a more sensible bearer before proceeding. Similarly, if the battery on a phone is really low, the telephony client might decide to "prefer" GSM to WiFi even if it's more expensive.

3) An operator or 3rd party may well decide to optimise for certain bearers, rather than rely on a lowest common denominator. If you're at home on an HSDPA femtocell, or WiFi, then you'll probably get more data throughput. This may mean reengineering the browser with a bigger cache or memory buffer to take advantage of it. It could mean the handset decides to use a higher-quality codec for better sound. It might switch on (or off) functions like advertising, or different sorts of messaging, or 101 other location-specific applications. The user interface might change automatically, or it could display location-dependent tariffs.

4) There may be more efficient routing through the network for a given application in certain locations/on a specific bearer. Take BT as an example. When a Fusion phone is at home on the WiFi connection, the browser would ideally send all web traffic straight out over the broadband connection direct to the Internet... and not first via Vodafone's cellular core network used as part of BT's MVNO relationship, as UMA would normally enforce. Even for an integrated operator like FT/Orange, there's no point unnecessarily taking up capacity in the MSCs and GGSNs for IP traffic that's then going straight to the Internet. (Potentially this function could be done in the home gateway rather than the phone itself).

A lot of people don't understand all this, particularly if they work at a mobile operator and still fervently believe that anything you do on a handset is "a service", rather than understanding that sometimes you want to do non-service activities as well.

Some handset software companies do get this. Most obviously, the enterprise-centric dual-mode clients from Avaya, Cisco, Divitas, Siemens etc have "multiple personalities", making the phone behave differently when it's in WiFi mode.

But I've also had discussions with Symbian (which has a thing called a Bearer Abstraction Layer, or something like that) which passes bearer information to the apps, so developers can embed the sort of intelligence I discuss above. Nokia's inclusion of UPnP technology in some of its WiFi handsets reflects the fact that it also"gets it" about making phones good citizens of the consumer-electronics ecosystem, as well as being operator-centric.

And this morning I had a discussion with a company called Abaxia, which is also completely on-message about the above. It has some dynamic UI technology that alters the handset idle screen and applications, depending on the network context. Interestingly, it's working on both bearer-aware (eg cellular vs WiFi) or location-aware (eg whether you're in a homezone) variants. On the homezone side, it's working with Orga on a SIM-based solution that works out if the user is in a given cell (or triangulates from a set of base stations), and enables the UI to adapt accordingly.

The Orga solution sounds a bit similar to the one from Seeker Wireless, albeit without the network-side location server element containing a map of base station locations. They both have the handset/SIM locate the network, rather than vice versa. I'll do another post about non-WiFi/non-femtocell FMC solutions at some point - they generally offer location-based tariffing discrimination but don't add any dedicated indoor wireless coverage or capacity.

I foresee a lot more work in this area, as operators & device vendors realise that optimising the user experience, for different bearers or locations, is an essential aspect of FMC. Different bearers are inherently different - don't treat this as inconvenient, treat it as an opportunity and exploit it.