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

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

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

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)

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)

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

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)

Background NENA 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 All calls entering the ESInet will include location in the signaling with the call (under normal conditions)

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) 9-1-1 Authorities have accurate and complete GIS systems that are used to provision the LVF and ECRF Changes to the GIS system are automatically propagated to the ECRF and LVF

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 Periodic re-validation of civic location against the LVF is needed to assure that location remains valid as GIS data changes 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

Background NENA 08-003 Assumptions (cont.) Legacy PSAP Gateways are included in the i3 architecture to interface between i3 ESInets and legacy PSAPs 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 Federal, State and local laws, regulations and rules may need to be modified to support NG9-1-1 system deployment

Background NENA 08-003 Assumptions (cont.) 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 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 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