RFP 29393 Appendix G System Requirements.pdf

RFP 29393 Next Generation 911

Appendix G

System Requirements

Appendix G System Requirements

1. GENERAL REQUIREMENTS

1.1. GENERAL REQUIREMENTS AND NEXT GENERATION 911 (NG911) VISION

1.1.1. Responses to Each Requirement: All responses are to be included in Attachment 2a or Attachment 2b Compliance Requirements Checklist (Lot 1 or Lot 2). Adjacent to each requirement will be five check boxes (Complies, Complies Partially, Complies with Future Capability, Does Not Comply, Not Applicable (N/A)). Contractor must respond by placing an “X” in only one check box per stated requirement. Failure to complete this process properly may result in the rejection of the proposal.

A response to each requirement, including a detailed description of the proposed solution, is required. Do not underestimate the importance of providing detailed descriptions. The details should be sufficient to properly convey the Proposer’s intentions but should not be verbose in nature. Marketing materials are not considered appropriate in-line responses. Proposer may attach marketing materials as separate, supplemental documents, but details are still required to support the answer. Proposer shall not refer to other sections as a response. Even if the response is an exact duplicate of a previous response, the details must be provided in the same row as the requirement. Proposer must not include pricing information in its descriptions and must not refer to pricing.

1.1.2. New York State Requirements: The ESInet, including the design and deployment of interface functions and security measures, must follow current New York State ITS policies and standards unless the New York State ITS policies and standards are enhanced by requirements in this RFP.

1.1.3. Disclaimer of Tariffs: No existing or future tariffs as imposed by New York State Public Service Commission shall apply to this contract. Notwithstanding anything to the contrary set forth in this RFP or in any tariff filed, submitted or provided to New York State, the New York State Public Service Commission or any other Agency prior to or following the effective date in connection with or applicable to the services provided by the Contractor or an approved subcontractor, neither New York State nor the Counties are bound by any such tariff, terms, conditions, restrictions or limitations, and the Contractor disclaims the right to assert otherwise. The intent of the statement is not to limit responses to non-regulated exchange carriers, rather the intent is to allow the widest participation in this process. Further, the statement says and means that the contract will not be subject to tariffs, even though some of the underlying services may in fact be regulated and subject to tariffs.

1.1.4. Public Safety Grade Definition: The national standards listed in the RFP identify the requirements for an Emergency Services IP network (ESInet) and Next Generation Core Services (NGCS) functions must meet or exceed. The term “public safety grade” has been utilized in this RFP to refer to this level of standards compliance. The proposed System of Services must comply with the following public safety grade definitions, in addition to the adopted standards listed in this document:

Reliability: “Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time.” The traditional measure of system or component reliability is Mean Time Between Failure (MTBF). The required MTBF must result in system reliability of 0.99999.

Availability: “Availability is the degree to which a system or component is operational and accessible when required for use.” System availability depends on the Mean-Time To Repair (MTTR) calculation, which measures the time it takes to recover from component failure, a failed system upgrade, operator error, or other scheduled or unscheduled system interruption. Reference section 5.1 SLA Requirements for availability requirements.

Downtime must not exceed five minutes per year, which equates to 99.999 percent availability.

1.1.5. Security: Secure communications must be retained through the following measures, proposer must comply with all applicable NYS Information Technology Services (ITS) technology & security policies/standards, to include cybersecurity, data security, and privacy protections for personal information, ensuring that all subcontractors adhere to the same standards. All systems and services must also adhere. Meet the applicable NENA standards throughout the project, NYS ITS policies/standards shall supersede the NENA standards where applicable. This is required from start to completion of project; documentation of this adherence must be kept and produced to the State upon request. Referenced NENA standards are as follows NENA-STA-040.2-2024, NENA Security for Next Generation 9-1-1 Standard (NG-SEC).

The Lot 2 Contractor shall provide:

A cybersecurity audit of PSAPs before connection to the ESInet. The cybersecurity audit shall follow, at a minimum, the severity categories as defined in NIST FIPS 199, Standards for Security Categorization of Federal Information and Information Systems. The cybersecurity audit shall be conducted in accordance with State cybersecurity policies and other relevant policies.

o With successful completion of a PSAP audit, the Lot 2 contractor will provide the PSAP and DHSES with a report stating the PSAP is in compliance.

o If a PSAP fails an audit, the Lot 2 contractor will provide the PSAP with a report stating the deficiencies, and it will be the responsibility of the PSAP to correct the deficiencies.

o Once a PSAP has corrected the deficiencies, the PSAP will contact DHSES to schedule a second audit by the Lot 2 contractor to ensure compliance. A second audit cost shall be included within Lot 2’s cost proposal submission.

Upon successful completion of the Lot 2 Contractor’s PSAP cybersecurity audit, DHSES will provide a notice to the Lot 1 Contractor to proceed with PSAP connection.

After initial connection is complete and passed, contractor shall conduct yearly audits of all PSAP’s to ensure compliance.

Contractor, suppliers, and subcontractors shall protect all data in accordance with the terms and conditions of applicable contractual agreements between the contractor and supplier and NYS DHSES.

It shall be the responsibility of all contractors, suppliers, and subcontractors to comply with applicable federal, state, and local statutes and regulations that relate to control and authorized use of information and information resources.

All access to information by a non-government employee shall comply with applicable codes of conduct, policies, contracts, laws and regulations.

Persons who are not government employees (e.g., contractors, suppliers, or vendors) shall have appropriate clearances and authorizations in place prior to being granted access to information of any classification other than Public. NYS DHSES reserves the right to review employee qualifications prior to granting access and reserves the right to reject an individual given proper cause. Refer to RFP Section 2.2.11.

Release of Sensitive (Most Sensitive) Data/Information shall only be completed by or at the explicit direction of DHSES and shall be documented when released.

Restricted Information shall be shared only with the explicit permission of the originator.

Permission shall be in writing. Electronic communications are acceptable. Electronic submissions that support the notion of role-based approval or rights-based responsibilities are allowed.

Sensitive Information shall only be shared with the explicit permission of the originator and/or in accordance with applicable laws and regulations. Electronic systems that support the notion of role-based approval or rights-based responsibilities are allowed.

o If the classification is unknown, the information shall be treated as Sensitive (Internal

Use Only) until the proper classification is determined or it is determined to be Public Information by the originator or other applicable laws and regulations.

Release of Sensitive (Most Sensitive) information shall be documented when released subject to a FOIL request.

o If the classification is unknown, the information shall be treated as Sensitive (Internal

Use Only) until the proper classification is determined or it is determined to be Public Information by the originator or other applicable laws and regulations.

All Data shall be safeguarded within the Next Generation 911 System.

Sensitive Data requires encryption as defined in NENA-STA-010.3 and shall be defined in a

Data Protection Policy.

Sensitive (Most Sensitive Information) data is allowed to be stored or transmitted on a network between devices, whether inside or outside a government entity, it must be encrypted.

o Encryption shall be AES 256.

If cloud services are used:

Any cloud services proposed as part of the solution must be disclosed by the proposer and are subject to NYS DHSES review and approval.

The Contractor shall use mechanisms such as Private Key protection and management methods (Key Vaults, Key Management Systems, etc.). For very high assurance security cases, contractor should protect Private Keys with Hardware Security Modules (HSM).

The Contractor shall support audit logging, monitoring, access control and data encryption when Services are offered as Software as a Service model (SaaS).

The use of MFA is required for remote access.

The Contractor should adhere to broadly accepted security conventions, e.g., NIST-800, CIS

Controls, or other locally applicable controls.

Contractor who employs individuals must ensure their employees have received current security training in their assigned area of responsibility with minimum yearly training and certification. Security operations, administration, and maintenance training applies to any individual responsible for securing and/or working on any part of the NG911 system. NYS DHSES can require a service provider to supply validation and assurances of a technician’s knowledge and skill to perform a task.

Rivest-Shamir-Adleman (RSA)- based public-key cryptography using X.509 certificates to authenticate elements, agencies and agents. Mutual authentication must exist between both ends of communication.

An eXtensible Access Control Markup Language (XACML) – based data rights management (DRM) system to control authorization.

Advanced Encryptions Standard (AES) – 256 bit encryption, at a minimum, to provide confidentiality.

Secure Hash Algorithm 1 (SHA-1) or Secure Hash Algorithm 2 (SHA-2) digest-based hashing to provide integrity protection.

DSIG–based digital signatures to provide non-repudiation.

All cloud services must adhere to the requirements stated elsewhere in the document for development and staging environment. All requirements regarding software updates shall also apply to cloud services.

1.1.6. Network Traffic Restrictions: All data traversing the IP network, and subsequent access to that data, is restricted to public safety use only, as required in NENA-STA-010.3f-2021, Section

2.7 Emergency Services IP Networks. Commercial and non-public safety data and access is strictly prohibited from sharing bandwidth dedicated for ESInet use.

The established metrics in this definition can be achieved through system and component redundancy, diversity, resiliency, and other similar engineering methodologies. When the term “public safety grade” is applied in this document, the Proposer should describe how its network and core services system and components from mission-critical functions either meets or exceeds the standards-based public safety grade definition provided in this section.

1.1.7. Proposer Vision of NG911 – Mandatory. New York State is interested in retaining a Contractor that understands and can clearly demonstrate alignment with the industry’s evolution to NENA-compliant ESInet solutions. Each Proposer shall describe its vision of NG911 and how it aligns with NENA’s vision.

2. TECHNICAL REQUIREMENTS

2.1. STANDARDS

2.1.1. Adopted Standards – Mandatory. New York State seeks a standards-based solution that complies with NYS ITS & nationally accepted standards and requirements applicable to IP network architecture, security, and interface functionality. The Proposer must propose an IP network design, deployment, operation, and security that will be in full compliance with the standards, requirements, and recommendations identified in Attachment 2a or Attachment 2b, any successor standards, and any other relevant industry standards. Contractor’s third party vendors, subcontractors and consultants must also be in full compliance with this section.

