What’s Next for i3?

1. What’s Next for i3? Dan Mongrain, Senior Solutions ConsultantBell Canada Terry Reese NENA NG9-1-1 Architecture Evolution Subcommittee Chair Senior Consultant, Ericsson

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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