RFP Addendum 4 for posting.pdf

SPB Form 26 Last Revised 4-17-2025

SOLICITATION ADDENDUM 4

QUESTIONS AND ANSWERS

SOLICITATION NUMBER: 202591102

NG 911 Data Analytics Reporting System

Opening Date: September 2, 2025 Addendum Effective Date: August 11, 2025

Questions and Answers

Following are the questions submitted and answers provided for the above-mentioned solicitation. The questions and answers are to be considered as part of the solicitation. Questions came from both those submitted in writing and those asked at the solicitation conference. The answers provided below control and take precedent over any verbal information provided at the solicitation conference. It is the responsibility of bidders to check the State Purchasing Bureau website for all addenda or amendments.

Question

RFP

Section

Reference

RFP

Pg #

Question State Response

1.

Project Requirements and Scope of Work

17 PSC received various questions regarding obtaining an extension and/or clarification of the due date for the RFP.

Please refer to Addendum 2, Revised Schedule of Events. Bids must be received electronically no later than August 29, 2025.

No further extensions will be provided.

2. Technical Requirements

7 Should the analytics platform interface directly with ESInet functional elements, or integrate with an existing or future i3 logger that is part of the core services?

The preferred integration point is ESInet / NGCS logging elements. The analytics platform should be capable of interfacing with logger to consume i3-standard events, metadata, and call/session records. Direct access to ESInet elements may be limited based on provider agreements and local PSAP arrangements.

3. Technical Requirements

7 Can we get clarification on which aspects of the analytics solution are subject to i3 architecture standards?

The analytics engine itself does not need to be natively i3-compliant but must consume i3-compliant data using standard protocols (e.g., SIP, MSRP, log schemas per NENA STA-010.3). Only those aspects of the analytics platform that interact with NG9-1- 1 elements to collect log events —such as call data, network events, session metadata, or logging feeds—are subject to i3 standards.

4. Project Requirements and Scope of Work

4 What is the number of hosts/systems needed for the state to have analytics?

Nebraska PSAPs are currently formed into seven host/remote regions. There are two hosts for each region. The hosts for the Southeast Region currently reside at Lumen data centers.

Question

RFP

Section

Reference

RFP

Pg #

Question State Response

5. Technical Requirements

9-

To avoid gaps in end-to-end traceability, could you confirm which exact NENA-STA-010.3 LogEvent classes you expect each Functional Element

(ESRP, BCF, ECRF/LVF, LNG)

to emit to the centralized Logging Service mentioned “Enterprise-Wide Reporting, Logging, and Data Collection”?

The LogEvent classes expected are

• CallEvent

• LocationEvent

• CallEvent

• LocationEvent

• PolicyEvent

• MediaEvent

• SystemEvent

• SecurityEvent

• InterfaceEvent

• ErrorEvent.

6. Technical

10 Section 2.1 also notes that logs must be “scalable support for long‑term retention,” but does not state a duration. Would the PSC like the solution to retain i3 log records for a specific number of years, or to align with Nebraska’s current records‐retention schedule?

The retention schedule should be scalable, as PSAPs may have a different retention time period than the PSC. Please use the longer retention schedule if there is a conflict.

7. Technical

10 The RFP asks the system to “generate reports in accordance with the NENA‑STA‑010.3 Discrepancy Report mechanisms” . It is often observed that jurisdiction‑specific fields are added to these reports. Are any PSC‑defined fields or codes required beyond the standard i3 Discrepancy schema?

There are no PSC-defined codes beyond i3 Discrepancy schema.

8. Technical

11 2.3 requires automated differentiation of test calls and transferred calls (p. 11). For consistent KPI calculations, would you prefer that the platform expose a boolean flag at ingestion time or a post-processing classification rule library?

Please describe the vendor’s capability to detect and differentiate between legitimate/live calls and anomalous or non-genuine activity. This includes identifying test calls as well as calls that exhibit unusual patterns—such as those occurring at regular intervals, from repeat numbers within a short timeframe, or at consistent times of day—indicative of potential automation or scripted behavior.

9. Technical

8 In 1.5 “Data Collection & Integration” (p. 8), CPE feeds, CAD systems, and third-party APIs are listed as

The capability and formats need to be flexible depending on the API integration.

RFP

Section

Reference

RFP

Pg #