2.1.2. Evolving Standards – Mandatory. As industry standards evolve, the Contractor’s solution shall be updated/upgraded to maintain compliance with the current version of established industry standards. Within six months of revised standards ratification (if not mandated sooner), solution updates/upgrades must be in development. Within 12 months of revised standards ratification (if not mandated sooner), solution updates/upgrades must be implemented, with no financial impact for features that are required to maintain a standards-based operation. Compliance requirements apply also to the supporting standards referenced within each standard. As solution updates are made to maintain industry standards compliance, the solution shall not abandon services or feature functionality in place at the time of the solution upgrade. The Contractor must uncover any performance or feature changes prior to the upgrade and report them to NYS DHSES for approval. The Contractor must define the process used to review updated standards and implement solution updates/upgrades.

2.1.3. Proprietary Solutions and Standards – Mandatory. Proprietary solutions, or solutions with limited compliance with industry-standards, may be disqualified if it is determined that the solution will not immediately achieve NYS’s goal of interconnectivity and interoperability throughout the State, and with neighboring Emergency Services Internet Protocol Network (ESInet). Proposer shall reveal any use of proprietary standards or protocols in its proposed solution, or state that it fully complies with this requirement. In addition, Contractor shall reveal whether patented technology is utilized in its proposed solution, who owns the patent, and describe any licensing arrangement fees to be included within proposal and requirements. Any limitations, whether technological or philosophical, shall be disclosed in the response.

2.2. CAPACITY

2.2.1. System Capacity – Mandatory. PSAPs in the State received and processed over 19 million

911 calls annual on average. All end-to-end IP network facilities and components must be engineered to support each 911 call across the ESInet, at a minimum, and to comply with system requirements as established in this RFP. The Contractor’s initial design and deployment of the IP network, including all components and physical network segments, shall provide capacity that will support a “busy-hour” concept with potential to exceed 65,000 calls per hour. The system must also be tested to include burst rates over a short period of time, concurrent calls, and overall license restraints. If the PSAP Call Handling Equipment (CHE) has a call queue operational process, the contractor must comply with the PSAPs set call queue depth level. The System of Services should be designed to not exceed 50% utilization of the “busy hour” for the System of Services. The IP network facility and component capacity cannot be downgraded at any point during deployment. Initial design capacities should include call delivery along with additional consideration for Computer-Aided Dispatch (CAD), logging systems, GIS data, streaming media, real-time text, IP traffic, traffic management systems, communication systems, and incident management systems so these applications can be added later with little or no change required in the network.

2.2.2. System Growth – Mandatory. The IP network must be capable of capacity growth commensurate with both planned and actual traffic and usage for life of the contract. Contractor must support any future OSP migrations from TDM to SIP traffic. All current and potential core functions and ESInet applications should be considered (e.g., call-handling systems, Computer Aided Dispatch, logging systems, GIS data, streaming media, real-time text, IP traffic, traffic management systems, communications systems, and incident management systems). The upgrade process shall not interrupt, degrade, or in any way negatively impact network connectivity or established functionality for any system user.

2.2.3. Scalable Design in Capacity and Coverage – Mandatory. The Contractor’s IP network solution must be designed and deployed in a way that is easily scalable, with the ability to grow in both capacity and coverage to 200% of the original design without significant loss of the original IP network investment. A hardware upgrade should not be required for every instance of network capacity expansion.

2.2.4. Lead Times – Mandatory. The System of Services must be scalable to 200% of initial design as specified in section 2.2.3 of this document. If utilization is consistently above 50% for a combined period of eight hours during a 24-hour period and occurs more than two times in ten days, then a notification to NYS DHSES is required. A full report and actions to increase capacity may be required if it is deemed that traffic is showing upward trends. Upon direction of the NYS DHSES, the Contractor shall specify lead times to increase capacities within one month of determining an increase is required. Proposer shall specify lead times required to increase capacities over and above 200% for each ESInet element. This may be in terms of busy-hour calls, network bandwidth, or any other applicable measure. The proposed solution must be capable of handling current and planned IP traffic and usage over the term of the contract.

2.3. Network

2.3.1. Network Management and Configuration – Mandatory. As defined by NENA an ESInet “is a managed IP network that is used for emergency services communications, and which can be shared by all public safety agencies. It provides the IP transport infrastructure upon which independent application platforms and core services can be deployed, including, but not restricted to, those necessary for providing NG911 services. ESInets may be constructed from a mix of dedicated and shared facilities. ESInets may be interconnected at local, regional, state, federal, national, and international levels to form an IP-based internetwork (network of networks). This term ESInet designates the network, not the services that ride on the network.”

New York State desires to implement a public safety-grade ESInet as a service and managed in accordance with SLAs listed in this document. Contractor shall design such a network to provide interconnectivity for New York State entities described in this document and deploy NGCS functions and components necessary to handle all call-delivery operations in the State.

Additionally, the ESInet must be reconfigurable to allow for Point Of Interconnection (POI) addition, removal, or transfer (e.g., two PSAPs procure a shared call-handling system and abandon their individual systems, requiring a POI location change).

2.3.2. Support of Additional Functionality – Mandatory. 911 call delivery is the initial focus during the implementation of the System of Services. New York State seeks to have the ability to transition additional PSAP functions to the IP network after call delivery is transitioned to the System of Services. The ESInet should provide the options to include other data-sharing public safety applications and support additional designated touchpoints in the future. This would include critical data and information transport that supports core functions, such as CAD, GIS and logging.

2.3.3. Diverse Entrances – Mandatory. The network shall be designed with diverse entrances (e.g., “east-west” entrances) into each building identified in Attachment 4 and any location that is part of the IP network, including data centers or other buildings housing mission-critical core services associated with the State’s ESInet. Primary and redundant links shall not share common routes, trenches, or poles. If last-mile facility or building construction is required, Contractor shall so indicate. If this is not possible at a given location, Contractor shall indicate how it intends to provide redundant and resilient connectivity to that location. Proposer must share design documentation and put in place required agreements or MOU’s with any and all service providers to ensure compliance with these requirements. The proposer understands and agrees that it is ultimately responsible to ensure all information is provided to NYS DHSES. New York State is open to proposals that provide non-terrestrial transport if noted as optional in the design submissions and priced as an option in the Cost Proposal. Please note that terrestrial transport must be the primary transport, but it is understood that non-terrestrial options provide additional resiliency by adding layers of redundancy, especially in underserved areas. Such options may include cellular, satellite and/or microwave connectivity. The State encourages the inclusion of such options for consideration.

2.3.4. IP Network Infrastructure and Equipment – Mandatory. All network equipment shall be carrier class, new and current manufacture. All servers, systems, routers, switches, and other network equipment shall support IPv4 and IPv6, and be capable of running dual protocol stacks.

2.3.5. IP Network Infrastructure and Equipment – Mandatory. The Contractor’s network solution will adhere to the International Organization for Standardization’s (ISO) Open Systems Interconnection (OSI) model, Layer 1 through Layer 7.

2.3.6. IP Network Infrastructure and Equipment – Mandatory. Standards-based protocols shall be used, and the use of proprietary routing protocols is prohibited.

2.3.7. IP Network and Equipment – Mandatory. Resiliency, or fast failover, may be achieved using the Bidirectional Forwarding Detection (BFD) protocol as defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 5880 and RFC 5881, or other standards-based, non-proprietary methods approved by the State. If BFD or similar protocols are utilized, Proposer must provide deployment details.

2.3.8. IP Network Infrastructure and Equipment – Mandatory. All routers and switches must support multicast routing and switching. The applicable base protocols are Internet Group Management Protocol (IGMP) and Protocol Independent Multicast (PIM).

2.3.9. IP Network Infrastructure and Equipment – Mandatory. The network equipment shall support Quality of Service (QoS) marking for prioritizing traffic in the network using Differentiated Services Code Point (DSCP) protocol. While the network can change DSCP values through rules, the values typically are set by the system or functional element that originates the traffic. Network routers and switches shall not be configured in such a manner as to change DSCP values set by originating functional elements.

2.3.10. Shared Infrastructure – Mandatory. New York State understands that Contractors may propose the use of infrastructure that is shared between other customers. No system or component failure, administrative action, or other activity associated with other customers shall impact the availability and reliability of the State’s ESInet.

2.3.11. Data Center Requirements – Mandatory. Data centers utilized in the design, deployment, and operation of the ESInet and core services must possess and maintain a Tier 3 rating, at a minimum, although a Tier 4 data-center rating is preferred.

Tier I: Basic Capacity Tier II: Redundant Site Infrastructure Tier III: Concurrently Maintainable Tier IV: Fault-Tolerant

2.3.12. Points of Failure – Mandatory. The mission-critical IP network shall be designed with no single point of failure. No single point of failure will be allowed within the ESInet including any equipment and/or networking that may be located outside New York State but involved in the provision of NG911 service. Any response which contains a single point, or multiple single points (i.e., within a series process) of failure will be disqualified. However, this does not include those PSAPs for which true physical diversity (for ESInet connectivity) is either unavailable or cost-prohibitive to provide. The response must indicate which PSAP locations will not be provided with true physical diversity.

2.3.13. Points of Failure – Mandatory. All equipment, including established regeneration stations, must include redundant processors and power supplies, and be supported by an Uninterruptible Power Supply (UPS) system (sufficient to carry systems until the alternate power source is online and transferred) and alternate power source in a properly conditioned environment. The alternate power source must be tested under load at least weekly, must support full load operation for at least 72 hours without refueling, and the Proposer must detail refueling plans in their proposal for outages lasting longer than 72 hours.

