What is NG9-1-1?

What is NG9-1-1?
National Emergency Number Association (NENA)

NENA's Role
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.

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)², 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.