Standard Data Formats For 9-1-1 Data Exchange & GIS Mapping

NENA

Standard Data Formats

For 9-1-1 Data Exchange

& GIS Mapping

NENA Standard Data Formats for 9-1-1 Data Exchange & GIS Mapping

NENA-02-010, Version 9, December 16, 2010

Standard Advisory Board Approval Date, February 2, 2011

NENA Executive Board Approval Date, March 28, 2011

Prepared by:

National Emergency Number Association (NENA) Technical Committee Chairs

Published by NENA

Printed in USA

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 2 of 103

NENA STANDARDS

NOTICE

The National Emergency Number Association (NENA) publishes this document as a guide for the designers

and manufacturers of systems to utilize for the purpose of processing emergency calls. It is not intended to

provide complete design specifications or parameters or to assure the quality of performance of such equipment.

NENA reserves the right to revise this NENA STANDARD 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

 or to reflect changes in the design of equipment or services described herein.

It is possible that certain advances in technology will precede these revisions. Therefore, this NENA

STANDARD should not be the only source of information used. NENA recommends that readers contact their

Telecommunications Carrier representative to ensure compatibility with the 9-1-1 network.

Patents may cover the specifications, techniques or network interface/system characteristics disclosed herein.

No license expressed or implied is hereby granted. 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.

This document has been prepared solely for the voluntary use of E9-1-1 Service System Providers, network

interface and system vendors, participating telephone companies, etc.

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 Technical Committee has developed this document. Recommendations for change to this document

may be submitted to:

National Emergency Number Association

4350 N. Fairfax Drive, Suite 750

Arlington, VA 22203-1695

800-332-3911

or: [email protected]

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 3 of 103

Acknowledgments:

The National Emergency Number Association (NENA) Data Technical Committee, Data Exchange Working

Group and GIS Data Model Working Group developed this document.

NENA recognizes the following industry experts and their companies for their contributions in development of

this document.

Version 9, Approved: March 28, 2011

Members Company

Erica Aubut, Data Technical Committee Vice-Chair, GIS

Working Group Leader and Technical Editor

State of Vermont

Delaine Arnold, Data Technical Committee Chair Arnold 9-1-1 Consulting

Patty Bluhm, Data Exchange Formats Working Group Leader

and XML Editor

Intrado

Marc Berryman Data Digital Technologies, Inc.

Carlton B. Walls, III Lancaster County-Wide

Communications

Gordon Chinander Metropolitan Emergency

Services Board

Kathy Lillequist Geo-Comm

Sharon Nichol-Jost Bexar Metro 9-1-1

Carl Reed Open Geospatial Consortium

Robert White State of Maine

Adam Iten State of Arizona

Robert Long Bexar Metro 9-1-1

This committee would also thank Tom Breen, Technical Committee Chair/Liaison, Tony Busam, Technical

Committee Vice-Chair/Liaison, and Roger Hixson, Technical Issues Director, for their support and assistance.

The committee/working group would also like to give a special thank you to Patty Bluhm and Open Geospatial

Consortium for all their efforts, support & assistance in developing the NG9-1-1 GIS Data Model.

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 4 of 103

TABLE OF CONTENTS

1 EXECUTIVE OVERVIEW ............................................................................................................................... 8

1.1 PURPOSE AND SCOPE OF DOCUMENT .................................................................................................................... 8

1.2 REASON TO IMPLEMENT ........................................................................................................................................ 8

1.3 BENEFITS .............................................................................................................................................................. 9

2 INTRODUCTION .............................................................................................................................................. 9

2.1 OPERATIONAL IMPACTS SUMMARY ...................................................................................................................... 9

2.2 SECURITY IMPACTS SUMMARY ........................................................................................................................... 10

2.3 DOCUMENT TERMINOLOGY ................................................................................................................................. 10

2.4 REASON FOR ISSUE .............................................................................................................................................. 10

2.5 RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK ............................................................................. 16

2.6 DATE COMPLIANCE ............................................................................................................................................. 16

2.7 ANTICIPATED TIMELINE ...................................................................................................................................... 16

2.8 COSTS FACTORS .................................................................................................................................................. 16

2.9 FUTURE PATH PLAN CRITERIA FOR TECHNICAL EVOLUTION .............................................................................. 17

2.10 COST RECOVERY CONSIDERATIONS ............................................................................................................... 17

