RFI Earth-Proximity Space-Relay Communication and Navigation Services.pdf

NASA Request for Information (RFI) Earth-Proximity Space-Relay Communication and Navigation Services: Commercial Capabilities, User Perspectives, and Support for SCaN’s Transition from TDRS.

Section 1. Introduction

The National Aeronautics and Space Administration (NASA) is seeking information from U.S. and international commercial providers on current and planned space-based relay communication and navigation capabilities to support NASA missions in the Earth Proximity region. NASA is particularly interested in innovative, scalable, and cost-effective commercial SATCOM solutions that can enable robust support for science, technology, and human spaceflight operations.

This Request for Information (RFI) is issued by NASA’s Space Communications and Navigation (SCaN) Program, which is focused on transitioning toward a commercially driven architecture for space communications and navigation services. As NASA looks to retire aging government-owned infrastructure, such as the Tracking and Data Relay Satellite (TDRS) system, the agency aims to leverage commercial capabilities to ensure sustained, resilient, and flexible support for its evolving mission needs. This RFI aligns with NASA’s broader objective to foster commercialization and stimulate private sector investment in the Earth Proximity region.

As part of this RFI, NASA is seeking supplemental information including:

• User perspectives on use cases, performance expectations, and plans to adopt commercial space-relay services (Appendix A)

• Industry capability to offer limited Tracking and Data Relay Satellite (TDRS)-backward compatible services (Appendix B)

Section 2. RFI Overview

2.1 Background

NASA missions, operating in the Near Space region within Earth proximity (i.e., below 36,000 km), need to be able to determine the state of the spacecraft, command the spacecraft to execute the NASA mission or resolve anomalous conditions, and retrieve or download science mission data collected by the spacecraft instruments.

For more than 40 years, these services were provided by the Tracking and Data Relay Satellite system, a NASA-owned and operated satellite relay communications system. Currently, TDRS is still a valuable communications platform; however, its fundamental architecture remained consistent for over 40 years. The TDRS constellation is projected to support missions until the 2030s. However, as of November 2024, the NASA Agency Program Management Council (APMC) has suspended new mission commitments to TDRS.

The National Space Policy and the U.S. Government directed NASA to obtain commercial satellite services as one of many customers, purchasing “data as a service” rather than owning and operating a TDRS replacement. By purchasing commercial services rather than deploying new infrastructure for NASA missions, the SCaN program can focus critical funds and resources on solving technical challenges for future exploration and improving progress for new mission science objectives.

To obtain this data delivery service, NASA established the Communications Services Project (CSP) to transition future near-Earth missions from Government-owned, contractor-operated (GOCO) communications services to a catalog of reliable, robust, cost-effective, and commercially available satellite communications services. Thus far, CSP has identified NASA’s satellite communication relay needs (phase 1) and partnered with industry to demonstrate end-to-end commercial services that may meet future NASA mission needs (phase 2). This RFI marks the beginning of phase 3 of the CSP, working towards a future competitive procurement of commercial satellite communication relay services from multiple providers to supply NASA near-Earth missions with communication capabilities. NASA intends to release an RFP in 2027 and expects to begin validating services in 2028. NASA is targeting operational services no later than the end of 2031. NASA is considering limited backward compatible services in a narrow timeframe, e.g. 2030- 2035, to ensure existing missions are supported as TDRS declines.

2.2 Required Services

CSP categorizes NASA mission needs into two service types based on the need for pre-coordination, Direct and File Access services. These two service types are provisioned based on timeliness of the service via Nominal and Critical Access. The service types are defined as:

• Direct Access Service – a forward and return communications service that does not require pre-coordination of spacecraft subsystems to initiate. Direct Access Services typically support lower data rates and data volumes (e.g., Telemetry & Command services) but are not limited to this use case.

This type of service can also be used to establish contact with a spacecraft without the use of another communications service (no intermediary steps beyond providing ephemeris and scheduling the service if needed).

• File Delivery Service – a forward and return communications service that requires pre-coordination of spacecraft subsystems to initiate. File Delivery Services typically support higher data rates and data volumes. This type of service cannot establish contact with a spacecraft without the use of an alternate service to initiate contact at some point during operations (e.g., commanding of spacecraft subsystems to point antenna).