Question State Response sources. Could the PSC enumerate the message formats (e.g., SIP logs, XML ALISA, JSON webhook payloads) expected from each source to avoid ingestion gaps?

10. Technical

8 In 1.5 , what polling or push frequency is acceptable for CAD integrations where real-time webhooks are not available? (polling interval unspecified)

The requirements for CAD integration have been removed. This is no longer a requirement for the requested solution.

11. Technical

7 1.2 “Data Integrity & Security” calls for “configurable validation rules.” To ensure traceability of rejected records, should failed validation events be persisted in the same logging store or a separate quarantine dataset?

Either method is acceptable

12. Technical

7 If validation fails on a live transaction (1.2, p. 7-8), is the desired behavior is to block ingestion, forward with warnings, or retry with back-off? (error-handling path unclear)

There is no preference at this time for a specific desired behavior

13. Technical

7 1.2 states “encryption of all data at rest using AES-256 or higher”. Does the PSC require KMIP-compliant external key management, or is cloud-native KMS acceptable if FIPS 140-2 validated?

Cloud-Native KMS is acceptable

14. Technical

7 The same section mandates “real-time IDPS with automated response” (1.2,

p. 7-8). Could you clarify whether evidence of IDPS alerts must be available inside the NG911 reporting UI, or is quarterly attestation sufficient?

Quarterly attestation is sufficient

RFP

Section

Reference

RFP

Pg #

Question State Response

15. Technical

9 To prevent cross-tenant data leakage (1.6, p. 9), are dedicated logical schemas per PSAP acceptable, or is full physical segregation required?

Dedicated logical schemas per PSAP are acceptable

16. Technical

8 1.4 “Reporting & Analytics” requires customizable dashboards with drill‑down

(p. 8). Would the PSC like to standardize on a specific visualization library palette or follow vendor defaults?

Vendor can show what they have as their defaults and if something else is requested/need, that can be worked through and adjustments made through contract.

17. Technical

8 The same section references export in “XML, JSON, CSV, Excel, PDF” (1.4, p. 8). Are there size limits or field-level redaction rules that exports must enforce before distribution?

There are no size limits or field level redaction rules identified at this time.

18. Technical

12 4.0 “Ad-Hoc Reporting System” lists UI elements like drop-downs and help functions (p. 12). Could you confirm whether ad-hoc designers are limited to PSC staff or also available to PSAP supervisors?

AD HOC reporting should be available to all authorized users with the only difference being the data set available.

19. Technical

8 Predictive analytics for call-volume forecasting are requested in 1.4 (p. 8). Does the PSC have minimum accuracy thresholds (e.g., ≤10 % MAPE) or confidence-interval expectations for model outputs?

The State does not have minimum accuracy thresholds identified. Either method is acceptable.

20. Technical

8 Geospatial views such as heatmaps and choropleths are called for in 1.4 (p. 8).

Which map projection (e.g., EPSG:4326 vs. EPSG:3857) and base-map provider should the system default to for statewide Nebraska displays?

Regarding map projections and basemaps, our primary concerns for map products are readability and interoperability. EPSG: 3857 is an acceptable default for web maps;

however, we have no strong preference so long as the projection is appropriate for geographic data relevant to Nebraska.

RFP

Section

Reference

RFP

Pg #

Question State Response

Similarly, vendors should utilize whatever basemap(s) best suit the product following common cartographic principles and design practices.

21. Technical

11 3.0 “Data Capture Requirements” asks for a color-coded statewide PSAP system-health map (p. 12).

Could you share the specific health metrics and threshold values that drive the green/yellow/red status?

High priority:

• Call Volume and Traffic Load

• Call Failure Rates

• Latency & Response Times

• Outage or Degraded Service

• Location Accuracy and Errors

Medium priority:

• Security & Interface Events

• GIS and Routing Integrity

22. Technical

7 Network performance monitoring (1.3, p. 7) lists latency, packet-loss and jitter.

For alerting, would the PSC like ITU-T G.114 thresholds (≤150 ms one-way) adopted, or a custom baseline?

ITU-T G.114 threshold is acceptable, The ESInet provider is responsible for SLA performance and reporting, as defined in their contract. The analytics platform may be used for independent verification or correlation of SLA adherence, but not as the primary SLA enforcement tool.

23. Technical

7 Reliability requirements include “redundant components and automatic failover” with DR plan (1.3,

p. 7). Could you specify the target RPO/RTO values PSC expects for both the analytics UI and underlying data lake?