2.11 ADDITIONAL IMPACTS (NON COST RELATED ................................................................................................... 17

2.12 INTELLECTUAL PROPERTY RIGHTS POLICY .................................................................................................... 17

2.13 ACRONYMS/ABBREVIATIONS ......................................................................................................................... 18

3 TECHNICAL DESCRIPTION ....................................................................................................................... 19

3.1 TYPES OF DATA EXCHANGE FORMATS................................................................................................................ 19

3.1.1 Common Considerations: ......................................................................................................................... 20

3.1.2 Version 1 & 2 formats: ............................................................................................................................. 20

3.1.3 Version 3 data formats: ............................................................................................................................ 20

3.1.4 Version 4 Description Summary: .............................................................................................................. 22

4 RECOMMENDED READING AND REFERENCES .................................................................................. 23

5 EXHIBITS......................................................................................................................................................... 24

EXHIBIT 1 ................................................................................................................................................................. 24

5.1 VERSION 1 FORMAT FOR DATA EXCHANGE (OBSOLETE – DO NOT USE) ............................................. 24

EXHIBIT 2 ................................................................................................................................................................. 29

5.2 VERSION 1 FORMAT FOR MSAG DATA EXCHANGE (OBSOLETE – DO NOT USE) ................................ 29

EXHIBIT 3 ................................................................................................................................................................. 30

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 5 of 103

5.3 VERSION 1 HEADER FORMAT FOR DATA EXCHANGE (OBSOLETE – DO NOT USE) ............................ 30

EXHIBIT 4 ................................................................................................................................................................. 31

5.4 VERSION 1 TRAILER FORMAT FOR DATA EXCHANGE (OBSOLETE – DO NOT USE) ........................... 31

EXHIBIT 5 ................................................................................................................................................................. 32

5.5 VERSION 2.0 FORMAT FOR DATA EXCHANGE ........................................................................................ 32

5.6 VERSION 2.0 FORMAT FOR MSAG DATA EXCHANGE ............................................................................ 32

5.7 VERSION 2.0 HEADER FORMAT FOR DATA EXCHANGE ........................................................................ 32

5.8 VERSION 2.0 TRAILER FORMAT FOR DATA EXCHANGE ....................................................................... 32

EXHIBIT 6 ................................................................................................................................................................. 33

5.9 VERSION 2.1 FORMAT FOR DATA EXCHANGE ........................................................................................ 33

EXHIBIT 7 ................................................................................................................................................................. 41

5.10 VERSION 2.1 FORMAT FOR MSAG DATA EXCHANGE ....................................................................... 41

EXHIBIT 8 ................................................................................................................................................................. 45

5.11 VERSION 2.1 HEADER FORMAT FOR DATA EXCHANGE ................................................................... 45

EXHIBIT 9 ................................................................................................................................................................. 46

5.12 VERSION 2.1 TRAILER FORMAT FOR DATA EXCHANGE .................................................................. 46

EXHIBIT 10 ............................................................................................................................................................... 47

5.13 VERSION 3.1 FORMAT FOR DATA EXCHANGE .................................................................................... 47

5.13.1 Data Record Format Example: ............................................................................................................ 58

EXHIBIT 11 ............................................................................................................................................................... 59

5.14 VERSION 3.1 FORMAT FOR MSAG DATA EXCHANGE ....................................................................... 59

EXHIBIT 12 ............................................................................................................................................................... 63

5.15 VERSION 3.1 HEADER FORMAT FOR DATA EXCHANGE ................................................................... 63

5.15.1 Header Record Format Example: ........................................................................................................ 63

EXHIBIT 13 ............................................................................................................................................................... 65

5.16 VERSION 3.1 TRAILER FORMAT FOR DATA EXCHANGE .................................................................. 65

EXHIBIT 14 ............................................................................................................................................................... 66

5.17 VERSION 3.1 WIRELESS DATA EXCHANGE ......................................................................................... 66

5.17.1 Dynamic Updates of the ALI Database ................................................................................................ 66

EXHIBIT 15 ............................................................................................................................................................... 73

5.18 VERSION 4 XML FORMAT FOR DATA EXCHANGE ............................................................................. 73

5.18.1 The XML Schema ................................................................................................................................. 73

5.18.2 Schema Version Control ...................................................................................................................... 73

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 6 of 103

5.18.3 Schema Design ..................................................................................................................................... 74

5.18.4 Schema Extensions ............................................................................................................................... 74

5.18.5 Schema Validation ............................................................................................................................... 74

5.18.6 Validation Point ................................................................................................................................... 74

5.18.7 Redefining of Data Elements ................................................................................................................ 75

5.18.8 Two examples of this redefining are described below. ......................................................................... 75

5.18.9 Transmission Protocol ......................................................................................................................... 75

5.18.10 XML Schema Location ......................................................................................................................... 76

5.18.11 Example of the relationship between schema Generations and subsequent Releases ......................... 78

5.18.12 All schemas: ......................................................................................................................................... 79

6 ALI SCHEMAS ................................................................................................................................................ 79

6.1.1 ALI.xsd ...................................................................................................................................................... 79

6.1.2 ALITypeLib.xsd ......................................................................................................................................... 80

6.1.3 ALI Query Service Directory and Schemas .............................................................................................. 81

6.1.4 AQS and AQS.WS Removed ...................................................................................................................... 81

6.1.5 MSAGRecord.xsd ...................................................................................................................................... 81

7 I2 SCHEMAS .................................................................................................................................................... 81

7.1.1 Geopriv Directory and Schemas ............................................................................................................... 81

7.1.2 GML-3.1.1 Directory and Schemas .......................................................................................................... 81

7.1.3 All I2 Schemas .......................................................................................................................................... 81

7.1.4 V2.xsd ....................................................................................................................................................... 83

7.1.5 V7.xsd ....................................................................................................................................................... 83

7.1.6 V8.xsd ....................................................................................................................................................... 83

7.1.7 V9.xsd ....................................................................................................................................................... 83

EXHIBIT 22 ............................................................................................................................................................... 83

GIS DATA MODEL, VERSION 2.0 ........................................................................................................................... 83

1.0 Preface .................................................................................................................................................................. 83

1.2 9-1-1 SPATIAL ATTRIBUTES FOR LINE DATA ........................................................................................... 86

1.2.1B. RAILROAD LAYER (OPTIONAL).................................................................................................................. 90

1.2.1C. HYDROLOGY LAYER (OPTIONAL) .............................................................................................................. 91

1.3. 9-1-1 SPATIAL ATTRIBUTES FOR POINT DATA ................................................................................... 92

1.3. A EMERGENCY SERVICE AGENCY LOCATION LAYER (REQUIRED) .................................................................... 92

1.3 B. CELL SITE LOCATION LAYER (REQUIRED) ..................................................................................................... 94

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 7 of 103

1.3 C. MILE MARKER LOCATION LAYER (OPTIONAL) .............................................................................................. 95

1.3 E. SITE/STRUCTURE LOCATION LAYER (OPTIONAL) .............................................................................................. 96

1.4. 9-1-1 SPATIAL ATTRIBUTES FOR POLYGON DATA ............................................................................ 98

1.4 A. COUNTY BOUNDARY LAYER (REQUIRED) ...................................................................................................... 98

1.4 B. EMERGENCY SERVICE ZONE BOUNDARY LAYER (REQUIRED) ....................................................................... 98

1.4 C. MUNICIPAL BOUNDARY LAYER (REQUIRED) ................................................................................................. 99

7.4 ................................................................................................................................................................................ 99

7.5 1.4 D. EMERGENCY SERVICE AGENCY BOUNDARY LAYER (REQUIRED) ............................................................. 99

1.4 E. CELL SITE COVERAGE LAYER (REQUIRED) .................................................................................................. 100

1.4 F.  Hydrology Layer (Optional) ............................................................................................................................... 102

99 PREVIOUS ACKNOWLEDGMENTS ........................................................................................................ 103

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 8 of 103

1 Executive Overview

1.1 Purpose and Scope of Document

This document sets forth NENA standard formats for Automatic Location Identification (ALI) data exchange

between Service Providers and Data Base Management System Providers, a GIS data model, a Data Dictionary,

and formats for data exchange between the ALI Database and PSAP Controller equipment.

Movement of ALI source data between Service Providers and/or Data Base Management System Providers is a

necessary and common activity for the activation of E9-1-1 systems. Means of moving such data is varied and

many. This document contains data exchange formats recommended for creation and transporting of 9-1-1 data.

This recommendation advocates the use of one of two common protocols (KERMIT and NDM) for use in the

near term and with a move toward one common protocol (TCP/IP) in the future. The recommendation unfolded

in this manner with the recognition that as a goal NENA acknowledges the advantage of one protocol, but that

existing systems are in place so an evolution plan must be put in place and that no single protocol can satisfy all

applications.

1.2 Reason to Implement

Industry adoption of the standard will:

 Minimize costs incurred in providing E9-1-1 data base services.

 Ensure timely activation of E9-1-1 data base systems.

 Ensure consistent provision of ALI data.

 Enable data compatibility for system integration of E9-1-1 products and services.

 Minimize set-up time

 Aid companies in future planning

When to Implement

Since many Service Providers, Data Base Management System Providers and equipment vendors are currently

utilizing the original Version 1 and 2 data exchange formats defined herein, it is strongly recommended that

Version 4 XML formats be implemented to provide for future data needs. Service Providers and the respective

Data Base Management System Provider must jointly determine the data format most relevant to the system

software being utilized.

A goal of January 1, 2000 was recommended as the date when Service Providers would be capable of sending

data utilizing the revised Version 2.0 (now 2.1) format and Version 3.0 format to the Data Base Management

System.

It was further understood that many in-service data flows were unable to conform to the NENA formats by the

target date, but the Data Technical Committee strongly recommends that every effort be made to conform to at

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 9 of 103

least one of the NENA data exchange formats preferably the most current Generation of Version 4 as found on

the NENA Internet site at http://www.nena.org/xml_schemas/nena.htm

.

July 1, 1994 was established as the date when Service Providers and Data Base Management Service Providers

should be capable of using the transmission protocol options. All future plans should include the ability to use

these options.

Version 4 Data Exchange Format should be implemented in conjunction with wireless phase II.

1.3 Benefits

The benefits that will be realized by implementing the newly defined NENA Version 4 standard in this

document may not be immediately discernable. While all NENA standards promote a consistent view of 911

data, this release of the NENA 02-010 document provides the first major departure from the previously held

standard for data exchange by introducing the XML data exchange format coordinated between 911 data source

technologies. This release of NENA Version 4 lays the groundwork necessary to support the ever growing and

changing sources of 911 data.

Utilizing the changes outlined in this document will allow the use of industry standard tools for XML data

processing. While this will not eliminate the need for future programming effort it does provide a standard

approach to the identification, transmission and processing of data from many sources each with its unique data

format and structure.

NENA Version 4 Data Exchange Format is an industry standard XML data format. NENA XML (Extensible

Markup Language) documents have been adapted from SGML (Standard Generalized Markup Language) by

the World Wide Web Consortium. Version 4 Data Exchange Format has been 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.

In addition to the XML changes this document introduces a new field to the previous NENA version 2.1. As a

result of the implementation of private switch 911 and the common use of the NENA 2.1 format, we have added

a field for NENA Data Provider ID (Company ID 2) and renamed the existing Dial Tone Provider field to

Access Infrastructure Provider (Company ID 1). The character space for new data field was taken from the last

5 character positions in the NENA Reserved data field. Since these character positions were reserved for NENA

only use there should be no impact on operating systems. For those companies utilizing Private Switch 911, this

change provides a location for both the Access Infrastructure Provider (Company ID 1) and the provider of the

PBX station data provider. (Company ID 2)

2 Introduction

2.1 Operational Impacts Summary

Due to the increased volume and unique format of XML data, implementing the current changes to NENA 4

will impact all systems and network elements associated with the creation, transport and processing of 911

XML data.

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 10 of 103

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.

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

2.3 Document Terminology

The terms “shall “, “must” and “required” are used throughout this document to indicate required parameters

and to differentiate from those parameters that are recommendations. Recommendations are identified by the

words “desirable” or “preferably”.

2.4 Reason for Issue

NENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in this

paragraph.

Version Date Reason For Changes

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

2 06/15/1993 NENA Version 2 Data Exchange Format created.

3 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 “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

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 11 of 103

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.

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

5 01/22/2002

Version 3.0 formats were changed to Version 3.1 with the

introduction of Version 4, and the need 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 SGML

(Standard Generalized Markup Language) by the World

Wide Web Consortium. Version 4 Data Exchange Format

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 12 of 103

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

.

6 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

 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 Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 13 of 103

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

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 being

displayed at the PSAP)

 E = VoIP Coin/Pay Phone (preferably with VPAY

being displayed at the PSAP)

 F = VoIP Wireless (preferably with VMBL being

displayed at the PSAP)

 J = VoIP Nomadic (preferably with VNOM being

displayed at the PSAP)

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

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 14 of 103

Exhibit 22 for GIS mapping was unintentionally omitted

from the last version of the 02-010 document. Exhibit 22

has been re-inserted into this version, no changes were

made to Exhibit 22.

New Class of Service for Wireless Phase II – added COS

“I” that tells the PSAP the call is from 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 (WSDLs) as well as the I2

WSDLs. http://www.nena.org/xml_schemas/nena.htm

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 15 of 103

8 03/30/2007

Establish Function of Change for 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

http://www.nena.org/pages/Content.asp?CID=76&CTID=5

.

The formal document name is “04-005 NENA ALI Query

Service Standard”.

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

8.2 06/10/2009

Updated all urls to agree with new web pages.

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 16 of 103

9 12/16/2010

Modified Exhibit 22, GIS Data Model, Version 2.

Updated to most current template by adding the following

new sections:

2.2

SECURITY IMPACTS SUMMARY .........................................

E

2.5 RECOMMENDATION FOR ADDITIONAL DEVELOPMENT

WORK .......................................................................................

E

2.9 FUTURE PATH PLAN CRITERIA FOR TECHNICAL

EVOLUTION ..............................................................................

E

2.11 ADDITIONAL IMPACTS (NON COST RELATED .................

E

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

2.6 Date Compliance

All systems that are associated with the 9-1-1 process shall be designed and engineered to ensure that no

detrimental, or other noticeable impact of any kind, will occur as a result of a date/time change up to 30 years

subsequent to the manufacture of the system. This shall include embedded application, computer based or any

other type application.

To ensure true compliance the manufacturer shall upon request provide verifiable test results to an industry

acceptable test plan such as Telcordia GR-2945 or equivalent.

2.7 Anticipated Timeline

Deployment or implementation of this standard will take place as required.

2.8 Costs Factors

The implementation of the XML portion of this standard will require programming changes to all 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.

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 17 of 103

2.9 Future Path Plan Criteria for Technical Evolution

In present and future applications of all technologies used for 9-1-1 call and data delivery, it is a requirement to

maintain the same level or improve on the reliability and service characteristics inherent in present 9-1-1 system

design.

New methods or solutions for current and future service needs and options should meet the criteria below. This

inherently requires knowledge of current 9-1-1 system design factors and concepts, in order to evaluate new

proposed methods or solutions against the Path Plan criteria.

Criteria to meet the Definition/Requirement:

1. Reliability/dependability as governed by NENA’s technical standards and other generally accepted base

characteristics of E9-1-1 service

2. Service parity for all potential 9-1-1 callers

3. Least complicated system design that results in fewest components to achieve needs (simplicity,

maintainable)

4. Maximum probabilities for call and data delivery with least cost approach

5. Documented procedures, practices, and processes to ensure adequate implementation and ongoing

maintenance for 9-1-1 systems

This basic technical policy is a guideline to focus technical development work on maintaining fundamental

characteristics of E9-1-1 service by anyone providing equipment, software, or services.

2.10 Cost Recovery Considerations

Normal business practices shall govern the cost recovery.

2.11 Additional Impacts (non cost related

The information or requirements contained in this NENA document are known to have XXX 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

required

2.12 Intellectual Property Rights Policy

NENA takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that

might be claimed to pertain to the implementation or use of the technology described in this document or the

extent to which any license under such rights might or might not be available; nor does it represent that it has

made any independent effort to identify any such rights.

NENA Standard Data Formats for 9-1-1 Data

Exchange & GIS Mapping NENA 02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 18 of 103

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

4350 N Fairfax Dr, Suite 750

Arlington, VA 22203-1695

800-332-3911

[email protected]

2.13 Acronyms/Abbreviations

Some acronyms/abbreviations used in this document have not yet been included in the master glossary. After

initial approval of this document, they will be included. See NENA 00-001 - NENA Master Glossary of 9-1-1

Terminology located on the NENA web site for a complete listing of terms used in NENA documents.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 19 of 103

3 Technical Description

3.1 Types of Data Exchange Formats

All data exchange formats utilize 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, MSAG data

exchange, Header and trailer records, Wireless data formats are included in Versions 3.1 and 4.

A new standard format Version 1.0 has been defined for the ALI Request Response message sent to

the PSAP screen.

Version 1 formats are 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 recognize that the original formats needed to be expanded to accommodate

additional data fields critical to some data providers and also recognizing that NENA must position

the standard record for the future. Version 2 formats contain 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.

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.

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 20 of 103

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

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

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 21 of 103

 There is no particular sequence of the tag/data combinations within a Tag Data Record.

 Each tag and its associated data is 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 required 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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 22 of 103

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

<xs:complexType

name=”StreetAddressType”>

<xs:all>

<xs:element name=”HouseNum”/>

<xs:element name=”HouseNumSuffix/>

<xs:element name=”PrefixDirectional/>

<xs:element name=”StreetName”/>

<xs:element name=”StreetSuffix/>

<xs:element name=”PostDirectional”/>

<xs:element name=”MSAGCommunity”/>

<xs:element name=”PostalCommunity”/>

<xs:element name=”StateProvince”/>

<xs:element name=”County”/>

<xs:element name=”TARCode”/>

<xs:element name=”PostalZipCode”/>

</xs:all>

</xs:complexType>

Individual components or elements

that make up a street address are

housed is a container element called

StreetAddressType.

This example is intended to show

how related data elements may be

grouped together and is not

intended to be accurate in form

or structure.

Refer to the actual XML documents

located on the NENA web site at

http://www.nena.org/xml_schemas/

nena.htm

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 23 of 103

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

 The XML schema defines the structure, sequence and required elements within an XML

document.

 The receiving Data Base Management System provider will determine the minimum set of

elements required 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.

 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/.

4 Recommended Reading and References

Refer to the NENA Master Glossary of 9-1-1 Terminology NENA-01-002 for definitions of the

terms used in this document.

Refer to the NENA 04-005 NENA ALI Query Service Standard for specifications on XML ALI

source data exchange.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 24 of 103

5 Exhibits

EXHIBIT 1

5.1 VERSION 1 FORMAT FOR DATA EXCHANGE (Obsolete – DO NOT USE)

FIELD

NAME

POSITIO

N

BYTE

S

TYPE DESCRIPTION

Function Code 1 1 A Type of activity the record is being submitted for.

Valid entries:

C = Change

D = Delete

I = Insert

NPA 2-4 3 N Three digit area code of the Calling Number

Calling

Number

5-11 7 N Seven digit telephone number of the Calling

Number

House Number 12-21 10 AN House Number. The field should be space 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 Number

Suffix

22-25 4 AN House number extension (e.g. ½). The field

should be spaced filled if no suffix applies.

Prefix

Directional

26-27 2 A Leading street direction prefix. The field should

be space filled if no prefix applies. Valid entries:

N S E W

NE NW SE SW

Street Name 28-67 40 AN Valid service address of the Calling Number.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 25 of 103

Street Suffix 68-71 4 A Valid street abbreviation, as defined by the U.S.

Postal Service Publication 28, Appendix C. (e.g.

AVE)

Post

Directional

72-73 2 A Trailing street direction suffix. The field should

be space filled if no suffix applies. Valid entries:

N S E W

NE NW SE SW

Community

Name

74-105 32 A Valid service community of the street

name/house number as designated by the MSAG.

State 106-107 2 A Alpha state abbreviation (e.g. TX)

Location 108-127 20 AN Additional address information (free formatted)

describing the exact location of the Calling

Number (e.g. Apt 718)

Customer

Name

128-159 32 AN Subscriber name associated with the Calling

Number.

VERSION 1 FORMAT FOR DATA EXCHANGE (Obsolete – DO NOT USE)

Class of

Service

160 1 AN Value of:

1 = Residence 6 = Coin 1 Way

out

2 = Business

7 = Coin 2 Way

3 = Residence

PBX

8 = Mobile

4 = Business PBX

9 = Residence

OPX

5 = Centrex 0 = Business OPX

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 26 of 103

Type of

Service

161 1 N Value of:

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

Exchange 162-165 4 AN Local Exchange Carrier exchange identifier for

the serving telephone office of the customer.

ESN 166-170 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 171-173 3 N Three-digit area code of the Main Number

associated with the Calling Number.

Main Number 174-180 7 N Seven Digit telephone number of the Main

Number associated with the Calling Number.

Order Number 181-190 10 AN Service order number for the activity establishing

this record.

Extract Date 191-196 6 N Date on which the record was created in the

format. MMDDYY

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 27 of 103

County ID 197-200 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.

Company ID 201-205 5 AN NENA registered Company Identification code.

Source ID 206 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 28 of 103

VERSION 1 FORMAT FOR DATA EXCHANGE (Obsolete – DO NOT USE)

Zip Code

207-211 5 AN Postal Zip Code

Zip + 4 212-215 4 AN Postal Zip Code Extension

General Use 216-226 11 AN This field will be mutually used by data exchange

partners to pass information not defined in

previous fields.

Reserved 227-239 13 AN This field is reserved for the Data Base

Management Systems Provider’s use.

End of Record 240 1 AN Always an asterisk (*).

NOTE: All fields are left justified, with trailing spaces.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 29 of 103

EXHIBIT 2

5.2 VERSION 1 FORMAT FOR MSAG DATA EXCHANGE (Obsolete – DO NOT USE)

NOTE: All

fields are left

justified, with

trailing spaces.

NAME POSITION BYTES TYPE

Prefix

Directional

1-2 2 AN

Street Name 3-42 40 AN

Street Suffix 43-46 4 AN

Post Directional 47-48 2 AN

Low Range 49-58 10 AN

High Range 59-68 10 AN

Community

Name

69-100 32 A

State 101-102 2 A

Odd/Even 103 1 O, E OR B

ESN 104-108 5 AN

Extract Date 109-114 6 MMDDYY

PSAP ID 115-118 4 AN

County ID 119-122 4 AN

Exchange 123-126 4 AN

General Use 127-146 20 AN

Reserved 147-159 13 AN

End of Record 160 1 Always “*”

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 30 of 103

EXHIBIT 3

5.3 VERSION 1 HEADER FORMAT FOR DATA EXCHANGE (Obsolete – DO NOT USE)

NAME POSITION BYTES TYPE

Header Indicator 1-5 5 “UHL”

Extract Date 6-11 6 MMDDYY

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

Reserved 94-159 66 AN

End of Record 160 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 missed.

When used with an ALI source data file, the reserved field will be

expanded to 146 bytes.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 31 of 103

EXHIBIT 4

5.4 VERSION 1 TRAILER FORMAT FOR DATA EXCHANGE (Obsolete – DO NOT USE)

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 169 bytes.

NAME POSITION BYTES TYPE

Trailer Indicator 1-5 5 “UTL”

Extract Date 6-11 6 MMDDYY

Company Name 12-61 50 AN

Record Count 62-70 9 N

Reserved 71-159 89 AN

End of Record 160 1 Always “*”

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 32 of 103

EXHIBIT 5

5.5 VERSION 2.0 FORMAT FOR DATA EXCHANGE

5.6 VERSION 2.0 FORMAT FOR MSAG DATA EXCHANGE

5.7 VERSION 2.0 HEADER FORMAT FOR DATA EXCHANGE

5.8 VERSION 2.0 TRAILER FORMAT FOR DATA EXCHANGE

Have Been Replaced by Version 2.1 Formats

See Exhibits 6 through 9

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 33 of 103

EXHIBIT 6

5.9 VERSION 2.1 FORMAT FOR DATA EXCHANGE

FIELD

NAME

POSITIO

N

BYTE

S

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 of the Calling Number.

Calling

Number

5-11 7 N Seven-digit telephone number of the Calling

Number.

House Number 12-21 10 AN House number. The field should be space 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 Number

Suffix

22-25 4 AN House number extension (e.g. ½). The field

should be space filled if no suffix applies.

Prefix

Directional

26-27 2 A Leading street direction prefix. The field 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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 34 of 103

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

Directional

92-93 2 A Trailing street direction suffix. The field should

be space filled if no suffix applies. Valid entries:

N S E W

NE NW SE SW

Community

Name

94-125 32 A Valid service community of the street

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

Name

188-219 32 AN Subscriber name associated with the Calling

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 35 of 103

VERSION 2.1 FORMAT FOR DATA EXCHANGE

FIELD

NAME

POSITIO

N

BYTE

S

TYPE DESCRIPTION

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 36 of 103

Class of

Service

220 1 AN Value of:

1 = Residence 8 = Mobile

2 = Business 9 = Residence

OPX

3 = Residence

PBX

0 = Business OPX

4 = Business PBX A = Customer

Owned Coin

Telephone

(COCT)

5 = Centrex B = Not Available

Footnote

4

6 = Coin 1 Way

out

G = Wireless

Phase I

7 = Coin 2 Way H = Wireless

Phase II

I = Wireless

Phase II with

Phase I

information

V = VoIP Services

Default COS

C = VoIP

Residence

D=VoIP

Business

E = VoIP

Coin/Pay

Phone

F=VoIP

Wireless

J = VoIP

Nomadic

K

=VoIP

Enterprise

Services –

Centrex &

PBX

For all VoIP

COS see notes

on page 13

T = Telematics

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 37 of 103

Type of

Service

221 1 N Value of:

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

6 = Local Ported Number (LNP)

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 38 of 103

VERSION 2.1 FORMAT FOR DATA EXCHANGE

FIELD

NAME

POSITIO

N

BYTE

S

TYPE DESCRIPTION

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 Number 241-250 10 AN Service order number for the activity establishing

this record.

Extract Date 251-256 6 N Date on which the record was created in the

format MMDDYY

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

Infrastructure

Provider

(Company ID

1)

261-265 5 AN NENA registered Company Identification code of

the Access Infrastructure Provider

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 39 of 103

Customer Code 287-289 3 AN Code used to uniquely identify a customer.

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

Cell ID 343-348 6 AN Identification number indicating a geographic

region of cellular coverage.

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

Extract Date

387-394 8 N Date on which the record was created in the

format YYYYMMDD

NENA

Reserved

395-475 81 AN This field is reserved for NENA Data Technical

Committee Assignment

Data Provider

ID (Company

ID 2)

476-480 5 AN NENA registered Company Identification code of

the Data Provider (Note 1)

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 40 of 103

VERSION 2.1 FORMAT FOR DATA EXCHANGE

FIELD NAME POSITIO

N

BYTES TYPE DESCRIPTION

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 41 of 103

EXHIBIT 7

5.10 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 42 of 103

NOTE: All fields are left justified, with trailing spaces.

Function of Change for MSAG options

End of record 200 1 Always “*”

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 43 of 103

Insert a single range:

FOC=I defines the current image to be inserted

Delete a single range:

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 currently 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 44 of 103

Delete a single range:

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 can not 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

FOC=J follows to define the single after image for the join (two or more X records must proceed

the J)

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 45 of 103

EXHIBIT 8

5.11 VERSION 2.1 HEADER FORMAT FOR DATA EXCHANGE

NAME POSITION BYTES TYPE

Header Indicator 1-5 5 “UHL”

Extract Date 6-11 6 MMDDYY

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

Date

98-105 8 N

Reserved 106-199 94 AN

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 46 of 103

EXHIBIT 9

5.12 VERSION 2.1 TRAILER FORMAT FOR DATA EXCHANGE

NAME POSITION BYTES TYPE

Trailer Indicator 1-5 5 “UTL

Extract Date 6-11 6 MMDDYY

Company Name 12-61 50 AN

Record Count 62-70 9 N

Expanded Extract

Date

71-78 8 N

Reserved 79-199 121 AN

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 47 of 103

EXHIBIT 10

5.13 VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Record Type

DAT or

RTN

0 A Indicates start of data record (label only, no data

follows). Valid labels:

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

Indicator

STI 1 AN Record status indicator.

Valid entries:

E = Error

C = Completed

P = Pending processing

U = Unprocessed Gateway received but not sent

to processing, (future date)

Function of

Change

FOC 1 A Type of activity the record is being submitted for.

Valid “x” entries:

C = Change

D = Delete

I = Insert

U= Unlock

M = Migrate

E = Delete error record

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 48 of 103

Calling Party

Number

CPN 10 N Number of the Calling Party.

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 49 of 103

VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

House

Number

HNO 10 AN

House Number. Footnote

1,2,3

House

Number

Suffix

HNS 4 AN

House number extension (e.g. ½). Footnote

1,2,3

Prefix

Directional

PRD 2 A

Leading street direction prefix. Footnote

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

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

Directional

POD 2 A

Trailing street direction suffix. Footnote

1,2,3

Valid “x” entries:

N S E W

NE NW SE SW

1

Where an MSAG exists, must fit the MSAG entry.

2

Primary address associated with the Calling Party Number

3

Must include all 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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 50 of 103

MSAG

Community

Name

MCN 32 A Valid service community name as identified by the

MSAG. Footnote

1,2,3

Postal

Community

Name

PCN 32 A Valid service community name as identified by the

U S Postal Service. Footnote

3

State/Provinc

e

STA 2 A Alpha US state, Canadian province 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

Landmark

Address

LMK 60 AN Landmark or Vanity address such as “One

Rockefeller Plaza”

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 51 of 103

VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Also Rings At

Address

ARA 60 AN Secondary address for the Calling Party Number that

rings at 2 locations. Not validated against the MSAG.

Footnote

3

Not applicable to dual service.

This information may be displayed at the PSAP

Customer

Name

NAM 32 AN Subscriber name associated with the Calling 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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 52 of 103

Class of

Service

CLS 1 AN Valid entries:

1 = Residence 8 = Mobile

2 = Business 9 = Residence OPX

3 = Residence

PBX

0 = Business OPX

4 = Business PBX A = Customer Owned Coin

Telephone (COCT)

5 = Centrex B = Not Available

Footnote

4

6 = Coin 1 Way

out

G = Wireless Phase I

7 = Coin 2 Way H = Wireless Phase II

I = Wireless

Phase II with

Phase I

Information

V = VoIP Services

Default COS

C = VoIP Residence

D=VoIP

Business

E = VoIP Coin/Pay Phone

F=VoIP

Wireless

J = VoIP Nomadic

K=VoIP

Enterprise

Services –

Centrex &

PBX

For all VoIP COS see

notes on page 13

T = Telematics

4

NA = not available – class of service for an ESCO failure

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 53 of 103

Type of

Service

TYS 1 AN Valid entries:

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

VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTE

S

TYPE DESCRIPTION

Emergency

Service

Number

(ESN)

ESN 5 AN Emergency Service Number associated with the

House Number and Street Name and Community

Name.

Note: The Service Provider, providing the E9-1-1

Selective Routing will assign ESNs.

Main

Telephone

Number

MTN 10 N Ten-digit telephone number of the Main Billing

Number associated with the Calling Party Number.

Format: NPANXXXXXX Footnote

3

5

The Data Technical Committee strongly recommends that all processing edits be removed from this

Label due to technological changes requiring improved data security measures.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 54 of 103

Call Back

Number

CBN 10 AN Telephone Number that can be dialed to reach a

specific calling party. The call back number must be

a dialable number and used as a back up if the

displayed number cannot be reached. Used for both

wireline and wireless calls. Footnote

3

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

Number

ORD 10 AN Service order number for the activity associated with

this record.

Completion

Date

CPD 10 N Completion Date in format CCYY-MM-DD

County ID COI 5 AN County Identification code (usually the FIPS code).

Note: County Identification field is used to identify

the county of call origination. The Committee

recommends use of the FIPS code assigned to each

county by the U S Census Bureau.

Access

Infrastructur

e Provider

(Company

ID 1)

CPF 5 AN NENA registered Company Identification code for

Service Provider providing the network access to the

end user customer (wireline, wireless, IP, etc.).

Data

Provider ID

(Company

ID 2)

CPS 5 AN NENA registered Company Identification code for

Service Provider/Reseller/Private Switch supplying

ALI record source information.

Postal/Zip

Code

ZIP 10 AN Postal or Zip code. Format: NNNNN-NNNN or

ANANAN Footnote 3

Customer

Code

CUS 3 AN Code used to uniquely identify a wireline customer

Comments CMT 30 AN Optional notes, may be displayed at PSAP

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

3

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 55 of 103

TAR Code TAR 6 AN Taxing Area Rate Code

Alternate

Telephone

Number

ALT 10 N Remote Call Forwarding number used during Interim

Number Portability-NPANXXXXXX

Return Code

Number

RCN 3 N Code indicating specific processing error 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 56 of 103

VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Special

Attention

Indicator

SAI 1 AN Calls that require special attention. Valid entries:

1 = TTY call

2 = ACN = Automatic crash/collision notification

Common

Language

Location

Indicator

(CLLI)

CLI 11 AN CLLI code of the local loop central office for the 911

calling party.

General Use 1

GU1 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 2 GU2 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 3 GU3 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 4 GU4 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 5 GU5 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 6 GU6 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

General Use 7 GU7 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 57 of 103

General Use 8 GU8 60 AN This field will be mutually used by data exchange

partners to pass information not defined in previous

fields.

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

Footnote

3

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 Footnote

3

Elevation ELV 6 N Elevation/Altitude indicated as height above mean sea

level, measured in meters. Right Justified; pad field

with zeros or spaces. (Can be used for wireline)

Sample: +00000 , -00000 Footnote

3

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 58 of 103

VERSION 3.1 FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

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 Separator | 1 AN A “pipe” is to be utilized for the field separator

(ASCII HEX-7C)

End of record

NL

NL 1 AN The NEW LINE character is a single character that

identifies the end of record in all cases for all records.

(ASCII HEX-0A)

5.13.1 Data Record Format Example:

DAT|FOC|CPN..........|HNO..........|PRD..|STN....................|STS....|MCN....................|STA..|LOC..

..........................|NAM...........................................|CLS.|TYS.|MTN..........|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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 59 of 103

EXHIBIT 11

5.14 VERSION 3.1 FORMAT FOR MSAG DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Record Type MSG 0 Indicates start of MSAG record (label only, no

data follows)

Function of

Change

FOC 1 A Type of activity the record is being submitted for.

Valid entries

6

:

D = Delete

I = Insert

Prefix

Directional

PRD 2 AN Leading street direction prefix

Valid “x”

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

Directional

POD 2 AN Trailing street direction suffix. -Valid “x” entries:

N S E W

NE NW SE SW

Low Range LOR 10 AN The lowest house number that is included in this

ESN definition

6

See Version 2.1 MSAG FOC for more details: Function of Change for MSAG options

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 60 of 103

High Range HIR 10 AN The highest house number that is included in this

ESN definition

MSAG

Community

Name

MCN 32 A Valid service community name as defined by the

MSAG

Postal

Community

Name

PCN 32 A Valid service community name as defined by the

U S Postal Service

State/Province STA 2 A Alpha U.S. state, Canadian province 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 61 of 103

VERSION 3.1 FORMAT FOR MSAG DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Emergency

Service Number

(ESN)

ESN 5 AN Emergency Service Number associated with the

House Number and Street Name and Community

Name.

Note: The Service Provider, providing the E9-1-

1 Selective Routing will assign ESNs.

Completion

Date

CPD 10 N Completion date in format CCYY-MM-DD

PSAP ID PSI 4 AN Code identifying the PSAP associated with the

assigned ESN

County ID COI 5 AN County Identification code (usually the FIPS

code).

Note: County Identification field is used to

identify the county of call origination. The

Committee recommends use of the FIPS code

assigned to each county by the U S 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 Control

Office

SRT 11 AN 9-1-1 Control Office CLLI

General Use 1 GU1 60 AN This field will be mutually used by data exchange

partners to pass information not defined in

previous fields.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 62 of 103

General Use 2 GU2 60 AN This field will be mutually used by data exchange

partners to pass information not defined in

previous fields.

The items below do not require a “Label” only the symbol shown

Field Separator | A “pipe” is to be utilized for the field 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..........|MCN.......................

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 63 of 103

EXHIBIT 12

5.15 VERSION 3.1 HEADER FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DATA DESCRIPTION

Record Type HDR 0 A Indicates start of header record (label only, no

data follows)

Record

Identifier

TST 3 AN Test Records Only

Extract Date EXD 10 N Year, Month, Day the data was processed, Format:

CCYY-MM-DD

Company Name CON 50 AN Name of Company forwarding file

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 company’s

to provide additional information

The items below do not require a “Label” only the symbol shown

Field Separator | 1 AN A “pipe” is to be utilized for the field separator

(ASCII HEX-7C)

End of record

NL

NL 1 AN The NEW LINE character is a single character

that identifies the end of record In all cases for all

records. (ASCII HEX-0A)

5.15.1 Header Record Format Example:

HDR|EXDCCYY-MM-

DD|CON…………………………..|CYC………|REC………|GEN……….|NL

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 64 of 103

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 65 of 103

EXHIBIT 13

5.16 VERSION 3.1 TRAILER FORMAT FOR DATA EXCHANGE

NAME LABEL MAX #

BYTES

TYPE DATA DESCRIPTION

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

The items below do not require a “Label” only the symbol shown

Field Separator | 1 AN A “pipe” is to be utilized for the field separator

(ASCII HEX-7C)

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 66 of 103

EXHIBIT 14

5.17 VERSION 3.1 WIRELESS DATA EXCHANGE

5.17.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 must be dynamically populated in the ALI database. Wireless Service Providers must 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 currently 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/IS J-STD-036 and

the soon to be published NENA Standard for the Implementation of the Wireless Emergency Service

Protocol E2 Interface via TCP/IP. 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/IS J-STD-

036 and the NENAE2 Interface Document, the NENA standards must take precedence. Position data

retrieved from the MPC nmay need to be translated to conform to the ALI database and ALI source

data formats.

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 67 of 103

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 nused to transmit the ALI back to the

PSAP.

Dynamic Updates of the ALI Database

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

Call-Back

Number

CBN 10 AN Telephone Number that can be dialed to reach a

specific calling party. The call back number must

be a dialable number and used as a back up if the

displayed number cannot be reached

MOBILE ID

(MIN)

MIN 10 AN Mobile Identification number of the cellular

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 68 of 103

VERSION 3.1 FORMAT FOR WIRELESS DATA EXCHANGE

Dynamic Updates of the ALI Database

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

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 indicated as height above mean

sea level, measured in meters (Can be used for

wireline) Sample: #####

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

Flag

LVD 1 N Valid data indicator (1=OK; 0=Invalid).

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

(WGS84). Other codes may be added as additional

datum become available through authorized

entities.

Where x =

83 = NAD83

84 = WGS84

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 69 of 103

LDT

Confidence

COF 7 N Information that indicates the level of uncertainty

inherent to the associated latitude/longitude

information expressed in meters, ranging from one

meter to 1800 Km expressed in meters.

LDT

Confidence

Percentage

COP 3 N Information identifying the confidence by which it

is known that the calling party lies within the

associated shape description. It is expressed as a

percentage ranging from 0 – 100.

LDT Provider

ID

LDT 8 AN LDT Provider Identification Code. Codes to be

developed and held by NENA.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 70 of 103

VERSION 3.1 FORMAT FOR WIRELESS DATA EXCHANGE

Dynamic Updates of the ALI Database

NAME LABEL MAX #

BYTES

TYPE DESCRIPTION

LDT

Technology

LTY 2 AN Defines how particular position information 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 RF Fingerprinting

6 = Network Cell Sector

16 = Handset Unspecified

17 = Handset GPS

18 = Handset AGPS

19 = Handset EOTD

20 = Handset AFLT

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 KPH) SPD 3 N Speed of travel in kilometers per hour.

Heading

(in degrees)

HDG 3 N Direction of travel, decimal degrees from true

north. Valid entries 0-359.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 71 of 103

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

A..|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 SGML (Standard Generalized

Markup Language) 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 Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 72 of 103

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

. Go to this url and select

NENA XML Schema Repository. Select Schema Archive. Select Version 0.0. All previous

XML format exhibits are shown including Element Tags, Data Dictionary, GIS Data Model, and

ALI Response V1.0.

XML ALI Exchange development should be done in accordance with the 04-005 NENA ALI Query

Service Standard. The most current versions of the ALI and AQS schemas should be used.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 73 of 103

EXHIBIT 15

5.18 VERSION 4 XML FORMAT FOR DATA EXCHANGE

5.18.1 The XML Schema

The XML Schema is a document that represents how the XML data must be organized. It defines the

data elements that are required 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)

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 74 of 103