2.3.14. Network Latency – Mandatory. The ESInet shall be designed to operate with less than 50 milliseconds (ms) of latency. Proposer shall specify the guaranteed maximum latency (less than 50 ms) under a full-load condition, and include how that information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.15. Point of Presence (POP) to POP – Mandatory. Proposer shall specify the guaranteed maximum latency from interconnection facility (aka Point Of Presence, or POP) to interconnection facility, and include how that information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.16. POP to Endpoints – Mandatory. Proposer shall specify the guaranteed maximum latency from interconnection facilities to the network interface device located at the entrance to the customer’s premises, and include how that information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.17. Packet Loss – Mandatory. The ESInet shall be engineered to keep the packet loss budget under 1%. Proposer shall specify the guaranteed maximum end-to-end packet loss (less than 1%) across its network. This specification also shall include any loss characteristics associated with another carrier’s network or any applicable wireless links. Audio media streams are the most sensitive to packet loss. ESInets should be designed without oversubscription. The Proposer must provide how packet loss information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.18. Jitter – Mandatory. The ESInet must be designed to maintain less than 20 ms variation in the end-point jitter buffers. Proposer shall specify the guaranteed maximum variation in endpoint jitter buffers (less than 20 ms), and include how variation information will be gathered, calculated, and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.19. Mean Time to Repair (MTTR) – Mandatory. Proposer shall specify the MTTR characteristics of its proposed solution. These specifications shall reflect the end-to-end solution, as well as components or subsystems that are subject to failure. Proposer shall include how MTTR information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.20. Mean Time Between Failures (MTBF) – Mandatory. Proposer shall specify the MTBF characteristics of its proposed solution. The specifications reflect the end-to-end solution, as well as components or subsystems that are subject to failure. Proposer shall include how MTBF information will be gathered, calculated and provided to NYS DHSES, Office of Interoperable and Emergency Communications.

2.3.21. Network Traffic Convergence – Mandatory. Proposer shall specify convergence protocols and the estimated or guaranteed network convergence time of IP traffic at any point within the proposed solution, including how convergence information will be gathered, calculated, and provided to NYS DHSES, Office of Interoperable and Emergency Communications. The guaranteed network convergence time must meet requirements of call handling solutions deployed at PSAPs in New York State.

2.3.22. Aircraft Downlink Capability – Optional. Agencies may have the capability of capturing live video footage of emerging and ongoing public safety incidents using aircraft. The agencies may desire to provide this video data to New York State PSAPs for eventual dissemination to public safety personnel. The Proposer should describe how providing this data to New York State PSAPs could be incorporated into the ESInet. The Proposer should identify any specific needs, risks, or constraints of including this capability into the ESInet. If applicable, the Contractor should provide any pricing related to this capability on the Optional Tab of the Cost Proposal Worksheet.

Costs related to this capability should not be included in the base price calculation of the ESInet.

2.4. INTERCONNECTION TO LEGACY SELECTIVE ROUTERS

2.4.1. Legacy Network and PSAP Gateways – Mandatory. Contractor must provide redundant, resilient Legacy Network Gateways (LNGs) with Legacy Selective Router Gateway (LSRG) functionality to allow the Legacy selective routers to transfer calls with Automatic Number Identification (ANI) and Automatic Location Identification (ALI) information to deployed NGCS and vice versa. Legacy functionality and components must be in place and operational during the NG911 transitional phase until all dependent PSAPs have completed the transition and the State concurs with discontinuing Legacy functionality.

2.4.2. Points of Presence – Mandatory. Contractor must provide multiple POI for Originating Service

Providers (OSPs) in each Local Access and Transport Area (LATA). The Contractor must facilitate the OSPs to diversely connect to a minimum of two POIs in each LATA. Documentation must be kept, maintained and provided to NYS DHSES of the OSPs and the POIs they are connecting to in each LATA.

2.4.3. Inter-tandem Trunks – Mandatory. Contractor must provide inter-tandem trunks between the

State ESInet and legacy selective routers during the transition, and for tandems identified by NYS DHSES, Office of Interoperable and Emergency Communications, that are necessary to support transfers to neighboring agencies outside of the ESInet footprint.

2.4.4. Migration of Existing Services – Mandatory. The Contractor shall be responsible for the migration of existing 911 services to the ESInet and NGCS at all interfaces between the Contractor and other emergency call originating network operators to accomplish 911 call delivery which meets the quality and reliability requirements of this RFP. This includes stating the terms, conditions, procedures, or processes for interconnection and exchange of information between other carrier’s networks and systems and the Contractor’s networks and systems. Unless the parties otherwise agree, such terms, conditions, procedures or processes shall follow any applicable State of New York laws, telephone industry practices, NENA standards and recommended practices, or applicable US telecommunication law.

The Contractor is expected to work closely with other network operators and to cooperate fully with them in order to accomplish successful transition to the i3-based ESInet. The terms, conditions, procedures or processes shall not impose onerous requirements on other network operators and shall be stated in the proposed solution. Contractor must manage all contracting and negotiation procedures, and the establishment of interconnection agreements and/or memorandums of understanding, in addition to the integration of all OSPs to the ESInets.

Proposer shall explain how it has worked with legacy OSPs with similar projects and shall provide specific plans for working with established legacy 911 service providers in New York.

