What’s Next for i3?

N E N A D e v e l o p m e n t C o n f e r e n c e | O c t o b e r 2 0 1 4 | O r l a n d o , F l o r i d a

What’s Next for i3?

Dan Mongrain, Senior Solutions ConsultantBell Canada

Terry Reese

NENA NG9-1-1 Architecture Evolution Subcommittee Chair

Senior Consultant, Ericsson


Overview

Review goals and assumptions of the NENA i3 Solution, as described in NENA 08-003

Provide status of Version 2 standardIdentify/prioritize topics for inclusion

in Version 3


BackgroundNENA 08-003, NENA Functional and

Interface Specification for the NENA i3 Solution – Stage 3, Version 1, was published in June of 2011

Describes an end-state NG9-1-1 architecture

Focuses on the network, components, and interfaces required to establish Next Generation 9-1-1 service


BackgroundRecognizes that different components of

the NG9-1-1 solution will evolve at different ratesOrigination networksEmergency Services NetworksPSAPs

Gateways are needed to facilitate transition to an end-to-end NG9-1-1 solutionLegacy Network Gateway (LNG)Legacy PSAP Gateway (LPG)


BackgroundHigh-Level Characteristics of the NENA i3

Solution ArchitectureEnd-to-end IP signaling from IP-enabled

endpoint to IP-enabled PSAP (end state)Emergency calls are routed to the correct

PSAP based on caller location; callback number and caller location are delivered to the PSAP with the call

Calls are expected to be multimedia (i.e., audio, video, text)


BackgroundHigh-Level Characteristics of the NENA i3

Solution Architecture (cont.)Supports call originations from many different

kinds of devices and services (e.g., SMS, IM, video phones, PDAs, telematics)

Call originations from legacy wireline/wireless originating networks, as well as from VoIP callers and text messaging applications, will be supported


BackgroundHigh-Level Goals of i3 Solution:

Provide at least wireline/wireless-equivalent functionality to support emergency call originations from fixed, nomadic, and mobile IP users

Build on those capabilities to improve performance and extend feature functionality (e.g., to support delivery of text-based emergency service requests to PSAPs)


BackgroundNENA 08-003 Assumptions

1. All calls entering the ESInet are SIP-basedCalls may undergo interworking (e.g., at gateway

systems) prior to entering the ESInet

2. Access Network Providers provide some type of location function for their networks

3. All calls entering the ESInet will include location in the signaling with the call (under normal conditions)


BackgroundNENA 08-003 Assumptions (cont.)

4. 9-1-1 Authorities have transitioned from tabular MSAG/ESNs to GIS-based Location Validation Function (LVF) and Emergency Call Routing Function (ECRF)

5. 9-1-1 Authorities have accurate and complete GIS systems that are used to provision the LVF and ECRFChanges to the GIS system are automatically

propagated to the ECRF and LVF



6. Civic location will be validated by the access network against the LVF prior to an emergency call being placed

7. Periodic re-validation of civic location against the LVF is needed to assure that location remains valid as GIS data changes

8. Legacy Network Gateways are included in the i3 architecture to interface between legacy originating networks and i3 ESInets

In recognition of the fact that legacy wireline and wireless networks will continue to be used for the foreseeable future



9. Legacy PSAP Gateways are included in the i3 architecture to interface between i3 ESInets and legacy PSAPsIn recognition of the fact that not all PSAPs will

have upgraded to i3 compatibility even after Emergency Services Network transitions away from Selective Routers and ALI systems

10. Federal, State and local laws, regulations and rules may need to be modified to support NG9-1-1 system deployment



11. While NG9-1-1 is based on international protocols, the specific protocol mechanisms defined in NENA 08-003 are North American-specific and may not be applicable in other areas


Status of i3 StandardDraft of version 2 Standard has

undergone Working Group Review and All Committee Review

i3 Architecture WG is in the process of addressing comments from All Committee ReviewSignificant number of technical and editorial

comments from All Committee Review; comments are being addressed and resolved and their disposition recorded

Next Step: Public Review


Potential Future Work Items SDO convergence work to align the details between i3

and related origination network 9-1-1 interfaces Provide additional clarity on how elements and services

interact, and how clients use elements and services Standardized SNMP MIBs for each FE Addition of XMPP as an additional IM protocol supported

by NG9-1-1 Descriptions of the Provisioning Service Objects (PSOs)

defined for standard functions Validation of geodetic coordinate-based location Further examples of call routing, including examples of

geodetic coordinates-based call routing using the LoST interface


Potential Future Work Items Provide a standard NENA schema for WFS as used in the

i3 SIF layer replication protocol Provide further Discrepancy Report definitions; reconcile

definitions with those in NG Data Management standard Specify policy document structures for each of the

policy instances defined for the ESRP Consider supporting the ability to have an alternative

address returned by the LVF (as is supported by the i2 Validation Database)

Address support for testing of Policy Routing Rules Consider the suitability of IETF-standard geocoding

protocol/service, should one be developed, as possible replacement for current NENA-specified interface


Potential Future Work Items Revisit the four mechanisms currently specified for call

transfer to see if consensus can be reached on reducing the number of options

Define a mechanism for obtaining updates to Incident state

Describe a way of controlling the information that must be logged, since current procedures involved a large amount of logging and situations where information is logged by both the sender and the receiver

Describe which elements generate which log event types

Provide recommendations on siprec metadata to improve interoperability

Define mechanisms to support blind and supervised transfer, and the logging associated with such transfers


Potential Future Work Items Specify a more general way to connect to Agency

Locator Search Services Provide detailed definition of the Map Database Service Specify minimum standards for PSAP Credentialing

Agency (PCA) Certificate Policy and Certification Practice Statement conformance

Include reference to a future INF document that defines roles

Specify the value that should be populated as the “TTT” value delivered to legacy PSAPs for VoIP calls

Specify the interworking function between MSRP and TTY

Define the XML structure for Additional Data Associated with a Location


Potential Future Work Items Describe the PSAP Management Interface Describe the handling of ALI Query Service

parameters by NG9-1-1 elements Expansion of Appendix B to include additional fields

in support of MSAG Conversion Service Support for standard NENA schemas Identification of “minimum set” of requirements to

be considered “compliant with” i3 standard; prioritization of features during transition to full i3 compliance

Include examples of SIP header use to facilitate interoperability


Potential Future Work Items Further evaluate the role of the Spatial Information

Function (SIF), including functions for GIS data warehousing, QA/QC and data aggregation

Identify new Functional Element to support multimedia callbacks

Revisit handling of Baudot tones at Legacy Network Gateways and Legacy PSAP Gateways

Define how Emergency Incident Data Documents (EIDD) are transported between Functional Elements

Define how a citizen can transfer a file (video, picture, etc.) to a PSAP

Define interworking between Multimedia Messaging Service (MMS) and PSAPs