5.18.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 required

the change will be made to a single reference file 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.

5.18.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 required 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

5.18.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 to ensure they are valid, ensures that required 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.

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 75 of 103

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.

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

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

5.18.9 Transmission Protocol

The future direction of data exchange methods adopted by NENA must 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 (STX) / End of Text (ETX) protocol wrapped around the

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 76 of 103

ALI source data or other message. While this protocol works well in the current environment there

are benefits to be gained from newer, faster data delivery methods and protocols such as TCP/IP,

HTTP, HTTPS, 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.

5.18.10 XML Schema Location

NENA Version 4 Data Exchange Formats are available on the NENA web site at

http://www.nena.org/xml_schemas/nena.htm

.

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 77 of 103

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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 78 of 103

5.18.11 Example of the relationship between schema Generations and subsequent

Releases

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 79 of 103

Schema Version 4.2

Change Log

These are the items that have been changed from Version 4.1 to 4.2 in the schemas.

5.18.12 All schemas:

1) Changed all instances of datatypes (and restrictions) xs:string to xs:token

7

.

2) Set version in all schemas to 4.2.

6 ALI Schemas

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

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 80 of 103

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.

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

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 (superceded 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.

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 81 of 103

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.

6.1.3 ALI Query Service Directory and Schemas

The “aliqs” directory contains schemas and WSDLs for ALI Query Service. These are all new.

6.1.4 AQS and AQS.WS Removed

Directories containing preliminary work on AQS have been removed.

6.1.5 MSAGRecord.xsd

1) Removed RangeNumberType.

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.

