NENA Technical Standards & Documents

Select one or more Committee – Then click Apply.

Standard# & Titles only List / Archived Technical Standards

Technical – General
Operations – General

  • 00-001 v16 Master Glossary

    The NENA Master Glossary is a guide for readers of NENA publications and a tool for members of the NENA committees that prepare them. It defines the terms, acronyms and definitions associated with the 9-1-1 industry. Intended users of this document are any person needing NENA’s definition/description of a 9-1-1 related term.

Technical – General

  • 01-001 v4.1 Organization & Document Approval Processes

    This document is written for NENA Technical Committee leadership and members. A requirement for participating in the Technical Committee process is to adhere to all procedures outlined in this document.

Technical – Data

  • 02-010 v9 Data Formats for ALI, MSAG & GIS

    This document sets forth NENA standard formats for Automatic Location Identification (ALI) related data exchange between Service Providers and Data Base Management System Providers, a GIS data model, a Data Dictionary, and formats for data exchange between the ALI Database and PSAP Controller equipment.

  • 02-011 v7 9-1-1 Data Management

    This document sets forth NENA standards for all Service Providers (SPs) involved in providing dial tone to end users whether or not they are the 9-1-1 Database Management System Provider (DBMSP) or a SP in an Enhanced 9-1-1 area. It includes Database Maintenance, Quality measurements, INP, LNP and Number Pooling standards to be utilized for any 9-1-1 system that provides information for data display. It defines measurements that support meaningful computations to allow for a better understanding of database quality and timeliness of database updates.

  • 02-011A Excerpt: 9-1-1 Database Administration Software

    This is a portion of NENA 02-011 that has been excerpted to make this section more accessible and to assist users requiring the ability to get MSAG Updates, ANI/ALI trouble resolutions and additional information to their 9-1-1 Database Management System Provider. The associated software may be downloaded at at no charge.

  • 02-013 v3 Provisioning & Maintenance of MSAG Files to VDBs and ERDBs

    Voice over Internet Protocol (VoIP) is poised to become the predominant technology used in the telecommunications industry. As the public adopts VoIP, E9-1-1 calls will increasingly originate from VoIP users. Some VoIP telecommunications service provider networks, however, are not natively compatible with the existing E9-1-1 infrastructure. NENA is developing a view of migratory (i2) and long-term (i3) solutions that will continue to support location-based routing of E9-1-1 calls and delivery of location-related information to PSAPs.

  • 02-014 v1 GIS Data Collection & Maintenance

    This document is the NENA recommended standard for GIS data collection and GIS data maintenance. This document is meant to provide PSAP management, vendors, and other interested parties necessary guidelines for collecting and maintaining GIS data. Collection and maintenance of GIS data is most reliably accomplished by qualified, trained individuals or vendors that have received formal GIS training and instruction.

  • 02-015 v1 Resolving ANI/ALI Discrepancies & NRFs

    This NENA document sets forth standards for PSAP jurisdictions, Access Infrastructure Providers (AIP), Service Providers and Data Base Management System Providers (DBMSPs) in reporting and resolving discrepancies that occurred during a 9-1-1 call. These processes are meant to standardize ANI/ALI Trouble and “No Record Found” reporting to facilitate their timely resolution. An ANI/ALI Trouble is defined as a wrong ANI, no ANI or an ALI Discrepancy, which includes “No Record Found”. This document takes into account all the technologies available for 9-1-1 calls to date. Due to the various ways these technologies deliver 9-1-1 calls to PSAPs, there are various timelines for resolution of discrepancies.

  • 02-501 v1 Wireless ALI Data Content

    There has been a growing concern, among public safety administrators in various states and other interested parties, about the increasing degree of inconsistency in the use of specific E9-1-1 data fields for varying types of ALI-related data items. While this has provided a degree of customization to support varied PSAP data processes, it also has driven a large set of variations in SCP and MPC programming, and in ALI server data handling, along with expensive customizing of CAD and Mapping system software.

    As in other aspects of 9-1-1 data handling, what might be considered a positive situation – a high degree of flexibility – also can carry a high degree of complexity, when the national level view is considered. As a result, a balance between flexibility and complexity usually provides necessary real service capabilities with simplification and overall cost savings, due to lessened complexity.

  • 02-502 v3 NENA Company ID Registration

    This “NENA Company ID Registration Service Technical Information Document” defines the Company ID program and provides instructions for companies to register their company identification.

  • 02-503 v1 XML Namespaces

    This document dedicated to namespaces as used in XML technologies. It is intended to provide a non technical introduction to the concept of namespace and a relatively complete overview of the specific characteristics of XML namespaces.

  • 06-001 v2 Local Service Provider Interconnection Information Sharing

    This document sets forth recommended NENA standards for all Local Service Providers involved in providing dial tone to end users.

  • 06-002 v3 ALEC Service Initiation

    The purpose of the Service Initiation Guidelines is to provide guidance for 9-1-1 service initiation, as well as define the needs of the ALECs, ILECs and 9-1-1 Administrators. When an ALEC enters into a new service area, they may not know the appropriate contacts in order to obtain the required information for a successful 9-1-1 implementation. On the same note, 9-1-1 administrators/entities need notification of ALECs who will be serving customers in their jurisdiction.

  • 06-003 v2 Private Switch (PS) E-9-1-1 Database

    Recent technical developments make it possible for Private Branch Exchange Telephone Systems (PBX) to provide Telephone Station level Automatic Number Identification (ANI). This NENA Technical Reference defines the requirements and methods to accomplish the provisioning of Private Switch 9-1-1 (PS/911) data in conjunction with the use of a Multi Line Telephone System (MLTS) or Private Branch Exchange (PBX) telephone system. For the purpose of this document and to be consistent with other NENA documents, a Private Branch Exchange telephone system or PBX will be referred to as a Multi-Line Telephone System or MLTS.

  • 06-501 v2 (Converted to TRD 06-750) MLTS Model Legislation

    Converted to TRD 06-750 February 19, 2009.

  • 06-502 v1 MLTS E9-1-1 Caller Location Discovery and Reporting

    Recent technology innovations have made it critically important for organizations to address the challenge of identifying the location of the users of communications systems during emergencies in the Multi Line Telephone System1 (MLTS) environment. This paper and the accompanying diagrams will discuss many of the issues related to the location of individuals during emergencies in the MLTS environment. It will further outline the current suggested methods of dealing with the challenge using commonly available technology as recommended in this document by NENA.

  • 06-750 v3 (Previously TID 06-501) MLTS Model Legislation

    Recent technology innovations have made it important to update the MLTS Model Legislation recommended in 2000.  The following revised Policy document reflects changes in IP technology; Implementation & Testing; Training and the use of building code Fire Zones to facilitate the creation of the Emergency Response Location.

Technical – Network

  • 03-002 v3 Enhanced MF Signaling, E9-1-1 Tandem to PSAP

    This NENA Standard defines the use of a Feature Group D like signaling protocol between the E9-1-1 selective routing tandem and E9-1-1 customer premises equipment (CPE) which is called “Enhanced MF Signaling”. This document does not suggest the implementation of Feature Group D trunking – there are tariff issues associated with FGD that do not apply to 91-1. Rather, it recommends borrowing the “off the shelf” MF signaling protocol from Feature Group D in order to facilitate the delivery of one or two ten-digit ANI’s to the PSAP over existing facilities, without creating an entirely new protocol.

  • 03-003 v1 Inter-Networking, E9-1-1 Tandem to Tandem

    This NENA Technical Reference defines the use of an Integrated Services Digital Network (ISDN) User Part (ISUP) signaling protocol between E9-1-1 selective routing tandems, and similar equipment, for the purpose of allowing 9-1-1 calls to be transferred or routed across E9-1-1 networks.

  • 03-004 v2 E9-1-1 Functional Entity Model

    Recent changes in telephony technology along with corresponding changes in the regulatory environment with respect to E9-1-1 Service are impacting the service architectures being defined for E9-1-1 Services. Support of Wireless Phase II and NENA i2 for VoIP are making enhancements to existing E9-1-1 functionality necessary.

    The definition of service architectures to support Wireless Phase II and NENA i2 for VoIP functionality will impact both wireless and wireline networks. Since both wireless and wireline networks will play a role in processing an increasing number of Emergency Calls, it is critical that the interconnection for these networks be based on a common understanding of the functions and interfaces supported by each network.

  • 03-005 v1 E9-1-1 Selective Routing Switch

    This document is intended to define the Generic Feature Requirements of an Enhanced 9-1-1 Selective Routing switch. For legibility, this document describes the Selective routing switch as a single switching element even though the NENA Functional Entity Model describes the Selective Routing function as it fits into the E9-1-1 network as a whole. This allows the developer to create the E9-1-1 function as a centrally located switching entity, or as distributed network elements. It also distinguishes which features and characteristics are fundamental to an Enhanced 9-1-1 system, and which, through either current or anticipated advancement of the industry, are deemed optional or additional features of the 9-1-1 network.

  • 03-006 v1 E9-1-1 Call Congestion Management

    This document provides a framework for consideration of the various factors impacting the management of call congestion and traffic engineering for E9-1-1 networks. A network reference model is provided for use in referring to generic E9-1-1 network entities. This is followed by a section that outlines generally accepted industry practices for traffic engineering for E9-1-1 networks.

  • 03-007 v1 ESCO Code Selection

    This NENA Recommended Standard for Emergency Service Central Office (ESCO) Code Selection, Assignment and Display Management discusses the Emergency Service Central Office (ESCO) code specifications as it relates to the incoming trunk groups in the E9-1-1 Control Office. It is a guide for designers, manufacturers, 9-1-1 Service Providers, 9-1-1 Database Authorities and 9-1-1 Public Safety Answering Points (PSAPs). It identifies some of the issues involved with the selection, assignment, processing and management of the ESCO codes used for trunk group origination identification during an Automatic Number Identification (ANI) failure.

  • 03-008 v1 E9-1-1 Default Assignment and Call Routing Functions

    This “NENA Recommended Standard for E9-1-1 Default Assignment and Call Routing Functions” document provides an overview of various database and network specifications and requirements related to Default Routing of 9-1-1 calls. It is intended to help local authority; database and/or network administrators select a model in the development of standard default routing arrangements. It identifies and defines methods used to assign defaults and route 9-1-1 calls when circumstances prevent normal selective routing. Each approach is used during a specific set of circumstances; similarly a specific set of circumstances shall determine which approach is most appropriate.

  • 03-501 v4 Network Quality Assurance

    Single points of failure in the 9-1-1 network should not be tolerated. Network and Emergency Services providers should design and deploy fault tolerant systems which will eliminate, as much as possible, single points of failure that prevent routing 9-1-1 calls successfully. The solution should be capable of delivering a 9-1-1 call to a designated default Public Safety Answering Point (PSAP)(?) during times of network failure through either alternate routing, Emergency Stand Alone (ESA) / Emergency Transport Backup (ETB) / Emergency Line Access (ELA) capabilities, cellular networks, etc. and should be automated when/where possible. Very clearly, the first priority is to route the call to a designated PSAP.

  • 03-502 v1 Trunking for Private Switch 9-1-1 Service

    This NENA TID defines three distinct alternative trunking configurations to accomplish the provisioning of Private Switch 9-1-1 Service (PS/911) in conjunction with the use of Private Branch Exchange (PBX) telephone systems. For PBX systems that use digital trunks, Primary Rate Interface Integrated Services Digital Network (PRI-ISDN) trunks, the provisioning of PS/911 may be accommodated without the requirement of dedicated trunks for transporting 9-1-1 calls. For PBX systems that use analog trunks (i.e. they are not compatible with PRI and/or PRI trunks are not available from local service providers), the provisioning of PS/911 may be accommodated by using dedicated circuits that operate with the Centralized Automated Message Accounting (CAMA) signaling protocol.

  • 03-503 v1 SS7 Guidelines

    This document is a guide to orient the SS7 translation engineer/technician on the nature of translations required in the SS7 messaging between the E9-1-1 Selective Router and the various network elements that seek to connect to the router. These elements can include both wireline end offices and VoIP Emergency Services Gateways (ESGW) owned or operated by local exchange carriers (ILECs and CLECs), VoIP Service Providers (VSPs) and/or the E9-1-1 Service System Providers (SSPs). It is not in the scope of this document to explain exact details of any particular 9-1-1 SR, but to act as a way to understand the dynamics of these types of translations. This document is secondary to any network disclosure or other translation policy guides from any 9-1-1 Service System Provider. The reader of this document is encouraged to contact the 9-1-1 Service System Provider for any detailed questions on SS7 translations or policy details.

  • 03-504 v1 Mobile Emergency Service (E911M)

    This document contains standards requirements for providing the PSAP with a working callback number to all wireless phones that call 9-1-1. It brings with it the solution to a number of other open issues.

  • 03-505 v1 Rate Center Consolidation

    This document is a guide for E9-1-1 Subject Matter Experts (SMEs) and Regulatory Agencies in determining a rate center consolidation configuration that minimizes the impact of E9-1-1 call delivery in a failure condition. Specifically, this document addresses the impacts of rate center consolidation in an environment served by multiple service providers.

  • 03-506 v1 E9-1-1 Voice Circuit Requirements

    The purpose in determining voice circuit requirements for an E9-1-1 Trunk Group is to provide a transmission Grade of Service (GOS) for each 9-1-1 caller that is at least P.01 (probability that no more than one call out of 100 attempts made during the average busy hour will be blocked) and that, where available, physically diverse routing is being used between nodes.

    In no case is it ever recommended that voice circuits be designed at less than P.01 Grade of Service (GOS). Note that P.01 can also be described as P0.01 in the industry. In this document that are to be considered as synonymous.

  • 03-507 v1 ESQK Guidelines for VoIP
    This document is a guide to orient VSPs, ESGW operators, and VPC operators on the use and assignment of ESQKs for 9-1-1 Emergency Services Gateway (ESGW) to Selective Router (SR) connectivity and call routing.
  • 03-508 v1 Multiple Service Type Calls

    This document provides a review of the topics that are associated with the practice of delivering more than one type of an emergency call over the same trunk group into a legacy type E9-1-1 selective router.   It describes the market forces leading to the implementation of the practice as well as the technological pros and cons associated with it. The technical and operational implications of the practice are addressed from the perspective of many separate areas, including groups such as the originating service provider, network aggregator, E9-1-1 system service provider, Public Safety Agency (i.e., PSAP management/call takers), and regulatory bodies that govern 9-1-1 operations. 

  • 03-509 v1 Femtocell and UMA

    The purpose of this “Femtocel/UMA Technical Information Document” is to describe in technical as well as operational terms the current state of femtocell and UMA deployments with respect to call processing of E9-1-1 calls, and to identify the impacts to Public Safety Answering Points (PSAPs) of receiving and processing calls from femtocells. This TID also describes the current 9-1-1 infrastructure, next generation emergency networks, and discusses integration of femtocells and UMA technologies into those networks. This TID will provide information to allow the National Emergency Number Association (NENA) and other interested parties to develop new communications methodologies, standards, and protocols to facilitate emergency communications between users of femtocells/UMA and PSAPs.

  • 05-001 v1 E2 Interface

    This “NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2 Interface” document provides explicit protocols and parameters for interoperable operation of the E2 interface over TCP/IP. 1This interface is between the MPC/GMLC and the EMSE as defined in TR45.2’s TIA/EIA/J-STD-036-A . This document defines the methods that MPC/GMLC and ESME use to interact, allowing for the concept of geographically redundant nodes and the inherent link management. It defines how the TCAP-based application protocol is to be encapsulated upon the TCP/IP stack.

  • 05-501 v1 SS7 Guidelines for MSC to Selective Router Connectivity

    This document is a guide to orient the SS7 translation engineer/technician on the nature of 9-1-1 Mobile Switching Center (MSC) to SR translations. It is not in the scope of this document to explain exact details of any particular 9-1-1 SR, but to act as a way to understand the dynamics of these types of translations.

