2011 NG9-1-1 Conference
In February, I attended the NENA TDC/ODC conference in Nashville, TN. For the past five years, this annual conference has focused on defining standards for Next-Gen 9-1-1 (NG9-1-1). It’s a working conference. Attendees get an unfiltered view into the activities of the various working groups and committees. Attendees are encouraged to provide feedback and participate in ongoing activities. The following are some of my observations from this year’s conference:
NG9-1-1 PSAP Definition
As pieces of NG9-1-1 technology begin to emerge, some PSAPS have claimed NG9-1-1 status as a result of implementing portions of NG9-1-1, such as an IP phone system or an Emergency Services IP Network (ESInet). This has prompted NENA to clarify the definition of what a PSAP must have to be considered an NG9-1-1 PSAP. In a nutshell an NG9-1-1 PSAP must have
- ESInet (Emergency Services IP Network)
- i3 Architecture (i3 elements necessary to route a call through an ESInet)
- Databases (Those databases required to support i3 architecture elements)
- Processes and procedures to maintain databases and i3 elements.
As with many major initiatives, early expectations of what NG9-1-1 would accomplish tended to be idealistic. Now that the scope of NG9-1-1 is more clearly defined, NENA finds itself having to rein in expectations. Among these are:
Myth: NG9-1-1 will enable text to 9-1-1.
Reality: Existing texting protocols are not suitable for use with 9-1-1. They do not provide guaranteed delivery nor do they include location information. NG9-1-1 will support future texting protocols that are suitable for 9-1-1.
Myth: NG9-1-1 will cost less.
Reality: Even though NG9-1-1 uses industry standard equipment and protocols, the complexity of the system will require expensive software and maintenance which may cost as much or more than legacy networks.
Myth: NG9-1-1 will provide better location information.
Reality: Location information is provided by the carrier or device, not the NG9-1-1 network. NG9-1-1 will do a better job routing a call to the proper PSAP, but will not modify the location passed in.
Setting proper expectations for what NG9-1-1 will and won’t do is going to be an ongoing educational process for NENA.
In the past NENA has discussed having a certification process for vendors to ensure their solutions are NG9-1-1 compliant. But in talking to NENA staff at the conference, they haven’t been able to find a way to fund a certification program. So, at least for now, it isn’t on their radar.
While NG9-1-1 will provide major benefits, it will be a more complex system than the legacy 9-1-1 network. Even considering the hacks that have been done to the legacy network to support cellular and IP communications, NG9-1-1 will likely still require more resources to setup and maintain.
NENA has produced numerous documents and presentations that attempt to describe NG9-1-1 in simplified terms. But it is a difficult thing to do. To date, the best document I have found describing NG9-1-1 is the i3 specifications document. It is a very technical document, not suitable for non-technical people. But other documents and presentations that have tried to summarize the information have either been too technical themselves or too simplistic to explain what’s really happening. The i3 document can be found at http://www.nena.org/technical-standards.
This year’s conference shows there is still good momentum behind the NG9-1-1 initiative. Significant progress has been made, but there is still a lot of work to do. NENA posts the current status of the standards documents at http://www.nena.org/ng911-project. I’ve only scratched the surface of items discussed at the conference. Session materials, including presentations and session notes, can be found on NENA’s website at http://www.nena.org/tdc-odc/session-material.