NENA ISSUE SUBMISSION & CHARTER FORM - NENA-ADM-003

Instructions for NENA ISSUE SUBMISSION FORM:

1.  The Originator completes Section 1 and e-mails the form to the NENA Committee Resource Manager (CRM) at .

2.  Upon approval of the DSC Co-Chairs & HQ Staff[1], the CRM publishes the form for 10-day review.

3.  The Development Steering Council (DSC) reviews Section 1 along with comments received during the 10-day review and decides whether to accept the Issue according to the criteria described in NENA ADM-002. Acceptance of the Issue does not necessarily include acceptance of the “Requested Outcome or Proposed Solution”. If the Issue is accepted and assigned to a Committee, the CRM fills out Section 2 based on DSC instructions.

4.  The Committee Co-Chair(s) and all Subcommittee/Working Group Chairs complete Section 3 (the Working Group Charter) and emails the form to the CRM.

5.  The DSC approves the Working Group Charter and the CRM enters the approval date in Section 2.

6.  The CRM sends a copy of the updated form to the Originator.

7.  The CRM updates Section 2 when the Issue status changes.

NOTE: Some fields on this form will be used to populate the Charter if this Issue is accepted and assigned by the DSC.

Section 1 - Issue Details
To Be Completed by the Originator
Please provide input for all fields
Short title (what the Issue may easily be referred to by)
Data Flow to the PSAP in NG9-1-1 / Date Submitted:
12/15/2016
Originator Name / Roger Hixson
Originator Organization / NENA
Originator Email /
Originator Phone / 202 618 4405
Description of Problem or Opportunity (Provide detailed and clear information. If this is time sensitive or critical provide an explanation.
NENA definition of data flow and structure (replacement and expansion of traditional ALI) within NG9-1-1, to the PSAP, and to other users and applications is needed to set standards and/or recommendations for PSAP display and utilization of data that will be and/or can be produced via NG9-1-1 systems for 9-1-1 calls and messaging. The transition of data from legacy ALI structures to NG9-1-1 effective result, the addition of new data (either produced initially on a call or provided as additional data) to the PSAP display, the PIDF-LO data element to PSAP screen data relationships, the conversion of legacy CoS indicators to the new NG9-1-1 definitions, and the transition from legacy approaches (VPC or MPC/GMLC) to a more integrated data process in NG9-1-1 are all issues in this work. If this is not done, we can expect that vendors and random 9-1-1 Authorities will fill the void and define inconsistent approaches in this environment, allowing for undue inconsistency and confusion in the emergency communications process.
Requested Outcome/Proposed Solution (Provide detailed and clear information):
Note: The final resolution and disposition of this issue may not conform precisely to the Requested Outcome or Proposed Solution. The Working Group consensus will determine the actual means used to accomplish the intent of the Requested Outcome or Proposed Solution.
The expected outcome would be a Standard(s) and/or other documents that would clearly define recommended structure and content of data to be provided to the PSAP (or alternate point) under NG9-1-1 operations, and how the transition from today’s legacy E9-1-1 process to NG9-1-1, and the expansion for other data items from PIDF-LO, multi-media, and other sources can be accomplished utilizing NEIM-compliant schemas, or the documentation of how non-NEIM compliant schemas should be mapped to NEIM-compliant schemas.
(The writer of this ISF assumes that this work will impact and involve multiple NENA Committees, and would likely fall under the auspices of the NGTPC – which was where it was originally intended)
Section 2 – DSC Tracking
To be Completed by NENA DSC
Issue Number / 20161215-2
Date Published for 10-Day Review / 12/20/2016
Review Comments / 01/17/2016
Date and Reasons for Rejection by the DSC
Date Assigned by DSC / 01/17/2016
Submit PINS to ANSI? / ☐ Yes ☐ No Date PINS Submitted:______
Referred To - Who will receive the Issue?:
If applicable, which NENA Committee will own this Issue?
☐ Accessibility ☐ Agency Systems ☐ Data Management ☒ Data Structures ☐ Interconnection & Security ☐ NGTPC ☒ PSAP Operations ☐ Public Education & PSAP Training
Data Management & PSAP Operations who will work with Roger Hixson to further define needs. They will work with Roger and determine who the lead committee will be.
5/9/2017: DATA STRUCTURES WILL TAKE THE LEAD.
Or specify the internal NENA owner of this Issue ______
********************************************************************************************
Or specify which external entity it was referred to:
☐ APCO ☐ ATIS-ESIF ☐ ATIS-PTSC ☐ ATIS-WTSC ☐ IEEE ☐ IETF ☐ NFPA
OTHER ______
Working Group Assigned To
(If applicable)
Estimated/Requested Completion Date of draft (if applicable) / December 2018
DSC Instructions to the Working Group (includes supplements or modifications to the Originator’s Requested Outcome)
Date the Charter is due back to DSC / 02/28/2017
Date Working Group Charter Approved / 05/09/2017
Actual Completion Date
(to be completed later)
Status Updates: link to Scopes & Goals
Resolution: (a brief explanation of how the Issue was resolved for closure)
Section 3 – Working Group Charter
To Be Completed by the Committee Co-Chairs & all Subcommittee/Working Group Co-Chairs, and approved by the DSC. /
Assigned Committee Working Group (should be based on the name used in the Issue Submission form, and include the Parent Committee name.)
Data Structures (lead) and PSAP Operations Committees / Issue Number
(from above)
20161215-2 / Date WG Created
(if it is a new WG)
Goal/Objective/Deliverable (Describe each goal/objective/deliverable and provide detailed and clear information, based on the accepted Issue.)
#1 goal/objective/deliverable: Define structure and content of ALI equivalent data to be delivered on initial display at PSAP.
#2 goal/objective/deliverable: Define structure and content of ALI equivalent data to be delivered upon inquiry (e.g. available on rebid as opposed to available initially for routing, ALI, or both).
#3 goal/objective/deliverable: Transitional plan for ALI equivalent data to NG9-1-1 information and how to handle additional data.
Importance (Rank each goal/objective/deliverable as Essential, Important, or Desirable as follows;
·  Essential – required for something else to succeed
·  Important – helpful toward the success of another work effort
·  Desirable – asset for other reasons
#1 goal/objective/deliverable is ranked: Essential
#2 goal/objective/deliverable is ranked: Essential
#3 goal/objective/deliverable is ranked: Important
Schedule (Considering the Estimated Completion Date for the Issue, establish when each goal/objective/deliverable should be met or accomplished, and provide detailed and clear information, based on the accepted Issue.
If applicable, list any intermediate schedule milestones, e.g., “Outline complete”, “First draft complete”.)
#1 goal/objective/deliverable: April 2018
#2 goal/objective/deliverable: April 2018
#3 goal/objective/deliverable: September 2018 ______
****WG Chairs to determine
Dependencies (Identify all known dependencies for achieving success, e.g., completion of work in other committees or other organizations outside of NENA.)
Participation from i3, Data Structures, and PSAP Ops WG members
Chair(s) (Who will serve as the Chair(s) for the group performing this work? Provide name, phone and email.)
Preferably someone from the i3, Data Structures, and PSAP Ops WG members
Editor(s) (Who will serve as the Editor(s) for the group performing this work? Provide name, phone and email.)
Possibly Steve O’Connor
Participating Organizations (Identify all outside organizations that will be needed for success of the identified goals/objectives/deliverables, e.g., APCO, ATIS, NEIM, IHIS, etc.)
NENA & NASNA
Subject Matter Expertise Needed (Identify the types of SMEs needed to achieve success.)
SMEs from i3, Data Structures and PSAP Ops WG members
Required Resources (Identify the types of non-human resources needed to achieve success, e.g., list server, web site, etc.)
NENA Workspace, TurboBridge, and Join.Me
Initial Work Schedule Plan (Identify the initial call & meeting schedule, e.g., every Tuesday at 10am EASTERN.)
*****Likely every Thursday at 11 a.m. EST (subject to conferring with people who join the WG)
Status Reporting Schedule (The Charter serves as the guiding document to drive work activities toward established goals. Additionally, it serves as a tool to ensure timely status reports to the DSC throughout the work interval. Depending on the nature of the work, and its impact on other work, the timing of status reports may differ among WG activities.
This field is to be used by the DSC to establish the timing of WG status reports to the DSC or designated Project Mgr(s).)
Monthly Scopes & Goals
Measurement (How will each goal/objective/deliverable be evaluated? Use quantitative and/or qualitative measures which are descriptive of the measurement criteria)
#1 goal/objective/deliverable: First step, diagram, explain, and identify ALI screen elements in existing legacy initial delivery data flow; thereafter as a second step diagram, explain, and identify ALI screen elements for NG9-1-1; thereafter as a third step develop an Information or Standards document as feasible and appropriate or move on to Goal #3 Transitional Plan and then do Information or Standards document as feasible and appropriate.
#2 goal/objective/deliverable: First step, diagram, explain, and identify ALI elements in existing legacy initial delivery data flow ; thereafter as a third step develop an Information or Standards document as feasible and appropriate or move on to Goal #3 Transitional Plan and then do Information or Standards document as feasible and appropriate.
#3 goal/objective/deliverable: After completing Essential Goals #1 and #2, timing and combination differences should be considered to develop a transition plan for NG9-1-1 data flow via an Information or Standards document as feasible and appropriate.
Further Explanation
“ALI equivalent Data” relates to how call related data in and under NG9-1-1 design would flow and be presented to the PSAPs, and how that could be compared to ALI as we know it today in E9-1-1 and transitional NG9-1-1, where there is no LIS and there is no CIDB. In other words, what changes with the actual NG9-1-1 designed data flow process, as compared to ALI as we know it today. For example, depending on how the OSPs choose to provide calls and data, some NG9-1-1 design features are enabled or not. For instance, if they continue the pANI process as today, we will never get to caller location based routing, or maybe some partial process that still continues either the cell/sector pre-determined PSAP, or a better routing process that is still done outside the NG9-1-1 system. Software changes by the OSPs would be required to cause wireless carrier routing to the appropriate NG9-1-1 system, and the NG9-1-1 then determine and control the route to the appropriate PSAP, or a PRF determined alternate PSAP, based on GIS ECRF/ESRP data.As another example, in NG9-1-1 design, there is no single data item equivalent to Class of Service as we know it today, rather potentially three different items of data that in combination provide the same info (and more) than is true with a single CoS field today. In addition, to Data Flow to the PSAP, what a PSAP is willing to display or hide on their ALI screen may impact data flow and its importance. So there are various data flow alternates and related potential timing issues related combinations to both the nature of the network and routing control involving the data flow and how it works.

Attachment

Operations Transition Conceptual Outline

(for use with Committee leads to help clarify the identification of gaps in current information for Public Safety 9-1-1 service management)

What are the gaps in our documentation between E9-1-1 using traditional procedures vs NG9-1-1 and operational variations?

·  Review other NENA and related NG9-1-1 planning and transition documents (provide link(s))

What procedures are needed, what do we have covered, what don’t we have covered ( = gaps )

1.  Procedures to provision/prepare an IP network for later use as an ESInet

2.  Preparing ESInet IP network as base for NG9-1-1 operation

3.  Identifying ESInet and NG9-1-1 core system operations issues

a.  Policy, organizational and governance structure to support NG9-1-1

(may be more NGPP related?)

i.  What are our assumptions about these areas being established in prep for ops transition?

ii. What’s in place or being put in place before the actual start of `Ops transition’?

  1. ESInet network management with vendor
  2. What are the changes involved in moving from an E9-1-1 environment where the physical network is a given to Public Safety operations to an NG9-1-1 environment where active involvement by Public Safety operations with a vendor of an IP network is part of the process?
  3. Take other emergency services applications on the ESInet into account
  4. NG9-1-1 core system management with vendor or vendors

(assumes we are not treating NG9-1-1 core system self-management case)

  1. Establishment of databases (list major DBs for clarity)
  2. Testing – network testing, DB testing, functional testing, ongoing testing
  3. Public education

4.  Identifying NG9-1-1 related PSAP operations issues

  1. Present and transition period
  2. Near future
  3. PSAP internal systems upgrades (logging, recording, MIS, CAD, etc, including hosted options)
  4. Data base content to NG9-1-1 core system (central database management group?)
  5. New additional data and info and its use by the PSAP and other users
  6. Security
  7. Education and training needs

5.  User education

6.  Public education – as 9-1-1 service transitions to new media and device capabilities

NENA ADM-003, 07/28/2015 Page 3 of 7

[1] See ADM-002 for details surrounding Issue acceptance.