Solved: VoIP 9-1-1

A broad-based coalition of universities and public safety organizations has invented the future of emergency dialing. It promises new capabilities for 9-1-1, but will take substantial resources to implement.

By Gerry Blackwell | Posted Jun 27, 2005
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

The Next Generation 9-1-1 (NG911) project—a joint effort of research universities, public safety organizations, and telecommunications vendors—will demonstrate its promising new IP-based emergency calling solution again this week at the National Emergency Number Association (NENA) convention. NENA is a trade association for local and state operators of emergency call centers or public safety answering points (PSAPs).

The NG911 group first demonstrated an early prototype of the system last month. That demonstration was received well and has led to further discussions, with the FCC among others, says Professor Henning Schulzrinne, chairman of the department of computer science at Columbia University in New York and one of the principal investigators on the project.

The NG911 system is not to be confused with the system VoIP providers will likely be mandated to implement within four months of the passing of a currently proposed new FCC regulation. "The FCC solution only addresses part of the problem," says Schulzrinne. "It stitches something together that kind of works in some circumstances. Our emphasis is on a much longer-term solution."

Problems and opportunities
The NG911 group argues that a new emergency calling paradigm is required to both take advantage of unique opportunities IP communications presents and deal with new problems not faced in the traditional circuit-switched environment. Solving the problems is the first priority. The first is number portability—the telephone number assigned to a VoIP subscriber is no longer tied through the national numbering system to a region (area code) and local area (exchange prefix). Subscribers outside the country could have a New York city area code, for example.

There is also a separation of physical connectivity and service. The telephone company knows the exact address to which a telephone number is assigned—its wires are connected there. VoIP providers know only the billing address, which even with fixed residential services is not necessarily the permanent location of the phone. This is made more complicated by the mobility IP telephony offers. A subscriber could change locations for long periods by taking a residential VoIP gateway to a new location and plugging it in to a different high-speed Internet connection. Or if he's using a laptop with a soft phone, he could change locations from one call to the next.

Piecing together an answer
"[Our system] solves these problems essentially by dividing the responsibility for emergency calling between two entities," Schulzrinne says. "One entity, namely the [ISP], knows where you are but doesn't know you're making an emergency call. The other, the [VoIP] provider, has no clue where you are but knows you're making an emergency call."

One part of the NG911 solution is to have the terminating device—the subscriber's IP phone or gateway—deliver location information to the VoIP provider as part of the signaling information sent along with the call. The best way to do this, the project team believes, is to have the Internet service provider's DHCP server deliver location information along with an IP address whenever a user plugs in an IP device.

When a user dials 9-1-1, the location data will automatically be sent along with IP address to the VoIP provider. Now the VoIP provider knows it's an emergency call (because the user dialed 9-1-1) and knows where the call is originating. In the NG911 framework, the provider sends the location information to a PSAP directory service which looks up the correct emergency call center for the originating location, and then the provider routes the call to that PSAP.

Demonstrably viable, but . . .
The project team proved with the first demonstration that its technology can work, Schulzrinne says, and it will demonstrate an improved prototype at this week's NENA convention. But he admits there are several impediments to implementing such a system on a national scale.

One is that no comprehensive PSAP directory exists as such, although the information exists at local, regional and state levels and mobile emergency call service providers such as OnStar have compiled their own comprehensive directories. Schulzrinne sees the directory service working something like Internet domain name directories, with data sources logically and administratively decentralized, but access through a portal from anywhere.

An even more fundamental problem is that PSAPs for the most part rely on traditional PBX technology and cannot receive IP phone calls unless they're first passed through an IP voice gateway. Most gateways would not be able to pass through the IP-based location information.

Migrating PSAPs; cooperating ISPs
"The PSAPs need to migrate to IP telephony," Schulzrinne says. "Not for every call taker, but it will require some hardware investment. This is the biggest challenge in terms of coordination given that there are 6,100 PSAPs and most are fairly small operations that might have only two or three seats."

The migration to IP will happen gradually anyway, he notes, because PSAPs, like any other organization, need and typically already have high-speed Internet connectivity, and because the industry wide trend is to IP PBXs replacing traditional telephony systems. But it will take time, and money.

Then it will be necessary to get ISPs to play along. For ISPs to be able to pass location data to terminating devices during log-in and IP configuration will likely require changes to their operations systems, Schulzrinne says. (We're guessing some ISPs will say this is the understatement of the year.)

Schulzrinne would like to think ISPs will want to participate willingly. "The optimist in me thinks ISPs are going to do this just because they know it's the right thing to do, because they don't like their customers to die anymore than anyone else does," Schulzrinne says.

But realistically, regulation may be required to "accelerate" the process, he says. For one thing, some ISPs that are also telephone companies may be tempted to drag their heels on any such initiative in order to maintain the validity of their competitive claim that new VoIP competitors can't provide adequate 911 service.

This can't just be seen anymore as, 'Oh, emergency calling, that's a problem for Vonage,'" Schulzrinne says. "That approach will only result in spending a lot of time on an incomplete solution that won't work reliably."

Solving the current problems with VoIP emergency calling, with the necessary migration to IP voice, will also create opportunities for improving emergency calling services by letting callers deliver additional rich media information such as video or still photography, or data such as medical or hazardous material information. It will also mean that in the event of a widespread outage, PSAPs could set up emergency sites almost anywhere they can get Internet connectivity.

Getting it done
"The NG911 system, while it's a longer-term solution than many being discussed, would not take forever to implement, Schulzrinne believes. "I would guess that it depends on PSAPs more than on us," he says. "We could do it within a year, though perhaps not nationwide just because of the number of PSAPs involved would make that difficult."

The next major step will be moving from a demonstration of a prototype to actually field testing a system with real PSAPs fielding real calls. In the meantime, the demonstration at the NENA convention is a crucial interim step. "What we want to do next is engage the PSAP community so we actually get some feedback—'Yeah, that's what we need,' or 'We also need this,' or 'Here's what we really need.'"

The NG911 project group has the resources to make it happen if the ISPs and PSAPs are onside. Besides Columbia University and NENA, the project group includes:

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter