Location is Needed To Make Presence Workable
Don Van Doren wrote an excellent blog for NoJittter recently regarding deficiencies in the current incarnation of presence. Don identified three primary issues:
- 1. In the most beneficial UC applications, what's needed isn't a specific person, but rather someone with a particular skill or knowledge.
- 2. Status updating is largely a manual process, and it’s a pain to update.
- 3. A person’s “availability” is contingent on who's trying to reach them.
It is that second point that is has always struck me. It will be totally impractical to have a presence system that requires people to update their status manually; it’s simply not going to happen. Further, if the presence status is consistently incorrect, users will simply ignore it. In short, unless we can develop a solution that recognizes and fits into the way that people actually work, the likelihood of widespread adoption is remote. Fortunately, we in the mobility space have some ideas to contribute.
UC platforms can typically change the user’s presence status based on on/off hook status, calendar entries, user defined rules, or those manual overrides. The first three are automatic, but with some important limitations that may still require the manual override. First, on/off hook status has marginal value if it cannot recognize the status of the user’s mobile device. The capabilities of the current mobile UC clients vary widely, but often they can recognize on/off hook status of the mobile only for calls that terminate (not originate) on the mobile.
Calendar driven updating is a useful idea except for the fact that most of us are dragged into countless ad hoc meetings during the course of the day. We need a solution that is more dynamic (more “realistic” would probably be a better term) and requires little or no action on the user’s part. “Little action” would entail the user’s responding to a system prompt asking if they would like to have their status changed.
One important development in making presence plausible would be the ability to recognize where the user is and tie that location information in with these other metrics. If the person is in a conference room and their calendar says they’re scheduled for a meeting, we can put two-and-two together.
The key element is that people don’t go anywhere without their mobile phones; if we can find the mobile we can find the user. There are potentially three elements in the mobile we might use to determine location, and a number of different location technologies that can be used to track them. A workable solution will require a combination of these as each has a different profile regarding coverage, accuracy, and battery draw.
- GPS/Assisted GPS: GPS, or the more power efficient Assisted GPS, is very accurate and available on many mobile devices. However it suffers from long initial location time (i.e. “time to first fix”), has virtually no visibility indoors, and creates a significant battery draw.
- Cell Tower Location: Not as accurate as GPS (accuracy depends on the size of the cells in that area), but it is far more power efficient; the tower identifier is automatically stored and updated in the phone. With a database of tower locations you can determine the city and roughly the neighborhood the user is in. You can also record the tower identifiers for regularly visited locations like your office or the hotel you generally stay at in a particular city.
- In-building Wi-Fi Location: Wi-Fi location is typically used to locate equipment (e.g. stat carts in a hospital), but it can be used to locate any Wi-Fi capable device. This solution requires a location appliance (e.g. AeroScout or Ekahau) on the wireless LAN and can provide resolution within a few meters. The device must send a Wi-Fi frame periodically to be located, and Wi-Fi is also something of a power hog. iPhone users have found it’s best to turn it off when not in use.
- Wide Area Wi-Fi Location: Skyhook Wireless has a Wi-Fi Positioning System (WPS) that uses a database of over 100 million Wi-Fi access points they have mapped; this is the location service used in many iPhone applications. The device receives beacon messages from visible access points, sends the access point addresses (i.e. BSSID) to Skyhook, who returns the location coordinates. Used either alone or in conjunction with GPS, WPS combines speed and accuracy, but it too requires a Wi-Fi radio.
- Bluetooth: Generally overlooked as a location technology, if your mobile device has a Bluetooth interface, we can find it. If the mobile is registered with a desktop PC or PBX station, we can surmise that user is within 10m of their office (i.e. the typical transmission range of a Class 2 Bluetooth transceiver). There is also a Bluetooth location tracking (BLT) protocol, so “promiscuous” Bluetooth transceivers could be installed in conference rooms, the cafeteria, or near building exits.
It is important to note that most of these solutions are handset-based, so the handset will know where it is, but it will still need a mobile data capability to tell the presence server. Network-based location solutions like in-building Wi-Fi location systems will also need to interface with the presence server that will set the presence status (or prompt the user to determine if the status change is warranted) and then make it know to others based on the availability rules the user has defined.
Conclusion
Presence truly is one of the core capabilities of UC, but users are busy, they’re often on the move, and they are not going to adopt a capability that doesn’t work well or is more trouble than it’s worth. Location capability linked to the user’s mobile device could be what makes this capability practical and workable. However, if we need to determine location both in and out of the office, a multi-modal solution will be required. As is often the case, the consumer-oriented applications have figured out how to make location work for them, but we haven’t done nearly as a good a job for the enterprise.