Network Extension for User Continuity and Sustainability (NEXUS)

Statement of Objectives (SOO)

1. PURPOSE

The purpose of this Statement of Objectives (SOO) is to define mission objectives, measurable performance outcomes, and constraints that enable industry to propose commercially scalable, technically credible, secure solutions. This SOO establishes what must be achieved through demonstration to validate service readiness and inform transition to sustained commercially provided relay services.

NEXUS is intended to validate not only technical compatibility, but also the Offeror’s ability to deliver assured mission support for Government users through reliable service availability, operational continuity, effective prioritization, and a credible path to sustained relay services.

The demonstration must also provide NASA with confidence that the proposed approach can scale on a schedule that supports incremental sustained service availability beginning in 2029 and progression toward full operational capability by mid-2031.

Terminology Note: For purposes of this SOO, the terms Offeror, Provider, and Vendor refer to the entity submitting a proposal in response to this solicitation. The terms customer vehicle, customer platform, customer control center, user, legacy user, and TDRS user refer, as applicable, to the existing NASA or Government missions, spacecraft, platforms, ground control elements, or user organizations currently supported by TDRS-based relay services.

2. DEMONSTRATION MISSION OBJECTIVES

The objectives and outcomes of this demonstration phase are critical to validating a viable solution for long-term commercially provided relay services supporting NASA and other legacy Government missions. The key objectives for the NEXUS on-orbit demonstration include:

• Protect continuity of legacy Government missions operating within defined TDRS Ka-band spectral ranges without requiring modification to customer vehicle onboard systems.

• Demonstrate an operationally viable on-orbit relay service using a representative implementation of the proposed sustained-service architecture.

• Obtain NASA Authority to Connect (ATC) prior to beginning the on-orbit performance measurement period. ATC indicates that the demonstrated NEXUS service is ready for a designated Government user or users to connect to the service.

• Complete an initial on-orbit demonstration that includes a minimum 30-calendar-day on-orbit performance measurement period using the proposed backward-compatible Ka-band relay capability.

• Execute end-to-end concurrent forward and return relay services, including scheduling, service activation, data delivery, monitoring, and full relay between the customer platform and the Ground Service Interface.

• Verify applicable service requirements and validate performance, coverage, concurrency, handovers where applicable, and operational execution through on-orbit demonstration across the required space, ground, network, scheduling, user, and Ground Service Interface elements.

• Generate sufficient technical, operational, schedule, cost, user-integration, and service-assurance data to inform future Government decisions regarding sustained relay services and NASA’s assessment of long-term assured mission delivery.

• Enable service readiness within a timeframe acceptable to maintain legacy service availability.

3. REQUIRED PERFORMANCE OUTCOMES

The Offeror must demonstrate compliance with functional and performance outcomes sufficient to validate backward-compatible relay service capability. This SOO establishes NASA’s objectives, required outcomes, and operational context for the NEXUS demonstration. Detailed functional, performance, interface, and verification requirements for the full service are contained in Attachment A.2, NEXUS Service Requirements Document (SRD). Offerors proposed concept must comply with the SRD in its entirety and demonstrate an increment of the concept. In the event of an inconsistency between the SOO and SRD, the SRD will govern technical requirements.

The Offeror must deliver verification evidence against applicable requirements and, through an on-orbit demonstration, provide validation of capability that is applicable and scalable to a full backward-compatible Ka-band service. NASA requires sufficient information to evaluate demonstrated performance, service assurance, scalability, operational readiness, and the remaining work needed to transition to sustained service, consistent with applicable data-rights and proprietary information protections.

Verification and Validation compliance will be approved by NASA. The Offeror must describe its verification philosophy, including the planned use of analysis, test, inspection, demonstration, heritage data, ground testing, and on-orbit validation. The Offeror must identify how verification limitations, deviations, waivers, or residual verification risks will be documented and submitted for NASA review and approval prior to demonstration execution. The specific requirement areas are summarized in the following subsections. Detailed functional requirements, performance thresholds, and technical parameters are defined in Attachment A.2.