Technical – CPE

  • 04-001 v2 E9-1-1 PSAP Equipment

    This NENA Technical Reference NENA-04-001 defines the Public Safety Answering Point (PSAP)(?) equipment requirements intended for use by users, manufactures and providers of E9-1-1 Customer Premise Equipment (CPE). A PSAP is an agency or group of agencies designated and authorized to receive and respond to emergency calls requiring one or more public services (Police, Fire, EMS or all three).

  • 04-002 v4 PSAP Master Clock

    This Standard is a guide for designers and manufacturers of PSAP equipment. It identifies engineering and technical requirements to be met before the NENA membership shall consider purchase of such equipment; it may also be of value to purchasers, maintainers and users of such equipment.

  • 04-003 v1 E9-1-1 ISDN PSAP Equipment Utilizing Basic Rate Interface

    This NENA Technical Reference NENA-04-003 defines the Integrated Services Digital Network BRI (ISDN BRI) Public Safety Answering Point (PSAP)(?) equipment requirements intended for use by users, manufacturers and providers of E9-1-1 Customer Premise Equipment (CPE). The PSAP is a designated agency that receives and responds to emergencies such as Police, Fire, EMS, etc.

  • 04-004 v1 PSAP Intelligent Workstation

    This NENA Technical Reference NENA-04-004 defines the Public Safety Answering Point (PSAP)(?) Intelligent Workstation (IWS) equipment requirements intended for use by users, manufactures and providers of E9-1-1 Customer Premise Equipment (CPE).

  • 04-005 v1 ALI Query Service

    This document defines the NENA XML ALI Query Service (AQS) that specifies new protocols between the PSAP and the Next Generation Emergency Services Network (NGESN). It provides the rationale behind the AQS and how it relates to the current ALI protocol. It also provides an overview of implementation alternatives (bindings) described in detail within the document.

  • 04-501 v1 Integrating Applications on Intelligent Workstations

    The emergence of intelligent workstations and multitasking operating systems has allowed the integration 0f multiple applications that had previously appeared on separate platforms. Integrating these applications on one workstation can provide a higher level of functionality and ease of use over individual dedicated equipment. This integration of applications on a single platform leads to a higher level of responsibility for all associated vendors.

  • 04-502 v1 CPE Site Characteristics

    This Technical Information Document is a guide for PSAP managers and for the designers, manufacturers and installers of PSAP CPE (Customer Premises Equipment). It identifies the required and desirable characteristics of the PSAP facilities that house the supporting CPE. “Supporting CPE” includes all of the equipment and facilities that support PSAP operations with the exception of call taker or dispatch related equipment that is located in the workspace. Supporting CPE is often located in a “back room” and is sometimes referred to as “backroom” equipment.

  • 04-503 v1 PSAP Security

    Today’s Public Safety Answering Points (PSAPs) face more threats than ever before. In a post 9/11 world, the 9-1-1 community must recognize the reality of increased threats and vulnerabilities. New product paradigms are being designed and implemented by the PSAP community at a rapid pace. Today’s call-centers are challenged to keep pace with the rapid shifts in technology.