7 I2 Schemas

7.1.1 Geopriv Directory and Schemas

The geopriv directory contains the CivicAddress and geoshape schemas.

7.1.2 GML-3.1.1 Directory and Schemas

The GML directory contains GML schemas referenced from the v9 schemas.

7.1.3 All I2 Schemas

Old New

V2-request v2Request

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 82 of 103

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

v3-response v3Response

vpc-lis-request vpcLisRequest

ipl-request iplRequest

message-id messageId

ipl-response iplResponse

pos-source posSource

v8-request v8Request

v8-response v8Response

vpc-erdb-request vpcErdbRequest

erdb-request erdbRequest

erdb-response erdbResponse

v9-request v9Request

v9-response v9Response

vdb-identity-request vdbIdentityRequest

erdb-identity-request erdbIdentityRequest

identity-request identityRequest

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 83 of 103

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.

7.1.4 V2.xsd

1) Modified result element to be String with numeric restriction.

7.1.5 V7.xsd

1) Removed pidf import

2) Added return 500, 570, 580 to ReturnCodeType

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

7.1.7 V9.xsd

This schema has been completely re-written.

7.2 EXHIBIT 22

7.3 GIS DATA MODEL, VERSION 2.0

7.3.1 1.0 Preface

Version 2.0 of the NENA GIS Data Model identifies the minimal attributes required 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), and for the

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 84 of 103