Requirement Driver Information: Offerors must propose solutions that meet all stated SRD requirements, which are intended to preserve backward compatibility with current TDRS users. Offerors may identify any SRD requirements that materially affect feasibility, schedule, technical complexity, risk, or pricing, and may provide the requirement number and title, Offeror interpretation, assumptions, supporting rationale, quantified impact, and any proposed alternative value, approach, or implementation concept.

Submission of proposed alternatives or requirement impact information does not revise, waive, relax, or trade any SRD requirement or any other solicitation term, condition, evaluation criterion, schedule milestone, or fixed requirement. NASA may use this information to understand requirement drivers, affordability, technical and schedule risk, and solution maturity. Offerors should also identify any aspects of the proposed capability that exceed requirements or provide additional operational value.

3.1 General Coverage and Service

The NEXUS System must provide Ka-band communication services across all designated coverage regions between supported customer vehicles and the Ground Service Interface, preserving TDRS-equivalent capabilities without requiring modifications to legacy customer vehicle onboard systems. The system must deliver bidirectional Forward Services from the Ground Service Interface to the customer vehicle and Return Services from the customer vehicle to the Ground Service Interface, with sufficient RF bandwidth to support mission data delivery, telemetry, command and control, and operational continuity.

For purposes of this SOO, the Ground Service Interface means the Ka-band Forward/Return Link ground demarcation point between the NEXUS system and the customer mission system.

Approved customer interface equipment will be installed at the NEXUS Offeror’s designated ground entry point, data center, or other NASA-approved NEXUS ground interface location. The customer must connect to this equipment and provide the communications path from the Ground Service Interface to the customer control center or mission operations center.

The Offeror-provided NEXUS system includes all systems, satellites, ground infrastructure, network elements, scheduling functions, and operational capabilities required to plan, schedule, and move Ka-band data in a bent-pipe fashion between the customer vehicle and the Ground Service Interface.

The graphic below depicts the full NEXUS system in the light blue box and the customer interface boundary in the green box. The purple dashed lines represent the NEXUS demarcation interfaces with the customer vehicle and the Ground Service Interface.

Figure 1. High-level Definition of the NEXUS System

The full service NEXUS architecture must support at least 8 concurrently operational, paired Forward and Return links across the full service volume, with regional coverage requirements distributed across Region A (longitude range of +/-180° to -60° ), Region B (longitude range of -60° to +60°), and Region C (longitude range of +60° to +/-180°), all maintaining minimum relay line-of-sight elevation angles ≥10 degrees toward Zenith for compatibility with legacy customer vehicle antenna pointing limits.

Figure 2. NEXUS Coverage Regions

The full service volume includes all longitudes, all latitudes between +/- 75 deg and altitudes from 0 km to 900 km.

Figure 3. 2-D Slice of Service Volume Latitude and Altitude

During the on-orbit demonstration phase, the Offeror must demonstrate an operationally viable relay service using a representative implementation of its proposed sustained-service architecture.

The demonstration must prove that the proposed system can operate as an end-to-end service, not merely as an isolated space segment test. NASA will coordinate access to designated legacy customer vehicles and provide available mission interface information needed to support demonstration planning; the Offeror remains responsible for planning, integrating, executing, and validating the end-to-end demonstration service. The demonstration is not required to provide full operational service but must demonstrate a representative and scalable increment of the Offeror’s proposed sustained-service architecture.

The on-orbit demonstration must include a minimum 30-calendar-day on-orbit performance measurement period using the proposed backward-compatible Ka-band relay capability. The performance measurement period must begin after NASA provides Authority to Connect (ATC) for a designated Government user or users to connect to the demonstrated NEXUS service. The on-orbit demonstration must, at a minimum, demonstrate the following:

End-to-end service execution. The demonstration must execute the full-service thread from scheduling through service delivery, including forward and return data relay between the customer vehicle and the Ground Service Interface, with performance meeting applicable thresholds. This includes the space, ground, network, scheduling, monitoring, and operational interfaces necessary to validate the applicable demonstration requirements and provide relay service to the user.

Backward-compatible service to legacy TDRS Ka-band users. The demonstration must show that the proposed service can support heritage TDRS Ka-band users without requiring modification to customer vehicle onboard systems, consistent with Attachment A.2.