Technical – Non-Traditional

  • 07-501 v11 Future 9-1-1 Models

    The purpose of this document is to develop models of 9-1-1 systems that will provide the features and functionalities that the public safety organizations need to do their job of responding to 9-1-1 calls. The models have been developed with a view to the future in that each model represents either a view of what currently exists or what is expected to exist at a predefined point in the future.

  • 07-502 v1 Non-Traditional Communications to PSAP Equipment

    This document will identify, define, discuss and offer potential solutions or alternatives to interfaces required to bring non-traditional sources of information into Enhanced 9-1-1 Public Safety Answering Point (PSAP)(?).

  • 07-503 v1 Network Interfaces for 9-1-1 and Emerging Technologies

    This NENA Technical Information Document (TID) provides a reference to network interfaces for users, manufactures and providers of E9-1-1 in an Emerging Technologies such as:

    • Voice over Packet (VoP)
    • Voice over Internet Protocol (VoIP)
    • Voice over Digital Subscriber Line (VoDSL)
  • 07-504 v1 Collision Notification & Telematics Information

    The purpose of this “Automatic Collision Notification and Vehicle Telematics Technical Information Document” is to understand and describe in both technical and operational terms the current telematics industry and telematics emergency calls and associated information delivered to Public Safety Answering Points (PSAPs). The document scope also reflects on the current 9-1-1 infrastructure, the next generation emergency networks, and it discusses the integration of telematics emergency calls and information into those networks. This Technical Information Document (TID) will provide information to allow the National Emergency Number Association (NENA) and other interested parties to develop new communications methodologies and protocols to facilitate emergency communications between Telematics Service Providers (TSP) and PSAPs.

