Nena Sta 015.10 2018 - Datakkk

NENA
Standard Data Formats

For E9-1-1 Data Exchange
& GIS Mapping
Abstract: This document sets forth NENA standard formats for Automatic Location
Identification (ALI) data exchange between Service Providers and Data Base Management
System Providers, a Geographic Information System (GIS) data model, and formats for
data exchange between the ALI Database and PSAP Controller equipment.
NENA Standard Data Formats for E9-1-1 Data Exchange & GIS Mapping
NENA-STA-015.10-2018 (Originally 02-010)

DSC Approval: 06/24/2018
PRC Approval: 08/03/2018
NENA Executive Board Approval: 08/12/2018
Next Scheduled Review Date: 08/12/2021
Prepared by:
National Emergency Number Association (NENA) Data Structures Committee, Class of
Service Working Group.
Published by NENA
Printed in USA
© Copyright 2018 National Emergency Number Association, Inc.

NENA Standard Data Formats for 9-1-1 Data Exchange & GIS Mapping
NENA-STA-015.10-2018 (originally 02-010), August 12, 2018
1 Executive Overview
This document sets forth NENA standard formats for Automatic Location Identification
(ALI) data exchange between Service Providers and Data Base Management System
Providers, a Geographic Information System (GIS) data model, and formats for data
exchange between the ALI Database and PSAP Controller equipment. However, it should
be noted that legacy E9-1-1 formats to a PSAP are highly configurable. The reason for
revising this document is to add additional legacy Classes of Service (CoS), standardized
use of Service Descriptions in the Customer Name/Service field, and specify the
recommended CoS information in Section 18 and the recommended Service Descriptions in
Section 19.
08/12/2018 Page 2 of 119

TABLE OF CONTENTS
1 EXECUTIVE OVERVIEW ............................................................................................................................... 2

DOCUMENT TERMINOLOGY ................................................................................................................................ 8
INTELLECTUAL PROPERTY RIGHTS (IPR) POLICY ..................................................................................... 9
REASON FOR ISSUE/REISSUE ........................................................................................................................... 9
2 TECHNICAL DESCRIPTION....................................................................................................................... 17
2.1 TYPES OF DATA EXCHANGE FORMATS ............................................................................................ 17
2.1.1 Common Considerations: ...................................................................................................................... 18
2.1.2 Version 1 & 2 formats: .......................................................................................................................... 18
2.1.3 Version 3 data formats: ......................................................................................................................... 19
2.1.4 Version 4 Description Summary:.......................................................................................................... 19
2.2 TYPES OF DATA ELEMENTS WITHIN DATA FORMATS AND ADDITIONAL GUIDANCE ... 21
2.2.1 Additional Guidance on the three Classes of Service for Wireless Network Services displaying Civic
Address as Primary ALI ........................................................................................................................................ 22
2.2.2 Additional Guidance to rename the “Customer Name” field to “Customer Name/Service” field and
on standardized “Service Descriptions” ............................................................................................................. 23
2.2.3 Additional Guidance on Customer Name/Service field and standardized “Service Descriptions” for
Wireless Network Services displaying Civic Address as Primary ALI ............................................................. 23
2.2.4 Additional Guidance on CoS and on Customer Name/Service field and standardized “Service
Description” for Wireless Carrier Small Cells .................................................................................................... 24
Description” for Customer Femtocells ............................................................................................................... 24
2.2.6 Additional Guidance on Customer Name/Service field and standardized “Service Description” for
Wi-Fi Calling .......................................................................................................................................................... 25
Description” for Wireless Home Phones ............................................................................................................ 25
2.2.8 Additional Clarification and Guidance on the Existing VoIP Wireless (VMBL) CoS and Replacement
with a new CoS of Other Mobile (OMBL) .......................................................................................................... 26
2.2.9 Additional Guidance on new CoS for Supplemental Geodetic Location from Third-Party (SDXY) CoS
27
3 NENA V1.0 ...................................................................................................................................................... 28
4 NENA V2.0 ...................................................................................................................................................... 28
08/12/2018 Page 3 of 119

5 VERSION 2.1 FORMAT FOR DATA EXCHANGE ................................................................................... 29

6 VERSION 2.1 FORMAT FOR MSAG DATA EXCHANGE ...................................................................... 35
7 VERSION 2.1 HEADER FORMAT FOR DATA EXCHANGE ................................................................. 38
8 VERSION 2.1 TRAILER FORMAT FOR DATA EXCHANGE ................................................................ 39
9 VERSION 3.1 FORMAT FOR DATA EXCHANGE ................................................................................... 40
9.1.1 Data Record Format Example: ............................................................................................................. 50
10 VERSION 3.1 FORMAT FOR MSAG DATA EXCHANGE ...................................................................... 51
11 VERSION 3.1 HEADER FORMAT FOR DATA EXCHANGE ................................................................. 55
11.1.1 Header Record Format Example: .................................................................................................... 55
12 VERSION 3.1 TRAILER FORMAT FOR DATA EXCHANGE ................................................................ 57
13 VERSION 3.1 WIRELESS DATA EXCHANGE ........................................................................................ 58
13.1.1 Dynamic Updates of the ALI Database .......................................................................................... 58
14 VERSION 4 XML FORMAT FOR DATA EXCHANGE ............................................................................. 64
14.1 THE XML SCHEMA ........................................................................................................................................... 64
14.2 SCHEMA VERSION CONTROL ............................................................................................................................ 64
14.3 SCHEMA DESIGN.............................................................................................................................................. 64
14.4 SCHEMA EXTENSIONS ...................................................................................................................................... 65
14.5 SCHEMA VALIDATION ....................................................................................................................................... 65
14.6 VALIDATION POINT.......................................................................................................................................... 65
14.7 REDEFINING OF DATA ELEMENTS ..................................................................................................................... 65
14.8 TWO EXAMPLES OF THIS REDEFINING ARE DESCRIBED BELOW. ........................................................................... 66
14.9 TRANSMISSION PROTOCOL............................................................................................................................... 66
14.10 XML SCHEMA LOCATION.................................................................................................................................. 67
14.11 EXAMPLE OF THE RELATIONSHIP BETWEEN SCHEMA GENERATIONS AND SUBSEQUENT RELEASES ......................... 68
14.12 ALL SCHEMAS: ................................................................................................................................................. 69
15 ALI SCHEMAS ................................................................................................................................................ 70
15.1 ALI.XSD .......................................................................................................................................................... 70
15.2 ALITYPELIB.XSD ............................................................................................................................................. 70
15.3 ALI QUERY SERVICE DIRECTORY AND SCHEMAS ............................................................................................... 71
15.4 AQS AND AQS.WS REMOVED ......................................................................................................................... 71
15.5 MSAGRECORD.XSD ......................................................................................................................................... 71
16 I2 SCHEMAS .................................................................................................................................................. 72
08/12/2018 Page 4 of 119

16.1 GEOPRIV DIRECTORY AND SCHEMAS ................................................................................................................ 72

16.2 GML-3.1.1 DIRECTORY AND SCHEMAS ............................................................................................................ 72
16.3 ALL I2 SCHEMAS ............................................................................................................................................. 72
16.4 V2.XSD ........................................................................................................................................................... 73
16.5 V7.XSD ........................................................................................................................................................... 73
16.6 V8.XSD ........................................................................................................................................................... 74
16.7 V9.XSD ........................................................................................................................................................... 74
17 GIS DATA MODEL, VERSION 2.0 ............................................................................................................ 74
17.1 PREFACE ......................................................................................................................................................... 74
17.2 METADATA ...................................................................................................................................................... 74
17.3 9-1-1 SPATIAL ATTRIBUTES FOR LINE DATA ......................................................................................... 77
17.3.1 Centerline Layer (REQUIRED) ......................................................................................................... 77
17.3.2 Railroad Layer (Optional) ................................................................................................................. 81
17.3.3 Hydrology Layer (Optional) .............................................................................................................. 82
17.4 9-1-1 SPATIAL ATTRIBUTES FOR POINT DATA ...................................................................................... 82
17.4.1 Emergency Service Agency Location Layer (REQUIRED) ............................................................ 82
17.4.2 Cell Site Location Layer (REQUIRED) ............................................................................................. 84
17.4.3 Mile Marker Location Layer (Optional) ........................................................................................... 85
17.4.4 Railroad Grade Crossing Layer (Optional) ..................................................................................... 86
17.4.5 Site/Structure Location Layer (Optional) ....................................................................................... 86
17.5 9-1-1 SPATIAL ATTRIBUTES FOR POLYGON DATA ................................................................................ 88
17.5.1 County Boundary Layer (REQUIRED) ............................................................................................. 88
17.5.2 Emergency Service Zone Boundary Layer (REQUIRED) .............................................................. 88
17.5.3 Municipal Boundary Layer (REQUIRED) ......................................................................................... 89
17.5.4 Emergency Service Agency Boundary Layer (REQUIRED) .......................................................... 90
17.5.5 Cell Site Coverage Layer (REQUIRED) ........................................................................................... 91
17.5.6 Hydrology Polygon Layer (Optional) ............................................................................................... 93
18 NENA RECOMMENDED CLASSES OF SERVICE ................................................................................... 94
19 NENA RECOMMENDED SERVICE DESCRIPTIONS FOR CUSTOMER NAME/SERVICE FIELD96
20 NENA REGISTRY SYSTEM (NRS) CONSIDERATIONS ..................................................................... 99
21 DOCUMENTATION REQUIRED FOR THE DEVELOPMENT OF A NENA XML SCHEMA ............ 99
22 IMPACTS, CONSIDERATIONS, ABBREVIATIONS, TERMS, AND DEFINITIONS ..................... 99
08/12/2018 Page 5 of 119

22.1 OPERATIONAL IMPACTS SUMMARY.................................................................................................................... 99

22.2 TECHNICAL IMPACTS SUMMARY ........................................................................................................................ 99
22.3 SECURITY IMPACTS SUMMARY .......................................................................................................................... 99
22.4 RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK ............................................................................ 100
22.5 ANTICIPATED TIMELINE ................................................................................................................................. 100
22.6 COSTS FACTORS ............................................................................................................................................ 100
22.7 COST RECOVERY CONSIDERATIONS ................................................................................................................ 100
22.8 ADDITIONAL IMPACTS (NON-COST RELATED.................................................................................................... 101
22.9 ABBREVIATIONS, TERMS AND DEFINITIONS .................................................................................................... 101
23 RECOMMENDED READING AND REFERENCES ................................................................................ 116
ACKNOWLEDGEMENTS...................................................................................................................................... 117
08/12/2018 Page 6 of 119

NENA
STANDARD DOCUMENT
NOTICE
This Standard Document (STA) is published by the National Emergency Number Association
(NENA) as an information source for 9-1-1 System Service Providers, network interface
vendors, system vendors, telecommunication service providers, and 9-1-1 Authorities. It is not
intended to provide complete design or operation specifications or parameters or to assure the
quality of performance for systems that process such equipment or services.
NENA reserves the right to revise this Standard Document for any reason including, but not
limited to:
 Conformity with criteria or standards promulgated by various agencies,
 Utilization of advances in the state of the technical arts,
 Reflecting changes in the design of equipment, network interfaces, or services described
herein.
This document is an information source for the voluntary use of communication centers. It is
not intended to be a complete operational directive.
It is possible that certain advances in technology or changes in governmental regulations will

precede these revisions. All NENA documents are subject to change as technology or other
influencing factors change. Therefore, this NENA document should not be the only source of
information used. NENA recommends that readers contact their 9-1-1 System Service Provider
(9-1-1 SSP) representative to ensure compatibility with the 9-1-1 network, and their legal
counsel, to ensure compliance with current regulations.
Patents may cover the specifications, techniques, or network interface/system characteristics
disclosed herein. No license is granted, whether expressed or implied. This document shall not
be construed as a suggestion to any manufacturer to modify or change any of its products, nor
does this document represent any commitment by NENA, or any affiliate thereof, to purchase
any product, whether or not it provides the described characteristics.
By using this document, the user agrees that NENA will have no liability for any consequential,
incidental, special, or punitive damages arising from use of the document.
NENA’s Committees have developed this document. Recommendations for changes to this
document may be submitted to:
National Emergency Number Association
1700 Diagonal Rd, Suite 500
Alexandria, VA 22314
202.466.4911
or commleadership@nena.org
08/12/2018 Page 7 of 119

NENA: The 9-1-1 Association improves 9-1-1 through research, standards development,
training, education, outreach, and advocacy. Our vision is a public made safer and more
secure through universally-available state-of-the-art 9-1-1 systems and better-trained 9-1-1
professionals. Learn more at nena.org.
Document Terminology
This section defines keywords, as they should be interpreted in NENA documents. The form
of emphasis (UPPER CASE) shall be consistent and exclusive throughout the document.
Any of these words used in lower case and not emphasized do not have special significance
beyond normal usage.
1. MUST, SHALL, REQUIRED: These terms mean that the definition is a normative
(absolute) requirement of the specification.
2. MUST NOT: This phrase, or the phrase "SHALL NOT", means that the definition is
an absolute prohibition of the specification.
3. SHOULD: This word, or the adjective "RECOMMENDED", means that there may
exist valid reasons in particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing a different
course.
4. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" means that
there may exist valid reasons in particular circumstances when the particular
behavior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with
this label.
5. MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional.
One vendor may choose to include the item because a particular marketplace
requires it or because the vendor feels that it enhances the product while another
vendor may omit the same item. An implementation which does not include a
particular option “must” be prepared to interoperate with another implementation
which does include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option “must” be
prepared to interoperate with another implementation which does not include the
option (except, of course, for the feature the option provides.)
These definitions are based on IETF RFC 2119.
08/12/2018 Page 8 of 119

Intellectual Property Rights (IPR) Policy

NOTE – The user’s attention is called to the possibility that compliance with this
standard may require use of an invention covered by patent rights. By publication of this
standard, NENA takes no position with respect to the validity of any such claim(s) or of
any patent rights in connection therewith. If a patent holder has filed a statement of
willingness to grant a license under these rights on reasonable and nondiscriminatory
terms and conditions to applicants desiring to obtain such a license, then details may be
obtained from NENA by contacting the Committee Resource Manager identified on
NENA’s website at www.nena.org/ipr.
Consistent with the NENA IPR Policy, available at www.nena.org/ipr, NENA invites any
interested party to bring to its attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may be required to implement this
standard.
Please address the information to:
National Emergency Number Association
1700 Diagonal Rd, Suite 500
Alexandria, VA 22314
202.466.4911
or commleadership@nena.org
Reason for Issue/Reissue

NENA reserves the right to modify this document. Upon revision, the reason(s) will be
provided in this paragraph.
Document Number Approval Reason For Issue/Reissue
Date
NENA 02-010 v1 06/15/1991 Initial Document defined NENA Version 1 Data
Exchange Format. The original Version 1 Data
Exchange format was created to provide
established formats for exchange of 9-1-1 data
between Service Providers and the Data Base
Management System Providers. The format was
created in a fixed format with 232 characters
available within the record format for ALI source
data.
08/12/2018 Page 9 of 119


Date
NENA 02-010 v2 06/15/1993 NENA Version 2 Data Exchange Format created.
NENA 02-010 v3 06/30/1998 Version 1 has been changed to reflect current
terminology in format description fields.
Version 2 has been changed to Version 2.1 to
reflect new fields which reflect the “year 2000”
date identification and definition of the
Alternative Telephone Number “Alt #” field for
the “ALT#” associated with Interim Number
Portability, to identify the Function of Change
indicators of “U”nlock and “M”igrate for Local
Number Portability and to reflect current
terminology in format description fields. This will
be the last update to Version 2.
Version 3 Data Exchange Formats were added
June 1998 due to the difficulty in modifying
Version 2 standards. Version 3.0 has been
created to reflect data formats utilizing a “Tag
Data” concept, which creates a variable length
record dependent upon the data fields being
utilized between Service Providers and Data Base
Management System Providers. Version 3
formats include additional fields and updated
field names to better reflect industry trends.
NENA 02-010 v4 05/30/1999 This standard has been created to merge and
replace the original NENA 02-001 NENA
Recommended Formats for Data Exchange and
NENA 02-003 NENA Recommended Protocols for
Data Exchange into a common document to
facilitate ease of use based upon the user
community. There has been no intentional
change made to the existing standards. The
original standards documents 02-001 and 02-003
will be removed from service.
NENA 02-010 v5 01/22/2002 Version 3.0 formats were changed to Version 3.1
with the introduction of Version 4, and the need
08/12/2018 Page 10 of 119


Date
to change existing labels and add new labels due
to technology changes.`
This standard has been updated with a Version 4
Data Exchange that is based on Version 3.1 tags
with XML formatting. Version 3.1 and Version 4
tags are meant to be mirrors of each other with
the only difference being the tag versus XML
formatting. This document has also been
updated with Version 1.0 of the GIS Data Model
Format and Version 1.0 of the Format for Data
Exchange between ALI Database and PSAP
Controller Equipment.
Version 4 Data Exchange Format is an industry

standard XML data format. NENA XML (Extensible
Markup Language) documents have been
adapted from Standard Generalized Markup
Language (SGML) by the World Wide Web
Consortium. Version 4 Data Exchange Format
was created to bring the NENA Data Exchange
Format in line with industry standard
implementation methods, to introduce versioning
control and promote reusability of previous work.
All existing NENA 4 information has been
removed from this document and moved to an
easily accessible area on the NENA web site.
http://www.nena.org/xml_schemas/nena.htm.
NENA 02-010 v6 11/09/2004 The NENA Version 4 XML Data Exchange Format
has been revised to include:
 Industry standard tag naming conventions
 A schema library document to define XML
tag names and their respective data types
 An XML schema document for use in
validation of XML documents
08/12/2018 Page 11 of 119


Date
 A redesigned XML schema to promote the
reusability of defined XML data structures.
 A process that will allow changes to
existing data definitions that will not
require reprogramming of applications.
 Establishment of Generation and
Release control methods that promotes
backward compatibility
The Data Provider ID (Company ID 2) field is
used to carry the NENA Company ID of a
PS/911data provider or a reseller. The NENA
Reserved field has been reduced by 5 bytes to
accommodate the Data Provider ID (Company ID
2) field. In addition the “Company ID” field that
represents the “Company ID 1” field has been
renamed to Access Infrastructure Provider ID and
the definition clarified.
NENA 02-010 v7 02/25/2006 Established new Classes of Service for VoIP.
There have been 4 types of VoIP users identified:
1. Fixed (static) - VoIP service sold as not
having nomadic capability
2. Enterprise – Internet Protocol Private
Branch Exchange (IP PBX), VoIP service
sold as not having nomadic capability
3. Nomadic – VoIP service that has the
capability to be moved
4. Mobile – example: like wireless, designed
to operate from multiple locations
Seven new Class of Service have been identifies
for VoIP. With the understanding that most VoIP
providers do not have the capability of delivering
the specific Class of Service at this time, a default
Class of Service has been developed.
08/12/2018 Page 12 of 119


Date
V = VoIP Services default Class of Service.
(preferably with VOIP being displayed at the
PSAP)
The other new Class of Service one byte
characters are:
 C= VoIP Residential (preferably with VRES
being displayed at the PSAP)
 D= VoIP Business (preferably with VBUS
 E = VoIP Coin/Pay Phone (preferably with
VPAY being displayed at the PSAP)
 F = VoIP Wireless (preferably with VMBL
 J = VoIP Nomadic (preferably with VNOM
 K = VoIP Enterprise Solutions –Centrex &
PBX (preferably with VENT being displayed
at the PSAP)
All VoIP Class of Service are for both static and
nomadic services with the exception of J=VoIP
Nomadic. This will be used when a customer is
moving from one location to another and is
unsure of the class of service they SHOULD be
using at that time, as it is different than their
normal/predominant class of service.
Exhibit 22 (now Section 17) for GIS mapping
was unintentionally omitted from the last version
of the 02-010 document. Exhibit 22 (now
Section 17) has been re-inserted into this
version; no changes were made to Exhibit 22
(now Section 17).
New Class of Service for Wireless Phase II –
added CoS “I” that tells the PSAP the call is from
08/12/2018 Page 13 of 119


Date
a Phase II capable service, but only phase I
information was available. Re-bid ALI for phase
II information. Note, re-bid will not guarantee
phase II information will be provided.
XML Release 4.1 to accommodate i2 standard
which was developed by NENA to handle VoIP
calls in the current E9-1-1 system. The i2
directory includes schemas used by the i2 web
services definitions (WSDL) as well as the i2
WSDL.
http://www.nena.org/xml_schemas/nena.htm
NENA 02-010 v8 03/30/2007 Establish Function of Change for Master Street
Address Guide (MSAG) Data Exchange
Function of Change for MSAG options:
Insert a range:
 FOC=I defines the current image to be
inserted
Delete a single range:
 FOC=D defines the current image to be
deleted
Place footer in document with reference to name
formatting when sending in data to the DBMS.
Last, First format is the recommended format for
residential customer names.
The document name has been changed to reflect
the new NENA ALI Query Service standard; the
document describes data formats and not
protocols.
The ALI Query Service Standard is available at
https://www.nena.org/?page=ALI_Query_Service
The formal document name is “04-005 NENA ALI
Query Service Standard”.
08/12/2018 Page 14 of 119


Date
NENA 02-010 v8.1 01/08/2008 Correction to MSAG Data exchange reserved field
length.
The reserved field should have been shortened 1
character due to the addition of FOC in Revision
8.
NENA 02-010 v8.2 06/10/2009 Updated all Uniform Resource Locators (URLs) to
agree with new web pages.
NENA 02-010 v9 12/16/2010 Modified Exhibit 22 (now Section 17), GIS Data
Model, Version 2.
Updated to most current template by adding the
following new sections:
22.3 SECURITY IMPACTS SUMMARY
22.4 RECOMMENDATION FOR ADDITIONAL
DEVELOPMENT WORK
22.8 Additional Impacts (non cost related
NENA-STA-015.10-2018 08/12/2018 Five new CoS for potential use have been added,
WDL2, WDL1, WCVC, TEXT, and SDXY. New
Section 2.2 established three new wireless CoS
(WDL2, WDL1, and WCVC) for use when a
wireless 9-1-1 call provides civic oriented data
from the National Emergency Address Database
(NEAD) and potentially other scenarios, such as
pre-provisioned carrier small cells, customer
femtocells, or non-mobile phones using wireless
network connectivity. New Section 2.2 also
established a new CoS of TEXT for text-to-9-1-1,
and established a new CoS of SDXY for
supplemental geodetic location from third-party.
The “Customer Name” field has been renamed as
the “Customer Name/Service” field to reflect
current usage, and to accommodate the seven
standardized “Service Descriptions” and to
provide an additional signal to the
telecommunicator to pay attention to both x, y
08/12/2018 Page 15 of 119


Date
coordinates and civic address. In addition, also
specified that the existing “VoIP Wireless”
(VMBL) CoS established in 2006 SHOULD be set
up to work similar to WPH2 x, y coordinates in
the context of non-CMRS and wireless IP
services, and SHOULD also be renamed as “Other
Mobile,” OMBL. In order to have a clear single
up-to-date reference for all currently recognized
CoS (which would now also include WDL2,
WDL1, WCVC, TEXT, SDXY, and OMBL), a new
Section 18 has been added, and a new Section
19 has been added to also have a clear single
up-to-date reference for standardized “Service
Descriptions” in the Customer Name/Service
field. In addition, the numbering in the
document was modified to be consecutive and
consistent with obsoleted versions.
08/12/2018 Page 16 of 119

2 Technical Description
2.1 Types of Data Exchange Formats

All data exchange formats utilize American Standard Code for Information Interchange
(ASCII) characters. The NENA Data Technical Committee has established 4 versions of
standard data formats for use by Service Providers and Data Base Management System
Providers when exchanging E9-1-1 data base information. Four (4) versions of standard
format have been defined for each of the following; ALI source data exchange, Master
Street Address Guide (MSAG) data exchange, Header and trailer records, Wireless data
formats are included in Versions 3.1 and 4.
Historically, standard format Version 1.0 had been defined for the ALI Request Response
message sent to the PSAP screen.
Version 1 formats were the original NENA recommended formats utilizing the 240 character
format for Data Exchange; 160 character format for MSAG Data Exchange and 160
character format for Header and Trailer records.
Version 2 formats recognized that the original formats needed to be expanded to
accommodate additional data fields critical to some data providers and also recognized that
NENA should position the standard record for the future. Version 2 formats contained all
data fields resident in Version 1 formats utilizing a 512 character format for Data
Exchange; 200 character format for MSAG Data Exchange and 200 character formats for
Header and Trailer records. However, both Version 1.0 and 2.0 are obsolete and have been
replaced by Version 2.1. See Sections 3 and 4.
Version 3 formats recognize that the previous formats were limiting distribution of data as
technology evolved and the Data Technical Committee, after much discussion, arrived at
the present NENA Version 3 format, included in this document. This format takes a “Tag
Data” approach to information exchange for both wireline and wireless data distribution.
Benefits include flexibility, faster programming changes, more efficient data transmission
and smaller file sizes.
Version 4 formats recognize the need for an industry standard naming convention, greater
flexibility and faster programming changes. NENA Version 4 has been revised to support
these needs and to introduce reusability of defined data elements, a method to introduce
Schema changes that are backward compatible and do not impact operating applications.
This revised XML format can be supported by off the shelf XML tools to perform proper
validation of XML documents. The revised NENA Version 4 establishes a design philosophy
for all new XML schema and data development.
08/12/2018 Page 17 of 119

The NENA Data Technical Committee requires that Service Providers maintain consistency
by utilizing formats consistent to one version; i.e. Header and Trailer records MUST be the
same version format as the Data or MSAG Exchange formats utilized. It should be noted
that some things in the past may not have been clearly defined in E9-1-1 (e.g., Customer
Name and Street Address fields potentially containing special characters), and this may
create additional potential translation complications between E9-1-1 and NG9-1-1, which
may also include translation complications for voice-based texting between E9-1-1 and
NG9-1-1 (compare, “@” in Real-Time Text (RTT) with “(at)” in TTY). Prospectively, 9-1-1
stakeholders making changes to E9-1-1 are urged to be sensitive to any potential
complications such changes may have for the transition to NG9-1-1.
2.1.1 Common Considerations:

All data exchange formats utilize ASCII characters. ASCII characters used in alpha only and
alpha/numeric fields SHOULD be limited to A thru Z, a thru z (some legacy systems will not
understand lower case), 0 thru 9, comma ‘, ’, forward slash ‘ / ’, semi colon ‘; ‘, ampersand
‘&’, and apostrophe ‘ ’ ’. Spaces are allowed with one exception----the first character of a
field may not be a space. Spaces between words are acceptable. Other characters may
impact the accurate processing of data.
Data Base Management System Providers SHOULD document how they utilize versions 1,
2, 3 and 4 and the fields that their software systems can utilize.
The “General Use” field may be used when exchange partners agree to exchange
information not defined.
Header and Trailer records MUST be the same version format as the Data or MSAG
Exchange formats utilized.
A full update record MUST be provided for all data exchange versions and function-of-
change updates.
Data TYPE indicators are as follows: A= Alpha, N=Numeric, V=Variable, AN=Alpha
Numeric, AV=Alpha Variable
2.1.2 Version 1 & 2 formats:

 Standard field location.
 Fixed record lengths.
 Data exchange formats require that complete data records be exchanged.
 All data fields are treated as “left-justified” with trailing spaces.
 Unused fields are space-filled.
08/12/2018 Page 18 of 119

2.1.3 Version 3 data formats:

 A tag data record is a record of varying length, comprised of pre-defined tag labels
and the associated data elements.
 There is no particular sequence of the tag/data combinations within a Tag Data
Record.
 Each tag and its associated data are separated from all other tag/data combinations
by a pre-defined field separator.
 A pre-defined End of Record character follows each Tag Data Record.
 The receiving Data Base Management System Provider will specify the minimum set
of tag/data elements needed by that system to uniquely identify and process the
record.
 If the field is not being used (I.E: “Street Suffix”, “Post Directional”, “Customer
Code”) then the label is not used.
 Data Technical Committee authorized new tags may be added to the record without
changing the file format.
 Header records will employ cycle counting to ensure a cycle of updates is not
missed.
 Trailer records will employ record counting to ensure a record within an update file
is not missed.
2.1.4 Version 4 Description Summary:

 Tags are angled brackets with the data between them. An example of a start-tag
and end-tag is <NAM></NAM>.
 Content is the data between the start-tag and end-tag.
 An Element is the combination of start-tag, data and end-tag. An example of an
element is <NAM>JOHN DOE</NAM>.
 Tags can have Attributes. An example is <RECORD Num=”1”> which indicates that
the elements for record number 1 follow this tag.
 Elements may contain other elements. A “StreetAddressType” is an example of
container element with sub-elements in a group that identify the component parts
for a street address and can be reused wherever a “StreetAddressType” element is
needed.
08/12/2018 Page 19 of 119

<xs:complexType Individual components or

name=”StreetAddressType”> elements that make up a street
address are housed is a
<xs:all>
container element called
<xs:element name=”HouseNum”/> StreetAddressType.
<xs:element name=”HouseNumSuffix/>
<xs:element name=”PrefixDirectional/> This example is intended to
<xs:element name=”StreetName”/> show how related data
elements may be grouped
<xs:element name=”StreetSuffix/> together and is not intended
<xs:element name=”PostDirectional”/> to be accurate in form or
structure.
<xs:element
name=”MSAGCommunity”/>
<xs:element Refer to the actual XML
name=”PostalCommunity”/> documents located on the NENA
web site at
<xs:element name=”StateProvince”/>
http://www.nena.org/xml_sche
<xs:element name=”County”/> mas/nena.htm
<xs:element name=”TARCode”/>
<xs:element name=”PostalZipCode”/>
</xs:all>
</xs:complexType>
 In XML, records are referred to as “documents”.

 The XML schema defines the structure, sequence and needed elements within an
XML document.
 The receiving Data Base Management System provider will determine the minimum
set of elements needed by that system to uniquely identify and process the record.
 If the data is not being used (I.E: “Street Suffix”, “Post Directional”, “Customer
Code”) then the Element may be omitted.
 If data is present in an XML data element but the receiving Database Management
System does not use the data element, the receiving Database Management System
will ignore it.
08/12/2018 Page 20 of 119

 Version 4 utilizes Generation and Release controls. A Release is a subset of a

Generation. A Release may be changed such as adding new tags without effecting
working applications. Generation changes will affect backward compatibility. A
schema from a newer Generation cannot be used to validate documents from a
previous Generation. The NENA Data Technical Committee will coordinate all
Generation and Release changes.
 Header elements will employ cycle counting to ensure a cycle of updates is not
missed.
 Trailer elements will employ record counting to ensure a record within an update file
is not missed.
 Supporting documentation for the most current and all previous XML schema
Generations and Release s will be available on the NENA web site.
 This document does not contain a complete description of XML elements and
features.
 Details on each XML Generation, Release, Element Type Definition and Schema
documentation is available on the NENA web site at
http://www.nena.org/xml_schemas/nena.htm. More information on XML may be
found at http://www.w3.org/XML/.
2.2 Types of Data Elements within Data Formats and Additional

Guidance
In the past, there were clearer dividing lines and less convergence between different
networks and technologies, and there was much less room for reasonable interpretation
regarding when and how to use certain data elements, with CoS and the Customer Name
field being primary current examples. In addition, there may also be increased potential
for the provision of location information from a third-party that is separate from the
mandatory location required by applicable regulation from the wireless carrier/originating
service provider. Without some additional guidance and explanation on the data elements
within the data formats, the primary purpose and use of the data formats can be
undermined and erode data exchange and usefulness of these legacy data formats.
Therefore, additional guidance is needed and provided herein in the following subparts on
when and how to use the data elements within the data formats in a more standardized
manner.
08/12/2018 Page 21 of 119

2.2.1 Additional Guidance on the three Classes of Service for Wireless Network
Services displaying Civic Address as Primary ALI
Three new wireless CoS are being established for use when a wireless 9-1-1 call provides
civic oriented data from the National Emergency Address Database (NEAD) and from other
sources. The three are as follows:
 WDL2 indicates a wireless 9-1-1 call that provides civic oriented data (address
and sub-address location [where appropriate]) in addition to traditional WPH2
geodetic X, Y and Uncertainty data associated with the caller’s location (where
available). When this CoS is used, it indicates the civic oriented data is expected
to meet the highest quality level criteria to be dispatchable, and indicates that the
sub-address location within the building address is very close to the caller’s
location.
 WDL1 indicates a wireless 9-1-1 call that provides civic oriented data (address
and building zone [where appropriate]) in addition to traditional WPH2 geodetic
X, Y and Uncertainty data associated with the caller’s location (where
available). When this CoS is used, it indicates the civic oriented data is expected
to meet the medium-quality level criteria to be dispatchable by building zone but
also indicates a less detailed location than WDL2.
 WCVC indicates a wireless 9-1-1 call that provides civic oriented data (address) in
addition to traditional WPH2 geodetic X, Y and Uncertainty data associated with
the caller’s location (where available). When this CoS is used, it indicates the
civic oriented data is not expected to meet the criteria to be dispatchable by
either building zone (WDL1) or sub-address location (WDL2).
With regard to these three new CoS for wireless network services displaying civic address
as the primary ALI, the current implementation expectation is for 9-1-1 customer premises
equipment (CPE) to use existing ALI display fields. But other implementation issues (such
as the specific location logic between the three CoS quality levels using the criteria from
the NEAD, additional telecommunicator training, integration and relationship with display of
the WPH1 cell tower location, and potential changes to 9-1-1 mapping configurations)
SHOULD remain under review for additional work, testing, and further recommendations by
NENA and other stakeholders. Moreover, as the quality level of WPH2 location indoors may
be enhanced in the future independent from the NEAD, there may be additional factors to
consider down the road on such implementation issues.
08/12/2018 Page 22 of 119

2.2.2 Additional Guidance to rename the “Customer Name” field to “Customer

Name/Service” field and on standardized “Service Descriptions”
While long called the “Customer Name” field in NENA documents, for over a decade
wireless 9-1-1 calls have included the name of the facilities-based wireless service provider
(and sometimes their contact telephone number as well). The field has been used to
indicate “Fixed” in the case of a customer femtocell, to indicate “@Home” in the case of a
UMA device, and to indicate more recently sometimes “Verify,” “HotSpot,” and/or “Wi-Fi
Calling” separately or in combination as may have been be chosen by the applicable
wireless carrier and/or 9-1-1 authority.
Instead of using term “Customer Name” for the field, using “Customer Name/Service” is
more consistent with how the field has been used and how it may be used in the future.
Accordingly, in Section 5 and Section 9, the name of the field has been changed to
“Customer Name/Service” and a new Section 19 with seven standardized Service
Descriptions for the Customer Name/Service field has been added to this document. The
recommended Service Descriptions in Section 19 may be used alone or in combination with
end user customer name or service provider name. Where more than one of the above
may apply, it is generally recommended that the one presenting the highest level quality of
location information SHOULD be used in the event of a conflict. However, unnecessarily
combining Service Descriptions or using non-standardized Service Descriptions can lessen
usefulness and SHOULD be avoided. Therefore, it expected that any existing uses of non-
standardized Service Descriptions will promptly be reviewed by 9-1-1 stakeholders, and
thereafter inconsistent descriptions (with the seven identified in Section 19) should stop
being used.
2.2.3 Additional Guidance on Customer Name/Service field and standardized

“Service Descriptions” for Wireless Network Services displaying Civic
Address as Primary ALI
In order to help clarify and provide an additional signal to the telecommunicator to pay
attention to both the x, y coordinates and the civic address, it is recommended that where
the end user subscriber name is not placed in the Customer Name/Service field (or in
addition to it, if applicable), the Customer Name/Service field SHOULD include displaying
“WRLSW/ CIVIC SPECIFIC” for the WDL2 CoS; WRLS W/ CIVIC ZONE for the WDL1 CoS;
and WRLS W/ CIVIC RANGE for the WCVC CoS. Accordingly, the three new CoS of WDL2,
WDL1, and WCVC are in Section 18 and three standardized Service Descriptions are in
Section 19.
08/12/2018 Page 23 of 119

2.2.4 Additional Guidance on CoS and on Customer Name/Service field and

standardized “Service Description” for Wireless Carrier Small Cells
In 2013, per ATIS-0500025, for purposes of only the E2 interface in J-STD-036-C-2, the
FIXD classification was introduced associated with position source 53 for provisioning a
small, semi-static wireless cell covering areas less than 100 meters, in cases where civic
address information would be provisioned as additional secondary information. The
purpose of the ATIS recommendation was to provide an additional signal to the
telecommunicator to pay attention to both the x, y coordinates and the civic address.
However, since that time the FCC has adopted rule amendments with specifics on wireless
carriers providing dispatchable location or x, y coordinates within 50 meters as primary ALI.
Accordingly, rather than establishing a new CoS for small cells, it is recommended that:
(1) Where a dispatchable location would be displayed as primary ALI of the caller, either
WDL2 or WDL1 should be used, as applicable, based on the specific location logic
between WDL2 and WDL1 under the criteria for the NEAD (potentially via translating
either the FIXD or RESD classification associated with position source 53 or 54).
(2) Where x, y coordinates would still remain as primary ALI of the caller and for cases
where the small cell coverage area is generally believed to be 50 meters or less and
where the end user subscriber name is not placed in the Customer Name/Service
field (or in addition to it, if applicable) associated with the WPH2 CoS, the Customer
Name/Service field SHOULD include displaying ““INDOOR SMCELL/DAS HEAD.” See
Section 19.

standardized “Service Description” for Customer Femtocells
As of the adoption of the revisions of this to document, at least one wireless carrier deploys
customer femtocells that also display pre-provision location civic address information as
additional, secondary information and uses the Customer Name/Service field to provide an
additional signal to the telecommunicator to pay attention to both the x, y coordinates and
the civic address. However, as wireline replacement continues, customer femtocells may
start to display civic address information as primary ALI. Accordingly, rather than
establishing a new CoS for customer femtocells, it is recommended that:
(1) Where a dispatchable location would be displayed as primary ALI of the caller, either
WDL2 or WDL1 should be used, as applicable, based on the specific location logic
between WDL2 and WDL1 under the criteria for the NEAD (potentially via translating
either the FIXD or RESD classification associated with position source 53 or 54).
(2) Where x, y coordinates would still remain as primary ALI of the caller and for cases
where the customer femtocell coverage area is generally believed to be 50 meters
or less and where the end user subscriber name is not placed in the Customer
08/12/2018 Page 24 of 119

Name/Service field associated with the WPH2 CoS, the Customer Name/Service field
SHOULD include displaying “FEMTOCELL.” See Section 19.
2.2.6 Additional Guidance on Customer Name/Service field and standardized

“Service Description” for Wi-Fi Calling
As of adoption of the most revision of this document, at least three nationwide wireless
carriers put “WI-FI CALLING” in the Customer Name/Service field. In the current context,
when “WI-FI CALLING” is being displayed in the Customer Name/Service field, a mobile
handset’s ability to actually be mobile may be very limited during a 9-1-1 call, and the end
user moving the mobile handset outside this limited area may disconnect the caller using
Wi-Fi calling from a mobile handset for 9-1-1 calls. For purposes of troubleshooting issues,
Wi-Fi Calling the Customer Name/Service field may also assist the service provider in
identifying the specific network. The type of location information with 9-1-1 calls using Wi-
Fi connectivity today may be similar to wireless 9-1-1, may be similar to Interconnected
VoIP, may vary based on circumstances or service provider, and may involve Wi-Fi 9-1-1
calling from tablet as opposed to a mobile handset. Accordingly, due to the current
potential locations situations and scenarios, because the caller may be disconnected if they
were to become mobile with the mobile handset or tablet, and for potential troubleshooting
purposes, including “WI-FI CALLING” in the Customer Name/Service field provides
additional context information. See Section 19.

standardized “Service Description” for Wireless Home Phones
As of adoption of the most recent revision of this document, there is no information that
informs telecommunicators that the x, y coordinates from a Wireless Home Phone (WHP) is
not from a generally mobile handset but rather is instead from an adapter that may be
nomadic or static but generally not mobile (unless perhaps in moving motor home). In
addition, for purposes of only the E2 interface in J-STD-036-C-2, the RESD classification
had been introduced associated with position source 54 for provisioning a static wireless
device at a residential location. However, as wireline replacement continues, WHPs may
start to display civic address information as primary ALI. Accordingly, rather than
establishing a new CoS for WHPs, it is recommended that:
(1) Where a dispatchable location would be displayed as primary ALI of the caller using
a wireless 9-1-1 solution, either WDL2 or WDL1 should be used, as applicable, based
on the specific location logic between WDL2 and WDL1 under the criteria for the
NEAD (potentially via translating either the FIXD or RESD classification associated
with position source 53 or 54).
(2) Where a dispatchable location would be displayed as primary ALI of the call using a
VoIP 9-1-1 solution, the applicable VoIP CoS should be used, and where the end
08/12/2018 Page 25 of 119

user subscriber name is not placed in the Customer Name/Service field, use of
“NON-MOBILE PHONE” in the Customer Name/Service field should be considered to
provide additional context information.
(3) Where x, y coordinates would be displayed as primary ALI of the caller using a
wireless 9-1-1 solution and WPH2 is used for the CoS, use of “NON-MOBILE PHONE”
in the Customer Name/Service field should be considered to provide additional
context information. See Section 19.
2.2.8 Additional Clarification and Guidance on the Existing VoIP Wireless

(VMBL) CoS and Replacement with a new CoS of Other Mobile (OMBL)
In the past, there appeared to be clearer dividing lines and less potential for confusion or
varying interpretation regarding when a particular CoS SHOULD be associated with x, y
coordinates as the primary location for CPE and mapping purposes (e.g., the WPH2 CoS
and CMRS service under FCC Rule 20.18) compared to when a particular CoS SHOULD be
associated with civic address as the primary location for CPE and mapping purposes (e.g.,
the VOIP CoS and Interconnected VoIP service under FCC Rule 9.5). In 2006 when the
“VoIP Wireless” was incorporated into this document as a new CoS, there being no
definition of “VoIP Wireless” and there was also no statement or guidance whether x, y
coordinates or civic address were to be the primary address location for CPE and mapping
purposes. In addition in late 2015, the FCC approved waivers for Wi-Fi calling (also called
Voice over Wi-Fi) and there is also a growing greater potential for over the top (OTT) voice
over a wireless broadband network from Applications separate from the underlying wireless
network carrier. Accordingly, with regard to the existing “VoIP Wireless” (VMBL) CoS
established in 2006, to the extent it continues to be used it is clarified to be expected to
work similar to WPH2 x, y coordinates in the context of non-CMRS and wireless IP services.
In other words, to the extent it continues to be used the existing VMBL CoS is clarified to
be used with x, y coordinates being the primary expected address location for CPE and
mapping purposes, but civic address information MAY also be displayed when providing
civic address information is believed to be within 50 meters. However, given that the term
VoIP is generally associated with civic address as the primary location and given that Wi-Fi
calling and OTT voice over wireless broadband may have differences from legacy CMRS
services (e.g., potentially no WPH1 cell tower information may be presented, potentially
rebid may return no additional results, and potentially existing CMRS regulations may not
be applicable or may ultimately be adopted to be different from legacy CMRS services),
replacement of the VMBL CoS with a CoS of “OMBL” for “Other Mobile” would be a more
PREFERABLE way to distinguish such from legacy CMRS even though the services may be
similarly mobile and present x, y coordinates as the primary location. (For non-mobile and
nomadic services with a civic address as the primary location using those same Wi-Fi
calling or OTT voice using wireless broadband separate from the underlying wireless carrier
08/12/2018 Page 26 of 119

network, the existing VNOM CoS would be considered most appropriate and other VOIP
CoS considered appropriate as well.) Accordingly, it is recommended that a CoS of OMBL
replace the existing CoS of VMBL when x, y coordinates are to be primary location from
non-legacy CMRS types of technologies that are separate from the underlying wireless
carrier network.
2.2.9 Additional Guidance on new CoS for Supplemental Geodetic Location from
Third-Party (SDXY) CoS
The SDXY CoS is intended to be used to identify the provision of location information that
is provided by a third-party separate from the mandatory location required by applicable
regulation from the wireless carrier/originating service provider. The SDXY CoS indicates
supplementary geodetic location information (with confidence and uncertainty data) as the
primary location type for mapping purposes (similar to WPH2 CoS and OMBL CoS where
geodetic location is the primary location information, respectively, from a wireless carrier or
an Interconnected VoIP originating service provider), and the SDXY CoS indicates the use
of an IP network to transmit location information from the device to a third-party location
provider separately from the call. The SDXY CoS geodetic location is intended to be
derived from commercial-grade device-based hybrid location technologies, and may be
enriched by other handset-based location technologies where considered appropriate by
the third-party location provider. It is expected that the SDXY CoS geodetic location data
from the third-party provider may allow for manual and/or automatic updates subject to
capabilities of customer-premises equipment to perform such requests.
08/12/2018 Page 27 of 119

3 NENA V1.0
VERSION 1.0 FORMAT FOR DATA EXCHANGE
VERSION 1.0 FORMAT FOR MSAG DATA EXCHANGE
VERSION 1.0 HEADER FORMAT FOR DATA EXCHANGE
VERSION 1.0 TRAILER FORMAT FOR DATA EXCHANGE
Have Been Replaced by Version 2.1 Formats
4 NENA V2.0
VERSION 2.0 FORMAT FOR DATA EXCHANGE
VERSION 2.0 FORMAT FOR MSAG DATA EXCHANGE
VERSION 2.0 HEADER FORMAT FOR DATA EXCHANGE
VERSION 2.0 TRAILER FORMAT FOR DATA EXCHANGE
Have Been Replaced by Version 2.1 Formats
08/12/2018 Page 28 of 119

5 VERSION 2.1 FORMAT FOR DATA EXCHANGE

FIELD NAME POSITION BYTES TYPE DESCRIPTION
Function Code 1 1 A Type of activity the record is being
submitted for. Valid entries:
C = Change
D = Delete
I = Insert
U = Unlock
M = Migrate
NPA 2-4 3 N Three-digit area code (Number Plan Area) of
the Calling Number.
Calling 5-11 7 N Seven-digit telephone number of the Calling
Number Number.
House 12-21 10 AN House number. The field SHOULD be space
Number filled if no house number is available.
NOTE: Although the House Number field is

ten characters, it is understood that
telephone companies MAY only support up
to 8 characters.
House 22-25 4 AN House number extension (e.g. ½). The
Number Suffix field SHOULD be space filled if no suffix
applies.
Prefix 26-27 2 A Leading street direction prefix. The field
Directional SHOULD be space filled if no prefix applies.
Valid entries:
N S E W
NE NW SE SW
Street Name 28-87 60 AN Valid service address of the Calling Number.
08/12/2018 Page 29 of 119


Street Suffix 88-91 4 A Valid street abbreviation, as defined by the
U. S. Postal Service Publication 28, Appendix
C. (e.g. AVE)
Post 92-93 2 A Trailing street direction suffix. The field
Directional SHOULD be space filled if no suffix applies.
Valid entries:
N S E W
NE NW SE SW
Community 94-125 32 A Valid service community of the street
Name name/house number as designated by the
MSAG.
State 126-127 2 A Alpha state abbreviation (e.g. TX)
Location 128-187 60 AN Additional address information (free
formatted) describing the exact location of
the Calling Number (e.g. Apt 718).
Customer 188-219 32 AN Subscriber name associated with the Calling
Name/Service Number. Preferred format for an individual
customer name (not a business) is: Last,
First and, optionally, a suffix which may be
generation (Jr, III) and/or title (Phd, Esq,
MD). Honorifics (Mr., Mrs, Ms.) SHOULD
not be included as part of the name.
Alternatively, in order to provide the
telecommunicator with an additional signal
to pay attention to both the x, y coordinates
and the civic address (and/or where the
individual customer name is not provided)
and to provide other clarifying service type
information in a standardized manner, the
field MAY be used in a standard way by
carriers, with specific standardized “Service
Descriptions.” See Sections 2.2 and 19 of
this document.
08/12/2018 Page 30 of 119


Class of 220 1 AN Value of:
Service 1 = Residence 8 = Mobile
2 = Business 9 = Residence
OPX
3 = Residence 0 = Business
PBX OPX
4 = Business PBX A = Customer
Owned Coin
Telephone
(COCT)
5 = Centrex B = Not Available
Footnote 4
6 = Coin 1 Way G = Wireless
out Phase I
7 = Coin 2 Way H = Wireless
Phase II
I = Wireless
Phase II with
Phase I
information
V = VoIP C = VoIP
Services Residence
Default CoS
D = VoIP E = VoIP
Business Coin/Pay
Phone
F = Other Mobile J = VoIP
Nomadic
K = VoIP For all VoIP
Enterprise CoS see
Services – notes on
Centrex & page 13
PBX
08/12/2018 T = Telematics Page 31 of 119


Type of 221 1 N Value of:
Service 0 = Not FX (Foreign Exchange Service)
nor Non-Published
1 = FX in 911 serving area
2 = FX outside 911 serving area
3 = Non-Published
4 = Non-Published FX in serving area
5 = Non-Published FX outside 911
serving area
6 = Local Ported Number (LNP) (Local
Number Portability)
7 = Interim Ported Number
Exchange 222-225 4 AN Local Exchange Carrier exchange identifier
for the serving telephone office of the
customer.
ESN 226-230 5 AN Emergency Service Number associated with
the House number and Street Name.
NOTE: ESN field may be space filled when the Data
Base Management System Provider is validating the
address. The Service Provider providing the E9-1-1
Selective Routing will provide a list of ESNs available
for assignment.
Main NPA 231-233 3 N Three-digit area code of the Main Number
associated with the Calling Number.
Main Number 234-240 7 N Seven Digit telephone number of the Main
Number associated with the Calling Number.
Order 241-250 10 AN Service order number for the activity
Number establishing this record.
Extract Date 251-256 6 N Date on which the record was created in the
format MMDDYY
08/12/2018 Page 32 of 119


County ID 257-260 4 AN County Identification Code (usually the FIPS
code)
NOTE: County Identification field is used to
identify the county of call origination. The
Subcommittee recommends use of the FIPS
code assigned to each county by the U S
Census Bureau.
Access 261-265 5 AN NENA registered Company Identification
Infrastructure code of the Access Infrastructure Provider
Provider
(Company ID
1)
Source ID 266 1 AN Code that indicates whether data is part of
the initial data base creation process or part
of the daily update process.
Daily = Space, Initial Load = C
Zip Code 267-271 5 AN Postal Zip Code
Zip + 4 272-275 4 AN Postal Zip Code Extension
General Use 276-286 11 AN This field will be mutually used by data
exchange partners to pass information not
defined in previous fields.
Customer 287-289 3 AN Code used to uniquely identify a customer.
Code
Comments 290-319 30 AN Optional notes, MAY be displayed at PSAP
X Coordinate 320-328 9 AN Longitude/ X coordinate
Y Coordinate 329-337 9 AN Latitude/ Y coordinate
Z Coordinate 338-342 5 AN Structure elevation (This is not intended to
include floor level or uncompensated
barometric pressure.)
Cell ID 343-348 6 AN Cellular Identification Number indicating a
geographic region of cellular coverage.
08/12/2018 Page 33 of 119


Sector ID 349 1 AN Sub set/section of a cell.
TAR Code 350-355 6 AN Taxing Area Rate Code
Reserved 356-376 21 AN This field is reserved for the Data Base
Management System Provider’s use.
ALT # 377-386 10 N Customer Number being remote call
forwarded in Interim Number Portability
service.
Expanded 387-394 8 N Date on which the record was created in the
Extract Date format YYYYMMDD
NENA 395-475 81 AN This field is reserved for NENA Data
Reserved Technical Committee Assignment
Data Provider 476-480 5 AN NENA registered Company Identification
(Company ID code of the Data Provider (Note 1)
2)
Reserved 481-511 31 AN This field is reserved for the Data Base
Management System Provider’s use.
End of Record 512 1 AN Always an asterisk (*).
NOTE: All fields are left justified, with trailing spaces.

The Service Provider providing E9-1-1 Selective Routing MUST
provide the governmental entity with a list of ESNs available for
assignment by MSAG development personnel.
NOTE 1:The Data Provider ID (Company ID 2) field is used to carry the

NENA Company ID of a PS/911 data provider. The NENA
Reserved field has been reduced by 5 bytes to accommodate the
Data Provider ID field. In addition the “Company ID” field that
represents the Dialtone Provider NENA Company ID has been
renamed to “Access Infrastructure Provider ID” (Company ID 1)
and the definition clarified.
08/12/2018 Page 34 of 119

6 VERSION 2.1 FORMAT FOR MSAG DATA EXCHANGE
NAME POSITION BYTES TYPE

Prefix Directional 1-2 2 AN
Street name 3-62 60 AN
Street Suffix 63-66 4 AN
Post Directional 67-68 2 AN
Low Range 69-78 10 AN
High Range 79-88 10 AN
Community Name 89-120 32 A
State 121-122 2 A
Odd/Even 123 1 O, E or B
ESN 124-128 5 AN
Extract Date 129-134 6 MMDDYY
PSAP ID* 135-138 4 AN
County ID 139-142 4 AN
Exchange 143-146 4 AN
General Use 147-166 20 AN
TAR Code 167-172 6 AN
Function of Change 173 1 A
Reserved 174-191 18 AN
Expanded Extract Date 192-199 8 N
End of record 200 1 Always “*”
NOTE: All fields are left justified, with trailing spaces.
08/12/2018 Page 35 of 119

*Note: In this instance, “PSAP ID” means “the Code identifying the PSAP associated with
the assigned ESN,” which may be different than how “PSAP ID” is used in 18.5.2 and
18.5.4 of this document where the term means “the Code identifying the PSAP as listed in
the FCC PSAP registry.”
Function of Change for MSAG options

Insert a single range:
FOC=I defines the current image to be inserted
FOC=D defines the current image to be deleted
Changes to an MSAG Range SHOULD appear in the Delta Files as a “D” record followed by
an “I” record.
Deprecated MSAG FOC options
Some DBMS providers provide delta MSAG files using FOC codes that were documented for
Version 3.1 in the previous versions of this document. These codes are not part of the
NENA 02-010 standard – but are shown below for documentation.
Insert a range:
FOC=I defines the current image to be inserted (no FOC=X used)
Change a single range:
FOC=X comes first to define the current (before) image
FOC=C comes second to define the after image
FOC=D defines the current image to be deleted (no FOC=X used)
Split one range:
FOC=X comes first to define the current (before) image
FOC=S or L comes next (two or more FOC=S records) to define two or more ranges
after the split (S&L are the same FOC and cannot be used interchangeably)
Join two or more ranges:

FOC=X comes first to define two or more before images – MUST be in a sending
sequence by house number
08/12/2018 Page 36 of 119

FOC=J follows to define the single after image for the join (two or more X records must
proceed the J)
08/12/2018 Page 37 of 119

7 VERSION 2.1 HEADER FORMAT FOR DATA EXCHANGE

Header Indicator 1-5 5 “UHL”
Company Name 12-61 50 AN
Cycle Counter 62-67 6 N
County ID 68-71 4 AN
State 72-73 2 A
General Use 74-93 20 AN
Release Number 94-96 3 N
Format Version 97 1 N
Expanded Extract 98-105 8 N
Date
End of Record 200 1 Always “*”
NOTE: All fields are left-justified, with trailing spaces, except the Cycle
Counter, this field will be right-justified with leading spaces.
Header records will employ cycle counting to ensure a cycle of

updates is not is missed.
When used with an ALI source data file, the ‘Reserved’ field will
be expanded to 406 bytes (when used with an ALI source data
file).
08/12/2018 Page 38 of 119

8 VERSION 2.1 TRAILER FORMAT FOR DATA EXCHANGE

Trailer Indicator 1-5 5 “UTL
Company Name 12-61 50 AN
Record Count 62-70 9 N
Expanded Extract 71-78 8 N
Date
End of Record 200 1 Always “*”
NOTE: All fields are left justified, with trailing spaces, except for the
Record Count; this field will be right-justified with leading spaces.
Trailer records will employ record counting to ensure a record

within an update file is not missed.
When used with an ALI source data file, the ‘Reserved’ field will
be expanded to 433 bytes.
08/12/2018 Page 39 of 119

9 VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX # TYPE DESCRIPTION
BYTES
Record Type DAT or 0 A Indicates start of data record (label only, no
data follows). Valid labels:
RTN
DAT = Data Record sent from the Service
Provider to the Data Base Management
System Provider
RTN = Data record returned from the Data
Base Management System Provider to the
Service Provider
Status STI 1 AN Record status indicator.
Indicator Valid entries:
E = Error
C = Completed
P = Pending processing
U = Unprocessed Gateway received but
not sent to processing, (future date)
Function of FOC 1 A Type of activity the record is being

Change submitted for.
Valid “x” entries:
C = Change
D = Delete
I = Insert
U = Unlock
M = Migrate
E = Delete error record
08/12/2018 Page 40 of 119


BYTES
Calling Party CPN 10 N Number of the Calling Party.
Number Emergency Location Identification Number
(ELIN) – A valid North American Numbering
Plan format telephone number assigned to
the Multi-Line Telephone Systems Operator
by the appropriate authority that is used to
call to a PSAP and is used to retrieve the
ALI for the PSAP. The ELIN MAY be the
same number as the ANI. The North
American Numbering Plan number may in
some cases not be a dialable number.
Footnote 3
House HNO 10 AN House Number. Footnote 1,2,3
Number
House HNS 4 AN House number extension (e.g. ½). Footnote
Number Suffix 1,2,3
Prefix PRD 2 A Leading street direction prefix. Footnote
Directional 1,2,3
Valid “x” Entries:
N S E W
NE NW SE SW
Street Name STN 60 AN Valid service address of the Calling Party
Number. Footnote 1,2,3
1 Where an MSAG exists, MUST fit the MSAG entry.

2 Primary address associated with the Calling Party Number
3 MUST include all (Telephone Number (TN) USERS information on all Multi-Line Telephone
Systems that will facilitate the implementation of enhanced 9-1-1 on all PBX, Key, Hybrid and
Centrex Systems. Resellers MUST supply end user specific name and location information, not
information pertaining to the name and location of the Reseller.
08/12/2018 Page 41 of 119


BYTES
Street Suffix STS 4 A Valid street abbreviation, as defined by the
U S Postal Service Publication 28, Appendix
C. (e.g. AVE) Footnote 1,2,3
Post POD 2 A Trailing street direction suffix. Footnote
Directional 1,2,3
Valid “x” entries:
N S E W
NE NW SE SW
MSAG MCN 32 A Valid service community name as identified
Community by the MSAG. Footnote 1,2,3
Name
Postal PCN 32 A Valid service community name as identified
Community by the U S Postal Service. Footnote 3
Name
State/Provinc STA 2 A Alpha US state, Canadian province
e abbreviation e.g., TX (Texas), ON
(Ontario) Footnote 1,2,3
Location LOC 60 AN Additional location information (free
formatted) describing the exact location of
the Calling Party Number (e.g., Apt 718, or
cell sector A)
Emergency Response Location (ERL) – A
Location to which a 9-1-1 emergency
response team may be dispatched. The
location SHOULD be specific enough to
provide a reasonable opportunity for the
emergency response team to quickly locate
a caller anywhere within it.
Footnote 2,3 This information MAY be
displayed at the PSAP
08/12/2018 Page 42 of 119


BYTES
Landmark LMK 60 AN Landmark or Vanity address such as “One
Address Rockefeller Plaza”
Also Rings At ARA 60 AN Secondary address for the Calling Party
Address Number that rings at 2 locations. Not
validated against the MSAG. Footnote3 Not
applicable to dual service.
This information MAY be displayed at the
PSAP
Customer NAM 32 AN Subscriber name associated with the Calling
Name/Service Number. Preferred format for an individual
customer name (not a business) is: Last,
First and, optionally, a suffix which may be
generation (Jr, III) and/or title (PhD, Esq,
MD). Honorifics (Mr., Mrs., Ms.) SHOULD
not be included as part of the name.
Alternatively, in order to provide the
telecommunicator with an additional signal
to pay attention to both the x, y coordinates
and the civic address (and/or where the
individual customer name is not provided)
and to provide other clarifying service type
information in a standardized manner, the
field MAY be used in a standard way by
carriers, with specific standardized “Service
Descriptions.” See Sections 2.2 and 19 of
this document.
08/12/2018 Page 43 of 119


BYTES
Class of CLS 1 AN Valid entries:
Service 1 = Residence 8 = Mobile
2 = Business 9 = Residence OPX
3 = Residence 0 = Business OPX
PBX
4 = Business PBX A = Customer Owned
Coin Telephone
(COCT)
5 = Centrex B = Not Available
Footnote4
6 = Coin 1 Way G = Wireless
out Phase I
7 = Coin 2 Way H = Wireless
Phase II
I = Wireless
Phase II with
Phase I
Information
V = VoIP C = VoIP Residence
Services
Default CoS
D = VoIP E = VoIP Coin/Pay
Business Phone
F = Other Mobile J = VoIP Nomadic
K = VoIP For all VoIP CoS
Enterprise see notes on
Services – page 13
Centrex &
PBX
T = Telematics
08/12/2018 Page 44 of 119


BYTES
Type of TYS 1 AN Valid entries:
Service 0 = Not FX nor Non-Published
1 = FX in 911 serving area
2 = FX outside 911 serving area
3 = Non-Published
4 = Non-Published FX in serving area
5 = Non-Published FX outside 911
serving area
8 = PSALI Published
9 = PSALI Non-Published
Exchange EXC 4 AN A defined area, served by one or more
telephone Central Offices, within which a
Local Exchange Carrier furnishes service.
Footnote 5
Emergency ESN 5 AN Emergency Service Number associated with
Service the House Number and Street Name and
Number Community Name.
(ESN) Note: The Service Provider, providing the
E9-1-1 Selective Routing will assign ESNs.
Main MTN 10 N Ten-digit telephone number of the Main
Telephone Billing Number associated with the Calling
Number Party Number. Format: NPANXXXXXX
Footnote3
4 NA = not available – class of service for an ESCO failure

5The Data Technical Committee strongly recommends that all processing edits be removed from this
Label due to technological changes requiring improved data security measures.
08/12/2018 Page 45 of 119


BYTES
Call Back CBN 10 AN Telephone Number that can be dialed to
Number reach a specific calling party. The call back
number MUST be a dialable number and
used as a backup if the displayed number
cannot be reached. Used for both wireline
and wireless calls. Footnote3
P-ANI PNI 10 AN Pseudo ANI or locally specific code
identifying the receiving antenna for the
wireless 9-1-1 call for routing purposes.
Order ORD 10 AN Service order number for the activity
Number associated with this record.
Completion CPD 10 N Completion Date in format CCYY-MM-DD
Date
County ID COI 5 AN County Identification code (usually the FIPS
code).
Note: County Identification field is used to
Committee recommends use of the FIPS
Census Bureau.
Access CPF 5 AN NENA registered Company Identification
Infrastructure code for Service Provider providing the
Provider network access to the end user customer
(Company ID (wireline, wireless, IP, etc.).
1)
Data Provider CPS 5 AN NENA registered Company Identification
ID (Company code for Service Provider/Reseller/Private
ID 2) Switch supplying ALI record source
information.
Postal/Zip ZIP 10 AN Postal or Zip code. Format: NNNNN-NNNN
Code or ANANAN Footnote 3
Customer CUS 3 AN Code used to uniquely identify a wireline
Code customer
08/12/2018 Page 46 of 119


BYTES
Comments CMT 30 AN Optional notes, MAY be displayed at PSAP
Telephone Number (TN) USERS on MLTS
can include any pertinent information that
will assist in reducing response time such as
– contact security department, contact front
desk, etc. Footnote3
TAR Code TAR 6 AN Taxing Area Rate Code
Alternate ALT 10 N Remote Call Forwarding number used
Telephone during Interim Number Portability-
Number NPANXXXXXX
Return Code RCN 3 N Code indicating specific processing error
Number code or processing completed successfully.
(MAY be used as many times as necessary.)
Valid "x" entries:
Not present (or 000 if used) = processing
completed successfully
XXX = Valid NENA Standard Error Code
Special SAI 1 AN Calls that require special attention. Valid
Attention entries:
Indicator 1 = TTY call
2 = ACN = Automatic crash/collision
notification
Common CLI 11 AN CLLI code of the local loop central office for
Language the 911 calling party.
Location
Indicator
(CLLI)
General Use 1 GU1 60 AN This field will be mutually used by data
08/12/2018 Page 47 of 119


BYTES
Longitude LON 11 N Longitude/X coordinate. Right Justified; pad
field with zeros or spaces to left of decimal
degrees. +long: east of Greenwich; -long:
west of Greenwich. When Phase II location
cannot be provided, Phase I information
SHOULD be reported, i.e., the cell site or
sector where the call is received. (Can be
used for wireline)
Sample: +000.000000 , -000.000000
Footnote3
08/12/2018 Page 48 of 119


BYTES
Latitude LAT 10 N Latitude/Y coordinate. Right Justified; pad
field with zeros or spaces to left of decimal
degrees. +lat: north of equator; -lat: south
of equator. When Phase II location cannot
be provided, Phase I information SHOULD
be reported, i.e., the cell site or sector
where the call is received. (Can be used for
wireline)
Sample: +00.000000 , -00.000000
Footnote3
Elevation ELV 6 N Elevation/Altitude indicated as height
different from mean sea level (plus or
minus), measured in meters. Right Justified;
pad field with zeros or spaces. (This is not
intended to include floor level or
uncompensated barometric pressure.)
Sample: +00000 , -00000
Cell Site ID CEL 6 AN Identification number indicating a
geographic region of cellular coverage. .
When Phase II location cannot be provided,
Phase I information SHOULD be reported,
i.e., the cell site or sector where the call is
received.
Sector ID SEC 2 AN Sub set/section of a cell. When Phase II
location cannot be provided, Phase I
information, i.e., the cell site or sector
where the call is received SHOULD be
reported.
The items below do not require a “Label” only the symbol shown
Field | 1 AN A “pipe” is to be utilized for the field separator
Separator (ASCII HEX-7C)
08/12/2018 Page 49 of 119

End of record NL 1 AN The NEW LINE character is a single character that

NL identifies the end of record in all cases for all
records. (ASCII HEX-0A)
9.1.1 Data Record Format Example:

DAT|FOC|CPN..........|HNO..........|PRD..|STN....................|STS....|MCN...............
.....|STA..|LOC............................|NAM...........................................|CLS.|TYS.|MT
N..........|CPD........|CPF.....|NL
NOTE: If the field is not being used (I.E: “Street Suffix”, “Post Directional”,
“Customer Code”) then the label is not used. It is also not necessary for the labels
to be in any particular order. Fields MAY be added to the record without changing
the file format.
The Service Provider, providing E9-1-1 Selective Routing MUST provide
the governmental entity with a list of ESNs available for assignment by
MSAG development personnel.
08/12/2018 Page 50 of 119

10 VERSION 3.1 FORMAT FOR MSAG DATA EXCHANGE

BYTES
Record Type MSG 0 Indicates start of MSAG record (label only,
no data follows)
Function of FOC 1 A Type of activity the record is being
Change submitted for. Valid entries6:
D = Delete
I = Insert
Prefix PRD 2 AN Leading street direction prefix Valid “x”
Directional Entries:
N S E W
NE NW SE SW
Street Name STN 60 AN Valid service address of the Calling Party
Number.
Street Suffix STS 4 AN Valid street abbreviation, as defined by the
U S Postal Service Publication 28, Appendix
C. (e.g. AVE)
Post POD 2 AN Trailing street direction suffix. -Valid “x”
Directional entries:
N S E W
NE NW SE SW
6 See Version 2.1 MSAG FOC for more details:

*Note: In this instance, “PSAP ID” means “the Code identifying the PSAP associated with the
assigned ESN,” which may be different than how “PSAP ID” is used in 18.5.2 and 18.5.4 of this
document where the term means “the Code identifying the PSAP as listed in the FCC PSAP
registry.”
Function of Change for MSAG options
08/12/2018 Page 51 of 119


BYTES
Low Range LOR 10 AN The lowest house number that is included in
this ESN definition
High Range HIR 10 AN The highest house number that is included
in this ESN definition
MSAG MCN 32 A Valid service community name as defined by
Community the MSAG
Name
Postal PCN 32 A Valid service community name as defined by
Community the U S Postal Service
Name
State/Provinc STA 2 A Alpha U.S. state, Canadian province
e abbreviation i.e., TX (Texas), ON (Ontario)
Odd/Even OEN 1 A Valid “x” entries:
O = Odd numbering only
E = Even numbering only
B = Both odd and even numbering
Emergency ESN 5 AN Emergency Service Number associated with
Service the House Number and Street Name and
Number Community Name.
(ESN) Note: The Service Provider, providing the
E9-1-1 Selective Routing will assign ESNs.
Completion CPD 10 N Completion date in format CCYY-MM-DD
Date
08/12/2018 Page 52 of 119


BYTES
PSAP ID PSI 4 AN Code identifying the PSAP associated with
the assigned ESN (Note: In this instance,
“PSAP ID” means “the Code identifying the
PSAP associated with the assigned ESN,”
which may be different than how “PSAP ID”
is used in 18.5.2 and 18.5.4 of this
document where the term means “the Code
identifying the PSAP as listed in the FCC
PSAP registry.”)
County ID COI 5 AN County Identification code (usually the FIPS
code).
Note: County Identification field is used to
Committee recommends use of the FIPS
Census Bureau.
Exchange EXC 4 AN A defined area, served by one or more
Telephone Central Offices, within which a
Local Exchange Carrier furnishes service.
TAR Code TAR 6 AN Taxing Area Rate Code associated with this
House Number range, Street Name and
Community Name
E9-1-1 SRT 11 AN 9-1-1 Control Office CLLI
Control Office
08/12/2018 Page 53 of 119

Field | A “pipe” is to be utilized for the field

Separator separator (ASCII HEX-7C)
End of record NL A NEW LINE character is a single character
that identifies the end of record in all cases
for all records. (ASCII HEX-0A)
MSAG Record Format Example:

MSG|FOC.|PRD..|STN.......................................|STS....|LOR..........|HIR..........|M
CN.................................|PCN.................................|STA..|OEN.|ESN.....|CPD.......
.|EXC....|SRT...........|GU1.....................................................................................|
NL
NOTE: If the field is not being used (I.E: General Use) then the label is not used. It
is also not necessary for the labels to be in any particular order. Fields MAY be added to
the record without changing the file format.
08/12/2018 Page 54 of 119

11 VERSION 3.1 HEADER FORMAT FOR DATA EXCHANGE

NAME LABEL MAX # TYPE DATA DESCRIPTION
BYTES
Record Type HDR 0 A Indicates start of header record (label only,
no data follows)
Record TST 3 AN Test Records Only
Identifier
Extract Date EXD 10 N Year, Month, Day the data was processed,
Format: CCYY-MM-DD
Company CON 50 AN Name of Company forwarding file
Name
Cycle Counter CYC 9 N Sequential number, 1-999,999,999
Record Count REC 9 N Number of records by record type in file,
does not include Header and Trailer records
General Use GEN 20 AN Field to be utilized by sender/receiver
companies to provide additional information
Field | 1 AN A “pipe” is to be utilized for the field
End of record NL 1 AN The NEW LINE character is a single character
NL that identifies the end of record In all cases
for all records. (ASCII HEX-0A)
11.1.1 Header Record Format Example:

HDR|EXDCCYY-MM-
DD|CON…………………………..|CYC………|REC………|GEN……….|NL
NOTE: If the field is not being used (I.E: General Use) then the label is not used. It is also
not necessary for the labels to be in any particular order, except for the Record
08/12/2018 Page 55 of 119

Type indicator, which MUST be first. Fields MAY be added to the record without
changing the file format.
Header records will employ cycle counting to ensure a cycle of updates is not
missed.
08/12/2018 Page 56 of 119

12 VERSION 3.1 TRAILER FORMAT FOR DATA EXCHANGE
NAME LABEL MAX # TYPE DATA DESCRIPTION

BYTES
Record Type TLR 0 A Indicates start of Trailer record (label only,
no data follows)
Record Count REC 9 N Number of records by record type in file,
does not include Header and Trailer records
Field | 1 AN A “pipe” is to be utilized for the field
End of record NL 1 AN A NEW LINE character identifies the end
of record value in all cases for all records.
(ASCII HEX-0A)
TLR|REC.........|NL
NOTE: Fields MAY be added to the record without changing the file format, because a
record consists of the data found between one new line and the next, labels need not
follow in sequence though checking for duplicate labels within a single record would be
prudent.
Trailer records will employ record counting to ensure a record within an update file is not
missed.
08/12/2018 Page 57 of 119

13 VERSION 3.1 WIRELESS DATA EXCHANGE

13.1.1 Dynamic Updates of the ALI Database
The Version 1 through 4 Formats for Data Exchange applies to record and file exchanges
between Service Providers and Data Base Management System Providers. These
exchanges are file oriented and MAY be exchanged using bulk electronic file transmissions,
CD-ROM, diskette, magnetic tape, or similar medium. The need to provide dynamic ALI
database updates during 9-1-1 calls was introduced with Wireless Phase I solutions. The
traditional record/file format for data exchange does not apply to dynamic database
updates, which are real-time transaction, oriented. Header and Trailer records are not
utilized in a transaction message, which is designed to be a real-time update of one or
more database records.
Wireless solutions require information to be provided to the PSAP at the time a 9-1-1 call is
in progress from a wireless device. This information is dynamic since it cannot be
determined or stored in the ALI database prior to the 9-1-1 calls. Information such as the
wireless caller’s Call Back Number, Latitude, and Longitude information is only known at
the time the 9-1-1 call is placed and may be dynamically populated in the ALI database.
Wireless Service Providers may generate a real-time transaction to the ALI System that
contains this dynamic information. The ALI database is updated with this information prior
to the PSAP equipment issuing an ALI request (bid) to the ALI database. When the ALI
system receives the request from the PSAP, the dynamically updated database record is
retrieved and used to build the ALI source data that will be transmitted back to the PSAP,
with the Call Back Number, Latitude, Longitude, and other dynamically updated
information.
This dynamic update capability requires real-time interfaces to be developed between the
data provider and the ALI Database Management System. Many of these interfaces are in
place as Wireless Phase I solutions were deployed. These real-time interfaces may utilize
proprietary software and data formats.
Wireless Phase II introduced the need to retrieve updated lat/long information during 911
call processing. Data Base Management System Providers SHOULD refer to TIA/EIA J-STD-
036 and NENA 05-001 Standard for the Implementation of the Wireless Emergency Service
Protocol E2 Interface. When implementing the E2 interface DBMS System Providers MUST
ensure compatibility between the data elements defined in the E2 interface and the data
elements defined in this NENA document. When inconsistencies exist between TIA/EIA J-
STD-036 and the NENA E2 Interface Document, the NENA standards MUST take
precedence. Position data retrieved from the MPC MAY need to be translated to conform to
the ALI database and ALI source data formats.
08/12/2018 Page 58 of 119

NENA recognizes that existing interfaces may utilize these proprietary interfaces, protocol,
and data formats. The Dynamic Update of the ALI Database shown in the XML format is
for illustrative purposes. Each interface provider SHOULD review the data elements for
dynamic updates for consideration in these proprietary interfaces. Adoption of XML data
format for real-time interfaces may provide the same benefits recognized for record/file
exchange. New data elements may need to be added to these real-time interfaces as new
technology is introduced. New data elements can be easily added when using XML format.
The following are data elements for Dynamic Updates to the ALI Database. These same
data elements SHOULD be defined in the ALI source data format used to transmit the ALI
back to the PSAP.

BYTES
Call-Back CBN 10 AN Telephone Number that can be dialed to
Number reach a specific calling party. The call back
number MUST be a dialable number and
used as a backup if the displayed number
cannot be reached
MOBILE ID MIN 10 AN Mobile Identification number of the cellular
(MIN) wireless device.
Roamer Port RPT 10 AN Temporarily assigned "roamer" call back
number.
Channel RCC 3 AN Channel signal received on.
Longitude LON 11 N Longitude/X coordinate. Right Justified; pad
field with zeros to left of decimal degrees.
+long: east of Greenwich; -long: west of
Greenwich. When Phase II location cannot
be provided, Phase I information SHOULD
be reported, i.e., the cell site or sector
where the call is received. (Can be used for
wireline) Sample: +000.######
08/12/2018 Page 59 of 119


BYTES
Latitude LAT 10 N Latitude/Y coordinate. Right Justified; pad
field with zeros to left of decimal degrees.
+lat: north of equator; -lat: south of
equator. When Phase II location cannot be
provided, Phase I information SHOULD be
reported, i.e., the cell site or sector where
the call is received. (Can be used for
wireline) Sample: +00.######
Elevation ELV 5 N Elevation/Altitude/Z indicated as height
different from mean sea level (plus or
minus), measured in meters. (This is not
intended to include floor level or
uncompensated barometric pressure.)
Sample: +000.### , -00.###
P-ANI PNI 10 AN Pseudo ANI or locally specific code
identifying the receiving antenna for the
wireless 9-1-1 call for routing purposes.
Location Valid LVD 1 N Valid data indicator (1=OK; 0=Invalid).
Flag
Datum NAD 2 AN Specifies the map projection and coordinate
system for the display of the Longitude and
Latitude coordinates. Two systems are
commonly used for North America. The
code 83 identifies North American Datum for
1983 (NAD83). Code 84 identifies the
World Geodetic System for 1984 (WGS 84).
Other codes MAY be added as additional
datum become available through authorized
entities.
Where x =
83 = NAD83
84 = WGS 84
08/12/2018 Page 60 of 119


BYTES
LDT COF 7 N Information that indicates the level of
Confidence uncertainty inherent to the associated
latitude/longitude information expressed in
meters, ranging from one meter to 1800 Km
expressed in meters.
LDT COP 3 N Information identifying the confidence by
Confidence which it is known that the calling party lies
Percentage within the associated shape description. It
is expressed as a percentage ranging from
0 – 100.
LDT Provider LDT 8 AN LDT Provider Identification Code. Codes to
ID be developed and held by NENA.
08/12/2018 Page 61 of 119


BYTES
LDT LTY 2 AN Defines how particular position information
Technology was obtained to help assess its credibility.
Defined values include:
Single Character Value of x: Translation
Value of yyy:
0 = Unknown
1 = Network Unspecified
2 = Network AOA
3 = Network TOA
4 = Network TDOA
5 = Network Radio Frequency (RF)
Fingerprinting
6 = Network Cell Sector
16 = Handset Unspecified
17 = Handset GPS
18 = Handset A-GPS (Assisted GPS)
19 = Handset E-OTD (Enhanced
Observed Time Difference )
20 = Handset AFLT (Advanced Forward
Link Trilateration)
Time Stamp TME 8 AN Universal Time Coordinate (UTC) indicating
milliseconds into UTC day.
Day Stamp DAY 7 N Year and Julian date. (UTC Date). Sample:
1996187 (CCYYDDD).
Speed (in SPD 3 N Speed of travel in kilometers per hour.
KPH)
Heading HDG 3 N Direction of travel, decimal degrees from
true north. Valid entries 0-359.
(in degrees)
08/12/2018 Page 62 of 119


BYTES
Cell Site ID CEL 6 AN Identification number indicating a
geographic region of cellular coverage.
When Phase II location cannot be provided,
Phase I information SHOULD be reported,
i.e., the cell site or sector where the call is
received.
Sector ID SEC 2 AN Sub set/section of a cell. . When Phase II
location cannot be provided, Phase I
information SHOULD be reported, i.e., the
cell site or sector where the call is received.
Wireless Data Format Example:

CBN..........|MIN..........|RPT...........|RCC...|XCD...........|YCD...........|ZCD......|PNI
..........|LVD.|NDA..|COF....|COP..|LDT........|LTY....|TME........|DAY.......|SPD...|
HDG...|NL
NOTE: Version 4 Data Exchange Format is an industry standard XML data format. NENA
XML (Extensible Markup Language) documents have been adapted from Standard
Generalized Markup Language (SGML) by the World Wide Web Consortium. Version 4 Data
Exchange Format was created to bring the NENA Data Exchange Format in line with
industry standard implementation methods, to introduce versioning control and promote
reusability of previous work. All existing NENA 4 information has been removed from this
document and moved to an easily accessible area on the NENA web site.
http://www.nena.org/xml_schemas/. Go to this Uniform Resource Locator (URL) and
select the Current NENA XML Schemas. All previous XML format exhibits are shown
including Element Tags, GIS Data Model, and ALI Response V1.0.
XML ALI Exchange development SHOULD be done in accordance with the NENA ALI
Query Service Standard, NENA-STA-029 (originally 04-005). The most current
versions of the ALI and AQS schemas SHOULD be used.
08/12/2018 Page 63 of 119

14 VERSION 4 XML FORMAT FOR DATA EXCHANGE

14.1 The XML Schema
The XML Schema is a document that represents how the XML data SHOULD be organized.
It defines the data elements that are needed and those that are optional. The schema also
describes data types (Strings vs. integer data, date elements, etc.), the relationship
between data elements (single or multiple instance, parent and child elements)
14.2 Schema Version Control

All NENA data exchange formats, prior to NENA 3, by nature, could not be changed
without becoming a completely new data exchange format and were not backward
compatible.
NENA 4 provides a vehicle to support necessary change without disturbing existing systems
and processes. NENA 4 can be said to be backward compatible within schema generations.
A Schema Generation change is used to make major modifications to the XML Schema,
changes that are so different that they will prevent the validation process. Schema from
one Generation are not backward compatible and cannot be used to validate data
documents. For example, changing the schema rules about how data elements are
organized will often be the cause of backward incompatibility since this type of change
would modify the definition, structure or existing relationships between data elements or
groupings. Again, a new Generation will not be backward compatible with previous
generations.
A Schema Release change is used to introduce modifications to an XML Schema that
maintain backward compatibility with all other schema releases within the current
generation.
Schema Generations will be kept in “Generation” named folders on the NENA Web site
linked to the NENA Home Page, following W3C conventions, and will be available to anyone
who requires the schema documents for validation or development. Under each Generation
folder will be folder(s) that contain the most current as well as previous schema releases.
Each Release folder will contain the actual schema files, all supporting documentation and
Application Information Caption Map data.
14.3 Schema Design

In a simple schema design, the data element type definitions MAY be included within the
schema itself. To promote reusability data type definitions have been separated into an ALI
Type Library schema document. The ALI Type Library can be used or referenced by other
applications or schemas to retrieve the data types defined for 911 ALI. When schema or
data definition changes are needed the change will be made to a single reference file
08/12/2018 Page 64 of 119

within a release instead of changing the individual schemas. When the change is made to
the ALI Type Library schema the change is then available to all applications that reference
it.
14.4 Schema Extensions

XML Schema Extensions provide a method to include additional data elements that have
not yet been specifically defined in the ALI Library. Schema Extensions promote a data
flexibility that was not available in previous NENA exchange formats. Once it has been
determined that the new data element(s) provided through the extension mechanism are
needed they will be added to the ALI Type Library or other schema documents, through
the NENA Data Committee process. A new schema release will then be created which
includes the new data elements
14.5 Schema Validation

Proper Schema validation provides a level of confidence that the data being sent to and
received by an application meets the established definition and requirements for the
defined XML data. Previous NENA data exchange versions defined the arrangement of data
elements in a fixed length record. The XML Schema describes the layout of an XML
document. Validation checks the element tag names, the needed tags and data are
present, the order of data elements in the XML document, and the data type of each
element to ensure they fit the definition and meet the requirements as specified in the
Schema. Each XML data document includes information that specifies the Schema
Generation and Release used to validate the XML document from which it was issued. This
Schema Generation and Release information is included in the XML documents Root
Element at the beginning of the XML document.
14.6 Validation Point

The purpose of the XML schema is to provide a means to determine that an XML document
is complete and valid as to its format, structure and data element types. The most logical
point in the data exchange for validation to occur is at the sending application. Performing
validation at the sending end ensures that only valid XML documents are received reducing
retransmissions and effort on the receiving end to return the document to the sender. An
alternative method is to validate on both ends where there is either a lack of confidence in
the sender validation process or where the developer of the software wants to leverage the
power of the schema.
14.7 Redefining of Data Elements

With a careful review of the original NENA 4 data elements it becomes apparent that the
NENA 3 data elements were wrapped in an XML tag and called NENA 4 causing the real
08/12/2018 Page 65 of 119

benefits available with XML to be missed. For this reason the current NENA 3 and NENA 4
data elements have been reexamined to determine areas where improvements could be
made. Details regarding additions, changes or modifications can be found in README files
located within the Generation/Release folders on the NENA web site.
14.8 Two examples of this redefining are described below.

General Use
The original NENA 4 data exchange document identifies eight (8) text elements labeled
General Use 1 thru 8, each 60 characters in length. During the review of schema definition
these 8 data elements were removed and replaced with 1 element called General Use. The
definition of this element says that there can be 1 or many of this general use element. In
this way the XML document can, without changing Generation or Release include 1 General
Use data element or 20. This is similar to adding rows or columns to a table in a word
processor or adding a column in spreadsheet program. A new column or row can be added
by creating an additional instance or occurrence of the data element. In a similar manner
additional General Use fields can be added in the XML document without changing the
schema or the definitions.
Class and Type of Service
The original NENA 4 definitions for Class and Type of Service contain a 2 dimensional data
element for each Class and Type of Service The first part being the numeric representation
such as 1, 2, 3, etc. The second part is a text definition of the number such as, 1=
Residence, 2=Business, etc. The purpose was to make the standard text definition
available for display at the PSAP. In the NENA 4 XML Schema document these definitions
become part of the ALI Type Library schema and are, therefore, available to those
applications that require it by using the schema as a cross reference to the definitions. This
technique maintains the use of standard definitions, promotes reusability of data across
many applications and schemas. This can also reduce the size of the data stream by not
passing the definitions along with the data.
14.9 Transmission Protocol

The future direction of data exchange methods adopted by NENA should incorporate
method and design concepts that are independent of traditional connection protocols.
Among the benefits of XML data is the ability to be protocol independent. For example the
current ALI source data delivery method utilizes a Start of Text /End of Text (STX/ETX)
protocol wrapped around the ALI source data or other message. While this protocol works
well in the legacy E9-1-1 environment there are benefits to be gained from more modern,
faster data delivery methods and protocols such as Transmission Control Protocol/Internet
08/12/2018 Page 66 of 119

Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure(
HTTPS), Simple Object Access Protocol (SOAP or others.
This becomes more apparent as the additional data available from Wireless, ACN and other
sources we have not yet identified are considered. Since XML is protocol independent it
MAY be used within the existing infrastructure without limiting the possibility of using other
protocols to deliver the ALI source data or other data messages.
14.10 XML Schema Location

NENA Version 4 Data Exchange Formats are available on the NENA web site at
http://www.nena.org/XML_Schemas.
The most current Generation and Release XML schemas and supporting documentation are
available at this location.
Schema documents for all XML data sources will be coordinated and validated by the NENA
Data Technical Committee.
A Schema Generation identifies XML families of schemas that are backward compatible
within that family or generation.
A Schema Release is a grouping of schema documents for each XML data source such as
ACN, Service Order, MSAG, etc.
There may be many releases within a Schema Generation. The differences between
releases are such that they do not cause incompatibility with previous releases within that
Generation schema family.
Schema changes that cause backward incompatibility constitute a new Generation.
Some schema documents may not change between a Generation or Release; however, all
files in each release within each generation will have been verified to ensure compatibility
with all other schemas within that release. Once this has been accomplished the collection
of schemas will be organized into a Release, assigned a number designating the Generation
family it belongs to and its order within that Generation family and then place on the NENA
web site for use. An example of the Release naming convention would be Release 1.2 for
Generation 1, Release 2 designating the second release of XML schemas within Generation
1. The next release within Generation 1 would be Release 1.3 and so on.
08/12/2018 Page 67 of 119

14.11 Example of the relationship between schema Generations and

subsequent Releases
08/12/2018 Page 68 of 119

Schema Version 4.2

Change Log
These are the items that have been changed from Version 4.1 to 4.2 in the schemas.
14.12 All schemas:

1) Changed all instances of datatypes (and restrictions) xs:string to xs:token7.
2) Set version in all schemas to 4.2.
7 An xs:token string is a string that does not contain the carriage return (#xD), line feed (#xA) nor tab
(#x9) characters, that has no leading or trailing spaces (#x20) and that has no internal sequences of
two or more spaces
08/12/2018 Page 69 of 119

15 ALI Schemas
15.1 ALI.xsd
1) Removed LocationInfo root element.
2) Removed MaxOccurs unbounded from LocationInfo occurring in AliBody.
3) Added Best Practices documentation for CallInfoType.
4) Modified CallInfoType so that all child elements are optional; specific change is that
CallingPartyNum and ClassOfService are now optional.
5) Added the following optional element to the ALI schema CallInfoType definition:
CallInfo/SpecialMessage : SpecialMessageType.
6) Added the following optional element to the ALI schema CallInfoType definition:
CallInfo/AlsoRingsAtAddress : TextualCivicAddressType
7) Removed use attribute in LocationInfoType.
8) Added Best Practices documentation for AgenciesType.
9) Replaced individual Law/Fire/EMS types with Agency Type definition.
10) Added ability to specify multiple OtherAgencies.
11) Modified ESN to be an optional element in Agencies.
12) Modified SourceInfoType to make DataProvider, Access Provider, ALIRetrievalGMT
optional elements.
13) Modified NetworkInfo to make PSAPID and RouterID optional elements.
14) Added PSAPName as element for NetworkInfo.
15.2 ALITypeLib.xsd
1) Modified AdditionalAgencyInfoType size to be 75 rather than 100 chars.
2) Added AgencyType definition which contains AgencyName and AgencyTN.
3) Removed AlsoRingsAtAddressType.
4) Modified CellID and SectorID to be optional elements for CellSiteType; added Best
Practices documentation.
5) Add length specifier of 1 to ClassOfServiceCodeType.
6) Added length specifier to CountryType
08/12/2018 Page 70 of 119

7) Added Name as optional element in DataProviderIDType.

8) Added length specifier of 2 to DatumType.
9) Added Name as optional element in AccessProviderIDType.
10) Removed EMSType, FireType, LawType (superseded by AgencyType).
11) Added length specifier to LDTTechnologyCodeType.
12) Removed LocationValidType.
13) Added PSAPNameType.
14) Removed RoamerPortType.
15) Added length specifier to SourceOfServiceType (this is an optional field in Call Info).
16) Added length specifier to SpecialAttentionIndicator.
17) Added SpecialMessageType.
18) Added Best Practices documentation for StreetAddressType.
19) Made all elements in StreetAddressType optional.
20) Added the following optional element to StreetAddressType definition: TextualAddress
: TextualCivicAddressType. (Even though this may seem redundant with the
LocationDescription element, the latter is defined to hold additional information about
a location (for example “South Wing”) rather than the civic address of the location
itself. The TextualAddress element is there to explicitly support cases where street
address is available only in textual (un-structured) form – like the address of a VoIP
caller in i2.)
21) Added TextualCivicAddressType.
22) Added length specifier to TypeOfServiceCodeType.
15.3 ALI Query Service Directory and Schemas

The “aliqs” directory contains schemas and Web Service Description Language (WSDL) for
ALI Query Service. These are all new.
15.4 AQS and AQS.WS Removed

Directories containing preliminary work on AQS have been removed.
15.5 MSAGRecord.xsd
1) Removed RangeNumberType.
08/12/2018 Page 71 of 119

2) Modified LowRange and HIghRange to be HouseNumTypes.

3) Modified Function of Change to be consistent with decisions made for NENA 2.1
retrofit. The only FOC types supported are “D” and “I”.
4) Moved TARCode from the street element to the range element.
16 I2 Schemas
16.1 Geopriv Directory and Schemas
The geopriv directory contains the CivicAddress and geoshape schemas.
16.2 GML-3.1.1 Directory and Schemas

The GML directory contains GML schemas referenced from the v9 schemas.
16.3 All I2 Schemas
Old New
V2-request v2Request
v2-response v2Response
v2-esct v2Esct
v2-esct-ack v2EsctAck
callserver-vpc-request callserverVpcRequest
callserver-vpc-esct callserverVpcEsct
esr-request esrRequest
call-id callId
call-origin callOrigin
esr-response esrResponse
esct-ack esctAck
v3-request v3Request
vpc-lis-request vpcLisRequest
ipl-request iplRequest
08/12/2018 Page 72 of 119

message-id messageId
ipl-response iplResponse
pos-source posSource
vpc-erdb-request vpcErdbRequest
erdb-request erdbRequest
erdb-response erdbResponse
vdb-identity-request vdbIdentityRequest
erdb-identity-request erdbIdentityRequest
identity-request identityRequest
identity-response identityResponse
location-key locationKey
nena-id nenaID
organization-name organizationName
cert-uri certUri
location-key locationKey
Added version attribute to the schema element.
16.4 V2.xsd
1) Modified result element to be String with numeric restriction.
16.5 V7.xsd
1) Removed pidf import
2) Added return 500, 570, 580 to ReturnCodeType
08/12/2018 Page 73 of 119

16.6 V8.xsd
1) Removed pidf import
2) Added return 210, 211, 212, 213, 214, 215, 562 to ReturnCodeType
3) Modified geo-location to be consistent with V9.
16.7 V9.xsd
This schema has been completely re-written.
17 GIS DATA MODEL, VERSION 2.0

17.1 Preface
Version 2.0 of the NENA GIS Data Model identifies the minimal attributes needed in a
spatial dataset. It also defines the GML schema that can be used with this model. Using
the GML schema, this data model can be used for GIS data exchange between neighboring
public safety agencies and to meet the requirements of GIS data needed for the NENA i2
solution (NENA 08-001).
Note: This data model is NOT compliant with Civic Location Data Exchange Format
(CLDXF) (NENA-STA-004) and does not meet the GIS requirements for the NENA i3
solution (NENA-STA-010). As of the publication of this document, the NENA NG9-1-1 GIS
Data Model (NENA-STA-006) has been developed and is undergoing Public Review as of
the most recent revision of this document. It is recognized that this Version 2.0 may have
become somewhat unclear on some aspects and may be different than or inconsistent with
what may be expected to be adopted in the NENA NG9-1-1 GIS Data Model (NENA-STA-
006). However, because Version 2.0 is expected to be essentially substantively superfluous
prospectively once the NENA NG 9-1-1 GIS Data Model (NENA-STA-006) has been adopted,
no attempt has been made to update Version 2.0 to provide any additional or increased
substantive clarity or to reconcile Version 2.0 with what is expected to be adopted in the
NENA NG9-1-1 GIS Data Model ((NENA-STA-006) although a couple of non-substantive
typographical errors in Version 2.0 were corrected).
17.2 Metadata
The Content Standard for Digital Geospatial Metadata (CSDGM), Vers. 2 (FGDC-STD-001-
1998) is the US Federal Metadata standard. The Federal Geographic Data Committee
originally adopted the CSDGM in 1994 and revised it in 1998. According to Executive Order
12096 all Federal agencies are ordered to use this standard to document geospatial data
created as of January, 1995. The standard is often referred to as the FGDC Metadata
Standard and has been implemented beyond the federal level with State and local
governments adopting the metadata standard as well.
08/12/2018 Page 74 of 119

The international community, through the International Organization of Standards (ISO),

has developed and approved an international metadata standard, ISO 19115. As a member
of ISO, the US is required to revise the CSDGM in accord with ISO 19115. Each nation can
craft their own profile of ISO 19115 with the requirement that it include the 13 core
elements. The FGDC is currently leading the development of a US Profile of the (ISO)
international metadata standard, ISO 19115.
Metadata is information about the content, quality, condition, and other characteristics of
data being sent. The basic elements to be included in the metadata file are taken from the
2003 ISO 19115 – International Standard for Geographic Information – Metadata.
This International Standard defines an extensive set of metadata elements; typically only a
subset of the full number of elements is used. However, it is essential that a basic
minimum number of metadata elements be maintained for a dataset. Listed are the core
metadata elements required to identify a dataset, typically for catalogue purposes. This list
contains metadata elements answering the following questions: “Does a dataset on a
specific topic exist (‘what’)?”, “For a specific place (‘where’)?”, “For a specific date or period
(‘when’)?” and “A point of contact to learn more about or order the dataset (‘who’)?”. Using
the recommended optional elements in addition to the mandatory elements will increase
interoperability, allowing users to understand without ambiguity the geographic data and
the related metadata provided by either the producer or the distributor. Dataset metadata
profiles of this International Standard MAY include this core.
Listed below are the core metadata elements (mandatory and recommended optional)
REQUIRED for describing a dataset. An “M” indicates that the element is MANDATORY. An
“O” indicates that the element is OPTIONAL. A “C” indicates that the element is
MANDATORY under certain conditions.
Dataset title (M) Spatial representation type (O)
(MD_Metadata > (MD_Metadata >
MD_DataIdentification.citation > MD_DataIdentification.spatialRepresentationType
CI_Citation.title) )
Dataset reference date (M) Reference system (O)
(MD_Metadata > (MD_Metadata > MD_ReferenceSystem)
MD_DataIdentification.citation >
CI_Citation.date)
Reference system (O)
Dataset responsible party (O) Lineage (O)
08/12/2018 Page 75 of 119

(MD_Metadata > (MD_Metadata > DQ_DataQuality.lineage >

MD_DataIdentification.pointOfContact LI_Lineage)
>
CI_ResponsibleParty)
Geographic location of the dataset On-line resource (O)
(by four (MD_Metadata > MD_Distribution >
coordinates or by geographic MD_DigitalTransferOption.onLine >
identifier) (C) CI_OnlineResource)
(MD_Metadata >
MD_DataIdentification.extent >
EX_Extent
> EX_GeographicExtent >
EX_GeographicBoundingBox or
EX_GeographicDescription)
Dataset language (M) Metadata file identifier (O)
(MD_Metadata > (MD_Metadata.fileIdentifier)
MD_DataIdentification.language)
Dataset character set (C) Metadata standard name (O)
(MD_Metadata > (MD_Metadata.metadataStandardName)
MD_DataIdentification.characterSet)
Dataset topic category (M) Metadata standard version (O)
(MD_Metadata > (MD_Metadata.metadataStandardVersion)
MD_DataIdentification.topicCategory)
Spatial resolution of the dataset Metadata language (C)
(O) (MD_Metadata.language)
(MD_Metadata >
MD_DataIdentification.spatialResolutio
n>
MD_Resolution.equivalentScale or
MD_Resolution.distance)
Abstract describing the dataset Metadata character set (C)
(M) (MD_Metadata.characterSet)
08/12/2018 Page 76 of 119

(MD_Metadata >
MD_DataIdentification.abstract)
Distribution format (O) Metadata point of contact (M)
(MD_Metadata > MD_Distribution > (MD_Metadata.contact > CI_ResponsibleParty
MD_Format.name and
MD_Format.version)
Additional extent information for Metadata date stamp (M)
the dataset (MD_Metadata.dateStamp)
(vertical and temporal) (O)
(MD_Metadata >
MD_DataIdentification.extent >
EX_Extent
> EX_TemporalExtent or
EX_VerticalExtent)
17.3 9-1-1 SPATIAL ATTRIBUTES FOR LINE DATA
17.3.1 Centerline Layer (REQUIRED)

ATTRIBUTE USE TYPE DATA DESCRIPTION
NAME
R/O
Low Address R N Lowest address on left side of street in ascending
Left order
High Address R N Highest address on left side of street in ascending
Left order
Low Address R N Lowest address on right side of street in ascending
Right order
High Address R N Highest address on right side of street in ascending
Right order
Prefix R A Leading street direction prefix. Valid Entries: N S E W
Directional NE NW SE SW
Street Name O A The element of the complete street name preceding
the street name element that indicates the type of
08/12/2018 Page 77 of 119


NAME R/O
Pre Type street. These are typically Street Suffixes according to
Appendix C in United States Postal Service (USPS)
Publication 28. However, they are not abbreviated
when used in this field.
Street Name R AN Valid street name as assigned by local addressing
authority
Street Suffix R A Valid Street abbreviation, as defined by the US Postal
Service Publication 28. (e.g. AVE)
Post R A Trailing street direction suffix. Valid Entries: N S E W
Directional NE NW SE SW
Road Class R N http://www.fhwa.dot.gov/planning/processes/statewid
e/related/highway_functional_classifications/section03
.cfm#Toc336872980
Highway Performance Monitoring System (HPMS)
Functional Classifications:
1= Interstate
2= Other Freeways and Expressways
3= Other Principal Arterial
4= Minor Arterial
5= Major Collector
6= Minor Collector
7= Local
Not designated as a HPMS Functional Classification,

but non the less an important road classification for
9-1-1:
8= Trails (Recreational trails)
One-way R A One way road classification. The direction of the line

08/12/2018 Page 78 of 119


NAME R/O
is an internal attribute maintained by the GIS
database. The direction of the line can be displayed by
symbolizing the beginning (FROM) node and the
ending (TO) node of the street centerline. The
direction of the street centerline SHOULD be FROM
the lowest address range TO the highest address
range
B or Blank – travel in both directions allowed
FT – One-way from FROM node to TO node (in
direction of arc)
TF – One way from TO node to FROM Node (opposite
direction of arc)
Postal R A Postal Community Name as identified on the left side
Community of the street
Name Left
Postal R A Postal Community Name as identified on the right side
Community of the street
Name Right
Postal R AN Postal or Zip code as identified on the Left side of the
Code/Zip street. Format: ANANAN or NNNNN 2
Code Left
Postal R AN Postal or Zip code as identified on the Right side of
Code/Zip the street. Format: ANANAN or NNNNN2
Code Right
MSAG R A Valid service community name as identified by the
Community MSAG on the left side of the street
Name Left
MSAG R A Valid service community name as identified by the
Community MSAG on the right side of the street
Name Right
ESN Left O AN 3-5 digit Emergency Service Number associated with
street segment
08/12/2018 Page 79 of 119


NAME R/O
ESN Right O AN 3-5 digit Emergency Service Number associated with
street segment
Segment ID R N Unique Road Segment ID number
County Name R AN County Name on the Left side of the street as given in
Left FIPS 6-4 1
County Name R AN County Name on the Right side of the street as given
Right in FIPS 6-4 1
County Code R A County Code on the Left side of the street as given in
Left FIPS 6-4 1
County Code R A County Code on the Right side of the street as given
Right in FIPS 6-4 1
State/Provinc R A Two character Alpha U.S. State or Canadian province

e Left abbreviation as defined by Postal Authority or ISO
3166-2 i.e. TX (Texas), ON (Ontario)
State/Provinc R A Two character Alpha U.S. State or Canadian province
e Right abbreviation as defined by Postal Authority or ISO
3166-2 i.e. TX (Texas), ON (Ontario)
Source of R A Agency that last updated the record
Data
Date Updated R N Date of last update Format: CCYY-MM-DD
1
http://www.census.gov/geo/reference/ansi.html The FIPS Codes Standard SHALL not
apply to applications involving interchange of international data that require the use of the
08/12/2018 Page 80 of 119

country codes of the International Organization for Standardization, i.e., ISO 3166. For the
convenience of such users, the ISO 3166 country codes are published in FIPS PUB 104,
Guideline for Implementation of ANSI Codes for the Representation of Names of Countries,
Dependencies, and Areas of Special Sovereignty. FIPS PUB 104 provides both two- and
three-character alphabetic codes for each entity listed. Federal agencies that do not require
FIPS PUB 104 for international data interchange, and are not involved in national defense
programs or with the mission of the U.S. Department of State, may adopt either set of
codes.
2
The USPS considers zip codes to be delivery routes instead of areas. There may be
differences between this depiction and actual zip code mailing address.
17.3.2 Railroad Layer (Optional)

NAME R/O
Line R A Railroad Line Owner (Code of Association of
American Railroads)
Line Sub- R A Railroad Line Sub-Division Name
Division
Name
Line Type R A Main, Secondary or Siding
Line Status R A Active or Inactive
Segment ID R N Unique Railroad Segment ID
Mile Post Low R AN Beginning Linear Reference
Mile Post R AN Ending Linear Reference
High
Passenger R A Passenger Rail Indicator
Rail Indicator
Data
08/12/2018 Page 81 of 119

17.3.3 Hydrology Layer (Optional)

ATTRIBU US TYP DATA DESCRIPTION
TE NAME E E
R/
O
Surface R A Type of Surface Water (river, stream, etc.)
Water
Type
Surface R A Name of river, stream etc.
Water
Name
Segment R N Unique Hydrology Segment ID
ID
Data
Date R N Date of last update Format: CCYY-MM-DD
Updated
17.4 9-1-1 SPATIAL ATTRIBUTES FOR POINT DATA
17.4.1 Emergency Service Agency Location Layer (REQUIRED)

NAME R/O
Agency Type R A Law = L
Fire = F
Emergency Medical Service = E
Other = O
1
County R AN County Name as given in FIPS 6-4
Name
1
County Code R A FIPS County Code as given in FIPS 6-4
Community R N Unique Community ID Number i.e. FIPS,
08/12/2018 Page 82 of 119

ID GEOCODES, etc.
Agency ID R N Emergency Service Agency ID defined with the
first 5 digits as the County ID code and the last 4
digits as the locally assigned agency code
Agency Name R A Name of Agency
Agency R A Agency Contact Person
Contact
House R AN House Number Prefix to accommodate
Number Alphanumeric characters or fire numbers in
Prefix house number i.e. Wisconsin
House R N House Number
Number
House R AN House Number Suffix
Number
Suffix
Prefix R A Leading street direction prefix. Valid Entries: N
Directional SEW
NE NW SE SW
Street Name O A The element of the complete street name
Pre Type preceding the street name element that
indicates the type of street. These are typically
Street Suffixes according to Appendix C in USPS
Publication 28. However, they are not
abbreviated when used in this field.
authority
Street Suffix R AN Valid Street abbreviation, as defined by the US
Postal Service Publication 28. (e.g. AVE)
Post R A Trailing street direction suffix. Valid Entries: N S
Directional EW
NE NW SE SW
Postal R A Postal Community Name
Community
08/12/2018 Page 83 of 119

Name
MSAG R A Valid service community name as identified by
Community the MSAG
Name
Postal O AN Postal or Zip code. Format: NNNNN or ANANAN2
Code/Zip
Code
State/Provinc R A Two character Alpha U.S. State or Canadian
e province abbreviation as defined by Postal
Authority or ISO 3166-2 i.e. TX (Texas), ON
(Ontario)
Telephone O AN Telephone Number of Agency Format: NPA-NXX-
Number XXXX
Data
17.4.2 Cell Site Location Layer (REQUIRED)

NAME
R/O
NENA CO ID R AN NENA Company ID
http://www.nena.org/default.asp?page=CID2014
Numeric Cell R N Carrier Cell site ID

ID
Cell Site R A Location Name assigned by the wireless carrier
Common
Name
Cell Site R AN Cell Site Identifier provided by the wireless
Unique ID service provider, it is unique to the cell site
Cell Site R A The address of the cell tower as provided by the
Address wireless service provider. Needs to be MSAG
08/12/2018 Page 84 of 119

Valid
Community
Name
Community the MSAG
Name
Cell Site State R A State where the cell tower is located
1
County Code R AN FIPS County Code as given in FIPS 6-4
Air Interface R A A=Analog (900MHz), P=Digital (PCS), T=TDMA

Technology (Digital AMPs), G=GSM – Type of RF Voice
Technology
Data
17.4.3 Mile Marker Location Layer (Optional)

NAME R/O
Mile Post ID R N Mile Post Identification Number
Mile Marker R A Type of mile marker :
Type Railroad name
Road name
Trail
Water Way
Coastal
Boardwalk
Route System R AN Name of route system (ex: Interstate 85)
08/12/2018 Page 85 of 119

Name
Segment ID R N Unique Road or Railroad Segment ID number
Data
17.4.4 Railroad Grade Crossing Layer (Optional)

NAME R/O
Grade R N Unique United States Department of
Crossing ID Transportation (USDOT) ID for the Crossing
Crossing R AN Position of Crossing
Position At Grade
Railroad (RR) Under
RR Over
Grade O A Name given to Grade Crossing
Crossing Name
Source of Data R A Agency that last updated the record
17.4.5 Site/Structure Location Layer (Optional)

NAME R/O
ID GEOCODES, etc.
Site ID R N Unique Site ID Number
House R AN House Number Prefix to accommodate
Number Alphanumeric characters or fire numbers in
08/12/2018 Page 86 of 119

Prefix house number i.e. Wisconsin

House R N House Number
Number
House R AN House Number Suffix
Number
Suffix
Location O AN Additional location information.
Abbreviated as shown in USPS Publication 28,
Appendix C, Item C2.
Prefix R AN Leading street direction prefix. Valid Entries: N
Directional SEW
NE NW SE SW
Street Name O A The element of the complete street name
Pre Type preceding the street name element that
indicates the type of street. These are typically
Street Suffixes according to Appendix C in USPS
Publication 28. However, they are not
abbreviated when used in this field.
authority
Street Suffix R AN Valid Street abbreviation, as defined by the US
Postal Service Publication 28. (e.g. AVE)
Post R AN Trailing street direction suffix. Valid Entries: N S
Directional EW
NE NW SE SW
ESN R AN Emergency Service Number associated with this
House Number, Street Name and Community
Name
Community
Name
Community the MSAG
08/12/2018 Page 87 of 119

Name
Postal O AN Postal or Zip code. Format: NNNNN or ANANAN2
Code/Zip
Code
Landmark R AN Landmark or Vanity address
Site Type R A Type of Structure – Classification Field
L/R R A Left/Right side of the road
Data
Date Updated R N Date of last update Format: CCYYMMDD
17.5 9-1-1 SPATIAL ATTRIBUTES FOR POLYGON DATA
17.5.1 County Boundary Layer (REQUIRED)

NAME R/O
1
County Name R AN County Name as given in FIPS 6-4
1
County Code R N FIPS County Code as given in FIPS 6-4

Data
17.5.2 Emergency Service Zone Boundary Layer (REQUIRED)

NAME R/O
08/12/2018 Page 88 of 119

ID GEOCODES, etc.
1
1
County Code R N FIPS County Code as given in FIPS 6-4
PSAP ID R AN Code identifying the PSAP as listed in the FCC

PSAP registry
http://www.fcc.gov/pshs/services/911-
services/enhanced911/psapregistry.html
Agency ID R N Emergency Service Agency ID
ESN R AN Emergency Service Number associated with the
ESZ
Data
17.5.3 Municipal Boundary Layer (REQUIRED)

NAME R/O
ID GEOCODES, etc.
Community the MSAG
Name
Data
08/12/2018 Page 89 of 119

17.5.4 Emergency Service Agency Boundary Layer (REQUIRED)

NAME R/O
PSAP ID R AN Code identifying the PSAP as listed in the FCC
PSAP registry
1
1
Count Code R N FIPS County Code as given in FIPS 6-4
Agency ID R N Emergency Service Agency ID

Data
D R N Date of last update Format: CCYY-MM-DD
08/12/2018 Page 90 of 119

17.5.5 Cell Site Coverage Layer (REQUIRED)

NAME R/O
LDT Provider R AN LDT Provider Identification Code. Codes to be
ID developed and held by NENA
Numeric Cell R N Carrier’s Cell site ID
ID
Cell Site R AN Cell Site Identifier provided by the wireless service
Unique ID provider, it is unique to the cell site
Numeric R N Carrier Sector ID usually indicates Omni or multi-
Sector ID sectored antenna faces
ESRD/ESRK R N Emergency Service Routing Digit (ESRD) is a 10
digit # used for routing a wireless call & is assigned
by cell sector. Emergency Services Routing Key
(ESRK) is a 10-digit # for routing & is assigned as a
pool of numbers to a PSAP. The first # of range is
entered here
Sector R N Orientation of the cell sector antenna face, with North
Orientation/ being 0 degrees and South = 180 degrees.
Azimuth
Sector R A Cell Sector Antenna orientation compass direction.
Compass An alpha indicator of the section directional – e.g. NE,
Orientation WSW, etc.
Sector Beam R N Width of the sector antenna beam in degrees, under
Width normal operating conditions
Average Sector R N Average true sector radius range (under average
Radius operating conditions.) Radius at which cell tower’s
polygon of influence ends and another begins.
Coverage R A C=Company Map, D=Digital data from Company,
source P=GIS Propagation Study, L=Line of Site analysis,
R=Range Defined
Source of Data R A Agency that last updated the record
08/12/2018 Page 91 of 119

Date updated R N Date of last update Format: CCYY-MM-DD
08/12/2018 Page 92 of 119

17.5.6 Hydrology Polygon Layer (Optional)

NAME R/O
Surface R A Type of Surface Water (pond, lake, large
Water Type waterway, reservoir, etc.)
Surface R A Name of Pond, lake, waterway, reservoir, etc.
Water Name
Segment ID R N Unique Hydrology Segment ID
Data
08/12/2018 Page 93 of 119

18 NENA Recommended Classes of Service

Code Name of Service Commonly NENA Related
Used (4 Recom ATIS J-
char) CoS mended STD-
Codes (4 char) 036-C-1
CoS Position
Codes Source
Codes
1 Residence RESD RESD
2 Business BUSN BUSN
3 Residence PBX PBXR PBXR
4 Business PBX PBXB PBXB
5 Centrex CNTX CNTX
6 Coin 1 Way PAY$, COIN PAY$
7 Coin 2 Way COIN, PAY$ COIN
8 Mobile MOBL, WRLS MOBL
9 Residence OPX RSDX, RESX RSDX
0 Business OPX BSNX, BUSX BSNX
A Customer Owned Coin COCT COCT
Telephone
B COS Not Available NA NA 48
C VoIP Residence VRES VRES
D VoIP Business VBUS VBUS
E VoIP Coin/Pay Phone VPAY VPAY
F Other Mobile OMBL OMBL
G Wireless Phase I WRLS / WPH1 WRLS 49
H Wireless Phase II WPH2 WPH2 1-5, 8-47,
51
I Wireless Phase II with Phase I P2P1, WPH1 WPH1 0, 6, 7, 50
Information
08/12/2018 Page 94 of 119


CoS Position
Codes Source
Codes
J VoIP Nomadic VNOM VNOM
K VoIP Enterprise Services - VENT VENT
Centrex & PBX
L Semi-Static, Small Coverage * 53
Cell
M Static Wireless Device * 54
N Text Message Sent to 911 TEXT TEXT** 52**
O Wireless E911 WCVC 55
Civic Address
P Wireless E911 WDL1 56
Dispatchable Location 1
Q Wireless E911 WDL2 57
Dispatchable Location 2
R Supplemental Geodetic SDXY ***
Location from Third-Party
S Available
T Telematics TLMA, TELM TLMA
U Available
V VoIP Services Default COS VOIP VOIP
W Available WRLS
X Available CELL
Y Available
Z Available
08/12/2018 Page 95 of 119


CoS Position
Codes Source
Codes
* Null, NENA has not adopted specific Classes of Service for position sources 53 (FIXD) and
54 (RESD) as recommended by ATIS, but they are still shown in this Exhibit for
completeness, to reconcile with the ATIS document, and to avoid confusion. See 3.2.4 and
3.2.6 for discussion of FIXD and RESD classifications associated with position source 53
(FIXD) and position source 54 (RESD).
** This is applicable Short Message Service (SMS)/MMS text-to-911 origination.
*** ATIS has not adopted specific Position Source for Supplemental Geodetic Location
from Third-Party.
19 NENA Recommended Service Descriptions for Customer

Name/Service Field
Usual Recommended Telecommunicator Clue Primary Primary ALI
End Service Purpose Related
State Description ATIS J-
CoS STD-
036-C-1
Position
Source
Codes
WPH2 FEMTOCELL Also pay attention to any 51 x, y coordinates
presented fixed civic
address information in
addition to the x, y
coordinates
WPH2 INDOOR The civic address may be 51 x, y coordinates
SMCELL/DAS highly accurate because it
HEAD should be a static device
with a very small coverage
area. Also pay attention to
08/12/2018 Page 96 of 119


CoS STD-
036-C-1
Position
Source
Codes
any presented fixed civic
address information in
addition to the x, y
coordinates
WPH2, WI-FI CALLING This is believed to be a Not Either x, y
VOIP*, mobile handset, tablet, or Applicable coordinates or
OMBL, other device using WI-FI Civic Address,
SDXY connectivity, and and such may
disconnection may result if vary by either
caller were to become certain
mobile circumstances
or service
provider
WDL2 WRLS W/ CIVIC Also pay attention to 57 Civic Address
SPECIFIC presented x, y coordinates
information in addition to
the civic address. The
caller is likely indoors, but
may not have ability to be
mobile (e.g., wireless
broadband vs. Wi-Fi access
point)
WDL1 WRLS W/ CIVIC Also pay attention to 56 Civic Address
ZONE presented x, y coordinates
08/12/2018 Page 97 of 119


CoS STD-
036-C-1
Position
Source
Codes
point)
WCVC WRLS W/ CIVIC Also pay attention to 55 Civic Address
RANGE presented x, y coordinates
point)
WPH2, NON-MOBILE While caller may be using 51, 55, (1) x, y
VOIP* PHONE wireless network 56, or coordinates
connectivity, this device is Not when WPH2 is
NOT believed to be a Applicable the CoS
mobile handset, and (VOIP)
(2) Wireless
disconnection may result if Civic Address
caller were to become when either
mobile. WDL2 or WDL1
is presented
(3) VoIP Civic
Address when a
VOIP CoS is
presented
Where more than one of the above may apply, it is generally recommended that the one
presenting the highest level quality of location information SHOULD be used in the event of
a conflict. The above recommended Service Descriptions MAY be used alone or in
08/12/2018 Page 98 of 119

combination with end user customer name or service provider name. Unnecessarily
combining Service Descriptions or using non-standardized Service Descriptions can lessen
usefulness and SHOULD be avoided. * In some areas, such as in Texas, the CoS of VOIP
may be used as a default and VRES, VBUS, VNOM, etc. may generally be in use with
Interconnected VoIP services.
20 NENA Registry System (NRS) Considerations

Not Applicable
21 Documentation Required for the Development of a NENA XML

Schema
Not Applicable
22 Impacts, Considerations, Abbreviations, Terms, and Definitions
22.1 Operational Impacts Summary

Due to the increased volume and unique format of XML data, implementing the last
changes to NENA 4 may impact many systems and network elements associated with the
creation, transport and processing of 911 XML data.
Change to the NENA Reserved field should have no impact on operating systems since
these character positions were reserved for NENA use and should be space filled where not
being used.
22.2 Technical Impacts Summary

Communication Service Providers may need to adjust their existing processes, procedures,
and services to implement data exchange format modifications and to conform to the data
format requirements or suggestions in this document. However, data exchange formats
are a longstanding part of E9-1-1, and any new modifications (such as adding new Classes
of Service) have historically been accommodated as long as a sufficient period of time is
available for development, deployment, and training associated with such.
22.3 Security Impacts Summary

Security is handled by the appropriate 9-1-1 Data Base Management System Provider and
the appropriate 9-1-1 data providers as deemed by their internal IT security procedures
and processes. The appropriate 9-1-1 Data Base Management System Provider should
review and consider NENA-INF-015.1-2016 as applicable.
08/12/2018 Page 99 of 119

22.4 Recommendation for Additional Development Work

The evolution of 9-1-1 call and data delivery from analog to IP will require additional
development to meet the needs of a Next Generation 9-1-1 system. New databases,
processes, architecture, and interfaces will require this document be updated to
accommodate these changes.
With regard to the additions of WDL2, WDL1, WCVC, TEXT, and SDXY, and changing
existing VMBL to OMBL, it is recommended that there be additional development work
by appropriate NENA Committee(s) to promptly incorporate WDL2, WDL1, WCVC, TEXT,
SDXY, and OMBL into data mapping for purposes of Legacy Network Gateways, Legacy
PSAP Gateways, and any other needed ALI to NG9-1-1 data purposes. See, specifically
NENA-STA-010.2-2016 at Appendix A, Table A-15-2 Class of Service Mapping. In
addition, new training information materials SHOULD be prepared for the CoS of WDL2,
WDL1, WCVC, TEXT, SDXY, and OMBL.
With regard to the standardized use of “Service Descriptions” in the Customer
Name/Service field, there are four recommendations for additional development work.
First, the NENA Testing Validation Worksheet (TVW) process in NENA 57-002 (which has
not be updated since 2006) SHOULD be reviewed and updated as needed to reflect use of
“INDOOR SMCELL/DAS HEAD” in the Customer Name/Service field for provisioning small
cells. Second, any existing uses of non-standardized “Service Descriptions” in the Customer
Name/Service field SHOULD promptly be reviewed by the PSAP community. Any records
found to be inconsistent with the new seven standardized “Service Descriptions” in Section
19 should have ALI Discrepancy Reports filed with the data provider. Fourth, within five
years the new standardized “Service Descriptions” in the Customer Name/Service field
SHOULD be reviewed for continued need and usefulness as NG9-1-1 becomes fully
deployed on an end-to-end basis and a single legacy CoS is superseded and replaced by
the use of (1) service environment, (2) service type, and (3) service mobility.
22.5 Anticipated Timeline

Deployment or implementation of this standard will take place as may be required or as
done on a voluntary basis.
22.6 Costs Factors

The implementation of the XML portion of this standard may require programming changes
to applications involved in the transport and processing of XML data and may require
enhancements to the 911 network such as to support increased volumes of data.
22.7 Cost Recovery Considerations

Normal business practices may govern the cost recovery.
08/12/2018 Page 100 of 119

22.8 Additional Impacts (non-cost related

The information or requirements contained in this NENA document are known to have
impacts, based on the analysis of the authoring group, and development has been started.
The primary impacts include:
 Improved coordination, communication, collaboration, and cooperation between
9-1-1 authorities, addressing authorities and other entities involved in 9-1-1 data
development and data delivery will be needed
22.9 Abbreviations, Terms and Definitions

See NENA-ADM-000, NENA Master Glossary of 9-1-1 Terminology, located on the NENA
web site for a complete listing of terms used in NENA documents. All abbreviations used in
this document are listed below, along with any new or updated terms and definitions.
Term or Abbreviation Definition / Description
(Expansion)
A 9-1-1 System Service Provider (9-1-1 SSP)
provides systems and support necessary to
enable 9-1-1 calling for one or more Public
Safety Answering Points (PSAPs) in a specific
geographic area. A 9-1-1 SSP may provide the
systems and support for either E9-1-1 or NG9-
1-1. In the context of E9-1-1 it is typically, but
not always, an Incumbent Local Exchange
Carrier (ILEC). This includes:
 A method of interconnection for all
9-1-1 SSP (System Service telecommunications providers including but not
Provider) limited to the wireline, wireless, and VoIP
carriers
 A method and mechanism for routing a 9-1-1
call to the Public Safety Answering Point (PSAP)
with no degradation in service regardless of the
technology used to originate the call
 A method to provide accurate location
information for an emergency caller to a PSAP
and if required, to other emergency response
agencies
 Installation of PSAP call handling equipment
08/12/2018 Page 101 of 119

and training of PSAP personnel when contracted

to do so
 Coordinating with PSAP authorities and other
telecommunications entities for troubleshooting
and on issues involving contingency planning,
disaster mitigation and recovery
A non-human initiated process to identify that a
motor vehicle has been involved in a collision,
ACN (Automatic Collision
collecting data from sensors in the vehicle, and
Notification)
communicating that data to a Call Center or
PSAP.
A type of handset-based position location
technology. Unlike A-GPS, AFLT does not use
GPS satellites to determine location. To
determine location, the phone takes
measurements of signals from nearby cellular
AFLT (Advanced Forward Link base stations (towers) and reports the
Trilateration) time/distance readings back to the network,
which are then used to triangulate an
approximate location of the handset. In
general, at least three surrounding base
stations are required to get an optimal position
fix.
Assisted GPS is a system that often significantly
improves the startup performance—i.e., time-
to-first-fix (TTFF)—of a GPS satellite-based
positioning system. A-GPS is extensively used
A-GPS (Assisted GPS) with GPS-capable cellular phones, as its
development was accelerated by the
U.S. FCC's 911 requirement to make cell phone
location data available to emergency call
dispatchers.
The automatic display at the PSAP of the
caller’s telephone number, the address/location
ALI (Automatic Location
of the telephone and supplementary emergency
Identification)
services information of the location from which
a call originates
08/12/2018 Page 102 of 119

ALT # (Alternative Telephone Customer Number being remote call forwarded

Number) in Interim Number Portability service.
ANI (Automatic Number Telephone number associated with the access
Identification) line from which a call originates.
A terrestrial Location Determination Technology
(LDT) that computes a transmitter’s location
AOA (Angle of Arrival)
based upon the angle at which the transmitter’s
radio signal strikes multiple receivers.
A standard for defining codes for information
exchange between equipment produced by
ASCII (American Standard Code for
different manufacturers. A code that follows the
Information Interchange)
American Standard Code for Information
Interchange.
A U.S.-based organization that is committed to
rapidly developing and promoting technical and
ATIS (Alliance for
operations standards for the communications
Telecommunications Industry
and related information technologies industry
Solutions)
worldwide using a pragmatic, flexible and open
approach. http://atis.org/
Cell ID (Cellular Identification Identification number indicating a geographic
Number) region of cellular coverage.
CLDXF (Civic Location Data A set of data elements that describe detailed
Exchange Format) street address information.
An identifier used in the North American
telecommunications industry to specify the
CLLI (Common Language Location
location of equipment. For example, an 8 to 11
Indicator)
character code assigned to a central office to
designate the physical location.
A US FCC designation for any carrier or licensee
CMRS (Commercial Mobile Radio
whose wireless network is connected to the
Service)
public switched telephone network.
A designation in E9-1-1 that defines the service
COCT (Customer Owned Coin
category of the telephony service for customer
Telephone)
owned coin telephone.
CoS (Class of Service) A designation in E9-1-1 that defines the service
08/12/2018 Page 103 of 119

category of the telephony service. A few

examples are residential, business, Centrex,
coin, PBX, VoIP and wireless Phase II (WPH2).
NENA-INF-018 NENA Non-Mobile Wireless
Service Interaction Information Document
Communications or terminal equipment located
CPE (Customer Premises
in the customer’s facilities – Terminal
Equipment)
equipment at a PSAP
National Spatial Data Infrastructure
Stakeholders have long utilized the Content
Standard for Digital Geospatial Metadata
(CSDGM). However, Circular A-119
Revised directs agencies to use voluntary
consensus standards in lieu of government-
unique standards. Furthermore, Circular A-
CSDGM (Content Standard for
16 promotes the use of international standards
Digital Geospatial Metadata)
to advance the building of the Global Spatial
Data Infrastructure (GSDI). Several ISO
metadata standards are now endorsed by the
Federal Geographic Data Committee (FGDC)
and federal agencies and NSDI Stakeholders
are encouraged to make the transition to ISO
metadata.
A system of manual procedures and computer
programs used to create, store and update the
DBMS (Data Base Management
data required to provide Selective Routing
System)
and/or Automatic Location Identification for E9-
1-1 systems.
An industry standard interface (defined in J-
E2 interface (Emergency Service STD-036) used between a Mobile Positioning
Protocol E2 Interface) Center (MPC/GMLC) and an ALI database
server.
U.S. trade organization that issued its own
EIA (Electronic Industry standards and contributed to the American
Association) National Standards Institute. It also acted as a
trade organization of manufacturers that set
standards for use of its member companies,
08/12/2018 Page 104 of 119

conducted education programs, and lobbied in

Washington for its members’ collective
prosperity. It was associated with the
Telecommunications Industry Association (TIA).
It ceased operations in February 2011.
A valid North American Numbering Plan format
telephone number, assigned to the MLTS
Operator by the appropriate authority that is
ELIN (Emergency Location used to route the call to a PSAP and is used to
Identification Number) retrieve the ALI for the PSAP. The ELIN may be
the same number as the ANI. The North
American Numbering Plan number may in some
cases not be a dialable number.
Enhanced Observed Time Difference (E-OTD) is
a standard for the location of mobile
telephones. The location method works by
E-OTD (Enhanced Observed Time
multilateration. Conceptually, the handset
Difference)
makes an observation of the time difference of
arrival of signals from two different base
stations.
A Location to which a 9-1-1 emergency
response team may be dispatched. The
ERL (Emergency Response location SHOULD be specific enough to provide
Location) a reasonable opportunity for the emergency
response team to quickly locate a caller
anywhere within it.
A 3-5 digit number that represents one or more
ESN (Emergency Service Number) ESZs. An ESN is defined as one of two types:
Administrative ESN and Routing ESN
A 10-digit North American Numbering Plan
number that uniquely identifies a base station,
ESRD (Emergency Services Routing cell site, or sector that is used to route wireless
Digit) emergency calls through the network. The
ESRD may also be used by the PSAP to retrieve
the associated ALI data.
A 10-digit North American Numbering Plan
ESRK (Emergency Services Routing
number that uniquely identifies a wireless
08/12/2018 Page 105 of 119

Key) emergency call, is used to route the call

through the network, and used to retrieve the
associated ALI data.
An independent U.S. government agency
overseen by Congress, the Federal
Communications Commission regulates
FCC (Federal Communications
interstate and international communications by
Commission)
radio, television, wire, satellite and cable in all
50 states, the District of Columbia and U.S.
territories.
The Registry lists PSAPs by an FCC assigned
identification number, PSAP Name, State,
County, City, and provides information on any
type of record change and the reason for
FCC PSAP registry (also known as
updating the record. The Commission updates
the Master PSAP Registry)
the Registry periodically as it receives additional
information. Available at
The Federal Geographic Data Committee
(FGDC) is an interagency committee that
FGDC (Federal Geographic Data
promotes the coordinated development, use,
Committee)
sharing, and dissemination of geospatial data
on a national basis. https://www.fgdc.gov/
Federal Information Processing Standards
(FIPS) are publicly announced standards
developed by the United States federal
FIPS (Federal Information
government for use in computer systems by
Processing Standards)
non-military government agencies and
government contractors. Refer to FIPS in
Wikipedia for overall information
An identifier to indicate the type of activity
FOC (Function of Change) and/or type of processing that the data record
is being submitted for.
A telephone line switched in an exchange or
FX (Foreign Exchange Service) central office other than the exchange or
central office area in which the telephone is
08/12/2018 Page 106 of 119

located.
A system for capturing, storing, displaying,
GIS (Geographic Information
analyzing and managing data and associated
System)
attributes which are spatially referenced.
The Global Positioning System (GPS) is a space-
based navigation system that provides location
and time information in all weather conditions,
GPS (Global Positioning System) anywhere on or near the Earth where there is
an unobstructed line of sight to four or more
GPS satellites. https://en.wikipedia.org/wiki/G
lobal_Positioning_System
The Highway Performance Monitoring System
(HPMS) is a national level highway information
HPMS (Highway Performance
system that includes data on the extent,
Monitoring System)
condition, performance, use and operating
characteristics of the nation's highways.
Hypertext Transport Protocol typically used
HTTP (Hypertext Transfer Protocol) between a web client and a web server that
transports HTML and/or XML.
HTTP with secure transport (Transport Layer
HTTPS (Hypertext Transfer
Security or its predecessor, Secure Sockets
Protocol Secure)
Layer)
An architecture to connect emergency callers in
the IP domain with Public Safety Answering
Points (PSAPs) supported by the existing E9-1-1
i2
network infrastructure. This interim step in the
migration towards end-to-end IP networks is
referred to as i2.
NENA i3 introduces the concept of an
Emergency Services IP network (ESInet), which
i3 is designed as an IP-based inter-network
(network of networks) shared by all agencies
which may be involved in any emergency.
IPBX or IP PBX (Internet Protocol An IP PBX is a private branch exchange

Private Branch Exchange) (telephone switching system within an
enterprise) that switches calls between VoIP
08/12/2018 Page 107 of 119

(Voice over Internet Protocol or IP) users on

local lines while allowing all users to share a
certain number of external phone lines. The
typical IP PBX can also switch calls between a
VoIP user and a traditional telephone user, or
between two traditional telephone users in the
same way that a conventional PBX does. The
abbreviation may appear in various texts as IP-
PBX, IP/PBX, or IPPBX.
Includes patents, published and unpublished
patent applications, copyrights, trademarks, and
trade secret rights, as well as any intellectual
IPR (Intellectual Property Rights)
property right resembling a member of the
foregoing list as such right may exist in a
particular jurisdiction. www.nena.org/IPR
An independent, non-governmental
ISO (International Standards international organization with a membership of
Organization) 161 national standards bodies.
https://www.iso.org
A system which computes the x and y
LDT (Location Determination
coordinates of a wireless 9-1-1 caller, and z,
Technology)
where applicable.
A process by which a telephone number may be
LNP (Local Number Portability) reassigned from one Local Exchange Carrier to
another
A system comprised of common control unit(s),
telephone sets, control hardware and software
and adjunct systems used to support the
capabilities outlined herein. This includes
network and premises based systems. E.g.,
MLTS (Multi-Line Telephone
Centrex, VoIP, as well as PBX, Hybrid, and Key
System)
Telephone Systems (as classified by the FCC
under Part 68 Requirements) and includes
systems owned or leased by governmental
agencies and non-profit entities, as well as for
profit businesses.
MMS (Multimedia Messaging Multimedia Messaging Service (MMS) is an
08/12/2018 Page 108 of 119

Service) evolution of the SMS. With a MMS, you can

send a message including pictures, video, or
audio content to another device. With a MMS,
you can send a message including pictures,
video, or audio content to another device.
A database of street names and house number
ranges within their associated communities
MSAG (Master Street Address
defining Emergency Service Zones (ESZs) and
Guide)
their associated Emergency Service Numbers
(ESNs) to enable proper routing of 9-1-1 calls.
A geographic coordinate system, based on
modern satellite measurements of the shape of
NAD83 (North American Datum 83)
the earth, used to represent spatial features on
a flat map display.
The National Emergency Address Database
(NEAD) is defined by the Federal
Communications Commission (FCC) in 47 C.F.R.
20.18(i)(1) as “[a] database that utilizes MAC
address information to identify a dispatchable
location for nearby wireless devices within the
CMRS provider’s coverage footprint.” That
same FCC rule also defines dispatchable
location as “[a] location delivered to
NEAD (National Emergency
the PSAP by the CMRS provider with a 911 call
Address Database)
that consists of the street address of the calling
party, plus additional information such as suite,
apartment or similar information necessary to
adequately identify the location of the calling
party. The street address of the calling party
must be validated and, to the extent possible,
corroborated against other location information
prior to delivery of dispatchable location
information by the CMRS provider to the PSAP.”
The National Emergency Number Association is
NENA (National Emergency a not-for-profit corporation established in 1982
Number Association) to further the goal of “One Nation-One
Number.” NENA is a networking source and
promotes research, planning and training. NENA
08/12/2018 Page 109 of 119

strives to educate, set standards and provide

certification programs, legislative representation
and technical assistance for implementing and
managing 9-1-1 systems. www.nena.org
The NEW LINE character is a single character
NL (New Line) character that identifies the end of record in all cases for
all records. (ASCII HEX-0A)
An established three-digit area code for a
particular calling area where the first position is
NPA (Numbering Plan Area)
any number 2 through 9 and the last two (2)
positions are 0 through 9.
An Off-Premises Extension (OPX) is a dedicated
circuit connecting a distant location to a main
OPX (Off-Premises Extension)
PBX to provide the same phone system features
available at the main location.
Over-the-top (OTT) services that bypass
OTT (over-the-top) traditional network distribution approaches and
run over, or on top of, core Internet networks.
pANI (Pseudo Automatic Number A telephone number used to support routing of

Identification) wireless 9-1-1 calls. It may identify a wireless
cell, cell sector or PSAP to which the call should
AKA: routing number be routed.
A private telephone switch that is connected to
PBX (Private Branch Exchange) the Public Switched Telephone Network.
A service option which provides Enhanced 9-1-1

PSALI (Private Switch ALI) features for telephone stations behind private
switches. E.g. PBXs.
An entity responsible for receiving 9-1-1 calls
and processing those calls according to a
PSAP (Public Safety Answering specific operational policy.
Point)  Primary PSAP: A PSAP to which 9-1-1 calls are
routed directly from the 9-1-1 Control Office.
 Secondary PSAP: A PSAP to which 9-1-1 calls
08/12/2018 Page 110 of 119

are transferred from a Primary PSAP.

 Alternate PSAP: A PSAP designated to receive
calls when the primary PSAP is unable to do so.
 Consolidated PSAP: A facility where multiple
Public Safety Agencies choose to operate as a
single 9-1-1 entity.
 Legacy PSAP: A PSAP that cannot process
calls received via i3-defined call interfaces
(IPbased calls) and still requires the use of
CAMA or ISDN trunk technology for delivery of
9-1-1 emergency calls.
 Serving PSAP: The PSAP to which a call would
normally be routed.
“PSAP ID” sometimes be used to mean “the
Code identifying the PSAP associated with the
PSAP ID assigned ESN,” but may also sometimes be
used to mean the Code identifying the PSAP as
listed in the FCC PSAP registry.
Radio frequency fingerprinting is a process that
identifies the device or signaler from which a
radio transmission originated by looking at the
RF Fingerprinting properties of its transmission, including specific
radio frequencies. Each signal originator has its
own specific "fingerprint" based on the location
and configuration of its transmitted signals.
RR Railroad
Text transmission that is character at a time, as
RTT (Real-Time Text)
in TTY.
The Standard Generalized Markup Language
SGML (Standard Generalized
(SGML) is a standard for defining generalized
Markup Language)
markup languages for documents.
A service typically provided by mobile carriers
that sends short (160 characters or fewer)
SMS (Short Message Service)
messages to an endpoint. SMS is often fast, but
is not real time.
08/12/2018 Page 111 of 119

SOAP is a protocol for exchanging XML-based

messages over a computer network, normally
SOAP (Simple Object Access using HTTP. SOAP forms the foundation layer of
Protocol) the Web services stack, providing a basic
messaging framework that more abstract layers
can build on.
STX/ETX is a simple packet protocol for serial
STX/ETX (Start of Text /End of
data streams and offers packetization, type
Text)
tagging, and checksum protection for user data.
A Taxing Area Rate (TAR) Code is an
abbreviation that may sometimes be used in a
TAR (Taxing Area Rate) Code
legacy service order system and that may
identify a taxing area.
A communications protocol linking different
TCP/IP (Transmission Control computer platforms across networks. TCP/IP
Protocol/Internet Protocol) functions at the 3rd and 4th levels of the Open
Systems Interconnection model.
A terrestrial Location Determination Technology
(LDT) that computes a transmitter’s location
TDOA (Time Difference of Arrival)
based upon the times a signal is received at
multiple receivers.
A lobbying and trade association, the result of
TIA (Telecommunications Industry the merger of the USTA (United States
Association) Telephone Association) and the EIA (Electronic
Industries Association).
TN (Telephone Number) Telephone Number
Time of arrival (TOA or ToA), sometimes
called time of flight (ToF), is the travel time of a
TOA (Time of Arrival)
radio signal from a single transmitter to a
remote single receiver.
The phrase TTY (or Teletype device) is how the
TTY (Teletypewriter) deaf community used to refer to the extremely
large machines they used to type messages
A.K.A. TDD (Telecommunications
back and forth over the phone lines. A TDD
Device for the Deaf)
operates in a similar way, but is a much smaller
desktop machine. The deaf community has
08/12/2018 Page 112 of 119

used the phrase "TTY" and sometimes uses it

interchangeably with "TDD."
http://www.gallaudet.edu/dpn-home/ttyrelays-
and-closed-captions.html
This worksheet and the accompanying
completion rules ensure that PSAPs or the 9-1-1
TVW (Testing Validation Governing Authority have all of the data
Worksheet) elements they need in order to make informed
call routing decisions and to update their CAD
and mapping applications.
A URL is a type of URI, specifically used for
URL (Uniform Resource Locator) describing and navigating to a resource (e.g.,
http://www.nena.org)
United States Department of Transportation
USDOT
(USDOT)
USPS (United States Postal United States Postal Service
Service)
The primary time standard in the world based
on the time zone in Greenwich, England. Also
known as Zulu or Greenwich Mean Time (GMT).
UTC (Universal Coordinated Time)
Time provided by National Institute of
Standards and Technology (NIST) and United
States Naval Observatory (USNO).
Technology that permits delivery of voice calls
VoIP (Voice over Internet Protocol) and other real-time multimedia sessions over IP
networks.
W3C (World Wide Web World Wide Web Consortium (W3C)
Consortium)
The World Geodetic System reference
WGS 84 (World Geodetic System coordinate system used by the Global
for 1984) Positioning Systems and in cartography and
navigation.
A wireless networking technology that uses
Wi-Fi radio waves to provide wireless high-speed
internet and network connections. Wi-Fi is a
08/12/2018 Page 113 of 119

registered trademark phrase that means IEEE

802.11x
A service offering being used by some wireless
carriers, cable companies, other companies,
and some enterprise customers that seek to
deliver voice calls over Wi-Fi. In the context of
9-1-1 calling at least from major wireless
carriers, there is a general first preference for
the mobile handset to send 9-1-1 calls over the
Wi-Fi Calling CMRS or VoLTE networks where available and
Wi-Fi calling may only be used when such does
not occur within a period of several seconds.
Where the 9-1-1 calling is done via Wi-Fi
calling, the connectivity from the Wi-Fi access
point to the 9-1-1 system is comparable to
connectivity from a wired broadband connection
for VoIP to the 9-1-1 system.
A residential or business Digital Enhanced
Cordless Telephone (DECT) phone adapter
device that generally provides home phone
calling through wireless Commercial Mobile
Radio Service connected services; generally
requires an AC power source; is generally not
WHP (Wireless Home Phone) used in a mobile context (as is a wireless
handset); and is designed for use at a fixed
location. This device may support nomadic as
well as static use cases. It is also technically
possible for this device to be used in a mobile
manner where a mobile AC power source is also
available, such as in a motor home.
The Web Services Description Language
(WSDL) is an XML-based language used to
describe the services a business offers and to
WSDL (Web Service Description provide a way for individuals and other
Language) businesses to access those services
electronically. WSDL is the cornerstone of the
Universal Description, Discovery, and
Integration (UDDI) initiative spearheaded by
08/12/2018 Page 114 of 119

Microsoft, IBM, and ARIBA. UDDI is an XML-

based registry for businesses worldwide, which
enables businesses to list themselves and their
services on the Internet. WSDL is the language
used to do this. WSDL is derived from
Microsoft’s Simple Object Access Protocol
(SOAP) and IBM’s Network Accessible Service
Specification Language (NASSL). WSDL replaces
both NASSL and SOAP as the means of
expressing business services in the UDDI
registry. An XML-based interface definition
language that is used for describing the
functionality offered by a web service.
X Coordinate (Longitude) Longitude coordinate.
An internet specification for web documents
that enables tags to be used that provide
functionality beyond that in Hyper Text Markup
Language (HTML). In contrast to HTML, XML
XML (eXtensible Markup Language) has the ability to allow information of
indeterminate length to be transmitted to a
PSAP call taker or dispatcher versus the current
restriction that requires information to fit the
parameters of predefined fields.
The formal document definition (structure,
content type and constraints) describing a class
XML (eXtensible Markup Language) of XML instance documents. There are various
Schema XML schema languages, but in this document,
all schemas are assumed to be defined using
the W3C XML Schema definition language.
Y Coordinate (Latitude) Latitude coordinate.
Elevation/Altitude indicated as height different
from mean sea level (plus or minus), measured
Z Coordinate (Elevation)
in meters. (This is not intended to include floor
level or uncompensated barometric pressure.)
08/12/2018 Page 115 of 119

23 Recommended Reading and References

[1] NENA Master Glossary of 9 1 1 Terminology, NENA-ADM-000
[2] U.S. Department of Transportation - Federal Railroad Administration– Secretary’s
Action Plan for Highway-Rail Crossing Safety and Trespass Prevention Secretary of
Transportation
[3] NENA Data Standards For Local Exchange Carriers, ALI Service Providers & 9-1-1
Jurisdictions, NENA-STA-030 (originally 02-011)
[4] NENA GIS Data Collection and Maintenance Standards, NENA-STA-032
(originally 02-014)
[5] Wireless Phase I & II Features and Functions Operational Information Document,
NENA 57-001
[6] Refer to NENA ALI Query Service Standard for specifications on XML ALI source data
exchange, NENA-STA-029 (originally 04-005)
08/12/2018 Page 116 of 119

ACKNOWLEDGEMENTS
The National Emergency Number Association (NENA) Data Structures Committee, Class of
Service Working Group developed this document.
Executive Board Approval Date: 08/12/2018
NENA recognizes the following industry experts and their employers for their contributions
in development of this document.
Members Employer
Brooks Shannon, Data Structures INdigital Telecom
Committee Co-Chair
John Beasley, Data Structures Ark-Tex Council Of Governments, TX
Committee Co-Chair and Working Group
Co-Chair
Richard Muscat, Working Group Co- Bexar Metro 9-1-1 Network District, TX
Chair
Bruce Wilson Qualcomm Technologies, Inc.
Christian Lounsbury, ENP Missoula County, MT
Christian Militeau, ENP West Safety Services
Daryl Ostendorf City of O’Fallon, IL
Glenna Johnson DeKalb County, IL
James Leyerle, ENP OnStar
Jason Horning, ENP North Dakota Association of Counties
Jason Ramsay, ENP West Safety Services
Jay Slater, ENP Bandwidth
Jesseca Mundahl, ENP Metro Communications Agency, SD
Jim McDaniel AT&T
John Cummings, ENP Time Warner Cable
John Kozlowski Aculab
Joshua Howell, ENP City of Grand Rapids, MI
08/12/2018 Page 117 of 119

Julie Harmon, ENP Capital Area Council of Governments, TX

Kathy McMahon Mission Critical Partners
LaToya Marz City of DeKalb, IL
LeAnna Russell, ENP North Central Texas Council of Government
Lee Meyer Time Warner Cable
Lisa Wirtanen AT&T
Mark Whitby, ENP Pinellas County, FL
Peter McHale, ENP Verizon Wireless
Rebekah Craft City of Salem, VA
Regina Payne Montgomery County Emergency
Communications District, TX
Reinhard Ekl RapidSOS
Robert Gasper, ENP State of Maine
Rochelle Dodd, ENP Greater Harris County Emergency Network, TX
Roger Hixson, ENP NENA
Roger Marshall Comtech Telecommunications Corporation
Sharon Nichol-Jost, ENP Bexar Metro 9-1-1 Network District, TX
Steve Leese APCO
Susan Pettingill, ENP Orange County, FL
Theresa Reese Ericsson Inc.
Tom Breen, ENP Comtech Telecommunications Corporation
Tommy Takeshita, ENP Akimeka LLC
Vonda Payne Commission on State Emergency
Communications, TX
Wendi Lively, ENP Spartanburg County, SC
08/12/2018 Page 118 of 119

Special Acknowledgements:
Delaine Arnold ENP, Committee Resource Manager, has facilitated the production of this
document through the prescribed approval process.
The Class of Service Working Group is part of the NENA Development Group that is led by:
 Pete Eggimann ENP and Jim Shepard ENP, Development Steering Council Co-Chairs
 Roger Hixson ENP, Technical Issues Director
 Chris Carver ENP, PSAP Operations Director
08/12/2018 Page 119 of 119

Nena Sta 015.10 2018 - Datakkk

Uploaded by

Copyright:

Available Formats

Nena Sta 015.10 2018 - Datakkk

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nena Sta 015.10 2018 - Datakkk

Uploaded by

Copyright:

Available Formats

NENA

Standard Data Formats

NENA-STA-015.10-2018 (Originally 02-010)

© Copyright 2018 National Emergency Number Association, Inc.

08/12/2018 Page 2 of 119

© Copyright 2018 National Emergency Number Association, Inc.

1 EXECUTIVE OVERVIEW ............................................................................................................................... 2

08/12/2018 Page 3 of 119

© Copyright 2018 National Emergency Number Association, Inc.

5 VERSION 2.1 FORMAT FOR DATA EXCHANGE ................................................................................... 29

© Copyright 2018 National Emergency Number Association, Inc.

16.1 GEOPRIV DIRECTORY AND SCHEMAS ................................................................................................................ 72

© Copyright 2018 National Emergency Number Association, Inc.

22.1 OPERATIONAL IMPACTS SUMMARY.................................................................................................................... 99

08/12/2018 Page 6 of 119

© Copyright 2018 National Emergency Number Association, Inc.

It is possible that certain advances in technology or changes in governmental regulations will

08/12/2018 Page 7 of 119

© Copyright 2018 National Emergency Number Association, Inc.

08/12/2018 Page 8 of 119

© Copyright 2018 National Emergency Number Association, Inc.

Intellectual Property Rights (IPR) Policy

Reason for Issue/Reissue

08/12/2018 Page 9 of 119

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

Version 4 Data Exchange Format is an industry

08/12/2018 Page 11 of 119

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

08/12/2018 Page 12 of 119

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

08/12/2018 Page 14 of 119

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

© Copyright 2018 National Emergency Number Association, Inc.

Document Number Approval Reason For Issue/Reissue

08/12/2018 Page 16 of 119

© Copyright 2018 National Emergency Number Association, Inc.

2.1 Types of Data Exchange Formats

08/12/2018 Page 17 of 119

© Copyright 2018 National Emergency Number Association, Inc.

2.1.1 Common Considerations:

2.1.2 Version 1 & 2 formats:

08/12/2018 Page 18 of 119

© Copyright 2018 National Emergency Number Association, Inc.

2.1.3 Version 3 data formats:

2.1.4 Version 4 Description Summary:

08/12/2018 Page 19 of 119

© Copyright 2018 National Emergency Number Association, Inc.

<xs:complexType Individual components or

 In XML, records are referred to as “documents”.

08/12/2018 Page 20 of 119

© Copyright 2018 National Emergency Number Association, Inc.