Simultaneous user support, including CONUS. The demonstration must provide simultaneous forward and return paired links for at least two customer vehicles. At least one demonstrated service thread must support a NASA-designated legacy customer vehicle operating within the Region A / CONUS service case.

Operational traceability to sustained service. The demonstration must operate within the Offeror’s proposed full-service architecture, concept of operations, ground/network design, scheduling approach, and mission integration framework in a manner that demonstrates a credible path to sustained service.

Assured mission delivery. The demonstration must provide evidence that the proposed service can reliably support Government mission needs when required, including service availability, scheduling responsiveness, operational prioritization, anomaly response, and continuity of service.

Representative service volume validation. The demonstration must deploy enough assets to service at least 20 percent of the full-service volume at any given time, assuming the user could be at 0 km or up to 900 km altitude. The Offeror must propose the specific number, type, and orbital placement of demonstration assets used to achieve the 20 percent service volume demonstration. NASA will evaluate the realism of the approach, including the Offeror’s architecture, performance model, operations concept, and scalability to the full-service architecture.

Schedule traceability to sustained service. The demonstration must provide evidence that the proposed architecture, deployment approach, launch strategy, ground/network integration, operations concept, and supply chain can support incremental sustained service availability beginning in 2029 and progression toward full-service capability by mid-2031.

Additional capabilities listed below are not minimum requirements but may be considered by NASA as evidence of maturity, scalability, or operational relevance.

Additional service volume coverage above 20 percent at any given time Multiple operational handovers Additional simultaneous forward and return paired links Demonstration of additional service threads, users, regions, or operational scenarios beyond the minimum required demonstration

Attachment A.2 includes requirements intended to preserve backward compatibility with heritage TDRS Ka-band users, particularly within the space-to-space forward and return service requirements.

3.2 Ka-band Forward Service

The NEXUS System must provide Ka-band Forward Services within the designated frequency range in compliance with National Telecommunications and Information Administration (NTIA) and International Telecommunication Union (ITU) spectrum allocations, while meeting stringent signal quality parameters essential for maintaining backward compatibility with heritage TDRS users. Collectively, the requirements on these parameters preserve forward service compatibility through signal integrity, interface integrity, end-to-end link characteristics, and overall performance consistent with heritage TDRS operations, ensuring that existing mission link budgets and customer vehicle systems remain valid without requiring modifications to legacy architectures.

Some of the key parameters required to preserve backward compatibility include:

Frequency Range Phase nonlinearity Gain Flatness Gain Compression AM/PM Conversion Factor Spurious Phase Modulation (PM) Spurious Outputs Incidental Amplitude Modulation

(AM)

Polarization

Axial Ratio Effective Isotropic Radiated Power

(EIRP)

Latency Digitizer Sampling Rate Digitizer Quantization Allowable Degradation Waveform Agnostic digital

Intermediate Frequency (IF)

3.3 Ka-band Return Service

The NEXUS System must provide Ka-band Return Services within the designated frequency range in compliance with NTIA and ITU spectrum allocations, while meeting stringent signal quality parameters essential for maintaining backward compatibility with heritage TDRS users.

Collectively, the requirements on these parameters preserve signal integrity, interface integrity, end-to-end link characteristics, and overall performance consistent with heritage TDRS operations, ensuring that existing mission link budgets and customer vehicle systems remain valid without requiring modifications to legacy architectures.

Some of the key parameters required to preserve backward compatibility include:

Frequency Range Phase nonlinearity Gain Flatness Gain Compression AM/PM Conversion Factor Input Signal Level Waveform Agnostic digital

Intermediate Frequency (IF) Gain-to-Noise-Temperature ratio

(G/T)

Polarization Axial Ratio Received Power Variation (P_rec

Variation) EIRP Tolerance Latency Digitizer Sampling Rate Digitizer Quantization Allowable Degradation

3.4 Security and Privacy

Securing NASA data and commands, and the integrity of the overall system/service is mandatory.

The NEXUS System must implement comprehensive cybersecurity, information assurance, cryptographic, and cloud security controls across the entire service architecture, encompassing space (including the spacecraft), ground, network, and cloud elements, including all prime contractor, subcontractors, service providers, hosted payload providers, ground segment operators, and third-party entity components. This must include facility protections and access controls necessary to protect the integrity of the overall system/service. The Offeror must complete the following activities and provide NASA with the artifacts called out in this section to enable NASA to determine the adequacy and acceptability of the Offeror’s security control implementation. The security and privacy activities required include:

Security Architecture Disclosure (CASQ) All Offerors must complete the Commercial Architecture Security Questionnaire (CASQ) to ensure alignment with federal cybersecurity requirements.

Control Baseline and Evidence The Offeror must provide evidence of cybersecurity control implementation satisfying High-impact requirements for availability and integrity consistent with FIPS 199 categorization. The Offeror must implement and maintain information security controls in accordance with NIST SP 800-53 (current revision) consistent with FISMA and applicable NASA policy.

The system and associated services must meet:

High impact level controls for Integrity and Availability Moderate impact level controls for Confidentiality

The Offeror must implement all required management, operational, and technical safeguards consistent with the applicable control baseline. The Offeror must demonstrate compliance using recognized commercial or Government cybersecurity frameworks, certifications, third-party assessments, or corporate security programs, including but not limited to CMMC, ISO/IEC 27001, FedRAMP, or equivalent, provided that:

1. The Offeror submits a documented control mapping demonstrating alignment to the required NIST SP 800-53 control baseline and impact levels specified in this contract.

2. Any gaps between the alternative framework and the required NIST baseline are identified and remediated.

3. NASA SCaN retains final authority to determine adequacy and acceptance of the control implementation.

Use of alternative frameworks does not relieve the Offeror of responsibility for meeting the required NIST SP 800-53 control requirements. Evidence and/or artifacts generated from other cybersecurity frameworks including corporate best practice can be used to satisfy these requirements.

Assessments and Remediation Prior to initial authorization, any gaps between existing cybersecurity frameworks and identified requirements must be remediated and/or addressed. Independent assessments by a certified 3rd party must be accepted against the above requirements or SCaN can offer a certified assessor.

After initial authorization, the Offeror must conduct and provide:

An independent third-party cybersecurity assessment at least every three (3) years An annual internal cybersecurity assessment briefing

For both assessments, the Offeror must provide:

Remediation plans for all Critical and High vulnerability findings, including repeat findings Status reports on remediation progress for NASA review

Cryptography The Offeror must implement cryptography compliant with CNSA 2.0 requirements, where applicable, including readiness for Post-Quantum Cryptography algorithms such as ML-KEM and ML-DSA. The Offeror should include plans for implementing defenses against AI driven threats and enforcing strict patch management. The Offeror must describe its approach to key management and crypto-agility sufficient to support timely algorithm updates and transitions as standards evolve.

Privacy The system must restrict access for all external interfaces to only authorized mission/customer vehicle users of scheduled services, preventing unauthorized access to signals and data containing potentially sensitive information.

Applicability and NASA Authority All cybersecurity, information assurance, cryptographic, and cloud security requirements specified herein apply to the prime contractor, all subcontractors, service providers, hosted payload providers, ground segment operators, and any other third-party entities involved in delivering the NEXUS relay service.

The Offeror remains responsible for end-to-end compliance across the service architecture. NASA retains final authority to determine the adequacy and acceptance of the Offeror’s security control implementations. The Offeror must support NASA’s security review processes and obtain an Authority to Connect (ATC) prior to establishing operational connectivity with NASA mission networks or interfaces. There may be multiple points prior to the demonstration where ATC is required to facilitate secure connection with NASA networks. However, for the on-orbit demonstration, ATC also serves as the NASA control point authorizing a designated Government user to connect to the demonstrated NEXUS service for purposes of beginning the on-orbit performance measurement period.

3.5 Scheduling and Controlling

The NEXUS System must receive, validate, and execute service schedule requests through authorized customer interfaces associated with the Ground Service Interface, creating conflict-free schedules consistent with NASA-provided priority lists to enable schedule-driven operations with minimal operator interaction.