Technical – VoIP/Packet

  • 08-001 v2 Interim VoIP Architecture (i2)

    Voice over Internet Protocol (VoIP) is poised to become the predominant technology used in the telecommunications industry. As the public adopts VoIP, E9-1-1 calls will increasingly originate from VoIP users. Some VoIP telecommunications service provider networks, however, are not natively compatible with the existing E9-1-1 infrastructure. This document was developed to outline an interim architecture to connect callers in the IP domain with Public Safety Answering Points (PSAPs) supported by the existing E9-1-1 Service Provider network.

  • 08-002 v1 Functional & Interface Standards for NG9-1-1 (i3)

    Major changes in the existing emergency services architecture are being driven by the rapid evolution of the types of devices and services that can be used to call for help. Also there is an increasing volume and diversity of information that can be made available to assist PSAPs and responders in an emergency. NENA recognizes this is a fundamental update to the North American 9-1-1 system, and is addressing the challenge with a system design called “Next Generation 9-1-1(?)” (NG9-1-1(?)). NG9-1-1 is the evolution of Enhanced 9-1-1 to an all-IP-based emergency communications system. This technical specification, commonly referred to as i3, is the first version of the NG9-1-1 system design.

  • 08-003 v1 NENA i3 Solution

    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 descrepencies 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.


  • 08-501 v1 Network Interface to IP Capable PSAP

    This “NENA Technical Information Document on the Network Interface to IP Capable PSAP” document provides technical information to guide manufacturers of network equipment and Public Safety answering Point (PSAP)(?) Customer Premises Equipment (CPE) in the development of Internet Protocol based interfaces between the network and PSAP CPE and to assist E9-1-1 Network Service Providers and PSAP’s in implementing such interfaces. It defines a service description for the capabilities that will need to be supported by the VoIP signaling on the interface, as well as the necessary network and CPE elements needed in the supporting architecture. The Appendices to this TID include specific assumptions/issues for individual candidate Voice over Internet Protocol (VoIP) signaling protocols, that will need to be considered in the specification of (separate) technical reference document(s) that provide signaling requirements for the individual VoIP protocol alternatives identified.

  • 08-502 v1 E9-1-1 Requirements

    This document is intended to provide a resource that describes the features and functions of the E9-1-1 system that is currently deployed in the United States. These features and functions are a compilation of different regional networks and some may not be present in any particular E9-1-1 network.

  • 08-503 v1 VoIP Characteristics

    The purpose of this document is to procure, create and publish a VoIP primer document to be used by individuals not familiar with VoIP technology.

  • 08-504 v1 VoIP Standards Development Organizations (SDOs)

    This “NENA VoIP Standards Development Organizations” is a reference for NENA technical committees to use for determining the various standards setting bodies involved in the implementation and on going development of VoIP protocols and procedures as they relate to emergency calling.

  • 08-505 v1 Location Determination: IP-Based Emergency Services

    This document is the first edition of what will be a comprehensive document addressing many access network configurations. This edition has a narrow solutions focus and will address only the automated mechanisms for the residential broadband market, manually configured location mechanisms for end-points are not discussed. User-provided location information is beyond the scope of this document. Revised editions of this document will add new sections to address enterprise, hosted and mobile access configurations.

  • 08-751 v1 i3 Requirements (Long Term Definition)

    This “NENA i3 Technical Requirements Document” is intended to specify the requirements the i3 (Long Term Definition) Standard should meet.  This document is issued to guide the development of the i3 Standard.

  • 08-752 v1 Location Information to Support IP-Based Emergency Services

    This Technical Reference document provides the NENA requirements for providing location information to support emergency calling. It also provides example scenarios and use cases that need to be supported. This is being provided to support organizations that are defining solutions for determining, acquiring and conveying location information to support emergency calling.

  • 08-DRAFT Emergency Services IP Network Design for NG9-1-1

    NOTE: NENA 08-XXX, Version 1, is continuing to be developed by the ESIND WG.

    Many 9-1-1 Entities have built, are building, or will build in the near future an Emergency Services network to connect the PSAPs in their region. The effort and expense required to build these regional facilities is significant. What steps can be taken today to ensure that these regional IP networks will be able to transport traffic for NG9-1-1(?) functions (i.e. ECRF, ESRP, etc.) when those services become more readily available? What are some of the major design considerations that should be taken into account? What are some of the caveats, limitations, and advantages of the various technologies? The purpose of this document is to provide the 9-1-1 Entities with the tools (i.e. design methodologies, best practices, templates for ESInet RFI and RFP, etc.) that will enable them to design and deploy networks today that will be capable of meeting the requirements of an NG9-1-1 system.


Technical – Data
Operations – Next Generation Integration – NGI

  • 70-001 v1 NENA Registry System

    When developing and deploying technical standards which employ enumerations, or lists of values, where the enumeration or lists can reasonably be expected to change over time as new technology, vendors, service providers or other stakeholders evolve, a known stable way to maintain the current acceptable values in the enumeration or list is required. The values in the enumeration or list are called a registry. This document describes how registries are created and maintained in NENA.

  • 70-DRAFT Provisioning and Maintenance of GIS data to ECRF/LVF

    NOTE:  NENA XX-XXX, Version 1, is continuing to be developed by the NGDD ECRF/LVF WG.

    This document defines operational processes and procedures necessary to support the i3 Emergency Call Routing Function (ECRF) and Location Validation Function (LVF). Additionally, this document identifies ECRF/LVF performance and implementation tradeoffs for 9-1-1 Authorities’ consideration.

    The roles and responsibilities of 9-1-1 Authorities vary depending on jurisdictional hierarchy, resource availability, capabilities, service arrangements, and regulations and statutes. As such, 9-1-1 Authorities are expected to work with ECRF/LVF operators to further clarify and/or identify additional services prior to development and implementation of ECRF and LVF. 
    Although this document contains references to 9-1-1 authorities’ Geographic Information System (GIS), Public Safety Answering Point (PSAP)(?)(?) equipment and mapping applications, access and call network providers Location Information Servers (LIS), and other core functions of the NG9-1-1(?) system, their functionality and operations are out of scope for this document. NENA 08-003 contains definition of data structures and detailed functional and interface standards that are referenced in this document.  


  • 71-001 v1 NG9-1-1 Additional Data

    With the implementation of NG9-1-1(?) there will be many forms of additional data available to emergency responders. This document covers the use of additional data associated with a call, a location, a caller and a PSAP. Together with the SIP Invite and PIDF-LO, additional data associated with a call has the ability to look at other data sources; i.e., Vehicle Emergency Data Set (VEDS) to assist in determining the appropriate call routing and handling.

  • 71-002 DRAFT Civic Location Data Exchange Format (CLDXF)

    NOTE:  NENA 71-002, Version 1, is being worked by the NGDD CLDXF WG.

    NENA Joint Data/Next Generation Integration Committees, Next Generation Data Development Working Group (NGDD), has created the Next Generation 9-1-1(?) (NG9-1-1(?)) Civic Location Data Exchange Format (CLDXF) Standard as one component of a larger suite of NG9-1-1 standards. The NG9-1-1 standards are intended to provide a common and mutually-understood means for PSAPs to exchange 9-1-1 call location information.

    The NENA NG9-1-1 CLDXF standard supports the exchange of United States civic location address information about 9-1-1 calls, both within the US and internationally. The NENA NG9-1-1 CLDXF standard covers civic location addresses within the United States, including its outlying territories and possessions. The NENA NG9-1-1 CLDXF standard defines the data elements needed for address data exchange, and provides an XSD for implementing the standard. As a data exchange standard, the NENA NG9-1-1 CLDXF is not intended to support civic location address data management. It is assumed that address information will be transmitted call by call, as part of the call record, and that any local address data repository would be external to the call information. Therefore the standard does not provide for an address identifier, address metadata, or address data quality tests.

    Concurrently with the NGDD WG’s development of the CLDXF, the Address Standard Working Group (ASWG) has been developing an address standard for the U.S. FGDC. The FGDC draft standard is intended to support address data management. The FGDC draft defines address data content, attributes, and metadata; address classes; address data quality tests; and an XSD for address data exchange. The Joint Data Technical/Next Generation Integration Committees, Next Generation Data Development Working Group, has worked closely with the Address Standard Working Group to prepare a profile of the NENA and FGDC draft standards that details the precise relationship between them. Pending formal adoption of the separate standards by NENA and FGDC, the profile will be included as an informative annex to both standards.


  • 71-501 v1 Synchronizing GIS with MSAG & ALI

    This document is the NENA information document for the synchronization of certain Geographic Information Systems (GIS) database layers with the Master Street Address Guide, the Automatic Location Information data, and optionally the site / structure locations.

    This document is meant to provide PSAP management, vendors, and other interested parties necessary guidelines for synchronizing GIS data with existing 9-1-1 databases. The synchronization process of the GIS data is most reliably accomplished by qualified, trained individuals or vendors that have received formal GIS training and instruction.

  • 71-502 v1 Overview of NG9-1-1 Policy Rules

    This document is an overview of what policy rules are, how policy is defined, and the ways that they may be used. Policy rules influence the delivery of calls to a PSAP and, how these calls are handled based on call taker skill sets and other criteria. Policy Rules are defined and implemented by the governing 9-1-1 Authority.