Figure 2.2.1: Service Types: Direct Access Service (Left) and File Delivery Service (Right)

The service types are further categorized by how they are provisioned – both who has control of the service and the timeliness:

• Nominal Provisioning – a service that supports routine operations. Such as support to user mission activities including command uplink, telemetry, and mission data downlinks. The NASA customer may request a service of this type, and the service provider decides when that service is available.

• Critical Provisioning – communications and navigation services that must always provide reliable and secure services without degradation of performance. Any function or group of functions is deemed mission critical if its failure will result in a situation whereby the user spacecraft cannot be recovered.

Critical services support a timeframe that poses a risk to mission success if not always delivered reliably and securely during mission critical phases. These services may be planned or unplanned but require service providers to deliver a service in a timely manner. The NASA customer decides the timeframe in which the service is needed. Critical communications services support missions that have low risk tolerance.

CSP Critical Services include routine, contingency, and emergency services depending on the need for timeliness of the communications. From a Commercial Services perspective, the provider handles the three subcategories the same way, treating each as a critical service, where NASA determines when the service is needed. Each service type supports the mission lifecycle. Service provisioning characteristics and relationships to example use cases for service types is summarized in Table 2.2.1.

Table 2.2.1: NASA Mission Lifecycle Phases and Corresponding Service Types

Missions will typically use a variety of services provisioned in different ways across their lifecycle, as shown in Figure 2.2.2. A potential provider does not have to supply all service types; missions may use different services from different providers.

Figure 2.2.2: NASA Mission Lifecycle Phases and Corresponding Service Types

Current and future NASA missions fall into a wide breadth of categories, from Science to Human Space Flight (HSF), with corresponding service support requirements during distinct mission phases. This RFI is can be openly shared with the mission community, enabling NASA and industry to move closer towards operational status.

Below are summaries of high priority capabilities and corresponding details necessary for determining potential support to NASA missions. Provide details regarding your current or planned space-relay capabilities that will be available by FY31, including:

3.1 Space-Relay Architecture

NASA missions require services throughout the entirety of the Earth proximity region, from launch vehicle operations to GEO. Provide details regarding the space relay constellation and corresponding service regions, including:

1. Support Volume:

o Orbital Altitude range: Launch vehicles (0 km to orbit insertion) and satellites (LEO, MEO, GEO, and high-altitude orbits) o Inclination Range o Latitude Range o Describe the degree of resiliency or overlapping coverage inherent in the architecture.

2. Constellation: Satellite altitude/position, number of satellites, etc.

3. General description of supporting ground infrastructure.

4. Timeline:

o Constellation and service volume status by FY31.

o Phased launch and upkeep approach post-FY31.

Table 3.1.1: Space-Relay Architecture Overview Category Parameter Parameter Options/Range/Unit

Support Volume

Orbital Altitude Range km Inclination Range Degrees

Latitude Range Degrees south latitude / Degrees north latitude

Constellation

LEO/MEO/GEO LEO/MEO/GEO

Number of Satellites #

Satellite Positions Orbital Shell Keplerian Elements, Lat/Lon for GEO constellations, etc.

3.2. Space-Relay Communications (Forward and Return) Capabilities

The primary services required by NASA missions are communication support, including spacecraft commanding, telemetry downlink, and high data rate file delivery capabilities. Provide information regarding space-relay communication services, including:

1. Frequency Bands: L-Band, S-band, Ku-band, Ka-band, Optical, or others.

2. Performance Characteristics: Data rate/throughput, data latency, schedule/service latency, number of concurrent users, etc.

3. Signal Parameters: Channel bandwidth, data rates, G/T, EIRP, etc.

4. Quality of Service (QoS) Metrics: Bit error rate (BER), packet error rate (PER), jitter, latency, etc.

5. Technical advantages over existing TDRS constellation capabilities.

6. Anomaly Resolution Support:

o During contingency or emergency Critical Services: required time to respond to service requests and coordinate directly with operations personnel to ensure mission assurance.

o On-console support for Critical services, including engineering and help-desk support.

7. Describe what availability and reliability mean in the context of your service and how they are calculated.

Table 3.2.1: Communication Services Parameters Category Parameter Parameter Options/Range/Unit

General Communication Support Y/N Simultaneous Forward and Return Support Y/N Schedule/Service Latency s

Forward

Frequency Range MHz EIRP dBW Max Channel Bandwidth MHz Symbol/Data Rates (Min to Max) Msps/Mbps Bit Error Rate (BER) Errors/# transmitted bits

Single or Multi Access? Single or Multiple (max # concurrent users)

Availability 0.0 - 1.0 Reliability 0.0 - 1.0

Return

Frequency Range MHz G/T dB/K Bent Pipe or Regenerative? Bent Pipe or Regenerative Max Channel Bandwidth MHz Symbol/Data Rates (Min to Max) Msps/Mbps Bit Error Rate (BER) Errors/# transmitted bits

Single or Multi Access? Single or Multiple (max # concurrent users)

Acquisition Time s Latency s Availability 0.0 - 1.0 Reliability 0.0 - 1.0

3.3 Space-Based Position, Navigation, and Time Dissemination (PNT) Capabilities

Future NASA missions will require navigation services such as PN Ranging, 1/2-way doppler, antenna angle measurements, or time transfer capabilities that deliver state determination products such as definitive ephemeris, predictive ephemeris, range, range rate, Doppler, time, etc. If applicable, provide information regarding any PNT services offered by the space-relay network:

1. Cooperative Tracking Capabilities: PN ranging, 1-way or 2-way Doppler, Antenna Angle measurements, time transfer, etc.

o Tracking Overview: Methodology, frequency band, number of concurrent users.

o Measurement Performance: Accuracy, precision, rate, and latency for tracking satellites in different orbital regimes (LEO, MEO, GEO).

2. Non-Cooperative Tracking Capabilities: Radar, optical, etc.

o Tracking Overview: Methodology, frequency band, number of concurrent users.

o Measurement Performance: Accuracy, precision, rate, and latency for tracking satellites in different orbital regimes (LEO, MEO, GEO).

3. Integrated crosslink communication and tracking/navigation capabilities, such as doppler measurements extracted directly from the communication channel, simultaneous communication and navigation support on separate channels, etc.

4. Orbit determination and state vector estimation capabilities.

5. Overall PNT capability maturity assessment:

o Describe the general maturity of PNT technology and services.

o Maturity and availability of user equipment to support PNT capabilities.

o Existing or prior customer relationships related to PNT services.

o Relevant demonstration results or benchmarks if applicable.

Table 3.3.1: Tracking and Navigation Services Parameters Category Parameter Parameter Options/Range/Unit

Position, Navigation and Timing

Support Y/N Simultaneous Communication and Navigation Support Y/N

Cooperative Tracking Capabilities PN Ranging, 1-way or 2-way Doppler, Antenna Angle Data, etc.

Cooperative Tracking Frequency Ranges MHz Non-Cooperative Tracking Capabilities Radar, Optical, etc.

Range Measurement Accuracy m Velocity Measurement Accuracy m/s Time Transfer Accuracy s Latency s

3.4 Compatible Spacecraft Terminals

NASA anticipates commercial providers will include compatible terminals as part of the overall service offering. If applicable, provide information regarding off-the-shelf, space qualified communication terminals certified to operate on the network:

1. General Details:

o Types of terminals for different mission classes (such as flagship, CubeSat, etc.) or orbital locations (launch vehicle, LEO, MEO, etc.).

o Terminal reliability, lifetime, etc.

o Terminal manufacturer(s)

2. System Overview: Technology Readiness Level (TRL), components, in-flight software update capabilities, etc.

3. Physical Link Parameters: EIRP, G/T, data rates, etc.

4. Size, Weight, and Power (SWaP) details.

5. System Interfaces and Interface Control Documentation: RF, power, data, etc.

6. Acquisition Details:

o Cost model, such as part of the overall service price, as a separate monthly/annual rental fee, a single upfront price, etc.

o Lead time.

7. Integration Support: Compatibility testing process/plans, support during flight integration, etc.

8. Interoperability: Compatibility with alternative service providers, existing NASA assets, etc.

If terminals are not currently available, how do you plan to offer them, and on what timeline?

Table 3.4.1: Spacecraft Terminal Parameters Category Parameter Parameter Options/Range/Unit

Terminals

Technology Readiness Level (TRL) 1 to 9 Components Transceiver, Antenna, Amplifier, etc.

EIRP dBW G/T dB/K Channel Bandwidth MHz Symbol/Data Rates (Min to Max) Msps/Mbps Volume cm3 Mass kg Baseline Power Draw W Tx Only Power Draw W Rx Only Power Draw W Tx/Rx Combined Power Draw W Availability of Interface Control Documents RF, Electrical, Data, etc.

Cost $ Lead Time Months or Years

3.5 Launch Vehicle Support Services

Portions of the NASA and national security launch vehicle (LV) community have come to rely on TDRS communications and tracking during launch. In the future, these needs need to be met by alternative commercial capabilities. In the interest of facilitating future business to business relationships, NASA requests information on industry capability related to launch vehicle TT&C support as follows:

1. Support for launch vehicle specific service offerings, including short duration (multi-hour) but high reliability communications coverage from the launch pad through to LEO, MEO, or GEO orbit insertion.

2. Architecture application to launch vehicle service expectations:

o Frequency bands leveraged.

o Orbital infrastructure characteristics.

o Characterization of performance delivered to LV use case.

3. Commitment: Service reliability or commitments available for launch vehicle support.

4. Service Scheduling: Maximum time prior to launch that support can be scheduled (in months or years).

5. Schedule Slips: Architecture and customer service approach to accommodating last-minute launch schedule delays.

6. Network Health: Details available to users regarding the health of the network and services to help customers make go/no-go decisions for launch.

o Types of information provided and timeliness/refresh rate of the information.

7. Latency: Network path and latency for delivering real-time telemetry to LV operation centers.

8. Support Locations: Global support or limited to specific geographic areas/launch sites.

9. Cybersecurity: Any launch vehicle specific network or communication security details.

10. Transition: Approach to minimize impact to existing systems as they transition from TDRS to the offered services.

11. Terminals: Launch vehicle specific terminals.

3.6 Interoperability, Security, and Standards Compliance

NASA programs and missions currently adhere to a series of international and federal standards, including both communication standards and cybersecurity requirements. With the transition to commercial services, NASA requests information on potential service network’s interoperability, security, and standards compliance, including:

1. Spectrum Licensing: FCC/ITU spectrum licensing status, legal spectrum usage approach, etc.

o Identify spectrum resources or regulatory authorizations currently held that would support the proposed Earth-based space relay services, o Identify any spectrum access needs, licensing requirements, concerns with associated services utilizing authorized spectrum, or potential risks that would need to be addressed.

o Describe coordination plans, international considerations (if applicable), and any support you would anticipate requiring.

2. Current industry standards utilized.

3. Potential interoperability with NASA’s current and future communication and tracking systems.

4. Any standards, requirements, or compliance items that represent a challenge to delivering services to future NASA missions.

5. Cybersecurity:

o Security approach, including encryption, authentication, and anti-jamming protocols to ensure secure and tamper-resistant support for classified missions.

o Security approach consistency with Federal Information Security Modernization (FISMA) Act of 2014 and NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations Revision 5, or related issues/challenges.

o Demonstrations and/or representation/certification for how the electronic information and IT resources will be protected from unauthorized modification, disclosure, or destruction.

o Cloud Storage Security: FEDRAMP service status and storage location (inside or outside of continental US).

o Approach for protection of command, control and telemetry systems, and protection against communications jamming and spoofing.

3.7 Service Model, Business Considerations, and Cost Structure

To understand potential acquisition of services and integration of future NASA missions into a potential commercial network, NASA request details on the industry approach, including:

• Business Status:

o Number of simultaneous missions that can be supported.

o Outside NASA business case and future user/revenue projections.

o Current and future partners, contract status, etc.

• Business Strategy:

o Approach for achieving sustainable operations and growth for the proposed services, such as expected customers or markets beyond NASA.

o Approach to managing business risk and identification of factors that will influence commercial success.

o Describe additional capabilities, assets, or business arrangements that could be used to de-risk the deployment and operation of the proposed services. Provide examples and discuss the potential benefits to mission success, schedule assurance, or cost efficiency.

• Business Model: Subscription-based, per-use pricing, fixed contracts, etc.

o Preferred Cost Model: $/minute, $/GB, $/pass, $/month, $/mission, volume purchase discounts, etc.

Rationale for preferred cost model.

Sample Service Level Agreement if available.

Cost for non-data services such as mission planning, integration, etc.

• Any potential differences between cost models between NASA and other commercial customers.

Mission Planning Support:

o Products (user guide, ICD, etc.) to support the development lifecycle of a mission.

When identifying proprietary information as part of the RFI response, please consider enabling information to be shared with the NASA mission community or released publicly.

o Direct assistance to support mission analysis and impact trades throughout the mission planning phase, such as feasibility analysis, link analysis, and resource loading based on mission profile.

o Fault Tolerance Approach: Single point failure modes, dual string capabilities, etc.

o If offered, how is mission planning support costed? Is it part of service pricing or billed separately?

• Integration Timeline:

o Timeline for pre-launch compatibility testing, in-flight integration, etc.

o Describe any service products to support design/development, integration, and test prior to operational service.

• Operations Support:

o Description of approach to data delivery to/from users.

o Ability to report interference, provide notification conditions affecting services, and providing QoS metrics during and post events.

o Ability to detect, quantify, and mitigate signal interference.

o Capability to support end-to-end threat assessments with NASA.

o Contingency/emergency support.

• Service Prioritization:

o Approach for prioritizing requests between different users.

o Prioritization details/information conveyed to service users.

o How does prioritization impact pricing?

• System backwards compatibility with future service versions.

o Timespan over which service will be compatible after deployment.

o Capability to support missions that extend beyond nominal user terminal certifications, such as 10+ year lifetimes.

• Ground Interface:

o Cloud Services.

o Non-cloud-based connections.

o API interfaces (or ICD):

Service schedule including availability periods.

Resource booking requests and confirmations.

Service configuration profiles and/or parameters.

Service outage notifications.

Voice communications.

Asset and/or service status.

Service status.

Table 3.7.1: Business Model Parameters Category Parameter Parameter Options/Range/Unit

Business Model

Scheduling Process Human-in-the-loop, Machine 2 Machine API, etc.

Cost $/s, $/GB, volume purchase discounts, etc.

FCC License Status

Representative End-to-End Data Flow

Quality of Service (QOS) Metrics BER, PER, Latency, etc.

Service Prioritization

Testing and Integration Timeline Months or Years

3.8 Capability Validation Process

NASA has developed a validation process to onboard and establish potential commercial networks as eligible and certified service providers. The qualification process consists of nine Capability Validation Milestones (CVM), as outlined in Table 3.8.1. To ensure an efficient onboarding process for commercial relay services, NASA requests information on the CVM process, including:

• Cost: Anticipated cost for your organization to complete the entire capability validation process.

o If possible, break down the estimate to a cost per milestone basis.

• Timeline: Anticipated timeline to complete the capability validation process.

• Contents:

o Ability to meet the proposed descriptions of each individual milestone, including delivering the defined artifacts, documentation, and/or test data.

If possible, identify any existing or planned data products your organization would baseline to complete each milestone.

• Validation Process Feedback:

o Concerns regarding process order or milestone titles, descriptions, and/or requested artifacts.

o Recommendations for adjustments to the validation process.

Table 3.8.1: Validation Activities Milestone Milestone Title Proposed Milestone Description

SIR

Service Integration Review

Government-led review to assess contractor's technical and procedural plans to execute the Validation Task Order (VTO) milestone.

CVM 01 Service Concept Generically describes how the NASA missions will access, use, and monitor the commercial relay service.

CVM 02 Service Requirements

Details the services intended to be offered to NASA on a provider-by-provider basis.

CVM 03 Service Design Details the maturity of the commercially provided space-to-space communications services being offered, with supporting material.

CVM 04

Service Integration

Describes how NASA missions will integrate their spacecraft bus with the service provided communications terminal, Mission Operations Center (MOC), and Science Operations Center (SOC) interfaces.

CVM 05 Service Test Conducts testing, if not previously performed, and provides test results confirming that the proposed commercially provided communications services are sufficiently mature to enter verification testing.

CVM 06 Service Verification

Demonstrate with artifacts or test results the service performance meets or exceed the service requirements, including physical and functional interfaces.

CVM 07 Service Validation

Assess provider artifacts documenting the full up, end-to-end service, utilizing on-orbit missions and service provided elements, confirming operational readiness for space users, including anomaly resolution and administrative aspects.

ORR

Operational Readiness Review

Government-led review to assess the readiness of the proposed commercially provided communications service to transition to mission operations.

Section 4: Information for Participants

This RFI is issued solely for planning purposes and does not constitute a solicitation. In accordance with Federal Acquisition Regulation (FAR) 15.201(e), responses to this RFI are not considered offers and cannot be accepted by NASA to form a binding contract. NASA is under no obligation to issue a solicitation or award a contract based on this RFI. However, the information received may inform future acquisition strategies.

Respondents are encouraged to provide information that is not subject to limited or restricted data rights. If proprietary or restricted data is included, it must be clearly marked to ensure proper identification and protection. Respondents are responsible for all costs associated with their submissions. NASA intends to review all responses and may reach out for further discussions if needed.

Please note that NASA, along with its support contractors and subcontractors, may review submitted information. Responses will not be returned, and respondents will not receive feedback on the review results.

NASA does not intend to award a contract or provide compensation based on this RFI. Participation is entirely voluntary and will not impact eligibility for future solicitations.

At this time, no solicitation exists. Do not request a copy of a solicitation. If one is issued in the future, it will be announced on the Government Point of Entry website (www.sam.gov). It is the responsibility of potential respondents to monitor this site for any updates or releases.

Section 5: Instructions for Submission

5.1 RFI Response

Submission Requirements for Industry Respondents:

• A maximum of 4 total files may be submitted in response to Section 3 and Appendix B: a one-page summary, the written responses to section 3, an Excel or CSV with associated data, and a written response to Appendix B if applicable. The one-page summary should include: company name, address, primary point of contact and telephone number, company’s government size classification, and a brief description of the company’s capabilities relevant to the RFI requirements.

• The page limitation for the written responses to Sections 3 and Appendix B is 10 pages each. At the front of each of these files, please ensure company or entity name and business and technical POCs are included.

Submission Requirements for User Stakeholders:

• A single file should be submitted for user stakeholders responding to Appendix A. The page limitation is 5 pages, and the entity name and POC should be indicated.

Submission Notes for All Parties:

• For the written responses, submit an electronic response as searchable, unlocked PDF files with editing permissions enabled.

• Use 12-point Times New Roman font, single-spaced text, and standard formatting.

Responses must be submitted via email to: hunter.c.butkovic@nasa.gov

Table 5.1.1: Summary of Submission Requirements RFI Response Document Page Limit Format Notes One-Page Summary Document 1 page PDF

Required as part of industry response.

Response to Section 3 10 pages PDF

Required as part of industry response.

NA Excel / CSV Required -- corresponds to tabular data requests in Section 3.

Response to Appendix B (as applicable) 10 pages PDF

Industry response optional.

Response to Appendix A (as applicable) 5 pages PDF

For user stakeholder community members to respond.

5.2 General Information

• Agency: National Aeronautics and Space Administration (NASA)

• Announcement Title: Commercial Space-Relay Communication and Navigation Services

• Announcement Number: 80GRC025R7020RFI

• Response Due Date: 11 July 2025

Point of Contact:

• Contracting Officer: Hunter Butkovic

• Email: hunter.c.butkovic@nasa.gov

RFI Questions

Questions regarding this RFI should be submitted via email to hunter.c.butkovic@nasa.gov with the subject line:

• "Commercial Space-Relay Communication and Navigation Services – [Company Name]"

• NASA will respond to questions individually via email. Questions and answers will not be made public.

Questions should be submitted by close of business on 13 June 2025.

Appendix A: User Stakeholder Perspectives

As NASA prepares for the acquisition of commercial relay services, input from the user stakeholders including science, human space flight, launch vehicle, and Commercial LEO Destinations communities, is being requested as follows:

• Needs and use cases: describe your current or projected needs for space-relay services and the contextual use cases that you would like to see satisfied by commercial providers. For example:

o Types of services – data delivery, commanding, telemetry downlink.

o Communications capabilities – data rates, volumes, frequency bands.

o Position, navigation and timing capabilities.

o In what timeframe would operational services need to be ready?

o Cadence of service needs – how much and when?

• Expectations for performance and support: for the desired use cases, are there performance goals or support features that are desired, such as:

o Availability, reliability, time to restore service etc.

o Prioritization of use o Anomaly response o Service interfaces for scheduling, customer support, data delivery, etc.

• Familiarity and contact with commercial providers: if applicable, describe any interactions that have occurred with commercial service providers:

o Names of providers you have spoken to.

o Degree to which you believe providers can meet your needs and use cases.

o Needs you believe industry is not yet capable of providing.

• Preparing for commercial service use:

o Describe any concerns you have about adopting commercial services.

o Are there further actions you believe NASA should take to support your team’s ability adoption of commercial services in the future?

o Are there questions you believe should be asked of potential providers in any future RFIs?

Appendix B: Additional Requested Information – Backwards Compatible Services

In addition to the information described in the main body of the RFI, NASA is also considering how industry might address providing a limited set of services for a select few existing missions that are currently reliant on TDRS and do not have the capability to transition to alternate commercial services. NASA is interested in understanding if commercial service providers can augment or replace TDRS services for a finite duration to support these missions. Response to Appendix B is not mandatory.

If applicable, please provide details regarding backwards compatibility with existing TDRS services defined in tables B.1.1-B.1.3, including:

• Communication Services:

o Services to be provided via a “bent pipe” or RF transponder with no onboard signal processing.

o Both low and high data rate services are expected. Low latency forward and return services are required for both data rate use cases.

o Forward: S-Band, Ka-Band, Ku-Band.

o Return: S-Band, Ka-Band, Ku-Band.

• Navigation Services:

o S-Band: PN Ranging, 1-way (non-coherent) or 2-way (coherent) doppler, Antenna Angle Data.

• Information/details from NASA necessary to evaluate ability to support existing TDRS user base.

Identify any proposed modifications to the U.S. Table of Frequency Allocations that would facilitate expanded commercial use of these services. Describe any current regulatory constraints and indicate preferences regarding service allocation status, such as primary or secondary allocation, or inclusion through a U.S. footnote to support commercial viability in the relevant frequency bands.

Table B.1.1: TDRS Backward Compatible Forward Service Parameters Parameters S-Band

Demand Access S-Band Ku-Band Ka-Band

Space-to-Space Freq. Bands

2106.4 MHz 2025.8-2117.9

MHz

13.775 GHz 22.55-23.55 GHz

Minimum set of Space-to-Space Polarization

LHCP Only LHCP or RHCP Dual polarization, selectable for each contact.

LHCP or RHCP Dual polarization, selectable for each contact.

LHCP or RHCP Dual polarization, selectable for each contact.

Data Rates Up to 300 kbps Up to 7 Mbps 25 Mbps 25 Mbps Channel Bandwidth

6 MHz (if needed)

20 MHz 50 MHz 50 MHz

Reference EIRP for a GEO-based relay (1)

42 dBW Up to 46.3 dBW 46.5 dBW Support autotrack and program track

63.0 dBW Support autotrack and program track

Note 1: EIRP values are based on current TDRS capabilities at GEO. Respondents should provide feedback and calculations for other architectures of consideration (e.g., different orbits, payload capabilities, etc.)

Table B.1.2: TDRS Backward Compatible Return Service Parameters Parameters S-Band Demand

Access System S-Band Ku-Band (1) Ka-Band (1)

Space-to-Space Freq. Bands

2287.5 MHz 2200-2300 MHz 15.0034 GHz 25.25-27.5 GHz

Minimum set of Space-to- Space Polarization

LHCP Only LHCP or RHCP Dual polarization, selectable for each contact.

LHCP or RHCP Dual polarization, selectable for each contact.

LHCP or RHCP Dual polarization, selectable for each contact.

Historical Data Rates

Up to 3 Mbps Up to 6 Mbps 600 Mbps 1,200 Mbps

Channel Bandwidth

6 MHz (if necessary)

10 MHz 240 MHz 650 MHz

Reference G/T for a GEO-based relay (2)

3.1 dB/K 9.5 dB/K (minimum), up to

12.5 dB/K

24.4 dB/K Support autotrack and program track

26.5 dB/K Support autotrack and program track

Note 1: Other considerations - responders should describe any potential developments and capabilities in high bandwidth spot beam technology.

Note 2: G/T values are based on current TDRS capabilities at GEO. Respondents should provide feedback and calculations for other architectures of consideration (e.g., different orbits, payload capabilities, etc.)

Table B.1.3: TDRS Tracking/Navigation Service Parameters

Parameter Value

Types of cooperative tracking PN Ranging 1-way or 2-way Doppler Antenna Angle Data

Cooperative tracking frequencies 2200-2300 MHz and/or 2025.8-2117.9 MHz

Types of non-cooperative tracking Radar

Range Accuracy Random (1 σ) - 2.73 meters Systematic - ≤ 7.7 m

Doppler Accuracy 1 way ≤ 3.1 mm/s, 1 σ 2 way ≤ 1.55 mm/s, 1 σ

Additional information requested:

• General: The respondent should describe any additional capabilities, assets, or business arrangements you possess that could enhance or de-risk the deployment and operation of the proposed space relay services. This may include, but is not limited to, in-house launch capabilities, hosted payload opportunities, existing infrastructure, or operational partnerships. Please provide relevant examples and describe how these factors would benefit mission success, schedule assurance, or cost efficiency.

• Scheduling & Data Distribution Schema: The use cases of interest include both low and high data rate services with low data latency (e.g., near real-time data dissemination / no store-and-forward) requirements for all cases. The respondent should define scheduling mechanism and data distribution strategy (space to space and space to ground), including data assurance and information security strategies and mitigations.

• Coverage Capabilities: Users would be interested global coverage from ground (for testing) to LEO to Artemis lunar return (e.g., 30,000 km). Coverage for higher latitude/polar orbits is of interest.

o The respondent should provide max altitude that can be supported.

o The respondent is encouraged to discuss alternative capabilities, relay architectures, and vehicles or payload strategies to achieve service.

o The respondent should discuss satellite pointing constraints in different orbital regimes.

o The respondent should discuss tracking services including but not limited to P/N spreading modes for S-Band.

o The respondent should describe capabilities to provide extended elliptical field of view

(EEFOV)-like use case support (e.g., current TDRSS EEFOV is 76.8 deg E-W outboard in

GEO).

o The respondent should describe availability schema and proficiency of packet delivery (e.g., current TDRS capability is 99.7% operational availability).

o The respondent should discuss RF interference mitigation strategies.

• PNT Capabilities: Please provide information on how your capability enables time dissemination, positioning, and/or navigation (PNT) services. Specifically address:

o The maturity of your PNT technology (e.g., technology readiness level, operational experience).

o Existing or prior customer relationships related to PNT services.

o Maturity and availability of user equipment.

o Relevant performance data, demonstration results, or benchmarks.

• Implementation Schedule & Service Availability: Respondents should discuss their nominal schedule to field a system in orbit from Authorization to Proceed (ATP) to operational availability.

Respondents should discuss their high-level strategy to sustain an operational capability along with mission life. Respondents should discuss the nominal system capability to support multiple simultaneous users, primarily focusing on high-rate data service users:

o 1 user dedicated o 2 users simultaneously o 4 users simultaneously o 8 users simultaneously o 16 users simultaneously

• System Implementation & Utilization Costs: Respondents should discuss Rough Order of Magnitude (ROM) costs from ATP to launch, as well as costs for using services (e.g., SLA).

• Informing Future NASA Guidance: NASA understands there may be challenges associated with delivery of services using government spectrum bands and the business feasibility given the limited the number of users. NASA is interested in creative solutions to provide these limited legacy services, including (but not limited to) hosting government-owned-and-operated payloads, government-owned-contractor-operated payloads, distributed spacecraft architectures, etc. Please identify areas where further NASA guidance or dialogue would enable industry to better evaluate and plan for a potential future acquisition, and methods by which industry would prefer to receive such information.