What’s Next for i3?
Dan Mongrain, Senior Solutions Consultant
Bell Canada
Terry Reese
NENA NG9-1-1 Architecture Evolution
Subcommittee Chair
Senior Consultant, Ericsson
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
Overview
 Review
goals and assumptions of the
NENA i3 Solution, as described in NENA
08-003
 Provide status of Version 2 standard
 Identify/prioritize topics for inclusion in
Version 3
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
Background
 NENA
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
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
Background
 Recognizes
that different components of
the NG9-1-1 solution will evolve at different
rates
 Origination
networks
 Emergency Services Networks
 PSAPs
 Gateways
are needed to facilitate
transition to an end-to-end NG9-1-1 solution
 Legacy
Network Gateway (LNG)
 Legacy PSAP Gateway (LPG)
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
Background
 High-Level
Characteristics of the NENA i3
Solution Architecture
 End-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)
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
Background
 High-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
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
Background
 High-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)
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
Background
 NENA
1.
08-003 Assumptions
All calls entering the ESInet are SIP-based
 Calls
may undergo interworking (e.g., at gateway
systems) prior to entering the ESInet
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)
2.
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
Background
 NENA
08-003 Assumptions (cont.)
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 ECRF
4.
 Changes
to the GIS system are automatically
propagated to the ECRF and LVF
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
Background
 NENA
08-003 Assumptions (cont.)
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
6.

N E N A
In recognition of the fact that legacy wireline and
wireless networks will continue to be used for the
foreseeable future
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
Background
 NENA
08-003 Assumptions (cont.)
Legacy PSAP Gateways are included in the i3
architecture to interface between i3 ESInets
and legacy PSAPs
9.
 In
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.
N E N A
Federal, State and local laws, regulations and
rules may need to be modified to support
NG9-1-1 system deployment
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
Background
 NENA
11.
N E N A
08-003 Assumptions (cont.)
While NG9-1-1 is based on international
protocols, the specific protocol mechanisms
defined in NENA 08-003 are North Americanspecific and may not be applicable in other
areas
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
Status of i3 Standard
 Draft
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
Review
 Significant
number of technical and editorial
comments from All Committee Review;
comments are being addressed and
resolved and their disposition recorded
 Next
N E N A
Step: Public Review
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
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

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
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

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
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
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
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

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
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
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
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
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