The system must provide role-based access control for all external interfaces used for scheduling, configuring, monitoring, and controlling services, ensuring only properly authorized accounts can create, view, or modify services while maintaining confidentiality by providing customers with schedule and service information pertaining only to their authorized vehicles and operations.

The system must support real-time modification of service parameters including frequency assignment, bandwidth allocation, polarization, and power level without loss of lock or service disruption to active links, preserving operational flexibility and compatibility with TDRS heritage operations.

The system must execute new or modified scheduled services within 5 minutes of validated request receipt, receive and process customer-provided state vectors or Two Line Element (TLE) sets to properly configure relay satellite antenna pointing for signal acquisition and service event execution, and generate relay satellite ephemeris data at sufficient accuracy and cadence to support customer vehicle orbit determination, pointing prediction, acquisition scheduling, and link planning activities.

3.6 External Interfaces

The NEXUS System must provide secure external interfaces at the Ground Service Interface point for service status information including received signal strength, transmit RF output level, attenuation, service availability, antenna pointing parameters, polarization, link state, and other pertinent real-time operational information.

The NEXUS System must provide both a web-based Graphical User Interface (GUI) and an Application Programming Interface (API) to access service scheduling, configuration, monitoring, and control functions. These interfaces must support customer integration through the Ground Service Interface and enable customers to integrate NEXUS relay services with their mission software and operational environments.

3.7 Additional Performance and Operations

The NEXUS System must meet specified Ka-band signal acquisition and tracking performance under customer vehicle flight dynamics conditions. The system must provide Ka-band services with relay satellite antenna boresight pointing accuracy sufficient to ensure reliable space-to-space link performance, preserve link margin, maintain stable acquisition and tracking based on TLE or state vector data, and prevent relay-induced degradation of service availability across all supported regions without imposing additional antenna pointing constraints on customer vehicles.

The system must support customer vehicle operational constraints related to minimum continuous service event durations with a given relay satellite for particular customer vehicle altitudes.

The system must coordinate and perform dynamic space operations and maneuvering, including relay satellite collision avoidance maneuvers based on received conjunction assessment data, to execute critical time-sensitive maneuvers and avoid collisions with satellites and debris. The system must also provide onboard proximity sensors capable of continuously monitoring the orbital environment and providing autonomous, real-time detection and alerting of close approach.

3.8 Testing Interfaces

The NEXUS System must provide secure testing interfaces to support (1) comprehensive Radio Frequency (RF) compatibility testing with customer vehicle communication systems, (2) ground interface testing at the Ground Service Interface, including connectivity with customer control centers mission operations centers and mission data systems, and (3) Integrated System End-to- End testing. These testing interfaces must ensure that all NEXUS ground and relay assets can operate together with customer systems to meet vehicle support and service requirements, prior to on-orbit deployment of the NEXUS demonstration.

Prior to System End-to-End testing, the Offeror must perform successful RF compatibility testing between a flight-equivalent/representative NEXUS RF System and a flight-equivalent/representative NASA RF system.

After successful RF compatibility testing, the Offeror must perform successful End-to-End testing between a flight equivalent/representative NEXUS System and a flight equivalent/representative NASA system, including all applicable ground-based components and interfaces.

Any Government resources required to support testing must be handled in accordance with the Solicitation and applicable Government-resource approval processes.

4. CONSTRAINTS AND INTERFACES

The proposed solution must operate within the following constraints:

4.1 Spectrum and Regulatory Compliance

NASA will be responsible for securing the appropriate spectrum authorization for the Ka-band forward and return space-to-space links. Such authorization will be obtained through the National Telecommunications and Information Administration (NTIA) in accordance with applicable federal spectrum management regulations and procedures. NASA will also be responsible for filing the Ka-band forward and return links with the International Telecommunication Union (ITU).

The Offeror must be responsible for securing the appropriate spectrum authorizations from the Federal Communications Commission (FCC), or other applicable regulatory entities, as well as associated ITU filings, for all other aspects of the overall system. This responsibility includes, but is not limited to: telemetry, tracking, and command (TT&C); space-to-ground forward/return links; all payload communications not related to the NEXUS Ka-band forward and return links;