2.4.5. P.001 Grade of Service – Mandatory. Proposer’s solution must include the process that will be utilized to analyze the current trunk engineering for 911 traffic, and to validate any applicable trunk rebalancing for P.001 grade of service.

2.5. INTERCONNECTION TO OTHER IP NETWORKS

2.5.1. New York State Regional ESInet – Mandatory. New York City is in implementation stages of an IP network to support interoperability functions that include data exchange, system sharing, and backhaul. New York City may request to migrate existing functionality from their regional ESInet to the statewide System of Services. Contractor must plan for and facilitate the migration of PSAPs and existing functionality from their system to the statewide System of Services if necessary. Contractor shall coordinate and cooperate with existing New York City ESInet vendors and representatives to design, plan, and carry out the migration.

If in the instance other entities (tribal, DoD) do not want to integrate into the Statewide ESInet and develop their own regional ESInets, the Contractor must support the integration of these systems, where necessary, and provide the requirements and process for interconnection. Contractor shall assess the established regional networks to determine compliance with applicable requirements and standards and needs to facilitate a successful integration. Contractor shall cooperate with existing regional ESInet vendors and representatives to design, plan, and carry out the integration.

Proposer must take into account and address the possibility that future system integrations may include hosted CHE controllers supporting one to many PSAPs and regional ESInets with NGCS and/or IP Selective Routers (IPSR) solutions.

2.5.2. Network-to-Network Interconnectivity – Mandatory. There will be future need to provide interconnectivity with IP networks external to New York – e.g., other state ESInets, and the Nationwide Public Safety Broadband Network (NPSBN) implemented by the First Responder Network Authority (FirstNet). Proposer shall describe its process for interconnecting established and standards-compliant IP networks to the Statewide ESInet. The design and deployment shall be in compliance with Network-to-Network Interface (NNI) standards established by the Alliance for Telecommunications Industry Solutions (ATIS). All interconnections shall adhere to the State’s security requirements included in this RFP. The Proposer shall detail plans for ESInet interconnection to the States of Vermont, Connecticut, New Jersey and the Commonwealths of Massachusetts and Pennsylvania, as well as the Canadian provinces of Ontario and Quebec (either separately or as an international interconnect to Canada, as appropriate). Costs to establish these connections must be provided in the Cost Proposal Spreadsheet (Attachment 1a).

2.5.3. Network-to-Network Interface Agreement – Mandatory. An agreement must be established between the selected Contractor, DHSES, and authorized point of contact for each entity or regional IP network that will share a POI with the Statewide ESInet. Integration touch points will be determined through active collaboration between the county or regional network authority and the selected Contractor. The agreement shall delineate clear lines of responsibility for the network security, management, and monitoring functions between the designated network authorities. The Contractor shall describe its process and requirements for the agreement development and execution.

2.5.4. Network-to-Network Interface Standards Compliance – Mandatory. The Contractor shall confirm standards compliance for any interconnected network not previously identified by NYS DHSES that is utilized by the Contractor as a service-providing measure.

2.6. POWER DISTRIBUTION

2.6.1. Power and Redundancy – Mandatory. Contractor will maintain redundant power feed, distribution, supplies and backups that sustain vendor-displayed and -supported core and edge network components. Contractor shall identify any point in the network that does not meet the stipulated power and redundancy and provide alternate plans to achieve requirement compliance.

In addition to redundant feeds, distribution, supplies and backups, all components must be supported, at minimum, by an Uninterruptible Power Supply (UPS) system (sufficient to carry all systems until the alternate power source is online and transferred) and alternate power source in a properly conditioned environment. The alternate power source must be tested under load at least weekly, must support full load operation for at least 72 hours without refueling, and the Proposer must detail refueling plans in their proposal.

2.7. SUPPORT MAINTENANCE

2.7.1. System Monitoring and Support – Mandatory. All facets of the ESInet shall be monitored on a staffed (i.e., humans always present and on-duty at the monitoring location) 24/7/365 basis. The monitoring and service management tools must be separate, distinct and not dependent on ESInet infrastructure. Proposer shall provide a description for 24/7/365 maintenance support for the life of the solution. Contractor’s support shall be provided in conformance with its understanding of public safety maintenance windows and associated notification processes, with consistent approaches to problem resolution, change management processes, supporting systems, incident management, release management, warranty and licensing maintenance process, and adherence to NYS DHSES policies and system monitoring best practices. The Offeror shall describe how it conducts lifecycle planning.

2.7.2. System Monitoring and Support – Mandatory. Contractor shall provide a single point of contact on a 24/7/365 basis for PSAPs and DHSES to report, escalate, and receive status updates on incidents affecting the System of Services as well as other communications related to the System of Services. Contractor shall provide at least two contact methods that are fully independent of each other and of the System.

2.8. SECURITY

2.8.1. Cybersecurity – Mandatory. For the purposes of this document, cybersecurity is defined as the established systems and processes focused on protecting computers, networks, programs, and data from unintended or unauthorized access, modification, or destruction. In addition to any specific security measures identified elsewhere within this RFP and NYS ITS policies and standards, Proposers are encouraged to provide additional information on any additional security measures taken to ensure the safe and secure operation of the ESInet. The security requirements established in the applicable standards listed in Appendix F apply equally to all elements of the system requested in this RFP, including but not limited to components located in the following building types:

