ng9-1-1 core architecture: i3 v3 terry reese brian rosen

NG9-1-1 Core Architecture: i3 v3TERRY REESE

BRIAN ROSEN

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

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)

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 servicesWork 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 termWork Group: i3 Architecture


•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 addressedWork 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


•Inclusion of XMPP as a protocol to support Instant Messaging

Work Group: i3 Architecture

•Provide additional examples of call routingWork Group: i3 Architecture

•Determine whether referenced OGC documentation is sufficient to enable interoperable implementations



•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



•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


•Support the ability to have an alternative address returned by the LVF (as is supported by the i2 Validation Database)


•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


•Support for testing of Policy Routing RulesWork Group: Data Management

•Revisit the four mechanisms currently specified for call transfer to see if consensus can be reached on reducing the number of optionsWork Group: i3 Architecture


•Specify the details related to the Map Database Service and its interfaces

Work Group: i3 Architecture/Data Management

•Define the PSAP Management interfaceWork Group: i3 Architecture

•Specify a more general way to connect to the Agency Locator Search Services



•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


•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 transfersWork Group: Data Management


•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


•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


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


•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 operationWork Group: i3 Architecture

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

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

ng9-1-1 core architecture: i3 v3 terry reese brian rosen

Documents