The file's text, extracted by GovTribe without its formatting.
Instructions (Lot 2)
| Attachment 2b - Compliance Requirements Checklist |
| Independent Verification & Validation (Lot 2) |
| This document outlines the Independent Verification & Validation (IV&V) Lot 2 requirements. For each item, please indicate your compliance level to demonstrate your IV&V capability for that task. |
All responses are to be included on tab "IV&V (Lot 2)". Each requirement has five check boxes (Complies, Complies Partially, Complies with Future Capability, Does Not Comply, Not Applicable (N/A)) of which the Proposer 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.
There is a section in Column V for "Additional Details". Some requirements request detailed descriptions of functionality, process, experience, etc., and the Proposer must provide clear, concise, direct, detailed and specific responses to each item. Attachments are acceptable and should be referenced in "Additional Details".
When selecting a response other than "Complies", the contractor must provide additional details to support the selected compliance level.
Features or components desired by New York State that are not required to be proposed are marked as optional. All items in the Compliance Requirements Checklist must be completed by the Proposer regardless of if the requirement is mandatory or optional.
The responses to each requirement described in this section must include one of the following:
Complies: The proposed IV&V approach meets the RFP requirement. The necessary IV&V methodologies, tools, and expertise are developed and readily available for implementation.
Complies Partially: The proposed IV&V approach addresses the RFP requirement using an alternative, currently developed and available IV&V methodology. Alternatively, the proposed IV&V solution meets some, but not all, of the specific IV&V requirements. The Proposer must clearly explain how their proposed IV&V does not fully comply.
Complies with Future Capability: The proposed IV&V approach will meet the RFP requirement with a capability that will be delivered in a future calendar quarter and year. This future capability must be generally available at no additional cost to New York State.
Does Not Comply: The proposed IV&V solution does not/cannot meet the specific RFP requirement.
Not Applicable (N/A): This IV&V requirement is not relevant to the proposed scope or has not been assessed. Additional details must be provided in the "Additional Details" section.
New York State (NYS) recognizes that the required resources are a collaborative effort of individuals in one organization or, perhaps, several organizations. The Proposer is responsible for understanding and adequately responding to the concepts and requirements included in this Compliance Requirements Checklist.
“All proposers responding to this RFP must adhere to all applicable New York State Information Technology Services (NYS ITS) policies.”
IV&V (Lot 2)
| In order for the State to evaluate bids for Independent Verification & Validation (IV&V) Lot 2 fairly and completely, Proposers are strongly encouraged to provide all of the information requested. | | | |
| Contractors shall indicate a "Compliance Level Response" that addresses each stated checklist item. | | | |
| Covered by RFP Appendix G | CHECKLIST ITEM | Compliance Level Response | |
| GENERAL REQUIREMENTS | | Complies | Complies |
| Partially | Complies with | | | |
| Future Capability | Does | | | |
| Not Comply | Not Applicable (N/A) | | | |
| (Provide details if this box is selected) | Additional | | | |
Details (to support answer)
| GENERAL REQUIREMENTS AND NEXT GENERATION 911 (NG911) VISION | | | | | | |
| Section 1.1.7. | Proposer Vision of NG911 – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| TECHNICAL REQUIREMENTS | | FALSE | FALSE | FALSE | FALSE | FALSE |
| STANDARDS | | | | | | |
| Section 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. | | | | | |
| Section 2.1.2. | Evolving Standards – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.1.3. | Proprietary Solutions and Standards – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| CAPACITY | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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. | | | | | |
| Section 2.2.2. | System Growth – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.2.3. | Scalable Design in Capacity and Coverage – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.2.4. | Lead Times – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| NETWORK | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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).
| Section 2.3.2. | Support of Additional Functionality – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.3. | Diverse Entrances – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.4. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.5. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.6. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| Standards-based protocols shall be used, and the use of proprietary routing protocols is prohibited. | | | | | |
| Section 2.3.7. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.8. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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). | | | | | |
| Section 2.3.9. | IP Network Infrastructure and Equipment – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.10. | Shared Infrastructure – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.11. | Data Center Requirements – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| | 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 | | | | | | |
| Section 2.3.12. | Points of Failure – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.13. | Points of Failure – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.14. | Network Latency – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.15. | Point of Presence (POP) to POP – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.16. | POP to Endpoints – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.17. | Packet Loss – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.18. | Jitter – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.19. | Mean Time to Repair (MTTR) – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.20. | Mean Time Between Failures (MTBF) – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.21. | Network Traffic Convergence – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.3.22. | Aircraft Downlink Capability – Optional | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| INTERCONNECTION TO LEGACY SELECTIVE ROUTERS | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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. | | | | | |
| Section 2.4.2. | Points of Presence – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.4.3. | Inter-tandem Trunks – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.4.4. | Migration of Existing Services – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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.
| Section 2.4.5. | P.001 Grade of Service – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| INTERCONNECTION TO OTHER IP NETWORKS | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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.
| Section 2.5.2. | Network-to-Network Interconnectivity – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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). | | | | | |
| Section 2.5.3. | Network-to-Network Interface Agreement – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.5.4. | Network-to-Network Interface Standards Compliance – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| POWER DISTRIBUTION | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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. | | | | | |
| SUPPORT MAINTENANCE | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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. | | | | | |
| Section 2.7.2. | System Monitoring and Support – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| SECURITY | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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 State IT Contract Terms and Conditions, 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 | | | | | | |
| Section 2.8.2. | Personally Identifiable Information Restrictions – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.8.3. | Security Plan – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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) best 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. | | | | | |
| Section 2.8.4. | Compliance Matrix – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.8.5. | Predictive Analysis and Modeling Capabilities – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| Proposer shall describe its capabilities to provide predictive analysis and modeling to combat security threats. | | | | | |
| Section 2.8.6. | Network Credentials – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.8.7. | Third-party Audit – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.8.8. | Physical Security – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| NEXT GENERATION CORE SERVICES (NGCS) ELEMENTS | | FALSE | FALSE | FALSE | FALSE | FALSE |
| Section 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 |
| Section 2.9.2. | Host Site Locations – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.3. | Future Product Roadmap – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.4. | Legacy Network Gateway (LNG) – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.5. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.6. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.7. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.8. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.9. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.10. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.11. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The LNG solution must be deployed with resiliency and redundancy to provide public safety-grade service as defined in 1.1.4. | | | | | |
| Section 2.9.12. | Star Code Transfers – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.13. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| Contractor’s LNG solution shall provide for LSRG functionality. | | | | | |
| Section 2.9.14. | LNG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.15. | Legacy PSAP Gateway (LPG) – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.16. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The LPG solution must be deployed with public safety-grade resiliency and redundancy. | | | | | |
| Section 2.9.17. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.18. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.19. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The LPG shall convert outbound call transfers to SIP in accordance with the requirements in NENA-STA-010.3f-2021. | | | | | |
| Section 2.9.20. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.21. | LPG – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| 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. | | | | | |
| Section 2.9.22. | Border Control Function (BCF) – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The BCF shall provide logical network security functions between external networks and the ESInet, and between the ESInet and PSAP networks. The BCF is responsible for numerous functions, including: | | | | | |
| • | Border Firewall |
| • | Virtual Private Network (VPN) |
| • | IDS/IPS |
| • | Session Border Controller (SBC) |
| • | Opening and closing of pinholes |
| • | Limiting access to critical components using virtual local area networks (VLANs) |
| • | Call admission control |
| • | Transcoding |
| • | Signaling protocol normalization and interworking |
| • | Network address translation (NAT) |
| • | Codec negotiation |
| • | Support QoS and priority markings |
| • | Media proxy |
| • | Wireless Networks |
The Proposer shall provide details, including drawings, that describe how its proposed BCF meets or exceeds all functions listed above and the requirements described in NENA-STA-010.3f-2021, as well as additional firewall requirements described in NENA-STA-040.2-2024, or the next subsequent version of the NENA documents listed that are publicly available as of the RFP issue date.
| Section 2.9.23. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The BCF solution shall be deployed in a manner to provide a public safety-grade level of service as defined in Section 1.1.4. | | | | | |
| Section 2.9.24. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| BCF management shall include auditing of system log files for anomalies, and processes for responding to and managing security incidents. | | | | | |
| Section 2.9.25. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The BCF must be capable of detecting when silence suppression is present in the 911 call; continuing to use silent suppression if detected; inserting comfort noise if silence suppression is detected; and disabling silence suppression if it is not detected in the call. | | | | | |
| Section 2.9.26. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The BCF shall mediate all incoming 911 calls from VoIP providers to SIP calls in accordance with NENA-STA-010.3f-2021. Any specific variations or non-compliance with this requirement must be identified and documented. | | | | | |
| Section 2.9.27. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The BCF must provide the functionality to maintain logs of all 911 sessions and all additional BCF logging and recording requirements, as specified in NENA-STA-010.3f-2021. | | | | | |
| Section 2.9.28. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s BCF solution shall support transcoding of Baudot tones to real-time text, as described in IETF RFC 4103. | | | | | |
| Section 2.9.29. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s proposed SBC shall recognize if a NAT or a Network Address and Port Translation (NAPT) has been performed on Open Systems Interconnection (OSI) Layer 3, but not above, and correct the signaling message for SIP. | | | | | |
| Section 2.9.30. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s proposed SBC shall enable interworking between networks utilizing IPv4 and IPv6 by using dual stacks, selectable for each SBC interface, based on NENA-STA-010.3f-2021. All valid IPv4 addresses and parameters shall be translated to/from the equivalent IPv6 values. | | | | | |
| Section 2.9.31. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s proposed SBC shall support SIP over the following protocols Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Transport Layer Security over TCP (TLS-over-TCP), and Stream Control Transmission Protocol (SCTP). Protocols supported must be selectable for each SBC interface to external systems. These transport layer protocols are generated and terminated at each interface to external systems. | | | | | |
| Section 2.9.32. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s proposed SBC shall be able to populate the Layer 3 headers, based on call/session type (e.g., 911 calls), to facilitate priority routing of packets. | | | | | |
| Section 2.9.33. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| The Contractor’s proposed SBC shall support encryption for calls that are not protected entering the ESInet, based on NENA-STA-010.3f-2021. | | | | | |
| Section 2.9.34. | BCF – Mandatory | FALSE | FALSE | FALSE | FALSE | FALSE |
| Contractor shall describe the functionality of the proposed BCF solution in sufficient detail to address the requirements outlined, with particular attention given to the user interface and features, and the security aspects. The Contractor shall provide details, including drawings, that describe the different BCF elements that its proposed solution comprises. As part of the details, the Contractor shall identify all expected elements and/or interfaces to be provided by the PSAPs during the transition. | | | | | |
| Section 2.9.35. | Emergency Services Routing Proxy (ESRP) and Policy Routing Function (PRF) – Optional | FALSE | FALSE | FALSE | FALSE | FALSE |
This is the start of the file's text. The full file is on GovTribe.