99.9% availability, 1 hour RPO considering continuous and near real time backups, 4 hour RTO

24. Technical

11 It is often observed that inconsistent “test-call” indicators can distort statewide KPIs. In 2.3 (p. 11), would the Commission prefer that vendors supply a canonical enumeration and ingestion-time mapping table for all legacy test-call flags, or retain vendor-specific codes and normalize them only at the reporting layer?

Test call reference being removed from the amended RFP. Requesting instead abnormal call activity from normal call traffic. (i.e.

numerous calls from same number in short timeframe, numerous calls from same numbers noted to be a repeatable pattern -such as test calls at shift change, etc.)

25. Technical

9 In 1.5 (Data Collection & Integration, p. 9), Either method is acceptable.

RFP

Section

Reference

RFP

Pg #

Question State Response transformation and enrichment tools are required to "clean, normalize, and augment raw data." Would the PSC prefer a business-user rules engine for these transformations, or vendor-managed ETL scripts governed by change control?

26. Project and Scope of Work

4 What is the number of total PSAP positions used for call taking across the state?

106 Active 271 Total

27.

Project Requirements and Scope of Work 4

How many PSAPs have dedicated backup sites, and how many call taking positions are at that site? 6 Backup Sites

28. Addendum 1

Is there a cost proposal sheet missing from Attachment B to fill out?

No

29. Technical

7 Section E. Technical Requirement specifies that each item must be marked as "Comply" or "Exception."

However, there are certain items that are not applicable to the MIS solution. Would it be possible to include "Not Applicable" as an additional response option? We are prepared to provide justifications for any items marked as such, and this would allow us to more accurately reflect the compliance status of our solution.

Anything not applicable would be an exception. Please explain the exception.

30. Cost 28 In order to provide cost – the following information is required:

1) Individual PSAP names

2) Position Count per

PSAP

3) Indicate if PSAP is stand along, a HOST PSAP or Backup PSAP

See included list to follow.

RFP

Section

Reference

RFP

Pg #

Question State Response

4) PSAP CPE type and CPE Version

31. Project Requirements

6 Is the analytics expected to perform core network monitoring, such as bandwidth and jitter, or consume the data from the ESInet or core service provider?

The analytics platform is not expected to perform NGCS and ESInet diagnostics (e.g., bandwidth, jitter) that is the role of the ESInet and NGCS provider. It is expected to consume and have the capability to perform analysis on the operational and performance data made available by the ESInet and NGCS provider(s). This includes data feeds, logs, and performance metrics the vendor can expose.

32. Technical

7 Should the analytics platform interface directly with the ESInet functional elements or interface directly with the I3 logger that is part of the core services?

The preferred integration point is ESInet / NGCS logging elements. The analytics platform should be capable of interfacing with logger to consume i3-standard events, metadata, and call/session records. Direct access to ESInet elements may be limited based on provider agreements and local PSAP arrangements.

33. Technical

8 Is the analytics solution responsible for independent monitoring of SLAs adherence in the ESInet or is the ESInet provider expected to provide that service?

The ESInet provider is responsible for SLA performance and reporting, as defined in their contract. The analytics platform may be used for independent verification or correlation of SLA adherence, but not as the primary SLA enforcement tool.

34. Technical

11 Is analytics platform expected to store 24-months of voice recordings, or integrate with external archival or logging systems?

The analytics platform is not expected to natively store 24 months of voice recordings.

Instead, it should integrate with the existing logging and archival system that stores audio, providing retrieval, indexing, and analytical capabilities.

35. Technical

7 Can we get clarification on which aspects of the analytics solution are subject to I3 architectural standards? So specifically, does it already have to be part of the NG I3 standard?

The analytics engine itself does not need to be natively i3-compliant but must consume i3-compliant data using standard protocols (e.g., SIP, MSRP, log schemas per NENA STA-010.3). Only those aspects of the analytics platform that interact with NG9-1- 1 elements to collect log events —such as call data, network events, session metadata, or logging feeds—are subject to i3 standards.

36. Project

4 Ingestion of former systems data, will that data be given in

Legacy system data ingestion format and terms will depend on the prior vendor and

RFP

Section

Reference

RFP

Pg #

Question State Response the former vendors parsed format of provided from a Raw CDR Log?

transition planning between the two parties.

