9-1-1 Policy, Technology, Operations, and Education
with National Emergency Number Association (NENA)
What is NG9-1-1?
The evolution of emergency calling beyond the traditional voice 9‐1‐1 call has caused the recognition that our current E9‐1‐1 system is no longer able to support the needs of the future.
Next Generation 9‐1‐1 (NG9‐1‐1) networks replace the existing narrowband, circuit switched 9‐1‐1 networks, which carry only voice and very limited data. Currently there are difficulties in supporting such things as text messages for emergencies, images and video (including support for American Sign Language users), and easy access to additional data such as telematics data, building plans and medical information over a common data network.
In addition, the need for inter‐communications across states, between states, and across international boundaries requires that we create a more flexible 9‐1‐1 system design with much greater data handling capabilities. A highly standardized system is essential and critical to seamlessly support communications and data transfer across county, state, and international borders, and across the multitude of emergency response professions and agencies, from traditional PSAPs to Poison Control Centers, trauma centers, Coast Guard, and disaster management centers. There will be numerous and varied steps toward the new system named NG9‐1‐1, and vendors are already referring to their products as aimed at, enabling, or being wholly NG9‐1‐1 compliant.
Vendors who have direct experience with parts of today’s E9‐1‐1 system and service, and who are directly involved in NENA and other standards development can and are starting to produce NG9‐1‐1 oriented products. The direction of the Standards that will support NG9‐1‐1 is becoming clear, and demonstrations and trials are beginning to appear and will contribute to continued standards development. Despite this progress, a fully featured, truly “standards based” NG9‐1‐1 system is not yet identifiable, because the necessary standards are still in development. As a result, a summary definition of NG9‐1‐1 as a system and service process is needed to clarify what is involved.
NG9-1-1 Summary Definition
NG9‐1‐1 is a system comprised of hardware, software, data and operational policies and procedures briefly described below, to:
• provide standardized interfaces from call and message services
• process all types of emergency calls including non‐voice (multi‐media) messages
• acquire and integrate additional data useful to call routing and handling
• deliver the calls/messages and data to the appropriate PSAPs and other appropriate
• emergency entities
• support data and communications needs for coordinated incident response and
• provide a secure environment for emergency communications
The basic building blocks required for NG9‐1‐1
Emergency Services IP Network (ESInets) use broadband, packet switched technology capable of carrying voice plus large amounts of varying types of data using Internet Protocols and standards. ESInets are engineered, managed networks, and are intended to be multi‐purpose, supporting extended Public Safety communications services in addition to 9‐1‐1. NG9‐1‐1 assumes that ESInets are hierarchical, or a `network of networks’ in a tiered design approach to support local, regional, state and national emergency management authorities.
International Standards Compliant IP Functions Internet Engineering Task Force (IETF1) based IP protocol standards provide the basic functionality of the system. NENA has applied standards from IETF and other Standards Development Organizations to specific NG9‐1‐1 requirements. Examples are: Location Validation Function (LVF) and Emergency Call Routing Function (ECRF) and other functions, as defined in NENA 08‐002, [IP] Functional and Interface Standards for NG9‐1‐1 (i3).
This NENA Standard defined the core IP functionality of the larger NG9‐1‐1 system.Software Services/Applications NG9‐1‐1 uses service oriented architecture, software applications and data content to intelligently manage and control its IP based processes. NG9‐1‐1 is software and database driven to enable an exponential increase in available data and information sharing possibilities. It also provides flexibility and individual agency choice to determine information needs based on predetermined business/policy rules.
Databases and Data Management NG9‐1‐1 uses a set of database systems to house and provide management of the above data content. Some examples are: validation, routing control, policy/business rules, and system‐wide detail call records. (reference: pending NENA NG9‐1‐1 Data standards) NG9‐1‐1 provides the mechanisms to access external sources of data, either automatically or manually, via the ESInet, to support more knowledgeable and efficient handling of emergency calls/messages. Examples: telematics/ACN data, hazardous material information, building plans, medical information, etc.
Security NG9‐1‐1 provides extensive security methods at the hardware and software levels to replicate the privacy and reliability inherent in E9‐1‐1 services.
Human Processes NG9‐1‐1 as a service system involves a multitude of human procedures and system operations procedures to control and monitor the functionality and effectiveness of the systems and services that provide NG9‐1‐1 service. Examples include database establishment and maintenance procedures, IP network operations, security processes, trouble shooting procedures, database auditing and accuracy validation procedures,.
NENA is an organization chartered to represent both public safety and the 9‐1‐1 industry, present and future, in its mission to focus on the development, evolution, and expansion of emergency communications. NENA is the organization responsible to define NG9‐1‐1, and to coordinate the development and support of NG9‐1‐1 as a system and a service to the public, the industry, and to Public Safety entities.
In the past, this has been about 9‐1‐1 exclusively, but the future involves a more `virtual’ approach to how the public and governmental entities accomplish emergency communication through NG9‐1‐1. Text devices don’t `dial’ 9‐1‐1, for example, but use a different form of identification to access the system and achieve delivery to PSAPs and other entities. However, the basic processes and service needs are the same, no matter what `code’ is used. The conceptual base of NG9‐1‐1 is international in scope, designed to support all emergency codes, such as 9‐1‐1, 1‐1‐2, 1‐1‐1, and all others among the 62 access codes (at last count) used around the world. Other communications and data exchange functions that will be considered part of an NG9‐1‐1 system won’t use any such access codes, but will access ESInets as necessary to communicate seamlessly across local, State, regional, international boundaries.
What development and support areas does NENA focus on for NG9-1-1?
View NENA Table (Other organizations may be involved)
Note: Local Government has two roles – funding management and public safety operations
NG9-1-1: Are we there yet?
Fully featured, standards based NG9‐1‐1 will likely be implemented in successive releases; but unless it’s a full replacement for existing E9‐1‐1 functions2, including additional features to bring 9‐1‐1 service up to the level needed in today’s emergency communications environment, it is not a true “next generation” of 9‐1‐1. True NG9‐1‐1 will include the ability to support interactive text messaging, policy‐based routing using location and several other factors, such as call type, target PSAP status, network status, and automatic acquisition of supportive data and its use within the system to control routing and other actions prior to delivery to the PSAP, and many other standards defined features and functions.
When a newer, IP based replacement for E9‐1‐1 meets or exceeds the capability set above, it will achieve fully featured NG9‐1‐1. Note that this is not about having all possible originating service types implemented, but that the NG9‐1‐1 capabilities defined above are present, tested (to the extent possible, which may be limited to lab testing if there are no live instances of any given capability)2, and ready for service. If a given IP‐based system is not capable of all initial NG9‐1‐1 features and functions, it can certainly be considered to be on the path to full NG9‐1‐1, but is still pre‐NG9‐1‐1 in nature. communications requires that the new system be as completely featured as the old system, and tested in advance.
1 IETF (Internet Engineering Task Force) generates international IP standards for Internet and other applications
2 Utilizing a new system for ongoing 9‐1‐1 service in a way that is highly unlikely to disrupt emergency