NENA i3 Solution - Stage 3
Full Name:
Detailed Functional and Interface Standards for the NENA i3 Solution
Document Type: Standard
Number: NENA-STA-010.2-2016 (originally 08-03)

This specification builds upon prior NENA publications including i3 requirements and architecture documents. Familiarity with the concepts, terminology and functional elements described in these documents is a prerequisite. While the requirements and architecture documents describe high level concepts, the present document describes only the detailed functional and external interfaces to those functional elements. If there are discrepancies between the requirements or architecture documents and this document, this document takes precedence. This document provides a baseline to other NG9-1-1 related specifications.


The i3 solution supports end-to-end IP connectivity; gateways are used to accommodate legacy wireline and wireless origination networks that are non-IP. NENA i3 introduces the concept of an Emergency Services IP network (ESInet), which is designed as an IP-based inter-network (network of networks) that can be shared by all public safety agencies that may be involved in any emergency. The i3 Public Safety Answering Point (PSAP) is capable of receiving IP-based signaling and media for delivery of emergency calls conformant to the i3 standard.

Getting to the i3 solution from where we are today means that we will have to go through a transition from existing legacy originating network and 9-1-1 PSAP interconnections to next generation interconnections. This document describes how NG9-1-1 works after transition, including ongoing interworking requirements for IP-based and TDM-based PSAPs and origination networks. It does not provide solutions for how PSAPs, origination networks, selective routers and ALI systems evolve. Rather, it describes the end point where conversion is complete. At that point, selective routers and existing ALI systems are decommissioned and all 9-1-1 calls are routed by the ECRF and arrive at the ESInet via SIP. The NENA NG9-1-1 Transition Planning Committee (NGTPC) will produce documents covering transition options and procedures.

This document supports IP-based and legacy TDM-based PSAPs.

TDM-based PSAPs are connected to the ESInet via a gateway (the Legacy PSAP Gateway). The definition of the Legacy PSAP Gateway is broad enough that both primary and secondary PSAPs that have not been upgraded may be served by this type of gateway.

Similarly, the scope includes gateways for legacy wireline and wireless origination networks (the Legacy Network Gateway) used by origination networks who cannot yet create call signaling matching the interfaces described in this document for the ESInet. It is not envisioned that legacy origination networks will evolve to IP interconnect in all cases, and thus the Legacy Network Gateways will be needed for a very long time. The document considers all wireline, wireless, and other types of networks with IP interfaces, including IMS networks, although the document only describes the external interfaces to the ESInet, which a conforming network must support. This document describes a common interface to the ESInet, to be used by all types of origination networks or devices. How origination networks, or devices within them, conform is not visible to the ESInet and is out of scope. NENA has endeavored to define this interface to be sufficiently aligned with the major types of originating networks, as defined by the prevalent SDOs (such as 3GPP, 3GPP2, IETF), that they are able to conform without significant modification to their architectures. However, it is recognized that IMS design has evolved in parallel with development of this document, and that further SDO convergence work will be required to align the details between i3 and related origination network 9-1-1 interfaces. The results of this convergence work will be documented in a future edition of this document. Further, regulatory policies will affect how this standard will evolve.

This specification defines a number of Functional Elements (FEs), with their external interfaces. An implementation of one or more FEs in a single indivisible unit (such as a physical box, or software load for a server) is compliant with this specification if it implements the functions as defined, and the external interfaces as defined for the assembly of FEs. Internal interfaces between FEs which are not exposed outside the implementation are not required to meet the standards herein, although it is recommended that they do.

This document describes the "end state” that has been reached after a migration from legacy TDM circuit-switched telephony, and the legacy E9-1-1 system built to support it, to an all IP-based telephony system with a corresponding IP-based Emergency Services IP network. To get to this "end state” it is critical to understand the following underlying assumptions:

  1. All calls entering the ESInet are SIP based. Gateways, if needed, are outside of, or on the edge of, the ESInet. IP services that are not native SIP based, have protocol interworking to SIP prior to being presented to the ESInet.
  2. Access Network Providers (e.g.: DSL providers, fiber network providers, WiMax providers, Long Term Evolution (LTE) wireless carriers, etc.) have installed, provisioned and operated some kind of location function for their networks. Location functions are critical for 9-1-1 calls originating on an IP network because it provides a 9-1-1 valid location to IP clients that bundle their location in the SIP signaling to the ESInet.
  3. All calls entering the ESInet will normally have location (which might be coarse, e.g., cell site/sector) in the signaling with the call.
  4. 9-1-1 authorities have transitioned from the tabular MSAG and ESNs to GIS based Location Validation Function (LVF) and Emergency Call Routing Function (ECRF).
  5. 9-1-1 authorities have accurate and complete GIS systems, which are used to provision the LVF and ECRF. A change to the 9-1-1Authority’s GIS system automatically propagates to the ECRF and LVF and immediately affects routing.
  6. Civic location will be validated by the access network against the LVF prior to an emergency call being placed. This is analogous to MSAG validation.
  7. Periodic revalidation of civic location against the LVF is also needed to assure that location remains valid as changes in the GIS system that affect existing civic locations are made.
  8. Since the legacy circuit-switched TDM network will very likely continue to be used for the foreseeable future (both wireline and wireless,) the i3 architecture defines a Legacy Network Gateway (LNG) to interface between the legacy network and the ESInet.
  9. Transition to i3 is complete when the existing Selective Router and ALI are no longer used. Even after that time, some PSAPs may not have upgraded to i3. The i3 architecture describes a Legacy PSAP Gateway (LPG) to interface between the ESInet and a legacy PSAP. The LPG supports the origination of an emergency call through the ESInet to a legacy PSAP as well as the transfer of an emergency call from/to an i3 PSAP to/from a legacy PSAP.
  10. Federal, State and local laws, regulations and rules may need to be modified to support NG9-1-1 system deployment.
  11. While NG9-1-1 is based on protocols that are international, and are designed to allow visitors and equipment not of North American origin to work with NG9-1-1, the specific protocol mechanisms, especially interworking of legacy telecom and ESInet protocols is North American-specific and may not be applicable in other areas.
Committee Name(s):

Interconnection & Security Committee

Created: 06/14/2011

Current Document:

Detailed Functional and Interface Specification for the NENA i3 Solution


 NENA Registry System (schemas are shown under "i3-v2-xml-schemas")

 Previous VersionsNENA 08-003 v1_20110614
Licensing Declaration Forms

Qualcomm 08-003 v1