Data centers PSAPs Backup Facilities Network-housing structures Regeneration sites and other buildings housing any element or device as part of the overall system

2.8.2. Personally Identifiable Information Restrictions – Mandatory. Contractor shall develop policy and procedures to demonstrate compliance with applicable State laws and requirements regarding confidentiality and privacy of Personally Identifiable Information (PII). Contractor will facilitate DHSES Compliance with New York’s Personal Privacy Protection Law (Public Officers Law Article 6-A) as needed.

2.8.3. Security Plan – Mandatory. A comprehensive security plan is a critical component of the

Statewide ESInet deployment. Contractor shall maintain a security plan, including mitigation, monitoring, alerting, incident-response, continuity of operations plan, and logging processes.

Proposer shall provide information on specific hardware components and software systems incorporated in the proposed security plan. Contractor’s security plan is required to utilize the latest relevant NYS ITS policies & standards and NENA specifications and the National Institute of Standards and Technology (NIST) 800-88 data-sanitization standards, and shall incorporate the intentions of the Communications Security, Reliability, and Interoperability Council (CSRIC)1 best

1 https://www.fcc.gov/communications-security-reliability-and-interoperability-council-ix: WG1A, WG2A, WG2B, WG4A, WG4B, WG4C, WG5A, WG6, WG7 and WG8.

practices. The Proposer shall describe its plan for not less than annual penetration testing in the development environment. All applicable rules and regulations of the Federal Communications Commission (FCC), in addition to those specified herein, shall apply.

2.8.4. Compliance Matrix – Mandatory. Using the instructions in NENA (NENA-REF-012.1-2025), Proposer shall provide a compliance matrix as outlined in the NENA NG-SEC Audit Checklist; the matrix shall identify whether the proposed solution Complies (Yes), Does Not Comply (No), or is Not Applicable (N/A) to the identified requirement(s) for each audit question. The completed NG- SEC Audit Checklist must be submitted with the proposal.

2.8.5. Predictive Analysis and Modeling Capabilities – Mandatory. Proposer shall describe its capabilities to provide predictive analysis and modeling to combat security threats.

2.8.6. Network Credentials – Mandatory. Proposer’s solution shall provide a process so that devices and carriers outside the ESInet shall not have credentials, per NENA-STA-010.3f-2021, “Security” section or its successor document.

2.8.7. Third-party Audit – Mandatory. Contractor shall complete an annual third-party security audit at its cost and allow for additional annual third-party security audits at the request and cost of NYS

DHSES.

2.8.8. Physical Security – Mandatory. All structures housing ESInet components must have security and access-control systems that ensure that only duly authorized individuals can access the areas housing systems and network equipment related to the ESInet. Workstations or other equipment connected to the ESInet shall be housed in secured, access-controlled areas. Any devices, power distribution, and cross-connect panels feeding the cages or rooms housing systems related to this project shall be similarly protected.

2.9. NEXT GENERATION CORE SERVICES (NGCS) ELEMENTS

2.9.1. Network and Solution Diagram – Mandatory. Proposer shall provide a network and solution diagram that clearly depicts the proposed transitional and end-state for the ESInet, taking into account the jurisdictions in Attachment 4.

In addition, Contractor shall provide and maintain an “as-built” diagram of the System of Services.

In the “as-built” diagram, diversity needs to be clearly identified from the ingress Border Control Functions (BCFs) to the PSAPs. Documentation must be maintained for all ingress and egress connections to the ESInet. Every ingress and egress connection must have at least one paired diverse connection to or from the ESInet. DHSES reserves the right to request additional or changes to existing documentation and network designs as it deems necessary so they may support and maintain proper oversite of the statewide network. The Contractor will work with DHSES to adjust documentation and “as-built” diagram to meet DHSES’s requirements. All documentation and “as-built” diagram shall be viewed as ’living’ documents and kept current, updated and distributed as changes are made.

The following functional elements and services shall be included:

Legacy Network Gateways (LNG) Legacy PSAP Gateway (LPG) Border Control Function (BCF)

Emergency Services Routing Proxy

(ESRP)

Policy Routing Function (PRF)

Emergency Call Routing Function (ECRF) Location Validation Function (LVF) Spatial Interface (SI) Location Database (LDB)

Discrepancy routing Logging and recording Time Server

2.9.2. Host Site Locations – Mandatory. Proposer shall provide the proposed locations for hosting core service elements that service NYS DHSES, including a secondary backup location and the data center tier level for the host sites.

2.9.3. Future Product Roadmap – Mandatory. The Proposer shall provide a future product roadmap. Roadmap items should include an estimated time of feature availability. Supporting details should describe the established frequency of future product roadmap notifications.