Location Validation Function and the Emergency Calling Routing Function in the NENA i3 solution

(NENA 08-751).

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

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 85 of 103

Dataset title (M)

(MD_Metadata >

MD_DataIdentification.citation >

CI_Citation.title)

Spatial representation type (O)

(MD_Metadata >

MD_DataIdentification.spatialRepresentationType)

Dataset reference date (M)

(MD_Metadata >

MD_DataIdentification.citation >

CI_Citation.date)

Reference system (O)

(MD_Metadata > MD_ReferenceSystem)

Dataset responsible party (O)

(MD_Metadata >

MD_DataIdentification.pointOfContact >

CI_ResponsibleParty)

Lineage (O)

(MD_Metadata > DQ_DataQuality.lineage >

LI_Lineage)

Geographic location of the dataset (by four

coordinates or by geographic identifier)

(C)

(MD_Metadata >

MD_DataIdentification.extent > EX_Extent

> EX_GeographicExtent >

EX_GeographicBoundingBox or

EX_GeographicDescription)

On-line resource (O)

(MD_Metadata > MD_Distribution >

MD_DigitalTransferOption.onLine >

CI_OnlineResource)

Dataset language (M)

(MD_Metadata >

MD_DataIdentification.language)

Metadata file identifier (O)

(MD_Metadata.fileIdentifier)