It is anticipated that there will be an agreement between all parties to ensure data can be retained. Data format specifics may vary and the expectation is to define these areas during transition planning upon contract execution.

37. Project

5 Secondarily, If from the vendors distilled log, after transformation, would the data be treated as a demark since we wouldn’t have the raw data, from there or “as is” and then the data would be in new vendor format moving forward?

Once legacy data is transformed and ingested, the demarcation for demark would begin with the new system. From that point on, the data is managed in the new vendor’s normalized format, but historical records should remain distinguishable for audit purposes.

38. Project Requirements

6 Will the core service provider push data out or is the expectation to pull that information our from said vendor?

The expectation is that the analytics platform will need to pull data from NGCS or logging systems via APIs, secure file transfer, or similar methods. Push models may be negotiated depending on provider capability but should not be assumed.

39. Schedule of Events

Ad

A follow-up timeline wise. You talked about beginning the project in Oct., and at some point you have an NGCS rebid essentially, would the state want to build out the current provider or more focused 1st on PSAP data collection and then come back to core service part after or is that expectation whole thing would be stood up and then have a transition to new NGCS vendor, if there is a new NGCS vendor?

The priority is initially focused on PSAP data collection, with adaptability for future integration with a new or existing NGCS provider. The project should be architected to support phased transition, minimizing rework if NGCS rebid leads to a new provider.

40. Technical

8 On your current vendors, CAD vendors, CPE vendors question. Do the vendors follow EIDO NENA standards, or do they use their own data format?

The use of EIDO (Emergency Incident Data Object) standards is not presently universal.

Some vendors may support it; others may still use proprietary formats. The analytics platform should be able to handle formats for EIDO that are required at implementation and transform as needed.

RFP

Section

Reference

RFP

Pg #

Question State Response

41. Project Requirements

6 RFP mentions predictive analytics and call volume forecasting. Are there any specific use cases or are you looking to better understand hourly or seasonal use cases> What are you wanting to better understand (section 1.4) What type of forecasting are you looking for?

At a minimum, the State is interested in hourly, seasonal, and event-based forecasting to support staffing models, workload distribution, and resource planning. Use cases could include:

• Peak hour analysis

• Event impact forecasting

• Seasonal call trend prediction

• PSAP workload balancing

42. Technical

8 RFP mentions being able to pull from 3rd party applications: are there currently any 3rd party applications or service providers that are deployed that would need to be integrated with?

Potential other 3rd party applications may also need to be integrated including local call logging systems, CAD, MIS tools, or workforce management systems. The platform should support extensible APIs and plug-ins for integration flexibility.

43. Technical

13 (Section 8) Frequency of reports provided such as call volume and call forecasting:

Would this still require delivery or is there something other to get report itself?

Reports must be available via web-based dashboards, scheduled email delivery, and on-demand export. The platform should support both push and pull models for report access.

Further, both scheduled and ad hoc reports are required. Users should be able to generate real-time reports based on filters or triggers and schedule recurring delivery (e.g., hourly, daily, weekly summaries, monthly performance reports).

44. Project Requirements

4 If you had to prioritize the key elements in the RFP, who would you prioritize them?

What are the highest priority items?

While the State would define final priorities, the ranking may change if the ESInet / NGCS vendor changes, or a PSAP condition exists that would alter the phased approach:

1. Data Integration with PSAPs and

NGCS

2. Forecasting and Analytics Accuracy

3. Reporting Flexibility

4. Scalability Across All PSAPs

5. I3 Logging and Compliance

45. Cost 28 You mentioned some of the

PSAPs don’t have CAD systems. Do you want the pricing to be reflected per PSAP vs. those that don’t?

How do you deal with a PSAP that doesn’t have a CAD vs the ones that do?

Vendors should detail per-PSAP pricing to allow greater flexibility if pricing needs to be adjusted.

This addendum will be incorporated into the solicitation.

RFP

Section

Reference

RFP

Pg #

Question State Response

46. Technical Requirements

8 To clarify: From a wide view these are numerous call handling vendors and their commodities, and 1 NGCS, so large variables with CAD vendors? Some clarification on that and the expectations of doing some on premises data collection would be necessary and therefore require more hardware being deployed unless CAD vendors can provide an API?

Yes, for PSAPs lacking APIs or cloud-enabled interfaces, on-premises hardware may be necessary to gather data. This should be accounted for in the cost proposal. It will be incumbent upon the respondent to provide any needed clarifications as to their pricing scheme. CAD specific integrations are no longer required.

