5-Appendix C - Technical Requirements.xlsx
XLSX spreadsheet 700 KB Posted
- Solicitation number
- RFP 2000004244
- Issued by
- Fairfax County, Virginia
About this file
Summary
This document is Appendix C (Technical Requirements) for RFP 2000004244 issued by Fairfax County, Virginia, on behalf of regional 911 Authorities across Virginia, Maryland, and the District of Columbia to procure Next Generation 9-1-1 Core Services (NGCS) and Emergency Services IP Network (ESInet) solutions. The RFP requires offerors to complete a comprehensive Functionality Matrix addressing technical requirements across eight major categories: ESInet and NGCS Architecture, Security, Facilities, Deployment/Monitoring/Alarming, NGCS Functional Elements, Originating Service Provider Migrations, ALI Transition, and Text to 911 capabilities. Offerors must respond with one of four compliance statuses ("Complies," "Complies Partially," "Complies with Future Capability," or "Does Not Comply") and provide detailed written explanations for any response other than full compliance. The matrix serves as the primary evaluation tool, with explanations in the Response Explanation column weighted more heavily than supporting documentation. All incomplete items are deemed non-compliant, and responses marked "Complies" with additional explanations are automatically downgraded to "Complies Partially."
The technical requirements mandate that solutions meet rigorous standards including 99.999% monthly reliability, redundant dual data centers with active-active configuration, Tier 3 or higher facilities rated for FEMA 361 standards, 24/7/365 US-based Network Operations Center monitoring, and compliance with NENA i3 standards and multiple security frameworks (NIST SP 800-53, ISO 27001, NENA-STA-040.2-2024). The solution must support diverse network architectures including IPv4/IPv6, BGP, multicast routing, Quality of Service, and network convergence under 54 milliseconds with Mean Opinion Score of 4.0 or better. Critical functional elements include Emergency Services Routing Proxy, Policy Routing Function, Emergency Call Routing Function, Location Validation Function, Spatial Interface, and support for text-to-911 capabilities. Offerors must demonstrate capability to manage FCC Phase 1 and Phase 2 NG911 Request submissions, coordinate with Originating Service Providers, provide comprehensive documentation including as-built designs and acceptance test plans, and support independent third-party validation of functionality and cybersecurity compliance.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 8-Appendix F- SLA Summary Matrices.pdf | ||
| 7-Appendix E - Narrative Responses.docx | DOCX document | |
| 3-Attachment B.pdf | ||
| 2-Attachment A1-A7.pdf | ||
| 4-Appendix B.pdf | ||
| 1-DPMM Coversheet.pdf | ||
| 9-Appendix G- Interoperability Testing Schedule.pdf | ||
| 6-Appendix D - Cost Proposal.xlsx | XLSX spreadsheet | |
| 10-RFP 2000004244.pdf |
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 RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities
| Appendix C - Technical Requirements |
| Instructions |
| Purpose of Solution Functionality Matrix: |
| This matrix shall be completed by the Offeror. It will be used as a record of how the Offeror will meet expectations. |
| *The Offeror shall provide an explanation for any response that is not "Complies". The Offeror shall only complete the "Response Explanation" column with a written narrative and cannot simply refer to a secondary document. All incomplete items within this attachment will be deemed "Does Not Comply". |
| Additional documentation (including, but not limited to, graphs, charts, diagrams, images, samples, policies, etc.) should be provided to support Offeror's explanation and included in the Offeror's technical response. Offerors should identify in their technical response which tab and item their additional documentation is in support of. (Example: Tab A - ESInet Architecture, Item A.2) |
| Primary evaluation method will be the response in the "Response Explanation" column in the spreadsheet, not a reference document. |
| By checking "Complies" the Offeror agrees to provide the requirements described in the Item number and the solution is 100% compliant as written. |
| **For all "Complies" responses, the Offeror SHALL NOT add a "Response Explanation". Any "Complies" response with an explanation will be interpreted as a "Complies Partially" response, which will lower the evaluation score. |
| By checking "Complies Partially" the Offeror must identify the exceptions in the "Response Explanation". |
| By checking "Complies with Future Capability" the Offeror must identify when compliance will be achieved in "Response Explanation". |
| By checking "Does Not Comply" the Offeror must identify why compliance is not possible in "Response Explanation". |
The term 911 Authority is used to represent an entity that is using this RFP and subsequent contract for services.
The Tab Labeled "Narrative Response" shall be completed by the Offeror:
Offeror shall submit the narrative response in the form provided in RFP Appendix E - Narrative Responses..
The Offeror is responsible to ensure their response is contained within that three (3) page document per Narrative Response.
Any diagrams or figures shall NOT count toward the three (3) page limit per Narrative Response.
The diagrams shall be a visual representation of the narrative response and will be limited to no more than 100 words per diagram, which will include diagram labels.
&A &P of &D
A. ESINET NGCS Architecture
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
ESInet and NGCS Architecture
Offeror:
Criteria Item # ESInet Architecture Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 1 | A.1 | The Offeror's NGCS solution shall be designed without any single points of failure. Additionally, the solution shall have diverse entrance facilities for core sites and will provide diverse entrance facilities for any connectivity to the PSAP over the ESInet. The solution shall include the ability for multiple IP providers to integrate into the solution. |
| 1 | A.2 | The NGCS solution shall support IPv4 and IPv6 protocol stacks. |
| 1 | A.3 | The solution shall support BGP, utilizing Bidirectional Forwarding Detection and TLS. |
| 1 | A.4 | The solution shall support multicast routing and switching. |
| 1 | A.5 | The solution shall support quality of service (QoS) marking using Differentiated Service Code Point (DSCP). |
| 3 | A.6 | The solution shall support a network traffic convergence of less than 54 milliseconds (ms). |
| 3 | A.7 | The solution shall maintain a Mean Opinion Score (MOS) of 4.0 or better at the handoff to the call handling equipment. |
| 3 | A.8 | The proposed solution shall be scalable to support bandwidth growth by fifty-percent (50%). |
| 1 | A.9 | The solution shall have Interfaces implemented with other i3-compliant ESInets to facilitate ESInet-to-ESInet transfers retaining standard data in SIP header and PIDF-LO needed to properly route the call. |
| 1 | A.10 | Phase 1 NG911 Request Submission Approach |
Offerors must be able to submit, on behalf of a 911 Authority, a valid Phase 1 Request as defined in 47 CFR § 9.29(a) and (b), to enable the delivery of 911 traffic in an IP-based Session Initiation Protocol (SIP) format as requested by the 911 Authority.
The submission format must address the following elements:
1) Understanding of Regulatory Requirements:
Demonstrate a clear understanding of the Phase 1 Request process as outlined in 47 CFR § 9.29(a)-(b). Submission format must meet all of the criteria that constitutes a valid request from a 911 Authority, and the regulatory obligations of covered 911 service providers.
1 A.11 Phase 1 NG911 Request Submission Approach
2) 911 Authority Representation:
The Offeror's methodology for representing a 911 Authority in the submission of a Phase 1 Request shall Include how the Offeror verifies the authority's eligibility and intent to initiate IP-based 911 traffic delivery.
1 A.12 Phase 1 NG911 Request Submission Approach
3) Coordination and Documentation:
Offeror shall coordinate with the 911 Authority to gather and submit all required information to ensure the request is complete, accurate, and compliant with FCC requirements. Offerors shall also have a process for documenting and retaining evidence of the submission.
1 A.13 Phase 1 NG911 Request Submission Approach
4) Stakeholder Notification:
Offerors shall have a process to notify and coordinate with impacted stakeholders (e.g., originating service providers, state regulatory bodies) during and after submission of the request.
1 A.14 Phase 1 NG911 Request Submission Approach
5) Follow-up and Support:
Offerors shall have a process for follow-up communications, addressing questions or challenges from service providers, and ensuring timely implementation of SIP-based 911 call delivery and how the Offeror will support the required testing.
1 A.15 Phase 2 NG911 Request Submission Approach Offerors must be able to submit, on behalf of a 911 Authority, a valid Phase 2 Request in accordance with 47 CFR § 9.29(a)-(b). This request compels the 911 Authority’s relevant Originating Service Providers (OSPs) to deliver all 911 traffic—destined for the 911 Authority’s Public Safety Answering Points (PSAPs)—to the NG911 Delivery Points designated by the 911 Authority.
The Offeror’s approach must address the following:
1) SIP-Based Delivery Compliance:
The Offeror's solution shall ensure 911 traffic is delivered in an IP-based Session Initiation Protocol (SIP) format, consistent with NG911 standards as identified or specified by the 911 Authority.
Reference: 47 CFR § 9.29(a)-(b) 1 A.16 Phase 2 NG911 Request Submission Approach
2) Location Information Requirements:
The Offeror's solution shall incorporate caller location data in the signaling path, using Presence Information Data Format - Location Object (PIDF-LO).
1 A.17 Phase 2 NG911 Request Submission Approach
3) Regulatory Understanding and Execution:
The Offeror shall have a clear understanding of the legal and procedural requirements for submitting a Phase 2 Request, including coordination with the 911 Authority to validate the request, collection of necessary data, and ensuring compliance with FCC regulations.
1 A.18 Phase 2 NG911 Request Submission Approach
4) Stakeholder Coordination:
The Offeror shall coordinate with relevant OSPs, regulatory agencies, and other stakeholders to facilitate implementation of Phase 2 delivery requirements, testing, and support ongoing compliance.
1 A.19 Phase 2 Request for Updated NG911 Delivery Points In cases where a 911 Authority is already receiving IP-based SIP-formatted 911 calls over an Emergency Services IP Network (ESInet) and has either:
1) Changed NGCS providers due to a contract renewal, or
2) Opted, following the FCC rule codified in 47 CFR § 9.29, to update its designated NG911 Delivery Points Offerors must be able to submit, on behalf of a 911 Authority, a valid Phase 2 Request in accordance with 47 CFR § 9.29(a)-(b).
The Offeror's shall assist the 911 Authority in preparing and submitting a valid Phase 2 Request to the relevant Originating Service Providers (OSPs), requiring that all 911 traffic bound for the 911 Authority’s Public Safety Answering Points (PSAPs) be routed to the newly designated NG911 Delivery Points.
1 A.20 Phase 2 Request for Updated NG911 Delivery Points
2) Standards Compliance: Provide an overview of how your solution ensures all 911 traffic is delivered in IP-based Session Initiation Protocol (SIP) format, in compliance with NENA i3 NG911 standards as specified by the 911 Authority.
1 A.21 Phase 2 Request for Updated NG911 Delivery Points
3) Location Data Integration:
Provide a description of how caller location information will be included in the call signaling, using Presence Information Data Format – Location Object (PIDF-LO).
1 A.22 Phase 2 Request for Updated NG911 Delivery Points
4) Coordination and Execution:
The Offeror shall coordinate with the 911 Authority, impacted OSPs, and other stakeholders to ensure timely, accurate, and compliant implementation of the updated delivery configuration.
| 3 | A.23 | Resiliency: In the event of a failure of any single instance of a hardware or software element, or physical connection, the Offeror's solution shall not negatively impact the overall solution performance. |
| 3 | A.24 | The Offeror's solution's network-connected elements shall support at least two redundant and physically diverse network interfaces. The Offeror must be able to identify if network diversity includes connections from multiple network providers and the use of blended technologies, SD-WAN, or SDN. |
| 3 | A.25 | The Offeror's solution shall have all powered devices include a minimum of two redundant power supplies (each of which powers the device, alone, and which 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. |
| 3 | A.26 | Declare the Offeror's commitment to participate in all future NENA ICE events in which their NGCS and deployed systems can be tested. |
| 1 | A.27 | Offeror commits to obtaining and maintaining any i3 certification from an accredited national certification program when one becomes available |
| 3 | A.28 | Offeror shall implement ANSI related i3 standards in their offerings within 18 months from official publication by the controlling ANSI standards development organization (SDO). Offeror will also maintain a roadmap of planned solution upgrades and share the Roadmap with the primary Agency Point of Contact defined in the contract (or a designee) on an annual basis to allow the involved NGCS 911 Authorities to plan for upgrades in a regular manner. |
| 3 | A.29 | The Offeror's solution shall have the ability for the ESInet to support Alarm integration utilizing ASAP, and other alarm protocols. |
| 3 | A.30 | The Offeror shall not use of any proprietary standards or protocols that deviate from the NENA i3 commonly accepted NG911 standards. The use of RFAI is not a commonly accepted NGCS PIDF-LO standard. By selecting complies, the proposed solution uses only commonly accepted NG911 standards as directed by the 911 Authority. |
| 3 | A.31 | The Offeror's solution shall have the ability to support interoperability for all 911 applications including but not limited to PSAP to PSAP communications, Hosted CAD, CAD data exchange, RMS data exchange, Hosted logging recorder, Radio System backhaul, Other emergency communication data, GIS applications, Text to 911, and other third-party public safety data. |
| 3 | A.32 | The Offeror's solution shall have the ability to support Additional Data Repositories (ADR), Identity Searchable ADR (IS-ADR), and/or commercial third-party Location Information Service (LIS) |
&A &P of &D
B. Security
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Security
Offeror:
Criteria Item # Security Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 1 | B.1 | Offeror shall perform regular testing and proactive analysis of the network for vulnerabilities (e.g., intrusion detection and prevention (IDS/IPS)) and have security controls that align with best practices such as NIST SP 800-53, ISO 27001, and NENA-STA-040.2-2024. |
| 1 | B.2 | Offeror shall provide access reports from facilities down to the individual device level |
| 1 | B.3 | Offeror shall implement and maintain multi-factor authentication (MFA) for any access to externally accessible portals, user interfaces (UIs), etc. and least-privilege access for all systems (e.g., Robustness against cyber threats, access to Policy Routing Function portal, reporting portal, system dashboards, etc.) |
| 1 | B.4 | Offeror shall submit a confidential summary of cyber security related findings to Contract POC of all findings and mitigation actions. |
| 1 | B.5 | Offeror shall provide to the 911 Authority the management reports that list the life-cycle data about key security certificates (PCA certificates, other system related deployed certificates) that should include the Certificate Name and its functional use in the network, quantity of certificates deployed, and certificate life-cycle (e.g., days to expiration, expiring domains, and any reporting data used for audits relative to certificates). |
| 1 | B.6 | Offeror shall ensure that all components and/or functional elements providing NG9-1-1 services under this contract carry valid identity certificates traceable to the PSAP Credentialing Agency (PCA). |
| 1 | B.7 | Offeror shall support the PCA process including the functions as an Intermediate Certificate Authority (ICA), in coordination 911 Authority to issue and manage end-entity certificates and shall acquire and maintain the 911 Authority end-entity certificates with the national PCA per authorization policies |
| 1 | B.8 | Offeror shall support independent, 911 Authority approved, third-party security audits of the solution selected |
| 1 | B.9 | Offeror shall use a validated process to acquire and use valid identity certificates traceable to the NIOC PCA to ensure uniqueness of domain name(s) and interoperability of certificates |
| 1 | B.10 | Offeror shall acquire and maintain PSAP credentials and provide secure reporting visibility of certificates deployed and associated validity periods and a process to ensure certificates are renewed in a reasonable time before certificate expiration |
| 2 | B.11 | Offeror shall utilize Transport Layer Security (TLS) in all communications across the ESInet. |
| 3 | B.12 | Offeror shall have and use a documented change management process, including procedures for handling customer requests. Additionally, this process shall specify how the service provider will communicate scheduled and emergency changes during designated maintenance windows, ensuring the use of a defined Method of Procedure (MOP). All prior notifications regarding changes should be issued a minimum of seven (7) business days in advance. |
| 1 | B.13 | Offeror shall provide 'As-built' documentation for each jurisdiction (911 Authority) and will be submitted prior to system final acceptance |
| 2 | B.14 | Offeror shall provide the security needed for network interface specifications for ESInets including: originating network to ESInet/NGCS interconnection; ESInet to PSAP interconnection; as well as ESInet-to-ESInet and ESInet-to-legacy Emergency Services Network interconnection |
| 1 | B.15 | Offeror shall provide the security standards-based network interface control document for CHE and other systems connected to the ESInet |
| 1 | B.16 | Offeror shall ensure security will be incorporated into the user's guide for all user-accessible solution elements |
| 3 | B.17 | Offeror shall integrate into the interface control document needed to support system monitoring, logging, remote access, and outage reporting. |
| 1 | B.18 | Offeror shall support the NIOC pricing for the PCA. |
&A &P of &D
C. Facilities
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Facilities
Offeror:
Criteria Item # Facilities Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 2 | C.1 | Offeror shall provide network resiliency, dual data centers, and active active configuration, or the functional equivalent, will be incorporated into the design to ensure 99.999% reliability on a monthly basis. |
| 2 | C.2 | For cloud-native deployments, Offeror shall design and validate to support 99.999% reliability. |
| 1 | C.3 | Offeror shall provide physical access restrictions for the data centers and the data at rest used throughout the solution. |
| 2 | C.4 | Offeror shall utilize data centers rated at a minimum of Tier 3, incorporating redundancy (N + 1 or higher) and geographically diverse infrastructure for core services. (ie. NGCS, ESRP, BCF, PRF, and ECRF) |
| 1 | C.5 | Offeror shall use hardened data center facilities for NGCS services operation that can withstand F5-category winds up to 318 miles per hour in accordance with FEMA 361 or equivalent standards and located outside high-risk flood zones |
&A &P of &D
D. Deploy, Monitor, and Alarm
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Deployment, Monitoring, and Alarming
Offeror:
Criteria Item # Monitoring and Alarming Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 3 | D.1 | Offeror's solution shall provide automated network node monitoring and alarming with SLA-backed uptime and failover capabilities |
| 3 | D.2 | Offeror shall integrate an alarming and ticketing system with the ability to respond to security events within 15 minutes and ability to escalate appropriately according to defined security levels and SLAs |
| 3 | D.3 | Offeror shall display network node status in a client-facing dashboard that is an executive level view that provides the ability to identify the status of the solution at a glance and shall include (near) real-time updates of tickets and network status with critical service health indicators |
| 3 | D.4 | Offeror shall provide user-definable notification levels and recipients, with text and email delivery options for responding to: |
1) Unauthorized access attempts
2) Data exfiltration attempts
3) Malware or ransomware activity
4) Known common vulnerabilities and exposures (CVEs)
| 3 | D.5 | Offeror shall support Best Practice Thresholds for Monitoring NG9-1-1 Functional Elements, as specified in NENA-INF-040.2 |
| 3 | D.6 | Offeror shall support outage reporting as required by 911 Authority, state statutes, and FCC requirements |
| 3 | D.7 | Offeror will establish and operate an all US-based Network Operations Center (NOC) capable of providing 24/7/365 monitoring, staffed by qualified personnel, to oversee the following functions: |
1) ESInet and NGCS core elements (e.g., ESRP, ECRF, LVF, PRF, BCF, Bridging)
2) Network availability, latency, jitter, and packet loss
3) Troubleshooting needed to identify root causes impacting, NGCS, CHE, or OSP.
| 3 | D.8 | Offeror shall provide a process for users to submit tickets for incidents, problems, and changes by phone, and directly into an ticketing IT Service Management System with defined user access that does not require users to call a generic nationwide 1-800 number and wait in a generic queue that is not capable of providing the support needed for this NGCS solution. |
| 3 | D.9 | Offeror shall provide a process to perform outward notifications and updates of customer tickets through phone, email, and text |
| 3 | D.10 | Offeror shall provide a process used to demonstrate compliance with SLAs for notification and ticket resolution as outlined in RFP requirements. The process shall include SIP messaging logs, call detail records, and/or call logs to verify compliance with contractual obligations provided to independent third-party for validation at customers direction. |
| 3 | D.11 | Offeror shall provide the Reason for Outage (RFO) reports and regulatory compliance are managed according to Federal Communications Commission (FCC) standards, and include Root Cause Analysis (RCA) for any major service outage with a written report for RCAs delivered within 7 days. |
| 3 | D.12 | Offeror shall provide the media contact for any outage or service failure |
| 3 | D.13 | Offeror shall provide the government and regulatory contact for any outage or service failure |
| 3 | D.14 | Offeror shall provide access for Tier 1, Tier 2, and Tier 3 support to technical staff for escalations |
| 3 | D.15 | Offeror shall provide eBonding in the ticketing IT Service Management platform and other vendor provided system status reporting systems and other third-party NOC/SOC integrations for CHE and CAD that depend on the use of the ESInet/NGCS solution |
| 3 | D.16 | Offeror shall provide the established written escalation procedures communicated to each 911 Authority's management and technical team points of contact |
| 3 | D.17 | Offeror shall provide the defined backup procedures and how change management logs are maintained for any updates to network elements, configurations, or routing logic. Procedures shall include Documentation of completed results from NGCS Acceptance Test Plans (ATPs) and PSAP ATPs. |
| 3 | D.18 | Offeror shall only provide NOC/SOC access that is US based, (meaning there exists no “offshore” remote access into systems installed within any 911 Authority's network for general system administration, maintenance, or troubleshooting.) |
| 3 | D.19 | Offeror shall provide the root cause of a problem, both during deployment and at steady-state when the perception is that a delay or error is being introduced that is outside the control of the Offeror selected in this RFP. |
| 3 | D.20 | Offeror shall provide the process used to ensure that the solution can be deployed even if there are noted gaps in the capabilities of the CHE deployed at the PSAP. The process shall include how conflicts be resolved? |
| 3 | D.21 | Offeror shall provide the process used to manage subcontractors and ensure that they are compliant with all the requirements in this RFP and subsequent contract. |
| 3 | D.22 | Offeror shall support an independent third-party validation of the solution’s feature functionality for interoperability and cyber security |
| 3 | D.23 | Offeror shall provide SIP messaging logs, call detail records, and/or call logs to verify compliance with contractual obligations provided to independent third-party for validation at customers direction. |
| 3 | D.24 | Offeror shall provide the required web interface tools to support the following requirements and capabilities: |
1) Availability of web interface tools for accessing the LDB to extract reports, view TN, MSAG, and GIS data, perform corrections of Discrepancy Reports (DRs), add status notes, and view transaction history as needed to support subscriber validation processes.
2) A web interface tool for viewing and submitting incident and change tickets.
3) An online dashboard showing network, device, and monitoring/alarm statuses.
4) A web interface tool for viewing policy-routing configurations.
5) A web interface tool to access call detail records (CDRs), searchable by date/timestamp, call back number, etc.
6) A call trace application showing SIP messaging (INVITEs, REFERs, SIP errors, etc.) as well as HELD, LoST, and ADR queries and responses.
7) A web tool for Spatial Interface and LVF interface.
| 3 | D.25 | Offeror shall provide web interfaces that are not included in requirement D.24, but may be required to support the NGCS solution. |
| 3 | D.26 | Offeror shall provide a high level diagram of the proposed solution design that includes the transitional and end state design. |
| 3 | D.27 | Offeror shall provide a proposed implementation plan vision |
| 3 | D.28 | Offeror shall provide a sample acceptance test plan |
| 3 | D.29 | Offeror shall provide the leadership and project management needed to ensure the success of the deployment. |
| 3 | D.30 | Offeror agrees that if, during testing, the 911 authority feels that a solution test fails, the 911 authority will provide the successful Offeror with a written description of what test failed and why. The 911 Authority will also identify to the successful Offeror an expected amount of time, no less than 10 calendar days, that will be allowed to resolve the problem. |
| 3 | D.31 | The following (D.31-D.44) will be required from the successful Offeror under Contract and will be considered the property of the 911 Authority. No explanation is needed for the following, provided the offeror selects "Complies". |
| 3 | D.32 | As-built solution design documentation to include configured parameters and policy-routing flow-downs |
| 3 | D.33 | Interface specifications for CHE solution provider |
| 3 | D.34 | Electronic operations manuals for all tools and UIs |
| 3 | D.35 | COOP/DR Plan |
| 3 | D.36 | Detailed Training Plan |
| 3 | D.37 | Project implementation Plan that includes progress reports with written progress updates, key tasks, and milestones distributed within 24 hours of any project call that captures the minutes and action items from all project calls. |
| 3 | D.38 | Detailed Transition Plan |
| 3 | D.39 | Acceptance test plan |
| 3 | D.40 | NENA NG-SEC compliance matrix |
| 3 | D.41 | SI user documentation |
| 3 | D.42 | Project staffing plan |
| 3 | D.43 | Samples of all canned reports |
| 3 | D.44 | NOC/SOC User guides including change-management and escalation processes |
&A &P of &D
E. NGCS Functional Elements
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
NGCS Functional Elements and GIS
Offeror:
Criteria Item # NGCS Functional Elements (FE) Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 2 | E.1 | The use of a Legacy Network Gateway (LNG)/Legacy PSAP Gateway (LPG) (NENA-STA-010.3f-2021) should be minimized since most 911 Authorities that use this RFP are on an ESInet. Offeror shall only provide an LNG and/or Location Database (LBD) when directed by the 911 Authority and agrees to explain why, and which OSP networks the LNG and LDB will service. |
| 2 | E.2 | Offeror shall provide automated failover and load balancing across geographically diverse points of presence (PoPs) to ensure that call spikes do not negatively impact the ability to deliver 911 calls to the correct PSAP. |
| 2 | E.3 | Offeror shall should only use a Legacy Selective Router Gateway (LSRG) when interfacing with a legacy 911 network, which is not the case for much of Virginia, Maryland, and the District. Offeror shall only implement an LSRG when directed by the 911 Authority in accordance with (NENA-STA-034.1-2022). |
| 2 | E.4 | Offeror shall provide the Border Control Function (BCF) (NENA-STA-010.3f-2021) and identify where in the solution this FE will be needed. |
| 2 | E.5 | Offeror shall provide the Emergency Services Routing Proxy (ESRP) (NENA-STA-010.3f-2021) and ensure the ESRP will support integrations with LIS, Forest Guide returned values, and ESInet to ESInet connectivity. |
| 2 | E.6 | Offeror shall provide the Policy Routing Function (PRF) (NENA-STA-010.3f-2021) to include steady state, planned events, and catastrophic events. The PRF shall include alternate routing in the event a PSAP is not available and the validation expected from the 911 Authority. |
| 2 | E.7 | Offeror shall provide the Emergency Call Routing Function (ECRF) that uses standard compliant address points, road centerlines, and service boundaries (primary and secondary PSAPs) (and 3D shapes when they are supported in standards) (NENA-STA-010.3f-2021) that conform to CLDXF for data at rest in the ECRF. |
| 2 | E.8 | For the proposed ECRF, the Offeror shall document its features and capabilities, to include its error handling, default mechanisms, and logging. Documentation shall provide an overview of how it is deployed. |
| 2 | E.9 | Offeror shall ensure the ECRF supports a query from PSAP with a geodetic or civic location. The ECRF shall interface with the Forest Guide and other ECRFs as well as the function of the internal and external ECRF. |
| 2 | E.10 | Offeror shall ensure the ECRF will permit querying by another ECRF, LNG, or ESRP. |
| 2 | E.11 | The Offeror's solution shall support Civic Location Data Exchange Format v2 (US) (and future versions of same) for data at rest as the standard for validating civic address information and as the standard for conveying address information to other elements and systems |
| 2 | E.12 | Offeror shall provide the Location Validation Function (LVF) (NENA-STA-010.3f-2021) that will support the OSP LIS and provide discrepancy reporting and an interface for all OSPs |
| 2 | E.13 | Offeror shall provide the data management support services that will serve as a single point of contact for OSPs and PSAPs to coordinate the resolution of subscriber location discrepancies and support the overall integrity of the call location delivery to PSAPs and include any tools and processes used for coordination of the data in the OSP LIS and the LVF. Offeror shall also have processes for how a PSAP or GIS Authority will submit requests for location updates to the OSP for inaccuracies, discrepancies, readdressing or annexation. |
| 2 | E.14 | Offeror shall provide the Spatial Interface (SI) (NENA-STA-010.3f-2021) |
| 2 | E.15 | Offeror shall provide Spatial Data Provisioning Interface (SDPI) (NENA-STA-010.3f-2021) |
| 2 | E.16 | Offeror shall provide the Spatial Data Management function (SDM) (NENA-STA-010.3f-2021) |
| 2 | E.17 | Offeror shall use Network Time Protocol and Time Source |
| 2 | E.18 | Offeror shall provide the MSAG Conversion Service (MCS), if required for Legacy PSAP Gateways (LPGs)(NENA-STA-010.3f-2021) and offeror shall deploy the interface and hardware requirements that are assumed to be provided by CHE. |
| 2 | E.19 | Offeror shall support NENA GIS Data Model compliance including layers for site structure address points and site structure address polygons (proposed), as well as CLDXF fields. Offerer shall include support for detailed sub address information in terms of buildings, floors, units, rooms, and seats. Offeror shall search for and validate against information in the ESRP, ECRF, LVF, GCS, MCS, and LDB (location database) support as part of the NG9-1-1 transition, optionally include 3D shapes for buildings and interior spaces that contain CLDXF attributes, or reference or use any terrain datasets for reference against future Z/altitude specifications. |
| 2 | E.20 | Offeror shall provide the Discrepancy Report (DR) function as a management system to track, route, and resolve discrepancy reports (NENA-STA-010) |
| 2 | E.21 | When directed, Offeror shall ensure the ability of the NGCS to support the Emergency Incident Data Object (EIDO) and IDX as a standard mechanism to share emergency incident information between and among authorized entities and systems (NENA-STA-021, NENA-STA-024) |
| 2 | E.22 | Offeror shall support options users have to upload data in any provided spatial reference interface and what transformations are allowed (e.g., WGS84 (EPSG 4326)) to format data for use in the NGCS. The shall not include any proprietary interfaces that must be used to support the spatial interface and the ability to integrate the spatial interface with ESRI. |
| 2 | E.23 | Offeror shall support ability to automatically read or pull address and roads updates from a GIS REST service or other means to update data through the SI or equivalent (as opposed to manually loading GIS updates through a website login and interface) |
| 2 | E.24 | Offeror shall make use of provided GIS address or roads data to support MSAG and ALI maintenance needs during the NG9-1-1 transition phase |
| 2 | E.25 | Offeror shall provide the ability to accept GIS layers from different sources, such as the provisioning boundaries from a state and addresses from counties within the state. |
| 2 | E.26 | Offeror shall provide an ECRF that provisions data to the Forest Guide, beyond using a vendor specific forest guide to manage their implementation. ECRF shall include access and provisioning of data to the Forest Guide as defined by current standards and future standard changes, beyond using a vendor specific forest guide to manage the implementation to Forest Guide (NENA-STA-010.3f-2021). Solution shall support credentialing with the Forest Guide and hierarchical ECRFs when integrated with state, national or adjacent NG9-1-1 solutions. |
| 2 | E.27 | Offeror shall provide the Bridging functionality (NENA-STA-010.3f-2021) to include answer all calls at bridge and ad hoc |
| 2 | E.28 | Offeror shall provide the Outbound Call Interface Function (OCIF) (NENA-STA-010.3f-2021), and the ability to transfer to a specific URI and an ad hoc 10-digit transfer |
| 2 | E.29 | Offeror will implement the latest ratified NENA i3 standards in their offerings within 18 months from official publication. The NGCS provider will afford the NGCS Contract designated Agency Point of Contact with detailed descriptions of any issues in complying with this requirement over the life of the contract for awareness and work with the designated POC to establish a work plan to implement the new revised standards on a revised and mutually agreeable schedule in the NGCS solution. |
| 2 | E.30 | Offeror shall leverage Jurisdiction GIS data for geospatial routing of 911 calls, and for responses to CHE LoST queries for police/fire/ems response agencies. |
| 2 | E.31 | Offeror shall provide an ECRF and LVF that supports LoST Sync as defined in STA-010 when requested by the customer, and any successor to the LoST Sync mechanism in future versions of STA-010 used to provision ECRF and LVF coverage to the Forest Guide. |
| 2 | E.32 | Offeror shall provide an SI for the ECRFs, LVFs, other FEs that use GIS data (MCS, MDS, GCS etc) as defined in i3. The SI MUST be used to provision GIS data to the stated FEs and must support a process to identify and suggest corrections for any gaps and overlaps in the GIS data. Any successor(s) to the SI must be employed as well. i3 3.1 will introduce such a successor, the SDPI, along with a companion FE called the SDM. |
| 2 | E.33 | Offeror shall provide secondary quality assurance (QA) and coalescing of GIS data to identify any structural issues with the data (attributes, formatting, missing layers, etc.) as well as any gaps and overlaps for all GIS data provided and undergo data-quality and data integrity checks to ensure that the data complies with all applicable requirements of NENA-STA-015-2018, NENA 02-014, and Attachment B of NENA-STA-01.3.2021. |
| 2 | E.34 | Offeror will return report of errors in tabular format (CSV, XLS), NGUID of feature with error and List of check(s) failed |
| 2 | E.35 | Offeror shall provide web interface and/or automated method to provision data to the SI and retrieve post-QA data for the use of maps and/or the computer-aided dispatch (CAD) system |
| 2 | E.36 | Offeror shall support data exchange in Environmental System Research Institute's (ESRI) structured Query Language (SQL) Spatial Database Engine (SDE) or geodatabase formats as an important capability. |
| 2 | E.37 | The Offeror shall supply the SI for the minimum GIS data needed to deploy the solution and how the GIS data will be provisioned into the ECRF and shall not push all responsibilities to the 911 Authority or the GIS Authority. |
&A &P of &D
F. OSP and SR Migrations
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Origination Service Provider and Selective Router Migrations
Offeror:
Criteria # Origination Service Provider and Selective Router Migrations Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 1 | F.1 | Offeror shall provide the ability to connect to military bases as OSP and as NGCS |
| 1 | F.2 | Offeror shall provide OSP connectivity in support of wireline, wireless, and VoIP traffic, as well as multiline telephone systems (MLTS) |
| 1 | F.3 | Offeror shall coordinate with each 911 Authority served under this contract to obtain a letter of authority/agency (LOA) |
| 1 | F.4 | Offeror shall establish interconnection and commercial agreements, and trunking in alignment with industry standards (e.g., ATIS-0700015) and best practices and FCC Part 9, Subpart J. |
| 3 | F.5 | Offeror shall provide an interface control document (ICD) for all OSP, CHE, and other 3rd party providers requiring ESInet connectivity |
| 3 | F.6 | Offeror shall coordinate with all telecommunications providers, IP circuit providers, and network providers that will be used to manage circuit order processes to include testing and integration. |
| 1 | F.7 | Offeror shall manage all adds, moves, changes, and deletions of connections to OSPs, both TDM and IP-based, monitor these connections, and proactively work with the respective OSPs to resolve problems as they occur |
| 1 | F.8 | Offeror shall coordinate and deploy (where necessary) connectivity to legacy selective routers to support receipt of initial 911 calls, 911 call delivery to PSAPs served by legacy selective routers, and transfers to neighboring agencies not served by the provider's NG9-1-1 NGCS solution, including considerations related to bridging functionality and conveyance of call/incident information |
| 1 | F.9 | Offeror shall coordinate and deploy connectivity to a neighboring ESInet to support transfers to neighboring agencies not served by provider's NG9-1-1 NGCS solution, including bridging functionality and conveyance of call/incident information (i.e., Emergency Incident Data Objects [EIDOs and IDX]) |
| 1 | F.10 | Offeror shall support transition of both TDM (via Legacy Selective Router Gateways and Legacy Network Gateways) and SIP ingress to the ESInet |
| 1 | F.11 | Offeror shall provide 2 in-state Points of Interface (POI) as required by FCC Part 9, Subpart J. |
| 1 | F.12 | Offeror shall support i3-compliant call-handling solution interface with the provided NGCS solution and provide the interfaces needed for the CHE to interface with the ESRP and LIS during all migrations. |
| 2 | F.13 | Offeror shall support conversion and delivery to PSAP of the following: Z-axis: Wireless calls Height Above Ellipsoid (HAE) to Height Above Ground Level (AGL) (or Height Above Terrain, HAT). Today, wireless carriers are required by the FCC to deliver z-axis location in the form of HAE. Offeror's solution shall be able to convert HAE to AGL (or HAT). |
| 2 | F.14 | Offeror shall support Z-axis: Wireless call Z-axis 3D visualization and shall provide a solution to support visualization wireless callers 3D location in a 3D map. It is expected the solution includes the 3D data. |
| 1 | F.15 | Offeror shall integrate all OSP provided location and other media types determined by NENA STA - 010.3e-202 1 for delivery to CHE |
&A Page &P of &D
G. ALI Transition
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
ALI Transition
Offeror:
| Criteria | Item # | ALI Transition | Offeror Response | Response Explanation | Attached Document Reference (if applicable) |
| 2 | G.1 | If requested, Offeror's solution shall provide a Master Street Address Guide (MSAG) Conversion Service (MCS) to assist with converting from an existing NGCS solution to the proposed solution. | |||
| 1 | G.2 | Offeror shall work with OSPs to migrate from the existing Service order input (SOI) process for subscriber records to a Location Information Server (LIS). | |||
| 1 | G.3 | Offeror shall support the Integration and provisioning for MLTS databases. | |||
| 1 | G.4 | If requested, Offeror shall provide the Location Database (LDB) for the Pseudo Automatic Number Identification (pANI) provisioning and shell records management | |||
| 1 | G.5 | If requested, Offeror shall provide the LDB for the provisioning and management of pANIs utilized by Legacy PSAP Gateways and egress Legacy Selective Router Gateways | |||
| 1 | G.6 | Offeror shall manage the transition to include coordination of all provider records from the legacy ALI database to the replacement LDB and any dual provisioning necessary during the transitional phases of the project | |||
| 1 | G.7 | Offeror shall provide reporting for all data within the LDB via a web-based tool and the solution shall support a GIS-derived MSAG for legacy validation. | |||
| 1 | G.8 | Offeror shall ensure FCC Phase 2 compliance and eliminate the need for the LDB. | |||
| 1 | G.9 | Offeror shall provide LDB services needed until all OSPs have completed FCC Part 2 requirements |
&A &P of &D
H. Text to 911
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Text to 911
Offeror:
Criteria Item # Text to 911 Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 2 | H.1 | Offeror shall support the Message Session Relay Protocol (MSRP) |
| 2 | H.2 | Offeror shall support Real Time Text (RTT) capability |
| 2 | H.3 | Offeror shall support transcoding of Baudot tones to RTT |
| 2 | H.4 | Offeror shall deliver 911 text messages via the ESInet to PSAPs from current TCC providers (e.g. Intrado, Comtech) |
| 2 | H.5 | Offeror shall provide policy-based routing on incoming text messages |
| 2 | H.6 | Offeror shall support text transfers from PSAP to PSAP across the ESInet |
| 2 | H.7 | Offeror shall support Rich Communication Service (RCS) when OSPs begin to deliver 911 text messages in this format |
| 2 | H.8 | Offeror shall support all (TCC) capabilities to implement fully compliant NGCS solution for Text to 911 |
| 2 | H.9 | Offeror shall receive text messages and provide 911 routing for all major wireless OSPs today, including the ability to provide reporting that the text was delivered to the PSAP. |
| 2 | H.10 | Offeror shall support interconnection to third-party TCCs |
&A &P of &D
I. Service Agreement (SLA)
| RFP 2000004244 - NGCS and ESInet Fairfax VA and Regional 911 Authorities |
| Appendix C - Technical Requirements |
Service Level Agreements
Offeror:
Criteria # Security Offeror Response Response Explanation Attached RFP Responder Document Reference (if applicable)
| 3 | I.1 | Offeror shall provide capacity levels of each element of the ESInet and the NGCS and ensure the capacity levels can support peak 911 call volumes. This may be in terms of busy-hour calls, network bandwidth, and any other applicable measure. The proposed solution must be capable of handling current call volume plus 25 percent growth over the term of the contract. Offeror shall provide the incremental cost to handle 125% of current call volume in the Optional Pricing Table. |
| 3 | I.2 | Network Latency—Offeror guarantees that maximum latency across its backbone network under full load is sufficient to support NG911 call flow. Offeror shall gather, calculate, and provide the NGCS solution with an end-to-end latency as specified in Appendix F. |
| 3 | I.3 | Point of Presence (POP) to POP—Offeror shall guarantee maximum latency from interconnection facility (also known as, point of presence, or POP) to interconnection facility needed to support NG911 call flow at full capacity and provide the 911 Authority with information on how that data is gathered, calculated, and provided to support the NGCS solution. |
| 3 | I.4 | POP to Endpoints—Offeror shall guarantee maximum latency from interconnection facilities to the network interface device located at the entrance to the customer’s premises needed to support NG911 call flow at capacity, and provide the 911 Authority with information on how that data is gathered, calculated, and provided to support the NGCS solution. |
| 3 | I.5 | Packet Loss—Offeror shall guarantee maximum end-to-end packet loss across its network needed to support NG911 call flow at full capacity. This specification shall also include any loss characteristics associated with another carrier’s network or any applicable wireless links that may be integrated into the ESInet, and provide the 911 Authority with information on how that data is gathered, calculated, and provided to support the NGCS solution. |
| 3 | I.6 | Network Traffic Convergence—Offeror shall implement convergence protocols and guarantee or estimate the network convergence time (<54 milliseconds [ms]) of IP traffic at any point within the proposed solution, and provide the 911 Authority with information on how convergence data is gathered, calculated, and provided to support the NGCS solution. |
| 3 | I.7 | Mean Time to Repair—Offeror shall guarantee the mean time to repair (MTTR) characteristics of its proposed solution in accordance with SLAs. These specifications shall reflect the end-to-end solution, as well as components or subsystems that are subject to failure. Offeror shall provide the 911 Authority with details on how MTTR information will be gathered, calculated, and provided to support the NGCS solution. |
| 3 | I.8 | Mean Time Between Failures—Offeror shall guarantee the meantime between failures (MTBF) characteristics of its proposed solution in accordance with SLAs. These specifications shall reflect the end-to-end solution, as well as components or subsystems that are subject to failure. Offeror shall provide the 911 Authority with how MTBF information will be gathered, calculated and provided to support the NGCS solution. |
| 3 | I.9 | System Availability—Offeror shall guarantee the service level offered as a percentage of time when the service is available, and the maximum period of total outage before remedies are activated in accordance with SLAs. Availability is defined as MTBF divided by (MTBF + MTTR), as specified in Appendix F. Offeror shall provide the 911 Authority with information on how system availability data will be gathered, calculated, and provided to support the NGCS solution after contract award. |
| 3 | I.10 | End-of-Support or End-of-Life Equipment—Offeror shall proactively replace any hardware that has reached end of support (EOS) no later than 120 days prior to the manufacturer’s EOS / EOL date. |
| 3 | I.11 | ESInet and NGCS System Availability—Offeror shall proactively ensure that the NGCS, all functional elements, and the ESInet maintain an uptime of 99.999% monthly, as measured by system availability reports. |
| 3 | I.12 | Call Delivery Success Rate—Offeror shall proactively ensure that the NGCS and all functional elements support a 99.999% successful call delivery to the correct PSAP based on the location provided by the OSP, measured monthly by system call routing reports that include total calls received, how the call was routed, where the call was routed, and call routing times. |
| 3 | I.13 | Location Information Services – Offeror shall provide LVF that ensures the OSP is capable of delivering 98% of calls with a valid PIDF-LO object using a valid CLDXF-US compliant civic address for non-wireless OSPs and geodetic for wireless OSPs, with a LIS retrieval from the ESRP of less than 2 seconds. |
| 3 | I.14 | ECRF Spatial Interface Support – Offeror shall ensure that any valid spatial interface update to the ECRF is completed and in production within 72 hours of receiving a valid data input from a GIS contributor. |
| 3 | I.15 | Remedies—Offeror shall comply with the financial and operational remedies to the purchaser and its designated agencies for each event, as identified in Appendix F, based on service credits for each hour of downtime that exceeds the SLA requirements. |
| 3 | I.16 | It is expected that the Offeror will have processes and procedures for supporting a NOC/SOC that can rapidly triage calls. Offeror shall have documented and defined the attributes of its incident severity levels, including response and resolution times for each severity level, and how response and resolution times are measured. |
| 3 | I.17 | Offeror shall have documented processes and procedures for change management, managing and monitoring any changes, TDOS, and DDOS monitoring and reporting, and notification of any service-impacting incidents. |
| 3 | I.18 | Offeror shall provide incident management support and response based on the criticality of the incident. The 911 Authority will determine the criticality of the incident that will trigger severity levels as outlined in Appendix F. |
| 3 | I.19 | Offeror shall comply with all applicable FCC rules throughout the term of the services contract. |
| 3 | I.20 | Offeror shall notify the 911 Authorities and/or its designee within 15 minutes of discovering an outage that may impact 9-1-1 services. At the time of initial notification, the Selected Offeror shall convey all available information useful for mitigating the effects of the outage, including a name, telephone number, ticket or reference number, and email address for follow-up. The Selected Offeror is responsible for coordinating data gathering, troubleshooting, and reporting on behalf of its suppliers, and for providing 24/7 network monitoring. |
| 3 | I.21 | Offeror shall communicate any additional material information to the 911 Authority or its designee no later than two hours after the initial contact, and at intervals no greater than two hours thereafter until normal 9-1-1 service is restored. This information shall include the nature of the outage, its best-known cause, the geographic scope, the estimated time for repairs, and any other relevant details. |
| 3 | I.22 | Following the restoration of normal 9-1-1 service, the Selected Offeror shall provide a Reason for Outage (RFO) Report / Root Cause Analysis to the 911 Authority and/or its designee within 30 days of discovering the outage. Offeror shall comply with the notification and reporting requirements in Appendix C, Appendix F, and the RFP. Additionally, Offeror shall provide NOC/SOC tools and techniques to ensure that its suppliers perform troubleshooting and post-event analysis, with associated reports. |
| 3 | I.23 | Outage notifications are a critical element for understanding overall system health. Awareness of issues in neighboring PSAPs provides valuable insight into potential impacts elsewhere. For example, if PSAP A’s trunk capacity is impaired and PSAP B is its first alternative route, insight into the impairment will help PSAP B prepare staff for potential call influx. Therefore, the 911 Authority is interested in an outage notification service that allows each PSAP to select the types of notifications and the PSAPs for which it will receive outage alerts, updates, and RFO reports. A web portal for authorized users to select/deselect notification types is preferred. Offeror shall provide a method to support such an outage notification service. |
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 .