6-Appendix E - Technical Combined.xlsx
XLSX spreadsheet 78 KB Posted
- Attached to
- Next Generation 9-1-1 Evolution
- Solicitation number
- GSS26716-E911_SVC
- Issued by
- Delaware
About this file
Technical Requirements Document Summary
This is a technical requirements specification document for the State of Delaware's Next Generation 9-1-1 (NG9-1-1) Evolution procurement, outlining detailed compliance expectations for vendors proposing ESInet, NGCS, and Call Handling as a Service (CHaaS) solutions with integrated recording capabilities. The document establishes mandatory technical specifications across three primary functional areas: General Requirements (covering industry standards evolution, change management, software release management, warranty, availability, incident reporting, escalation procedures, backup and restoration, maintenance logging, storage and delivery, PSAP facilities coordination, spare parts management, project planning, and 24/7 NOC/SOC support); CHaaS and Recorder Requirements (specifying hardware-based call-handling architecture for eight State PSAPs with geodiverse datacenters, NG911 i3 compliance deployed as PIDF-Lo, integration with existing Tyler Technologies and Central Square CAD systems, redundant network connectivity with no single points of failure, SOC 2 compliance, three-year recording retention, comprehensive mapping functionality with GIS integration including RapidSOS and aerial imagery services, multi-tenant capabilities supporting ACD and ring-all configurations, text-to-911 integration, real-time statistics, call monitoring and barge-in capabilities, speed dials with 100+ entries, and extensive MIS reporting); and ESInet-NGCS Requirements (mandating fully diverse network architecture across core sites, aggregation sites, points of interconnection, and PSAP locations with carrier diversity including last mile, support for IPv4/IPv6 dual stacks, BGP with BFD, multicast routing, DSCP QoS marking, network traffic convergence under 54 milliseconds, MOS of 4.0, scalability for 50 percent bandwidth growth, and redundant power supplies with 24-hour generator backup at Tier 3 or higher facilities capable of withstanding EF5-category winds).
The document requires vendors to provide detailed compliance responses for each technical requirement, selecting one of three options—Comply, Does Not Comply, or Partially Complies—with substantive explanatory comments. Critical infrastructure requirements include implementation of NENA 75-001.1 Security Standards, completion of NG-SEC Audit Checklists, multifactor authentication for all system access, AES-256 encryption for sensitive data at rest and in transit, TLS for SIP signaling, SHAKEN caller identity verification, 3-2-1 backup strategy with quarterly backup testing, annual internal security assessments with external assessments every three years, and comprehensive incident response policies. Vendors must demonstrate operational experience with specific technologies, including PIDF-LO implementations, Intrado ESInet/NGCS integration, CAD manufacturer integrations (particularly cloud-based systems), mobile laptop call-taking positions with dual-screen configurations, radio headset integration, and advanced features such as AI/ML applications for administrative call handling and excessive call location analysis. The procurement explicitly requires vendors to provide onsite technical support resources (minimum four certified staff residing within Delaware), accept independent third-party solution validation, deliver comprehensive acceptance testing plans at least 30 days prior to execution, and commit to detailed project management including biweekly status calls with written progress reports within 24 hours. Training requirements mandate both train-the-trainer and end-user models accommodating 24/7 shift schedules, with onsite coaching for a minimum of four hours per shift immediately following cutover, and all training materials provided in digital and hardcopy formats.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 14-Appendix M ESInet-NGCS Service Level Agreement.pdf | ||
| 1-26716-E911 SVC.pdf | ||
| 7-Appendix F - Interfaces Integrations.xlsx | XLSX spreadsheet | |
| 4-READ ME FIRST Appendix C Online Bid Submission Portal Instructions.pdf | ||
| 8-Appendix G - CAD Mobile Data Functional Specifications.xlsx | XLSX spreadsheet | |
| 13-Appendix L CHaaS-Recorder Service Level Agreement.pdf | ||
| 11-Appendix J - Questionnaire.xlsx | XLSX spreadsheet | |
| 10-Appendix I - Fire Records Specification Inspections.xlsx | XLSX spreadsheet | |
| 2-Appendix B - Pricing CHaas-REC and ESInet-NGCS.xlsx | XLSX spreadsheet | |
| 12-Appendix K - Professional Services Agreement Draft.pdf | ||
| 9-Appendix H - Law Enforcement Records Management Specifications.xlsx | XLSX spreadsheet | |
| 5-Appendix D Required Vendor Forms.xlsx | XLSX spreadsheet | |
| 3-Appendix B1 - Pricing CAD, Mobile, LERMS and Fire RMS.xlsx | XLSX spreadsheet |
Show all 13
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Each tab contains specific requirements, applicable to all Vendors regardless of the solution(s) they are proposing, as indicated by the title of each tab. For each requirement, the vendor is required to clearly select one (and only one) of the three options (Comply, Does Not Comply, Partially Complies) from the Compliance column (E), and to provide additional descriptive information in the Comments column (F). |
| For the Technical ESInet-NGCS tab, there is an additional column which is titled application (E), which must be completed. For each requirement, the vendor is required to clearly select one (and only one) of the three options (Comply, Does Not Comply, Partially Complies) from the Compliance column (F), and to provide additional descriptive information in the Comments column (G). |
Technical General
| State of Delaware | Vendor Response Required | Vendor Response Required | |||
| REQ # | Function | Process | Requirements | Compliance | Comments |
| 1.1 | General | Industry Standards Evolution | As industry standards evolve, the Vendor’s solution shall be upgraded to maintain conformance with the current version of established industry standards. The Vendor’s solution shall support new call-handling and security industry standards within 18 months of ratification of applicable industry standards. Conformance requirements apply also to the supporting standards referenced within each standard. | ||
| 1.1 | General | Industry Standards Evolution | As solution updates are made to maintain conformance, the solution shall not abandon services, features, or functionality in place at the time of the solution upgrade. The Vendor must divulge and justify any performance or feature changes prior to the upgrade and report them to the State for approval. | ||
| 1.2 | General | Change Management | Documented change-management process including system and scope changes, team member changes, as well as scheduled and emergency software & configuration changes | ||
| 1.2 | General | Change Management | A Method of Procedure (MOP) with backout plan for review by the State minimum 72 hours prior to planned maintenance activities | ||
| 1.2 | General | Change Management | A means for the State to request changes and receive updates on progress | ||
| 1.2 | General | Change Management | Defined backup procedures | ||
| 1.3 | General | Change Orders | The Vendor shall respond to the State’s request for new feature/functionality within a reasonable timeframe, (e.g. 2 weeks for simple things like configuration changes, 6 weeks for complex things like software development). Responses shall include important factors such as request description, cost, timeframe, risk, etc.. | ||
| 1.3 | General | Change Orders | The Vendor shall submit and respond to all system change orders in writing. | ||
| 1.3 | General | Change Orders | All change orders require approval by the State, or designated representative, prior to performing work. | ||
| 1.3 | General | Change Orders | The State will not accept change orders resulting in additional costs unless requested by the State. | ||
| 1.4 | General | Software Release Management | The Vendor shall describe the frequency of scheduled software releases and the decision-making processes involved in deciding what features and defect resolutions to include in a scheduled release. | ||
| 1.4 | General | Software Release Management | Maintenance releases and feature releases shall be provided to all State PSAPs at no cost while a maintenance agreement is in place. | ||
| 1.4 | General | Software Release Management | The Vendor shall describe the frequency of defect-resolution software releases and the decision-making processes involved in selecting which software defects to fix. | ||
| 1.4 | General | Software Release Management | The Vendor shall notify and coordinate scheduling with the State whenever solution servicing requires onsite visits. Notification shall occur no less than ten business days before the needed visit and scheduling shall be at the sole discretion of the State. | ||
| 1.4 | General | Software Release Management | The Vendor shall include in its proposal the procedure to manage and track system changes. This is especially important when changes affect the performance of a particular device, and it needs to be returned to its former configuration. The configuration-management procedure shall be available to maintenance personnel and State staff. | ||
| 1.4 | General | Software Release Management | The Vendor shall provide release notes to the State no less than ten business days prior to system upgrades or updates, clearly identifying bug-fixes and any new functionality of which the State may wish to take advantage. | ||
| 1.4 | General | Software Release Management | The Vendor shall request authorization from the State no less than ten days prior to performing maintenance, upgrades, backups, restorations, or other system changes that may impact the performance or functionality of the system or service. The only exception to this advance-notice requirement is in cases where an update or upgrade is immediately required to restore a failed or failing service or component. | ||
| 1.5 | General | Warranty | For all software and Vendor-provided hardware, the Vendor shall include 24 x 7 x 365 parts and labor warranty for the duration of the contract from the date of final State acceptance. The Vendor shall provide 24 x 7 x 365 extended warranty (parts and labor) for any optional extensions. | ||
| 1.5 | General | Warranty | For all software and Vendor-provided hardware, warranties shall cover hardware, cabling and connectors, software, and include 24 x 7 x 365 support. | ||
| 1.5 | General | Warranty | The Vendor shall describe how out-of-warranty items are repaired or replaced. The Vendor shall briefly describe the processes and procedures. | ||
| 1.6 | General | Long-Term Availability | The Vendor shall provide 12 months’ (minimum) advance written notification to the State for any end-of-life (EOL) or end-of-support (EOS) component, with a plan for how the affected component(s) will be replaced without affecting service. | ||
| 1.6 | General | Long-Term Availability | The proposed solution shall be supported by the manufacturer(s) for a period of nine years from the date of full system acceptance by the State. | ||
| 1.7 | General | Incident and Trouble Reporting | The Vendor shall describe the procedures involved for initiating, tracking, communicating status, and resolving trouble reports. | ||
| 1.7 | General | Incident and Trouble Reporting | The Vendor shall describe capabilities to interface with other management systems using standard protocols such as Simple Network Management Protocol (SNMP) or Common Management Information Protocol (CMIP). | ||
| 1.8 | General | Escalation Procedures | Following cutover to any Vendor provided systems, the State may require escalation of an issue for resolution. The Vendor shall provide: |
a. Documentation of the escalation process along with names, titles, and contact information.
b. The after-hours escalation process, if it is different from normal work hours.
c. The process for updating escalation documentation as personnel changes occur during the contract period.
| 1.8 | General | Escalation Procedures | Vendor shall identify the specific issues, address how future occurrences will be avoided (risk mitigation), and provide a suggested path toward resolution. |
| 1.8 | General | Escalation Procedures | The escalation process shall address inclusion of the manufacturer (if other than Vendor) in meetings and discussions with affected PSAPs when the Vendor’s efforts have not resolved the issue. |
| 1.8 | General | Escalation Procedures | Escalation processes shall describe in detail the procedures for the State regarding resolution of critical defects, including time to resolution and engagement of Tier 3 or Tier 4 engineering and development resources. |
| 1.9 | General | Software Backup and Restoration | The Vendor shall perform automatic backups of software, as well as all PSAP-specific configurations and databases. The backups cannot affect system performance. |
| 1.9 | General | Software Backup and Restoration | The Vendor shall describe in detail, in the proposal, the recommended backup schedule of any customer-premise-installed devices that have databases, operating systems, and/or configurations that may be backed up. |
| 1.10 | General | Maintenance and Repair History Log | The Vendor shall provide, utilize, and maintain an online history log for all State sites that tracks all system issues, resolutions, configuration changes, upgrades, etc. that are performed onsite or remotely. |
The Vendor shall describe the process for managing the history log and provide read access to the State.
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall be accountable for the storage of materials until such time that the items are to be installed. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The State facilities may not be used as a warehouse for uninstalled equipment. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall coordinate with the State for the shipping and delivery of all equipment prior to installation. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall be responsible for ensuring that the equipment is fully staged, configured, and tested prior to delivery to the State. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall arrange for equipment to be delivered onsite as-needed, and the cost for delivery shall be included in the Vendor’s proposal. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall be responsible for all hardware, from its receipt until it is accepted by the State personnel in writing. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall be responsible for the disposal of shipping material, as well as the daily removal of other refuse. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | The Vendor shall provide the State with a detailed inventory of all equipment installed on PSAP premises, in hard and soft copy formats using Microsoft Excel. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | At a minimum, the inventory data shall include where it is installed, manufacturer, part number, serial number, quantity, and model number. |
| 1.11 | General | Storage, Staging, Delivery, and Inventory Control | Any hardware or equipment lost, misplaced, or damaged prior to acceptance will be replaced at the Vendor’s sole expense. |
| 1.12 | General | PSAP Facilities | As the selected Vendor performs the installation and cutover of the equipment/services, the Vendor shall ensure the PSAP will experience minimal interruption to normal business operations. |
| 1.12 | General | PSAP Facilities | Prior to any PSAP visit, the Vendor shall provide advance notice to, and obtain authorization from, the State and the PSAP, which each reserve the right to alter or suspend the intended schedule for any reason at its sole discretion. |
| 1.12 | General | PSAP Facilities | The Vendor shall be responsible for the repair or restoration of any damages caused by the Vendor, its subcontractors, or delivery personnel to any PSAP or agency facilities through the receipt, delivery, installation, or testing of the solution. |
| 1.13 | General | Spares and Advance Replacement | The Vendor shall describe their plan to maintain multiple critical spares kits for all customer-premise-installed equipment that can be delivered onsite to PSAPs within the response time frames outlined in Appendix L - CHaaS and Recorder Performance Standards and Service Level Agreements. |
| 1.13 | General | Spares and Advance Replacement | Any spares used out of the kits shall be replaced within 24 hours with tracking information about the shipment provided in advance. |
| 1.13 | General | Spares and Advance Replacement | The Vendor shall provide prices of all equipment installed at PSAPs, and honor those prices for the life of the contract. |
| 1.13 | General | Spares and Advance Replacement | The Vendor shall provide pricing and documentation describing the repair and advance-replacement processes for out-of-warranty solution components purchased by the State. |
| 1.14 | General | Master Project Plan | Within 60 days of contract signing, selected Vendor(s) shall provide a detailed Master Project Plan (MPP) that includes the details surrounding the deployment of the solution(s) they’re contracted to provide, including any recommendations for the State that minimize risk or improve efficiency. At a minimum, the plan must include: |
a. Schedule plan showing a task oriented gantt chart that illustrates the entire project schedule and milestone deliverables; calculated from contract signing, through installation, testing and cutover, to project completion.
b. Network plan showing when connectivity will be ordered and installed, configured, and tested.
c. Installation and Integration plan showing the expected timeframes for all hardware and software installations, system integrations, and the process that will be followed to ensure success.
d. Transition / Migration plan with description of the methods and procedures that will be employed to ensure a non-service-affecting transition for each PSAP from their current environment to the new one, and a fallback procedure to restore PSAPs to their pre-transition state in the event of problems. The plan shall include a recommended sequence of PSAP cutovers given their size, call volume, and other factors.
e. Training plan showing the classes that will be provided, their duration, the intended audience, and the schedule when they are expected to be provided, (ensuring training occurs within 2 weeks of PSAP cutover).
f. Project staffing plan showing the resources and roles expected to be required for successful solution implementation as well as all the expected times when resources will be onsite at PSAPs.
g. Risk mitigation plan showing how risks to the project will be mitigated.
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide 24 x 7 x 365 staffed network operations center (NOC)/security operations center (SOC) within North America that provides continuous monitoring of the system(s) deployed in the State. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide the ability for users to submit, track, and modify tickets by phone or email, regardless of the type (incidents, problems, changes, and maintenance). |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide outward notifications and updates of customer tickets through phone, email, and text. |
| 1.15 | General | Network Operations Center / Security Operations Center | Support interactions with the State via collaborative tools, such as Zoom, Google Meet, Microsoft Teams, Webex. |
| 1.15 | General | Network Operations Center / Security Operations Center | Have an executive dashboard showing (near) real-time updates of support tickets and overall system (and network) health status |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide fully documented escalation procedures with contact information for all levels of escalation. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide root cause analysis (RCA) reports and regulatory compliance according to Federal Communications Commission (FCC) standards anytime an outage or service interruption causes a severity 1 or 2 impact to 911. |
| 1.15 | General | Network Operations Center / Security Operations Center | Preliminary RCA reports are due to the State within five business days of initial report of issue; final root-cause analysis within 30-calendar days of root cause determination including steps taken to prevent issue from recurring. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide media and/or governance contacts for any outage or service interruption / failure. The contact information shall be updated annually/quarterly. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide a service management contact that is the primary contact for the Service after go-live until contract expiration. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide access to technical and executive staff for escalations. |
| 1.15 | General | Network Operations Center / Security Operations Center | Comply with Statement on Standards for Attestation Engagements Number 16 (SSAE 16) |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide NOC/SOC staff trained or experienced with NG911 and call-handling systems with regular refresher/update training. |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide the ability to access and troubleshoot, diagnose, and repair network and systems remotely from locations within North America, (no “offshore” remote access into systems installed within the State). |
| 1.15 | General | Network Operations Center / Security Operations Center | The Vendor shall provide the ability and commitment to support and drive the troubleshooting of all service affecting issues (network, CAD, recordings, etc.), even when it is determined that the root cause of the issue is outside the scope of the Vendor’s solution or service, (e.g., provide call traces and log analysis to assist in troubleshooting a NGCS or CHE issue). |
Technical CHaaS-REC
| State of Delaware | Vendor Response Required | Vendor Response Required | |||
| REQ # | Function | Process | Requirements | Compliance | Comments |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The State requires Vendors propose a hardware-based hosted call-handling solution that supports each of the State’s eight (8) PSAPs. The CHE hosts must be located within geodiverse datacenters, however they do not have to be located within the State. The State asks Vendors to propose the most economical and reliable solution available. |
Vendors offering a cloud-based call handling solution for the initial deployment will not be considered for this procurement. The State may be interested in upgrading the Vendor's hardware solution to a cloud-based solution in the future and ask Vendors that offer this option to briefly describe how the transition would occur, if there's impacts to the PSAPs, and if there's additional costs associated with the transition.
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | Vendors must provide a long-term Recording solution as part of their proposal. The Recording solution must record all audio from the State’s 911, non-emergency, and radio traffic, as well as text, multimedia, AML, transcription, and other types of data. The Recording solution must be capable of integrating with other State systems (non-911) if desired. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The Solution shall integrate with the State’s existing CAD systems provided by Tyler Technologies and Central Square. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The Solution must integrate each PSAP’s 10-digit administrative lines. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The Solution must integrate the State’s text-to-911 traffic currently deployed using Intrado’s TCC. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The Solution must be NG911 capable, deployed as i3 (PIDF-Lo), and integrate with Intrado’s two-core ESInet and NGCS solution based in Longmont and Miami. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | The Solution must include a mapping service that allows for the use of the State’s map data and can display both the NG911 network-provided caller location as well as the RapidSOS-provided location on the same map. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | Relocation of the State’s ESInet circuits from their current demarcation points to the Vendors chosen datacenters will be required – Vendors shall briefly explain how the ESInet transition would occur. |
| 2.1 | CHaaS and Recorder | CHaaS Solution Architecture | Vendor shall be responsible for working directly with Intrado, or their subcontractor if necessary, to troubleshoot any issues related to SIP signaling, call presentation, and/or Recording. |
| 2.2 | CHaaS and Recorder | CHaaS Network | Vendor shall be responsible for deploying, managing, and monitoring the CHE network and resolve any issues therein. |
For clarity, the CHE network is the network between the CHE host site datacenters, as well as between those datacenters and PSAPs.
| 2.2 | CHaaS and Recorder | CHaaS Network | Vendor shall work directly with Intrado as the State’s current NG911 provider to design, order, install, and test any new ESInet, call-handling, Recorder, TCC, or administrative line network connectivity. Vendor shall collaborate with Intrado over routing specifications to accommodate the expected behaviors, (e.g. accessibility, resilience, load sharing, failover, etc.). |
| 2.2 | CHaaS and Recorder | CHaaS Network | Vendor shall provide redundant network connectivity from diverse carriers into diverse entrance facilities at all datacenters and PSAPs. There shall be no overlapping equipment, facilities, or carriers, from end-to-end, including last mile. Vendors shall state the facilities where they are unable to deploy true diversity as described above. |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall provide CHE network connectivity that supports the State’s current call and data delivery functionality between agencies. |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall align with NENA STA‑010.3f-2021, Detailed Functional and Interface Specifications for the NENA i3 Solution, (or its successor document, when ratified). |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall use open standards. |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall support and enforce quality of service (QoS) marking using Differentiated Service Code Point (DSCP). |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall provide voice network traffic convergence resulting in maximum 2 seconds of audio loss when a network circuit fails during a live call. |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall maintain a Mean Opinion Score (MOS) of 4.0. |
| 2.2 | CHaaS and Recorder | CHaaS Network | The solution shall scale to support call-volume growth by 50% without requiring replacement of any critical hardware or software component. |
| 2.2 | CHaaS and Recorder | CHaaS Network | Failure of any single instance of a hardware or software element, or physical connection shall not impact overall solution performance. |
| 2.2 | CHaaS and Recorder | CHaaS Network | All network-connected elements shall support at least two redundant network interfaces with automatic failover between them. |
| 2.2 | CHaaS and Recorder | CHaaS Network | All powered devices supporting network connectivity for the State, (firewalls, routers, switches, etc.) shall include a minimum of two redundant power supplies (each shall be able to power the device alone) that would be connected to separate circuits OR be connected to a power-transfer device that allows a single power supply to be connected to two isolated power sources (i.e., circuits) with automatic, uninterrupted failover, in the event the primary circuit fails. |
| 2.3 | CHaaS and Recorder | Security | The solution shall comply with NENA 75-001.1, Security for Next-Generation 9-1-1 Standard (NG-SEC). The Vendor shall detail how its solution addresses the requirements of the following sections of the standard: |
a. Section 6 – General Security
b. Section 7 - Safeguarding Information Access
c. Section 9 - Network and Remote Access Security Guidelines
| 2.3 | CHaaS and Recorder | Security | Vendor shall be System and Organization Controls 2 (SOC 2) compliant |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall include a security plan document that addresses, physical, application, and network security. |
| 2.3 | CHaaS and Recorder | Security | The solution shall utilize encryption in all communications across the CHE network. |
| 2.3 | CHaaS and Recorder | Security | The solution must include firewalls between call-handling nodes and their external connections. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall ensure that all call-handling components interfacing with the State’s NG911 provider carry credentials traceable to the national PSAP Credentialing Agency (PCA). |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall perform proactive analysis of the CHE network for vulnerabilities including independent security audits of the solution. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall have a defined continuity of operations (COOP) plan as well as a disaster recovery (DR) plan and make those plans available for review at the State’s request. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall provide access reports from facilities (physical access) down to the individual device level (physical or virtual access), upon request, when a service-impacting issue has occurred. |
| 2.3 | CHaaS and Recorder | Security | The solutions shall require multifactor authentication for any access into the systems supporting this CHE and network solution, as well as for access to any externally accessible portals, user interfaces (UIs), system dashboards, etc.. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall describe their security software update policy and procedures, for both normal maintenance as well as emergency software patches, antivirus updates, etc., and include the frequency and turnaround time for different types of updates. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall describe their plan/approach for adopting evolving security best practices. |
| 2.3 | CHaaS and Recorder | Security | The Vendor shall complete the NG-SEC Audit Checklist, and submit for approval, as described in NENA 75-502, Next Generation 9‑1-1 Security (NG‑SEC) Audit Checklist 75-502. |
(For this procurement, the Vendor must comply with all requirements designated as Required “R” in column labeled “Compliance Finding”).
| 2.4 | CHaaS and Recorder | CHaaS Network Documentation | The Vendor shall provide its proposed network design to include carriers and last mile providers. |
| 2.4 | CHaaS and Recorder | CHaaS Network Documentation | The Vendor shall provide the deployed mid-level design documentation depicting network paths and equipment diversity, prior to acceptance testing of the solution. |
| 2.4 | CHaaS and Recorder | CHaaS Network Documentation | The Vendor shall interoperate with the State’s ESInet and NGCS provider’s i3 network interface specifications. |
| 2.4 | CHaaS and Recorder | CHaaS Network Documentation | The Vendor shall provide detailed as-built solution documentation to include network, equipment, ports, protocols, network paths, network providers, routing information (e.g. BGP), firewalls, software versions, as well as configured parameters (implemented design). |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The State is procuring Call Handling as a service (CHaas), therefore, Vendors shall be responsible for monitoring, alarming, notifying, and ultimately resolving, all parts of their solution; including, CHE, Recorder, connectivity, audio quality, general functionality, location related services, system health (CPU, memory, storage, etc.), integrations, and PSAP workstations. |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The Vendor shall provide physical access monitoring and reporting for all facilities where the CHE hosts operate. |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The Vendor shall provide event logging and reporting in real, or near-real, time. |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The Vendor shall provide CHaaS network monitoring and alerting and shall act on the alerts according to the level of impact to the CHaaS service and in accordance with service level agreements (SLAs). |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The Vendor shall provide CHaaS hardware and software monitoring and alerting and to act on the alerts according to the level of impact to the CHaaS service and in accordance with service level agreements (SLAs). |
| 2.5 | CHaaS and Recorder | CHaaS Monitoring and Alarming | The Vendor shall provide user-definable notification levels and recipients with text and email delivery options. |
| 2.6 | CHaaS and Recorder | i3 Conformance | The solution shall conform to the latest published/ratified version of NENA STA-010.3f-2021, NENA i3 Standard for Next Generation 9-1-1. |
| 2.6 | CHaaS and Recorder | i3 Conformance | The solution shall interface with any NENA i3-conformant NGCS and ESInet. For the initial deployment, Vendor’s solution shall assume an i3 interface deployment with the Intrado ESInet/NGCS. |
| 2.6 | CHaaS and Recorder | i3 Conformance | The Vendor shall provide the number of its operational call-handling installations that utilize Presence Information Data Format Location Object (PIDF-LO), and the NGCS provider with whom it’s been deployed. PIDF-Lo includes HTTP-enabled location delivery (HELD), Location-to-Service Translation (LoST), Additional Data Repository (ADR) queries, and other i3 protocols. |
| 2.7 | CHaaS and Recorder | Technical Support | The Vendor shall provide a minimum of four onsite certified technical support resources that reside within the State to be the primary points of contact for any issues related to CHaaS, the workstations, the network, the Recorder, and any other hardware and software that’s been deployed within State facilities. The onsite technical support resources shall operate in accordance with agreed response and repair time SLAs. |
| 2.7 | CHaaS and Recorder | Technical Support | The State shall have the ability to review resume and/or CV of potential onsite resources to gauge experience and identify those best fit for the role. |
| 2.8 | CHaaS and Recorder | Solution Validation | At the discretion of the State, the Vendor shall allow for independent third-party validation of all mandatory solution requirements and feature functionality prior to cutover of the site(s). |
| 2.8 | CHaaS and Recorder | Solution Validation | The CHaaS solution shall provide transparency and access to all SIP messaging, call detail records (CDRs), key performance indicators (KPIs), (e.g., MOS scores, network latency, jitter, packet loss, etc.), call logs, and any other data determined to be necessary to verify compliance with contractual obligations or to troubleshoot issues. |
| 2.8 | CHaaS and Recorder | Solution Validation | The Vendor shall provide documentation of completed results from testing of any hardware or software changes prior to implementation in the live environment. |
| 2.8 | CHaaS and Recorder | Solution Validation | Vendor shall provide a full test suite that demonstrates traceability to all requirements where compliance was selected within this document for review and approval by the State no less than 8 weeks prior to the live cutover of any hardware or software in the live 911 environment. The State will review and determine acceptance or modification of test suite. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | The solution shall automatically (i.e., without manual intervention) transfer or failover core processing functionality from one call handling node to another upon detection of a problem that could impact the system’s ability to meet the 99.999% service level requirement. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | During incidents where core processing has failed over to a different node, or where a single node is processing all calls, call-handling capacity and performance shall not be degraded. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | The Vendor shall provide a description of how the solution achieves 99.999% availability. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | Core-processing functionality may be distributed across two or more call-handling datacenters provided by the Vendor. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | The solution shall support remote call-taking capability via virtual private network (VPN) connections over the public internet via Vendor-provided (and supported/maintained) laptops. Vendor shall explain their available solutions. |
| 2.9 | CHaaS and Recorder | Redundancy, Reliability, Availability | The solution shall support hot-seating capabilities (i.e., the ability for a telecommunicator from one PSAP or agency to login at a workstation at any other PSAP or agency using their home credentials, and receive/process calls from their home PSAP. Vendor shall explain any limitations with this functionality. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | The solution shall support the computer-aided dispatch (CAD) system interface as described in NENA-STA-027.3-2018, NENA E9-1-1 PSAP Equipment Standards. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | The solution shall support both serial and IP-based connections. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | The solution shall support a bi–directional interface with the CAD system. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | Vendors’ solution shall detail the process to import and export phone book data from the CHE into CAD and vice versa. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | The solution shall support CHE to CAD cut/paste feature and describe how this functionality will be enabled. |
| 2.10 | CHaaS and Recorder | CAD Interoperability | The solution shall support integration with the State’s CAD systems for the life of the contract. Today, these systems are provided by Tyler Technologies and Central Square, however they could be replaced at anytime. Vendor shall list the CAD manufacturers they’ve integrated with in the past, and state specifically if any of them are cloud-based. Vendor shall describe any concerns or anticipated problems integrating with cloud-based CAD systems. |
| 2.11 | CHaaS and Recorder | Long-term Recorder | The solution must include the installation, provisioning, configuration, testing, deployment, and maintenance of a network and position-based long-term audio Recorder with minimum 3 years storage/retention time. |
| 2.11 | CHaaS and Recorder | Long-term Recorder | The Recorder solution shall support recording at all State PSAP workstations for both 911 and non-emergency calls, P25 radio recordings at the towers, phone/sip recording, analog and talk group recording, and the State DOT 700 mhz traffic, plus other potential integrations. Vendor shall explain what non-voice related data can be recorded with the solution, e.g. multimedia. |
| 2.11 | CHaaS and Recorder | Long-term Recorder | The solution shall support playback of recordings independently or together. |
| 2.11 | CHaaS and Recorder | Long-term Recorder | The solution shall support the following with single-click playback controls that enable the user to navigate to any portion of the recorded conversation(s): |
a. Play.
b. Pause.
c. Stop.
d. Play forward/fast forward (without altering voice pitch).
e. Rewind.
f. Repeat.
g. Skip forward or back a configurable number of seconds Vendors shall state what controls aren't available, if any.
| 2.12 | CHaaS and Recorder | PSAP Hardware | The vendor shall provide all hardware required within the PSAPs, including but not limited to; new workstations (PCs, monitors, keyboards, mice, keypads, headsets, etc.), Recorder equipment, network equipment (routers, switches, firewalls, etc.), etc.. Vendors shall explain what hardware will be installed at the PSAPs, and ensure they are new and covered by (extended) manufacturer warranty for no less than five years from the date the device is placed into operation. |
| 2.12 | CHaaS and Recorder | PSAP Hardware | Whenever supported by the device manufacturer, all servers, switches, routers, firewalls, PCs, and other devices within the solution shall be configured with redundant power supplies and redundant network interfaces. |
| 2.12 | CHaaS and Recorder | PSAP Hardware | The Vendor shall work with the State to provide (and maintain) mobile laptop call-taking positions and spares at each PSAP to be used for remote call processing. The laptops shall include 2 screens – one for call handling display and one for the map. Integrated solutions are preferred, however add-on screens (e.g. USB) are acceptable as long as they can be fastened or connected to the laptop in some way. All laptops and peripherals shall be housed in a secure, hardened, carrying case. Vendors shall explain their available solutions. |
Vendors are asked to quote the laptops separately as optional items so each PSAP can choose how many they want.
| 2.13 | CHaaS and Recorder | Systems Integration | The Vendor shall integrate local administrative lines (analog, SIP, and ring-downs) into the CHE solution. |
| 2.13 | CHaaS and Recorder | Systems Integration | The Vendor shall describe any experience or integration capabilities it has with RapidSOS, Smart911, and Rave. It is preferred that these applications integrate into the CHE and not require their own, separate, display monitor(s). Vendor shall explain any experience integrating with ECaTS. |
| 2.13 | CHaaS and Recorder | Systems Integration | The Vendor shall describe its experience and capability of integrating PSAP radio headsets at CHaaS workstations. |
| 2.13 | CHaaS and Recorder | Systems Integration | DE State Police have dedicated positions located within each primary PSAP that calltakers can transfer calls to when needed. The Vendor shall explain if this capability is supported and how it would be done. |
| 2.13 | CHaaS and Recorder | Systems Integration | The Vendor shall explain if its CHaaS solution has the ability for a calltaker to alert certain position(s) within their agency, to warn of an important call being transferred to them, either via on-screen display notification, and/or light poles and wallboard. |
| 2.13 | CHaaS and Recorder | Systems Integration | The Vendor shall deploy EIDO functionality, if desired by the State at anytime during the contract term. |
| 2.14 | CHaaS and Recorder | Multi-Tenant Capability | Vendor shall deploy multiple tenants as necessary for the State’s call handling solution to support their eight (8) primary and secondary PSAPs, and potentially additional PSAPs if necessary in the future. |
| 2.14 | CHaaS and Recorder | Multi-Tenant Capability | Today, there are two PSAPs that have a unique arrangement with State Police (SP). These PSAPs use ACD, they answer all calls, and they transfer to SP as necessary using internal CHE functionality (ring groups). (The NGCS does not process these transfers). |
| 2.14 | CHaaS and Recorder | Multi-Tenant Capability | Vendor shall state if their proposed solution can provide this functionality, and if so, how? Alternatively, please state if the Vendor requires SP be treated as a secondary PSAP instead. |
| 2.14 | CHaaS and Recorder | Multi-Tenant Capability | It shall be possible for each tenant/PSAP to choose whether they deploy a ring-all or ACD solution. |
| 2.14 | CHaaS and Recorder | Multi-Tenant Capability | The State shall be able to create their own unique set of configurations for each tenant (e.g., agent identifications [IDs], roles, permissions, groups, screen layouts, speed-dial catalogs, management information system [MIS] reports, system status, greetings, etc.). |
Vendor shall explain what types of settings/configurations are system-wide versus PSAP-specific.
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall explain how text calls are received, answered, transferred, and tracked in the system. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall provide examples of the applicable UIs (e.g., screenshots). |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall provide the ability to text from 9‑1-1. Vendor shall describe any additional features that may be available for text conversations initiated by the PSAP, for example streaming video. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall explain disposition of attached multimedia and how text calls are handled by the MIS. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The solution shall be able to accept SMS text delivery from Intrado’s TCC via the existing ESInet connections (i.e., not require a separate internet connection). |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall provide SMS foreign language translation capability. Vendor shall describe how the feature works, if internet connectivity is required, and whether this feature is available today or is a roadmap item for the future. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The Vendor shall describe its text messages history feature. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | Vendors shall provide details regarding transfers between different TCC providers, including location and text conversation history, and any limitations therein. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | Vendor shall provide a means to have text-to-911 calls use ring-all or ACD functionality for each PSAP. |
| 2.15 | CHaaS and Recorder | Integrated Text-to-911 | The solution shall allow agents to print text conversations to their local network printer. |
| 2.16 | CHaaS and Recorder | Real-Time Text | The Vendor shall describe plans for supporting real-time text-to-9-1-1 sessions as a part of its solution or explain any plans to offer this feature in the future. |
| 2.16 | CHaaS and Recorder | Real-Time Text | If not currently developed, the Vendor shall provide details of when this capability will be included in the proposed solution as a no-charge upgrade/deliverable. |
| 2.17 | CHaaS and Recorder | Translation and Transcription | The solution shall provide the ability to translate and transcribe the 9-1-1 voice call to a text record or documented dialogue. Vendor shall state whether this requires an internet connection to a third party provider. Vendor shall clearly state if this feature is available today, or if it is a roadmap item to be delivered in the future, and if costs associated with this feature are included or additional. |
| 2.17 | CHaaS and Recorder | Translation and Transcription | The solution shall provide foreign language translation capabilities. Particularly for the languages of Spanish, Haitian Creole, Mandarin, French, and Korean. Vendor shall describe how the feature works, including whether an internet connection is required, and whether this feature is available today or is a roadmap item for the future. |
| 2.18 | CHaaS and Recorder | Status Lights | The solution shall be capable of displaying call taker status visually, for example, busy 911 / busy admin-line / available / needs assistance, etc.. This can be provided via color schemes on call taker screens or via light poles. Vendor shall describe their solution. |
| 2.18 | CHaaS and Recorder | Status Lights | The solution shall allow for a call taker to manually switch their status light to a special designated color for certain conditions, and this shall also update the wall board statistics accordingly. |
| 2.19 | CHaaS and Recorder | User Roles | The Vendor shall provide user role settings, which are retained between logins, during upgrades, and between sessions (i.e., logoff and return next day). |
| 2.19 | CHaaS and Recorder | User Roles | The solution shall be capable of establishing skills-based roles which would allow the State to have calls distributed to the appropriate user based on the type of call – wireline, wireless, text, administrative, etc.. Vendor shall describe this feature and identify any constraints or restrictions. |
| 2.19 | CHaaS and Recorder | User Roles | Access to call-handling assets (e.g., trunks, lines, queues, speed dials, configurations, screen layouts, greetings, etc.) may be controlled by a user’s role. |
| 2.20 | CHaaS and Recorder | Human-Machine Interface (HMI) | The solution shall comply with NENA 54-750, NENA/APCO Human Machine Interface & PSAP Display Requirements, and provide an explanation of any areas of non-compliance with the standard. |
| 2.20 | CHaaS and Recorder | Human-Machine Interface (HMI) | If a call is alternate-routed or otherwise diverted to a destination other than the normally intended destination, the call-handling solution shall recognize and present the originally intended destination and the reason why the call was diverted (reference sections 3.3.CC of NENA 54-750). |
Describe what call-takers see on the CHE screen. Also indicate if it is possible to display something for calls transferred from out of state.
2.21 CHaaS and Recorder Distinctive Ring Tones The solution shall provide the ability to configure distinctive ring tones for 9-1-1 calls, 9-1-1 calls in a pending queue, administrative calls, text messages, etc.
Vendor shall explain how many different ring tones are available for use.
| 2.21 | CHaaS and Recorder | Distinctive Ring Tones | The solution shall provide the ability to configure any of the call types (911, 911 pending, admin, text, etc.) with distinctive ring tones both audibly and via in-ear headsets. |
| 2.21 | CHaaS and Recorder | Distinctive Ring Tones | The solution shall support user-selected, distinctive ring tones for each automatic call distribution (ACD) queue or call type. |
| 2.21 | CHaaS and Recorder | Distinctive Ring Tones | The solution shall provide distinctive ring tones to be customized by agent role or login. |
| 2.22 | CHaaS and Recorder | Conference Controller | The conference controller shall enable the telecommunicator to add an outside caller or inside caller to an in-progress “live” call while remaining on the line, with no limitation as to what type of call the telecommunicator is handling. |
| 2.22 | CHaaS and Recorder | Conference Controller | The conference controller shall automatically control the audio levels (AGC) of the calling parties so that no degradation of voice quality occurs. |
| 2.22 | CHaaS and Recorder | Conference Controller | The original telecommunicator shall be able to mute/unmute (i.e., disable/enable the microphone of) any party on the conference. |
| 2.22 | CHaaS and Recorder | Conference Controller | The original telecommunicator shall be able to deafen/undeafen (i.e., disable/enable the earpiece/speaker of) any party on the conference without muting that party’s audio (i.e., allow the telecommunicator to speak to others on the conference, without that party hearing, while still able to hear that party). |
| 2.22 | CHaaS and Recorder | Conference Controller | The original telecommunicator shall be able to select and drop any party from the conference. |
| 2.22 | CHaaS and Recorder | Conference Controller | The original telecommunicator, or any of the conference parties, shall be able to drop out of the conference without disconnecting the original caller. |
| 2.22 | CHaaS and Recorder | Conference Controller | The conferencing feature shall support, at a minimum, any combination of minimum six parties. |
| 2.23 | CHaaS and Recorder | Call Monitoring | The solution shall allow authorized PSAP personnel to listen to another telecommunicator’s live conversation. |
| 2.23 | CHaaS and Recorder | Call Monitoring | The monitoring feature shall be controlled by the authorized personnel’s credentials. |
| 2.23 | CHaaS and Recorder | Call Monitoring | Monitoring shall include the option as to whether the telecommunicator being monitored is made aware (visually or audibly) when their call is being monitored. |
| 2.23 | CHaaS and Recorder | Call Monitoring | Monitoring shall not degrade the audio quality of the call. |
| 2.23 | CHaaS and Recorder | Call Monitoring | The Vendor shall describe its options, or plans, for supporting a call-monitoring-like functionality for text-to-9-1-1 sessions. |
| 2.23 | CHaaS and Recorder | Call Monitoring | The Vendor shall describe its ability to allow authorized personnel to post temporary notifications on call-taker screens, (i.e. “bill-boarding”), without blocking screen real-estate that could contain critical information. |
| 2.23 | CHaaS and Recorder | Call Monitoring | The Vendor shall describe if its able to allow authorized personnel to speak to the call-taker while monitoring a live 911 call and not have the caller hear them, (i.e. “whisper”). |
| 2.24 | CHaaS and Recorder | Call Barge-In | The solution shall allow authorized PSAP personnel to barge into existing calls, hear the live conversation, and speak to participants on the call as another participant. |
| 2.24 | CHaaS and Recorder | Call Barge-In | The feature shall be activated by authorized PSAP personnel in a simple way, like utilizing a mouse or other simple keyboard command. |
| 2.24 | CHaaS and Recorder | Call Barge-In | This feature shall not degrade the audio quality of the call. |
| 2.24 | CHaaS and Recorder | Call Barge-In | This feature shall be configurable to provide a tone to announce the barge-in. |
| 2.24 | CHaaS and Recorder | Call Barge-In | The Vendor shall describe options or plans for supporting a barge-in-like capability for text-to-9-1-1 sessions. |
| 2.25 | CHaaS and Recorder | Callback | Call back of any 9-1-1 or administrative call (wireline, wireless, telecommunications device for the deaf/teletypewriter [TDD/TTY], text, and Voice over IP [VoIP] callers, Real-time Text [RTT]) shall be based on the calling party number (or callback number), not the pseudo ANI (pANI) if one is present. |
| 2.25 | CHaaS and Recorder | Callback | Any required dialing prefix digit(s) insertion/deletion (e.g., adding +9 or removing the area code) shall be automatic and not require manual input. |
| 2.25 | CHaaS and Recorder | Callback | The callback function shall require only a single mouse click. |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The solution shall provide a visual and audible indication for abandoned calls and it shall be presented to the entire queue. |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The solution shall display the number of abandoned calls from the same callback number and allow a single successful callback to clear all entries displayed. |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The solution shall clear the abandoned call count display upon successful callback and answer of the telephone number. |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The solution shall provide each individual agency with the ability to configure an automatic-callback option (voice or text) to be enabled or disabled by the agency. |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The automatic callback option shall prompt the recipient of the call to take an action (e.g., press 1 to notify the agency that no assistance is needed; press 2 to be routed to 9‑1-1, etc.). |
| 2.26 | CHaaS and Recorder | Abandoned Calls | The solution shall provide abandoned call reports as part of its MIS. |
| 2.27 | CHaaS and Recorder | Repeat Callers | The solution shall provide a caller history feature that displays the date and time of the last 50 to 100 previous calls from the same number and include notes provided by the telecommunicator(s) who handled the previous calls. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .