142083-27-0002_NOAAPort_RFI_Questions.pdf

1. BACKGROUND

The National Weather Service (NWS) Advanced Weather Interactive Processing System

(AWIPS) Satellite Broadcast Network (SBN) system provides a one-way broadcast of NOAA environmental data and information in near-real time to NOAA and external users. This AWIPS

SBN (managed by the AWIPS Network Control Facility (NCF) service is operated by a commercial provider of satellite communications utilizing a C-band frequency. Weather data

(satellite imagery, radar data, model data, sensor data, etc.) is collected and processed across the

Weather Enterprise and then fed to the NCF, which disseminates the products via the AWIPS

SBN / NOAAPort data broadcast via the Galaxy 31 Satellite. Currently, all NWS products are evolving with greater resolution, additional details, and conversions from text base to a digital format, increasing bandwidth requirements over the AWIPS SBN.

For nearly three decades, the NOAAPort SBN has served as a central broadcast mechanism delivering real-time weather, satellite, radar, numerical weather prediction model output, and emergency warnings across C-band satellite transponders to field offices, commercial weather entities, emergency managers, and interagency partners. The NOAAPort SBN is scheduled for deactivation as early as August 31, 2027.

The two primary drivers that necessitate the decommissioning and replacement of the

NOAAPort SBN are:

1. Cloud Enterprise Migration: The NWS is actively transitioning its core operational forecasting applications to cloud-native platforms, eliminating internal NWS field reliance on dedicated SBN satellite broadcasts.

2. C-Band Spectrum Reallocation: The Federal Communications Commission (FCC) plans to auction and repurpose upper C-band satellite spectrum, impacting the long-term availability and viability of the legacy C-band broadcast infrastructure.

While internal NWS users will access data via tools within the NWS Enterprise Cloud (NEC) environment, external stakeholders—including commercial vendors, emergency managers, and academic institutions—will not have direct access to these internal-NWS tools and will therefore require alternative pathways that are robust, low-latency, and highly-available.

2. PURPOSE AND OPERATIONAL OBJECTIVES

The NWS seeks industry feedback on technical architectures, delivery paradigms, commercial services, and migration strategies capable of satisfying the following core objectives:

● High-Volume Data Delivery: Sustained distribution of large diverse data streams, including hazard information, forecasts, surface and upper air observations, high-resolution satellite imagery, weather radar, numerical model output, and more.

● Low-Latency and High Reliability: Deterministic, low-latency transmission meeting or exceeding 99.99% operational availability, even during severe weather outbreaks or regional network disruptions.

● Dynamic Priority Queuing and Low-Latency Escalation: Automated, multi-tier traffic management to guarantee that life-safety and mission-critical communications are prioritized over routine or bulk data transfers. Prioritized alert streams must execute direct, zero-wait delivery paths to achieve minimal end-to-end latency, ensuring immediate arrival at customer ingest nodes regardless of overall system throughput or peak network utilization.

● Dissemination Diversity: Cloud-native messaging/event-driven architectures, hybrid terrestrial IP networks, and potential fallback wireless/satellite transport options.

● Cost Efficiency and Open Standards: Non-proprietary protocols and scalable delivery models that minimize capital hardware investments for external data consumers.

3. REQUESTED INFORMATION AND INDUSTRY QUESTIONS

Respondents are encouraged to address any or all of the following topics in their submissions:

3.1.Technical Architecture and Delivery Solutions

3.1.1. Cloud and Hybrid Dissemination: What commercial cloud-based or hybrid IP delivery architectures represent best practices for streaming continuous, high-volume

(100 Mbps minimum) meteorological data to thousands of concurrent endpoints?

3.1.2. Low-Latency and Deterministic Transport: In your experience, what methods can be employed to guarantee deterministic delivery and minimal jitter for time-critical hazard warnings and real-time radar/satellite products?

3.1.3. Bandwidth Efficiency: What compression, filtering, or selective subscription technologies can be leveraged to allow users to ingest tailored subsets of data without requiring full-feed ingest?

3.1.4. Data Stream Preemption and Traffic Prioritization: What architectural designs can dynamically detect, classify, and prioritize life-safety products (e.g., severe weather warnings) over heavy, scheduled payloads during periods of peak system load or bandwidth throttling? What mechanism(s) can be employed to ensure critical alerts experience near-zero added queueing delay?

3.2.Weather Resilience and Continuity of Operations (COOP)

3.2.1. Severe Weather Operating Conditions: What transport mechanism(s) do you recommend to maintain operational integrity during severe weather events that may be accompanied by widespread power/telecom outages?

3.2.2. Non-Internet / Redundant Fallback: For stakeholders in remote or degraded network environments, what cost-effective mechanisms could provide resilient backup connectivity?

3.3.Security and Data Integrity

What security protocols and tools do you recommend to ensure end-to-end data integrity, source authentication, and protection against tampering or denial-of-service across public cloud or public internet pathways?

3.4.Transition Strategy and Execution

3.4.1. Migration Timeline and User Onboarding: Based on a legacy target deactivation in August 2027, what timeline and testing milestones would be required for industry and external partners to integrate, test, and transition to a new distribution paradigm?

3.4.2. Interoperability and Standards: What solutions can be leveraged to serve user communities with different levels of technical agility (i.e., highly agile groups may only need a month while less agile groups may need years) while minimizing operations and maintenance costs.

3.5.Acquisition and Contracting Approach

3.5.1. Recommended Contracting Model: What contract structure, contract type, or combination of contractual arrangements would best align with the commercial delivery models applicable to the contemplated NOAAPort replacement capability?

In your response, consider approaches such as firm-fixed-price arrangements, managed services, subscription- or consumption-based services, Data-as-a-Service, indefinite-delivery/indefinite-quantity (IDIQ) vehicles, or other commercially available models.

3.5.2. Additional Information Required from the Government: What additional technical, operational, performance, security, transition, or pricing information would your organization need from the Government to develop a meaningful proposal and associated pricing for this requirement?

3.5.3. Rough Order of Magnitude (ROM) Cost Estimate: The Government is seeking a general cost range for market research and acquisition planning purposes only. A detailed cost breakdown, supporting cost data, or formal pricing analysis is not required. Based on your understanding of the contemplated NOAAPort replacement capability, provide a high-level ROM estimate or cost range for implementing and operating the proposed approach.

The ROM should, at a minimum, distinguish between:

● Estimated one-time or non-recurring costs to establish and implement the capability; and

● Estimated recurring costs to operate and sustain the capability;

Respondents should also briefly identify:

● What key assumptions were used in developing the ROM estimate; and

● Any significant factors that could materially affect the estimated cost.