€¦ · XLS file · Web view · 2017-06-135890. 5900. 5910. 5920. 5930. 5940. 5950. 5960. 5970. 5980. 5990. 6000. ... 35900. 35910. 35920. 35930. 35940. 35950. 35960. 35970. 35980

Instructions

Date: 05/06/2023 Time: 22:53:09 1 of 115

The tabs have been formatted to print on legal size paper.

Instructions: Fill in the Proposer Company Name below.[insert Company Name here]Fill in the Class (ESInet & Core or L&R or GIS) for this RCM below.[insert Class here]

Proposer Compliance Comments

Proposal Section Reference

Other Proposer CommentsThis column is to be used at the Proposer's discretion for relevant information not covered elsewhere.

Overview: The intent of the Requirements Compliance Matrix (RCM) is to understand the Proposer's level of compliance to each line in the three tabs of this document. The RCM also provides a baseline set of requirements, which will be updated during the systems engineering design process as described in RFP section III.D.1. The Evaluation Guidance tab provides general evaluation guidance so Proposers can gain an understanding of the relative importance to the City of the technical areas or categories in the RFP.

Proposer Compliance:Full (F) / Partial (P) /

Not (X) / Not Applicable (NA)

The Proposer shall fill in for each line in the RCM if their proposal is Fully (F), Partially (P) or Not (X) compliant to the specific Requirement Text, to be placed in the column with the above heading.

If the requirement does not apply to their class/scope of work, the Proposer shall designate the requirement as NA. For example, if the requirement under review is associated with the ESInet/Core but the Proposer is only providing a response to the GIS scope of work, the column shall be filled-in with NA.

Note: it is not acceptable to denote statement of work tasks or other requirements as NA if the intent as described in the RFP is for all classes/scopes of work to participate or implement that functionality or activity (e.g. participation in the design review, test phases, etc. - these are mandatory).

The Proposer shall provide comments to explain each partial or non-compliance; they may also provide other details at their discretion. As discussed in the body of the RFP, if the Proposer will meet the spirit of the requirement, or if the requirement is badly worded, a Partial or Not Applicable response will not necessarily be viewed negatively by the City if it is explained well.

The Proposer shall provide the reference to the section of their proposal which covers the subject matter addressed by the line of Requirement Text, as applicable. It will certainly make it easier for the city to understand, correlate and otherwise appreciate the linkage between the proposal content and the requirement it covers.

NOTES:

The "Comments" column provides supplemental information as a reminder to the Proposer when planning the technical response. The contents of the table are subject to change with any change being communicated by the ACCO to all Proposers.

Technical Categories RFP and RCM Sections Comments

1 20

2 Subsystem Availability 15

3 10

4 10 III.D.1 and elsewhere in III.D

5 10

6 10

7 5

8 5 III.D.9 and elsewhere in III.D

9 Training 5

10 5

11 5

Total 100

The table shown below provides general evluation guidance only so Proposers can gain an understanding of the relative importance to the City of the technical areas or categories in the RFP. The "Total Scoring %" column is the planned quantification for scoring. The "RFP and RCM Sections" column is an indication of the major RFP sections / subsections where the associated technical category can be found. The Proposer should expect that other sections / subsections in the RFP may contain scope or requirements that additonally apply to that technical category. Therefore a thorough review of all the sections / subsections of the RFP is recommended and all items should be addressed systematically in the Proposer's technical proposal. The City will evaluate each technical category in aggregate but also look for completeness of the response, regardless of the subsection where the information is found or the number of requirements.

Category ID #

Total Scoring %

Subsystem Architecture and Scope of Work Details

RFP Class in III.D.3 or III.D.4 or III.D.5; also III.C.2, III.C.3, III.D.6.a and in the rest of III.D.6

• The Class or scope of work is contained in III.D.3 or III.D.4 or III.D.5• Requirements for each Class that do not fall into any other Technical Category shall be aggregated here

III.D.2 and all availability subsections in III.D

• Each Class to support 6 nines overall• 5 nines per subsystem• No single point of failure• Provide Availability analysis

Standards ComplianceThroughout Section III, NENA tab in RCM, and Appendix H

• Higher emphasis on compliance to NENA tab in RCM

Systems Engineering Process and Design Phases

• Requirements review process• Design review process

Subsystems Integration and Test

III.D.7 and elsewhere in III.C and III.D

• Integration phases plans and execution • Test phases plans and execution

Cyber and IT Security III.D.8 and "IT Security Requirements" tab in RCM

Technical Project Management

III.D.1, III.D.13, and elsewhere in III.D and III.E

Robustness and Utilization of the SDE

III.D.10 and elsewhere in III.D

Control, Reporting, and Statistics

III.D.11 and elsewhere in III.D and III.E

Operations and NOC Functionality

III.D.12 and elsewhere in III.D

Requirements in RFP Body

Date: 05/06/2023 Time: 22:53:09 3 of 115

RCM ID # RFP Section # RFP Section Name Requirement Text Proposer Compliance Comments Proposal Section Reference Other Proposer Comments

I. TIMETABLE [N/A for this RCM]II. [N/A for this RCM]

III

500III.A

510

520 530 Project scope includes twenty (20) neighboring 9-1-1 jurisdictions,

540

550

560

570

580

590

600

610

620

630

640

III.B.1 Proposer shall be strong financially.

650

660

670

III.B.2 Proposer's Role

680

690



SUMMARY OF THE REQUEST FOR PROPOSALS

SCOPE OF SOLUTION / SERVICESAgency Goals and Objectives for this RFP

Project scope includes replacing the two (2) DMS 100 Tandems and all associated networking facilities that are currently in-service supporting E9-1-1 delivery, with standards-compliant NG9-1-1 ESInet and Core Services.

Project scope includes the migration of all Originating Service providers (OSPs) currently providing services in the City to new NG9-1-1 call aggregation points.

Project scope includes the interconnection with other systems (child rqts below)

Project scope includes the existing ancillary systems and the Public Switched Telephone Network (PSTN) to include, but not limited to, EANs, Tie lines, ERS/BARS, VOIP, orderline, Ring Down, orderwire, voice alarm, 6wire, legacy voice, 311, 10 digit numbers, SolarCell, LinkNYC, L&R eSubpoena (NICE Investigate),

Project scope includes the existing Interim Text to 9-1-1 system via its Terminating Text Control Center (T-TCC),Project scope includes the NG9-1-1 Call Handling subsystem and its vendor – jointly with the City

Project scope includes the existing legacy L&R subsystem which will continue to support the City’s Radio efforts and other analog 911 telephony subsystems

Each Proposer shall implement a subsystem that meets or exceeds the performance, availability objectives established for the NG9-1-1 system of systems per Appendix F and the Availability Section III.D.2.

Each Proposer shall implement a subsystem that is fully compliant with all NG9-1-1 standards developed under the auspices of the National Emergency Number Association (NENA), the Internet Engineering Task Force (IETF), the Alliance for Telecommunications Industry Solutions (ATIS), and the other standards listed in Appendix H.

Each Proposer shall fully assist the City to realize a robust, integrated, and coordinated NG9-1-1 solution where the City acts as the lead and overall systems integrator.

Proposer shall provide key integration services with each of the other selected Proposers and their corresponding subsystems. Proposer shall price integration services into their proposal, assuming an undetermined but capable selected Proposer for the other scopes of work.

Proposer is encouraged to quantify any cost savings for integration services in the case where they themselves are the selected Proposer for other scopes of work they have bid.

B. Agency Assumptions Regarding Proposer ApproachProposer's Capabilities

Proposer shall have a demonstrated track record of delivering large, complex projects in general, and NG9-1-1 systems in particular.

Proposer and their selected team members (if any) must have a long-term commitment to NG9-1-1 and have the organizational structure, staff expertise and commitment to good project management practices which will together successfully meet the City's needs.

Proposers are encouraged to propose a complete solution for each scope of work using all of their own products and services. Alternatively, Proposers may provide a Prime / Subcontractor relationship which selects best in class subcontractors who collectively provide all necessary products and services.

Proposer may submit a proposal that meets the RFP requirements within each scope of work. Proposer shall submit a detailed explanation of the roles and responsibilities of the Proposer and all subcontractors.

All Proposers and their sub-contractors must be currently registered with the City via the City’s web based system per Section III.G and Attachment E of this RFP.


Date: 05/06/2023 Time: 22:53:09 4 of 115

RCM ID # RFP Section # RFP Section Name Requirement Text Proposer Compliance Comments Proposal Section Reference Other Proposer CommentsProposer Compliance:Full (F) / Partial (P) /


700III.B.3

710

720

730

III.B.4

740

III.B.5

750

760III.B.6 Business Continuity Plan

761

762

763

770

III.B.7

780III.B.8

790

III.C

800

810

820

830

840

850

860

870

Proposer's Financial Stability

Proposers shall have the financial strength to fulfill the requirements of each scope of work.The successful Proposer shall have a track record of profitability at the corporate level in addition to the operating unit responsible for NG9-1-1 products and services.The successful Proposer shall have sufficient working capital to procure the necessary equipment and staff the project.

Proposer's Successful Track Record in NG9-1-1

Proposer shall have a successful track record in installing NG9-1-1 systems, migrating OSPs from E9-1-1 to NG9-1-1, interconnecting with neighboring 9-1-1 jurisdictions, adapting to IP-based and legacy Ancillary systems, interfacing with NG9-1-1 Call Handling Subsystems and managing the full system during steady-state operations – as appropriate and relevant for each scope of work.

Proposer's Long-Term Commitment to NG9-1-1

Proposer shall have a demonstrated commitment to NG9-1-1 and specifically to products and services for Government customers, as demonstrated by active participation in standards development organizations, participation in industry forums, especially NENA and the NENA Industry Collaboration Events, hiring and developing of staff with 9-1-1 experience and Emergency Number Professional (ENP) credentials and active participation in the evolution of regulatory regimes applicable to NG9-1-1 at the state and federal levels.

The Proposer's long-term commitment to NG9-1-1 shall be evidenced by the R&D investments they make on an annual basis.

The selected Contractor(s) and all subcontractors must have a business continuity plan in place.This plan shall include major threats and risks to business operations, impact analysis of the threats, and preventive and recovery planning to minimize the potential harm.The plan shall include steady-state operations of the system as well as during the development and implementation of the NG9-1-1 solution / services.

The plan shall be submitted 30 days after contract award. Parts of the plan that deal specifically with products or services required by the City shall be identified in the plan that will need to be submitted 30 days after contract award.

Proposer's Protection of the City's Information

Proposers and their subcontractors shall have policies and procedures in place to protect the information provided by the City and information developed as part of the contract based on each scope of work. NDA (Nondisclosure Agreements) from the Prime Contractor and its sub-contractors shall be submitted to the City 30 days after contract award.

Proposer's Acceptance of Contract Terms

Proposers shall agree to the mandatory terms of the proposed agreement for this procurement and provide feedback on other negotiable terms.

Technical Solution Overview

The successful Proposer(s) shall implement Next Generation 9-1-1 (NG9-1-1) scopes of work consistent with the latest public safety industry standards and regulations as published by NENA, the Internet Engineering Task Force (IETF), the Alliance for Telecommunications Industry Solutions (ATIS), and the other standards listed in Appendix H.

Each selected Proposer shall work cooperatively such that the City achieves a robust, integrated, and coordinated NG9-1-1 solution.

The required solution shall replace the redundant and diverse pair of DMS-100 tandems and Automatic Location Information (ALI) service. The NG9-1-1 system shall also replace all TDM network facilities used in the current system.

The selected Proposers shall provide a managed solution to the City, once the subsystems become operational.

The NG9-1-1 system shall accept and aggregate all 9-1-1 calls originating in any of the five NYC boroughs, along with transferred calls from neighboring jurisdictions. The NG9-1-1 system shall deliver such calls to a new, NG9-1-1 Call Handling Subsystem that supports call takers in the two (2) Public Safety Answering Centers serving the City.

The successful Proposers will be responsible for all aspects of the transition from the current E9-1-1 call routing and call aggregation subsystem to the NG9-1-1 system.Each selected Proposer shall deliver a subsystem that must be highly available and meet stringent performance, reliability and capacity requirements per Appendix F and the Availability Section III.D.2.

Physical and cyber security of each NG9-1-1 subsystem is of vital importance to the City and the Proposer shall meet all related, referenced guidelines and standards.

Since many aspects of the design of the NG9-1-1 solution for the City will be left to the selected Proposer, the Proposer shall design a robust solution with the City providing strong oversight and approvals.


Date: 05/06/2023 Time: 22:53:09 5 of 115



880

890III.C.2

900

910

920

930

940

950

960

970

980

990

1000

1010

1020

1030

1040

1050

1060

The successful Proposers must demonstrate how their solution meets the high standards set by the City.

Envisioned NG9-1-1 System

The successful Proposers shall be responsible for implementing the integrated, coordinated NG9-1-1 system logically shown in Box 1 of Figure 2, per the industry and City standards of Appendix H.

The NG9-1-1 system shall interconnect with all the subsystems depicted in Boxes 2, 3, 4, 5 and 6 of Figure 2 and the "Notes" that follow Figure 2.The NG9-1-1 system shall interconnect with the existing / legacy L&R subsystem depicted in Box 5 of Figure 2 and in Figure 3.

The subsystem interconnections shall support the transport of all media types including voice, text, photos, video and data.

The selected Proposers shall each provide the proper interfaces and integration to one another and to each of the subsystems in Figure 2, to ensure the proper call routing.

As shown in Figure 3, the NG9-1-1 L&R subsystem proposed by the Proposer shall:1. implement full NG9-1-1 Logging and Recording per the NENA standards. 2. interface with the ESInet and Core Services Functional Elements, the Call Handling Subsystem and T-TCC.3. interface to the existing Radio L&R subsystem.

For NG9-1-1 provisioning and reporting systems as depicted in Figure 4 and clarified in the "Notes", Proposers shall provide a complete description of all interfaces and a detailed description of the user experience provided by the Proposer's proposed Graphic User Interfaces (GUI).

Each Proposer shall be instrumental in the City achieving an integrated, coordinated solution where the City will play an active role in the oversight and assurance of the overall system meeting its needs.

Proposers shall provide real-time or near real-time access to the ESInet and Core Services and L&R subsystems performance data with two points of interface: the City’s trouble ticketing system and the Proposer’s Reporting and Statistics Capture (RSC) Portal as described logically in Figure 5, clarified by the "Notes".

Proposers are required to integrate to, and use the City’s trouble ticketing/helpdesk, NOC, SOC, and enterprise services directly through a City provided interface.

The Proposer shall offer a help desk contact interface accessible to the City’s Public Safety Help Desk, Originating Service Providers, and neighboring jurisdictions so that the Proposer’s helpdesk staff, who are required to be available 24x7x365, can be reached (e.g. 800 number, email, paging).

The Proposer's RSC interface shall provide access to real-time or near real-time system performance data.Each Proposer's subsystem shall provide functionality for an Application Programming Interface (API) which supports SQL database queries by an autonomous authenticated external computer, which shall be made available for each SQL database in the subsystem (i.e. for both the L&R or ESInet and Core Services subsystems).

Each Proposer's subsystem shall provide a GUI to permit an operator to manually enter and execute SQL database queries for each SQL database in the subsystem (i.e. for both the L&R or ESInet and Core Services subsystems).

The Proposer shall deploy the NG9-1-1 and L&R subsystem, shown in box “1” in Figure 2, within PSAC1 and PSAC2, and within an optional third site. Deployment of a NG9-1-1 and L&R subsystem in the City Solution Development Environment (SDE) is also mandatory. A description of the SDE configuration and requirements can be found in Section III.D.9.

The Proposer shall deploy a NG9-1-1 and L&R subsystem in the City Solution Development Environment (SDE). A description of the SDE configuration and requirements can be found in Section III.D.9.

The Proposer shall consider and propose alternatives to the described City approach in a manner sufficient for the City to consider them. The primary considerations for the physical deployment of the functional elements are: 1) system availability, resiliency, redundancy and diversity, 2) Physical security, 3) cyber security and protection of data, 4) compliance to requirements and standards and 5) future expansion of storage, network capacity and the eventual interconnection with NG9-1-1 systems deployed elsewhere in New York State.

The call aggregations functionality, ESInet, gateways and all core services shall be physically located within the two PSACs.


Date: 05/06/2023 Time: 22:53:09 6 of 115



1070

1080

1090

1091

1100

1110

III.C.3

1120

1130

1140III.D

1150

1160

1170

1180

1190

1200

1210

1220

Although the City will cover the cost of power, cooling and cabinet/racks for any Proposer equipment hosted at the SDE, either PSAC, or the optional third site, all network facilities and WAN connections required by the Proposer shall be included in their price proposal. WAN connections between PSAC1, PSAC2, and the SDE must be included for the purposes of this proposal and must be priced. WAN connections and equipment to all OSPs, either temporary or permanent, must also be priced.

The Proposer shall address each requirement by stating its full, partial or non-compliance to these and other requirements, or possibly not applicable when appropriate, by filling out this Requirements Compliance Matrix (RCM).

Proposers shall provide comments, state the reason for non-compliance, and possibly provide rewording of any requirement in the Proposer Compliance Comments column in the RCM, adjacent to the requirement, if the intent of a particular requirement is unclear or technically incorrect.

For any noncompliant requirement response, the Proposer shall provide a clear explanation of how their solution meets the City’s intent.The Proposer shall bring any requirements changes to the attention of the City during the Questions phase of the RFP process identified in Section I.

NG9-1-1 ESInet and Core Services Planning and Implementation Roles and Responsibilities

The selected Proposers shall enable the City to achieve an integrated, coordinated solution encompassing all aspects of the NG9-1-1 system described in the RFP.

The selected Proposers shall enable the City to be actively involved in the systems engineering lifecycle, configuration, transition to operations and in monitoring the day-to-day operations of the system.

For each Activity in Table 2, the selected Proposer(s) shall meet the role described and enable the City to meet its roles.

Detailed Technical Requirements

The Proposer shall understand, acknowledge, and follow the over-arching guidelines / instructions given below before drafting the narrative for their Technical Proposal:

The City will be actively involved in the requirements, design and test phases of the project. The City - in its sole discretion - will provide approval of the requirements baseline, final design, formal testing and transition to operations, to ensure the solution meets the City's needs. Once the capability in this RFP becomes operational, the project will become a managed service for the remainder of the contract period.The Proposer must address all the requirements that are included throughout the narrative of this RFP, referenced in a website, or referenced in the Appendices and Attachments. Note: The selected Proposer and/or City may revise the wording of any requirement during the requirements and/or design phases as required to implement a proper solution.

The City may have included some high-level requirements to the RCM that are referenced, but may not be fully or formally quoted in the text of the RFP. The City requires the Proposer to state their compliance to the overall intent of these requirements and reference the specific section number of their proposal narrative in the RCM.

The RCM (this document from ATTACHMENT J) is the initial requirements baseline. Once contracts are awarded, the requirements definition subphase will result in the final requirements baseline.

If there is any conflict between the wording of a requirement in the narrative in this RFP and the RCM, the requirements stated in the RCM take precedence.If there is any conflict between the intent of the requirements stated in this RFP and those included in standards or on a referenced website, the requirements stated explicitly in this RFP take precedence.

In this RCM, indicate if the proposal meets (or exceeds) each requirement, the aspects of the requirements it does not meet, or alternatives proposed. Any exceptions to the requirements must be clearly stated as such, within the Proposer’s proposal with alternatives clearly stated within the response as applicable.

If the Proposer has a unique solution, or part thereof, that clearly meets or exceeds the intent of the requirements in this Section, then the City encourages the Proposer to propose the solution and provide sufficient details for the City to understand and evaluate it.


Date: 05/06/2023 Time: 22:53:09 7 of 115



1230

1240III.D.1

1250III.D.1.a

1260

1270

1280

1290

1291

1300 III.D.1.b Deliverable Format The Proposer shall submit all technical deliverables using Microsoft Office tools.

1310

1320

1330III.D.1.c

1340

1350III.D.1.d

1360 The Proposer shall deliver an updated project schedule at least monthly.

1370

1380

1390

1400III.D.1.e

1410

1420

1430III.D.1.f

For purposes of this RFP and design hierarchy, the ESInet and Core Services together are called a subsystem, the GIS solution is also called a subsystem and the L&R solution is also called a subsystem. The term 'system' may be used in this document as a general term to denote a higher level in the architecture.

Systems Engineering Methodology and Required Artifacts

Proposers shall use rigorous Systems Engineering and Project Methodologies that yield artifacts required by the City and provide early assurances that the solution will meet the City’s needs.

Use of PSAC1, PSAC2, SDE Cabinets

The Proposer shall be responsible for the managed service cost of WAN circuits between OSPs. Cost associated with WAN services to the optional 3rd site should not be priced at this time.

The Proposer shall locate the Call Routing Facilities (CRFs) and Call Aggregation Functions within PSAC1, PSAC2, and the optional 3rd site (if required).

For the design at PSAC1, PSAC2, the optional 3rd site (if required), and the SDE, the Proposer shall utilize the City-provided pre-installed cabinets, data center floor space, standard 3-phase power drops under the floor, and infrastructure level data center connectivity between cabinets. The City provided cabinets will be ready for use by the Proposer to host equipment required by the Proposers.

If the Proposer has special requirements for the cabinets and/or power, then the Proposer shall discuss them during the negotiation/design phase of the project. The Proposer shall be responsible for racking equipment and cabling equipment within their cabinets and to their adjacent cabinets, while the City takes care of cabling to the cabinet at more distant locations in the data center via preinstalled building infrastructure cabling (i.e. overhead/below floor CAT6a and fiber optic cables).

WAN connectivity/transport to the SDE and between PSACs shall be the Proposer’s responsibility.

The Proposer shall send all deliverables to the City Document Manager (contact to be provided) directly via an email attachment and also hand-delivered or mailed.

The Proposer shall print three copies for each formal technical document delivery as outlined in the RFP.

Project Milestones and Deliverables

Each Proposer shall meet the projected project milestones and deliverables as listed in Section IV.A.3.a.4, subject to change by mutual agreement.

The Proposer shall follow the projected project milestones and deliverables are anticipated, subject to change by mutual agreement.

Project Management Office (PMO) Meetings

The selected Proposer shall coordinate weekly meetings with the City’s Project Management Office (PMO) team to status schedules, risks and adjudicate project action items.

The Proposer shall provide an agenda two days before the meeting and then distribute meeting minutes within three business days after each meeting.The meeting notes shall include action items, due dates and current status, as a minimum.

Proposer shall support a more formal presentation on a monthly basis, in place of a weekly meeting, if the City requests it in advance. These presentations, perhaps to higher-level City management, shall be conducted via PowerPoint slides and the slides will then be delivered to the participants via email along with the meeting notes and actions.

Technical Management Meetings

Proposer shall coordinate weekly meetings with the City’s technical integration team (to include NYPD and FDNY members when necessary) to status progress, risks and adjudicate project action items.

The Proposer shall provide an agenda two days before the meeting and then distribute meeting minutes within three business days after each meeting. The meeting notes shall include action items, due dates and current status, as a minimum. Any formal presentation shall be done via PowerPoint slides which shall be delivered to the City via email.

Requirements Control Board (RCB)

The Proposer shall allocate man-hours to participate in the Requirements Control Board (RCB) made up of Proposer and City team members.


Date: 05/06/2023 Time: 22:53:09 8 of 115



1440

1450III.D.1.g Test Review Board (TRB)

1460

1470III.D.1.h Technical Project Phases

1480

1490

1500

1510

III.D.1.h.1 Negotiation Phase

1520

1530

1540

1550

1560 III.D.1.h.2 Project Initiation Phase The selected Proposer shall present the organization chart1570 The selected Proposer shall introduce key personel1580 The selected Proposer shall generate and discuss the WBS (Excel)1590 The selected Proposer shall finalize and present the baselined schedule1600 The selected Proposer shall generate and discuss the Quality Assurance Plan1610 The selected Proposer shall provide a list of known project risks

1620

1630

1640 The selected Proposer shall provide a contact list with phone number for team1650 The selected Proposer shall provide meeting notes

1660III.D.1.h.3 Design Phase

1670

1680 The Proposer shall maintain a schedule which will meet the target date.

1690

1700III.D.1.h.4

1710

1720

1730

To streamline the requirements management process, the Proposer shall consider implementing an internal requirements review board within their team such that when the City sees a set of requirements, they will have been well-discussed in advance.

The Proposer shall allocate man-hours to participate in the Test Review Board made up of Proposer and City team members.

The Proposer shall create Test Discrepancy Reports (TDRs) and enter the TDRs into a problem tracking system.The selected Proposers shall participate in the City’s structured design process which adheres to Systems Engineering methodologies and good project management procedures.

For the purposes of this RFP, the ESInet, Core Services, L&R, and GIS engineering and PMO services requested by this RFP shall be listed in the integrated master schedule as independent projects.

Each project shall be subject to the design process and technical project phases outlined in Section IV.A.3.a.9 and described in detail further below in the RFP.Proposers shall create and provide each of the deliverables associated with each technical project phase as described in more detail in the RFP.

In addition to the normal effort required to flush out cost and contract specific details in the Negotiation Phase, the Proposer shall lead the generation of an agreed Statement of Work (SOW) for their project, along with the generation of the first preliminary schedule.

The SOW shall include the text of the RFP (as a starting point) with inputs from the Proposer’s proposal.The Proposer shall work in tandem with City personnel to generate the other deliverables for this phase.

The Proposer shall bring any substantive changes into the negotiation process to have the opportunity to include any new requirements, needs, and scope not already included in the RFP and to update their notional design.

The Proposer shall prepare for discussions around the need for any long lead items and other risk mitigation strategies such as an early purchase of parts to support an accelerated SDE buildout.

The selected Proposer shall discuss, agree, and document the reporting lines to be followed between the organizations in the form of a Communication PlanThe selected Proposer shall provide a more detailed view of the schedule for the next three months.

The design phase shall be broken into subphases which are concluded by a formal Critical Design Review.The goal to complete the design phase shall be six months after the Notice to Proceed is issued by the ACCO; this supports the goal for the entire project to be integrated, tested, training completed, and the scopes of work (subsystems) ready for operational cutover with the Call Handling Subsystem no later than July 31, 2021.

The Proposer shall meet with their technical and programmatic counterparts on a weekly basis.

Design Phase - Integration and Coordination

The Contractor must integrate their schedule baseline along with all other projects (Esinet, Core, GIS, L&R, NG Call Handling).

The Contractor must include the required integration and test phases on their baseline schedule. The Proposer must coordinate and organize technical and PMO meetings on a weekly basis to ensure proper communication and to see that project level milestones will be achieved per plan.

The Proposer in conjunction with the City shall integrate its project schedule with the City’s Integrated Master Schedule (IMS)


Date: 05/06/2023 Time: 22:53:09 9 of 115



1740

1750

1760

1770

1780 III.D.1.h.5 SDE Design Phase The Proposer shall implement an accelerated deployment of the SDE

1790

1800

1810

1820

1830 The Proposer shall generate the SDE requirements within the first month.1840 The Proposer shall create a preliminary design for the SDE within the first month.1850 The Proposer shall create an SDE design document within the first month.

1860

1870 The Proposer shall provide presentation slides1880 The Proposer shall provide final block diagrams1890 The Proposer shall provide a floor plan1900 The Proposer shall provide wiring diagrams1910 The Proposer shall provide rack elevations1920 The Proposer shall provide a list of technical risk1930 The Proposer shall provide a BOM1940 The Proposer shall provide an SDE preliminary test plan.

1950III.D.1.h.6

1951

1952

1960

1970

1980

1990

2000

2010

The Proposer shall participate in Technical Interchange Meetings (TIMs) with other projects (at least once per month) to ensure that the designs between vendors are compatible, that the external interfaces communicate correctly, that their project level design is integrated and works with the other Proposers, and that their project is integrated with the Public Safety System-of-Systems (e.g. integrated with the NOC/SOC/Helpdesk/Enterprise services and City edge firewalls).

The Contractor shall take the lead to coordinate meetings to drive progress whenever possible.

Interface documentation, integration test plans, test procedures, test reports shall be a shared responsibility between Proposers and the City.The majority of the integration work shall be accomplished through joint discussions/agreements/documentation with their counterparts on other projects.

The Proposer shall document their suggestions and requested changes to the SDE design in their proposal narrative.

The SDE accelerated design phase shall address all SDE design topics in the first month (or two) after contract signing.

In the SDE Design Phase, a long lead BOM shall be created, approved by the City and ordered quickly.If possible the SDE block diagram, long lead items, and the initial SDE BOM shall be created during negotiations period so that the BOM can be authorized and released to the Proposer’s purchasing in the first week after contract signing.

The Proposer shall provide a combined Requirements/Preliminary/Critical Design Review.

Requirement Definition Subphase

To ensure timely completion of this requirements phase, the Contractor’s RFP technical design shall be as complete as possible when proposed.

The selected Contractor shall add, modify and/or delete from the Requirements Compliance Matrix (initial requirement baseline) to fix inaccuracies, to more accurately match their proposal to the approved requirements and to augment the RCM with important requirement additions, notes, allocations and other details that have not been captured by the initial RCM.

The Contractor shall add relevant / important functional requirements from the referenced documents in APPENDIX H to the RCM.The Contractor shall define and include both functional and non-functional (e.g. performance) requirements. (Note: Component level, protocol level and internal interfaces subsystem requirements do not necessarily need to be specified and tested. Only subsystem level requirements are mandated.)

The Contractor shall store all requirements via a formal requirements management tool.The Contractor shall directly utilize the City’s Jama (Contour) tool from the City’s MetroTech office located in Brooklyn, or transfer the requirements from their Requirements Management tool to Contour.

During the initial design phase, the vendor shall make a preliminary allocation as to how the requirements will be verified, i.e. allocation of requirements to analysis, demonstration, test, inspection.

During the initial design phase the Vendor shall allocate the requirements to subsystem components (e.g. LNG, ECRS, BCF, LVR, etc.) and to the test phases (FAT, SAT, Integration and Test, SIT)

The Proposer shall delete/update/modify/augment the initial requirements baseline, extracted from the content of the RFP in ATTACHMENT J and the other referenced technical documents found in the Appendices.


Date: 05/06/2023 Time: 22:53:09 10 of 115



2020

2030

2040The Proposer shall document the business processes in the form of use cases.

2050

2060

2070III.D.1.h.7

2080

2090

2100

2110

2120

2130 The Subsystem Requirements Review (SRR) shall include an outline for Training plan.

2140

2150

2160III.D.1.h.8

2170III.D.1.h.9

2180 For the PDR the Proposer shall provide a PowerPoint presentation slides.2190 For the PDR the Proposer shall provide a Preliminary Design Document (PDD)2200 For the PDR the Proposer shall provide an updated RVTM

2210

2220 For the PDR the Proposer shall provide a Draft Integration Plan2230 For the PDR the Proposer shall provide a draft operational cutover plan.2240 For the PDR the Proposer shall provide the approved outline for the CDR document

2250

2260

2270III.D.1.h.10

The RVTM must be updated and become an appendix to the Requirement Design Document, but is not expected to be complete at the conclusion of the Requirement Design phase since many of the test allocations and traces will not be complete until later design phases.

The RVTM shall be a deliverable of all the design phases - incrementally improved - until it is complete.

Each external interface with another subsystem shall be documented via an Interface Control Document (ICD), one per external interface. The City will provide the ICD template.

The Proposer shall work with the City to update the existing Sparx architecture to include the new subsystem interfaces and subsystem elements

Subsystem Requirements Review (SRR)

The Proposer shall discuss known technical and related project risks at the Subsystem Requirements Review (SRR).

The Subsystem Requirements Review (SRR) shall include PowerPoint presentation slides.The PowerPoint slides/presentation will include all aspects of the preliminary design and must cover the required outlines and initial planning activities. Schedule progress and known technical risks shall also be provided.

The Subsystem Requirements Review (SRR) shall include a Subsystem Requirements Document (SRD) to include requirement allocations (to components and how verified)

The Subsystem Requirements Review (SRR) shall include an updated Requirements Verification Tractability Matrix (RVTM) which can be generated via Jama (Contour) once the database fields are populated.

The Subsystem Requirements Review (SRR) shall include an outline for Test Plan (including FAT, SAT, SIT)

The Subsystem Requirements Review (SRR) shall include an outline for Implementation plan

The Subsystem Requirements Review (SRR) shall include an outline for integration plan, to include OSP transition to DMS-100s and fpr for integration of all connected subsystems.

The Subsystem Requirements Review (SRR) shall include an outline for cutover plan to operations.

Preliminary Design Subphase

At the Preliminary Design Review (PDR), the Proposer must provide an updated availability analysis to be approved before the next design phase is authorized.

Preliminary Design Review (PDR)

After the successful conclusion of the formal Preliminary Design Review (PDR) meeting the Proposer shall provide an outline for the CDR design document.

For the PDR the Proposer shall provide a Draft version of all required plans including Draft Training Plan

For the PDR the Proposer shall provide draft engineering documentation for block diagrams, floor layouts, wiring diagrams, IP layer 1,2,3 documentation, configuration setting, etc.

For the PDR the Proposer shall provide the SDE design details/updates, SDE test procedures and RVTM requirement allocation, or changes, if not already provided in the SDE design phase.

Critical Design Subphase The critical design must meet all the defined requirements of the subsystem - it must provide the required documentation and the implementation plan shall be finalized showing how the design will be built, configured and tested at the proposed facility.


Date: 05/06/2023 Time: 22:53:09 11 of 115



2280

2290

2300

2310III.D.1.h.11

2320

2330

2340

2350

2360

2370

2380

2390

2400

2410 For the formal Critical Design Review (CDR) the Proposer shall produce wire lists

2420

2430

2440

2450III.D.1.h.12 (l) Build Phase

2460

2470 During the Build phase the Proposer shall label racks and wires.

2480

2490

2500

2510

2520

2530

2540 During the Build phase the Proposer shall create As-built documentation2550 During the Build phase the Proposer shall create a QA report of inspections.

The Proposer shall submit the Critical Design Document that may describe the use of gateways, describe the integration with the other subsystems, reference the IP diagrams and explain their contents (e.g. routing details, DNS, active directory, security details),specify where cabinets will be located on the datacenter floor, reference all final plans developed during this phase, specify dates for equipment arrival, specify how the OSPs are transitioned with the DMS-100s, and describe the plan to cut-over the external interfaces for this subsystem in the context of the greater system and its interfaces.

During the Critical Design Subphase the Proposer shall finalize the required plans and provide the details of the integration and test phases. During the Critical Design Subphase any test equipment such as a call load generators or gateways must be specified and contained in the BOM.

Critical Design Review (CDR)

For the formal Critical Design Review (CDR) the Proposer shall produce PowerPoint presentation slides

For the formal Critical Design Review (CDR) the Proposer shall produce a Critical Design Document (CDD)For the formal Critical Design Review (CDR) the Proposer shall produce a final Subsystem Test Plan (FAT, SAT and SIT).

For the formal Critical Design Review (CDR) the Proposer shall produce test cases allocated to requirements

For the formal Critical Design Review (CDR) the Proposer shall produce an implementation plan (defines the build phase)For the formal Critical Design Review (CDR) the Proposer shall produce an integration plan (defines integration phase to other subsystems)For the formal Critical Design Review (CDR) the Proposer shall produce a Draft OSP transition plan (defines the cutover of OSPs through the use of gateways)

For the formal Critical Design Review (CDR) the Proposer shall produce an Operation cutover plan (including how to decommission the interim Text to 911 subsystem)For the formal Critical Design Review (CDR) the Proposer shall produce an IP layer 1,2 and 3 technical drawingsFor the formal Critical Design Review (CDR) the Proposer shall produce Rack Elevation Drawings

For the formal Critical Design Review (CDR) the Proposer shall produce drawings at the cabinet and inter cabinet level.

For the formal Critical Design Review (CDR) the Proposer shall produce a complete Bill of Materials to include any required purchase.For the formal Critical Design Review (CDR) the Proposer shall produce SDE design details, changes and updates, if not already provided in the SDE design or PDR design phase.

During the Build phase the Proposer shall enter or capture the serial number and asset tags into the help desk for maintenance purposes.During the Build phase the Proposer shall assemble and rack into larger component assemblies the individual hardware subsystem parts as per the CDR drawings.

During the Build phase the Proposer shall download and complete configuration details such as router configurations and databases

During the Build phase the Proposer shall execute component level tests on an as-needed basis without formal witness by the City.

During the Build phase the Proposer shall create as-built documentation from the original CDR baseline.During the Build phase the Proposer's quality assurance team shall issue a report to the City showing the level of QA inspections sufficient to ensure the overall system quality is satisfactory, but will minimally include a 100% check of the as-built documentation (rack elevations, wiring diagrams and cabling diagrams) for a random 10% of the racks.

The Proposer’s QA function shall report to a higher level in the Proposer’s management chain to ensure a level of independence of the Proposer’s QA team.

During the Build phase the Proposer shall report any risks/issues encountered either technically or programmatically to the City during the Proposer’s weekly PMO and technical team meetings with the City.


Date: 05/06/2023 Time: 22:53:09 12 of 115



2560

2570

III.D.1.h.13

2580

2590

2600

2610

2620

2630

2640

2650

2660

2670

2680

2690

2700

During the Build phase the Proposer shall create detailed test procedures required to meet scheduled deliverables.

Integration and Test Phases

Formal test steps to be executed shall include:1) Subsystem Test Phases (applies to ESInet, Core, GIS, L&R, NG Call Handling projects)a. SDE Test (SDET) b. Factory Acceptance Testing (FAT) c. Subsystem Acceptance Testing (SAT)

Formal test steps to be executed shall include:2) Internal integration and test of the ESInet with Core components and external WAN interfaces, including:a) WAN lines and equipment to OSPsb) WAN connections and equipment between PSACs

Formal test steps to be executed shall include: 3) Integration and test of the ESInet and Core and NG L&R subsystems to the City SEIM/Security Operating Center (SOC) a. Integration and test of the BCF firewall or equivalent into the City SOC; b. opening firewall ports as required,

Formal test steps to be executed shall include: 4) Integration and test of the ESInet Core and NG L&R subsystems to the City Network Operations Center (NOC)/Enterprise services, to include:c. NOC manager-of-managers and monitoring functionality, including all trap forwarding and configuration of alarm and alert thresholdsd. Integration and test of the City provided Monitoring Functionality (IBM Netcool Omnibus) e. Use of backup servicesf. Inventory managementg. Configuration Managementh. collection and forwarding of syslogs to the City supplied log collectioni. Integration and test to the City’s DNS and Active Directoryj. Packet capturek. Remote access

Formal test steps to be executed shall include: 5) Integration and test of the ESInet Core and NG L&R subsystems to the City ITIL compliant Helpdesk/CMDB Software

Formal test steps to be executed shall include: 6) Integration and Test of ESInet Core with GIS

Formal test steps to be executed shall include: 7) Integration, test, and cutover of OSPs to SIP including the interface of the SIP to SS7 gateway which in turn feeds the DMS-100s with a goal of no operational impacts to the Legacy Call Handling subsystem

Formal test steps to be executed shall include: 8) Integration and test of the ESInet Core and NG L&R with Ancillary subsystems, to include: EANs, Tie Lines, ERS/BARs, Voice Alarm, Order Wire, Ringdown, Admin Phones, Text to 911, solarCell and LinkNYC, NYC 311

Formal test steps to be executed shall include: 9) Integration and test of NG L&R with Legacy Radio L&R subsystem and NICE Systems Investigate (eSubpoena)

Formal test steps to be executed shall include: 10) Integration and test of ESInet and Core to the integrated L&R subsystema. Integration and Test of NextGen Call Handling with integrated ESInet and Core, GIS, and L&R Subsystems

Formal test steps to be executed shall include: 11) Integration and test with Neighboring NG9-11 Jurisdictions Formal test steps to be executed shall include: 12) Integration of all projects to City reporting subsystemFormal test steps to be executed shall include: 13) Integration and test of the ESInet and Core call queues and any remaining external interfaces

Formal test steps to be executed shall include: 14) Integration and test at a system level (i.e. during the System Integration Test or SIT)


Date: 05/06/2023 Time: 22:53:09 13 of 115



2710

2720

2730III.D.1.h.14 Test Phase Details

2740 The Proposer shall provide the final Test plan for the entire subsystem at the CDR

2750

2760

2770

2780

2790

2800

2810

2820

2830

2840

2850

2860

2870

2880

2890

2900

2910

2920

2930

During the Integration Phase the Proposer shall create a weekly Integration Progress ReportDuring the Integration Phase the Proposer shall issue a report to the Test Review Board, on a weekly basis, all severity 1 and 2 TDRs that are encountered, ensuring that all TDRs are recorded in the City’s TDR reporting tool.

The Proposer shall provide the draft FAT/SAT Test plan for the entire subsystem at the PDR

The Test Plan shall incorporate the final RVTM mapping of requirements to Test Cases.The Draft Detailed Test procedures must be available at least 6 weeks before they are to be utilized for the formal dry run, but must include one round of redlining either on the SDE equipment or on the actual subsystem hardware.

The Proposer shall create and finalize the final test procedures for FAT, SAT and SIT in parallel with the Critical design and build phases.

The Proposer shall show and track on the baseline schedule the projected task start and projected date for the test procedure rough draft (not deliverable to the City).

The Proposer shall provide test plans and test procedure steps for functionality that is traced to the approved requirement baseline created during the Requirements phase. (The test procedures follow from the approved Test plan which outlines the test cases and the requirements linked to the test cases via the RVTM.)

The Proposer shall redline the Draft test procedure, created in Microsoft word, by running the procedures on SDE or the actual subsystem equipment.The Proposer shall submit the Draft test procedure incorporated redlines document to the City for initial approval.

The test procedures shall undergo a complete annotated dry run on the actual subsystem equipment which may be witnessed by the City at its discretion.The Proposer shall scann and submit the annotated dry run procedures to the City as proof that the dry run has been completed.The Proposer shall update the test procedures, to incorporate dry run changes with “track changes” turned on in Microsoft Word, and then the City provides final approval for the final test procedures.

The test procedures shall be formally executed and witnessed by the City, NYPD, FDNY Fire, FDNY EMD and the Proposer personnel.

To facilitate timely approval of final test procedures, the Proposer shall break up the test procedures as necessary into logical parts and City approval will be granted on each test procedure subset.(For example, the test procedures might be partitioned by subsystem: FAT, SAT, Performance, Subsystem Integration, SIT.)

The test plans may be broken out into subsections.(however an overall subsystem test plan including FAT, SAT, and integration would, in this case, be required.)

Each Test Case shall satisfy one or more requirements and is a description of the logical series of test steps that are detailed in the Test Procedures (Note: if you have a test case but no requirements associated with the test case, it means you missed a requirement, the requirements must then be updated as necessary).

At the time of the CDR, the Test Cases shall be described and the required personnel and test equipment shall be outlined.(The actual detailed test steps have not yet been created and redlined yet)

At the time of the CDR, the Test Procedures shall be organized by Test Case and shall contain the detailed test procedure steps that were only outlined in the test plan. At the time of the CDR, the test procedures shall contain a reference to the requirement and the test step where they are verified.The Proposer must successfully pass the Test Readiness Review (TRR) in order to enter into a project test phase (e.g. FAT or SAT).(One of the important entry criteria tracked at the Test Readiness Review is the City’s approval of the test procedures and the completion of a dry run)(the TRR cannot be successfully completed without approved test procedures and a Dry run).

The Proposer shall issue the dry run set of Test Procedures after addressing all City comments


Date: 05/06/2023 Time: 22:53:09 14 of 115



2940

2950

2960 For the Test Phase the Proposer shall include approved Test procedures2970 For the Test Phase the Proposer shall include TRR slides2980 For the Test Phase the Proposer shall include meeting notes2990 For the Test Phase the Proposer shall include dry run results3000 For the Test Phase the Proposer shall include a formal TDR log3010 For the Test Phase the Proposer shall include a Test Report

3020III.D.1.h.15.a

3030

3040

III.D.1.h.15.b

3050

3060

3070 The Proposer shall provide approved performance test procedures (Appendix to SAT)

3080

3090 The Proposer shall provide performance test TRR Slides3100 The Proposer shall provide performance test meeting notes3110 The Proposer shall provide performance test Dry Run results3120 The Proposer shall provide performance test Formal TDRs3130 The Proposer shall provide performance test Test Report

3140

3150

3160

3170

3180

3190

3200 The Proposer shall work with the TRB on performance testing to develop fixes

3210

3220

During the document review cycle the Proposer shall provide track changes to the document revisions, provide revision history, update revision numbers and upload the various releases on the City’s SharePoint.

The Proposer shall create the following schedule milestones within the baseline schedule: Design Reviews, document outlines/drafts, the first document release, City review time, revision time by the vendor, the final review and required formal document releases. Also included on the schedule shall be the TRR, redlines to the initial draft test procedures, dry runs and time for the test procedure review cycle (potentially in parts).

Subsystem Level Performance Testing

Each subsystem shall undergo subsystem level performance testing as outlined and agreed in Proposer's test plan for the subsystem. The performance test procedures shall be an appendix to the SAT test procedures that may be approved separately by the City.(This subsystem level test is required to ensure that the system level performance testing is successful.)

System Level Performance Testing

At the system level, the Proposer shall work with other vendors and the City to help generate a set of SIT performance test procedures – under City oversight - which shall include verification of the system level performance requirements with, as a minimum, the integrated ESinet, Core, L&R subsystem, GIS subsystem, and Call Handling subsystems.

The SIT performance test procedures shall require the aid of a call generator dedicated to that purpose.(This call generator equipment will primarily be provided by the Core Services subsystem provider, however the Proposer of each scope of work will be required to provide all test equipment, test software, test data with their delivery of the subsystem to the City that is required to fully test their requirements and their allocated system level requirements.)

The subsystem shall undergo performance stress/endurance/burn-in tests for a period of no less than 30 days and will include 8 hour periods at full maximum load, followed by 16 hours with loads simulating more normal operational conditions and at least one 2-day period at the full rate system load for both PSACs per Appendix F.

The Proposer shall provide their contribution to SIT as applicable and agreed with the CityCtiy.

The Proposer shall provide performance test TDRs, i.e. ensuring that all TDRs are recorded in the City’s TDR reporting tool.The Proposer shall report the performance test progress weekly at a suitable schedule granularity

The Proposer shall report the performance test status of all TDRs that are encountered, to the Test Review Board on a weekly basis.

The Proposer shall work with the TRB on performance testing to develop suitable regress plansThe Proposer shall work with the TRB on performance testing to develop suitable retests

The Proposer shall work with the TRB on performance testing to develop suitable work arounds

The Proposer shall work with the TRB on performance testing to develop patch to fit in with the overall test schedule.

The Proposer shall work with the City test team to fill out the TDRs including information such as impact, root cause, when fixed.


Date: 05/06/2023 Time: 22:53:09 15 of 115



3230

3240III.D.1.h.16

3250

3260

3270

3280III.D.1.h.17 User Acceptance Test

3290III.D.1.h.18 User Training

3300 The Proposer shall create a draft Training plan due at the project PDR3310 The Proposer shall create a final Training plan to be completed for the CDR.3320 The training plan shall contain an overview of all courses to be taught

3330

3340 The training plan shall contain the number of times a particular course will be taught3350 The training plan shall contain the maximum number of students per class3360 The training plan shall contain the agreed location and time if possible.3370 The training plan shall be presented to the City via PowerPoint slides at the CDR.

3380

3390

3400

3410

III.D.1.h.19 Operational Cutover

3420

3421

3430III.D.1.h.20 30-Day FSAT

3440III.D.1.h.21

3450

3460III.D.2.a The Proposer shall provide a thorough Availability engineering analysis.

3470

3480

3490

The Proposer shall work with the City test team in signing off regressing tests and TDRs as appropriately.

System Integration Test (SIT)

The Proposer shall execute a final System Integration Test (SIT) of system level functionality with Legacy L&R, NG911 L&R, Call Handling, Reporting, GIS, NOC/SOC/Helpdesk and all external interfaces under City approval.

The Proposer shall coordinate the generation of agreed test procedures with other subsystem providers and the City integration team.The Proposer shall be responsible for contributing to, and reviewing, the final SIT test report.

For System Integration Testing the Proposer shall provide the As-built documentationThe Proposer shall provide support for UAT, but will be coordinated by the Agencies and the City

To support the training phase of the project, the Proposer shall create a Training plan with outline due at SRR

The training plan shall contain a detailed description and outline of content for each course

The Proposer shall complete the student and teacher course material at least six weeks before the training is to commence (or as required and agreed with the City) and shall submit it to the City for approval.

The Proposer shall finalize and provide all class times and locations in a memo to the City six weeks before start of class.

The Proposer shall provide all user training before the subsystem becomes operational or as otherwise agreed to by the City.

The City Integration team and other subsystem vendors shall work with the Contractor to transition the OSPs away from the DMS-100 tandem switches and their transition of SIP to SS7 LNG gateways and into full operations, operations, as agreed upon in the contract’s Design Phase – Integration and Coordination.

The Proposer shall transfer the interim Text to 911 subsystem over to the new ESInet and Core Services subsystem and the new NG911 Call Handling Subsystem. (This will occur one OSP at a time until all OSP calls have been transitioned without Severity 1 or2 Test Discrepancy Reports (TDRs) and a work off plan is agree to for any remaining Severity 3 or 4 TDRs.)

Within the scope of work of the Contract, the Contractor shall ensure an in-service migration from the legacy system to the NG9-1-1 system – in steps or stages as appropriate - such that there is no system downtime for live 911 operations.

Following the formal operational cutover period, the Proposer’s team shall be responsible for 24x7 operational support for a 30-day period.

Operational Support Phase

The warranty period will start following the formal 30-day FSAT and the Proposer shall begin service support and SLA tracking The Proposer shall deliver an operations support / management plan in the form of a Responsible - Accountable - Consulted – Informed document (RACI), due a minimum of 60 calendar days before start of operations.

Purpose, Primary Requirement, and Background

The ESInet and Core and L&R subsystems shall have a minimum of 6-nines operational availability (99.9999% availability – no more than 31.5 seconds downtime per year on average)

The Proposer shall provide a separate independent availability analysis for the ESInet and Core and a separate analysis for the L&R subsystem, each of which meet the six-nines minimum.

The architecture and availability of PSAC2 shall be the same as PSAC1, which shall be the same as the optional 3rd site.(Any two sites should generate 6-nines operational availability overall.)


Date: 05/06/2023 Time: 22:53:09 16 of 115



3500

3510

3520

III.D.2.b

3530

3540

3550

3560

3570

3580

3590

3600

3610

III.D.2.c Operational Availability

3620III.D.2.c.1

3630

The Proposer shall plan any of the ESInet and Core / L&R Subsystems maintenance, fixes, upgrades, repairs, and patches scheduled and break-fix down time to be mitigated by redundant equipment sets such that it can be performed on one set of redundant equipment within a PSAC while the second set of redundant equipment is operational.

The SDE shall be used to test and create operational procedures for maintenance, upgrade, and repair on the non-production environment before the steps are executed in the production environment.

Functional Decomposition and Block Diagrams

The Proposers shall provide a functional decomposition of each subsystem that they plan to bid.(It shall consist of the Mission Critical Functional Elements (MCFE) and non-Mission Critical Functions of the subsystem, where the MCFE of the subsystem are defined as those functional elements which will cause a break (downtime) in the operational receipt and processing of the emergency calls, if all MCFEs of a given type fail at any given PSAC.)(The City requires this decomposition to be visually depicted in a functional block diagram and to be described in the Proposers technical narrative.)

The Proposer shall provide hardware and software block diagrams with significant internal and all external interfaces to also be provided and described in terms of their relationship to the MCFEs in the Proposers narrative.

The Proposer shall provide overall availability for their subsystem scope of work in terms of the individual availability of the Mission Critical Functional Elements defined in their block diagram. (The Proposer shall provide analytic proof of the overall availability of the PSACs and the individual availability of each Mission Critical Function in the PSACs.)

The Proposer shall create a report to understand the combined Hardware (HW)/ Software (SW) operational availability at existing Proposer sites.(This report should be based on site HW/SW uptime on real deployed facilities that the Proposer and the Proposer’s subcontractors have jointly deployed.)

The Proposer shall provide a combined hardware/software Availability report based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. (The report should include the downtime due to HW failures, down time due to SW, and the downtime due to Maintenance activities. Any scheduled downtime excluded from the hardware/software availability calculation should be described in full.)

Harware/Software down time shall be converted to subsystem operational availability. The Proposer shall describe how the proposed design for NYC, which may have a higher level of redundant equipment, or perhaps a SW revision to address previous defects, would be expected to perform.

In the event that the Proposer will bid the GIS components of this RFP (which is SW only), the Proposer shall generate the independent availability reports for the SW that they propose to deliver.(Shall be based on the uptime of previously delivered SW at operational sites. HW failures should be excluded in this case. The report should be based on downtime due to SW failures, downtime due to required upgrades/patches, or where the Proposers SW was forced to be restarted due to memory growth or for other similar reasons.)

The integrity/validity of the data used in the availability analysis shall be justified by the Proposer.(The source of data used in the report, applicability of the data and method of arriving at the final combined hardware/software availability shall be fully explained in the report. Additional details on availability in general can be found in NENA 08-506 section 3.4.

The subsystem level Operational Availability (Ao) shall be based on the subsystem decomposition into subsystem sites, external interfaces (WANs) and Mission Critical Functions (described below) and the hardware availability associated with these pieces, combined in an appropriate serial or parallel manner along with the appropriate Mean Downtime (MDT) as described/defined in more detail below(Software availability is excluded here, but is addressed in a subsequent section).

Hardware Only Operational Availability

The Proposer shall provide a subsystem hardware-based Operational Availability analysis based on the content and requirements of this section.

The Proposer shall provide sound justification for the MDT design parameters utilization.


Date: 05/06/2023 Time: 22:53:09 17 of 115



3640

3650

III.D.2.c.2

3660

III.D.2.d

3670

3680

3690

3700III.D.2.e

3710

3720

3730

3740

3750

3760

3770

3780

3790III.D.2.f

3800

3810

3820

The Proposer shall provide an independent analysis for the ESInet and Core Subsystem and another for the L&R subsystem.

Subsystem Operational Availability Requirements

The ESInet and Core Services and NG911 L&R Subsystems shall be available 24 hours per day, 7 days per week and 365 days a year, with a subsystem level operational Availability, including all WAN interface Availability (internal and/or external), of at least 99.9999 % (“six nines availability”). (Note: the intent of including the WAN in the analysis is to ensure that the WAN circuits ordered by the Proposer do not become the weakest link in an otherwise satisfactory design.)

Subsystem HW Availability Modeling and Analysis

Subsystem Availability shall be calculated by modeling the subsystem as an interconnection of components, subcomponents and elements in series and/or parallel. (The same rules apply to each level of the subsystem decomposition.) (An individual piece of equipment, a set of redundant equipment in a CRF or L&R Site, or the CRF/L&R Site itself should be combined in either series or parallel to obtain the next high level of availability.

Subsystem Availability shall be computed based on the availability of the components in a given CRF (i.e. at PSAC1, PSAC2, or optional 3rd site) and should include any external WAN interface availability between sites.(It must include connectivity between PSAC1 and PSAC2. Hence, this availability should include the external interface availability which includes the ESInet WAN availability, which in turn is based on contracted SLAs that are proposed by the Proposer.)

The Availability of the external interfaces to the OSP shall be calculated and reported separately.

The composite availability of the subsystem shall be provided with the OSP WAN connections.

Subsystem External Interfaces and WAN Availability

The ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the Call Handling Subsystem

The ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the Logging and Recording subsystem - legacy

The ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the Logging and Recording subsystem – next generationThe ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the Public Safety NOC/SOC/HELPDESKThe ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the PSAC1/PSAC2 ESInet and Core DashboardsThe ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the Connectivity to PSAC1/PSAC2 and an optional 3rd site if it exists

The ESInet/Core Subsystem shall provide all LAN/WAN connectivity for the subsystem external interfaces for the OSP external interfaces/WANs

The ESInet/Core Subsystem operational availability shall include the operational availability of all Mission Critical external interfaces and any mission critical internal interfaces not already included with the CRF Site availability calculations.

The operational availability of external WAN interfaces shall be based on the SLA contracted with the WAN service provider for uptime, MTTRS and overall MDT.(When multiple WAN lines are used to service a single external interface, the operational availability computation shall be fully described.)

Mission Critical Functions

The Proposer shall describe and include LNG - Legacy Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include BCF - Border Control Function Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include ESRP - Emergency Service Routing Proxy Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include LSRG Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation


Date: 05/06/2023 Time: 22:53:09 18 of 115



3830

3840

3850

3860

3870

3880

3890

3900

III.D.2.g

3910

3920

3930

3940

3950

3960

3970

3980

The Proposer shall describe and include LP - Legacy PSAP Gateway Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include Database services (VPC, MPC, LIS/ALI, ECRF, etc.) Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include ESINET Network equipment (WAN and LAN) Mission Critical Functions Elements (MCFE) of the ESInet/Core Subsystem in their architectural design documentation

The Proposer shall describe and include Logging Service (SRS) Mission Critical Functional Elements of the L&R Subsystem in their architectural design documentation.

The Proposer shall describe and include Recording playback Service Mission Critical Functional Elements of the L&R Subsystem in their architectural design documentation.

The Proposer shall describe and include Database services Mission Critical Functional Elements of the L&R Subsystem in their architectural design documentation.

The Proposer must define any additional Mission Critical Functional Elements not specifically asked for by the City so as to realistic depict their subsystem internal design and block diagrams. (Any redefinitions may be acceptable but should be explained in detail and used in the analysis of the CRF and the L&R Site operational availability.)

Availability Analyses Guidelines and Requirements

The ESInet and Core and L&R subsystems’ Mission Critical Functional Element (MCFE) shall be hosted on a hardware architecture design consisting of at least two sets of redundant, physically separable HW equipment at any given location (PSAC1, PSAC2, or optional 3rd site).

Each set of ESInet and Core and L&R subsystem redundant equipment shall be capable of providing all Mission Critical functionality at the sustained full subsystem rated load per Appendix F.

The ESInet and Core (including GIS and L&R) subsystem’s redundant components hardware within any given site (PSAC1, PSAC2, or optional 3rd Site) shall be physically separated within the site datacenter in opposite corners of the datacenter.The ESinet/Core & L&R Subsystems Subsystem at any given site (PSAC1, PSAC2, or optional 3rd Site) shall consist of independent hardware / software and external interfaces, which are capable of providing all subsystem mission critical functions autonomously.

The ESInet and Core and L&R subsystems shall be designed to provide concurrent, load-shared service between PSAC1 and PSAC2 and the optional third site.

(Note: the architecture described above requires at least 4 complete sets of redundant hardware - two in each PSAC. All existing operational mission critical subsystems within PSAC1/PSAC2 have similar availability specifications. High availability provided in this manner ensures that any given PSAC can be taken off line for a technical refresh of one or more subsystems and ensures that a single 911 scenario can be accommodated. The optional third CRF/L&R Site would provide a total of 6 sets of redundant equipment and would accommodate two 911-like disaster scenarios. The requirement for two or more sets of HW located in a PSAC are required to increase the overall site availability and to permit the physical separation of the equipment sets in order to minimize the effect of physical damage from say a broken pipes or accidents like a forklift truck running into a set of racks on one side of the room.)

The Proposer shall provide an independent analysis for each subsystem which shall include operational availability at the Subsystem level, PSAC/Site level, and MCFE level based on the Proposer’s MCFE block diagram decomposition within a given Site.The Proposer shall describe the method and rationale for their redundant equipment calculations in relationship to the MCFEs within a given site and subsystem. The Proposer's description for the rationale/justification for the overall Mean Down Time (MDT) utilized in the operational availability calculation and shall include the time to diagnose incident problems and come up with a repair approach

The Proposer's description for the rationale/justification for the overall Mean Down Time (MDT) utilized in the operational availability calculation and shall include the time to repair hardware per the plan


Date: 05/06/2023 Time: 22:53:09 19 of 115



3990

4000

4010

4020

4030

4040 The Subsystem MDT shall be no greater than 4 hours.

4050

4060

III.D.2.h

4070

4080

4090

III.D.2.i

4100

4110

4120

4130

4140

4150

4160

The Proposer's description for the rationale/justification for the overall Mean Down Time (MDT) utilized in the operational availability calculation and shall include the time to restore software/firmware images if required

The Proposer's description for the rationale/justification for the overall Mean Down Time (MDT) utilized in the operational availability calculation and shall include any other time not mentioned but possibly required to restore service or functionality to the downed component (e.g., transferring operational data, or rebooting one or more servers)

The Proposer's description for the rationale/justification for the overall Mean Down Time (MDT) utilized in the operational availability calculation and shall include the contracted service level (SLAs) of chosen suppliers to provide parts and/or to response to incidents on site within the specified MDT

The Proposer shall describe the necessary 24x7 staff levels for tier 1, 2, & 3 technical staff on site and / or at the NOC to ensure that the chosen MDT is appropriate and applicable

The Proposer shall describe the need for any on-site spares required to justify the MDT

MTBF used in the calculation of operational availability shall be based on manufacturer’s data, or if the component is provided in-house, via statistically significant/justifiable operational field failure and uptime data.

Database Service Availability

The ESInet/Core and L&R Subsystem internal databases shall provide active-active replication within a subsystem Site, such that all database copies are kept synchronized by ensuring that any change to one database copy is propagated automatically to all other copies within the site without human intervention.

The subsystem databases at differencing Sites shall provide active-active database replication between subsystem Sites, such that all database copies in all subsystem Sites are kept synchronized by ensuring that any change to one copy is propagated automatically to all other copies without human intervention.

The Proposer shall estimate the required BW to provide active-active database replication between sites.

Disaster Scenario Availability Requirements

The ESInet and Core or L&R services at any one site, shall be completely independent of any the subsystem equipment at any other Site, such that if any, or all other Sites, are completely disabled (i.e. in a “smoking hole” scenario), then the surviving Site can provide all subsystem services, where a site in this context is defined as PSAC1, PSAC2, or the optional 3rd Site.

In the event of a smoking hole or other site-wide outage at one or more of the other subsystem sites, ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) shall be continuously available.

In the event of a smoking hole or other site-wide outage at one or more of the other subsystem sites, ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) shall have no momentary down

In the event of a smoking hole or other site-wide outage at one or more of the other subsystem sites, ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) shall have no necessary HW or SW configuration changes or updates .

In the event of a smoking hole or other site-wide outage at one or more of the other subsystem sites, ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) shall have no database reloads or updates required due to the event

ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) which has been offline for an extended period of time, defined as greater than 8 hours shall be capable of resynchronizing all databases with any currently operation site within 1 hour or less.

ESInet and Core or L&R subsystem Mission Critical Functions at any given site (PSAC1, PSAC2, or the optional 3rd Site) which has been offline for less than 8 hours shall be capable of resynchronizing all databases with any currently operation site within 10 minutes or less.

The Proposer shall describe in their proposal any manual, non-automatic steps, necessary to keep the subsystem mission critical functionality operational should one or more CRFs or L&R Sites become completely unavailable.


Date: 05/06/2023 Time: 22:53:09 20 of 115



4170III.D.3.a The Proposer shall submit an initial ESInet design and block diagrams.

4180 The proposed ESInet must conform to NENA 08-506.

4190

4200

4210

4220

4230

4240

4250 The ESInet shall be designed to provide the availability detailed in Section III.D.2.

4260

4270

4280

4290

4300

4310

4320

4330

4340

4350

4360

4370

Emergency Services IP Network and Core Requirements

The Proposer shall build and test the ESInet prior to, or in parallel with, the build and test of NG9-1-1 Core Services.

The Proposer shall plan tasks for the internal integration and joint testing of the NG9-1-1 Core Services with the ESInet. Once the ESInet is placed into serviceThe Proposer is responsible for all maintenance and repair of all components that comprise the ESInet/Core subsystem.The Proposer shall provide suggestions in their technical narrative for modification to the RFP integration and test section IV.A.3.a.9 that they believe are in the best interests of the City.

Prior to steady-state operations, Proposer shall provide as built drawings, architectural diagrams, design documents, rack layouts, wiring diagrams and configuration files in electronic form.

The ESInet shall be designed and implemented with no single points of failure by using a highly reliable, redundant, resilient and diverse architecture and provide automatic failover in response to any outages.

Additional requirements for the reliability design of the ESInet shall be guided by the FCC Report and Order FCC 13-158 - Improving 9-1-1 Reliability and Reliability and Continuity of Communications Networks, Including Broadband Technologies.

Proposer shall provide a narrative describing how the required availability will be achieved in the ESInet design as describe in Section III.D.2.

The ESInet and Core Services shall be designed and implemented to meet the capacity, performance requirements detailed in APPENDIX F - SUBSYSTEM PERFORMANCE and CAPACITY.

The ESInet and Core Services shall be designed so that the total capacity required includes bandwidth for all media (voice, text, photo attachments and video attachments), SIP signaling (subscribe/notify, etc.) and Logging and Recording (signaling, event logging and media recording).

The ESInet and Core Services shall be designed so that the system availability requirements, bandwidth capacity must be adequate to carry increased traffic if segments of the ESInet are unavailable.

Proposer shall provide a narrative describing how each performance and capacity requirement will be met.

The ESInet and Core Services subsystem shall have the ability to automatically reroute traffic to alternative routes in order to bypass network outages and equipment failures.

The ESInet shall also provide Quality of Service (QoS) to prioritize critical traffic by importance of applications and users as required by the NENA specifications.

Proposer shall provide network at a minimum, depict the physical and logical design including path diversity, ingress and egress points, planned bandwidth for each segment, interconnection locations including 9-1-1 call aggregation points, PSAC1, PSAC 2, the optional 3rd site and other network nodes as applicable.

All security requirements identified in Appendix H – Applicable Standards shall be metProposer shall provide a narrative describing the physical and logical security measures to be taken to protect the ESInet. This narrative must discuss how I. unauthorized individuals will be prevented from accessing the network, II. how data theft will be prevented, detected, and trackedIII. how intrusion prevention encompassing all seven (7) layers of the OSI model is implemented and achieved throughout the network

The physical and logical security measures narrative shall describe how the Proposer will conduct periodic assessments of vulnerabilities, how security incidents are identified, reported, mitigation plans are implemented and how security documentation is maintained.


Date: 05/06/2023 Time: 22:53:09 21 of 115



4380

4390

4400

4410 Proposers shall document and provide a report of all proposed subnets.

4420III.D.3.b

4430

III.D.3.b.1

4440

4450

4460

4470

4480

4490

4500

4510

III.D.3.b.2

4520

4530

Physical deployment of LNGs shall be located at both PSAC1 and PSAC2.

4540

4550

4560

Proposer must describe the application of the 256-bit Advanced Encryption Standard (AES) in their solution.

The ESInet shall support both private and dedicated IP Version 4 (IPv4) and IP version 6 (IPv6) address space for routing for City Agencies.

Proposers shall describe how their solution will support both versions and how the platform shall be managed and monitored to avoid potential errors.

NG9-1-1 Functional Elements (FEs).

The NG9-1-1 Functional Elements (FEs) listed below shall be included in the solution and discussed in the Proposer's proposal.

Border Control Functions (BCFs)

The Proposer's proposal shall include how the BCFs shall be deployed at all SIP-based ingress and egress points.Notes: (This includes interconnections with the OSPs, neighboring NG9-1-1 jurisdictions, Call Handling Subsystems and all other SIP-based systems.)

The firewall functionality of the BCF should be certified to, or justifiably equivalent to, Common Criteria EAL4 or higher.

BCFs proposed must comply with the appropriate NENA standards including and especially STA-010.2-2016.If the BCF is the first functional element in the system to process a call, it must assign a unique incident ID and report this ID to the Logging and Recording system and all other elements in the system consistent with the NENA standards.

the City must be able to track a call from entry into the system to the arrival of a first Proposer on scene.

Proposers shall describe the BCFs being proposed with special emphasis on the role they will play in addressing denial of service attacks, distributed denial of service attacks and other security threats.

Proposers shall provide an operational availability analysis/report for BCFs, of the hardware alone and then also for combined hardware and software if applicable.Notes: (An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.)

The Proposer shall provide sound justification for the mean downtime (MDT) design parameter. See Section III.D.2. for more details on Availability requirements.

Legacy Network Gateways (LNGs)

Any OSPs operating in the City that cannot interconnect with the NG9-1-1 system via SIP shall interconnect via SS7 or PRI. (OSPs names and interconnection notes via SS7 or PRI can be found in APPENDIX A of the RFP.)

LNGs proposed shallcomply with the appropriate NENA standards including STA-010.2-2016.

If the LNG is the first functional element in the system process a call, it shall assign a unique incident ID and report this ID to the Logging and Recording system and all other elements in the system consistent with the NENA standards.

The City Must be able to track a call from entry into the system to the arrival of a first Proposer on scene. Notes: (The ESInet and Core Services components of the end-to-end system must anticipate this requirement even though the call handling and computer aided dispatch systems play a role.)

Proposers shall describe the LNGs being proposed with special emphasis on the role they will play in addressing security threats.


Date: 05/06/2023 Time: 22:53:09 22 of 115



4570

4580

The Proposer shall adiscuss the physical deployment of the LIF, NIF and PIF.

4590

4600 The Proposer must also discuss the physical deployment of the LIF, NIF and PIF.

4610III.D.3.b.3

4620

4630

4640

4650

4660

4670III.D.3.b.4 The ESRPs shall comply with NENA standards especially STA-010.2-2016

4680

4690

4700

4710

The Proposer shall identify the entity providing the LNG functionality overall, and in particular the Network Interwork Function (NIF), the Protocol Interwork Function (PIF) and the Location Interwork Function (LIF).

Proposers shall provide an operational availability analysis/report for LNGs, of the hardware alone and then also for combined hardware and software if applicable. Notes: ( An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.)

Legacy Selective Router Gateways (LSRGs)

LSRGs shall be required.Notes: (In order to interconnect with neighboring 9-1-1 jurisdictions that are still serviced by legacy selective routers.)

LSRGs proposed shall comply with the appropriate NENA standards including and especially STA-010.2-2016.

LSRGs shall be physical deployment at both a PSAC1 and PSAC2 and at the optional 3rd site if required.

If the LSRG is the first functional element in the system to process a call, it shall assign a unique incident ID and report this ID to the Logging and Recording system and all other elements in the system consistent with the NENA standards.Notes: (It is extremely important that the City is able to track a call from entry into the system to the arrival of a first Proposer on scene. The ESInet and Core Services components of the end-to-end system must anticipate this requirement even though the call handling and computer aided dispatch systems play a role.)

Proposer shall provide a description their LSRGs and in particular, the capabilities they have in addressing security threats.

Proposers shall provide an operational availability analysis/report for LSRGs, of the hardware alone and then also for combined hardware and software.Notes: (An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter. See Section III.D.2. of the RFP for more details on Availability requirements.)

Emergency Services Routing Proxy (ESRP)

The FDNY published 10-digit numbers for reporting a fire shall be directed and routed through the ESRP. Other 10-digit emergency numbers, and point to point circuits, will also be required to route through the ESRP.

The Proposer’s narrative should describe their plans and architecture to strip off incoming attachments for certain types of media (e.g. pictures and video), and to store the them in a data repository that is compliant with the capacity and volume requirements of Appendix F.

The Proposer shall provide full support for routing Emergency Incident Data Documents (EIDDs) as described in the latest release of NENA/APCO Emergency Incident Data Document (EIDD) Information Document.

If the ESRP is the first functional element in the system to process a call, it shall assign a unique incident ID and report this ID to the Logging and Recording system and all other elements in the system consistent with the NENA standards.


Date: 05/06/2023 Time: 22:53:09 23 of 115



4720

4730

4740

4750

4760

4770III.D.3.b.5

4780

4790

4800 The PRF shall comply with NENA standards especially NENA-STA-003.1.1-2014.

4810

4820

The ESRP must also be capable of load balancing between the two PSACs, and the optional 3rd site (if required by the City). This shall be accomplished by monitoring the multiple queues established for each of the PSACs via the subscribe/notify feature document in the standards.

Proposer shall describe their ESRPs and in particular, the capabilities it has in addressing security threats and any additional functionality mentioned in other requirements.

Proposer shall provide their proposed physical deployment of the HW in the Datacenter, as well as identify the entity providing the ESRP functionality if it is to be supplied by a subcontractor.


Proposers shall provide an operational availability analysis/report for ESRPs, of the hardware alone and then also for combined hardware and software if applicable.Notes: (An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.)

Policy Routing Function (PRF)

When the total capacity for call taking begins to reach a point of saturation, call diversion shall be implemented.

Notes: (Possible 9-1-1 Call Diversion example 1: At some point, taking additional calls reporting a single event reaches a diminishing point of return. A PRR must then be used to divert calls exceeding some settable threshold to either neighboring jurisdictions and/or to an Interactive Multimedia Response (IMR) unit when its associated threshold is reached. This would free up call taking capacity at the PSACs to take calls reporting different emergencies. The IMR should be designed as an option, that canso that be enabled or disabled by the City.Possible 9-1-1 Call Diversion example 2: It is possible that the volume of 9-1-1 calls reporting an event requiring a police response can block calls reporting a fire or requiring a response from EMD. Incoming calls specifically requesting either Fire or EMD by using the service requested identifier can be directly routed to their call queues bypassing the normal incoming 9-1-1 call queue allowing for a quicker response.)

PRRs shall be provided for NYPD and FDNY to apply special treatment to calls with additional data, photos, or video attached.

Notes: (Special treatment example 1: The City does not want attachments to MMS messages to be sent automatically to a call taker. Instead, PRRs shall be implemented to divert attachments to a repository with a unique identifier or hyperlink. The availability of attachments, the type of attachment and the unique identifier/hyperlink can be passed to the call taker. Accessing the attachment(s) would then be at the discretion of the call taker, histaker, his/her supervisor, or the first Proposers. Accessing the repository and the attachments would be a feature integrated with the new Call Handling subsystem through an interface to the Call Handling Subsystem.Possible special treatment example 2: The City may certify certain OSPs and/or applications to be authorized to send photos, data and streaming video through the NG9-1-1 system to the PSAC. PRRs may be implemented to treat these certified OSPs or applications in a prescribed way.)

The PRF description shall describe the human interface that allows for entering Policy Routing Rules (PRRs) (see GUI 3 in Figure 4 of the RFP). The ability of the GUI to detect errors and the security measures provided to prevent unauthorized access shall be described in the Proposer’s narrative.

There shall be no practical limit on the number of PRRs that can be established, however, for pricing purposes, Proposers should anticipate developing 50 PRRs, storage for attachments and media, to be included.

D438

Verger, Maya:


Date: 05/06/2023 Time: 22:53:09 24 of 115



4830

4840

4850

4860

4870

III.D.3.b.6

4880

4890

4900

4910

4920

4930

4940

4950

4960

4970

4980

Proposers should anticipate developing 50 PRRs, storage for attachments and media, to be included. Proposer shall describe their PRFs and in particular, compliance with the standard, its ability to perform the types of routing and special treatment described and the functionality implemented to address security threats.

Proposer must provide their proposed physical deployment and disclose the entity providing the PRF functionality.

Proposer shall describe the functionality of the human interface (GUI 3 in Figure 4 of the RFP) including the access controls, audit trail of changes and validation of logic prior to putting them into service

Location Information Server (LIS)

The Proposer shall deploy a shared LIS that will act as a repository of wire line subscriber addresses and pseudo ANIs (pANIs) for wireless and Voice over IP subscribers. The LIS shall be required to interconnect with Mobile Positioning Centers (MPCs) and VoIP Positioning Centers (VPCs) using the current PAM and E2 interfaces.

For the end-state, the Proposer shall implement a LIS/ALI that closely matches the attributes of the LIS as defined in NENA Standard STA-010.2-2016. Notes: (Specifically, the LIS must implement the HELD Protocol and support all queries from LNGs and the NG9-1-1 Call Handling Subsystems to be procured under a separate RFP.)

The Proposer shall "normalize" the data that populates the new LIS/ALI.

The Proposer shall include all services necessary to support the transition of the current ALI database to the City's new LIS/ALI

Physical deployment of LIS/ALIs isshall be at the PSACs and optional 3 rd Site. The Proposer shall provide a detailed description of the LIS/ALI proposed including a detailed comparison against the LIS as defined in NENA standard STA-010.2-2016,and the entity that is providing the LIS functionality.

The Proposer shall describe the functionality of the Graphic User Interface (GUI 1 in Figure 4 of the RFP) for the LIS/ALI including the access controls, audit trail of changes and validation of logic as part of their narrative.

The Proposer must provide a description of the data cleansing and data normalization services proposed to ensure a “clean” database for the LIS/ALI.Notes: (Specifically, the City requires that records in the current MSAG and ALI be audited for inconsistencies with the NENA standard especially with respect to location information. Of particular note is the accuracy of records in the current ALI for payphones and cell towers. Subway locations must be established that are easily identifiable.)

The Proposer must provide a description of the migration process from the existing ALI to the new LIS/ALI deployed by the City. Notes: (The description must describe the requirement placed on the OSPs, any parallel processing of ALI records from the OSPs, and an outline for testing/validating that the new process is working properly.)

The migration process description shall describe the requirement placed on the OSPs, any parallel processing of ALI records from the OSPs, and an outline for testing/validating that the new process is working properly.

The Proposer shall provide all services required for ongoing updates of the LIS/ALI deployed by the City under this contract. This includes but is not limited to the following:- Creation and update of a new MSAG - Responding to No Record Found (NRF) errors- Populating the Location Validation Function (LVF) with MSAG information- Help desk (see GUI 2 in Figure 5 of the RFP) for the OSPs to resolve issues- Implementation of a provisioning platform to process new records from the OSPs prior to placement in the LIS/ALI

The Proposer must provide tools and services to support requirements in NENA Standards 03-502, 06-003and 06-502.Proposer shall anticipate and include in their price the implementation of the NENA standards on all multi-line telephone systems (MLTS) deployed by the City.


Date: 05/06/2023 Time: 22:53:09 25 of 115



4990

5000

5010

5020

(See Section III.D.2. of the RFP for more details on Availability requirements.)

5030

III.D.3.b.7 Master Network Clocks

5040

5050

5060

The LIS shall provide active-active replication within a site, and between PSACs and the optional 3rd site such that all copies of the database are kept synchronized by ensuring that any change to one is propagated to all other copies.

Proposers shall provide an operational availability analysis/report for LIS, of the hardware alone.Notes: ( An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.)(See Section III.D.2. of the RFP for more details on Availability requirements.)

Notes: ( An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.)

A Master Network Clock solution must be included in the Proposer's proposal and shall assume that any systems deployed at either of the PSACs will be on their own sub-net and therefore cannot use the clock already in place.Notes: (The Master Network Clock must be deployed consistent with NENA STA-026.5. For purposes of the proposal, Proposers must assume that any systems deployed at either of the PSACs will be on their own sub-net and therefore cannot use the clock already in place.) and that any systems deployed at either of the PSACs will be on their own sub-net and therefore cannot use the clock already in place.

-The master clock shall synchronize with a GPS time source.

-The master clock shall use NTP version 3 (or more current version) protocol for time synchronization of all servers, workstations and network elements within the system.

- The availability of the Master Clock must support the overall and site-specific availability requirements

- The ESInet and Core services FEs shall provide the capability to authenticate to a master clock component.

- The master clock shall maintain workstation/server/network device clock accuracy within a given facility within +/- 2 ms.

- The FEs shall report time in Eastern Standard Time, i.e. UTC - 5 hours with no adjustment to account for daylight saving time. Notes: (This is done because Daylight Savings Time can create anomalous glitches when transitioning from EST to DST, which can become apparent in reports and when correlating syslog events.)

Proposer shall deploy a standards compliant Master Network Clocks and provide details of the proposed Master Clocks, their proposed physical deployment and the entity that is providing the Master Clock functionality

Proposers shall provide an operational availability analysis/report for master clocks, of the hardware alone.Notes: ( An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report.


Date: 05/06/2023 Time: 22:53:09 26 of 115



5070

5080

5090

5100

III.D.4.a

5110

5120

5130

5140

5150

5160

5170III.D.4.b Proposer Experience

5180

5190III.D.4.c

The Proposer shall provide sound justification for the mean downtime (MDT) design parameter. See Section III.D.2 of the RFP for more details on Availability requirements.)

Proposers shall provide an operational availability analysis/report for master clocks, of the combined hardware and software if applicable.Notes: ( An Availability analysis/report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter. See Section III.D.2 of the RFP for more details on Availability requirements.)


GIS FEs and Data Management - GIS Component Needs and Background

For the GIS scope of work the Proposer shall utilize all existing and available source data (internal City data sources and External sources).

The Proposer shall provide management skills and the coordination necessary to complete the GIS database and associated functionality.

The Proposer shall provide a complete, integrated, coordinated software only solution for GIS data management, while utilizing the hardware equipment provided by the ESInet and Core Services subsystem vendor.

The GIS Proposer shall provide any hardware requirements as part of this proposal (e.g. number of CPUs, amount of memory on a server etc.) that are required by their proposed solution and shall generate a SW availability report based on SW already in operation.

The Proposer shall aggregate the Citywide digital centerline layer.

The Proposer shall aggregate the Citywide address points layer.

The Proposer shall aggregate the Citywide emergency services response boundary layers.

The Proposer shall aggregate the Citywide other additional or supplemental layers as deemed necessary

The Proposer shall verify the completeness of their narrative to meet the intent of the identified requirements within the RFP by filling out the RCM found in Attachment J.Notes: (Any exceptions to the requirements identified herein must be clearly stated as such within the Proposer’s proposal. Alternatives must also be clearly stated within the response, if applicable.)

Any exceptions to the requirements identified herein shall be clearly stated as such within the Proposer’s proposal. Alternatives requirements shall also be clearly stated within the response, if applicable.

Proposer shall possess demonstrated capabilities in the areas of GIS map development, road centerline development, address point development and MSAG development.

The Proposer shall demonstrate familiarity and experience in the design, development, utilization and maintenance of the GIS datasets necessary to support the needs of the City as it relates to this project. Experience in the design, development and implementation of GIS ETL tools and programs is strongly preferred.

Integration with Other GIS Systems

The Proposer offering a GIS proposal shall take the lead in integrating their proposed GIS software with the hardware contained in the ESInet and Core Services subsystem.


Date: 05/06/2023 Time: 22:53:10 27 of 115



5200

5210III.D.4.d Sources of GIS Data

5220

5230

5240 Proposer shall use City-provided data sources and other additional data sources.

5250

III.D.4.e

5260

5270

5280

5290

5300

5310

III.D.4.f Road Centerlines

5320

5330III.D.4.g

5340

5350

Proposers offering an ESInet and Core Services subsystem proposal must describe the GIS providers that they have previously worked when deploying their operational Core services.

Proposers offering a GIS-only proposal must describe the other NG9-1-1 Core Services providers they have worked with to deploy operational NG9-1-1 systems.

The Proposer shall utilize as the primary source of data for this project the Citywide Street Centerline (CSCL) GIS data developed and maintained by the City.

The Proposer may utilize additional sources of information in conjunction with the known available data sources described in the RFP. Notes: These additional sources may include relationships or partnerships with commercial firms, utilities, US Postal Service address datasets, etc.

The Proposer shall describe within its proposal submission any additional data sources that would be utilized, including and especially PSAP boundary information from adjacent 9-1-1 Jurisdictions and how it will supplement and improve upon the primary source data

GIS Data Model and Use of Tools

The Proposer shall maintain all GIS data layers aggregated for this project as feature classes in Environmental Systems Research Institute’s (ESRI) file geodatabase format in a WGS 84 Latitude/Longitude projection prior to provisioning and loading the data into the ECRF/LVF system. Notes: The City uses NAD 1983 StatePlane New York Long Island - FIPS 3104 (US Feet) as its standard coordinate system, so transformation to WGS 84 will be required.

The Proposer's geodatabase model must comply with the NENA GIS Data Model standards for the NG9-1-1 i3 requirements.

The Proposer's geodatabase model must be compatible with the Computer-Aided Dispatch (CAD) mapping systems in use by NYPD and FDNY.

Proposer shall aggregate the specified GIS data layers and their representative attributes into a seamless Citywide and regional (including information from counties found in APPENDIX B - DETAILS RELATED TO INTERCONNECTION WITH NEIGHBORING 9-1-1 JURISDICTIONS) dataset.

Proposer shall conduct a gap analysis in which they shall identify errors and discrepancies within the various local Citywide GIS map datasets.

The Proposer shall provide sufficient information and guidance by CMG or the other local entities for the remediation of their data.

The Proposer shall submit a database modeling specification document that outlines the database schema representing the GIS layers to be developed, to include fields, descriptions, field types, etc.

The Proposer shall describe the methodology used to aggregate a Citywide road centerlines GIS data layer.Notes: The methodology description shall include how the Proposer will adhere to the NENA standard for NG9-1-1 GIS Data Model.

When aggregating the road centerlines layer Road centerlines must be broken at all intersection points with other named and addressed road centerlines.

When aggregating the road centerlines layer Invalid connectivity at intersections shall be flagged for correction by CMG.

When aggregating the road centerlines layer the Proposer shall identify all errors and discrepancies identified during the aggregation of this data layer and submit the identified errors and discrepancies to CMG for remediation.

Site/Structure Address Points

The Proposer shall describe the methodology used to aggregate a Citywide structure address point GIS data layer. The methodology description used to aggregate a Citywide structure address point GIS data layer shall include how the Proposer will adhere to the NENA standard for NG9-1-1 GIS Data Model.

When aggregating the site/structure address points layer, the Proposer shall identify all errors and discrepancies identified during the aggregation of this data layer and submit the identified errors and discrepancies to CMG for remediation.


Date: 05/06/2023 Time: 22:53:10 28 of 115



5360

III.D.4.h

5370

5380

5390III.D.4.i

5400

5410

5420III.D.4.j Road Name Alias Table

5430

5440III.D.4.k Cell Sector Locations

5450

5460III.D.4.l

5470

5480

5490

5500

5510

5520

5530 The Proposer shall provide 24x7x365 customer support.

5540

Administrative Boundary

The Proposer must describe the methodology used to aggregate Citywide administrative boundary GIS data layers containing City boundaries.

The methodology description used to aggregate Citywide administrative boundary GIS data layers containing City boundaries shall include how the Proposer will adhere to the NENA standard for NG9-1-1 GIS Data Model.

The Proposer shall identify all errors and discrepancies identified during the aggregation Citywide administrative boundary GIS data layers containing City boundaries and submit the identified errors and discrepancies to CMG for remediation.

Emergency Services Boundary

The Proposer shall describe the methodology used to aggregate Citywide emergency services boundary GIS data layers containing PSAC service areas and Police, Fire, EMS service areas.

The methodology description of the Citywide emergency services boundary GIS data layers containing PSAC service areas and Police, Fire, EMS service areas shall include how the Proposer will adhere to the NENA standards for NG9-1-1 GIS Data Model

When aggregating the emergency services boundary layers, the Proposer shall identify all errors and discrepancies identified during the aggregation of this data layer and submit the identified errors and discrepancies to the local entity for remediation.

The Proposer shall describe the methodology used to create a Citywide road name alias table.

The methodology description of the Citywide road name alias table shall include how the Proposer will adhere to the NENA standard for NG9-1-1 GIS Data Model.

The Proposer shall describe the methodology used to create a Citywide cell sector locations GIS data layer.

The methodology description of the Citywide cell sector locations GIS data layer shall include how the Proposer will adhere to the NENA standard for NG9-1-1 GIS Data Model.

GIS/ECRF/LVF Managed Solution

The Proposer shall provide as a managed solution a fully developed GIS change detection/update process capable of addressing data updates and discrepancy inquiries from the City.

The system shall have the ability to perform QA/QC audit checks and data analysis on an on-going basis prior to the provisioning of GIS data into the ECRF/LVF. The Proposer shall provide the implementation and management of a NG9-1-1 ECRF and LVF as defined in the NENA 08-003 Detailed Functional and Interface Standards for the NENA i3 Solution.

The Proposer shall fully describe the implementation, system tools and processes, by which it will manage GIS data updates from the local 9-1-1 entities, provide for QA/QC auditing functions prior to provisioning the GIS data into the ECRF/LVF and implement and manage a NG9-1-1 compliant ECRF/LVF system.

The Proposer shall provide for a secure web portal for local 9-1-1 entities to submit GIS update/change requests and the Proposer to communicatemeasurements, discrepancy tracking, for GIS quality assurance and system status.

The Proposer shall provide the means for the City to view system and data metrics by providing a portal to their RSC The Proposer shall provide process and usage training of the change management process to the local 9-1-1 entities.

SI System maintenance events shall last less than 4 hours and notice shall be given 1 week in advance


Date: 05/06/2023 Time: 22:53:10 29 of 115



5550

5560

5570 ALI No Record Found (NRF) records shall be corrected within 48 hours of detection

5580

5590

5600 The Proposer shall provide the means for web-enabled reports, performance

5610

5620III.D.4.m

5630

5640

5650

5660 The Proposer shall provide SW for a standards-compliant ECRF.

All SW updates, patches, maintenance activities shall not disrupt the operating NG911 system. All changes shall be applied to one set of redundant HW while the second set continues to process operational requests.

GIS updates to the ECRF/LVF shall be processed within 24 hours after passing quality control

GIS updates shall be processed and inserted into the system within 3 business days of receipt from CityGIS to ALI comparison shall be completed within 5 business days of receipt from City error/discrepancy feedback.

The Proposer shall describe the functionality of the graphic user interface (GUI 5 in Figure 4 of the RFP) including the access controls, audit trail of changes and validation of logic prior to putting them into service

Emergency Call Routing Function (ECRF)

The Proposer shall provide a clear description of the proposed ECRF software, list its features and capabilities, discuss its error handling, default mechanisms and logging and provide an overview of how it is deployed and achieves high reliability

The ECRF software description shall discuss the GIS update process, frequency and the handling of error reports.

The Proposer shall Supply ECRF SW based function that is 99.9999% availability given the two sets of redundant SW provided by the ESInet and Core Services subsystem.

The Proposer shall be responsible for secure and reliable ECRF Internet Protocol (IP) Located at PSAC1 and PSAC2.

The Proposer shall provide a web portal that permits administrative read-only access to the GIS database. This function must be rate-limited to avoid impacting emergency call delivery services.

The Proposer shall state the maximum number of queries per second the proposed ECRF may sustain for at least sixty minutes under adverse, as defined by the City, but “all up” conditions.

The Proposer shall describe and list the features of the proposed ECRF, with particular emphasis on how it meets the specific requirements herein.

The ECRF shall interface and provide location-based emergency call routing functionality via the RFC 5222 (Location-to-service Translation [LoST] protocol) and the functional specification of NENA STA-010.2-2016.

The ECRF shall Support LoST queries (via Transmission Control Protocol [TCP]) from ESRP(s), PSAC Call Handling Subsystems or any other permitted IP host within the City ESInet.

The ECRF shall Rate-limit queries from sources other than provisioned ESRPs

The ECRF shall Log all connections, connection attempts and LoST transactions.

The ECRF shall be able to route locations based on geographical coordinates (LAT/LON) and based on civic addresses (house #, street, city, etc.).

The ECRF shall support updates to the GIS database without disruption of ECRF LoST service.

The ECRF shall be able to validate GIS database changes before they are applied, for example, detect overlaps or gaps in layer geographical boundaries.


Date: 05/06/2023 Time: 22:53:10 30 of 115



5670

5680

5690III.D.4.n

5700

5710

5720 The Proposer shall deploy at least two LVF instances

5730

5740

5750

5760

5770 The Proposer shall provide a standards-compliant LVF.

5780

The ECRF shall provide active-active replication within a site such that all copies of the database are kept synchronized by ensuring that any change to one is propagated to all other copies.

The ECRF shall provide active-active replication between sites (PSAC1, PSAC2and the optional 3rd site) such that all database copies on different sites are kept synchronized by ensuring that any change to one copy is propagated to all other copies.

Location Validation Function (LVF)

The LVF shall be highly available to Origination Service Providers and to the public at large, so these parties can verify that civic addresses or latitude/longitude will return PSAC or emergency Proposer Uniform Resource Identifiers (URIs).

The Proposer shall provide an LVF with an operational availability of at least 99.999%The Proposer shall provide the NG9-1-1 Location Validation Function (LVF) as defined in the NENA Standards

The Proposer shall provide a user-friendly web server portal located within the PSCZ to which Internet users may browse the database. The web server shall query the LVF via the proxy and return a user-friendly display with the results of the LoST query.

The Proposer shall explain the proposed LVF implementation, with particular attention to the arrangement of the proposed components, user interface and features and the security aspects of the LVF.

The Proposer shall pProvide for a process for call origination providers to submit updates to GIS data or report discrepancies.

The LVF shall be a separate instance of the ECRF-like processes running within the Core NG9-1-1 Routing Service security zone.

The LVF shall utilize a separate database instance of the GIS database derived from the ECRF GIS database. The Proposer shall show how this separate GIS database instance will be kept synchronized with the ECRF GIS database in real-time or near real-time.

The LVF shall be accessed via a proxy server located within the PSCZ. The Core NG9-1-1 Service firewall shall then allow LVF access only from the proxy process.

The LVF shall provide a standard LoST interface via a TCP port. This port must be listed in a Domain Name Server (DNS) entry. Connections and transactions on this port shall be logged and shall be rate limited by the PSCZ proxy.

The LVF proxy shall provide a LoST interface accessible by a credentialed connection that may be used by OSPs or other authorized parties. This port may be used to support a much higher rate of machine-to-machine LVF LoST protocol queries.

Proposers shall provide an operational availability analysis / report for LVF, of the hardware alone.Notes: An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter.

Proposers shall provide an operational availability analysis / report for LVF, of the combined hardware and software if applicable.Notes: An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter.


Date: 05/06/2023 Time: 22:53:10 31 of 115



5790III.D.4.o

5800

5810

5820III.D.5.a

5830

5840

5850

5860

5870III.D.5.b Printers

5880

III.D.5.c

5890

III.D.5.d Maintenance Contract

5900

5910III.D.5.e

5920

5930 Playback shall be provided on multiple remote workstations.

5940

5950

5960

5970

Systems Integration of GIS

The Proposer shall take the lead on the integration of all GIS services that they install. The Proposer shall demonstrate their understanding of their role in the integration of the GIS FEs with the rest of the NG9-1-1 Core Services FEs by describing their role in the process and how it relates to the other selected Proposer(s).

The Proposer shall clearly describe their expectations of the City in coordination of the Systems Integration process

NENA Requirement Compliance

The Logging and Recording subsystem shall be consistent with the NENA standards, especially STA-010.2-2016.

If Proposer finds conflicts between standards, the Proposer must specify which standards their proposal follows.The L&R subsystem shall synchronize its time and date via an NTP interface to the customer-provided network clock when available.Version upgrades, updates and maintenance to the subsystem shall only be applied after review and approval of the plan by the City and tested in the SDE.

The Proposer shall be responsible for systematically deploying L&R upgrades, fixes and maintenance to the subsystem.

The L&R subsystem shall support commonly used peripherals including printers and fax machines allowing the user to print reports.

Open Interface to Other Applications

The Proposer’s solution shall integrate with, and provide integration services to, the many third-party applications and interfaces, to include, but not limited to: the CAD systems for NYPD and FDNY, the existing legacy L&R subsystem that services Radio and the existing analog phone systems (via the LNG).

The Proposer shall provide a commitment to the City that they will provide software, equipment and services that meet NENA NG9-1-1 requirements and standards now available (see references in Appendix H) and shall describe how they will periodically update the subsystem components to meet future evolution of the NENA standards.

The Proposer shall warrant that the proposed subsystem will be supported for a minimum of ten (10) years from the date of the full acceptance of the proposed subsystem.

NG9-1-1 Functional Elements

All NG9-1-1 FE’s shall be logged. APPENDIX D - DETAILS OF LOGGING AND RECORDING INTERFACE REQUIREMENTS lists all events which shall be logged.

Media recording shall l be required at all NG9-1-1 subsystem ingress points and at the NG9-1-1 Call Handling Subsystem. The subsystem shall allow for simultaneous recording on all channels.

The NG L&R subsystem shall to provide multiple channel playback without loss of any data and without deterioration to the rest of the subsystem processes.

The subsystems simultaneous playback functionality shall be available for multi-media types including audio, text and video.

The Proposer shall describe the NG9-1-1 Core Services vendors with whom it has demonstrated seamless interoperability.

Categories of interoperability that the Proposer has previously demonstrated with other vendors shall be specified including full production deployment, current implementation of a production system, lab testing and participation in NENA ICE.


Date: 05/06/2023 Time: 22:53:10 32 of 115



5980

5990

6000

6010

6020

6030

6040

6050

6060

6070

6080III.D.5.f The L&R storage infrastructure shall be available to record and log at all times.

6090

6100

6110

6120

6130III.D.5.g Availability

6140

6150III.D.5.h Expansion

6160III.D.5.i

6170III.D.5.j Data Formatting

The Proposer shall describe if the proposed solution utilizes open source software/products and detail what, if any, are utilized.The Proposer shall describe how product enhancement control (configuration management) is maintained and shall describe how this CM system will be utilized to handle open source software community advances.

The Proposer shall describe any risk associated with utilization of open source software.The L&R subsystem shall have the ability to provide unattended and automatic archiving of software databases and subsystem equipment configuration via a user-defined schedule.

The L&R subsystem shall have the ability to record and capture information from the NG9-1-1 Core Services FEs described in the RFP and a NG9-1-1 Call Handling Subsystem that meets the requirements of Attachment J, Appendix E, and as outlined in referenced documents of Appendix H.

The L&R subsystem services offered must be provided as an end-to-end managed service. Notes: The proposal shall include and describe all updates, upgrades and ongoing management of the subsystem for the duration of the contract.

The subsystem must be compliant with all privacy requirements including the Health Insurance Portability and Accountability Act (HIPAA).

Any remote workstation with rights shall be able to search across multiple recorders in one step, as if they were one recorder. Proposer’s proposal shall act as a single system to allow workstations anywhere on the network to access any recorder.

Proposer shall provide a functional block diagram detailing the proposed solution components and connectivity, including firewalls, servers, recording devices, clients and network components.

Storage Availability and Security

The recorded media and all logged events shall be available at all times for search and retrieval. All stored media and logged events shall also be secure. While some capability to edit the media, as described in the RFP, shall be allowed, in all other cases the stored media and events shall be unalterable and secure

Proposer shall consider and propose a well-defined storage hierarchy, potentially including local, intermediate and archive levels.

Proposer shall specify the database system and version being proposed (i.e. Microsoft SQL server, Oracle, MySQL, etc.) and list any other supported databases for the L&R subsystem.

The L&R subsystem shall be designed with adequate redundancy, having no single points of failure. The Proposer shall describe how their proposed solution for the L&R subsystem is fully redundant with no single points of failure and how it conforms to the requirements described in III.D.2 of the RFP.

The L&R subsystem shall be capable of being expanded without taking the operational 911 Call Handling Subsystem off-line at either PSAC.

Subsystems Engineering Margin and Growth

The initial subsystem deployment shall be sized for 1.5 times the amount of storage deemed necessary to support the performance and capacity requirements found in APPENDIX F - SUBSYSTEM PERFORMANCE and CAPACITY.

The L&R subsystem shall be able to natively store records in standard audio format including WAV, MP3 and other standard media formats.


Date: 05/06/2023 Time: 22:53:10 33 of 115



6180

6190

6200

6210

6220 The L&R subsystem shall permit the user to synchronously play up to 20 recordings.

6230

6240

6250

6260

6270III.D.5.k The L&R subsystem shall provide a search, retrieval and export capability. .

6280

6290

6300

6310

6320

6330

6340

6350

6360

6370

6380

The L&R subsystem voice recording shall provide the functionality for activating and deactivating the record function as follows: - Record continuously - Record during voice activity - Record while telephone line voltage indicates off-hook - Record via SIP packet capture

The Proposer shall l provide subsystem documentation, including as-built diagrams, rack diagrams, configuration, wire diagrams and IP lever 1, 2, 3 diagrams that describing the subsystem operation (and/or architecture, operating system dependencies) and as described in Section III.D.2 of the RFP.

The L&R subsystem voice recording GUI shall be customizable by an authorized user by providing the functionality for additional fields to be added to the GUI window for the purpose of annotating and commenting on voice record.

The L&R subsystem shall automatically permit up to 500 records to be displayed as a result of a user query and shall ask the user to verify that results greater than 500 records should be displayed.

The L&R subsystem shall provide a visualization tool to view call activity from a group of call takers.

The L&R subsystem shall provide functionality for supervisors with sufficient privilege to select and monitor the audio on up to 25 positions - call-taker / dispatch positions from authorized workstation positions.

The L&R subsystem shall provide functionality to annotate a voice recording with a spoken time announcement, to be associated, saved and exportable with specific recordings.

The L&R subsystem voice annotation functionality shall include the capability to define the volume and extent of information provided, e.g. weekday, month, day, year, hours, minutes, seconds, AM/PM, duration

Search, Retrieval, Reporting, Playback and Export

Proposers shall provide a detailed description of the Graphical User Interface provided for the L&R subsystem.

The L&R subsystem shall provide a web-based user interface for end-user interactions including searching, retrieving, exporting, reporting, quality assurance and auditing. The L&R subsystem web-based user interface for end-user interactions shall be compatible with the current Microsoft Internet Explorer Version(s) which will be specified during the design review process.

Proposer shall list any other web browsers supported along with their versions of the L&R subsystem web-based user interface for end-user interactions.

Proposer shall describe the functionality of the Graphical User Interface (GUI 2 in Figure 4 of the RFP), including the access controls, audit trail logging and validation of logic prior to putting them into service.

All functions, administrative and user, shall be accessible via a web browser and not require the hosting of any application software on the user’s system.Proposer shall specify if their web interface requires any browser add-ins such as Adobe Flash, Java, or Silverlight.

Proposer shall specify the web application server being proposed, e.g. Microsoft IIS Server, Apache, etc. Proposer shall list any others that are supported.The L&R subsystem shall provide a profile-based system that will allow groups of users to be created and specific resources (channels) to be assigned. Proposer shall specify the software development environment/platform/language the system is written in, e.g. VB.Net, Java, Spring Services and any standards used, e.g. WC3, HTML5.

The L&R subsystem shall provide fast and convenient incident / scenario reconstruction and export for sharing with multiple voice, screen, image and data elements – directly within the same application interface.


Date: 05/06/2023 Time: 22:53:10 34 of 115



6390

6400 the supervisor shall have instant access to recordings for their agency PSAP.

6410

6420

6430

6440

6450

6460

6470

6480

6490

6500

6510

6520

6530

6540 The L&R subsystem shall store all data sets for a period of no less than 2 years.6550 The L&R subsystem storage shall be expandable by a factor of at least 5x.

6560

6570

Proposer shall configure the subsystem to allow each call taker to access only their own recordings, while

The System Administrators shall have access to recordings for all PSAPs within their agency.The L&R subsystem shall allow an authorized user to redact a copy of the original audio to support agency export requirements and shall provide an audit trail of all redactions including the user who authorized the export and redaction.

The L&R subsystem shall provide functionality for an interface which allows an authorized user to generate the retrieval of all call recordings that match the specified criteria, where the search function can be provided through a single query or a series of queries to the call records database.

The L&R subsystem search/playback application shall support searching by any data field or annotation associated with the recording.

The L&R subsystem search/playback application shall minimally include the following search criteria: The L&R subsystem search/playback application shall minimally include the following search criteria: - Date and Time - Customizable Channel Name or Number - Call Duration - Call Notations, Flags - Dual-toned, Multi-frequency (DTMF) Codes - Extension Number - Call Direction (incoming or outgoing) - ANI/ALI - Caller ID - Agency - Console Position - May also include vVoice analytics – key words or the lack of key words. - Media type/Call type (text, video, image, etc.)

The L&R subsystem user authentication shall authorize data access, based on Group and User access levels, where data access shall minimally include:- Access to voice- Access to media- Access to reporting and report templates- Access to the device- Access to logs

The L&R subsystem shall record and store PD, Fire and EMD agency data on independent hardware platforms segregated by agency.

The access and control of each independent hardware set will be specified and defined by the agency with the help of the Proposer, during the design phase of the project.

The L&R subsystem user authentication shall have a list of predefined groups and subgroups, which will be defined during the design phase of the project.

The L&R subsystem shall provide functionality to join PD/Fire/EMD datasets based on access privileges so as to generate reports spanning the joined datasets.The L&R subsystem shall provide functionality to seamlessly join, using a single GUI, the legacy L&R data sets from PD/Fire/EMD (servicing the Radio subsystem) with the NG911 PD/FD/EMD datasets specified herein, so as to provide privilege-based user and reporting access.

The L&R subsystem shall provide functionality for any data type to be encrypted in the storage archive.

The L&R subsystem storage, shall include all logs and records, shall be 100% replicated in real-time (or near real-time) to at least 2 offsite locations, in addition to being stored at the recording site. The offsite replication shall occur between PSAC1 and PSAC2.

The L&R subsystem shall log all use of user access/privilege and denial of user access/privilege by any user or external process.


Date: 05/06/2023 Time: 22:53:10 35 of 115



6580

6590 The L&R subsystem shall log the workstation by which the user accesses data.

6600

6610

6620

6630

6640

6650

6660

6670

6680 The L&R subsystem shall permit tagging local or remote workstations.

6690III.D.5.l

6700

III.D.5.m Screen Capture

6710

6720

6730

6740

6750

The L&R subsystem data storage and access Record shall meet with all CJIS requirements and policy.

The L&R subsystem shall provide functionality to track and report the complete list of users who have accessed a given data file. The L&R subsystem shall provide functionality to grant or prevent access to a given workstation, based on a specific user or group.

The L&R subsystem shall provide functionality to playback up to 20 channels simultaneously

The L&R subsystem shall provide functionality to playback audio at variable speeds, which shall minimally include the following variable speeds ¼, ½, 1x, 1.5x, 2x, 2.5x, 3x.

Proposer shall describe its simultaneous channel playback capabilities including simultaneous playback of multiple events such as audio, text and multimedia along a single timeline.

The L&R subsystem playback functionality shall be independent of any other subsystem function and shall, in particular, not interfere with the recording of any channel.

The L&R subsystem shall allow search and playback from an unlimited number of remote workstations on the LAN and laptops and tablets on a secure network, as well as directly from the recording unit with no LAN access required.

The L&R subsystem shall permit tagging of call records or groups of call records with color flags and alphanumeric information.

Subpoena Requests and Processing

The Proposer shall integrate with the existing Legacy electronic subpoena (eSubpoena) request processing. Note the existing subpoena functionality is provided by NICE Systems Inc. as part of their “Investigate” SW product.

The L&R subsystem shall provide functionality and network bandwidth for the periodic capture of all operational call taker and dispatch screens, to include:• two screens for the CAD system for either NYPD, FDNY Fire, or FDNY EMD• one telephony call handling screen• one radio dispatch screenOnly screens with active operators need to be captured.

The Proposer shall size the subsystem at each of the two PSACs with an assumption that up to 400 telephony call taker positions and 160 radio dispatchers will be active at any moment at each of the two PSACs.

The Proposer shall assume, for the purposes of this RFP, a screen resolution of 1920x1080 with a 32-bit color depth.The Proposer shall describe in full their preferred approach to L&R subsystem snapshots / pixel changes, the proposed refresh rate and the degree of compression that can be applied to the data.

The L&R subsystem capture shall remain online for at least 7 days, at which time the subsystem shall be capable of selecting data sets by position and time interval and moving them to long term storage.

The long term storagefor the L&R subsytem shall be 50% of the storage required for the overall 7 days of short term storage.

Administrative GUI functionality for the L&R subsystem shall be provided to view selected positions in real time, to search and to purge short-term and long-term storage


Date: 05/06/2023 Time: 22:53:10 36 of 115



6760

6770III.D.5.n Subsystem Home Page

6780

6790

6800

6810III.D.5.o Network

6820

6830

6840

6860III.D.5.p System Security

6870

6880

6890

6900

6910

III.D.5.q

6920

6930

Screen capture recordings for the L&R subsystem shall be synchronized with the recorded audio, and shall permit the simultaneous playback of both the captured screen images and the audio recorded for each position.

The L&R subsystem shall provide a web based GUI to select reports and the format of the report. A link to the report GUI shall be provided on the user homepage upon login.

The L&R subsystem shall provide functionality to automatically generate email reports on a daily, weekly, monthly or annual basis.

The subsystem shall provide functionality to verify authenticity by optionally:a) exporting all media types/reports with a digital signature b) encrypting all media types/reports upon export

The L&R subsystem shall provide functionality to generate an audit trail for each export, including the user ID, the date and time and the workstation used.

Proposers shall propose the network infrastructure required to achieve the storage availability, security and accessibility requirements listed in the RFP.

The network proposed shall support the availability, reliability, redundancy and security required as detailed in APPENDIX F - SUBSYSTEM PERFORMANCE and CAPACITY III.D.2 of the RFP.

Full proposal Proposers shall thoroughly describe the characteristics of the network proposed. Partial, L&R-only proposals may assume that the network will be provided by the selected full proposal Proposer.

Security measures shall be provided in accordance with the applicable NENA and City standards as specified in APPENDIX H - APPLICABLE STANDARDS and ATTACHMENT SCY - Security Requirements.

The Proposer shall create a security plan with details of the security architecture, which includes the Network, Platform, Physical, Data and Process elements.

The Proposer’s physical place of business that provides remote support to the subsystem shall provide secure access such as door keys, locks, key cards, security cameras, audible and visual alarms and subsystem or device labels.

The Proposer shall identify how the solution will protect the subsystem from network hackers and viruses that attempt to impede the normal operation of a system. The Proposer shall identify how their solution will sufficiently protect the subsystem from attack.

Interconnection with Existing L&R Subsystem

The new NG9-1-1 L&R subsystem shall support the NG9-1-1 Core Services and the new NG9-1-1 Call Handling Subsystem. Notes: The logging and recording of Radio will continue to be supported by the City’s existing L&R subsystem.

The new NG9-1-1 L&R subsystem shall seamlessly integrate and interoperate with the existing L&R subsystem.

Proposer’s proposal shall provide seamless integration of the new L&R subsystem with the existing L&R subsystem that will remain in place.


Date: 05/06/2023 Time: 22:53:10 37 of 115



6940

6950

6960

Suggest to combine this above in the notes section

6970

III.D.5.r

6980

6990

7000III.D.6

The Proposer must comply with the requirements in Appendix H.

7010III.D.6.a

7020

7030

7040

7050

7060

7070III.D.6.b

7080III.D.6.c Electrical Interface

A single interface shall allow for search and retrieval across both the new and existing L&R subsystems.

Proposers shall provide an operational availability analysis / report for L&R of the hardware alone.Notes: An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter.

Proposers shall provide an operational availability analysis / report for L&R of the combined hardware and software if applicable.Notes: An Availability analysis / report is based on uptime data collected from operational PSAPs and which includes downtime due to hardware and software. Any scheduled downtime excluded from the availability calculation shall be described in full. The source of data used in the report, applicability of the data and method of arriving at the final combined hardware and/or software availability shall be fully explained in the report. The Proposer shall provide sound justification for the mean downtime (MDT) design parameter.

Systems Integration of L&R

The Proposer shall demonstrate their understanding of their role in the integration of the L&R FEs with the rest of the NG9-1-1 Core Services FEs, the new NG9-1-1 Call Handling system and the existing radio L&R system by describing their role in the process.

The Proposer shall include the full implementation of the NG9-1-1 Subscribe/Notify functionality as defined in NENA-STA-010.2 2016

Additional RequirementsOverall Solution Architecture The Proposer's overall solution architecture shall extend from the point from

interconnection with OSPs, neighboring 9-1-1 jurisdictions and ancillary systems on the ingress side to PSAC1 and PSAC 2 on the egress side.

The Proposer's overall design shall include a configuration at the Solutions Development Environment (SDE). A description of the SDE and the proposed configuration required can be found in Section III.D.9.

The System as a whole must be availab le a minimum of 99.9999% of the time to route calls presented to the system.To deliver the system availability required, the system must be designed with no single point of failure. It must also be designed with a high level of diversity and redundancy.

Access to all ESInet and NG9-1-1 Core Services components shall be tightly controlled and preclude any unauthorized access to systems.

Logical access to the network and the security of all data used in the system must be tightly controlled. Unauthorized access to the call transport facilities and all system information must be prevented.

Implementation of NG9-1-1 Subscribe/Notify

The Proposer must include the full implementation of the NG9-1-1 Subscribe/Notify functionality.

All devices proposed for the subsystem shall be provided with all necessary connecting cords and cables conforming to the National Electrical Manufacturers Association (NEMA) Codes.


Date: 05/06/2023 Time: 22:53:10 38 of 115



7090

7100

7110III.D.6.d Wiring and Cabling

7120

7130 Any cables used shall be rated where required by local building or fire codes.

7140

7150

7160III.D.6.e Grounding

7170

7180

7190

7200III.D.6.f

7210

7220

7230

7240 The secondary TVSS must not degrade the audio signal.

7250III.D.6.g Asset Management

7260III.D.6.h Disaster Planning

7270

7280

7290 ii) the proposed location of a tertiary facility7300 iii) the implications to the new NG9-1-1 Call Handling Subsystem

7310

7320

7330

7340

7350

The subsystems deployed at either PSAC must not cause interference to the existing radio, security, or closed circuit television communications systems, installed communications console equipment or any other data processing equipment The subsystems deployed at either PSAC must comply with all applicable FCC standards as applied to data processing equipment.All interface connections and visible cables shall use standard EIA connectors secured by wall plates where exposed.

All cables shall be clearly marked and/or numbered in a manner that reflects a unique identifier of the cable at both ends in accordance with the NYC DoITT standard for cable labeling.

All equipment deployed at either PSAC shall have the capability to be connected to redundant, resilient and diverse power sources. In addition, other facilities chosen shall provide redundant, resilient and diverse power sources supported by UPS.

Cabling, communications outlets, power wiring, subsystem grounding, conduit facilities and equipment rooms shall be installed in accordance with the national standards as listed in APPENDIX H - APPLICABLE STANDARDS and all applicable local codes.

The proposed subsystem shall provide surge and lightning protection for all connections to AC power. Any components deployed at either PSAC shall be integrated with the facilities grounding.

All hardware shall be mechanically and electrically grounded to prevent both user hazard and loss of data or hardware integrity due to external electrical impulse.

All equipment shall be grounded in compliance with the manufacturer recommendations and applicable standards.

Transient Voltage Surge Suppression The secondary Transient Voltage Surge Suppression (TVSS) shall be installed with the

proposed subsystem where appropriateTVSS devices must be installed on all equipped ports that are connected to or may be connected to wire line or wireless facilities. The secondary TVSS devices shall be listed with a maximum clamping voltage of 250 volts or less and operate in less than 10 nanoseconds.

All TVSS devices shall meet UL497A requirements and must have an operational indicator to alert maintenance personnel that the device has been utilized, failed, or that the circuit is unprotected.

All equipment owned by the City with a value in excess of $200 must have an asset tag and must be registered in the City’s asset management system. Proposer must apply asset tags as the asset is received.The Proposer shall propose ways to mitigate the City losing one PSAC where it will be "single sided" and vulnerable until both PSACs are up and operational.

The Proposer shall propose the deployment of an optional tertiary facility outside of both PSACs that would provide for ongoing, redundant, resilient and diverse call routing if one instance of the Core Services FEs was located in an unavailable PSAC.

Regarding the optional tertiary facility, the Proposer shall provide comments to the City as to:i) advantages and disadvantages of this option,

iv) the implications for NYPD Dispatchers and FDNY ARDs and dispatchers including radio communicationsv) options available to the City to subscribe to a shared solution to fall back on should it become necessary vs. a facility fully dedicated to the Cityvi) the possible use of a tertiary facility to host Core Services FEs for use by other parts of New York State as it implements NG9-1-1.

The Proposer shall provide comments and pricing on the deployment of a tertiary location to host an additional instance of NG9-1-1 Core Services.

The Proposer shall provide other disaster planning options that meet the needs of the City.


Date: 05/06/2023 Time: 22:53:10 39 of 115



7360

III.D.6.i

7370

7380

7390 The Proposer shall inculde pricing for IMRs for the above scenario.

7400

7410

III.D.6.j

7420

7430

III.D.6.k

7440

7450

III.D.6.l

7460

III.D.6.m

7470III.D.6.n

7480

7490

7500The NG9-1-1 L&R subsystem shall record all live video streamed conference calls.

7510III.D.7

The selected Proposer shall be responsible for the integration of their work scope.

7520

7530

III.D.7.a

7540

7550

Deployment of an Interactive Multimedia Response Unit (IMR)

The Proposer shall not be required to divert calls using PRRs on a wholesale basis but they may implement this on a limited basis in very specific situations where the City’s preference is to send those calls to a neighboring jurisdiction.

The Proposer shall consider and then propose the use of IMRs as a backup to a backup to a backup.The Proposer shall consider recommending how IMRs could be used in conjunction with PRRs to address the rare case when call volume exceeds the available call taking capacity.

The Proposer shall provide a description of their IMR and recommend how an IMR might be used by the City.

Automated Fire and Police Alarms and Calls from Central Station Alarm Companies

Proposer shall provide an explanation on how other jurisdictions have taken advantage of standards such as AFPA.

Proposer shall provide a detailed explanation of how Automated Fire and Police Alarms and calls from Central Station Alarm companies can be interfaced to the NG9-1-1 system.

Transition of Service Management Responsibilities to the City

The Proposer shall provide a description of roles and responsibilities of the ongoing operational and support responsibilities of the successful Proposers and their associated costs.

Proposers shall propose a plan for the City to take on some or all operational and management responsibilities.

VoIP Phone System for Non-Emergency Voice Calling

Proposers shall provide a description of the strengths and challenges with implementing 3 digit dialing as part of the Core Services functionality proposed as opposed to delivering this functionality as part of a NG9-1-1 Call Handling Subsystem to be procured via a different RFP.

Implementation of the FCC’s Accessible Communications for Everyone Program

Proposers shall provide thoughts and options on supporting the Accessible Communications for Everyone (ACE) program with the proposed NG9-1-1 system.

American Sign Language over Video

The NG9-1-1 ESInet and Core Services subsystem shall support American Sign Language over live video conference call. The subsystem shall provide functionality to accept, route, and provide live video streamed conference calls to one or more 911 call taker positions that are dedicated to American Sign Language interpretation.

The subsystem shall provide functionality to conference-in and route live video streamed calls to a video relay interpretation service which shall provide American Sign Language interpretation services.

Required Systems Integration Services

The selected Proposer shall share integration responsibility for all external interfaces with the vendor associated with the far end of the interface.

ESInet and Core Integration with Originating Service Providers The selected ESInet and Core Services subsystem Proposer shall be responsible for

entering into interconnection agreements with each of the OSPs. The selected ESInet and Core Services subsystem Proposer shall prepare a standard interconnection agreement for review and approval by the City.

The selected ESInet and Core Services subsystem Proposer shall manage the migration of all OSP from their current interconnections with the DMS-100 tandems until the final operational state of NG9-1-1 subsystem with the Operational Call Handling Subsystem has been achieved.


Date: 05/06/2023 Time: 22:53:10 40 of 115



7560

7570

III.D.7.b

7580

7590

7600

7610

7620

7630

III.D.7.c

7640

7650

7660III.D.7.d

7670

7680

7690III.D.7.e

7700

7710

7720

7730

7740 The Proposer shall integrate with the Call Handling Subsystem.

7750

7760

The ESInet and Core Subsystem Proposer shall provide a narrative describing their approach to negotiating and executing interconnection agreements with the OSPs and their approach to migrating them to the NG9-1-1 subsystem and shall also comment on the expected duration of each of the steps in the process.

Transition of the OSPs to SIP with Gateway to Operational DMS-100

The selected ESInet and Core Services Proposer shall be the sole party responsible for the transition of the OSPs to SIP from their current state to an operational state with the DMS-100s via a gateway. Note: This includes all integration and coordination efforts with Verizon, who hosts the DMS-100s at their COs.

The Proposer shall, during the phase of the project integration, execute the formal transition plans developed during the Critical Design Phase. One-by-one the OSPs shall be integrated and cut over to the new subsystem using SIP, (some utilizing SIP directly and some utilizing a gateway). The SIP calls, upon reaching the CRF, shall then be redirected through a subsystem gateway which shall in turn convert the call signaling back to SS7 protocol and onward to the DMS-100s.At the end of the transition phase all the OSP calls shall be routed through the subsystem without disruption to the current Vesta operational environment.

The OSP test queues shall be made available so that the Call Handing Subsystem can undergo joint system testing with the ESInet and Core Services subsystem without affecting on-going operations.

During the transition phase custom test queues shall be created to exercise and test the subsystem’s ability to handle each OSP’s conversion to SIP, and the onward conversion back to SS7.

The test plan and test procedure developed for the transition phase of testing will be executed and follow the same path as those for FAT and SAT.

Integration and Test with the NYC Public Safety NOC/SOC/Helpdesk External Interfaces

During integration, the Proposer shall take the lead in the integration and test of NYC Public Safety NOC/SOC/Helpdesk/Enterprise services with the ESInet and Core and NG L&R subsystems.

The Proposer must utilize City provided interfaces to implement this functionality, including implementing subsystem monitoring to send SNMPv3 traps and informs to the Public Safety NOC Manager-of-Managers (MOM).

The Proposer shall consider NOC/SOC/Helpdesk, and Enterprise services test procedures to be part of the Subsystem Acceptance Test (SAT) phase of the project even through it is an integration to an external City provided subsystem

Integration and Test with Logging and Recording

NG L&R subsystem shall be integrated with the legacy L&R subsystem that supports Radio and other analog connections before the integration of L&R with the ESInet and Core Subsystem and the Call Handling Subsystem.The ESInet and Core Services provider shall integrate with the combined L&R subsystems

The L&R Proposer’s staff shall create the L&R integration test procedures with ESInet and Core Services subsystem.

Integration and Test with the Call Handling Subsystem The Call Handling Subsystem shall comply with all relevant NENA standards

especially those that deal with the interface to the ESRP in Core Services.

All calls shall be delivered to the Call Handling Subsystem with Presence Information Data Format Location Object (PIDF-LO) and all available subscriber information and preferences.

The ESRP must interface with the new Call Handling Subsystem in compliance with the appropriate NENA standards. .

The Proposer must provide any specific requirements or interpretations of the standard they have relied on if it varies from the NENA standards.The LIS/ALI must interface with the new Call Handling Subsystem in compliance with the appropriate NENA standards.

Once the interfaces have been confirmed to be functional, the Proposer shall utilize test queues setup during the OSP transitions to provide SIP test calls to the Call Handling Subsystem.

The Call Handling Subsystem and the ESInet/Core Services subsystem test procedures which follow the system test plan (created during the CDP) shall be redlined, dry run and formally executed.


Date: 05/06/2023 Time: 22:53:10 41 of 115



7770

7780

7790

7800III.D.7.f Integration with GIS

7810

7820III.D.7.g

7830

7840

7850

7860III.D.7.h

7870III.D.7.h.1

7880III.D.7.h.2

The Proposal shall include the support for the Emergency Reporting system.

7890

7900 III.D.7.h.3 SolarCell & LinkNYC Proposer shall note any issues foreseen in supporting SolarCell and LinkNYC.

7910III.D.7.i

7920

7930

III.D.8 Cyber Security

7931

7932

7933

7934

7935

7936

7937

More details about the required interface to the new NG9-1-1 Call Handling Subsystem can be found in Appendix E

The successful Proposer shall be responsible for supporting the Proposer of the Call Handling Subsystem (selected by the City through another RFP) for the transition from the current VESTA workstations to the new NG9-1-1 Call Handling Subsystem.

Proposer shall provide a detailed explanation of the call handling and LIS/ALI interface they have implemented, any assumptions or interpretations of the standard they have made and a list of Call Handling Subsystems they have successfully interfaced with.The ESInet and Core Services provider shall integrate the ESInet/Core with the configured GIS software required by this RFP. The Proposer shall address the integration, test and cutover of the GIS and the LIS/ALI functionality in their technical narrative.

Integration with Neighboring NG9-1-1 Jurisdictions

The successful Proposer shall work with the 9-1-1 System Service Providers responsible for each of the counties in New Jersey and New York State to establish the appropriate interconnection with the City's NG9-1-1 system.

The successful Proposer shall work with the 9-1-1 authorities in each of the counties in New Jersey and New York State to gather the necessary GIS data to support call transfers.

Proposer shall provide a narrative describing their approach to establishing interconnections with all identified neighboring 9-1-1 jurisdictions.

Proposer shall provide a narrative describing the collection and maintenance of required GIS data from each of the jurisdictions. Proposers shall also provide expected durations for each of these steps.

Integration with Ancillary Legacy Systems Proposers must describe how they will adapt the several legacy ancillary systems to

the NG9-1-1 system. New York City 3-1-1 System Proposers shall provide support for the SIP trunking from the City’s 3-1-1 system

adequate to support 400 to 500 call transfers per day.Emergency Reporting System

Proposer shall provide a detailed explanation of how the Emergency Reporting System will be adapted to the NG9-1-1 system.

Integration with the Interim Text to 9-1-1 Proposer shall provide an assessment of the technical and regulatory evolution of

SMS and RTT to reach emergency services.Proposer shall propose a solution that can adapt to the most likely scenarios for text to 9-1-1 and RTT to 9-1-1.

Proposer shall provide the highest level of cyber security possible by adhering to the security standards list in APPENDIX H - APPLICABLE STANDARDS and by implementing all security standards found on the City’s website and all DoITT PSAC Security guidelines shown in Attachment K.

Proposer shall provide a detailed description of how their proposed solution integrates with the overall DoITT Cyber mission to monitor, detect, analyze, mitigate and respond to cyber threats and adversarial activity on the ESInet.The ESInet / Core Subsystem shall implement subsystem functionality to protect against Distributed Denial of Service (DDOS) Attacks.

The Proposer shall fully describe their proposed DDOS security functionality and how they propose testing said functionality.The ESInet / Core Subsystem shall implement subsystem functionality to protect against Telephone Distributed Denial of Service Attacks (TDDOS).The Proposer shall fully describe their proposed TDOS security functionality and how they propose testing said functionality.

The ESInet / Core Subsystem shall implement subsystem functionality to protect against Multimedia and Text Distributed Denial of Service Attacks (MTDDOS).

The Proposer must fully describe their proposed MTDDOS security functionality and how they propose testing said functionality.


Date: 05/06/2023 Time: 22:53:10 42 of 115



7940

III.D.8.a.1

7950

III.D.8.a.2 Actors

7960

III.D.8.a.3 Example Flow

7970

III.D.8.a.4 Alternative Flow

Cyber Security scenario 1: Distributed Denial of Service (DDOS) Attack - DNS Amplification Vector

Prelude

The Proposer shall deal with an orchestrator, possibly a nation state, criminal or disgruntled employee plans and prepares a DNS attack on a PSAP of moderate size. Either the orchestrator has created its own botnet or takes the easier path of leveraging an existing geographically diverse botnet whose operator makes its resources available. This botnet consists of hundreds, possibly thousands of PCs and servers from across the world, which are infected with a specific malware, making them an unwitting part of the botnet. The orchestrator has likely performed some reconnaissance on the target PSAP and chose an inconvenient time of attack, such as high call volume times when even a fully staffed PSAP is vulnerable to overload. The orchestrator will also research the DNS arrangement of the target network through use of commonly available scanners. In this scenario, the PSAP leverages external DNS services through its own DNS infrastructure as part of the service area’s network operated by the local municipality. Under current conditions, the configuration of the PSAP’s DNS server is irrelevant, because the target of a DNS Amplification DDOS is generally not the target’s DNS server. It can be any externally-facing address, including a numbered interface on their perimeter router, their firewall, their mail server, their web server (most common), or anything. The idea is simply to consume the bandwidth on their circuit, choking off legitimate traffic. If you can spike the Central Processing Unit (CPU) on the target device as a side effect that is a bonus, but it is not required for a successful DDoS.

The Proposer shall deal with• Orchestrator (Nation State, Criminal, Disgruntled Employee, etc.)• DNS Server A• DNS Server P (PSAP)• Multiple remote PC’s

Amplification DDoS attack works like this:A large number of clients, typically in a botnet, send DNS requests to publicly accessible DNS servers on the Internet with a spoofed source address of a target at the victim. The target is generally the victim’s website, but can be anything in the target netblock. Each request is very small (< 100 bytes), allowing the targets to send out billions upon billions of them. The DNS servers on the Internet helpfully respond to the requests and send the answer (which is much larger, often in the tens of kilobytes) to the address listed as the source. Which happens to be the victim’s website, or their firewall, or something else. The sheer number of requests, coupled with the sheer size of each, rapidly consumes all of the bandwidth available on their circuit.1. The attack is initiated through an action by the orchestrator.2. In this case, the attacker simply clicks an icon on a simple user interface. 3. Seconds later, the botnet constituents send a specifically crafted DNS request to public DNS servers.4. Part of the DNS request lists the municipality’s DNS server as the source (or some other high value target such as the PSAP ingress router or SBC addresses)).5. Shortly after, (possibly milliseconds), the impact of the attack is felt by the PSAP.6. The targeted PSAP services (such as the DNS server response to PSAP name resolution, or the ingress router or SBC) degrade or fail.7. Depending on the network bandwidth available to the DNS server or PSAP and/or size of the attack, the PSAP network will begin either slowing or could experience a stoppage of communications.8. The DNS server may not be located on the same path as the PSAP, so this does not necessarily follow. However, the attacker could utilize the PSAP ingress router in the IP source address, so as to target that directly9. Any external access attempt by the PSAP will degrade or fail due to loss of name resolution or bandwidth.10. Trouble ticket systems slow or fail.11. Depending on the network architecture, call quality may degrade or VoIP services may be lost completely.12. Internal communications may be affected, depending on DNS architecture.13. Ability to report or gain assistance to resolve the outage may be lost.14. If other PSAPs in the area are similarly affected, transfer of call taking capability may also be impossible.15. The orchestrator may decide to stop the attack or may reengage the attack at a later time or date.The Proposer shall be prepared to respond If the PSAP itself is compromised, multiple alternate vectors are possible including financial or political extortion requirement payment of funds to the attacker or the release of information based on political motivations. Note that no inside knowledge is required to carry out a DDOS attack. This said, there are routine cyber hygiene protocols that PSAPs should consider and implement in order to mitigate at least some of the potential threats and vectors.


Date: 05/06/2023 Time: 22:53:10 43 of 115



7980

III.D.8.a.5 Post-Conditions

7990

III.D.8.b.1

8000

III.D.8.b.2 Actors

8010

III.D.8.b.3 Example Flow

8020

III.D.8.c.1

8030

III.D.8.c.2 Actors

The Proposer shall prevent the PSAP network to begin either slowing or experience a stoppage of communications. Any external access attempt by the PSAP will degrade or fail due to loss of name resolution or bandwidth. Trouble ticket systems may slow or fail. Depending on the network architecture, call quality may degrade or VoIP services may be lost completely. Ability to report or gain assistance to resolve the outage may be lost.

Cyber Security scenario 2: Telephony Denial of Service (TDOS) Attack

Prelude

The Proposer shall prevent an orchestrator, possibly a nation state, criminal or disgruntled employee plans and prepares a Telephone Denial of Service (TDOS) attack on one or more PSAPs. To carry out the attack, the orchestrator arranges for a large number of calls to be made to target phone number(s), which can be PSAP administrative lines or emergency (9-1-1) lines. The attack can be carried out either by leveraging an existing “busy signal” service [BUSY-SIGNAL], or by utilizing resources (such as compromised PBX systems) commandeered by the orchestrator. To avoid detection or to inhibit corrective measures, the caller-id may be changed on every call. TDOS attacks on PSAP administrative lines have been most common to date [DHSTDOS] since calls to these numbers can be made from any phone number. However, attacks against emergency (9-1-1) lines are also possible.

The Proposer shall block these possible perpetrators:• Orchestrator (Nation State, Criminal, Disgruntled Employee, etc.)• Vulnerable or compromised PBXs

From a cyber-attack perspective, a TDOS attack works like this:The orchestrator arranges for a large number of calls to be made to the target phone number(s). The calls used in the attacks may utilize a legitimate caller-id or (more commonly) may spoof caller-id, potentially changing the caller-id on every call to avoid detection. The goal of the attack is to tie up resources within the PSAP, preventing the handling of legitimate incoming calls and/or the making of outgoing calls. The audio content of the calls may include DTMF patterns, white noise, silence (which could be construed as a “silent call” from a disabled user, or as a technical problem), or audio in English or in a foreign language. PSAP administrative lines have been a popular target for TDOS attacks, since calls originating from anywhere can be used to reach them. In contrast, calls made to 9-1-1 may or may not be routed to the target PSAP, depending on the caller-id. Often TDOS attacks are mounted in concert with other criminal activity, such as extortion attempts, or toll fraud [TOLL-FRAUD]. The orchestrator may call the target PSAP and demand payment based on a pretext (such as a debt owed by a former PSAP employee). After the blackmail demand is denied, the attack begins, typically lasting for hours or even days. The orchestrator may utilize compromised PBXs not only to initiate calls to the target PSAP but also in order to make unauthorized international calls or calls to services charging by the minute. These schemes may result in the accumulation of large charges within short periods of time, so that they can be financially damaging to the owners of the compromised PBXs.

Cyber Security scenario 3: One PSAC Compromised need to protect Interconnected PSACs

Prelude

The Proposer shall prebvent a PSAP to be compromised by some means such as virus, malware, hijack (see other Use Case #), etc. and it is attempting to propagate or access other PSAPs over trusted connections such as the ESI Net.

The Proposer shall block these possible perpetrators:- Orchestrator (Criminal, Disgruntled Employee, etc.)- PSAP#1 staff, PSAP#2 staff, PSAP#3 staff- Originating Service Provider (OSP) and Text Control Center(TCC)- Systems support staff (contracted or PSAP)- Network support staff (contract or PSAP/ LAN and ESI Net)- CPE Proposers


Date: 05/06/2023 Time: 22:53:10 44 of 115



8040

III.D.8.c.3 Example Flow

8050

III.D.8.c.4 Alternative Flow

8080III.D.9

8090

8100

8110

8120

III.D.9.b

8130

8140

III.D.10 Training

The Proposer shall ensure that the PSAP is not compromised via code injection of a video file sent through Multimedia Messaging Service (MMS) messaging to the PSAP as in the following example 1. PSAP#1 receives a spoofed MMS text message from the orchestrator via the OSP and TCC2. PSAP#1 staff view the video file unknowingly executing the malicious code. PSAP#1 due to weak cybersecurity measures has now been compromised.3. PSAP#1 staff experience difficulties with call handling functions due to corruption on local servers and systems.4. That malicious code then attempts to increase its footprint expanding over trusted connections to shared unprotected resources.5. PSAP#2 systems begin to have failures and problems with call handling functions.6. PSAP#3’s cybersecurity monitoring and security measures detect the malicious codes attempt at access alerting PSAP#3 staff.7. PSAP#3 staff investigates the alarms, identify the potential threat and then enact appropriate plans, which include disabling of connectivity to PSAP#1 and eventually PSAP#2.8. PSAP#3 staff notifies PSAP#1 and #2 of the activity they have identified.9. PSAP#1 and #2 begin their own actions towards mitigation.10. Eventually once all systems have been cleaned and tested connectivity to the ESInet will be re-established.

The responder shall provide several alternatives to this type of attack most stemming from how the original PSAP is compromised and depending on the cybersecurity measures in place at the originating site and the interconnected sites. Call handling can be affected if file corruption or network bandwidth becomes restricted due to the malicious code’s activity .

Solutions Development Environment The Proposer shall propose design, build, integration and testing services to

complete the ESInet and Core deployment located in the SDE.

Proposers shall include in their proposals a narrative description of the proposed NG9-1-1 Core, L&R, and GIS subsystem equipment for use in the SDE.

Proposers shall provide thoughts on how the SDE design phase will be executed and provide any risks that they believe the accelerated design approach will present.The Proposer shall provide description of how the Proposer will use the SDE to reduce program risk through early interface testing or other activities.

SDE for User Acceptance Testing (UAT)

The Proposer shall consider what additional equipment, if any, will be required to outfit the SDE to facilitate and perform UAT with the user community. The proposed SDE block diagram must identify all equipment required to fulfill this aspect of the mission for the user community. The SDE design document shall describe how the UAT testing will occur in the SDE by the public safety user community.

The Proposer will allow The City to cover the cost of power, cooling and racks at the SDE. The City will also arrange for the network WAN connections between the SDE and PSAC1, PSAC2 if required. Pricing must include full maintenance on the hardware and software as well as upgrades to both (not including the 2 technical refreshes described later). Assume for the purposes of the RFP that the SDE will be actively monitoring by the City’s NOC/SOC/Enterprise services contained in the SDE.

The Proposer shall provide training for all users of the system at every level. The depth of the training and they delivery mechanism must be geared to the intended audience. Training must be available on all aspects of the system that City employees interface with. The Proposer must include a full suite of training modules. At a minimum, training must be available for users of:1. System monitoring;2. The provisioning interface for the Policy Routing Function;3. The provisioning interfaces for the ECRF and LVF; and4. The provisioning interfaces for the LIS/ALI.5. The NG9-1-1 Logging and Recording systemModule content and delivery must be developed for each of the following levels:1. The mayor's office and Agency Management;2. Senior operations management;3. Operations management; 4. Administrators; and5. Individual users


Date: 05/06/2023 Time: 22:53:10 45 of 115



8150

8160

8170

8180 Proposer proposal must include workstations to support classroom training.

8190

III.D.11

8200

8210III.D.12

8220

8230

8240 Proposer shall provide a complete, integrated and coordinated solution.

8250

Proposer shall provide a full description of the roles, responsibilities, skills, knowledge level and authority level for Operations Management, Administrators and individual users.The Proposer shall estimate the training effort as shown in Table 4. This table will be updated during negotiations.

Proposers shall have staff with extensive training experience and certifications to provide training to all City employees interfacing with the system.

Reporting and Statistics Capture

The Proposer shall provide the City requires with comprehensive Reporting and Statistics Capture (RSC) functionality that captures subsystem data and produces reports. Features of the RSC must include:- Real-time or near real-time system performance data must be made available to all authorized users.- Data must be captured to report on all requirements shown in APPENDIX F - SUBSYSTEM PERFORMANCE AND CAPACITY.- Additional data to be captured and specific reports can be found in APPENDIX G - DATA TO BE CAPTURED AND REQUIRED REPORTS.- The RSC must require a secure user ID login.- Access to the RSC Portal, data and reports must be role-based and reflect the credentials of the user. - The system must support the generation of reports in PDF, HTML, CVS and Microsoft Excel formats.- The RSC must be accessible anywhere with a secure network connection and support any device with an internet browser including smart phones and tablets.- The creation of ad hoc reports using a report generation tool that provides dropdown lists and checkboxes to allow the user to include every major field stored in the RSC.

Proposer shall describe the functionality of the Graphic User Interface including the access controls, audit trail of changes and validation of logic prior to putting them into service.

Subsystem Management & Maintenance The Proposer shall provide the City the ability to actively oversee the day-to-day

operations and monitor subsystem performance.

The Proposer shall provide the City with an integrated, coordinated solution from which shall be at least in part, if not in full, provided by City supplied interfaces to the City NOC, SOC and Enterprise Services. This solution must include every aspect of managing and maintaining the system for the life of the contract including:- 24x7 system monitoring- Network and NG9-1-1 maintenance- all software and hardware updates- all hardware and software upgrades- a trouble ticketing and problem escalation system- real-time, scheduled and ad hoc reporting

The Proposer shall apply to all network facilities and NG9-1-1 components from the point of ingress within the subsystem to the point of egress from the subsystem.

Proposer shall describe the methodologies, systems, procedures, run books and tools used to provide this solution.


Date: 05/06/2023 Time: 22:53:10 46 of 115



8260

III.D.12.a

8270 Proposer shall provide robust customer service and support. 8280 Proposer shall provide a description of the services proposed.

8290

III.D.12.b

8300 The Proposer must define Tier 1, 2, 3, 4 escalation policy and staffing.

8310

8320

Customer Service and Support Requirements

The Proposer must provide customer support services at various levels including the Mayor's office, Agency (DoITT, NYPD and FDNY) Management and Operations and users including supervisors. Customer services for all levels must include:- SLA Management- Event management- Incident management- Diagnostics and reporting- Problem resolution and trouble handling- Network fault monitoring- request fulfillment- Remote diagnostics- Access management- Capacity management- Change management- Configuration management

Network Operations Center and Security Operations Center (NOC/SOC) and Enterprise Services The proposed subsystem shall directly interface with the City supplied Network

Operations Center (NOC) and Security Operations Center (SOC).

The Proposer shall utilize the City’s NOC/SOC/Helpdesk which is equipped with a Manager-of-Manager, SEIM, Helpdesk software and Enterprise Management Suite of tools that monitor, Manage, Save and Restore every aspect of PSAC subsystems including:- SNMP vs 3 traps alarms and alerts- Central collection and storage of Syslogs- Collection and correlation of system and security events to provide real-time indication of potential security attack vectors- the performance and availability of devices and Server software- SW/HW inventory- SW Configuration Management- Network Device Configuration Management - network performance, throughput, latency, jitter, packet loss statistic tracking- ITSM tool, SLA Tracking, plus Change, Incident, Problem, Asset Management- Complete backup and restore capability with availability (or expandable) storage for backups

The Proposer shall utilize the centralized Public Safety NOC VMware and HW based environment supports and provides the following centralized NOC and enterprise services SW:a) Central NOC (Netcool/Omnibus)b) Microsoft Active Directory serversc) MacAfee EPO Virus/Malware/HIPs Protectiond) DNS services (Active Directory)e) Patch management (Bladelogic)f) Hardware Inventory (iLo HP Insight manager)g) Software Inventoryh) SW deliveryi) HW/SW configuration managementj) Help Desk Functionality k) Network Services (CISCO OVA, CISCO DCNM, CISCO ACS, MacAfee IPS SW)l) Netcool impactm) SEIM and event syslog capture and storage (not disclosed)n) Packet Capture and analysis o) Remote Access subsystem p) Centralized Certificate Services


Date: 05/06/2023 Time: 22:53:10 47 of 115



8330

8340

8350

8360

8370

8380

8390

8400

8410 The Proposer's active directory shall interface to the central NOC Active Directory

8420

8430

8440

8450

8460

8470

8480III.D.12.c Help Desk Requirements

8490

8500

8510

The Proposer shall utilize the City provided NOC/SOCwhich has an availability in excess of five nines, with high availability components located at both PSAC1 and PSAC2.

The Proposer shall design their subsystem (during the subsystem design phase) to be compatible with City provided NOC/SOC/Helpdesk/Enterprise services suite of tools.

The Proposer shall describe any service described above that cannot be utilized through the City provided interfaces and must be provided by subsystem functionality described in the Proposer’s proposal.

The Respopnder shall provide the City with to a description of alternate solutions; however, pricing should be based upon utilization of the above described services and interfaces and on the other content of this subsection to the extent possible. Should the City agree to an alternative solution, the redefined scope and pricing will be addressed during negotiations.

Each Proposer subsystem shall forward service-affecting SNMP vs 3 traps to the central Public Safety NOC.

Each Proposer subsystem shall configure SNMP-capable servers and network elements with appropriate thresholds appropriate to detect and automatically forward service-affecting events when the configured threshold is crossed.The Proposer’s subsystem shall utilize the City provided event manager which will monitor the subsystem directly through a direction connection to the City’s NOC/SOC.

The subsystem shall support Active Directory based central administration and authentication for windows based servers and workstations.

The subsystem shall support DNS and must interface to the City supplied DNS as the DNS authority.

The Proposer may be required to host client event management and enterprise management SW on subsystem servers, which would then be subject to compatibility testing with native subsystem’s servers. The Proposer should assume for the purposes of pricing this RFP that no such client SW will be required. This topic will be formally resolved during the negotiation phase.

The Proposers shall utilize the City-provided virus/malware prevention/detection/end-point SW (MacAfee) which requires client based SW on target workstations and servers. The Proposer’s subsystem equipment shall utilize SNMP version 3 for all SNMP protocol transactions.

The Proposers SNMP access/control passwords shall conform to DoITT password complexity requirements.

The Proposers shall describe in their technical narrative the necessary security and network functionality that will be required to meet NIST security compliance of their subsystem. Any functionality not provided by the City supplied NOC/SOC/trouble ticket/Enterprise interfaces will be addressed during the negotiation phase of the project.

The Proposer must ensure that all actionable events created and are actively tracked by the City’s Helpdesk software.

The Proposer is required to directly participate in the City’s process to include Change, Incident, Problem, Management process which includes the creation of Change Requests through the City’s Change Request module that is part of the City’s Trouble ticket/Helpdesk software. All changes and maintenance to operational equipment will go through a Change Request (CR) which must be approved before by the CCB before action taken is permitted by the Proposer’s staff. Break fix CR that must be implemented to restore operational service (severity 1 or 2 TDRs) can for the purpose of this RFP be assumed to authorized in real time (i.e., assume 5 minutes for City authorization). Such incidents, when generated via the ITSM tool are automatically and directly escalated to the highest level of City’s management and will invoke an escalated internal approval process.

The Proposer’s help desk must operate on a 24x7x365 basis and be adequately staffed by resources who are trained and qualified in help desk and customer support services.Proposers shall provide onsite help desk staff that are dedicated only to City of NY Public Safety ESInet and Core/GIS and NG L&R Subsystems.


Date: 05/06/2023 Time: 22:53:10 48 of 115



8520

8530

8540

8550

8560

8570

8580

8590 The Proposer shall create Incident Record within 15 minutes for all Severities

8600

8610 The Proposer shall resolve Critical incident within 2 hours 8620 The Proposer shall send notifications of Critical Incidents within 20 mins8630 The Proposer shall report High incident resolution within 6 hours8640 The Proposer shall acknowledge a Medium incident within 4 hours8650 The Proposer shall resolve a Medium incident within 72 hours8660 The Proposer shall acknowledge a Low incident within 34 hours8670 The Proposer shall resolve a Low incident within 168 days

8680III.D.13

8690

8700

8710

8720

8730

8740

The Proposer shall describe their Tiered support model and why this support model can be expected to provide the minimum 4-hour Mean Down Time, as defined in the Availability section in III.D.2.The Proposer’s help desk staff must act as a single point of contact for all matters involving the ESInet and Core/GIS subsystem and NG L&R subsystem.

The Proposer’s helpdesk staff must be accessible via various methods including voice, text and email and have communication with:d) All Tier levels of the Proposer’s maintenance and support service personnel e) The City’s Public Safety helpdesk, maintenance and support personnelf) Maintenance and support personnel associated with connected OSPs

Proposer must propose an escalation guideline document that describes the escalation procedure for the City. The Proposer must provide the following levels of service:

The Proposer shall provide Standard notification to the City for any changes to the systemThe Proposer shall provide Expedited notification to the City for any changes to the systemThe Proposer shall provide Emergency notification to the City for changes to the system

The Proposer shall acknowledge Critical and High Severity incidents within 10 minutes

Project Management, Planning and Schedule Requirements Proposers shall provide a preliminary project management plan as part of their

proposal.

The Proposer shall describe the methodology for implementing Proposer's proposed solution and show activities involved with integration to the City’s NG9-1-1 Call Handling Subsystem leading to operational cut over on or before July 31, 2021.

The Proposer shall implement a project management plan that is consistent with the Project Management Institute (PMI) best practices.

The Proposer shall provide, at a minimum, include the implementation project plan which must include:- Proposed schedule (see additional requirements and planning assumptions below)- Change management plan- Configuration management plan- Communications plan- Quality Assurance and Quality Control plan- Risk Management plan- Status meeting with the City.- Project Jeopardy Notification.

The successful Proposer shall have an organizational structure that demonstrates the importance of project management and Project Managers, including a description of the management processes used throughout their various projects.

The successful Proposer shall apply project management methodologies detailed in the Project Management Body of Knowledge (PMBOK) and will staff project management positions with individuals with the experience necessary.

Proposer shall help coordinate Project Management Office (PMO) meetings that will be held to review project status, schedules, risks, and other important programmatic areas. Proposer shall send out an agenda two days before the meeting and meeting minutes shall be captured and circulated within two days of the completion of the meeting.


Date: 05/06/2023 Time: 22:53:10 49 of 115



8750

8760

8770III.D.13.a

The Proposer must propose a high-level schedule in phases as part of their proposal.

8780

8790III.D.13.b

8800

8810

III.D.13.c Technical Refresh

8820

8830III.E

8840

8850

8860

To encourage greater engagement and interaction with City project team members, the Proposer shall utilize one, up to four, cubicle(s) at MetroTech Center in Brooklyn, NY, for each Proposer’s exclusive use. A City phone and a City desktop computer configured with the City’s preferred tools including Microsoft Project, Visio, Outlook, Word and Excel will be provided at each cubicle, subject to the City’s security and usage regulations.

The selected Proposers shall provide systems integration services - managed internally by each Proposer’s PM and working in full coordination with the City’s PMO and technical teams.

Schedule and Planning Assumptions

The Proposer in developing the implementation schedule, Proposer must make the following assumptions:- Contract signing and project initiation as shown in SECTION I – TIMETABLE- All OSPs have been engaged and an interconnection/migration schedule meeting the project milestones/deadlines can be arranged- All neighboring 9-1-1 jurisdictions have been engaged and an interconnection schedule meeting the project milestones/deadlines can be arranged- All City organizations responsible for Ancillary Systems and Text to 9-1-1 will be ready to support the migration schedule required to meet project milestones/deadlines- Completion of the ESInet and Core Services Build phase no later than Feb 2, 2020- Completion of the ESInet and Core Services SAT Test phase no later than July 5, 2020- NG9-1-1 Call Handling Subsystem will be ready for integration no later than December 6, 2020- Beginning of System Integration Test (SIT) March 1, 2021- Overall NG9-1-1 System Ready for Service commencing no later than July 31, 2021.

Test Plan and Assumptions The test plan to be implemented shall follow the City's testing methodology and use

the City's terminology.

Proposer shall propose a test plan consistent with the one used by the City outlined in Appendix I and show all scheduled tests in the MS Project schedule in accordance with the release management process and policy for testing and implementation into production.

The City requires the Proposer to perform two (2) complete technical refreshes, one refresh starting in operational years 5 and 10 during the 15 operational life of the subsystem. HW is expected to be completely replaced and updated for each Functional Element in the subsystem. The newly installed HW and SW must meet or exceed the requirement baseline established during the project design phase, including the requirements related to availability. HW/SW must meet or exceed the requirements specified by the latest version of the applicable NENA specifications. The technical refresh is required to be backward compatible with any SW that does not require a technical update.

The Proposer shall allow technical refresh costs to be reimbursed subject to a change order, contract update, or as discussed and agreed during the negotiations phase of the project. An update to the project design documents, along with an updated implementation and test plan, will be required as part of the technical refresh process. No operational down time will be permitted as part of this refresh process.

Overall Program Reporting and Governance Each Proposer shall embrace complete, transparent, bi-directional communications

during all phases and covering all topics. Each Proposer shall provide frequent project status assessments and actively participate in more formal project reviews.

Each Proposer shall anticipate a full, face-to-face meeting with the Program Stewardship Committee every month during the migration to NG9-1-1 and quarterly once the system is in steady-state operations.

To focus on specific aspects of the project, each Proposer shall anticipate sub-committee meetings, on a monthly basis for proposal planning purposes.


Date: 05/06/2023 Time: 22:53:10 50 of 115



8870

8880

8890

8900

8910

III.G

8920

III.H

8930

III.I

8940

III.J

8950

III.K

8960

III.L

8970III.M

8980

8990

III.N

9000

III.O

9010

IV [N/A for this RCM]

Proposer shall collect topics for the Agenda of sub-committee or other project meetings and distribute them two weeks prior to the meeting to allow all parties to prepare.Proposer shall publish the final agenda three days prior to the meeting and shall include the topic, any decisions to be made, and the topic owner.The Proposer shall plan on their project manager and any required specialists to attend Program Stewardship Committee meetings in person.

Proposer shall participate in all Program Stewardship Committee and subcommittee meetings in an open, transparent manner.

Compliance with Local Law 34 of 2007

Proposers are required to complete ATTACHMENT G – DOING BUSINESS DATA FORM and return it with your proposal submission and must do so in a separate envelope. (If the Proposer is a proposed joint venture, the entities that comprise the proposed joint venture must each complete a Data Form.)

Whistleblower Protection Expansion Act Rider

Proposers shall post a notice informing their employees of their rights in reference to Local Law Nos. 30 and 33 of 2012, codified at sections 6-132 and 12-113 of the New York City Administrative Code, the Whistleblower Protection Expansion Act, protecting employees of certain City contractors from adverse personnel action based on whistleblower activity relating to a City contract.

Compliance with Iran Divestment Act

Each Proposer is required to complete the attached Bidders Certification of Compliance with the Iran Divestment Act, certifying that it is not on a list of entities engaged in investments activities in Iran created by the Commissioner of the NYS Office of General Services.

Subcontractor Compliance Notice

The selected Proposer shall utilize the City’s web-based system to identify all subcontractors in order to obtain subcontractor approval pursuant to PPB Rule section 4-13, and shall also be required to enter all subcontractor payment information and other related information in such system during the contract term.

HIRENYC and Reporting Requirements

The selected Proposer shall follow the Hire NYC process requiring contractors to enroll with the Hire NYC system within thirty days after the registration of the contract subject to this solicitation, to provide information regarding all entry to mid-level job opportunities arising from this contract and located in New York City, and to agree to interview qualified candidates from HireNYC for those opportunities. The Rider also includes reporting requirements unrelated to HireNYC.

Paid Sick Leave Law Contract Rider

The selected Proposers as contractors of the City of New York may be required to provide sick time pursuant to the PSLL. The Paid Sick Leave Law Rider will be included in any contract awarded from this RFP and will incorporate the PSLL as a material term of such a contract.

Joint Ventures and Other Contractor Relationships

Joint ventures must carry the required insurance either as policies written specifically for the joint venture entity, or by using their existing single entity policies with endorsements written for the joint venture activity

The joint venture must be formed as a separate legal entity, and established for at least five (5) years prior to proposal submission under this RFP.

HIPAA Business Associate Provisions

If in the course of Contractor’s performance of services, a Covered Entity Agency and/or Business Associate Agency will disclose any Protected Health Information to Contractor, or otherwise provide access to any Protected Health Information to Contractor, Contractor will be subject to the City’s HIPAA Business Associate provisions set forth in Attachment HIPAA. If Contractor provides Logging and Recording services, Contractor shall be subject to the City’s Business Associate provisions set forth in Attachment HIPAA.

Prevailing Wage Requirements

Any work within the scope of services of this contract involving construction and labor trades will require compliance with NYS Labor Law 220 as to the construction trade work. Any work within the scope of services of this contract involving building service occupations will require compliance with NYS Labor Law 230 as to the building services work. The provisions of the NYC Living Wage Law [Admin Code 6-109] will apply to any work within the scope of services of this contract in any of the applicable areas of employment: day care services, food services, Head Start services, homecare services, services to persons with Cerebral Palsy, building services and temporary services.

When federal funding is utilized for this contract any work involving construction trades would also be subject to the requirements of the US Davis- Bacon Act. When federal funding is utilized for this contract any work involving service occupations may be subject to the US McNamara-O’Hara Service Contract Act.

FORMAT AND CONTENT OF THE PROPOSAL


Date: 05/06/2023 Time: 22:53:10 51 of 115



V. [N/A for this RCM]

VI. [N/A for this RCM]

12000APPENDIX F

12010

12020

12030

12040

12050

12060

12070

12080

12090

12100

12110

12120

12130

12140

12150

12160 The ESInet/Core network shall have a Call setup time less than 1 second.

PROPOSAL EVALUATION AND CONTRACT AWARD PROCEDURES

GENERAL INFORMATION TO PROPOSERS

SUBSYSTEM PERFORMANCE and CAPACITY

The following system performance requirements must be achieved. Those items that must be included in an SLA are noted accordingly.

The ESInet/Core Subsystem shall provide voice call routing throughput of 50,000 calls per hour.

The ESInet/Core, GIS, and L&R Subsystems shall process a peak voice call volume of 12,600 calls per hour sustained for up to 2 days. Note: 12,600 calls per hour corresponds to 6300 at both PSAC1 and PSAC2. Hence the SDE or optional 3rd site equivalent specification is 6300 calls per hour total.

The ESInet/Core, GIS, and L&R Subsystems shall be capable of processing a Minimum of 500 Simultaneous Calls.

The ESInet/Core Subsystem shall implement a Minimum Call Queue depth of at least 5000 calls.

The ESInet/Core Subsystem shall process Text to 9-1-1 messages at a rate corresponding to 3% of the peak voice call volume (378 per hour).

The ESInet/Core Subsystem shall process MMS messages at a rate corresponding to 3% of the peak voice call volume (378 per hour).

The ESInet/Core and L&R Subsystems data storage shall be sized to support an MMS attachment size of 50M bytes each.

The ESInet/Core, GIS, and L&R Subsystems shall be capable of processing 33,000,000 voice calls per year.

The ESInet/Core, GIS, and L&R Subsystems shall be capable of processing 990,000 (i.e. 3% of 33,000,000) Text to 9-1-1 messages per year.

The ESInet/Core, GIS, and L&R Subsystems shall be capable of processing 990,000 (i.e. 3% of 33,000,000) MMS messages per year.

The ESInet/Core and L&R subsystem system storage shall be initially sized for 2 years of MMS storage with the capability of to be expanded by a factor of 5.

The ESInet/Core network shall have a packet latency of less than 5 ms average round trip between the ingress point (BCF or LNG) and the egress point (Call Handling Subsystem).

The ESInet/Core network shall have a Packet Loss less than 1% between the ingress point (BCF or LNG) and the egress point (Call Handling Subsystem).

The ESInet/Core network shall have a Jitter that is not to exceed 5 ms between the ingress point (BCF or LNG) and the egress point (Call Handling Subsystem).The ESInet/Core network shall have a Time clock Accuracy (network devices, servers, workstation) within 2 ms of the Stratum-1-time-server.

IT Security Requirements

Date: 05/06/2023 Time: 22:53:10 52 of 115

RCM ID # Security ID Requirement Text City Comment Proposer Compliance Comments Other Proposer Comments

5.1. 5.1. General

20000 5.1.1.

20010

20020 5.1.2. https://www1.nyc.gov/assets/doitt/downloads/pdf/encryption.pdf

20030 5.1.3.

20040 5.1.4. Provided through enterprise services interfaces

20050 5.1.5.

20060 5.1.6.

20070 5.1.7.

20080 5.1.8.

20090 5.1.9.

20100 5.1.10 Administrative accounts must not be shared.

20110 5.1.1120120 5.1.12 Subsystem Passwords shall follow Citywide Password policy. https://www1.nyc.gov/assets/doitt/downloads/pdf/password.pdf

20130 5.1.13

20140 5.1.14 Subsystem service accounts must follow Citywide Password policy.

20150

20160 5.1.15

20170 5.1.16 Note: Vulnerabilityscan SW is provided by DoITT Security Team.

20180 5.1.17 Application scan SW is provided by the DoITT Security Team.

20190 5.1.18

20200 5.1.19

20210 5.1.21

20220 5.1.2220230 5.2. 5.2. Firewall

20240

20250 5.2.1.

20260 5.2.2.

20270 5.2.3.


Not (X) / Not Applicable (NA)Proposal Section

Reference

All Constractor personnel working on an assigned project must have their laptops installed with City approved AntiVirus, Anti - Malware/spyware capabilities with real time updates.

All City of New York data with a data classification of private or confidential may not be stored and/or transmitted across any communication mechanism unless it is protected using approved data encryption technology.

This policy applies to all information classified as private or confidential that may be transmitted by electronic means. Electronic information is defined as data, stored electronically, copied, and/or transmitted concerning the City of New York business, information systems, employees, business partners, or customers. See https://www1.nyc.gov/assets/doitt/downloads/pdf/encryption.pdf

The subsystem shall encrypted NYC Confidential level I and level II data (PII, PHI) and other private classified data at rest and in transmission.

The Subsystem shall backup and maintain the current subsystem HW/SW Configuration state for a minimum of one year to ensure recovery and rollback when necessary.

Applies to network equipment, servers, workstations, databases, etc. Backup are via the enterprise services interfaces

The subsystem shall utilize City provided remote access services and follow City remote access policy. Access to Remote Access servers will be granted within Public safety environment using native AD auth.Access to Remote Access servers from outside of PSAC2 environment will be granted based on need and Public Safety executive approvalAll Subsystem activity with elevated privileges must be logged and reviewed periodically by the Subsystem operational team who runs the system.Subsystem Generic (default) administrative accounts must be disabled - and an alert issued if they are used.

Subsystem administrative account useage shall be restricted to activities requiring administrative priviliges admin activities and not be used for routine activities.

Admin must log into an other account when doing non-admin functions such as email and browsing.

The subystem shall establish separate individual accounts for each person with administrative access. The Subsystem SDE Development environment shall be isolated such that it is not connected to the public safety live production environment.

The Subsystem shall change all default passwords in all HW/SW components before before connecting devices to the public safety operational network.

Service account are those utilized by operating system and HW access to subsystem resources.

The subsystem shall provide two synchronized time sources (i.e., Network Time Protocol– NTP) from which all servers and network equipment retrieve time information on a regular basis so that timestamps in logs are consistent. Subsystem devices utilizing NTP shall ensure that NTP sessions to the subystem NTP servers utilized authentication and encryption.

All subsystem devices must undergo a vulnerability authenticated scan and all High/Medium level vulnerabilities shall be fixed before placing the device into operations.

All applications are recommended to undergoan application scan for vulnerability scan and all High/Med level vulnerabilities shall be fixed before placing the application into operations. Non City owned equipment and software are not allowed to be connected in both production and SDE environment of PSAC2.Personal devices shall not be connected to the operational or SDE environment public safety networks.

All Documents pertaining to PSAC2 project must be labelled and disclosed as per guidelines provided in “Document classification and disclosure Guidelines” All IP addressing on any equipment in PSAC2 must be compliant with PSAC2 IP addressing scheme administered by DoITT.

Subsystem firewalls and the firewall components of BCFs shall be certified to EAL4 or greater. Subsystem Firewall or BCF rules shall be based on specific source/destination host IP addresses and service ports specific to subsytem applications.

Custom appId definitions should be used to deal with non-standard apps.

The subsystem shall only use secure version of protocols through encryption and authentication.All Subsystem Firewall rules shall be based on subnets and ports which shall be documented and approved via an exception process.


Date: 05/06/2023 Time: 22:53:10 53 of 115

RCM ID # Security ID Requirement Text City Comment Proposer Compliance Comments Other Proposer CommentsProposer Compliance:Full (F) / Partial (P) /


Reference

20280 5.2.4.

20290 5.2.5.

20300 5.2.5.

20310 5.2.6.

20320 5.2.7.

20330

20340 5.2.10

20350 5.2.11

20360 5.2.12

20370

2038020390 5.2.14 Subsystem Firewall/BCF rules and design shall be documented in detail.20400 5.3 5.3. DNS

20410 5.3.1.

20420

20430 5.3.2.

20440 5.3.4.

20450 5.3.5.20460 5.4. 5.4. Systems

20470 5.4.1.

20480 5.4.2.

20490 5.4.3.

20500 5.4.4.

20510 5.4.5.

20520 5.4.6.

20530 5.4.7.

20540 5.4.8.

20550 5.4.9.20560 5.4.10 The Subsystem shall test backups periodically, but at least once a quarter.

The subsystem shall not permit Inbound traffic originated from Internet to be terminated directly in City public safety network.

All access from Internet must be performed via approved remote access (sec 5.33)The subsystem shall not permit general purpose outbound Internet access to be provisioned within PSAC2 infrastructure.

The subsystem requests to reach specific Internet targets for Call home or support purposes will require the City approval and only to restricted specific URL(s)/destination(s).All subsytem traffic to security zones exterior to the system must pass through the public safety connect block

to allow for centralized deep packet capture capability and maintain routing consistency.

Subsystem management protocols and administrative connections must be encrypted or isolated into a separate segment from data. (Snmp v3 etc.,) Subsystem interface communication through firewalls/BCF must be logged to the fullest extent.

Subsystem logs must be exported to the City Centralized Log servers and to PSAC2 SEIM tool for advanced correlation. Logs must be stored for at least 1 year.

All subsystem device configurations and data shall be backed up at least every 90 days.

All subsystem backup records shall be retained for a minimum of 1 year.

Subsystem administrative access shall utilize individually assigned role-based administrator accounts.

Subsystem accounts shall be create for, and utilized the principle of least privilege, such that a process, a user, or a program is only able to access the information and resources that are necessary for its legitimate business purpose.

The principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program) must be able to access only the information and resources that are necessary for its legitimate purpose.

Subsystem local admin accounts shall have very strong password and must be used only in “emergency network down” situation with executive approval.

Subsystem DNS sub-domains shall be in compliant with PSAC2 standards with a mutually agreed upon domain name assigned by City ITSecurity.

Subsystem Active Directory domains must be in compliant with PSAC2 standards with mutually agreed upon domain names and structure assigned by City ITSecurity. Subsystem DNS Client resolution must occur via windows servers that are local to the security zone.Subsytem Local DNS servers shall point to Public Safety DNS servers as forwarders for upstream resolution.Subsystem DNS queries shall be logged and exported to PSAC2 SEIM tool in management network directly or indirectly via log aggregation.

The subsystem shall follow citywide naming standards for all hosts (servers, devices, and workstations).Subsytem devices systems shall be installed with the minimum required OS image, software modules and application software.

Subsystem devices must be configured with a City approved golden/hardened OS image that uses security best practices used to harden/lock down the OS and with current patches and OS updates already incorporated. The Subsystem golden image shall be security tested in the Subsystem SDE environment before use in any formal subsystem build.

A City supplied vulnerability manager will be available to perform intrusive testing on the OS image.

The subsystem shall utilize the City provided Patch management functionality. Subsystem devices shall log all secuirty events and send the event logs to the City supplied centralized log collection server. The Subsytsem shall forward aggregated security events to the public safety SEIM Tool in the management network.

Subsytem Devices shall be backed up in accordance with business requirements which shall be documented in the subsystem Disaster Recovery (DR) / COOP Plan / using offsite storage.

Use of the City provided backup functionality will automatically fullfill the offsite portion of this requirement.

The City Backup management functionality shall encrypted backup media (tapes, CD, files, etc).

This is a City requirement if the subsystem uses the City provided backup system.


Date: 05/06/2023 Time: 22:53:10 54 of 115



Reference

20570 5.4.11

20580 5.4.12

20590 5.4.13 Partial duplicate of above.

20600 5.4.14 We will ask that the subsystem use the City EPO system. 20610 5.5. 5.5. Vulnerability Management

20620 5.5.1.20630 5.5.2. Subsystem vulnerability scan data shall be exported to PSAC2 SEIM tool.

20640 5.5.3.

20650 5.5.4.20660 5.5.5. 5.5.5. Workstations/Servers

20670 5.5.5.

20680 5.5.5.

20690

20700 5.5.5.20710 5.6. 5.6. Virtual Infrastructure

20720 5.6.1.

20730 5.6.2.

20740 5.6.3.

20750 5.6.4.

20760 5.6.5.

20770 5.6.6.

20780 5.6.7.

20790 5.6.8.

20800 5.6.9.20810 5.7. 5.7. Network

20820 5.7.1.

20830 5.7.2.

20840 5.7.3.

20850 5.7.4.

20860 5.7.5.

20870 5.7.6.

The Subsystem shall deliver an approved Disaster Recovery plan during the subsytem CDR.

The subsystem shall utilize the City provided centrally managed anti-virus, anti- malware anti spyware, HIPS with zero day protection capability and auto signature updates that are availabile via the public safety management network.

This is a City requirement if the subsystem uses the City provided backup system.

The subsystem shall utilize the City provided Centralized AntiVirus/Malware services that are availabile via the public safety management network.

If separate EPO systems are being this requires prior approval of design by DoITT ITSecurity . Local EPO must installed so that the centralized EPO can be given full read only visibility to ensure compliance.

Automated vulnerability scan shall be run weekly for desktops and daily for servers. Critical vulnerabilities must be fixed in 48 hrs.

The Subsystem vulnerability scanner account must be separate and be restricted to the IP address of scanner engine. The subsystem shall permit only authorized individuals can run vulnerability scan

Subsytsem workstation client devices shall have a Firewall/HIPS SW installed and a rule to block all incoming traffic except to accommodate required business applications.

Subsystem peripheral ports on Workstations/Servers shall be locked down by policy except in cases where there is a specific business requirement to connect a peripheral.

Subsytem Auto run capability shall be disabled for USB, cd/DVDs or removable media in workstations that require peripherals for a required business purpose.

Subsystems shall utilize an automated tools to inventory all administrative privileges on desktop, laptop and servers periodically and make sure that everyone with admin privilege still has a need and is authorized by a senior executive.

The Subsystem, when utilizing virtual infrastucture, shall establish role based, least privilege access control for administration of the Virtual infrastructure.

(Example, a person who needs console access using Vcenter must not have any resource permissions.)

The subsystem shall be administered with separation of duties implemented, so that No single administrator is permitted to perform all the supervisory (highest privilege) functions in the subsystem. Subsystem administrative access to virtual infrastucture shall be allowed only from authorized IP addresses.Subsystem administrative access shall be performed only with a City approved Change Request (CR).Subsystem administrative accesss to virtual infrastucture shall be logged and the logs must be exported to PSAC2 SEIM tool.

Subsystem virtual switches shall export Netflow information containing all traffic flows to the City Netflow system with a maximum flow aggregation setting of 60 seconds.

Subsystem administrative users shall have a named account to perform privileged functions.

Sharing of accounts is not allowed.

The Subsystem design shall Isolate the physical host from the virtual machine such that virtual machine users cannot access host files, firmware, etc. Subsystem Physical Hosts or Virtual Hosts shall not span multiple security zones.

Subsystem network devices shall be locked down to prevent all services except “SSH” to be listening on the device.The subsystem shall keep unused network switch ports in an administrative shutdown state.Subsytem vulnerability scanning shall be performed on all devices on a periodic basis.Subsystem software/firmware security vulnerabilities in code must be fixed in priority order based on the criticality and business impact. Subsystem devices shall be configured to send system log events to the City's centralized log servers. The Subsystem shall aggregate security events shall be forwarded to Public Safety SEIM Tool.


Date: 05/06/2023 Time: 22:53:10 55 of 115



Reference

20880 5.7.7.

20890 5.7.8.

20900 5.7.9.

20910 5.7.11

20920 5.7.12

20930 5.7.13

20940 5.7.14

20950 5.7.15

20960 5.7.16

20970 5.7.21 Connect blocks include approved firewalls and WAN routers.

20980 5.7.2220990 5.8. 5.8. Wireless 21000 5.9. 5.9. Applications

21010 5.9.4.21020 5.10. 5.10. Security Awareness

21030 5.10.1

21040 5.10.2

21050 5.10.3

21060 5.10.4

21070 5.10.5

21080 5.10.6

21090 5.10.7

21100 5.10.8

21110 5.10.9

21120 5.10.1

21130 5.10.121140 5.11. 5.11. Asset Management

21150 5.11.1

Subsystem management protocols and administrative connections shall be encrypted or isolated into separate segment/vlan from data traffic. Subsystem initial and subsequent versions of device configurations must be backed up every 90 days and kept for at least 1 year.

Subsystem device administrative access shall be restricted to a specific set of redundant Remote Access servers that are part of City's Management Network.The subsytem shall utilize role based, least privilege access control for administrative access.

Subsystem administrators shall be provided with thier own account to perform privileged functions.

Sharing of accounts is not allowed.Subsystem account access and audit logs from Access control systems must be forwarded to City Public Safety SEIM tool for correlation.Subsystem shall provide functionality for administrative accounts to be centrally managed.Subsystem Operational procedures due at Critical Design Review shall be developed to routinely review access permissions.Subsystem default local administrative accounts shall be changed prior to installing devices in production.Subsytem connections to 3rd external parties or to the Internet are must transverse the approved City connect Block.Subsystem Network Topology and interconnections must be documented in detail and are due at the subsytem Critical Design Review.

During the subsystem build phase engineers/techs are required to uninstall or remove from the system sample scripts, libraries, components, compilers, or any other unnecessary code that is not being used by an application.

Subsystem IT Staff shall undergo a yearly Administrator Security Awareness trainingSubsystem Call center and non IT Staff must undergo a quarterly User Security Awareness trainingSubsystem Security Awareness Training shall be included in job responsibilities and scheduled as part of normal operational procedure.Subsystem Security Awareness Training shall include Incident response roles and responsibilities. Subsystem Security Awareness Training shall include media Protection guidelines.

Subsystem Security Awareness Training shall include Visitor Control, Physical access to spaces policies and procedures like challenge strangers, report unusual activity etc..Subsystem Security Awareness Training shall include Social engineering awareness and proper handling of confidential information.Subsystem Security Awareness Training shall include Password usage and management – creation, change and protection guidelines .

Subsystem Security Awareness Training shall include:- Protection from viruses, worms, Trojan horses and other malicious code,- unknown email attachments , - Internet Usage , - SPAM, - Laptop , - Handheld device security ,- Disallow ability of personal owned equipment/software, - Desktop security, - access control, - individual accountability

Subsystem Security Awareness Training for information support personnel shall include: n- Data backup and storage, - system patching, - access control measures and network infrastructure protection.Subsytsem Security Training Records shall be documented and kept current by a designated Information Security Officer..

Subsystems shall maintain software and hardware inventory of all managed devices and systems.


Date: 05/06/2023 Time: 22:53:10 56 of 115



Reference

21160 5.11.221170 5.12. Capacity Planning

21180 5.12.1

21190 5.12.2

21200 5.12.2

21210 5.12.2

21220 5.12.321230 5.13. 5.13. Change Control

21240 5.13.121250 5.14. 5.14. Disk Maintenance

21260 5.14.121270 5.15. Documentation

21280 5.15.121290 5.15.2 The subsystem shall document the subsytem Security Plan for CDR.

21300 5.15.321310 5.16. 5.16. System BCP / DR

21320 5.16.121330 5.17. 5.17. Security Incident Response

21340 3.17.1

21350 3.17.221360 5.18. 5.18. Security Incident

21370 5.18.1

21380 5.18.2

21390 5.18.3

21400 5.18.4

21410 5.18.5

21420 5.18.6

21430 5.18.721440 5.19. 5.19. Logging

21450 5.19.1

Subsystem operators must fill out an “Asset Classification worksheet” to identify each system and its criticality and classification of data handled by the system to assist with Incident response planning.

Subsystem resource and usage variables and thresholds that need to be set and monitored shall be identified by the product vendor or the implementer by the Critical Design Review. Subsystem devices shall be monitored for resource utilization.

Subsystem devices shall shall alert the NOC if utilization is above a predefined threshold.Subsystem shall track and create devices level historical data for capacity planning.The Subsystem shall performed Load Testing before cutover into operations.

The subsystem configuration, HW, and SW changes shall be subject to “City Change Control process” which will be established in compliance with Citywide Change Policy.

Subsystem disk maintenance must be performed in accordance with “Citywide Data destruction policy”

The Subsystem design shall be fully documented in detail at CDR, updated to the as-bult configuration during the build phase, and kept up to date during the operational phase of the project.

Subsystem Documentation shall be labelling with the proper city classification and shall follow “Document Classification and disclosure Guidelines”

The subsystem Business continuity planning, COOP and DR plans shall be documented and approved by CDR.

Subsytem level, Incident Response Plan incorporating classification of incidents, response to security incidents, sharing of incidents with PSAC2 Security Operations Center and mitigation shall be documented.

The Incident Response plan shall document responsibilities and procedures to handle information security events and weaknesses effectively once they have been reported.

5.18.1. There shall be an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery. The Subsystem Vendor shall employ automated mechanisms to support the incident handling process.

The Subsystem shall collect Incident-related information from a variety of sources including, but not limited to, audit monitoring, network monitoring, physical access.

The subsystem vendor shall incorporate the lessons learned from ongoing incident handling activities into the incident response procedures and implement the new procedures accordingly.

Where a follow-up action against a person or agency after an information security incident involves legal action (either civil or criminal), evidence shall be collected, retained, and presented to conform to the rules for evidence laid down in the relevant jurisdiction(s).

The Subsystem shall tracked and report information system security incidents in the format specified and agree to in the CDR and on an ongoing basisThe City Information Security Officer ( Director of Security) shall maintain completed security incident reporting forms

Subsytem servers, network, and security infrastructure components shall be enabled for audit logs.


Date: 05/06/2023 Time: 22:53:10 57 of 115



Reference

21460 5.19.2

21470 5.19.3

21480 5.19.421490 5.19.5 Subsystem Audit review/analysis shall be conducted at least once a week.

21500 5.19.6

21510 5.19.721520 21530 5.20. 5.20. Logging Fields

21540 5.20.121550 5.21. 5.21. Time Stamps

21560 5.21.1

21570 5.21.2

21580 5.21.321590 5.22. 5.22. CJIS Protection of Audit Information

21600 5.22.1

21610 5.22.221620 5.23. 5.23.CJIS Audit Record Retention 21630 5.23.1 The Subsystem shall retain audit records for at least one (1) year.

The Subsystem shall log the following events: o Successful and unsuccessful system log-on attempts. o Successful and unsuccessful attempts to use: § access permission on a user account, file, directory or other system resource § create permission on a user account, file, directory or other system resource § write permission on a user account, file, directory or other system resource § delete permission on a user account, file, directory or other system resource § Change permission on a user account, file, directory or other system resource. o Successful and unsuccessful attempts to change account passwords. o Successful and unsuccessful actions by privileged accounts. o Successful and unsuccessful attempts for users to: § access the audit log file; § modify the audit log file; § destroy the audit log file.

The subsystem shall provide alerts to City Security Operations Center (SOC) SEIM Tool in the event of an audit processing failure, to minimally include:o Audit processing failures include, for example: software/hardware errors, o failures in the audit capturing mechanisms, and o audit storage capacity being reached or exceeded.

The City Information Security Officer will assign resources to review/analyze information system audit records for indications of inappropriate or unusual activity, investigate suspicious activity or suspected violations, to report findings to appropriate officials, and to take necessary actions.

The Subsystem operational personnel shall increase the level of audit monitoring and analysis activity within the information system whenever there is an indication of increased risk to agency operations, agency assets, or individuals based on law enforcement information, intelligence information, or other credible sources of information.

The Subsystem shall forward audit logs to the Public Safety SEIM Tool in mthe management network zone either directly or via a log aggregation device. .

The Subsystem shall provide the following content with every audited (log) event: o Date and time of the event. o The component of the information system (e.g., software component, hardware component) where the event occurred. o Type of event. o User/subject identity. o Outcome (success or failure) of the event.

The Subsystem information systems shall provide time stamps for use in audit record generation. The Subsytem time stamps shall include in the audit records the date and time values generated by the Subsystem internal system clocks. Subsystem clocks shall be synchronized to NTP clock provided in the network.

Subsystem information systems shall protect audit information and audit tools from modification, deletion and unauthorized access.

5.22.2. Subsystem personnel shall Before exchanging Criminal Justis Information (CJI), agencies put formal agreements in place that specify security controls, including information exchange agreements outlining the roles, responsibilities, and data ownership between agencies and any external parties.


Date: 05/06/2023 Time: 22:53:10 58 of 115



Reference

21640 5.23.221650 5.24. 5.24. CJIS - Logging NCIC and III Transactions 21660 5.25. 5.25. Account management

21670 5.25.1

21680 5.25.2

21690 5.25.3

21700 5.25.4

21710 5.25.5

21720 5.25.621730 5.26. 5.26.Access Enforcement

21740 5.26.1

21750 5.26.2

2176021770 5.27. 5.27. Least Privilege

21780 5.27.1

21790

21800

21810 5.27.2

21820 5.27.321830 5.28. 5.28. System Access Control

21840 5.28.1

Subsystem personnel, once the minimum retention time period has passed, shall continue to retain audit records until it is determined that they are no longer needed for administrative, legal, audit, or other operational purposes, which shall include: o retention and availability of audit records relative to Freedom of Information Act (FOIA) requests, o subpoena, and o law enforcement actions.

The Subsystem administrator or a City Designee shall manage information system accounts, including establishing, activating, modifying, reviewing, disabling, and removing accounts. The Subsystem administrator or a City Designee shall validate information system accounts at least annually and shall document the validation process.A City Designee shall specify Subsystem account types (i.e., individual, group, and system), establishment of subsystem conditions for group membership, and the assignment of associated subsystem authorizations is determined.A City Designee shall identify Subsystem authorized users of the information systems and specify access rights/privileges.

A City Designee shall grant access to the information system based on: o Valid need-to-know/need-to-share that is determined by assigned official duties. o Satisfaction of all personnel security criteria.

A City Designee or system owner responsible for account creation shall be notified when: o A user’s information system usage or need-to-know or need-to share changes. o A user is terminated or transferred or associated accounts are removed, disabled, or otherwise secured.

The Subsystem shall enforce access and privilege rights to the subsystem and Its contained information.

The Subsystem shall restrict access to privileged functions (deployed in hardware, software, and firmware) and security relevant information to explicitly authorized personnel, for example, security administrators, system and network administrators, and other privileged users with access to system control, monitoring, or administration functions (e.g., system administrators, information system security officers, maintainers, system programmers).

Subsystem access control policies, to include : a) identity-based policies, b) role-based policies, c) rule-based policies and d) associated access enforcement mechanisms to minimally include: - access control lists, - access control matrices, - cryptographyshall be employed to control access between users, or processes acting on behalf of users, and objects to incluce devices, files, records, processes, programs, domains.

A City approved Subsystem administrator or a City Designee shall approve individual access privileges.The Subsystem shall enforce physical and logical access restrictions associated with changes to the information system.The Subsystem shall generate, retain Log records reflecting physical and logical access restrictions changes.

The Subsytem shall enforce the most restrictive set of rights/privileges or access needed based on specific duties, operations, or information systems as necessary to mitigate risk.

Subsystem logs of access privilege changes shall be maintained for a minimum of one year or at least equal to the agency’s record retention policy – whichever is greater.

The Subsytem shall prevent multiple concurrent active sessions associatd with one user identification/Account. Agencies shall document the parameters of the operational business needs if any, for multiple concurrent active sessions.


Date: 05/06/2023 Time: 22:53:11 59 of 115



Reference

21850 5.28.2

21860 5.28.321870 5.29. 5.29.Access Control Mechanisms

21880 5.29.1

21890 5.29.2

21900 5.29.3

21910 5.29.4 to provide increased information security for the agency. 21920 5.30. 5.30. Unsuccessful Login Attempts

21930 5.30.1

21940 5.30.2

2195021960 5.31. 5.31. System Use Notification

21970 5.31.1

21980 5.31.2

21990 5.31.322000 5.32. 5.32. Session Lock

The Subsystem shall ensure that only authorized personnel can add, change, or remove component devices, dial-up connections, remove programs, or alter programs.

The Subsystem shall control access to Criminal Justice Information based on one or more of the following: o Account privileges linked to Job/role assignment or function of the user seeking access.o Physical location. o Network addresses (e.g., users from sites within a given agency may be permitted greater access than those from outside). o Time-of-day and day-of-week/month restrictions.

The Subsystem shall utilize ACLs to authorized and grant user or processes permission to access, read, write, modify, change system objects (system resources) based on the type of access prilivages assigned to the associated account.

The Subsystem shall restrict access to specific functions by never allowing users to request information, functions, or other resources for which they do not have sufficient access privaleges, which shall minimally include: a) menus, b) database views, and c) network devices.

The subsystems utilizing encryption shall provide strong key management by the deployment or use of a City key management server and providing configuration backups.

Encrypted information can only be decrypted, and therefore read, by those possessing the appropriate cryptographic key.

The subsystem shall employ access enforcement mechanisms at the application level.

The Subsystem shall enforce a limit of no more than 5 consecutive invalid access attempts by a user upon which the system shall automatically lock the account/node for a 10 minute time period unless released by an administrator.

The Subsystem shall automatically lock administrative accounts when 5 consecutive invalid access attempts have occurred.

Subsystem administrator accounts that have been locked out due to failed login attempts shall require a security investigation to performed before the account can be reenabled for use.

5.31.1. The information system shall display an approved system use notification message, before granting access, informing potential users of various usages and monitoring rules. The system use notification message shall, at a minimum, provide the following information: |-----------------------------------------------------------------| | This system is for the use of authorized users only. | | Individuals using this computer system without authority, or in | | excess of their authority, are subject to having all of their | | activities on this system monitored and recorded by system | | personnel. | | In the course of monitoring individuals improperly using this | | system, or in the course of system maintenance, the activities | | of authorized users may also be monitored. | | Anyone using this system expressly consents to such monitoring | | and is advised that if such monitoring reveals possible | | evidence of criminal activity, system personnel may provide the | | evidence of such monitoring to law enforcement officials. ||-----------------------------------------------------------------|

Subsytem privacy and security policies shall be consistent with a) applicable laws, b) executive orders, c) directives, d) policies, e) regulations, f) standards, and g) guidance.

Subsystem use notification messages shall be implemented in the form of warning banners displayed when individuals log in to the information system.


Date: 05/06/2023 Time: 22:53:11 60 of 115



Reference

22010 5.32.1 prevent further access to the system by

22020 5.32.222030 5.33. 5.33. Remote Access

22040 5.33.4 Not a NEXTGEN requirement22050 5.34. 5.34. Personally Owned Information Systems

2206022070 5.35. 5.35. CJIS Identification Policy and Procedures

22080 5.35.1

22090 5.35.2

22100 5.35.3

22110 5.35.4

22120 5.35.5

22130 5.35.6

22140 5.35.722150 5.36. 5.36. CJIS Authentication Policy and Procedures

22160 5.36.1

22170 5.36.222180 5.36.3 5.36.3. Password

2219022200 5.36.4 5.36.4. Personal Identification Number(PIN)

22210

22220 5.36.522230 5.37. 5.37. Access Restrictions for Changes

22240 5.37.122250 5.37.2 5.37.2. Least Functionality

2226022270 5.37.3 5.37.3. Network Diagram

The Subsystem shall a) initiating a session lock after a maximum of 30 minutes of session inactivity, and b) the session lock shall remains in effect until the user re-establishes access using appropriate identification and authentication procedures. Subsystem users shall directly initiate session lock mechanisms to prevent inadvertent viewing when a device is unattended.

A session lock is not a substitute for logging out of the information system.

The Subsystem shall permit remote access for privileged functions only for compelling operational needs but shall document the rationale for such access in the security plan for the information system.

A personally owned information systems, equipment, or devices shall not be authorized for attachment, access, or processing on any Public Saftey information network.

Each person who is authorized to store, process, and/or transmit CJI shall be uniquely identified.

A unique identification shall also be required for all persons who administer and maintain the system(s) that access CJI or networks leveraged for CJI transit. The unique identification can take the form of a full name, badge number, serial number, or other unique alphanumeric identifier.

Subsytem personnel shall be City approved and are required to identify themselves uniquely through the City Badging process which also include personnel vetting before the user is allowed to perform any actions on the Subsystem.Subsystem Management shall ensure that all user IDs belong to City authorized users with valid and active City Badges.Subsytem identification and account data shall be kept current by adding new users and disabling and/or deleting former users.

Subsytem audit trails shall be used to identify the requesting agency if there is a reason to inquire into the details surrounding why Subsystem personnel ran an inquiry on a subject.

Subsystem personnel's identity shall be authenticated and approved by the City.Definition: Authenticators are (the something you know, something you are, or something you have) part of the identification and authentication process.

The subsystem shall follow the secure password attributes, below, to authenticate an individual’s unique ID. Passwords shall: • Be a minimum length of eight (8) characters on all systems. • Not be a dictionary word or proper name. • Not be the same as the Userid. • Expire within a maximum of 90 calendar days. • Not be identical to the previous ten (10) passwords. • Not be transmitted in the clear outside the secure location. • Not be displayed when entered.

Subsystem Personal Identificaiton Numbers (PIN) shall:• Be a minimum of six (6) digits • Have no repeating digits (i.e., 112233) • Have no sequential patterns (i.e., 123456) • Not be the same as the Userid. • Expire within a maximum of 365 calendar days. • Not be identical to the previous three (3) PINs. • Not be transmitted in the clear outside the secure location. • Not be displayed when entered. The subsystem shall enforce Multi factor (at least 2 factor ) authenticaion for any non-local access of Public Safety applications

5.37.1. Only qualified and authorized individuals are allowed to initiate changes, including upgrades and modifications.

The Subsystem shall configure the application, service, or information system to provide only essential capabilities and shall specifically prohibit and/or restrict the use of specified functions, ports, protocols, and/or services.


Date: 05/06/2023 Time: 22:53:11 61 of 115



Reference

22280 includes ESInet

2229022300 5.37.4 5.37.4. Security of Configuration Documentation

2231022320 5.38. 5.38. Media Storage and Access

22330 5.38.1

22340 5.38.222350 5.38.3 5.38.3. Digital Media during Transport

2236022370 5.38.4 5.38.4. Electronic Media Sanitization and Disposal

22380 5.38.4

22390 5.38.4

22400 5.38.4

22410 5.38.422420 5.38.5 5.38.5. Disposal of Physical Media

22430 5.38.522440 5.39. 5.39. Security Perimeter 22450 5.39.2 5.39.2. Physical Access Authorizations

2246022470 5.39.3 5.39.3. Physical Access Control

2248022490 5.39.4 5.39.4. Access Control for Transmission Medium

2250022510 5.39.5 5.39.5. Access Control for Display Medium

22520 5.39.5

22530 5.39.522540 5.39.6 5.39.6. Monitoring Physical Access

2255022560 5.39.7 5.39.7. Visitor Control

22570 5.39.7

22580 5.39.722590 5.39.8 5.39.8. Delivery and Removal

22600

The subsytem shall ensure that a complete topological drawing depicting the interconnectivity of the Subsystem, to the criminal justice information systems and services is created and maintained in a current status.

The Subsystem shall provide network topological drawing by CDR toi include the following: • All communications paths, circuits, and other components used for the interconnection, beginning with the agency-owned system(s) and traversing through all interconnected systems to the agency end-point. • The logical location of all components (e.g., firewalls, routers, switches, hubs, servers, encryption devices, and computer workstations). Individual workstations (clients) do not have to be shown; the number of clients is sufficient. • Labelling as per Document labelling guidelines. • The agency name and date (day, month, and year) drawing was created or updated.

Subsystem personnel shall protect the system documentation from unauthorized access.

The Subsytem shall securely store electronic and physical media within physically secure locations or controlled areas.The Subsystem shall restrict access of electronic and physical media to authorized individuals.

Subsystem Digital and Tape Media shall be encrypted while transporting information outside of the physical boundary of secure areas.

Subsytem Personnel shall sanitize by overwriting data at least three times or degauss electronic media prior to disposal or release for reuse by unauthorized individuals. Subsystem inoperable/unwanted electronic media shall be destroyed (cut up, shredded, etc.). Subsystem personnel shall maintain written documentation of the steps taken to sanitize or destroy electronic media. Subsystem personnel shall ensure the sanitization or destruction is witnessed or carried out by authorized personnel.

Subsystem personnel shall ensure the disposal or destruction is witnessed or carried out by authorized personnel.

The Subsystem and City personnel shall develop and keep current a list of personnel with authorized access to the physically secure location (except for those areas within the permanent facility officially designated as publicly accessible) or shall issue credentials to authorized personnel.

The City shall control all physical access points (except for those areas within the facility officially designated as publicly accessible) and shall verify individual access authorizations before granting access.

The Subsystem and City personnel shall control physical access to information system distribution and transmission lines within the physically secure location.

Subsystem and City personnel shall control physical access to information subsystem devices.

The Subsystem and City shall position information system devices in such a way as to prevent unauthorized individuals from accessing and viewing sensitive data.

The City shall monitor physical access to the information system to detect and respond to physical security incidents.

The City shall control physical access by authenticating visitors before authorizing escorted access to the physically secure location (except for those areas designated as publicly accessible). Subsystem personnel shall escort visitors at all times and monitor visitor activity.

The City shall authorize and control information system-related items entering and exiting the physically secure location.


Date: 05/06/2023 Time: 22:53:11 62 of 115



Reference

22610 5.40. 5.40. Boundary Protection 22620 5.40.1 The Subsytem shall control access to connected networks processing CJI.

22630 5.40.2

22640 5.40.3

22650 5.40.4

22660 5.40.5

22670 5.40.622680 5.41. 5.41. Encryption

22690 5.41.1

22700 5.41.2

22710 5.41.3

22720 5.41.4

22730 5.41.4

22740

22750 5.41.522760 5.42. 5.42. Intrusion Detection Tools and Techniques

22770

22780 5.42.1

22790 5.42.2

22800 5.42.322810 5.43. 5.43. Patch Management

22820 5.43.1

22830 5.43.2

22840 5.43.3

22850 5.43.422860 5.44. 5.44. Malicious Code Protection

The Subsytem shall monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.

The Subsytem shall ensure any connections to the Internet, other external networks, or information systems occur through controlled interfaces (e.g. proxies, gateways, routers, firewalls, encrypted tunnels). The Subsytem shall employ tools and techniques to monitor network events, detect attacks, and provide identification of unauthorized use.

The Subsytem shall ensure that physical operational failure of the boundary protection mechanisms does not result in any unauthorized release of information outside of the information system boundary and that devices shall “fail closed” vs. “fail open”. The Subsytem shall ensure that No publicly accessible systems shall be hosted in boundary of public safety network.

Subsystems utilizing encryption shall be a secured with an encryption key of length at least 256 bits.

The subsystem shall ensure that when Criminal Justice Information is transmitted outside the boundary of the physically secure location, the data shall be immediately protected via cryptographic encryption mechanisms.

The Subsytem shall protect CJI data at rest (i.e. stored electronically) via cryptographic encryption mechanisms when the CJI information is located outside the boundary of the physically secure site.

Subsystem encryption passphrase shall meet the following requirements: * Be at least 10 characters * Not be a dictionary word. * Include at least one (1) upper case letter, one (1) lower case letter, one (1) number, and one (1) special character. * Be changed when previously authorized personnel no longer require access. 5.41.4.5. Multiple files maintained in the same unencrypted folder shall have separate and distinct passphrases. A single passphrase may be used to encrypt an entire folder or disk containing multiple filesThe Subsytem encryption cryptographic module used shall be certified to meet FIPS 140-2 standards.

The Subsystem shall implement network-based and/or host-based intrusion detection tools. The Subsytem and/or the City SEIM shall Monitor inbound and outbound communications for unusual or unauthorized activities.

The Subsystem shall send individual intrusion detection logs to a central SEIM and logging facility where correlation and analysis will be accomplished as a system wide intrusion detection effort.

The Subsytem and/or the City SEIM shall employ automated tools to support near-real-time analysis of events in support of detecting system-level attacks.

The Subsystem support personnel shall identify applications, services, and information systems containing software or components affected by recently announced software flaws and potential vulnerabilities resulting from those flaws.

The Subsystem support personnel or the software developer/vendor, in the case of software developed and maintained by a vendor/contractor, shall develop and implement a local policy that ensures prompt installation of newly released security relevant patches, service packs and hot fixes. Local policies should include such items as:

Subsystem support personnel shall test appropriate patches and updates in the SDE before operational installation to include: 1) The ability to rollback patches, updates, etc. when necessary2) the distribution of automatic updates without individual user intervention. 3) Centralized patch management capabilities

Subsystem support personnel shall expeditiously create, test and implement patches required to address issues discovered during security assessments, continuous monitoring or incident response activities. .


Date: 05/06/2023 Time: 22:53:11 63 of 115



Reference

22870 5.44.1

22880 5.44.2

22890 5.44.322900 5.45. 5.45. Spam and Spyware Protection

22910 5.45.1

22920 5.45.2

22930 5.45.322940 5.46. 5.46. Security Alerts and Advisories

22950 5.46.122960 5.47. 5.47. CJIS Personnel Security Policy and Procedures

22970 5.47.1

22980 5.47.1

22990 5.47.1

23000 5.47.123010 5.47.2 5.47.2. Personnel Screening for Contractors and Vendors

23020 5.47.2

23030 5.47.2

23040 5.47.2

23050 5.47.223060 5.47.3 5.47.3. Personnel Termination

2307023080 5.47.4 5.47.4. Personnel Transfer

2309023100 5.47.5 5.47.5. Personnel Sanctions

23110

Subsystems not connected to the Internet shall implement local procedures to ensure malicious code protection is kept current (i.e. most recent update available).

Subsytems shall employ virus protection mechanisms to detect and eradicate malicious code (e.g., viruses, worms, Trojan horses) at critical points throughout the network and on all workstations, servers and mobile computing devices on the network.

The Subsystem shall ensure malicious code protection is enabled on all of the aforementioned critical points and information systems and resident scanning is employed.

The Subsystem shall employ spam protection mechanisms at critical information system entry points (e.g. firewalls, electronic mail servers, remote-access servers). The Subsystem shall employ spyware protection at workstations, servers and mobile computing devices on the network.

The Subsystem shall detect and take appropriate action on unsolicited messages and spyware/adware via implemented spam and spyware protection mechanisms.

Subsystem personnel shall seekout and receive information system security alerts/advisories applicable to their subsystem devices and applications on a regular basis, and shall:1) Issue alerts/advisories to appropriate personnel. 2) Document the types of actions to be taken in response to security alerts/advisories. 3) Take appropriate actions in response. 4) Employ automated mechanisms to make security alert and advisory information available throughout the agency as appropriate.

The City shall verify identification, a state of residency and national fingerprint-based record checks shall be conducted within 30 days of assignment for all personnel who have direct access to CJI and those who have direct responsibility to configure and maintain computer systems and networks with direct access to CJI.

City requests for access shall be made as specified by CJA Security Officer (CSO ). The CSO, or their designee, is authorized to approve access to CJI. All CSO designees shall be from an authorized criminal justice agency.

Support personnel, contractors, and custodial workers with access to physically secure locations or controlled areas (during CJI processing) shall be subject to a state and national fingerprintbased record check unless these individuals are escorted by authorized personnel at all times. It is recommended individual background re-investigations be conducted every five years unless Rap Back is implemented.

Prior to granting access to CJI, the CGA on whose behalf the Contractor is retained shall verify identification via a state of residency and national fingerprint-based record check. However, if the person resides in a different state than that of the assigned agency, the agency shall conduct state (of the agency) and national fingerprint-based record checks and execute a NLETS CHRI IQ/FQ/AQ query using purpose code C, E, or J depending on the circumstances. A Contractor employee found to have a criminal record shall be be disqualifiedApplicants shall also be disqualified on the basis of confirmations that arrest warrants are outstanding for such applicants.

The CGA shall maintain a list of personnel who have been authorized access to CJI and shall, upon request, provide a current copy of the access list to the CSO.

The Subsystem management upon termination of individual employment, shall immediately terminate access to CJI.

Subsystem Management shall review CJI access authorizations when personnel are reassigned or transferred to other positions and initiate appropriate actions such as closing and establishing accounts and changing system access authorizations.

Subsystem Management shall employ a formal sanctions process for personnel failing to comply with established information security policies and procedures.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 64 of 115

RCM ID # Section Subject Requirement Text Proposer Compliance Comments Proposal Section Reference Other Proposer Comments

30000 NENA-STA-10.2 8.1 Additional Data Additional Data

30010 NENA-STA-10.2 5.11.0 Additional Data ADR30020 NENA-STA-10.2 8.1 Additional Data By Reference Additional Data received by reference shall be passed by reference to any other entities.

30030 NENA-STA-10.2 5.11.0 Additional Data Call-Info

30040 3.2 Additional Data Dereference GEN 1000-0100

30050 NENA-STA-10.2 5.11.0 Additional Data Dereference

30060 NENA-STA-10.2 8.1 Additional Data Multiple Sources

30070 NENA-STA-10.2 5.11.0 Additional Data PIDF-LO

30080 NENA-STA-10.2 8.1 Additional Data Privacy

30090 NENA-STA-10.2 5.11.0 Additional Data Servers

30100 NENA-STA-10.2 5.11.0 Additional Data Telematics

30110 NENA-STA-10.2 5.11.0 Additional Data Third Parties

30120 NENA-STA-10.2 5.11.0 Additional Data TLS

30130 NENA-STA-10.2 5.11.0 Additional Data XML

30140 3.2 Discovery GEN 2000-0100 Any FE must be able to discover other FEs within an Agency.

30150 NENA-STA-10.2 5.16.0 Agency Locator ALRS



Standards Document

Functional Element

ExternalRequirement

Num (if supplied)



The device, originating network or caller could operate an ADR containing the data itself, or it could supply the data to a 3rd party who operates the ADR, or it can include the data by value in the call. Any intermediary (service provider) handling the call shall provide a ProviderInfo block. Per RFC 7852, where no originating network or service provider is in the path of the call, the calling device shall provide Additional Call Data. Does the Responder comply with the above scenarios?

All origination networks and service providers are expected to provide at least this minimum set of information which shall be populated in an ADR when passed by reference, or provided in the body of the INVITE message when passed by value. Access networks are expected to provide the same minimum set of information. The ADR is queried with the URI obtained from the Call-Info header field with a purpose starting with “EmergencyCallData.”, or in a <provided-by> of a PIDF-LO and returns the Additional Data structure. It is important that ALL origination networks and service providers handling the call add a Call-Info header field, where the origination network or service provider can be reasonably expected to determine they are handling an emergency call. The transaction to dereference the Additional Data URI shall be protected with TLS. The dereferencing entity, which may be an ESRP, LPG, PSAP or responding agency uses its credentials (traceable to the PCA for NG9-1-1 entities) to dereference the Additional Data URI. The originating network or service provider can use any credential, as long as the domain listed in the URI is the domain of the SubjectAltName in the credential.

An emergency call shall have at least two Call-Info header fields each with a URI that resolves to an Additional Data structure (RFC 7852) (the required block types are EmergencyCallData.ProviderInfo and EmergencyCallData.ServiceInfo). The URI may resolve to a Content Identifier that references the body of the INVITE message where the Additional Data may be found, or it may lead to an external database.

NENA/APCO-REQ-001.1.1

Any FE that needs to dereference Additional Data URIs shall provide an Additional Data dereference interface as described in the Data Associated with a call, caller, location or PSAP sections of NENA-STA-010.2.

ADRs may not have the data themselves, but may know where the data can be found. The response to a dereference request can be redirected to another ADR with an HTTPS 303 response (Iterative Refer). Does the ADR support Iterative Refer?

Ultimately, a given call may have multiple sources of Additional Data from one or more ADRs. If conflicting information is discovered, the information identified as most recently updated by the data source shall take precedence over information determined to be older.

Additionally, the <provided-by> element of a PIDF-LO may contain an Additional Data URI or the content of a set of Additional Data blocks. The external database that dereferences external Additional Data URIs is an Additional Data Repository (ADR). There is a minimum amount of information listed as Mandatory for EmergencyCallData.ProviderInfo and EmergencyCallData.ServiceInfo that, when combined with information from the PIDF-LO and the SIP INVITE or MESSAGE, is minimally equivalent to the information currently provided by all origination networks in the ALI. Does the Responder's solution provide a method of processing the above statements in their functional elements?

To protect the privacy of the caller, the amount of information returned by the ADR query may vary depending on the TLS session credentials established by the entity executing the query. PSAPs will have credentials traceable to the PCA that shall be accepted by the data provider.ADR servers are not required to be able to serve a query more than 5 minutes after an emergency call is terminated. Does the Responder have a mechanism in place to enforce this rule?

Devices such as those within telematics equipped vehicles and medical monitoring devices that can place emergency calls could have the capability to respond to an ADR query, or could publish data to an external ADR that would respond to dereference requests. A service provider (such as a telematics service provider) may provide the ADR instead of the device. Other devices may also provide an ADR for use in an emergency call. Alternatively, the data may be provided by value by the device, originating network or service provider.

The ADR could be provided by the access network, origination network or service provider. For service providers, access and origination networks that only provide the minimal data called for in RFC 7852, the ADR could be provided by a third party. For Additional Data provided by the calling entity itself, the ADR could be provided by it, or a third party.

Interaction with the ADR shall be protected by TLS. The ADR shall accept certificates traceable to the PCA. ESInet entities may only accept certificates for the ADR signed by a CA recognized by common web browsers.

The Additional Data Repository (ADR) is a database that holds Additional Data. URIs pointing to the ADR may be passed in a call, in an EIDD or by other mechanisms. The ADR shall return an XML data structure in response to an HTTPS GET of the URI.


Functional Elements

An Agency Locator record is identified by a URI whose domain is an ALRS. The URI can be presented to an ALRS that shall respond with the record. The ECRF returns the URI.The Agency Locator shall provide an Agency Locator Record Store (ALRS) which holds the actual data record for the agency.

The ALRS shall use a simple HTTPS GET with the URI. The querier shall use his credentials to create the TLS connection, and the credential and its corresponding agency type and role may influence what information is returned.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 65 of 115

RCM ID # Section Subject Requirement Text Proposer Compliance Comments Proposal Section Reference Other Proposer CommentsStandards Document

Functional Element

ExternalRequirement

Num (if supplied)







30220 3.4.2 Agency Locator EIDD

30230 NENA-STA-10.2 5.16.0 Agency Locator ElementState

30240 NENA-STA-10.2 5.16.0 Agency Locator Search



30270 NENA-STA-10.2 5.16.0 Agency Locator ServiceState

30280 NENA-STA-10.2 5.01.1 Bad Actor The BCF shall implement the “Bad Actor” mechanism as described in NENA-STA-10.2 Section 5.1.2.

30290 NENA-STA-10.2 5.01.1 CDR

30300 NENA-STA-10.2 5.01.1 Encryption

30310 3.5.3 ESInet NET 0100-0100

30320 NENA-STA-10.2 5.01.1 ESRP The BCF shall facilitate forwarding of an emergency call/session to an ESRP (and only an ESRP).

30330 NENA-STA-10.2 5.01.1 Firewall The SBC component of the BCF shall protect against SIP specific and general DDoS attacks.

30340 NENA-STA-10.2 5.01.2 Identifiers

30350 NENA-STA-10.2 5.01.1 Priority marking

30360 3.5.3 PSAP NET 0100-0100 A BCF shall exist between the ESInet and the PSAP.

30370 3.5.3 PSAP NET 0100-0100

30380 NENA-STA-10.2 5.01.1 Resource-Priority The BCF shall add the Resource-Priority header if not already included.

30390 NENA-STA-10.2 5.01.2 ROHC BCFs shall support Robust Header Compression (ROHC) as defined in RFC 3843.

30400 NENA-STA-10.2 5.01.1 RTT

30410 NENA-STA-10.2 5.01.1 SBC

30420 NENA-STA-10.2 5.01.1 SIP

30430 NENA-STA-10.2 5.01.2 SIP The BCF shall support SIP interfaces upstream and downstream per NENA-STA-10.2 Section 4.1.

30440 NENA-STA-10.2 5.01.2 SIPREC

30450 NENA-STA-10.2 5.01.2.1

30460 NENA-STA-10.2 5.01.2 Web Service


The ALRS may be operated by the agency itself, the ESInet operator may operate an ALRS for the entire ESInet, or any other party may operate an ALRS. Every agency shall have a record stored in at least one ALRS, with the URI for that record stored in the ECRF that serves the agency.Every agency shall have a record stored in at least one ALRS, with the URI for that record stored in the ECRF that serves the agency.

A search for an agency where the search key is a name is provided by the Agency Locator Search Service. The Service is operated by the ESInet operator. The search function may return one or more Agency Locator URIs, a referral to another Agency Locator Search Service, or an error.The Agency Locator shall support the ALSBNRequest method and respond with a ALSBNResponse response.


SEND-EIDD 1000-0200

The FE must be able to send an EIDD to an agency based on an agency name using the Agency Locator.

Each Functional Element in the Agency Locator shall implement the server-side of the ElementState event notification package. The Agency Locator functional element shall promptly report changes in its state to its subscribed elements.The Agency Locator shall provide a name (white page) search function, with wild cards, to find a specific agency, location and agency type.The Agency Locator shall provide a search component which uses the ECRF and a LoST query to find a given agency by type and location.The Search Service shall be provisioned with other Search Services’ URIs to allow searches beyond the local ESInet much like a Forest Guide.The set of Agency Locator Functional Elements within an ESInet shall implement the server-side of the ServiceState event notification package for the Agency Locator.

Border Control Function


The SBC component of the BCF shall be capable of producing CDRs based on call/session control information (e.g., SIP/SDP). These CDRs may be used to manage the network and for Service Level Agreement (SLA) auditing.


The SBC component of the BCF shall support encryption (AES on TLS) for calls that are not protected entering the ESInet.



The ESInet will provide BCF functionality between the ESInet and the outside origination networks including the Internet.

Border Control FunctionBorder Control Function


The BCF, as the first active SIP element in the path of an emergency call, adds the Call Identifier, Incident Tracking Identifier and Resource-Priority (if not already present) to the call. These identifiers shall be added to the initial message of a dialog forming transaction INVITE or the MESSAGE method associated with a non-human-initiated call. The identifiers shall be added to all other SIP messages processed by the BCF.


The BCF shall support conformance checking and mapping (if applicable) of priority marking based on policy for emergency calls/sessions.





A BCF shall exist between the PSAP NG9-1-1 Network and any other external networks to which it is connected. This does not imply that a virtual PSAP necessarily requires a BCF between any part of that virtual PSAP and the network that connects them together. Refer to the NENA i3 document NENA-STA-010.2 for a detailed description of BCF functionality and interfaces.

Border Control FunctionBorder Control FunctionBorder Control Function

The SBC component of the BCF shall optionally support transcoding. For example, the SBC component may transcode Baudot tones to RFC 4103 real-time text (RTT).


The SBC component of the BCF shall be capable of populating the layer 2 and layer 3 headers/fields, based on call/session type (e.g., 9-1-1 calls) in order to facilitate priority routing of the packets.


The SBC component of the BCF shall support SIP/SDP protocol normalization and/or repair, including adjustments of encodings to a core network profile. This may be done in order to facilitate backward compatibility with older devices that may support a deprecated version of SIP/SDP.

Border Control FunctionBorder Control Function

BCFs that anchor media shall implement the Session Recording Client interface defined by SIPREC. Provisioning may control whether the BCF logs media.


Via NENA-CallSuspicion

The BCF shall attach a parameter to the Via header for each call. The parameter “NENA-CallSuspicion” is a 0-100 score of call suspicion where 0 is least suspicious and 100 is most suspicious.


The SBC "bad actor" request/response is a web service operated on the domain mentioned in the parameter and shall be implemented.


The SBC shall support a "bad actor" web service that implements a BadActorRequest method with a BadActorResponse response.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 66 of 115


Functional Element

ExternalRequirement

Num (if supplied)



30480NENA-STA-10.2 5.08.0 Bridging B2BUA

30490

NENA-STA-10.2 5.08.0 Bridging B2BUA

30500

NENA-STA-10.2 5.08.0 Bridging Bridge Call Flow

30510

NENA-STA-10.2 5.08.2 Bridging

30520


30530

3.6.1.6 Bridging EIDD

30540NENA-STA-10.2 5.09.1 Bridging

30550


30560


30570


All Bridges in the ESInet shall implement the Session Recording Client interface defined by SIPREC (RFC 7866). Provisioning may control whether the bridge does log media.

When the bridge is used to transfer the call, the location of the caller and any Additional Data included with the call shall be transferred to the transfer target. Additionally, any information the PSAP has determined beyond what it was sent shall be given to the transfer target. The mechanism for accomplishing this is to create an EIDD and include it in the transfer operation. The transferor creates the EIDD and includes a Call-Info header field with a purpose parameter of “eidd” as an escaped header field in the Refer-To header. The bridge will then include this header in the INVITE it sends to the transfer target. The EIDD includes the location reported for the caller (in the form it received it, i.e. by-value or by-reference) and any Additional Data included in the call.

The bridge is a service: each element of the bridge shall implement the server-side of ElementState and the set of bridge elements shall implement the server-side of ServiceState. As bridges are typically a local service, it is recommended that ServiceState for the bridge service be implemented by each NGCS that provides a bridge service.

Call Transfer Involving a B2BUA

When another PSAP is bridged to a 9-1-1 call there are separate “legs” for each participant in the bridge. The 9-1-1 call itself terminates at the bridge, with the call taker and the transfer target having separate legs into the bridge. When the transfer target receives the initial SIP transaction it is an INVITE from the bridge to establish a conference. It is critical that the transfer target receives (or has access to) the location of the original caller, as well as any Additional Data that the transferring PSAP call taker may have received during the processing of the emergency call, or was generated by the call taker as a result of processing the incoming emergency call. Caller location information along with any Additional Data shall be populated in an Emergency Incident Data Document (EIDD) structure (See NENA-STA-10.2 Section 8 for further discussion of Additional Data structures). When an emergency call is transferred, the transferring PSAP will request that the bridge inserts by embedded header, a Call-Info header field with a URI that points to the EIDD data structure in the REFER method sent to the bridge, and a purpose parameter of “eidd”. The bridge shall subsequently include this Call-Info header field in the INVITE it sends to the transfer target.

Call Transfer Involving a B2BUA

When transferring a 9-1-1 call, the transferring PSAP shall supply an EIDD containing the information that represents the current state of the incident/call. The EIDD is passed in an escaped Call-Info header field with a purpose of “eidd” that is within the Refer-To header. The EIDD shall be passed by reference, where the Call-Info header field contains a URL that when dereferenced yields the EIDD. While the EIDD normally could be passed by value (in which case the Call-Info header field in an INVITE would contain a Content Identifier URI and the body of the INVITE would contain the EIDD in a mime type of xml+nena/eidd), such a construct could not be invoked at the bridge by an embedded header in the Refer-To: from the transferring PSAP. To dereference the URI and obtain the EIDD, the recipient does an HTTPS: GET on the URI and the EIDD (NENA-APCO-REQ-001.1.1) is returned.The EIDD contains a snapshot of the state of the Incident, as known by the sending Agency. Obtaining updates to Incident state will be defined in a future version of this document.


BRIDGE-IN 0100-0100

When an i3 PSAP is bridged into a 9-1-1 call the receiving PSAP must have the ability to receive all of the data that the initial PSAP sends, including location, etc. This information will be found in the EIDD embedded or referenced in the received INVITE message as described in the Bridging section of NENA-STA-010.2.

Passing data to Agencies via bridging

When this solution is implemented, some element in the initial call path from the BCF to the first PSAP that answers the call shall include a B2BUA function as described in RFC 3261. All calls are relayed through the B2BUA.

Passing data to Agencies via bridging

The B2BUA is transparent to signaling with the following exceptions:1. Media endpoints towards both the caller and the PSAP are rewritten to be contained within the B2BUA.2. The REFER method, when executed on the PSAP side to a conference bridge, causes the bridge to invite the B2BUA to the conference, and the B2BUA to respond as illustrated below. The leg between the caller and the B2BUA sees no transaction.3. If the B2BUA receives an INVITE from a caller that does not include a Supported header containing the replaces option-tag it shall include a Supported header containing the replaces option-tag in the INVITE forwarded to the ESInet and provide the functionality described in this section.Note that the following flow assumes that the Primary PSAP has already created a conference using SIP Ad Hoc methods, as described in Section 5.7.1.1 of NENA 08-002.

Primary PSAP Drops, Secondary Completes Transfer

The B2BUA may act as a media relay for all media. All media packets on all negotiated media streams are relayed from one side of the B2BUA to the other.


Characteristics of this solution are: The solution is deployed at the edge of the ESInet; the rest of the ESInet can assume Replaces works. Media is anchored at the BCF regardless of what happens to the call. The B2BUA is call stateful. The B2BUA is in the path regardless of whether the device implements Replaces or not.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 67 of 115


Functional Element

ExternalRequirement

Num (if supplied)



30580


305903.6.1.6 Bridging Replaces

30600 NENA-STA-10.2 5.08.1 Bridging RFC 4579

30610NENA-STA-10.2 5.08.1.2 Bridging The Call Taker solution shall support the call flow described in Section 5.10 of RFC 4579.

30620NENA-STA-10.2 5.08.1.3 Bridging The Call Taker solution shall support the call flow described in Section 5.5 of RFC 4579.

30630NENA-STA-10.2 5.08.1 Bridging

30640

NENA-STA-10.2 5.09.2.4 Bridging

30650

NENA-STA-10.2 5.09.2.4 Bridging

30660NENA-STA-10.2 5.09.3 Bridging All incoming 9-1-1 calls shall be answered at a bridge.

30670 3.6.1.2 Call Handling Additional Data CALL 2000-0100

30680 3.6.1.2 Call Handling Agency Locator CALL 3000-0100

30690 3.5.2 Call Handling Agency Locator NET 0100-0100 30700 NENA-STA-10.2 4.01 Call Handling Agent Calls SIP shall be the protocol used for calls between agents within the ESInet.

30710 NENA-STA-10.2 4.1.10.0 Call Handling Alarms

30720 NENA-STA-10.2 4.1.08.1 Call Handling Audio

30730 3.6.1.8 Call Handling Barge The Call Handling FE must support the ability for an authorized supervisor to barge into the call.

30740 3.6.1.5 Call Handling Bridge






30800 3.6.1.7 Call Handling Bridge The Call Handling FE shall support using the ECRF to determine the route to the appropriate agency.



30830 3.6.1.7 Call Handling Bridge The i3 PSAP shall have the capability to drop from the bridge without terminating the bridge.




RFC 3725 describes a technique in which the initial answering UAC becomes a signaling B2BUA. If this method is chosen in an ESInet, a call taker UA receiving a call which does not contain a Supported header indicating support for Replaces shall take the actions described in this section. Unlike the examples in RFC 3725, the caller has a call established with the call taker (which takes on the role of the “controller” in RFC 3725). The call sequence (based on RFC 3725 Flow IV) is described in the following subsections.


BRIDGE-IN 0200-0100

The Bridge FE shall support all the options listed in the NENA-STA-010.2 section titled “Transfer Involving Devices Not Supporting Replaces”. Provisioning of the Bridge FE shall be able to select one of these options.The Call Taker solution shall support the conferencing procedures that are documented in RFC 4579.

RFC 4579 Section 5.10RFC 4579 Section 5.5RFC 4579 Section 5.9

It is required that some element in the call path implement the Replaces header as described in RFC 4579 Section 5.9.

Transfer Target Terminates Session with Caller

In this transfer scenario, the Call Taker UA remains in the signaling path for the duration of the call. The media flows directly (via any BCF firewall of course) between the caller and the Transfer Target. Any further transfers would be accomplished in a similar manner, with the Call Taker UA accepting an INVITE with a Replaces header, and initiating a re-INVITE towards the caller to establish the correct media path.

Transfer Target Terminates Session with Caller

This sequence is only necessary when the device does not implement Replaces. The Call Taker UA can notice the presence of the Supported header, and if Replaces is supported, it can just initiate a transfer using standard SIP methods, as described in NENA-STA-10.2 Section 5.7.1. It could, optionally, attempt the Replaces even if a Supported header was not found, detect an error and initiate the re-INVITE as above in response.

Conference / Transfer


Additional data about a call, caller or location may be retrieved using the processes described in the Additional Data Repository (ADR) section of NENA-STA-010.2.


The Call Handling FE shall implement the client side of the Agency Locator interface as described in Agency Locator section of NENA-STA-010.2.


The Agency Locator FE shall be used to locate an Agency and the interfaces and services it provides. Please refer to Agency Locator section of NENA-STA-010.2 document for more information.

The SIP functional elements shall support APCO/CSAA 2.101.2-2014 alarm notification within the ESInet.All User Agents shall support g.711 mu-law codecs. It is recommended that AMR, AMR-WB, EVRC, EVRC-B, EVRC-WB, and EVRC-NW codecs also be supported.

NENA/APCO-REQ-001.1.1 FLOOR 0600-0100 NENA/APCO-REQ-001.1.1

BRIDGE 0100-0100

The Call handling FE must provide the functionality allowing the Agent to have a side bar conversation with others without the calling party hearing the conversation.


BRIDGE-OUT 0100-0100

The Call Handling FE must have the ability to establish a bridge to one or more NG9-1-1 entities or legacy (e.g., PSTN) entities.



The bridge signaling for calls shall include the PSAP identifier of the originating PSAP. See NENA-STA-010.2 for more information.



When an emergency call is bridged, the Call Handling FE shall make available the location or location reference information in the bridge signaling that was received in the original emergency call plus Additional Data references per local policy. See the Passing data to Agencies via bridging section of NENA-STA-010.2.



When an emergency call is bridged, the Call Handling FE shall pass the local notes collected during interactions with the caller in an EIDD passed in the signaling as defined in NENA-STA-010.2.



The i3 PSAP may implement a transfer (bridge) function based upon the location of the caller and classification of the call, e.g. to police, fire, Emergency Medical Service (EMS) or other authorized agencies.





The Call Handling FE shall use the Incident location and proper service identifier (e.g. urn:nena:service:responder.police) to query the ECRF in order to determine the agency to which the call shall be bridged.



The Call Handling FE shall support using a URI to initiate a bridge, the URI being obtained from the ECRF or from a local database.





The Call Handling FE shall support the capability to blind or attended transfer a call to another Agent, PSAP or authorized agency. Attended transfer uses the Bridging and related sections of NENA-STA-010.2.



On a transfer, the Call Handling FE may provide ancillary supplemental information collected during the dialogue with the caller (e.g. Agent notes).

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 68 of 115


Functional Element

ExternalRequirement

Num (if supplied)



30860 3.6.1.8 Call Handling Bridge FLOOR 0100-0100

30870 3.6.1.8 Call Handling Bridge The Call Handling FE must support the capability to add parties to the bridge.

30880 3.6.1.8 Call Handling Bridge The Call Handling FE must support the capability to selectively drop parties from the bridge.

30890 3.6.1.8 Call Handling Bridge The Call Handling FE must support the capability to selectively mute parties on the bridge.





30940 3.6.1.8 Call Handling Bridge30950 NENA-STA-10.2 4.1.01 Call Handling BYE The call interfaces shall be able to generate the BYE transaction to terminate the call.

30960 NENA-STA-10.2 4.1.01.3 Call Handling BYE30970 NENA-STA-10.2 4.01 Call Handling Call back SIP shall be the protocol used to call a 9-1-1 caller back.

30980 3.6.1.2 Call Handling Default PSAP CALL 1900-0100

30990 NENA-STA-10.2 4.1.01.3 Call Handling31000 NENA-STA-10.2 4.1.16.0 Call Handling Element Overload SIP functional elements shall implement the overload control mechanisms described in RFC 7339.

31010 3.5.2 Call Handling ESRP NET 0100-0100

31020 3.5.2 Call Handling ESRP NET 0100-0100

31030 NENA-STA-10.2 4.1.09.0 Call Handling IM

31040 NENA-STA-10.2 5.07.04 Call Handling LIS Interface

31050 3.5.2 Call Handling LVF NET 0100-0100

31060 NENA-STA-10.2 4.1.02.6 Call Handling MSRP





31110 NENA-STA-10.2 4.01 Call Handling31120 NENA-STA-10.2 4.1.11.0 Call Handling Multipart MIME All SIP functional elements in the ESInet shall support multipart MIME as defined in RFC 2046.

31130 NENA-STA-10.2 4.1.09.0 Call Handling Mutiparty Chat

31140 NENA-STA-10.2 4.1.17.0 Call Handling NAT




When an NG9-1-1 Call Handling FE initiates a bridge it shall transmit all of the data that the PSAP’s policy allows.

NENA/APCO-REQ-001.1.1 FLOOR 0200-0100 NENA/APCO-REQ-001.1.1 FLOOR 0300-0100 NENA/APCO-REQ-001.1.1 FLOOR 0400-0100 NENA/APCO-REQ-001.1.1 FLOOR 0500-0100

The Call Handling FE shall have the capability to allow parties on the bridge to converse without another party’s knowledge.

NENA/APCO-REQ-001.1.1 FLOOR 0700-0100

The Call Handling FE must support the ability for an authorized supervisor to monitor the call without the other parties’ awareness.


The Call Handling FE (or the bridge acting on its behalf) must log an event to the Logging Service denoting that someone has initiated monitoring of the call.


Call Handling FEs on the bridge shall be notified of status of other parties on the bridge. See Bridging section of NENA-STA-010 for more information.


The notification capability shall be configurable such that notification of certain parties’ (e.g. supervisors) presence is not notified to other parties on the bridge.

All SIP functional elements shall support a BYE initiated from either end of the call. PSAPs shall accept a BYE request and honor it.


If an i3 PSAP is designated as the default PSAP it may receive the call request with a default location. This i3 PSAP shall process the call as a normal emergency call.

Disconnect Control

The ESInet and PSAP solutions shall support the mechanism for the PSAP control of dsconnect on a 9-1-1 call as described in NENA-STA-10.2 Appendix C.


The Call Handling FE of the PSAP shall use the ESRP when making a call to another agency or transferring or conferencing an existing call outside of the PSAP. The Call Handling FE determines the intended destination of the call or transfer request, for example using the ECRF for service-and-location based routing or the Agency Locator for name based routing, and the Call Handling FE forwards the call to wherever that routing mechanism determines, which would normally be an ESRP. For example a PSAP sends a call to a fire department by querying the ECRF with the location of the incident and an appropriate Service URN such as urn:nena:service:sos.fire.


The PSAP Call Handling FE, Incident Record Handling FE, Dispatch FE or other PSAP Services must use the ESRP to route a location based Service Request (selective transfer). Routing the request through an ESRP for any location based services allows the ESInet to take advantage of the PRF feature.Instant Message (IM) text-based communications shall be supported by all call handling elements with location and the ability to support location updates.

For HELD location URIs, specifying responseTime = emergencyDispatch shall result in a location meeting current regulatory accuracy requirements. If the PSAP wishes an immediate location, it can specify a short responseTime (perhaps 250 ms), and get the best location quality available in that time. Location updates for location URIs using HELD may be obtained by repeating the dereference request.


A PSAP uses the LVF to validate a location that was received either verbally, by a text message or by some other non-standard method for conveying location.All SIP endpoints within the ESInet shall be capable of responding to Message Session Relay Protocol (MSRP) which can be used to carry Instant Messages especially from a TCC. All call handling elements within the ESInet shall support the Message Session Relay Protocol (MSRP) (RFC 4975).Location shall be included in a Geolocation header in the initiation of the MSRP session as with any other “calls” to 9-1-1.Other Instant Messaging protocols such as XMPP shall be supported by an originating network, but shall be interworked to MSRP prior to presentation to the ESInet.All call handling elements within the ESInet shall support the Relay Extensions for the Message Session Relay Protocol (MSRP) (RFC 4976).

Multimedia Display

Calls are potentially multimedia, and can include one or more forms of media (audio, video and/or text). See NENA-STA-10.2 Section 4.1.10 for a discussion of “non-human-initiated calls” (also called “data-only emergency calls”) which can be used for non-human-initiated requests for help where there is no human caller.

All call handling elements within the ESInet shall support Multi-party Chat using the Message Session Relay Protocol (MSRP) (RFC 7701).All SIP functional elements in an ESInet that implement SIP interfaces shall comply with RFC 5626 (Outbound) to maintain connections from User Agents. PSAPs, IMRs, bridges and other elements that terminate calls from entities outside an ESInet that may be behind NATs shall implement “Interactive Connectivity Establishment (ICE)”, RFC 5245. The ESInet shall maintain a “Traversal Using Relays around NAT (TURN)” server for use by entities inside the ESInet placing calls towards the Internet.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 69 of 115


Functional Element

ExternalRequirement

Num (if supplied)



31170 NENA-STA-10.2 4.1.0 Call Handling

31180 NENA-STA-10.2 4.1.10.0 Call Handling





31230 NENA-STA-10.2 4.1.14.0 Call Handling31240 NENA-STA-10.2 4.1.03.3 Call Handling Presence All SIP functional elements shall support the update of presence information to a presence server.




31280 NENA-STA-10.2 4.1.06.0 Call Handling31290 NENA-STA-10.2 4.1.04.0 Call Handling ROHC All SIP functional elements within the ESInet shall support Robust Header Compression (ROHC). 31300 NENA-STA-10.2 4.1.13.0 Call Handling Routing All SIP elements shall support routing of SIP messages per RFC 3261 and RFC 3263.

31310 NENA-STA-10.2 4.1.15.0 Call Handling Routing31320 NENA-STA-10.2 4.1.08.0 Call Handling RTP All SIP call handling elements shall support media using Real Time Protocol (RTP) (RFC 3550).

31330 NENA-STA-10.2 4.1.08.3 Call Handling RTT

31340 NENA-STA-10.2 4.1.09.0 Call Handling RTT

31350 NENA-STA-10.2 4.1.12.0 Call Handling SDES31360 NENA-STA-10.2 4.1.0 Call Handling SIP Call Interface All calls presented to the ESInet shall be SIP signalled.

31370 NENA-STA-10.2 4.1.01 Call Handling SIP Call Interface

31380 NENA-STA-10.2 4.1.02.1 Call Handling SIP CANCEL

31390 NENA-STA-10.2 4.1.04.0 Call Handling SIP Headers

Non-human-initiated-calls

The interfaces shall support SIP “non-human-initiated calls” (also called “data-only emergency calls”) which can be used for non-human-initiated requests for help where there is no human caller.


All SIP functional elements shall support non-human-initiated calls, also called data-only emergency calls.


Non-human-initiated calls (also called data-only emergency calls) presented to an ESInet shall be signaled with a SIP MESSAGE method containing a Common Alerting Protocol (CAP) message. The <area> element of the CAP message is copied, in PIDF-LO form, into a Geolocation header of the SIP MESSAGE container. The CAP message is included in the body of the SIP MESSAGE, with a MIME type of application/common-alerting-protocol+xml.


The SIP functional elements shall route and handle non-human-initiated calls the same as voice, video or text calls throughout the NG9-1-1 system.

Originating network interface

A call from an unauthenticated device shall populate the P-Preferred-Identity header field in the INVITE request with an equipment identifier as a SIP URI and no P-Asserted-Identity shall be provided.


The incoming INVITE or MESSAGE method to the ESInet shall include at least two Call-Info header fields containing URIs that refer to Additional Data “ProviderInfo” and “ServiceInfo” structures. This is indicated by the ‘purpose’ parameters value starting with “purpose=EmergencyCallData.ProviderInfo” and “purpose=EmergencyCallData.ServiceInfo”. Additional Call-Info header fields may be included that contain a URI(s) that refers to other Additional Data blocks. Some providers will also include a “SubscriberInfo” block.


Functional elements in the ESInet shall assume a SIP call entering the ESInet is an emergency call unless it can determine it is something else, such as a call to an administrative number. Even if the call is not marked with an emergency service URN, the call shall be assumed to be an emergency call.

Resource Prioritization

The Resource-Priority header (RFC 4412) shall be used on SIP calls to indicate a priority that proxy servers give to specific calls.


All SIP proxy servers in the ESInet shall implement Resource-Priority and process calls in priority order when a queue of calls is waiting for service at the proxy server and, where needed, pre-empt lower priority calls.


BCFs shall police Resource-Priority for incoming SIP calls: those that appear to be emergency calls (such as those To: 911 but without a Request URI of “urn:service:sos”) shall be marked with a provisioned Resource-Priority which defaults to “esnet.1”.


The Resource-Priority in the ESInet shall be defined as:esnet.0 Calls which relate to an incident in progress, but whose purpose is not criticalesnet.1 9-1-1 calls traversing the ESInetesnet.2 Calls related to an incident in progress which are deemed criticalesnet.3- esnet.4 not defined

All calls shall be presented to the PSAP based on the terminating ESRP’s Policy Routing Function (PRF). The Geolocation header, Call-Info header fields and other headers shall be the same. The call will be routed, using normal RFC 3261 procedures, to the URI obtained from the ESRP’s PRF.

All call handling elements in the ESInet shall support Framework for Real-Time Text (RTT) over IP using SIP (RFC 5194).Real-Time Text (RTT) text-based communications shall be supported by all call handling elements with location and the ability to support location updates.All endpoints in the ESInet shall implement media security with SDP Security Descriptions for Media Streams (SDES) as defined in RFC 4568.

NG9-1-1 elements that process 9-1-1 calls shall accept calls that do not strictly follow the SIP standards. So long as the messages can be parsed, and the method discerned, at least the first SIP element (the BCF) shall be able to accept the call and forward the call onward.All SIP functional elements shall support CANCEL signaling to abandon a call, and NGCS elements shall treat a CANCELled call as such, including logging requirements.

All SIP interfaces to the NG9-1-1 Core Services shall support the following SIP Headers fields:To RFC 3261 [8.1.1.2 & 20.39] Usually sip:911 or “urn:service:sos”From RFC 3261 [8.1.1.3 & 20.20]Via RFC 3261 [8.1.1.7 & 20.42]CSeq RFC 3261 [8.1.1.5 & 20.16]Call-Id RFC 3261 [8.1.1.4 & 20.8]Call-Info RFC 3261 [8.1.1.10 & 20.9]Contact RFC 3261 [8.1.1.8 & 20.10]Content-Length RFC 3261 [20.14]Content-Type RFC 3261 [8.2.3 & 20.15], RFC 4119 and RFC 4566Geolocation RFC 6442Geolocation-Routing RFC 6442

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 70 of 115


Functional Element

ExternalRequirement

Num (if supplied)



31400 NENA-STA-10.2 4.1.05.0 Call Handling SIP Headers

31410 NENA-STA-10.2 4.1.07.0 Call Handling SIP History-Info

31420 NENA-STA-10.2 4.1.02.7 Call Handling SIP INFO31430 NENA-STA-10.2 4.1.01 Call Handling SIP INVITE The call interfaces shall support the 9-1-1 INVITE method.

31440 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE




31480 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE31490 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE The SIP functional elements shall support a "call treatment" of diverting to another PSAP.


31510 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE31520 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE The SIP functional elements shall use 183 Session Progress in some specific circumstances.





31570 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE31580 NENA-STA-10.2 4.1.01.1 Call Handling SIP INVITE All SIP functional elements shall support a “re-INVITE” in SIP.

31590 NENA-STA-10.2 4.1.02.6 Call Handling SIP MESSAGE


Content-Language RFC 3261 [20.13]Accept-Language RFC 3261 [20.3]Content-Disposition RFC 3261 [20.11]Record-Route RFC 3261 [20.30]Allow RFC 3261 [20.5]Unsupported RFC 3261 [20.40]Require RFC 3261 20.32Proxy Require RFC 3261 20.29Expires RFC 3261 20.19Min-expires RFC 3261 20.23Subject RFC 3261 20.36Priority RFC 3261 20.26Date RFC 3261 20.17Timestamp RFC 3261 20.38Organization RFC 3261 20.25User-Agent RFC 3261 20.41Server RFC 3261 20.35Authorization RFC 3261 20.7Authentication-Info RFC 3261 20.6Proxy-Authenticate RFC 3261 20.27Proxy-Authorization RFC 3261 20.28WWW-Authenticate RFC 3261 20.44Warning RFC 3261 20.43Call-Info RFC 3261 20.9 Used to carry URIs to Additional DataError-Info RFC 3261 20.18Alert-Info RFC 3261 20.4In-Reply-To RFC 3261 20.21MIME-Version RFC 3261 20.24Reply-To RFC 3261 20.31Retry-After RFC 3261 20.33RAck RFC 3262 7.2RSeq RFC 3262 7.1Event RFC 3265 7.2.1Allow Events RFC 3265 7.2.2Subscription-State RFC 3265 7.2.3Replaces RFC 3891Resource Priority RFC 4412 3.1 Section 4.1.6

SIP functional elements shall support the History-Info header (RFC 4244) and the associated Reason parameter. Elements that retarget a call shall add a History-Info header indicating the original intended recipient, and the reason why the call was retargeted. NGCS elements shall be prepared to handle a History-Info (and its associated Reason parameter) added by an element outside the ESInet before presentment to the 9-1-1 system.All SIP functional elements within the ESInet shall support the INFO method which is used for communicating mid-session signaling information along the signaling path for a call.

The standard INVITE/OK/ACK sequence shall be followed, with allowance for provisional (1XX) responses.The SIP functional elements shall support an emergency call that has a Route header obtained from the ECRF based on the location of the call and a Request URI containing a Service URN.

The SIP functional elements shall support a "call treatment" of routing a call to the PSAP serving the location of the caller.

The SIP functional elements shall support a "call treatment" of returning a Busy (600 Busy Everywhere).

The SIP functional elements shall support a "call treatment" of answering at an Interactive Media Response (IMR) system.

UACs within the ESInet shall generate an appropriate audible and in most cases a visual ring indication.The SIP functional elements shall normally only return a 180 Ringing provisional response when a 9-1-1 call is queued for answer.

The SIP functional elements shall not use other 1XX response due to uneven implementations of these responses. The SIP functional elements shall supply a 180 Ringing repeated response at approximately 3 second intervals if the call is not answered.The SIP functional elements shall accept any 1XX intermediate response and provide an appropriate indication to the caller when placing a call back

All SIP functional elements that handle 9-1-1 calls are usually not redirected, and thus 3XX responses are normally not used; however 3XX may be used for calls initiated within the ESInet shall be handled. All SIP functional Elements that initiate calls within the ESInet respond appropriately to 3XX responses as defined in RFC 3261.

All SIP endpoints within the ESInet shall be capable of responding to a MESSAGE method which is used to carry for example Common Alerting Protocol (CAP) message. The SIP functional elements shall support the MESSAGE method and shall contain a Call-Info header field with a URI of one or more Additional Data blocks.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 71 of 115


Functional Element

ExternalRequirement

Num (if supplied)








31660 NENA-STA-10.2 4.1.02.3 Call Handling SIP OPTIONS

31670 NENA-STA-10.2 4.1.02.5 Call Handling SIP PRACK

31680 NENA-STA-10.2 4.1.03.3 Call Handling SIP PUBLISH

31690 NENA-STA-10.2 4.1.01 Call Handling SIP REFER

31700 NENA-STA-10.2 4.1.01.2 Call Handling SIP REFER

31710 NENA-STA-10.2 4.1.01.2 Call Handling SIP REFER31720 NENA-STA-10.2 4.1.01.2 Call Handling SIP REFER All SIP functional elements shall support the REFER event package.

31730 NENA-STA-10.2 4.1.01.2 Call Handling SIP REFER31740 NENA-STA-10.2 4.1.03.1 Call Handling SIP REGISTER All SIP functional elements shall support REGISTER for UA registration.31750 NENA-STA-10.2 4.1.02.2 Call Handling SIP UPDATE All SIP functional elements shall support UPDATE as defined in RFC 3311.31760 NENA-STA-10.2 4.1.12.0 Call Handling SRTP All endpoints in the ESInet shall implement media security with SRTP as defined in RFC 3711.

31770 NENA-STA-10.2 4.1.03.2 Call Handling31780 NENA-STA-10.2 4.1.0 Call Handling Text The interfaces shall support SIP text media.

31790 NENA-STA-10.2 4.1.12.0 Call Handling TLS31800 NENA-STA-10.2 4.1.12.0 Call Handling Transport All SIP functional element signaling within the ESInet shall be TCP with TLS.

31810 NENA-STA-10.2 4.1.12.0 Call Handling Transport

31820 3.6.1.11 Call Handling TTY/TDD TTY 0100-010031830 NENA-STA-10.2 4.1.08.4 Call Handling TTY/TDD Endpoints shall be capable of receiving calls initiated from a TTY (baudot) device.

31840 NENA-STA-10.2 4.1.08.4 Call Handling TTY/TDD31850 NENA-STA-10.2 4.1.0 Call Handling Video The interfaces shall support SIP video media. 31860 NENA-STA-10.2 4.1.08.2 Call Handling Video All User Agents shall support video compression format H.264/MPEG-4 Version 10.

31870 NENA-STA-10.2 4.1.08.2 Call Handling Video

31880 NENA-STA-10.2 4.1.08.2 Call Handling Video

31890 NENA-STA-10.2 4.1.08.2 Call Handling Video31900 NENA-STA-10.2 4.1.08.2 Call Handling Video SIP functional elements shall support RTP/AVPF (RFC 4585) and is preferred in offers.

31910 NENA-STA-10.2 4.1.09.0 Call Handling XMPP

The SIP functional elements shall support the MESSAGE method <addresses> element and shall contain “urn:service:sos”, the same as the Route header for the Message.

The SIP functional elements shall contain the MESSAGE method <info> element. The element shall contain an <event code>. The <valueName> may be some externally defined namespace, but in many cases is expected to be “NENA”.

The SIP functional elements shall support the MESSAGE method <area> element. At least one <polygon> or <circle> element shall be included. Any <areaDesc> and <geocode> elements will not be used by the routing elements, although destination agencies may be able to make use of them. The Geolocation header in the MESSAGE shall have the PIDF-LO equivalent of the <polygon> or <circle> element(s).

A digital signature shall be included in the CAP message. The CAP message shall not be encrypted. Transport Layer Security (TLS) shall be used on the SIP MESSAGE transmission to encrypt the message, with fallback.When the CAP message is enclosed in an EDXL-DE wrapper, the body of the SIP MESSAGE will contain a section application/emergency-data-exchange-language+xml.All SIP endpoints within the ESInet shall be capable of responding to an OPTIONS request, as defined in RFC 3261.All SIP endpoints within the ESInet shall be capable of responding to a PRACK method which is used within systems that need reliable provisional responses (non 100). All SIP functional elements shall support the PUBLISH method for publishing event state. See RFC 3911.

The call interfaces shall support a 9-1-1 REFER method to support conference and transfer of calls. Call takers (and thus bridges that they use) shall be able to generate the BYE transaction to terminate the call.All SIP functional elements shall support the REFER method which is used within the ESInet to transfer a call and conference additional parties to a call.

All SIP functional element shall support the REFER method which indicates that the recipient (identified by the Request-URI) shall contact a third party using the contact information provided in the Refer-To header of the request.

All SIP functional element shall support a REFER which is sometimes used with the Replaces header, which is dubbed “REFER/Replaces”. This is used to replace a call leg with another call leg, an example being replacing a two way call between the caller and call taker with a leg between the caller and the bridge, with another transaction used to create the leg between the call taker and the bridge. If an element receives an REFER with Replaces request where the Replaces SIP Call ID does not exist, it shall be rejected.

SUBSCRIBE/NOTIFY

All SIP functional elements shall support SUBSCRIBE/NOTIFY as a mechanism to implement asynchronous events notification between two elements.

SIP packet fragmentation and reassembly shall be supported by all elements. If TLS establishment fails, fallback to TCP/UDP without TLS is allowed. If fallback without TLS happens, additional security weaknesses occur, and implementations shall be prepared to deal with the security risks engendered when TLS protection is not available.

All SIP functional elements shall support TLS, TCP and UDP transport with fallback to UDP being allowed.


The ESInet and all other sources of calls to the PSAP must only present RFC 4103 RTT to the PSAP. This implies that all TTY calls must be transcoded (Baudot to RFC 4103) before presentation to the PSAP. The Call Handling FE must be able to accept RFC 4103 and display as text.

LNGs and LSRGs shall transcode baudot as early in the media path as possible, and the IP network between the origination network and the transcoder shall be engineered to have very low packet loss and minimize other impairments. The transcoder shall be compliant with RFC 5369 and shall be transparent to audio that is not Baudot tones. Transcoders shall reduce the amplitude of detected Baudot tones, but shall not remove them entirely.

All User Agents shall support H.264/MPEG-4 Version 10 baseline profile support is recommended. At least levels 1-3 shall be supported.

User Agents in the ESInet shall support both RFC 5104 and RFC 5168 for full frame refresh requests. The RFC 5104 Real Time Control Protocol (RTCP) method is preferred with fall back to RFC 5168 INFO method when the sender does not implement RFC 5104.

Functional elements shall maintain 30 frames-per-second (fps) video if offered by the sender In order to maintain the ability to support rapid finger-spelling for sign language. RTP/AVPF (RFC 4585) shall be supported and is preferred in offers.

The functional elements shall specifically support the Extensible Messaging and Presence Protocol (XMPP)

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 72 of 115


Functional Element

ExternalRequirement

Num (if supplied)



31920 3.2 Default Location GEN 2600-0100

31930NENA-STA-10.2 4.7.0 ADR A PSAP or ESRP shall be enhanced to file a DR on an ADR.

31940NENA-STA-10.2 4.7.0 Agency Locator

31950

NENA-STA-10.2 4.7.0 Agency Reporting

31960NENA-STA-10.2 4.7.0 Authentication

31970NENA-STA-10.2 4.7.0 BCF A BCF shall be enhanced to file a DR on a originating network sending it a malformed call.

31980NENA-STA-10.2 4.7.0 An ESRP shall be capable to file a DR on a Border Control Function

319903.2 Client GEN 1100-0100

320003.2 Data GEN 1700-0100

32010NENA-REQ-002.1 3.11 Data A data user shall report data access failure to administrator of the data.

32020NENA-REQ-002.1 3.11 Data Turnaround time for data user to produce the report shall be near real time.

32030NENA-REQ-002.1 3.11 Data

32040NENA-REQ-002.1 3.0 Data Data User to Data Owner due to rights management

32050NENA-STA-10.2 4.7.0 Data owner A data user shall be capable to file a DR on a data owner due to rights management issues

32060NENA-REQ-002.1 3.0 ECRF ECRF Operator to SI Operator on GIS data provisioning

32070NENA-REQ-002.1 3.0 ECRF ECRF Operator to Discrepancy Report (DR) Subscribers on GIS gaps and overlaps

32080NENA-STA-10.2 4.7.0 ECRF The ECRF needs to file a DR on the GIS.

32090NENA-STA-10.2 4.7.0 ECRF Routing Data

32100NENA-REQ-002.1 3.4 ECRF/LVF ECRF and LVF Operator to SI Operator on GIS data provisioning

32110

NENA-REQ-002.1 3.4 ECRF/LVF

32120NENA-REQ-002.1 3.4 ECRF/LVF

32130NENA-REQ-002.1 3.4 ECRF/LVF Turnaround time for SI Operator to resolve discrepancy shall be one business day

32140

NENA-REQ-002.1 3.4 ECRF/LVF



32170NENA-STA-10.2 4.7.0 ECRF/LVF

32180NENA-REQ-002.1 3.11 Entity


Functional Element

If an FE forwards a default location, the FE shall ensure that the default marking is preserved on the forwarded default location.

Discrepancy Reporting


The Agency Locator (NENA-STA-010.2 Section 5.16) provides the URI to an agency’s DR service. For elements (such as an ECRF) that shall have a corresponding DR web service, no discovery mechanism is currently specified, and will be addressed in a future revision of this document.


A Discrepancy Report (DR) is sent by the agency reporting the discrepancy to a responding agency and will pass through several phases: The reporting agency creates the DR and forwards it to the responding agency The responding agency acknowledges the DR report and provides an estimate of when it will be resolved The reporting agency may request a status update and receive a response The responding agency resolves the DR and reports its resolution to the reporting agency


Any entity shall be capable to file a DR on another entity due to authentication issues (bad certificate, unknown entity, etc.)

Discrepancy ReportingDiscrepancy Reporting




Any FE may implement the Discrepancy Reporting client functionality to provide a convenient method for users of that FE to file a Discrepancy Report.



An FE that discovers a discrepancy must report it to the entity responsible for the data that is erroneous using the Discrepancy Reporting mechanism described in NENA-STA-010.2.


GEN-DR 0200-0100


GEN-DR 0200-0200


GEN-DR 0200-0300

Turnaround time for Administrator of data to resolve issue or work with data user for resolution shall be near real time but no longer than 24 hours.

Discrepancy ReportingDiscrepancy ReportingDiscrepancy ReportingDiscrepancy ReportingDiscrepancy ReportingDiscrepancy Reporting

Any client of an ECRF shall be enhanced to file a DR on the routing data (which could be a GIS layer problem or something else).


ECRF/LVF-DR 0100-0000



ECRF and LVF Operator shall report general failures to SI Operator on failures when provisioning due to GIS data quality control checks.Some issues that could be reported back to the 9-1-1 Authority from the SI are:• Incorrect eXtensible Markup Language (XML) schema, or malformed XML in a Web Feature Service (WFS) transaction message• Unexpected GIS layer or attributes• Invalid or missing geometry for a feature• Unauthorized provisioning source



Turnaround time for ECRF and LVF Operator to produce a Discrepancy Report to SI Operator shall be as near real time as possible without impacting the time it takes to route an incoming 911 call/request for service.





ECRF and LVF Operator to Discrepancy Report Subscribers on GIS Gaps and OverlapsThe GIS data is provisioned to the ECRF and LVF from a SI. As the ECRF and LVF Operator receive data from any SI, the QA/QC procedures are applied.



ECRF and LVF Operator shall publish GIS data quality error reports to a subscription-based service near real time. Discrepancy Report web service (DR Web Service) as defined in NENA STA-010- Detailed Functional and Interface Standards for the NENA i3 Solution.



DR Web Service shall notify DR subscribers (SI Operators and 9-1-1 Authorities) of GIS data quality issues near real time


The ECRF/LVF may be receiving data from another ECRF/LVF and thus shall need to file a DR on its upstream provider.


GEN-DR 0100-0000

Entity (such as an intelligent device) attempts to establish a communication link to another entity. Link fails due to possible out of date or invalid certification, no account or configuration error as some examples.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 73 of 115


Functional Element

ExternalRequirement

Num (if supplied)



32190NENA-REQ-002.1 3.0 Entity Entity to Entity due to authentication issues

32200NENA-STA-10.2 4.7.0 ESInet Any client shall be enhanced to file a DR on the ESInet operator.

32210NENA-REQ-002.1 3.5 ESRP

32220NENA-REQ-002.1 3.5 ESRP

32230NENA-REQ-002.1 3.5 ESRP Turnaround time for ESRP Operator to produce the discrepancy report(s) shall be near real time.

32240NENA-REQ-002.1 3.5 ESRP

32250NENA-REQ-002.1 3.5 ESRP

32260NENA-REQ-002.1 3.5 ESRP

32270NENA-REQ-002.1 3.5 ESRP Turnaround time for ESRP to produce the report shall be near real time.

32280NENA-REQ-002.1 3.5 ESRP

32290

NENA-REQ-002.1 3.5 ESRP

32300NENA-REQ-002.1 3.5 ESRP ESRP shall report invalid, unusual, inconsistent or improper incoming data to the BCF.

32310NENA-REQ-002.1 3.5 ESRP Turnaround time for ESRP to produce the report shall be near real time.

32320NENA-REQ-002.1 3.5 ESRP Turnaround time for BCF Operator to resolve or refer discrepancy shall be one business day.

32330NENA-REQ-002.1 3.0 ESRP

32340

NENA-REQ-002.1 3.10 Forest Guide FG-DR 0100-0000

32350NENA-REQ-002.1 3.10 Forest Guide FG-DR 0100-0100

32360NENA-REQ-002.1 3.10 Forest Guide FG-DR 0100-0200 Turnaround time for FGO to produce the report shall be near real time.

32370NENA-REQ-002.1 3.10 Forest Guide FG-DR 0100-0300

32380NENA-REQ-002.1 3.10 Forest Guide FG-DR 0100-0400 Turnaround time for resolution from referral shall be three business days.

32390NENA-REQ-002.1 3.0 Forest Guide Forest Guide Operator to Contributing ECRF Node Operator on provisioning coverage data

324003.2 GEN 1200-0100

32410NENA-REQ-002.1 3.11 General Source entity shall report authentication failure to administrator of the destination entity.

32420NENA-REQ-002.1 3.11 General Turnaround time for source entity to produce the report shall be near real time.



ESRP-DR 0100-0000

Emergency Services Routing Proxy (ESRP) to 9-1-1 Authority(s) or owner of problem routing policy(s). A route is created to a PSAP that the ESRP does not recognize or conflicts with one or more existing policies shall be reported.


ESRP-DR 0100-0100

ESRP Operator shall report conflict in existing policies, missing or invalid data elements to 9-1-1 Authority(s) or owner of routing policy(s).


ESRP-DR 0100-0200


ESRP-DR 0100-0300

Turnaround time for 9-1-1 Authority(s) or owner of routing policy(s) to resolve a discrepancy report shall be one business day.


ESRP-DR 0200-0000

ESRP on Access and/or Originating Network Provider with default route.Any ingress conditions preventing the call from being routed to the appropriate PSAP shall be reported.


ESRP-DR 0200-0100

ESRP Operator shall report when a default route is engaged and why (if available) to authority having jurisdiction.


ESRP-DR 0200-0200


ESRP-DR 0200-0300

Turnaround time for Access and/or Originating Network Provider to respond to discrepancy report shall be one business day.


ESRP-DR 0300-0000

ESRP to a BCF OperatorThe ESRP submits a DR on the BCF Operator for invalid, unusual, inconsistent, or improper incoming data.Some issues that could be reported back to the BCF are:• Invalid forwarding of an emergency call/session to an ESRP• Reporting of unusual incoming IP packets that the ESRP determines shall be blocked to protect the intended receiving user or network• Quality of Service (QoS) inconsistencies to the PSAP• Invalid or improper Call Detail Recording (The BCF also serves as the media session controller, which plays a part in delivery of multimedia content to the PSAP and the call detail recording function).• Baudot tones (TTY) to real time text transcoding errors


ESRP-DR 0300-0100


ESRP-DR 0300-0200


ESRP-DR 0300-0300


Emergency Services Routing Proxy (ESRP) to 9-1-1 Authority(s) or owner of problem routing policy(s).


Forest Guide Operator to Contributing ECRF Node Operator on provisioning coverage dataThe Contributing ECRF Node Operator will need to replicate both geographic extent and civic representations of its coverage area to a national Forest Guide (FG). This data will be transmitted to the FG using the LoST-Sync protocol per IETF RFC 6739.Some issues that could be reported back to the Contributing ECRF Node Operator from the FG are:• Invalid geometry• Gap/overlap• Duplicate attribute• Mandatory field(s) missing or mismatched data types• General provisioning failure to FG• Malformed URI• Lost-Sync protocol errors2 (badRequest, forbidden, internalError, serverTimeout, and notDeleted).


Forest Guide Operator (FGO) shall report discrepancies in GIS data from quality control checks to the contributing ECRF Node Operator.


Turnaround time for contributing ECRF Node Operator providing the GIS data to resolve or refer to downstream contributing ECRF Node Operator shall be one business day.




Functional Element

An FE may send a discrepancy report automatically if it has sufficient data available to complete the report.


GEN-DR 0100-0100


GEN-DR 0100-0200

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 74 of 115


Functional Element

ExternalRequirement

Num (if supplied)



32430NENA-REQ-002.1 3.11 General

32440

NENA-REQ-002.1 3.11 General

32450NENA-STA-10.2 4.7.0 IS-ADR A PSAP or ESRP shall be enhanced to file a DR on an IS-ADR.

32460

NENA-REQ-002.1 3.11 LIS

32470

NENA-REQ-002.1 3.2 LIS LIS-DR 0100-0000

32480NENA-REQ-002.1 3.2 LIS LIS-DR 0100-0100

32490NENA-REQ-002.1 3.2 LIS LIS-DR 0100-0200 Turnaround time for LIS to produce the report shall be near real time



32520NENA-REQ-002.1 3.2 LIS LIS-DR 0200-0200 Turnaround time to produce a Discrepancy Report shall be less than 24 hours.

32530NENA-REQ-002.1 3.0 LIS A discrepancy shall be submitted on failure to dereference a location from a LIS.

32540NENA-REQ-002.1 3.0 LIS

32550NENA-STA-10.2 4.7.0 LIS A PSAP or ESRP shall be able to submit a DR on a LIS.

32560NENA-REQ-002.1 3.7 LNG LNG Operator to CSP shall report a call that comes into the system with no ANI.

32570NENA-REQ-002.1 3.7 LNG LNG Operator shall produce a report on incoming call(s) with no ANI to the CSP.

32580NENA-REQ-002.1 3.7 LNG Turnaround time for the LNG Operator to produce the report shall be near real time.

32590NENA-REQ-002.1 3.7 LNG

32600NENA-REQ-002.1 3.7 LNG LNG Operator shall produce a report on instance(s) receiving a malformed response or no response.


32620NENA-REQ-002.1 3.7 LNG

32630NENA-REQ-002.1 3.7 LNG

32640NENA-REQ-002.1 3.7 LNG LNG Operator shall produce a report on instance(s) receiving malformed response or no response.


32660NENA-REQ-002.1 3.7 LNG Turnaround time for CSP to respond to discrepancy report shall be one business day.

326703.2 Logging Service GEN 1700-0200

32680NENA-STA-10.2 4.7.0 Logging Service A log client (logging entry or query) shall be capable to file a DR on the Logging Service

32690NENA-REQ-002.1 3.8 LSRG

32700NENA-REQ-002.1 3.8 LSRG LSRG shall notify the CSP that a call was dropped or terminated without appropriate signaling.

32710NENA-REQ-002.1 3.8 LSRG

32720NENA-REQ-002.1 3.8 LSRG LSRG Operator shall produce a report on instance(s) of a failed transfer.


GEN-DR 0100-0300

Turnaround time for Administrator of the destination entity to resolve issue or work with source entity for resolution shall be near real time but no longer than 24 hours


GEN-DR 0200-0000

Data User to Data Owner due to rights managementExample: PSAP requesting information such as building blueprint or contact information about a location, not available due to Rights Management.Example: The network a device is connected to requests information to complete call routing. SIP header may contain a location object used for querying a data source for obtaining actual location information. The system does not allow device access to the location information.



GEN-DR 0300-0000

Failure to dereference a location from a LIS Similar to the No Record Found (NRF) situation in the legacy system Points of dereference:1. PSAP controller or call taker workstation may need to dereference a device location2. ESRP3. Legacy PSAP Gateway (LPG)


Communication Service Providers (CSP) provisioning records to a Location Information Server (LIS): This applies to LIS location by value only. A discrepancy report is produced by the LIS when a record from a CSP is not accepted into the LIS database. When the CSP and LIS Operator are the same entity, the discrepancy report may be internal within the CSP system. Resolving an error will require an action to correct the issue and re-submission into the LIS.


The LIS shall report data information such as a format error using CSP- provided error description (excluding LVF errors)



LIS validating records against the LVF: The LIS Operator submits location record(s) to the LVF. The location records are validated against the LVF. If any discrepancies are identified in the location records, the resulting discrepancy report shall be returned to the LIS Operator.


The LIS shall report location data elements that are valid, invalid, or unchecked to a Communications Service Provider (CSP) and optionally to 9-1-1 Authority

Discrepancy ReportingDiscrepancy ReportingDiscrepancy Reporting

LIS validating records against the Location Validation Function (LVF) shall report any errors or discrepancies.


LNG-DR 0100-0000


LNG-DR 0100-0100


LNG-DR 0100-0200


LNG-DR 0200-0000

LNG Operator shall report a query to the provider of PIDF-LO that is received as a malformed response or no response.


LNG-DR 0200-0100


LNG-DR 0200-0200


LNG-DR 0200-0300

Turnaround time for provider of the PIDF-LO to respond to discrepancy report shall be one business day.


LNG-DR 0300-0000

Notification from LNG Operator to CSP that a call was dropped or terminated without appropriate signaling.


LNG-DR 0300-0100


LNG-DR 0300-0200


LNG-DR 0300-0300



Any FE that sends or receives Discrepancy Reports (defined in the Discrepancy Reporting section of NENA-STA-010.2) must log the report it sent or received.


LSRG -DR 0200-0000

LSRG Operator shall report a query to the provider of PIDF-LO that is received as a malformed response or no response.


LSRG -DR 0300-0000


LSRG -DR 0400-0000

LSRG shall create a discrepancy report on a failed transfer. Notification of the transfer failure will be to the entity originating the transfer and the 9-1-1 Authority.


LSRG -DR 0400-0100

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 75 of 115


Functional Element

ExternalRequirement

Num (if supplied)



32730NENA-REQ-002.1 3.8 LSRG Turnaround time for the LSRG Operator to produce the report shall be near real time.

32740NENA-REQ-002.1 3.8 LSRG


32760NENA-REQ-002.1 3.8 LSRG LSRG Operator shall produce a report on incoming call(s) with no ANI to the CSP.


32780NENA-REQ-002.1 3.8 LSRG


32800NENA-REQ-002.1 3.8 LSRG LSRG Operator shall produce a report on instance(s) receiving no or malformed response.


32820

NENA-REQ-002.1 3.8 LSRG

32830NENA-REQ-002.1 3.0 LSRG LSRG Operator shall be able to submit a DR to 9-1-1 Authority on Non-MSAG valid location.

32840NENA-REQ-002.1 3.0 LVF An LVF Operator shall be able to submit a DR to an SI Operator on GIS data provisioning.

32850NENA-REQ-002.1 3.0 LVF An LVF Operator shall be able to notify DR Subscribers on GIS gaps and overlaps.

32860NENA-STA-10.2 4.7.4 LVF

328703.2 GEN 1800-0100

32880

NENA-REQ-002.1 3.1

32890NENA-STA-10.2 4.7.0

32900NENA-STA-10.2 4.7.0 Policy



32930

NENA-REQ-002.1 3.6 PRF

32940NENA-REQ-002.1 3.6 PRF

32950NENA-REQ-002.1 3.6 PRF

32960NENA-REQ-002.1 3.6 PRF

32970

NENA-REQ-002.1 3.3 SI SI-DR 0100-0000


LSRG -DR 0400-0200


LSRG -DR 0500-0100

LSRG Operator shall produce a report on instance(s) of a failed location MCS validation to the 9-1-1 Authority


LSRG -DR 0500-0200


LSRG-DR 0100-0100


LSRG-DR 0100-0200


LSRG-DR 0200-0100

LSRG Operator shall produce a report on instance(s) receiving a malformed response or no response.


LSRG-DR 0200-0200


LSRG-DR 0300-0100


LSRG-DR 0300-0200


LSRG-DR 0500-0000

LSRG Operator to 9-1-1 Authority on Non-MSAG valid location:LSRG Operator queries the MCS (MSAG Conversion Service), and doesn’t receive an MSAG valid response. The location may be LVF valid, but not MSAG valid. This applies to calls being transferred from an ESInet to a legacy network.

Discrepancy ReportingDiscrepancy ReportingDiscrepancy ReportingDiscrepancy Reporting

The Discrepancy Reporting web service shall support the LVFDiscrepancyReport method and LVFDiscrepancyResponse response.



Management Console

Any FE that sends or receives Discrepancy Reports (defined in the Discrepancy Reporting section of NENA-STA-010.2) shall send a copy of the Discrepancy Report to the Management Console.

Discrepancy Reporting Minimum Content

The minimum content for a Discrepancy Report shall consist of:• Time Stamp of Discrepancy Submittal• Discrepancy Report ID• Discrepancy reporting agency domain name• Discrepancy reporting agent user ID• Discrepancy reporting agency contact info• Service or Instance in which the discrepancy exists• Additional notes/comments• Discrepancy Service or Database specificsAdditional Info• Query that generated the discrepancy• Full response of the query that generated the discrepancy (Message ID, Result Code, etc.)• What the reporting agency thinks is wrong• What the reporting agency thinks is the correct response, if available


Notify Agencies and Services

There shall be a Discrepancy Report (DR) functional element to notify agencies and services (including the BCF, ESRP, ECRF, Policy Store and LVF) when any discrepancy is found.


Any Policy Enforcement Point shall be capable to file a DR on a Policy owner due to formatting, syntax or other errors in the policy


A client of a Policy may report a discrepancy. The most common report is that the Policy Query returns an invalid Policy from the Policy Store.


The Discrepancy Reporting web service shall support the PolicyDiscrepancyReport method and PolicyDiscrepancyResponse response.


PRF-DR 0100-0000

PRF to owner of routing policiesThe PRF may not be capable of routing a call due to routing rule formatting, conflicts, syntax, creation of a loop between PSAPs, etc. This is an integrity check as policies are defined on the Policy Store.


PRF-DR 0100-0100

Policy Routing Store Operator shall produce a report on the routing policy(s) that produce invalid routing conditions to 9-1-1 Authority(s)/Owner of routing policies


PRF-DR 0100-0200

Turnaround time for the Policy Routing Store Operator to produce the report shall be near real time.


PRF-DR 0100-0300

Turnaround time for 9-1-1 Authority(s)/ Owner of routing policies to resolve discrepancy report shall be near real time.


SI Operator to 9-1-1 Authority on provisioning GIS dataThe 9-1-1 Authority may enable a SI to coalesce local GIS data into a regional or state database. The SI provisions the coalesced dataset to the Emergency Call Routing Function/Location Validation Function (ECRF/LVF) Operator based on SI functionality as stated in NENA STA-010 - Detailed Functional and Interface Standards for the NENA i3 Solution.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 76 of 115


Functional Element

ExternalRequirement

Num (if supplied)



32980

NENA-REQ-002.1 3.3 SI SI-DR 0100-0100

32990NENA-REQ-002.1 3.3 SI SI-DR 0100-0200 Turnaround time for SI to produce a Discrepancy Report shall be near real time.

33000NENA-REQ-002.1 3.0 SI SI Operator to 9-1-1 Authority on provisioning Geographic Information Systems (GIS) data

33010NENA-STA-10.2 4.7.3 Status Update

33020NENA-STA-10.2 4.7.0 Web Service The Discrepancy Reporting mechanism shall be in the form of a web service.

33030NENA-STA-10.2 4.7.0 Web Service


33050

NENA-STA-10.2 4.7.0 Web Service




33090 NENA-STA-10.2 5.15.0 DNS

33100 NENA-STA-10.2 5.15.0 DNSSEC

33110 NENA-STA-10.2 5.15.0 Hostnames

33120 NENA-STA-10.2 5.15.0 Redundancy

33130 NENA-STA-10.2 5.15.0 SRV

33140 NENA-STA-10.2 5.15.0 U-NAPTR U-NAPTR resolution shall be supported to obtain the URI for the ECRF (RFC 4848 and RFC 5986).

33150 NENA-STA-10.2 5.15.0 U-NAPTR U-NAPTR resolution shall be supported to obtain the URI for the LIS (RFC 5986).

33160 3.4.2 EIDD Error

33170 3.4.2 EIDD

33180 3.4.2 EIDD

33190 3.4.2 EIDD

33200 3.4.2 EIDD The FE must be able to request that an EIDD be sent by value or by reference.

33210 3.4.2 EIDD Notifier

33220 3.4.2 EIDD Schema All EIDDs must conform to the EIDD schema.

33230 3.4.2 EIDD Send The FE must implement an asynchronous notification mechanism for sending EIDDs.

33240 3.4.2 EIDD Send The FE must implement a Request-Response messaging mechanism for sending EIDDs.


SI shall report to 9-1-1 Authority on GIS data quality control checks. Some issues that could be reported back to the 9-1-1 Authority from the SI are:• Invalid geometry• Gap/overlap• Duplicate attribute as defined by the SI system• Mandatory field(s) missing or mismatched data types• Address range issues on centerline• General provisioning failure to SI or ECRF/LVF• Malformed Uniform Resource Identifier (URI)NOTE: It is expected that 9-1-1 Authorities will perform Quality Assurance/Quality Control (QA/QC) processes listed above prior to provisioning the data into the SI thus minimizing the errors and resolution timeframe for the provisioning process.



A reporting agency may request a status update. The mechanism defined assumes the responding agency continuously tracks the status of Discrepancy Reports that it has received (including those it has recently resolved), and can respond to the Status Update immediately.


When a discrepancy is reported on an element (such as an ECRF), the web service shall be operated by the entity that operates the element, not necessarily by the element itself.


All DRs shall contain common data elements (a prolog) that are defined in NENA-STA-010.2 Section 4.7.


The database or service shall have a defined block of data that will include: Query that generated the discrepancy Full response of the query that generated the discrepancy (Message ID, Result Code, etc.) What the reporting agency thinks is wrong What the reporting agency thinks is the correct response, if available


The Discrepancy Reporting web service shall support the DiscrepancyReportRequest method and DiscrepancyReportResponse response.


When the responding agency determines what the resolution to the DR is, it sends the resolution to the ResolutionURI parameter in the report request.


The Discrepancy Reporting web service shall support the StatusUpdateRequest method and StatusUpdateResponse response.

Domain Name Service

All elements connected to the ESInet shall have local DNS resolvers to translate hostnames they receive to IP addresses.

Domain Name Service

DNSSEC (RFC 4035) shall be deployed in authoritative DNS servers, especially those resolving names found in external ECRF/LVFs.

Domain Name Service

All elements identified by hostnames shall have corresponding Domain Name Service (DNS) records as specified in RFC 1034 in the global public DNS.

Domain Name Service

DNS servers shall be highly redundant, and resolvers shall be able to use cached records even if they have expired if they lose connections to authoritative DNS servers to resolve names.

Domain Name Service

A domain that has SIP elements within the domain shall have an SRV record (RFC 2782) for a SIP service for the domain and any of its subdomains that may appear in a URI.

Domain Name ServiceDomain Name Service


SEND-EIDD 1400-0200

The FE receiving a subscription or request for an EIDD must be able to respond with an appropriate error if the requested format (value or reference) is not acceptable per the agency policy.


Functional Element

SEND-EIDD 1000-0400

An FE must be able to request EIDDs based on data contained in an EIDD such as incident types, location, etc.


Functional Element

SEND-EIDD 1300-0100

The FE must support sending and receiving EIDDs by reference based on policy. A Uniform Resource Identifier (URI) is sent in the notification or response, and the recipient may retrieve the EIDD by dereferencing the URI.


Functional Element

SEND-EIDD 1300-0100

The FE must support sending and receiving EIDDs by value based on policy. When sent by value, the EIDD is transmitted in the notification or response.


Functional Element

SEND-EIDD 1400-0100


SEND-EIDD 1000-0300

An FE must be able to request notifications of any new incidents, or updates to an existing incident, from an FE within an agency or the IDE of another agency.


SEND-EIDD 0600-0100


SEND-EIDD 1100-0200


SEND-EIDD 1200-0100

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 77 of 115


Functional Element

ExternalRequirement

Num (if supplied)



33250 3.4.2 EIDD Specification

33260 NENA-STA-10.2 5.16.2 Agency Locator The ECRF shall support an Agency Locator search function.

33270 3.4.2 EIDD

33280 NENA-STA-10.2 4.4.7 Error Responses The ECRF/LVF shall provide LoST error responses as described in NENA-STA-10.2 Section 4.4.7.

33290 NENA-STA-10.2 4.4.3 findService The LoST servers shall support the “civic” and “geodetic-2d” baseline profiles defined in RFC 5222.

33300 NENA-STA-10.2 4.4.3 findService








33380 NENA-STA-10.2 4.4.4 findService All ECRF and LVF implementations shall support both recursive and iterative modes.





33430 NENA-STA-10.2 4.4.4 findService LoST servers shall return SIPS and HTTPS URIs in addition to the SIP and HTTP URIs.


33450 NENA-STA-10.2 4.4.4 findService The ECRF LoST shall not return the “NO-EXPIRATION” value.





SEND-EIDD 1600-0100

The specification resulting from these requirements shall identify which FE(s) must populate specific component(s) of an EIDD.

Emergency Call Routing Function



SEND-EIDD 1000-0100

The FE shall be able to send an EIDD to an agency based on an agency type and location using the ECRF.

Emergency Call Routing FunctionEmergency Call Routing FunctionEmergency Call Routing Function

ECRF/LVF shall support any of the PIDF-LO elements described in NENA-STA-004 document within a civic location.


The LoST interface allows a geo-location to be expressed as a point or one of a number of defined “shapes” such as circle, ellipse, arcband or polygon. ECRFs shall be able to handle all of these shapes.


The “service” element identifies the service requested by the client. Valid service names shall be “urn:service:sos” or one of its sub-services for ECRF and LVF queries used by originating networks or devices for emergency calls. For internal ECRFs used by entities within the ESInet to route calls, the <service> element shall be a service URN beginning with “urn:nena:service”. ECRF implementations shall support “urn:nena:service”. The use of such service URNs is dependent on provisioning of service boundary layers in the GIS.


The optional attribute to request validation occurs in a query and indicates whether location validation shall be performed and is currently conditioned on the <location> element containing a civic address; i.e., it is an error to request location validation for a geodetic coordinates-based location in RFC 5222.


Entities inside the ESInet shall specify recursion by setting the recursive attribute in the findService request to true and all ECRFs and LVFs shall implement and perform recursion when requested to help mitigate the effect of an attack on the Internal Forest Guide (see section 5.14.6). The internal ECRFs and LVFs (see NENA-STA-10.2 Section 5.14), when they are under stress from attack, may refuse queries from entities they do not know. External queries may use either recursion or iteration, as the external Forest Guide will be publicly available.


LoST servers shall support operating in recursive mode or iterative mode if the server being queried is not authoritative for the location supplied.


The ECRF shall support the use of iteration which simply returns a domain name of the next ECRF to contact.


The ECRF shall support operating in a recursive mode or an iterative mode, depending on local provisioning and the value of the ‘recursive’ attribute of the findService request.



If the ECRF successfully processes a LoST findService message, it shall return a LoST <findServiceResponse> message containing a <mapping> element that includes the “next hop” ESRP or the final PSAP URI in the <uri> element.


If the ECRF cannot successfully process a LoST findService message, it returns a LoST <errors> message indicating the nature of the error or a LoST <redirect> message indicating the ECRF that can process the findService message.


The <uri> returned shall specify either the next hop URI of the PSAP or the ESRP that is appropriate for the location sent in the query message. This shall be a globally routable URI with a scheme of “sip” for “urn:service:sos”.


Other service URNs may return values with HTTP/HTTPS schemes, for example “urn:nena:service:additionalData”.



The ECRF LoST findService shall support the ‘expires’ attribute in the <mapping> element provides an ECRF or LVF with a way to control load, balancing that against the time required to completely implement a routing change when circumstances require. By increasing the expiration time, fewer queries to the server may be received if upstream LoST servers or clients implement caching.

Emergency Call Routing FunctionEmergency Call Routing Function

The ECRF LoST findService response shall contain <via> elements in the <path> element that name the LoST servers visited to obtain the answer.


The ECRF LoST findService response <displayName> element of the <mapping> response is a text string that provides an indication of the serving agency(ies) for the location provided in the query.


The ECRF LoST findService <service> element in the query identifies the service for which this mapping is valid. An ECRF outside the ESInet is required to support the “urn:service:sos” service. Service substitution, as described in RFC 5222 shall be used to substitute “urn:service:sos” for all subservices such as “urn:service:sos.police”, which would cause the call to be routed the same as a call to “urn:service:sos”. ECRFs inside the ESInet shall support both “urn:service:sos” and “urn:nena:service:sos”. Support for other services will depend on local implementation. Routing of services inside the ESInet may depend on the (TLS) credentials of the client: routes for two services using the same service URN may receive different PSAP URIs. Note that if recursion is used, the credentials of the recursive server would be used, rather than the credentials of the original client.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:11 78 of 115


Functional Element

ExternalRequirement

Num (if supplied)










33560 3.2 GEN 2200-0100

33570 NENA-STA-10.2 4.4.5

33580 NENA-STA-10.2 4.4.6 All ECRFs and LVFs shall implement listServices and listServicesByLocation.

33590 NENA-STA-10.2 4.4.0 LoST The ECRF shall support the LoST (RFC 5222) protocol.

33600 NENA-STA-10.2 4.4.0 LoST

33610 NENA-STA-10.2 4.4.0 LoST

33620 NENA-STA-10.2 4.4.0 LoST The ECRF shall support retrieving lists of services available at a location.

33630 NENA-STA-10.2 4.5.0 LoST

33640 NENA-STA-10.2 5.03.0 LoST The Location Validation Function (LVF) shall be provisioned for civic location validation.

33650 NENA-STA-10.2 5.03.0 The ECRFs and LVFs shall implement the LoST protocol (RFC 5222).

33660 NENA-STA-10.2 5.03.2.4 The ECRF shall implement an NTP client interface for time-of-day information.


The ECRF Lost findService <serviceNumber> element in the <mapping> response shall contain the emergency services number appropriate for the location provided in the query. This allows a foreign end device to recognize a dialed emergency number. The service number returned by an ECRF or LVF for an emergency call would be “911”.


If the ECRF is configured to allow it, a requesting entity can obtain the boundary of the service area handled by the requested service, returned in the <serviceBoundary> element of <mapping>. This is most useful for mobile devices that use geodetic coordinates since they can track their location. When they leave the service area, they can send another findService request to determine the proper service area for their new location and avoid re-querying the ECRF as long as they are within the returned boundary.


The ECRF Lost findService service boundary in a <mapping> shall be returned by value or by reference, or not at all, at the discretion of the server. If the server returns a service boundary reference, the client may then obtain the actual service boundary with a <getServiceBoundary> request. A service boundary represented by a given reference can never change, so a client only needs to retrieve the boundary value a single time. Future mappings returned by the server and having the same service boundary may reuse the reference, eliminating the need to transmit the boundary value again.


Because a service boundary is not needed to initiate an emergency call, and because a complex boundary may be quite large, it is recommended that an ECRF be configured to return geodetic service boundaries by reference. Devices querying an ECRF in order to immediately initiate an emergency call shall not attempt to obtain the service boundary by value. Does the Responder support this recommendation?


The <locationValidation> element in < findServiceResponse > identifies which elements of the received civic address were “valid” and used for mapping, which were “invalid” and which were “unchecked” when validation is requested. Since the ECRF is not responsible for performing validation, this parameter may not be returned, subject to local implementations. LVFs would always return <locationValidation> if <validateLocation> was set to “True” in the findService request. Does the Responder's ECRF process the <locationValidation> element.


Does the Responder's ECRF comply with the following ECRF <locationValidation> rules?

To understand the validation portion of the response, follow these rules:1. The combination of all elements appearing in the <valid> list defines the scope.2. The combination of all elements appearing in the <invalid> list is not valid within the scope.a. No meaning can be inferred regarding the status of any individual element unless it is the only invalid element listed.b. The combination of elements may be valid in other scopes.c. One or more elements may appear as invalid even if they were not used in the original query, but could be used to resolve an ambiguity.3. Any individual element appearing as unchecked (or used in the query but not appearing in any of lists) was not checked or could not be determined to be either valid or invalid.


If any element appears in the <invalid> list, the location information is invalid and shall not be entered in the LIS. A response with only <valid> and/or <unchecked> elements shall be entered into the LIS.



Functional Element

An FE that determines the destination of a call or message based on the location of the caller, incident, etc. must use the Emergency Call Routing Function (ECRF) to determine the route.


getServiceBoundary

If a LoST server returns a service boundary by reference, it shall handle getServiceBoundary requests.


listServices and listServicesByLocation


The ECRF shall support retrieving URIs to support the retrieval of information based on a location such as Additional Data about that location.


The ECRF shall support retrieving URIs to support the retrieval of information based on a location such as Agency Locator records.



Events are communicated within and between ESInets using the SIP SUBSCRIBE/NOTIFY mechanism described in RFC 3265. ESInet functional elements shall accept or generate events to outside elements using different asynchronous event notification mechanisms, which would need to be interworked to SIP SUBSCRIBE/NOTIFY at the ESInet boundary.


Lost Query Examples


Mapping Data Provisioning Interface

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 79 of 115


Functional Element

ExternalRequirement

Num (if supplied)



33670 NENA-STA-10.2 5.03.2.7

33680 NENA-STA-10.2 4.4.1 Routing

33690 NENA-STA-10.2 4.4.1 Routing

33700 NENA-STA-10.2 5.03.2.5 Routing The ECRF shall implement a logging interface per NENA-STA-010.2 Section 5.13.

33710 NENA-STA-10.2 5.03.2.6 Routing The ECRF shall implement the server-side of the ElementState event notification package.

33720 NENA-STA-10.2 5.03.2.3 Routing Data The ECRF provisioning of routing data shall be on-line and near real time.

33730 NENA-STA-10.2 5.03.3.1 Service State

33740 NENA-STA-10.2 5.03.5 Spatial Interface

33750 NENA-STA-10.2 5.03.3.1 Time Interface The ECRF shall provide routing information based on a civic address or geodetic location.

33760 NENA-STA-10.2 3.07.0 Hostname

33770 NENA-STA-10.2 3.07.0 IPv4 ESInets shall accept and route IPv4 packets. All services shall support IPv4 interfaces.

33780 NENA-STA-10.2 3.07.0 IPv6

33790 NENA-STA-10.2 3.07.0 QoS

33800 NENA-STA-10.2 5.02.5

33810 NENA-STA-10.2 8.2 Abandoned Call

33820 NENA-STA-10.2 5.02.3 Additional Data

33830 NENA-STA-10.2 5.02.2.5 The ESRP shall implement the mechanisms for retrieving Additional Data (RFC 7852).

33840 NENA-STA-10.2 5.02.1.1 Call Queuing




Mapping Data Provisioning Interface

The ECRF functional elements shall implement the server-side of the ServiceState event notification package.


The functional elements shall support the following steps in determining the "next hop": All SIP-based emergency calls pass location information either by value (PIDF-LO) or by reference (Location URI) plus a Service URN to an Emergency Services Routing Proxy (ESRP) to support routing of emergency calls. The ESRP passes the Service URN and location information via the LoST interface to an Emergency Call Routing Function (ECRF), which determines the next hop in routing a call to the requested service. The ECRF performs the mapping of the call's location information and requested Service URN to (e.g.) a “PSAP URI” by querying its data and then returning the URI provided. Using the returned URI and other information (time-of-day, PSAP state, etc.), the ESRP then applies policy from a Policy-based Routing Function (PRF) to determine the appropriate routing URI. This URI is the “next hop” in the call's routing path that could be an ESRP URI (intermediate hop), a PSAP URI (final hop), or even a call-taker (see NENA-STA-10.2 Section 5.3 for a more detailed functional explanation of the i3 ECRF).


The service URN used to query the ECRF by an ESRP shall be obtained by provisioning of the “origination policy” of the queue that the call is received on at the ESRP. The response of the ECRF is determined by provisioning of the service boundary layers, which specify the URN they apply to. Thus, ECRFs (and ESRPs) are not hard coded with any specific URNs, but the provisioning of the policy in the ESRP shall match the provisioning of the service boundaries in the ECRF.

Emergency Call Routing FunctionEmergency Call Routing FunctionEmergency Call Routing FunctionEmergency Call Routing Function

The ECRF shall accept location information conforming to U.S. addressing standards defined in NENA-STA-004.1-2014 (CLDXF).


The ECRF shall have a policy that defines who it will provide data to. If the ECRF provides a replica service, the interface is the layer replication service as described in NENA-STA-010.2 Section 4.6. In this case, the ECRF is the server-side, as opposed to the client interface it shall provide towards the SI(s) it receives data from.


Emergency Services IP Networks

Functional elements connected to the ESInet will not be referred to by their IP address but rather through a Fully Qualified Domain Name (FQDN) hostname using DNS.



ESInets shall accept and route IPv6 packets. All services shall support IPv6 interfaces. IPv6 is recommended for use throughout the ESInet, but cannot be assumed.


The functional elements shall support Quality of Service (QoS) reasons, IP traffic within an ESInet shall implement DiffServ (RFC 2475). Routers shall respect code points: functional elements shall mark packets they create with appropriate code points. The BCF shall police code points for packets entering the ESInet.

Emergency Services Routing Proxy

10-digit Telephone Numbers

The ESRP is provisioned with Mappings from 10-digit PSAP telephone numbers to URIs (if the ESRP handles 10 digit calls on behalf of PSAPs).


When a PSAP handles a call it develops information about the call which shall be passed to subsequent PSAPs dispatchers and/or responders. This structure or a reference to it will be passed with a transferred call (see NENA-STA-010.2 Section 5.8.1.3) or as part of a dispatch operation.


The ESRP shall construct Additional Data structures when the relevant rule set mentions elements from these structures.


Additional Data Interfaces


The functional element Emergency Service Routing Proxy (ESRP) shall be the base routing function for emergency calls.


The destination of the call on the output of the ESRP is conceptually a queue, represented by a URI. In most cases, the queue is maintained on a downstream ESRP, and is most often empty. However, when the network gets busy for any reason, it is possible for more than one downstream element to "pull" calls from the queue. The queue is most often First In First Out, but in some cases there can be out-of-order selections from the queue.


The output of the ESRP is a SIP message with a Route header (possibly) rewritten, a Via header added, and in some cases, additional manipulation of the SIP messages.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 80 of 115


Functional Element

ExternalRequirement

Num (if supplied)






33900 NENA-STA-10.2 5.02.1.1 Data Structures




33940 NENA-STA-10.2 5.02.1.10 Data Structures The ESRP shall process OPTIONS transactions per RFC 3261.

33950 NENA-STA-10.2 5.02.1.2 Data Structures The ESRP shall support Call Queuing as defined in NENA-STA-010.2 Section 5.02.



33980 NENA-STA-10.2 5.02.5 Default Location

33990 NENA-STA-10.2 5.02.5 Default Route

34000 NENA-STA-10.2 5.02.1.2


The ESRP shall have interfaces to the ECRF for location based routing information, as well as various event notification sources to gather state, which is used by its Policy Routing Function (PRF).


The ESRP shall have interfaces to various event notification sources to gather state, which is used by its Policy Routing Function (PRF).


For typical 9-1-1 calls with a Request URI starting with “urn:service:sos” received, the ESRP shall:1) Evaluate an origination policy “rule set” for the queue the call arrives on;2) Query the location-based routing function (ECRF) with the location included with the call (including any steps to dereference location included by reference) to determine the “normal” next hop (smaller political or network subdivision, PSAP or call taker group) URI;3) Evaluate a termination policy rule set for that URI using other inputs available to it such as headers in the SIP message, time of day, PSAP state, etc.


The result of the policy rule evaluation is a URI. The ESRP shall forward the call to the URI (which is a queue).


The ESRP may also handle calls to what used to be called “administrative lines,” meaning calls directed to, for example a 10-digit number listed for a particular PSAP, although in NG9-1-1, they may be multimedia calls, and may be to a more general SIP URI. It is recommended that such calls route through the BCF to an ESRP and be subject to the same security and policy routing as regular 9-1-1 calls. Such calls would normally not have a Geolocation header, but would arrive on a different queue, have a different origination policy, would not query an ECRF and would use a fixed URL for “Normal-Next Hop”.


For calls forwarded by a PSAP to a responder with a Request URI of “urn:nena:service:responder.*” and a Route header containing the responder URI, the ESRP uses the domain of the Route header to choose an origination policy and evaluates it per 1-3 above. Note that the responders may have URIs in the ECRF that are different from a URI found in, for example, the Agency Locator, which may follow different paths. Responders are encouraged to use route policy for handling unusual circumstances that may require calls to be forwarded to alternative agencies, but they are not required to do so. ESRPs which do not have a termination policy for the Route header in this circumstance forward the call to the domain specified in the route header with no further processing.


An ESRP is usually the “outgoing proxy server” for calls originated by the PSAP. The ESRP would route calls within the ESInet, and would route calls to destinations outside the ESInet through an appropriate gateway or SIP trunk to a PSTN or other carrier connection. Call-backs to the original caller are an example of such outgoing calls to external destinations. No policy rule set evaluation is used for outgoing calls. While an ESRP could be an incoming proxy server for non-emergency calls, such use is beyond the scope of this standard.




The destination of every routing decision is conceptually a queue of calls. The queue can be large or small, it can have one or many sources entering calls on a queue, it can have one or many sources taking calls off the queue. All queues defined in this document are normally First In First Out. A unique SIP URI identifies a queue. A queue is normally managed by an ESRP. A call sent to the queue URI shall route to the entity that manages it. Calls are enqueued by forwarding them to the URI (which is usually obtained by policy rule evaluation of an upstream ESRP). Calls typically are dequeued by the ESRP, making a routing decision and sending the call to a downstream queue managed by an ESRP or endpoint such as a call taker or IMR. As such, all call queues are “ingress” queues, conceptually on the input side of an ESRP. In cases where more than one dequeuer exists for a queue, one entity (normally an ESRP) manages the queue, and other ESRPs register to dequeue calls from the queue. The queue mechanism discussed here is not an “egress” queue, which would conceptually be on the output side of an ESRP. A given ESRP takes calls off its queues (or queues managed by some other entity if there are multiple dequeuers) and processes them. That ESRP will then enqueue the call on a downstream entity that manages another queue.


ESRPs may, and often will, manage multiple queues. For example, an ESRP may manage a queue that is used for normal 9-1-1 calls routed to the local ESInet, and one or more queues for calls that are diverted to it by ESRPs from other areas that are overloaded. Each queue shall have a unique URI that routes to the ESRP.


The ESRP is provisioned with the default locations it uses, including (potentially) one for each origination domain, and an overall default location.


The ESRP is provisioned with a URI of a default route PSAP that takes calls when a route cannot be determined.


DequeueRegistration

The ESRP proxy servers may be simple RFC 3261 compliant servers. In such cases, the queue is considered to have a length of 1 and its existence can be ignored.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 81 of 115


Functional Element

ExternalRequirement

Num (if supplied)



34010 NENA-STA-10.2 5.02.1.2

34020 NENA-STA-10.2 5.02.4

34030 NENA-STA-10.2 5.02.1.4 The ESRP shall support a DequeueRegistration web service as defined by NENA-STA-010.2.

34040 NENA-STA-10.2 5.02.1.4

34050 NENA-STA-10.2 7.01 DNS NAPTR

34060 NENA-STA-10.2 5.02.2.3 ECRF

34070 NENA-STA-10.2 5.02.2.3 ECRF

34080 NENA-STA-10.2 5.02.2.3 ECRF

34090 NENA-STA-10.2 5.02.5 ECRF The ESRP is provisioned with The ECRF it uses.

34100 NENA-STA-10.2 5.02.1.5 ECRF

34110 NENA-STA-10.2 5.02.2.6 ElementState The ESRP shall implement the server-side of the ElementState event notification package.

34120 NENA-STA-10.2 5.02.2.6 ElementState

34130 NENA-STA-10.2 5.02.2.6 ElementState

34140 NENA-STA-10.2 5.02.3 ElementState The ESRP shall maintain an ElementState structure for its own state.

34150 NENA-STA-10.2 5.02.3 ElementState The ESRP shall maintain an ElementState structure for every downstream element it serves.

34160 NENA-STA-10.2 5.02.4 ElementState The ElementState policy determines which entities may subscribe it its ElementState event.

34170 NENA-STA-10.2 5.02.1.3


DequeueRegistration

The ESRP managing a queue may have policies controlling which entities may enqueue and dequeue calls to the queue. The dequeueing entity registers (DequeueRegistration) to receive calls from the queue. The ESRP would respond to a call from an entity not in its policy with a 404 error.


DequeueRegistration

The DequeueRegistration policy determines which entities may subscribe to the DequeueRegistration event.


DequeueRegistration web service


DequeueRegistration web service

The DequeueRegistration web service shall provide a DequeueRegistrationRequest method with a DequeueRegistrationResponse response.


Enterprise SIP Proxy Servers shall utilize DNS NAPTR and SRV queries as described in RFC 3263 to determine the IP address, transport protocol, and port number of the SIP Proxy Server(s) associated with the Service Provider’s domain name.


This document defines service URNs that can be used by an ESRP to query an ECRF. These service URNs include:urn:nena:service:sos.psap = Route calls to primary PSAPurn:nena:service:sos.level_2_esrp = Route calls to a second level ESRP (for an example, a state ESRP routing towards a county ESRP)urn:nena:service:sos.level_3_esrp = Route calls to a third level ESRP (for example, a regional ESRP that received a call from a state ESRP and in turn routes towards a county ESRP).urn:nena:service:sos.call_taker = Route calls to a call taker within a PSAP


ESRPs use these service URNs to perform finer resolution routing (e.g. state to regional, regional to psap, or other next hop). Each ESRP in the path may use a different service URN that relates to the hierarchy of routing within a given ESInet. The URIs returned by the ECRF using these service URNs (along with location) would be associated with queues used by downstream elements. Typically, those queues would not allow any entity other than the upstream ESRP to enqueue calls on that queue, which is specified by that queue’s policy (See NENA-STA-10.2 Section 5.02.1.4). The specific service URN used by an ESRP is specified in its origination routing policy (see NENA-STA-10.2 Section 4.3.2.1.9). Any URN in the “urn.service.sos” or “urn:nena.service.sos” tree shall be supported by all ESRPs. Loops can result if the service urns specified in the policy are not appropriately chosen.


The ESRP shall use the ECRF interface with the “urn:nena:service:additionalData” service URN when the relevant rule set specifies an element in that structure. The same location used for the location-based route is used for the Additional Data query.



The ESRP shall evaluate PRF rule sets for the queue the call arrives on (OriginationPolicy) and the result of the ECRF query (TerminationPolicy).



The ESRP shall maintain a Subscription for this package on every downstream element/service it serves.


The ESRP shall implement the server-side of the ElementState event notification package and accept Subscriptions for all upstream ESRPs it expects to receive calls from.





ESRP State Notification and Subscriptions

Race conditions exist where a dequeued call may be sent to an entity that just became congested. A call/event sent to a queue which is Inactive or Disabled, or where the current queue length is equal to or greater than the allowed maximum queue length will have an error (486 Busy Here) returned by the dequeuer. An ESRP that dequeues a call, sends it to a downstream entity and receives a 486 in return shall be able to either re-enqueue the call (at the head of the line) or send it to another dequeueing entity. Note that the upstream ESRP may be configured with policy rules that will specify alternate treatment based on downstream queue state.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 82 of 115


Functional Element

ExternalRequirement

Num (if supplied)



34180 NENA-STA-10.2 5.02.1.3

34190 NENA-STA-10.2 5.02.1.3

34200 NENA-STA-10.2 5.02.2.4 The ESRP shall implement the HELD Dereferencing interface.

34210 NENA-STA-10.2 5.02.2.8 Logging The ESRP shall implement the logging interface per NENA-STA-010.2 Section 5.13.

34220 NENA-STA-10.2 5.02.2.9 Logging

34230 NENA-STA-10.2 5.02.5 Logging The ESRP is provisioned with The Logging service it uses.

34240 NENA-STA-10.2 5.02.1.3 Notifier



34270 NENA-STA-10.2 5.02.1.6

34280 NENA-STA-10.2 5.02.4 Origination-Policy The ESRP shall use an Origination-Policy rule set for each queue it manages.

34290 NENA-STA-10.2 5.02.2.2 Overview

34300 NENA-STA-10.2 5.02.2.3 Overview The ESRP shall implement a LoST interface towards a (provisioned) ECRF.

34310 NENA-STA-10.2 5.02.1.2 QueueState




34350 NENA-STA-10.2 5.02.1.3 QueueState The ESRP shall implement and maintain QueueState as defined by NENA-STA-010.2.



ESRPs normally send calls to downstream entities that indicate they are available to take calls. “Available” however, is from the downstream entities point of view. Network state may preclude an upstream entity from sending calls downstream. Normal SIP processing would eventually result in timeouts if calls were sent to an entity that never responds because the packets never arrive. Timeouts are long however, and a more responsive mechanism is desirable to ensure that rapid response to changing network conditions route calls optimally.



If active calls are being handled, the upstream entity knows the downstream entity is connected. However, some routes are seldom used, and a mechanism shall be provided that ensures the connectedness of each entity remains known.


HELD Dereference Interface



The ESRP shall implement the AbandonedCallEvent to notify a PSAP that a call was started, but then cancelled prior to the PSAP receiving the call.



Notifier Processing of SUBSCRIBE Requests: The Notifier (i.e., the ESRP) consults the policy (queueState) to determine if the requester is permitted to subscribe. If not, the ESRP returns 603 Decline. The ESRP determines whether the queue is one of the queues managed by the Notifier. If not, the ESRP return 488 Not Acceptable Here. If the request is acceptable, the Notifier returns 202 Accepted.


Notifier Generation of NOTIFY Requests: When state of the queue changes (call is placed on, removed from the queue, or management action/device failure changes the “state” enumeration), a new NOTIFY is generated, adhering to the filter requests.


Rate of Notification: This package is designed for relatively high frequency of notifications. The subscriber can control the rate of notifications using the filter rate control (RFC 6446). The default throttle rate is one notification per second. The default force rate is one notification per minute. The Notifier shall be capable of generating NOTIFYs at the maximum busy second call rate to the maximum number of downstream dequeueing entities, plus at least 10 other subscribers.


Notify Event Package

The ESRP shall support a Notify Event Package Name: nena-ESRPnotify when the PRF encounters a Notify action.



The first ESRP in the path adds a Call identifier and adds a Call-Info header field with a purpose parameter of “nena-CallId” if one is not already present.



Each ESRP element will maintain a QueueState notifier, and track the number of calls in queue for the queues that it manages. ElementState overrides QueueState (if the Element is Down, the queue is Inactive).


Event Package Name: nena-QueueStateEvent Package Parameters: NoneSUBSCRIBE Bodies: standard RFC 4661 + extensions filter specification may be presentSubscription Duration Default one (1) hour. One (1) minute to twenty-four (24) hours is reasonable.NOTIFY Bodies: MIME type application/vnd.nena.queuestate+xml


QueueState is an event that indicates to an upstream entity the state of a queue. The SIP Notify mechanism described in RFC 3265 is used to report QueueState. The event includes the URI of the queue, the current queue length, allowed maximum length and a state enumeration including: Active: one or more entities are actively available or are currently handling calls being enqueued Inactive: no entity is available or actively handling calls being enqueued Disabled: The queue is disabled by management action and no calls may be enqueued Full: The queue is full and no new calls can be enqueued on it. Standby: the queue has one or more entities that are available to take calls, but the queue is not presently in use. When a call is enqueued, the state changes to “Active”.


QueueState need not be implemented on simple routing proxy or when queue length is 1 and only one dequeuer is permitted.


NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 83 of 115


Functional Element

ExternalRequirement

Num (if supplied)




34370 NENA-STA-10.2 5.02.3 QueueState The ESRP shall maintain a QueueState structure for each queue it manages.

34380 NENA-STA-10.2 5.02.3 QueueState

34390 NENA-STA-10.2 5.02.4 QueueState The ESRP shall use an enqueuer policy that specifies which entities can enqueue calls on the queue.


34410 NENA-STA-10.2 5.02.4 QueueState The QueueState policy determines which entities may subscribe to the QueueState event.

34420 NENA-STA-10.2 5.02.5 QueueState The ESRP is provisioned with the queues it manages.

34430 NENA-STA-10.2 5.02.5 QueueState The ESRP is provisioned with the queues it dequeues from.

34440 3.2 Routing GEN 2800-0100

34450 NENA-STA-10.2 5.02.2.6 ServiceState The ESRP shall implement the client side of the ServiceState event notification package.

34460 NENA-STA-10.2 5.02.2.6 ServiceState

34470 NENA-STA-10.2 5.02.2.6 ServiceState The ESRP shall implement the server-side of the ServiceState event notification package.

34480 NENA-STA-10.2 5.02.2.2 SIP Call-Info

34490 NENA-STA-10.2 5.02.1.7 SIP Methods The ESRP shall support all SIP methods and headers per RFC 3261.

34500 NENA-STA-10.2 5.02.2.4 The ESRP shall implement the SIP Presence Event Package.

34510 NENA-STA-10.2 5.02.4

34520 NENA-STA-10.2 5.02.2.7 Time The ESRP shall maintain reliable NTP time synchronization.

34530 NENA-STA-10.2 4.5.0 Event Notification



34560 NENA-STA-10.2 5.14.1 Forest Guide ECRF/LVF34570 NENA-STA-10.2 5.14.2 Forest Guide ElementState The Forest Guide shall implement the server-side of the ElementState event notification package.

34580 NENA-STA-10.2 5.14.0 Forest Guide


For this purpose, relatively frequent NOTIFYs of the QueueState event are used. Successful completion of the NOTIFY is an indication to the upstream entity that calls sent to the downstream entity shall succeed. The subscription may include a “force” and/or “throttle” filter (RFC 6446) to control the rate of Notification.



The ESRP shall maintain a QueueState structure for states of the entities registered to enqueue and dequeue calls from the queue, the number of calls in queue, maximum calls allowed and current queue state.



The ESRProuteEvent Policy determines which entities may subscribe to the ESRProute Event (see Section 5.02.1.6).






FEs that require location based routing to another Agency must use an Emergency Services Routing Proxy (ESRP) to route a location based Service Request (selective transfer).



The ESRP shall maintain a Subscription for this package on every downstream element/service it serves.



The first ESRP in the path adds a Call-Info header field, if one is not already present, with a purpose parameter of “nena-IncidentId” and a new Incident Tracking Identifier.



SIP Presence Event Package


Termination-Policy

The ESRP shall have access to the appropriate Termination-Policy ruleset for every URI that the ECRF can return in response to a service query made by the ESRP (Normal-NextHop).


SIP SUBSCRIBE/NOTIFY

Events shall be communicated within and between ESInets using the SIP SUBSCRIBE/NOTIFY mechanism described in RFC 3265.


ESInet functional elements shall accept or generate events to outside elements using different asynchronous event notification mechanisms, which would need to be interworked to SIP SUBSCRIBE/NOTIFY at the ESInet boundary.


ESInet events shall be defined by an event package which includes the name of the event, the subscription parameters, the conditions under which NOTIFYs are issued and the content of the NOTIFY, as described in RFC 3265.

Given a query to an area outside its coverage area, an ECRF/LVF may have the coverage regions of other ECRF/LVFs to which it could refer a query, or it would refer to a Forest Guide. In NG9-1-1, each state is nominally a tree, with local ECRF/LVFs as the children. The top of the tree is often a state ECRF/LVF. There is a National Forest Guide that has knowledge of these trees. The National Forest Guide exchanges mappings with other National Forest Guides. A state coverage region, exported to the National Forest Guide could be the civic state element, and a polygon representing the state boundary.


The ECRF shall make use of Forest Guides as defined in RFC 5582. A server that does not answer a query can refer to a Forest Guide to determine the response.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 84 of 115


Functional Element

ExternalRequirement

Num (if supplied)




34600 NENA-STA-10.2 5.14.2 Forest Guide A Forest Guide shall provide gap/overlap coverage analysis as described for ECRFs.34610 NENA-STA-10.2 3.05.0 Forest Guide Location The functional elements shall support Location as represented by content in a PIDF-LO document.


34630 NENA-STA-10.2 5.14.2 Forest Guide LoST

34640 NENA-STA-10.2 5.16.0 Agency Locator

34650 NENA-STA-10.2 3.10.0 E.164 The functional elements shall handle a full E.164 telephone number.

34660 3.2 Element State GEN 1400-0100

34670 NENA-STA-10.2 3.04.2 ElementState

34680 3.2 Keep-alive GEN 3500-0100 A keep-alive mechanism is required on each interface between FEs.

34690 NENA-STA-10.2 3.04.0 Logging Any functional element that handles a call shall implement the Logging Interface.

34700 NENA-STA-10.2 3.04.1 SecurityPosture

34710 NENA-STA-10.2 3.04.3 Service State

34720 NENA-STA-10.2 3.11.0 SNMP v3

34730 NENA-STA-10.2 5.06.0 Geocode Service ElementState

34740 NENA-STA-10.2 5.06.0 Geocode Service Replication

34750 NENA-STA-10.2 5.06.0 Geocode Service ServiceState

34760 NENA-STA-10.2 5.06.0 Geocode Service Web Service




34800 NENA-STA-10.2 12.1 IANA Actions The Responder shall support the IANA Registry entries as described in NENA-STA-10.2 Section 12.1.34810 NENA-STA-10.2 3.01.1 Identifiers Agency Identifier The functional elements shall support the use of Agency Identifiers.

34820 NENA-STA-10.2 3.01.1 Identifiers Agency Identifier

34830 NENA-STA-10.2 3.01.2 Identifiers Agent Identifier34840 NENA-STA-10.2 3.01.2 Identifiers Agent Identifier Functional elements shall support the use of Agent Identifiers.

Functional Elements

The functional elements shall support the PIDF-LO element called "retransmission-allowed", which when missing or set to false is meant to prohibit forwarding of the PIDF-LO. Handling of location when processing an emergency call is controlled by law, and NG9-1-1 FEs normally would ignore retransmission-allowed within the ESInet for such calls. There are circumstances where data about an emergency call may be sent to entities not covered by existing law. In those circumstances it is desirable that NG9-1-1 FEs honor the privacy wishes of the sender as expressed in the retransmission-allowed field. When handling non-emergency calls, it is desirable that retransmission-allowed be honored.

Gap/Overlap coverage

Location Validation Function

The LVF shall make use of Forest Guides as defined in RFC 5582. A server that does not answer a query can refer to a Forest Guide to determine the response.

The National Forest Guide maintains a LoST interface, as described in NENA-STA-10.2 Section 4.4, for query resolution. It also maintains a LoST-sync interface defined in RFC 6739 for updating its coverage regions. The LoST-sync interface is used for both state ECRF/LVF interfaces and other National Forest Guides. The National Forest Guide only serves “urn:service:sos”, “urn:nena:service:sos” and “urn:nena:service:responder”. It may be able to refer to other Forest Guides for services other than these. The National Forest Guide may interchange coverage with other National Forest Guides.

Functional Elements

The functional element Agency Locator as described in NENA-STA-010.2 shall be an element provided in the Responder's solution.

Functional Elements


Functional Elements

Every FE must implement the notifier side of the Element State interface described in NENA-STA-010.2.

Functional Elements

The functional elements shall support ElementState which is an event that indicates the state of an element either automatically determined, or as determined by management.


Functional ElementsFunctional ElementsFunctional Elements

The functional elements shall support SecurityPosture which is an event that represents a downstream entity’s current security state.

Functional Elements

The functional elements shall support ServiceState which is an event that indicates the state of service either automatically determined, or as determined by management.

Functional Elements

All physical realizations shall provide Simple Network Management Protocol (SNMP) version 3 (RFC 3410 and RFC 3418) management interfaces to network management systems.The Geocode Service (GCS) shall implement the server-side of the ElementState event notification package. The GCS shall promptly report changes in its state to its subscribed elements.The Geocode Service shall be provisioned using the same mechanism as is used to provision the ECRF and LVF layer replication from the master SI. The Geocode Service (GCS) shall implement the server-side of the ServiceState event notification package for the GCS. The Responder shall provision a Geocode Service (GCS) web service that provides geocoding and reverse geocoding functionality.The Geocode Service (GCS) web service shall implement the GeocodeRequest request and the GeocodeResponse response.The Geocode Service (GCS) web service shall implement the ReverseGeocodeRequest request and the ReverseGeocodeResponse response.The Geocode Service (GCS) web service logs the invocation of the function, as well as the input and output objects.

SDP parameter “suspended”

An agency is represented by a domain name as defined in RFC 1034. Agencies shall use one domain name consistently in order to correlate actions across a wide range of calls and incidents. Any domain name in the public Domain Name System (DNS) is acceptable so long as each distinct agency uses a different domain name. This implies that each agency ID is globally unique. An example of an agency identifier is “police.allegheny.pa.us”.

An agent is represented by an agent identifier that is a username, using the syntax for “Dot-string” in RFC 5321 (that is, the user part of an email address, without the possibility of a “Quoted-String”). Usernames shall be unique within the domain of the agency, which implies that the combination of Agent and Agency IDs is globally unique. Examples of this are “[email protected]” and “[email protected]”.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 85 of 115


Functional Element

ExternalRequirement

Num (if supplied)



34850 NENA-STA-10.2 3.01.3 Identifiers Element Identifier34860 NENA-STA-10.2 3.01.3 Identifiers Element Identifier Functional elements shall support the use of Element Identifiers.

34870 NENA-STA-10.2 3.01.4 Identifiers Service Identifier34880 NENA-STA-10.2 3.01.4 Identifiers Service Identifier The functional elements shall support the use of Service Identifiers.

34890 NENA-STA-10.2 3.01.5 Identifiers Service Identifier34900 NENA-STA-10.2 3.01.6 Identifiers Service Identifier The functional elements shall support the assignment and use of Incident Tracking Identifiers.

34910 NENA-STA-10.2 5.11.1 IS-ADR

34920 NENA-STA-10.2 5.11.1 IS-ADR

34930 NENA-STA-10.2 5.11.1

34940 NENA-STA-10.2 5.11.1

34950 NENA-STA-10.2 5.11.1

34960 NENA-STA-10.2 5.11.1

34970 NENA-STA-10.2 5.11.1

34980 3.7.8 Agency Locator IDE 0700-0100

34990 3.7.8 Discovery IDE 0500-0100 An IDE must be discoverable by other FEs.

35000 3.4.2 EIDD

35010 3.4.2 EIDD

35020 3.6.7 Dequeue IMR 0200-0100

35030 NENA-STA-10.2 5.12.0 ElementState

A logical name used to represent physical implementation of a functional element or set of functional elements as a single addressable unit. The external interfaces of the element shall adhere to the standards in this document. Elements are addressable via a hostname that shall be globally unique. An example of an element identifier is “esrp1.state.pa.us”. Element Identifiers represent one instance of a replicated functional element when redundant instances of a function are provided for reliability.

A service can be implemented in one or more elements, and indeed for redundancy purposes, nearly every service shall be implemented by multiple elements. Regardless, the external interfaces of the service shall adhere to the standards in NENA-STA-010.2. Services are identified with a Fully Qualified Domain Name (FQDN). An example of a Service Identifier is “psap.allegheny.pa.us”.

The term “call” includes voice calls, video calls, text calls and non-human-initiated calls. The first element in the first ESInet that handles a call assigns the Call Identifier. The form of a Call Identifier is a Uniform Resource Name (URN) formed by the prefix “urn:nena:uid:callid:”, a unique string containing alpha and/or numeric characters, the “:” character, and the Element Identifier of the element that first handled the call. For example, “urn:nena:uid:callid:a56e556d871:bcf.state.pa.us” would be a properly formatted Call Identifier. The unique string portion of the Call Identifier shall be unique for each call the element handles over time. The length of the unique string portion of the Call Identifier shall be between 10 and 30 characters. One way to create this unique string is to use a timestamp with a suffix that differentiates multiple calls if they could be created by the element in the same instant. Implementations using multiple physical devices to implement a redundant element may need an additional component to guarantee uniqueness. The Call Identifier is added to a Session Initiation Protocol (SIP) message using a Call-Info header field with a purpose of “nena-CallId”.

Identity Searchable Additional Data Repository

Some Identity Searchable Additional Data Repositories (IS-ADR) have an optional feature that allows the repository to be searched by identity. This capability is needed when data is stored by an entity that is not in the path of the call or access network. For example, personal medical data provided by the caller may be stored by an entity trusted by the caller to keep such data. The caller provides the identity it uses on calls, and the IS-ADR is searched. An IS-ADR is an ADR and shall conform to NENA-STA-10.2 Section 5.11.


It is anticipated that a number of third parties will choose to host an IS-ADR. A registry of recognized IS-ADRs is defined by this document (NENA-STA-10.2 Section 11.22). PSAPs and other responsible parties can then use the NENA IS-ADR registry as input into the configuration of the NG9-1-1 functional elements under their control. Does the Responder have an IS-ADR registered?


IS-ADR Web Service

The IS-ADR provides a web service. When queried with caller's “From” address or P-Asserted-Identity (as retrieved from the SIP header), the IS-ADR optionally returns an XML document containing the caller’s Additional Data (by value).


IS-ADR Web Service

The IS-ADR provides a web service. When queried with caller's “From” address or P-Asserted-Identity (as retrieved from the SIP header), the IS-ADR optionally returns a URI that can be used to dereference the caller’s Additional Data.


IS-ADR Web Service

The IS-ADR provides a web service. When queried with caller's “From” address or P-Asserted-Identity (as retrieved from the SIP header), the IS-ADR optionally returns an HTTP 303 response (Iterative Refer), instructing the client to direct an Additional Data query to the resource specified in the response.


IS-ADR Web Service

When the IS-ADR web service is queried with the caller's “From” address or P-Asserted-Identity (as retrieved from the SIP header), the IS-ADR returns an indication that no data was found for the provided “From” or P-Asserted-Identity URI.


IS-ADR Web Service

The IS-ADR provides a web service that shall support an IS-ADRRequest request and IS-ADRResponse response.


Incident Data Exchange

The IDE FE shall implement the client side of the Agency Locator interface as described in Agency Locator section of NENA-STA-010.2.





SEND-EIDD 0800-0100

The Incident Data Exchange FE shall present a discoverable query point to other agencies and FEs through which incident information may be obtained regarding incidents handled by FEs registered with the Incident Data Exchange FE.



SEND-EIDD 0900-0100

The FE may respond to a request for incident information by replying with an EIDD containing data extracted from its own internal databases. The Incident Data Exchange FE shall reply with an EIDD obtained by querying appropriate FEs.


Interactive Media Response

In order to support call diversion in PSAP overload conditions, the Interactive Media Response FE must support the dequeue function for queues from other PSAPs described in the Dequeue Registration Event Package section of NENA-STA-010.2.


Each functional element in the IMR shall implement the server-side of the ElementState event notification package. The IMR shall promptly report changes in its state to its subscribed elements.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 86 of 115


Functional Element

ExternalRequirement

Num (if supplied)



35040 3.6.7 IMR 0100-0100

35050 NENA-STA-10.2 5.12.0 IMR

35060 NENA-STA-10.2 5.12.0 IMR

35070 3.6.7 IMR 0300-0100


35090 NENA-STA-10.2 5.12.0 ServiceState

35100 NENA-STA-10.2 5.12.0 SIPREC

35110 NENA-STA-10.2 5.12.0 VXML

35120 NENA-STA-10.2 5.12.0 VXML

35130 NENA-STA-10.2 4.2.0 Credentials

35140 NENA-STA-10.2 5.10.0 Dereference

35150 NENA-STA-10.2 4.2.0 EIDD

35160 NENA-STA-10.2 5.10.0 Geolocation

35170 NENA-STA-10.2 4.2.0 HELD Dereference Any functional element needing location that has a HELD URI shall dereference per RFC 6753.

35180 NENA-STA-10.2 5.10.0 HELD Dereference The LIS shall support HELD Dereferencing (RFC 6753) and/or the SIP Presence Event Package.

35190 NENA-STA-10.2 4.2.0 Location

35200 NENA-STA-10.2 4.2.0 The LIS shall provide a dereference function for location by reference.

35210 NENA-STA-10.2 4.2.0

35220 NENA-STA-10.2 4.2.0

35230 NENA-STA-10.2 4.2.0

35240 NENA-STA-10.2 4.2.0

35250 NENA-STA-10.2 4.2.0



Functional Element

The Interactive Media Response (IMR) FE is similar to an Interactive Voice Response (IVR) unit, but it handles audio, video and text media. The IMR FE must conform to the requirements in the Interactive Media Response section of NENA-STA-010.2.


The Interactive Media Response system (IMR) is similar to an Interactive Voice Response (IVR) unit, but handles audio, video and text media. It may be used to answer calls when the PSAP is receiving more calls than it has call takers to answer them. It offers interaction with the caller (“Press 1 if this about the car crash on Fourth and Main, Press 2 if this is about some other problem”). Does the Responder provide an IMR with their solution?


IMRs shall interpret an IM, RTT or other text received consisting the digits 0-9, ‘#’ or ‘*’ immediately following a prompt for input as equivalent to DTMF key presses.



Management Console

In order to enable management control of diversion, an interface between the Interactive Media Response FE and the Management Console would be required.


Calls may be queued within the IMR waiting for available call takers. The queue of calls shall be a queue as defined in NENA-STA-10.2 Section 5.2.1.2 and maintain the specified QueueState and DequeRegistration events so that PSAP management can monitor and control the queue as it does all other queues.


The set of IMR functional elements shall implement the server-side of the ServiceState event notification package for the IMR. Since IMR is typically a local service it is recommended that each ESInet that provides an IMR service implement ServiceState for that ESInet.


IMRs shall implement the Session Recording Client (SRC) interface defined by SIPREC (RFC 7866). Provisioning may control whether the IMR logs media.


IMRs shall implement RFC 4240 and VXML V2.0. VXML <audio> tags shall specify multiple MIME types with appropriate types for the media. Synthesis scripts shall render text for text media. The IMR shall implement at least g.711 mu-law, g.711 a-law, AMR, AMR-WB, EVRC (RFC 3558), EVRC-B (RFC 4788), EVRC-WB (RFC 5188), and EVRC-NW (RFC 6884) codecs.


The IMR shall support the syntax for specifying a URI to route to a specific VXML script is defined in RFC 4240.

Location Information Server

The credentials shall be used by the LIS to authorize delivery of dispatch location, with the required confidence/uncertainty information (when geodetic location is supplied) or civic/sub-civic address-level information (when civic location is supplied), when requested by a PSAP or other authorized entities.


The LIS shall provide a “dereference” service for a location URI it supplies: given the URI, the LIS provides the location value as a PIDF-LO.


When location is passed by value, processing elements along the path shall not change the location record. If location information changes, a new PIDF-LO with a different <provided-by> element shall be created and passed in addition to the original location. The vehicle for passing this information is an EIDD.


The LIS supplies location (by value or reference) to the endpoint, or to a proxy operating on behalf of (OBO) the endpoint. The ESInet is not directly involved in that transaction: the resulting PIDF-LO or location URI shall appear in the initial SIP message in a Geolocation header. If the LIS supplies location by reference, it shall also provide dereferencing service for that location URI. Elements in the ESInet, including the ESRP, and the PSAP may dereference a location URI as part of processing a call.




It is recommended that LISs cache location values and supply the cached values if multiple dereferences occur in quick succession, such as when a call is being routed.


Location by Reference



The LIS shall support location by reference (LbyR), where a location URI is populated in the Geolocation header.



All elements in an ESInet that use location by reference (LbyR) shall implement SIP and HTTP Enabled Location Delivery (HELD) dereferencing protocols.



The access network that provides location by reference (LbyR) shall supply either a SIP or a HELD location reference URI. Networks that use other protocols shall interwork to SIP or HELD.



Elements in the ESInet that receive a location by reference and forward location in SIP signaling to another element shall pass the reference, and not any value that they determine by dereferencing (although the value shall be logged).



Each element shall do its own dereference operation, supplying its credentials to the LIS. It is recommended that LISs cache location values and supply the cached values if multiple dereferences occur in quick succession, such as when a call is being routed.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 87 of 115


Functional Element

ExternalRequirement

Num (if supplied)



35260 NENA-STA-10.2 5.10.0 If the broadband access network supports true mobility, it shall supply location by reference.

35270 NENA-STA-10.2 5.10.0 The broadband fixed network shall supply location by reference (optional).

35280 NENA-STA-10.2 5.10.0

35290 NENA-STA-10.2 4.2.0 Location by Value

35300 NENA-STA-10.2 5.10.0 Location by Value A Location Information Server (LIS) shall supply location in the form of a PIDF-LO (location by value).

35310 NENA-STA-10.2 5.10.0 Location by Value The broadband fixed network shall supply location by value (preferred).

35320 NENA-STA-10.2 4.2.0 LVF The LIS shall provide a validation of location stored in the LIS by querying the LVF for civic addresses

35330 NENA-STA-10.2 5.10.0 LVF

35340 NENA-STA-10.2 4.2.0 Protocols The LIS shall implement one or both of the SIP and HELD protocols.

35350 NENA-STA-10.2 5.10.0 SIP Presence The LIS shall support SIP Presence to provide location-by-reference as defined by RFC 5808.

35360 NENA-STA-10.2 5.10.0 SIP Presence

35370 NENA-STA-10.2 4.2.0 SIP URI

35380 NENA-STA-10.2 5.10.0 SIP URI

35390 NENA-STA-10.2 4.2.0 TLS

35400 NENA-STA-10.2 5.03.3.5 ECRF

35410 NENA-STA-10.2 5.03.2.6 ElementState The LVF shall implement the server-side of the ElementState event notification package.

35420 NENA-STA-10.2 4.4.4 Iteration

35430 NENA-STA-10.2 5.03.2.5 Logging The LVF shall implement a logging interface per NENA-STA-010.2 Section 5.13.

35440 NENA-STA-10.2 4.4.0 LoST The LVF shall support the LoST (RFC 5222) protocol.

35450 NENA-STA-10.2 5.03.2.2

35460 NENA-STA-10.2 5.03.2.7 ServiceState

35470 NENA-STA-10.2 5.03.5 Spatial Interface

35480 NENA-STA-10.2 5.03.2.4 Time The LVF shall implement an NTP client interface for time-of-day information.







When location is provided by reference the reference shall be valid at least for the length of the call. Does the Responder have a mechanism to expire or delete locations by reference?


The SIP functional elements shall support Location by Value (LbyV) in the body of a SIP message, with a pointer to it (i.e., a cid URL) in the Geolocation header of the SIP message.





A LIS shall validate locations prior to entering them into the LIS using the LVF (NENA-STA-10.2 Section 5.3).




The querier can limit how often further NOTIFYs are sent (before expiration of the subscription) using a filter (RFC 4661). Rate limits (RFC 6446) and Location filters (RFC 6447) shall be supported by the LIS if it supplies a SIP location URI.


Any functional element needing location that has a SIP location URI shall issue a SIP SUBSCRIBE (RFC 3265) to the location URI. Filters (RFC 4661, RFC 6446 and RFC 6447) may be used to control notification.


If the LIS supplies location by reference it shall support the SIP Presence Event Package, location filters (RFC 6447) and event rate control (RFC 6446)..


The LIS shall accept credentials traceable to the PSAP Credentialing Authority (PCA) when establishing the TLS connection as sufficient to deliver “dispatch” quality location.


The LVF shall use the same data provided to the ECRF as described in NENA-STA-010.2 Section 5.3.3.1.



The LVF shall support the use of iteration which simply returns a domain name of the next ECRF to contact.




LoST Location validation

Local LVF policy shall be responsible for determining which elements are given priority in determining which URI and which associated location data element tokens are deemed valid.


The LVF functional elements shall implement the server-side of the ServiceState event notification package.


The LVF shall have a policy that defines who it will provide data to. If the LVF provides a replica service, the interface is the layer replication service as described in NENA-STA-010.2 Section 4.6. In this case, the LVF is the server-side, as opposed to the client interface it shall provide towards the SI(s) it receives data from.


NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 88 of 115


Functional Element

ExternalRequirement

Num (if supplied)



35490 NENA-STA-10.2 5.13.0 Logging Service ServiceState

35500 3.7.7 Logging Service Administrative

35510 3.7.7 Logging Service Agency Locator

35520 NENA-STA-10.2 5.13.2.3 Logging Service Attended Transfer

35530 3.7.7 Logging Service Audit Trail

35540 3.7.7 Logging Service Audit Trail

35550 NENA-STA-10.2 5.13.2.5 Logging Service Blind Transfer

35560 NENA-STA-10.2 5.13.2.4 Logging Service Call Back

35570 NENA-STA-10.2 5.13.0 Logging Service All functional elements in an ESInet shall log all significant events to the Logging Service.

35580 3.4.2 Logging Service EIDD All EIDDs must be logged as specified in the Logging Service section of NENA-STA-010.2.

35590 3.4.2 Logging Service EIDD Whenever an EIDD is sent, a notice of the exchange must be logged.

35600 3.4.2 Logging Service EIDD Whenever an EIDD is received, a notice of the exchange must be logged.

35610 3.4.2 Logging Service EIDD

The set of Logging Service functional elements shall implement the server-side of the ServiceState event notification package.


LOGGING 1000-0100

The Logging Service shall support acquisition of media from administrative communications via the standard interface (See NENA-STA-010.2).


LOGGING 1900-0100

The Logging Service shall implement the client side of the Agency Locator interface as described in Agency Locator section of NENA-STA-010.2.

The Responder shall support the following Attended Transfer scenario:

The Answer-Point transfers the call to a third party. The call shall still be recorded if it is bridged by the SRC. Call hits the SRC SRC opens a recording session with the recorder, including the call identifier Call is answered Call stream is added to the recording session Both parties communicate Answer-Point calls 3rd Party Call is answered by 3rd Party Re-invite is sent to the recorder with the call identifier 3rd Party stream is added to the recording session Answer-Point hangs up Remaining parties continue to communicate Caller hangs up 3rd Party hangs up SRC closes the recording session.Note: All additional information about the call can retrieved from the logging service using the call identifier.


LOGGING 1500-0100

The Logging Service shall keep an audit trail of all attempts to access logged data (successful and unsuccessful).


LOGGING 1600-0101

This audit trail shall contain the type of access, the identification of the data accessed, the username, and the date/time of the access.

The Responder shall support the following Blind Transfer scenario:

The Answer-Point transfers call to a third party as an unsupervised transfer. The call shall still be recorded by the SRC. Call hits the SRC SRC opens a recording session with the recorder, including the call identifier Call is answered Call stream is added to the recording session Both parties communicate Answer-Point calls 3rd Party Answer-Point hangs up Re-invite is sent to the recorder with the call identifier 3rd Party stream is added to the recording session All parties communicate if and when 3rd party answers Caller hangs up 3rd Party hangs up SRC closes the recording session.

The Responder shall support the following Call Back scenario:

The SRC initiates an outbound call via recorded administrative line in response to a 911 hang-up or dropped call. The call between the Originating-Point and the Caller is recorded for its duration. The call flow for this scenario is: Call is initiated in response to 9-1-1 call that was disconnected due to hang-up or drop SRC opens a recording session with the recorder, including the call identifier Call is answered by the previously disconnected caller Call stream is added to the recording session Both parties communicate Called party hangs up SRC Originating Point hangs up SRC closes the recording session.

Call Back (Outgoing Call)


SEND-EIDD 0100-0100


SEND-EIDD 0200-0100


SEND-EIDD 0300-0100


SEND-EIDD 0400-0100

When a relevant change in Incident information occurs, an EIDD must be sent to communicating FEs, within the constraints of any installed filter. What constitutes a relevant change will be determined in future work.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 89 of 115


Functional Element

ExternalRequirement

Num (if supplied)



35620 3.4.2 Logging Service EIDD

35630 NENA-STA-10.2 5.13.0 Logging Service ElementState

35640 NENA-STA-10.2 5.13.3.1 Logging Service Extenions

35650 3.7.7 Logging Service Fault Tolerence

35660 3.2 Logging Service GEN 2700-0100 FEs that log events must do so as specified in the Logging Service section of NENA-STA-010.2.

35670 3.7.7 Logging Service

35680 3.7.7 Logging Service High Availability The Logging Service shall support high availability of logged data.

35690 NENA-STA-10.2 5.13.0 Logging Service Incoming Call

35700 NENA-STA-10.2 5.13.2.1 Logging Service Incoming Call

35710 NENA-STA-10.2 5.13.5 Logging Service






35770 NENA-STA-10.2 5.13.3.1 Logging Service LogEvent


35790 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 35800 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the AgentStateChange event.



SEND-EIDD 0500-0100

When an agency receives a call, the first FE handling the associated Incident must send an EIDD to the logger. This requirement also applies when an Incident is communicated through some means other than a call.Each Logging Service functional element shall implement the server-side of the ElementState event notification package.

Logging services shall not require any specific extension to provide services conformant to this document. Funcional elements that use a logging service shall not depend on a logging service accepting an extension to provide services conformant to this document. Each EventType contains additional data specific to the EventType.


LOGGING 1400-0100

The Logging Service shall support the fault tolerance mechanisms defined in the Logging Service section of NENA-STA-010.2.


Functional Element


Functional Element

LOGGING 0200-0100

The Logging Service shall support all of the interfaces defined in the Logging Service section of NENA-STA-010.2.


LOGGING 1300-0100

Media recording shall begin at the earliest point possible, which can be before the call has been answered if early media are available; recording media both at or near ESInet ingress and within a PSAP is desirable.

The Responder shall support the following incoming call scenario:

The SRC opens a recording session with the logging recorder. The call between the Caller and Answer-Point is recorded for its duration. The call flow for this scenario is: Call hits the SRC SRC opens a recording session with the recorder, including the call identifier Call is answered Call stream is added to the recording session Both parties communicate Caller hangs up Answer-Point hangs up SRC closes the recording session.

Instant Recall Recorder

The ability to quickly review current or recent emergency communications content shall be provided.


The client application shall support functions to retrieve media for display or playback. The client is expected to impose any additional limitations required by local policy, such as limiting recall to communications the user has handled, to specific communications types, and/or limiting the time period from which recent communications can be recalled.


The client shall provide functionality that allows the user to navigate within and between recalled communications. Access to media for instant recall is subject to the same security restraints as all log records. The PSAP may impose additional constraints on which agents may access media.


The ability to quickly review current or recent emergency communications content shall be provided.


The client shall impose additional limitations required by local policy, such as limiting recall to communications the user has handled, to specific communications types, and/or limiting the time period from which recent communications can be recalled. The client is also responsible for providing functionality that allows the user to navigate within and between recalled communications. Access to media for instant recall is subject to the same security restraints as all log records. The PSAP may impose additional constraints on which agents may access media.


The client shall provide functionality that allows the user to navigate within and between recalled communications. Access to media for instant recall is subject to the same security restraints as all log records. The PSAP may impose additional constraints on which agents may access media.

The LogEvent object contains an extension point that may be used to log any proprietary data in a logger. The namespace that defines the extension is included in the LogEvent object and the LogEvent may contain any object defined in that namespace. Each LogEvent defined in this document contains an extension point for that LogEvent, which allows logging of additional proprietary data. The size of any object, with all its extensions, may be limited to a provisionable value by the logging service, and the operator of a logging service may have a whitelist or blacklist of allowed extensions.

The Logger functional element shall support the AdditionalAgency: When an agency becomes aware that another agency may be involved, in any way, with a call, it shall log an AdditionalAgency event. The AdditionalAgency event includes an <AdditionalAgencyId> tag which is an Agency Identifier (see NENA-STA-10.2 Section 3.1.1). Among other uses, this event is used by PSAP management to query all Logging Services that may have records related to a call or incident.The Logger functional element shall support the AdditionalDataQuery request and AdditionalDataResponse response.

The Logger functional element shall support the ALILocationQuery request and ALILocationResponse response.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 90 of 115


Functional Element

ExternalRequirement

Num (if supplied)



35820 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 35830 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the CallSignalingMessage event.35840 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the CallStateChange event.35850 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the ClearIncident event.35860 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the DiscrepancyReport event.35870 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the EIDD event.35880 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the ElementStateChange event.

35890 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 35900 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the GatewayCallEvent event.35910 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the Hookflash event.35920 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the KeepAliveFailure event.35930 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the LegacyDigits event.35940 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the LinkIncident event.




35980 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 35990 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the LoSTquery event.36000 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the LoSTresponse event.36010 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the MalformedMessage event.36020 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the MergeIncident event.

36030 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 36040 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the QueueStateChange event.36050 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the RecordingFailed event.36060 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the ReopenIncident event.

36070 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 36080 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the SecurityPostureStateChange event.36090 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the ServiceStateChange event.36100 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the SiprecMetadata event.36110 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the SplitIncident event.


Each element that is not call stateful, but handles a call, shall log a CallProcess event of the INVITE or MESSAGE. There are no parameters to “Call Process”. FEs that log CallProcess also log the actual SIP message with CallSignalingMessage.

EndMedia:EndMedia signals that media streams stopped. The EndMedia event shall include one or more <MediaLabel> tags that shall match the SDP labels in the corresponding StartMedia event. More than one EndMedia (with different <MediaLabel>s) may occur for a call. This event is logged by any media anchor (call recipient for an emergency call, caller for a call back, bridge or BCF if the BCF anchors media) for the communication session media. A <MediaQualityStats> tag contains tags that give QoS statistics about the media stream. The content of <MediaQualityStats> contains the “SessionReport” element from RFC 6035. <MediaQualityStats> shall be supported by all media anchors.

StartRecCall/EndRecCall is identical to StartCall/EndCall, but is logged by the logging service (SRS) and the client (SRC) for the siprec recording session.The Logger functional element shall support the LocationQuery request and LocationResponse response.LogEvent function shall assign a globally unique LogIdentifier to each LogEvent and returns the LogIdentifier in its response.

The form of a LogIdentifier shall be a URI consisting of the string “urn:nena:uid:logid:”, a unique string, the “:” character and the domain name of the Logging Service. The unique string shall be between 10 and 35 characters long and unique to the Logging Service. An example LogIdentifier is “urn:nena:uid:logid:0013344556677-231:logger.state.pa.us”. The domain specified shall be the domain of the Logging Service to which the appropriate RetrieveLogEvent can be sent.

The Logger functional element shall support the SIP Message logging.: A SIP Message is logged with a Message log event. Elements that log Message shall also log the actual SIP message with CallSignalingMessageThe text of the message is included as a <text> parameter. A <direction> tag has one of two value “incoming” and “outgoing”. MSRP is logged with SIPREC.

Route: Proxy servers that make routing decisions (ESRPs or other SIP proxy servers in the path of the call) shall log the route it selected with the Route EventType. The URI where it decided to send the call (encoded in a <RouteUri> tag, plus a text string <RouteReason> for choosing that route are included in the LogEvent. For ESRPs, the name of the rule is included in a <RouteRule> tag.

StartCall/EndCall: Each functional element that is call stateful logs the beginning and end of its processing of a call, including non-human-initiated calls, with Start Call and End Call events. Elements that log StartCall/EndCall shall also log the actual SIP message with CallSignalingMessage for SIP parts of a call and GatewayCallEvent for TDM parts of a call. For StartCall and EndCall, the Timestamp shall be the time the INVITE, MESSAGE, BYE or equivalents to these messages, or the final error code was received or sent by the element logging the event. Both StartCall and EndCall shall be logged upon receipt of MESSAGE. A <CallDirectionValuesCode> tag has one of two values “incoming” and “outgoing”, where “incoming” means a call received from the ESInet and “outgoing” means a call placed by, for example, a PSAP towards some caller. Optional <StartCallStandardPrimaryCallType>, <StartCallStandardSecondaryCallType> and <StartCallLocalCallType> tags may be included in StartCall. The <StartCallStandardPrimaryCallType> and <StartCallStandardSecondaryCallType> tags are limited to values found in the LogEvent Call Type Registry [11.16] <StartCallLocalCallType> can have any value defined locally. Optional <StartCallLocalUse> elements are also available (limited to 128 bytes each). When StartCall is used with non-SIP interfaces, <to> and <from> tags are used to capture the participants in the call.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 91 of 115


Functional Element

ExternalRequirement

Num (if supplied)





36150 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent 36160 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support the UnLinkIncident event.36170 NENA-STA-10.2 5.13.3.2 Logging Service LogEvent The Logger functional element shall support theThe UnMergeIncident event.













36300 NENA-STA-10.2 5.13.6 Logging Service The LogEventReplicator shall have interfaces identical to LogEvent.



36330 NENA-STA-10.2 5.13.6 Logging Service The replicator shall replicate LogEvents exactly as they were received without modifying any field.

StartMedia: StartMedia contains information about one call medium (voice, video or RTT/MSRP text). The media event includes a text string <SessionDescriptionProtocol> tag that contains an RFC 2327 Session Description Protocol description of the media codecs as negotiated. The StartMedia event shall include one or more <MediaLabel> tags that shall match the SDP labels if they exist. More than one Media event can occur for a call. Recorded media streams include integral time reference data within the stream. This event is logged by any media anchor (call recipient for an emergency call, caller for a call back, bridge or BCF if the BCF anchors media) when at the start of media reception or transmission as appropriate. A <DirectionValuesCode> tag has one of two value “incoming” and “outgoing”.

StartRecMedia and EndRecMedia are identical to StartMedia/EndMedia but apply to the SIPREC recording session. Both the SRC and SRS log StartRecMedia/EndRecMedia. If an entity receives a media stream where it transcodes to another stream, including receiving TTY tones as audio, the entity transcoding creates a SIPREC recording stream for the transcoded media it creates, and logs StartRecMedia for it. The <MediaLabel> tags shall be the same as those in the StartMedia/EndMedia so that matching of streams is possible. If the SRC mixes audio from multiple streams, the MediaLabel is composed from the MediaLabels used in the originating streams, concatenated with a “+” between them. A <MediaTranscodeFrom> tag is used in this case containing the RFC 4575 label of the original incoming stream. Absence of the tag indicates no transcode is performed. For TTY received as audio, the recorded stream would be Real Time Text.

TransferCall: When a call is transferred, the transfer shall be logged by the transferor (the entity that had the call prior to transferring it). The transfer target URI is logged in a <TransferCallTarget> tag. Elements that log TransferCall shall also log the actual SIP <TransferCallTargetSipCallId> tag that contains the SIP CallId of the new session with the transfer target, when known. Note that the PSAP may not know this CallId, but the bridge would.Note: Mechanisms to support blind and supervised transfer are not defined in this document and will be standardized in a future revision of this document. Logging of such transfers is still required.

The Logger functional element shall support the RetrieveLogEvent to retrieve a logged event from the Logging Service.Policy shall control who can retrieve logged events from the Logging Service. The policy of the element/agency that logged the event governs what entities can retrieve the event.The Logger functional element shall support the ListAgenciesByCallId which returns a list of agencies involved in a call, including those referenced in AdditionalAgency events for the call.

The Logger functional element shall support the ListAgenciesByIncidentId which returns a list of agencies involved in an Incident, including those referenced in AdditionalAgency events for all calls associated with the Incident.

The Logger functional element shall support the RetrieveTextConversation which returns an HTML formatted record suitable for human consumption of the text portion of a call, including all text sent by all parties. A label preceding the text sent identifies the sender of the text. A time stamp of the start of the text is included in the label.The Logger functional element shall support the ListLogEventsByCallId which returns a list of LogIdentifiers that have a specified Call Identifier. The Logger functional element shall support the ListLogEventsByIncidentId which returns a list of LogEvents that have a specified Incident Tracking Identifier. The Logger functional element shall support the ListCallsbyIncidentId which returns a list of Call Identifiers associated with a specific Incident Tracking Identifier.

The Logger functional element shall support the ListIncidentsByDateRange which returns a list of Incident Tracking Identifiers occurring within a time/date range. The request includes a <StartDateTime> Timestamp and an <EndDateTime> Timestamp. A variety of times are logged against an Incident.

The Logger functional element shall support the ListIncidentsByLocation which returns a list of Incidents that occurred within a specified geographic region. The request includes a GML shape in a <AreaOfInterestRequest> tag. A variety of locations are logged against an Incident. This function returns an Incident if any location logged against the Incident intersects any part of the areaOfInterest. A combination of ListIncidentsbyDateRange and ListIncidentsByLocation, the request includes a <StartDateTime>, <EndDateTime> and <AreaOfInterestRequest>.

The Logger functional element shall support the ListCallsByDateRange which returns a list of Call Identifiers occurring within a time/date range. The request includes a <StartDateTime> Timestamp and an <EndDateTime> Timestamp.

LogEventReplicatorLogEventReplicator

The LogEventReplicator shall take a stream of LogEvents on its input port(s) and replicate them to each of its provisioned output ports.

LogEventReplicator

The LogEventReplicator output ports shall be connected to the logging service, in which case all functional elements that log would send their LogEvents to the replicator, which would copy them to the logging service and the other devices connected to the replicator.

LogEventReplicator

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 92 of 115


Functional Element

ExternalRequirement

Num (if supplied)






36370 3.7.7 Logging Service LogEvents

36380 NENA-STA-10.2 5.13.0 Logging Service Logging Service

36390 NENA-STA-10.2 5.13.0 Logging Service Logging Service36400 NENA-STA-10.2 5.13.1 Logging Service Logging Service The Logging Service shall incorporate a web service that supports logging and retrieving events.

36410 NENA-STA-10.2 5.13.1 Logging Service Logging Service

36420 3.7.7 Logging Service Media

36430 3.7.7 Logging Service Playback



36460 3.7.7 Logging Service Playback The Logging Service shall support a media seek function for audio, video and text media.

36470 3.7.7 Logging Service Radio Media

36480 NENA-STA-10.2 5.13.0 Logging Service Redundancy

36490 3.7.7 Logging Service Retain

36500 3.7.7 Logging Service Retention Policy

36510 3.7.7 Logging Service Retention Policy

36520 NENA-STA-10.2 5.13.2 Logging Service RTCP

36530 3.7.7 Logging Service Screen Capture


36550 NENA-STA-10.2 5.13.2.6 Logging Service Shutdown

36560 NENA-STA-10.2 5.13.3.1 Logging Service SIP

36570 NENA-STA-10.2 5.13.2 Logging Service SIPREC

LogEventReplicator

Replicators shall have filtering capability to restrict which events are sent to which ports, but such filtering is not otherwise standardized.

LogEventReplicator

Each event received by the replicator shall be sent to each of the output ports, subject to such filtering.

LogEventReplicator

Each event received by the replicator shall be sent to each of the output ports, subject to such filtering. One of the output ports is designated the “master” port. When a transaction is started on the input port, the replicator starts the transaction on all of its output ports. Whatever response is returned from the master port is used as the response from the replicator to the input port. All other responses are ignored. If the logging service is connected to a replicator output port, normally it would be on the master port.


LOGGING 0100-0100

The Logging Service shall support logging of all LogEvents that occur within the PSAP as defined in the NENA LogEvent registry, and any required additional data associated with them.

Since incidents may involve multiple agencies, obtaining logging records from multiple logging services may be required. The Agency Locator record includes the URI to the logging service for a particular agency. Does the Responder support the use of the Agency Locator as described here?

ESInets can be built with logging services either local or centralized, and less commonly a mix of both local and state level logging services. Accordingly, each ESInet that provides an IMR service shall implement ServiceState for that ESInet.

Logging Services shall implement a Session Recording Protocol (SIPREC) interface (RFC 7866) for recording the media and associated metadata, and provide a Real Time Streaming Protocol (RTSP) (RFC 2326) interface to play back the media.


LOGGING 0300-0100 T

he Logging Service shall support logging of all media that terminates in, or originates from, the PSAP.


LOGGING 0400-0100

The Logging Service shall support playback of multiple audio streams and/or audio mixing (combining of multiple audio streams into a single stream for playback, i.e. bridging).


LOGGING 0500-0100

The Logging Service shall support playback of multiple video streams and/or video mixing (combining of multiple video streams into a single stream for playback, i.e. compositing).


LOGGING 0600-0100

The Logging Service shall support playback of multiple text streams mixed into a single stream together with identification of parties and timing.


LOGGING 0700-0100


LOGGING 0900-0100

The Logging Service shall support acquisition of radio media and metadata via the Radio Interface as described in the Radio Interface section.Clients to the logging service shall support logging to at least three or more loggers for redundancy purposes.


LOGGING 1200-0101

Log records must be retrievable from the Logging Service FE for as long as the records are retained by the Agency.


LOGGING 1700-0100

The Logging Service shall support retention policies for logged data that retains and deletes data as required.


LOGGING 1800-0100

The Logging Service shall support “protect from deletion” functionality that allows certain logged data to be marked to prevent deletion when its retention period has expired.

All SRCs and SRSs shall implement RTCP on the recording session. The SRC shall send NTP time in sender reports, which shall be recorded by the SRS. This allows media synchronization of multiple media streams on playback.


LOGGING 1100-0100

The Logging Service shall support acquisition of display data (i.e. screen capture) with timing information.

Session Recording Server

The Logging Service shall act as a Session Recording Server (SRS) and accept media and metadata from a Session Recording Client (SRC) as defined in the Session Recording Protocol (RFC 7866).

The Responder shall support the following Clean Logging Service Shutdown scenario:

The Logging Recorder shall be able to provide a clean shut down by sending a BYE as specified in NENA-STA-10.2 Section 4.1.01.3, for example when one SRS in a redundant pair is going out of service. The SRC shall respond with a 200 OK. Call hits the SRC SRC opens a recording session with the recorder, including the call identifier Call is answered Answer-Point stream is added to the recording session Both parties communicate Recorder sends a BYE SRC responds with a 200 OK.

The CallIdURN and IncidentIDURN shall be provided on all legs of a dialog-forming SIP transaction initial message (INVITE or MESSAGE). Stateless proxies may not know the IDs and thus may not be able to provide them, and some implementations may not be able to provide the IDs on other messages in the transaction. The logger will need to track such messages (via the SIP call identifier) and log the Call and Incident IDs.

The logging recorder that supports the Session Recording Server (SRS) functionality defined in the SIPREC specification (RFC 7866) interfaces to any Functional Element that supports a Session Recording Client (SRC).

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 93 of 115


Functional Element

ExternalRequirement

Num (if supplied)



36580 NENA-STA-10.2 5.13.2 Logging Service SIPREC36590 NENA-STA-10.2 5.13.2 Logging Service SRC SRCs shall support recording of media to at least two SRSs.

36600 NENA-STA-10.2 5.13.2 Logging Service SRC interface

36610 NENA-STA-10.2 5.13.2 Logging Service SRC interface

36620 NENA-STA-10.2 5.13.0 Logging Service Subscribers

36630 NENA-STA-10.2 5.13.2.2 Logging Service Three Party Call

36640 3.7.7 Logging Service Time

36650 NENA-STA-10.2 5.13.5 Logging Service Web Service36660 NENA-STA-10.2 5.13.5 Logging Service Web Service The Logging Service’s Web Service interface shall support the recall of all defined media types.

36670 3.4.3 Call Handling

36680 3.4.3

36690 3.4.3

36700 3.4.3

36710 3.4.3 Element State

36720 3.4.3 Interfaces The Management Console interfaces shall be discoverable.

36730 3.4.3 Security Posture

36740 3.4.3 Service State

36750 3.4.3 System Alarms

36760 NENA-STA-10.2 5.05.0 ElementState The MCS shall implement the server-side of the ElementState event notification package.

36770 NENA-STA-10.2 5.05.0 Logging The MCS service logs the invocation of the function, as well as the input and output objects.

36780 NENA-STA-10.2 5.05.0 ServiceState The MCS shall implement the server-side of the ServiceState event notification package.



36810 NENA-STA-10.2 13.0 Data Dictionaries The Responder shall support the NENA XML Registry as described in NENA-STA-10.2 Section 13.36820 NENA-73-501 3.2 Non-Voice Centric Device 0200-0100 An NVC Emergency Services device shall be voice capable.

36830 NENA-73-501 3.2 Non-Voice Centric Device 0200-020036840 NENA-73-501 3.2 Non-Voice Centric Device 0200-0300 An NVC Emergency Services device shall be able to receive a voice call from a PSAP.

The SRC and the Logging Service acting as the SRS shall support the SIPREC Metadata interface (RFC 7865). The Logging Service creates a SiprecMetadata LogEvent to log this metadata (see the LogEvent section for details). Each emergency call (that is, each Communication Session), shall result in a separate Recording Session.

Any element that has call media, including MSRP, shall deploy the SRC interface and at least one element in the call path shall deploy the SRC interface.All Bridge elements (NENA-STA-10.2 Section 5.7), Gateway elements (NENA-STA-10.2 Section 7) and BCF elements that anchor media shall implement the SRC interface. The Logging Service functional element shall promptly report changes in its state to its subscribed elements.

The Responder shall support the following Three Party call scenario:

The Answer-Point establishes a two party call and conferences in a third party. The call shall still be recorded while the third party is being added as well as when all three parties are on the call. Call hits the SRC SRC opens a recording session with the recorder, including the call identifier Call is answered Call stream is added to the recording session Both parties communicate Answer-Point calls 3rd Party Call is answered by 3rd Party Re-invite is sent to the recorder with the call identifier 3rd Party stream is added to the recording session All parties communicate Caller hangs up 3rd Party hangs up Answer-Point hangs up SRC closes the recording session.


LOGGING 0800-0100

The Logging Service shall support synchronizing of multiple played back media streams to each other and to original Network Time Protocol (NTP) (RFC 1305) time.The Logging Service’s Web Service interface shall support the capability to query, retrieve any stream media functions.


Management Console

MANAGEMENT 0500-0100

An interface between the Management Console FE and the Call Handling FE is required to allow the Management Console FE to control whether diverted calls are accepted by the Call Handling FE, as described in the Dequeue Registration Event Package section of NENA-STA-010.2. The Call Handling FE is responsible for informing the Terminating ESRP of this status.


Management Console

Discrepancy Report


The Management Console shall receive discrepancy reports from sources outside and inside of the Agency.


Management Console

Discrepancy Report


The Management Console shall support sending and receiving Status Updates and Status Update Requests as described in the Discrepancy Reporting section of NENA-STA-010.2.


Management Console

Discrepancy Report Web Service


The Management Console shall host a Discrepancy Report Web Service for the agency as described in the Discrepancy Reporting section of NENA-STA-010.2.


Management Console


An interface between the Management Console FE and all PSAP Fes shall be required so those FEs can report their Element State and/or Service State to the Management Console.


Management Console



Management Console


The Management Console shall implement the Security Posture notification as described in the Security Posture section of NENA-STA-010.2.


Management Console


The Management Console shall report the PSAP’s Service State to entities inside or outside the PSAP.


Management Console


The Management Console must implement the receiver side of the alarm interface as described in the System Alarms Section.

MSAG Conversion ServiceMSAG Conversion ServiceMSAG Conversion ServiceMSAG Conversion Service

The Responder's solution shall provision an MSAG Conversion Service (MCS) web service that provides conversion between PIDF-LO and MSAG data.

MSAG Conversion Service

The MCS shall support the web service PIDFLOtoMSAGRequest request and PIDFLOtoMSAGResponse response.

NENA XML Schema

An NVC Emergency Services device shall be capable of detecting an emergency service request and marking it (e.g., in a similar manner as an NG9-1-1 voice call) for the benefit of the serving network.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 94 of 115


Functional Element

ExternalRequirement

Num (if supplied)



36850 NENA-73-501 3.2 Non-Voice Centric Device 0200-0400







36920 NENA-73-501 3.1 Non-Voice Centric 0100-0700

36930 NENA-73-501 3.1 Non-Voice Centric General 0100-0500

36940 NENA-73-501 3.4 Non-Voice Centric IP Network 0400-0100










37040 NENA-73-501 3.1 Non-Voice Centric Location 0100-0600

37050 NENA-73-501 3.1 Non-Voice Centric Media 0100-0200

37060 NENA-73-501 3.1 Non-Voice Centric Media 0100-0300

37070 NENA-73-501 3.1 Non-Voice Centric Message 0100-0400

37080 NENA-73-501 3.3 Non-Voice Centric 0300-0100 It shall be possible to authenticate the end user device subject to regional regulatory requirements.




An NVC Emergency Services device shall be able to download available destinations (e.g. – dial string, service URN) for emergency call detection.An NVC Emergency Services device shall be pre-loaded with at least one application suitable for NVC Emergency Services.Once a device is aware that a NVC Emergency Services session has been initiated, the device shall (subject to user configuration) avoid drawing unnecessary attention to the user (e.g., playing audible tones or flashing brightly) and shall confirm this to the user in as private a manner as is reasonable, such as using text on the screen or audio if headphones are already connected. Behavior in an emergency text situation may need to be different relative to the normal configuration.

When roaming, an NVC Emergency Services device shall originate NVC Emergency Services using the same network (e.g., home or visited) in a manner similar to next generation emergency voice communications.The NVC Emergency Services device shall clearly differentiate emergency text sessions from non-emergency text sessions on the user display.

The NVC Emergency Services device shall be able to deliver recorded media in a form that allows progressive playback. (It is desirable that all pre-recorded media sent during an emergency be progressively viewable.)When adding additional media to an existing session, the user must be made aware when additional media is requested by the PSAP, and must be able to permit or deny it.

End-to-End General

NVC Emergency Services is not a subscription service. Access to NVC Emergency Services shall be available to all end users utilizing NVC Emergency Services capable devices.

NVC Emergency Services is an enhancement to next-generation emergency capabilities. Because not all networks, devices, and PSAPs will be enhanced at the same time, a mechanism must be developed to inform end users whether NVC Emergency Services are available for use to report an emergency (e.g., if there is an available i3 PSAP) . It is desirable for users to be informed before attempting to make NVC emergency services call.In NVC Emergency Services situations, the NG9-1-1 i3 / ESInet shall provide a capability to route to an alternate PSAP when necessary.Within an NG9-1-1 i3 / ESInet, all NVC Emergency Services attempts shall be logged and the data made available as required by the PSAP.An NG9-1-1 i3 / ESInet shall be able to transfer NVC Emergency Services content to an appropriate alternate destination if the situation is not an emergency.

During an emergency session, the NG9-1-1 i3 / ESInet must deliver subsequent NVC Emergency Services content to the same PSAP as the initial content and call setup signaling at the beginning of the non-voice emergency session.The NG9-1-1system shall have the capability to associate all emergency sessions and content with the originating caller.The PSAP shall be able to acknowledge setup of the NVC Emergency Services session back to the originating caller.The NG9-1-1 i3 / ESInet shall be responsible for routing NVC Emergency Services sessions to the appropriate PSAP.Within an NG9-1-1 i3 / ESInet, it shall be possible to associate non-voice sessions and voice calls from the same caller together.Detailed log records of a NVC Emergency Services session shall be generated by an NG9-1-1 i3 / ESInet.The NG9-1-1 i3 / ESInet shall be responsible for any logging of multi-media that may be needed for post processing.

Delivery of location information to PSAPs associated with a NVC Emergency Services session shall be protected against unauthorized disclosure and alteration in a similar manner to next generation voice emergency services. NVC Emergency Services data not provided by the origination network cannot be attested to or vouched for by the network operator.

NVC Emergency Services may support real-time session-based text and other multi-media (e.g., file transfer of pictures or pre-recorded video clips), real-time video services, and supplementary real-time audio (e.g., background sound) or video.

An originating network or end user device may support some or all media types, and support of any specific media by an origination network or end user device may be subject to regional regulatory requirements.

NVC Emergency Services shall support, subject to regional regulatory requirements, text-based communication using Real-Time Text (RTT) [RFC4103] and Session Initiation Protocol (SIP) SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) (session mode) [RFC4975, RFC4976]. Support of Extensible Messaging and Presence Protocol (XMPP) [RFC3920, RFC3921] and SIP SIMPLE (pager mode) [RFC3428] shall be considered as a future study item.

Origination NetworkOrigination Network

It shall be possible to provide integrity protection, and/or privacy for NVC Emergency Services similar to what will be provided for next generation voice emergency services.

Origination Network

NVC Emergency Services shall transport location information to the PSAP in the same manner as next generation voice emergency services

Origination Network

The origination network may provide a capability to enable a NVC Emergency Services device to obtain local emergency numbers or other emergency address(es) (e.g., destination address) in the same manner as next generation voice emergency services.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 95 of 115


Functional Element

ExternalRequirement

Num (if supplied)












37210 NENA-73-501 3.1 Non-Voice Centric Support 0100-0100

37220 NENA-STA-10.2 5.19.2

37230 NENA-STA-10.2 5.19.1 SIP Call Interface

37240 NENA-STA-10.2 5.19.3 SIP Call Interface

37250 3.6.2 Outgoing Alert CAP The Outgoing Alerts interface shall use the Common Alerting Protocol (CAP v1.2).

37260 3.6.2 Outgoing Alert Distributors

37270 3.6.2 Outgoing Alert Distributors The Notifier shall be able to select Distributors.



37300 3.6.2 Outgoing Alert Distributors The Outgoing Alert Functional Element shall provide a mechanism to manage a list of Distributors.

37310 3.6.2 Outgoing Alert Distributors The Outgoing Alert Functional Element shall log alerts sent and acknowledgement received.

37320 3.6.2 Outgoing Alert Distributors The unique identifier shall accompany all requests and acknowledgements.


37340 3.6.2 Outgoing Alert EIDD

37350 3.6.2 Outgoing Alert Groups

37360 3.6.2 Outgoing Alert IPAWS-OPEN

37370 3.6.2 Outgoing Alert Notifier There shall be a unique identifier assigned to a notification request.

37380 NENA-REQ-002.1 4.5 BCF

37390 NENA-REQ-002.1 4.5 BCF BCF Operator shall produce a report to the 9-1-1 Authority and/or other authorized entities.

Origination Network

NVC Emergency Services shall be provided in the same network (e.g., home or visited) in a manner similar as for next generation emergency voice services.

Origination Network

NVC Emergency Services shall provide a high level of reliability and low delay in the delivery of signaling and content. (The quality of service requirements for specific media classes are reserved for future study.)

Origination Network

NVC Emergency Services shall utilize the same priority mechanisms as next generation emergency voice services.

Origination Network

Detailed log records of the NVC Emergency Services session shall be generated by the origination network in a similar manner to next generation emergency voice services. Note: Media is not required to be logged in the origination network.

Origination Network

NVC Emergency Services shall support any kind of emergency numbers, emergency SIP and TEL URIs and special indications for emergency sessions within the SIP signaling in the same manner as next generation voice emergency services.

Origination Network

In cases where a NVC Emergency Services device can't detect an emergency service request, the emergency session shall still be detected and supported by an origination network that supports NVC Emergency Services.

Origination Network

All emergency content shall be carried with an indication of the source, in a similar manner as for next generation emergency voice services.

Origination Network

During an emergency session, the origination network must deliver subsequent NVC Emergency Services content to the same ESInet as the initial media and call setup signaling at the beginning of the non-voice emergency session.

Origination Network

The origination network shall be responsible for routing NVC Emergency Services signaling and content to the appropriate ESInet.Entities which support the use of NVC Emergency Services shall support end user initiated two-way emergency communications between end users and emergency authorities.

Origination Networks

Additional Data Repository

Origination networks that are also access networks are expected to provide a Location Information Server (LIS) function that provides location validation and location dereferencing if Location by Reference (LbyR) is supplied meeting the requirements of NENA-STA-10.2 Section 5.10.


The origination network is expected to present emergency calls to the ESInet meeting the ESInet SIP interface specified in NENA-STA-10.2. All calls will be signaled with SIP, shall contain a Geolocation header, and shall be routable by the ECRF using the location contained in, or referenced by the Geolocation header.


Origination networks and devices presenting calls to ESInets are expected to provide an Additional Data Repository interface meeting the requirements of NENA-STA-10.2 Section 5.11 unless they always send Additional Data by value.


OUTGOINGALERT 0200-0100



There shall be a standardized interface between the Notifier and one or more Distributors (entities, typically outside the ESInet, that deliver alerts to targeted devices).





An acknowledgment mechanism shall be specified for the Distributor to inform the notifier that the alert has been distributed.



Interface shall support specification of distribution by affected area (geo-targeting), pre-determined groups, opt-in and opt-out (including opt-in to a geo-targeted alert using a supplied location), or any combination of these options. This requirement does not impose requirements on any given Distributor to allow all such targeting options.









To support alerts to emergency services personnel or entities, an acknowledgment mechanism shall be provided that allows a Distributor to inform the Notifier that an alert has been acknowledged by an individual target.



The Outgoing Alert Functional Element shall support receiving EIDDs in order to provide information about a notification.



The Notifier shall be able to classify targeted devices into groups and to specify which groups are to receive the alert.



The interface shall be compatible with IPAWS-OPEN such that alerts may be sent through IPAWS-OPEN to existing distribution mechanisms.



Performance Statistics Report

BCF-PSR 0100-0000

Performance Statistics ReportA statistical report summarizing the volume of ingress and egress traffic running through the BCF.


BCF-PSR 0100-0100

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:12 96 of 115


Functional Element

ExternalRequirement

Num (if supplied)



37400 NENA-REQ-002.1 4.5 BCF

37410 NENA-REQ-002.1 4.5 BCF

37420 NENA-REQ-002.1 4.7

37430 NENA-REQ-002.1 4.7

37440 NENA-REQ-002.1 4.7

37450 NENA-REQ-002.1 4.7

37460 NENA-REQ-002.1 4.4 ECRF

37470 NENA-REQ-002.1 4.4 ECRF ECRF Operator shall produce one or more reports to 9-1-1 Authority(s) or authorized entities.

37480 NENA-REQ-002.1 4.4 ECRF

37490 NENA-REQ-002.1 4.4 ECRF

37500 NENA-REQ-002.1 4.3 ESRP

37510 NENA-REQ-002.1 4.3 ESRP ESRP Operator shall produce a report for 9-1-1 Authority and Originating Network Provider


BCF-PSR 0100-0200

Minimum content of the report shall include:o Reporting party’s contact informationo Reporting time periodo Performance statistics• Volume of ingress and egress• Volume of blocked traffic by blockage issue• Volume of BadActorRequest received• Volume of BadActorRequest honored (policy applied to the sourceId)• Volume of CallSuspicion submitted per score


BCF-PSR 0100-0300

Report available monthly at a minimum or as requested for 9-1-1 Authority and/or authorized entities.


Discrepancy Report Statistics

DR-PSR 0100-0000

Performance Statistics Report:Any element that receives or produces a discrepancy report shall provide a summary report that captures quantity received, created, and resolution timeline. Breakdown of discrepancy reports resolved within or exceeding recommended timeframe as noted in Discrepancy Report documentation.



DR-PSR 0100-0100

Entity responsible for any element that produces or receives a discrepancy report shall produce a report to the 9-1-1 Authority and/or authorized entity.



DR-PSR 0100-0200

DR-PSR 0100-0200 Minimum content of the report shall include:o Reporting party’s contact informationo Reporting time periodo Performance statistics broken down by reports produced or received by entity• Discrepancy Report Produced Quantity produced Grouped by type of discrepancy report Grouped by entity reported to

• Discrepancy Report Received Quantity of Discrepancy Reports resolved within recommended timeframe Quantity of Discrepancy Reports resolved beyond recommended timeframe Quantity of Discrepancy Reports unresolved Grouped by type of discrepancy report



DR-PSR 0100-0300

Report available monthly at a minimum or as requested for 9-1-1 Authority and/or authorized entities


ECRF-PSR 0100-0000

Performance Statistics ReportA statistical report summarizing the number of ECRF queries and query responses.


ECRF-PSR 0100-0100


ECRF-PSR 0100-0200

Minimum content of the report shall include:o Reporting party’s contact informationo Reporting time periodo Performance statistics• Total number of queries received by ECRF• Total number of queries by type <findService> < getServiceBoundary> <listServicesByLocation> <listServices>• Total number of Warning and Error* messages received from ECRF• Number of each Warning and Error* messages returned for each query type• Breakdown of ECRF response times by query type for iterative queries For response time oriented statistics: Average (mean) % of transactions between 130-145% of the Average (approximately one standard deviation from average) % of transactions greater than 145% of the Average (approximately two standard deviations from average)• Breakdown of ECRF response times by query type for recursive queries For response time oriented statistics: Average (mean) % of transactions between 130-145% of the Average (approximately one standard deviation from average) % of transactions greater than 145% of the Average (approximately two standard deviations from average)* Warning and Error messages as defined in IETF RFC52223.


ECRF-PSR 0100-0300

Report available monthly at a minimum or as requested for 9-1-1 Authority and/or authorized entities.


ESRP-PSR 0100-0000

Performance Statistics ReportA statistical report summarizing the success and error type codes of the ESRP routing processes and ECRF queries.


ESRP-PSR 0100-0100

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 97 of 115


Functional Element

ExternalRequirement

Num (if supplied)



37520 NENA-REQ-002.1 4.3 ESRP

37530 NENA-REQ-002.1 4.3 ESRP

37540 NENA-REQ-002.1 4.6 GIS GIS-PSR 0100-000 Any functional element receiving GIS data shall provide a statistical report of its GIS transactions.

37550 NENA-REQ-002.1 4.6 GIS

37560 NENA-REQ-002.1 4.6 GIS

37570 NENA-REQ-002.1 4.6 GIS

37580 NENA-REQ-002.1 4.1 LIS

37590 NENA-REQ-002.1 4.1 LIS

37600 NENA-REQ-002.1 4.1 LIS

37610 NENA-REQ-002.1 4.1 LIS Report available daily with an on-demand option for 9-1-1 Authority and other authorized entities

37620 NENA-REQ-002.1 4.2 LVF

37630 NENA-REQ-002.1 4.2 LVF


ESRP-PSR 0100-0200

Minimum content of report shall include:o Reporting party’s contact informationo Reporting time periodo Performance statistics• Number of successes• Error type code, including default, alternate, and contingency routing• Volume of Discrepancies reported• Summary of Discrepancy types• Date of Discrepancy


ESRP-PSR0100-0300

Report available monthly at a minimum or as requested for 9-1-1 Authority and/or Originating Network Provider.

Performance Statistics ReportPerformance Statistics Report

GIS-PSR 0100-0100

Functional Element Operator (e.g. LVF, ECRF), receiving GIS data for provisioning, shall produce a report to the 9-1-1 Authority and/or authorized entity.


GIS-PSR 0100-0200

Minimum content of the report shall include:o Reporting party’s contact informationo Reporting time periodo Number of GIS data transactions receivedo Number of successful transactionso Number of provisioning errors by type/code


GIS-PSR 0100-0300

Performance Statistics Reports shall be made available monthly at a minimum and/or as requested for 9-1-1 Authority and/or authorized entities.


LIS-PSR 0100-0000

Performance Statistics ReportA statistical report summarizing the LIS transaction volume of successes and failures for provisioning and call processing.The statistics in this report could be used for a variety of purposes including: overall operational management/oversight of the LIS performance, capacity monitoring/planning, troubleshooting data delivery issues, management of service level agreements, data quality assurance, service provider oversight/management, etc. Other uses are anticipated as use of the LIS becomes integral to data delivery.


LIS-PSR 0100-0100

LIS Operator shall produce a report containing transaction volume showing success and failure rate of provisioning and call processing functions for 9-1-1 Authority and other authorized entities


LIS-PSR 0100-0200

Minimum content for report shall include: o Reporting party’s contact information o Reporting time period o Validation Statistics for Provisioning • Total number of updates attempted • Total number of updates that pass validation • Total number of discrepancies o Call Processing Statistics • Total number of queries • Total number of responses handled o Summary of discrepancies by error description and Access Network Operator Statistics for location validation • Total number of individual record transactions attempted during reporting time period • Total number of successful individual record transactions • Total number of failed individual record transactions (e.g. no record found) • Summary of failed individual record transactions by error description • Total number of dereference attempts • Total number of dereference failures by error description


LIS-PSR 0100-0300


LVF-PSR 0100-0000

Performance Statistics Report:A statistical report summarizing the volume and accuracy of transactions occurring between the LIS and LVF. The report assists in defining the performance of the LVF. The statistics in this report could be used for a variety of purposes including: overall operational management/oversight of the LVF performance, management of service level agreements, data quality assurance, etc. Other uses are anticipated as use of the LVF becomes integral to data provisioning and call delivery.


LVF-PSR 0100-0100

The LVF Operator shall produce a report containing volume and accuracy of LVF transactions between the LIS and location validation and routing databases for the 9- 1-1 Authority and LIS Operator.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 98 of 115


Functional Element

ExternalRequirement

Num (if supplied)



37640 NENA-REQ-002.1 4.2 LVF

37650 NENA-REQ-002.1 4.2 LVF

37660 3.2 PIDF-LO Default Location GEN 2500-0100

37670 NENA-STA-10.2 4.3.2.2.0 Actions

37680 NENA-STA-10.2 8.1 Additional Data

37690 NENA-STA-10.2 4.3.2.1.03 Additional-Data

37700 NENA-STA-10.2 4.3.2.2.03 Busy Action The PRF shall support the <busy> element returns 600 Busy Everywhere to the caller.

37710 NENA-STA-10.2 4.3.2.1.06 Call Suspicion

37720 NENA-STA-10.2 4.3.2.1.12 CallSource The PRF shall implement the CallSource condition.

37730 3.4.2 EIDD

37740 3.4.2 EIDD

37750 3.2 Element State GEN 1500-0100 Policy must control which FEs are allowed to subscribe to Element State for a particular FE.

37760 NENA-STA-10.2 4.3.2.1.10 ElementState The PRF shall implement the ElementState condition.

37770 3.2.1 Each Agency shall have its own policies including security policies.

37780 NENA-STA-10.2 4.3.2.1.16 Incoming Queue The PRF shall implement the Incoming Queue condition.

37790 NENA-STA-10.2 4.3.2.1.05 Location

37800 NENA-STA-10.2 4.3.2.1.09 LoSTServiceURN The Policy shall implement the LoSTServiceURN condition.

37810 NENA-STA-10.2 4.3.2.1.04 MIME Body List

37820 NENA-STA-10.2 4.3.2.1.15 Normal-NextHop The PRF shall implement the Normal-NextHop condition.

37830 NENA-STA-10.2 4.3.2.2.04 Notify Action

37840 3.3


LVF-PSR 0100-0200

The minimum content of reports shall include:o Reporting party’s contact informationo Reporting time periodo Validation statistics: Statistic 1 is a quantity of LVF responses where allattributes are found to be valid. Statistic 2 is a quantity of LVF responses with at least one attribute to be found invalid. Specific attribute errors are identified in the Discrepancy Report section of this documento Total number of transactions during reporting time periodo Average response times of LVF querieso Percentage of response time within some interval (for example 90% of the time)


LVF-PSR 0100-0300

The report shall be available daily with an on-demand option for 9-1-1 Authority and LIS Operator(s).


An FE that receives a PIDF-LO containing a location marked as a "default location” shall ensure that the location is treated and processed appropriately.

Policy Routing Function

As stated in RFC 4745, conditions are the 'if'-part of rules, whereas actions form the 'then'-part. The actions and transformations parts of a rule determine which operations the proxy server shall execute on receiving a connection request attempt that matches all conditions of this rule. Actions and transformations permit certain operations to be executed.


Any of the additional data elements in (RFC 7852) or NENA 71-001 or its successor document, NENA STA-010.2 may be used by PSAP management to establish business rules and policies for call handling and routing.


The Policy shall implement the Additional-Data condition. The <additional-data> element contains four child elements: <type> which is a block type beginning with “EmergencyCallData.” <element> that contains a tag (element name) of one of the elements in the Additional Data blocks. <operator> which may be one of “=”, “<>”, “>”, “<”,”>=”, “<=” <content> a value to be compared with the <element> value using the <operator>A typical use for this element is to route based on the class of service components, or on language preferences.



The Policy shall implement the Call Suspicion condition that evaluates the spam-score header of the SIP message. The <callsuspicion> element has one child element, <score>: which indicates the spam score in the attributes "from" and "to".




SEND-EIDD 0700-0100

The transmission of an EIDD must comply with the data rights management policy of the agency that created the data. The data rights management policy must conform to local, state/provincial and federal laws and regulations.



SEND-EIDD 1500-0100

The FE sending an EIDD may send an EIDD by reference to those that have requested an EIDD by value if dictated by agency policy.


Policy Routing FunctionPolicy Routing Function



FEs Shared by Multiple Agencies

MULTI-TENANT 0100-0100


The Policy shall implement the Location condition that re-uses the location-based condition elements from RFC 6772 on the location used for routing.



The Policy shall implement the MIME Body List condition. The <mime-list> element contains one or more child <mime> child elements. Any mime type listed in the <mime> element is compared with the content of the incoming message.



The <notify> element has several child elements (<recipient>, <eventCode>, <urgency>, <severity>, and <certainty>) and sends a NOTIFY message containing a CAP message to any entity subscribing to the Normal-NextHop's ESRPnotify event for that reason code. This may be used, for example, to advise other entities that calls are being diverted, etc. If the <recipient> is a service URN, the CAP message is wrapped in a SIP MESSAGE and is routed via the ECRF to the proper recipients. All indicated child elements provide information on how to populate the CAP message.



Policy Routing of Calls and Incidents POLICY 0100-0100

Wherever a destination for a call or an EIDD must be selected from a list of destinations based on state, load, location, and similar factors, the choice of destination must be contained within a policy. Rationale: This requirement is to constrain implementations to provide a standardized mechanism for PSAP management to control routing within the PSAP and between PSAPs much like the ESRP Policy Routing Function controls routing of calls in the NGCS. Implementations may provide additional routing capability, but must support the standardized mechanism.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 99 of 115


Functional Element

ExternalRequirement

Num (if supplied)



37850 3.2 Policy Store GEN 0750-0100

37860 NENA-STA-10.2 4.3.0 Policy Store Policy shall be stored into and retrieved from the Policy Store using a web service.

37870 NENA-STA-10.2 4.3.0 Policy Store



37900 NENA-STA-10.2 4.3.0 Policy Store The policy retrieved shall be valid until the expiration time.





37950 3.2 GEN 0800-0100

37960 3.2 GEN 0900-0100

37970 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement a RetrievePolicy method.

37980 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement a MoreRetrievePolicy method.

37990 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement a StorePolicy method.

38000 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement a MoreStorePolicy method.

38010 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement an EnumeratePolicies method.

38020 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement an UpdatedPolicies method.

38030 NENA-STA-10.2 4.3.1.0 The Policy Store Web Service shall implement an EnumerateAgencies method.

38040 NENA-STA-10.2 4.3.1.0 The Policy Store shall be replicated and distributed.

38050 NENA-STA-10.2 4.3.2.1.09 Priority

38060 NENA-STA-10.2 4.3.2.2.01 Priority

38070 NENA-STA-10.2 4.3.2.1.08 QueueState The Policy shall implement the QueueState condition.

38080 NENA-STA-10.2 4.3.2.1.08 QueueState

38090 NENA-STA-10.2 4.3.2.1.14 Request URI The PRF shall implement the Request URI condition.

38100 NENA-STA-10.2 4.3.2.2.02 Route Action

38110 NENA-STA-10.2 4.3.2.0 The Policy shall be represented in an RFC 4745-compliant common policy schema.

38120 NENA-STA-10.2 4.3.2.0

38130 NENA-STA-10.2 4.3.2.0

38140 NENA-STA-10.2 4.3.2.0



Any FE that implements policy defined in a NENA and/or APCO standard to control its operation shall obtain such a policy from a policy store.



The "Policy Store Web Service" shall facilitate agencies uploading and retrieving policies. Policies are named by the function that defines the policy i.e., the DownstreamRoutingPolicy for an ESRP. A specific policy set is known by that name and the agency whose policy is being stored or retrieved. The authentication to the web service identifies the agency storing or retrieving policy sets in the store.


The Policy Store shall only accept or deliver complete policy sets, not individual rules within a policy set.


The Policy Store shall reduce the size of the chunk returned if it is unable or unwilling (by local policy) to serve a chunk as large as the requester specifies.



The PRF policy shall be retrieved again from the Policy Store If the policy is needed for use after expiration. The response may not return the policy requested. Instead, it may return a referral to another Policy Store that may have the policy.


The PRF data rights management system shall limit which agencies, agents or functions are permitted to retrieve policies for another agency.


The rights management policy shall allow an agency to store policies on behalf of another agency. The interface includes a chunking mechanism that can be used by either the client or the server to limit the size of an individual transaction.


The interface shall include a chunking mechanism that can be used by either the client or the server to limit the size of an individual transaction.



Policy Store Web Service

Any FE that implements a Policy Store as described in the Policy Store Web Service section of NENA-STA-010 must implement the server side of the policy web service functions as described therein.




Any FE that interfaces to an external policy store must implement the client side of the policy web service functions as described in NENA-STA-010.2.


















The ESRP shall use the SIP-based notification mechanism described in RFC 3265 to obtain the value of the variable.


Each rule shall contain an unsigned integer value to indicate its priority in the <priority> element. When the conditions of two rules evaluate to 'true' then the rule with the higher priority value wins i.e., the actions of that rule will be executed. Every rule shall have a unique priority value.


If the ESRP is unable to reach the queue, it would show the queue state as “unreachable” to the PRF.



The PRF action supported is forwarding of SIP messages to a specific URL. The <route> element contains two child elements namely <recipient> and <cause>, where <recipient> contains a URI that will become the Route header for the outgoing SIP message (the Request URI is normally a service URN), and the <cause> contains the value used with the Reason header associated with a History-Info header. The <recipient> element is mandatory, and the <cause> element is optional.The <cause> values are defined in a Registry that this document establishes (NENA-STA-10.2 Section 11.13).


Route Policy Syntax


Route Policy Syntax

The Policy shall inherit the MIME type of common policy documents, namely application/auth-policy+xml.


Route Policy Syntax

The Policy shall be composed of rules that contain three parts - conditions, actions, and transformations as described in RFC 4745.


Route Policy Syntax

The Policy conditions statement shall evaluate to 'true' or 'false'. If it evaluates to 'true' then the action, and the transformations part of the rule is executed.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 100 of 115


Functional Element

ExternalRequirement

Num (if supplied)



38150 NENA-STA-10.2 4.3.2.0

38160 NENA-STA-10.2 4.3.2.1

38170 NENA-STA-10.2 4.3.2.1.07 Security Posture The Policy shall implement the Security Posture condition.

38180 NENA-STA-10.2 4.3.2.1.11 ServiceState The Policy shall implement the ServiceState condition.

38190 NENA-STA-10.2 4.3.2.1.13 SIP Body The Policy shall implement the SIP Body condition.

38200 NENA-STA-10.2 4.3.2.1.02 SIP Header The Policy shall implement the SIP Header element condition.

38210 NENA-STA-10.2 4.3.2.1.01 Time Period The Policy shall implement the Time Period condition.

38220 3.2.1 Provisioning FEs shall not allow the provisioning of one Agency to affect the provisioning of another Agency.

38230 3.2 Security GEN 2100-0100

38240 NENA-STA-10.2 3.01.4 Service Identifier Additional Data

38250 NENA-STA-10.2 3.01.4 Service Identifier Agency Locator

38260 NENA-STA-10.2 3.01.4 Service Identifier Conference Bridge

38270 NENA-STA-10.2 3.01.4 Service Identifier






38330 NENA-STA-10.2 3.01.4 Service Identifier Logging Service



38360 NENA-STA-10.2 3.01.4 Service Identifier Policy Store

38370 3.2 SNMP GEN 1300-0100

38380 NENA-STA-10.2 5.04.0 Spatial Interface ElementState

38390 3.2 Spatial Interface GIS Interface GEN 0300-0100



38420 NENA-STA-10.2 5.04.0 Spatial Interface GIS Interface

38430 3.2 Spatial Interface GIS Replica GEN 0500-0100

38440 NENA-STA-10.2 4.6.0 Spatial Interface Layer Replication


Route Policy Syntax

The Policy shall deal with cases where multiple condition parts evaluate to 'true', a conflict resolution priority-based mechanism is described to avoid conflicting actions to be executed.


Route Policy Syntax

The Policy shall inherit the Common Policy functionality, including <validity>. The <identity> and <sphere> condition is not used by this version of the document.

Policy Routing FunctionPolicy Routing FunctionPolicy Routing FunctionPolicy Routing FunctionPolicy Routing Function


FEs Shared by Multiple Agencies

MULTI-TENANT 0300-0100


Functional Element

FEs must enforce Security mechanisms for Identity, Roles, Authentication, Authorization, and Data Rights Management, as described in the Security section of NENA-STA-010.2.The Responder shall provide a functional element that represents the Service Identifier of an Additional Data Repository (if hosted on an ESInet).The Responder shall provide a functional element that represents the Service Identifier of an Agency Locator.The Responder shall provide a functional element that represents the Service Identifier of an Conference Bridge.


The Responder shall provide a functional element that represents the Service Identifier of an Emergency Call Routing Function.


The Responder shall provide a functional element that represents the Service Identifier of an Emergency Service Routing Proxy.

Geocode Conversion Service

The Responder shall provide a functional element that represents the Service Identifier of an Geocode Conversion Service.

Identity-Searchable Additional Data Repository

The Responder shall provide a functional element that represents the Service Identifier of an Identity-Searchable Additional Data Repository (if hosted on an ESInet).

Interactive Media Response Service

The Responder shall provide a functional element that represents the Service Identifier of an Interactive Media Response Service.


The Responder shall provide a functional element that represents the Service Identifier of an Location Validation Function.The Responder shall provide a functional element that represents the Service Identifier of an Logging Service .

Map Database Service

The Responder shall provide a functional element that represents the Service Identifier of an Map Database Service.

MSAG Conversion Service

The Responder shall provide a functional element that represents the Service Identifier of an MSAG Conversion Service.The Responder shall provide a functional element that represents the Service Identifier of a Policy Store.


Functional Element

All FEs must support emitting Simple Network Management Protocol (SNMP) traps for alarm notification. The SI shall implement the server side of ElementState event notification package and permit any ECRF or LVF that receives a feed from it to subscribe to it.


If an FE provides a Geographic Information System (GIS) server interface, the FE must support the Spatial Interface (SI) server interface as described in the Spatial Interface section of NENA-STA-010.2.


If an FE provides a GIS client interface, the FE must support the SI client interface as described in the Spatial Interface section of NENA-STA-010.2.


If an FE provides a GIS which is used to provision other FEs, the FE must support the SI server interface as described in the SI section of NENA-STA-010.2.The Responder's GIS solution shall provision a Spatial Interface (SI) functional element that provides the interface between the authoritative copy of GIS data and the ECRF and LVF.


If an FE provides a GIS replica, the FE must support the SI client interface as described in the SI section of NENA-STA-010.2.

OGC Document OGC 10-069r2 describes a layer replication interface service for geospatial databases using the Web Feature Service (WFS) and the ATOM protocol (RFC 4287 and RFC 5023). Essentially, the changes in the database are expressed in WFS Insert/Update/Delete actions and ATOM is used to move the edits from the master to the copy. GeoRSS (http://www.georss.org) is a very simple mechanism used to encode the GML in RSS feeds for use with ATOM. There are three ATOM feeds proposed by OGC 10-069r2; a change feed, resolution feed, and a replication feed. The SI layer replication interface is patterned after the replication feed described within OGC 10-069r2.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 101 of 115


Functional Element

ExternalRequirement

Num (if supplied)






38480 3.7.2 Spatial Interface Map Database

38490 NENA-STA-10.2 5.03.2.3 Spatial Interface Replicas

38500 3.6.4 System Alarms Failure

38510 3.6.4 System Alarms Interfaces A standardized interface shall be specified between the alarm sender and the alarm receiver.

38520 3.6.4 System Alarms Notifier

38530 3.6.4 System Alarms Receivers

38540 3.6.4 System Alarms Severity Alarms shall provide multiple levels of severity.

38550 NENA-STA-10.2 3.10.0 E.164

38560 NENA-STA-10.2 3.10.0 E.164

38570 NENA-STA-10.2 10 Test Calls 486 Bust Here

38580 NENA-STA-10.2 10 Test Calls Contact header

38590 NENA-STA-10.2 10 Test Calls ESInet

Note: OGC 10-069r2 is an OGC Public Engineering Report, not a standard. OGC 10-069r2 is not believed to be definitive enough to enable multiple interoperable implementations. A future OGC specification or a future revision of this document is needed to describe the protocol definitively. As with any standardized interface in this document; implementations may provide alternatives to the SI interface in addition to the standard interface defined in this section. A standard NENA schema for WFS as used in the i3 SI layer replication protocol will be provided in a future revision of this document.

Geospatial data is stored in a Geographic Information System (GIS). This document does not standardize the GIS. However, the data in the GIS is used to provision the ECRF, the LVF, the Map Database Service and other functions. In order to provide a standardized interface from the GIS to the rest of The functional elements that need GIS data, this document describes a “Spatial Interface” (SI), which is a standardized interface towards data consumers such as the ECRF/LVF. The SI could be built into a GIS system, or could be a stand-alone element with proprietary interfaces to GIS systems and the standardized interface towards the data consumers. The data model provided by the SI is based on the conventional GIS “layer” that consists of a set of geospatial “features”, each of which could be a point, line, polygon or a set of points, lines or polygons. Each feature has a set of named attributes. For example, a part of a road might be represented as a set of connected straight lines of the road centerline, with attributes that name the road and provide the range of address numbers in that segment of the road. A SI layer replication interface is used within the ESInet to maintain copies of the data in the layers of the authoritative GIS system that drives routing and display of maps throughout the system. Furthermore, any element that obtains GIS data via the SI could provide copies of the data to another element with the same interface, thus permitting wide distribution of authoritative data. The SI interface is near real time: an authorized change to the authoritative GIS will be reflected in the copies nearly immediately via the SI.The data structure for the SI shall include the elements marked as "M" in Appendix B of the NENA-STA-010.2.


MAPPING 0300-0100

The provisioning interface for the Map Database shall be the Spatial Interface (SI) interface defined in NENA-STA-010.2.A SI layer replication interface shall be used to maintain copies of the required layers as described in NENA-STA-010.2 Section 4.6.


ALARM 0300-0100

The alarm mechanism shall fail-safe such that both ends shall know that the alarm mechanism has failed.


ALARM 0200-0100


ALARM 0100-0100

Any FE (alarm sender) shall provide the ability to notify the appropriate personnel (alarm receiver) of its status including resolution of problems.


ALARM 0400-0100

Alarm sender shall be able to send status to multiple alarm receivers some of which may be outside the PSAP.


ALARM 0500-0100

Telephone Numbers

Where telephone numbers are used within an ESInet, full E.164 (ITU) numbers may be encountered on any call and all elements shall be able to handle a full E.164 telephone number. Ten-digit numbers conforming to the North American Numbering Plan (NANP) may be assumed to be North American telephone numbers and telephone numbers that are not full E.164 numbers but contain a digit string with greater than 10 digits may be assumed to be non-North American telephone numbers, but missing the “+” prefix. Some systems may have more sophisticated methods of determining a full E.164 number from a digit sequence appearing in the signaling. Telephone numbers conveyed as part of a URI shall be designated as such either by using a tel URI (RFC 3966) or in a SIP URI using the user=phone parameter.

Telephone Numbers

Where telephone numbers are used within an ESInet, full E.164 numbers may be encountered on any call and all elements shall be able to handle a full E.164 telephone number. Ten-digit numbers conforming to the North American Numbering Plan (NANP) may be assumed to be North American telephone numbers and telephone numbers that are not full E.164 numbers but contain a digit string with greater than 10 digits may be assumed to be non-North American telephone numbers, but missing the “+” prefix. Some systems may have more sophisticated methods of determining a full E.164 number from a digit sequence appearing in the signaling. Telephone numbers conveyed as part of a URI shall be designated as such either by using a tel URI or in a SIP URI using the user=phone parameter.

PSAP CPE shall refuse repeated requests for test from the same device (same Contact URI or source IP address/port) in a short period of time (within 2 minutes). Any refusal is signaled with a 486 Busy Here.

The PSAP shall insert its identity in the Contact header field of the response. To provide authentication, the Identity header field (RFC 4474) shall be inserted, signed by an entity in the path (such as an ESRP) with a certificate traceable to the PCA.

An INVITE message with the Service URN (found in the Request-URI) of “urn:service:test.sos” shall be interpreted as a request to initiate a test call. The PSAP shall return a 200 OK response in normal conditions, indicating that it will complete the test function. The PSAP may limit the number of test calls. If that limit is exceeded, the response shall be 486 Busy Here. PSAPs may accept requests for secondary services such as “urn:service:sos.fire.test” and complete a test call, or the PSAP may reject the call and return 404 Not Found. PSAP management may disable the test function (using PSAP policy).

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 102 of 115


Functional Element

ExternalRequirement

Num (if supplied)



38600 NENA-STA-10.2 10 Test Calls Loopback

38610 NENA-STA-10.2 10 Test Calls PSAP

38620 NENA-STA-10.2 10 Test Calls PSAP

38630 NENA-STA-10.2 3.02.0 Time NTP

38640 3.8.1 Time Time Server

38650 NENA-STA-10.2 3.03.0 Time Timestamp38660 NENA-STA-10.2 3.03.0 Time Timestamp Functional elements records shall be marked with a Timestamp.

38670 NENA-STA-10.2 11.21 URN Registry

38680 NENA-STA-10.2 11.18 URN Registry AgencyRoles

38690 NENA-STA-10.2 11.20 URN Registry Agent States

38700 NENA-STA-10.2 11.19 URN Registry AgentRoles

38710 NENA-STA-10.2 11.30 URN Registry The Responder shall support the URN Registry entries as described in NENA-STA-10.2 Section 11.30.

38720 NENA-STA-10.2 11.8 URN Registry elementState



38750 NENA-STA-10.2 11.22 URN Registry38760 NENA-STA-10.2 11.29 URN Registry Interface Names The Responder shall support the URN Registry entries as described in NENA-STA-10.2 Section 11.29.

38770 NENA-STA-10.2 11.14 URN Registry LogEvent





38820 NENA-STA-10.2 11.13 URN Registry RouteCause

A PSAP accepting a test call shall accept a media loopback test (RFC 6849) and shall support the “rtp-pkt-loopback” and “rtp-start-loopback” options. The PSAP user agent would specify a loopback attribute of “loopback-source”, the PSAP being the mirror. The PSAP shall loop back no more than 3 packets of each media type accepted (voice, video, text), after which the PSAP shall send BYE.

If the PSAP accepts the test, it shall return in the 200 OK a body with MIME type text/plain consisting of the following contents:a. The name of the PSAP, terminated by a CR and LFb. The string “urn:service:sos.test” terminated by a CR and LFc. The location reported with the call (in the Geolocation header). If the location was provided by value, the response would be a natural text version of the received location. If the location was provided by reference, the PSAP shall dereference the location, using credentials acceptable to the LIS issued specifically for test purposes. Credentials issued by a PCA-rooted CA shall have the token “test” as the agent name or the first token in the domain name. The location returned may not be the same as the LIS would issue for an actual emergency call.

NG9-1-1 PSAPs shall implement the test function described in RFC 6881. As the function is designed to test if a 9-1-1 call was placed from the test-initiating device, the test mechanism shall mimic the entire actual 9-1-1 call path as closely as practical. The test mechanism is completely automatic, with no manual intervention required. To route the same as an actual emergency call, route urns in the “urn:nena:service” tree are provided for test calls.

It is essential that all elements on the ESInet have the same notion of time. To do so, every element shall implement NTP, and access to a hardware clock shall be provided in each ESInet such that the absolute time difference between any element on any ESInet and another element in the same or any other ESInet is maintained within one tenth of a second of one another.


TIMESYNC 0100-0100

The Time Server FE shall meet the requirements specified in the Time Server Section of NENA-STA-010.2.

Any record that shall be marked with when it occurred (especially a log record) includes a Timestamp. A Timestamp includes integer-valued year, month, day, hour, and minute values, a decimal seconds value, and a timezone offset value. Time shall include seconds, and, if two or more Timestamps could be generated by the same element within one second where the order of events matter, the seconds element shall include sufficient decimal places in the seconds field to differentiate the Timestamps. Except where otherwise dictated by standards, all time within the ESInet is represented as local time with offset from UTC. The offset is a required component of the Timestamp and consists of an integer number of hours and minutes.

“urn:nena:service:agencyLocator”

The Responder shall support the URN Registry entries for “urn:nena:service:agencyLocator” as described in NENA-STA-10.2 Section 11.21.The Responder shall support the URN Registry entries for AgencyRoles as described in NENA-STA-10.2 Section 11.18.The Responder shall support the URN Registry entries for Agent States as described in NENA-STA-10.2 Section 11.20.The Responder shall support the URN Registry entries for AgentRoles as described in NENA-STA-10.2 Section 11.19.

Call and Incident ID Extension to LoST

The Responder shall support the URN Registry entries for elementState as described in NENA-STA-10.2 Section 11.8.

EsrpNotifyEventCode

The Responder shall support the URN Registry entries for EsrpNotifyEventCode as described in NENA-STA-10.2 Section 11.12.

ExternalEventCode

The Responder shall support the URN Registry entries for ExternalEventCode as described in NENA-STA-10.2 Section 11.11.


The Responder shall support the URN Registry entries for Identity Searchable Additional Data Repository as described in NENA-STA-10.2 Section 11.22.

The Responder shall support the URN Registry entries for LogEvent as described in NENA-STA-10.2 Section 11.14.

LogEvent CallSignalingMessage Protocol

The Responder shall support the URN Registry entries for LogEvent CallSignalingMessage Protocol as described in NENA-STA-10.2 Section 11.15.

LogEvent CallStates

The Responder shall support the URN Registry entries for LogEvent CallStates as described in NENA-STA-10.2 Section 11.17.

LogEvent CallTypes

The Responder shall support the URN Registry entries for LogEvent CallTypes as described in NENA-STA-10.2 Section 11.16.

Logging Service Media Error Reason Codes

The Responder shall support the URN Registry entries for RouteCause as described in NENA-STA-10.2 Section 11.13.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 103 of 115


Functional Element

ExternalRequirement

Num (if supplied)



38830 NENA-STA-10.2 11.10 URN Registry securityPosture

38840 NENA-STA-10.2 11.9 URN Registry serviceState



38870 NENA-STA-10.2 11.2 URN Registry urn:nena





38920 NENA-STA-10.2 11.7 URN Registry urn:nena:uid38930 NENA-STA-10.2 11.25 URN Registry urn:nena:xml The Responder shall support the URN Registry entries as described in NENA-STA-10.2 Section 11.25.38940 NENA-STA-10.2 11.26 URN Registry urn:nena:xml:ns The Responder shall support the URN Registry entries as described in NENA-STA-10.2 Section 11.26.


38960 NENA-STA-10.2 11.28 URN Registry The Responder shall support the URN Registry entries as described in NENA-STA-10.2 Section 11.28.38970 NENA-STA-10.2 3.06.0 xCards xCards The functional elements shall support xCards, a common representation of contact information.

38980 NENA-STA-10.2 3.03.0 XML Timestamp

38990 NENA-STA-10.2 7.1

39000 NENA-STA-10.2 7.1

39010 NENA-STA-10.2 7.1

39020 NENA-STA-10.2 7.1 ElementState

39030 NENA-STA-10.2 7.1 Logging

39040 NENA-STA-10.2 7.1.1 MF & SS7

39050 NENA-STA-10.2 7.1.1.1

39060 NENA-STA-10.2 7.1.1.1

39070 NENA-STA-10.2 7.1.1.1

39080 NENA-STA-10.2 7.1.1.1

39090 NENA-STA-10.2 7.1.1.1

The Responder shall support the URN Registry entries for securityPosture as described in NENA-STA-10.2 Section 11.10.The Responder shall support the URN Registry entries for serviceState as described in NENA-STA-10.2 Section 11.9.

SIPheader ‘Is’ Operator conditions

Too Many Mappings Warning Extension to LoST

The Responder shall support the URN Registry entries "urn:nena" as described in NENA-STA-10.2 Section 11.2.

urn:nena:service:federal_police

The Responder shall support the URN Registry entries beginning with "urn:nena:service:federal_police" as described in NENA-STA-10.2 Section 11.6.

urn:nena:service:responder

The Responder shall support the URN Registry entries beginning with "urn:nena:service:responder" as described in NENA-STA-10.2 Section 11.5.

urn:nena:service:sos

The Responder shall support the URN Registry entries beginning with "urn:nena:service:sos" as described in NENA-STA-10.2 Section 11.3.

urn:nena:service:test

The Responder shall support the URN Registry entries beginning with "urn:nena:service:test" as described in NENA-STA-10.2 Section 11.4.The Responder shall support the URN Registry entries beginning with "urn:nena:uid" as described in NENA-STA-10.2 Section 11.7.

urn:nena:xml:schemaWeb Service Status Codes

Timestamps contained in XML documents governed by this specification shall be represented by the “dateTime” datatype described in XML Schema Part 2: Datatypes Second Edition (http://www.w3.org/TR/xmlschema-2/), and shall be indicated in schema definitions accordingly. An example of a Timestamp in this format is “2015-08-21T12:58.03.01+05:00”.

Legacy Network Gateway (LNG)

(MF/SS7 to SIP) Protocol Interwork Function (PIF)

If the incoming call is a TTY call, the PIF will be responsible for interworking TTY to real time text per RFC 5194. See Section 7.1.1 for further details.)


NG9-1-1 specific Interwork Function (NIF)

The NIF shall be responsible for taking any non-location call information provided by the LIF and generating a data structure that contains Additional Data about the call, along with a pointer/reference to that data structure. (See Section 7.1.2 for further details.)


Location Interwork Function (LIF)

The location information shall be provided to the NIF for use in determining the route for the emergency call, and for populating the outgoing SIP INVITE message. Other non-location information associated with the call that is known or obtained by the LIF shall be passed to the NIF for population in an AdditionalData data structure. (See Section 7.1.3 for further details.)


Where the LNG is provided by the 9-1-1 authority, or the NGCS operator, the LNG shall implement the server-side of the ElementState event notification package.


Note: The LNG must log all significant events. Log record formats for this purpose are provided in Section 5.13.3 of this document.


The Legacy Network Gateway is expected to support MF and SS7 trunking arrangements to receive emergency calls from legacy originating networks.


MF Trunk Interface

The PIF component of the Legacy Network Gateway shall be capable of recognizing a trunk seizure and returning a wink back to the wireline switch or MSC.


MF Trunk Interface

Upon receiving an MF digit string containing the dialed digits “911” (i.e., KP + 911 + ST), the PIF component shall return an ANI request signal to the wireline trunk or MSC.


MF Trunk Interface

The PIF component of the Legacy Network Gateway shall be capable of receiving and processing the appropriate ANI sequence. If CAMA-type signaling is used on the MF trunk from a wireline end office to the Legacy Network Gateway, the PIF component of the Legacy Network Gateway shall be capable of receiving and processing an ANI sequence that consists of “I + 7-digit ANI”.


MF Trunk Interface

If Feature Group D operator-type signaling is used on the MF trunk from a wireline end office to the PIF component of the Legacy Network Gateway, the PIF component shall be capable of receiving and processing an ANI sequence consisting of “II + 7/10-digit ANI”.


MF Trunk Interface

If an emergency call originates in a wireless network and is routed from an MSC to the Legacy Network Gateway over an MF trunk group, and an ESRD is outpulsed with the ANI, the PIF component of the Legacy Network Gateway shall be capable of receiving and processing “II+7/10-digit+10-digit” Feature Group D-type signaling, where ANI is outpulsed as the first 7/10 digit number, and ESRD is outpulsed as the second 10-digit number (i.e., the called party number).

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 104 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39100 NENA-STA-10.2 7.1.1.1

39110 NENA-STA-10.2 7.1.1.1

39120 NENA-STA-10.2 7.1.1.1

39130 NENA-STA-10.2 7.1.1.2 SS7 Interface

39140 NENA-STA-10.2 7.1.1.2.1

39150 NENA-STA-10.2 7.1.1.2.1

39160 NENA-STA-10.2 7.1.1.2.1

39170 NENA-STA-10.2 7.1.1.2.2

39180 NENA-STA-10.2 7.1.1.2.2

39190 NENA-STA-10.2 7.1.1.2.2

39200 NENA-STA-10.2 7.1.1.2.2

39210 NENA-STA-10.2 7.1.1.3 Early Media

39220 NENA-STA-10.2 7.1.1.4

39230 NENA-STA-10.2 7.1.1.4


MF Trunk Interface

If an emergency call originates in a Commercial Mobile Radio Service (CMRS)-type wireless network and is routed from an MSC to the Legacy Network Gateway over an MF trunk group, and the wireless network uses the Wireline Compatibility Mode approach (i.e., only the ESRK is signaled), the PIF component of the Legacy Network Gateway shall be capable of receiving and processing an ESRK following the “II” (i.e., as ANI), and the digits “9-1-1”, “1-1”, or “1” as the called number.


MF Trunk Interface

Upon receiving a 200 OK message from the NIF component, the PIF component shall generate an answer signal to the wireline switch or MSC.


MF Trunk Interface

The PIF component of the Legacy Network Gateway shall be capable of receiving and processing an on-hook indication from a wireline switch or MSC, and shall generate a SIP BYE message toward the NIF, as described in Section 7.1.1.1


When a wireline end office or MSC determines that an SS7 Initial Address Message (IAM) associated with a 9-1-1 call is to be generated, it shall also need to generate and pass some Message Transfer Part (MTP)-level information, along with the Integrated Services Digital Network User Part (ISUP) information, to the Legacy Network Gateway.


SS7 Message Transfer Part (MTP) Signaling for 9-1-1 Call Setup

The wireline end office/MSC shall be responsible for generating information that shall be populated in the MTP Signaling Information Field (SIF) and the Service Information Octet (SIO) portions of the IAM sent to the Legacy Network Gateway.



The SIO contains the service indicator that identifies the MTP user involved in the message. In the case of a call setup message generated by a wireline end office or MSC, the service indicator shall identify the ISDN User Part as the MTP user. The subservice field shall indicate that the message is a national network message and shall identify the MTP message priority. In the case of IAMs related to 9-1-1 calls, the message priority shall have the value “1” (where priority 3 is the highest priority assigned to SS7 messages)50. Therefore, the PIF component of the Legacy Network Gateway shall be capable of receiving and processing an IAM that contains MTP information that includes a Service Information Octet (SIO) that contains the following information:• The service indicator shall identify the ISDN User Part as the MTP user.• The subservice field shall indicate that the message is a national network message and that the message priority has a value of “1”.



The SIF contains a routing label, consisting of the Originating and Destination Point Codes, as well as the Signaling Link Selection value for the message, a Circuit Identification Code associated with the trunk selected for the call, a Message Type Code identifying the message as an Initial Address Message (IAM), and the content of the IAM itself. The PIF component of the Legacy Network Gateway shall be capable of receiving and processing an IAM that contains MTP information that includes a Signaling Information Field (SIF) containing the following information:• A routing label that contains the point code of the wireline end office or MSC in the Originating Point Code field, the point code of the Legacy Network Gateway in the Destination Point Code field, and an SLS code assigned by the wireline end office/MSC.• A Circuit Identification Code assigned by the wireline end office/MSC and associated with the trunk selected for the call.• A Message Type code identifying the message as an IAM.• The content of the IAM itself.


SS7 ISUP Signaling for 9-1-1 Call Setup

The trunk group from the wireline end office or MSC to the Legacy Network Gateway shall be a dedicated trunk group per carrier.



If the incoming trunk to the Legacy Network Gateway is an SS7-controlled dedicated trunk the PIF component of the Legacy Network Gateway shall be capable of receiving and processing an ISUP IAM containing parameters populated as described in GR-2956-CORE, CCS/SS7 Generic Requirements in Support of E9-1-1 Service, Sections 5.2.1.2.1, R2956-77 and 5.2.1.4.1, R2956-82, respectively.



The PIF component of the Legacy Network Gateway shall be capable of receiving and processing an ISUP Release (REL) message from a wireline end office or MSC, formatted as described in Table A-5 of GR-317-CORE, and generating a Release Complete Message (RLC) formatted as described in Table A-6 of GR-317-CORE in response.



The PIF component of the Legacy Network Gateway shall be capable of receiving and processing supervisory ISUP messages sent by wireline end offices and MSCs (e.g., Blocking, Blocking Acknowledgement). The PIF component shall follow the procedures described in Section 3.1.4 of GR-317-CORE for processing these messages.


In order to provide the equivalent of “trunk-side recording”, an LNG is expected provide Early Media to downstream elements whenever it is possible to do so (for example, with an MF trunk origination). Any LNG that is acting as a SIPREC SRC (Session Recording Client) shall provide Early Media to the SRS (Session Recording Server).


Handling of Media Associated with TTY Calls

If the Legacy Network Gateway receives an incoming TTY call, the PIF component shall be responsible for recognizing the Baudot tones in incoming media and replacing them with RFC 4103 Real-TimeText



The PIF component shall be responsible for generating Baudot tones in outgoing media if real-time text is received in RTP packets.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 105 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39240 NENA-STA-10.2 7.1.1.4

39250 NENA-STA-10.2 7.1.1.5

39260 NENA-STA-10.2 7.1.1.5

39270 NENA-STA-10.2 7.1.1.5

39280 NENA-STA-10.2 7.1.1.5

39290 NENA-STA-10.2 7.1.1.5

39300 NENA-STA-10.2 7.1.1.5

39310 NENA-STA-10.2 7.1.1.5

39320 NENA-STA-10.2 7.1.1.5



To support TTY calls, the PIF component shall include an SDP in the INVITE message sent to the NIF component that describes a media format associated with real time text, as described in RFC 4103.


Internal Interface to the NIF Component

The PIF component of the Legacy Network Gateway must have the capability to use standard interworking procedures, as defined in ATIS-1000679.2015, to generate a SIP INVITE message based on incoming SS7 signaling, and pass that INVITE message to the NIF component of the Legacy Network Gateway.



The SIP INVITE generated by the PIF shall consist of the following information:• A Request-URI that contains the information signaled in the SS7 Called Party Number parameter (per ATIS-1000679.2015) or as the MF called number.• A To header that contains the information signaled in the SS7 Called Party Number parameter (per ATIS-1000679.2015) or as the MF called number.• A “From” header that contains the information signaled in an SS7 Generic Digits Parameter (GDP), if present.If a GDP is not received in incoming signaling, the “From” header shall be populated with the information signaled in the SS7 Calling Party Number parameter (if present).• A P-Asserted-Identity (P-A-I) header that is populated with the information contained in the SS7 Calling Party Number parameter (per ATIS-1000679.2015). In addition, the P-A-I header shall also contain the content of the SS7 Calling Party Category (CPC) parameter and the Originating Line Information (OLI) parameter, if present in the received SS7 Initial Address Message (IAM) (per ATIS-1000679.2015).• A P-Charge-Info header that is populated with the information that was contained in the SS7 Charge Number parameter (per ATIS-1000679.2015) or was signaled as the MF ANI.• A Contact header that contains the trunk group parameters that identify the ingress trunk group to the Legacy Network Gateway, as defined in RFC 4904.• A Via header that is populated with the element identifier (see Section 3.1.3) for the Legacy Network Gateway.• An SDP offer that includes the G.711 codec. To support incoming TTY calls, the SDP offer shall describe a media format associated with real time text as described in RFC 4103.



The PIF component of the Legacy Network Gateway shall be capable of receiving and processing a SIP Trying (100) message passed to it by the NIF component, acknowledging receipt of the INVITE that was previously generated by the PIF component.



The PIF component of the Legacy Network Gateway shall also be capable of receiving and processing a 180 Ringing message. If the incoming trunk group to the Legacy Network Gateway is an SS7 trunk group, then upon receiving the 180 Ringing message, the PIF component of the Legacy Network Gateway shall generate an ISUP Address Complete Message (ACM) formatted as described in Section 7.2.1.1 of ATIS-1000679.2015 and Section 3.1.1.5 of GR-317-CORE, LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP), with the following clarification. It is expected that bits DC of the Backward Call Indicator parameter shall be set to “01” indicating “subscriber free”, bits HG of the Backward Call Indicator parameter shall be set to “00” indicating “no end-to-end method available”, bit I shall be set to “1” indicating “interworking encountered”,” bit K shall be set to “0” indicating “ISDN User Part not used all the way”, and bit M shall be set to “0” indicating “terminating access non-ISDN”.



The PIF component of the Legacy Network Gateway shall be capable of receiving and processing a 200 OK message, indicating that the call has been answered. If the incoming trunk to the Legacy Network Gateway is an SS7 trunk, then upon receiving the 200 OK message, the PIF shall generate an ISUP Answer Message (ANM) formatted as described in Section 3.1.1.6 of GR-317-CORE. If ANM is the first backward message sent by the Legacy Network Gateway (i.e., no ACM is sent previously due to the 200 OK being the first SIP message received), the Legacy Network Gateway shall follow the procedures specified in Section 7.5.1 of ATIS-1000679.2015. Specifically, the Called Party’s Status indicator (Bit DC) of the Backward Call Indicators parameter shall be set to “no indication,” bit I shall be set to “1” indicating “interworking encountered,” bit K shall be set to “0” indicating “ISDN User Part not used all the way,” and bit M shall be set to “0” indicating “terminating access non-ISDN.”



If the incoming trunk to the Legacy Network Gateway is an MF trunk, then upon receiving the 200 OK message, the PIF shall generate an answer signal to the wireline switch or MSC.



The PIF component of the Legacy Network Gateway shall be capable of receiving and processing a SIP BYE message, and acknowledging the BYE by returning a 200 OK message to the NIF. If the incoming trunk to the Legacy Network Gateway is an SS7 trunk, then upon receipt of the BYE message, the PIF shall generate an ISUP REL message, and be capable of receiving and processing an ISUP RLC sent in response. If the incoming trunk to the Legacy Network Gateway is an MF trunk, then upon receipt of the BYE message, the PIF shall generate an on-hook signal to the wireline switch or MSC.



The PIF shall also be capable of generating a BYE message and sending it to the NIF if an ISUP REL is received from the wireline switch or MSC or an on-hook signal is received over an MF trunk from the wireline switch or MSC, and shall be capable of receiving and processing a 200 OK message from the NIF sent in acknowledgement.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 106 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39330 NENA-STA-10.2 7.1.1.5

39340 NENA-STA-10.2 7.1.2.1

39350 NENA-STA-10.2 7.1.2.1

39360 NENA-STA-10.2 7.1.2.1

39370 NENA-STA-10.2 7.1.2.1

39380 NENA-STA-10.2 7.1.2.2

39390 NENA-STA-10.2 7.1.2.2



If the PIF component receives other SIP messages from the NIF component, it shall process them per RFC 3261.


NIF Handling of INVITE from PIF

The NIF component of the Legacy Network Gateway functional element is expected to provide special processing of the information received in the incoming INVITE message from the PIF component to facilitate call delivery to an i3 ESInet. The NIF shall determine, based on the incoming trunk group and/or the incoming signaling, whether the call is a wireline or wireless emergency call. If the call is received over an MF trunk group, the NIF shall make this determination based on the incoming trunk group parameters included in the Contact header of the INVITE message from the PIF. If the call is received over an SS7 trunk group, the NIF shall make this determination based on the coding of the cpc and oli parameters in the P-A-I header of the INVITE message from the PIF and/or the ingress trunk group parameters in the Contact header of the INVITE message from the PIF. Based on this determination, the NIF shall extract the appropriate information (i.e., calling party number, charge number, and/or ESRD) from the incoming signaling to be used as the location key and shall pass it to the Location Interwork Function (LIF) for use in obtaining caller location information. (See Section 7.1.3 for further discussion of LIF functionality and interfaces.)



If the NIF determines that the incoming call is a legacy wireline emergency call, and only one number is received in incoming signaling as the Calling Party Number (CPN)/ANI (i.e., the URI in the “From”, P-A-I, and P-Charge-Info headers of the INVITE message received from the PIF contains the same CPN/ANI), the NIF shall pass this number to the LIF to use in retrieving the location for the call. If the NIF determines that the incoming call is a legacy wireline emergency call and two different numbers are received in incoming signaling (i.e., the INVITE message from the PIF contains a URI associated with the Charge Number in the P-Charge-Info header and a different URI associated with the CPN in the P-A-I header) the NIF shall support a configuration option to tell it which number to send to the LIF as input to location retrieval.



If the NIF determines (based on the oli parameter in the P-A-I header or the trunk group information in the Contact header) that the incoming call is a legacy wireless emergency call, and both a callback number (i.e., Mobile Directory Number [MDN]) and an ESRD are received in incoming signaling, the NIF shall send both numbers to the LIF since both are required to uniquely identify the call. The NIF shall determine, based on configured information associated with the trunk group identified in the trunk group parameters within the Contact header of the received INVITE, where to extract the callback information and ESRD from. The ESRD may be populated in the Request URI/To headers or in the “From” header. The MDN may be populated in the “From” header or the P-A-I header.


NIF Handling of Location Information from the LIF

Once the NIF receives location information from the LIF in geo or civic format, the NIF shall be capable of generating a routing request to an ECRF. The NIF shall generate a LoST query, which includes the location information provided by the LIF and an appropriate service URN (i.e., “urn:service:sos”), following the procedures described in Section 4.4. If the NIF does not receive a routing location from the LIF component within a pre-specified period of time, the NIF component shall use a default location (based on the incoming trunk group information provided in the Contact header of the INVITE message from the PIF component) to query the ECRF.



Upon receiving the response from the ECRF, the NIF shall determine the outgoing route for the call using the URI of the target ESRP received in the LoST response. If the NIF component of the Legacy Network Gateway does not receive a response to a LoST query within a provisioned time period, or receives an error indication from the ECRF, it shall log the event and route the call based on a provisioned default ESRP URI.



In addition to determining the outgoing route, the NIF shall generate a data structure that contains Additional Data about the call. The data structure shall contain the mandatory information identified in Section 3.1 of NENA 71-001, as well as any other non-location information associated with the call that is provided to the NIF by the LIF, formatted according to. The NIF may include this Additional Data (or a subset of it) “by-value” in the body of the outgoing SIP message it sends to the ESRP, and/or it may generate a pointer/reference to that data structure. The pointer shall contain the URI of the ADR where the Additional Data information is stored. The URI generated by the NIF shall include the callback number. If there is only static information and no per-call information, the NIF may include a reference URI to a static ADR that may be maintained at the NIF or elsewhere if maintained by the 9-1-1 Authority. If the NIF generates a pointer/reference to an Additional Data structure, it shall include the reference URI in the Call-Info header field of the INVITE message sent to the ESRP, with a purpose parameter beginning with “EmergencyCallData”. If the NIF passes Additional Data by reference, and the reference refers to the LNG, the NIF component of the LNG must maintain an ADR interface, utilizing the HTTPS GET method described in IETF RFC 7230, to support dereference requests for Additional Data.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 107 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39400 NENA-STA-10.2 7.1.2.3

39410 NENA-STA-10.2 7.1.2.3

39420 NENA-STA-10.2 7.1.2.3

39430 NENA-STA-10.2 7.1.2.3

39440 NENA-STA-10.2 7.1.2.3

39450 NENA-STA-10.2 7.1.2.3


SIP Interface to the ESInet

o If the call was originated by a non-initialized mobile caller (i.e., the callback number is of the form 911+ “last 7 digits of the ESN or IMEI expressed as a decimal”) the “From” header shall contain a value of “Anonymous.”• A P-Asserted-Identity (P-A-I) header that contains the callback number retrieved by the LIF component or received in incoming signaling from the PIF component, as appropriate for the type of emergency call origination. Note that the P-A-I sent by the NIF component to the ESRP shall not contain cpc or oli parameters.o If the “Service Delivered by Provider to End User” provided by the LIF component is equal to “POTS,” the NIF component shall populate the P-A-I with the SS7 Calling Party Number information received in the P-A-I header of the incoming INVITE message from the PIF component.o If the “Service Delivered by Provider to End User” provided by the LIF component is equal to “wireless”, then the NIF component shall populate the P-A-I header as follows: If the “From” header and the P-A-I header of the incoming INVITE message from the PIF component are not the same (i.e., a GDP was received in the incoming signaling from the MSC), the NIF component shall use the SS7 Calling Party Number value provided in the P-A-I header of the INVITE message from the PIF component to populate the P-A-I header of the outgoing INVITE message. If the “From” header and the P-A-I header of the incoming INVITE message from the PIF component are the same (i.e., no GDP was present in the incoming signaling from the MSC), the NIF component shall use the callback number provided by the LIF component to populate the P-A-I header of the outgoing INVITE message. If the LIF component does not provide a callback number to the NIF component within a pre-specified period of time, the NIF component shall omit the P-A-I header from the outgoing INVITE message.o If a non-initialized mobile caller originated the call, the P-A-I header shall be omitted.• A P-Charge-Info header, if one was received in the INVITE message from the PIF component. This field shall contain the information received by the Legacy Network Gateway in an SS7 Charge Number parameter or signaled as an MF ANI.• A Via header that is populated with the element identifier (see Section 3.1.3) for the Legacy Network Gateway• A Route header that contains the ESRP URI obtained from the ECRF• A Contact header that contains a SIP URI that is associated with the Legacy Network Gateway• A Supported header that contains the “geolocation” option tag• A Geolocation header that either: • Points to the message body (using a “Content Identifier” URI, as defined in RFC 2392) where a PIDF-LO containing the location value retrieved by the LIF is coded (see Section 7.1.3) • Contains a location-by-reference URI• An SDP offer as received from the PIF component.



If, during the processing of the emergency call, the NIF component of the Legacy Network Gateway creates an Additional Data data structure and stores it, the NIF component of the Legacy Network Gateway shall include one or more Call-Info header fields with a purpose parameter beginning with “EmergencyCallData” and a URI associated with the ADR that contains the Additional Data data structure which, when dereferenced, would yield additional information about the call.



If, during the processing of the emergency call, the NIF component of the Legacy Network Gateway creates two or more AdditionalData structures and sends them forward “by value” in the outgoing INVITE message, the NIF component of the Legacy Network Gateway shall populate the data structures in the body of the INVITE message and shall include one or more Call-Info header fields having a purpose parameter prefix of “EmergencyCallData” that contain a cid: URI that points to the information in the message body.



A P-Preferred-Identity header shall be populated with 911 + “last 7 digits of the ESN or IMEI expressed as a decimal” if the call was originated by a non-initialized mobile caller.



The NIF component shall be capable of receiving and processing a 180 Ringing message or a 183 Session Progress message from the ESInet in response to the SIP INVITE. If the NIF component receives a 180 Ringing message, it shall send a 180 Ringing message to the PIF component. If the NIF component receives a 183 Session Progress message, it shall send a 183 Session Progress message to the PIF component.



The NIF component shall also be capable of receiving and processing a 200 OK message from the ESInet. If the NIF component receives a 200 OK message from the ESInet, it shall send it to the PIF component. The NIF component shall be capable of receiving and processing an ACK message from the PIF component in response to the 200 OK message. The NIF component shall subsequently send an ACK message to the ESInet.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 108 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39460 NENA-STA-10.2 7.1.2.3

39470 NENA-STA-10.2 7.1.2.3

39480 NENA-STA-10.2 7.1.2.3

39490 NENA-STA-10.2 7.1.2.3

39500 NENA-STA-10.2 7.1.2.3

39510 NENA-STA-10.2 7.1.3

39520 NENA-STA-10.2 7.1.3



If callback information is not available at the time that the initial INVITE message is sent by the NIF component to the ESRP, but is subsequently provided by the LIF component, the NIF component shall generate a re-INVITE message to communicate this information to the PSAP. The re-INVITE message shall reference the existing dialog so that the i3 PSAP (or Legacy PSAP Gateway, in the case of a legacy PSAP) knows that it is to modify an existing session instead of establishing a new session. The re-INVITE message shall include the following information:• A Request-URI that contains the information provided in the Contact header of the 200 OK message that was returned in response to the original INVITE message• A To header that contains the same information as the original INVITE message (i.e., the digits “911”)• A “From” header that contains the same information as in the original INVITE message (i.e., the “From” header shall be populated with the value received in the incoming INVITE message from the PIF component, which is the ESRK)• A P-Asserted-Identity (P-A-I) header that contains the callback number retrieved by the LIF component• A Via header that is populated with the element identifier (see Section 3.1.3) for the Legacy Network Gateway• A Route header that contains the same information as in the original INVITE (i.e., the ESRP URI obtained from the ECRF)• A Contact header that contains the same information as in the original INVITE message (i.e., a SIP URI associated with the Legacy Network Gateway).



The i3 PSAP/Legacy PSAP Gateway shall return a 200 OK to indicate that it accepts the change, and the Legacy Network Gateway shall respond to the 200 OK by returning an ACK message.



The NIF component shall be capable of receiving and processing a BYE message from the ESInet. If the NIF component receives a BYE message from the ESInet, it shall pass it to the PIF component. The NIF component shall be capable of receiving and processing a 200 OK message from the PIF component in response to the BYE message, and shall subsequently send a 200 OK message to the ESInet.



If the NIF component receives other SIP messages from the ESInet, it shall validate them and if necessary, apply the appropriate error handling per RFC 3261. If the messages pass the validity checks, the NIF component shall pass them to the PIF component.



The NIF component shall be capable of receiving and processing a BYE message from the PIF component. If the NIF component receives a BYE message from the PIF component, it shall send a BYE message to the ESInet. Upon receiving a 200 OK message from the ESInet in response to the BYE message, the NIF component shall return a 200 OK message to the PIF component.


Location Interwork Function

At the request of the NIF, the LIFshall invoke location retrieval functionality to obtain the location information that shall be used as the basis for call routing and that shall be delivered to the PSAP. Specifically, the LIF shall query an associated location server/database.• If the call is a wireline emergency call, the associated database shall contain location information in the form of a location value. This location value shall be used for both routing and dispatch purposes.• If the call is a Phase I wireless emergency call for which static dispatch location information is stored locally (i.e., no query is launched to the MPC/GMLC), the associated database shall obtain a routing location by accessing pre-provisioned data that maps the ESRD to a routing location chosen so that it shall route to the primary PSAP that is to receive the call, and shall use the locally stored information as the dispatch location for the call.• If the call is a wireless Phase II emergency call (or a Phase I wireless emergency call using this implementation), the associated database shall access pre-provisioned data that maps the location key (i.e., ESRK or ESRD) provided with the call to a routing location chosen so that it shall route to the target PSAP associated with the ESRK/ESRD, and shall query an MPC/GMLC for dispatch location information.



The data in the internal location server/database may be provisioned using proprietary mechanisms/interfaces (e.g., using the existing provisioning flows, systems and interfaces that are used for provisioning legacy ALI databases today), or using a standard provisioning interface, as specified in a subsequent NENA standard, or some combination thereof, depending on the business agreements that exist between the Legacy Network Gateway provider and the data owners.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 109 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39530 NENA-STA-10.2 7.1.3

39540 NENA-STA-10.2 7.1.3

39550 NENA-STA-10.2 7.1.3

39560 NENA-STA-10.2 7.1.3



The LIF shall receive one or two numbers/keys from the NIF to be used for location retrieval/acquisition. Upon receiving the key(s), the LIF shall consult “steering” data to determine whether another system must be queried to obtain location information for dispatch purposes.• If a single key is received from the NIF associated with a legacy wireline origination, it shall not be present in the steering data. The LIF shall utilize internally defined procedures/protocols to retrieve static location information which shall be used for both routing and dispatch purposes from an associated location server/database.• If the NIF provides two keys to the LIF and they are not present in the steering data (i.e., the keys include an ESRD that is associated with a Phase I wireless origination in which no MPC/GMLC query is to be launched), the LIF shall obtain routing location for the call by accessing pre-provisioned data in an associated database that maps the ESRD to a routing location chosen so that it shall route to the target PSAP associated with the ESRD. Dispatch location shall be retrieved from static location information accessed via internally defined procedures/protocols.• If the key(s) include an ESRK or ESRD that is contained in the steering data, the LIF shall access pre-provisioned data in an associated database that maps the location key (i.e., ESRK or ESRD) to a routing location chosen so that it shall route to the target PSAP associated with the ESRK/ESRD, and shalll generate an E2 or MLP query (as appropriate for the MPC/GMLC whose address is included in the steering data) and direct it to the MPC/GMLC identified in the steering data to obtain dispatch location.



If the call is from a legacy wireline originating network, it is expected that the LIF shall map the CPN/ANI to a location value (in the form of a civic address) and other non-location call-related information (Refer to Appendix A for details on mapping between legacy and NG9-1-1 data). The location value and any non-location information shall be returned to the NIF where it is used to build the required Additional Data XML documents.



If the call originated in a legacy wireless network using Wireline Compatibility Mode, the LIFshall interrogate its steering data with the ESRK. The steering data shall contain the address of the MPC/GMLC in the legacy wireless network that shall be queried for initial/updated dispatch location. The LIF component shall obtain the routing location for the call by consulting an associated database that contains static mappings of ESRK to routing location chosen so that it will route to the target PSAP associated with the ESRK. The LIF component will also generate an E2 or MLP query for dispatch location, containing the ESRK, to the MPC/GMLC and must be capable of processing an E2/MLP response. The LIF component will immediately return the routing location to the NIF component, along with an indication that the “Service Delivered by Provider to End User” is “wireless” and a SIP or HELD location reference that contains the ESRK and the URI of the Legacy Network Gateway. Upon receiving the dispatch location returned by the MPC/GMLC (which is initially expected to convey information about the location of the cell site/sector), the LIF component shall store the dispatch location and pass any non-location information received in the MPC/GMLC response, including the callback number, to the NIF component.



If the call originated in a legacy wireless network that supports the signaling of callback number and ESRD, the LIF component shall consult its steering data using the ESRD. The steering data includes the address of the MPC/GMLC in the legacy wireless network that shall be queried for initial/updated dispatch location.• If the legacy wireless network is only Phase I-capable, the LIF may not find steering data that corresponds to the ESRD and shall instead retrieve from its local database a static location value that is associated with the cell site/sector to be used as the dispatch location. The LIF shall obtain the routing location for the call by consulting an associated database that contains static mappings of ESRDs to routing location chosen so that it shall route to the target PSAP associated with the ESRD. The LIF shall then pass the routing location, along with an indication that the “Service Delivered by Provider to End User” is “wireless” and originating network contact information (i.e., the “Data Provider Contact URI”) to the NIF component. The LIF shall also pass a SIP or HELD location reference to the NIF that uniquely identifies the location information and the Legacy Network Gateway. The LIF shall associate the location reference with the routing and dispatch location.• If the LIF component finds steering data corresponding to the ESRD, it shall obtain the routing location for the call by consulting an associated database that contains static mappings of ESRD to routing location chosen so that it shall route to the target PSAP associated with the ESRD. The LIF component shall also generate an E2/MLP query for dispatch location, containing the callback number and ESRD, to the MPC/GMLC and must be capable of processing an E2/MLP response. The LIF component shall immediately return the routing location to the NIF component, along with an indication that the “Service Delivered by Provider to End User” is “wireless”. The LIF shall also pass a SIP or HELD location reference to the NIF that uniquely identifies the location record and the Legacy Network Gateway. Upon receiving the dispatch location returned by the MPC/GMLC (which is initially expected to convey information about the location of the cell site/sector), the LIF component shall retain the dispatch location and associate it with the location reference. The LIF component shall also pass any non-location information received in the E2/MLP response to the NIF component.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 110 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39570 NENA-STA-10.2 7.1.3

39580 NENA-STA-10.2 7.1.3.1.1 The LNG shall support the interworking between HELD and E2 as described in Section 7.1.3.1.1.

39590 NENA-STA-10.2 7.1.3.1.2 The LNG shall support the interworking between HELD and MLP as described in Section 7.1.3.1.2.

39600 NENA-STA-10.2 7.1.3.1.3

39610 NENA-STA-10.2 7.1.3.1.4

39620 NENA-STA-10.2 7.2 PIF

39630 NENA-STA-10.2 7.2 PIF

39640 NENA-STA-10.2 7.2 PIF

39650 NENA-STA-10.2 7.2 PIF The LPG must implement the server-side of the ElementState event notification package.

39660 NENA-STA-10.2 7.2 PIF

39670 NENA-STA-10.2 7.2.1

39680 NENA-STA-10.2 7.2.1

39690 NENA-STA-10.2 7.2.1

39700 NENA-STA-10.2 7.2.1 The LPG shall support the MF interface signalling as described in Section 7.2.1.1.



Since the Legacy Network Gateway may provide a location reference (e.g., associated with a legacy wireless emergency call origination) in the INVITE that it sends to the ESRP, the LIF must also support the dereferencing of location references by external elements (e.g., ESRPs, PSAPs). The interface used by a LIF for dereferencing is the same as the interface used by a LIS for dereferencing, as described in Section 4.2. Specifically, the LIF must support SIP and/or HELD dereferencing protocols, and must be capable of applying the appropriate one based on the format of the location reference provided as output from the location retrieval process.


Interworking Between HELD and E2


Interworking Between HELD and MLP


Interworking Between SIP Presence and E2

The LNG shall support the interworking between SIP Presence and E2 as described in Section 7.1.3.1.3.


Interworking Between SIP Presence and MLP

The LNG shall support the interworking between SIP Presence and MLP as described in Section 7.1.3.1.4.

Legacy PSAP Gateway (LPG)

1. (SIP -MF/E-MF/DTMF) Protocol Interwork Function (PIF). This functional component interworks the SIP protocol to traditional MF, Enhanced MF, or ISDN, or other protocols, as appropriate for the interconnected PSAP. If the PIF component determines that the call is to be delivered to the PSAP as a TTY call, the PIF component shall be responsible for interworking real time text and TTY per RFC 5194. The PIF component must also be capable of interworking text messages received in an MSRP session with TTY. It is assumed that the PIF functional component does not require specialized hardware, and can therefore be implemented using commercially available hardware. (See Section 7.2.1 for further details.)


2. NG9-1-1 specific Interwork Function (NIF). This functional component provides NG9-1-1- specific processing of the call signaling, which includes special handling of attached location, selection of trunk groups, and callback number mapping, etc. The NIF associates one form of identifier with another, which includes mapping any combination of identifiers, such as 10- digit NANP numbers, non-NANP identifiers (pANIs), E.164 (International 11-15 digit) identifiers, and SIP URIs. For example, when a call is received with location and a SIP URI and it is destined for a legacy PSAP, the NIF maps the attached location and callback identifier information to a pANI that is then delivered to the PSAP with the call and used by the PSAP as a key for subsequent location and callback information retrieval. In addition, the NIF includes functionality to support transfer requests and, optionally, requests for the invocation of alternate routing (e.g., in cases of PSAP evacuation). This functional component shall be viewed as a Back-to-Back User Agent (B2BUA) in front of the PIF. (See Section 7.2.2 for further details.)


3. Location Interwork Function (LIF). This functional component supports standard ALI query/response interface protocols, as well as the interworking of NG9-1-1 relevant data elements to a standardized ALI format for population in ALI response messages. (See Section7.2.3 for further details.)

Legacy PSAP Gateway (LPG)Legacy PSAP Gateway (LPG)

The LPG must log all significant events. Log record formats for this purpose are provided in Section 5.13.3 of this document.


Protocol Interwork Function

The PIF component of the Legacy PSAP Gateway shall be responsible for interworking the SIP signaling received from the NIF component with the traditional or Enhanced MF signaling sent over the interface to the destination PSAP. The PIF shall also be responsible for accepting Dual Tone Multi Frequency (DTMF) signaling (e.g., associated with transfer requests) from the legacy PSAP and sending it to the NIF component in RTP packets, per RFC 4733.



The PIF component of the Legacy PSAP Gateway must be capable of accepting a SIP INVITE message generated by the NIF component (see Section 7.2.2.3).



Upon receiving the INVITE method, the PIF component of the Legacy PSAP Gateway shall identify the destination PSAP based on the information in the Request URI and select an outgoing trunk to that PSAP based on the outgoing trunk group information in the Request URI. Based on the information received in incoming signaling from the NIF component, the PIF component shall generate either traditional MF (i.e., 8-digit CAMA) or Enhanced MF (E-MF) call signaling. In both cases, the MF signaling sequences used in delivering emergency calls to legacy PSAPs include a“Special Handling” indication along with the ANI59. (See Section 7.2.3 for further information.) Legacy PSAPs that support E-MF interfaces may support the delivery of a 10-digit key or pANI that serves as a reference to the caller’s location information in addition to a 10-digit callback number and “Special Handling” indication. The traditional MF and E-MF signaling interfaces that may be supported by a legacy PSAP are described below.



NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 111 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39710 NENA-STA-10.2 7.2.1.2 The LPG shall support the Enahnced MF (E-MF) interface signalling as described in Section 7.2.1.2.

39720 NENA-STA-10.2 7.2.1.3

39730 NENA-STA-10.2 7.2.1.3

39740 NENA-STA-10.2 7.2.1.4

39750 NENA-STA-10.2 7.2.1.4 The PIF must interwork the RFC 4103 real time text generated by the NIF to Baudot tones.

39760 NENA-STA-10.2 7.2.1.5

39770 NENA-STA-10.2 7.2.2

39780 NENA-STA-10.2 7.2.2

39790 NENA-STA-10.2 7.2.2.1





If an incoming call is to be delivered by the Legacy PSAP Gateway to the PSAP as a TTY call, the PIF component shall be responsible for recognizing the media format provided in the SDP as being associated with real time text and generating Baudot tones for delivery to the legacy PSAP.



If a legacy PSAP responds to an incoming call by generating Baudot tones, the PIF component shall be responsible for recognizing the Baudot tones in incoming media and replacing them with RFC 4103 real time text.


Handling of Media Associated with SMS, Instant Messaging and RTT

Interworking of SMS to MSRP is expected to occur outside the ESInet, but legacy PSAPs must have the capability to accept text messages. Interworking between MSRP and TTY must occur within the LPG. Specification for interwork between MSRP and TTY shall be covered in a future revision of this document.


Handling of Media Associated with SMS, Instant Messaging and RTT


Handling of Video Media

A Legacy PSAP is unable to handle video, and the PIF shall not return an SDP media line for any video offer. Only the audio media shall pass through to the PSAP.


NG9-1-1 Specific Interwork Function (NIF)

The NIF component of the Legacy PSAP Gateway functional element is expected to provide special processing of the information received in incoming call setup signaling to facilitate call delivery to legacy PSAPs, to assist legacy PSAPs in obtaining the necessary callback and location information, and to support feature functionality currently available to legacy PSAPs, such as call transfer and requests for alternate routing.


NG9-1-1 Specific Interwork Function (NIF)

The NIF component of the Legacy PSAP Gateway must be capable of accepting SIP signaling associated with emergency call originations, as described in Section 4.1. Specifically, the NIF component of the Legacy PSAP Gateway must be capable of receiving and processing an INVITE that includes the following information:• Request URI = urn:service:sos• Max Forwards <70• Record Route = ESRP URI• Route header = PSAP URI resolving at the gateway64• From = Callback Number/Address or “Anonymous,” if unavailable• To: e.g., “sip:[email protected]”• P-A-I = the callback number/address or omitted if call is from a non-initialized mobile caller (i.e., P-Preferred-Identity containing 911 + last 7 digits of the ESN or IMEI expressed as a decimal” is present)• P-Preferred-Identity = 911 + “last 7 digits of the ESN or IMEI expressed as a decimal” (if present for emergency calls originated by non-initialized mobile callers)• Via = ESRP URI (added to other Via headers present in the INVITE message received by the terminating ESRP)• Contact = as received by the terminating ESRP (i.e., a SIP URI or tel URI identifying the user to facilitate an immediate call back to the device that placed the emergency call, or a SIP URI associated with a Legacy Network Gateway)• Supported = as received by the terminating ESRP• SDP = as received by the terminating ESRP• Geolocation = Content Identifier URI or location reference URI• A Geolocation-Routing header set to “yes”.• Call-Info = a URI which, when de-referenced, would yield additional information about the call or a cid: URI that points to additional information populated in the message body• History-Info = as specified in RFC 4244, with a Reason Parameter (will be present if call has undergone diversion).


Handling of Emergency Calls with Non-NANP Callback Information

Traditional MF and E-MF interfaces to legacy PSAPs assume that callback information signaled to a PSAP shall be in the form of a 7/10-digit NANP number. There are specific non-NANP number strings defined for use in scenarios where the callback number is either missing or garbled. It is possible that VoIP or legacy wireless emergency call originations shall contain callback information that is not in the form of (or easily converted to) a 10-digit NANP number. To address this situation, the NIF component of the Legacy PSAP Gateway shall perform a mapping from the non-NANP callback information to a locally significant digit string that can be delivered to the legacy PSAP via traditional MF or E-MF signaling. As described in Sections 7.2.1.1 and 7.2.1.2, the locally significant digit string delivered to the PSAP shall be of the form “NPD/NPA-511-XXXX”. If a pANI of the form NPD/NPA-511-XXXX is sent in the MF sequence corresponding to the callback number, the same digit string can be generated by the Legacy PSAP Gateway and delivered to the legacy PSAP as a pANI that represents location information received by the Legacy PSAP Gateway in incoming signaling.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 112 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39800 NENA-STA-10.2 7.2.2.2

39810 NENA-STA-10.2 7.2.2.2

39820 NENA-STA-10.2 7.2.2.2

39830 NENA-STA-10.2 7.2.2.2

39840 NENA-STA-10.2 7.2.2.2

39850 NENA-STA-10.2 7.2.2.2

39860 NENA-STA-10.2 7.2.2.2

39870 NENA-STA-10.2 7.2.2.3

39880 NENA-STA-10.2 7.2.2.3

39890 NENA-STA-10.2 7.2.2.3


Special Handling Indication

Whether a legacy PSAP supports a traditional MF interface or an E-MF interface, it is possible for the information that appears at the PSAP CPE display to “flash” if the call has first been default- routed or alternate-routed. Today, in a legacy E9-1-1 environment, the decision about whether or not to flash the display at the PSAP depends upon local administration of Emergency Services Number (ESN) information.



In a legacy E9-1-1 environment, default routing occurs when the initial selective routing process at the first SR fails, due to a valid ESN not being produced, or no valid Calling Station Information being available on a wireline call, or no valid cell site and sector information being available on a wireless call. Under these circumstances, the call is sent to the default ESN associated with the incoming trunk group for that call.



Alternate routing occurs when the interface to a selected PSAP is found to be busy for any of these conditions: traffic busy (all trunks in use), night transfer (make-busy key operated), or upon detection of a failure condition (all trunks out of service). The alternate PSAP (or other destination) to which the call is routed may be on the same SR as the first PSAP or it may be served by a different SR.



In a legacy environment, whether flashing shall occur depends on the particular ESN used to point the call to the PSAP. Each SR has a list of ESNs that indicate that flashing shall occur when calls are directed to the associated PSAP. ESN definitions are under local control. An incoming call could be mapped to a flashing ESN at one SR, and the same call could be mapped to a non-flashing ESN at the second SR.



An SR indicates to the PSAP CPE that a flashing display shall be provided by the NPD value or the “II” value signaled to the legacy PSAP in the MF signaling sequence. For PSAPs that support traditional MF interfaces, an NPD digit with a value of 0-3 represents a steady ANI display. An NPD digit with a value of 4-7 represents a flashing ANI display (an NPD value of “8” is used for test calls.) For PSAPs that support an E-MF interface, an II value of “40” indicates a steady display, and a value of “44” represents a flashing display. (An II value of “48” is used for test calls.)



One other scenario in which the II digits are used to communicate “special handling” is where a PSAP supports the delivery of a single 10-digit number over an E-MF interface and expects the Calling Station Number to be delivered, but a 10-digit location reference is signaled instead because the Calling Station Number is not available.



In the current i3 architecture, the ESRP interacts with a PRF to identify alternate routing addresses based on policy information associated with the next hop in the signaling path. The i3 Solution must support a means of signaling forward an indication that alternate/default routing has been applied to an emergency call so that the Legacy PSAP Gateway can determine when to include a Special Handling Indication in the MF signaling it sends to the legacy PSAP65. The ESRP shall use the History-Info header (RFC 4244) and the associated Reason parameter to communicate an indication of alternate/default routing. The NIF component of the Legacy Network Gateway shall determine the appropriate coding of the NPD or II based on the content of received History-Info and Reason headers and provisioning associated with the destination PSAP.


Internal Interface to the PIF Component

The NIF component shall generate an INVITE message to be sent to the PIF component. This message shall contain information from the incoming INVITE message associated with the emergency call, as well as any pANIs mapped by the NIF component. The NIF must determine, based on provisioning, whether the interface to the target PSAP is a traditional or Enhanced MF interface so that it can populate the callback and location information correctly in the INVITE that it sends to the PIF component. The NIF shall obtain callback information from the incoming INVITE message in the following way. If the incoming INVITE message contains a P-A-I header, it shall use the information in this header as callback information. If the incoming INVITE message does not contain a P-A-I header, the NIF shall look in the “From” header. If the “From” header contains a value other than “Anonymous”, the NIF shall use the content of the “From” header as the callback information. If the “From” header contains the value “Anonymous” and a P-Preferred-Identity header is present in the message, the NIF shall use the content of the P-Preferred-Identity as the callback information. The NIF shall obtain location information from the Geolocation header of the incoming INVITE message.



If the PSAP supports a traditional MF interface, then the NIF shall determine, based on provisioning associated with the destination PSAP, whether to populate the “From” header of the INVITE message that it sends to the PIF with an NPD + 7-digit number that is associated with callback information or with an NPD + 7-digit number that is associated with the location information.



If the PSAP expects callback information to be delivered, but the callback information is unavailable or is of the form 911+ “last 7 digits of the ESN or IMEI expressed as a decimal”, and location information is available, the NIF shall signal the location information in the “From” header. If the PSAP expects location information to be delivered and location information is not available, or if neither callback information nor location information is available, the digits “0-911-0TTT” shall be signaled in the “From” header. In a legacy environment, the “TTT” represents an end office identifier associated with the incoming trunk group to the SR. Further study is needed to determine what shall be populated as the “TTT” value for calls originating from VoIP customers.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 113 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39900 NENA-STA-10.2 7.2.2.3

39910 NENA-STA-10.2 7.2.2.3

39920 NENA-STA-10.2 7.2.2.3.1

39930 NENA-STA-10.2 7.2.2.4

39940 NENA-STA-10.2 7.2.2.4 The LPG shall support Emergency Call Transfer as described in Section 7.2.2.4.

39950 NENA-STA-10.2 7.2.2.5

39960 NENA-STA-10.2 7.2.2.6 Test Calls

39970 NENA-STA-10.2 7.2.2.7

39980 NENA-STA-10.2 7.2.3



A legacy PSAP that supports an E-MF interface may be capable of receiving one or two MF signaling sequences. If a PSAP supports the delivery of only one 10-digit number, the NIF shall determine, based on per-PSAP provisioning, whether callback information or location information shall be populated in the “From” header of the INVITE message it sends to the PIF. If the expected 10-digit number (e.g., Calling Station Number) is unavailable, but the second number (e.g., corresponding to the caller’s location) is available, the available 10-digit number shall be signaled in the “From” header. If neither 10-digit number is available, and only one 10-digit number is expected to be signaled over the E-MF interface, the digits “000-911-0TTT” shall be signaled in the “From” header.



If the legacy PSAP supports an Enhanced MF interface in which two 10-digit sequences are expected, and either the Calling Station Number or the location reference is unavailable, the NIF shall substitute the digits “000-911-0TTT” for the missing information in the P-A-I or “From” header. If neither 10-digit number is available, and two 10-digit numbers are expected to be signaled over E-MF interface, the NIF shall substitute the digits “000-911-0TTT” for both the Calling Station Number and the location reference. Further study is needed to determine what shall be populated as the ‘TTT’ value for calls originating from VoIP customers.


INVITE Message Sent from NIF Component to PIF Component

The INVITE message sent by the NIF component to the PIF component shall contain the following information:• Request URI = PSAP URI resolving at the gateway expressed as a tel URI or a sip URI of the form “sip:<TN>@psap1.gateway.com;user=phone”, along with the trunk group parameters that identify the outgoing trunk group to the destination PSAP, as defined in RFC 4904• Max Forwards <70• Record Route = ESRP URI• From = See Table 7-9• To = sip:[email protected]• P-A-I = See Table 7-9• Via = an identifier for the Legacy PSAP Gateway• Contact = as received by the NIF component• Supported = as received by the NIF component• SDP = as received by the NIF component• History-Info = as received (if present in the INVITE message received by the NIF component• Reason = as received (if present in the INVITE message received by the NIF component.


Support for Emergency Call Transfer

When a legacy PSAP determines that it is necessary to transfer an emergency call, it sends a “flash” signal and waits for dial tone. Once the dial tone is received, the PSAP requests the transfer either by operating a key associated with a particular type of secondary PSAP (e.g., fire department) or a particular PSAP destination (e.g., using a speed calling feature), or by manually dialing the number of the desired destination.


Support for Emergency Call Transfer


Alternate Routing Invocation and Notification

Alternate routing allows a network to temporarily re-route calls to a different PSAP when the primary PSAP is unavailable to answer the call, or when connectivity to the primary PSAP is not available due to network failure. The LPG must support Alternate Routing Invocation and Notification as described in Section 7.2.2.5.


The NIF must support and act as the termination point for the test call interface although administrative provisioning processes shall be available to disable it especially under overload situations. The test interface includes the ability of the test caller to offer media and to receive a response and loop back a small number of packets of each media accepted at the PSAP. This provides a mechanism for a caller to determine that a call to a legacy PSAP behind a Legacy PSAP Gateway could not accept video. Legacy PSAP Gateways must refuse offers for video and accept offers for audio and text (which shall be converted by the PIF component and conveyed using existing mechanisms, i.e., TTY). The LPG is responsible for the media loopback required by the test call mechanism. Test calls shall not be passed through the LPG to the Legacy PSAP.


MSRP Interworking in Support of SMS

SMS must be interworked to TTY for delivery to a legacy PSAP using its existing TTY equipment. Originated SMS messages are expected to be interworked to MSRP outside the ESInet. The NIF and/or the PIF must interwork MSRP to Baudot tones. This interwork from MSRP to TTY must be compatible with the similar function provided by the J-STD-110 Text Control Center’s mapping from SMS to TTY.



As described in Section 7.2, the Legacy PSAP Gateway must support an ALI interface that can accept an ALI query from the legacy PSAP and return location information based on the formats specified in NENA 04-001 and NENA 04-005. There is additional information beyond just callback number and location information that may be included in an ALI response. There are various ways that ALI data may be obtained by the Legacy PSAP Gateway so that it can be returned to the legacy PSAP in the expected format.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:13 114 of 115


Functional Element

ExternalRequirement

Num (if supplied)



39990 NENA-STA-10.2 7.2.3

40000 NENA-STA-10.2 7.2.3

40010 NENA-STA-10.2 7.2.3

40020 NENA-STA-10.2 7.2.3

40030 NENA-STA-10.2 7.2.3

40040 NENA-STA-10.2 7.2.4.1 Call Setup Timing



40070 NENA-STA-10.2 7.2.4.2

40080 NENA-STA-10.2 7.2.4.2.1



If the Legacy PSAP Gateway receives callback information (i.e., in the form of a 10-digit NANP number) and location-by-value in the incoming INVITE message from the ESRP, the Legacy PSAP Gateway can use this information to populate the callback number and location fields of the ALI response. Note that the Legacy PSAP Gateway shall have to interact with the MSAG Conversion Service (MCS) if the location information received in incoming signaling (or obtained via dereferencing) is in civic format. This is necessary to ensure that the location information populated in the ALI response message is in the correct format for the legacy PSAP to which it is being delivered. (See Section 5.4.1 for further details regarding the MCS.) If the interaction with the MCS is unsuccessful, the Legacy PSAP Gateway shall provide an indication of “no record found” to the PSAP.



If the legacy PSAP Gateway receives callback information in the incoming INVITE message from the ESRP that is not in the form of (or easily converted to) a 10-digit NANP number, the Legacy PSAP Gateway shall populate the pANI generated by the NIF component (as described in Section 7.2.2.1) as the callback number in the ALI response.



If location-by-reference is received in the incoming INVITE message from the ESRP, the Legacy PSAP Gateway shall have to support the ability to query other elements (i.e., LISs, Legacy Network Gateways) using an appropriate dereferencing protocol, as specified in Section 4.2, to obtain dispatch location for the call. If the location value returned in the dereference response is a civic location, the Legacy PSAP Gateway shall use the MCS and convert the dispatch location value to the appropriate format for population in the ALI response message.



If the location-by-value received in a SIP INVITE message from an ESRP or in a dereference response contains a geodetic coordinate-based location that identifies a shape other than a point or circle with radius, the Legacy PSAP Gateway must convert that geo-coordinate location to a point with uncertainty, using an appropriate algorithm, before populating it in the ALI response message.



The Legacy PSAP Gateway shall use Additional Data structures to populate other fields in the ALI response. If the Additional Data has been delivered to the Legacy PSAP Gateway “by-reference”, the Legacy PSAP Gateway shall need to support the HTTPS GET method described in IETF RFC 7230 to obtain the Additional Data “by-value”. The Legacy PSAP Gateway shall use the information contained in the Call-Info header field of the received INVITE to either identify the address of the target ADR to which the GET shall be directed, or the place in the message body where the Additional Data is provided “by-value”. The Legacy PSAP Gateway shall be capable of processing the XML-formatted Additional Data structures in the message body or received in the dereference response and using it to populate the appropriate fields of the ALI response message. The Additional Data used to populate the ALI response comes from the data in the call signaling and not from the data in the PIDF-LO.


Call Setup timing shall be used by the PIF component of the Legacy PSAP Gateway to determine if the legacy PSAP CPE is correctly interfacing with the Legacy PSAP Gateway. Call Setup timing for Enhanced MF (E-MF) and Traditional MF (NPD + 7-digit ANI) is the same, so only one example of setup timing shall be outlined. Precise details of Call Setup timing can be found in NENA 03-002, ANSI-0600414.1998(2007), and/or Telcordia GR-350-CORE.


Legacy 9-1-1 system policies dictate that a 9-1-1 call is terminated if it encounters two successive call setup failures. If the Legacy PSAP Gateway cannot deliver a call to a legacy PSAP trunk on the first attempt, it shall then attempt to deliver the call to another PSAP trunk, according to its standard hunting or routing algorithms. If the Legacy PSAP Gateway has a call setup failure on the second attempt, it shall terminate the call, and return an appropriate message (i.e., a SIP 500 Server Internal Error message) toward the originating network(s) to indicate such.


The Legacy PSAP Gateway shall determine that a call setup has, or shall fail when the PIF component fails to receive a “wink” from the CPE in response to its off-hook condition (Seizure) toward the legacy PSAP within a specific period of time. Traditional values would suggest that the PSAP return a wink to the Legacy PSAP Gateway within a minimum of four (4) to twenty (20) seconds. Most 9-1-1 systems use the four-second interval as the minimum time period in order to reduce potential call delays on a first try failure. If the Legacy PSAP Gateway has not received a wink condition from the PSAP CPE within the minimum period (i.e. four seconds) after sending an off-hook indication, it shall mark the call as a failure, and proceed as described above (i.e., by sending a SIP 500 Server Internal Error message toward the originating network).


Call Disconnect Timing

Call disconnect timing depends on whether the caller70 or the PSAP disconnects first. It determines how soon the Legacy PSAP Gateway may offer a new call to the legacy PSAP on the same circuit. The Legacy PSAP Gateway must ensure that there is sufficient timing between the disconnection of one call and the presentation of a new call to the legacy PSAP so that the legacy PSAP CPE can reset and be ready in time for the next call.


Call Disconnect Timing When PSAP Disconnects First

If the PSAP disconnects first, the Legacy PSAP Gateway shall wait a sufficient time period after the receipt of the on-hook signal from the CPE to determine that the on-hook condition is a disconnect, and not a hook flash (i.e., a request to generate or cancel a three-way conference). In most legacy implementations, the minimum time period is generally assumed to be approximately 1100 ms to consider the on-hook condition a disconnect request. At this point, the Legacy PSAP Gateway may offer a new call to the Legacy PSAP.

NENA-APCO Standards

Date: 05/06/2023 Time: 22:53:14 115 of 115


Functional Element

ExternalRequirement

Num (if supplied)



40090 NENA-STA-10.2 7.2.4.2.2

40100 NENA-STA-10.2 7.2.5


Call Disconnect Timing When Caller Disconnects First

If the caller disconnects (resulting in the Legacy PSAP Gateway sending an on-hook signal to the legacy PSAP) prior to the legacy PSAP disconnecting, the Legacy PSAP Gateway must wait a sufficient period of time after the PSAP has gone into an on-hook condition so that it is ready to respond to a new call being offered from the Legacy PSAP Gateway. This is sometimes described as a guard interval. Industry has not yet established a “typical” value for this timer. It varies by system, and by PSAP CPE type. Typical minimum values are: 700 ms, 1250 ms, or even 1650 ms between the on-hook condition from the PSAP CPE and the Legacy PSAP Gateway offering a new call to the legacy PSAP. (Under no circumstances shall the Legacy PSAP Gateway offer a call to the legacy PSAP when the legacy PSAP is still in an off-hook condition toward the Legacy PSAP Gateway.) The Legacy PSAP Gateway may set this guard timer value as appropriate for the CPE type, but must not offer new calls until a minimum interval after an on-hook indication has been received by the Legacy PSAP Gateway from the legacy PSAP CPE.


Trouble Detection/Reporting at the Legacy PSAP Gateway

The Legacy PSAP Gateway shall generate messages, alarms, etc. when it encounters problems with a legacy PSAP. The conditions under which a Legacy PSAP Gateway shall generate such messages/alarms shall include:• PSAP initiates a request for alternate routing/activates a “make-busy” switch• The Legacy PSAP Gateway detects a “wink” failure• A PSAP trunk stays in an off-hook condition longer than expected (keeping a circuit from being used).