launch service activities; orbital debris compliance; and any approvals or regulatory requirements necessary for the placement and operation of supporting ground infrastructure.

The NEXUS Ka-band space-to-space relay spectrum is reserved for authorized Government mission use and is not available for non-Government commercial communications services.

Offerors may propose other commercial services only where separately authorized and non-interfering with NEXUS requirements.

4.2 Infrastructure and Routing Constraints

To ensure security and regulatory compliance, the NEXUS System, including all ground assets/components/stations/terminals, network/system operations centers, network lines, and supporting infrastructure must be prohibited from being located within or traversing through all countries (including all subgroups) listed in Country Group D per Supplement No. 1 to part 740 of the EAR. Reference link: eCFR :: Supplement No. 1 to Part 740, Title 15 -- Country Groups

4.3 Transition Alignment

The demonstrated service architecture must provide a credible and traceable path to sustained commercial service without requiring fundamental redesign. The Offeror must demonstrate that its proposed space, ground, network, scheduling, operations, and mission integration approach can scale from the demonstration configuration to full operational service. Demonstration data must include, as applicable, measured link performance, service availability, scheduling responsiveness, contact duration, handover performance, anomaly response, interface performance, operational staffing assumptions, cost drivers, scalability assumptions, and deltas required to transition from demonstration to full service. Full operational service must support eight concurrent paired forward and return links across three regions and sustain operations for a minimum 15-year service life. The demonstrated service must provide NASA with confidence that the proposed architecture can support assured mission delivery for Government users, including reliable availability, operational prioritization, and continuity of service under sustained operational conditions.

4.4 Other Hosted Payloads

Other hosted payloads are permitted and encouraged; however, such payloads must not degrade, interfere with, constrain, delay, or otherwise adversely affect the NEXUS relay service or the Offeror’s ability to meet NEXUS performance, availability, cybersecurity, schedule, operational, or service continuity requirements. Spacecraft commodities can be shared with hosted payloads, but hosted payload anomalies, failures, operating modes, resource demands, mission requirements, or associated ground/user interfaces must not propagate to or impact the NEXUS relay service, operations, or availability.

The Offeror’s cybersecurity plan must address all hosted payloads, associated ground systems, users, interfaces, data paths, and operations, and must describe specific measures to prevent them from introducing cyber vulnerabilities to the NEXUS relay service.

The NEXUS relay service must have priority over any non-NEXUS hosted payload for all spacecraft resources, operations, scheduling, command authority, fault recovery, anomaly response, and any other capability required toserve NEXUS users. NASA will provide a NEXUS relay service user priority list. Hosted payload operations must not conflict with, supersede, or reduce NEXUS priority, performance, availability, or continuity.

The Offeror must identify any proposed hosted payloads and describe their interfaces, resource allocations and limits, operating modes, operational constraints, cybersecurity protections, fault isolation approach, and verification approach. Proposed hosted payloads must be identified as part of the proposal or as soon as practicable after award, as applicable, to allow NASA review and approval without adversely affecting the NEXUS demonstration schedule, integration, cybersecurity, or service performance.

Proposed hosted payloads are subject to NASA review and approval to ensure they do not adversely affect NEXUS performance, availability, cybersecurity, schedule, operations, mission assurance, service continuity, or compliance with applicable law, regulation, or contract requirements.

5. DEMONSTRATION SUCCESS CRITERIA

The demonstration will be considered successful when the Offeror has:

Verified compliance with all applicable performance requirements in Attachment A.2 through delivered and approved verification data.

Validated system function and performance through on-orbit execution and ground infrastructure.

Completed a minimum 30-calendar-day on-orbit performance measurement period after ATC and provided sufficient data, performance results, and operational evidence for NASA to evaluate the applicable demonstration success criteria and applicable SRD thresholds.

Demonstrated viability of the relay services while operating on-orbit through successful execution of end-to-end concurrent forward and return relay services between the customer vehicle and the Ground Service Interface.

Successfully supported heritage TDRS customer vehicle communications without requiring customer vehicle modifications, proving backward compatibility.

Reduced technical and integration risks to enable confident transition to sustained service.