47. Project Requirements

4 I know you went over the regional listings and such at the beginning: Can a list be provided for each PSAP and their connections and host connections for network planning purposes? If possible, the call handling providers for network planning purposes?

See included list to follow.

48. Proposal Instructions

28 On the SOW, Item 3, page 28:

2nd paragraph, Further information or expand: the response should contain responses to the following: Is there something missing there or is that just in reference to the remainder of the RFP?

This was corrected in Addendum 3.

PSAP NAME POSITION COUNT HOST/REMOTE CPE TYPE CPE VERSION

Antelope County 2 Remote Solacom Guardian NG 911

Boone County 2 Remote ECW 4.7.8.892942

Boyd-Holt Counties 2 Host Solacom Version 22

Brown County 2 Remote Solacom Guardian NG 911

Buffalo County 8 Host Viper Version 7

Burt County 2 Remote Viper Version 7

Butler County 2 Remote ECW 4.2.8.8.8553

Cass County 4 Remote Vesta Mech

Cedar County 3 Remote ECW Motorola

Chase County 2 Remote Viper Version 7

Cherry County 3 Host Solacom Guardian NG 911

Cheyenne County 3 Remote Viper Positron version 7

City of Alliance 3 Remote Viper Version 7

City of Beatrice/SE NE 911 4 Remote Vesta R6.1RF1

City of Columbus 4 Host ECW 4.4.7.112214

City of Falls City 2 Remote Vesta Mech

City of Grand Island 5 Host ECW WM 4.4.6.110606

City of Hastings 4 Remote Vesta Mech

City of Holdrege 2 Remote Viper Version 7

City of Lincoln 18 Remote Vesta Mech/8.0.242.485

City of McCook 2 Remote Viper Version 7

City of Norfolk 6 Host Motorola ECW 4.4.7.4.1575

City of North Platte 6 Remote Viper Version 7

City of South Sioux City 4 Host ECW Motorola

City of Wayne 5 Remote ECW Motorola

Clay County 2 Remote Vesta 8.0.242.458

Colfax County 2 Host Viper Version 6.4.0.353

Cuming County 2 Remote Viper Positron

Custer County 3 Remote ECW Motorola

Dawes County 2 Remote Viper Version 7

Dawson County 4 Host Viper Version 7

Dixon County 2 Remote ECW 10.0.2.52

Dodge County/Fremont 4 Host Viper Version 7

Douglas County 13 Host Viper Version 7

Dundy County 1 Remote Viper Version 7

Fillmore County 2 Remote Vesta Mech

Franklin County 3 Remote Viper Version 7

Frontier County 2 Remote Viper Version 7

Furnas County 2 Remote Viper Version 7

Garden County 2 Remote Viper Version 7

Hamilton County 3 Remote ECW Version 4.4

Hitchcock County 1 Remote Viper Version 7

Howard County 2 Remote Viper Version 7

Jefferson County 911 3 Remote Vesta Mech

Johnson County 2 Remote Vesta 911 8.0

Kearney County 2 Remote Viper Version 7

Keith County 3 Remote Viper Version 7

Kimball County 3 Remote Viper Version 7

Knox County 2 Remote ECW 4.4.7

PSAP NAME POSITION COUNT HOST/REMOTE CPE TYPE CPE VERSION

Morrill County 2 Remote Viper Version 7

Nemaha County 2 Remote Vesta Mech (8)

Nuckolls County 911 2 Remote Vesta 8.0242.485

Otoe County Sheriff 2 Remote Vesta Mech

Perkins County 3 Remote Viper Version 7

Pierce County 2 Remote ECW Motorola

Region 26 3 Remote ECW Version 4.4.7.1

Rock County 2 Remote Solacom Left Blank

Saline County 3 Remote Vesta 8.0.245.485

Sarpy County 10 Remote Viper Version 7

Saunders County 3 Remote ECW Motorola

Scotts Bluff County 4 Remote Viper Version 7

Seward County 4 Remote Vesta Mech

Sheridan County 2 Remote Solacom Solacom

Thayer County 2 Remote Vesta Mech

Thurston County 2 Remote ECW Version 4.4.7.112214

Washington County 911 3 Remote Viper Version 7

Webster County 2 Remote Vesta Mech

York County 4 Remote Vesta Mech

This addendum will be incorporated into the solicitation.