Dataset character set (C)

(MD_Metadata >

MD_DataIdentification.characterSet)

Metadata standard name (O)

(MD_Metadata.metadataStandardName)

Dataset topic category (M)

(MD_Metadata >

MD_DataIdentification.topicCategory)

Metadata standard version (O)

(MD_Metadata.metadataStandardVersion)

Spatial resolution of the dataset (O) Metadata language (C)

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 86 of 103

1.2 9-1-1 SPATIAL ATTRIBUTES FOR LINE DATA

1.2.1A Centerline Layer (Required)

ATTRIBUT

E NAME

USE

R/O

TYPE DATA DESCRIPTION

Low Address

Left

R N Lowest address on left side of street in ascending order

High

Address Left

R N Highest address on left side of street in ascending order

Low Address

Right

R N Lowest address on right side of street in ascending order

High R N Highest address on right side of street in ascending order

(MD_Metadata >

MD_DataIdentification.spatialResolution >

MD_Resolution.equivalentScale or

MD_Resolution.distance)

(MD_Metadata.language)

Abstract describing the dataset (M)

(MD_Metadata >

MD_DataIdentification.abstract)

Metadata character set (C)

(MD_Metadata.characterSet)

Distribution format (O)

(MD_Metadata > MD_Distribution >

MD_Format.name and

MD_Format.version)

Metadata point of contact (M)

(MD_Metadata.contact > CI_ResponsibleParty

Additional extent information for the

dataset

(vertical and temporal) (O)

(MD_Metadata >

MD_DataIdentification.extent > EX_Extent

> EX_TemporalExtent or

EX_VerticalExtent)

Metadata date stamp (M)

(MD_Metadata.dateStamp)

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 87 of 103

Address

Right

Prefix

Directional

R A Leading street direction prefix. Valid Entries: N S E W

NE NW SE SW

Street Name

Pre Type

O A The element of the complete street name 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.

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

Directional

R A Trailing street direction suffix. Valid Entries: N S E W

NE NW SE SW

Road Class R N http://www.fhwa.dot.gov/planning/fctoc.htm

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)

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 88 of 103

One-way R A One way road classification. The direction of the line 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

Community

Name Left

R A Postal Community Name as identified on the left side of the

street

Postal

Community

Name Right

R A Postal Community Name as identified on the right side of

the street

Postal

Code/Zip

Code Left

R AN Postal or Zip code as identified on the Left side of the street.

Format: ANANAN or NNNNN

2

Postal

Code/Zip

Code Right

R AN Postal or Zip code as identified on the Right side of the

street. Format: ANANAN or NNNNN

2

MSAG

Community

Name Left

R A Valid service community name as identified by the MSAG

on the left side of the street

MSAG

Community

Name Right

R A Valid service community name as identified by the MSAG

on the right side of the street

ESN Left O AN 3-5 digit Emergency Service Number associated with street

segment

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 89 of 103

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 Left

R AN County Name on the Left side of the street as given in FIPS

6-4

1

County

Name Right

R AN County Name on the Right side of the street as given in

FIPS 6-4

1

County Code

Left

R A County Code on the Left side of the street as given in FIPS

6-4

1

County Code

Right

R A County Code on the Right side of the street as given in FIPS

6-4

1

State/Provinc

e Left

R A Two character Alpha U.S. State or Canadian province

abbreviation as defined by Postal Authority or ISO 3166-2

i.e. TX (Texas), ON (Ontario)

State/Provinc

e Right

R A Two character Alpha U.S. State or Canadian province

abbreviation as defined by Postal Authority or ISO 3166-2

i.e. TX (Texas), ON (Ontario)

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1

http://www.census.gov/geo/www/fips/fips65/index.html The FIPS Codes Standard shall not apply

to applications involving interchange of international data that require the use of the 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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 90 of 103

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.

1.2.1B. Railroad Layer (Optional)

ATTRIBU

TE NAME

USE

R/O

TYPE DATA DESCRIPTION

Line R A Railroad Line Owner (Code of Association of American

Railroads)

Line Sub-

Division

Name

R A Railroad Line Sub-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

High

R AN Ending Linear Reference

Passenger

Rail

Indicator

R A Passenger Rail Indicator

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 91 of 103

1.2.1C. Hydrology Layer (Optional)

ATTRIBU

TE NAME

US

E

R/

O

TYP

E

DATA DESCRIPTION

Surface

Water Line

R A Type of Surface Water (river, stream, etc.)

Surface

Water Name

R A Name of river, stream etc.

Segment ID R N Unique Hydrology Segment ID

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 92 of 103

1.3. 9-1-1 SPATIAL ATTRIBUTES FOR POINT DATA

1.3. A Emergency Service Agency Location Layer (Required)

ATTRIBU

TE NAME

USE

R/O

TYP

E

DATA DESCRIPTION

Agency

Type

R A Law = L

Fire = F

Emergency Medical Service = E

Other = O

County

Name

R AN County Name as given in FIPS 6-4

1

County

Code

R A FIPS County Code as given in FIPS 6-4

1

Community

ID

R N Unique Community ID Number i.e. FIPS,

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

Contact

R A Agency Contact Person

House

Number

Prefix

R AN House Number Prefix to accommodate

Alphanumeric characters or fire numbers in

house number i.e. Wisconsin

House

Number

R N House Number

House

Number

Suffix

R AN House Number Suffix

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 93 of 103

Prefix

Directional

R AN Leading street direction prefix. Valid

Entries: N S E W

NE NW SE SW

Street

Name Pre

Type

O A The element of the complete street name

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.

Street

Name

R AN Valid street name as assigned by local

addressing authority

Street

Suffix

R AN Valid Street abbreviation, as defined by the

US Postal Service Publication 28. (e.g.

AVE)

Post

Directional

R AN Trailing street direction suffix. Valid

Entries: N S E W

NE NW SE SW

Postal

Community

Name

R A Postal Community Name

MSAG

Community

Name

R A Valid service community name as

identified by the MSAG

Postal

Code/Zip

Code

O AN Postal or Zip code. Format: NNNNN or

ANANAN

2

State/Provi

nce

R A Two character Alpha U.S. State or

Canadian province abbreviation as defined

by Postal Authority or ISO 3166-2 i.e. TX

(Texas), ON (Ontario)

Telephone

Number

O AN Telephone Number of Agency Format:

NPA-NXX-XXXX

Source of

Data

R A Agency that last updated the record

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 94 of 103

Date

Updated

R N Date of last update Format: CCYY-MM-

DD

1.3 B. Cell Site Location Layer (Required)

