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 discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Sunday, June 01, 2008

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.

6 comments:

Peter J. Cranstone said...

Dean,

This is exactly what I talked about on the Forum, and also exactly what we've been able to offer customers for over a year now. Plus our context client also allows the consumer complete control over his or her privacy.

There is a complete explanation of how it works on our web site.

Cheers,

Peter
5o9 Inc

Peter J. Cranstone said...

I forgot one thing. We have an Open API so developers can essentially access ANY device side API and then pass that information directly to the web server.

Our solution is cross platform and runs inside the default browser.

Cheers,

Peter

Paul Golding said...

The issue is really about having open access to the presence server so that any application can write presence vectors to it. In theory, SIP/SIMPLE and XMPP are wonderfully extensible architectures - I can basically put whatever 'presence' stuff I want in there, if it's open for updates.

Presence data is a real issue. I worked with one MVNO whose proposition was more or less wiped out by the costs of data in pushing presence vectors back and forth. Of course, these updates can be filtered by rather complex filtering schemes in SIP/SIMPLE, but then you run into the issue of how to do the filtering.

The other issue is how do applications consume presence data. On most mobile handset platforms today, there is no method for routing presence data to applications in a 'multi-tasking' context, assuming, that is, that multi-tasking is even meaningful on the device (which on most, it still isn't).

mike said...

have you tried Jaiku on S60?

It does the presence thing already. It reads the S60 diary and will post to the web interface (default is only free/busy information).

It also posts profile type (silent, pager or other), your location (based on their Database of Cell tower locations).

Martijn Brouns said...

Presence in itself is merely one aspect of a user's context. That context cosists of:
- what device is in hand
- what kind of connection is available (2G, 3G, WiFi, WiMax)
- what kind of applications are available to the user
- what subscriptions/blockages does a user have
- how trustworthy is the user's identity (how is he authenticated)
- how long can he call (prepaid credit, battery)
- etc.

Standardising access to a comprehensive set of contextual user data will take ages.

We should approach this as basic as possible. Forget about battery life and other contextual frills. Knowing that a user is accesible via phone, text would be a great start.

Secondly I think mobile users are not interested in syncing presence information 24/7. When scrolling through my address book though, I like to have an update as soon as I hightlight one user (i.e. when I am on the verge of contacting that user).

It's just like real life. It's that 2 seconds before I start a conversation, that make me evaluate whether the person in question is not on a call, in what mood he's in, etc.

Let's keep it simple people. In the end, for most people out in the street (the user!) this conversation is still incomprehendable and geeky anyway.

Dean Bubley said...

Thanks for your comments.

Martijn - yes, I like that idea that it just checks a contact's presence just before you want to call/SMS.

Also, I had a chat with the OMTP about some of the issues they're dealing with around security & API accessibility with their Bondi concept. Seems like there's definitely something worthwhile going on.

Mike - no, I haven't tried Jaiku. I really not a particular fan of trying out random downloadable apps. Also, I don't use the diary on my S60 work device (my personal phone is a featurephone not a smartphone). Sounds quite good though, and fits better with the sort of concepts I'm talking about.

Dean