Technical – VoIP/Packet
Operations – VoIP

  • 73-501 Non-Voice-Centric Emergency Services

    The Emergency Services community has a desire to have multimedia emergency services supported with the same general characteristics as emergency voice calls. As a result, there is a need to communicate with emergency services using mechanisms that are not primarily voice.

    Non-Voice -Centric (NVC) Emergency Services are intended to support (human) end user to authority communication. NVC Emergency Services may support the following examples of non-verbal communications to an emergency services network:

    1. Text communication between end users and emergency services
    2. Multi-media (e.g., pictures, video clips) transfer to emergency services during a voice or NVC session with emergency services.
    3. Real-time video session with emergency services
    4. Text communication with supplementary media (such as background audio and/or video)

    NVC Emergency Services as defined in this document focuses on Next Generation Network (NGN) technology and does not include legacy messaging services, such as Short Messaging Service (SMS) . In addition, NVC Emergency Services does not include support of calls from non-human initiated devices (e.g., fire alarms).

    There will be significant impacts to the entire emergency services system resulting from the changes in networks and devices as described in this document. It is expected that end user devices and origination networks will ultimately evolve, and that the next generation emergency services solution will allow this evolution to take place over time. Many systems in the emergency services network must eventually change. New end-to-end messaging relationships must be established.

    In addition to supporting the general public, this capability facilitates emergency communications by individuals with disabilities (e.g., persons who are deaf, deaf-blind, hard of hearing, or have a speech disability).