ATTRIBU

TE NAME

US

E

R/

O

TYP

E

DATA DESCRIPTION

NENA CO

ID

R AN . NENA Company ID www.NENA.org

Numeric

Cell ID

R N Carrier Cell site ID

Cell Site

Common

Name

R A Location Name assigned by the wireless carrier

Cell Site

Unique ID

R AN Cell Site Identifier provided by the wireless service provider,

it is unique to the cell site

Cell Site

Address

R A The address of the cell tower as provided by the wireless

service provider. Needs to be MSAG Valid

Postal

Community

Name

R A Postal Community Name

MSAG

Community

Name

R A Valid service community name as identified by the MSAG

Cell Site

State

R A State where the cell tower is located

County

Code

R AN FIPS County Code as given in FIPS 6-4

1

Air

Interface

Technology

R A A=Analog (900MHz), P=Digital (PCS), T=TDMA (Digital

AMPs), G=GSM – Type of RF Voice Technology

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 95 of 103

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1.3 C. Mile Marker Location Layer (Optional)

ATTRIBU

TE NAME

USE

R/O

TYPE DATA DESCRIPTION

Mile Post

ID

R N Mile Post Identification Number

Mile Marker

Type

R A Type of mile marker :

Railroad name

Road name

Trail

Water Way

Coastal

Boardwalk

Route

System

Name

R AN Name of route system (ex: Interstate 85)

Segment ID R N Unique Road or Railroad Segment ID

number

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1.3 D. Railroad Grade Crossing Layer (Optional)

ATTRIBUTE

NAME

USE

R/O

TYPE DATA DESCRIPTION

Grade

Crossing ID

R N Unique USDOT ID for the Crossing

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 96 of 103

Crossing

Position

R AN

Position of Crossing

At Grade

RR Under

RR Over

Grade

Crossing

Name

O A Name given to Grade Crossing

Source of

Data

R A Agency that last updated the record

Date Updated R N Date of last update Format: CCYY-MM-DD

1.3 E. Site/Structure Location Layer (Optional)

ATTRIBU

TE NAME

USE

R/O

TYPE DATA DESCRIPTION

Community

ID

R N Unique Community ID Number i.e. FIPS,

GEOCODES, etc.

Site ID R N Unique Site ID Number

House

Number

Prefix

R AN House Number Prefix to accommodate

Alphanumeric characters or fire numbers in

house number i.e. Wisconsin

House

Number

R N House Number

House

Number

Suffix

R AN House Number Suffix

Location O AN Additional location information.

Abbreviated as shown in USPS Publication

28, Appendix C, Item C2.

Prefix

Directional

R AN Leading street direction prefix. Valid Entries:

N S E W

NE NW SE SW

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 97 of 103

Street Name

Pre Type

O A The element of the complete street name

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.

Street Name R AN Valid street name as assigned by local

addressing authority

Street Suffix R AN Valid Street abbreviation, as defined by the

US Postal Service Publication 28. (e.g. AVE)

Post

Directional

R AN Trailing street direction suffix. Valid Entries:

N S E W

NE NW SE SW

ESN R AN Emergency Service Number associated with

this House Number, Street Name and

Community Name

Postal

Community

Name

R A Postal Community Name

MSAG

Community

Name

R A Valid service community name as identified

by the MSAG

Postal

Code/Zip

Code

O AN Postal or Zip code. Format: NNNNN or

ANANAN

2

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

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYYMMDD

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 98 of 103

1.4. 9-1-1 SPATIAL ATTRIBUTES FOR POLYGON DATA

1.4 A. County Boundary Layer (Required)

ATTRIBU

TE NAME

USE

R/O

TYPE DATA DESCRIPTION

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

1

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1.4 B. Emergency Service Zone Boundary Layer (Required)

ATTRIBU

TE NAME

US

E

R/

O

TYP

E

DATA DESCRIPTION

Community

ID

R N Unique Community ID Number i.e. FIPS, GEOCODES, etc.

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

1

PSAP ID R AN Code identifying the PSAP as listed in the FCC PSAP registry

http://www.fcc.gov/pshs/services/911-

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 99 of 103

services/enhanced911/psapregistry.html

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

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1.4 C. Municipal Boundary Layer (Required)

ATTRIBU

TE NAME

US

E

R/

O

TYP

E

DATA DESCRIPTION

Community

ID

R N Unique Community ID Number i.e. FIPS, GEOCODES,

etc.

MSAG

Community

Name

R A Valid service community name as identified by the MSAG

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

7.4

7.5 1.4 D. Emergency Service Agency Boundary Layer (Required)

ATTRIBU

TE NAME

USE

R/O

TYPE DATA DESCRIPTION

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

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 100 of 103

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

1

Agency ID R N Emergency Service Agency ID

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

1.4 E. Cell Site Coverage Layer (Required)

ATTRIBUT

E NAME

USE

R/O

TYPE DATA DESCRIPTION

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 101 of 103

LDT

Provider ID

R AN LDT Provider Identification Code. Codes to be

developed and held by NENA

Numeric Cell

ID

R N Carrier’s Cell site ID

Cell Site

Unique ID

R AN Cell Site Identifier provided by the wireless service

provider, it is unique to the cell site

Numeric

Sector ID

R N Carrier Sector ID usually indicates Omni or multi-

sectored antenna faces

ESRD/ESRK R N ESRD is a 10 digit # used for routing a wireless call & is

assigned by cell sector. 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

Orientation/

Azimuth

R N Orientation of the cell sector antenna face, with North

being 0 degrees and South = 180 degrees.

Sector

Compass

Orientation

R A Cell Sector Antenna orientation compass direction. An

alpha indicator of the section directional – e.g. NE,

WSW, etc.

Sector Beam

Width

R N Width of the sector antenna beam in degrees, under

normal operating conditions

Average

Sector

Radius

R N Average true sector radius range (under average operating

conditions.) Radius at which cell tower’s polygon of

influence ends and another begins.

Coverage

source

R A C=Company Map, D=Digital data from Company, P=GIS

Propagation Study, L=Line of Site analysis, R=Range

Defined

Source of

Data

R A Agency that last updated the record

Date updated R N Date of last update Format: CCYY-MM-DD

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 102 of 103

1.4 F. Hydrology Layer (Optional)

ATTRIBU

TE NAME

USE

R/O

TYP

E

DATA DESCRIPTION

Surface

Water Line

R A Type of Surface Water (pond, lake, large waterway,

reservoir, etc.)

Surface

Water Name

R A Name of Pond, lake, waterway, reservoir, etc.

Segment ID R N Unique Hydrology Segment ID

Source of

Data

R A Agency that last updated the record

Date

Updated

R N Date of last update Format: CCYY-MM-DD

2.0 References

 U.S. Department of Transportation - Federal Railroad Administration– Secretary’s Action

Plan for Highway-Rail Crossing Safety and Trespass Prevention Secretary of

Transportation

 NENA 02-010, NENA Formats and Protocols for Data Exchange

 NENA 02-011, NENA Data Standards For Local Exchange Carriers, ALI Service Providers

& 9-1-1 Jurisdictions

 NENA 02-014 NENA GIS Data Collection and Maintenance Standards

 NENA 57-001 Wireless Phase I & II Features and Functions Operational Information

Document

NENA Standard Data Formats for 9-1-1

Data Exchange & GIS Mapping NENA

02-010,

Version 9, March 28, 2011

Version 9, March 28, 2011 Page 103 of 103

99 Previous Acknowledgments

Data Exchange Formats Sub-Committee Members of as 11/01/2005

Barry, Tim AT&T

Bluhm, Patty – Chair HBF Group

Bostrom, Carol AT&T

Connel, David Denco Area 9-1-1 District

Desjardins, Pierre Positron

Hutchins, Gary Intrado

Jacques, Maria State of Maine

Lafferty, Sam AT&T

Leigh, Kim Qwest

Louden, Tom Verizon

Marczak, Bill BellSouth

Muehleisen, Scott OM2 Technology

Muehleisen, Tom NuVox Communications

Pyles, Ira Hillsborough County 9-1-1

Sherry, Bob Intrado

Vislocky, Mike Network Orange