2.9.4. Legacy Network Gateway (LNG) – Mandatory. The LNG is a signaling and media interconnection point between callers in legacy call-originating networks (E911) and the NENA NG911 i3 architecture. The LNG shall log all calls it receives and processes and shall permit the uploading of daily log files to a network monitoring and management system for analysis. The LNG shall allow for ad hoc uploads of log files for troubleshooting and incident response. All call activity on both the legacy side (Time-Division Multiplexing, or TDM) and the IP side of the LNG shall be logged. The LNG shall have Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) functionality to detect and mitigate Distributed Denial of Service (DDoS) and other attacks from both the TDM side and the IP side.

2.9.5. LNG – Mandatory. The LNG shall provide the capability to obtain location information to define, create, populate and send the correct Presence Information Data Format – Location Object (PIDF-LO) parameter to the correct ESRP or terminating PSAP, as described in NENA-STA- 010.3f-2021.

2.9.6. LNG – Mandatory. The LNG shall convert all incoming 911 calls to Sessions Initiation Protocol

(SIP) calls in accordance with the SIP requirements of NENA-STA-010.3f-2021. Any Contractor variations and/or non-compliance with the SIP requirements of NENA-STA-010.3f-2021 must be identified and noted. Contractor shall provide details regarding an NG911 Interwork Function (NIF) or Protocol Interworking Function (PIF) if one or both are employed with the LPG.

2.9.7. LNG – Mandatory. The LNG external interfaces shall comply with NENA-STA-010.3f-2021 and other applicable interface standards and requirements adopted by DHSES and documented in Appendix F.

2.9.8. LNG – Mandatory. The LNG shall support obtaining the callback number associated with any pseudo-ANI (pANI) data that does not include the callback number. This may require the Contractor to obtain the callback number from the wireless or Voice Over Internet Protocol (VoIP) provider and may include additional recurring and non-recurring costs that are independent of this RFP. The Contractor shall be responsible for all recurring and non-recurring costs associated with this requirement.

2.9.9. LNG – Mandatory. The LNG must facilitate logging of all events and 911 calls received and processed. Each call log shall contain all relevant parameters defined in NENA-STA-010.3f-2021,

4.12 Logging Service.

2.9.10. LNG – Mandatory. All LNG log files shall be capable of being extracted in near real-time and shall be in a format suitable for importing into a spreadsheet or word-processing program.

2.9.11. LNG – Mandatory. The LNG solution must be deployed with resiliency and redundancy to provide public safety-grade service as defined in 1.1.4.

2.9.12. Star Code Transfers – Mandatory. The legacy selective router gateway shall support selective transfer, commonly known as star code transfers, made by and to PSAPs connected to legacy 911 systems (i.e., legacy PSAPs) for calls destined for PSAPs connected to the statewide ESInet, or to neighboring PSAPs outside of New York’s ESInet. Proposer must provide a detailed description of how this is achieved.

2.9.13. LNG – Mandatory. Contractor’s LNG solution shall provide for LSRG functionality.

2.9.14. LNG – Mandatory. Proposer shall provide the proposed locations for hosting the primary

LNGs that will serve DHSES, including the data center tier level for the host sites.

2.9.15. Legacy PSAP Gateway (LPG) – Mandatory. The LPG is a signaling and media interconnection point between legacy PSAP CHE and the NGCS. The LPG enables the transfer of calls from the ESInet to a PSAP that may not have upgraded its CHE to an i3-capable call-handling system. The LPG also allows the legacy PSAP to transfer or alternate-route legacy TDM calls to another PSAP on the ESInet. The LPG shall log all calls it receives and processes and shall permit the uploading of daily log files to a network monitoring and management system for analysis. The LPG shall allow for ad hoc uploads of log files for troubleshooting and incident response in real-time or near real-time. All call activity on both the legacy (TDM) side and the IP side of the LPG shall be logged. The LPG shall have IDS/IPS functionality to detect and mitigate DDoS and other attacks from the IP side.

2.9.16. LPG – Mandatory. The LPG solution must be deployed with public safety-grade resiliency and redundancy.

2.9.17. LPG – Mandatory. The LPG shall support a SIP interface toward the ESInet, as defined in NENA-STA-010.3f-2021. Contractor shall also provide details regarding an NG911 NIF or PIF if one or both are employed with the LPG.

2.9.18. LPG – Mandatory. The LPG shall support both Centralized Automatic Message Accounting

(CAMA) and ALI interfaces toward the PSAP CHE that are compliant with the requirements of NENA-STA-010.3f-2021.

2.9.19. LPG – Mandatory. The LPG shall convert outbound call transfers to SIP in accordance with the requirements in NENA-STA-010.3f-2021.

2.9.20. LPG – Mandatory. The LPG shall support star codes as defined in NENA-STA-010.3f-2021, with the exceptions that the star codes may be up to three digits in length.

2.9.21. LPG – Mandatory. The LPG must facilitate logging of all events, and 911 calls received and processed. Each call log shall contain all relevant parameters identified in NENA-STA-010.3f- 2021, Section 4.12.

2.9.22. Border Control Function (BCF) – Mandatory.