1 / 19

What’s Next for i3?

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

jada
Download Presentation

What’s Next for i3?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related