Extending mobile presence - the need for context and device state information

I speak to a broad variety of vendors and operators about presence in a mobile context. It crops up repeatedly both for operator-centric developments like IMS and RCS, and also for independent applications like mobile VoIP and corporate unified comms.

In theory, mobile phones ought to be good platforms for presence information - both rudimentary connection details (online, offline, idle etc) and some personalised state or emotional content as well ("Dean is currently thinking about lunch" and so on).

In addition, the network is sometimes able to add some extra information about the user - maybe location cell ID, whether the user is on a call, whether they are connected via fixed or mobile and so forth.

All this is useful, and currently highly under-exploited. There is a lot of work needed just to prove the current user experience and gain adoption. Although I can't see anyone actually paying for presence directly, it potentially enhances other services, and could also generate increased traffic and call completion.

But at the same time, I think the mobile presence industry is missing a trick. The presence client on a phone ought to be able to pick up a lot more information about the device's - and the user's - context. In particular, it would be fantastic if it could pick up details from the underlying phone APIs, and enable that data to be exploited by clever applications in the network, or directly by a contact. So for example - whether the phone is on charge, or is running low on battery. Or whether the user is using a Bluetooth headset. Or that the accelerometer can detect motion that looks like walking or driving. Or that the memory for SMS's is almost full.

These are just some ideas, but you get the picture. There are all sorts of clever things that could be achieved with this approach.

(Yes, clearly privacy is a huge concern here, but let's assume that we can simultaneously invent some form of reasonably-effective permissioning system - perhaps an easier version of that seen on sites like Facebook)

Now clearly a fundamental issue is that phones differ in many of these regards. I don't think there's a standardised API for % battery remaining for example, and the SMS memory may be split between phone, SIM and memory card. Different OS's and models of phone have very different capabilities which would make creating "common denominators" extremely difficult.

But maybe we could start with a couple of basic aspects - perhaps standardised by OMTP or OMA - and then incrementally add more features over time.

Unfortunately, there seems to be no easy way to catalyse development of this type of concept. Bodies like the 3GPP shy away from dependency on mobile phone-resident software, often naively believing that everything of value can be done from the network core. It may be that we will need to rely either on operator-customised handset platforms (DoCoMo, maybe?) , or third-party software providers, probably from VoIP or IM backgrounds (Truphone? Skype? social networking clients?). We're getting there first with location context (Loopt, fring and others do this), but that still not providing data at the level of "device state".

On the other hand, one of the downsides of any extensions to current mobile presence technology would be the amount of extra signalling traffic involved. I'm already hearing that the IMS-centric view of a "presence enabled phonebook" is running into scaling problems. If you have 100 entries in a contact list, and you expect all of them to be continually updated, this causes a huge amount of (typically SIP) traffic. It also requires presence clients to be running continually in the background on devices, with consequent implications for power consumption.