Produced measurable performance, availability, operational, schedule, cost, user-integration, and service-assurance data to inform future sustained-service planning.

Complete documentation of all demonstration results with all anomalies resolved or properly dispositioned.

NASA may determine the demonstration successful once the applicable SOO objectives, SRD requirements, and approved demonstration success criteria have been met, including completion of the minimum 30-calendar-day on-orbit performance measurement period after ATC and delivery of the Demonstration Performance Validation Package, and the Offeror has provided sufficient evidence to support NASA’s assessment of technical, operational, schedule, user-integration, and programmatic readiness for potential transition to sustained service.

6. TRANSITION TO SUSTAINED SERVICES

This acquisition is structured as a phased approach:

1. Demonstration (This solicitation): The Offeror must demonstrate an operationally viable relay service using a representative implementation of its proposed sustained-service architecture. The demonstration must validate critical system functions, prove backward compatibility with heritage TDRS Ka-band users, and demonstrate operational readiness across the required space, ground, network, scheduling, user, and Ground Service Interface elements.

The demonstration phase is intended to validate capability, reduce risk, and inform NASA’s future sustained-service acquisition strategy. Full constellation fielding and sustained operational service are expected to occur under a future service contract, not under this BAA.

The demonstration must support participating NASA customer vehicles, including at least one NASA-designated legacy customer vehicle operating within the Region A / CONUS service case.

NASA will coordinate access to legacy customer vehicles and provide mission interface information needed to support demonstration planning. The Offeror remains responsible for planning, integrating, executing, and validating the end-to-end demonstration service. The demonstration configuration must represent an initial or partial increment of the proposed sustained-service architecture, and demonstrate a credible path to the required sustained-service capability.

2. Commercially Provided Relay Services (Follow-on activity): Upon successful completion of demonstration objectives, NASA intends to conduct a follow-on competitive acquisition for full operational services. The operational services contract must provide communications services across all three Regions (A, B, & C) with a minimum of 8 concurrent paired links serving the full population of supported Government customer vehicles over a 15-year operational service life.

The Offeror's demonstration performance, including technical capability, operational reliability, backward compatibility validation, cost-effectiveness, and user mission support, must inform NASA's requirements definition and acquisition strategy for the full operational services contract.

NASA’s future sustained service strategy will be informed by the extent to which the demonstrated capability provides confidence in assured mission delivery, operational continuity, service availability, scalability, affordability, and the ability to support Government users when mission need demands. NASA’s planning objective is to enable incremental sustained service availability beginning in 2029 and to build toward full operational service capability by mid-2031. The demonstration should therefore provide NASA with confidence that the Offeror’s approach can scale from the demonstrated configuration to sustained service on a schedule aligned with that objective.

7. GOVERNMENT INSIGHT AND DIGITAL COLLABORATION ENVIRONMENT

The Contractor must propose an approach for Government engagement that provides NASA appropriate insight into program execution, technical progress, risk management, integration status, verification status, demonstration readiness, anomaly resolution, and operational readiness.

The approach must support informed Government decision-making while respecting the Contractor’s role as the provider, integrator, and operator of the proposed NEXUS capability.

The Contractor must provide NASA read-only access to a secure digital collaboration environment, or equivalent digital collaboration method, where practical and consistent with the Contractor’s internal management and security processes. The purpose of this environment is to support Government insight into program execution and demonstration readiness without requiring Government direction of the Contractor’s internal design, management, or business operations.

The environment should include, as applicable, program performance dashboards, milestone evidence packages and supporting data, interface and integration artifacts, version-controlled schedule updates, readiness evidence, risk and issue tracking information, verification and validation status, anomaly and corrective-action status, and service performance metrics once available.

The Contractor’s approach should identify key touchpoints, reviews, technical interchange meetings, data access points, milestone gates, test events, readiness assessments, and decision points where NASA engagement is proposed. The approach should demonstrate how NASA will have timely access to the information necessary to assess project health, demonstration readiness, service assurance, and transition risk while allowing the Contractor to execute efficiently and meet the NEXUS schedule objectives.

Attachment List:

Attachment A.2 Service Requirements Document (SRD)