Technical – CPE
Operations – Next Generation Integration – NGI

  • 75-001 v1 NENA Security for Next-Generation 9-1-1 Standard (NG-SEC)

    The purpose of this document is to establish the minimal guidelines and requirements for the protection of NG9-1-1(?) assets or elements within a changing business environment. This document:

    • Identifies the basic requirements, standards, procedures, or practices to provide the minimum levels of security applicable to NG9-1-1 Entities.
    • Provides a basis for auditing, and assessing levels of security and risk to NG9-1-1 Entities, assets or elements, and exception approval / risk acceptance process in the case of non-compliance to these guidelines.

    This document is applicable to all NG9-1-1 Entities including, but not limited to:

    • Public Safety Answering Points
    • NG9-1-1 “ESINet”
    • NG9-1-1 Service Providers
    • NG9-1-1 Vendors
    • Any Contracted service that perform functions or services that require securing NG9-1-1 assets. 
    • Those who use, design, have access to, or are responsible for NG9-1-1 assets (includes computers, networks, information, etc.).

    This document will impact the operations of 9-1-1 systems and PSAPs as standardized security practices are implemented where they have not been in place before. NG9-1-1 Entities will be required to understand, implement and maintain new security solutions, mechanisms and processes.

Joint – NG Transition Planning

  • 77-501 v1 NG9-1-1 Transition Planning Considerations

    The public safety community has recognized the need to evolve legacy emergency services networks to next generation concepts which may facilitate new capabilities and services. As such there are numerous industry associations and Standard Development Organizations (SDOs) that are defining architectures and protocols for these next generation networks. The public safety community desires to take advantage of this work and address the challenge it represents to emergency communications. To this end, work is progressing in other NENA committees to define the specific emergency services architectures and protocols involved. The transition of emergency services addressed by this document relies upon this collective work.