Docstoc

20100811_08-001 v2

Document Sample
20100811_08-001 v2 Powered By Docstoc
					    NENA Interim VoIP Architecture for
       Enhanced 9-1-1 Services (i2)




NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)
NENA 08-001, Version 2
Standards Advisory Board approval date, June 18, 2010
NENA Executive Board approval date, August 11, 2010

Prepared by:
National Emergency Number Association (NENA) VoIP/Packet Technical Committee

Published by NENA
Printed in USA
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


                                         NENA
                             TECHNICAL STANDARD DOCUMENT

                                              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 to assure the quality of performance of
such equipment.
NENA reserves the right to revise this TSD 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
TSD 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 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 Dr, Suite 750
Arlington, VA 22203-1695
800-332-3911
or: techdoccomments@nena.org




Version 2, August 11, 2010                                                 Page 2 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


Acknowledgments:

The National Emergency Number Association (NENA) VoIP/Packet Technical Committee
developed this document.
NENA recognizes the following industry experts and their companies for their contributions in
development of this document.

Version 2, Approval Date, August 11, 2010
Members                                   Company
Nate Wilcox Technical Committee Chair     Microdata
Roger Marshall Technical Committee        TCS
Vice-Chair
Anand Akundi, WG Leader and Technical Telcordia Technologies
Editor
Michael Armstrong                         Verizon
Delaine Arnold                            Arnold 9-1-1 Consulting
Eric Arolick                              Telcordia Technologies
Tim Barry                                 AT&T
Marc Berryman                             Greater Harris County 9-1-1
Patty Bluhm                               Intrado
Tom Breen                                 AT&T
Guy Caron                                 Bell Canada
Randall Gellens                           Qualcomm
Ken Maynard                               Bexar Metro 9-1-1 Metro District
Theresa Reese                             Telcordia Technologies
Brian Rosen                               Neustar
Robert Sherry                             Intrado
Maureen Stork                             Verizon Business
Hannes Tschofenig                         Nokia Siemens Network
James Winterbottom                        Andrew Corporation

This committee would also thank Tom Breen, Tony Busam and Roger Hixson for their support and
assistance.




Version 2, August 11, 2010                                               Page 3 of 247
                                                                                                       NENA Interim VoIP Architecture for
                                                                                                       Enhanced 9-1-1 Services (i2)
                                                                                                       NENA 08-001 v2, August 11, 2010


                                                                  TABLE OF CONTENTS

1       EXECUTIVE OVERVIEW .............................................................................................................................. 9 
1.1  PURPOSE AND SCOPE OF DOCUMENT .................................................................................................................... 9 
1.2  REASON TO IMPLEMENT........................................................................................................................................ 9 
1.3  BENEFITS .............................................................................................................................................................. 9 
2       INTRODUCTION ............................................................................................................................................ 10 
2.1     OPERATIONAL IMPACTS SUMMARY .................................................................................................................... 10 
2.2     SECURITY IMPACTS SUMMARY ........................................................................................................................... 10 
2.3     DOCUMENT TERMINOLOGY ................................................................................................................................ 10 
2.4     REASON FOR ISSUE/REISSUE ............................................................................................................................... 11 
2.5     RECOMMENDATION FOR ADDITIONAL DEVELOPMENT WORK ............................................................................ 12 
2.6     DATE COMPLIANCE ............................................................................................................................................ 12 
2.7     ANTICIPATED TIMELINE...................................................................................................................................... 12 
2.8     COSTS FACTORS ................................................................................................................................................. 12 
2.9     FUTURE PATH PLAN CRITERIA FOR TECHNICAL EVOLUTION .............................................................................. 12 
2.10      COST RECOVERY CONSIDERATIONS ............................................................................................................... 13 
2.11      ADDITIONAL IMPACTS (NON COST RELATED) ................................................................................................. 13 
2.12      INTELLECTUAL PROPERTY RIGHTS POLICY .................................................................................................... 13 
2.13      ACRONYMS/ABBREVIATIONS ......................................................................................................................... 13 
3       TECHNICAL DESCRIPTION ....................................................................................................................... 15 
3.1  GENERAL ASSUMPTIONS ..................................................................................................................................... 15 
3.2  OVERVIEW OF INTERCONNECTION TO CONVENTIONAL E9-1-1 SYSTEMS ........................................................... 17 
3.3  DESCRIPTION OF FUNCTIONAL ELEMENTS .......................................................................................................... 19 
   3.3.1  User Agent (UA) ....................................................................................................................................... 19 
   3.3.2  VoIP Endpoint (VEP) ............................................................................................................................... 19 
   3.3.3  Server........................................................................................................................................................ 20 
   3.3.4  Call Server ................................................................................................................................................ 20 
   3.3.5  Proxy or Proxy Server/Policy and Routing Server ................................................................................... 20 
   3.3.6  Redirect Server/Call Relay Server ............................................................................................................ 20 
   3.3.7  Emergency Services Gateway (ESGW)..................................................................................................... 20 
   3.3.8  Emergency Service Zone Routing Data Base (ERDB) ............................................................................. 21 
   3.3.9  VoIP Positioning Center (VPC)................................................................................................................ 21 
   3.3.10    Validation Data Base (VDB) ............................................................................................................... 22 
   3.3.11    Location Information Server (LIS)....................................................................................................... 23 
   3.3.12    Root Discovery Service (RDS) ............................................................................................................. 23 
3.4  DESCRIPTION OF 9-1-1 DATA OBJECTS ............................................................................................................... 23 
3.5  INTERFACE DEFINITIONS..................................................................................................................................... 26 
   3.5.1  v0 – LIS to VoIP Endpoint ........................................................................................................................ 26 
   3.5.2  v1 – VoIP Endpoint to Call Server/Proxy................................................................................................. 27 
   3.5.3  v2 – Call Server or Routing Proxy or Redirect Server to VPC................................................................. 27 
   3.5.4  v3 –VPC to LIS ......................................................................................................................................... 27 
   3.5.5  v4 – Call Server/Routing Proxy to ESGW ................................................................................................ 28 
   3.5.6  v5 – Call Server/Proxy to Redirect Server................................................................................................ 28 
   3.5.7  v6 – Call Server to Routing Proxy ............................................................................................................ 28 
   3.5.8  v7 – LIS to VDB ........................................................................................................................................ 28 
   3.5.9  v8 – VPC to ERDB ................................................................................................................................... 29 

Version 2, August 11, 2010                                                                                                           Page 4 of 247
                                                                                                     NENA Interim VoIP Architecture for
                                                                                                     Enhanced 9-1-1 Services (i2)
                                                                                                     NENA 08-001 v2, August 11, 2010


   3.5.10    v9 – LIS/VPC to Root Discovery Operator .......................................................................................... 29 
   3.5.11    v-E2 – VPC to ALI DB ......................................................................................................................... 29 
3.6  LOCATION INFORMATION SCENARIOS................................................................................................................. 29 
   3.6.1  Endpoint Stores Location ......................................................................................................................... 30 
   3.6.2  LIS Stored – Location Key ........................................................................................................................ 30 
3.7  CALL ROUTING SCENARIOS ................................................................................................................................ 30 
   3.7.1  Basic Call Routing of VoIP Emergency Calls to ESGW........................................................................... 32 
   3.7.2  Proxy Redirect Server............................................................................................................................... 34 
   3.7.3  Routing Proxy Routing Scenario .............................................................................................................. 36 
   3.7.4  ESGWRI-based Routing Translations ...................................................................................................... 37 
3.8  CALL ROUTING FAILURE SCENARIOS ................................................................................................................. 38 
   3.8.1  Abnormal Conditions Detected at the Call Server/Proxy ......................................................................... 38 
   3.8.2  Abnormal Conditions Detected at the VPC .............................................................................................. 39 
   3.8.3  Abnormal Conditions Detected at the ESGW ........................................................................................... 41 
   3.8.4  Default Routing at the Selective Router.................................................................................................... 41 
   3.8.5  Summary of Contingency/Default Routing ............................................................................................... 41 
3.9  LOCATION VALIDATION...................................................................................................................................... 44 
3.10     ROOT DISCOVERY SERVICE (RDS) ................................................................................................................ 45 
   3.10.1    Root Discovery Assumptions................................................................................................................ 45 
   3.10.2    Root Discovery..................................................................................................................................... 46 
   3.10.3    VDB Directory File Format ................................................................................................................. 50 
   3.10.4    ERDB directory file format .................................................................................................................. 53 
   3.10.5    ERDB Directory File Format – Geodetic Coverage............................................................................ 56 
3.11     PSAP CALL CONTROL FEATURES .................................................................................................................. 59 
   3.11.1    Requirements ....................................................................................................................................... 61 
   3.11.2    ESGW Interworking Requirements ...................................................................................................... 62 
4       SECURITY ....................................................................................................................................................... 63 
4.1     AUTHENTICATION ............................................................................................................................................... 63 
4.2     MESSAGE INTEGRITY .......................................................................................................................................... 64 
4.3     MESSAGE ENCRYPTION....................................................................................................................................... 64 
4.4     NETWORK ELEMENT SECURITY .......................................................................................................................... 64 
4.5     NETWORK LAYER SECURITY .............................................................................................................................. 64 
4.6     APPLICATION LAYER SECURITY ......................................................................................................................... 65 
4.7     LOCATION DATA SECURITY ................................................................................................................................ 65 
5       FUNCTIONAL REQUIREMENTS ............................................................................................................... 67 
5.1  VSP CALL SERVER/PROXY ................................................................................................................................. 67 
   5.1.1  Authentication and Authorization ............................................................................................................. 68 
   5.1.2  Performance ............................................................................................................................................. 68 
   5.1.3  Reliability and Availability ....................................................................................................................... 68 
5.2  ROUTING PROXY SERVER ................................................................................................................................... 69 
   5.2.1  Authentication and Authorization ............................................................................................................. 69 
   5.2.2  Performance ............................................................................................................................................. 69 
   5.2.3  Reliability and Availability ....................................................................................................................... 69 
5.3  REDIRECT SERVER .............................................................................................................................................. 69 
   5.3.1  Authentication and Authorization ............................................................................................................. 70 
   5.3.2  Performance ............................................................................................................................................. 70 
   5.3.3  Reliability and Availability ....................................................................................................................... 70 
5.4  EMERGENCY SERVICES GATEWAY (ESGW) ....................................................................................................... 70 


Version 2, August 11, 2010                                                                                                         Page 5 of 247
                                                                                                   NENA Interim VoIP Architecture for
                                                                                                   Enhanced 9-1-1 Services (i2)
                                                                                                   NENA 08-001 v2, August 11, 2010


   5.4.1  Authentication and Authorization ............................................................................................................. 72 
   5.4.2  Performance ............................................................................................................................................. 72 
   5.4.3  Reliability and Availability ....................................................................................................................... 72 
5.5  ESZ ROUTING DATABASE (ERDB) .................................................................................................................... 72 
   5.5.1  Receiving and Storing Routing Information ............................................................................................. 72 
   5.5.2  Processing Routing Queries ..................................................................................................................... 73 
   5.5.3  Authentication and Authorization ............................................................................................................. 81 
   5.5.4  Performance ............................................................................................................................................. 81 
   5.5.5  Reliability and Availability ....................................................................................................................... 81 
5.6  VOIP POSITION CENTER (VPC) .......................................................................................................................... 81 
   5.6.1  Support for Emergency Call Routing ....................................................................................................... 81 
   5.6.2  Delivery of Location Information ............................................................................................................. 87 
   5.6.3  Authentication and Authorization ............................................................................................................. 90 
   5.6.4  Performance ............................................................................................................................................. 90 
   5.6.5  Reliability and Availability ....................................................................................................................... 90 
5.7  VALIDATION DATA BASE (VDB) ........................................................................................................................ 90 
   5.7.1  Storage of MSAG Validation .................................................................................................................... 90 
   5.7.2  Perform Validation ................................................................................................................................... 91 
   5.7.3  Authentication and Authorization ............................................................................................................. 93 
   5.7.4  Performance ............................................................................................................................................. 93 
   5.7.5  Reliability and Availability ....................................................................................................................... 93 
5.8  LOCATION INFORMATION SERVER (LIS)............................................................................................................. 93 
   5.8.1  Detailed LIS Requirements ....................................................................................................................... 94 
   5.8.2  LIS Query Protocol and Location Information Format ............................................................................ 95 
   5.8.3  Validated Address to PIDF-LO Mapping ................................................................................................. 95 
   5.8.4  Authentication and Authorization ............................................................................................................. 96 
   5.8.5  Performance ............................................................................................................................................. 96 
   5.8.6  Reliability and Availability ....................................................................................................................... 96 
5.9  AUTOMATIC LOCATION IDENTIFICATION (ALI) DATABASE................................................................................ 97 
   5.9.1  Authentication and Authorization ............................................................................................................. 97 
   5.9.2  Performance ............................................................................................................................................. 97 
   5.9.3  Reliability and Availability ....................................................................................................................... 97 
6       DETAILED INTERFACE SPECIFICATIONS............................................................................................ 98 
6.1  V0 – LIS TO VOIP ENDPOINT .............................................................................................................................. 98 
6.2  V1 – VOIP ENDPOINT TO CALL SERVER .............................................................................................................. 98 
6.3  V2 – CALL SERVER/ROUTING PROXY/REDIRECT SERVER TO VPC ..................................................................... 99 
   6.3.1  v2 Message Definitions ............................................................................................................................. 99 
   6.3.2  v2 Message Call Flows, Key Scenarios and Semantics .......................................................................... 115 
   6.3.3  v2 Interface Security ............................................................................................................................... 121 
6.4  V3 – VPC TO LIS .............................................................................................................................................. 121 
6.5  V4 - CALL SERVER/ROUTING PROXY TO ESGW ............................................................................................... 122 
   6.5.1  v4 Interface Architecture ........................................................................................................................ 122 
   6.5.2  v4 Interface Call Flow ............................................................................................................................ 123 
   6.5.3  v4 Message Parameters .......................................................................................................................... 125 
   6.5.4  Specification of the v4 interface ............................................................................................................. 126 
   6.5.5  v4 SIP Messages Examples..................................................................................................................... 128 
   6.5.6  Assumptions ............................................................................................................................................ 131 
   6.5.7  v4 Interface Security ............................................................................................................................... 131 
6.6  V5 – CALL SERVER/PROXY TO REDIRECT SERVER ............................................................................................ 131 


Version 2, August 11, 2010                                                                                                      Page 6 of 247
                                                                                                     NENA Interim VoIP Architecture for
                                                                                                     Enhanced 9-1-1 Services (i2)
                                                                                                     NENA 08-001 v2, August 11, 2010


   6.6.1  Technical Description............................................................................................................................. 131 
   6.6.2  v5 Interface Call Flow ............................................................................................................................ 132 
   6.6.3  v5 Message Parameters .......................................................................................................................... 135 
   6.6.4  Specification of the v5 Interface ............................................................................................................. 140 
   6.6.5  SIP Exchange Example........................................................................................................................... 144 
   6.6.6  v5 Security Requirements ....................................................................................................................... 149 
6.7  V6 – CALL SERVER TO ROUTING PROXY INTERFACE ........................................................................................ 149 
   6.7.1  v6 Interface Architecture ........................................................................................................................ 149 
   6.7.2  v6 Interface Call Flow ............................................................................................................................ 150 
   6.7.3  v6 Message Parameters .......................................................................................................................... 153 
   6.7.4  Specification of the v6 interface ............................................................................................................. 154 
   6.7.5  v6 SIP Message Examples ...................................................................................................................... 155 
   6.7.6  v6 Interface Security ............................................................................................................................... 157 
   6.7.7  v6 Interface Assumptions ........................................................................................................................ 158 
6.8  V7 – LIS TO VDB ............................................................................................................................................. 158 
   6.8.1  v7 Message Definitions ........................................................................................................................... 158 
   6.8.2  v7 Message Flows, Key Scenarios and Semantics .................................................................................. 166 
   6.8.3  v7 Interface Security ............................................................................................................................... 169 
6.9  V8 INTERFACE - VPC TO ERDB........................................................................................................................ 169 
   6.9.1  v8 Message Definition ............................................................................................................................ 170 
   6.9.2  v8 Message Flows, Key Scenarios and Semantics .................................................................................. 181 
   6.9.3  Security ................................................................................................................................................... 185 
6.10     V9 INTERFACE – LIS/VPC TO RDS .............................................................................................................. 185 
   6.10.1      v9 Messages Definitions .................................................................................................................... 185 
   6.10.2      v9 Message Flows, Key Scenarios and Semantics ............................................................................. 191 
   6.10.3      v9 Interface Security .......................................................................................................................... 193 
6.11     V-E2 INTERFACE – ALI TO VPC .................................................................................................................. 193 
   6.11.1      v-E2 Message Definitions .................................................................................................................. 194 
   6.11.2      Emergency Services Protocol (ESP) Parameters .............................................................................. 198 
   6.11.3      v-E2 Message flows, Key Scenarios and Semantics........................................................................... 203 
   6.11.4      v-E2 Interface Security ...................................................................................................................... 207 
7       ROLES AND RESPONSIBILITIES ............................................................................................................ 208 
7.1  RESPONSIBILITIES ............................................................................................................................................. 210 
   7.1.1  Caller ...................................................................................................................................................... 210 
   7.1.2  VoIP Service Provider ........................................................................................................................... 210 
   7.1.3  Redirect Operator ................................................................................................................................... 211 
   7.1.4  Routing Proxy Operator ......................................................................................................................... 211 
   7.1.5  LIS Operator........................................................................................................................................... 211 
   7.1.6  ESGW Operator...................................................................................................................................... 211 
   7.1.7  Selective Router (SR) Operators ............................................................................................................. 212 
   7.1.8  PSAP Operators ..................................................................................................................................... 212 
   7.1.9  ALI Operator .......................................................................................................................................... 212 
   7.1.10    VPC Operator .................................................................................................................................... 213 
   7.1.11    Credential Authority .......................................................................................................................... 214 
   7.1.12    Routing Number Authority (RNA) ...................................................................................................... 215 
   7.1.13    Master Street Address Guide (MSAG) Source ................................................................................... 216 
   7.1.14    Validation Database (VDB) Operator ............................................................................................... 217 
   7.1.15    Emergency Routing Database (ERDB) Operator .............................................................................. 217 
   7.1.16    Root Discovery Operator (RDO) ....................................................................................................... 218 


Version 2, August 11, 2010                                                                                                         Page 7 of 247
                                                                                                    NENA Interim VoIP Architecture for
                                                                                                    Enhanced 9-1-1 Services (i2)
                                                                                                    NENA 08-001 v2, August 11, 2010


     7.1.17          9-1-1 Administrator ........................................................................................................................... 218 
8       RECOMMENDED READING AND REFERENCES................................................................................ 220 
9       EXHIBITS (INFORMATIVE) ..................................................................................................................... 223 
9.1  POTENTIAL ALI CHANGES ................................................................................................................................ 223 
   9.1.1  Purpose ................................................................................................................................................... 223 
   9.1.2  Overview ................................................................................................................................................. 223 
   9.1.3  Potential Changes Required to Support i2 Solution ............................................................................... 223 
9.2  RULES FOR ADDRESS ABBREVIATION ............................................................................................................... 225 
   9.2.1  Resources for Abbreviation Matching .................................................................................................... 225 
9.3  MSAG TO POSTAL ADDRESS COMPARISON ...................................................................................................... 226 
9.4  ERDB DISCOVERY USING GEODETIC INFORMATION ........................................................................................ 230 
   9.4.1  Polygon Definition.................................................................................................................................. 230 
   9.4.2  Endpoint (Subscriber) Location Representation .................................................................................... 231 
   9.4.3  ERDB Root Discovery Provisioning ....................................................................................................... 233 
   9.4.4  ERDB Root Discovery Operation ........................................................................................................... 235 
9.5  WEB SERVICES ................................................................................................................................................. 237 
   9.5.1  Standards used........................................................................................................................................ 237 
   9.5.2  Key Points regarding Web Services ....................................................................................................... 237 
   9.5.3  Substitution of Special Characters ......................................................................................................... 238 
9.6  V7 CLIENT CONSIDERATIONS/RECOMMENDATIONS .......................................................................................... 239 
   9.6.1  Overview ................................................................................................................................................. 239 
   9.6.2  Wiremap LIS ........................................................................................................................................... 239 
9.7  CALL ROUTING PERFORMANCE GUIDELINES .................................................................................................... 241 
9.8  ISSUES UNDER INVESTIGATION ......................................................................................................................... 245 
10      PREVIOUS ACKNOWLEDGMENTS ........................................................................................................ 246 




Version 2, August 11, 2010                                                                                                        Page 8 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



1     Executive Overview
Voice over Internet Protocol (VoIP) is poised to become the predominant technology used in the
telecommunications industry. As the public adopts VoIP, E9-1-1 calls will increasingly originate
from VoIP users. Some VoIP telecommunications service provider networks, however, are not
natively compatible with the existing E9-1-1 infrastructure. This document outlines an architecture
to connect emergency callers in the IP domain with Public Safety Answering Points (PSAPs)
supported by the existing E9-1-1 network infrastructure. This interim step in the migration towards
end-to-end IP networks is referred to as i2.

1.1    Purpose and Scope of Document
This document is the NENA recommended standard for the i2 architecture to support the
interconnection of VoIP domains with the existing Emergency Services Network infrastructure in
support of the migration toward end-to-end emergency calling over the VoIP networks between
callers and PSAPs.
This document provides an overview of the VoIP architecture, functional elements, and interfaces, as
well as the interface specifications necessary for interconnection with the existing Emergency
Services Network infrastructure.
This issue of the i2 standard supports E9-1-1 for fixed and nomadic VoIP services. Support for
mobile VoIP services will be covered in a future release of this document.
This document does not include specifications for the methods used to determine location nor how
the endpoint actually receives location. The document does provide pointers to other specifications
that could be used to provide location to the endpoint.

1.2    Reason to Implement
VoIP is being introduced into the North American environment by VoIP Service Providers (VSPs).
NENA and a number of the VSPs acting through the Voice on the Net (VON) Coalition reached
agreement to support current NENA and industry work towards long-term solutions that include (a)
delivery of 9-1-1 calls to the proper PSAP; (b) providing callback number/contact information to the
PSAP; (c) providing the location of the caller; and (d) PSAPs having direct IP connectivity. The
initial standards development work of the NENA VoIP/Packet Committee was completed by the end
of 2005. The architecture described in this standard reflects that initial work as well as the evolution
of the i2 Solution architecture definition since that time.
This recommended standard is being provided to facilitate the development and implementation of
interoperable, standard equipment and processes to support VoIP emergency services calling
throughout North America.

1.3    Benefits
Use of this document will:

Version 2, August 11, 2010                                                   Page 9 of 247
                                                              NENA Interim VoIP Architecture for
                                                              Enhanced 9-1-1 Services (i2)
                                                              NENA 08-001 v2, August 11, 2010


      •Ensure that equipment and service providers that conform to these recommendations will
       have a solution that is interoperable,
Foster development of network elements and processes that can be reused in the architecture that
supports end-to-end IP calling to the PSAP.

2     Introduction
2.1       Operational Impacts Summary
Operational impacts include:
      •    Additional data provided to the PSAP. In order to differentiate VoIP emergency calling,
           VoIP calls will be distinguishable and new data elements pertinent to VoIP calls will be
           provided to call takers. This may impact both call taking procedures and training of call
           takers.
      •    New processes required. Call routing will be based on the caller’s location which will be
           matched to routing information contained in routing databases. With this architecture, VoIP
           caller addresses may not be stored in Automatic Location Identification (ALI) databases, but
           must still be Master Street Address Guide (MSAG) valid. This will require comparison with
           information contained in new validation databases. New processes to populate and maintain
           these routing and validation databases must be developed and implemented.
      •    Default Routing. Some calls will be placed without location information available, making
           location-based routing virtually impossible. Some form of default routing for those calls will
           have to be implemented. Handling of those calls will have operational implications for the
           PSAPs receiving the calls.

2.2       Security Impacts Summary
The critical nature of the E9-1-1 Emergency Services Network makes it essential to ensure that the
E9-1-1 network is properly protected. The i2 solution introduces new network elements, new
underlying transport networks and protocols to the E9-1-1 Emergency Services network. Note that a
number of protocol interfaces are outside the scope of the 9-1-1 system (v0/v1) and several are
between elements that are considered to be within the 9-1-1 system (v2, v3, v4, v5, v6, v7, v8, v9
and v-E2). The former are specified by other standards organizations, such as the IETF. The latter
are defined in this document. For the interfaces within the scope of this document, the security
mechanisms are dependent on the specifics of the underlying network joining the various i2 solution
network elements.

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



Version 2, August 11, 2010                                                     Page 10 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


2.4       Reason for Issue/Reissue
NENA reserves the right to modify this document. Upon revision, the reason(s) will be provided in
the table below.


  Version         Approval Date      Reason For Changes
  Original        12/06/2005         Initial Document
     2            8/11/2010          Reasons Listed Below

Version 2: This document was originally issued to identify the minimum requirements and desirable
network elements for VSP interconnection with the E9-1-1 Service Provider infrastructure for
delivery of emergency calls and associated callback, location, and service provider information,
equivalent to conventional wireline and wireless callers.
Version 2 of this document is published for the following reasons:
      •Clarify the status of E9-1-1 services on mobile VoIP;
      •Further define requirements for ERDB/VDB Root Discovery mechanisms;
      •Further define ERDB discovery mechanism using geodetic information;
      •Add the v9 Interface specification;
      •Specify supported geodetic shapes;
      •Specify VDB/ERDB data synchronization solution;
      •Specify mechanisms to convey the callback number in the signaling path in both the IP
       domain and the Emergency Services Network;
    • Specify an ESQK guard timer value;
    • Normalize i2 message names;
    • Specify Default ESQK pools mechanism;
    • Specify the UA behavior in regard to supplementary services during emergency calls;
    • Specify a solution to support call delivery to non-E9-1-1-enabled PSAPs;
    • Specify a method to convey the subscriber name in the signaling path of the IP domain;
    • Replace the ESRN solution with a new concept: ERT & ESGWRI;
    • Specify a solution for the ERDB to provide default routing data;
    • Specify a solution to signal geodetic information from the IP domain into the Emergency
       Services Network;
    • Specify support for PSAP call control features;
    • Editorial modifications for overall document coherence & consistency including various
       updates to reflect progress is other SDO work.
    • Depreciation of the v3 interface
NOTE – Due to the above changes, this issue of the Standard is not backwards compatible with
Issue 1 of this document


Version 2, August 11, 2010                                              Page 11 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


2.5     Recommendation for Additional Development Work
No additional external Standards development work has been identified in support of this Standard.

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
This architecture is intended to be implemented in the near term. It provides the technological
approach required to meet the objectives agreed to by NENA and the VON Coalition. Prior to
implementation, further agreement must be reached on roles and responsibilities for developing,
operating and maintaining the network elements called for in the architecture.

2.8     Costs Factors
Implementation of the architecture outlined in this document will require the deployment of a
number of new network elements. Each of the new elements must be provisioned, operated, and
maintained. In addition new databases are required, which will further require the development and
maintenance of new supporting processes.

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



Version 2, August 11, 2010                                                    Page 12 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   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
Traditionally, much of the cost of the existing E9-1-1 Service Provider infrastructure has been
supported through the collection of fees and surcharges on wireline and wireless telephone service.
New network elements in the IP Domain will need to be paid for in some manner. Additionally, as
VoIP service replaces traditional voice services that currently support the E9-1-1 Service Provider
infrastructure, existing fee collections will decline and must be replaced.

2.11 Additional Impacts (non cost related)
The information or requirements contained in this NENA document are known to have both
technical and operational impacts, based on the analysis of the authoring group, and development
has been started.

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 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
or: techdoccomments@nena.org

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 [39] -
NENA Master Glossary of 9-1-1 Terminology located on the NENA web site for a complete listing
of terms used in NENA documents.




Version 2, August 11, 2010                                                  Page 13 of 247
                                                     NENA Interim VoIP Architecture for
                                                     Enhanced 9-1-1 Services (i2)
                                                     NENA 08-001 v2, August 11, 2010


 The following Acronyms are used in this document:
 Acronym        Description                                                     ** N)ew
                                                                                (U)pdate
 ERT             Emergency Route Tuple                                             N
 ESGWRI          Emergency Services Gateway Route Identifier                       N




Version 2, August 11, 2010                                          Page 14 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



3     Technical Description
This section provides an overview of the i2 migratory solution architecture recommended by NENA
for supporting emergency calls originated in the IP domain and terminated using the Public Switched
Telephone Network (PSTN) emergency services infrastructure.

3.1    General Assumptions
        •   It is assumed that one goal of the i2 solution architecture is to make no changes that will
            affect the PSAP.
        •   It is assumed that one goal of the i2 solution architecture is to minimize changes in the
            existing providers of 9-1-1 infrastructure (e.g. SR provider, ALI provider, etc.), although
            the i2 architecture does not preclude providers of 9-1-1 infrastructure from providing
            additional services in the IP domain.
        •   It is assumed that existing processes used for wireless carriers can be used to cause the
            Selective Routing Databases (SRDBs) and ALI DBs to be populated with the appropriate
            shell records for the Emergency Services Query Keys (ESQKs) used in this architecture.
        •   The i2 solution supports the receipt of both civic and geodetic location information as
            input to emergency call routing decisions. This enables the solution to route calls
            regardless of the format of the location provided by the source. It is expected that the
            location provided by the originating network and chosen for routing purposes by the
            VoIP Positioning Center (VPC) will be included in the location information that is
            provided to the PSAP. The location provided to the PSAP will be in the same form (civic
            or geodetic) that was received by the VPC.
        •   The call setup signaling in the IP domain described in this document uses Session
            Initiation Protocol (SIP) as specified in Internet Engineering Task Force (IETF) Request
            For Comments (RFC) 3261[5] (plus other supporting work in IETF), and additional
            requirements described or identified in this standard. Where IP domains use other
            protocols (e.g., ITU-T H.323), it is assumed that they will support emergency parameters
            (e.g. location) for inter-working with various interfaces and with SIP when required.
        •   A Valid Emergency Services Authority (VESA) registry will be used to provide
            certification of entities that are authorized to query for and view location information for
            any given emergency call instance it is requested to process.
        •   The various agencies that are needed to play a role for this solution to work will step up
            to their roles and responsibilities.
        •   Location information may, in general, be presented by the VoIP end point by one of two
            methods: Civic or geodetic. However, civic location is required for non-wireless fixed
            and nomadic types of service, with geodetic location optionally sent as supplemental
            information in addition to the civic location for these service types. Civic location
            presented to the PSAP is expected to be MSAG Validated.

Version 2, August 11, 2010                                                   Page 15 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


       •   The ERDB and VDB service must be provided by the same operating entity.
       •   The 9-1-1 authority will determine the single ERDB/VDB provider that will service a
           specific geographic area. For example, a State 9-1-1 Authority may choose one provider
           for its state or designate separate providers for different regions of the state. This will
           ensure that the data in the ERDB and VDB is consistent. See Section 6 for further
           discussion.
       •   The Internet architecture provides for, and promotes a model that separates connectivity
           and access mechanisms from applications and services. This is in contrast to traditional
           telephony and communication networks where access infrastructure is provided by the
           service provider as a necessity to service connectivity. This document describes an
           interim solution for providing emergency services connectivity to VoIP callers. This
           architecture places no requirements on any access network provider having to have a pre-
           defined relationship with any application service provider in order to enable emergency
           services support.
       •   Although this document focuses on VoIP emergency calls routed via SRs and dedicated
           trunks to E9-1-1-enabled PSAPs, this solution also supports the routing of VoIP
           emergency calls to non-E9-1-1-enabled PSAPs using a 7x24 (E.164) number to route via
           the PSTN. The 7x24 number must be obtained from the PSAP coordinator.
       •   The feature interaction behavior specified in NENA 08-502, NENA E9-1-1 Generic
           Requirements, is supported by the i2 Solution.
       •   It is assumed silence suppression will be disabled for emergency calls.
       •   When reusing an ESQK due to ESQK exhaust, there will be no expectation that location
           will be provided.
       •   It is expected that a VoIP Endpoint (VEP) operating in an i2 environment is capable of
           recognizing an emergency call in order to adapt its behavior specifically for processing
           emergency calls. For example, special emergency services logic is required to attach
           location, or a reference to it, to an originating emergency call, as well as to adapt feature
           interactions and silence suppression behaviors. If the VEP is incapable of recognizing an
           emergency call, the fall back is to have the VSP Call Server/Proxy always perform this
           task.
       •   It is expected that location, or a reference to it, will be presented with each emergency
           call, when available. In special circumstances, it may be possible that explicit user-
           defined usage rules present in the PIDF-LO document be overridden by regulatory-driven
           rules.
       •   For VEPs and VSP Call Servers/Proxies destined for the North American market, it is
           expected that, at a minimum, the dialed digits 9-1-1 will be recognized as emergency
           dialed digits. The VEP and the VSP Call Server/Proxy may be able to recognize other
           well known emergency dialed digits (1-1-2 for the EU, 9-9-9 for the UK, etc.).



Version 2, August 11, 2010                                                   Page 16 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


Refer to next section for additional assumptions about the i2 solution architecture and relationships
between entities in the architecture.

3.2       Overview of Interconnection to Conventional E9-1-1 Systems
This section provides an overview of the interconnection between the IP domains and the existing
E9-1-1 Emergency Services Provider infrastructure.
Figure 3-1 illustrates the functional elements and signaling interfaces used to support the i2 solution.
The acronyms used to label elements in the diagram are defined in the NENA Master Glossary and
in Section 2.13 of this standard. On the left of the figure are the functional elements of the IP
domain. Some of these represent functional elements used in the SIP architecture and are defined in
IETF RFC 3261[5].
Several new functions are introduced in the i2 solution that assist in:
      • validation of location information,
      • routing emergency calls to the appropriate interconnection point with the existing
        infrastructure,
    • providing the interconnection for the IP domain with the existing network elements and
        databases needed to support delivery of location information to the PSAP.
Brief descriptions of these new functional elements are provided in Section 3.3, along with
definitions of some of the SIP elements from RFC 3261[5] for convenience.
The IP domain “cloud” in the figure represents the collective set of IP domains, including multiple
private and public service provider domains, from which emergency calls might originate, and
through which emergency calls are interconnected with the existing emergency services
infrastructure that is shown on the right-hand side of the diagram.
In this document, all the call control interfaces are described using SIP as the example protocol. This
does not preclude providers from using other call control protocols as long as the functionality
described in this document is provided by the other protocol. For example, H.323 [29] is a protocol
that could be used instead of SIP. If other protocols have to be used then it is important that the same
functionality be provided
The logical SIP signaling interfaces between functional elements used for call setup signaling in the
IP domain are represented by dashed lines in the figure. The logical interfaces for the exchange of
location-related data between and among functional elements in the IP domain are represented by
solid lines. The interfaces defined in this standard are labeled (vX) for convenience in referencing
individual interface descriptions. The physical and logical signaling and data exchange interfaces
among existing E9-1-1 network and database elements are defined in other documents.




Version 2, August 11, 2010                                                   Page 17 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



                     IP domain                                      Emergency Services
                                                            PSTN
                                                                     Provider Network
                        Routing Proxy &
                       Redirect Server(s)          PSTN                   Used for contingency routing
                                                  Gateway                 and non-E9-1-1-enabled PSAP
                       v6
        Call Server/
              Proxy
                                                         ESGW(s)
                        v5                       v4
                                                                             E9-1-1
                             v4                                             Selective
          v1                                                                Router(s)              PSAP
                                            v2
 VoIP
 End
 Point                             v2
                                                          VPC
                                                         VPC                      SRDB
                                                       VPC
                v0                                                   v-E2
                             v3
                                                       v8                                  ALI
               LIS
                                            v9              ERDB

                                                                              MSAG
                                                  v7        VDB    DBMS
                             v9


                                  RDS


       Figure 3-1 VoIP Domain Interconnection with Emergency Services Provider Network
This figure is simplified for illustrative purposes, not showing all the interconnection of multiple
entities or mirrored E9-1-1 Selective Routers (SRs), ALI DBs, or new MSAG-based databases used
for VoIP emergency call routing or validation of location. The PSTN cloud is part of the diagram
because the i2 solution allows for the routing of VoIP emergency calls to non-E9-1-1-enabled
PSAPs using E.164 numbers [53] and contingency routing using the PSTN. In cases of failures, it
may be possible for emergency calls to be routed to the appropriate PSAP using the PSTN. It should
be noted that:
   •     There may be multiple VoIP Positioning Centers (VPCs) in any given serving area. The Call
         Server/Proxy Server/Redirect Server hosting the v2 interface chooses the VPC for
         interconnection.



Version 2, August 11, 2010                                                    Page 18 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


      •A given VPC may have interfaces to one or more ALI DBs. One or more VPCs may have
       interfaces to any given ALI DB.
   • The Emergency Service Zone (ESZ) Routing Database (ERDB) may be distributed across
       multiple database repositories in North America, but there is one authoritative source for the
       routing data for any given geographic serving area. When the ERDB is implemented apart
       from the VPC, it may support routing queries from VESA-certified VPCs in the i2 solution.
   • The Validation Database (VDB) may be distributed across multiple database repositories in
       North America, but there is one authoritative source for the location validation data for any
       given geographic serving area.
   • There will be at least one Emergency Services Gateway (ESGW) interconnected with any
       given E9-1-1 SR.
   • Any given ESGW may be interconnected with one or more E9-1-1 SRs.
   • At any given time, each VoIP endpoint (VEP)/User Agent (UA) will interact with only one
       Location Information Server (LIS) yielding a single unambiguous location or location
       reference.
   • A Call Server (CS) is operated by a VSP. A CS is typically configured to contact contracted
       VPC(s) for emergency calls or alternatively, can contract a Redirect Server or Routing Proxy
       for this task.
   • ESGW operators can be regional, similar to SR operators today.
   • Each VSP operator may contract with one or multiple ESGW operators and a single ESGW
       can be reached from multiple VSP operators.
The interfaces shown in Figure 3-1 are described in greater detail in subsequent sections of this
document.

3.3       Description of Functional Elements
This section provides brief high-level descriptions of the functional elements in the IP domain used
to support validation and management of location information, routing of emergency calls, and
delivery of location-related information to network elements and databases in the existing E9-1-1
service provider infrastructure.

3.3.1      User Agent (UA)
As defined for SIP in IETF RFC 3261[5], the User Agent represents an endpoint in the IP domain, a
logical entity that can act as both a user agent client (UAC) that sends requests, and as user agent
server (UAS) responding to requests.

3.3.2      VoIP Endpoint (VEP)
In this document, the term VoIP endpoint is used to refer to the endpoint IP device that is used to
originate an emergency call. It can take the form of a VoIP phone device, a VoIP Analog Terminal
Adaptor (ATA) or a VoIP soft-client application running over a Personal Computer (PC).



Version 2, August 11, 2010                                                 Page 19 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


3.3.3   Server
A server is a network element that receives requests in order to service them and sends back
responses to those requests. Examples of servers used in SIP domains are proxies, user agent servers,
redirect servers, and registrars.

3.3.4   Call Server
The term Call Server in this document is used to refer to the entity in a private or public IP domain
that provides service to endpoints in an emergency caller’s home domain and that interworks with
the SIP servers and other elements in the IP domain used to support emergency services call routing
in the i2 solution. The CS may use SIP or some other VoIP signaling protocol within its own serving
domain.
Functional requirements for the CS in the context of the i2 architecture are described in Section 5.1.

3.3.5   Proxy or Proxy Server/Policy and Routing Server
“A policy and routing server in the context of SIP is a proxy server, an intermediary entity that acts
as both a server and a client for the purpose of making requests on behalf of other clients. A proxy
server primarily plays the role of routing, which means its job is to ensure that a request is sent to
another entity “closer” to the targeted user. Proxies are also useful for enforcing policy (for example,
making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific
parts of a request message before forwarding it.” (Refer to IETF RFC 3261[5].) It can be a
policy/routing element in other protocols.
Functional requirements for the Routing Proxy (RP) in the context of the i2 architecture are
described in Section 5.2.

3.3.6   Redirect Server/Call Relay Server
In the context of SIP, a call relay server is a redirect server that generates (3xx) redirect responses to
requests it receives, redirecting the client to contact an alternate set of Uniform Resource Identifiers
(URIs). (Refer to IETF RFC 3261[5].) This may be an H.323 Gatekeeper for implementations that
use ITU-T H.323 architectures [29].
Functional requirements for the Redirect Server in the context of the i2 architecture are described in
Section 5.3.

3.3.7   Emergency Services Gateway (ESGW)
The ESGW is the signaling and media inter working point between the IP domain and conventional
trunks to the E9-1-1 SR. It uses either Multi-Frequency (MF) or Signaling System #7 (SS7)
signaling. The ESGW uses the routing information provided in the received call setup signaling (the
ESGWRI) to select the appropriate trunk (group) and proceeds to signal call setup toward the SR
including the ESQK in outgoing signaling. The ESGW may signal only the 10-digit ESQK or, both
the ESQK and callback number to the SR.

Version 2, August 11, 2010                                                     Page 20 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


Functional requirements for the ESGW in the context of the i2 architecture are described in Section
5.4.

3.3.8   Emergency Service Zone Routing Data Base (ERDB)
The ERDB contains the routing information associated with ESZs. It supports the boundary
definitions for ESZs and the mapping of civic address or geo-spatial coordinate location information
to a particular ESZ.
For each ESZ, the ERDB contains an Emergency Route Tuple (ERT) consisting of a Selective
Routing Identifier, a routing Emergency Services Number (ESN) that uniquely identifies the ESZ in
the context of that SR, and an NPA that is associated with the outgoing route to the SR. The ERDB
may contain a Contingency Routing Number (CRN) (i.e., a 10-digit 24x7 PSAP number) associated
with the ESZ. The ERDB may also contain an Administrative ESN for the ESZ, when applicable.
Section 5.5.1 provides more details on Administrative ESNs. There is a one-to-many relationship
between an ERT and ESZs.
When an emergency call is originated and location information is received from the VPC, the ERDB
will identify the ESZ and routing information associated with the location information. It will return
the ERT, CRN (if available) and optionally, the administrative ESN to the VPC.
The ERDB supports an interface from one or more VESA-certified VPCs in the i2 solution. The
ERDB may be distributed across multiple database repositories, but there is one authoritative source
for the routing data for any given geographic serving area. Civic location-based routing data in the
ERDB is expected to be based on the same MSAG data used to provide location validation in the
VDB, and also from existing SR network configuration information. The ERDB may support an
interface to the Database Management Systems that manage the MSAG data (to receive updates),
but this interface is not specified in this document.
Functional requirements for the ERDB in the context of the i2 architecture are described in Section
5.5.

3.3.9   VoIP Positioning Center (VPC)
The VPC is the element that provides routing information to support the routing of VoIP emergency
calls. It also cooperates in delivering location information to the PSAP using the existing ALI DB
infrastructure.
The VPC interfaces to the ERDB to obtain routing data.
The VPC receives queries from the CS or RP/RS over the v2 interface.
The information provided in a query over the v2 interface includes callback and subscriber name
information, when available (to be provided to the PSAP so that a call taker can call back an
emergency caller), and a Presence Information Data Format-Location Object (PIDF-LO) [8][37] or
Location Key. The VPC may also receive other information about the call, such as VSP
identification information.

Version 2, August 11, 2010                                                 Page 21 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


If the VPC receives a Location Key, the VPC obtains the location information from the identified
LIS.
The VPC uses the received location information to determine the appropriate ERDB to query for the
routing instructions using the Root Discovery mechanisms described in Section 3.9.
The VPC uses the received location information to request routing information from the ERDB that
is associated with the caller’s location. The VPC may also obtain information from the ERDB to
assist in contingency routing.
Using the routing data received from the ERDB, the VPC temporarily allocates an ESQK to a
particular call instance and stores information associated with that call with the ESQK pending a
subsequent query from an ALI DB.
The VPC may, optionally, be responsible for translating the ERT information received from an
ERDB to an Emergency Services Gateway Route Identifier (ESGWRI). The ESGWRI is used by the
CS/RP to route an emergency call to the correct ESGW, and by the ESGW to select the desired trunk
group path(s) to the appropriate SR for the call.
If the VPC is responsible for translating the ERT to an ESGWRI, it will pass the ESGWRI, ESQK,
and the Last Routing Option (LRO) to the CS/RP/RS in the response to a request for routing
information associated with the emergency call. If the VPC is not responsible for translating the ERT
to an ESGWRI, the VPC will pass the ERT, ESQK, and LRO to the CS/RP/RS in the routing
response.
The VPC de-allocates the ESQK when it receives an indication that the call has ended or when the
guard timer associated with the ESQK assignment expires, whichever occurs first.
Functional requirements for the VPC are described in Section 5.6.

3.3.10 Validation Data Base (VDB)
The VDB contains information that describes the current, valid civic address space defined by the
Emergency Services Network Provider’s MSAG. The structure of the database is beyond the scope
of this standard. However, the VDB should have the capability to receive a validation request
containing a civic address consisting of data elements included in the civic Location Object (LO)
defined in RFC 4119 [8][37] and as described in NENA 02-010 [11], and be able to determine if
this civic address is a valid address. The VDB will return a response indicating that a given location
is a valid address or an error response. This process ensures that the address is a real address (i.e., the
address exists) but does not ensure that it is the location of the caller.
The VDB may be distributed across multiple databases, for example, with different VDBs serving
different regional areas; however, there will be one primary source of validation data for any given
geographic area or address. NENA 02-013 [38] defines the provisioning and maintenance of the
VDB data.




Version 2, August 11, 2010                                                     Page 22 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


Functional requirements for the VDB in the context of the i2 architecture are described in Section
5.7.

3.3.11 Location Information Server (LIS)
A Location Information Server (LIS) is a functional entity that provides locations of endpoints. A
LIS can provide Location-by-Reference, or Location-by-Value, and, if the latter, in geo or civic
forms. A LIS can be queried by an endpoint for its own location, or by another entity for the location
of an endpoint. In either case, the LIS receives a unique identifier that represents the endpoint, for
example an IP address, circuit-ID or Media Access Control (MAC) address, and returns the location
(value or reference) associated with that identifier. The LIS is also the entity that provides the
dereferencing service.
Location information is in the form of civic address or geo-spatial location attributes associated with
a particular physical location. A location reference or location key is an identifier assigned by the
LIS that can be used by an entity that receives it to obtain location information from the LIS, as
described in Section 3.5.12.2.
The LIS is configured with mappings between individual location information and a logical
representation of the physical locations with which they are associated.
For wireline implementations, the wiremap in the LIS is assumed to be configured and maintained
by the entity that provides/maintains the physical or logical access facility for endpoint equipment.
For example, this might be an IT administrator for an enterprise, or an Internet Service Provider
(ISP) or Access Infrastructure Provider (AIP) in non-enterprise/residential VoIP markets. The
administrator/owner of the LIS is responsible for creating and maintaining this wiremap, and for
ensuring that the civic location data is MSAG-validated.
A given endpoint can be associated with a physical location that is mapped to a particular civic
address or geodetic coordinates, and this information is downloaded from the LIS to the endpoint as
described in Section 3.5.12.1.
Functional requirements for the LIS in the context of the i2 architecture are described in Section 5.8.

3.3.12 Root Discovery Service (RDS)
The RDS is the entity that stores the serving areas of ERDBs and VDBs. It accepts queries that
contain geo-spatial or civic location information over the v9 interface. When queried with location
information, it returns a list of URIs for ERDBs or VDBs serving that area.

3.4   Description of 9-1-1 Data Objects
This section identifies 9-1-1 data objects defined in the i2 solution architecture. These data objects
are needed to support routing of emergency calls and delivery of location information to PSAPs. The
use of the data objects and the protocols defined to carry them are described in detail in the
specification of the various interfaces in the i2 solution architecture.


Version 2, August 11, 2010                                                  Page 23 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


Emergency Services Gateway Route Identifier (ESGWRI) – The ESGWRI is used by the Call
Server/Routing Proxy to route an emergency call to the correct ESGW, and by the ESGW to select
the desired path to the appropriate SR for the call. The ESGWRI format is as follows: sip: +1
numberstring@esgwprovider.domain;user=phone where the “numberstring” is 10 numeric
characters (e.g., nnnnnnnnnn).
Emergency Route Tuple (ERT) – The ERT consists of the elements from the Emergency Services
Zone Routing Database that are used to select an ESGWRI. The ERT is communicated via the v2
and v8 interfaces and represents a route through a Selective Router for a collection of ESNs that are
associated with a Selective Router. The components of the ERT are:
   •   a Selective Routing Identifier consisting of a Common Language Location Identifier (CLLI)
       code of the form AAAABBCCDDD, where
           o AAAA represents the city/county
           o BB represents the State/Province
           o CC represents the building or location
           o DDD represents the network,
   •    a 3- to 5-digit routing Emergency Services Number (ESN) that uniquely identifies the ESZ in
        the context of that SR,
    • an NPA that is associated with the outgoing route to the SR.
Emergency Services Query Key (ESQK) – The ESQK identifies a call instance at a VPC, and is
associated with a particular SR/ESN combination. The ESQK is delivered to the E9-1-1 SR and may
be delivered as the calling number/ANI for the call to the PSAP. The ESQK is used by the SR as the
key to the Selective Routing data associated with the call. The ESQK may be delivered by the SR to
the PSAP as the calling number/ANI for the call, and subsequently used by the PSAP to request ALI
information for the call. The ALI database includes the ESQK in location requests sent to the VPC.
The ESQK is used by the VPC as a key to look up the location object and other call information
associated with an emergency call instance. The ESQK is expected to be a ten-digit North American
Numbering Plan (NANP) Number.
Last Routing Option (LRO) – The LRO is sent by the VPC to the Call Server/Routing Proxy and
provides the Call Server/Routing Proxy with a "last chance" destination for the call. The LRO may
be the Contingency Routing Number (CRN), which is a 24x7 PSAP emergency number, or it may
contain a routing number associated with a national or default call center. The content of the LRO
will depend on the condition that resulted in the providing of the LRO. Ultimately the usage of LRO
routing data for call delivery is based on logic internal to the Call Server/Routing Proxy.
Contingency Routing Number (CRN) – A 10-digit 24x7 number that could be used, when
available, to route emergency calls to the PSAP in scenarios where a network (i.e., trunk or SR)
failure results in the ESGW being unable to route the emergency call over the desired path to the SR.
The CRN is expected to be a 10-digit NANP number.



Version 2, August 11, 2010                                                 Page 24 of 247
                                                                     NENA Interim VoIP Architecture for
                                                                     Enhanced 9-1-1 Services (i2)
                                                                     NENA 08-001 v2, August 11, 2010


 Location Object (LO) – In the context of this document, the LO is used to refer to the current
position of a VEP that originates an emergency call. The LO is expected to be formatted as a
Presence Information Data Format – Location Object (PIDF-LO) as defined by the IETF in RFC
4119 [8] and RFC 5139 [37] document. The PIDF-LO may be:
        Geodetic location – latitude, longitude, elevation, and the datum which identifies the
        coordinate system used. For the i2 solution it is expected that geodetic location information
        will be formatted using the World Geodetic System 1984 [35] (WGS84 1) datum.
        Civic location – a set of elements that describe detailed street address information.
Location Key (LK) – an object that uniquely identifies an instance of a LO that is stored/managed
by a LIS on behalf of a VoIP endpoint. The Location Key may contain a unique LIS identifier and a
unique identifier for the end point. For example, in SIP this is represented as a URI and the term
used is "Location by Reference”. Details on the Location Key are for further study.
Location Information Element (LIE) – a protocol container for either or both of:
   • one LK.
   • one PIDF document.
Callback Number – an identifier for an emergency caller that can be used by the PSAP to reach an
emergency caller subsequent to the release of an emergency call. In the i2 solution, the Callback
Number is an E.164 number, and is represented in VoIP signaling by a tel-Uniform Resource
Identifier (URI) [41]. The callback number, when available, must be sourced from the VSP’s
subscription data which shall not be directly modifiable by the user.
Customer Name – The Customer Name represents the name of the VSP’s customer who subscribed
to the VoIP service and is typically billed for it. The Customer Name, when available, must be
sourced from the VSP’s subscription data which shall not be directly modifiable by the user.
Postal Address - A Postal Address includes the following data elements in the VDB validation
request and response:
    •   HouseNum
    •   PrefixDirectional (not included in all addresses – e.g. N 7TH)
    •   StreetName
    •   StreetSuffix (not included in all addresses – e.g. CONGRESS AVE)
    •   PostDirectional (not included in all addresses e.g. ACADEMY DR E)
    •   PostalCommunity
    •   CountyName
    •   StateProvince
    •   PostalCode
    •   Country

1 The i2 solutions uses Internet standards for location representation as described in RFC-5491[18]. Locations expressed
as points and shapes are specified using the WGS-84 datum in either 2 or 3 dimensions.

Version 2, August 11, 2010                                                               Page 25 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


An address is considered Postal valid if it exists in the country’s Postal Service authority data. For
example, a valid Postal Address will conform to USPS abbreviations as specified in USPS Standard
Publication No. 28 or the Canadian Postal Guide. The VDB may use a database or service based on
USPS data to determine whether an address is a valid postal address.
MSAG Address - An MSAG Address includes the following data elements in the VDB validation
request and response:
      •    HouseNum
      •    HouseNumSuffix
      •    PrefixDirectional (not included in all addresses – e.g. N 7TH)
      •    StreetName
      •    StreetSuffix (not included in all addresses – e.g. CONGRESS AVE)
      •    PostDirectional (not included in all addresses e.g. ACADEMY DR E)
      •    MSAGCommunity
      •    CountyID (not used by all MSAG addresses)
      •    StateProvince

An address is considered MSAG valid if it exists in the MSAG database. The MSAG database is
created by the Addressing Authority for a region. It contains entries for valid Address Ranges for the
Streets (within the Communities, Counties, and State/Province) for which the Addressing Authority
is responsible. The Abbreviations, Street Names and Community Names may not be the same as the
valid Postal Address for the same address (in fact they will most probably be different – see
Appendix C). An MSAG address may also require a County ID to be specified. The County ID may
be an abbreviation of the County Name or it may be the Tax Area Rate (TAR) Code for the County.

3.5       Interface Definitions
This section provides brief definitions of the VoIP and data exchange interfaces included in the i2
Solution.
The v2, v7, v8 and v9 interfaces specifications are based on web services. A short tutorial on this
technology is provided in Exibhit 8.5 for convenience.

3.5.1      v0 – LIS to VoIP Endpoint
The v0 interface is used to provide a means for a VoIP endpoint to receive information
corresponding to a pre-determined location. The information provided may be in the form of a LK,
or it can be a PIDF-LO containing the actual location, as described in Section 3.5.2. In the i2
timeframe, it is expected that the PIDF-LO may include either or both Geodetic and Civic
information, to enable routing of the emergency call, and a Civic Location, e.g. addresses for non-
mobile IP devices (mobile IP endpoints are not specifically addressed), for display to the PSAP.
How the IP network actually determines the location and the protocol between the LIS and IP device
is outside the scope of this document.

Version 2, August 11, 2010                                                  Page 26 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


 This interface should be defined by standards organizations such as TIA/IETF. Additional details
can be found in Section 6.1.

3.5.2   v1 – VoIP Endpoint to Call Server/Proxy
The v1 interface is between the VoIP Endpoint and the Call Server within the VSP’s network. It is
used to initiate an emergency call which will ultimately be answered by the correct PSAP and is also
used to communicate the location information to the Call Server when an emergency call is initiated.
The interfaces must:
   a. Transport emergency call notifications
   b. Support transport of the location information (containing either or both of a PIDF-LO and
        LK)
   c. Support the other requirements listed in this document.
 This interface should be defined by standards organizations such as TIA/IETF. Additional details
can be found in Section 6.2.

3.5.3   v2 – Call Server or Routing Proxy or Redirect Server to VPC
The v2 interface is used to request emergency call routing information. The Call Server can invoke
the v2 interface directly or utilize a Routing Proxy/Redirect Server, which requires forwarding the
LIE, or sufficient information to construct the LIE to the Routing Proxy/Redirect Server. It is
expected that the VSP/Routing Proxy Operator will have a business relationship in place which
would allow the Call Server/Proxy to send requests for routing information to the appropriate VPC.
The v2 interface is an eXtensible Markup Language (XML) query/response interface. It provides a
means for the Call Server/Routing Proxy/Redirect Server to request emergency services routing
information from the VPC based on the location of the caller. The Call Server/Routing
Proxy/Redirect Server sends a request containing location information (LO or LK), subscriber name
and callback information, and if available, a VSP identifier to the VPC. The VPC uses the location
information to interact with an ERDB to determine an ERT for routing. The ERT is also used to
determine a pool of ESQKs from which an ESQK can be allocated for the call. The ERT and ESQK
are returned over the v2 interface in the response to a request for routing information associated with
an emergency call. As an alternative to the v2 interface returning the ERT, the VPC may translate
the ERT into an ESGWRI which is returned instead of the ERT. The VPC will return an LRO, if
one is available. Additional details can be found in Section 6.3.

3.5.4   v3 –VPC to LIS
The v3 interface provides a means for the VPC to obtain the emergency caller’s location. This is
used when the LIE, provided to the VPC via the v2 interface, contains an LK. The LK is used in
obtaining the location from the LIS. The VPC uses the returned location information to obtain
routing information from the ERDB. Additional details can be found in Section 6.4.



Version 2, August 11, 2010                                                  Page 27 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


3.5.5   v4 – Call Server/Routing Proxy to ESGW
The v4 interface is used to forward the call to the appropriate ESGW. The Call Server/Routing
Proxy uses the ESGWRI returned from the VPC, or derived based on the ERT returned by the VPC,
to forward calls to the appropriate ESGW, and inserts the ESGWRI and ESQK into the signaling
message. Additional details can be found in Section 6.5.

3.5.6   v5 – Call Server/Proxy to Redirect Server
The v5 interface is defined as a SIP interface to a Redirect Server so it supports a subset of the SIP
specification. The Call Server sends a SIP INVITE containing callback information, the subscriber
name, the LO and/or LK, and the VSP identifier to the Redirect Server. The Redirect Server
interfaces to the VPC over v2 to obtain routing instructions for the emergency call based on the
location of the caller. The VPC provides the Selective Routing Identifier, Routing ESN and NPA
(referred to as an ERT) or ESGWRI along with the ESQK to the Redirect Server. The Redirect
Server responds to the Call Server with a 300 response with a Contact header containing the
ERT/ESGWRI and a P-Asserted-Identity (PAI) [40] containing the ESQK. The Redirect Server will
also include a Contact header including the LRO, if a LRO was included in the response from the
VPC. The Call Server then selects an ESGW based on the ERT/ESGWRI and forwards the call to it
via the v4 interface.
To facilitate release of the ESQK allocated to the call, the Redirect Server will need to inform the
VPC when the call has terminated. To enable termination reporting using existing SIP methods, the
Redirect Server will need to send a SUBSCRIBE method to the Call Server via the v5 interface to
make the Call Server aware that notification should be sent upon termination of the call. When the
Call Server detects that the call has terminated, the Call Server will send a SIP NOTIFY method via
the v5 interface to the Redirect Server. Upon receiving the NOTIFY method, the Redirect Server
will inform the VPC over the v2 interface so that it can release the ESQK.
Additional details can be found in Section 6.6.

3.5.7   v6 – Call Server to Routing Proxy
The v6 interface is defined as a SIP interface to a Routing Proxy. The Routing Proxy supports the
full SIP specification. The CS sends a SIP INVITE containing the callback information, the
subscriber name, the LO and/or LK, and the VSP identifier to the RP. This interface is used when
the CS (unconditionally) routes all emergency calls to a Routing Proxy.
Additional details can be found in Section 6.7.

3.5.8   v7 – LIS to VDB
The v7 interface is used by the LIS provider to request validation of a given Civic Location as
compared with the MSAG-based data stored in the VDB. The VSP may also use this interface from
its LIS, when acting on behalf of its customers in the function of location provider/verifier.



Version 2, August 11, 2010                                                  Page 28 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


A location validation request includes at least the civic location. The response includes an indication
of whether or not the Civic Location is a valid address recognized by the MSAG, and may include
error/diagnostic information to assist in resolving problems.
The interface should be able to support individual location validation requests sent one at a time for
validation processing.
Additional details can be found in Section 6.8.

3.5.9    v8 – VPC to ERDB
The v8 interface supports queries from the VPC to the ERDB. The VPC sends location information
for the emergency caller to the ERDB to obtain routing information (ERT), and other information to
help in selection of an appropriate ESQK for the call and to support the delivery of call/location
information in response to ALI database requests.
Additional details on this interface can be found in Section 6.9.

3.5.10 v9 – LIS/VPC to Root Discovery Operator
The v9 interface allows a LIS/VPC to discover the appropriate VDB/ERDB. Several mechanisms
have been defined to allow for the discovery of the VDB/ERDB and these mechanisms are described
in Section 3.9.
Additional details on this interface can be found in Section 6.10.

3.5.11 v-E2 – VPC to ALI DB
The v-E2 interface uses the E2+ protocol as defined in NENA Standards 05-001[13], with
modifications required for support of i2. The ESQK is sent in a query by the ALI DB over the v-E2
interface. The VPC responds with the emergency caller’s location, callback number, and VoIP
Provider identifier/information it received in the VSP and/or source element.
The ALI DB will need to steer ESQK queries to the VPC provider. The ESQK may need to be
identified with a VoIP Class of Service to separate this processing from the logic that is in place for
Wireless.
Additional details on this interface can be found in Section 6.11

3.6     Location Information Scenarios
There may be a variety of technologies and solutions for determining the location of an individual
caller, but after the location has been determined and validated (refer to Section 3.8), location
information must be made available for routing an emergency call to the appropriate interconnection
point and for delivery to the PSAP. This section provides a high-level overview of two basic
scenarios for storing and conveying location information for support of emergency calling from the
IP domain.


Version 2, August 11, 2010                                                   Page 29 of 247
                                                                          NENA Interim VoIP Architecture for
                                                                          Enhanced 9-1-1 Services (i2)
                                                                          NENA 08-001 v2, August 11, 2010


3.6.1    Endpoint Stores Location
To convey geographical location information within an object that includes a user's privacy and
disclosure preferences and which is protected by strong cryptographic security, the IETF has defined
an XML-based Presence Information Data Format - Location Object (PIDF-LO) that allows for
encapsulation of location information within a presence document. The PIDF-LO defines an object
suitable for both identifying and encapsulating pre-existing location information formats and for
providing adequate security and policy controls to regulate the distribution of that location
information. To provide its location to another entity (e.g., for originating an emergency call among
many other potential applications), the VoIP endpoint constructs a PIDF-LO that encapsulates its
location, as well as policy documents that describe how and to what entities that location information
can be presented. Note that the emergency services architecture being developed in IETF allows the
UA Client to include location information on emergency calls. The PIDF-LO can be used
independently of any 'using protocol' (e.g., SIP); any protocol that can carry XML or MIME
document types can carry the PIDF-LO.
In the endpoint-stored location scenario, using SIP signaling, the UA includes this PIDF-LO in the
message body of the INVITE message over the v1 interface shown in Figure 3-1. The PIDF-LO may
be carried over the v5 or v6 interface to a redirect or routing proxy, depending on the call routing
scenario (refer to Section 3.6), and is carried in a LIE over the v2 interface to the VPC for routing
determination and for subsequent delivery to the PSAP. The IETF draft-ietf-sipcore-location-
conveyance [12] describes location conveyance.

3.6.2    LIS Stored – Location Key
An alternate approach to supporting location for emergency services calling is allowed in the i2
solution, where completely specified in other standards bodies 2. This method allows for the LIS to
store the location information for a given endpoint and to download to that VoIP endpoint a Location
Key, in addition to, or instead of, the location information itself. Then, the VoIP endpoint stores the
LK and provides it, instead of or in addition to the location information, over the v1 interface on
emergency call originations. The location information/Location Key may be carried in call setup
signaling over the v5 or v6 interface to a redirect or routing proxy, depending on the call routing
scenario (refer to Section 3.6), and it will be included over the v2 interface to the VPC. When the
VPC receives the LK in an LIE, it uses the LK to query the appropriate LIS over the v3 interface.
The LIS returns the PIDF-LO to the VPC for routing determination and for subsequent delivery to
the PSAP.

3.7     Call Routing Scenarios
The definition of Call Server, Redirect Server, and Routing Proxy permits a variety of business
relationships and responsibilities to be established. The variations considered in this document
include (but are not limited to):

2 The IETF has work started to define the Location Key (known as location-by-reference, LbyR) mechanism. At this time, the
working group is discussing the requirements in [43]. Location Conveyance is described in [12].


Version 2, August 11, 2010                                                                      Page 30 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   •    The VSP contracts for VPC and ESGW services from one or more providers, and retains
        maximum control over the processing of emergency calls. The VSP’s Call Server
        implements the v2 interface, directly queries the VPC for routing information (i.e., ESQK,
        LRO, and either the ERT or ESGWRI), selects the proper ESGW based on the ESGWRI, and
        routes calls via the PSTN using the LRO if normal routing fails.
    • The VSP contracts separately for VPC and ESGW services but desires a SIP interface to
        access routing data. The Redirect Server Operator implements a Redirect Server which
        accepts 9-1-1 calls from the VSP’s Call Server. The Redirect Server obtains the routing
        information from the VPC. It returns the call to the VSP’s Call Server with the ERT or
        ESGWRI in the SIP Contact Header, and the ESQK in the SIP P-Asserted Identity header.
        The Call Server selects the proper ESGW based on the ESGWRI. The Call Server handles
        alternate routing using the LRO.
    • The VSP contracts for a single 9-1-1 call termination service from a Routing Proxy provider
        and uses the v6 SIP interface to route emergency calls to the Routing Proxy provider. The
        Routing Proxy Service Provider receives all 9-1-1 calls at its Routing Proxy. The Routing
        Proxy provider implements the v2 interface, queries the VPC for ESQK, LRO, and either
        ERT or ESGWRI, selects the proper ESGW based on the ESGWRI, and routes calls via the
        PSTN using the LRO if normal routing fails.
The remainder of this section describes these three different example call routing scenarios which
will be able to be supported in the i2 solution. These solutions differ in terms of the element that is
responsible for interacting with the VPC to obtain the routing information and the query key for the
call, and in subsequently routing the call to the appropriate gateway (i.e., ESGW). In the first
scenario, it is assumed that a Call Server is responsible for detecting that an emergency call
origination has been requested, and interacting with a VPC to obtain the necessary routing
information and query key. The Call Server is then responsible for routing the call to the appropriate
ESGW. The second scenario includes a Redirect Proxy, which is responsible for accessing the VPC,
but subsequently returns control of the call back to the Call Server for subsequent
routing/processing. In the third scenario, a Routing Proxy Server in the call path is responsible for
querying the VPC and routing the call forward to the ESGW. Each of these scenarios is illustrated
with a diagram showing the relevant interfaces and a high-level description of the associated
information flow.
These scenarios also describe a contingency routing capability, to address scenarios in which the
ESGW is unable to route an emergency call to the E9-1-1 SR over the desired path because of a
failure condition associated with the interconnecting trunk group or SR.
Each scenario also includes delivery of an indication of call release to the VPC so that it can release
the allocated ESQK for use in routing other calls.
Performance in call routing is important so that VoIP-originated emergency calls reach the
appropriate PSAP as quickly as possible. This document does not provide normative requirements
on call routing performance however, informative guidelines are available in Section 9.7 to help
implementers in designing the best approach end-to-end.


Version 2, August 11, 2010                                                   Page 31 of 247
                                                                                    NENA Interim VoIP Architecture for
                                                                                    Enhanced 9-1-1 Services (i2)
                                                                                    NENA 08-001 v2, August 11, 2010


3.7.1     Basic Call Routing of VoIP Emergency Calls to ESGW
Figure 3-2 illustrates a basic call routing scenario for a VoIP emergency call origination. In this
scenario, a Call Server queries the VPC for routing information, and routes the call directly to the
ESGW. Before the emergency call is originated, the civic location is validated in steps A and B
(refer to Section 3.8).


                       IP domain                                              Emergency Services
                                                                               Provider Network
                       Call Server/
                             Proxy         7. INVITE
                                            (ESGWRI, ESQK,                                 E9-1-1
                                           [Callback])         ESGW                       Selective                    PSAP
 2. INVITE                                   v4                           CAMA or SS7      Router         MF, E-MF,
 (911@VSPdomain                                                                                           ISDN, CTX
 {PIDF-LO} / {LK})                                                      8. Call route
                                    3. Query (Callback,                                                   9. Deliver
                                                                     (ESQK, [Callback])
                                       Customer, LIE)                                                    Call (ESQK,
                       v1           6. Response (ERT or                                                  [Callback])
                                       ESGWRI, ESQK, [LRO])                             SRDB
    User                                                                                                                 NENA
    Agent                             v2                                                                                 02-010
                                                                          v-E2                     ALI
                                                                   VPC                                    10. ALI query (ESQK)
                                                                         11. ESPOSREQ (ESQK)              13. ALI response
     1. LO        v0
                                                                         12. esposreq (Callback,             (Callback,
        and/or                                                v8                                             Customer, location,
                                           4. Query (LK)                    Customer, location,
        LK                                                                                                   [provider info])
                                           5. Response                      [provider info])
                               v3              (PIDF-LO)
                                                               ERDB
            LIS
                                           v7                                     MSAG
                                                                                   MSAG
                                                               VDB                  MSAG
                       A. Validation query (civic location)              DBMS
                       B. Validation response (valid or
                          error [with diagnostic])

                            Figure 3-2 Basic Call Routing of VoIP Emergency Calls
Step 1. The endpoint is populated with a LO and/or LK. The figure illustrates the method whereby a
PIDF-LO/LK is downloaded from the LIS to the endpoint using the v0 interface.
Step 2. The VoIP endpoint originates an emergency call by sending a call initiation request,
designating 911@VSPdomain 3 as the target destination, and including the LO and/or LK. Using SIP
as the example, the User Agent would send an INVITE, including sip:911@VSPdomain in the
Request URI header, the Address of Record (AoR) associated with the User Agent (possibly in the
form of a tel- uri[41]) in the From header, and including the PIDF-LO member-body in the INVITE.



3 RFC 5031 [24]defines a URN scheme that could be used in the context of emergency services. It would replace the actual country-
specific dial string typically found in the user part of the URI of the INVITE. Please refer to [24] for a description of this mechanism.


Version 2, August 11, 2010                                                                                    Page 32 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


Step 3. The Call Server receives the call initiation request and uses local procedures to determine
the provisioned callback number and subscriber name associated with the Address of Record
received in the incoming INVITE. The Call Server then sends a routing request to the VPC using
the information received in, and determined based on, the call request. The VPC receives the routing
request that includes the following key pieces of information:
   •    A callback number associated with the emergency caller in the form of an E.164 telephony
        number (e.g., a tel URI)
   • A subscriber name associated with the emergency caller
   • A LIE.
Step 4. If a LK is received, the VPC queries the identified LIS over the v3 interface, including the
LK.
Step 5. The LIS returns to the VPC the requested location over the v3 interface.
Step 6. The VPC uses the location (received from the Call Server or queried from the LIS) to obtain
the ESZ-related routing information from the ERDB over v8 (not shown). The ERDB identifies the
ERT and CRN that will facilitate routing via the appropriate ESGW to the SR that serves this ESZ.
The VPC uses the received routing information to allocate an available ESQK from the pool of
ESQKs appropriate for the SR/ESN associated with the caller’s location/ESZ and sends a response
to the routing request for this call. The routing response sent to the Call Server will contain the
allocated ESQK and the appropriate LRO. In addition, routing information will be included in the
response that consists of either the ERT (if the Call Server is responsible for performing the ERT-to-
ESGWRI translation), or an ESGWRI (if the VPC is responsible for performing the ERT-to-
ESGWRI translation.
The VPC also determines the VSP either from the routing request contents or from the originator of
the request. The VPC maps the caller’s Callback number, subscriber name, VSP, and the contents of
the location into the appropriate fields necessary to populate the response to an Emergency Services
Positioning Request (ESPOSREQ) and stores this information pending a subsequent query from the
ALI DB.
Step 7. If the Call Server receives an ERT in the routing response from the VPC, the Call Server
will use the ERT to determine the target ESGW and the appropriate ESGWRI value for the call. If
the Call Server receives an ESGWRI in the routing response from the VPC, the Call Server will take
the ESGWRI received in the response and use it as the basis for selecting the appropriate ESGW
toward which to route the emergency call. In either case, the Call Server routes the call to the
ESGW, including the ESGWRI, the ESQK, and the callback number in outgoing signaling.
The LRO will be retained at the Call Server and only used for emergency call routing if the ESGW
detects a failure condition that makes routing based on the ESGWRI impossible.
Step 8. The ESGW uses the received ESGWRI to select an outgoing route (i.e., trunk group) to the
appropriate E9-1-1 SR. If the trunk group is available, the ESGW seizes a trunk and signals an



Version 2, August 11, 2010                                                  Page 33 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


emergency call origination to the E9-1-1 SR, using outgoing (SS7 or MF) 10 or 20-digit signaling as
specified in Section 5.3.1.
If the ESGW determines that it cannot route the call over a route associated with the ESGWRI due to
a failure condition, it shall inform the Call Server that a failure has occurred.
Step 9. The SR receives the emergency call, uses the ESQK to query the SRDB for the associated
Emergency Service Number (ESN), and uses the ESN to identify the appropriate PSAP for the call.
The SR then delivers the call to the appropriate PSAP, signaling the ESQK (as illustrated in Figure
3-2), the callback number (if available), or both the ESQK and the callback number, based on local
implementations.
Step 10. The PSAP ANI/ALI controller receives the call setup signaling, and sends an ALI query to
its serving ALI DB, using the ESQK (as illustrated in Figure 3-2) or callback number as the query
key, based on local implementations.
Step 11. The ALI DB sends an ESPOSREQ to the VPC (identified in the shell record for the ESQK
in the ALI DB), and includes the ESQK (as illustrated in Figure 3-2) or ESQK + callback number in
the request.
Step 12. The VPC receives the ESPOSREQ from the ALI DB, and uses the ESQK to retrieve the
ALI record information it stored previously (in Step 4). The VPC returns an Emergency Services
Positioning Request response (esposreq) to the ALI DB which includes the callback number, the
subscriber name, the location information, and the VSP provided information that can be supported
by the v-E2 interface.
Step 13. The ALI DB receives the esposreq from the VPC. It may also extract additional
information from the shell record for the ESQK. The ALI DB returns an ALI response to the PSAP,
following requirements in NENA 02-010[11].
Step 14. (not shown) When the VPC receives an indication that a particular instance of an
emergency call is being cleared, the VPC de-allocates the associated ESQK and makes it available
for subsequent emergency calls. Note that release of the ESQK may occur as a result of an
indication of call release over the v2 interface from the Call Server/Routing Proxy, or the expiration
of the ESQK guard timer, whichever occurs first.

3.7.2   Proxy Redirect Server
Figure 3-3 illustrates an example of an emergency call setup using SIP signaling to a Redirect
Server. In this scenario, the Call Server uses a Redirect Server to obtain routing information, and
then routes the call to the ESGW. The SIP Redirect Server performs a routing query to the VPC
over the v2 interface.
Before the emergency call is originated, the location is validated in steps A and B (refer to Section
3.8).
Steps 1 and 2 are the same as in the basic scenario described in Section 3.6.1.


Version 2, August 11, 2010                                                  Page 34 of 247
                                                                                         NENA Interim VoIP Architecture for
                                                                                         Enhanced 9-1-1 Services (i2)
                                                                                         NENA 08-001 v2, August 11, 2010


Step 3. The Call Server/SIP Proxy Server sends an INVITE over the v5 interface to a SIP Redirect
Server. The INVITE includes the callback number, subscriber name, and PIDF-LO.
Step 4. The SIP Redirect Server queries the VPC over the v2 interface, including the following key
information:
   •    A callback number associated with the emergency caller in the form of an E.164 telephony
        number (e.g., a tel URI)
   •    A subscriber name associated with the emergency caller
   •    LIE.


                           IP domain                                                 Emergency Services
                                                                                      Provider Network
               Call Server/
                     Proxy
                                  9. INVITE
                                  (ESGWRI, ESQK, [Callback])
                                                                   ESGW
                                                                                                E9-1-1
                                                                               CAMA or SS7     Selective
                                                v4                                                                        PSAP
                          3. INVITE                                                             Router        MF, E-MF,
2. INVITE                 8. REDIRECT                                                                         ISDN, CTX
(911@VSPdomain                     Redirect                                 10. Call route
{PIDF-LO} / {LK})                   Server                                (ESQK, [Callback])              11. Deliver
                             v5                                                                           Call (ESQK,
                                                  4. Query (Callback,
                    v1                                                                                    [Callback])
                                                     Customer, LIE)
                                                                                             SRDB
       User                                       7. Response (ERT or
                                                                                                                            NENA
       Agent                                         ESGWRI, ESQK,
                                                                                                                            02-010
                                           v2        [LRO])
                                                                                  v-E2                  ALI
                                                                        VPC                                   12. ALI query (ESQK)
                    v0
                                                                              13. ESPOSREQ (ESQK)             15. ALI response
        1. LO
                                                                              14. esposreq (Callback,            (Callback,
           and/or                                                 v8
                                      v3        5. Query (LK)                    Customer, location,             Customer, location,
           LK
                                                6. Response                      [provider info])                [provider info])

               LIS                                  (PIDF-LO)       ERDB

                                                  v7                                     MSAG
                                                                       VDB                MSAG
                                                                                           MSAG
                         A. Validation query (civic location)
                                                                              DBMS
                         B. Validation response (valid or
                            error [with diagnostic])




                                   Figure 3-3 Call Routing using SIP Redirect Server
Steps 5 through 7 are the same as Steps 4 through 6 in the basic scenario described in Section 3.6.1.
Step 8. The Redirect Server returns a SIP REDIRECT message to the SIP Proxy, including the
ESQK and either the ERT or the ESGWRI provided by the VPC. It may also include a LRO, if
provided by the VPC.



Version 2, August 11, 2010                                                                                        Page 35 of 247
                                                                                         NENA Interim VoIP Architecture for
                                                                                         Enhanced 9-1-1 Services (i2)
                                                                                         NENA 08-001 v2, August 11, 2010


Step 9. The Call Server/SIP Proxy routes the call to the ESGW over the v4 interface, including the
ESGWRI provided by the VPC or determined by the Call Server, the ESQK, and the callback
number.
Steps 10-15 are the same as Steps 8-14 in the basic scenario described in Section 3.6.1.

3.7.3     Routing Proxy Routing Scenario
Figure 3-4 illustrates an example of emergency call routing via a routing proxy. In this scenario, the
emergency call is routed via a routing proxy which initiates the routing query to the VPC, and then
routes the call directly on to the appropriate ESGW.

                             IP domain                                                  Emergency Services
   Call Server/
                                                                                         Provider Network
         Proxy
                          3. INVITE
                          (Callback, Customer,
                          {PIDF-LO} / {LK})
                    v6                             8. INVITE        ESGW                        E9-1-1
                                  Routing      (ESGWRI,ESQK,                                   Selective                    PSAP
                                   Proxy          [Callback])                                   Router MF, E-MF,
            v1                                                                  CAMA or SS7
                                              v4                                                               ISDN, CTX
                                                                                 9. Call route
2. INVITE                                                                     (ESQK, [Callback])          10. Deliver
(911@VSPdomain                              4. Query (LIE, Callback,                                      Call (ESQK,
{PIDF-LO} / {LK})                               Customer)                                                 [Callback])
                                            7. Response (ESQK, ERT                           SRDB
                                               or ESGWRI, [LRO])                                                             NENA
        User                                                                                                                 02-010
        Agent                                 v2                                 v-E2                    ALI
                                                                        VPC                                    11. ALI query (ESQK)
                     v0                                                        12. ESPOS REQ (ESQK)            14. ALI response
           1. LO                                                               13. esposreq (Callback,
              and/or                               5. Query (LK)                                                  (Callback, Customer,
                                                   6. Response     v8             Customer, location,             location,
              LK                                                                  [provider info])
                                                   (PIDF-LO)                                                      [provider info])
                                 v3
                     LIS                                            ERDB
                                                   v7
                                                                                         MSAG
                                                                                          MSAG
                                                                        VDB                MSAG
                         A. Validation query (civic location)
                         B. Validation response (valid or                      DBMS
                            error [with diagnostic])

                                   Figure 3-4 Call Routing using a SIP Routing Proxy
Before the emergency call is originated, the LO is validated in steps A and B (refer to Section 3.8).
Steps 1 and 2 are the same as in the basic scenario described in Section 3.6.1.
Step 3. The Call Server/SIP proxy sends an INVITE over the v6 interface to a SIP Routing Proxy.
The INVITE includes the callback number, subscriber name, and PIDF-LO.
Step 4. The SIP Routing Proxy queries the VPC over the v2 interface, including the following
information:


Version 2, August 11, 2010                                                                                         Page 36 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   •   A callback number associated with the emergency caller in the form of an E.164 telephony
       number (e.g., a tel URI)
   • A subscriber name associated with the emergency caller
   • LIE.
Steps 5 and 6 are the same as Steps 4 and 5 in the basic scenario described in Section 3.6.1.
Step 7. The VPC uses the received PIDF-LO to request routing information from the ERDB over v8
(not shown). The ERDB uses the received location to determine the ERT and CRN for the call. The
VPC uses the ERT to determine the ESQK associated with the ESZ of the caller, and allocates an
available ESQK for the call. The VPC sends a response to the routing request for this call over the
v2 interface to the Routing Proxy, including the allocated ESQK and either an ERT (if the Routing
Proxy is responsible for performing the ERT-to-ESGWRI translation) or an ESGWRI (if the VPC is
responsible for performing the ERT-to-ESGWRI translation). An LRO is also expected to be
included in the routing response.
The VPC also determines the VSP either from the routing request contents or from the originator of
the request. The VPC maps the caller’s callback number, subscriber name, VSP, and the contents of
the location into the appropriate fields necessary to populate the response to a subsequent
ESPOSREQ from the ALI DB and stores this information pending a subsequent query.
Step 8. The SIP Routing Proxy routes the call to the ESGW over the v4 interface, including the
ESQK provided by the VPC, the ESGWRI determined by the Routing Proxy or provided by the
VPC, and the callback number.
Steps 9-15 in the Emergency Services Provider Network are the same as Steps 8-14 in the basic
routing scenario described in Section 3.6.1.

3.7.4   ESGWRI-based Routing Translations
To route calls to the correct ESGW, the routing entity must translate an ESGWRI to the URI of the
ESGW. One way this can be accomplished is by having the ESGW operator maintain a table that
maps an ESGWRI value to an ESGW. The routing data for this table can be provided in a
standardized form, and may be retrieved using HTTP [33]. An example of a table, expressed as an
XML representation is as follows:




Version 2, August 11, 2010                                               Page 37 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010



<route-table xmlns="urn:nena:xml:ns:es:rt"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:rt rt.xsd">
  <ESGW>
    <organizationName>Generic ESGW Service</organizationName>
    <expiration>2006-12-01 09:28:43+10:00</expiration>
  </ESGW>
  <Routes>
    <Route ESGWRI=2127113345 hostId=”LowerManttanNY.example.com”/>
    <Route ESGWRI=2127113346 hostId=”LowerManttanNY.example.com”/>
    ...
    <Route ESGWRI=4047113345 hostId=”RaritanNJ.example.com”/>
    ...
  </Routes>
</route-table>


The exact implementation of the ESGWRI-to-ESGW translation will be determined by the provider
of the routing entity. However, to support this translation function, the ESGW Operator shall supply
the appropriate ESGW URI to the routing entity.

3.8       Call Routing Failure Scenarios
There are a number of errors or abnormal conditions (e.g., network failures) that may occur in the
process of routing emergency calls originated by VoIP users to the appropriate E9-1-1 SR in the
Emergency Service Provider’s network. This section identifies different error scenarios that may
occur in the course of routing an emergency call to the appropriate SR in an i2 environment, and
identifies the contingency/default routing mechanisms that should be invoked at the various VoIP
elements that are impacted by the abnormal condition or event.

3.8.1      Abnormal Conditions Detected at the Call Server/Proxy
There are several classes of error/failure conditions that may be detected at the CS. One class of
abnormal conditions is related to the request for routing information that the CS is expected to
generate for emergency calls and send to the appropriate VPC, and the processing of the associated
response message from the VPC. This class of error/failure scenarios includes the following:
      • The CS cannot identify the VPC (or its network address) to which the routing request
        associated with the emergency call should be directed.
    • The CS has lost connectivity to the VPC.
    • The CS receives an error response containing no routing information from the VPC.
    • The CS does not receive any response from the VPC within a pre-determined period of time.
In all of these scenarios, the CS does not receive any routing data from the VPC. If the problem is a
loss of connectivity to the (primary) VPC, and the CS is connected to multiple VPCs, the CS may
attempt to send the routing request to a secondary VPC, provided that the appropriate agreements
exist between the VSP and the VPC providers. Should one of the other error scenarios described

Version 2, August 11, 2010                                                 Page 38 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


above occur, the CS is expected to use a default routing number or URI that has been pre-defined by
the VSP to route the call to an agent at a 24x7 call center. The callback number will be treated as the
calling number/Automatic Number Identification (ANI) for the call. If the callback number cannot
be determined for the call, the CS should still route the call forward using the default routing number
or URI without a PAI header.
In another set of scenarios, the CS receives some routing information from the VPC, but this
information does not include an ERT/ESGWRI or ESQK. In this case, the CS receives a default
routing number in an LRO from the VPC, without an ERT/ESGWRI or an ESQK. This could occur
if the VPC does not successfully receive routing information from the ERDB in response to a routing
query.
If the CS receives routing information consisting of only an LRO, the CS will either use the LRO or
the default routing number provisioned at the CS, depending on the precedence pre-defined by the
VSP, as the routing number for the emergency call. The callback number will be signaled as the
calling number/ANI for the call, if it is available.
Likewise, if the CS receives routing information from the VPC that consists of an ERT, ESQK and
LRO, and the CS is unable to successfully translate the ERT to an ESGWRI, the CS will either use
the LRO or the default routing number provisioned at the CS, depending on the precedence pre-
defined by the VSP, as the routing number for the emergency call, and will signal the callback
number as the calling number/ANI for the call, assuming it is available.
Another class of abnormal conditions results from network failures that make routing the emergency
call over the desired primary route impossible. These include the following scenarios:
   •    The CS receives an ESGWRI (along with ESQK and LRO) from the VPC, but there is no
        available outgoing route to an ESGW associated with the ESGWRI.
    • The CS receives a failure indication from the ESGW (as described in Section 3.7.3).
Under both of these scenarios, the Call Server/Proxy is expected to use the LRO received in the
routing response from the VPC, or the default routing number provisioned at the CS, depending on
the precedence pre-defined by the VSP, as the routing number for the call, and the callback number
as the calling number/ANI for the call.

3.8.2   Abnormal Conditions Detected at the VPC
One class of errors that might be detected at the VPC involves problems with the structure or content
of the routing request from the originating node (CS/RP/RS) to the VPC, or queries from the VPC to
the Emergency Service Zone (ESZ) Routing Database (ERDB) or Location Information Server
(LIS). This class includes the following scenarios:
   •    The VPC receives a badly structured routing request (i.e., request message cannot be parsed
        or is malformed.)
   •    The routing request contains neither a Location Key nor a PIDF-LO.



Version 2, August 11, 2010                                                  Page 39 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   •    The VPC receives a PIDF-LO in the routing request, but it cannot determine, based on the
        received location, which ERDB to query for the routing data.
    • The VPC receives a PIDF-LO in the routing request, but when it uses it to query the ERDB
        for routing data, it receives either an error response or no response from the ERDB.
    • The VPC receives a Location Key in the routing request, but it cannot determine where to
        send the location query (i.e., it cannot determine the appropriate LIS).
    • The VPC receives a Location Key in the routing request, but has lost connectivity to the
        desired LIS.
    • The VPC receives a Location Key in the routing request, and is unable to successfully
        retrieve a PIDF-LO from the LIS (i.e., it receives an error response or no response from the
        LIS).
In all of these scenarios, the VPC is unable to successfully obtain routing data from the ERDB and
provide it in a response to the originating node. The VPC shall then send a response message that
indicates the nature of the error that occurred. The message may also include a default routing
number (i.e., a 24x7 number associated with a call center), as determined based on prior agreements
between the VPC provider, the VSP, and the call center to which calls are to be default-routed. (The
default routing number will be populated in the Last Routing Option parameter of the response
message.).
If a VPC is responsible for performing the ERT-to-ESGWRI translation, but it is unable to
successfully perform this translation for a specific ERT provided by the ERDB, the VPC will be
expected to send a response message to the Call Server/Proxy that provides default routing
information (consisting of a CRN, if one was returned by the ERDB) in an LRO. It is not
recommended that the ESQK be included in the response to the Call Server since the VPC could not
determine an ESGWRI.
Another type of abnormal condition that might be encountered at the VPC is related to a lack of
resources at the VPC. Specifically, the VPC successfully receives routing data from the ERDB, but
there are no ESQKs available from the applicable pool to associate with the specific call instance. In
this case, the VPC is expected to return a default ESQK value in the response message to the Call
Server/Proxy along with an ERT or ESGWRI and an LRO containing a CRN, if available, or a
default routing number. Since the default ESQK may be used for several concurrent call instances it
may not yield a valid location when used by the ALI to query the VPC over the v-E2. If a VPC
receives an Emergency Services Call Termination (ESCT) message from a Call Server/Proxy that
includes a default ESQK value the VPC shall ignore the ESCT message.
Abnormal conditions associated with the release of ESQKs may also be detected at the VPC. For
example, if the VPC receives an Emergency Services Call Termination (ESCT) message from a Call
Server/Proxy that includes an ESQK value that is not currently assigned (e.g., an ESQK that has
already been released, possibly due to the expiry of the guard timer), the VPC should ignore the
message, log the event and increment the maintenance count.




Version 2, August 11, 2010                                                 Page 40 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


3.8.3   Abnormal Conditions Detected at the ESGW
It is possible that an emergency call gets successfully routed to an ESGW, with the expected
information communicated in call setup signaling (i.e., the ESGWRI , ESQK, and callback number),
and that the ESGW can identify the appropriate outgoing trunk group to the SR associated with the
received ESGWRI, but a trunk failure or SR failure makes it impossible for the ESGW to deliver the
call to the desired SR over the primary route. In such a scenario, it is expected that the ESGW will
attempt to select a secondary route for the emergency call, assuming one has been provisioned.
However, if there is no way for the ESGW to route the call forward, it is expected that the ESGW
will inform the CS of the failure condition using the appropriate SIP signaling mechanism. The CS
will then follow the procedures described in Section 3.7.1.
If, based on provisioning, the ESGW is expected to deliver both a callback number and an ESQK to
the SR over a particular trunk group, and a callback number was not provided to the ESGW in the
received INVITE message, the ESGW shall generate a non-dialable callback number of the form
911-XXX-XXXX, where XXX-XXXX is the last seven digits of the received ESQK. The Class of
Service (CoS) will enable the PSAP to distinguish this non-dialable number from other non-dialable
numbers that are generated for wireless calls (911+7 digits of Electronic Serial Number (ESN)). The
ESGW shall deliver the call to the SR with the non-dialable callback number, and the ESQK.

3.8.4   Default Routing at the Selective Router
If the SR receives an emergency call from an ESGW, but the incoming call setup signaling
associated with that call does not include sufficient information to allow the SR to successfully
invoke the selective routing process, the SR will route the call to a pre-defined default PSAP based
on the incoming trunk group over which the call was delivered by the ESGW.

3.8.5   Summary of Contingency/Default Routing
The following table summarizes the contingency/default routing scenarios described above, and the
associated routing procedures.


                        Table 3-1 Contingency/Default Routing Summary

         Element                              Scenario                             Procedure
Call Server/Proxy                •   The Call Server/Proxy has lost       Call Server/Proxy uses pre-
                                     connectivity to the VPC (and is      defined default routing
                                     not connected in                     number or URI to route call
                                     primary/secondary arrangement to     to 24x7 call center with
                                     multiple VPCs).                      which VSP has an
                                                                          arrangement. Call
                                 •   The Call Server/Proxy receives an
                                                                          Server/Proxy signals
                                     error response (with no routing
                                                                          callback number as calling
                                     information) from any of the

Version 2, August 11, 2010                                                 Page 41 of 247
                                                       NENA Interim VoIP Architecture for
                                                       Enhanced 9-1-1 Services (i2)
                                                       NENA 08-001 v2, August 11, 2010


                                 VPCs.                                 number/ANI for the call (if
                             •   The Call Server/Proxy does not        available).
                                 receive any response from the
                                 VPC within a pre-defined period
                                 of time.
                             •   The Call Server/Proxy cannot
                                 determine which VPC to which to
                                 send the routing request.
                             •   The Call Server/Proxy has lost        Call Server/Proxy may
                                 connectivity to the VPC, and the      attempt to send the routing
                                 Call Server/Proxy is connected to     query to a secondary VPC,
                                 multiple VPCs in                      if supported by agreements
                                 primary/secondary arrangement.        between the VSP and VPC
                                                                       providers.
                             •   Call Server/Proxy receives            Call Server/Proxy uses
                                 ESGWRI (along with ESQK and           LRO as routing number for
                                 LRO) from VPC, but there is no        the call, and callback
                                 available outgoing route              number as calling
                                 associated with ESGWRI.               number/ANI for the call (if
                                                                       available).
                             •   Call Server/Proxy receives failure
                                 indication from ESGW.
                             •   Call Server/Proxy is responsible
                                 for performing ERT-to-ESGWRI
                                 translation, but the translation is
                                 not successful.
                             •   Call Server/Proxy receives a     Call Server/Proxy uses
                                 default routing number from VPC. default number provided by
                                                                  VPC or pre-defined -
                                                                  default routing
                                                                  number/URI provisioned at
                                                                  Call Server/Proxy as
                                                                  routing number for the call,
                                                                  depending on precedence
                                                                  defined by VSP. Callback
                                                                  number is calling
                                                                  number/ANI for the call (if
                                                                  available).
VPC                          •   VPC receives a badly structured       VPC sends a response
                                 routing request from the Call         message to the Call

Version 2, August 11, 2010                                              Page 42 of 247
                                                      NENA Interim VoIP Architecture for
                                                      Enhanced 9-1-1 Services (i2)
                                                      NENA 08-001 v2, August 11, 2010


                                 Server/Proxy.                        Server/Proxy that either
                             •   Routing request contains neither a   indicates the nature of the
                                 Location Key nor a PIDF-LO.          error condition, or that
                                                                      provides a default routing
                             •   VPC cannot determine which           number, depending on the
                                 ERDB to query based on received      arrangements made
                                 location.                            between the VPC provider
                             •   VPC receives either an error         and the VSP.
                                 response or no response from the
                                 ERDB.
                             •   VPC receives Location Key in
                                 routing request from Call
                                 Server/Proxy but cannot
                                 determine which LIS to query for
                                 location.
                             •   VPC receives Location Key in
                                 routing request, but has lost
                                 connectivity to the desired LIS.
                             •   VPC receives an error response or
                                 no response from LIS when
                                 querying for location.
                             •   Lack of resources at VPC (i.e., no   VPC returns a default
                                 ESQKs available for assignment       ESQK along with an
                                 to specific emergency call.          ERT/ESGWRI and LRO to
                                                                      the Call Server/Proxy in
                                                                      response to its routing
                                                                      request.
                             •   VPC is responsible for performing VPC returns a response to
                                 ERT-to-ESGWRI translation, but the Call Server/Proxy that
                                 translation is unsuccessful.      only contains an LRO.
                                                                   Callback number is calling
                                                                   number/ANI for the call (if
                                                                   available).
ESGW                         •   Trunk failure or SR failure makes    ESGW selects a secondary
                                 routing call over primary route      route for the call, if one has
                                 associated with ESGWRI               been provisioned.
                                 impossible.
                             •   No outgoing routes associated        ESGW returns a failure
                                                                      indication to the Call

Version 2, August 11, 2010                                             Page 43 of 247
                                                                            NENA Interim VoIP Architecture for
                                                                            Enhanced 9-1-1 Services (i2)
                                                                            NENA 08-001 v2, August 11, 2010


                                               with the received ESGWRI are                     Server/Proxy.
                                               available.
                                           •   Provisioning dictates delivery of                ESGW generates a non-
                                               ESQK and callback number to the                  dialable callback number of
                                               SR, but callback number is not                   the form 911 + last seven
                                               available.                                       digits of the ESQK, and
                                                                                                delivers call to the SR with
                                                                                                the non-dialable callback
                                                                                                number and the ESQK.
Selective Router                           •   Incoming signaling associated                    SR routes call to pre-
                                               with emergency call does not                     defined default PSAP
                                               contain sufficient information to                associated with incoming
                                               allow SR to successfully invoke                  trunk group from ESGW.
                                               selective routing process.

3.9    Location Validation
It is important that civic location information be pre-validated by comparison with validation data
based on the MSAG data maintained by the Emergency Services Provider and/or their designated
E9-1-1 Database provider(s).
In the i2 Solution, location validation shall be performed by the LIS provider. The VDB provides a
mechanism to perform validation on civic location information. There is no validation for geodetic
location data.
Location validation must take place before a call is originated. The purpose of location validation is
to ensure that the location information can be used to properly route an emergency call to the desired
PSAP, and also that the location information provided to the PSAP can be used for dispatch of
responders.
The location validation architecture in the i2 Solution supports a mechanism for the entity seeking
validation of civic location information (e.g., the LIS) to discover the appropriate VDB for any given
serving area. This mechanism is described in Section 3.9.1.
After the appropriate VDB has been identified, the location validation request is sent using the v7
interface described in Section 6.9. The location validation request may include as input a postal or
jurisdictional address 4. The end result of location validation shall be location information that is
sufficient to support mapping to a specific record in the MSAG.




4 Jurisdictional Address: An MSAG valid address for the physical location of a subscriber access line, which has been assigned by
the jurisdiction’s local addressing authority; i.e., planning department, zoning department, etc. and is used for 9-1-1 emergency
dispatching purposes.


Version 2, August 11, 2010                                                                        Page 44 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


3.10 Root Discovery Service (RDS)
This section describes the Root Discovery Service as defined in the i2 architecture. It discusses
methods to populate the root discovery database as well as the v9 interface for discovering a VDB
and/or ERDB for a particular location. The v9 interface is detailed in 6.10.
The root discovery mechanism is defined to allow:
   •   Location validation clients (i.e., LISs) to identify the appropriate serving VDB(s) for any
       given civic location
   •   VPCs to identify the appropriate serving ERDB(s) for any given civic or geodetic location.

3.10.1 Root Discovery Assumptions
The following assumptions relate to the two applications for the root discovery mechanism.

3.10.1.1 VDB Discovery Assumptions
The prescribed approach to VDB discovery is defined with the following criteria in mind:
   •   There is no assumption that only one provider of validation services exists for a given
       location. There may be competition for validation services in the future and the architecture
       shall not preclude the ability for more than one VDB provider to validate a given civic
       location. However, if there are competing providers, they must all have validation data that
       is based on one authoritative source (the MSAG) designated by the local 9-1-1 jurisdictional
       authorities.
   •   A local 9-1-1 authority may certify VDB provider(s) to assure the quality of the data.
   •   Discovery may occur fully automatically, or it may involve manual transcribing of location
       information and/or network addresses.
   •   There is no assumption made about whether the service will or will not be available to
       members of the general public; this being a matter of individual provider policy and/or any
       legislative or other constraints which may emerge in the future.
   •   There is an assumption that a single well-known URL will be available to operate as the root
       of discovery for VDB services. There is an assumption that the overall guidelines of
       operation and technical information associated with the use of VoIP services to access E9-1-
       1 will be publicly available on an Internet accessible web site.

3.10.1.2 ERDB Discovery Assumptions
The prescribed approach to ERDB discovery is defined with the following criteria in mind:
   •   There is no assumption that only one provider of ERDB services may identify itself as the
       routing service provider for a given geographic coverage area. This is because the MSAGs
       on which the routing data is based may have irregular boundaries that do not conform exactly
       to jurisdictional boundaries. In addition where GIS data is used, overlaps of GeoShape
       polygon data representing ERDB service coverage areas and the uncertainty associated with


Version 2, August 11, 2010                                                Page 45 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


       mobile location processes may result in more than one provider being identified for a given
       geographic location.
   •   A local 9-1-1 authority may certify ERDB provider(s) to assure the quality of the data.
   •   It is assumed that the ERDB will require authenticated access. It is assumed that discovery
       of the ERDB’s coverage areas will also require authenticated access.
   •   Discovery may occur fully automatically, or it may involve manual transcribing of location
       information and/or network addresses.
   •   It is assumed that the ERDB will generally not be available to members of the general public;
       although this may be a matter of individual provider or PSAP policy and/or any legislative or
       other constraints which may emerge in the future.
   •   There is an assumption that a single well-known URL will be available to operate as the root
       of discovery for ERDB services. This may or may not be the same URL as used for VDB
       location validation services. There is an assumption that the overall guidelines of operation
       and technical information associated with the use of VoIP services to access E9-1-1 will be
       publicly available on an Internet accessible web site.

3.10.2 Root Discovery

3.10.2.1 Service provider data consolidation
Providers of ERDB/VDB services shall be responsible for communicating the identity, URL, and
coverage of their service area(s) to the host of the root discovery service. It is expected that the root
discovery service operator will publish a mechanism by which such information may be
communicated to it. The host of the root discovery service shall also publish a mechanism by which
a 9-1-1 authority shall inform it of the certification status of the ERDB/VDB operator in its area. The
9-1-1 authority will provide written communication about the certification of the ERDB/VDB
provider in their area. The Root Discovery Operator (RDO) will provide a standard form for the
9-1-1 authority to fill out. One possible way to implement certification notification is for the RDO to
provide a web form for the 9-1-1 authority to fill out. No mechanism is defined to facilitate the root
discovery service operator being able to seek out and determine the identity of ERDB/VDB service
providers who do not make themselves known to them.

3.10.2.1.1 VDB Operator Reporting Coverage to Root Discovery Operator
For civic coverage, the VDB Operator shall prepare a file in the same format as the VDB directory
file format described in Section 3.9.3, including only coverage information for its VDB. The Root
Discovery Operator shall maintain a web page with a mechanism for uploading this file.

3.10.2.1.2 ERDB Operator Reporting Coverage to Root Discovery Operator
For civic coverage, the ERDB Operator shall prepare a file in the same format as the ERDB
directory file format described in Section 3.9.4, including only coverage information for its ERDB.
The Root Discovery Operator shall maintain a web page with a mechanism for uploading this file.


Version 2, August 11, 2010                                                   Page 46 of 247
                                                                           NENA Interim VoIP Architecture for
                                                                           Enhanced 9-1-1 Services (i2)
                                                                           NENA 08-001 v2, August 11, 2010


3.10.2.2 ERDB/VDB Discovery – File Download
In its most basic form the root discovery URL shall consist of a human readable list of ERDB/VDB
service providers as a table keyed against jurisdictional descriptions of the area of coverage of their
validation service. The table should be presented in alphabetical order by state/province and, if
further breakdown is required, by county (if applicable) in alphabetical order and if necessary, by
municipality in alphabetical order. For each row in the table, a list of ERDB/VDB service provider
URLs shall be provided. A facility to download this table in CSV (Comma Separated Values) format
shall also be supported. The File Download method allows the root discovery server the ability to
download all its ERDB/VDB coverage area information to the requester. Both the initial request for
coverage data and the subsequent request for updates will result in the download of the entire
coverage area information contained in the root discovery server. This mechanism does not allow for
selective downloads, only the entire coverage information present in the root discovery server can be
retrieved using this mechanism. If selected coverage area information is required, the mechanisms
defined in Section 3.9.2.3 and Section 3.9.2.4 can be used.

3.10.2.3 ERDB/VDB Discovery – Web Form Query 5
The root discovery service provider shall provide a database query mechanism to discover the ERDB
or VDB. VPC operators would use this mechanism to obtain information about ERDBs; location
validation clients (i.e., LIS operators) would use the same mechanism to obtain information about
VDBs. In this case, the user shall be able to key in a civic address, or fragment of a civic address
(e.g., using a form), including a USPS zip code, or a geographic location (i.e., lat/long coordinate
pair), and have those providers offering the appropriate services for this location returned as a list of
URLs associated with the ERDB/VDB providers.
For Web Form queries using civic location information, the response will return both URLs of the
appropriate VDB/ERDB and the civic location element that was used to determine the URLs. For
example, if the civic query contained State, County and city, but the root discovery used the county
to determine the URLs, the county name will be sent back in the response. This mechanism is used
for both normal and abnormal operation. If the civic query contained ambiguous entries, for
example, the state and city did not match; the root discovery server will send coverage information
for the State as this is the highest level that did not result in ambiguity. The response will contain
VDB/ERDB URLs for those ERDBs/VBDs that cover the entire state.
For Web Form queries using geodetic location information, the response will return the URLs of the
appropriate ERDB providers and the Percentage Overlap Confidence (POC) value associated with
the ERDB. The POC value describes the percentage of the initially provided caller-location that
overlaps with the corresponding ERDB service area. More information on how the POC value is
calculated is described in Section 8.4.4.


5 The Root Discover Operator will provide two HTTP based services, a web form and a web service. The former is used manually to
create a query by filling out a form on the RDO web server, and seeing the results presented in human readable form. The latter is
used by a computer system, submitting an XML based query and receiving an XML result.


Version 2, August 11, 2010                                                                       Page 47 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


This document provides no solution for synchronization if data is provided by different providers for
the same area.

3.10.2.4 ERDB/VDB Discovery – Web Services
The root discovery service provider shall also support an automated discovery mechanism such that
the available ERDB or VDB service providers for a given location can be determined via an XML-
based web query. This interface is implemented using web services. For identifying the VDB, the
semantics of this query shall be as follows:


<v9:identityRequest xmlns:v9="urn:nena:xml:ns:es:v9"
    xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
    xmlns:gml=”http://www.opengis.net/gml
    xmlns:gs=”http://www.opengis.net/pidflo/1.0"
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
  <v9:civiclocation>
    <v9:HouseNum>700</v9:HouseNum>
    <v9:PrefixDirectional>N</v9:PrefixDirectional>
    <v9:StreetName>LAVACA</v9:StreetName>
    <v9:StreetSuffix>ST</v9:StreetSuffix>
    <v9:MSAGCommunity>AUSTIN</v9:MSAGCommunity>
    <v9:CountyName>TRAVIS</v9:CountyName>
    <v9:StateProvince>TX</v9:StateProvince>
    <v9:PostalCode>78701</v9:PostalCode>
    <v9:Country>US</v9:Country>
  </v9:civiclocation>
</v9:identityRequest>



and the response shall be similarly formatted to provide a status of:
    • Found
    • NotFound, or
    • Ambiguous.
Similarly, for identifying the ERDB using a civic address, the semantics of the query shall be as
follows:




Version 2, August 11, 2010                                                 Page 48 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010



<erdb-identity-request
  xmlns=”urn:nena:xml:ns:es:erdbdiscover”
  xmlns:xsi=http://www.w3c.org/2001/XMLSchema-instance
  xsi:schemaLocation=”urn:nena:xml:ns:es:erdbdiscover erdbdiscover.xsd”>
     <vlocation>
        <…geopriv cl:civicAddress coded location…>
     </vlocation>
</erdb-identity-request>



For identifying the ERDB using geodetic location data, the semantics of the query shall be as
follows:


<v9:identityRequest xmlns:v9="urn:nena:xml:ns:es:v9"
    xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
    xmlns:gml=”http://www.opengis.net/gml
    xmlns:gs=”http://www.opengis.net/pidflo/1.0"
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
  <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
    <gml:pos>37.775 -122.4194</gml:pos>
  </gml:Point>
</v9:identityRequest>



The responses for both civic and geodetic requests shall be similarly formatted to provide a status of:
   •   Found
   •   NotFound, or
   •   Ambiguous.

For a status of Found, depending on the type of query, the response shall include a list of URLs for
ERDB providers that offer routing determination for that location or a list of VDB providers who
offer validation services for that location. For NotFound, there are no other response parameters
provided. For Ambiguous, those cl:CivicAddress fields which need to be resolved before a definitive
list of providers can be returned shall be provided.
Input is made to the root discovery database containing either civic location, (Postal or MSAG) or
geographic location (lat/long). For a civic location, the query will only operate based on a general
set of input fields, such as community name, county, Zip code, and state. Specific civic location
elements, such as house number and street name will be ignored.
ERDB/VDB queries include both a postal and MSAG community name. For the root discovery
function, if the querier knows BOTH the community names, they will both be matched to determine

Version 2, August 11, 2010                                                  Page 49 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


the ERDB/VDBs returned from a root discovery query. If only one is known, and it is known that it
is the MSAG community name, the postal community name should be sent empty, and a match on
MSAG community name will be made. If only one is known, and it is known that it is the Postal
community name, the MSAG community name should be sent empty, and a match on Postal
community name will be made. If the querier has only one community name, and it does not know
which type of community name it has, the postal community name should be used, with the MSAG
community name blank.
The root does not distinguish between MSAG community and Postal community in its database.
Therefore, a query supplying both, but reversed (postal community name in the msag community
name field and vice versa), will produce the same results as one with the community names correctly
supplied.

3.10.2.5 Load Balancing
Where a client is provided with multiple VDB/ERDB addresses the client may choose to round robin
the results to ensure even distribution.

3.10.3 VDB Directory File Format
The VDB directory file shall consist of a header identifying the following:
   •   Special file identifier tag string including format version
   •   Applicable country
   •   URL of source of file
   •   Date and time of creation of the file
   •   Expiry date and time of the file (by which the source URL must have a new version of the
       file with potential changes)
Each of the above pieces of information will be on a new line in the file and be provided in order.
Formats for each of the items will be as follows.
The special identifier string and version line shall be the first line of the file and shall have the form:
%!VDB-Directory-file V<version>
Where <version> is a decimal integer of one or more digits and is greater than or equal to one (1).
The applicable country is a string representing the country of coverage. The strings USA or Canada
shall be used for these countries. For example:
USA
The URL of the source file will be a standard dot delimited URL of the entity which generated the
data file. Nominally this is the VDB root discovery URL. For example:
vdbroot.nena.org
The date and time of creation of the file shall be in the form:
Created <time>

Version 2, August 11, 2010                                                     Page 50 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


Where <time> indicates when the file content was generated by the source and is of the form
YYYY:MM:DD HH:mm:SSZ
Where YYYY is the four digits representing the year, MM is the zero leading two digits representing
the month, and DD is the zero leading two digits representing the day number of the month. HH is
the zero leading hour of day, from 00 to 23. mm is the zero leading integer minutes of the hour and
SS is the zero leading integer seconds of the minute, both from 00 to 59. Z specifies that the time is
Zulu time.. The date and time of file creation date shall be provided in the universal time coordinated
(UTC) and not be specific to a particular time zone. Since the root reports coverage over multiple
time zones, and the location of the requestor may not match that of the VDB/ERDB operator or the
RDO, a time-zone independent time is required.
The date and time of effect for the file shall be in the form
TakesEffect <time>
The RDO will ensure that TakesEffect <time> will be equal to or less than the Expires <time>.
The effect date and time of the file shall be expressed using the same specification, in UTS, as the
creation date and time. This will be a date and time at which the contents of the file may be regarded
as valid. It shall be no earlier than the creation time and will supersede the contents of any previous
file at that time even if the expiry time of the previous file is after the effect time.
The date and time of expiry for the file shall be in the form
Expires <time>
The expiry date and time of the file shall be expressed using the same specification, in UTS, as the
creation date and time. This will be a date and time no earlier than the effect time. The contents of
the file must be considered invalid at this time and a file with a later effect time than the effect time
of this file must have been retrieved and its contents available to replace the current contents at least
by the time of expiry.
The rest of the file shall consist of the data representing VDB URLs which service indicated
locations. It will be provided as an alphabetically ordered comma separated set of values (CSV) with
each data record commencing on a new line. Each line will have the following format:
<State>, <County>, <Municipality>, <Zip code>, <VDB URL list>
The <State> value will have any one of the standard country specific (e.g.,USPS) 2 character
state/province abbreviations (e.g. CA, WA, TX).
The <County> value will correspond to the country specific (e.g.,USPS) spelling of the county name
(e.g. Collin as in Collin County, Texas).
The <Municipality> value will correspond to the country specific (e.g., USPS) spelling of the
municipality name of interest (e.g. Plano, as in Plano, Collin County, Texas). Entries include ALL
of: postal, jurisdictional, MSAG community names.




Version 2, August 11, 2010                                                    Page 51 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


The <postal code> value will correspond to the local Postal code (in the U.S. 5 digits only and in
Canada 6 characters only).
The VDB URL list shall be a semicolon separated list of URLs identifying the address of VDB
services that provide validation for the location indicated by the State-County-Municipality values
preceding this value. A URL list may be blank.
Records shall be provided in alphabetical order by row with each state/county grouping according to
the following convention.


State,   *, *, *, <urls for all counties of this state not listed>
State,   County, *, *, <urls for all municipalities of this county not listed>
State,   County, Municipality, *, <urls for the specific municipality, regardless
of zip   code>
State,   County, Municipality, zipcode, <urls for the specific zip code>



Note – Where no record is provided for a particular state, this shall be equivalent to the situation
where a State, record is provided with an empty URL list. That is, it shall be interpreted that there
are no VDB facilities for that state.
Information in the file is order dependent by line. Lines may be blank and blank lines may be
ignored. End of line may be in DOS or UNIX format and indicated by either a carriage return/line
feed <CR><LF> or just a <CR>. All other whitespace characters may be ignored except where it
forms part of a state, county, or municipality name where they may be interpreted as a single space
character. State, county, and municipality names shall not include a comma or asterisk and should be
limited to alphabetical, space, and hyphen characters.




Version 2, August 11, 2010                                                   Page 52 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


3.10.3.1 Example VDB Directory File

%!VDB-Directory-file V1
USA
vdbroot.nena.org

Created                2005:06:22 14:35:26Z
TakesEffect            2005:06:26 00:01:00Z
Expires                2005:07:27 00:00:00Z

AL, *, *, *, vdbse.sbc.com
AL, Autauga, *, *, vdbse.sbc.com
AL, Autauga, Montgomery, *, vdb.rnopco.com;vdbse.sbc.com
AL, Autauga, Pratville, 36067, vdb.rnopco.com
AK, *, *, *, vdbak.bpac.com
AS, *, *, *, americansamoa-territorialauthority-vdb.asta.gov
:
: denotes actual contents not shown for brevity
:
FM, *, *, * [comment – example of blank list; e.g. no VDB for Federated States
of Micronesia at this stage]
:
: denotes actual contents not shown for brevity
:
TX, *, *, *, vdbsw.sbc.com
:
: denotes actual contents not shown for brevity
:
WY, *, *, *, vdbwy.bigsky911.com;vdbnc.bpac.com
<eof>


3.10.4 ERDB directory file format
The ERDB directory file shall consist of a header identifying the following:
   •   Special file identifier tag string including format version
   •   Applicable country
   •   URL of source of file
   •   Date and time of creation of the file
   •   Expiry date and time of the file (by which the source URL must have a new version of the
       file with potential changes).
Each of the above pieces of information will be on a new line in the file and be provided in order.
Formats for each of the items will be as follows.
The special identifier string and version line shall be the first line of the file and shall have the form:




Version 2, August 11, 2010                                                     Page 53 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


%!ERDB-Directory-file V<version>
where <version> is a decimal integer of one or more digits and is greater than or equal to one (1).
The applicable country is a string representing the country of coverage. The strings USA or Canada
shall be used for these countries. For example:
Canada
The URL of the source file will be a standard dot delimited URL of the entity which generated the
data file. Nominally this is the ERDB root discovery URL. For example:
vdbroot.nena.org
The date and time of creation of the file shall be in the form:
Created <time>
Where <time> indicates when the file content was generated by the source and is of the form
YYYY:MM:DD HH:mm:SSZ
Where YYYY is the four digits representing the year, MM is the zero leading two digits representing
the month, and DD is the zero leading two digits representing the day number of the month. HH is
the zero leading hour of day, from 00 to 23. mm is the zero leading integer minutes of the hour and
SS is the zero leading integer seconds of the minute, both from 00 to 59. Z specifies that the time is
Zulu time The date and time of file creation date shall be provided in the universal time system
(UTS) and not be specific to a particular time zone as the root reports coverage over multiple time
zones, and the location of the requestor may not match that of the VDB/ERDB operator or the RDO.
The date and time of effect for the file shall be in the form
TakesEffect <time>
The effect date and time of the file shall be expressed using the same specification, in UTC, as the
creation date and time. This will be a date and time at which the contents of the file may be regarded
as valid. It shall be no earlier than the creation time and will supersede the contents of any previous
file at that time even if the expiry time of the previous file is after the effect time.
The date and time of expiry for the file shall be in the form
Expires <time>
The expiry date and time of the file shall be expressed using the same specification, in UTC, as the
creation date and time. This will be a date and time no earlier than the effect time. The contents of
the file must be considered invalid at this time and a file with a later effect time than the effect time
of this file must have been retrieved and its contents available to replace the current contents at least
by the time of expiry.
The rest of the file shall consist of the data representing ERDB URLs which service indicated
locations. It will be provided as an alphabetically ordered comma separated set of values which each
data record commencing on a new line. Each line will have the following format:
<State>, <County>, <Municipality>, <zip code>, <ERDB URL list>


Version 2, August 11, 2010                                                    Page 54 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


The <State> value will have any one of the standard country specific (e.g., USPS) 2 character
state/province abbreviations (e.g. CA, WA, TX).
The <County> value will correspond to the country specific (e.g.,USPS) spelling of the county name
(e.g. Collin as in Collin County, Texas).
The <Municipality> value will correspond to the country specific (e.g., USPS) spelling of the
municipality name of interest (e.g. Plano, as in Plano, Collin County, Texas). Entries include ALL
of: postal, jurisdictional, and MSAG community names.
The <zipcode> value will correspond to the local Postal Code (e.g. 5 digits in the U.S., 6 characters
in Canada).
The ERDB URL list shall be a semicolon separated list of URLs identifying the address of ERDB
services that provide routing and translation for the location indicated by the State-County-
Municipality values preceding this value. A URL list may be blank.
Records shall be provided in alphabetical order by row with each state/county grouping according to
the following convention.

State,   *, *, *, <urls for all counties of this state not listed>
State,   County, *, *, <urls for all municipalities of this county not listed>
State,   County, Municipality, *, <urls for the specific municipality, any zip
code>
State,   County, Municipality, zipcode, <urls for the specific zip code>



Note – Where no record is provided for a particular state, this shall be equivalent to the situation
where a State, record is provided with an empty URL list. That is, it shall be interpreted that there
are no ERDB facilities for that state.
Information in the file is order dependent by line. Lines may be blank and blank lines may be
ignored. End of line may be DOS or UNIX format and indicated by either a <CR><LF> or just a
<CR>. All other whitespace characters may be ignored except where it forms part of a state, county,
or municipality name where they may be interpreted as a single space character. State, county, and
municipality names shall not include a comma or asterisk and should be limited to alphabetical,
space, and hyphen characters.

3.10.4.1 Example Directory File Format – Civic Coverage
Below is an example ERDB Directory file in civic format.




Version 2, August 11, 2010                                                   Page 55 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010



%!ERDB-Directory-file V1
USA
erdbroot.nena.org

Created               2005:06:22 14:35:26Z
TakesEffect           2005:06:26 00:01:00Z
Expires               2005:07:27 00:00:00Z

AL, *, *, *, erdbse.sbc.com
AL, Autauga, *, *, erdbse.sbc.com
AL, Autauga, Montgomery, *, erdb.rnopco.com; erdbse.sbc.com
AL, Autauga, Pratville, 36067, erdb.rnopco.com
AK, *, *, *, erdbak.bpac.com
AS,*, *, *, americansamoa-territorialauthrty-erdb.asta.gov
:
: denotes actual contents not shown for brevity
:
FM, *, *, * [comment – example of blank list; e.g. no ERDB for Federated States
of Micronesia at this stage]
:
: denotes actual contents not shown for brevity
:
TX, *, *, *, erdbsw.sbc.com
:
: denotes actual contents not shown for brevity
:
WY, *, *, *, erdbwy.bigsky911.com; erdbnc.bpac.com
<eof>


3.10.5 ERDB Directory File Format – Geodetic Coverage
The ERDB geodetic directory file when sent from the ERDB operator to the RDO shall be an XML
file with a header containing the following:
   •    The ERDB URI (e.g., htpps://www.erdb.harriscounty.tx.gov/erdb.html)
   •    The ERDB common name (Harris County Texas ERDB)
   •    URL of source of file
   •    Date and time of creation of the file
   •    The date and time the file becomes effective
   •    Expiry date and time of the file (by which the source URL must have a new version of the
        file with potential changes)
The URL of the source file will be a standard dot delimited URL of the entity which generated the
data file. Nominally this is the ERDB root discovery URL.
<erdbURI>https://www.erdb.harriscounty.tx.gov/erdb.html</erdbURI>
The ERDB common name will be represented in a human-readable and recognizable format.


Version 2, August 11, 2010                                               Page 56 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


<erdbCommonname>Harris County Texas ERDB</erdbCommonname>
The date and time of creation of the file shall be in the form:
<createDate>yyyy-MM-ddThh:mm:ssZ</createDate>
Where [yyyy] is the four digits representing the year, [MM] is the zero leading two digits
representing the month, and [dd] is the zero leading two digits representing the day number of the
month. [hh] is the zero leading hour of day, from 00 to 23. [mm] is the zero leading integer minutes
of the hour and [ss] is the zero leading integer seconds of the minute, both from 00 to 59. The date
and time of file creation shall be provided in the Universal Time Coordinated (UTC) using the ISO
8601 [44] format and not be specific to a particular time zone. Since the root reports coverage over
multiple time zones, and the location of the requestor may not match that of the VDB/ERDB
operator or the RDO, a time-zone independent time is required.
The date and time of effect for the file shall be in the form:
<effectDate>yyyy-MM-ddThh:mm:ssZ</effectDate>
The effect date and time of the file shall be expressed using the same specification, in UTC, as the
creation date and time. This will be a date and time at which the contents of the file may be regarded
as valid. It shall be no earlier than the creation time and will supersede the contents of any previous
file at that time even if the expiry time of the previous file is after the effect time.
The date and time of expiry for the file shall be in the form:
<expiryDate>yyyy-MM-ddThh:mm:ssZ</expiryDate>
The expiry date and time of the file shall be expressed using the same specification, in UTC, as the
creation date and time. This will be a date and time no earlier than the effect time. The contents of
the file must be considered invalid at this time and a file with a later effect time than the effect time
of this file must have been retrieved and its contents available to replace the current contents at least
by the time of expiry.
Following the header shall be the definition of the GeoShape polygon representing the ERDB
coverage boundary expressed as a series of polygon points similar to those shown in Figure 3-5,




Version 2, August 11, 2010                                                    Page 57 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010




                             Figure 3-5 ERDB Coverage Polygon
A complete ERDB geo directory will consist of the above definitions for all ERDBs served by the
RDO.
An example of an ERDB geodetic directory file is presented below.

3.10.5.1 Example ERDB Geodetic Directory File
Below is an example of an ERDB Geodetic Directory File:




Version 2, August 11, 2010                                              Page 58 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010



<?xml version="1.0"?>
<erdbBoundaryDefinition xmlns="urn:nena:xml:ns:es:geoErdbRdo"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:nena:xml:ns:es:geoErdbRdo.xsd">
  <erdbID>
    <erdbURI>https://www.erdb.harriscounty.tx.gov/erdb.html</erdbURI>
    <erdbCommonname>Harris County Texas ERDB</erdbCommonname>
    <createDate>2006-10-01T13:00:00Z</createDate>
    <effectDate>2006-10-05T17:00:00Z</effectDate>
    <expiryDate>2006-11-01T13:00:00Z</expiryDate>
  </erdbID>
  <gml:Polygon srsName="urn:ogc:def:crs:EPSG:4326"
   xmlns:gml="http://www.opengis.net/gml">
    <gml:exterior>
      <gml:LinearRing>
        <gml:pos>42.556844 -73.248157</gml:pos>
        <gml:pos>42.549631 -73.237283</gml:pos>
        <gml:pos>42.539087 -73.240328</gml:pos>
        <gml:pos>42.535756 -73.254242</gml:pos>
        <gml:pos>42.542969 -73.265115</gml:pos>
        <gml:pos>42.553513 -73.262075</gml:pos>
        <gml:pos>42.556844 -73.248157</gml:pos>
      </gml:LinearRing>
    </gml:exterior>
  </gml:Polygon>
</erdbBoundaryDefinition>




3.10.5.2 RDO Directory File Format
When the RDO constructs a file for distribution, it will contain multiple instances of this XML
structure, one for each ERDB coverage area.

3.11 PSAP Call Control Features
Many PSTN emergency services deployments in North America and around the world, implemented
specific call control features that fulfill particular needs in handling emergency situations, beyond
the core Enhanced 9-1-1 feature set (selective routing, selective transfer, ANI and address display).
In fact, some jurisdictions even mandate the availability of some of these features. NENA-03-
005[45] provides descriptions of some of the PSAP Call Control Features covered herein. This
feature set allows PSAP attendants to keep control over emergency calls and their disposition.
Not all jurisdictions have implemented PSAP Call Control features. This section is applicable solely
to jurisdictions that currently support or are planning to support those features and who want to
extend these capabilities into the IP domain. It is up to the 9-1-1 Authorities to determine if PSAP
Call Control features shall be supported for their respective 9-1-1 jurisdictions.


Version 2, August 11, 2010                                                 Page 59 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


This section describes how PSAP Call Control Features will be supported in the i2 architecture for
jurisdictions requiring them.
While the VEP and the v1 interface are out-of-scope of this document, specific references to those
are required to ensure proper end-to-end functionality. Further, the following assumptions are
considered:
   •   The VEP is compliant with IETF best current practices as defined in draft-ietf-ecrit-
       phonebcp;
   •   The VEP has knowledge of the emergency session occurring;
   •   The VEP has knowledge of PSAP Call Control features being enforced;
   •   The VEP supports the PSAP Call Control features as defined herein.
Traditionally PSAP Call Control features include:
   •   Called Party Hold
   •   Enhanced Called Party Hold
   •   Switch Hook Status
   •   Ringback (On and Off-Hook)

The Called Party Hold feature, also known as Connection Hold, Bureau Hold, Network Hold and
Originator Hold, allows the voice path and other resources associated with a 9-1-1 call to remain,
even if the caller hangs up (goes on-hook). This "disconnect pending" state is sustained until the
PSAP attendant hangs up or some specific timer expires. While in the "disconnect pending" state, if
the caller picks up again, the caller will find themselves connected to the attendant. The Called
Party Hold feature is the parent of Enhanced Called Party Hold, Switch Hook Status, and Ringback.
As a complement to the Called Party Hold feature, Enhanced Called Party Hold allows the voice
circuit to be established even though the PSAP attendant hasn't yet answered when the caller hangs
up. Once the attendant picks up, regular connection hold capabilities apply. Therefore, if the caller
picks up again, his conversation with the attendant will resume.
The Switch Hook Status feature, also known as Disconnect Signal, allows the PSAP attendant to
detect that the caller has either hung up (on-hook) or picked up the phone (off-hook). A particular
tone is generated to signal the PSAP attendant of the change in the "hook status" of the caller. In an
i2 implementation that supports PSAP Call Control features, additional signaling must be sent from
the VEP to the ESGW whenever the caller goes on-hook or off-hook. Note that the ability for the
PSAP attendant to hear the switch hook status tone is dependant on the ability of the SR and/or
PSAP CPE to generate it. If either the VEP or the PSAP do not support Switch-hook Status on top
of Called Party Hold as described above, the feature will not be enforced end-to-end. As such, a
caller going on-hook may go unnoticed.
The Ringback feature enables the PSAP attendant to invite back an emergency caller, or someone in
the vicinity of the phone, into the conversation. This feature has different behaviors depending on

Version 2, August 11, 2010                                                  Page 60 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


the state of the device (on-hook or off-hook). First, while a conversation between caller and PSAP
attendant is occurring, it allows the attendant to request that a special audible tone (for example
receiver off-hook tone) be played at the caller's device. Second, as a complement to the Called Party
Hold feature, it allows the attendant to request that the caller's device rings, if it has been hung up.
Note that Ringback is different from call back as the former occurs during an emergency session
while the latter does not.

3.11.1 Requirements
This section describes the PSAP Call Control requirements.

3.11.1.1 Requirements for Called Party Hold, Switch-Hook Status and Ringback
Industry discussion is currently taking place to define detailed call flows to support Called Party
Hold and the associated features described above. It is expected that some modifications to the SIP
protocol will be necessary to support Called Party Hold feature functionality. In an effort to
progress the work, the following requirements for Called Party Hold, Switch-Hook Status and
Ringback have been identified.
   1. It must be possible to have the PSAP rapidly re-establish communications with a caller that
      attempts to prematurely disconnect from the call.
      Rationale: Time is paramount when handling emergency calls. Keeping resources active and
      available until the call taker determines the call can be terminated saves valuable time.
   2. It must be possible for the PSAP to know when the user has attempted to prematurely
      disconnect (switch-hook status).
      Rationale: Knowledge of the device state (and caller action) gives valuable information to
      the call taker which may influence how the call will be managed going forward.
   3. It must be possible for the PSAP to know when a user that has previously attempted to
      prematurely disconnect attempts to reconnect (switch-hook status).
      Rationale: Knowledge of the device state (and caller action) gives valuable information to
      the call taker which may influence how the call will be managed going forward.
   4. Reconnecting the caller must work reasonably reliably under congestion conditions.
      Rationale: PSAPs require robust mechanisms to perform their tasks.
   5. When CPH is enforced, the PSAP must be able to cause alerting at an endpoint which has
      attempted to prematurely disconnect from the emergency call, or when the caller has gone
      silent without having disconnected (Ringback).
      Rationale: The user believes they have disconnected, or is unable to communicate. The
      ability to alert is needed to encourage the user or someone in the surroundings to reconnect
      with the call taker.
   6. While CPH is enforced, the caller must not be able to place another call until the call is
      released either by the PSAP or by other mechanisms.
      Rationale: Priority must be given to the PSAP until such time the call taker determines the
      call can be terminated.


Version 2, August 11, 2010                                                   Page 61 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   7. A rapid resumption of communication, between the caller and the PSAP, following a
      premature disconnection attempt will be supported.
      Rationale: Premature disconnection will leave the PSAP unable to obtain important
      information. Rapid resumption mitigates this issue.
   8. Called Party Hold is not needed in all jurisdictions. It must be possible to not invoke the
      function and allow premature disconnect to terminate the call as if no special features were
      present.
      Rationale: This reflects the current situation.

3.11.1.2 Requirements for Enhanced Called Party Hold
In addition to the requirements for Called Party Hold, Switch Hook Status, and Ringback identified
above, the following requirements apply to the Enhanced Called Party Hold feature:
   1. It must be possible to complete an emergency call (once it has been recognized as an
      emergency call) to a PSAP even if the caller hangs up before the call is presented to the
      PSAP.
      Rationale: PSAPs cannot distinguish between calls which are appropriately disconnected
      and calls that need response but were cut short. This feature allows PSAPs to respond to
      calls that a user has attempted to disconnect.
   2. Enhanced Called Party Hold shall be applied at the earliest possible time in the call
      establishment process.
      Rationale: Disallowing call abandonment early minimizes the chances of abandoned calls.
   3. Enhanced Called Party Hold is not needed in all jurisdictions. It must be possible to not
      invoke the function and allow calls to be abandoned as if no special features were present.
      Enabling or disabling must be dynamic, so that it can be enforced or not depending on
      requirements at the PSAP.
      Rationale: This reflects the current situation.

3.11.2 ESGW Interworking Requirements
Due to the hybrid nature of the i2 architecture, the ESGW plays a determining role in supporting the
PSAP Call Control Features. In fact, the ESGW being the entity that sits on the edge of both the IP
domain and the Emergency Services Provider Network, it is responsible for all signaling and media
protocol mediation. It is recommended that the ESGW implement Connection Hold network
capabilities on the SS7 protocol as specified in ANSI T1.666 [50] (Section 4 - Connection Hold
Network Capability) and ANSI T1.628a [49], where SS7 interconnection is implemented to the SR.
ESGW interworking requirements associated with MF interconnection to the SR are left for future
study. The specifics of the protocol interworking between SIP and SS7 ISUP that must be supported
by the ESGW will depend on industry agreement being reached with respect to modifications of the
SIP protocol to support Called Party Hold, Switch Hook Status, and Ringback.
It is expected that PSAP Call Control features support at the ESGW will be requested through the
SR operator by 9-1-1 Authorities. As such, it will be up to the SR and ESGW operators to properly


Version 2, August 11, 2010                                                Page 62 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


configure the trunking arrangement between the SR and the ESGW to allow such support for the
targeted 9-1-1 jurisdictions.

4     Security
The critical nature of the E9-1-1 Emergency Services Network makes it essential to ensure that the
E9-1-1 network is properly protected. The i2 solution introduces new network elements, new
underlying transport networks and protocols to the E9-1-1 Emergency Services network. Note that a
number of protocol interfaces are outside the scope of the 9-1-1 system (v0/v1) and several that are
between elements that are considered to be within the 9-1-1 system (v2, v3, v4, v5, v6, v7, v8, v9
and v-E2). The former are specified by other standards organizations, such as the IETF. The latter
are defined in this document. For the interfaces within the scope of this document, the security
mechanisms are dependent on the specifics of the underlying network joining the various i2 solution
network elements.
Specifically, if the network that joins the network elements is private, secured, and managed such
that there is no reasonable possibility that anyone not specifically authorized to see E9-1-1 data (and
specifically location data) has access to any systems on that network, it will not be required to
deploy additional security measures. It should be noted that it is extremely difficult to guarantee that
a network is completely private, secured and managed with no reasonable possibility of unauthorized
access, therefore it is not recommended that such “walled gardens” be the only security provided. It
is recommended that even if private networks are used to implement the i2 interfaces, additional
security mechanisms described in this section be used.
The following sections provide recommendations on the steps that can be taken to minimize the risk
of compromise to the E9-1-1 network.

4.1    Authentication
Authentication is the process of verifying the claimed identity of a session requester. Mutual
authentication is important to ensure that both the originator of the session and the recipient of the
request are both satisfied with the credential information being provided. Authentication
mechanisms are needed in the i2 solution to ensure that only trusted entities with existing
relationships will be provided access to E9-1-1 data and services.
Authentication in the i2 solution is provided by using certificates. A certificate is a data object that
includes the server’s identity and its public key. The certificate is signed by computing its hash value
and encrypting it using a certificate authority’s private key. A certificate authority is a trusted third
party that issues digital certificates. The certificate authority guarantees that the holder of the digital
certificate is who they claim to be. NENA shall create (or contract for) a Valid Emergency Services
Authority (VESA) to operate as a certificate authority, and to be the root of all certificates issued to
entities participating in an i2 call.




Version 2, August 11, 2010                                                     Page 63 of 247
                                                              NENA Interim VoIP Architecture for
                                                              Enhanced 9-1-1 Services (i2)
                                                              NENA 08-001 v2, August 11, 2010


 It is recommended that elements involved in the i2 solution deploy strong authentication methods
such as RSA-1024 [20]or better, as documented in RFC2313[14] using X.509 certificates [21] and
Certificate Revocations Lists as profiled in RFC 3280[15] and best current practices.

4.2   Message Integrity
Message integrity mechanisms provide protection against unauthorized message modifications. One
of the ways this is accomplished is by using one-way hash functions. Hashing is the transformation
of a string of characters into a usually shorter, fixed-length value that represents the original string. If
the original message is tampered with, the message hash will not match the original message. This
helps to detect that the message was tampered with.
It is recommended that elements involved in the i2 solution deploy message integrity using Secure
Hashing Algorithm-1 (SHA-1), as defined in RFC 3174 [19] or better.

4.3   Message Encryption
Message encryption is a process of disguising a message in such a way as to hide its substance. The
need for encryption of messages is a function of the level of confidence in the network being used to
implement the i2 solution interfaces. If the network being used to implement an i2 solution interface
is vulnerable, then encryption techniques should be implemented to protect the messages.
If encryption is needed, Advanced Encryption Standard (AES), Federal Information Processing
Standards Publications (FIPS) PUB 197[16] or better will be used as the means to encrypt the
messages.

4.4   Network Element Security
An important aspect of maintaining security in a network is ensuring that the network elements that
constitute the network are secure. This includes physical security of the equipment and ensuring that
data contained in the network elements are accessed by only those personnel that have a need to
access the data.
It is recommended that network elements involved in the i2 solution employ authorization and
privacy mechanisms to protect E9-1-1 data.
The network elements should support the ability to authenticate users, control user access privileges,
initiate audit trails, report security alarms, recover from intrusions, and monitor data and system
integrity.

4.5   Network Layer Security
If the i2 solution interfaces are implemented on a network that is not private, secure and managed,
tunneling is an alternative that could be used to implement the interfaces. One acceptable mechanism
is to use IPsec [17] tunnels with strong authorization, integrity protection and privacy, at least
equivalent or stronger than RSA-1024/SHA-1/AES joining network elements which are secured, and
managed such that there is no reasonable possibility that anyone not specifically authorized to see

Version 2, August 11, 2010                                                      Page 64 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


E9-1-1 data (and specifically location data) has access to any system within the networks defined by
such tunnels. Note that this usually implies that the tunnels are established between the actual
network elements running the protocols, rather than the local area network on which such elements
reside.
If tunneling is used to implement the i2 solution interfaces, it is recommended that IPsec, RFC 4301
[17], be used with strong authentication using RSA-1024 or stronger, integrity protection using
SHA-1 or better and ensuring privacy using AES or better.

4.6     Application Layer Security
The applications themselves can be secured using, for example, Transport Layer Security (TLS),
RFC 4346 [22], with strong authorization, integrity protection and privacy, at least equivalent or
stronger than RSA-1024/SHA-1/AES (RFC5246[23]) as long as the systems the protocols are
running on are reasonably protected against unauthorized persons being able to modify the
applications.
It is recommended that TLS be used to secure the following vX interfaces: v2, v3, v4, v5, v6, v7, v8,
and v9.

4.7     Location Data Security
The existing Emergency Services Network provides a relatively high degree of security for
correctness of information, integrity, and authorization of access, authenticity/secrecy, and accuracy
of information. The intent of the NENA i2 solution is to provide functional equivalency to the
existing network services in an IP-based environment, and this includes ensuring that the location
information is valid and secure.
Voice over IP presents new challenges and security issues as it breaks the bond between access and
service provider characteristic of legacy networks, and at this time, lacks the legislative and
regulatory requirements that apply to more conventional telephony services. These security threats
present themselves in a number of forms and have varying degrees of severity, should they be
exploited to their full potential. This section attempts to outline the key security concerns related to
location data, and where in the i2 solution these concerns are best addressed. This section does not in
itself provide solutions to these concerns.
Current networks use location information to route calls to the local PSAP, and to provide a location
to which emergency responders may be dispatched. Three important characteristics of existing
networks contribute to the security of these functions:
      1. The source of the location is attributable to a specific trusted source. Location is provided by
         the access/voice service provider.
      2. The location information is applicable to a specific point in time. The location information is
         either used to directly route the call (as may be the case for wireless), or indirectly via the
         calling number/ANI (as for wireline). It is always retrieved at the time of call receipt.


Version 2, August 11, 2010                                                     Page 65 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


    3. The location information can be identified as belonging to a specific end-point. This may be
       a direct association as is the case with wireline, or it may be an indirect association, as is the
       case with Emergency Services Routing Keys (ESRKs) in wireless. The location information
       is known to apply specifically to the calling device; another device’s location cannot be
       misrepresented as the calling device’s location.
In order to provide service equivalence therefore, the location information obtained and used in the
delivery of VoIP emergency calls must satisfy these three requirements.
The i2 solution proposes a Location Information Server (LIS) be the source for distributing location
information within an access network. Furthermore the validity, integrity and authenticity of this
information are directly attributed to the LIS operator. The i2 solution therefore should provide:
    1. A mechanism to ensure that location data has been provided by a LIS with a known
        responsible operator and that it has not been changed, forged, tampered with, spoofed or
        replayed by any other party, including the user, since that LIS provided the data.
    2. A mechanism to ensure that a location object (PIDF-LO document) cannot be applied to
        more than one calling device.
    3. A mechanism to ensure that the location information is still true and applicable to the calling
        device at the time it is provided to the emergency network.
The majority of security concerns for the i2 solution are therefore focused on ensuring that location
information is accurate, valid, authentic and associated with a specific call instance. While secrecy
and privacy of location information may be of some importance, these are deemed secondary to
routing and PSAP requirements. Sections defining the individual i2 element interfaces will provide
requirements addressing specific security aspects of each interface.
Location configuration and conveyance requirements are described in NENA 08-752[27], but
guidance is offered here on what should be considered when designing mechanisms to report
location:
   1. The location object should be digitally signed.
   2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose,
      VPC and ERDB operators should issue certificates to LIS operators.
   3. The signature should include a timestamp.
   4. Where possible, the Location Object should be refreshed periodically, with the signature (and
      thus the timestamp) being refreshed as a consequence.
   5. Antispoofing mechanisms should be applied to the Location Reporting method.




Version 2, August 11, 2010                                                    Page 66 of 247
                                                                                NENA Interim VoIP Architecture for
                                                                                Enhanced 9-1-1 Services (i2)
                                                                                NENA 08-001 v2, August 11, 2010



5     Functional Requirements
This section provides high-level functional requirements for the new elements in the i2 solution
architecture that are described briefly in Section 3.3. For elements defined in other standards (e.g.,
Call Server, Routing Proxy, Redirect Server), this document identifies only incremental functional
requirements to support the i2 solution.

5.1     VSP Call Server/Proxy
This element is owned by the VSP and is always present, and always in the signaling path of a call.
If the signaling protocol is SIP, this element is a proxy server as defined in RFC3261. The VSP Call
Server receives a call from one of its subscribers on the v1 interface and must recognize that it is an
emergency call. Procedures for this vary depending on protocol and end device capability. For SIP-
based systems, VSPs must be capable of recognizing an emergency call (e.g., based on the tel-URI
with digits 911, a SIP-URI with a dial string of 911 in the user part, and eventually recognizing
<urn:service:sos> ).
Upon determining that a call is an emergency call, the VSP must determine the location of the caller.
Location information may accompany the call (in SIP, this would be in the form of a PIDF-LO body
in the INVITE message), may be requested of the endpoint, or the VSP may have access to a LIS
which has the location of the caller. 6 In addition, upon determining that a call is an emergency call,
the VSP Call Server must determine, using local procedures, the provisioned callback number and
subscriber name associated with the address of record for the subscriber.
The VSP CS may be implemented in one of several ways:
     1. It may operate or contract with a VPC.
     2. It may operate or contract with a RP.
     3. It may operate or contract with a RS.
In case 1, the VSP CS maintains a v2 interface. It queries the VPC for Routing Information/ESQK
by sending information on the v2 interface. The VSP CS may be required to translate an ERT to an
ESGWRI, based on business arrangements between the VSP and VPC provider. The VSP CS
maintains routing data which maps an ESGWRI to the URI of the appropriate ESGW. It uses this
data to obtain the URI, and forwards the call on the v4 interface, with the ESGWRI, ESQK, callback
number, and optionally subscriber name to the ESGW. At the end of the call, the Call Server/Proxy
is responsible for sending a call termination message to the VPC which includes the identity of the
ESGW that was used for the call.
In case 2, the VSP CS unconditionally forwards all emergency calls (along with the associated
callback number, subscriber name information and LO and/or LK) to the RP on the v6 interface. The
RP is expected to interact with the VPC to obtain call routing information and to forward the call to


6 The ability for the VSP call server or other proxies in the call path to retrieve location when it is not available from the endpoint has
been included in Section 8.8 as a potential item for investigation in a future issue of this document.


Version 2, August 11, 2010                                                                               Page 67 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


the correct ESGW. The RP may be required to translate an ERT to an ESGWRI, based on business
arrangements between the VSP and VPC provider.
In case 3, the VSP CS unconditionally forwards all emergency calls (along with the associated
callback number, subscriber name information, and LO and/or LK) to the RS on the v5 interface. It
should receive the call back from the RS with an ESQK and either an ESGWRI or an ERT. The VSP
CS may be required to translate an ERT to an ESGWRI, based on business arrangements between
the VSP and VPC provider .The VSP CS maintains routing data which maps an ESGWRI to the URI
of the appropriate ESGW. It uses this data to obtain the URI, and forwards the call on the v4
interface, with the ESGWRI, ESQK, PIDF-LO, callback number, and optionally subscriber name to
the ESGW. The CS notifies the RS when the call has terminated and this indication contains the
identity of the ESGW that was used for the call.
In cases of failure, the CS shall be capable of providing contingency routing based on the last routing
option that it receives.
For a SIP-based CS, the Record Route header should be specified to keep the server in the signaling
path of the call.
The CS shall keep call event records for trouble shooting purposes.
It is recommended that the CS shall save (subject to local regulations/restrictions), for trouble
shooting purposes, the following information, if available, associated with a call:
   •    The call history;
   •    The contents of the esrRequest message;
   •    The contents of the esrResponse message;
   •    The disposition of the call (e.g., ESGWRI or LRO used).

5.1.1   Authentication and Authorization
No incremental authentication and authorization requirements are specified for the VSP CS in this
document. However, authentication is advisable such that the CS can assert the subscriber name and
callback number to be supplied with the emergency call. Details on how a VSP can implement
authentication are out of scope of this document.

5.1.2   Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.1.3   Reliability and Availability
No incremental reliability and availability requirements are specified for the VSP CS in this
document.




Version 2, August 11, 2010                                                   Page 68 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


5.2       Routing Proxy Server
This element is optionally present in the call path. If the signaling protocol is SIP, this element is a
proxy server as defined in RFC 3261 [5]. When deployed, the RP receives emergency calls (only,
i.e., dedicated to emergency services) forwarded from the VSP CS on the v6 interface. It maintains a
v2 interface to query the VPC for routing information/ESQK. The RP may be required to translate
an ERT to an ESGWRI, based on business arrangements between the Routing Proxy service
provider and VPC provider. The RP maintains routing data which maps an ESGWRI to the URI of
the appropriate ESGW. It uses this data to obtain the URI, and forward the call on the v4 interface,
with the ESGWRI, ESQK, PIDF-LO, subscriber name and callback number, to the ESGW.
For Routing Proxies using SIP, the Record Route header should be specified to keep the proxy in the
call signaling path.
In cases of failure, the Routing Proxy shall be capable of providing contingency routing based on the
LRO that it receives.
Routing Proxies shall keep call event records for troubleshooting purposes.
It is recommended that the Routing Proxy shall save (subject to local regulations/restrictions), for
troubleshooting purposes, the following information associated with a call:
      •    The contents of the esrRequest message;
      •    The contents of the esrResponse message;
      •    The disposition of the call (e.g., ESGWRI or LRO used);
      •    The Call History.

5.2.1      Authentication and Authorization
The RP should implement authentication mechanisms and may enforce authorization policies.

5.2.2      Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.2.3      Reliability and Availability
An RP dedicated to emergency services shall be highly reliable and available. It is an objective that
the RP be available to the CS at a service availability level of 99.999%.

5.3       Redirect Server
This element is optionally present. If the signaling protocol is SIP, this element is a proxy server as
defined in RFC 3261 [5]. When deployed, the RS receives emergency calls (only) forwarded from
the VSP CS on the v5 interface. It maintains a v2 interface. It queries the VPC for ERT/ESQK or
ESGWRI/ESQK by sending information, including location, callback number, and subscriber name,
on the v2 interface. It then unconditionally forwards the SIP 300 Message on the v5 interface, with

Version 2, August 11, 2010                                                   Page 69 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


the ESQK, ERT/ESGWRI and the LRO back to the VSP CS. The VSP CS then routes the call, based
on the ESGWRI, to the correct ESGW over v4.
The RS shall support a mechanism to allow it to receive a call termination notification.
The RS shall support the capability to indicate to the VPC that a call has terminated.
It is recommended that the RS shall save (subject to local regulations/restrictions), for
troubleshooting purposes, the following information associated with a call:
      •    The contents of the esrRequest message;
      •    The contents of the esrResponse message;
      •    The disposition of the call (e.g., ESGWRI or LRO used);
      •    The Call History.

5.3.1      Authentication and Authorization
The RS should implement authentication mechanisms and may enforce authorization policies.

5.3.2      Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.3.3      Reliability and Availability
An RS dedicated to emergency services shall be highly reliable and available. It is an objective that
the RS be available to the CS at a service availability level of 99.999%.

5.4       Emergency Services Gateway (ESGW)
The ESGW takes VoIP delivered calls and converts them to circuit-switched signaling and media for
delivery into the E9-1-1 Selective Routing Network.
The ESGW implements the v4 interface. It accepts a call with an ESGWRI, ESQK, callback number
and, optionally subscriber name and uses the ESGWRI to select an outgoing trunk group to the E9-
1-1 network. The ESGW maintains mapping data that associates the ESGWRI with the appropriate
outgoing trunk group. It is expected that the ESGW will implement dedicated 9-1-1 trunks to the SR.
The ESGW provider and the VSP are expected to negotiate the codecs that are to be supported.
These trunk groups or routes use traditional telephony signaling schemes to deliver the emergency
call over dedicated voice channels between the gateway and the E9-1-1 network. These trunks
originate at the ESGW and terminate at the SR, as designed to meet the needs and constraints of the
particular E9-1-1 network for the caller’s location.
In general, the trunking protocol, and the trunk design will be determined based on the capabilities
(and requirements) of the destination E9-1-1 network.
Likely candidates for these circuits are:

Version 2, August 11, 2010                                                   Page 70 of 247
                                                                            NENA Interim VoIP Architecture for
                                                                            Enhanced 9-1-1 Services (i2)
                                                                            NENA 08-001 v2, August 11, 2010


    •   SS7 signaling, which can be used to signal either just the ESQK or both the ESQK and
        callback number, depending on the way the trunks are provisioned at the ESGW.
        - If only an ESQK is signaled to the SR, the IAM includes a Called Party Number (CdPN)
            of “911,” (or “11,” or “1”) and the ESQK in the Calling Party (CgPN) and/or Charge
            Number parameter(s). The 10 digit ESQK is used to represent the call key.
        − If both the ESQK and the callback number are to be signaled to the SR, the IAM includes
            a Called Party Number (CdPN) of “911” (or “11,” or “1”), the callback number in the
            Calling Party (CgPN) and/or Charge Number parameter(s), and the ESQK in the Generic
            Digits Parameter 7 (GDP). Note that if both the ESQK and callback number are expected
            to be signaled over a particular trunk group, but the callback number is not available, the
            ESGW is expected to generate a non-dialable callback number of the form 911 + the last
            seven digits of the ESQK, and deliver the call to the SR with the non-dialable callback
            number signaled as the Calling Party Number (CgPN) and/or Charge Number, and the
            ESQK signaled in the Generic Digits Parameter (GDP).
    • Traditional CAMA signaling, which can be used to signal either just the ESQK or both the
        ESQK and callback number, depending on trunk provisioning.
        − If only an ESQK is to be signaled to the SR, a called number of the form “911,” “11,” or
            “1” , and an ANI of the form I [single info digit] plus a 7-digit ESQK value, shall be
            outpulsed, with both digit streams contained between the KP and ST pulses. Note that
            since the ESGW will be receiving a 10-digit ESQK value, this assumes that the ESGW
            will convert the received 10-digit ESQK value to a 7-digit ESQK value.
        − If both the ESQK and the callback number are to be signaled to the SR, the ESQK will be
            outpulsed as the called number, and the ANI stream will consist of a single ANI “I” digit
            plus the last 7 digits of the callback number 8.
These trunk groups may not be used to originate traffic back into the ESGW, but once the call is
established, provide for two way voice communication.
In general, the 9-1-1 service provider will have technical standards, or accessibility letters that define
the allowable signaling schemes to be used within their network. In many cases, the ESGW operator
may also need to negotiate with the individual Public Safety Operators within a given geographic
area before these circuits can be ordered to, or through the SR Operator.
Sizing of trunk groups between ESGWs and SRs is a subject for a future study. This is a complicated
issue because, unlike wireline call delivery where an end office serves a fixed population, the
population served by a VSP is expected to be variable. Further complicating this issue is the fact that
a VSP is probably connected to multiple ESGWs and ESGWs are expected to be connected to
multiple VSPs. This many-to-many relationship makes determination of VoIP 9-1-1 traffic loads at
ESGWs an issue that needs further study.



7 NENA 03-503 [32] also allows the ESQK to be signaled as the called number in some implementations.
8 Not all implementations support signaling of 20-digits over MF trunk groups.


Version 2, August 11, 2010                                                                    Page 71 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


5.4.1      Authentication and Authorization
The ESGW should implement authentication mechanisms and may enforce authorization policies.

5.4.2      Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.4.3      Reliability and Availability
An ESGW dedicated to emergency services shall be highly reliable and available. It is an objective
that the ESGW be available to the CS/RP at a service availability level of 99.999%.

5.5       ESZ Routing Database (ERDB)
This section provides the high-level functional requirements for the ERDB.
The ERDB has two main functions:
      •    the ERDB is responsible for storing boundary definitions for each ESZ in its service area,
           along with associated routing information;
      •    the ERDB is responsible for delivery of routing information to the VPC.

5.5.1      Receiving and Storing Routing Information
The ERDB shall support storage of the boundary definitions for ESZs and the mapping of civic
address or geo-spatial coordinate location information to a particular ESZ. The ERDB shall be able
to identify the ESZ associated with any given civic address in its serving area, where the civic
address can be uniquely mapped to an MSAG-valid address. The ERDB shall be able to identify the
ESZ associated with any given pair of coordinates that are within its serving area.
The ERDB also stores attributes for each ESZ. For each ESZ, the ERDB shall be able to store the
following information needed for routing:
      •a Selective Routing Identifier associated with the primary SR that serves the ESZ in the i2
       solution;
   • the routing ESN within that primary SR that is associated with the ESZ;
   • an NPA that is associated with the outgoing route to the Selective Router.
Some PSAPs use administrative ESNs, different from the routing ESN associated with the ESZ. This
administrative ESN is also used in the ALI DB to identify a particular set of Police, Fire, and
Medical English Language Translations. The ERDB shall also be able to store an administrative
ESN for an ESZ, if applicable.
CRNs are 10-digit 24x7 PSAP numbers that are used for routing emergency calls under network
failure conditions. A CRN must be associated with each SR/routing ESN combination.



Version 2, August 11, 2010                                                    Page 72 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


As specified in Section 3.4, Selective Routing Identifiers are in the form of CLLI codes. ESNs shall
be defined as at least 5 digits in length (including leading zeros), in order to assure compatibility
with MSAG values.
NOTE: If the PSAP does not receive emergency calls via dedicated trunks and E9-1-1 facilities from
SRs, it may instead receive them via the PSTN using a 24x7 E.164 number. In that case, the ERDB
will store the PSAP E.164 number in the CRN attribute and there will not be other routing
information attributes populated for the ESZ (i.e., no Selective Routing Identifier, routing ESN,
NPA) associated with that caller’s location.
The ERDB is not aware of the trunk group arrangements at the ESGW. The arrangements may differ
between ESGW networks.

5.5.1.1 Data Management
The ERDB shall support a database structure that will allow for additional attributes to be easily
associated with an ESZ.
The ERDB database management system shall allow for multiple agents to simultaneously perform
database maintenance (data object creation, update, deletion) on the routing data.
The database structure shall be capable of supporting real-time queries.

5.5.1.2 Authentication and Authorization
The ERDB shall be able to authenticate the sources from which it receives source data for inclusion
in the ERDB. Based on the credentials of the source, the ERDB shall control the source’s access to
view, enter, and modify information in the ERDB.

5.5.1.3 Data Integrity
The ERDB database management system shall enforce consistency of routing information whether a
given location is defined as a civic address or as geo-spatial coordinate information.
The ERDB shall provide for automatic as well as manually initiated audits of the integrity and
consistency of the routing data.
For ERDB data consistency requirements please refer to NENA 02-013[38].

5.5.2   Processing Routing Queries
The ERDB shall be able to receive either or both civic and geodetic location information in a routing
query.
Whenever the ERDB receives a routing query containing valid location information from an
authorized VPC, the ERDB shall attempt to map the location information to the applicable ESZ and
its associated routing information.



Version 2, August 11, 2010                                                  Page 73 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


If both civic location and geodetic location information are included in a routing query, the ERDB
shall be configurable to support using either element or both, in a specified search order, in the
attempt to determine the routing information. The ERDB shall signify which one was used in the
response.

5.5.2.1 Authentication and Authorization of Routing Queries
The ERDB shall support the capability to authenticate the entities from which it is allowed to receive
routing queries.
Based on the credentials of the entity from which a routing query is received, the ERDB shall
support the capability to control the access of the entity to routing information in the ERDB.

5.5.2.2 Civic Location Information (Street Address) Received in Routing Query
The ERDB shall be able to receive the components of a civic address that are defined for the
Presence Information Data Format – Location Object (PIDF-LO) defined in RFC-4119 [8][37]:
    • State/Province
    • County Name
    • MSAG Community Name
    • Postal Community Name
    • Postal/Zip Code
    • Prefix Directional
    • Street Name
    • Street Suffix
    • Post Directional
    • House Number
    • House Number Suffix (if applicable)
The ERDB shall be able to recognize an alphanumeric County Name. In the USA, the ERDB shall
also be able to recognize a numeric Federal Information Processing Standard 9 (FIPS) County ID in
the County Name. In the USA, the ERDB shall support the capability to convert a County Name to a
Federal Information Processing Standard (FIPS) County ID value for the county, if County ID is
used within the ERDB for determining routing in a given area.
The ERDB shall be able to recognize either Postal Addresses or MSAG Addresses, as defined in
Section 3.4, received in the civic address information. If a valid address (i.e., one that can be
uniquely mapped to an MSAG-valid address) is received, then the ERDB shall be able to use it to
determine routing information and to identify MSAG-valid formats.
If the civic location information contains a valid address within the ERDB’s serving area, the ERDB
shall use this information to determine the ERT, the routing ESN, and the CRN associated with the


9 Federal Information Processing Standard (FIPS), PUB 6-4.


Version 2, August 11, 2010                                                  Page 74 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


identified ESZ. If there is a separate administrative ESN associated with the ESZ, the ERDB shall
also be able to determine the administrative ESN.
In addition, for postal civic addresses, the ERDB shall be able to transform a valid postal civic
address to the MSAG-valid format for that address.

5.5.2.3 Geodetic Location Information Received in Routing Query
If the routing query contains geodetic location information (latitude and longitude) that identifies a
location within the serving area of the ERDB, the ERDB shall be able to determine the ERT, the
routing ESN and the CRN associated with the identified ESZ in response to the routing query. If
there is a separate administrative ESN associated with the ESZ, the ERDB shall also be able to
determine the administrative ESN.
The geodetic location information must be in the form of decimal degrees, using the WGS84
coordinate system.

5.5.2.4 Responding to Routing Queries
If the ERDB is able to successfully use the received location information to determine the routing
information, the ERDB shall follow the requirements in Section 6.10 to send a response to the VPC,
including the following routing information:
   •    An ERT comprising:
            - A Selective Routing Identifier, if available.
            - A routing ESN, if available.
            - An NPA, if available.
    • A CRN, if available.
    • An Administrative ESN, if applicable.
    • An indication of whether civic or geo location information was used to determine routing (if
        both civic and geo location information were received).
NOTE: If the PSAP does not support dedicated trunks and E9-1-1 facilities, emergency calls will be
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the ERDB response will
indicate success, but the only routing information provided will be the CRN (i.e., ERT will not be in
the response).
If civic location information was received in the routing query, the ERDB shall also include the
transformed address information in its response to the VPC. The MSAG-valid address includes the
following data elements, as applicable:
   •   State/MSAG Community Name
   •   Prefix Directional (if applicable)
   •   Street Name
   •   Street Suffix (if applicable)
   •   Post Directional (if applicable)


Version 2, August 11, 2010                                                   Page 75 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   •   House Number
   •   House Number Suffix (if applicable)

5.5.2.5 Steering of Routing Queries
If the ERDB receives a routing query from a VPC, and the received location information is not
within the ERDB’s serving coverage area, the ERDB may support one of the following:
   •   The ERDB may steer the routing query to the appropriate ERDB and then pass the received
       response from that remote ERDB toward the requesting VPC.

NOTE: The steering procedures are incomplete at this time. Further work will be required to fully
define steering procedures. This may be a topic for a future issue of this Standard.

5.5.2.6 Error Handling
If the ERDB receives civic or geodetic location information that identifies a location within its
serving area for which it cannot determine any routing information, the ERDB shall return a
response to the VPC indicating that routing information is not available, also including the reason for
the failure.
If the ERDB receives civic or geodetic location information that identifies a location which is not
within its serving area and it cannot determine the ERDB to which the civic or geodetic location
information should be steered, the ERDB shall return an error response to the VPC indicating that
routing information is not available and indicating the reason for failure.
If the ERDB receives an error message in response to a routing query steered to another remote
ERDB, the ERDB shall pass the received error response received from the remote ERDB to the
VPC, including the reason for failure.

5.5.2.7 Default Routing
Default Routing may be invoked when a received civic address does not resolve to a single MSAG
address. For example, the location received matches at the state level but not at the municipality
level.
ERDB providers are encouraged to provide the default routing options described in this section. If
any default routing is to be provided, it is critical that the 9-1-1 Authorities work with the ERDB
provider to determine which of the default routing options described here should be offered for their
area. The 9-1-1 Authority must also work with the ERDB provider to build, approve and maintain
routing data. The ERDB shall not provide any default routing without the 9-1-1 Authority’s explicit
approval.
The 9-1-1 Authority can designate any ESN as a default ESN. Because there is currently no explicit
way for the VPC to communicate to the ALI system that a call has been default routed, it is
preferable that the 9-1-1 Authority specify distinct ESNs to be used as defaults so that the ESN itself


Version 2, August 11, 2010                                                  Page 76 of 247
                                                                           NENA Interim VoIP Architecture for
                                                                           Enhanced 9-1-1 Services (i2)
                                                                           NENA 08-001 v2, August 11, 2010


alerts the PSAP that a call has been default routed 10. These ESNs could be new ones designated for
the purpose, they could be the reused ESNs which were previously assigned by some PSAPs for pre-
i2 (one per PSAP) use, or they could be the same ESN associated with wireless default routing. As
with all ESNs in the ERDB, the default ESNs must be associated with a specific ERT.
This section describes two types of default routing. The 9-1-1 Authority must decide which types of
default routing they would like provided. If they decide that they wish to use both types of default
routes, they must determine the order in which they are applied for invalid addresses. The two types
of default routing are:
    •    Default Geodetic Routing. This type of routing has the potential to closely match how a call
         would be routed if the location was MSAG valid. In order for this type of default routing to
         be done all of these conditions must be met:
              o The ERDB must have street-level GIS information (either commercial 11, or provided
                by the 9-1-1 Authority).
              o The ERDB must maintain correct ESN polygon boundaries (which are ideally
                provided by the 9-1-1 Authority).
            o The address presented must be successfully geo-coded (i.e. when looking up the
                submitted address in the street-level information, a successful result is returned).
                Geo-coding is not a required function of the ERDB.
    • Default Tabular Routing. This type of routing is less likely to match how a call would be
        routed if the location was MSAG valid. It requires that the 9-1-1 Authority determine ESNs
        for default routes at the Postal Zone, Community, County and State level.
When default route ESNs are used, the MSAG-valid civic address parameter returned by the ERDB
should have the address fields set to “Verify” in any fields not determined to be accurate. The VPC
should set the Class of Service to “V” (especially in the case of reuse of the wireless default ESNs)
in the data returned by the VPC over the v-E2 interface.
If the 9-1-1 Authority does not make any choices in regards to handling invalid addresses, the ERDB
shall return a 400 Result Code (ErrorBadLocation) to the VPC. The VPC will then be responsible
for determining how to handle the call.

5.5.2.7.1 Default Geodetic Routing Requirements
The ERDB may provide the ability to default route based on a geo-coded civic location. If a non-
MSAG valid civic location is presented and that location can be successfully geo-coded, the ERDB
may use the same routing methodology used for calls where lat/long is the only information
provided in the erdbRequest message. The ERDB should include the geocoded location in the
erdbResponse message. The 9-1-1 Authority should approve the GIS data used for geo-coding.

10 Some PSAP representatives have suggested that using pre-i2 VoIP ESNs as the default routes would help the call-taker identify
which VoIP calls were default routed using this mechanism.
11 Commercial databases should not be used without the express approval of the 9-1-1 Authority.


Version 2, August 11, 2010                                                                        Page 77 of 247
                                                                             NENA Interim VoIP Architecture for
                                                                             Enhanced 9-1-1 Services (i2)
                                                                             NENA 08-001 v2, August 11, 2010


If a civic location can’t be geo-coded and the 9-1-1 Authority specifies that Tabular Default Routing
should not be used, the ERDB will not attempt to determine a default route and return a 400 Result
Code (ErrorBadLocation).
If a geo-route can be determined, the following return code will be returned to the VPC:
          210 = Default Route based on Geodetic match of complete civic location.


5.5.2.7.2 Tabular Routing Requirements
The ERDB shall have the ability to maintain default routing ERTs and ESNs for Postal Zone,
Community, County and State. The ERDB operator will coordinate with the 9-1-1 Authority to
build these default routes. If default routes are not built for certain areas, the ERDB shall return
Result Code 400 (ErrorBadLocation) to the VPC.
If the 9-1-1 Authority has chosen to tabular default route, the ERDB will match postal zone,
community, county and state from the civic location to default table entries for postal zone,
community, county, and state. The following table describes how the data elements from the civic
location are used to determine the default route.


                                Table 5-1 Tabular Routing using Civic Elements

                 Civic Location Data Elements
                                                                          Tabular Routing Record             Return
        Postal          Postal              County           State           Used for Routing                Code
        Zone          Community
      Found 12       found               found 13          found          Postal Zone + City +               211
                                                                          County + State
      Found          not found           found             found          Postal Zone + County +             212
                                                                          State
      Found          not found           not found         found          Postal Zone + State                213
      Found          not found           not found         not            Return Error                       400
                                                           found
      not      found                     found             found          City + County + State              214
      found
      or empty
      not      not found                 found             found          County + State                     215
      found or

12 Data specified as found means that an entry has been found in the Tabular Routing tables that matches the value from the Civic
Location.
13 If county is not supplied as part of the Civic Location it should be looked up using Postal Zone (if supplied) or Postal Community

and State.


Version 2, August 11, 2010                                                                          Page 78 of 247
                                                              NENA Interim VoIP Architecture for
                                                              Enhanced 9-1-1 Services (i2)
                                                              NENA 08-001 v2, August 11, 2010


               Civic Location Data Elements
                                                           Tabular Routing Record        Return
      Postal        Postal           County      State        Used for Routing           Code
      Zone        Community
    empty
    not          not found        not found    found       State                         216
    found or
    empty
    not          not found        not found    not         Return Error                  400
    found or                                   found
    empty


5.5.2.7.3 Example Tabular Default Routing Records
The following table presents a few example entries of tabular default routing records.
                              Table 5-2 Tabular Default Routing Records

     Postal Zone              City                County            State            ESN
    76148            Fort Worth               Tarrant              TX            00002
    76148            Haltom City              Tarrant              TX            00003
    76148            Watauga                  Tarrant              TX            00004
    76148                                     Tarrant              TX            00001
    76148                                                          TX            00099
                     Fort Worth               Tarrant              TX            00007
                                              Tarrant              TX            00001
                                                                   TX            00900
                     Denton                   Denton               TX            00101
   Note – there are no zip codes that cross counties in the USPS data



5.5.2.7.4 Example Addresses and Routing Decisions
                      Table 5-3 Example Addresses and Routing Decisions

                                                                        Return
    Civic Location                Routed On                                         ESN
                                                                        Code
    333 Bad Street                Postal Zone, City, County and
                                                                        211         00004
    Watauga, TX 76148             State
    333 Bad Street
                                  Postal Zone, County and State         212         00001
    Keller, TX 76148
    333 Bad Street
                                  Postal Zone and State                 213         00099
    Bad City, TX 76148
    333 Bad Street                City, County and State                214         00101

Version 2, August 11, 2010                                                       Page 79 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


    Denton, TX 76148
    333 Bad Street
                                                                    400
    Ardmore, OK 76148
    333 Bad Street
                               City, County and State               214            00007
    Fort Worth, TX
    333 Bad Street
                               County and State                     215            00001
    Keller, TX
    333 Bad Street
                               State                                216            00900
    Austin, TX


The following table illustrates all of the ways that the ERDB can determine routing based on the data
submitted in the erdbRequest:


                                       Table 5-4 ERDB Routing
                                                                              Data in Response
Data in Request                  ERDB Processing
                                                                          Result
                      MSAG        GeoCode            Routing                                    GeoCoded
 Civic      Geo                                                           Code      MSAG
                      found        found             Method                                     Location
   Y         N      Y            n/a              MSAG               201            Y           N
                                                                     210
   Y         N      N            Y                Default Geo                       N           Y
                                                                     211, 212,
                                                                     213, 214,
                                                                     215, 216*
   Y         N      N            N                Default Tabular                   N           N



   Y         Y      Y            n/a              MSAG               201            Y           N
   Y         Y      N            n/a              Geo                200            N           N
   N         Y      n/a          n/a              Geo                200            N           N
   N         N      n/a          n/a              Error Returned     401            N           N

Note: The order of items in this table does not imply that the ERDB will always attempt to geo-route
before attempting to tabular-route. The 9-1-1 Authority may choose to do tabular routing instead of
(or before) Geo-routing when a Civic Address that is not MSAG-valid is presented.
* Note – an address may also be determined to be not in the serving area in which case the ERDB
will return 562.




Version 2, August 11, 2010                                                     Page 80 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010


5.5.3      Authentication and Authorization

5.5.3.1 Data Management
The ERDB shall be able to authenticate the sources from which it receives source data for inclusion
in the ERDB. Based on the credentials of the source, the ERDB shall control the source’s access to
view, enter, and modify information in the ERDB.

5.5.3.2 Routing Queries
The ERDB shall support the capability to authenticate the entities from which it is allowed to receive
routing queries. Based on the credentials of the entity from which a routing query is received, the
ERDB shall support the capability to control the access of the entity to routing information in the
ERDB.

5.5.4      Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.5.5      Reliability and Availability
The ERDB shall be available to support routing queries with a reliability of 99.999%.

5.6       VoIP Position Center (VPC)
This section provides the high-level functional requirements for the VPC. The main functions of the
VPC are to:
      •    Support the routing of emergency calls originated by VoIP customers to the appropriate
           PSAP by providing critical routing information to the Call Server/Proxy;
      •    Deliver caller location, callback number, and subscriber name information in response to
           queries from ALI databases.

5.6.1      Support for Emergency Call Routing
There are a number of capabilities required of the VPC to support its role in providing routing
information to the Call Server/Proxy to support the routing of VoIP emergency calls. The VPC must
be able to process routing requests from a Call Server/Proxy, and if necessary, interact with a LIS to
obtain the caller’s location information. The VPC must use the location information, obtained from
the routing request or from the LIS, to generate a routing query to an ERDB to obtain routing
information associated with the caller’s location information. The VPC must then use this
information to generate a response to the Call Server/Proxy’s routing request. In addition, the VPC
will have to support contingency/default routing under certain failure scenarios. The following
subsections describe the functionality required of the VPC to support each of these aspects of VoIP
emergency call routing.


Version 2, August 11, 2010                                                   Page 81 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


5.6.1.1 Processing of Routing Requests from the Call Server/Proxy
The VPC shall be capable of receiving and processing a routing request from a Call Server/Proxy,
over a v2 interface that contains the following information:
   •    Identification of the entity that is requesting emergency call routing, including a 24x7
        number/address that can be used to reach that entity and the host ID associated with that
        entity;
    • An identifier that can be used to uniquely identify the call/transaction at the Call
        Server/Proxy;
    • An E.164 callback number that can be used by the PSAP to reach the call originator, if
        available;
    • Customer Name information, if available;
    • A Location Information Element (LIE) containing either a PIDF-LO or a Location Key to
        support interactions with an LIS to obtain the PIDF-LO.
    • An identifier for the caller’s Voice Service Provider, if available
In addition, the VPC shall be capable of processing the following optional information in a routing
request from a Call Server/Proxy:
   •   A Date Time Stamp indicating the UTC date and time the message was sent;
   •   An identifier for the destination VPC;
   •   An identifier inserted by the originating network that may be used by a LIS to validate that
       the received Location Key belongs to the originating network.
The VPC shall support the capability to authenticate the entities from which it is allowed to receive
routing requests.
Based on the credentials of the entity from which a routing request is received, the VPC shall
support the capability to control the access of the entity to routing information accessible by the
VPC.

5.6.1.2 Generation of Queries to LIS to Obtain Location Information
If the VPC does not receive a PIDF-LO in the LIE of the routing request from the Call Server/Proxy,
the VPC may query an LIS for caller location information, based on agreements between the VPC
provider, the LIS provider, and the VSP.
The details of the v3 interface used by the VPC to query a LIS for location information will be
specified in a future issue of this specification.

5.6.1.3 Generation of Routing Queries to the ERDB
Once the VPC receives an LIE containing caller location information, the VPC shall query an ERDB
to obtain routing data for the call. The VPC shall identify the appropriate ERDB to which to direct
the routing query by accessing discovery data that identifies the URL of the ERDB(s) that serves the
emergency caller’s location. If the VPC has received caller location information consisting of a


Version 2, August 11, 2010                                                   Page 82 of 247
                                                                         NENA Interim VoIP Architecture for
                                                                         Enhanced 9-1-1 Services (i2)
                                                                         NENA 08-001 v2, August 11, 2010


PIDF-LO document that contains more than one tuple 14, where each tuple contains a status element
with a geopriv location element, the VPC shall select the first tuple (i.e., the tuple containing the
highest priority location) as the basis for ERDB discovery. The VPC shall select the first piece of
information in the first tuple as the basis for discovering the ERDB. (See Section 3.9 for a detailed
description of the ERDB discovery mechanism).
Having identified the ERDB to which to direct the routing query, the VPC shall formulate a query
that contains the following information:
    •   A Message ID that will identify the message and allow for correlation of the query and the
        response;
    • The identifier of the node requesting the routing information (e.g., the VPC);
    • A civic location, a geodetic location, or both a civic location and a geo location.
Note that the VPC shall use the first location-info element to populate the routing query. If the
location information contains a geodetic location, and the coordinate system associated with that geo
location is something other than WGS84, the VPC shall convert the geodetic location to WGS84
[35] prior to sending it to the ERDB in the routing query.
In addition to the information identified above, the VPC may also include the following information
in the routing query to the ERDB:
    •    A Date Time Stamp indicating the UTC date and time that the message was sent;
    •    Identification of the ERDB from which routing information is being requested.

5.6.1.4 Processing of Routing Responses from the ERDB
The VPC shall be capable of processing a routing response from the ERDB that contains the
following information:
    •    A Message ID that allows for correlation of the query and the response;
    •    The identity of the node directly responding to routing query sent by the VPC;
    •    An ERT comprised of:
         o The Selective Routing Identifier associated with the caller’s location;
         o The routing ESN associated with the caller’s location;
         o The NPA that is associated with the outgoing route to the Selective Router appropriate
             for the caller’s location;
    •    The administrative ESN associated with the caller’s location (if present in the routing data at
         the ERDB);
    •    The CRN that identifies the 24x7 E.164 number of the alternate PSAP to which emergency
         calls should be routed under various abnormal conditions, if present in the routing data at the
         ERDB. (See Section 3.7 for further discussion of contingency/default routing procedures);


14 Please refer to [18] for recommended methods to construct a routable PIDF-LO document.


Version 2, August 11, 2010                                                                  Page 83 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   •    An indication of whether the ERDB was successful in providing routing information or the
        ERDB invoked default routing, and the basis on which the routing information was
        determined (i.e., a civic location or a geodetic location);
    • The MSAG-valid format of the civic address provided by the VPC in the routing query
    • The geo-coded location used in default routing (if geodetic default routing was applied at the
        ERDB);
    • A VPC Identifier that identifies the VPC that initiated the query;
    • A Date Time Stamp that indicates the UTC date and time that the message was sent;
    • An identification of the ERDB that was the original source of the routing information (which
        may or may not be the same as the ERDB that is directly connected to the querying VPC).
Upon receiving the response message from the ERDB, the VPC shall use the Selective Routing
Identifier, routing ESN, and NPA contained in the response message to identify the appropriate pool
of ESQKs for the call. From this pool of ESQKs, the VPC shall select an available ESQK value to
associate with the call. The VPC shall also set a guard timer once the ESQK has been associated
with the call. The recommended value for the guard timer is 8 hours in duration but can be settable
to an appropriate value based on statistical data by the VPC operator. The length of the guard timer
will affect the size of the ESQK pool. The VPC shall maintain an association between the ESQK and
the other call-related information (e.g., callback number, subscriber name, location, Provider
information) until it either receives an indication from the Call Server/Proxy that the call has
terminated or the guard timer expires (whichever occurs first), at which point the ESQK value will
be released.
The VPC shall hold one ESQK value within each pool in reserve to be used when there are no other
ESQK values within the pool available for association with an emergency call request. The VPC
shall associate this reserved (i.e., default) value with all new emergency call requests that require an
ESQK from a particular pool until such time as another ESQK value within that pool becomes
available. When a default ESQK is allocated to multiple simultaneous calls, the VPC will not be able
to provide call-related information to the ALI system.
As described in Section 3.3.9, the VPC may, optionally, be responsible for translating the Selective
Routing Identifier, routing ESN and NPA (which make up the ERT) received from the ERDB to an
ESGWRI. To support the ESGWRI translation function, the VPC will need to establish a
relationship with the ESGW operators whose systems interconnect with VPC customer systems (i.e.,
Call Server/Proxies). (See Section 7 for further discussion of Roles and Responsibilities). For each
ESGW, the VPC shall store mappings between Selective Routing Identifiers/NPAs/routing ESNs
and ESGWRI values. The VPC will have to have some knowledge about the routing logic supported
by each Call Server/Proxy it serves so that it will know which ESGWRI (i.e., associated with which
ESGW) it should return. Implicit in this arrangement, is the need for each ESGW’s ESGWRI values
to be unique. Otherwise, upon receiving the ESGWRI from the VPC, the Call Server/Proxy will not
know to which ESGW the call should be routed (if the Call Server/Proxy interconnects with multiple
ESGW operators’ systems).



Version 2, August 11, 2010                                                   Page 84 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


NOTE: If the PSAP does not support dedicated trunks and E9-1-1 facilities, emergency calls will be
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the ERDB response will
indicate success, but the only routing information provided will be the CRN (i.e., Selective Routing
Identifier, routing ESN, NPA will not be in the response).

5.6.1.5 Generation of Responses to Routing Requests from a Call Server/Proxy
Once the VPC has received the routing data from the ERDB, determined the ESQK value for the call
and optionally performed the ERT-to-ESGWRI translation, it shall prepare a response to the routing
request it received. Under normal conditions, this response message shall contain the following
information:
   •    The identifier of the responding VPC;
   •    An identifier that uniquely identifies the call at the Call Server/Proxy;
   •    The ESQK allocated by the VPC to the call;
   •    The CRN received in the ERDB response to be populated in the LRO parameter;
   •    An indication of whether or not the VPC was successful in providing the requested routing
        information, and the basis for determining the routing information (i.e., routing information
        based on civic or geodetic information, obtained from the routing request or via a query to
        the LIS);
    • If the VPC is responsible for performing ERT-to-ESGWRI translation, the routing response
        returned to the Call Server/Proxy shall also contain the ESGWRI;
    • If the VPC is not responsible for performing the ERT-to-ESGWRI translation, the routing
        response returned to the Call Server/Proxy shall also contain an ERT containing the Selective
        Routing Identifier, routing ESN, and NPA received in the ERDB response.
In addition, the VPC may also include the following optional information in the routing response to
the Call Server/Proxy:
    • A Date Time Stamp indicating the UTC date and time that the message was sent;
    • The identifier of the entity that requested emergency call routing.
NOTE: If the PSAP does not support dedicated trunks and E9-1-1 facilities, emergency calls will be
routed to the PSAP via the PSTN, using a 24x7 E.164 number. In that case, the VPC response will
indicate success, but the only routing information provided will be the CRN (i.e., ESQK,
ERT/ESGWRI will not be in the response).

5.6.1.6 Release of ESQKs
To minimize the risk of running out of ESQKs, the i2 Solution calls for a disconnect indication to be
sent to the VPC when a call is released, to enable the VPC to release ESQKs that are no longer in
use. This is accomplished by having the Call Server/Proxy send a call termination message to the
VPC at the conclusion of an emergency call. The VPC shall be capable of receiving a call
termination message that contains the following information:
   •   Identification of the routing node directly adjacent to the VPC;


Version 2, August 11, 2010                                                 Page 85 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   •    An identifier that uniquely identifies the call at the Call Server;
   •    The ESQK that was allocated by the VPC for the emergency call (i.e., the ESQK value that
        can now be returned to the ESQK pool at the VPC);
    • The identifier of the ESGW that was used to direct the call to the Selective Router, if
        available.
In addition, the VPC shall be capable of receiving and processing the following information, if
provided in the call termination message from the Call Server/Proxy:
    • A Date Time Stamp indicating the UTC date and time the message was sent;
    • The identifier of the VPC.
Upon receiving a call termination message, the VPC shall return the ESQK value identified in the
message to the pool of available ESQKs, and shall respond by sending a call termination
acknowledgment message that contains the identifier of the VPC and an identifier that uniquely
identifies the call at the routing element that sent the termination message. The VPC may also
include a Date Time Stamp in the acknowledgement message, indicating the UTC date and time the
message was sent.

5.6.1.7 Support for Contingency/Default Routing
There are a number of errors or abnormal conditions (e.g., failures) that may occur in the process of
routing emergency calls originated by VoIP users to the appropriate Selective Router in the
Emergency Service Provider’s network. This section describes abnormal conditions that might be
detected by the VPC, and describes the actions that should be taken by the VPC under these
conditions.
One type of error that may be detected at the VPC involves problems with the structure or content of
the routing request sent to the VPC by the Call Server/Proxy, or queries from the VPC to the ERDB
or LIS. These error scenarios include the following:
   •   The VPC receives a badly structured routing request from the Call Server/Proxy (i.e., the
       request message cannot be parsed or is malformed);
   •   The routing request from the Call Server/Proxy contains neither a Location Key nor a PIDF-
       LO;
   •   The VPC receives a PIDF-LO in the routing request from the Call Server/Proxy, but it cannot
       determine, based on the received location, which ERDB to query for the routing data;
   •   The VPC receives a PIDF-LO in the routing request from the Call Server/Proxy, but when it
       uses it to query the ERDB for routing data, it receives either an error response or no response
       from the ERDB;
   •   The VPC receives a Location Key in the routing request from the Call Server/ Proxy, but it
       cannot determine where to send the location query (i.e., it cannot determine the appropriate
       LIS);




Version 2, August 11, 2010                                                  Page 86 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   •    The VPC receives a Location Key in the routing request from the Call Server/ Proxy, and is
        unable to successfully retrieve a PIDF-LO from the LIS (i.e., it receives an error response or
        no response from the LIS).
In all of these scenarios, the VPC is unable to successfully obtain routing data from the ERDB and
provide it in a response to the Call Server/Proxy.
If the VPC is unable to successfully obtain routing data from the ERDB and provide it in a response
to the Call Server/Proxy, the VPC shall send a response message to the Call Server/ Proxy that
indicates the nature of the error that occurred. The message may also include a default routing
number (i.e., a 24x7 number associated with a call center), as determined based on prior agreements
between the VPC provider, the VoIP Service Provider, and the call center to which calls are to be
default-routed. (The default routing number will be populated in the Last Routing Option parameter
of the response message).
If a VPC is responsible for performing the ERT-to-ESGWRI translation, but it is unable to
successfully perform this translation for a specific ERT provided by the ERDB, the VPC shall send a
response message to the Call Server/Proxy that provides default routing information (consisting of a
CRN, if one was returned by the ERDB) in an LRO. It is not recommended that the ESQK be
included in the response to the Call Server since the VPC could not determine an ESGWRI.
Another type of abnormal condition that might be encountered at the VPC is related to a lack of
resources at the VPC. As described previously, one of the roles of the VPC is assigning an ESQK to
an emergency call from the appropriate ESQK pool that is associated with the Selective Routing
Identifier/routing ESN/NPA received from the ERDB. It is possible, in certain situations, for the
VPC to successfully receive routing data from the ERDB, but have no ESQKs available from the
applicable pool (other than a default ESQK) to associate with the specific call instance. The ESQK
exhaust could be caused by an unusually large number of calls being originated from a particular
geographic area, or due to some error in the allocation of the ESQK pool or in the de-allocation
process. If the VPC successfully receives routing data from the ERDB, but does not have an ESQK
available from the pool associated with the Selective Routing Identifier/routing ESN/NPA provided
in the ERDB response, the VPC shall return a routing response message to the Call Server/Proxy
that contains the reserved (i.e., default) ESQK value for the pool, along with either the ESGWRI (if
the VPC performed the ERT-to-ESGWRI translation) or the Selective Routing Identifier, routing
ESN and NPA (if the VPC did not perform the ERT-to-ESGWRI), and the CRN provided in the
response from the ERDB. (The CRN will be populated in the Last Routing Option parameter of the
response message).
A potential error scenario that could be encountered at the VPC related to the release of ESQKs is
the receipt of a call termination message containing an ESQK value that is not in use. If such an
error occurs, it is desirable that the VPC log the error and make a maintenance count.

5.6.2   Delivery of Location Information
As described above, the VPC will play an important role in delivering call and location-related
information for VoIP emergency calls to the ALI database for subsequent delivery to the PSAP to

Version 2, August 11, 2010                                                  Page 87 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


which the emergency call was routed. This will require the VPC to be capable of processing location
information requests from an authenticated, authorized ALI database, and providing the call and
location-related information associated with an identified call instance in response.
The VPC shall store call and location-related information about an emergency call at least until this
information is delivered to the ALI database. In particular, the VPC shall store the location
information provided to the ERDB in a routing query, and MSAG valid civic address information if
included in an ERDB response. If the VPC receives an indication from the ERDB that default
routing was applied, the VPC shall store the default location information (i.e., civic or geo-coded
location) received from the ERDB and return it to the PSAP when queried over the v-E2 interface.
For purposes of tracking and troubleshooting, it is desirable that the VPC retain archival storage for
call and location-related data after an emergency call is released, for a configurable period of time, to
be negotiated with the PSAPs served by the VPC. The VPC should retain, for example, a record of
the callback information, subscriber name, the allocated ESQK and the date/time it was allocated (to
support searching for information related to a particular call instance), location information used for
determining routing, VSP identification and ESGW identification information, the routing
information received from the ERDB and used for routing the call, and identification of the ERDB
that provided the routing information.
To assist PSAPs in troubleshooting, the VPC shall support a user interface that will allow an
authorized agent of the VPC operator to search for and view call and location-related data for any
call instance associated with a given ESQK in a given time interval.

5.6.2.1 Processing Location Queries
The VPC may receive location queries from one or more ALI databases. The VPC must be able to
identify and authenticate the entities from which it receives these queries to ensure that information
is only provided to those entities that are entitled to receive it. Therefore, when the VPC receives a
properly constructed Emergency Services Positioning Request (ESPOSREQ) message (as described
in Section 6.11) from an ALI DB, the VPC shall first determine whether the requesting entity is
authorized to access emergency call and location-related data. If the requesting entity is authorized,
the VPC shall use the ESQK contained in the Emergency Services Routing Key parameter of the
ESPOSREQ message to identify the call instance, and to look up the associated call and location-
related information stored at the VPC.

5.6.2.2 Generating Responses to Location Queries

5.6.2.2.1 Successful Responses
If the VPC can successfully obtain the call and location-related data associated with the call instance
identified by the ESQK in the ESPOSREQ message, the VPC shall construct an Emergency Services
Positioning Request Response (esposreq) message and send it to the ALI database identified by the
ESMEIdentification parameter in the received ESPOSREQ message. The esposreq message shall
contain the following key pieces of information:

Version 2, August 11, 2010                                                   Page 88 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   •   The ESMEIdentification coded with the identification of the ALI Database that initiated the
       query.
   • A PositionResult.
   • One or both of:
       - Position information consisting of latitude and longitude as WSG84 information, and
           altitude in meters, if available. If present, a Position Source will also be provided to
           identify the method used to determine the location information.
       - A Location Description (consisting of detailed street address information), if the location
           information associated with the call instance is populated with a civic location.
   • A Callback Number, if available in the information associated with the call instance.
   • A subscriber name (populated in the Location Description), if available in the information
       associated with the call instance.
   • An Emergency Services Routing Key, populated with the ESQK received in the ESPOSREQ.
   • An ESQK Date and Time Stamp.
   • A CompanyID, if the data associated with the call instance includes the NENA ID for the
       VSP. If the NENA ID for the VSP is not available then the NENA ID of the entity at the
       other end of the v2 interface is provided.
See Section 6.11 for further details related to the coding of the esposreq message.
The VPC shall include at most one civic and one geodetic location in the esposreq message. If the
VPC receives civic or geo-coded location information in the response from the ERDB, this
information will take precedence over civic or geo-location information included by the VPC in the
erdbRequest message. Specifically, if the VPC receives an msagvalidciviclocation parameter in the
erdbResponse message, it will use the msagvalidcivicaddress to populate the civic location
information in the esposreq message. If the VPC receives geo-coded location information in the
erdbResponse message, it will use the geo-coded location information to populate the position
information in the esposreq message along with the invalid civic address information. Otherwise,
the VPC will populate the civic and/or position information in the esposreq with the location
information included by the VPC in the erdbRequest message.

5.6.2.2.2 Error Responses
The VPC may be unable to provide location information in response to a request from the ALI
database due to the following conditions:
   •   The VPC experiences a system failure resulting in the inability to look up the information;
   •   The requesting entity is not authorized to access location data for emergency calls;
   •   Unexpected data is received in the location request;
   •   The ESQK identified in the request does not have any stored data associated with it;
   •   A default ESQK was allocated to multiple call instances.




Version 2, August 11, 2010                                                Page 89 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


If one of the above conditions occurs, the VPC shall report the error condition to the requesting ALI
database by returning an Emergency Positioning Request Return Error message with the appropriate
Error Code value. See Section 6.11 for further details related to the coding of this message.
If the VPC is receives a badly constructed query from an authenticated entity, the VPC shall report
the problem by returning an Emergency Positioning Response Reject message containing the
appropriate Problem Code. See Section 6.11 for further details related to the coding of this message.

5.6.3      Authentication and Authorization
The VPC shall authenticate the entities from which it receives queries to ensure that information is
only provided to those entities that are entitled to receive it.
The VPC may implement authorization policies to ensure that requesters only receive what they are
entitled to.

5.6.4      Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.6.5      Reliability and Availability
The VPC application shall be highly reliable and available. It is an objective that the VPC be
available to a querying element (e.g., Call Server/Proxy, ALI Database) at a service availability level
of 99.999%.

5.7       Validation Data Base (VDB)
This section provides the high-level functional requirements for the VDB. The main functions of the
VDB are to:
      •Store MSAG validation data (MSAG valid civic addresses) for a given area – it is expected
       that there will be multiple VDBs supported by the various entities and each contains a
       mechanism to validate data to conform to the MSAG for the given jurisdiction.
    • Perform MSAG Validation of a Civic Address request.
The legally designated 9-1-1 authority for the jurisdiction may provide this service, or it may be
delegated to an authorized entity.

5.7.1      Storage of MSAG Validation
The VDB shall support civic address information as defined by local MSAG(s) for a given region.
All modification requests to data stored on the VDB shall be logged.




Version 2, August 11, 2010                                                  Page 90 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


5.7.1.1 Data Management
The VDB database management shall allow for multiple agents to simultaneously perform database
maintenance (data object creation, update, deletion).
The VDB shall support uploads of MSAG data from authorized sources.
The database structure shall be capable of supporting 24x7 real-time queries keyed to various
elements of a civic address.

5.7.1.2 Data Management Authentication and Authorization
The VDB shall be able to authenticate the entities from which it receives source data for inclusion in
the VDB.
Based on the credentials of the entity, the VDB shall control the entity’s access to view, enter, and
modify information in the VDB.

5.7.1.3 Data Integrity
The VDB database management shall enforce consistency of civic address information to MSAG
format. (NOTE: This is even more critical since a postal address will be presented and it should be
known at this time if the address can be formatted into a MSAG address since the ERDB will need
to do this conversion when the call arrives at the VPC).
The VDB shall maintain an audit trail of changes in the database.

5.7.2   Perform Validation
The validation interface is described in Section 6.11.
The VDB shall be able to process and respond to validation request messages.
The request shall use a standard message format that can be sent to any VDB (e.g. an XML message
with the same elements) for any jurisdiction/region.
The elements/fields of the message shall align with NENA 02-010 [11] data requirements, i.e. use
already supported attribute names, when applicable.
Error responses shall be provided when validation fails.
Error responses may contain suggestions for alternative addresses. The request could contain either
postal or jurisdictional addresses but the response will return a postal address and may return a
jurisdictional address.
Error responses shall provide information that enables a requestor to determine the type of error that
occurred.
As a VDB option, the VDB may geo-code the validated address and return it in the response. The
data needed to perform the geocoding must be approved by a public safety authority.


Version 2, August 11, 2010                                                   Page 91 of 247
                                                                          NENA Interim VoIP Architecture for
                                                                          Enhanced 9-1-1 Services (i2)
                                                                          NENA 08-001 v2, August 11, 2010


The VDB must be able to accept postal addresses and be able to return jurisdictionally accurate
address information (including the correct community name and county for the 9-1-1 jurisdiction).
The VDB must be able to accept a civic address (including the correct community name for the 9-1-
1 jurisdiction) and be able to validate it. The VDB may also include postal address information
(postal community and postal code) in the response. The VDB may support the option to include
geodetic location information (latitude and longitude in WGS84 [35] format) in the response to the
location validation query.
The VDB shall provide a web services interface for civic address validation.
The VDB shall validate civic addresses submitted in the validation request message against both the
MSAG and, optionally, the country-specific Postal Service dataset 15. If an address resolves to one
and only one MSAG entry, the address is considered to be valid. If the address resolves to zero
MSAG entries or more than one MSAG entry, the address is considered to be invalid.
The VDB shall maintain translations from Postal Community Name to MSAG Community Name
and vice-versa.
The VDB may maintain translations from Postal County Name to MSAG County ID.
The VDB shall maintain translations from the country-specific Postal Service abbreviations to
MSAG abbreviations and vice-versa. MSAG abbreviations may differ among communities and
counties.
The VDB shall ignore variations in upper and lower case to perform address searches (i.e. perform
case-insensitive searches).
The VDB shall strip punctuation and translate non-standard abbreviations into standard country-
specific Postal Service abbreviations before performing any database search (see Section 9.2 – Rules
for Address Abbreviation).
The VDB may use a database or service based on postal service data to determine whether an
address is a valid postal address. The postal service search may provide other helpful information to
assist in the MSAG address validation (such as County Name).
The VDB may accept and parse into the appropriate fields malformed data such as HouseNum and
StreetName entered into the same field or directionals embedded in the StreetName field before
validating the submitted Address. The response will be a well-formed address (or addresses).
The VDB shall always return pre/post directional and suffixes in the appropriate fields in the
validateResponse message.
The VDB shall implement the v7 interface documented in Section 6.8.



15 All translations and searches done by the VDB to determine if an address is MSAG-valid must also be done by the ERDB when a
call is being routed. This means that all data managed by the VDB must also reside in the ERDB and that any translations or data
conversions done by the VDB must also be done by the ERDB.


Version 2, August 11, 2010                                                                      Page 92 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


If a submitted address cannot be automatically validated by the VDB, the VDB operator shall
research these addresses and either create or update the appropriate Postal to MSAG translations.
The VDB operator shall provide an email address (e.g., discrepancy@VDBdomain.com) that the LIS
operator could use to send the unvalidated address to the VDB provider for further research. If the
address still cannot be validated, the VDB shall return a more detailed explanation of why the
address is invalid. Note: Resolution of discrepancies may require coordination with the appropriate
ERDB providers and/or MSAG Operators.

5.7.2.1 Authentication and Authorization of Validation Queries
The VDB may authenticate the entities from which it is allowed to receive validation queries.

5.7.3    Authentication and Authorization

5.7.3.1 Data Management
The VDB shall be able to authenticate the entities from which it receives source data for inclusion in
the VDB.
Based on the credentials of the entity, the VDB shall control the entity’s access to view, enter, and
modify information in the VDB.

5.7.3.2 Validation Queries
The VDB may authenticate the entities from which it is allowed to receive validation queries.
Based on the credentials of the entity from which a query is received, the VDB may restrict the
ability of the entity to some validation queries e.g., it may be able to validate locations in some
regions but not others.

5.7.4    Performance
No normative performance requirements are specified in this document.

5.7.5    Reliability and Availability
The VDB shall be available to support validation requests with an availability of 99.9%.

5.8     Location Information Server (LIS)
The LIS sits within or at the edge of the access network and invokes applicable positioning
technologies enabling consistent and reliable location information to be attributable to an answerable
source. It may support a simple request/response message that allows the VPC to obtain the location
of a client without the client user identity being required. It may allow clients to request their
location directly. The LIS must support at least one of the functions but it is recommended that the
LIS support both functions. The LIS supports a location information credentialing system that
provides assurances of the applicability, currency, and identity of the source of the location


Version 2, August 11, 2010                                                    Page 93 of 247
                                                                               NENA Interim VoIP Architecture for
                                                                               Enhanced 9-1-1 Services (i2)
                                                                               NENA 08-001 v2, August 11, 2010


information. Precisely where a LIS resides in the network, how it determines location and the type of
location (geodetic or civic) that it returns will be dependent on a number of factors, among these are:
     •    The nature of the connection used by the client. That is, whether it is a residential broadband
          connection, an enterprise IP switch connected client, a wireless client connecting via a
          campus wireless LAN, a client connecting to a wide area broadband wireless connection, etc.
     •    Legacy circumstances. That is, the extent to which the clients, access devices, and switches
          have native support for location delivery versus the need to overlay a solution for location
          determination on existing infrastructure.
     •    The type of location information and accuracy required for a given target environment. For
          example, are static civic addresses with sufficient geodetic accuracy for routing sufficient or
          is a more accurate geodetic location required in the absence of a civic address?

5.8.1     Detailed LIS Requirements
The LIS is a critical component in the support of emergency services for VoIP. The location of the
caller is critical both in terms of routing the call to the correct PSAP and in terms of emergency
service dispatch to the emergency location. In providing location, however, there are a number of
important attributes that should be associated with both the location information and the manner in
which it is provided. These are summarized in the following list:
     1. Where the client must be aware of the LIS, the LIS shall support consistent mechanisms by
        which it can be "discovered" by client devices in the access network in order that location
        information and location keys can be obtained.
     2. When providing a client key or signed location, the LIS shall support an expiry mechanism
        by which it will delete its record of a client device within an agreed period of time unless it is
        renewed by the client 16.
     3. The LIS shall support a mechanism by which location can be provided to a requesting client
        device in the served access using a standardized and open protocol such that all clients can
        assume a consistent mechanism.
     4. Location shall be coded in a standardized fashion such that systems and devices which utilize
        delivered location will be able to do so in a consistent fashion.
     5. The location information shall be able to be provided with associated "credentials" to ensure
        the applicability of the location to the device.
            a. The credentials should reliably identify the source of the location (i.e. the LIS
                operational identity).
            b. The credentials should identify a unique client ID that the location is associated with.
            c. The credentials should identify a specific time after which the location should no
                longer be considered valid.
     6. The LIS shall support a mechanism whereby a client-provided location can be augmented
        with location credentials by the LIS if that client-provided location can be determined by the

16 There is currently limited Standards support for signing location but it is expected that more support will available by the time the
i2 solution is deployed.


Version 2, August 11, 2010                                                                            Page 94 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


       LIS to be representative of the client’s actual location (e.g. a more accurate client-provided
       GPS fix may be provided with credentials if the LIS can confirm the location falls within
       known boundaries of the client’s actual location).
   7. The LIS shall support the creation and delivery of a "Location Key" at the request of the
       client device, which can be used by the client or other network elements to query that client’s
       location information directly from the LIS. The details of the location key will be defined in
       a future version of this specification.
   8. The LIS shall support a standardized and open communications protocol to support the query
       of location information using a location key such that querying network elements can assume
       a consistent mechanism for doing so.
   9. The LIS shall support encrypted communications between itself and the client device such
       that exchanges of location information and location keys remain private.
   10. The LIS shall enforce authentication on querying network entities such that they must have
       permission to query the location of a device using a location key (e.g. the querying entity can
       present emergency service credentials).
   11. The LIS shall support encrypted communications between itself and querying network
       elements such that exchanges of location information on client IDs remains concealed.
   12. The LIS shall support a mechanism for validation of civic location information, as described
       Section 6.8.
   13. The LIS shall be able to support periodic revalidation of civic location information.

5.8.2   LIS Query Protocol and Location Information Format
In order for nomadic devices to be able to obtain information reliably and transparently regardless of
the IP access network that they "roam" into, it is necessary that there be a consistent means of
discovering and communicating with the LIS functional entity within the access network. To support
roaming across national network boundaries, it should be possible for a single VoIP client
implementation to determine location information in the same way regardless of the access network.
To facilitate this requirement, it is recommended that LIS interaction be based on a specification
from a global standards body.
The necessary functions for the location acquisition and delivery protocol to support are as follows:
   •    A discovery mechanism must be provided. This may be an explicit indication of the serving
        LIS entity identity provided, for example, by DHCP or DNS. Optionally, a broadcast and
        response message that allows a client device to find a LIS in the access network may be
        supported.
   •    A direct query to the LIS to provide location is recommended.

5.8.3   Validated Address to PIDF-LO Mapping
Table 5-5 below shows how data elements returned by the VDB would be mapped to PIDF-LO for
an emergency call. The validated data tag names shown are from the validateAddressResponse



Version 2, August 11, 2010                                                  Page 95 of 247
                                                                       NENA Interim VoIP Architecture for
                                                                       Enhanced 9-1-1 Services (i2)
                                                                       NENA 08-001 v2, August 11, 2010


returned by the v7 interface. The coordinates will be provided with WGS 84 [35] datum using
EPSG:4326 format.
                                     Table 5-5 - Validated Data Tag Names

                           Validated Address                        PIDF-LO Element
                                Element
                      HouseNum                                              HNO
                      HouseNumSuffix                                        HNS
                      PrefixDirectional                                     PRD
                      StreetName                                            RD 17
                      PostDirectional                                       POD
                      MSAGCommunity                                          A3
                      PostalCommunity                                      PCN 18
                      StateProvince                                          A1
                      CountyName                                             A2
                      PostalZipCode                                          PC
                      Country                                             Country
                      Latitude                                         gml:coordinates
                      Longitude                                        gml:coordinates
                      Elevation                                        gml:coordinates


5.8.4    Authentication and Authorization
The LIS, in the context of emergency services, must implement strong authentication mechanisms to
protect the private nature of the information it contains.
The LIS, in the context of emergency services, must implement strong authorization policies to
protect the private nature of the information it contains.

5.8.5    Performance
No normative performance requirements are specified in this document. Guidelines are provided in
Section 9.7.

5.8.6    Reliability and Availability
Since the LIS may be involved during an emergency call, the LIS emergency application shall be
highly reliable and available. It is an objective that the LIS be available to a querying element (e.g.,
the VPC for LK de-referencing) at a service availability level of 99.999%.

17 RD is defined in RFC-5139 [37] which replaces A6 defined in RFC 4119 (PIDF-LO).
18 PCN is defined in RFC-5139 [37] which updates RFC 4119 (PIDF-LO).


Version 2, August 11, 2010                                                               Page 96 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


5.9       Automatic Location Identification (ALI) Database
This section provides additional functional requirements on the existing ALI DB that shall be
implemented in support of the i2 solution.
The ALI database shall be configured with the following information associated with the ESQK:
      •The associated VPC (including identifier/address and contact information);
      •A new default VoIP Class of Service, designated as “V”
      •A default Administrative ESN to be used to identify the appropriate English Language
       Translations (ELT) for the emergency responders in the serving area identified by the ESQK.
The ALI database provider must support a v-E2 interface to the VPC and be able to use it to request
and receive location information for VoIP emergency calls. The v-E2 interface is described in
Section 6.11. The ALI database shall interpret the uses of data elements on the v-E2 interface as
described in Section 6.11.1.
These procedures may differ from the processes that would be used to receive data from a wireless
carrier’s Mobile Positioning Center (MPC).
The ALI DB shall include a NENA identifier for the VPC as the secondary Company (Data
Provider) ID sent to the PSAP in the response to its ALI query, if this information is supported on
the ALI to PSAP interface.
The ALI DB shall be capable of receiving both civic location and geodetic location over the v-E2
interface. The ALI DB shall deliver either civic or geodetic or both depending on the ALI-to-PSAP
interface supported.

5.9.1      Authentication and Authorization
No incremental authentication and authorization requirements are specified for the ALI DB in this
document.

5.9.2      Performance
No incremental performance requirements are specified for the ALI DB in this document.

5.9.3      Reliability and Availability
No incremental reliability and availability requirements are specified for the ALI DB in this
document.




Version 2, August 11, 2010                                                 Page 97 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



6     Detailed Interface Specifications
This section provides an overview of interfaces defined in this standard. This section is intended to
give the reader a better understanding of what role each of the interfaces provides and also to
provide the detailed specifications for the identified interfaces. Where applicable, XML schemas
associated with the specified interfaces can be found at the following location..
Each interface addresses a security mechanism to be used as part of the message exchange.
      The XML schema associated with this interface can be found at the following location:
                         http://www.nena.org/technical-xml-schemas

6.1    v0 – LIS to VoIP Endpoint
The detailed specification of this interface is out of scope for this document.
The v0 interface is the name given to the interface by which an end-device is informed of its location
by an entity in the access network. At the time of writing, several mechanisms are in standard track
or have reached standard status for providing location to endpoints. These include, but are not
limited to:
    1. Using DHCP to convey Geodetic information as defined in RFC 3825 [6]
    2. Using DHCP to convey Civic information as defined in RFC 4776 [7].
    3. Using LLDP-MED to convey Geodetic and/or Civic location as defined in ANSI/TIA-1057
        [25].
    4. Using HELD to request Geodetic and/or Civic location as defined in draft-ietf-geopriv-http-
        location-delivery [26].
With some mechanisms, the client-device will need to make a request to the network to obtain
location information and format the information into a PIDF-LO. With others, the location will be
delivered to the end-device pre-formatted as a PIDF-LO.
The detailed specification of this interface is out of scope for this document. However, NENA
prepared a Technical Requirement Document (TRD) 08-752 [27] and a Technical Information
Document (TID) 08-505 [28] that addresses location determination and acquisition in the IP domain.

6.2    v1 – VoIP endpoint to Call Server
The v1 interface represents the link between the client-device and a CS. It is over this link the user
establishes a call, and conveys location information. Location conveyance in call establishment is
being developed in the wider VoIP community. At present the most advanced work is in the IETF
and deals with location conveyance over SIP, (draft-ietf-sipcore-location-conveyance [12]). It is a
recommendation of the i2 architecture that the v1 interface be capable of transporting either location
or location key information regardless of the protocol being used to support the voice service. If the



Version 2, August 11, 2010                                                   Page 98 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


end point and the VSP are unable to provide a location or a location key, calls might not get routed
to the appropriate PSAP.
This interface is out of scope for the i2 solution.

6.3     v2 – Call Server/Routing Proxy/Redirect Server to VPC
This section describes the v2 interface between the VoIP CS/RP/RS and the VPC as shown in Figure
3-1. This interface provides a means for the CS/RP/RS to request emergency services routing
information from the VPC, and to inform the VPC, at call termination, when a routing/query key is
no longer required. The interface consists of four messages and these are introduced in subsequent
paragraphs. The v2 interface is XML-based.
The v2 interface is likely to need to operate in a variety of network environments, some trusted, and
some not. For this reason the HTTPS (HTTP [33] over TLS [22]) protocol using web services has
been selected as the transport mechanism for the v2 interface, as this provides strong security
mechanisms and is readily able to traverse enterprise and commercial firewalls when correctly
configured.

6.3.1     v2 Message Definitions
The v2 interface defines two sets of Request/Response messages (for a total of 4 messages). The first
message set requests and receives routing instructions. The second message set indicates that an
emergency call has concluded. The remainder of this Section details the 4 messages that make up
communication across the v2 interface.

6.3.1.1 Emergency Services Routing Request (esrRequest)
The esrRequest message is sent from the query node (CS/RP/RS) to the VPC to request routing
information and a query key. The valid parameters for the esrRequest message are included in the
following table.
                                 Table 6-1 - esrRequest Parameters
           Parameter                   Condition                            Description
source                          Mandatory                     The identifier of the node requesting
                                                              routing information directly from the
                                                              VPC.
Vsp                             Conditional                   The identifier of the caller's voice
                                                              service provider
callId*                         Mandatory                     Any identifier that can uniquely
                                                              identify the call globally.
datetimestamp                   Optional                      Date Time Stamp indicating UTC date
                                                              and time that the message was sent
callback*                       Conditional                   E.164 number that can be dialed by a
                                                              PSAP operator to reach the call

Version 2, August 11, 2010                                                 Page 99 of 247
                                                                         NENA Interim VoIP Architecture for
                                                                         Enhanced 9-1-1 Services (i2)
                                                                         NENA 08-001 v2, August 11, 2010


          Parameter                              Condition                             Description
                                                              originator
Lie                                   Mandatory               The Location Information Element.
callOrigin                            Optional                An ID inserted by the originating
                                                              network that allows LIS to validate if
                                                              the call is from the originating
                                                              network.
Vpc                            Optional                       The identifier of the destination VPC.
customer                       Conditional                    The subscriber/account name
                                                              associated with the callback number
    * In some cases the <callback> number will uniquely identify the call at the CS. In such a case,
    the <callId> parameter will contain the value of the <callback> number parameter. There is no
    formal requirement for this to be the case however, and only the value contained in the
    <callback> parameter shall be used to deliver the callback number over the v-E2 interface.

The <source> element identifies the node directly requesting emergency call routing from the VPC
over the v2 interface. It includes the source node (hostId), a NENA administered identifier (nenaId)
a 24x7 contact number (contact), and an optional uri URI (certUri) providing a link to the provider's
VESA issued certificate. The <source> must be a trusted entity of the VPC.
An example of how the <source> element is used, along with format definitions is as follows:

<source>
  <organizationName>James's cool VSP</organizationName>
  <hostId>cs34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel:17325551212/contact>
  <certUri>https://cs34.example.com/certificate.crt</certUri>
</source>



The <organizationName> is a free form text field into which the node owner may place their
company name or other label. This field is optional.
The <hostId> identifies the fully qualified domain name or IP address of the directly requesting
node. This field is mandatory.
The <nenaId> is the NENA administered company identifier ((NENA Company ID 19) of the node
requesting routing information over the V2 interface. This field is optional.
The <contact> is a telephone number by which the directly requesting node operator can be reached
24 hours a day, 7 days a week. This field is mandatory.


19 Registered NENA Company IDs are not used outside the United States.


Version 2, August 11, 2010                                                              Page 100 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010



The <certUri> provides a means of directly obtaining the VESA issued certificate for the requesting
node. This field is optional.
The <vsp> element identifies the Voice Service Provider for the call. This element is used to identify
the original VoIP service provider, in cases where the original VSP is not the same entity as the one
requesting routing information over the v2 interface. In cases where the VoIP service provider and
the entity requesting routing information are not the same, the <source> element is used to identify
the entity requesting routing information over the v2 interface and the <vsp> element is used to
identify the voice service provider. The mechanisms used to determine the VSP at routing
proxy/redirect server are for further study.

<vsp>
  <organizationName>Martin's super VSP</organizationName>
  <hostId>cs34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel:398348975439823</contact>
  <certUri>https://cs34.example.com/certificate.crt</certUri>
</vsp>



The <hostId> and <contact> elements must be provided. The <organizationName>, <nenaId> and
<certUri> fields are optional.
The <callId> element is an identifier that can be used to uniquely identify the call globally. If a
callId is received in SIP signaling, the Call Server shall use the received callId as the callId over the
v2 interface. If a callId is not received in incoming signaling, the call server/proxy shall follow the
recommended procedures as specified in RFC3261 for UA Call-ID generation.
An example of a callId received in SIP signaling:
<callId>3848276298220188511@atlanta.example.com</callId>.

The <callback> number is a tel-uri of the format “tel: 1-212-555-8215”. This identifies the E.164
number that can be dialed to reach the caller. This is the number that will be included in the callback
number field in the esposreq response message to the ALI.
<callback>tel:1-212-555-8215</callback>

The <lie> is the Location Information Element that contains location information that is used to
determine the routing and query keys to be used for the call. This parameter is mandatory, and if not
provided, the VPC must provide default routing or an error to the requesting node. If the <lie> is
present in the esrRequest, then it may contain a LocationKey, a PIDF-LO (geodetic and or Civic), or
both. The exact mechanism used to determine the routing and query keys is dependent on the
contents of the <lie>.



Version 2, August 11, 2010                                                    Page 101 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010



<lie>
  <locationKey>3c01abe092@lis.example.com</locationKey>
  <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
    entity="3c01abe092@lis.example.com">
    <tuple id="sg89ab">
     <status>
      <gp:geopriv>
        <gp:location-info>
          <gml:position>
            <gml:Point gml:id="point1" srsName="epsg:4326">
              <gml:pos>37.775 -122.422</gml:pos>
            </gml:Point>
          </gml:position>
            <cl:civilAddress>
              <cl:country>US</cl:country>
              <cl:FLR>2</cl:FLR>
            </cl:civilAddress>
        </gp:location-info>
        <gp:usage-rules>
        </gp:usage-rules>
      </gp:geopriv>
     </status>
     <timestamp>2003-06-22T20:57:29Z</timestamp>
    </tuple>
  </presence>
</lie>


The LIE example above shows both Geodetic Location and Civic address information, which is
acceptable, but in most cases it is expected that either Geodetic Location or Civic Location would be
sent in the LIE.
The <callOrigin> parameter is used by the VPC when it sends a LocationKey to the LIS over the v3
interface. The LIS is able to use this parameter to determine if the LocationKey received belongs to
the originating network. Use of this parameter is LIS implementation-specific and is subject to local
access network policy.
<callOrigin>accessNetwork.com</callOrigin>

The <datetimestamp> is the date time stamp in UTC time using ISO 8601 [44] format indicating the
time that the message was sent from the requesting node. This field is optional, but if not included,
then the VPC must maintain an accurate date and time stamp in any call event records so that an
audit trail is readily accessible.
<datetimestamp>2004-12-12T21:28:43Z</datetimestamp>
The <vpc> element identifies the VPC from which routing information is being requested.

Version 2, August 11, 2010                                                 Page 102 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010



<vpc>
  <organizationName>Specific VPC Service</organizationName>
  <hostId>cs34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel:398348975439823</contact>
  <certUri>https://cs34.example.com/certificate.crt</certUri>
</vpc>

The coding of the VPC element is the same as the coding for the source element.
The <customer> is an alphanumeric field that identifies the subscriber/account owner name
associated with the callback number in subscription data. The customer name will be included in the
<NAM> field of the Location Description parameter in the esposreq response message to the ALI.
<customer>Turin Turumbar</customer>

6.3.1.1.1 LIE PIDF-LO Routing
When the LIE contains a PIDF-LO, the VPC will perform a lookup in the ERDB, to obtain the ERT
consisting of a Selective Routing Identifier (i.e., CLLI code), a routing ESN, and an NPA, as well as
a contingency routing number (CRN) for the PSAP. Using the Selective Routing Identifier, routing
ESN, and NPA, the VPC can identify and allocate an ESQK. The ESQK, CRN, and either the ERT
or ESGWRI are subsequently returned to the Call Server/Proxy in an esrResponse message, with the
CRN being carried to the Call Server as an LRO.

6.3.1.1.2 LIE LocationKey Routing
The LocationKey provides information to the VPC on where to get the location of the caller. The
LocationKey may explicitly indicate a client-id and a LIS, say in the form or a URI, or it may be a
different form of identifier, such as callback number, that the VPC can use internally to determine a
LIS and subsequently request a location object. Having determined the LIS from the LocationKey,
the VPC then passes the LIE to the LIS and receives a LIE back, this time containing the original
LocationKey and a PIDF-LO. The VPC is then able to route based on the PIDF-LO as it did in the
Section 6.3.1.1.1.

6.3.1.1.3 esrRequest Message Format
The high-level message format for the esrRequest message is shown below:




Version 2, August 11, 2010                                                 Page 103 of 247
                                              NENA Interim VoIP Architecture for
                                              Enhanced 9-1-1 Services (i2)
                                              NENA 08-001 v2, August 11, 2010



<esrRequest xmlns="urn:nena:xml:ns:es:v2"
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
  xsi:schemaLocation="urn:nena:xml:ns:es:v2 v2.xsd">
   <vpc>
      <organizationName>Specific VPC Service</organizationName>
      <hostId>vpc.example.com</hostId>
   </vpc>
   <source>
      <organizationName>Terry's redirect proxy</organizationName>
      <hostId>rp34.example.com</hostId>
      <nenaId>nena1</nenaId>
      <contact>tel: 398348975439823</contact>
      <certUri>https://rp34.example.com/certificate.crt</certUri>
   </source>
   <vsp>
      <organizationName>Operator One's Call Server</organizationName>
      <hostId>cs98.example.com</hostId>
      <nenaId>nena2</nenaId>
      <contact>tel:15554476632</contact>
      <certUri>https://cs98.example.com/certificate.crt</certUri>
   </vsp>
   <callId>610239946019573</callId>
   <callback>610239946019573</callback>
   <lie>
      <locationKey>3c01abe092@lis.example.com</locationKey>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
       xmlns:pidf="urn:ietf:params:xml:ns:pidf"
       xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
       xmlns:gml="http://opengis.net/gml" entity="pres:user@example.com">
       <tuple id="a6fea09">
        <status>
         <gp:geopriv>
          <gp:location-info>
           <gml:position>
            <gml:Point gml:id="point1" srsName="epsg:4326">
             <gml:pos>42.5463 -73.2512</gml:pos>
            </gml:Point>
           </gml:position>
          </gp:location-info>
          <gp:usage-rules>
          </gp:usage-rules>
         </gp:geopriv>
        </status>
        <timestamp>2004-12-01T09:28:43Z</timestamp>
       </tuple>
      </presence>
   </lie>
   <callOrigin>Some arbitrary string in here</callOrigin>
   <datetimestamp>2004-12-12T21:28:43Z</datetimestamp>
   <customer>Gomer Pyle</customer>


Version 2, August 11, 2010                                   Page 104 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


</esrRequest>


6.3.1.2 Emergency Services Routing Response (esrResponse)
The esrResponse message is sent by the VPC to a routing entity (Call Server/Routing Proxy/Redirect
Server) in response to an esrRequest message. Valid parameters for the esrResponse message are
contained in the following table.
                              Table 6-2 - esrResponse Parameters

          Parameter                   Condition                          Description
vpc                           Mandatory                    The identifier of the responding VPC
callId                        Mandatory                    An identifier that uniquely identifies
                                                           the call at the Call Server
esgwri                        Conditional                  If determined by the VPC, this field
                                                           will contain the Routing Key that
                                                           allows routing of the call to the
                                                           Selective Router servicing the local
                                                           area in which the call was made.
ert                           Conditional                  The Emergency Route Tuple
                                                           comprised of the following tags used
                                                           by the receiving node to select the
                                                           appropriate ESGWRI.
         selectiveRoutingID   Conditional                  The Common Language Location
                                                           Indicator (CLLI) code associated with
                                                           the Selective Router to which the
                                                           emergency call is to be directed.
         routingESN           Conditional                  The Emergency Services Number
                                                           associated with a particular ESZ that
                                                           represents a unique combination of
                                                           Police, Fire and EMS emergency
                                                           responders.
         npa                  Conditional                  The Numbering Plan Area (NPA)
                                                           associated with the outgoing route to
                                                           the Selective Router that is appropriate
                                                           for caller’s location.
esqk                          Conditional                  The Query Key allocated by the VPC


Version 2, August 11, 2010                                              Page 105 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


         Parameter                       Condition                        Description
                                                             to uniquely identify the call within ESZ
lro                           Conditional                    The last routing option. This routing
                                                             option should only be used by the call
                                                             server or proxy as a last resort. The
                                                             actually meaning of the LRO is
                                                             different depending on what other
                                                             information is returned in response to
                                                             the query.
Result                        Mandatory                      Code indicating the reason for success
                                                             or failure to determine an ERT and
                                                             ESQK. See the next table for more
                                                             details.
datetimestamp                 Optional                       Date Time Stamp indicating UTC date
                                                             and time that the message was sent.
destination                   Optional                       The identifier of the routing node
                                                             immediately adjacent to the VPC.

The <vpc> element identifies the VPC.

<vpc>
  <organizationName>Specific VPC Service</organizationName>
  <hostId>vpc34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel:398348975439823</contact>
  <certUri>https://vpc34.example.com/certificate.crt</certUri>
</vpc>


The <hosted>, <nenaId>, and <contact> fields are mandatory while the other fields of the <vpc>
element are optional.
The <destination> element identifies the node that directly requested emergency call routing
information from the VPC. It includes the source node (hostId), a NENA administered Company ID
identifier (nenaId), a 24x7 contact number (contact), and optional parameters for the organization's
name and URI (certUri) for the operator's VESA issued certificate. The <destination> must be a
trusted entity of the VPC.




Version 2, August 11, 2010                                                Page 106 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



<destination>
  <organizationName>Generic Redirect Proxys</organizationName>
  <hostId>rp34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel: 398348975439823</contact>
  <certUri>https://rp34.example.com/certificate.crt</certUri>
</destination>



The <organizationName> is a free form text field into which the node owner may place their
company name or other label. This field is optional.
The <hostId> identifies the fully qualified domain name or IP address of the directly requesting
node. This field is mandatory.
The <nenaId> is the NENA administered company identifier (NENA Company ID). This field is
mandatory.
The <callId> is an identifier that uniquely identifies the call at the requesting node.
<callId>767673678674835784587</callId>
The <esgwri> is the translation of the ERT with ESGW-specific information provided by either the
VSP or ESGW operator directly. An <esgwri> may be provided if the VPC performs the ERT-to-
ESGWRI translation and a corresponding <esqk> is provided. The ESGWRI format is as follows:
sip: 1 numberstring@esgwprovider.domain;user=phone where the “numberstring” is 10
numeric characters (e.g., nnnnnnnnnn)
The <selectiveRoutingID> contains the CLLI code of the selective router to which the call is being
routed. The CLLI code is an 11 character alphanumeric field of the form AAAABBCCDDD, where
    • AAAA represents the city/county
    • BB represents the State
    • CC represents the building or location
    • DDD represents the network.
The Selective Routing Identifier will be included in the response message if the VPC is not
responsible for performing ERT-to-ESGWRI translation. The <selectiveRoutingID> must only be
provided if a <routingESN>, <npa>, and <esqk> are also provided, and must not be provided if an
<esgwri> is provided.
The <routingESN> is a 3- to 5 digit field that uniquely identifies the ESZ in the context of an SR,
and the associated Police, Fire, and EMS emergency responders associated with that ESZ. The
<routingESN> must only be provided if a <selectiveRoutingID>, <npa>, and <esqk> are also
provided, and must not be provided if an <esgwri> is provided.
The <npa> is a 3 digit field that identifies an NPA associated with an outgoing trunk group to the
appropriate SR associated with the caller’s location. The <npa> must only be provided if a

Version 2, August 11, 2010                                                    Page 107 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


<selectiveRoutingID>, <routing ESN>, and <esqk> are also provided, and must not be provided if
an <esgwri> is provided.

<ert>
   <selectiveRoutingID>QUBCPQ00CG1</selectiveRoutingID>
   <routingESN>12345</routingESN>
   <npa>418</npa>
</ert>



The <esqk> element contains the ESQK allocated by the VPC. This key identifies an ESN for a
specific PSAP, as well as the call instance at the VPC. A valid value must be returned in this field
for the call to be successfully routed to the appropriate PSAP, and for location information to be
supplied from the VPC to the PSAP. An <esqk> must only be provided if a corresponding <esgwri>
or <ert> is also provided. The <esqk> is expected to be a 10-digit North American Numbering Plan
Number. More information on ESQKs can be found in Interim p-ANI Administration Guidelines
(Rev. December 5, 2005) [54].
<esqk>npanxxnnnn</esqk>
The <lro> element contains the last routing option and provides the routing node with a "last
chance" destination for the call. The LRO may contain the Contingency Routing Number (CRN),
which is a 24x7 PSAP emergency number, or it may contain a routing number associated with a
national or default call center. The service type will depend on the condition that resulted in the
providing of the LRO. Ultimately the usage of LRO routing data for call delivery will depend on
decisions made internally to the routing node. There may be occasions when the VPC only returns
an LRO. Examples of scenarios in which this may be the case include invalid or unavailable
location information, VPC resource limitations, or the invoking of local PSAP routing policies.
When primary routing options fail, and no LRO is provided, the routing node is required to provide
specific default handling, which may include dropping the call. The <lro> shall be expressed as a
URI.
<lro>tel: 1-npa-nxx-nnnn</lro>
The <result> element indicates to the routing node whether or not the VPC was able to provide
routing information and the means by which the routing data was determined, or if no routing
information could be provided, the source of the problem. This element therefore provides a means
by which the VSP can monitor the quality of the routing information provided by a VPC operator. A
complete list of valid <result> codes is detailed in
Table 6-3. The values of the code are expected to be sent in this element.
<result>200 SuccessGeodetic</result>
The <datetimestamp> is the date time stamp in UTC time using ISO 8601 [44] indicating the time
that the message was sent from the VPC. This field is optional, but if not included, then the routing


Version 2, August 11, 2010                                                   Page 108 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


node must maintain an accurate date and time stamp in any call event records so that an audit trail is
readily accessible.
<datetimestamp>2004-12-12T21:28:43Z</datetimestamp>
                                     Table 6-3 - Result Codes
     Value                Name                                     Description
      200         SuccessGeodetic            VPC has successfully determined the routing
                                             information based on geodetic information contained
                                             in the initial esrRequest
      201         SuccessLISGeodetic         VPC has successfully determined the routing
                                             information based on geodetic information obtained
                                             from the LIS.
      202
                  SuccessCivic               VPC has successfully determined the routing
                                             information based on civic information contained in
                                             the initial esrRequest
      203         SuccessLISCivic            VPC has successfully determined routing information
                                             based on civic information obtained from the LIS

      400         LROBadLocation             No routing information can be determined from the
                                             location provided in the LIE. This may be because the
                                             LIE is malformed, or because the location does not
                                             map to a provisioned PSAP boundary. LRO is
                                             provided, but this is really default routing.
      401         LRONoLIS                   The VPC is unable to determine the LIS from which to
                                             get the location. An LRO is returned.
      402         LRONoLocation              The VPC was unable to get a location for the client
                                             from the LIS. An LRO is returned.
      403         LROBadMessage              The esrRequest received by the VPC could not be
                                             parsed or was malformed. An LRO is returned
      404         LRONoAuthorization         The requesting node's esrRequest message failed
                                             authorization at the VPC. An LRO is provided.
      405         ErrorBadLocation           VPC was unable to get routing information based on
                                             the sourced location. VPC is unable to provide an
                                             LRO for routing.
      406         ErrorNoLIS                 VPC was unable to determine the LIS based on a
                                             provided location key. VPC is unable to provide an
                                             LRO for routing.
      407         ErrorNoLocation            The VPC is unable to get a location from the LIS for
                                             the location key provided. VPC is unable to provide an
                                             LRO for routing.

Version 2, August 11, 2010                                                  Page 109 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


    Value                Name                                    Description
     408         ErrorBadMessage           The esrRequest received by the VPC could not be
                                           parsed or was malformed. VPC is unable to provide an
                                           LRO for routing.
      409        ErrorAuthorization        The requesting node's esrRequest message failed
                                           authorization at the VPC. VPC is unable to provide an
                                           LRO for routing.
      500        LRONoResource             VPC was unable to allocate an ESQK (or default
                                           ESQK) due to failure, and an LRO is provided to
                                           enable default routing.
      501        LROGeneralError           A general error is encountered and the VPC provides a
                                           LRO to enable default routing.
      502        ErrorNoResource           The VPC is unable to allocate an ESQK (or default
                                           ESQK) due to failure, and no CRN was provided from
                                           the ERDB. VPC is unable to provide an LRO for
                                           routing.
      503        ErrorGeneral              Any error cause that is not listed above. VPC is unable
                                           to provide an LRO for routing.

6.3.1.2.1 esrResponse Message Format
The following is an esrResponse message showing a successful response (result = 200). This
example message contains valid <esqk> and <lro> values, along with a valid <ert> consisting of a
<selectiveRoutingID>, <routingESN>, and <npa>. Note that this message could contain a valid
<esgwri> instead of the <ert> if the VPC performs the ERT-to-ESGWRI translation.




Version 2, August 11, 2010                                               Page 110 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010



<esrResponse xmlns="urn:nena:xml:ns:es:v2"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v2 v2.xsd">
   <result>200 SuccessGeodetic</result>
   <vpc>
     <organizationName>Specific VPC Service</organizationName>
     <hostId>vpc.example.com</hostId>
     <nenaId>nena1</nenaId>
     <contact>tel: 398348975439823</contact>
     <certUri>https://vpc.example.com/certificate.crt</certUri>
   </vpc>
   <destination>
     <organizationName>James's Call-Server</organizationName>
     <hostId>cs34.example.com</hostId>
     <nenaId>nena1</nenaId>
     <contact>tel: 398348975439823</contact>
     <certUri>https://cs34.example.com/certificate.crt</certUri>
   </destination>
   <callId>610239946019573</callId>
   <ert>
     <selectiveRoutingID>CITYTX12NET</selectiveRoutingID>
     <routingESN>00050</routingESN>
     <npa>817</npa>
   </ert>
   <esqk>469327927621542</esqk>
   <lro>tel: 160910920672398</lro>
   <datetimestamp>2004-12-12T21:28:53Z</datetimestamp>
</esrResponse>




6.3.1.3 Emergency Services Call Termination Message (ESCT)
The ESCT message is sent from the routing node to the VPC at the conclusion of the emergency
call. The intent of this message is to return the <esqk> associated with the call back to the pool of
available query keys for use by the VPC, and to inform the VPC as to which ESGW was used to
direct the call to the Selective Router. The valid parameters for the ESCT message are included in
the following table.
                                    Table 6-4 - ESCT Parameters
         Parameter                     Condition                              Description
source                          Mandatory                      The identifier of the routing node
                                                               directly adjacent to the VPC
esqk                            Conditional                    The ESQK to return to the VPC pool
esgw                            Conditional                    The identifier of the ESGW used to
                                                               direct the call to the selective router

Version 2, August 11, 2010                                                   Page 111 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


        Parameter                         Condition                         Description
datetimestamp                  Optional                      Date Time Stamp indicating UTC date
                                                             and time that the message was sent
callId                         Mandatory                     The identifier that uniquely identified
                                                             the call at the Call Server
vpc                            Optional                      The identifier of the VPC

The <source> element identifies the node directly requesting emergency call routing from the VPC.
It includes the source node (hostId), a 24x7 contact number (contact), as well as an optional NENA
administered company identifier (nenaId), and an optional uri (certUri) that provides a link to the
provider's VESA issued certificate. The <source> must be a trusted entity of the VPC.
The value of <hostId> element within <source> element must be identical within any set of
associated esrRequest and ESCT messages.
The format of the <source> element is shown below:

<source>
  <organizationName>CS-2K</organizationName>
  <hostId>cs34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel: 398348975439823</contact>
  <certUri>https://cs34.example.com/certificate.crt</certUri>
</source


The <organizationName> element stores free form text field into which the node owner may place
their company name or other label. This field is optional.
The <hostId> identifies the fully qualified domain name or IP address of the directly requesting
node, this field is mandatory.
The <nenaId> element stores the NENA administered company identifier (NENA Company ID),
this field is optional.
The <contact> element stores a telephone number by which the directly requesting node operator
can be reached 24 hours a day, 7 days a week. This element is mandatory.
The <certUri> element provides a means of directly obtaining the VESA issued certificate for the
requesting node. This element is optional.
The <vpc> element identifies the VPC.




Version 2, August 11, 2010                                                Page 112 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010



<vpc>
  <organizationName>Specific VPC Service</organizationName>
  <hostId>vpc34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel: 398348975439823</contact>
  <certUri>https://vpc34.example.com/certificate.crt</certUri>
</vpc>


The <hostId> and the <contact> must be provided. The <nenaId>, <organizationName> and
<certUri> fields are optional.
The <esqk> element stores the ESQK that was allocated by the VPC for the call. This is the ESQK
that can now be returned to the pool of ESQKs available for use by the VPC.
<esqk>npa-nxx-nnnn</esqk>
The <esgw> element stores the identifier for the ESGW that was used to direct to the call to the
selective router. If an LRO was used to route the call then this element must not be present in the
ESCT message. The <esgw> is expected to be in the form of an IP address or a fully qualified
domain name.
<esgw>http://esgwprovider1.example.com</esgw>
The <callId> element stores the identifier that uniquely identifies the call at the querying node.
<callId>sips:123456789456123@cs34.example.com</callId>
Any <callId> values must be identical within any set of associated esrRequest and ESCT messages.
The <datetimestamp> element stores the date time stamp in UTC time using ISO 8601 [44] format
indicating the time that the message was sent from the routing node. This field is optional, but if not
included, then the VPC must maintain an accurate date and time stamp in any call event records so
that an audit trail is readily accessible.
<datetimestamp>2004-12-12T21:28:43Z</datetimestamp>

6.3.1.3.1 v2 ESCT Message Format
The format for the ESCT message is defined below:




Version 2, August 11, 2010                                                   Page 113 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



<esct xmlns="urn:nena:xml:ns:es:v2"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v2 v2.xsd">
   <vpc>
     <organizationName>Specific VPC Service</organizationName>
     <hostId>vpc.example.com</hostId>
   </vpc>
   <source>
     <organizationName>National Call-Servers</organizationName>
     <hostId>cs34.example.com</hostId>
     <nenaId>nena1</nenaId>
     <contact>tel: 398348975439823</contact>
     <certUri>https://cs34.example.com/certificate.crt</certUri>
  </source>
   <esgw>http://esgwprovider1.example.com</esgw>
   <esqk>123456789456123</esqk>
   <callId>sips:123456789456123@cs34.example.com</callId>
   <datetimestamp>2004-12-14T09:44:39Z</datetimestamp>
</esct>


An esctAck message is sent from the VPC to the routing entity (CS/RP/RS) in response to an ESCT
message. If the Call Server does not receive an esctAck message after a specified time period, the
Call Server will log this event. The length of specified time period is an implementation detail. The
valid parameters for the esctAck message are contained in the following table.
                            Table 6-5 v2 esctAck Message Parameters
         Parameter                    Condition                        Description
callId                         Mandatory                      Identifies the call at the
                                                              routing element
vpc                            Mandatory                      The identifier of the VPC
Datetimestamp                  Optional                       Date & Time Stamp
                                                              indicating UTC date and
                                                              time that the message was
                                                              sent

The <callId> element stores the identifier that uniquely identifies the call at the routing element.
<callId>sips:123456789456123@cs34.example.com</callId>
The <vpc> element identifies the VPC.




Version 2, August 11, 2010                                                   Page 114 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010



<vpc>
  <organizationName>Specific VPC Service</organizationName>
  <hostId>vpc34.example.com</hostId>
  <nenaId>nena1</nenaId>
  <contact>tel: 398348975439823</contact>
  <certUri>https://vpc34.example.com/certificate.crt</certUri>
</vpc>


The <hostId> and <contact> must be provided. The <nenaId>, <organizationName> and
<certUri> fields are optional.
The <datetimestamp> parameter stores the date and time stamp in UTC time using ISO 8601 [44]
format indicating when the message was sent from the VPC. This field is optional, but if not
included, then the routing node must maintain an accurate date and time stamp in any call event
records so that an audit trail is readily accessible.
<datetimestamp>2004-12-12T21:28:43Z</datetimestamp>

6.3.1.3.2 v2 esctAck Message Format
Below is an example esctAck message sent by the VPC.

<esctAck xmlns="urn:nena:xml:ns:es:v2"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v2 v2.xsd">
   <vpc>
     <organizationName>Specific VPC Service</organizationName>
     <hostId>vpc.example.com</hostId>
     <nenaId>nena1</nenaId>
     <contact>tel: 398348975439823</contact>
     <certUri>https://vpc.example.com/certificate.crt</certUri>
   </vpc>
   <datetimestamp>2004-12-14T10:11:06Z</datetimestamp>
</esctAck>



6.3.2   v2 Message Call Flows, Key Scenarios and Semantics
Section 6.3.1 described in detail the 4 messages that make up communication across the v2 interface.
This section will describe the key call scenarios and show the message flows between the various
network elements.

6.3.2.1 v2 esrRequest contains valid Location
The following figure describes a typical call flow where a valid PIDF-LO document containing a
geodetic and/or civic location is provided by the LIS. The v2 messages are identified in bold red

Version 2, August 11, 2010                                                Page 115 of 247
                                                               NENA Interim VoIP Architecture for
                                                               Enhanced 9-1-1 Services (i2)
                                                               NENA 08-001 v2, August 11, 2010



    LIS                  UA                          CS                           VPC                 ESGW



            1. PIDF-LO

                                   2. Call Init
                                   (PIDF-LO)

                                                        3. esrRequest (PIDF-LO,
                                                           customer, callback)

                                                          4. esrResponse (ert or
                                                             esgwri, esqk, lro)


                                                               5. Route Call




                                                  Voice communication established


                               6. Call Termination

                                                                  7. esct
                                                           (callid, esgw, esqk)


                                                               8. esctAck




                              Figure 6-1 PIDF-LO Routing over v2


   1. The LIS provides a PIDF-LO containing geodetic and or civic information to the UA over
      v0.
   2. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
      initiation message.
   3. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call-ID, callback number,
      subscriber name, and LIE containing the PIDF-LO. The CS sends the esrRequest message to
      the VPC over v2.
   4. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
      location contained in the PIDF-LO to obtain an ERT consisting of a Selective Routing
      Identifier, routing ESN, and NPA, and a CRN from the ERDB (not shown). The VPC


Version 2, August 11, 2010                                                          Page 116 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


        allocates an ESQK based on the ERT. The VPC constructs an esrResponse message
        containing the ESQK, LRO, and either the ESGWRI or the ERT, and returns this to the CS
        over v2.
   5.   The CS uses the ESGWRI, if received in the routing response, to determine the correct
        ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the ERT
        received in the routing response message. The Call Server subsequently routes the call to the
        ESGW over v4, and includes the ESGWRI, ESQK and callback number in outgoing
        signaling.
   6.   The CS detects that call has concluded, and that the ESQK is no longer required.
   7.   The CS sends an ESCT message containing the ESQK, ESGW identifier and call ID to the
        VPC.
   8.   The VPC accepts the ESCT message, authenticates the Call Server, returns the ESQK to the
        pool of available keys, and notes the ESGW in its call event records. The VPC sends an
        esctAck message to the Call Server.




Version 2, August 11, 2010                                                 Page 117 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010



6.3.2.2 esrRequest contains a LocationKey
The following figure describes a typical call flow where a Location Key is provided by the LIS. Note
that the Location Key cannot be genuinely used for routing and must be de-referenced at the LIS
first. The v2 messages are identified in bold red.




                                Figure 6-2 LocationKey Routing




Version 2, August 11, 2010                                                Page 118 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   1. The LIS provides a LocationKey to the UA over v0. The LocationKey may explicitly
      identify a client and LIS, or it may contain a value that implies these identities to the VPC.
      Regardless of the actual implementation, the LocationKey provides sufficient information to
      enable to the VPC to request the location of a UA.
   2. The UA initiates an emergency call to the CS over v1 and includes the LocationKey in a LIE
      which is sent with the call initiation message.
   3. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call ID, callback number,
      subscriber name and LIE containing the LocationKey. The CS sends the esrRequest message
      to the VPC.
   4. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
      LIS ID to send the LIE to the LIS, and request a LocationObject over v3.
   5. The LIS authenticates and VPC and validates the LocationKey. The LIS returns a LIE to the
      VPC containing a valid PIDF-LO.
   6. The VPC uses the location returned by the LIS to request routing information from the
      ERDB (not pictured). The VPC allocates an ESQK. The VPC constructs an esrResponse
      message containing the ESQK, LRO, and either the ESGWRI or the Selective Routing
      Identifier, routing ESN, and NPA (the ERT), and returns this to the CS over v2.
   7. The CS uses the ESGWRI, if received in the routing response, to determine the correct
      ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the
      Selective Routing Identifier, routing ESN, and NPA received in the routing response
      message. The CS subsequently routes the call to the ESGW, and includes the ESGWRI,
      ESQK and callback number in outgoing signaling.
   8. The CS detects that the call has concluded, and that the ESQK is no longer required. The CS
      sends an ESCT message containing the ESQK, ESGW identifier, and Call ID to the VPC.
   9. The VPC accepts the ESCT message, authenticates the CS, returns the ESQK to the pool of
      available keys, and notes the ESGW identifier in the call event records. The VPC sends an
      ESCTAck message to the CS.




Version 2, August 11, 2010                                                Page 119 of 247
                                                                NENA Interim VoIP Architecture for
                                                                Enhanced 9-1-1 Services (i2)
                                                                NENA 08-001 v2, August 11, 2010



6.3.2.3 VPC returns an Error
The following figure describes a typical call flow where an invalid PIDF-LO document is provided
by the LIS. The v2 messages are identified in bold red.


                                                                                                     PSTN
    LIS                   UA                         CS                        VPC
                                                                                                      GW



            1. PIDF-LO

                                   2. Call Init
                                   (PIDF-LO)

                                                        3. esrRequest (PIDF-LO,
                                                           customer, callback)


                                                          4. esrResponse (error)


                                                           5. Default Route




                                                  Voice communication established


                               6. Call Termination




                                     Figure 6-3 Routing Error


   1. The LIS provides a PIDF-LO containing Civic address information to the UA over v0.
   2. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
      initiation message.
   3. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call ID, callback number,
      subscriber name, and a LIE containing the PIDF-LO. The CS sends the esrRequest message
      to the VPC over v2.



Version 2, August 11, 2010                                                         Page 120 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


    4. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC is unable
        to determine routing based on the location so it returns an error indication in the esrResponse
        to the CS with no LRO.
    5. The error indication in the esrResponse message triggers the CS to perform its default routing
        behavior using local default routing policies (as shown in the example call flow above) which
        may be to send the call to a default PSAP via an admin line or to a 3rd party call center. When
        the call is routed to a PSAP admin line or a third party call center, a PSTN gateway will be
        used instead of an ESGW.
    6. Some time later, the caller hangs-up, the CS detects that call has concluded and forwards the
        call termination message to the PSTN Gateway.
Note that the VPC is not expecting a v2 ESCT message at call termination time since no ESQK was
allocated for that call.

6.3.3      v2 Interface Security
The v2 interface will need to operate in a variety of network environments, some trusted, and some
not, as described previously. The v2 interface is an XML-based interface and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the routing entity
and the VPC is not on a trusted network, both the routing entity and VPC are expected to be
protected with IPsec or TLS, and thus require certificates rooted in VESA. Even in a trusted
network, TLS protection is advisable. The VPC is the server, and the routing entity is the client in
this interface. Mutual authentication is required when cryptographic security is deployed.

6.4       v3 – VPC to LIS
NOTE: The v3 Interface protocol defined in Issue 1 of this Standard is being deprecated in
Issue 2 of this Standard in anticipation of NENA adopting an industry accepted mechanism to
provide the v3 functionality in a subsequent issue of this specification. The reasons for
deprecating the existing v3 interface definition include:
      •    The existing v3 interface definition is not in line with current thinking on location
           reference/dereference mechanisms and protocols.
      •    This Standard would be more widely deployed if it used a location
           reference/dereference mechanism supported by more than just NENA
      • Deprecation of the v3 interface protocol in i2.5 provides a warning to developers to
        defer development of the v3 interface until industry Standards related to location
        reference/dereference have stabilized.
It is anticipated that the v3 Interface will support the HELD protocol, with SIP as another
potential option.
The original v3 interface protocol definition can be found in NENA 08-001 Issue 1.




Version 2, August 11, 2010                                                   Page 121 of 247
                                                                NENA Interim VoIP Architecture for
                                                                Enhanced 9-1-1 Services (i2)
                                                                NENA 08-001 v2, August 11, 2010


6.5     v4 - Call Server/Routing Proxy to ESGW
This version of the i2 specification defines the v4 interface based on the SIP protocol. Other
protocols can be used provided they meet the requirements included in this document. The v4
interface, outlined within the current NENA i2 architecture, defines the communication protocol and
messaging between a CS or RP and the ESGW. This interface specification is intended to outline the
required data fields, with formats and examples, by which a CS or RP can properly assemble and
send data – and also so that the ESGW knows what data format to expect, in order to further set-up
and facilitate the completion of an emergency voice call to the appropriate E9-1-1 network element.
The v4 interface provides the final leg of IP messaging into the existing TDM-based Emergency
Services Network. In the network implementation examples shown within this document, the v4
interface is always implemented between a SIP Proxy Server and an ESGW.

6.5.1    v4 Interface Architecture
With SIP, a variety of signaling paths leading up to the v4 interface may exist, including proxy
configurations which terminate the v4 interface. Because of this network variability, the v4 interface
may terminate to a 9-1-1 Call Server/Proxy, or any other (SIP) 9-1-1 Call Proxy. Despite other
variations which may exist in practice, this specification focuses on two basic scenarios which are
depicted below.



                        IP domain                                      Emergency Services
                                                                        Provider Network
                              Routing Proxy


              Call Server/
                    Proxy    v6
                                                             ESGW(s)         E9-1-1
                                                        v4                  Selective
                                                                            Router(s)
                                  v4                                                       PSAP


                   v1
                                                   v2
        VoIP                                                                   SRDB
        End
        Point
                                              v2
                                                              VPC


                                  Figure 6-4 v4 Interface – Proxy Example




Scenario 1:

Version 2, August 11, 2010                                                     Page 122 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


The CS receives routing instructions (provided by the VPC over the v2 interface). It then uses this
information to format a SIP INVITE message and sends it over the v4 interface to the appropriate
ESGW.
Scenario 2:
The CS sends the call to the RP over the v6 interface. The RP receives routing instructions (provided
by the VPC over the v2 interface). It then uses this information to format a SIP INVITE message and
sends it over the v4 interface to the appropriate ESGW.
Call flows and detailed messaging described in the following sub-sections are developed based on
Scenario 1.

6.5.2   v4 Interface Call Flow
The following call flow represented by a ladder diagram shows an emergency 9-1-1 call where the
CS queries the VPC to obtain necessary 9-1-1 call routing information and then uses the received
routing information to route the call to the ESGW. This messaging scenario is graphically depicted
in Figure 6-5. Messages which pertain to the V4 interface are shown in bold red. Also included is a
detailed call flow process description.




Version 2, August 11, 2010                                                 Page 123 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010




                                Figure 6-5 v4 interface – Call Flow


Detailed description of the procedure:
   1. A VEP, which has registered with the VSP and has a known and validated location, initiates
       a 9-1-1 emergency call by sending a SIP INVITE message with “911” as the dialed number
       and its media capabilities encapsulated in a SDP payload (denoted as SDP1), to the CS.
   2. The CS responds back to the VEP with a SIP 100 Trying message.



Version 2, August 11, 2010                                              Page 124 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   3. The CS requests routing information from the VPC. Using the information provided by the
       VPC, the 9-1-1 Call Server sends an INVITE to the ESGW. The INVITE message contains
       the ESGWRI, ESQK and callback number associated with the emergency call. The ESGW
       sets up the call to the SR using the ESGWRI to determine the appropriate trunk group. The
       call is delivered to the Selective Router along with the ESQK, and possibly the callback
       number, as determined by trunk group provisioning.
   4. The ESGW responds back to the CS with a SIP 100 Trying message.
   5. A SIP 183 Session Progress message is returned from the ESGW to the 9-1-1 Call Server to
       indicate that the call has been delivered to the Selective Router.
   6. A SIP 183 Session Progress message is returned from the 9-1-1 Call Server to the VEP.
   7. A SIP 200 OK message is returned from the ESGW to the CS with its media capabilities
       encapsulated in a SDP payload (denoted as SDP2) to indicate that the call has been answered.
   8. A SIP 200 OK message is sent with its media capabilities encapsulated in a SDP payload
       (denoted as SDP2) from the CS to the VEP.
   9 A SIP Ack is returned from the VEP to the CS to acknowledge receipt of the 200 OK
       message.
   10. A SIP Ack is returned from the CS to the ESGW.
   11. RTP channels are established end-to-end between the VEP and the ESGW.
   12. After some time, the emergency caller releases the call and the VEP initiates a SIP BYE
       message to the CS.
   13. The CS sends a SIP BYE message to the ESGW. (Note: Each call could be terminated from
       either end, though VEP call termination is shown here.)
   14. The ESGW sends a SIP 200 OK message to the CS.
   15. The CS sends a SIP 200 OK to the VEP.

6.5.3   v4 Message Parameters

6.5.3.1 v4 - Sending of SIP INVITE message
The message is identified in step 3 of Figure 6-5. It originates as a SIP INVITE from the CS to the
ESGW. Valid parameters for this message are included in the following table.
  i2 Data Element          Condition          SIP Header                  Description
                                                found in
  Provider-ID         Mandatory              Via               The identifier of the VoIP [Call]
                                                               Service provider (VSP). Other
                                                               Provider-IDs (e.g., Routing Proxy
                                                               or Redirect Server) may be
                                                               presented in additional Via
                                                               headers
  ESQK                Mandatory              P-Asserted-       Key allocated for the call for ALI
                                             Identity          query.
  ESGWRI              Mandatory              Request-URI       Number used to direct the call to

Version 2, August 11, 2010                                                 Page 125 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


  (Emergency                                                    the Emergency Service Gateway
  Services Gateway                                              and SR trunk
  Route Identifier)
  callbackNumber       Conditional*           NENA              E.164 number that can be dialed
                                              propriety         by a PSAP operator to reach the
                                              Parameter in P-   call originator
                                              Asserted-
                                              Identity
                                              (CBN=)
  customer             Optional               P-asserted-       Subscriber name
                                              Identity
                       Table 6-6 SIP INVITE - Standard Message Elements
* ESGWRI, ESQK, and callback are requested. Mandatory when available.

6.5.3.2 v4 - SIP 200 OK (SDP2) message
This message is identified in step 7 of Figure 6-5. It originates as a SIP 200 OK from the ESGW.
Valid parameters are included in the following table.

     Parameter            Condition            SIP Header                 Description
  esgwID               Mandatory              Via               The identifier (IP Address or
                                                                FQDN) of the ESGW Service
                                                                provider
                                        Table 6-7 SIP 200 OK

6.5.4   Specification of the v4 interface

6.5.4.1 Transport of SIP based v4 interface
UDP will be the default transport mechanism of the v4 SIP interface with port 5060.
TCP will be used as alternative transport of the v4 SIP interface, with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used where public access is required.

6.5.4.2 v4 SIP Methods, Messages and Information Elements
The implementation of the v4 interface shall support the SIP methods and responses documented
within this document, and as defined in RFC 3261 [5] and draft-ietf-sipcore-location-conveyance
[12].




Version 2, August 11, 2010                                                  Page 126 of 247
                                                                          NENA Interim VoIP Architecture for
                                                                          Enhanced 9-1-1 Services (i2)
                                                                          NENA 08-001 v2, August 11, 2010


6.5.4.3 v4 -SIP INVITE message to ESGW:
When a Call/Proxy Server implementation is deployed connecting the v4 interface on one end and
the ESGW on the other end, it is assumed that the Call/Proxy Server will be interconnected to the
VPC through a Redirect Server via the v5, or directly via the v2 interface. In a RP configuration, the
v4 interface is connected on one end to the RP and to the ESGW on the other end. The v2 interface
to the VPC is expected to be hosted at the RP. In both cases, the RequestURI (SIP INVITE) and P-
Asserted-Identity header information should be constructed as follows:

INVITE sip:+1ESGWRI@esgwprovider.net;user=phone SIP/2.0
Via: SIP/2.0/UDP proxyserver@RP.com;branch=z9hG4bKrandomstuff
Via: SIP/2.0/UDP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:proxyserver@rp.com;lr>
Record-Route: <sip:callserver@vsp.com;lr>
Max-Forwards: 68
To: <sip:911@vsp.com>
From: <sip:+1CgPN@vsp.com;user=phone>
P-Asserted-Identity:<sip:+1ESQK@vsp.com;user= phone;CBN=callback 20>
Call-ID: callid1
Geolocation: <cid:URI-ID@vsp.com>;inserted-by=URI-ID@vsp.com;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: XXXX

--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: URI-ID@vsp.com

(LO not shown)

--simple boundary
Content-Type: application/sdp

(SDP not shown)

--simple boundary

In network configurations using a standalone RS or a RP, an additional Via header may be present
identifying the intermediary element.



20 Although, in this example, both the From header and the P-Asserted-Identity header contain the callback number, it should be
noted that the content of the From header and the P-Asserted-Identity need not be the same. The From header is what was received
from the UA and the CBN is whatever the VSP puts in a PAI. The P-Asserted-Identity will include a URI parameter that contains the
callback number that the Call Server/Proxy determined to be associated with the emergency call, based on local procedures.


Version 2, August 11, 2010                                                                      Page 127 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


Another valid form of the PAI header would be:
P-Asserted-Identity: ‘subscriber name’ <tel+1-ESQK;CBN=npanxxnnnn>
A Record-Route header must be inserted by each node involved in progressing the call to ensure
they remain in the dialog throughout the call.

6.5.4.3.1 v4 - ESGW SIP message handling:
When receiving a SIP INVITE, the ESGW shall extract the ESGWRI from the contact header and
identify the outgoing trunk group over which the emergency call will be delivered to the SR. If a
single 10-digit number is to be signaled over the outgoing trunk group, the ESGW shall extract the
number in the URI of the P-Asserted-Identity header (i.e., the ESQK) and send it over the trunk
interface to the Selective Router as the calling party number/ANI.
If the ESGW determines that two 10-digit numbers (i.e., ESQK + callback number) are to be
signaled to the SR, the ESGW shall extract the number in the URI of the P-Asserted Identity header
(i.e., the ESQK) and signal that number to the Selective Router in the Generic Digits Parameter or
Called Party Number. The ESGW shall extract the callback number from the URI parameter in the
P-Asserted-Identity header and signal that number to the Selective Router as the Calling Party
Number/ANI.

6.5.4.4 Identifying a call instance
Please refer to IETF RFC 3261 for more details on identifying call instances [5].

6.5.5   v4 SIP Messages Examples
This section identifies what information is included in the headers exchanged in the SIP INVITE,
200 OK, and the SIP BYE messages over the v4 interface. The message sequence numbers refer to
steps identified in Figure 6-5.
Note: Location information (PIDF-LO) and credential information within the SIP messaging, as part
of a multipart MIME SIP message is retained. This means that parts can be used to authenticate,
inform, and direct, but these parts are not to be removed during the transference of SIP messaging.
The end result is that the v4 must support the inclusion of a PIDF-LO and associated credential
information within the subsequent SIP INVITE messages.
The following parameters have been used to construct the examples below:
   •    Called number = 911
   •    Callback number = 713-555-1234
   •    Subscriber name = John Doe
   •    VSP Provider = vsp.com
   •    CS URI = callserver@vsp.com
   •    ESGWRI = 713-111-2222
   •    ESQK = 713-511-4321

Version 2, August 11, 2010                                                 Page 128 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   •   ESGW Provider = esgwprovider.com
   •   ESGW URI = gateway@esgwprovider.com
   •   No RP or RS is involved in progressing the call.

Message 3: CS sends SIP INVITE to ESGW

INVITE sip:+17131112222@esgwprovider.com;user=phone SIP/2.0
Via: SIP/2.0/UDP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:callserver@vsp.com;lr>
Max-Forwards: 68
To: <sip:911@vsp.com>
From: ‘Anonymous’ <sip:+17135551234@vsp.com;user=phone>
P-Asserted-Identity: ‘John Doe’ <sip:+17135114321@vsp.com;CBN=7135551234>
Call-ID: 123456789@vsp.com
Geolocation: <cid:7135551234@vsp.com>;inserted-by=7135551234@vsp.com
   ;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pkcs-mime

CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: 379

--simple boundary
Content-type: application/pkcs-mime
Content-ID: 7135551234@vsp.com

(Encrypted LO + From:URI message digest not shown)

--simple boundary
Content-Type: application/sdp

(SDP not shown)

--simple boundary




Version 2, August 11, 2010                                               Page 129 of 247
                                                  NENA Interim VoIP Architecture for
                                                  Enhanced 9-1-1 Services (i2)
                                                  NENA 08-001 v2, August 11, 2010


Message 7: ESGW sends SIP 200 OK to CS

SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway@esgwprovider.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:callserver@vsp.com;lr>
To: <sip:911@vsp.com>
From: ‘Anonymous’ <sip:+17135551234@vsp.com;user=phone>
Call-ID: 123456789@vsp.com
CSeq: 1 INVITE
Contact: <sip:911@esgwprovider.com>
Content-Type: application/sdp
Content-Length: 148

(SDP not shown)



Message 13: CS sends SIP BYE to ESGW (caller-terminated call)

BYE sip:+17131112222@esgwprovider.com;user=phone SIP/2.0
Via: SIP/2.0/UDP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:callserver@vsp.com;lr>
From: <sip:+17135551234@vsp.com;user=phone>
To: <sip:911@vsp.com>
Call-ID: 123456789@vsp.com
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69



ESGW sends SIP BYE to CS (PSAP-terminated call)

BYE sip:+17135551234@vsp.com SIP/2.0
Via: SIP/2.0/UDP gateway@esgwprovider.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sip:callserver@vsp.com;lr>
Call-ID: 123456789@vsp.com
From: <sip:7135114321@vsp.com>
To: <sip:+17135551234@vsp.com;user=phone>
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69




Version 2, August 11, 2010                                       Page 130 of 247
                                                                         NENA Interim VoIP Architecture for
                                                                         Enhanced 9-1-1 Services (i2)
                                                                         NENA 08-001 v2, August 11, 2010


6.5.6    Assumptions
      1. The sip:uri user=token parameter has a token value equal to 'phone' to ensure existing gateway
          support (the use of an alternative token value would likely require software changes in
          various SIP based equipment).
      2. The P-Asserted-Identity SIP header is used to specify the ESQK value, since the impact on
          subsequent ESGW processing will be minimized.
      3. Either ordering or qvalues (ref. RFC3261) will be used to distinguish execution priority of
          multiple Contact headers.
      4. The logging of the specific ESGW used for the call will be done within the VPC and conveyed
          to the VPC using the 200 OK, then NOTIFY SIP messages.
      5. The SIP 200 OK message from the ESGW will contain a Contact header, listing the IP address
          or a valid URI of the ESGW utilized.

6.5.7    v4 Interface Security
The v4 interface will operate in a variety of network environments, some trusted, and some not, as
described previously. The v4 interface should be used with a suitable security mechanism as defined
in Section 4. When the connection between the CS or RP and the ESGW is not on a trusted network,
both the CS/RP and ESGW are expected to be protected with IPsec or TLS, and thus require
certificates rooted in VESA. Even in a trusted network, TLS protection is advisable. Mutual
authentication is required when cryptographic security is deployed.

6.6     v5 – Call Server/Proxy to Redirect Server
The v5 interface defines the communication protocol and behaviors between the CS and a RS
function using SIP, in response to an INVITE for the purpose of routing. In addition, the RS will
subscribe to the CS to be notified upon call termination. This section also describes v2 interface
interactions between the RS and the VPC as the method used by the RS to obtain routing
information from the VPC functional element 21.

6.6.1    Technical Description
As shown in Figure 6-6, the v5 interface exists between the CS and a RS. It provides a means for the
CS to request further emergency service routing information over SIP while retaining final routing to
the appropriate ESGW. The RS receives an INVITE method from the CS and interacts with the VPC
via the v2 interface to gather emergency call parameters. The RS then formats a 300 or 302
Response back to the CS with the emergency call parameters that are subsequently used by the CS to
select the appropriate ESGW to route the call to.




21 Some implementations may aggregate the RS and the VPC into one physical component internalizing the v2 interface.


Version 2, August 11, 2010                                                                     Page 131 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010



                  IP domain                                  Emergency Services
                                                              Provider Network
                       Redirect Server


        Call Server/
              Proxy    v5
                                                   ESGW(s)            E9-1-1
                                                                     Selective
                                                                     Router(s)
                                                                                     PSAP
                                         v4

             v1
 VoIP                                         v2
 End                                                                   SRDB
 Point

                                                    VPC


                                     Figure 6-6 – The v5 Interface

6.6.2    v5 Interface Call Flow
The following call flow shows a 9-1-1 call where the CS forwards the call to a RS to obtain
necessary 9-1-1 call routing information and then uses the received routing information to route the
call to the ESGW. Messages which pertain to the v5 interface are shown in bold red.




Version 2, August 11, 2010                                                    Page 132 of 247
                                                                                      NENA Interim VoIP Architecture for
                                                                                      Enhanced 9-1-1 Services (i2)
                                                                                      NENA 08-001 v2, August 11, 2010


    VEP                       CS                                                      RS                            VPC                    ESGW

               1. INVITE
            (911; PIDF-LO;
             callid1; SDP1)
             2. 100 Trying                           3. INVITE
                                   (callid1; PIDF-LO; customer; callback; SDP1)
                                                   4. 100 Trying                        5. esrRequest (PIDF-LO,
                                                                                           customer, callback)

                                                                                           6. esrResponse (ert or
                                               7. 300 Multiple choices                        esgwri, esqk, lro)
                                         (callid1; ert or esgwri; esqk; lro)
                                                       8. ACK

                                                         9. INVITE
                                   (callid1; esgwri; esqk; callback; PIDF-LO; SDP1)
                                                                                                                          10. 100 Trying

                                                  11. SUBSCRIBE
                                                   (callId1; timer)
                                             12. 200 OK SUBSCRIBE

                                                     13. NOTIFY
                                              (callid1;state; time left)
                                                14. 200 OK NOTIFY
                                                                                                                      15. 183 Session Progress
       16. 183 Session Progress                                                                                              (SDP2)
                (SDP2)



                                               Early Media: Audible Ringing Delivered

                                                17. 200 OK INVITE (SDP3)
          18. 200 OK (SDP3)
              19. ACK
                                                         20. ACK



                                                        RTP channels established

               21. BYE
                                                                                                                              22. BYE
                                                                                                                            23. 200 OK
             24. 200 OK
                                                    25. NOTIFY
                                            (callid1; state; time left=0)
                                                26. 200 OK NOTIFY                                27. esct
                                                                                           (esqk, esgw, callId1)
                                                  29. SUBSCRIBE                            28. esctAck (callId1)
                                                 (callId1; timer=0)
                                             30. 200 OK SUBSCRIBE

                                                    31. NOTIFY
                                            (callid1; state=terminated)
                                                32. 200 OK NOTIFY




                                            Figure 6-7 - v5 interface Call flow
Here is the detailed description of the procedure depicted in the figure above:


Version 2, August 11, 2010                                                                                         Page 133 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   1. A caller invokes an emergency call dialing 9-1-1. The VEP sends a SIP INVITE to the CS
       with location attached (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
   2. The CS responds with a SIP 100 Trying message to the VEP.
   3. The CS sends an INVITE to the RS which includes location information in a PIDF-LO
       document or a reference to a location, subscriber name and callback information.
   4. The RS responds with a SIP 100 Trying message to the CS.
   5. The RS uses the information received in the SIP INVITE to construct a v2 esrRequest to the
       VPC.
   6. The VPC queries the appropriate ERDB (step not shown) based on the location and
       constructs a v2 esrResponse message back to the RS with routing instructions received from
       the ERDB. There are two options for what the VPC returns to the RS, depending on the
       arrangement in place with the RS:
       a. The VPC holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
           the VPC allocates an ESQK, determines the routing number (ESGWRI) for the call, and
           provides this information to the RS along with the LRO. In this case, the CS will use the
           ESGWRI directly for route selection.
       b. The CS holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
           the VPC allocates an ESQK for the call and provides the ESQK and the ERT information
           to the RS along with the LRO. In this case, the CS will use internal ERT-to-ESGWRI
           mappings to select the proper route.
   7. The RS returns a SIP 300 22 response to the CS with the various routing options available.
   8. A standard SIP ACK is returned to the RS to acknowledge receipt of the 3XX response.
   9. If the CS received an ERT, it translates the ERT to an ESGWRI. The CS sends a SIP
       INVITE to the ESGW with the SDP offer (shown as SDP1) and ESGWRI. The ESQK is
       sent as an URI in a PAI header. The callback number is sent as a parameter in the same PAI
       header.
   10. The ESGW responds with a SIP 100 Trying message to the CS.
   11. The RS also sends a SUBSCRIBE method to the CS so that it is notified when the call
       disconnects.
   12. The CS returns a 200 OK to acknowledge the SUBSCRIBE request.
   13. The CS sends a NOTIFY to inform the RS of the current state of the call.
   14. The RS responds with a SIP 200 OK message to the CS.
   15. The call is delivered to the PSAP and the ESGW signals a SIP 183 Session Progress back to
       the CS.
   16. The CS forwards the SIP 183 Session Progress to the VEP.
A one-way media stream is established to facilitate the delivery of audible ringing to the VEP.

22   SIP 300 response is used as an example. A SIP 302 response could also be used.

Version 2, August 11, 2010                                                 Page 134 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


  17. The PSAP call taker answers the call and the offhook signal is conveyed to the ESGW. The
      ESGW sends a SIP 200 OK message to the CS with its SDP answer (shown as SDP2).
  18. The CS forwards the SIP 200 OK message with the ESGW SDP answer to the VEP.
  19. The VEP returns a standard SIP ACK to the CS to acknowledge receipt of the SIP 200
      response and acceptance of the SDP answer.
  20. The CS forwards the SIP ACK to the ESGW to confirm acceptance of the SDP answer.
The media streams are established in both directions. The caller and the PSAP call taker can now
                                            communicate.
  21. Some time later, the call is released (the call may be terminated from either direction
      however, in this example, the caller hangs-up first). The VEP sends a SIP BYE message to
      the CS.
  22. The CS forwards the SIP BYE to the ESGW.
  23. The ESGW terminates the call to the SR and then confirms reception of the call termination
      by sending back a SIP 200 OK message to the CS.
  24. The CS forwards the SIP 200 OK message to the VEP.
  25. The CS sends a SIP NOTIFY with the URI-ID and call-state of the caller to the RS.
  26. The RS responds with a SIP 200 OK message acknowledging receipt of the call termination
      state.
  27. The RS constructs a v2 esct message and sends it to the VPC so it can release return the
      ESQK to its pool.
  28. The VPC responds with a v2 esctAck message back to the RS to acknowledge.
  29. The RS sends another SIP SUBSCRIBE message to the CS to cancel the subscription to the
      dialog.
  30. The CS returns a SIP 200 OK message to acknowledge receipt.
  31. The CS sends a last SIP NOTIFY to confirm the cancellation of the subscription.
The RS returns a SIP 200 OK message to acknowledge receipt.

6.6.3    v5 Message Parameters

6.6.3.1 v5 – SIP INVITE Message
The v5 message originates as a normal SIP INVITE from the CS. Parameters provided by this
message will be used by the RS to construct the v2 esrRequest to be sent to the VPC for routing
instructions.
        Parameter        Condition           SIP Header                  Description
  vsp                 Mandatory             Via               CS entity requesting routing
                                                              instructions.
  PIDF-LO             Conditional*          MIME body         Source of the Location


Version 2, August 11, 2010                                                Page 135 of 247
                                                                            NENA Interim VoIP Architecture for
                                                                            Enhanced 9-1-1 Services (i2)
                                                                            NENA 08-001 v2, August 11, 2010


                                                                                   Information Element (LIE).
  Callback                   Conditional*                  P-Asserted-             E.164 number that can be dialed
                                                           Identity                by a PSAP operator to reach the
                                                                                   call originator.
  Customer                   Conditional*                  P-Asserted-             VSP subscriber name.
                                                           Identity
                                       Table 6-8 v5 SIP INVITE Parameters 23
* Sent if present
vsp – The identity of the VoIP Service Provider (CS). This is included in the Via header as part of
the URI.
PIDF-LO – If included, it contains information on the caller’s location used to construct the LIE.
The PIDF-LO is included as a body within the SIP INVITE.
callback – The callback number, determined by the VSP CS from subscription data, will be included
as a parameter in the P-Asserted-Identity header and expressed as an E.164 dialable and routable
number.
Customer – The subscriber name, determined by the VSP CS from subscription data, will be
included in a P-Asserted-Identity header. When included, the subscriber name is expected to be of
the form ‘John Doe’. Aliases, nicknames and the like are not allowed.

6.6.3.2 v5 SIP 300/302 response
The SIP 300 or SIP 302 message response is sent from the RS to the CS Proxy in response to a SIP
INVITE message.This message is constructed from the routing information provided by the VPC in
the v2 esrResponse message. A subset of valid parameters sourced from the v2 esrResponse for the
SIP 300/302 response is contained in Table 6-9.
         Parameter                        Condition                   SIP Header                      Description
  Provider-ID                          Mandatory                     Via                     Redirect Server responding
                                                                                             to INVITE.
  esqk                                 Conditional                   PAI                     Key allocated for the call.
  esgwri                               Conditional                   Contact                 Routing indicator used to
                                                                                             direct the call to the ESGW.
                                                                                             This parameter will be
                                                                                             present if the ESGWRI is
                                                                                             determined by the VPC.
                                                                                             This parameter will be
                                                                                             omitted if the ERT


23 This table contains a subset of the elements received in the v5 SIP INVITE message. Only the elements reused in the v2 interface
are described in this table. The v5 INVITE message will include all mandatory parameters described in RFC 3261.


Version 2, August 11, 2010                                                                        Page 136 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


              Parameter              Condition          SIP Header               Description
                                                                        parameter is present.
     ert                        Conditional           Contact           The routing tuple to be used
                                                                        by the call server to
                                                                        determine the ESGWRI. If
                                                                        the ESGWRI is already
                                                                        provided, then this field will
                                                                        be omitted.
     lro 24                     Conditional           Contact           Contingency Routing
                                                                        Number to be used for
                                                                        fallback or returned for error
                                                                        conditions (with no
                                                                        ESGWRI or ERT/ESQK)
                              Table 6-9 v5 SIP 300 Response Parameter
Two possible cases are supported. The first (a) is when the VPC returns an ESGWRI. The second
(b), is when the VPC returns an ERT.
       a) Once the RS has received the ESQK, ESGWRI, and LRO from the VPC, it formats and
          sends a SIP 300 or SIP 302 response. Most of the headers received in the INVITE are echoed
          back and two Contact headers are added. The Contact headers should be ordered such that
          the first header contains ESGWRI/ESQK information and the second one contains the LRO
          (included only if SIP 300 is used) for fallback. A qvalue parameter shall be added to each
          line to explicitly provide ordering.
          Contact header (first line) – this header is added to the 3XX response. It contains the
          ESGWRI and a PAI, containing the ESQK, Contact: <ESGWRI>;? P-Asserted-
          Identity:<ESQK>; q=#
          Contact header (second line) - it contains the LRO, e.g., Contact: <LRO>;q=#. The LRO is
          used by the CS/RP for contingency routing.
       b) Once the RS has received the ESQK, ERT, and LRO from the VPC, it formats and sends a
          SIP 300 or SIP 302 response. Most of the headers received in the INVITE are echoed back
          and two Contact headers are added. The Contact headers should be ordered such that the
          first header contains ERT/ESQK information and the second one contains the LRO (included
          only if SIP 300 is used) for fallback. A qvalue parameter shall be added to each line to
          explicitly provide ordering.
          Contact header (first line) – this header is added to the 3XX response. It contains the ERT
          and a PAI, containing the ESQK, e.g., Contact: CLLI.ESN.NPA@<CS-Provider-ID>?P-
          Asserted-Identity:<ESQK>; q=#;

24lro is not included when SIP 302 message is used since the SIP 302 message allows only one
Contact header.

Version 2, August 11, 2010                                                  Page 137 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


       Contact header (second line) - it contains the LRO, e.g., Contact: <LRO>:qvalue=#. The
       LRO is used by the CS/RP for contingency routing.
NOTE: The 300 response may just contain one Contact header with only the LRO. This is a valid
response and indicates that the VPC was unable to provide the ERT/ESQK or ESGWRI/ESQK. The
CS/RP would then use the LRO to route the call.

6.6.3.3 v5 SIP SUBSCRIBE/NOTIFY methods for Call Termination Reporting
To enable call termination reporting using existing SIP methods, emergency calls must include
subscription as part of the exchange with the RS. A SIP SUBSCRIBE method (defined in RFC 3265
[31] with a dialog event defined in RFC 4235 [51]) is sent from the RS to the CS following the SIP
300/SIP 302 response. This is to make the CS aware that notification should be sent upon
termination of the call. When the CS detects the call has completed, a SIP NOTIFY method (defined
in RFC 3265 [31]) is sent to the RS. The RS informs the VPC by sending an ESCT message over the
v2 interface (refer to Section 6.3), to enable the ESQK allocated for the call to be released and to
inform the VPC of the ESGW that was used.

6.6.3.3.1 Initiate Subscription to Call
As described above, following the 300/302 response from the RS, a SUBSCRIBE is sent from the
RS to the CS to convey that the RS desires to receive call state pertaining to this particular dialog
(the emergency call). The CS responds with a SIP NOTIFY to acknowledge receipt of the SIP
SUBSCRIBE. The tables below describe the messages involved in this initial exchange:
     Parameter            Condition             SIP Header                    Description
  Provider-ID          Mandatory              Via                The identifier of the RS.
  FROM                 Mandatory              From               RS URI and tag associated with the
                                                                 subscription
  Package              Mandatory              Event              Identify type of event being
                                                                 subscribed to and the call-id value
                                                                 associated with this subscription
  Timer                Manadatory             Expires            On initial subscription this value is
                                                                 set to the ESQK timeout value (8
                                                                 hours).
                       Table 6-10 v5 SIP SUBSCRIBE (Initial subscription)



     Parameter            Condition             SIP Header                    Description
  Provider-ID          Mandatory              Via                Contains CS URI
  URI-ID               Mandatory              From               URI of the caller sent in the From
                                                                 header.
  State                Mandatory              Subscription-      Status of the call is active.


Version 2, August 11, 2010                                                   Page 138 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


     Parameter              Condition           SIP Header                   Description
                                              State
  Dialog-content                              Content-Type:      Dialog package – refer to call flow
                                              dialog-info        examples. Provides the entity
                                                                 (caller URI-ID), state=current value,
                                                                 call-Id of this particular leg of the
                                                                 call, and tag.
                             Table 6-11 v5 SIP NOTIFY (Ack from CS)

6.6.3.3.2 Call Terminates
When the call ends, either at the caller or Emergency services end, the RS gets notified that the call
has completed. The table below shows the parameters in the NOTIFY when the call completes.
     Parameter            Condition             SIP Header                     Description
  Provider-ID          Mandatory              Via                Contains CS URI
  URI-ID               Mandatory              From               URI of the caller sent in the From
                                                                 header. URI associated with ESQK
                                                                 for the call.
  State                Mandatory              Subscription-      Status of the subscription is active
                                              State
  Dialog-content                              Content-Type:      Dialog package – refer to call flow
                                              dialog-info        examples. Provides the entity
                                                                 (caller URI-ID), call-Id of this
                                                                 particular leg of the call,
                                                                 state=terminated, and tag.
                          Table 6-12 NOTIFY (CS to RS on Termination)

6.6.3.3.3 Final Exchange to Confirm
This exchange is necessary to notify the CS that the subscription is over. The CS could indicate the
call is over without the need of this final exchange if the CS supports setting the Subscription-state
value to terminated, and then closes the subscription, making it unnecessary for the RS to send this
exchange as defined below:
     Parameter            Condition             SIP Header                    Description
  Provider-ID          Mandatory              Via                The identifier of the RS.
  FROM                 Mandatory              From               RS URI and tag associated with the
                                                                 subscription
  Package              Mandatory              Event              Identify type of event being
                                                                 subscribed to and the call-id value
                                                                 associated with this subscription
  Timer                Manadatory             Expires            0 – indicates the subscription is over

Version 2, August 11, 2010                                                   Page 139 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


                            Table 6-13 SUBSCRIBE (Final Confirmation)

     Parameter             Condition            SIP Header                    Description
  Provider-ID           Mandatory             Via               Contains CS URI
  URI-ID                Mandatory             From              URI of the caller sent in the From
                                                                header. URI associated with ESQK
                                                                for the call.
  State                 Mandatory             Subscription-     Status of the call is active
                                              State
  Dialog-content        Mandatory             Content-Type: No content
                                              dialog-info
  Length                Mandatory             Content-Length 0 – means no content
                         Table 6-14 NOTIFY (Ack from CS for final Confirm)

6.6.4     Specification of the v5 Interface

6.6.4.1 Transport of SIP-based v5 interface
UDP will be the default transport mechanism for the v5 interface with port 5060.
TCP will be used as alternative transport with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used where public access is required.

6.6.4.2 v5 SIP Methods, Messages and Information Elements
The implementation of the v5 interface shall support SIP methods and responses documented in this
document, and as defined in RFC 3261 [5] for redirection behaviors. It must also support SIP
SUBSCRIBE/NOTIFY methods and responses as defined in RFC 3265 [31] and draft-ietf-sipcore-
location-conveyance [12] for location conveyance.

6.6.4.2.1 v5 SIP INVITE Message from the CS to the RS
The SIP INVITE message received from the CS should be constructed as follows:




Version 2, August 11, 2010                                                 Page 140 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010



INVITE sips:911@RS-UA Provider-ID SIP/2.0
Via: SIP/2.0 /TCP CS-Provider-ID;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@RS-UA-Provider-ID.com>
From: CgPN <sip: URI-ID@vsp.com>;tag=AE32SS
P-Asserted-Identity: ‘subscriber’ <sip:URI-ID@vsp.com;CBN=callback;user=phone>
Call-ID: Call-Idvalue-1
Geolocation: <cid:URI-ID@vsp.com>;inserted-by=URI-ID@vsp.com;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: XXXX

--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: URI-ID@vsp.com

(PIDF-LO not shown)

--simple boundary
Content-type: application/sdp

(SDP not shown)

--simple boundary




6.6.4.2.2 v5 SIP 300 Multiple Choices Response
SIP 300 Multiple Choice Response is used an example in this section. The RS response to the SIP
INVITE from the CS should be constructed as follows:

SIP/2.0 300 Multiple Choices
Via: SIP/2.0/TCP CS-Provider-ID;branch=z9hG4bKrandomstuff1
To: 911 <sips:911@RS-UA-Provider-ID.com>
From: URI-ID <sip:URI-ID@myvsp.com>;tag=A-value
Call-ID: Call-Idvalue-1
CSeq: theCSeqvalue1 INVITE
Contact: <sips:routingInfo@CS-Provider-ID?P-Asserted-Identity:
        =<sips:+1-ESQK@RS-Provider-ID;user=phone>>;q=1
Contact: <sips:+1-LRO@CS-Provider-ID;user=phone>;q=2



Note: The “routingInfo” parameter can be expressed as a 10-digit ESGWRI or an alphanumeric
ERT.



Version 2, August 11, 2010                                              Page 141 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


6.6.4.2.3 v5 SIP SUBSCRIBE Message for Subscription Request
The RS requires to be informed of the state of the call in progress. A SIP SUBSCRIBE message is
sent to the CS immediately after the SIP 300 response to request notification of the call state. This
message should be constructed as follows (all values used are for illustrative purposes only):

SUBSCRIBE CS-Provider-ID SIP/2.0
Via: SIP/2.0/TCP RS-UA-Provider-ID;branchz9hG4bKrandomstuff3
Call-ID: Call-Idvalue2
To: <sip:URI-ID@myvsp.com>
From: RS-UA-Provider-ID;tag=RS-1234
Cseq: 12121 SUBSCRIBE
Event: dialog; call-id=”Call-Idvalue1”;from-tag=“AE32SS”
Expires: 3600



Note: The ESQK timer value is initially set to 8 hours.

6.6.4.2.4 v5 SIP NOTIFY Message for Subscription Confirmation
The CS acknowledges the subscription request by responding with a SIP NOTIFY message carrying
the actual state of the call. This message should be constructed as follows:

NOTIFY sips:RS-UA-Provider-ID SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branchz9hG4bKrandomstuff4
To: CS- Provider-ID;branch=z9hG4bKrandomstuff4
Call-ID: Call-Idvalue2
From: <sip:URI-ID@myvsp.com>;from-tag3
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: active;expires=3599
Content-Type: dialog-info
Content-Length:261

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
      version="0"
      state="full"
      entity=":URI-ID@myvsp.com> <dialog id="as7d900as8" call-id="Call-Idvalue1"
      local-tag="RS1234" direction="initiator">
    <state>active</state>
  </dialog>
</dialog-info>



Note: The state of the call immediately after the subscription is “active.”



Version 2, August 11, 2010                                                    Page 142 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


6.6.4.2.5 v5 SIP NOTIFY for Call Termination
Once the call terminates, the CS informs the RS by sending a SIP NOTIFY message with the new
call state (terminated). This message should be constructed as follows:

NOTIFY sips: RS-UA-Provider-ID SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branch=z9hG4bKrandomstuff4
Call-ID: Call-IDValue2
To: cs3.myvsp.com
From: <sip:URI-ID@myvsp.com>;from-tag3
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: active;expires=3580
Content-Type: dialog-info
Content-Length: 268

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
      version="2"
      state="full"
      entity=":URI-ID@myvsp.com> <dialog id="as7d900as8" call-id=" Call-
IDValue1"
      local-tag="RS-1234" direction="initiator">
      <state>terminated</state>
  </dialog>
</dialog-info>



Note: Call termination is signaled by setting the <state> parameter to “terminated”.

6.6.4.2.6 v5 SIP SUBSCRIBE for Subsciption Termination
The RS completes the subscription dialog by sending a new SIP SUBSCRIBE message to the CS
identifying termination of the subscription for this call. This message should be constructed as
follows:

SUBSCRIBE CS-Provider-ID SIP/2.0
Via: SIP/2.0 /TCP RS-UA-Provider-ID;branchz9hG4bKrandomstuff3
Call-ID: Call-Idvalue2
To: <sip:URI-ID@myvsp.com>
From: RS-UA-Provider-ID;tag=RS-1234
Cseq: 12121 SUBSCRIBE
Event: dialog; call-id=”Call-Idvalue1”;from-tag=“AE32SS”
Expires: 0



Note: Termination of the subscription is signaled by setting the Expires parameter to “0”.


Version 2, August 11, 2010                                                 Page 143 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


6.6.4.2.7 v5 SIP NOTIFY for Subscription Termination Confirmation
The CS confirms termination of the subscription by sending a SIP NOTIFY message to the RS. This
message should be constructed as follows:

NOTIFY sips: RS-UA-Provider-ID SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branchz9hG4bKrandomstuff4
To: CS-Provider-ID;branch=z9hG4bKrandomstuff4
Call-ID: Call-Idvalue2
From: <sip:URI-ID@myvsp.com>;from-tag3
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: terminated;expires=0
Content-Type: dialog-info
Content-Length: 0



Note: The termination of the subscription for a particular call is signaled by setting the
“Subscription-State” header to “Terminated”.

6.6.5   SIP Exchange Example
This section identifies what information is included in the SIP headers exchanged between the CS
requesting emergency call routing instructions and RS. The message sequence numbers refer to steps
identified in Figure 6-7. Not all message examples are provided.
The following parameters have been used to construct the examples below:
   •    Called number = 911
   •    Caller’s anonymous URI = sip:fhdoweww34@vsp.com
   •    Callback number = 713-555-1234
   •    Subscriber name = John Doe
   •    VSP Provider = vsp.com
   •    CS URI = callServer@vsp.com
   •    RS Provider = rsprovider.com
   •    RS Provider URI = rs-ua@rsprovider.com
   •    ESGWRI = 713-111-2222
   •    ERT = CTONPQ14DS2.54639.713
   •    ESQK = 713-511-4321
   •    LRO = 800-555-3434
   •    ESGW Provider = esgwprovider.com
   •    ESGW URI = gateway@esgwprovider.com




Version 2, August 11, 2010                                                    Page 144 of 247
                                                    NENA Interim VoIP Architecture for
                                                    Enhanced 9-1-1 Services (i2)
                                                    NENA 08-001 v2, August 11, 2010


Message 3: CS sends SIP INVITE to RS for further routing instructions

INVITE sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com ;branch=z9hG4bKrandomstuff1
Record-Route: <sip:callserver@vsp.com;lr>
To: 911 <sips:911@vsp.com;user=phone>
From: ‘anonymous’ <sip:fhdoweww34@vsp.com>;tag=afrt4
P-Asserted-Identity: ‘John Doe’ <sip:+17135551234@vsp.com;user=phone>
Call-ID: 123456789@vsp.com
Geolocation: <cid:fhdoweww34@vsp.com>;inserted-by=fhdoweww34@vsp.com
              ;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: 234

--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: fhdoweww34@vsp.com

(PIDF-LO not shown)

--simple boundary
Content-type: application/sdp

(SDP not shown)

--simple boundary



Message 7a: RS responds to CS with a SIP 300 Multiple Choices message using ESGWRI

SIP/2.0 300 Multiple Choices
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff1
Record-Route: <sip:callserver@vsp.com;lr>
To: 911 <sips:911@vsp.com;user=phone>
From: ’Anonymous’ <sip:fhdoweww34@vsp.com>;tag=afrt4
Call-ID: 123456789@vsp.com
CSeq:2 INVITE
Contact: <sips:+17131112222@vsp.com?P-Asserted-Identity:=<sips:+1-
7135114321@vsp.com;user=phone>?>
Contact: <sips:+1-8005553434@vsp.com;user=phone>




Version 2, August 11, 2010                                         Page 145 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


Message 7b: RS responds to CS with a SIP 300 Multiple Choices message using ERT

SIP/2.0 300 Multiple Choices
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff1
Record-Route: <sip:callserver@vsp.com;lr>
To: 911 <sips:911@vsp.com >
From: ’Anonymous’ <sip:fhdoweww34@vsp.com>;tag=afrt4
Call-ID: 123456789@vsp.com
CSeq: 2 INVITE
Contact: <sips:CTONPQ14DS2.54639.713@rsprovider.com?P-Asserted-
          Identity:=<sips:+1-7135114321@vsp.com;user=phone>?>
Contact: <sips:+1-8005553434@vsp.com;user=phone>



The ERT is constructed as CLLI.ESN.NPA where the CLLI is set to the destination SR; the ESN is
set to the ESN for the location; the NPA is set to an appropriate value for the trunk group to the SR.
Message 9: CS sends SIP INVITE to ESGW over v4 Interface

INVITE sips:+17131112222@esgwprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff1
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branch= 12356sssss98 _
Record-Route: <sip:callserver@vsp.com;lr>
To: 911 <sip:911@vsp.com;user=phone>
From: ’Anonymous’ <sip:fhdoweww34@vsp.com>;tag=afrt4
P-Asserted-Identity:<sip:+17135114321@vsp.com;user=phone;CBN=7135551234>
Call-ID: 123456789@vsp.com
Accept: application/sdp
CSeq: 1 INVITE
Content-type: application/sdp
Content-Length: 234

(SDP not shown)




Version 2, August 11, 2010                                                  Page 146 of 247
                                                  NENA Interim VoIP Architecture for
                                                  Enhanced 9-1-1 Services (i2)
                                                  NENA 08-001 v2, August 11, 2010


Message 11: RS send a SIP SUBSCRIBE method to CS

SUBSCRIBE callServer@vsp.com SIP/2.0
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branchz9hG4bKrandomstuff3
Call-ID: hesdr39532@rsprovider.com
To: <sip:fhdoweww34@vsp.com>
From: rs-ua@rsprovider.com;tag=RS1234
Cseq: 12121 SUBSCRIBE
Event: dialog; call-id=”123456789@vsp.com”;from-tag=afrt4
Expires: 28800



Message 12 (200 OK) not shown
Message 13: CS immediately sends a SIP NOTIFY to RS with current state

NOTIFY sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com;branchz9hG4bKrandomstuff4
To: callServer@vsp.com;branch=z9hG4bKrandomstuff4;tag=RS1234
Call-ID: hesdr39532@rsprovider.com
From: <sip:fhdoweww34@vsp.com>;tag=hewp41
Cseq: 12121 NOTIFY
Event: dialog
Subscription-State: active;expires=28799
Content-Type: dialog-info
Content-Length: <body-length>

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
      version="0"
      state="full"
      entity=":sip:fhdoweww34@vsp.com> <dialog id="as7d900as8"
      call-id="123456789@vsp.com"
      local-tag="RS1234" direction="initiator">
    <state>active</state>
  </dialog>
</dialog-info>




Version 2, August 11, 2010                                       Page 147 of 247
                                                      NENA Interim VoIP Architecture for
                                                      Enhanced 9-1-1 Services (i2)
                                                      NENA 08-001 v2, August 11, 2010


Message 25: CS sends a SIP NOTIFYto RS to signal call termination

NOTIFY sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff4
Call-ID: hesdr39532@rsprovider.com
To: callServer@vsp.com;branch=z9hG4bKrandomstuff4;tag=RS1234
From: <sip:URI-ID@myvsp.com>;tag=hewp41
Cseq: 12121 NOTIFY
Event: dialog
Subscription-State: active;expires=28620
Content-Type: dialog-info
Content-Length: <body-length>

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
      version="2"
      state="full"
      entity=": sip:fhdoweww34@vsp.com> <dialog id="as7d900as8"
      call-id="123456789@vsp.com"
      local-tag=" RS-1234" direction="initiator">
      <state>terminated</state>
  </dialog>
</dialog-info>



NOTE: The call server may send the redirect server several NOTIFY messages communicating state
changes of the dialog. The redirect server will ignore all notifications except the termination
notification.
NOTE: Termination can come from the VEP as well, same result.
Message 29: RS terminates the subscription

SUBSCRIBE callServer@vsp.com SIP/2.0
Via: SIP/2.0/TCP rs-ua@rsprovider.com;branchz9hG4bKrandomstuff3
Call-ID: hesdr39532@rsprovider.com
To: <sip:fhdoweww34@vsp.com>
From: rs-ua@rsprovider.com;tag=RS1234
Cseq: 12121 SUBSCRIBE
Event: dialog; call-id=”123456789@vsp.com”;from-tag=afrt4
Expires: 0




Version 2, August 11, 2010                                            Page 148 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


Message 31: CS sends a SIP NOTIFY to RS confirming completion of subscription

NOTIFY sips:rs-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com;branchz9hG4bKrandomstuff4
To: callServer@vsp.com;branch=z9hG4bKrandomstuff4;tag=RS1234
Call-ID: hesdr39532@rsprovider.com
From: <sip:fhdoweww34@vsp.com>;tag=hewp41
Cseq: 1 NOTIFY
Event: dialog
Subscription-State: terminated;expires=0
Content-Type: dialog-info
Content-Length: 0



NOTE: If the CS sends a NOTIFY that indicates that the call is over, the CS can set the
Subscription-state value to terminated, and that closes the subscription, making it unnecessary for
the RS to send another SUBSCRIBE with expires=0.

6.6.6    v5 Security Requirements
The v5 interface will need to operate in a variety of network environments, some trusted, and some
not, as described previously. v5 is a SIP interface and should be used with a suitable security
mechanism as defined in Section 4. When the connection between the Call Server and the Redirect
Server is not a trusted network, both the Call Server and Redirect Server are expected to be protected
with IPSEC or TLS, and thus require a certificates rooted in VESA. Even in a trusted network, TLS
protection is advisable. Mutual authentication is required when cryptographic security is deployed.

6.7     v6 – Call Server to Routing Proxy Interface
The v6 interface is defined as a SIP interface from a CS to a 9-1-1 RP. This interface is used where
the CS desires to unconditionally route all emergency calls to an entity that will both determine the
route and forward the call to the correct ESGW. The CS does not need to remain in the call setup
path (it is however expected to remain in the end-to-end signaling path).

6.7.1    v6 Interface Architecture
As shown in Figure 6-8, this implementation of a VoIP emergency call network incorporates a 9-1-1
RP to which all emergency calls are forwarded. The v6 interface is the SIP messaging between the
CS and the RP. The RP then contacts the VPC (using the v2 interface) to obtain the ESGWRI or
ERT, and ESQK, and forwards the call to the appropriate ESGW. In the case when the ERT is
obtained from the VPC, the Routing Proxy is responsible for translating the ERT to the appropriate
ESGWRI and then forwarding the call with the ESGWRI to the correct ESGW..




Version 2, August 11, 2010                                                  Page 149 of 247
                                                             NENA Interim VoIP Architecture for
                                                             Enhanced 9-1-1 Services (i2)
                                                             NENA 08-001 v2, August 11, 2010



                  IP domain                                  Emergency Services
                                                              Provider Network
                        Routing Proxy


        Call Server/
                       v6
              Proxy                                                  E9-1-1
                                              v4   ESGW(s)
                                                                    Selective
                                                                    Router(s)
                                                                                    PSAP


             v1
                                         v2
 VoIP
 End                                                                  SRDB
 Point

                                                    VPC


                                  Figure 6-8 v6 Interface Architecture

6.7.2    v6 Interface Call Flow
The following call flow represents a typical 9-1-1 call where the CS utilizes a RP which has a
connection to a VPC. All necessary call information is passed to the Routing Proxy using a SIP
INVITE. After the proper route is determined by the VPC using the v2 interface, the RP routes the
call to the appropriate ESGW via the v4 interface. Messages which pertain to the v6 interface are
shown in bold red.




Version 2, August 11, 2010                                                   Page 150 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010




                                 Figure 6-9 V6 interface Call Flow




Here is the detailed description of the procedure depicted in the figure above:

Version 2, August 11, 2010                                                  Page 151 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   1. A caller invokes an emergency call dialing 9-1-1. The VEP sends a SIP INVITE to the CS
       with location attached (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
   2. The CS responds with a SIP 100 Trying message to the VEP.
   3. The CS sends an INVITE to the RP which includes location information in a PIDF-LO
       document, subscriber name and callback information communicated in a PAI header.
   4. The RP responds with a SIP 100 Trying message to the CS.
   5. The RP uses the information received in the SIP INVITE to construct a v2 esrRequest to the
       VPC.
   6. The VPC queries the appropriate ERDB (step not shown) based on the location and
       constructs a v2 esrResponse message back to the RP with routing instructions received from
       the ERDB. There are two options for what the VPC returns to the RP, depending on the
       arrangement in place with the RP:
      a. The VPC holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
           the VPC allocates an ESQK, determines the routing number (ESGWRI) for the call, and
           provides this information to the RP along with the LRO. In this case, the RP will use the
           ESGWRI directly for route selection.
      b. The RP holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
           the VPC allocates an ESQK for the call and provides the ESQK and the ERT information
           to the RP along with the LRO. In this case, the RP will use internal ERT-to-ESGWRI
           mappings to select the proper route.
   7. The RP sends a SIP INVITE with the SDP offer (shown as SDP1) to the ESGW to set up the
       call to the SR using the ESGWRI received to determine the appropriate ESGW. The ESQK is
       sent as an URI in a PAI header. The callback number is sent as a parameter in the same PAI
       header.
   8. The ESGW responds with a SIP 100 Trying message to the RP.
   9. The call is offered to the PSAP and the ESGW signals a SIP 183 Session Progress back to the
       RP.
   10. The RP propagates the SIP 183 Session Progress to the CS.
   11. The CS propagates the SIP 183 Session Progress to the VEP.
A one-way media stream is established so that audible ringing can be delivered to the VEP.
   12. The PSAP call taker answers the call and the offhook signal is conveyed up to the ESGW.
       The ESGW sends a SIP 200 OK message to the RP with its SDP offer (shown as SDP2).
   13. The RP propagates the SIP 200 OK to the CS with the ESGW SDP offer.
   14. The CS forwards the SIP 200 OK message with the ESGW SDP offer to the VEP.
   15. The VEP returns a standard SIP ACK to the CS to acknowledge receipt of the SIP 200
       response and acceptance of the SDP offer.
   16. The CS forwards the SIP ACK to the RP to confirm acceptance of the SDP offer.
   17. The RP forwards the SIP ACK to the ESGW to confirm acceptance of the SDP offer.

Version 2, August 11, 2010                                                Page 152 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


A two-way media stream is established. The caller and the PSAP call taker can now communicate.
   18. Some time later, the call is released. (The call may be terminated from either direction
       however, in this example, the caller hangs-up first). The VEP sends a SIP BYE message to
       the CS.
   19. The CS forwards the SIP BYE to the RP.
   20. The RP forwards the SIP BYE to the ESGW.
   21. The ESGW confirms reception of the call termination by sending back a SIP 200 OK
       message to the RP. It then conveys the call state to the SR (not shown).
   22. The RP forwards the SIP 200 OK message to the CS.
   23. The CS forwards the SIP 200 OK message to the VEP.
   24. The RP constructs a v2 esct message and sends it to the VPC so it can release return the
       ESQK to its pool.
       25. The VPC responds with a v2 esctAck message back to the RP to acknowledge.

6.7.3   v6 Message Parameters

6.7.3.1 v6 – Sending of SIP INVITE Message
This message is identified in step 3 of Figure 6-9. It originates as a SIP INVITE from the CS to the
RP. Valid parameters for this message are included in the following table.
                               Table 6-15 - v6 SIP INVITE Parameters

   Parameter        Condition            SIP Header                      Description
  vsp              Mandatory       Via                   The identifier of the VoIP Service Provider
                                                         (VSP).
  PIDF-LO          Conditional*    MIME body             Source for the Location Information
                                                         Element.
  callback         Conditional*    P-asserted-Identity   E.164 number that can be dialed by a
                                                         PSAP operator to reach the call originator.
  customer         Conditional*    P-asserted-Identity   Subscriber name.
* Sent if present.
vsp – The identity of the VoIP Service Provider (CS). This is included in the Via header as part of
the URI.
PIDF-LO – If included, it contains information on the caller’s location used to construct the LIE.
The PIDF-LO is included as a body within the SIP INVITE.
Callback – The callback number, determined by the VSP CS from subscription data, will be
included in the P-Asserted-Identity header and expressed as an E.164 dialable and routable number.




Version 2, August 11, 2010                                                 Page 153 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


Customer – The subscriber name, determined by the VSP CS from subscription data, will be
included in a P-Asserted-Identity header. When included, the subscriber name is expected to be of
the form ‘John Doe’. Aliases, nicknames and the like are not allowed.

6.7.4   Specification of the v6 interface

6.7.4.1 Transport of SIP based V6 interface
UDP will be the default transport mechanism for the v6 interface with port 5060.
TCP will be used as alternative transport with port 5060.
TLS (SIPS) over TCP transport, with port 5061, should be used if possible.

6.7.4.2 v6 SIP Methods, Messages and Information Elements
The implementation of v6 interface shall support the SIP methods and responses documented in this
document and RFC 3261 [5] and in draft-ietf-sipcore-location-conveyance [12].

6.7.4.2.1 v6 SIP INVITE Message to RP
The SIP INVITE message received from the CS should be constructed as follows:




Version 2, August 11, 2010                                                 Page 154 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010



INVITE sips:911@RP-UA.Provider-ID.net SIP/2.0
Via: SIP/2.0/TCP CS-Provider-ID;branch=z9hG4bKrandomstuff1
Record-Route: <sips:CS-Provider-ID;lr>
To: 911 <sips:911@RP-UA-Provider-ID.com>
From: CgPN <sip:URI-ID@vsp.com>;tag=value
P-Asserted-Identity: ‘customer’ <sip:callback@vsp.ca;user=phone>
Call-ID: Call-Idvalue-1
Geolocation: <cid:URI-ID@vsp.ca>;inserted-by=URI-ID@vsp.ca;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: XXXX

--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: URI-ID@vsp.ca

(PIDF-LO not shown)

--simple boundary
Content-type: application/sdp

(SDP not shown)

--simple boundary


6.7.5   v6 SIP Message Examples
This section identifies information included in SIP headers exchanged between the CS and the
Routing Server. The message sequence numbers refer to steps identified in Figure 6-9. Not all
message examples are provided.
The following parameters have been used to construct the examples below:
   •    Called number = 911
   •    Caller’s URI = sip:joeblack@vsp.com
   •    Callback number = 713-555-4321
   •    Subscriber name = Joe Black
   •    VSP Provider = vsp.com
   •    CS URI = callServer@vsp.com
   •    RP Provider = rpprovider.com
   •    RP Provider URI = rp-ua@rpprovider.com
   •    ESGWRI = 713-111-2222
   •    ERT = CTONPQ14DS2.54639.713
   •    ESQK = 713-511-4321

Version 2, August 11, 2010                                               Page 155 of 247
                                              NENA Interim VoIP Architecture for
                                              Enhanced 9-1-1 Services (i2)
                                              NENA 08-001 v2, August 11, 2010


  • LRO = 800-555-3434
  • ESGW Provider = esgwprovider.com
  • ESGW URI = gateway@esgwprovider.com
Message 3: CS sends SIP INVITE to RP

INVITE sips:rp-ua@rsprovider.com SIP/2.0
Via: SIP/2.0/TCP callServer@vsp.com ;branch=z9hG4bKrandomstuff1
Record-Route: <sips:callServer@vsp.com;lr>
To: 911 <sips:911@vsp.com>
From: ‘Joe’ <sip:joeblack@vsp.com>;tag=afrt4
P-Asserted-Identity: ‘Joe Black’ <sip:+7135554321@vsp.com;user=phone>
Call-ID: 123456789@vsp.com
Geolocation: <cid:7135554321@vsp.com>;inserted-by=7135554321@vsp.com
   ;recipient=endpoint
Supported: geolocation
Accept: application/sdp, application/pidf+xml
CSeq: 1 INVITE
Content-Type: multipart/mixed; boundary=”simple boundary”
Content-Length: 234

--simple boundary
Content-type: application/cpim-pidf+xml; charset=us-ascii
Content-ID: 7135554321@vsp.com

(PIDF-LO not shown)

--simple boundary
Content-type: application/sdp

(SDP not shown)

--simple boundary




Version 2, August 11, 2010                                   Page 156 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


Message 7: RP sends SIP INVITE to ESGW over v4 Interface

INVITE sips:+17131112222@esgwprovider.com SIP/2.0
Via: SIP/2.0/TCP rp-ua@rpprovider.com;branch=z9hG4bKrandomstuff2
Via: SIP/2.0/TCP callServer@vsp.com;branch=z9hG4bKrandomstuff1
Record-Route: <sips:rp-ua@rpprovider.com;lr>
Record-Route: <sips:callServer@vsp.com;lr>
To: 911 <sip:911@vsp.com>
From: ’Joe’ <sip:joeblack@vsp.com>;tag=afrt4
P-Asserted-Identity: <sip:+17135114321@vsp.com;user=phone;CBN=7135554321>
Call-ID: 123456789@vsp.com
Accept: application/sdp,
CSeq: 1 INVITE
Content-Type: sdp;
Content-Length: 234

(SDP not shown)



Message 12 and 13 (200 OK) not shown


Message 19: CS sends SIP BYE to RP

BYE sip:+7131112222@rpprovider.com;user=phone SIP/2.0
Via: SIP/2.0/TCP callserver@vsp.com;branch=z9hG4bK4b43c2ff8.1
Record-Route: <sips:callServer@vsp.com;lr>
From: <sip:joeblack@vsp.com>;tag=afrt4
To: <sip:911@vsp.com>
Call-ID: 123456789@vsp.com
CSeq: 1 BYE
Content-Length: 0
Max-Forwards: 69


6.7.6   v6 Interface Security
The v6 interface will need to operate in a variety of network environments, some trusted, and some
not as described in previously. V6 is a SIP interface and should be used with a suitable security
mechanism as defined in Section 4. When the connection between the Call Server and the Routing
Proxy Server is not a trusted network, both the Call Server and Routing Proxy Server are expected to
be protected with IPsec or TLS, and thus require a certificates rooted in VESA. Even in a trusted
network, TLS protection is advisable. Mutual authentication is required when cryptographic security
is deployed.




Version 2, August 11, 2010                                                Page 157 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


6.7.7    v6 Interface Assumptions
When a 9-1-1 Proxy Server control model implementation is used, the 9-1-1 ProxyServer will be
interconnected to the VPC via the v2 interface or the equivalent messaging set.

6.8     v7 – LIS to VDB
This section describes the v7 interface between the LIS and the VDB. The LIS shall use this
capability to verify that an address is MSAG-valid, ensuring that civic addresses maintained in the
LIS are and remain routable in the legacy 9-1-1 infrastructure.
The v7 interface supports validation requests for one civic address at a time as records are added,
modified, or re-validated. In this case, the LIS shall use this protocol to send web service calls to the
appropriate VDB(s).

6.8.1    v7 Message Definitions
The v7 interface is made up of a query-response message pair. The first message is sent from the LIS
to the VDB requesting location information to be validated against the MSAG. The second message
is sent from the VDB to the LIS in response to this request. The remainder of this section details the
2 messages that make up communication across the v7 interface.

6.8.1.1 v7 Request for Address Validation (validateAddressRequest)
The validateAddressRequest message between a LIS and a VDB requests validation of a civic
address against the MSAG. The valid parameters for this message are included in the following
table.
                        Table 6-16 – v7 validateAddressRequest Parameters
     Parameter              Condition                                Description
MessageID                  Optional          Optional parameter that the LIS may provide. If available
                                             in the request, the value is echoed back in the response.
CustomerID                 Optional          This value is optionally assigned by the VDB to the LIS
                                             and represents a unique client for that VDB.
StreetAddress              Mandatory         Data container for the civic address.
    StreetName             Mandatory         Name of the street without suffix and prefix.
    MSAGCommunity*         Conditional       Valid service community name as found in the MSAG.
    PostalCommunity*       Conditional       Name of the community as found in the postal guide.
    StateProvince          Mandatory         Name of the state (U.S.) or province/territories (Canada).
    Country                Mandatory         Country identifier as per ISO-3166-1.
    PrefixDirectional      Optional          Leading street direction suffix (NSEW).
    StreetSuffix           Optional          Valid street abbreviation as defined in the postal guide
                                             (e.g., AVE).
      PostDirectional      Optional          Trailing street direction suffix (N,S,E,W).
      CountyName           Optional          Name of the county.

Version 2, August 11, 2010                                                    Page 158 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


     Parameter              Condition                               Description
   CountyID                Optional          County identification code (usually the FIPS code for the
                                             U.S.).
   PostalCode              Optional          Postal code as per postal guide.
   HouseNum                Optional          Civic number.
   HouseNumSuffix          Optional          Civic number extension (e.g. 1/2, A).

* MSAGCommunity or PostalCommunity or both must be present.
All mandatory elements must be provided in the request. The optional elements may be present in
the request.
It is recommended that v7 clients submit addresses using only country-specific postal service
abbreviations. However, v7 clients may submit addresses using any non postal service abbreviations.
The <MessageID> element uniquely identifies the request at the originating node and may be
provided by the LIS. If so, the VDB will echo it back in the response. The format is as follows:
<MessageID>character string</MessageID>

The <CustomerID> element contains an identifier that a VDB operator has assigned to uniquely
identify a client. If available, the LIS should provide it in the request. This parameter is optional and
the format is as follows:
<CustomerID>character string</CustomerID>

The <StreetAddress> element contains sub-elements defining the civic address. The format is as
follows:


<StreeAddress>
   <HouseNum>civic number</HouseNum>
   <HouseNumSuffix>number suffix</HouseNumSuffix>
   <PrefixDirectional>direction</PrefixDirectional>
   <StreetName>name of the street</StreetName>
   <StreetSuffix>suffix</StreetSuffix>
   <PostDirectional>direction</PostDirectional>
   <PostalCommunity>postal name of cummunity</PostalCommunity>
   <MSAGCommunity>MSAG community name</MSAGCommunity>
   <CountyName>name of the county</CountyName>
   <CountyID>FIPS code</CountyID>
   <StateProvince>state or province code</StateProvince>
   <PostalCode>zip or postal code</PostalCode>
   <Country>country code</Country>
</StreetAddress>




Version 2, August 11, 2010                                                    Page 159 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


6.8.1.1.1 v7 validateAddressRequest Example
The following represents a validation request example where only the mandated address fields are
provided.


<validateAddressRequest xmlns=urn:nena:xml:ns:es:V7>
   <MessageID>78801FA048D4226E4787F955</MessageID>
   <CustomerID>vdbprovider24769854</CustomerID>
   <StreetAddress>
       <StreetName>LAVACA</StreetName>
       <PostalCommunity>AUSTIN</PostalCommunity>
       <StateProvince>TX</StateProvince>
       <Country>US</Country>
   </StreetAddress>
</validateAddressRequest>




6.8.1.2 v7 Validation Response (validateAddressResponse)
The validateAddressResponse provides a Return Code showing Success or Error. It also returns a
Valid field that shows whether the submitted address yielded an MSAG-valid entry or not. It
contains an array of street addresses that contains a single address (for Success) or one to ‘n’ (n to be
determined by the VDB operator) addresses (for failures if any ‘n’ possible matches were found).
The valid parameters for this message are included in the following table.
                      Table 6-17 – v7 validateAddressResponse Parameters
     Parameter              Condition                               Description
MessageID                  Optional         Parameter that the LIS may provide. If available in the
                                            request, the value is echoed back in the response.
ReturnCode                 Mandatory        Code defining the outcome of the request. See Table
                                            6-18 for the defined values.
Valid                      Mandatory        Defines whether the requested address yielded an
                                            MSAG-valid address. Values are “Valid”, “Invalid” and
                                            “na”.
AddressList                Conditional      Container for the list of addresses the VDB was able to
                                            select based on the available address criterion.


The <MessageID> element uniquely identifies the request at the originating node and may be
provided by the LIS. If so, the VDB will echo it back in the response. The format is as follows:
<MessageID>character string</MessageID>




Version 2, August 11, 2010                                                    Page 160 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


The <ReturnCode> element contains a return code characterizing the outcome of the validation
process at the VDB. Valid return codes are listed in Table 6-18 below. The format is as follows:
<ReturnCode>return code</ReturnCode>

Any <AddressList> elements present, contain one civic address, along with an optional
corresponding geodetic position. Multiple <AddressList> elements, if present, have an ordered
sequence, from best match to worst match. The format is as follows:

<AddressList>
  <Civic>
     <HouseNum>civic number</HouseNum>
     <HouseNumSuffix>number suffix</HouseNumSuffix>
     <PrefixDirectional>direction</PrefixDirectional>
     <StreetName>name of the street</StreetName>
     <StreetSuffix>street suffix</StreetSuffix>
     <PostDirectional>direction</PostDirectional>
     <PostalCommunity>postal name of cummunity</PostalCommunity>
     <MSAGCommunity>MSAG community name</MSAGCommunity>
     <CountyName>name of the county</CountyName>
     <CountyID>FIPS code</CountyID>
     <StateProvince>state or province code</StateProvince>
     <PostalCode>zip or postal code</PostalCode>
     <Country>country code</Country>
  </Civic>
  <GeoPosition>
     <Latitude>latitude</Latitude>
     <Longitude>longitude</Longitude>
     <Elevation>elevation<Elevation>
  </GeoPosition>
</AddressList>
<AddressList>
  <Civic>
    ...
  </Civic>
..<GeoPosition>
    ...
  </Geoposition>
</AddressList>



When the Return Code 210 = Success – Address Translated (location is MSAG-valid but address
was modified) is supplied, the VDB shall include the modified information in the response message.
For example, if submitted AV is changed to AVE in order to validate, or if John Carpenter Freeway
is submitted and changed to Hwy 144, the modified value is used in the StreetAddress included in
the AddressList of the response message.



Version 2, August 11, 2010                                                Page 161 of 247
                                                                        NENA Interim VoIP Architecture for
                                                                        Enhanced 9-1-1 Services (i2)
                                                                        NENA 08-001 v2, August 11, 2010


There will be no Addresses returned if the input address fails validation and no alternative addresses
are found.
The VDB shall return the postal address, MSAG community name, information as to whether the
address is valid and optionally, the geo-code of the address when the validation succeeds. The VDB
may return MSAG County ID (if it is present in the MSAG).
The VDB shall return suggested alternate postal address(es) when the validation fails (if alternates
exist).
The VDB shall return addresses using only country-specific postal service street suffix abbreviations
and directional abbreviations in the appropriate fields.
When MSAG community and postal community names are both present in the request, the VDB
shall first use MSAG community name to search its database. If a match is not found using the
MSAG community name, it shall then use the postal community name.
When only one community name is present in the request, the VDB shall use that information to
search its database.
If a single match for the submitted address is found, the VDB shall return a “Valid” condition with
ReturnCode 200 and the data from the database search.
If no match is found and the VDB is searching using the postal community name, the VDB shall
lookup the MSAG community name from a postal-to-MSAG translation table. If a translation value
is found, the VDB shall search the database with the translated community name. If a single match is
found, the VDB shall return a “Valid” condition with ReturnCode 210 and the data from the VDB
search.
If the preceding searches have not found a match, the VDB may use other search mechanisms to find
likely matches for the address. Some alternate methods are:
return where HouseNum = <input house num>, StreetName sounds (e.g. soundex algorithm) like
<input street name>, State = <input state> and Zip = <input zip> or,
Search for alternate spellings for StreetName and Abbreviations in a translation table.
In this case, if any matches are found, the VDB will provide an “Invalid” condition with the
appropriate ReturnCode (551 to 561, 580) and return up to a specified number of matches 25. If no
matches are found, the VDB will return an “Invalid” condition with the appropriate ReturnCode
(551 to 561) only.
If the submitted address is for a geographical area that is not in the serving area of the VDB, the
VDB will respond with a “na” condition and ReturnCode 562.
If the submitted address yields multiple MSAG matches, the VDB shall provide an “Invalid”
condition with ReturnCode 570 and return up to a specified number of matches.

25 The maximum number of alternatives to be provided may be configurable by the VDB operator.


Version 2, August 11, 2010                                                                      Page 162 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


The VDB shall validate the data received against the appropriate VDB database and return an
indicator of the data’s validity and one or more addresses that may be matches for the input address.

6.8.1.2.1 v7 Defined Return Codes
Table 6-18 below lists the defined Return Codes supported over the v7 interface with their
associated description.
                                   Table 6-18 - v7 Return Codes

 Return Code                                         Description
      200        Success (location is MSAG-valid).
      210        Success – Address translated (location is MSAG-valid but address was modified).
      500        Internal Server Error (to indicate System Failure).
      551        Street Name is required.
      552        Community is required.
      553        State/Province is required.
      554        Postal code not found.
      555        Prefix Directional must contain only the characters N, S, E, W and must be from
                 1-3 characters in length.
      556        Post Directional must contain only the characters N, S, E, W and must be from 1-
                 3 characters in length.
      558        State not found.
      559        Community not found.
      560        Street not found.
      561        House number is out of range.
      562        Not in Serving Area.
      570        More than one MSAG entry match.
      580        Not found - alternates returned.

6.8.1.2.2 v7 validateAddressResponse Examples
Here is a successful validation response example for a single address where the VDB added the
MSAG community name, county name, county ID and geodetic information.




Version 2, August 11, 2010                                                 Page 163 of 247
                                              NENA Interim VoIP Architecture for
                                              Enhanced 9-1-1 Services (i2)
                                              NENA 08-001 v2, August 11, 2010



<validateAddressResponse xmlns=urn:nena:xml:ns:es:V7>
   <MessageID>78801FA048D4226E4787F955</MessageID>
   <ReturnCode>200</ReturnCode>
   <Valid>valid</Valid>
   <AddressList>
       <Civic>
          <HouseNum>700</HouseNum>
          <StreetName>LAVACA</StreetName>
          <StreetSuffix>ST</StreetSuffix>
          <PostalCommunity>AUSTIN</PostalCommunity>
          <MSAGCommunity>AUSTIN</MSAGCommunity>
          <CountyName>TRAVIS</CountyName>
          <CountyID>453</CountyID>
          <StateProvince>TX</StateProvince>
          <PostalCode>78701</PostalCode>
          <Country>US</Country>
       </Civic>
       <GeoPosition>
          <Latitude>30.270339</Latitude>
          <Longitude>-97.745044<Longitude>
          <Elevation>100<Elevation>
       </GeoPosition>
   </AddressList>
</validateAddressResponse>




Version 2, August 11, 2010                                   Page 164 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


Here is a successful validation response example for a single address where the VDB has modified
the provided address and subsequently added the MSAG community name, county name, county ID
and geodetic information.


<validateAddressResponse xmlns=urn:nena:xml:ns:es:V7>
   <MessageID>78801FA048D4226E4787F955</MessageID>
   <ReturnCode>210</ReturnCode>
   <Valid>valid</Valid>
   <AddressList>
      <Civic>
         <HouseNum>700</HouseNum>
         <StreetName>LAVACA</StreetName>
         <StreetSuffix>ST</StreetSuffix>
         <PostalCommunity>AUSTIN</PostalCommunity>
         <MSAGCommunity>AUSTIN</MSAGCommunity>
         <CountyName>TRAVIS</CountyName>
         <CountyID>453</CountyID>
         <StateProvince>TX</StateProvince>
         <PostalCode>78701</PostalCode>
         <Country>US</Country>
      </Civic>
      <GeoPosition>
         <Latitude>30.270339</Latitude>
         <Longitude>-97.745044<Longitude>
         <Elevation>100<Elevation>
      </GeoPosition>
   </AddressList>
</validateAddressResponse>



Here is an unsuccessful validation response example for a single address where the VDB couldn’t
validate against a unique MSAG entry. The VDB returns alternate addresses.




Version 2, August 11, 2010                                              Page 165 of 247
                                                    NENA Interim VoIP Architecture for
                                                    Enhanced 9-1-1 Services (i2)
                                                    NENA 08-001 v2, August 11, 2010


<validateAddressResponse xmlns=urn:nena:xml:ns:es:V7>
   <MessageID>78801FA048D4226E4787F955</MessageID>
   <ReturnCode>559</ReturnCode>
   <Valid>invalid</Valid>
   <AddressList>
      <Civic>
         <HouseNum>700</HouseNum>
         <StreetName>LAVACA</StreetName>
         <StreetSuffix>ST</StreetSuffix>
         <PostalCommunity>AUSTIN</PostalCommunity>
         <MSAGCommunity>AUSTIN</MSAGCommunity>
         <CountyName>TRAVIS</CountyName>
         <CountyID>453</CountyID>
         <StateProvince>TX</StateProvince>
         <PostalCode>78701</PostalCode>
         <Country>US</Country>
      </Civic>
      <GeoPosition>
         <Latitude>30.270339</Latitude>
         <Longitude>-97.745044<Longitude>
         <Elevation>100<Elevation>
      </GeoPosition>
   </AddressList>
   <AddressList>
      <Civic>
         <HouseNum>700</HouseNum>
         <StreetName>LAVACA</StreetName>
         <StreetSuffix>ST</StreetSuffix>
         <PostalCommunity>HOUSTON</PostalCommunity>
         <MSAGCommunity>HOUSTON</MSAGCommunity>
         <CountyName>HARRIS</CountyName>
         <CountyID>201</CountyID>
         <StateProvince>TX</StateProvince>
         <PostalCode>78701</PostalCode>
         <Country>US</Country>
      </Civic>
      <GeoPosition>
         <Latitude>29.719692</Latitude>
         <Longitude>-95.275822</Longitude>
         <Elevation>5<Elevation>
      </GeoPosition>
   </AddressList>
</validateAddressResponse>




6.8.2   v7 Message Flows, Key Scenarios and Semantics


Version 2, August 11, 2010                                         Page 166 of 247
                                                                 NENA Interim VoIP Architecture for
                                                                 Enhanced 9-1-1 Services (i2)
                                                                 NENA 08-001 v2, August 11, 2010


This section describes the key scenarios and shows the message flows between the various elements
involved. An automated mechanism is assumed in this section however, a manual process could be
used as well (by a LIS administrator for example).
It is expected that location validation will be performed outside of the emergency call flow so it
doesn’t introduce delays in processing the call.

6.8.2.1 v7 - Successful Postal Address Validation
The following figure describes a typical message flow where a valid location is provided by the LIS
to the appropriate VDB. The v7 messages are identified in bold red.




                                         Figure 6-10 v7 Successful Validation
Here is the detailed description of the procedure depicted in the figure above:
     1. Locations of broadband connections are loaded into the LIS 26. The civic locations may be
        postal-formatted.
     2. If the serving VDB is not already known, the LIS issues an identityRequest message to the
        RDS to discover the serving VDB for the location it manages. It is assumed that the LIS is
        authenticated with the RDS.
     3. The RDS searches its own database for corresponding records based on the provided
        location. It then constructs an identityResponse message back to the LIS containing the
        serving VDB URI(s).


26 This interface is out of scope for this document.


Version 2, August 11, 2010                                                      Page 167 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


   4. The LIS acknowledges the identityResponse message and constructs a
      validateAddressRequest message with the targeted location to (one of) the discovered
      VDB(s) over v7.
   5. The VDB authenticates the LIS, launches a database lookup using the provided location and
      provides a response back to the LIS containing the return code, the valid flag and MSAG-
      valid address associated with the location provided.

6.8.2.2 v7 – Initial Unsuccessful Postal Address Validation
The following figure describes a typical message flow where an invalid location is provided by the
LIS to the appropriate VDB. The v7 messages are identified in bold red.




                             Figure 6-11 v7 Unsuccessful Validation
Here is the detailed description of the procedure depicted in the figure above:




Version 2, August 11, 2010                                                  Page 168 of 247
                                                                           NENA Interim VoIP Architecture for
                                                                           Enhanced 9-1-1 Services (i2)
                                                                           NENA 08-001 v2, August 11, 2010


      1. Locations of broadband connections are loaded into the LIS 27. The civic locations may be
         postal-formatted.
      2. If the serving VDB is not already known, the LIS issues an identityRequest message to the
         RDS to discover the serving VDB for the location it manages. It is assumed that the LIS is
         authenticated with the RDS.
      3. The RDS searches its own database for corresponding records based on the provided
         location. It then constructs an identityResponse message back to the LIS containing the
         serving VDB URI(s).
      4. The LIS acknowledges the identityResponse message and constructs a
         validateAddressRequest message with the targeted location to (one of) the discovered
         VDB(s) over v7.
      5. The VDB authenticates the LIS, launches a database lookup using the provided location and
         provides a response back to the LIS containing the return code, the invalid flag and, if found,
         a list of potential alternate addresses.
      6. The LIS uses internal error management processes/mechanisms to correct the errors using the
         provided information by the VDB or other sources.
      7. It corrects the location and reissues a validateAddressRequest message to the VDB.
      8. The VDB authenticates the LIS, launches a database lookup using the provided location and
         provides a response back to the LIS containing the return code, the valid flag and MSAG-
         valid address associated with the location provided.

6.8.3    v7 Interface Security
The v7 interface will need to operate in a variety of network environments, some trusted, and some
not. The v7 interface should be used with a suitable security mechanism as defined in Section 4.
When the connection between the LIS and the VDB is not a trusted network, both the LIS and the
VDB are expected to be protected with IPsec or TLS, and thus require a certificates rooted in VESA.
Even in a trusted network, TLS protection is advisable. Mutual authentication is required when
cryptographic security is deployed. This provides strong security mechanisms and is readily able to
traverse enterprise and commercial firewalls when correctly configured. The LIS is expected to be a
VESA-certified entity, and the configuration of the LIS should be such that it uses a server-side
VESA certificate that is presented to the VDB on session establishment. This allows the VDB to
validate the LIS credentials before agreeing to accept and provide location information. The VDB
may use this information for billing or other purposes.

6.9     v8 Interface - VPC to ERDB
The v8 interface, in the context of the i2 architecture, defines the communication protocol and
messaging between a VPC and an ERDB, or between ERDBs 28. The ERDB is the entity that stores
the boundary information for emergency service zones. The ERDB should be able to accept queries

27 This interface is out of scope for this document.
28 The ERDB steering mechanism is only partially defined in this version of the document.


Version 2, August 11, 2010                                                                  Page 169 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


that contain geo-spatial or civic location information. When queried with location information, it
returns the ERT, MSAG formatted civic address (if routing is based on civic location information),
geo-coded location information (if geodetic default routing was applied at the ERDB), and CRN, if
available, which is used for contingency routing. In addition, the ERDB may also return an
administrative ESN via the v8 interface, if one is included in the routing information associated with
the caller’s location.

6.9.1    v8 Message Definition
A Request/Response message pair is defined here to allow a VPC to send a routing query to an
ERDB that contains information describing the emergency caller’s location (or to allow an ERDB to
forward a routing query received from a VPC to another ERDB), and to support the return of the
associated routing information by the ERDB. XML messages are used to support this information
exchange, with tags utilized for conveying civic and geodetic information to the ERDB.

6.9.1.1 v8 erdbRequest – Request Routing Information
For the query, the erdbRequest is expected to contain geographical coordinates, civic address
information or both civic and geodetic location information. The erdbRequest will be sent to an
ERDB identified via the Root Discovery process (Section 3.9 describes the Root Discovery process).
The location information provided to the ERDB in the query is derived from the LO obtained by the
VPC.
                              Table 6-19 - erdbRequest Parameters
      Parameter               Condition                                Description
   messageId             Mandatory                   This parameter uniquely identifies the query
                                                     at the VPC
   source                Mandatory                   Identifies the node directly requesting routing
                                                     information from the ERDB
   vpc                   Conditional                 Identifies the VPC that originally requested
                                                     the routing information
   location              Conditional                 If present, contains one or both of the
                                                     following elements:
        geolocation      *Conditional                WGS84 coordinates derived from LO

        civiclocation    *Conditional                Validated address passed in LO. This is
                                                     constructed from civic location information
                                                     received in the PIDF-LO
   datetimestamp         Optional                    The datetimestamp parameter carries the date
                                                     and time of the message generation described
                                                     using UTC
   destination           Optional                    Identifies the ERDB from which routing
                                                     information is being requested

Version 2, August 11, 2010                                                  Page 170 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


* One of these must be present, it is possible that both these elements may be present
The <messageId> parameter uniquely identifies the query at the VPC. The format is up to 32
characters, expressed as follows:
<messageId>78801FA048D4226E4787F955</messageId>


The <source> element identifies the node directly requesting emergency call routing information
from the ERDB over the v8 interface. It includes the source node (hostId), a NENA administered
identifier (nenaId), a 24x7 contact number (contact), and an optional uri (certUri), a link to the
provider's VESA issued certificate. The <source> must be a trusted entity of the ERDB.
The format must be as follows:

<source>
   <organizationName>Noname VPC</organizationName>
   <hostId>cs34.example.com</hostId>
   <nenaId>nena1</nenaId>
   <contact>tel:+398348975439823</contact>
   <certUri>https://vpc34.example.com/certificate.crt</certUri>
</source>


The <hostid> and <contact> fields are mandatory while all the other fields of the <source>
element are optional.
The <vpc> element identifies the VPC that is requesting the routing information from the ERDB. In
cases where the routing request is steered from one ERDB to another, the <vpc> element would
identify the VPC requesting the routing information whereas the <source> element would identify
the ERDB that is steering the request. The format must be as follows:


<vpc>
   <organizationName>Specific VPC Service</organizationName>
   <hostId>vpc.example.com</hostId>
   <nenaId>NENA911</nenaId>
   <contact>tel:+398348975439823</contact>
   <certUri>https://vpc.example.com/certificate.crt</certUri>
</vpc>


The <hostId> and <contact> fields are mandatory while all the other fields of the <source>
element are optional.
The <location> element contains the actual physical location of the VEP. It may be expressed as a
geodetic location, a civic address, or both formats of the same physical location.


Version 2, August 11, 2010                                                 Page 171 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


geolocation – The ERDB requires WGS 84 format so this may require the VPC to convert the
coordinate information, if received, to WGS84. The two other coordinates systems discussed to date
are NAD 83 and NAD 27 (HARN). Geolocation may be provided using GML notation as Point,
Circle or Sphere. If Circle or Sphere data is provided, the ERDB will use the center-point of the
circle or sphere to determine routing. The GML format may be as follows:

<location>
   <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
     <gml:pos>37.775 -122.4194</gml:pos>
   </gml:Point>
</location>



civiclocation– The civiclocation element uses NENA-defined data elements. This is constructed
from elements of the PIDF-LO. This must be the Civic Address that was used for ERDB discovery.
It is assumed that this address was previously validated at the VDB. The format must be as follows:


<location>
   <civiclocation>
      <HouseNum>700</HouseNum>
      <PrefixDirectional>N</PrefixDirectional>
      <StreetName>LAVACA</StreetName>
      <StreetSuffix>ST</StreetSuffix>
      <MSAGCommunity>AUSTIN</MSAGCommunity>
      <CountyName>TRAVIS</CountyName>
      <StateProvince>TX</StateProvince>
      <PostalCode>78701</PostalCode>
      <Country>US</Country>
   </civiclocation>
</location>



The <datetimestamp> parameter carries the date and time of the message generation described using
ISO 8601 [44] UTC format.
<datetimestamp>2001-12-17T09:30:47Z</datetimestamp>


The <destination> element identifies the ERDB from which routing information is being requested.
It includes the source node (hostId), a 24x7 contact number (contact), and optional parameters for
the organization's name and uri (certUri) for the operator's VESA issued certificate, and a NENA
administered identifier (nenaId). The <destination> must be a trusted entity of the VPC/ERDB.
The format must be as follows:



Version 2, August 11, 2010                                                Page 172 of 247
                                                   NENA Interim VoIP Architecture for
                                                   Enhanced 9-1-1 Services (i2)
                                                   NENA 08-001 v2, August 11, 2010



<destination>
   <organizationName>ERDB Provider</organizationName>
   <hostId>erdb34.example.com</hostId>
   <nenaId>nena1</nenaId>
   <contact>tel: 398348975439823</contact>
   <certUri>https://erdb.example.com/certificate.crt</certUri>
</destination>




6.9.1.2 erdbRequest Message Format
The following is an example erdbRequest message.




Version 2, August 11, 2010                                        Page 173 of 247
                                                    NENA Interim VoIP Architecture for
                                                    Enhanced 9-1-1 Services (i2)
                                                    NENA 08-001 v2, August 11, 2010


<erdbRequest xmlns="urn:nena:xml:ns:es:v8"
  xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
  xmlns:gml=”http://www.opengis.net/gml
  xmlns:gs=”http://www.opengis.net/pidflo/1.0"
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
  xsi:schemaLocation="urn:nena:xml:ns:es:v8 v8.xsd">
    <messageId>78801FA048D4226E4787F955</messageId>
    <source>
      <organizationName>Vern's Virtual VPC</organizationName>
      <hostId>cs34.example.com</hostId>
      <nenaId>nena1</nenaId>
      <contact>tel: 398348975439823</contact>
      <certUri>https:\\rp34.example.com/certificate.crt</certUri>
    </source>
    <location>
      <civiclocation>
        <HouseNum>700</HouseNum>
        <PrefixDirectional>N</PrefixDirectional>
        <StreetName>LAVACA</StreetName>
        <StreetSuffix>ST</StreetSuffix>
        <MSAGCommunity>AUSTIN</MSAGCommunity>
        <CountyName>TRAVIS</CountyName>
        <StateProvince>TX</StateProvince>
        <PostalCode>78701</PostalCode>
        <Country>US</Country>
      </civiclocation>
      <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
        <gml:pos>37.775 -122.4194</gml:pos>
      </gml:Point>
    </location>
    <datetimestamp>2001-12-17 09:30:47.0Z</datetimestamp>
    <destination>
      <organizationName>Earl's Excellent ERDB</organizationName>
      <hostId>cs47.example.com</hostId>
      <nenaId>nena3</nenaId>
      <contact>tel: 398348975439822</contact>
      <certUri>https:\\cs47.example.com/certificate.crt</certUri>
    </destination>
</erdbRequest>




6.9.1.3 v8 erdbResponse – Routing Response
The response message assumes the responding ERDB has been determined.




Version 2, August 11, 2010                                          Page 174 of 247
                                                     NENA Interim VoIP Architecture for
                                                     Enhanced 9-1-1 Services (i2)
                                                     NENA 08-001 v2, August 11, 2010


                             Table 6-20 - erdbResponse Parameters
        Parameter                 Condition                        Description
   messageId                 Mandatory            Uniquely identifies the query at the VPC
   source                    Mandatory            The identifier of the node directly
                                                  responding to the routing query over the v8
                                                  interface
   erdb                      Conditional          The identifier of the ERDB that is the
                                                  original source of the routing information
   ert                       Conditional          A routing identifier comprising the
                                                  following 3 elements:
         selectiveRoutingID Conditional           The Common Language Location Indicator
                                                  (CLLI) code associated with the Selective
                                                  Router to which the emergency call is to be
                                                  directed.
               routingESN Conditional             The Emergency Services Number associated
                                                  with a particular ESZ that respresents a
                                                  unique combination of Police, Fire and EMS
                                                  emergency responders.
                       npa Conditional            The primary Numbering Plan Area (NPA)
                                                  associated with the outgoing route to the
                                                  Selective Router that is appropriate for
                                                  caller’s location.




   adminesn                  Conditional          Identifies the administrative ESN associated
                                                  with the LO in the query
   crn                       Conditional          Contingency 24x7 E.164 phone number to
                                                  use when unable to route using the
                                                  ERT/ESGWRI.
   msagvalidcivicaddress Conditional              Carries the MSAG valid formatted civic
                                                  address provided by the ERDB
   geocodedlocation          Conditional          Carries the geo-coded location information
                                                  derived by the ERDB if geodetic default
                                                  routing was applied
   result                    Mandatory            Indicates the success or error in responding
                                                  to the query

Version 2, August 11, 2010                                           Page 175 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


         Parameter                 Condition                           Description
   datetimestamp             Optional                 The datetimestamp parameter carries the
                                                      date and time of the message generation
                                                      described using UTC
 destination                 Optional                 The identifier of the node requesting the
                                                      routing information

The <messageID> parameter uniquely identifies the query at the VPC. The format is up to 32
characters, expressed as follows:
<messageId>78801FA048D4226E4787F955</messageId>


The <source> element identifies the node directly responding with emergency call routing
information over the v8 interface. It includes the source node (hostId), a 24x7 contact number
(contact), and an optional uri (certUri) and an optional NENA administered identifier (nenaId) to
provide a link to the provider's VESA issued certificate.
The format must be as follows:

<source>
   <organizationName>Noname ERDB</organizationName>
   <hostId>erdb34.example.com</hostId>
   <nenaId>nena1</nenaId>
   <contact>tel: 398348975439823</contact>
   <certUri>https://erdb34.example.com/certificate.crt</certUri>
</source>


The <erdb> element identifies the node that is the source of the routing information. In some cases
the <erdb> element will be coded with the same information as the source element. In cases where
ERDB steering occurs, the <erdb> element will be coded with the identity of the ERDB from which
the routing information was obtained. It includes the source node (hostId), a 24x7 contact number
(contact), an optional NENA administered identifier (nenaId), and an optional uri (certUri) that
provides a link to the provider's VESA issued certificate. The format must be as follows:




Version 2, August 11, 2010                                                 Page 176 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



<erdb>
   <organizationName>No Name 1 ERDB</organization name>
   <hostId>erdb1.example.com</hostId>
   <nenaId>NENA911</nenaId>
   <contact>tel:+398348975439823</contact>
   <certUri>https://erdb1.example.com/certificate.crt</certUri>
</erdb>



The <ert> element is composed of a <selectiveRoutingID> tag, a <routingESN> tag and a <npa>
tag which are used to derive the appropriate ESGWRI.
The <selectiveRoutingId> contains the CLLI code of the selective router to which the call is being
routed. The CLLI code is an 11 character alphanumeric field of the form AAAABBCCDDD, where
   • AAAA represents the city/county
   • BB represents the State
   • CC represents the building or location
   • DDD represents the network.
The <selectiveRoutingID> must be provided if a <routingESN> and <npa> are provided.
The <routingESN> is a 3- to 5-digit field that uniquely identifies the ESZ in the context of an SR,
and the associated Police, Fire, and EMS emergency responders associated with that ESZ. The
<routingESN> must be provided if a <selectiveRoutingID> and <npa> are provided.
The <npa> is a 3 digit field that identifies the primary NPA associated with an outgoing trunk group
to the appropriate SR associated with the caller’s location. The <npa> must be provided if a
<selectiveRoutingId> and <routingESN> are provided.

<ert>
   <selectiveRoutingID>AAAABBCCDDD</selectiveRoutingID>
   <routingESN>nnnnn</routingESN>
   <npa>NPA</npa>
</ert>



The <adminESN> parameter is coded with the administrative ESN that is associated with the
location information that is received in the query, when this information is available. It is associated
with a particular set of English Language Translations for an ESZ in a PSAP that are stored by the
ALI Database.
<adminesn>12345</adminesn>




Version 2, August 11, 2010                                                   Page 177 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


The <crn> parameter holds the PSAP 24 x 7 emergency number that can be used to route the call in
times of network failure. The format is expected to be an E.164 PSTN telephone number.
<crn>npa-nxx-nnnn</crn>


The <msagvalidcivicaddress> parameter carries the MSAG-valid formatted civic address provided
by the ERDB. As previously described, the ERDB is expected to convert a received civic address
into an MSAG valid format that can be presented at the PSAP. This parameter is expected to be sent
only if a civic location is received in the erdbRequest message. The format must be as follows:

<msagvalidcivicaddress>
   <HouseNum>700</HouseNum>
   <HouseNumSuffix>1/2</HouseNumSuffix>
   <PrefixDirectional>N</PrefixDirectional>
   <StreetName>LAVACA</StreetName>
   <StreetSuffix>ST</StreetSuffix>
   <PostDirectional>SW</PostDirectional>
   <MSAGCommunity>AUSTIN</MSAGCommunity>
   <PostalCommunity>AUSTIN</PostalCommunity>
   <CountyName>TRAVIS</CountyName>
   <CountyID>453</CountyID>
   <StateProvince>TX</StateProvince>
   <PostalCode>78701</PostalCode>
   <Country>US</Country>
</msagvalidcivicaddress>



The <geocodedlocation> parameter carries the geo-coded location information derived by the
ERDB if geodetic default routing was applied to the emergency call. This parameter is expected to
be sent only if civic location information is received in the ERDBRequest message and is found to
be invalid, the ERDB determines that default routing procedures must be invoked, and the PSAP
Authority has authorized the use of geodetic default routing. The format must be as follows:

<geocodedlocation>
   <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
     <gml:pos>37.775 -122.4194</gml:pos>
   </gml:Point>
</geocodedlocation>



The <result> parameter carries an indication of whether the ERDB was able to provide routing
information and the means by which routing information was determined. If no routing information
was provided, this parameter could be used to determine the cause of the problem. Table 6-21 -
Result Codes lists and describes the codes that should be used.


Version 2, August 11, 2010                                               Page 178 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


<result>200</result>


<datetimestamp>– The <datetimestamp> parameter carries the date and time of the message
generation described using ISO 8601 [44] UTC format.
<datetimestamp>2001-12-17T09:30:47Z</datetimestamp>


The <destination> element identifies the node that directly requested emergency call routing
information. It includes the source node (hostId), a 24x7 contact number (contact), and optional
parameters for the organization's name and uri (certUri) for the operator's VESA issued certificate.
The <destination> must be a trusted entity of the VPC/ERDB.
The format must be as follows:

<destination>
   <organizationName>vpc Provider</organizationName>
   <hostId>vpc.example.com</hostId>
   <nenaId>nena1</nenaId>
   <contact>tel: 398348975439823</contact>
   <certUri>https://vpc.example.com/certificate.crt</certUri>
</destination>



                                     Table 6-21 - Result Codes
     Value               Name                                       Description
      200       SuccessGeodetic               This value indicates that the ERDB was successful in
                                              determining routing information using the received
                                              Geo Location information
      201       SuccessCivic                  This value indicates that the ERDB was successful in
                                              determining routing information using the received
                                              Civic Location information
      210       Default route on Geo          This value indicates that the ERDB was unable to
                                              provide routing based on the civic location provided
                                              but was able to successfully geocode the complete
                                              location yielding a default route based on geocoded
                                              information.
      211       Default Route on Postal,      This value indicates that the ERDB was unable to
                City, County, State           match an exact tabular MSAG-location based on the
                                              civic location provided but was successful in
                                              determining a default route based on the combination
                                              of Postal Zone, Community name, County and State.
      212       Default Route on Postal,      This value indicates that the ERDB was unable to


Version 2, August 11, 2010                                                  Page 179 of 247
                                                       NENA Interim VoIP Architecture for
                                                       Enhanced 9-1-1 Services (i2)
                                                       NENA 08-001 v2, August 11, 2010


    Value                Name                                    Description
               County, State               match an exact tabular MSAG-location based on the
                                           civic location provided but was successful in
                                           determining a default route based on the combination
                                           of Postal Zone, County and State.
     213       Default Route on City,      This value indicates that the ERDB was unable to
               County, State               match an exact tabular MSAG-location based on the
                                           civic location provided but was successful in
                                           determining a default route based on the combination
                                           of Community name, County and State.
     214       Default Route on County,    This value indicates that the ERDB was unable to
               State                       match an exact tabular MSAG-location based on the
                                           civic location provided but was successful in
                                           determining a default route based on the combination
                                           of County and State.
     215       Default Route on State      This value indicates that the ERDB was unable to
                                           match an exact tabular MSAG-location based on the
                                           civic location provided but was successful in
                                           determining a default route based on the State.
     400       ErrorBadLocation            This value indicates that the ERDB was unable to
                                           provide routing information because the received
                                           location information was bad
     401       ErrorNoLocation             This value indicates that the ERDB was unable to
                                           provide routing information because the no location
                                           information was received in the query
     403       ErrorBadMessage             This value indicates that routing information was not
                                           provided because the query received was corrupted
     404       ErrorAuthorization          This value indicates that routing information was not
                                           provided because the query failed authentication
     500       ErrorGeneral                This value indicates that a general error occurred and
                                           the ERDB is unable to return routing information
     562       Out of Area                 This value indicates that the ERDB cannot process the
                                           request as the address provided falls ouside its serving
                                           area.



6.9.1.4 ERDBResponse Message Format
The following is an example of an erdbResponse message.




Version 2, August 11, 2010                                              Page 180 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010



<erdbResponse xmlns="urn:nena:xml:ns:es:v8"
  xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
  xmlns:gml=”http://www.opengis.net/gml
  xmlns:gs=”http://www.opengis.net/pidflo/1.0"
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
  xsi:schemaLocation="urn:nena:xml:ns:es:v8 v8.xsd">
    <messageId>78801FA048D4226E4787F955</messageId>
    <source>
      <organizationName>Earl's Excellent ERDB</organizationName>
      <hostId>cs47.example.com</hostId>
      <nenaId>nena3</nenaId>
      <contact>tel: 398348975439822</contact>
      <certUri>https:\\cs47.example.com/certificate.crt</certUri>
    </source>
    <ert>
      <selectiveRoutingID>CITYTX12NET</selectiveRoutingID>
      <routingESN>00005</routingESN>
      <npa>512</npa>
    </ert>
    <adminesn>00000</adminesn>
    <crn>5129987777</crn>
    <msagvalidcivicaddress>
      <HouseNum>700</HouseNum>
      <StreetName>LAVACA ST</StreetName>
      <MSAGCommunity>AUSTIN</MSAGCommunity>
      <CountyName>TRAVIS</CountyName>
      <StateProvince>TX</StateProvince>
      <PostalCode>78701</PostalCode>
      <Country>US</Country>
    </msagvalidcivicaddress>
    <result>200</result>
    <datetimestamp>2001-12-17T09:30:47.0Z</datetimestamp>
    <destination>
      <organizationName>Vern's Virtual VPC</organizationName>
      <hostId>cs34.example.com</hostId>
      <nenaId>nena1</nenaId>
      <contact>tel: 398348975439823</contact>
      <certUri>https:\\rp34.example.com/certificate.crt</certUri>
    </destination>
</erdbResponse>




6.9.2   v8 Message Flows, Key Scenarios and Semantics
Section 6.9.1 describes in detail the two messages that make up communication across the v8
interface. This section will describe the key call scenarios and show the message flows between the
various network elements.


Version 2, August 11, 2010                                                Page 181 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


6.9.2.1 v8 – ERDB returns Routing Information in response to erdbRequest
The following figure describes a typical call flow where a valid location is provided by the VPC to
the appropriate ERDB. The v8 messages are identified in bold red.




                    Figure 6-12 - ERDB returns Routing Information over v8
Here is the detailed description of the procedure depicted in the figure above:
   1. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
      initiation message.
   2. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call-ID, callback number,
      subscriber name, and LIE containing the PIDF-LO. The CS sends the esrRequest message to
      the VPC over v2.



Version 2, August 11, 2010                                                  Page 182 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   3. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
      location contained in the PIDF-LO to request Routing information based on the provided
      location.
   4. The ERDB authenticates the VPC and retreives the location-associated ERT, CRN, admin
      ESN and MSAG-formatted address from its database and constructs the erdbResponse to the
      VPC over v8.
   5. There are two options for what the VPC returns to the CS depending on the arrangement in
      place with the CS:
      a. The VPC holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
          the VPC allocates an ESQK, determines the routing number (ESGWRI) for the call, and
          provides this information to the CS along with the LRO. In this case, the CS will use the
          ESGWRI directly for route selection. The VPC logs the MSAG-formatted address and
          Admin ESN with the other call-related information for audit trail purposes.
      b. The CS holds ERT-to-ESGWRI mappings. Based on the ERT received from the ERDB,
          the VPC allocates an ESQK for the call and provides the ESQK and the ERT information
          to the CS along with the LRO. In this case, the CS will use internal ERT to ESGWRI
          mappings to select the proper route.
   6. The CS subsequently routes the call to the ESGW over v4, and includes the ESGWRI, ESQK
      and callback number in outgoing signaling.
   The media stream is established. The caller and the PSAP call taker can now communicate.
   7. Some time later, the caller hangs up, the CS detects that call has concluded, and that the
      ESQK is no longer required.
   8. The CS sends an ESCT message containing the ESQK and ESGW identifier to the VPC over
      v2.
   9. The VPC accepts the ESCT message, authenticates the CS, returns the ESQK to the pool of
      available keys, and notes the ESGW in its call event records. The VPC sends an ESCTAck
      message to the CS.

6.9.2.2 v8 – ERDB returns Routing Error
The following figure describes a typical call flow where an invalid location is provided through the
VPC, and default routing is not applied or unsuccessful at the ERDB. The v8 messages are identified
in bold red.




Version 2, August 11, 2010                                                Page 183 of 247
                                                                        NENA Interim VoIP Architecture for
                                                                        Enhanced 9-1-1 Services (i2)
                                                                        NENA 08-001 v2, August 11, 2010


                                                                                                              PSTN
    UA                          CS                            VPC                        ERDB
                                                                                                               GW


              1. Call Init
              (PIDF-LO)
                                   2. esrRequest (PIDF-LO,
                                      customer, callback)
                                                                     3. erdbRequest
                                                                    (invalid location)



                                                                    4. erdbResponse
                                                                          (error)
                                     5. esrResponse (error)


                                     6. Default Route Call



                                        Voice communication established


          7. Call Termination




                                Figure 6-13 – ERDB Returns an Error over v8
Here is the detailed description of the procedure depicted in the figure above:
   1. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
      initiation message.
   2. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call ID, callback number,
      subscriber name, and a LIE containing the PIDF-LO. The CS sends the esrRequest message
      to the VPC over v2.
   3. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
      location contained in the PIDF-LO to request routing information based on the provided
      assumed-to-be-valid location.
   4. The ERDB authenticates the VPC and tries unsuccessfully to retrieve the location-associated
      routing information from its database. The ERDB is unable to perform default routing using
      the received location. It then constructs the erdbResponse to the VPC over v8 specifying the
      error condition encountered.
   5. The VPC receives the erdbResponse message and constructs an esrResponse message back to
      the CS over v2 with the error condition included.



Version 2, August 11, 2010                                                                  Page 184 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   6. The CS acknowledges the error and performs its default routing behavior using local default
      routing policies, which may be to send the call to a default PSAP (as shown in the example
      call flow above), or to drop the call altogether. While in this example, the call is default
      routed to a PSAP through the PSTN gateway.
      The media stream is established. The caller and the call taker can now communicate.
   7. Some time later, the caller hangs-up, the CS detects that call has concluded and forwards the
      call termination message to the PSTN gateway.

6.9.3   Security
The v8 interface will need to operate in a variety of network environments, some trusted, and some
not, as described previously. The v8 interface is an XML-based interface and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the VPC and the
ERDB is not a trusted network, both the VPC and ERDB are expected to be protected with IPsec or
TLS, and thus require certificates rooted in VESA. Even in a trusted network, TLS protection is
advisable. Mutual authentication is required when cryptographic security is deployed.

6.10 v9 Interface – LIS/VPC to RDS
The v9 interface, in the context of the i2 architecture, defines the communication protocol and
messaging between a LIS or VPC to the Root Discovery Service (RDS).
The RDS is the entity that stores the serving areas of ERDBs and VDBs. The RDS should be able to
accept queries that contain geo-spatial or civic location information. When queried with location
information, it returns a list of URIs for ERDBs or VDBs serving that area.

6.10.1 v9 Messages Definitions
A Request/Response message pair is defined here to allow a LIS or VPC to send a query to the RDS
that contains information describing the emergency caller’s location and to support the return of
URIs associated with VDBs or ERDBs that serve that area. XML messages are used to support this
information exchange.

6.10.1.1 v9 identityRequest – Request VDB/ERDB Information
For the query, the identityRequest is expected to contain either geographical coordinates or civic
address information. The location information provided to the RDS in the query is derived from the
LO obtained by the VPC or from the Location Information stored in the LIS.
                             Table 6-31 - identityRequest Parameters
      Parameter              Condition                            Description
   geolocation         *Conditional                WGS84 coordinates derived from LO

   civiclocation       *Conditional                Civic address information present in the LIS or
                                                   the civic address received at the VPC

Version 2, August 11, 2010                                                 Page 185 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


        Parameter           Condition                                  Description
     querytype         Mandatory                     Identifies whether VDB or ERDB information is
                                                     being requested
* One of these must be present; it is possible that both these elements may be present
geolocation – Geolocation may be provided using gml notation as Point, Circle or Sphere. If Circle
or Sphere data is provided the RDS will use the center-point of the circle or sphere to determine the
appropriate ERDB/VDB.

     <location>
        <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
        <gml:pos>37.775 -122.4194</gml:pos>
        </gml:Point>
     </location>



civiclocation – the civic address must be provided using NENA data elements as defined in NENA
02-010 [11] and NENA 02-013 [38].

     <location>
        <civiclocation>
           <HouseNum>700</HouseNum>
           <HouseNumSuffix>A</HouseNumSuffix>
           <PrefixDirectional>N</PrefixDirectional>
           <StreetName>LAVACA</StreetName>
           <StreetSuffix>ST</StreetSuffix>
           <PostDirectional>S</PostDirectional>
           <MSAGCommunity>AUSTIN</MSAGCommunity>
           <PostalCommunity>AUSTIN</PostalCommunity>
           <CountyName>TRAVIS</CountyName>
           <CountyID>419</CountyID>
           <StateProvince>TX</StateProvince>
           <PostalCode>78701</PostalCode>
           <Country>US</Country>
        </civiclocation>
     </location>



querytype format:

     <querytype>ERDB</querytype>



or



Version 2, August 11, 2010                                                 Page 186 of 247
                                                    NENA Interim VoIP Architecture for
                                                    Enhanced 9-1-1 Services (i2)
                                                    NENA 08-001 v2, August 11, 2010



   <querytype>VDB</querytype>


6.10.1.2 identityRequest Message Format using Civic Location


<identityRequest xmlns="urn:nena:xml:ns:es:v9" xmlns:alins="http://www.nena9-1-
1.org/schemas/2003/ali" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs=”http://www.opengis.net/pidflo/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
   <querytype>ERDB</querytype>
   <location>
      <civiclocation>
         <HouseNum>700</HouseNum>
         <PrefixDirectional>N</PrefixDirectional>
         <StreetName>LAVACA</StreetName>
         <StreetSuffix>ST</StreetSuffix>
         <PostalCommunity>AUSTIN</PostalCommunity>
         <MSAGCommunity>AUSTIN</MSAGCommunity>
         <CountyName>TRAVIS</CountyName>
         <StateProvince>TX</StateProvince>
         <PostalCode>78701</PostalCode>
         <Country>US</Country>
      </civiclocation>
   </location>
</identityRequest>



6.10.1.3 identityRequest Message Format using Geodetic Location
Point Example




Version 2, August 11, 2010                                         Page 187 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010



<identityRequest xmlns="urn:nena:xml:ns:es:v9"
 xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
 xmlns:gml=”http://www.opengis.net/gml
 xmlns:gs=”http://www.opengis.net/pidflo/1.0"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
   <querytype>ERDB</querytype>
   <location>
      <gml:Point srsName="urn:ogc:def:crs:EPSG:6.6:4326">
      <gml:pos>37.775 -122.4194</gml:pos>
      </gml:Point>
   </location>
</identityRequest>


Circle Example


<identityRequest xmlns="urn:nena:xml:ns:es:v9"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs=”http://www.opengis.net/pidflo/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
   <querytype>ERDB</querytype>
      <location>
         <gs:Circle srsName="urn:ogc:def:crs:EPSG:6.6:4326">
         <gml:pos>37.775 -122.4194</gml:pos>
         <gs:radius uom="urn:ogc:def:uom:EPSG::9001">30</gs:radius>
         </gs:Circle>
      </location>
</identityRequest>



6.10.1.4 identityResponse – VDB/ERDB Response
The response may contain one of three different response types: error, ambiguous or found.
                       Table 6-32 – identityResponse – v9:error Attribute
       Attribute               Condition                               Description
   code                 Mandatory                     Indicates error that occurred;
                                                      400 = not found
                                                      500 = general error
   message              Optional                      Text describing the error code

                   Table 6-32 – identityResponse – v9:ambiguous Parameters


Version 2, August 11, 2010                                               Page 188 of 247
                                                      NENA Interim VoIP Architecture for
                                                      Enhanced 9-1-1 Services (i2)
                                                      NENA 08-001 v2, August 11, 2010


      Parameters              Condition                             Description
   civiclocation       Mandatory                    If an ERDB/VDB can’t be determined; this
                                                    message returns the civic address fields
                                                    which must be resolved before an answer
                                                    can be determined.

                    Table 6-33 – identityResponse – v9:found Parameters
      Parameters               Condition                             Description
   erdbAddress         Conditional                  List of ERDB URIs that have routing
                                                    information for the address or geo-position
                                                    submitted.
   poc                 Conditional                  This only applies when geodetic information
                                                    is provided in the query. Percentage Overlap
                                                    Confidence value; this describes the
                                                    percentage of the initially provided caller-
                                                    location overlapped with the corresponding
                                                    ERDB service area.
   VDB                 Conditional                  List of VDB URIs that have MSAG
                                                    information for the address submitted.

* Conditional – either VDB or ERDB information must be returned.

6.10.1.5 identityResponse Message Format when found

<identityResponse xmlns="urn:nena:xml:ns:es:v9"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
   <found>
      <ERDB>
         <erdbAddress>earlserdb.vendor.com</erdbAddress>
         <poc>90</poc>
      </ERDB>
      <ERDB>
         <erdbAddress>ernestserdb.vendor2.com</erdbAddress>
         <poc>50</poc>
      </ERDB>
   </found>
</identityResponse>




Version 2, August 11, 2010                                            Page 189 of 247
                                                  NENA Interim VoIP Architecture for
                                                  Enhanced 9-1-1 Services (i2)
                                                  NENA 08-001 v2, August 11, 2010



<identityResponse xmlns="urn:nena:xml:ns:es:v9"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:nena:xml:ns:es:v9 v9.xsd">
   <found>
      <VDB>
         <vdbAddress>vernsvaluablevalidator.vendor.com</vdbAddress>
      </VDB>
      <VDB>
         <vdbAddress>valerievolubleverifier.vendor2.com</vdbAddress>
      </VDB>
   </found>
</identityResponse>




6.10.1.6 identityResponse Message Format when ambiguous

<identityResponse xmlns="urn:nena:xml:ns:es:v9"
 xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
 xmlns:gml=”http://www.opengis.net/gml
 xmlns:gs=”http://www.opengis.net/pidflo/1.0"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v9:\MYDOCU~1\XMLSchema
 \CurrentNENA\I2\v9\v9.xsd">
  <ambiguous message="token">
    <civiclocation>
      <PrefixDirectional>N</PrefixDirectional>
      <StreetName>LAVACA</StreetName>
      <StreetSuffix>ST</StreetSuffix>
      <PostalCommunity>AUSTIN</PostalCommunity>
      <StateProvince>TX</StateProvince>
    </civiclocation>
< /ambiguous>
</identityResponse>



6.10.1.7 identityResponse Message Format when error




Version 2, August 11, 2010                                       Page 190 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010



<identityResponse xmlns="urn:nena:xml:ns:es:v9"
 xmlns:alins=http://www.nena9-1-1.org/schemas/2003/ali
 xmlns:gml=”http://www.opengis.net/gml
 xmlns:gs=”http://www.opengis.net/pidflo/1.0"
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
 xsi:schemaLocation="urn:nena:xml:ns:es:v9:\MYDOCU~1\XMLSchema
 \CurrentNENA\I2\v9\v9.xsd">
   <error code="400" message="token"/>
</identityResponse>


6.10.2 v9 Message Flows, Key Scenarios and Semantics
Section 6.10.1 described in detail the 2 messages that make up communication across the v9
interface. This section will describe the key call scenarios and show the message flows between the
various network elements.

6.10.2.1 v9 – LIS Discovering VDB
The following figure describes a typical call flow where a valid location is provided by the LIS to
the RDS in order to discover the appropriate VDB. The v9 messages are identified in bold red.




                           Figure 6-14 - RDS returns VDB URIs over v9
Here is the detailed description of the procedure depicted in the figure above:
   1. The LIS issues an identityRequest message to the RDS to discover the serving VDB for a
      location it manages. It is assumed that the LIS is authenticated with the RDS.
   2. The RDS searches its own database for corresponding records based on the provided
      location. It then constructs an identityResponse message back to the LIS containing the
      serving VDB URI(s).

Version 2, August 11, 2010                                                  Page 191 of 247
                                                                                  NENA Interim VoIP Architecture for
                                                                                  Enhanced 9-1-1 Services (i2)
                                                                                  NENA 08-001 v2, August 11, 2010


   3. The LIS acknowledges the identityResponse message and constructs a
      validateAddressRequest message with the targeted location to (one of) the discovered
      VDB(s) over v7.
   4. The VDB authenticates the LIS and provides a response back to the LIS containing the return
      code and MSAG address associated with the location provided.

6.10.2.2 v9 – VPC Discovering ERDB
The following figure describes a typical call flow where a valid location is provided by the VPC to
the RDS in order to discover the appropriate ERDB. It is expected that the VPC will query the RDS
for every call. The v9 messages are identified in bold red.

      UA                         CS                      VPC                   RDS                    ERDB               ESGW



               1. Call Init
               (PIDF-LO)          2. esrRequest (PIDF-
                                      LO, customer,
                                        callback)
                                                             3. identityRequest
                                                                  (location)

                                                             4. identityResponse
                                                             (erdb URI(s), [poc])
                                                                                     5. erdbRequest
                                                                                         (location)

                                                                                     6. erdbResponse
                                                                                    (ert, crn, msagaddr)
                                  7. esrResponse (ert or
                                     esgwri, esqk, lro)


                                        8. Route Call



                                                  Voice communication established

           9. Call Termination

                                             10. esct
                                      (callid, esgw, esqk)


                                         11. esctAck



                                  Figure 6-15 - RDS returns ERDB URIs over v9
Here is the detailed description of the procedure depicted in the figure above:
   1. The UA initiates an emergency call to the CS over v1 and includes the PIDF-LO in the call
      initiation message.
   2. The CS determines the provisioned callback number and subscriber name associated with the
      UA, and constructs an esrRequest message that includes a Call-ID, callback number,

Version 2, August 11, 2010                                                                                 Page 192 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010


       subscriber name, and LIE containing the PIDF-LO. The CS sends the esrRequest message to
       the VPC over v2.
   3. The VPC receives the esrRequest from the CS and authenticates the CS. The VPC uses the
       location contained in the PIDF-LO to discover the serving ERDB based on the provided
       location over v9.
   4. The RDS authenticates the VPC and searches its database for corresponding records based on
       the provided location. It then constructs an identityResponse message back to the VPC
       containing the serving ERDB URI(s).
   5. The VPC acknowledges the identityResponse message and uses the location contained in the
       PIDF-LO to request Routing information from (one of) the discovered ERDB(s) over v8.
   6. The ERDB authenticates the VPC and retreives the location-associated ERT, CRN, admin
       ESN and MSAG-formatted address from its database, and constructs the v8 erdbResponse to
       the VPC.
   7. The VPC allocates an ESQK based on the received ERT. The VPC constructs an
       esrResponse message containing the ESQK, LRO, and either the ESGWRI or the ERT, and
       returns this to the CS over v2. The VPC logs the MSAG-formatted address and Admin ESN
       with the other call-related information for audit trail purposes.
   8. The CS uses the ESGWRI, if received in the routing response, to determine the correct
       ESGW, or the CS determines the ESGW and appropriate ESGWRI value based on the ERT
       received in the routing response message. The CS subsequently routes the call to the ESGW
       over v4, and includes the ESGWRI, ESQK and callback number in outgoing signaling.
       The media is established. The caller and the PSAP call taker can now communicate.
   9. Some time later, the caller hangs-up, the CS detects that call has concluded, and that the
       ESQK is no longer required.
   10. The CS sends an ESCT message containing the ESQK and ESGW identifier to the VPC over
       v2.
   11. The VPC accepts the ESCT message, authenticates the CS, returns the ESQK to the pool of
       available keys, and notes the ESGW in its call event records. The VPC sends an ESCTAck
       message to the CS.

6.10.3 v9 Interface Security
The v9 interface will need to operate in a variety of network environments, some trusted, and some
not, as described in previously. V9 is a XML-based interface and should be used with a suitable
security mechanism as defined in Section 4. When the connection between the VPC or LIS and the
RDS is not a trusted network, both the VPC/LIS and RDS are expected to be protected with IPsec or
TLS, and thus require certificates rooted in VESA. Even in a trusted network, TLS protection is
advisable. Mutual authentication is required when cryptographic security is deployed.

6.11 v-E2 Interface – ALI to VPC
The v-E2 interface, in the context of the i2 Solution migration architecture, defines the
communication protocol and messaging between a VPC and an ALI DB. This interface specification

Version 2, August 11, 2010                                               Page 193 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


outlines the required data fields, with formats and examples, by which a VPC shall properly
assemble and send emergency call-related data in response to a query from an ALI DB, in order to
facilitate the delivery of emergency call-related data to a conventional PSAP.
This interface is based on the E2+ interface between a wireless Mobile Positioning Center (MPC)
and an Emergency Services Message Entity (ESME) described in NENA-05-001[13], which is in
turn based on E2 interface specified in TIA J-STD-036-B [34]. This document provides incremental
requirements, describing the differences from NENA 05-001.
The technical description and the network architecture described in Sections 3 and 4 of NENA
05-001 shall apply with the following clarifications for the i2 Solution. In the i2 Solution
architecture, the VPC takes the place of the MPC in the architecture and the ESME is referred to as
an ALI, as illustrated in Figure 6-15.


                                                 ALI                            VPC



                  PSAP


                             one-to-one          ALI                            VPC
                           many-to-many



                              Figure 6-16. v-E2 Interface Architecture
It is not recommended that an E2 interface as described in TIA J-STD-036A (rather than NENA 05-
001) be used as the basis for the VPC to ALI interface. However, if this is the case, the ALI will not
be able to receive civic location information. It may receive some information, e.g., Callback
Number or geodetic location if it is available. Please refer to Appendix A.
If a PSAP-to-ALI Message (PAM) interface is used for communications between the VPC and the
ALI, this is not specified as part of the i2 Solution.
VPC operators may reuse existing physical interfaces to establish v-E2 logical connection along side
existing E2+ logical connections based on business agreements.

6.11.1 v-E2 Message Definitions
There are four Request/Response messages defined in NENA 05-001 that are defined here for use in
requesting and responding to requests for emergency call information from the VPC. The remainder
of this section details the four messages that make up communication across the v-E2 interface.



Version 2, August 11, 2010                                                  Page 194 of 247
                                                                           NENA Interim VoIP Architecture for
                                                                           Enhanced 9-1-1 Services (i2)
                                                                           NENA 08-001 v2, August 11, 2010


The VPC and the ALI DB shall be able to support the messages and parameters defined in NENA
05-001, as modified in this document for use across the v-E2 interface.

6.11.1.1 Emergency Services Position Request (ESPOSREQ)
The ESPOSREQ message is sent from the ALI DB to the VPC to request call- and location-related
information from the VPC for an emergency call, identified by a query key, the Emergency Services
Query Key (ESQK). The valid parameters for the ESPOSREQ message are included in the following
table. The ALI DB shall use the Position Request parameter to make the initial request for location
information as well as to request updates of location.
                                        Table 6-22. ESPOSREQ Parameters

          Parameter                               § Ref. in              Condition         Description/Value
                                                NENA 05-001
          Package Type=Query                          9.1.1             Mandatory          Query with
          with Permission                                                                  Permission
          Transaction ID                              9.1.2             Mandatory
          Component Sequence                          9.2.1             Mandatory
          Component Type                              9.2.2             Mandatory          Invoke (Last)
          Component ID                                9.2.3             Mandatory
          Operation Code                              9.2.4             Mandatory          Private TCAP
          Parameter Set                               9.2.7             Mandatory
          ESMEIdentification                          9.3.1             Mandatory
          Position Request Type                       9.3.2             Mandatory
          Emergency Services                          9.3.3            Mandatory 29 Emergency Services
          Routing Key (esprKey)                                                     Query Key (ESQK)
          Callback Number                             9.3.4               Optional         If 20 digits are sent to
                                                                                           the SR, the callback
                                                                                           number may be sent
                                                                                           over the v-E2
                                                                                           interface.


29 This parameter is Optional in NENA 05-001 for wireless call information provided to the ESME from the MPC. However, when
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with the
Emergency Services Query Key.


Version 2, August 11, 2010                                                                       Page 195 of 247
                                                                              NENA Interim VoIP Architecture for
                                                                              Enhanced 9-1-1 Services (i2)
                                                                              NENA 08-001 v2, August 11, 2010


6.11.1.2 Emergency Services Position Request Response (esposreq)
This message is sent from the VPC to the ALI DB to inform the ALI DB of the position of the VoIP
Endpoint.
      Table 6-23. Emergency Services Position Request Response (esposreq) Parameters
Parameter                                   § Reference in       § Ref. in        Inclusion          Description/Value
                                            NENA 05-001          this doc.        Condition
Package Type                                     9.1.1                -         Mandatory            Response
Transaction ID                                   9.1.2                -        Mandatory
Component Sequence                               9.2.1                -        Mandatory
Component Type                                   9.2.2                -        Mandatory             Return Result (Last)
Component ID                                     9.2.3                -        Mandatory
Parameter Set                                    9.2.7                -        Mandatory
Position Result                                  9.3.8                -        Mandatory
PositionInformation                              9.3.9
         Geographic Position                    9.3.9.2           1.1.3.3         Optional           Geo Location
              Position Source                   9.3.9.3          6.11.2.3         Optional           Method of location
                                                                                                     determination
CallbackNumber                                   9.3.5           6.11.2.4 Conditional 30             Caller’s E.164
                                                                                                     number
Emergency Services Routing                       9.3.7           5.11.2.5             NA             Not used.
Digits Request Response                                                                              (In the future this
                                                                                                     parameter might be
                                                                                                     populated with
                                                                                                     ESQK )
GeneralizedTime                                 9.3.11           6.11.2.6         Optional           Timestamp for
                                                                                                     assignment of ESQK
MobileIdentificationNumber                      9.3.12           6.11.2.7             NA             Not used
InternationalMobileSubscribe                    9.3.13              -                 NA             Not used
rIdentity (IMSI)
MobileCallStatus                                9.3.14              -              NA                Not used
CompanyID                                       9.3.15           6.11.2.8       Mandatory 31         Name of the VSP
                                                                                                     (up to 15 characters)
LocationDescription                             9.3.16           6.11.2.9       Conditional          Tagged elements of

30 This parameter is Optional in NENA 05-001 for wireless call information provided to the ESME from the MPC. However, when
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with an E.164
number identifying the Callback Number of the emergency caller, if it is available to the VPC.
31 This parameter is Optional in NENA 05-001 for wireless call information provided to the ESME from the MPC. However, when
the E2 interface is used to support VoIP call information from a VPC to an ESME, this parameter must be populated with
identification for the VoIP Service Provider, if it is available to the VPC. If one is not available, the VPC must substitute its own
name.


Version 2, August 11, 2010                                                                          Page 196 of 247
                                                                  NENA Interim VoIP Architecture for
                                                                  Enhanced 9-1-1 Services (i2)
                                                                  NENA 08-001 v2, August 11, 2010


Parameter                        § Reference in   § Ref. in          Inclusion   Description/Value
                                 NENA 05-001      this doc.          Condition
                                                                            the civic address
                                                                            along with
                                                                            Subscriber name
The VPC shall use the civic location information, if received in the response from the ERDB, to
populate the civic location information in this response message. If geo-coded location information
is received from the ERDB, geo-coded location information will be populated in the Position
Information – Geographic Position parameter.

6.11.1.3 Emergency Services Position Request Response Return Error
This message is sent from the VPC to the ALI DB to inform the ALI DB that the requested action
was not performed. The Error Code contains the reason for the failure.
    Table 6-24. Emergency Services Position Request Response Return Error Parameters

 Parameter                     § Reference in            §               Condition   Description/Value
                               NENA 05-001           Reference
                                                      in this
                                                     document
 Package Type                       9.1.1                     -         Mandatory    Response
 Transaction ID                     9.1.2                     -         Mandatory

 Component Sequence                 9.2.1                     -         Mandatory

 Component Type                     9.2.2                     -         Mandatory    Return Error
 Component ID                       9.2.3                     -         Mandatory

 Error Code                         9.2.5                     -         Mandatory
 Parameter Set                      9.2.7                     -         Mandatory
Note: No new error codes have been identified for this application.

6.11.1.4 Emergency Services Position Request Response Reject
This message is sent from the VPC to the ALI DB to inform the ALI DB that the invoke message
contains a Transaction or Component Level protocol error. The problem code describes the nature of
the protocol error.




Version 2, August 11, 2010                                                       Page 197 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


       Table 6-25. Emergency Services Position Request Response Reject Parameters

 Parameter                    § Reference in          §           Condition   Description/Value
                              NENA 05-001         Reference
                                                   in this
                                                  document
 Package Type                      9.1.1               -         Mandatory    Response
 Transaction ID                    9.1.2               -         Mandatory

 Component Sequence                9.2.1               -         Mandatory

 Component Type                    9.2.2               -         Mandatory    Reject
 Component ID                      9.2.3               -         Mandatory

 Problem Code                      9.2.6               -         Mandatory

 Parameter Set                     9.2.7               -         Mandatory


Note: No new problem codes have been identified for this application.

6.11.2 Emergency Services Protocol (ESP) Parameters
This section identifies the use and also differences from NENA 05-001 that shall be supported when
the v-E2 interface is implemented between a VPC and the ALI DB.

6.11.2.1 ESMEIdentification
The ESMEIdentification parameter shall be populated with the identification of the ALI requesting
the location information.

6.11.2.2 Position Information – Geographic Position Parameter
If coordinate-based location information is provided to the VPC for the emergency call, this
information shall be used to populate the Position Information – Geographic Position Parameter.
Specifically, the VPC shall obtain the geodetic location parameters from the PIDF-LO contained in
the LIE parameter of the Emergency Services Routing Request received by the VPC over the v2
interface as described in Section 6.3. (If the VPC receives the LIE directly from an LIS, the
following requirements apply if a geodetic object is included.) Geo-coded location information
provided by the ERDB may also be used to populate the Position Information – Geographic Position
parameter. The contents of these geodetic parameters shall be mapped to the v-E2 interface
Geographic Position parameter described in Section 9.3.10.2 of NENA 05-001, with one exception,
noted below.



Version 2, August 11, 2010                                                Page 198 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   •   If the received geodetic location object information does not include altitude or uncertainty
       parameters, the VPC shall use the Type of Shape and Shape description corresponding to
       “Ellipsoid Point”
   •   (FUTURE, for further study) If the received geodetic location object information includes
       uncertainty and confidence but not altitude parameters, the VPC shall use the Type of Shape
       and Shape description corresponding to “Ellipsoid Point with Uncertainty.”
   •   If the received geodetic location object information includes altitude, with or without
       uncertainty parameters, and the altitude type is specified as “meters,” the VPC shall use the
       Type of Shape and Shape description corresponding to “Point with altitude and uncertainty.”
   •   The degrees of latitude shall be used to populate the Degrees of Latitude in the Type of
       Shape and Shape description parameter. If degrees of latitude are provided in a format
       different from the one supported on the v-E2 interface, or if the degrees of latitude are
       provided in a coordinate system different from the one supported on the v-E2 interface (i.e.,
       WGS84), the VPC shall convert the latitude information to a format suitable for coding of
       degrees of latitude on the v-E2 interface.
   •   The degrees of longitude shall be used to populate the Degrees of Longitude in the Type of
       Shape and Shape description parameter. If degrees of longitude are provided in a format
       different from the one supported on the v-E2 interface, or if the degrees of longitude are
       provided in a coordinate system different from the one supported on the v-E2 interface (i.e.,
       WGS84[35]), the VPC shall convert the longitude information to a format suitable for coding
       of degrees of longitude on the V-E2 interface.
   •   (Future) If an Uncertainty parameter value is included and available to the VPC, the VPC
       may use this information to populate the Uncertainty code and Confidence parameters of the
       Type of Shape and Shape description parameter.
   •   If an Altitude parameter is included, and the Altitude type is specified as “meters,” the VPC
       shall use its contents to populate the Altitude in the Type of Shape and Shape description
       used for Point with Altitude and Uncertainty. If uncertainty/confidence values are not
       available to the VPC, when an Altitude parameter is included, the value of K for the
       uncertainty code and confidence shall be populated with 0 to indicate “no information.” If
       Altitude Uncertainty and Confidence are included, the VPC shall use this information to
       populate the Altitude Uncertainty code and Confidence parameters in the Type of Shape and
       Shape description parameter. If Altitude uncertainty/confidence values are not available to
       the VPC, when an Altitude parameter is included, the value of K for the uncertainty code and
       confidence shall be populated with 0 to indicate “no information.”
   •   Exception Case - If an Altitude parameter is included, and the Altitude type is specified as
       “floor,” the VPC shall use the use its contents to populate the Location parameter contained
       in the Location Description parameter described in NENA 05-001, Section 9.3.16, subject to
       the additional requirements described in Section 6.11.2.9.




Version 2, August 11, 2010                                                Page 199 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


6.11.2.3 Position Information - Position Source Parameter
The VPC shall use the “Method” parameter included in the PIDF-LO to populate the Position Source
parameter. The v-E2 interface shall support the new codings of the Position Source referred in the
shown in Table 6-26. Values of this parameter can be used by the ESME to identify this call as a
VoIP call.
If the “Method” parameter is not included in the PIDF-LO, the VPC shall populate the Position
Source parameter with the value corresponding to “IP-Unknown.”
  Table 6-26. Mappings of “Method token” values of the PIDF-LO to codings of the Position
                   Source Parameter in the esposreq Response Message

         Location Object parameter                 Position          Position Source
         (PIDF-LO: “Method token**”                Source            parameter value
         Value)                                   parameter             meaning
                                                    value
                                                  (decimal)
         <Not provided in PIDF-LO>                   128        IP – Unknown
         Manual: entered manually by an              129        IP – Manual entry
         operator or user, e.g., based on
         subscriber billing or service location
         information
         DHCP: provided by DHCP (used for            130        IP - Network Assisted – (e.g.,
         wireline access networks, see                          via DHCP)
         802.11 below)
         Triangulation: triangulated from            131        IP – Network Assisted – RF
         time-of-arrival, signal strength or                    Derived (e.g., ToA,
         similar measurements                                   Triangulation)
         Cell: location of the cellular radio        132        IP – Radio Network Access
         antenna                                                Point (e.g., lat/lon of cellualar
                                                                tower or of 802.11
                                                                transceiver)
         802.11: 802.11 access point (used           132        IP – Radio Network Access
         for DHCP-based provisioning over                       Point (e.g., lat/lon of cellular
         wireless access networks)                              tower or of 802.11
                                                                transceiver)
                                                     133        IP - Radio Network Sector
                                                                (e.g. lat/lon of centroid of
                                                                cellular sector coverage
                                                                area, or centroid of 802.11
                                                                coverage area with
                                                                directional antennas)
         GPS: Global Positioning System              134        IP – GPS (e.g., GPS in the
                                                                handset)*
         A-GPS: GPS with assistance                  135        IP – A-GPS (e.g., network-
                                                                assisted GPS)*


Version 2, August 11, 2010                                                   Page 200 of 247
                                                                            NENA Interim VoIP Architecture for
                                                                            Enhanced 9-1-1 Services (i2)
                                                                            NENA 08-001 v2, August 11, 2010


             Location Object parameter                          Position                 Position Source
             (PIDF-LO: “Method token**”                         Source                   parameter value
             Value)                                            parameter                    meaning
                                                                 value
                                                               (decimal)
                                                                    136             Derived, via Transformation
                                                                                    (e.g. either Geo-Coding or
                                                                                    Reverse-Geo-Coding) 32

Note: The values for GPS and A-GPS are provided here separately in order for contextual distinction
that implemented systems may rely on (i.e. GPS fix for a VoIP emergency call).
** Methods Tokens assigned by the IANA can be found at
http://www.iana.org/assignments/method-tokens/

6.11.2.4 Callback Number
The Callback Number parameter shall be populated with an E.164 number that represents the
emergency caller in the i2 Solution. This Callback Number shall be derived by the VPC from the
Callback parameter of the Emergency Services Routing Request described for the v2 interface in
Section 6.3.

6.11.2.5 Emergency Services Routing Key
The VPC shall populate the Emergency Services Routing Digits Request Response parameter with
the Emergency Services Query Key received in the ESPOSREQ message and used by the VPC as a
key to obtaining the emergency call related information used in this response.

6.11.2.6 Generalized Time
The VPC shall populate the Generalized Time parameter with the time that the ESQK was allocated
to the current emergency call (with which it is associated and for which location information is being
provided).

6.11.2.7 Mobile Identification Number
The VPC may populate the Mobile Identification Number with the Main Telephone Number
(applicable in Multi-Line Telephone Systems) if one is provided for the emergency call. Otherwise,
this optional parameter can be omitted.

6.11.2.8 Company ID
The VPC shall populate this parameter with the name of the VoIP Service Provider, if available.

32 This position source parameter value can be used to indicate a geo-coded location.


Version 2, August 11, 2010                                                                     Page 201 of 247
                                                                             NENA Interim VoIP Architecture for
                                                                             Enhanced 9-1-1 Services (i2)
                                                                             NENA 08-001 v2, August 11, 2010


6.11.2.9 LocationDescription
The VPC shall populate the Location Description parameter with the appropriate data fields tagged
using the NENA version 4 XML tags as defined in the NENA 02-010, and as described in NENA
05-001, Section 9.3.16.
The VPC shall use the information obtained from the civic address location object to populate these
fields, using the mapping described in Table 6-27. The VPC shall use the information contained in
the <customer> field of the v2 esrRequest message to populate the <NAM> field with the Subscriber
name associated with the VEP.
  Table 6-27. Mappings of Civic Address Data Elements and Other Data Elements to Tagged
                          Fields in Location Description Parameter

         Location Object parameter                     Populated by             NENA XML 4.0 tag in Location
         (PIDF-LO: Civic Address                       the VPC                  Description parameter
         Type)
         PIDF-LO: Civil: HNO                                                    Location Description: <HNO>
         PIDF-LO: Civil: HNS                                                    Location Description: <HNS>
         PIDF-LO: Civil: PRD                                                    Location Description: <PRD>
         PIDF-LO: Civil: RD                                                     Location Description: <STN>
         PIDF-LO: Civil: STS                                                    Location Description: <STS>
         PIDF-LO: Civil: POD                                                    Location Description: <POD>
         PIDF-LO: Civil: A3                                                     Location Description: <MCN>
         PIDF-LO: Civil: A1                                                     Location Description: <STA>
         PIDF-LO: Civil: County Name 33                                         Location Description: <COI>
         PIDF-LO: Civil: LOC                                                    Location Description: <LOC>*
         PIDF-LO: Civil: FLR                                                    Include "FL<content>" in LOC
         (CAtype27)                                                             <content>*
         PIDF-LO: Civil: LMK                                                    Not supported.
                                                       NENA ID of the           Location Description: <CPF>
                                                       VSP
                                                       v2 <customer>            Location Description: <NAM> 34

*NOTE: This information shall be included in the contents of the <LOC> tagged field as follows:
     •    If included in the PIDF-LO, these fields shall be concatenated in the following order: Floor,
          Location (LOC).
     •    Each field shall be directly preceded by the indicated abbreviation (i.e., FL, LOC), and shall
          be separated from the next field by the character “~” (tilde).

33 The VPC must convert the received County Name to a FIPS County Code.
34 While incorporated in the Location Description container, the name here is not associated with the physical location or the
broadband connection, but rather the VoIP service subscriber name.


Version 2, August 11, 2010                                                                          Page 202 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


   •    If the information for a given field cannot be included completely (i.e., without truncating it),
        then the last (truncated) field to be included shall also end with the character “~” (tilde) to
        indicate that it has been truncated.
The VPC operator and the E9-1-1 Service Provider/Database operator should determine if an
administrative ESN value can be transmitted over the v-E2 interface without causing any detrimental
affects to the 9-1-1 system.
If supported, the VPC shall use the administrative ESN received from the ERDB to populate the
ESN tagged field in the Location Description parameter. If an administrative ESN is not available
for the call, then the VPC may use the value of the Routing ESN to populate the ESN, or shall omit
the ESN tagged value from the Location Description parameter.

6.11.3 v-E2 Message flows, Key Scenarios and Semantics
The following call flow shows a 9-1-1 call where the CS interacts with a VPC to obtain the
necessary 9-1-1 call routing information and then uses the received routing information to route the
call to the ESGW. The ESGW routes the call forward to the SR which delivers it to the PSAP. The
PSAP queries an ALI database for location information. The ALI database queries the VPC for
location information and passes it to the PSAP. Messages which pertain to the v-E2 interface are
shown in bold red.




Version 2, August 11, 2010                                                   Page 203 of 247
                                                                                            NENA Interim VoIP Architecture for
                                                                                            Enhanced 9-1-1 Services (i2)
                                                                                            NENA 08-001 v2, August 11, 2010



               UA                       CS                       VPC                    ESGW                      SR                        PSAP                    ALI

                        1. INVITE
                     (911, PIDF-LO,
                      callid1, SDP1)

                      2. 100 Trying          3. esrRequest
                                         (PIDF-LO, [customer],
                                               [callback])

                                            4. esrResponse
                                         (ert/esgwri, esqk, lro)

                                           5. INVITE
                                         (callid1, esgwri, esqk,
                                         [callback], SDP1)
                                                                                                  6. IAM
                                                                                             (esqk, [callback])
                                                                         7. 100 Trying
                                                                                                  8. ACM
                                                                                                                        9. Call Delivery
                                                                                                                        esqk, [callback])
                                                                      10. 183 Session
                                                                     Progress (SDP2)
                     11. 183 Session
                     Progress (SDP2)
                                                                                                                        12.Audible Ringing


                           Early Media: Audible Ringing Delivered
                                                                                                                       13. PSAP Answers
                                                                                                 14. ANM
                                                                       15. 200 OK (SDP3)
                    16. 200 OK (SDP3)

                        17. ACK
                                                    18. ACK



                                                          Voice communication established
                                                                                                                                                     19. ALI Query
                                                                                                                                                   (esqk or callback)

                                                                                                                                                20. ESPOSREQ
                                                                                                                                               (esqk, [callback])

                                                                       21. esposreq
                                                                     (location, callback)

                                                                                                                                               22. ALI Response
                                                                                                                                                (Location info)
                                                                                                                       23. PSAP releases
                                                                                                 24. REL
                                                                          25. BYE
                        26. BYE

                       27. 200 OK
                                                 28. 200 OK
                                                                                                 29. RLC
                                                   30. esct
                                             (esqk, esgw, callid1)

                                                 31. esctAck
                                                (vpc, callid1)


                                                                 Figure 6-17 v-E2 Call Flow




Version 2, August 11, 2010                                                                                               Page 204 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


   1. A caller invokes an emergency call by dialing 9-1-1. The VEP sends a SIP INVITE to the
       CS. In this example, location information (i.e., location-by-value) is included in the SIP
       INVITE (shown as PIDF-LO) along with the SDP offer (shown as SDP1).
   2. The CS responds with a SIP 100 Trying message to the VEP.
   3. The CS uses the information received in the SIP INVITE to construct a v2 esrRequest to the
       VPC.
   4. The VPC queries the appropriate ERDB (step not shown) based on the location and
       constructs a v2 esrResponse message back to the CS with routing instructions received from
       the ERDB. There are two options for what the VPC returns to the CS, depending on the
       arrangement in place with the CS:
       a. The VPC is responsible for the ERT-to-ESGWRI mapping. Based on the ERT received
           from the ERDB, the VPC allocates an ESQK, determines the routing number (ESGWRI)
           for the call, and provides this information to the CS along with the LRO. In this case, the
           CS will use the ESGWRI directly for route selection.
       b. The CS is responsible for the ERT-to-ESGWRI mapping. Based on the ERT received
           from the ERDB, the VPC allocates an ESQK for the call and provides the ESQK and the
           ERT information to the CS along with the LRO. In this case, the CS will use internal
           ERT-to-ESGWRI mappings to select the proper route.
   5. If the CS received an ERT, it translates the ERT to an ESGWRI. Otherwise, it uses the
       ESGWRI received from the VPC to determine the outgoing route to the ESGW. The CS
       sends a SIP INVITE to the ESGW with the SDP offer (shown as SDP1) and the ESGWRI.
       The CS also includes an ESQK in the INVITE, sent as a URI in a PAI header. The callback
       number is also sent, as a parameter in the same PAI header.
   6. The ESGW uses the ESGWRI in the received INVITE message to determine the outgoing
       route to the SR. In this example, the selected trunk group is an SS7 trunk group, so the
       ESGW sends an SS7 Initial Address Message (IAM) to the SR. Depending on trunk group
       provisioning, the IAM with either contain just the ESQK, or both the callback number and
       the ESQK.
   7. The ESGW also responds with a SIP 100 Trying message to the CS.
   8. After the SR seizes the outgoing MF trunk and receives a wink back, it returns an SS7
       Address Complete Message (ACM) to the ESGW, indicating that interworking was
       encountered (with Called Party’s Status set to “no indication”).
   9. The call is delivered to the PSAP with the ESQK and/or the callback number, depending on
       local signaling arrangements.
   10. The ESGW signals a SIP 183 Session Progress back to the CS.
   11. The CS forwards the SIP 183 Session Progress to the VEP.




Version 2, August 11, 2010                                                  Page 205 of 247
                                                                            NENA Interim VoIP Architecture for
                                                                            Enhanced 9-1-1 Services (i2)
                                                                            NENA 08-001 v2, August 11, 2010


  Upon receiving complete ANI information, the PSAP signals the attendant and returns audible
ringing to the calling party 35. Simultaneously, upon return of the 183 Session Progress messages,
 one-way communication is established between the ESGW and the UA is established to facilitate
                          delivery of early media/audible ringing to the UA.
   12. The PSAP call taker answers the call and the off-hook signal is conveyed to the SR.
   13. The SR sends an SS7 Answer Message (ANM) to the ESGW.
   14. The ESGW sends a SIP 200 OK message to the CS with its SDP answer (shown as SDP2).
   15. The CS forwards the SIP 200 OK message with the ESGW SDP answer to the VEP.
   16. The VEP returns a standard SIP ACK to the CS to acknowledge receipt of the SIP 200
       response and acceptance of the SDP answer.
   17. The CS forwards the SIP ACK to the ESGW to confirm acceptance of the SDP answer.
  The media streams are established. The caller and the PSAP call taker can now communicate.
   18. The PSAP launches a location query to the ALI database. The query contains either the
       ESQK or the callback number, depending on local arrangements. (Note that the ALI query
       can be sent anytime after the call is delivered to the PSAP [Step 9], and likely occurs shortly
       after voice communication is established.)
   19. The ALI service formulates an ESPOSREQ (request) message and sends it over the v-E2
       interface to the VPC. Depending on local arrangements, the ESPOSREQ will either contain
       just the ESQK, or the callback number and the ESQK.
   20. The VPC responds by sending an esposreq (response) message over the v-E2 interface to the
       ALI service. The esposreq includes location information and the callback number.
   21. The ALI service provides the location and callback information to the PSAP.
   22. Some time later, the call is released (the call may be terminated from either direction
       however, in this example, the PSAP hangs-up first).
   23. The SR sends an SS7 Release Message (REL) to the ESGW.
   24. The ESGW generates a SIP BYE and sends it to the CS.
   25. The CS forwards the SIP BYE message to the VEP.
   26. The VEP terminates the call then confirms reception of the call termination by sending back
       a SIP 200 OK message to the CS.
   27. The CS forwards the SIP 200 OK message to the ESGW.
   28. The ESGW sends an SS7 Release Complete Message (RLC) to the SR, completing the
       release of the call.
   29. The CS constructs a v2 esct message and sends it to the VPC so it can release the ESQK and
       return it to the ESQK pool.
   30. The VPC responds with a v2 esctAck message back to the CS to acknowledge.

35 Note that in some implementations, the SR provides audible ringing to the caller during the outpulsing of the ANI information to
the PSAP.


Version 2, August 11, 2010                                                                         Page 206 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


6.11.4 v-E2 Interface Security
The v-E2 interface will need to operate in a variety of network environments, some trusted, and
some not, as described previously. The v-E2 interface is TCP/IP-based and should be used with a
suitable security mechanism as defined in Section 4. When the connection between the ALI DB and
the VPC is not a trusted network, both the ALI DB and the VPC are expected to be protected with
IPsec or TLS, and thus require a certificate rooted in VESA. Even in a trusted network, TLS
protection is advisable. Mutual authentication is required when cryptographic security is deployed.




Version 2, August 11, 2010                                                Page 207 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010



7   Roles and Responsibilities
The organizational components of the i2 solution refer to those entities, commercial or public, which
operate the various network elements in this architecture. For example, there are those entities that
are responsible for the operation of a Call Server, those entities that are responsible for the operation
of an ESGW, and those entities that are responsible for the operation of a Selective Router. In
practice these entities may have responsibility for one or more instances of these network elements
and may have a scope which is considerably larger than just the operation of i2 defined network
elements. Thus, the entities defined here are logical ones – the key in recognizing whether any of the
roles associated with these entities apply to any given real world party, is whether that party has
specific ownership and responsibility for the effective operation of the corresponding network entity.
Similarly the implementation of a specific logical network element may be such that various
components of the implementation are shared by more than one entity. In this case the owning
entities are jointly responsible and individually answerable for the effective operation of the network
element constituted by that implementation.
    •   Caller – Operates the device from which the call is made and initiates the call to emergency
        services.
    •   VoIP Service Provider (VSP) – Operates the network equipment that provides call
        processing for subscribers.
    •   Redirect Operator – Operates Redirect Server(s).
    •   Routing Proxy Operator – Operates Routing Proxy server(s).
    •   LIS Operator – Operates the LIS associated with the IP access network used by the callers.
    •   ESGW Operator – Operates emergency service gateway(s).
    •   SR Operator – Operates the Selective Router(s) corresponding to specific local exchange
        areas.
    •   PSAP Operator – Operates the Public Safety Answering Points in a particular county, state,
        or other regional jurisdiction.
    •   ALI Operator – Operates the Automatic Location Identification infrastructure used to
        provide caller information associated with a pANI offered in a query from a PSAP.
    •   VPC Operator – Operates VPC network element(s).
    •   Credential Authority – An authority responsible for supporting the infrastructure to assign
        and revoke electronic digital certificates to i2 network entities.
    •   Routing Number Authority (RNA) – An authority responsible for distributing ranges of
        numbers to network operators for the purposes of call routing and query steering.
    •   MSAG Source – Is responsible for defining, maintaining and publishing the Master Street
        Address Guide for a given coverage area.
    •   Validation Database (VDB) Operator – An operator that provides location information
        validation services to LIS operators and other users.




Version 2, August 11, 2010                                                   Page 208 of 247
                                                                          NENA Interim VoIP Architecture for
                                                                          Enhanced 9-1-1 Services (i2)
                                                                          NENA 08-001 v2, August 11, 2010


    •     Emergency Service Zone (ESZ) Routing Database (ERDB) Operator – An operator that
          supports the real time routing server that can resolve location information to emergency
          service zone route at the request of a VPC.
    •     Root Discovery Operator (RDO) - The operator that supports the well known root database
          from which the URI of the correct VDB or ERDB can be determined based on regional
          location information.
    •     9-1-1 Administrator The administrative jurisdiction of a particular 9-1-1 system. This could
          be a county/parish or city government, a special 9-1-1 or Emergency Communications
          District, a Council of Governments, an individual PSAP or other similar body.

The different organizational entities, overlaid on their corresponding functional entities, are shown in
the following diagram.


                                                    ESGW
                                                   Operator                                           SR
                                                                                                    Operator
                                                   ESGW
                                                                                        Selective
                                                                                         Router
                                                         Proxy
                                                        Operator            VPC
                          VSP
    Routing                                   Proxy                        Operator
    Number                                    Server
    Authority            Call                                                             PSAP
                        Server                                                                       PSAP
                                                                           VPC
  ESQK                                                                                              Operator
  Source
                                          Redirect
                                           Server
           Credential                                                                      ALI
                                       Redirect
           Authority                   Operator
                                                               ERDB                            ALI
 Certificate                                                  Discovery      ERDB            Operator
  Source
                                                                 Root         ERDB
                                                              discovery      Operator
                                 Client
                                 Device                        operator
                                                                                                 MSAG
                                          Caller
    VDB                                                                                       MSAG
  Discovery                                                               VDB                 Source
                                                                             VDB
           Root                  LIS
                                                                            Operator
        discovery
                                             LIS
        operator
                                           Operator


                                            Figure 7-1 i2 Organizational Entities


Version 2, August 11, 2010                                                               Page 209 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


7.1       Responsibilities

7.1.1      Caller
The caller is responsible for initiating the emergency call by inputting the appropriate emergency
service number (e.g., “9-1-1”). Arbitrary VoIP devices utilized on arbitrary access networks may
not provide sufficient functionality to be properly supported by the i2 network and last resort
routing, or even failure to deliver the call to any emergency operator, may occur.
The caller may also be known as the subscriber. The caller is the individual initiating the actual
emergency call. The subscriber is the individual who nominally owns the device and service
subscription. The terms “caller” and “subscriber” may be used relatively interchangeably in the
document text depending on context.

7.1.2      VoIP Service Provider
The VoIP Service Provider (VSP) operates the Call Server/Proxy which is directly utilized by the
caller to initiate the emergency call on the v1 interface. It is the VSP’s responsibility to ensure that
its call server(s) can appropriately identify that an emergency call has been invoked by the caller and
to initiate appropriate call handling. This appropriate handling includes the following:
      • Provide subscription-based calling party information including:
            o Calling party number
            o Customer name
    • Ensure that its call server(s) are correctly configured to identify the correct VPC, ESGW,
        redirect, or proxy servers depending on options used. VSPs are responsible for routing
        emergency calls towards the emergency service network using one of the following options:
            o Identify and query an appropriate VPC to obtain routing information for the call and
                direct the call to the ESGW indicated by that routing information through support of
                the v2 and v4 interface definitions.
            o Identify an appropriate redirect server and direct the call toward it and subsequently
                route it as determined by that redirect server utilizing the v5 and v4 interfaces.
            o Identify an appropriate proxy server and direct the call to that server utilizing the v6
                interface.
In configurations where VSPs support v4 interfaces to ESGWs and choose to provide their own
ERT-to-ESGWRI mapping, VSPs will have to coordinate the mapping with ESGW operators. VSPs
are responsible for ensuring their call server(s) have access to the other network entities, whichever
options are used, such that all geographic areas from which their callers can initiate calls and which
are accessible via the i2 architecture, are serviced. This may be by their own means or by the
establishment of commercial or other arrangements with the operators of VPC, redirect, proxy, and
ESGW server entities.




Version 2, August 11, 2010                                                   Page 210 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


7.1.3   Redirect Operator
The redirect operator maintains redirect server(s) and provides access to authorized call servers
which are in receipt of an emergency call using the v5 interface definitions. The redirect operator is
responsible for ensuring that redirect server equipment has access to VPC functionality that can
provide routing direction for all areas from which their VSP user base can originate calls.

7.1.4   Routing Proxy Operator
The Routing Proxy operator maintains proxy server(s) and provides access to authorized call servers
which are in receipt of an emergency call using the v6 interface definitions. The Routing Proxy
operator is responsible for ensuring that it can determine the appropriate routing information by
accessing relevant VPC functionality, and that it has access to the necessary ESGW infrastructure to
deliver calls for those areas.

7.1.5   LIS Operator
This operator is associated with a particular IP network access area. The LIS operator is responsible
for providing an operating infrastructure which supports requests for location information by
individual end user devices (UA) and/or properly credentialed network elements (e.g. VPC) over the
v0 and v3 interfaces respectively. The LIS operator is also responsible for providing technologies
and processes which ensure that the geographical location information provided with respect to users
is correct to within a specified range of accuracy. Where the location is effectively constrained to a
specified range, as determined by other standards, regulatory rulings, contract, etc., LIS operators are
responsible for providing a Civic Address corresponding to that location when one is applicable. LIS
operators are responsible for ensuring that this Civic Address information is properly and
independently validated with an appropriate VDB to ensure successful resolution of destination
when that address is used to route emergency calls.

7.1.6   ESGW Operator
The ESGW operator provides the equipment to interface between the IP network and the legacy
circuit switch-based emergency network. The ESGW operator is responsible for providing sufficient
and reliable capacity for the delivery of emergency calls to the Selective Router network elements in
their area of coverage. ESGW operators are responsible for ensuring that calls are placed on the
correct trunks based on the ESGWRI provided in emergency call setup signaling and in accordance
with the guidance of the corresponding SR operator as to which trunks correspond to which values
of routing information. ESGW operators are responsible for providing the appropriate signaling (i.e.,
MF or SS7, and appropriate number of digits (i.e., 10-digits [ESQK only] or 20-digits [ESQK +
callback number]) for the trunk groups over which emergency calls are to be delivered to an SR,
based on input from the SR operator. ESGW operators are responsible for ensuring that the call
server operators to whom they provide service, or VPC operators, if the translation from ERT to
ESGWRI is to be performed by the VPC, are informed which ESGWRIs are applicable to which
ESGW instances that they operate. The ESGW operator is also responsible for ensuring that the


Version 2, August 11, 2010                                                   Page 211 of 247
                                                            NENA Interim VoIP Architecture for
                                                            Enhanced 9-1-1 Services (i2)
                                                            NENA 08-001 v2, August 11, 2010


infrastructure that they operate provides the correct default, contingency, and congestion routing
mechanisms as specified by the SR operators, PSAP operators or other authorities as applicable to
the area of service. ESGW operators are also responsible for maintaining a call record system which,
upon request from the SR operator, will allow them to identify the call server operator from which a
given call originated, identified by time and ESQK. They must support the necessary mechanisms to
block delivery of calls from specific call server operators to specific destinations at the request of SR
operators.

7.1.7   Selective Router (SR) Operators
These operators provide the infrastructure to deliver calls arriving on trunks from ESGW network
elements to the correct serving PSAP based on the routing information in the call setup signaling.
They provide the equipment to adapt to the signaling and voice bearer media (e.g. CAMA) used by
the PSAP CPE. This equipment maintains the call state between the SR and the PSAP and responds
appropriately to mid-call commands such as call transfer requests to emergency responders. The SR
operator is responsible for ensuring that correct default, contingency, and congestion call routing
functions are configured for all incoming ESGW trunks. They are responsible for ensuring that
ESQK entries in the Selective Routing Database (SRDB) are configured to support call delivery to
the correct PSAP, selective transfer, etc. based on the correct ESN associations. SR operators are
responsible for working with the VPC operator either directly or through the MSAG administrator to
ensure that ESQK block assignments are correctly associated with the appropriate ERT. SR
operators are responsible for providing the correct information associated with unique routing data to
ESGW operators that connect to the SR(s) such that those operators can provision the correct trunk,
default, contingency, and congestion routing data against each ESGWRI in their systems.

7.1.8   PSAP Operators
PSAP operators provide the call center resources which take and assess emergency calls to
determine appropriate handling of the call. They are responsible for connecting the caller to the
correct first responder organizations when necessary. They are responsible for ensuring that they
operate the necessary CPE with associated staffing capacity and reliability to serve the volume of
calls originating in their serving area. They are responsible for ensuring that they have the necessary
CPE to query ALI equipment and receive and display call related information including the caller’s
location.
PSAP operators provide direction in terms of the correct default routing for calls that the network
needs to support. They may also have a role in specifying the necessary ESQK block allocation sizes
on a per ESZ basis.

7.1.9   ALI Operator
ALI operators provide the infrastructure to PSAP operators to retrieve the location, ESN
information, and other call related information based on the query key that was provided for the call.



Version 2, August 11, 2010                                                    Page 212 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


The ALI operator is responsible for providing an electronic query interface to PSAP operator CPE.
All valid query keys presented on that interface must be matched to the related call information,
including location, and presented back to the PSAP. In the case of i2 related requests, the local ALI
operator must ensure that the request is steered to the appropriate VPC over the v-E2 interface. ALI
operators are responsible for providing a reliable real-time infrastructure which can identify the
correct VPC to which to steer the query based on the presented ESQK, format a valid ESPOSREQ
message and to receive and process the esposreq response. The ALI operator is responsible for
ensuring that the ALI database maintains correct ESQK-to-VPC steering data such that any valid
ESQK presented as a query key can be matched to an appropriate VPC. The steering data must be
sourced from the VPC operator. ALI operators are responsible for maintaining records of queries to
facilitate historical analysis including identification of calls by time and ESQK assignment, and
content and status of request/response messages as they occurred.
ALI operators are responsible for ensuring that the responses received from the VPC are correctly
formatted and presented to the PSAP CPE.

7.1.10 VPC Operator
The VPC operator provides robust infrastructure which allows the routing information for a given
emergency call to be determined based on the location of the caller, and maintains the call
information, caller location information, and corresponding routing information, based on the
information received from the Call Server/Proxy via the v2 interface, from the ERDB via the v8
interface, and from the LIS via the v3 interface (if applicable). In configurations where VPCs
provide ERT-to-ESGWRI mapping, VPCs will have to coordinate the mapping with ESGW
operators. The VPC operator will be responsible for having mechanisms in place to respond to ALI
queries for location information. VPC operators will also be responsible for ensuring that any
MSAG-valid formatted civic location information or geo-coded location information received from
the ERDB in response to a routing query is stored at the VPC for inclusion in the response to the
ALI database. In addition, they are responsible for ensuring they have the infrastructure in place to
direct location queries to any applicable LIS interface when presented with a location key.
The VPC operator is responsible for ensuring that the VPC equipment supports compatible E2
interface capabilities to support ALI queries. The VPC operator must ensure that the necessary
processes and mechanisms are in place to obtain ESQK allocations from the RNA, to determine the
correct ERT-to-ESQK sub-block associations, and to make the E2 interface connections accessible
from authorized ALI operators. Where it is required to do so, the VPC operator must also ensure that
the ESQK allocations appropriate to each of its VPC instances is communicated to the ALI operator
in order that they can maintain a correct VPC steering database.
VPC operators are responsible for ensuring that any PSAP policies on call handling are applied with
respect to default routing when a location information source cannot be verified, or where location
information type (geodetic and/or civic) or content is limited. The VPC operator is responsible for
ensuring that last resort routing data is defined and that equipment is configured to provide this



Version 2, August 11, 2010                                                  Page 213 of 247
                                                                                    NENA Interim VoIP Architecture for
                                                                                    Enhanced 9-1-1 Services (i2)
                                                                                    NENA 08-001 v2, August 11, 2010


information in response to v2 interface queries when no more applicable route can be identified for
the call.
VPC operators are responsible for maintaining 24x7 telephone response service such that PSAP
operators can contact them for details of a particular call in the event of failure of an ALI query or in
order to determine the identity of the originating call server operator and to facilitate communication
with that operator in the event that assistance is needed to make contact with the caller. The VPC
operator is also responsible for maintaining historical records of all calls such that similar
investigations can be conducted at arbitrary points in the future.

7.1.11 Credential Authority
The credential authority is responsible for providing certificates to appropriately qualified call
server, VPC, ESGW, LIS, ERDB, and VDB operators. These digital certificates are to be provided
as and when they are needed to ensure that authentication can occur over the i2 defined interfaces
and so that location information can be digitally signed and checked for source of origin by network
elements within the i2 architecture.
It is the responsibility of credential authorities to ensure that certificates are securely generated,
distributed, and maintained. Where necessary, they are also responsible for the withdrawal and
cancellation of certificates.
Two types of credential authority are defined – VESA and the delegate authorities.



                                                                            Certificate
                                                                             Source
                                                             VESA
                              Credential
                              Authority

                                                                                          Delegation



                                           Delegate                   Delegate                 Delegate
                                           Credential                 Credential               Credential
                                           Authority                  Authority                Authority

                                Certificate             Certificate                       Certificate
                                 Source                  Source                            Source




    Figure 7-2 Organizational Decomposition – VESA and Delegate Credential Authorities



Version 2, August 11, 2010                                                                                  Page 214 of 247
                                                              NENA Interim VoIP Architecture for
                                                              Enhanced 9-1-1 Services (i2)
                                                              NENA 08-001 v2, August 11, 2010


7.1.11.1 Valid Emergency Services Authority (VESA)
This organization is the root source of all certificates. It is responsible for identifying and issuing
certificates either directly to end using entities or through delegate credential authorities. It is
responsible for ensuring that any delegate credential authority that it identifies is properly qualified
and operating with sufficient security and legitimacy to perform this role. Where VESA issues
certificates directly to end users, it also has the responsibilities of a delegate credential authority in
those cases.
VESA is also responsible for maintaining a master revocation list for all end entities that have had
their certificates revoked for any reason. It must provide a means for the delegate credential
authorities to populate the list. This list must be made available electronically to all organizational
entities which need to validate data based on VESA root certificates.

7.1.11.2 Delegate Credential Authorities
A delegate credential authority issues certificates, which are derived from VESA certification. It is
responsible for issuing certificates to the operators of network entities that utilize VESA certificates
for the exchange of authenticated data on the i2-defined interfaces.
Delegate credential authorities are responsible for ensuring that the organizations involved in the i2
architecture are properly equipped in infrastructure and operating processes to meet the demands of
reliable emergency call delivery and processing from VoIP networks before issuing certificates.
They should operate an appropriate process of assessment and renewal audit, in order to assess these
organizations and validate their suitability to participate in the i2 network. Part and parcel of this
responsibility is the generation and provision of electronic digital certificates which are required for
the purposes of authentication and authorization between the various network entities comprising the
i2 architecture.
Delegate credential authorities are also responsible for identifying when a given certificate needs to
be revoked (where an entity no longer meets the requirements of eligibility for the certificate – for
example, when it ceases operation). When a certificate is identified as being revoked or expired, this
information must be communicated to the VESA so the certificate can be included in the master
revocation list.
Examples of delegate credential authorities may be PSAP operators, state emergency authorities, or
regional 9-1-1 service providers.

7.1.12 Routing Number Authority (RNA)
The RNA is responsible for distributing ranges of numbers from a reserved number space to
properly credentialed network element operators for the purposes of call routing and query steering.
The RNA issues multiple discrete blocks of ESQK allocations to VPC operators from a reserved
numbering space defined for this purpose. The routing number authority is responsible for ensuring
the uniqueness and correctness of the numbers allocated and the corresponding information


Version 2, August 11, 2010                                                      Page 215 of 247
                                                                               NENA Interim VoIP Architecture for
                                                                               Enhanced 9-1-1 Services (i2)
                                                                               NENA 08-001 v2, August 11, 2010


associated with each number. They are responsible for ensuring that the VPC instances against
which allocations are made are properly credentialed and approved to provide emergency call
routing service. They are also responsible for polling these organizations to ensure that they are still
credentialed and, where necessary, for reclaiming ESQK allocations from VPC operators as VPCs
go out of service.

7.1.13 Master Street Address Guide (MSAG) Source
The MSAG source represents the organizational components that are responsible for performing the
division of an emergency coverage area into the individual emergency service zones (ESZ), and the
association of ESN lists to those zones. The ESZ must be defined in terms of civic address
boundaries incorporating the necessary postal and 9-1-1 field formatting. The definitions may further
support the division by geo-spatial boundaries 36. The MSAG source is required to make this
information available to authorized ERDB operators, VDB operators, PSAP and SR operators and
any other concerned parties who require this fundamental information. The MSAG source is
expected to have the necessary infrastructure in place to ensure that the MSAG data is kept current
and synchronized and that updates are made available in an electronic form to authorized parties in a
timely fashion. The MSAG source can be devolved into two specific organizational entities.




                                                                         MSAG
                                                         MSAG             Data
                                                          DB MSAG Source
                                                       MSAG                     MSAG
                                                      Operator                  Admin




                          Figure 7-3 Organizational Decomposition - MSAG Source

7.1.13.1 MSAG Administrator
The MSAG administrator is the component of the MSAG source that is responsible for determining,
documenting, and maintaining the actual MSAG data. This includes the local level activities to

36 Note that in order to support future devices that may only be able to be provided location as a geodetic location (e.g., devices that
support IETF RFC 3825 or mobile wide area wireless Internet access devices), there needs to be a geospatial boundary equivalent of
the MSAG. As in the case of cellular, the logical ESZ boundary may be of lower resolution, for example it may be the PSAP
boundary, in which case the ESN associated with this logical ESZ would indicate "query caller" as it does for cellular telephony
access.



Version 2, August 11, 2010                                                                            Page 216 of 247
                                                          NENA Interim VoIP Architecture for
                                                          Enhanced 9-1-1 Services (i2)
                                                          NENA 08-001 v2, August 11, 2010


understand ESZ boundary break downs and associated ESN lists. The MSAG Administrator is
responsible for maintaining the civic data in the MSAG. The MSAG Administrator is also
responsible for creating and maintaining the geo-spatial representation of ESZ boundaries. They are
responsible for liaising with the SR operators in the area of coverage to assist the SR operators in
determining which ERT values correspond to the ESZ allocations. They provide the data to the
MSAG operator for the actual electronic storage and distribution of the MSAG data.

7.1.13.2 MSAG Operator
The MSAG operator maintains the database equipment and infrastructure that supports the access
and retrieval of the MSAG data by authorized parties. They must provide the necessary
infrastructure for the MSAG administrator to ensure that the data can be updated. They must ensure
that the database itself remains reliable, uncorrupted, and secure from unauthorized access. The
MSAG Operator that provides access to the civic data of the MSAG may be different from the
MSAG Operator that provides access to the geo-spatial ESZ boundary data for the MSAG.

7.1.14 Validation Database (VDB) Operator
The VDB operators are responsible for providing the service by which LIS operators and other
authorized categories of users in their area of operation can submit access network location
information over the v7 interface for validation. Validation checks will ensure that the location
information will successfully key into the current MSAG in support of call routing. VDB operators
are responsible for providing an effective electronic means of performing validation and providing
assistance in correcting non-valid information. They must ensure that the validation occurs against
the current version of the MSAG. They are responsible for ensuring that the root discovery operator
is informed of the availability of their service and the regional coverage it provides to support
reliable discovery by users. When changing the URI of their infrastructure, they are responsible for
ensuring that old URIs are maintained for an overlap period and the RDO is informed of the
associated expiry and activation times.
The VDB operator should liaise with neighboring operators and resolve areas of overlap based on
regional coverage as identified in the root discovery information (see section on RDO).

7.1.15 Emergency Routing Database (ERDB) Operator
The ERDB operators are responsible for ensuring that reliable infrastructure with the necessary
performance to support real time routing queries over the v8 interface is available to authorized VPC
operators. They must ensure that the routing queries can occur using either the civic address or
geodetic boundary information contained in the MSAG that corresponds to the location in the query.
They must also support default routing procedures consistent with the policies of the associated 9-1-
1 Authority.
The ERDB operator is responsible for working with SR operators, PSAP operators and other parties
as necessary to ensure that ESZ boundaries are associated with correct ERT values that will be used
as the basis of call routing and that the correct ERT is provided in response to a routing request.

Version 2, August 11, 2010                                                 Page 217 of 247
                                                           NENA Interim VoIP Architecture for
                                                           Enhanced 9-1-1 Services (i2)
                                                           NENA 08-001 v2, August 11, 2010


They are responsible for ensuring that the US postal address format for civic address keying of the
routing database has a corresponding correct MSAG format for providing to the VPC in the v8
interface routing response.
They are responsible for ensuring that the root discovery operator is informed of the availability of
their service and the regional coverage it provides in order that they can be reliably discovered by
users. When changing the URI of their infrastructure, they are responsible for ensuring that old URIs
are maintained for an overlap period and the RDO is informed of the associated expiry and
activation times.
The ERDB operator should liaise with neighboring operators and resolve areas of overlap based on
regional coverage as identified in the root discovery information (see section on RDO). That is,
where ambiguity may arise in the root discovery data because of sub-municipality splits in ERDB
operator coverage, the operator may make arrangements to proxy routing requests for these areas of
overlap. The ERDB operators are responsible for maintaining records of all routing requests
including results and status against time and the identity of the requesting VPC entity.
Note that trunk group configurations at the ESGW are transparent to the ERDB.

7.1.16 Root Discovery Operator (RDO)
This is a singleton organizational entity in the architecture. That is, it is assumed that the functions
supported by this entity can be accessed by a single well known network address (URI). The RDO is
responsible for maintaining and making available the identities of the key VDB and ERDB functions
in the network. This information is to be maintained as current and made available to all requesting
entities. The RDO is responsible for ensuring that updated versions of the data with specific
activation and expiry times are available. New versions of data must always be made available
before current versions expire. The RDO is not responsible for discovering ERDB and VDB
operators itself, but it is responsible for providing the means to have discovery information reliably
communicated by those entities in an electronic form. The RDO is responsible for consolidating the
discovery information as received by all VDB and ERDB operators, negotiating coordinated
activation and expiry intervals, and making this consolidated information available for access over
the v9 interface. The RDO can be organizationally devolved into the ERDB RDO and the VDB
RDO as these functions have discrete user bases and separate root URI values may be assigned to
each function.

7.1.17 9-1-1 Administrator
The 9-1-1 Administrator represents the administrative jurisdiction for a particular 9-1-1 system. This
could be a county/parish, city or state government, a special 9-1-1 district, an Emergency
Communications District, a Council of Governments, an individual PSAP or other similar body. In
addition to its other responsibilities, the 9-1-1 Administrator is responsible for ensuring that 9-1-1
service is made available to users of NG9-1-1 services in accordance with this NENA standard.
The Role and Responsibilities of the 9-1-1 Administrator include:


Version 2, August 11, 2010                                                   Page 218 of 247
                                                         NENA Interim VoIP Architecture for
                                                         Enhanced 9-1-1 Services (i2)
                                                         NENA 08-001 v2, August 11, 2010


   •   Establish administrative process/implementation plan for accommodating VoIP Service
       Providers, including VPC and ESGW operators.
   •   Identify and describe the jurisdictional boundary and point of contact for each jurisdiction
   •   Designation/Selection of ERDB/VDB operator(s)
   •   Provide common point between MSAG operator(s) and VDB/ERDB operator(s)
   •   Ensure distribution of MSAG data to authorized users (either themselves or their designated
       agent)
   •   Providing geodetic data to authorized users (either themselves or their designated agent)
   •   Establish trunking criteria for ESGW operators and ensure access to selective router(s)
   •   Establish default routing criteria, including CRNs for PSAPs
   •   Review/approve ESQK numbering resource requests from VPC operators
   •   Ensure timely response to new VPC/VSP/ESGW deployments
   •   Coordinate testing for VPC/VSP deployments, either themselves or their designated agent
       provides this function
   •   Ongoing quality control interaction with VPCs, ESGWs, VSPs and E9-1-1 System Service
       Providers (SSPs).




Version 2, August 11, 2010                                                Page 219 of 247
                                                        NENA Interim VoIP Architecture for
                                                        Enhanced 9-1-1 Services (i2)
                                                        NENA 08-001 v2, August 11, 2010



8   Recommended Reading and References
This issue contains references to documents which were “work in progress” (e.g., Internet Draft at
the IETF) at the time of writing. This document may be revised as these references stabilize.
[1] IETF RFC 1032, Establishing a Domain – Guidelines for Administrators, M. Stahl, November
     1987.
[2] IETF RFC 1033, Domain Administrators Operations Guide, M. Lottor, November 1987.
[3] IETF RFC 1035, Domain Names – Implementation and Specification, P. Mockapetris,
     November 1987.
[4] IETF RFC 2131, Dynamic Host Configuration Protocol, R. Droms, March 1997.
[5] IETF RFC 3261, SIP: Session Initiation Protocol, J. Rosenberg et al, June 2002.
[6] IETF RFC 3825, Dynamic Host Configuration Protocol Option for Coordinate-based Location
     Configuration Information, July 2004
[7] IETF RFC 4776, Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
     Civic Addresses Configuration Information, H. Schulzrinne, November 2006.
[8] IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, J. Peterson, December
     2005
[9] Void
[10] Void
[11] NENA 02-010, NENA Standard Data Formats for ALI Data Exchange & GIS Mapping,
     Version 8.2, June 10, 2009
[12] IETF Internet Draft, Location Conveyance for the Session Initiation Protocol, J. Polk & B.
     Rosen, draft-ietf-sipcore-location-conveyance
[13] NENA 05-001, Implementation of the Wireless Emergency Service Protocol E2 Interface, Issue
     1, December 2, 2003
[14] IETF RFC 2313, PKCS #1: RSA Encryption, Version 1.5, March 1998
[15] IETF RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate
     Revocation List (CRL) Profile, April 2002
[16] NIST FIPS PUB 197, Advanced Encryption Standard, November 2001
[17] IETF RFC 4301, Security Architecture for the Internet Protocol, S. Kent & K. Seo, December
     2005
[18] IETF RFC 5491, GEOPRIV PIDF-LO Usage Clarification, Considerations and
     Recommendations, J.Winterbottom, M. Thomson, H. Tschofenig, March 2009
[19] IETF RFC 3174, US Secure Hash Algorithm 1 (SHA1), D. Eastlake, 3rd et al, September 2001
[20] RSA-1024, A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, R.L.
     Rivest et al, September 1, 1977

Version 2, August 11, 2010                                              Page 220 of 247
                                                      NENA Interim VoIP Architecture for
                                                      Enhanced 9-1-1 Services (i2)
                                                      NENA 08-001 v2, August 11, 2010


[21] ITU-T Recommendation X.509, Information Technology – Open Systems Interconnection – The
     Directory: Public-key and attribute certificate frameworks, November 2008
[22] IETF RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1, T. Dierks & E.
     Rescorla, April 2006
[23] IETF RFC 5246, The Transport Layer Security (TLS) Protocol, T. Dierks, E. Rescorla, August
     2008
[24] IETF RFC5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known
     Services, H. Schulzrinne, January 2008
[25] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices, April 2006
[26] IETF Internet Draft, HTTP Enabled Location Delivery (HELD), M. Barnes Ed., draft-ietf-
     geopriv-http-location-delivery
[27] NENA 08-752, Technical Requirements Document (TRD) for Location Information to Support
     IP-Based Emergency Services, Issue 1, December 21, 2006
[28] NENA 08-505, Recommended Method(s) for Location Determination to Support IP-Based
     Emergency Services, Issue 1, December 21, 2006
[29] VOID
[30] IETF RFC 1034, Domain Names – Concepts and Facilities, P. Mockapetris, November 1987
[31] IETF RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, A. B. Roach,
     June 2002
[32] NENA 03-503, SS7 Guidelines for Wireline and VoIP Emergency Services Gateway
     Interconnection to 9-1-1 Selective Routers, Issue 1, October 20, 2005
[33] IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding & al, June 1999
[34] TIA J-STD-036-B-2005, Enhanced Wireless 9-1-1 Phase 2, June 2005
[35] NIMA TR8350.2, Department of Defense World Geodetic System 1984 Its Definition and
     Relationships with Local Geodetic Systems, Third Edition, Amendment 2, January 2004
[36] TIA J-STD-036-A-2002, Enhanced Wireless 9-1-1, Phase 2 (ANSI/J-STD-036-A-2002)
     (superseded by J-STD-036-B-2005), June 2002
[37] IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format
     Location Object (PIDF-LO), M.Thomson, J. Winterbottom, January 2008
[38] NENA 02-013, Data Standards for the Provisioning and Maintenance of MSAG Files to VDBs
     and ERDBs, Version 3, June 7, 2008
[39] NENA 00-001, Master Glossary of 9-1-1 Terminology, Version 12, July 15, 2009
[40] IETF RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted
     Identity within Trusted Networks, C. Jennings & al, November 2002
[41] IETF RFC 3966, The tel URI for Telephone Numbers, H. Schulzrinne, December 2004


Version 2, August 11, 2010                                            Page 221 of 247
                                                       NENA Interim VoIP Architecture for
                                                       Enhanced 9-1-1 Services (i2)
                                                       NENA 08-001 v2, August 11, 2010


[42] OGC 06-142r1, GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet
     Engineering Task Force (IETF), version 1.0, April 10, 2007
[43] IETF Internet Draft, Requirements for a Location-by-Reference Mechanism, R. Marshall, Ed.,
     draft-ietf-geopriv-lbyr-requirements
[44] ISO 8601:2004, Data elements and interchange formats — Information interchange —
     Representation of dates and times, Third Edition, December 2004
[45] NENA 03-005, Generic Requirements for an Enhanced 9-1-1 Selective Routing Switch, Issue 1,
     January 15, 2004
[46] Void
[47] Void
[48] Void
[49] ANSI T1-628a-2001 (R2005), ECS – Connection and Ring Back Addendum, American National
     Standard Institute
[50] ANSI T1-666-1999 (R2004), Signaling System Number 7 (SS7) – Operator Services Network
     Capabilities, American National Standard Institute
[51] IETF RFC 4235, An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol
     (SIP), J. Rosenberg, H. Schulzrinne, R. Mahy Ed., November 2005
[52] IETF Internet Draft, Best Current Practice for Communications Services in support of
     Emergency Calling, B. Rosen & J. M. Polk, draft-ietf-ecrit-phonebcp
[53] ITU-T Recommendation E.164, http://www.itu.int/rec/T-REC-E.164-200502-I/en
[54] ATIS-0300089 P-ANI Administration Guidelines, http://www.atis.org/inc/wkdocs.asp




Version 2, August 11, 2010                                             Page 222 of 247
                                                  NENA Interim VoIP Architecture for Enhanced
                                                  9-1-1 Services (i2)
                                                  NENA 08-001 Version 2, (Board Approval Date)



9     Exhibits (Informative)
9.1       Potential ALI Changes

9.1.1      Purpose
This section provides a list of potential system changes on the ALI that could be considered
when implementing the i2 solution.

9.1.2      Overview
The initial i2 deployment will be similar to Wireless Wireline Compatibility Mode as specified
in J-STD-036. The VoIP provider will deliver an ESQK into the 9-1-1 Network. The PSAP will
query the local Emergency Services Message Entity, the ALI system, with the ESQK. Once the
ESME receives the ESQK from the PSAP it will query the VoIP Positioning Center (VPC) using
the E2+ message format as implemented over the v-E2 interface. This implementation approach
may necessitate software changes to an ESME that is currently supporting an E2 NCAS
deployment only. NENA 080-001, Issue 2, allows for 20 digits (i.e., ESQK + Callback
Number) to be delivered to the SR, and included in the v-E2 ESPOSREQ (query) message sent
to the VPC.
The E2 NCAS deployment allows for the delivery of the Callback Number and Emergency
Services Routing Digit to the PSAP (Format B within J-STD-036-B). In the E2 NCAS
deployment the caller’s geodetic location is obtained from the Mobile Positioning Center and the
data associated with the Emergency Services Routing Digits, as stored within the ESME, is used
for the cell site address. This differs from a deployment that uses the E2+ message format. When
the E2+ message format is used, the VPC is responsible for delivery of the Callback Number and
will place the civic address of the VoIP caller into tagged fields of the E2+ Location Description
parameter.

9.1.3      Potential Changes Required to Support i2 Solution
The following list is informative. The Pubic Service Agency should consult with their 9-1-1
System Service Provider to obtain an analysis of the potential changes required for implementing
the i2 solution. This text is meant to be used for discussion between the PSAP and the ALI
provider.
      •    Implement E2+ query based on ESQK or ESQK + Callback Number. ESQK shall be
           placed into the ESRK field of Emergency Services Protocol message. Since the ESQK
           will have the same form and function as the ESRK, there will be no change to the
           existing ESRK field. The Callback Number, if included will be placed in the Callback
           Number – Request parameter of the ESPOSREQ message, as described in Section 9.3.4
           of NENA 05-001.
      •    Implement parsing of tagged fields in the E2+ Location Description parameter into the
           ALI format.
           o Determine if any E2+ fields should not be used.
Version 2, (Board Approval Date)                                                  Page 223 of 247
                                               NENA Interim VoIP Architecture for Enhanced
                                               9-1-1 Services (i2)
                                               NENA 08-001 Version 2, (Board Approval Date)


       o Determine approach for using ESN returned in E2+ response and how agency names
           will be displayed.
       o Review the <LOC> tag and any data elements delivered in this field.
               • Determine if any conflict exists with existing ALI format.
       o Determine if there are any embedded labels in the ALI format that may need to be
           accounted for when parsing the VoIP data.
   •   Review VoIP Class of Service values and determine if any changes need to be made in
       call detail reports or Computer Aided Dispatch systems.
   •   Determine if the E2+ Position Source or ALI ESQK shell record shall be used to create a
       VoIP Class of Service.
       o Ensure that the VoIP Position Source value(s) are NOT interpreted as wireless values.
   •   Determine if the existing ALI format has any conflicts for displaying geodetic Location
       and Civic Location fields at the same time. This may be an issue if your existing ALI
       format has multi use fields.
       o Determine if a VoIP position source or Class of Service can be used to prioritize
           when a Geo Location or Civic Location should be displayed.
   •   Determine if there is a need for additional ALI text messages.
       o ESME should have the ability to distinguish when steering is done to a MPC or a
           VPC. This will be necessary to ensure wireless text messages are not created for VPC
           responses.




Version 2, (Board Approval Date)                                               Page 224 of 247
                                                 NENA Interim VoIP Architecture for Enhanced
                                                 9-1-1 Services (i2)
                                                 NENA 08-001 Version 2, (Board Approval Date)


9.2     Rules for Address Abbreviation

9.2.1     Resources for Abbreviation Matching
USPS Publication 28 can be found at the following link:
http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf
The Canadian Postal Guide can be found at the following link:
http://www.canadapost.ca/business/offerings/address_management/pdf/addressing_guide-e.pdf
The following table is excerpted from USPS Publication 28 to show variations in Street Suffix
Abbreviations. The suffix name of AVENUE was picked for illustration purposes only.


                              Commonly Used Street          Postal Service Suffix
Primary Street Suffix         Suffix or Abbreviation        Abbreviation (USPS Pub
Name                                                        28, Appendix C)
AVENUE                        AV                            AVE
                              AVE
                              AVEN
                              AVENU
                              AVENUE
                              AVN
                              ANVUE
                             Table 9-1: Street Suffix Abbreviation


The VDB must be able to translate AV, AVE, AVEN, AVENU, AVENUE, AVN and ANVUE
to the USPS accepted abbreviation of AVE.
Address received     Result Code           Address contained      Address returned
over the v7                                in the MSAG and        over the v7
                                           returned over v-E2
OAK AVE              100 (Success)         OAK AVN                OAK AVE
OAK AV               102 (Alt returned)    OAK AVN                OAK AVE
Oak Ave              102 (Alt returned)    OAK AVN                OAK AVE
OAK AVE.             102 (Alt returned)    OAK AVN                OAK AVE
        Table 9-2: Examples of Street and Street Suffix Names as input/outputs over v7



9.2.1.1    Additional Validation Functionality
The VDB may optionally do more than matching based on a standardized list. For example, if a
VDB receives “AVINU”, it could decide to associate and return AVE in the v7 response. The
limit of this VDB functionality should be incumbent on the specific implementation.

Version 2, (Board Approval Date)                                               Page 225 of 247
                                                  NENA Interim VoIP Architecture for Enhanced
                                                  9-1-1 Services (i2)
                                                  NENA 08-001 Version 2, (Board Approval Date)


9.3    MSAG to Postal Address Comparison
This appendix is provided for informational purposes only. The intent of the appendix is to
illustrate the fact that postal addresses and MSAG addresses are very often different and it is the
MSAG address which is required to ensure proper dispatch at the PSAP.
Information for VDB Developers


Example using actual MSAG data; postal addresses were looked up at
http://www.satorisoftware.com/US/addresscheck/AddressCheck.asp.

These are just some customer address examples pulled at random from MSAGs around the
country (no searches were done to find examples likely to not match to Postal addresses). Based
on this tiny sample it appears that conformity to Postal addresses is going to vary widely from
MSAG to MSAG with most MSAGs being very different from the Postal.
Variations of Andover in MSAG (each of these variations will have a different set of valid streets
and addresses associated with them):

      Community         County         State
      ANDOVER           SMST           NJ
      BORO
      ANDOVER           SUSX           NJ
      BORO
      ANDOVER TWP       SUSX           NJ


  MSAG Address                Postal Address                Comment
  18 AMBLER LANE              18 Ambler Ln                  Note that Postal City does not match
  ABERDEEN TWP, NJ            Matawan NJ 07747-1225         MSAG City.
                              County name: Monmouth         Postal lookup failed if zip not supplied
                                                            using city name ABERDEEN TWP;
                                                            worked without zip if TWP omitted.
  1 CLIFFSIDE WAY             1 Cliffside Way               Note that Postal City does not contain
  ANDOVER TWP NJ              Andover NJ 07821-5042         TWP.
                              County name: Sussex           Postal lookup failed if zip not supplied
                                                            using city name ANDOVER TWP;
                                                            worked without zip if TWP omitted.
  400 US HWY NO 206           Lookup failed with or         Mapquest returned: You searched for
  ANDOVER NJ                  without zip                   "400 us hwy no 206, andover, nj
                                                            07860", MapQuest did not find this
                                                            exact address, but found one very
                                                            similar: "400 Us Highway 206 S,

Version 2, (Board Approval Date)                                                   Page 226 of 247
                                            NENA Interim VoIP Architecture for Enhanced
                                            9-1-1 Services (i2)
                                            NENA 08-001 Version 2, (Board Approval Date)


  MSAG Address             Postal Address           Comment
                                                    Newton, NJ 07860-6002".
  301 W 1ST AVE            301 W 1st Ave            Postal lookup failed if zip not supplied
  BARRINGTON BORO          Barrington NJ 08007-     using city name BARRINGTON
  NJ                       1206                     BORO; worked without zip if BORO
                           County name: Camden      omitted.
  17 AVENUE A ST           17 Avenue A              Note that Postal City does not contain
  NEWARK CITY NJ           Newark NJ 07114-2661     CITY
                           County name: Essex
  2184 AZALEA AVE          2184 Azalea Ave          Note that Postal City does not match
  WALL TWP NJ              Sea Girt NJ 08750-2401   MSAG City.
                           County name: Monmouth    The MSAG has a few streets in it for
                                                    Sea Girt, NJ – Azalea Ave is not one
                                                    of them.
                                                    Postal lookup failed if zip not supplied
                                                    using city name WALL TWP; worked
                                                    without zip if TWP omitted.
  10 ACADEMY DR E          10 Academy Dr E          Note that Postal City does not match
  HANOVER TWP NJ           Whippany NJ 07981-       MSAG City.
                           1801                     Whippany, NJ is not in the MSAG
                           County name: Morris      Postal lookup failed if zip not supplied
                                                    using city name HANOVER TWP;
                                                    worked without zip if TWP omitted
  2948 HIGHWAY 72 E        2948 Highway 72 E
  ABBEVILLE, ABB, SC       Abbeville SC 29620-
                           5258
                           County name: Abbeville
  4216 TAYLOR CREEK        4216 Taylor Creek Rd
  RD                       Afton VA 22920-2159
  AFTON, ALB, VA           County name: Albemarle
  105 E HOLLAND            105 E Holland St
  ARCHBOLD, FUL, OH        Archbold OH 43502-
                           1210
                           County name: Fulton
  921 LIGHTHOUSE           Lookup failed with or    Mapquest returned:
  CHURCH RD                without zip              You searched for "921 LIGHTHOUSE
  BAKER, OKA, FL                                    CHURCH RD, BAKER, FL 32531",
                                                    MapQuest did not find this exact
                                                    address, but found one very similar:
                                                    "Baker, FL 32531".
  132 BANDERA CIR          132 Bandera Cir          Note that Postal City does not match
  BANDERA BAY, HEN,        Mabank TX 75156-8920     MSAG City.
  TX                       County name: Henderson
Version 2, (Board Approval Date)                                           Page 227 of 247
                                            NENA Interim VoIP Architecture for Enhanced
                                            9-1-1 Services (i2)
                                            NENA 08-001 Version 2, (Board Approval Date)


  MSAG Address       Postal Address                 Comment
  31496 330TH ST     31496 330th St
  BARNARD, NOD, MO   Barnard MO 64423-8240
                     County name: Nodaway
  139 SAWYERS CREEK 139 Sawyers Creek Rd
  RD                 Camden NC 27921-7507
  CAMDEN, CAM, NC    County name: Camden
  32995 TERRACE VIEW Lookup failed with or          Mapquest returned:
  RD                 without zip                    You searched for "32995 Terrace View
  CAPE KIWANDA, TIL,                                Rd, Cape Kiwanda, OR 97135", MapQuest
  OR                                                did not find this exact address, but
                                                    found one very similar: "Pacific City, OR
                                                    97135".

  493 SIMCOE MTN RD        493 Simcoe Mountain Rd
  CENTERVILLE, KLI,        Centerville WA 98613-
  WA                       2906
                           County name: Klickitat
  8620 N CR 800 E          Lookup failed with or    Mapquest returned:
  DECATUR, WLS, IN         without zip              You searched for "8620 N CR 800 E,
                                                    DECATUR, IN 46733", MapQuest did not
                                                    find this exact address, but found one
                                                    very similar: "8620 N 800 E-90, Decatur,
                                                    IN 46733-9202".
  34 DUNKARD               34 Dunkard Church Rd     Note that Postal City does not match
  CHURCH RD                Stockton NJ 08559-1405   MSAG City.
  DELAWARE TWP,            County name: Hunterdon
  HUNT, NJ
  1463 RD 51 E             1463 Road 51 E
  DIX, KIM, NE             Dix NE 69133-8920
                           County name: Kimball
  1720 SCIOTO RD           1720 Sciota Rd           Street name changed – counties are
  ELIZABETHTON, UNI,       Elizabethton TN 37643-   different; this is probably not a match
  TN                       1904                     Mapquest returned:
                           County name: Carter      You searched for "1720 SCIOTO RD,
                                                    ELIZABETHTON, TN 37643", MapQuest
                                                    did not find this exact address, but
                                                    found one very similar: "Elizabethton,
                                                    TN 37643-1904".
  2261 COMERS ROCK                                  street number or box number out of
  RD                                                range
  ELK CREEK, GRA, VA
                                                    Mapquest returned:
                                                    Map of the address
Version 2, (Board Approval Date)                                              Page 228 of 247
                                           NENA Interim VoIP Architecture for Enhanced
                                           9-1-1 Services (i2)
                                           NENA 08-001 Version 2, (Board Approval Date)


  MSAG Address             Postal Address          Comment
  13228 US 24              13228 US 24             Note that Postal City does not match
  EMERALD TWP, PAU,        Cecil OH 45821-9401     MSAG City.
  OH                       County name: Paulding




Version 2, (Board Approval Date)                                         Page 229 of 247
                                                   NENA Interim VoIP Architecture for Enhanced
                                                   9-1-1 Services (i2)
                                                   NENA 08-001 Version 2, (Board Approval Date)


9.4       ERDB Discovery Using Geodetic Information
ERDB discovery consists of sending location information to a root discovery node and being
returned the URI of an ERDB that can provide routing information for the associated call.
Geodetic information is normally expressed as an area or volume, so in border areas it is
possible, indeed quite likely, that the geodetic area representing the location of the caller may
span more than one ERDB. In this case the VPC will receive more than one ERDB URI.
Expressing service areas using geodetic coordinates to define a polygon is a relatively common
practice today to describe PSAP service boundaries. Errors in boundary specification between
two adjacent service areas may result in 'holes', areas in which neither PSAP will claim coverage,
or overlap where more than one PSAP would claim coverage. As of the time of writing it is
acknowledge that some geodetic PSAP boundary errors can range between 10 and 30 meters.
Figure 9-1 illustrates a typical ERDB service area polygon.




                              Figure 9-1: ERDB Service Area Polygon

9.4.1      Polygon Definition
As described earlier, geodetic representations for PSAP boundaries today can have errors in
coverage ranging from 10 to 30 meters, and these can result in coverage gaps where a caller may
not be able to reach a PSAP. In an attempt to overcome these problems, specific measures are
put in place for ERDB area definitions.
      •    A minimum polygon vertex precision is required. 4 decimal places is the recommended
           as minimum as this places the error at around 10 meters.
      •    A deliberate ERDB boundary overlap is required.
      •    Where area vertices are expressed to 4 decimal places, a boundary overlap of 50 meters is
           required.
Version 2, (Board Approval Date)                                                    Page 230 of 247
                                                              NENA Interim VoIP Architecture for Enhanced
                                                              9-1-1 Services (i2)
                                                              NENA 08-001 Version 2, (Board Approval Date)


Geodetic locations are most likely to be provided to, or by mobile devices. High accuracy
geodetic locations using A-GPS systems typically yield a location with an uncertainty radius of
around 30 meters or better. Providing an overlap of 50 meters will result in a significant
reduction in the chance of misrouting a call, but will also result in almost no chance for the
existence of coverage gaps. Where ERDB boundaries are known to be of extremely high
precision, or frequent misrouting is known to occur, the degree of overlap between service areas
can be reduced. A safety net of 50 meters overlap however is recommended as the norm.
Specific polygon definition rules are as follows:
    1. Polygons must be expressed in 2 dimensions using the EPSG:4326 coordinate reference
       system.
    2. Polygons must be defined with the upward normal being in the upward direction. To
       accomplish this, polygon vertices must be defined in a counter-clockwise direction.
    3. Lines between adjacent polygon vertices are minimum distance (geodesic).
    4. Polygons must be closed areas, with the first and last points in the definition being the
       same.
    5. A connecting line SHALL NOT cross another connecting line.
    6. Two successive points must not be diametrically opposed on the ellipsoid.
    7. This definition does not permit connecting lines greater than roughly 20,000 km. If such a
       need arises, the polygon can be described by adding an intermediate point.
    8. There are no restrictions on the number of points that may be used to represent a service
       area polygon.

9.4.2    Endpoint (Subscriber) Location Representation
Endpoint geodetic location information in this specification is provided from the VPC to the
ALI/PSAP over the v-E2 interface, which reuses the E2 specification [34] in existence for
cellular wireless. This interface restricts the formats of geodetic information to:
    • ellipsoid point (latitude, longitude)
    • ellipsoid point with altitude (latitude, longitude, altitude)
    • ellipsoid point with uncertainty radius (latitude, longitude, radius)
    • ellipsoid point with altitude and uncertainty radius (latitude, longitude, altitude, radius).
Since location conveyance to the PSAP is restricted to these forms, these will be the supported
locations for acceptance by the ERDB root discovery server. Location is provided inside a
PIDF-LO [8][37] document to the VPC, and it is expected that the geodetic location information
be constricted to the shapes and forms defined in the GeoShapes specification [42]. The
GeoShapes specification supports a number of shapes in addition to those supported by the v-E2
and ERDB root discovery interface. If the VPC receives a shape other than one that is acceptable
to the ERDB root discovery node, the VPC must either convert the shape to an acceptable form
without loss of coverage, or provide some kind of default routing for the call 37. The VPC must
not provide the unacceptable shape type to the ERDB root discovery node. Valid GeoShapes,

37 These conversions can and do occur today in GMLCs and MPCs that operate in cellular wireless networks, as location
determination techniques vary across carrier deployments and technologies.
Version 2, (Board Approval Date)                                                                        Page 231 of 247
                                                              NENA Interim VoIP Architecture for Enhanced
                                                              9-1-1 Services (i2)
                                                              NENA 08-001 Version 2, (Board Approval Date)


and their v-E2 equivalents are provided in Error! Reference source not found.Table 9-1-1,
where a GeoShape requires conversion this is clearly indicated.
Geo Shape             v-E2 Shape Equivalent                    VPC Actions                    Notes
   Type
Point             Ellipsoid Point                            Pass to Root            Geoshape uses the
                  Ellipsoid Point with altitude              Discovery               EPSG:4326 CRS
                                                             Server                  for 2d points, and
                                                                                     the EPSG:4979
                                                                                     CRS for 3d points
Circle            Ellipsoid Point with                       Pass to Root
                  Uncertainty radius                         Discovery
                                                             Server
Sphere            Ellipsoid Point with Altitude              Pass to Root
                  and Uncertainty radius                     Discovery
                                                             Server
Ellipse                              X                        Conversion 38
                                                                Required
Ellipsoid                            X                         Conversion
                                                                Required
Polygon                              X                         Conversion
                                                                Required
Prism                                X                         Conversion
                                                                Required
ArcBand                              X                         Conversion
                                                                Required
                               Table 9-3: GeoShape to VE2 Shape Mapping
Examples of the three accepted shape types are provided below.

9.4.2.1     GeoShape Examples
Following are examples of the GeoShapes supported by the v-E2 and ERDB root discovery
interfaces

9.4.2.1.1 Point
2D point:




38 Conversion methodology is left to implementation. Where conversion is performed, the converted shape is used to query both
the Root Discovery Server and later the ERDB and for return to the PSAP over the v-E2 interface.
Version 2, (Board Approval Date)                                                                        Page 232 of 247
                                               NENA Interim VoIP Architecture for Enhanced
                                               9-1-1 Services (i2)
                                               NENA 08-001 Version 2, (Board Approval Date)



<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
  xmlns:gml="http://www.opengis.net/gml">
    <gml:pos>-34.407 150.883</gml:pos>
</gml:Point>



3D point :

<gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
  xmlns:gml="http://www.opengis.net/gml">
    <gml:pos>-34.407 150.883 24.8</gml:pos>
</gml:Point>




9.4.2.1.2 Circle

<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
  xmlns:gs=”http://www.opengis.net/pidflo/1.0"
  xmlns:gml="http://www.opengis.net/gml">
    <gml:pos>42.5463 -73.2512</gml:pos>
    <gml:radius uom="urn:ogc:def:uom:EPSG::9001">850.24</gml:radius>
</gs:Circle>




9.4.2.1.3 Sphere

<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
  xmlns:gs=”http://www.opengis.net/pidflo/1.0"
  xmlns:gml="http://www.opengis.net/gml">
    <gml:pos>42.5463 -73.2512 26.3</gml:pos>
    <gs:radius uom="urn:ogc:def:uom:EPSG::9001">850.24</gs:radius>
</gs:Sphere>



9.4.3   ERDB Root Discovery Provisioning
ERDB root discovery nodes are expected to be provisioned with polygons representing ERDB
service boundary areas.
These files must provide a linkage between service area and an ERDB URI. The format of the
provisioning file and constraints around area representation are described in the following
subsections.


Version 2, (Board Approval Date)                                              Page 233 of 247
                                                NENA Interim VoIP Architecture for Enhanced
                                                9-1-1 Services (i2)
                                                NENA 08-001 Version 2, (Board Approval Date)


9.4.3.1 ERDB Root Discovery Provisioning Files
The ERDB root discovery node is provisioned with files describing the GeoShape polygons
representing ERDB service coverage areas. ERDB operators are required to provide an XML file
to the ERDB root discovery operator which defines an ERDB area of coverage, and an
association to an ERDB URI through which ERDB routing requests can be made.

9.4.3.1.1 ERDB Boundary Definition Format
The format for the ERDB boundary definition element consists of two sections, a header,
describing the ERDB for which the file belongs, a creation date for the data in the file, an
effective date, and an expiry date. All times must be expressed in UTC. The second part of the
file is the polygon definition as described in Section D.1.
A sample ERDB boundary definition may look similar to that shown below.




Version 2, (Board Approval Date)                                                Page 234 of 247
                                                   NENA Interim VoIP Architecture for Enhanced
                                                   9-1-1 Services (i2)
                                                   NENA 08-001 Version 2, (Board Approval Date)



<?xml version="1.0"?>
<erdbBoundaryDefinition
    xmlns="urn:nena:xml:ns:es:geoErdbRdo"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:nena:xml:ns:es:geoErdbRdo
                        geoErdbRdo.xsd">
  <erdbID>
    <erdbURI>https://www.erdb.harriscounty.tx.gov/erdb.html</erdbURI>
    <erdbCommonname>Harris County Texas ERDB</erdbCommonname>
    <createDate>2006-10-01T13:00:00Z</createDate>
    <expiryDate>2006-11-01T13:00:00Z</expiryDate>
    <effectiveDate>2006-10-02T13:00:00Z</effectiveDate>
  </erdbID>
  <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"
   xmlns:gml="http://www.opengis.net/gml">
    <gml:exterior>
      <gml:LinearRing>
        <gml:pos>42.556844 -73.248157</gml:pos>
        <gml:pos>42.549631 -73.237283</gml:pos>
        <gml:pos>42.539087 -73.240328</gml:pos>
        <gml:pos>42.535756 -73.254242</gml:pos>
        <gml:pos>42.542969 -73.265115</gml:pos>
        <gml:pos>42.553513 -73.262075</gml:pos>
        <gml:pos>42.556844 -73.248157</gml:pos>
      </gml:LinearRing>
    </gml:exterior>
  </gml:Polygon>
</erdbBoundaryDefinition>


9.4.4   ERDB Root Discovery Operation
Communication between a VPC and the ERDB root discovery server is performed using the v9
interface. This is a web services protocol that supports sending a single GeoShape object, Point
(2-D or 3-D), Circle, or Sphere from the VPC to the root discovery server. The response from the
root discovery server will be a list of zero or more ERDB URIs, along with a Percentage Overlap
Confidence (POC) value. The POC value describes the percentage of the initially provided
caller-location area (point plus uncertainty) overlapped with the corresponding ERDB service
area. This is illustrated in Figure 9-1-2 below.
If the location sent to the root discovery server is a 3 dimensional point, or a sphere, then the root
discovery server must project the shape into two dimensions prior to calculating the POC value.
This may be done by simply ignoring the altitude components.
The VPC should include the POC value and ERDB URI in event records generated for received
routing requests. This will assist ERDB and VPC operators in determining which areas and
boundaries are most susceptible to misrouting calls. Data for these areas can then be refined so
that improvements in routing data can be made.


Version 2, (Board Approval Date)                                                     Page 235 of 247
                                                  NENA Interim VoIP Architecture for Enhanced
                                                  9-1-1 Services (i2)
                                                  NENA 08-001 Version 2, (Board Approval Date)




                                   Figure 9-2 Area of Overlap
The POC value is a value between 0 and 100, where 0 represents no overlap, and 100 represents
complete overlap. A value of 0 should never be returned by the root discovery node, unless
specific default handling capabilities are provisioned into it.
The POC is calculated by finding the area of overlap, Ao , between the caller area, Ac , and the
ERDB service area, SAerdb.




The list of ERDB URIs returned to the VPC by the root discovery node should be in descending
order by POC value. The highest POC valued ERDB URI should occur first in the list. It may be
possible that one or more ERDB URIs may have the same non-zero POC value, in which case all
the ERDB URIs will be returned in the list.



Version 2, (Board Approval Date)                                                   Page 236 of 247
                                                    NENA Interim VoIP Architecture for Enhanced
                                                    9-1-1 Services (i2)
                                                    NENA 08-001 Version 2, (Board Approval Date)


9.5       Web Services
A number of the new vx interfaces described in this document use Web Services. This section is
intended to serve as a high-level tutorial of Web Services.
“A web service is a software application identified by a URI, whose interface and bindings are
capable of being identified, described and discovered by XML artifacts and supports direct
interactions with other software application using XML based messages via Internet-based
protocols.”
(World Wide Web Consortium)

A web service is a collection of protocols and standards used for exchanging data between
applications. Software applications written in various programming languages and running on
various platforms can use web services to exchange data over the internet in a manner similar to
inter-process communications on a single computer.

9.5.1      Standards used
      •    XML: All data to be exchanged is formatted with XML tags. This encoding can be
           performed by Simple Object Access Protocol (SOAP) or XML-Remote Procedure Call
           (RPC) (note: industry standards for security, interoperability, etc. are based on SOAP).
      •    Common protocols: XML data can be transported between applications using common
           protocols such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and
           Simple Mail Transfer Protocol (SMTP).
      •    Web Services Description Language (WSDL): The public interface to the web service is
           described by WSDL. This is an XML-based service description on how to communicate
           using the web service. It describes the operations the service has available, the messages
           the service will accept, and the protocol of the service.
      •    Universal Description, Discovery, and Integration (UDDI): The web service information
           is published using this protocol. It enables applications to look up web services
           information in order to determine whether to use them.
      •    SOAP: The service messaging layer of a web service. The messages are XML based.
           The protocol consists of three parts: an envelope that defines a framework for describing
           what is in a message and how to process it, a set of encoding rules for expressing
           instances of application-defined datatypes, and a convention for representing remote
           procedure calls and responses.

9.5.2      Key Points regarding Web Services
The key points to web services in providing emergency services are:
      •    Web services are programming language and platform neutral. A web service can be
           written in Microsoft’s .NET on a Window’s platform and accessed via a UNIX Java
           platform or other common development platforms.


Version 2, (Board Approval Date)                                                     Page 237 of 247
                                               NENA Interim VoIP Architecture for Enhanced
                                               9-1-1 Services (i2)
                                               NENA 08-001 Version 2, (Board Approval Date)


   •    Web services are industry standard. They were developed by the World Wide Web
        Consortium and the standards are freely available.
For more information on WSDL see the following link:
http://www.w3schools.com/wsdl/default.asp

9.5.3   Substitution of Special Characters
The Web Services interfaces are XML-based and certain text characters have special meanings
to XML and HTML. As a result, these characters cannot be passed through the interface directly.
Instead, the client must substitute standard HTML character codes for these characters. The
following table lists the characters and the codes used to replace them.


                                 Table 9-9-4 HTML Code Table
                           Character           HTML Code
                           &                   &amp;
                           ‘ (apostrophe)      &apos;
                           <                   &lt;
                           >                   &gt;
                           “ (double quote)    &quot;

                                  Table 9-5: HTML Code Table




Version 2, (Board Approval Date)                                               Page 238 of 247
                                                  NENA Interim VoIP Architecture for Enhanced
                                                  9-1-1 Services (i2)
                                                  NENA 08-001 Version 2, (Board Approval Date)


9.6     v7 Client Considerations/Recommendations
The v7 interface specification addresses only the messaging between a v7 client (e.g., a LIS) and
a v7 server (e.g., a VDB). This section is informative and presents suggestions and/or guidelines
that are outside the scope of the v7 interface standard. Following these guidelines will help a
VDB and v7 client developer ensure that their users can validate addresses quickly, and help
ensure that the v7 client is well behaved with respect to a v7 server.

9.6.1    Overview
A typical v7 client will provide a Graphical User Interface (GUI) to a user to collect addresses
for validation. The v7 client will use the data from the GUI to create and send v7 messages to the
VDB (the v7 server). The v7 client will receive the v7 response message, parse the message, then
use the parsed data to populate fields in the GUI presented to the User.

9.6.2    Wiremap LIS
The user for this type of v7 client will be the "administrator" of the wiremap LIS installation.
The administrator will need to validate addresses when the LIS is first installed. Whenever new
physical ports are wired, the administrator may need to validate addresses for those ports. Also
addresses will need to be re-validated on a periodic basis.
This solution assumes that the LIS presents web pages as the GUI to the LIS administrator.
Recommendation: The form presented to the LIS administrator should have distinct fields for
each part of the address, and those fields should match the fields in the underlying v7 messages.
Recommendation: The form should use drop-down menus for fields where the v7 interface
suggests the clients limit the data they send to relatively few values.
For example, if the v7 interface says that clients should limit the values submitted for
directionals to one of [e.g., N, S, E, W, NE, NW, SE, SW] it's best to use a drop-down menu on
the web page forms presented to the LIS administrator. Using drop-down menus helps minimize
the round-trip interactions required of the LIS administrator to validate an address.
Recommendation: For fields where the v7 interface suggests the clients limit the data they send
to a large but well known set of values, those fields should be validated prior to sending v7
messages.
For example, if the v7 interface says that clients should limit the values for submitted street
suffixes to those listed in country-specific Postal Standards, it would be impractical to try to
populate a web form drop-down with so many values. So it would be better to allow the LIS
administrator to enter suffixes free-form in a suffix field. Because the list is well known, the LIS
should validate the street suffix prior to sending a v7 message.
These validations could be client-side javascript, or validations running within the LIS web
server prior to sending the v7 message. The result of a validation should be a suggestion to
change the suffix prior to submitting for full validation. The LIS administrator should always be
able to proceed even if they don't accept this suggestion.

Version 2, (Board Approval Date)                                                    Page 239 of 247
                                                NENA Interim VoIP Architecture for Enhanced
                                                9-1-1 Services (i2)
                                                NENA 08-001 Version 2, (Board Approval Date)


It is best for the LIS v7 implementation to do these types of simple validations, because the VDB
is not required to suggest alternatives. By doing these validations and making suggestions up
front, the LIS can insure a better user experience for the LIS administrator.
Recommendation: When the v7 response contains address alternatives, the GUI should display
the alternatives in the same order, indicating the first alternative is likely the best choice.




Version 2, (Board Approval Date)                                                 Page 240 of 247
                                                 NENA Interim VoIP Architecture for Enhanced
                                                 9-1-1 Services (i2)
                                                 NENA 08-001 Version 2, (Board Approval Date)


9.7   Call Routing Performance Guidelines
The information provided in this Appendix is offered as guidance to implementers of i2
architectures. The timing values are estimated, not measured.
People calling for help should not experience a long wait time before getting an indication that
the call has reached the PSAP. Consequently, implementers of i2 are encouraged to engineer the
network and elements in the IP Domain in such a way that emergency calls are routed in the
most efficient manner.
The design objective herein is to align with PSTN requirements that specify the maximum wait
time for call setup to be 10 seconds. In an i2 environment, and using SIP as an example, this
would be measured from the time the original INVITE is sent from the VEP, to the time the VEP
receives early media (i.e. ringing) from the ESGW. A call setup timer will be implemented to
measure the call setup time. However, it is assumed the VEP may initially not be able to
implement such a timer. An acceptable approach would then be to implement a special call setup
timer at the Call Server.
The following diagram provides the estimated setup times to deliver a call to the PSAP under
three possible routing schemes; one where the CS/Proxy routes the call, one where a Redirect
Server is involved and one where a Routing Proxy is involved. The number given on each line is
the time required to pass the information through the network. Incremental setup times at each
step are represented in the bottom part of the reference mark.
The following table lists the expected Total Call Processing Time at the various entities.


      CS/Proxy       Redirect       Routing       VPC       ERDB        ESGW            SR
                      Server         Proxy

       100ms          50ms           50ms        200ms      200ms        50ms          50ms

                             Table 9-6 Total Call Processing Time
l.




Version 2, (Board Approval Date)                                                  Page 241 of 247
                                                                                                   NENA Interim VoIP Architecture for Enhanced
                                                                                                   9-1-1 Services (i2)
                                                                                                   NENA 08-001 Version 2, (Board Approval Date)


           VEP           CS/Proxy                 RS                    RP                   VPC                   ERDB             ESGW                     SR               PSAP




      0                                  1
     0ms                               100ms                                                             2
                 100ms
                                75ms
                                                                                                       275ms                3
                                                             100ms
                                                                                                   100ms
                                                                                                       100ms              475ms
                                                                                     4                               200ms
                   5                                                               775ms               100ms
                 975ms                                                                     100ms
                                                                                                                                               6
                                                             100ms
                         25ms                                                                                                                 1.1s
                                                                                   100ms

                                                                                                                                               6a
                                                               1 sec IP Latency
                                                                                                                                              2.1s                     7
                                                                                                                                      50ms
                                                                                                                                                                     2.25s
                                                                                                                             ISUP            100ms
                                                                                                                                                                                       8
                                                                                                                                                                  50ms
                                                                                                                               50ms
                                                                                                                                                                     2 secs          4.30s

                                                                                                                                                                       7
                                                                                                                             CAMA            2 secs
                                                                                                                                                                     4.15s             8
                                                                                                                                                      50ms
                                                                                                                                                                     2 secs          6.20s



      0                              1
     0ms                           100ms                   2
                 100ms
                                75ms
                                                         275ms                                          3
                                       100ms
                                                      25ms
                                                                      100ms                           400ms                 4
                                                                                                   100ms                  600ms
                                                                                                           100ms
                                                                                     5                               200ms
                                         6                                         900ms                   100ms
                                                                                           100ms
                    7                   1.1s                          100ms
                                               25ms
                 1.225s                100ms                                                                                                   8
                         25ms
                                                                                   100ms                                                     1.35s

                                                                                                                                              8a
                                                               1 sec IP Latency
                                                                                                                                             2.35s                     9
                                                                                                                                      50ms

                                                                                                                                             100ms                   2.50s
                                                                                                                             ISUP                                                     10
                                                                                                                                                                  50ms
                                                                                                                               50ms
                                                                                                                                                                     2 secs          4.55s

                                                                                                                                                                       9
                                                                                                                             CAMA            2 secs
                                                                                                                                                                     4.40s            10
                                                                                                                                                      50ms
                                                                                                                                                                     2 secs          6.45s


      0                              1
     0ms                           100ms                                             2
                 100ms
                                75ms                                               275ms
                                                100ms                                                   3
                                                                            25ms
                                                                                                      400ms                 4
                                                                                   100ms
                                                                                                   100ms
                                                                                                       100ms              600ms
                                                                                     5
                                                                                                                     200ms
                                                               6                   900ms               100ms
                                                                                           100ms
                                                              1.1s                 100ms                                                        7
                                                                     25ms
                                                                                                       100ms                                 1.225s

                                                                                                                                               7a
                                                               1 sec IP Latency
                                                                                                                                      50ms
                                                                                                                                             2.225s                    8
                                                                                                                                             100ms                  2.375s
                                                                                                                             ISUP                                                       9
                                                                                                                                                                  50ms
                                                                                                                               50ms
                                                                                                                                                                     2 secs          4.425s

                                                                                                                                                                       8
                                                                                                                             CAMA            2 secs
                                                                                                                                                                     4.25s              9
                                                                                                                                                      50ms
                                                                                                                                                                     2 secs          6.325s



                                                 Figure 9-3 Call Routing Performance
The following assumptions should be considered with the figure above.
Version 2, (Board Approval Date)                                                                                                                                         Page 242 of 247
                                                             NENA Interim VoIP Architecture for Enhanced
                                                             9-1-1 Services (i2)
                                                             NENA 08-001 Version 2, (Board Approval Date)


    •    Literal location (MSAG-validated civic or geodetic form) is assumed to be available to
         the entity interacting with the VPC 39.
    •    Congestion encountered using internet access is not considered in the performance. No
         assumption is made that the Internet provides separate priority queues for voice calls.
    •    Network connections assume Wide Area Networks (WANs).
    •    Network time between the VPC and ERDB can be eliminated if VPC has access to the
         information locally.
    •    It is assumed that the VPC is preloaded with the information needed to determine the
         appropriate ERDB 40. It is also assumed that the chosen ERDB has the routing
         information that is being requested.
    •    Delivery to the SR is expected to be either SS7 ISUP or traditional Centralized Automatic
         Message Accounting (CAMA).
    •    The SRDB is assumed to be on board the SR.
    •    Delivery from the SR to the PSAP is assumed to be CAMA.
    •    It is assumed that the VEP is not implementing a timer for a maximum wait time for call
         setup at 10 seconds so, a special CS-based timer is assumed. Once the CS receives the
         call from the IP endpoint, the call should be set up within that timeframe. This may
         override SIP specified timers that allow up to 32 seconds.
    •    Authentication/authorization at the ERDB, the VPC, the RS and the RP is assumed in
         their respective processing times. No other authentication/authorization processing times
         is included in this figure.
    •    It is assumed agreements between the Call Server and the first Proxy exist when both
         elements are locally operated by, or on behalf of the same VSP. No network and
         authentication times are assumed.
    •    IP Network Latency (IPL) can not be quantified so an additional 1 second is added to
         each routing scheme to account for signaling and processes such as TCP and TLS setup
         (when appropriate).
    •    Processing times shown indicate the total processing time required to process each call.

Overall timers applicable to the setup:
The following timers and suggested values are based on the estimated times in the above figure.
Note that timers should be configurable so that values can be adjusted according to real-life
measurements.

M1. CS timer – 10 seconds, maximum call setup time. If this timer expires, the CS may select a
    contingency routing scenario, through a PSTN gateway for example. Tearing down the call
    based on this timer is discouraged.

39 When an LK is supplied which requires the VPC to de-reference it at the LIS, add 1250ms (50ms processing, 200ms network
and 1 second IP Network Latency) to the total Call Setup Time.
40 When the RDS is involved to discover the ERDB, add 1250ms (50ms processing, 200ms network and 1 second IP Network
Latency) to the total Call Setup Time.
Version 2, (Board Approval Date)                                                                      Page 243 of 247
                                                 NENA Interim VoIP Architecture for Enhanced
                                                 9-1-1 Services (i2)
                                                 NENA 08-001 Version 2, (Board Approval Date)


M2. CS timer for CS to VPC (v2) – 4.6 seconds, maximum wait for response from VPC. If this
    timer expires, the CS may select a contingency routing scenario, through a PSTN gateway
    for example. Tearing down the call based on this timer is discouraged.
M3. RS timer for RS to VPC (v2) – 4.35 seconds, maximum wait time for response from VPC.
    If this timer expires, the RS shall return an error code over the v5 interface so the CS could
    invoke a contingency routing scenario, through a PSTN Gateway for example. Tearing
    down the call based on this timer is discouraged.
M4. RP timer for RP to VPC (v2) – 4.475 seconds, maximum wait for response from VPC. If
    this timer expires, the RP may select a contingency routing scenario, through a PSTN
    gateway for example. Tearing down the call based on this timer is discouraged.
M5. CS timer for CS to RS (v5) – 4.6 seconds, maximum wait for response from RS, including
    VPC and ERDB interactions. If this timer expires, the CS may select a contingency routing
    scenario, through a PSTN gateway for example. Tearing down the call based on this timer is
    discouraged.
M6. VPC timer for VPC to ERDB (v8) – 1.35 seconds, maximum wait for each ERDB query.
    If this timer expires, the VPC shall retry the ERDB query until timer M7 expires.
M7. VPC timer (v8) – 4.05 seconds, maximum overall wait time for any interactive responses
    between a VPC and ERDB(s). If this timer expires, the VPC shall send an error message
    (5XX) to the requesting entity (CS, RS or RP) over the v2 interface. The routing entity may
    then invoke a contingency routing scenario, through a PSTN gateway for example. Tearing
    down the call based on this timer is discouraged.

Average Expected Call Setup Times:
   •   4 to 5 Seconds with SS7 to the SR and CAMA to the PSAP
   •   6 to 7 Seconds with CAMA to the SR and CAMA to the PSAP

Call Setup times with applicable timers:
VEP-CS-Timer M2-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-Timer M2-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS-RS-Timer M3-RS-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-RS-Timer M3-RS-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-RP-Timer M4-RP-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-RP-Timer M4-RP-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS-Timer M5-CS-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS-Timer M5-CS-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
VEP-CS/RS/RP-Timer M7-CS/RP-ESGW-SS7 SR-CAMA PSAP+IPL= 8100ms
VEP-CS/RS/RP-Timer M7-CS/RP-ESGW-CAMA SR-CAMA PSAP+IPL= 10000ms
Overall Maximum call setup time (Timer M1) from time CS receives call – 10 secs
Version 2, (Board Approval Date)                                                 Page 244 of 247
                                                  NENA Interim VoIP Architecture for Enhanced
                                                  9-1-1 Services (i2)
                                                  NENA 08-001 Version 2, (Board Approval Date)


9.8       Issues under Investigation
This Appendix provides a list of issues that are still under consideration in the VoIP Migratory
Work Group. The resolution of these issues may result in revisions to the i2 solution document.
The issues that are currently on the VoIP Migratory group agenda as potential topics for further
investigation are as follows :
      •    Allowing VDB to return MSAG formatted address to LIS
      •    Requirements on VESA operator
      •    Requirements on ERDB/VDB discovery operator
      •    Delivery of Class of Service over v-E2 interface
      •    v0 Interface to Call Server
      •    Redefinition of the v3 interface to be in line with Industry Standards
      •    Support for mobile calls
      •    Support for E9-1-1 Call Control Features
      •    Support for ERDB Steering
      •    Support for internationalization of i2 Solution
      •    Support for an explicit indicator in v-E2 esposreq message identifying the location
           information on which call routing determination was based.
      •    Middle box acquisition and inserted location.
      •    Sending of geocoded location information to the PSAP when original civic location was
           invalid and the ERDB geo-coded the received invalid civic location for routing
           determination purposes
      •    Steering of queries between ERDB’s.
      •    Mechanism used at a routing proxy/redirect server to determine the identity of a VSP.




Version 2, (Board Approval Date)                                                  Page 245 of 247
                                            NENA Interim VoIP Architecture for Enhanced
                                            9-1-1 Services (i2)
                                            NENA 08-001 Version 2, (Board Approval Date)



10 Previous Acknowledgments
Version 1, Approval Date, 12/16/2005
Members:                                    Company
Nate Wilcox – VoIP/Packet Technical         MicroData
Committee Chair
Anand Akundi – Work Group Leader and        Telcordia Technologies
Technical Editor
Nate Wilcox – VoIP/Packet Technical Chair   MircoData
Delaine Arnold                              Arnold 9-1-1 Consulting
Ric Atkins                                  Tarrant County 9-1-1 District
Erica Aubut                                 State of Vermont 9-1-1
Tim Barry                                   AT&T
Marc Berryman                               Greater Harris County 9-1-1
Paul Binder                                 T-Mobile
Patty Bluhm                                 HBF Group
Dean Bordens                                AT&T
Tom Breen                                   AT&T
Tom Browne                                  HBF Group
Guy Caron                                   Bell Canada
Larry Ciesla                                Intrado
Martin Dawson                               Andrew Corporation
Carol DeFazio                               Telcordia Technologies
Martin Dolly                                ATT
Jerry Eisner                                Intrado
Tom Hicks                                   Intrado
Bill Horne                                  Tarrant County 9-1-1
Dick Khan                                   AT&T
Marc Linsner                                Cisco
Bill Marczac                                AT&T
Roger Marshall                              TCS
Jeff Martin                                 TCS
Ken Maynard                                 Bexar Metro 9-1-1 Metro District
Paul Mallett                                CSEC
Patti McCalmont                             Intrado
Dave Morris                                 Verizon
Theresa Reese                               Telcordia Technologies
Brian Rosen                                 Neustar
John Rosenberg                              Lucent
John Savaglio                               AT&T
Carl Smith                                  Intrado

Version 2, (Board Approval Date)                                           Page 246 of 247
                                   NENA Interim VoIP Architecture for Enhanced
                                   9-1-1 Services (i2)
                                   NENA 08-001 Version 2, (Board Approval Date)


Paul Stoffels                      AT&T
Maureen Stork                      Verizon Business
Chuck Thompson                     C.P. Thompson Limited
Larry Truesdale                    Nortel Networks
Greg Welenson                      Vonage
James Winterbottom                 Andrew Corporation




Version 2, (Board Approval Date)                               Page 247 of 247

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:11
posted:7/13/2011
language:English
pages:247