1. NG9-1-1 Core Architecture: i3 v3 TERRY REESE BRIAN ROSEN

2. Overview Current status of the i3 standard Discuss i3 v3 topics identified to date Identify Work Groups where i3 v3 topics will be addressed and support needed from other Work Groups Identify other potential topics to be addressed in the i3 v3 standard

3. Status of the i3 Standard Draft of i3 version 2 Standard has undergone Work Group Review, All Committee Review and Public Review i3 Architecture WG is in the process of addressing comments from the Public Review ◦ Over 1000 technical and editorial comments were received from the Public Review ◦ Comments are being addressed and resolved and their disposition recorded (~87% complete as of 9/10)

4. i3 v3: Topics and WGs Element and service interactions ◦ Additional clarity is needed to describe how elements and services interact, and how clients use elements and services  Work Group: i3 Architecture Clarification needed regarding use of term “near real time” ◦ Definitions, maximums and/or implementation guidance is necessary for each instance of this term  Work Group: i3 Architecture

5. i3 v3: Topics and WGs Further specification of the MSAG Conversion Service is needed ◦ Additional clarity needed to describe how MSAG and PIDF-LO elements relate ◦ Abnormal/error conditions need to be fully addressed  Work Group: i3 Architecture (with input from Data Structures) Simple Network Management Protocol (SNMP) Management Information Bases (MIBs) need to be standardized for each Functional Element  Work Group: ESIND/Data Structures

6. i3 v3: Topics and WGs Inclusion of XMPP as a protocol to support Instant Messaging  Work Group: i3 Architecture Provide additional examples of call routing  Work Group: i3 Architecture Determine whether referenced OGC documentation is sufficient to enable interoperable implementations  Work Group: i3 Architecture

7. i3 v3: Topics and WGs Provide a standard NENA schema for WFS as used in the i3 SI layer replication protocol  Work Group: XML WG Consider the suitability of IETF-standard geocoding protocol/service, should one be developed, as possible replacement for current NENA-specified interface  Work Group: i3 Architecture

8. i3 v3: Topics and WGs Discrepancy Reporting ◦ Discovery mechanism needs to be defined for elements (such as an ECRF) that have a corresponding DR web service ◦ A separate discrepancy report document (i.e., NG Data Management standard) exists, and must be reconciled with the i3 Standard  Work Group: Data Management Specific policy document structures for each of the policy instances defined for the ESRP  Work Group: i3 Architecture/Data Structures

9. i3 v3: Topics and WGs Support the ability to have an alternative address returned by the LVF (as is supported by the i2 Validation Database)  Work Group: i3 Architecture Extend description of callback call handling ◦ Need to address the handling callback calls that include media other than voice ◦ Need to address requirements for labeling callback calls destined for IMS- based origination networks  Work Group: i3 Architecture

10. i3 v3: Topics and WGs Support for testing of Policy Routing Rules  Work Group: Data Management Revisit the four mechanisms currently specified for call transfer to see if consensus can be reached on reducing the number of options  Work Group: i3 Architecture

11. i3 v3: Topics and WGs Specify the details related to the Map Database Service and its interfaces  Work Group: i3 Architecture/Data Management Define the PSAP Management interfac e  Work Group: i3 Architecture Specify a more general way to connect to the Agency Locator Search Services  Work Group: i3 Architecture

12. i3 v3: Topics and WGs EIDD Topics ◦ Define a mechanism for obtaining updates to Incident state ◦ Define an EIDD transport mechanism to support the conveyance of EIDDs between agencies, systems and applications  Work Group: EIDD

13. i3 v3: Topics and WGs Logging Topics ◦ 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  Work Group: Data Management

14. i3 v3: Topics and WGs Specify minimum standards for PSAP Credentialing Agency (PCA) Certificate Policy and Certification Practice Statement conformance  Work Group: PCA Specify the interworking function between MSRP and TTY  Work Group: i3 Arch

15. i3 v3: Topics and WGs Specify the value that should be populated as the MF “TTT” value delivered to legacy PSAPs for VoIP calls ◦ In a legacy environment, the “TTT” represents an end office identifier associated with the incoming trunk group to the E9- 1-1 tandem; it is signaled to a legacy PSAP when neither callback nor location information is available  Work Group: i3 Arch Define the XML structure for Additional Data Associated with a Location  Work Group: Additional Data

16. i3 v3: Topics and WGs Data Mappings ◦ Clarify how conversion between legacy formats and NG9-1-1 formats is accomplished ◦ Describe how parameters in an AQS query are handled by NG9-1-1 elements ◦ Specify additional fields to allow MSAG Conversion Service to operate correctly  Work Group: i3 Architecture (with input from Data Structures)

17. i3 v3: Topics and WGs PSAP Call Control Features ◦ Add clarifying text describing support for an SDP offer with an “a=suspended” attribute in IP originating networks ◦ Include additional call flow examples illustrating PSAP Call Control Feature operation  Work Group: i3 Architecture

18. Other Potential i3 v3 Topics Reorganization of i3 material into multiple smaller documents ◦ The i3 version 2 standard is currently close to 375 pages long ◦ Consideration being given to breaking the document into logical chunks that could be worked on/maintained separately  E.g., Move the text related to the Legacy Network Gateway (LNG) and Legacy PSAP Gateway (LPG) out of the i3 standard and combine it in a separate document with the material in the standard being created for the Legacy Selective Router Gateway (LSRG)  Other potential topics to be addressed in separate documents/modules include: ◦ Logging ◦ Additional Data ◦ Discrepancy Reporting ◦ Security–related topics (e.g., definition of roles, PCA standards specification) ◦ Data mappings

19. Other Potential i3 v3 Topics Re-definition of Spatial Interface (SI) ◦ Interface between an authoritative copy of GIS data and functional elements within an ESInet (e.g., ECRF and LVF) ◦ An SI layer replication interface is used to maintain copies of GIS layers that drive call routing, and location validation and display of maps within an NG9-1-1 system ◦ Open issue as to whether referenced OGC documentation is sufficient to support interoperable implementations ◦ SI needs to be revisited in i3 v3 ◦ Will require Data Management expertise