A_NEXUS TDRS-BC Statement of Objectives (SOO)_20260408.pdf

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 commercial relay services.

2. DEMONSTRATION MISSION OBJECTIVES

The objectives and outcomes of this demonstration phase are critical to validating a viable solution for long-term commercial relay services supporting NASA and other legacy government missions.

The key objectives for the NEXUS demonstration include:

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

• Demonstrate an operationally viable relay capability that functions as a service by providing no fewer than two concurrent paired forward and return links, with one paired link providing coverage for Region A (CONUS) and the second paired link providing coverage for another region proposed by the Provider. NASA desires persistent coverage in the proposed demonstration regions to the maximum extent practicable, consistent with the Provider’s proposed architecture.

• Verification of requirements and Validation of performance, coverage, concurrency, and operational execution through on-orbit demonstration.

• Generate sufficient technical, operational, and cost data to inform a follow-on competitive sustained services acquisition.

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

3. REQUIRED PERFORMANCE OUTCOMES

The provider shall demonstrate compliance with functional and performance outcomes sufficient to validate backward-compatible relay service capability. Specific functional and performance requirements necessary to support a potential service are provided in Attachment B – NEXUS Service Requirements Document (SRD). The provider will provide verification evidence against each of these requirements, and through an on-orbit demonstration, provide validation of capability that is applicable and scalable to a full backward-compatible Ka-band service.

Verification and Validation compliance will be approved by NASA. The specific requirement areas are summarized in the following subsections. Detailed functional requirements, performance thresholds, and technical parameters are defined in Attachment B.

Providers shall propose solutions that meet all stated requirements. The Ka-band operating frequency, RF bandwidth, and bent-pipe relay architecture are fixed requirements needed to preserve compatibility with heritage systems and are not open to trade. For other requirements, Providers may identify any that materially affect the feasibility, schedule, technical complexity, or pricing of the proposed solution and may describe associated trade considerations for NASA’s consideration, including identification of any requirements that are significant cost or schedule drivers. Providers should also identify any aspects of their proposed capability that exceed threshold requirements.

3.1 General Coverage and Service

The NEXUS System will provide continuous, global Ka-band communication services between customer control centers and supported vehicles, preserving TDRS-equivalent capabilities across all designated coverage regions. The system will deliver bidirectional Forward Services (control center to vehicle) and Return Services (vehicle to control center) with sufficient RF bandwidth to ensure mission data delivery, telemetry, command and control, and operational continuity without requiring modifications to legacy customer vehicle onboard systems. The NEXUS system to be provided by the vendor is comprised of all systems/satellites/ground infrastructure required to move Ka-band data back and forth (forward and return) in a bent-pipe fashion between the customer vehicle and the customer control center/system. The graphic below depicts the full NEXUS system in the light blue box and the interface boundary with the customer in the green box.

The purple dashed lines represent the Demarcation Interfaces to the customer vehicle and the customer control centers.

Figure 1. High-level Definition of the NEXUS System

The full service NEXUS architecture will support 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 for compatibility with legacy customer vehicle antenna pointing limits. The service volume includes all latitudes between +/- 75 deg and altitudes from 0 km to 1,500 km.

Figure 2. NEXUS Coverage Regions

During the demonstration phase, the system shall provide no fewer than two concurrent paired forward and return links. One paired link shall provide coverage for Region A (CONUS), and the second paired link shall provide coverage for another region proposed by the Provider. The Provider shall identify that region and describe how demonstration in that region could accelerate capability maturation and service transition. NASA desires persistent coverage in the proposed demonstration regions to the maximum extent practicable, consistent with the Provider’s proposed architecture.

All proposed services, including both the demonstration service and the full service architecture, shall be backward compatible with heritage TDRS Ka-band users and shall not require modifications to customer vehicle onboard systems. Attachment B includes requirements intended to ensure that backward compatibility is maintained, particularly within the space-to-space forward and return service requirements.

Recognizing that multiple constellation and orbit designs may be proposed for full service, the Provider shall describe the demonstration architecture needed to validate its proposed service architecture for a representative customer vehicle in the proposed region. The demonstration shall generate sufficient data to validate the design and support assessment of its scalability to a full service architecture capable of continuous global coverage.

3.2 Ka-band Forward Service

The NEXUS System will provide Ka-band Forward Services within the designated frequency range in compliance with National Transportation 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

• Carrier-to-Noise Ratio

• Effective Isotropic Radiated Power

(EIRP)

• Latency

• Digitizer Sampling Rate

• Digitizer Quantization

• Allowable Degradation

3.3 Ka-band Return Service

The NEXUS System will 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

• Prec 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 will implement comprehensive cybersecurity, information assurance, cryptographic, and cloud security controls across the entire service architecture, encompassing space, ground, network, and cloud elements, including all prime contractor, subcontractor, service provider, hosted payload provider, ground segment operator, and third-party entity components.

The provider will be required to 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 provider’s security control implementation. The security and privacy activities required include:

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

Control Baseline and Evidence The provider will provide evidence of cybersecurity control implementation satisfying High-impact requirements for availability and integrity consistent with FIPS 199 categorization. The provider shall 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 shall meet:

• High impact level controls for Integrity and Availability

• Moderate impact level controls for Confidentiality

The provider shall implement all required management, operational, and technical safeguards consistent with the applicable control baseline. The provider may demonstrate compliance using recognized industry cybersecurity frameworks or certifications (e.g., CMMC, ISO/IEC 27001, FedRAMP, or equivalent), provided that:

1. The provider 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 provider 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 will be remediated and/or addressed. Independent assessments by a certified 3rd party will be accepted against the above requirements or SCaN can offer a certified assessor.

After initial authorization, the provider will 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 provider will provide:

• Remediation plans for all Critical and High findings, including repeat findings

• Status reports on remediation progress for NASA review

Cryptography The provider will 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 provider will 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 shall apply to the prime contractor, all subcontractors, service providers, hosted payload providers, ground segment operators, and any other third-party entities involved in delivering NEXUS services.

The provider remains responsible for end-to-end compliance across the service architecture. NASA retains final authority to determine the adequacy and acceptance of the provider’s security control implementations. The provider will support NASA’s security review processes and obtain an Authority to Connect (ATC) prior to establishing operational connectivity with NASA mission networks or interfaces.

3.5 Scheduling and Controlling

The NEXUS System will receive, validate, and execute service schedule requests from customer control centers, creating conflict-free schedules consistent with NASA-provided priority lists to enable schedule-driven operations with minimal operator interaction.

The system will 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 will 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 will execute new or modified scheduled services within minutes of validated request receipt, receive and process customer-provided state vectors or Two Line Element sets to properly configure relay satellite antenna pointing for signal acquisition and service event execution, and generate relay satellite ephemeris data at sufficient cadence to support customer vehicle orbit determination, pointing prediction, and link planning activities.

3.6 External Interfaces

The NEXUS System will provide secure external interfaces to customer Mission Operations Centers (MOCs) and mission data systems 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 will provide both web-based and Application Programming Interface (API) access for service scheduling, configuration, monitoring, and control functions, enabling customers to integrate NEXUS services with their unique mission software and operational environments. The provider will also offer a “help line” that any user can call for immediate help if relay issues arise.

3.7 Additional Performance and Operations

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

The relay satellite antenna must provide slew rates and accelerations sufficient to support rapid repointing between customer vehicles for time-critical acquisition and handover scenarios.

The system will 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 will also provide onboard proximity sensors capable of continuously monitoring the orbital environment and providing real-time detection and alerting of close-approach.

3.8 Testing Interfaces

The NEXUS System will provide secure testing interfaces to support comprehensive Radio Frequency (RF) compatibility testing with customer vehicle communication systems and ground interface testing with customer control centers and mission data systems, ensuring 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, the provider will perform successful RF compatibility testing between a flight equivalent/representative NEXUS system and a flight equivalent/representative NASA system.

4. CONSTRAINTS AND INTERFACES

The proposed solution shall operate within the following constraints:

4.1 Spectrum and Regulatory Compliance

NASA shall 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 Provider shall 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.

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 will be prohibited from being located within or traversing through all countries 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 architecture shall be scalable and commercially supportable without fundamental redesign for sustained services. The system design must support transition from demonstration operations consisting of no fewer than two concurrent paired forward and return links, with one paired link covering Region A (CONUS) and a second paired link covering another provider-proposed region, to full operational services consisting of eight concurrent paired forward and return links across three regions, and sustain operations for a minimum 15-year service life.

5. DEMONSTRATION SUCCESS CRITERIA

The demonstration shall be considered successful when the provider has:

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

• Validated system function and performance through on-orbit execution.

• Demonstrated viability of the relay services while operating on-orbit

• 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 full service.

• Produced sufficient performance, availability, operational, schedule, and cost data to inform sustained services acquisition.

Successful demonstration shall be declared once these objectives have been met along with demonstrated capability to support sustained service both technically and programmatically.

6. TRANSITION TO SUSTAINED SERVICES

This acquisition is structured as a phased approach:

1. Demonstration (This solicitation): The provider shall rapidly establish a demonstration capability that validates critical system functions, proves backward compatibility with heritage users, and demonstrates operational readiness. The demonstration phase will include operational services to support participating NASA customer vehicles with no fewer than two concurrent paired forward and return links, with one paired link providing coverage for Region A (CONUS) and the second paired link providing coverage for another region proposed by the Provider. NASA desires https://www.ecfr.gov/current/title-15/subtitle-B/chapter-VII/subchapter-C/part-740/appendix-Supplement%20No.%201%20to%20Part%20740 persistent coverage in the proposed demonstration regions to the maximum extent practicable, consistent with the Provider’s proposed architecture.

2. Commercial 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 will provide continuous 24/7/365 communications services across all three Regions (A, B, & C) with a minimum of 8 concurrent paired links serving the full population of NASA customer vehicles over a 15-year operational service life.

The provider's demonstration performance, including technical capability, operational reliability, backward compatibility validation, cost-effectiveness, and customer satisfaction, will inform NASA's requirements definition and acquisition strategy for the full operational services contract.

Successful demonstration performance does not guarantee award of the follow-on operational services contract.

Attachment List:

Attachment B - NEXUS Service Requirements Document (SRD) Filename: NEXUS_SRD_CUI-ITAR