Emergency call location for mobile UC: slow progress on E911 improvements

The current unified communications E911 system works but in the most unsatisfactory manner

Emergency call location for mobile UC
Credit: ICMA

Making enterprise voice-over-Wi-Fi systems comply with emergency call regulations requires shoehorning new techniques into a very old architecture. It also exposes some unfinished technology and fragmented implementation models. We can do it, but no one is happy with the contortions.

There’s a large population of enterprise unified communications (UC) systems from Microsoft, Cisco, Avaya, Shoretel and others using Wi-Fi endpoints, whether dedicated Wi-Fi phones or client apps on smartphones. When it comes to emergency call functionality, we should expect these to work at least as well as landlines, PBX extensions and cell phones.

One of the most important emergency call (E911) functions is locating the caller. To make emergency call location work, we first need to find the location, then send the call, with caller location attached, to the correct emergency answering center in a form it can understand. Both of those steps present problems.

First, finding the location of wireless devices is difficult. There is no universally available wireless location technology that works indoors in a similar fashion to GPS outdoors. (And even GPS is often switched off to save battery life.)

Cobbling together alternative methods

The best near-universal location method is to use the associated access point’s location as a best estimate, which requires configuring a list of access points and their locations and identifying the associated access point when the emergency call is placed.

Alternative methods based on parsing IP addresses require unnatural subnet configuration but will work in a pinch. It’s also possible to get more accurate location with multi-access point triangulation, but this method is not widely used partly because the more-accurate location often can’t be passed to the emergency dispatcher.

Even the data format is problematic. Latitude-longitude is often easier to derive, but emergency services prefer the street address because it identifies the building entry point. Most important, we need to identify the floor in multi-storey buildings, and this is difficult to determine in latitude-longitude-altitude GPS coordinates. Today, street address with a floor number is the best solution but one that often requires a good deal of manual configuration.

Problems with PSAPs

Once the caller is located, the call and the caller location are routed to the nearest emergency answering center (public safety answering point, or PSAP). Most enterprise UC systems are set up to identify an emergency call, then find the caller’s location in real time using one of the above methods. The address can be used to identify the correct PSAP to route the call to (important with geographically distributed UC systems) and must be encoded and sent along with the call so the dispatcher can read the street address while engaging the caller.

The second step is getting the caller’s location to pop up on the dispatcher’s screen. And perhaps the biggest issues with today’s system lie here. PSAPs are run by cities and counties, and they are chronically underfunded and very slow to upgrade. Most still work on a landline model where the calling number is mapped to a street address. This model dates back to when each residential phone line had an associated street address. It is clearly limited, and today’s UC systems go through contortions to adapt to these archaic interfaces.

The usual process is to map a large area (often a whole floor) of a building to a phantom phone number and insert that number as the calling number when the call is sent to the PSAP. Each phantom phone number must be entered into the PSAP’s street address database beforehand, which is a tedious and error-prone process. (A whole industry of intermediaries populates location databases, inserts phantom calling numbers and determines which answering center a call should be routed to.)

The upshot is we have a system that works but in the most unsatisfactory manner.

A long way from indoor GPS

Despite the availability of suitable standards, the Wi-Fi industry has failed to converge on a widely implemented indoor location service. IEEE 802.11 standards already allow access points to advertise their locations both pre- and post-association and in latitude-longitude-altitude and street address format. These standards have not yet been embraced by access point or device vendors, but this may change with the forthcoming Wi-Fi Alliance Location certification: there is hope for universal adoption. 

Even assuming vendors incorporate them, it will take a while for these standards to percolate into the installed base. Alternatives to Wi-Fi include wider use of Bluetooth beacons, but these suffer from fragmented implementations, so the industry would need to pick a standard to adopt, then roll out an enormous number of beacons. Despite the availability of standards, we are some way from “indoor GPS.”

But the biggest obstacle to improving mobile UC E911 architecture remains the base of 6,000 public safety answering points nationwide. They move very slowly: today only 10 percent are capable of receiving text messages, hardly a new technology. A next-generation E911 project has been running for years, but we have yet to enjoy the fruits of implementation. Without more-capable dispatch centers that accept VoIP calls as part of a menu of access protocols, work on improving in-building caller location accuracy will be in vain.

This article is published as part of the IDG Contributor Network. Want to Join?

Must read: Hidden Cause of Slow Internet and how to fix it
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies