LCRNS SRD 10-18-2022.pdf

ii

ESC-LCRNS-REQ-0090

Lunar Communication Relay and Navigation Systems (LCRNS) Lunar Relay Services Requirements

Document (SRD)

Prepared by:

Signature on File 10/18/22

Nick Speciale Date Systems Engineer, LCRNS

NASA GSFC

Concurred by:

Signature on File

10/18/22 Signature on File

10/18/22

Laurie Mann Date Justin Long Date PNT System, LCRNS Comm System, LCRNS

NASA GSFC NASA GSFC

Signature on File

10/18/22 Signature on File

10/18/22

Jonathan Verville Date Benjamin Anderson Date ITC System, LCRNS DTN System, LCRNS

Signature on File

10/18/22

Nidhin Babu Date Ryan Archer Date Deputy PM Security Lead

Sanjeev Sharma Date

SMA, LCRNS

NASA GSFC

Approved by:

Jaime Esper ` Date Project Manager, LCRNS

NASA GSFC

iii

Preface

This is the NASA LCRNS Lunar Relay Service Requirements Document.

This document is controlled by the LCRNS Project Configuration Control Board (CCB).

This document will be updated by Documentation Change Notice (DCN) or complete revision.

An uncontrolled copy of this document may be downloaded from the NASA LCRNS Web Page at: Lunar Communications Relay and Navigation Systems | ESC Public Site (nasa.gov) vi

Table of Contents

Section 1. Introduction

1.1 Threshold Relay Capabilities by Increment (IOC)

1.2 Document Conventions, Definitions, and Notations

1.2.1 Coverage

1.2.2 Availability

1.2.2.1 Operational Service Availability

1.2.3 Service Volume

1.2.4 Service Provider Latency

1.2.5 Nominal Services

1.2.6 Critical Services

1.2.7 Data Services

1.2.8 PNT Terminology (AFS/Point-to-Point/LANS)

1.2.8.1 Point-to-Point (P2P)

1.2.8.2 Augmented Forward Signal (AFS)

1.2.8.3 Lunar Augmented Navigation Service (LANS)

1.2.9 Configuration Control

Section 2. Documentation

2.1 Applicable Documents

2.2 Reference Documents

Section 3. Lunar Relay Service Requirements

3.1 Lunar Relay Service Functional Requirements

3.2 Service Performance Requirements

3.2.1 Communications Requirements

3.2.2 Space Internetworking Data Service Requirements

3.2.3 Position, Navigation, and Timing (PNT) Services

3.2.4 Lunar Search and Rescue (LunarSAR) Services

3.2.5 Lunar Relay Service On-orbit Validation Capabilities

3.2.6 Lunar Relay Cybersecurity

Appendix A. Effectivity and Compliance

Appendix B. User Mission Specific Information and Timeline Reference

B.1 User- Level Assumptions

B.2 Communications and Data Services Characteristics

B.3 PNT System Characteristics

B.4 User Timelines vii

B.5 Reference Trajectories for Descent and Ascent

Appendix C. LunaNet Interoperability Compliance Matrix

Appendix D. Glossary and Acronym List viii

List of Figures

Figure 1-1 Service Volume I (SV1)

Figure 1-2 Service Volume II (SV2)

Figure 1-3 Service Volume III (SV3)

Figure 1-4 LCRNS PNT Services

Figure B-1 Reference Trajectory for HLS Landing

Figure B-2 Reference Trajectory for HLS Departure

List of Tables

Table 1-1 Artemis IOC Increment Capabilities

Table 2-1 Applicable Documents

Table 2-2 Reference Documents

Table 3-1 Operational Service Availability (IOC Increments)

Table 3-2 Operational Service Availability (EOC Increment)

Table 3-3 Minimum Constellation Sizing Requirements

Table 3-4 Lunar Relay Frequency Band Requirements

Table 3-5 LunaNet Proximity Signal Service Requirements

Table 3-6 Reference User System Performance and Data Rate Requirements

Table 3-7 Artemis Data Volume Service Requirements

Table 3-8 Aggregate Artemis Data Rate Service Requirements

Table 3-9 Aggregate Artemis Data Volume Service Requirements

Table 3-10 Representative User Scenario PNT Performance Requirements

Table 3-11 Lunar Relay PNT Reference Signal Source SISE Requirements

Table 3-12 Lunar Relay PNT Coherent Measurement MISE Requirements

Table A-1 Effectivity and Compliance Matrix

Table B-1 IOC-A Mission Estimated Support

Table B-2 IOC-B Mission Estimated Support

Table B-3 IOC-C Mission Estimated Support

Table B-4 Non-Crewed Artemis Mission Estimated Support

Table C-1 LCRNS SRD/LNIS Interoperability Specification Compliance Matrix for IOC 51

Section 1. Introduction

The NASA Lunar Communications Relay and Navigation Systems (LCRNS) Project has defined a set of requirements for Lunar Orbiting Relay Services by LunaNet Service Providers (LNSP) to support Artemis missions and assets (Human Landing System, Orion, Lunar Terrain Vehicle, Pressurize Rover, Extravehicular Activities, etc.), NASA payloads utilizing the Commercial Lunar Payload Services (CLPS) program, and other NASA science and technology missions in the lunar regime. The service is expected to initially include a few relays in lunar orbit matched to service provider ground stations in what is referred to as the Initial Operating Capability (IOC), covering the 2025 through 2028 timeframe. The IOC capability will be gradually built and validated over three increments during this timeframe, with full operational IOC capability in place by 2028. A more complex network will grow to meet expanding needs during the Enhanced Operating Capability (EOC), starting in 2030 (TBR) and beyond.

This LCRNS Services Requirements Document (SRD) covers LNSP communication and navigation services from users in the lunar proximity to a predefined NASA Near Space Network (NSN) interface point on Earth, and from Earth (via NSN interface point) to lunar users via space links. In addition, it covers services to lunar users communicating and navigating within the lunar proximity independent of Earth. Key interface performance requirements to lunar vehicles (i.e., HLS, LTV, CLPS, etc.) are included in this document. Relay service providers ground stations interface to the NSN network are included in ESC-NSN-ICD-0143.

The companion and applicable LunaNet Interoperability Specification, LNIS V.4 (ESC-LCRNS-SPEC-0015) provides a specific set of Interoperability Specifications (Appendix C) that must be met by all LNSP. It is expected this document will evolve as exploration and science element designs and concepts of operation mature.

1.1 Threshold Relay Capabilities by Increment (IOC)

IOC capabilities form the set of threshold requirements that shall be met by a LNSP. EOC capabilities can be implemented initially but are not part of the threshold set. Other NASA documentation may refer to the IOC capability as “sortie,” and the EOC capability as “Artemis Base Camp (ABC).”

IOC will be validated in three increments, based on Agency needs. Table 1-1 shows the capabilities needed for each mission and IOC increment assigned (A- Alpha, B-Bravo, and C-Charlie). Appendix A contains a SRD requirements effectivity spreadsheet based on mission capabilities needed per IOC increment for verification/validation. An effectivity listed as IOC means the requirement is applicable to all IOC increments.

A requirement is preceded by a shall. This document follows the formatting style of the document template defined by the SCaN Program Configuration Management Office. In some cases, the values of quantities included in this document are not certain and are designated as to be reviewed (TBR), to be determined (TBD), or to be supplied (TBS). Where approximate values of such quantities are known and provide useful guides for development, these are shown along with the TBR notation. Where no value is yet known, a TBD is included. Where a value is known but has not been supplied to the SRD book manager, a TBS is included.

1.2.1 Coverage

A service covers a particular volume of space if the system can close the link with a specified number of users in that volume. That assumes knowledge of user receiver performance, how many users must be serviced simultaneously, and how long is the service expected to last. Coverage to be measured over one earth month.

1.2.2 Availability

Availability is a subordinate of coverage, in the sense that no service can be made available if coverage does not exist. Availability in this document is defined as follow:

Availability = (Texpected - Tdown)/Texpected Where: Texpected is the time that a service is expected to be operational to meet coverage requirements and Tdown is the time that the service is not operational.

Examples of down time include software deliveries, engineering changes, system failures, system maintenance, slew times, and internal tests not requested by customer missions. The amount of time considered in the availability calculation shall be the time customers are prevented from scheduling the service averaged over one earth month.

1.2.2.1 Operational Service Availability

For a service provider availability is measured between the point when a relay receives the user signal to the NSN designated interface point. This is the only link path the service provider controls. For end-to-end availability the NSN interface and/or terrestrial communications systems will need to be added and is not covered in this SRD.

1.2.3 Service Volume

Service volume identifies the minimum space volume where coverage, as defined in this document, shall be met. There are three service volumes identified in this document.

Service Volume I (SV1): Includes lunar surface areas below -80 degrees south latitude and up to an altitude of 125 kilometers. Rationale: The intent of SV1 is to support initial services to surface missions and users in low lunar orbit or in transit to/from the surface, when within the service volume.

Figure 1-1 Service Volume I (SV1)

Service Volume II (SV2): Includes lunar surface areas below -75 degrees south latitude and up to an altitude of 200 kilometers. Rationale: The intent of SV2 is to support surface missions as well as users in low lunar orbit or in transit to/from the surface.

Figure 1-2 Service Volume II (SV2)

Service Volume III (SV3): Includes lunar surface areas for all latitudes and altitudes up to a minimum of 200 kilometers for full global coverage of the moon. Rationale:

The intent of SV3 is to provide global coverage to remove mission placement constraints, supporting surface missions as well as users in low lunar orbit or in transit to/from the surface.

Figure 1-3 Service Volume III (SV3)

1.2.4 Service Provider Latency

Service Provider Latency is defined as the amount of time (measured in seconds) between a signal leaving a mission User transmitter antenna to the time it is delivered to the NSN interface or to the satellite mission’s data processing system/control center, whichever is specified in the Mission Data Workbook. For purposes of this document, latency is measured only to the NSN interface.

1.2.5 Nominal Services

Normal Services cover typical and regular mission User activities such as telemetry, voice, video, and command and science/payload data.

1.2.6 Critical Services

Critical Services include communication 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. Examples of Critical Services include Launch, early orbit ops, human spaceflight, descent, crewed lunar surface operations, and spacecraft contingency. Critical services encompass both Contingency and Emergency activities. Contingency activities will occur when the user mission platform experiences a failure or degradation in function or performance that affects normal data collection, or otherwise compromises the health and safety of the system. Anomalies could be sudden, discrete events, such as the failure of a critical component, or could be a gradual degradation in performance detected by engineering trending that permits action prior to the occurrence of a mission-threatening situation. Contingency Services include all the activities performed during Normal Services, plus additional items such as configuration management, and other troubleshooting services as needed.

Emergency activities are a response to an unexpected anomaly that if not responded to in a timely manner would result in loss of mission, or in the case of Humans Spaceflight activities, Loss of life. Emergency service requests will be coordinated by the NSN Project directly with the LNSP to receive immediate communications services to prevent loss of their user mission platform, enable safing, restore normal operations, and preserve life.

1.2.7 Data Services

Data services or operations is defined as the network routing and processing of information associated with both real-time and store-and-forward (i.e., delay/disruption tolerant networking) capabilities between a user in lunar space and the NSN demarcation point (and vice versa). It differs from the simple "communications" reference which is traditionally employed generically.

1.2.8 PNT Terminology (AFS/Point-to-Point/LANS)

PNT services enable missions to determine position, velocity, surface location, plan trajectories, execute maneuvers, and maintain accurate time in a timeliness sufficient to meet mission requirements. PNT services can be offered via a combination of standardized signals for Doppler, ranging, timing, and standard messages and protocols for the exchange of measurements and products. These are needed for safety, situational awareness, communication, and mission and science objectives.

To offer these services and provide interoperability, the intent is to take maximum advantage of the communications links through judicious signal structure definitions. This can be accomplished in several ways. One method is to provide PNT through dedicated Point-to-Point (P2P) communications links with a user.

However, there is a need for lunar-global provisioning of PNT services to provide adequate geometry and appropriate time-to-first-fix to meet user requirements.

Thus, a second method using an Augmented Forward Signal (AFS) provides PNT functionality independent of dedicated user communications links to enable multiple user reception of the signal simultaneously. Through the build-up of LCRNS nodes, this will establish a Lunar Augmented Navigation System (LANS).

Figure 1-4 diagrams these PNT service options.

1.2.8.1 Point-to-Point (P2P)

These services are expected to be provided by scheduled direct links between the user and the provider. A point-to-point link can provide a reference signal for PNT observables with the associated messages. Alternatively, a signal that is not inherently designed to offer PNT observables may still be employed to transmit messages that support PNT.

1.2.8.2 Augmented Forward Signal (AFS)

The AFS is a special case instantiation of the reference signals structured to present the user with the ability to measure pseudorange, Doppler, and Time Transfer coupled with relevant information in messages. The compatible LCRNS nodes will transmit the AFS, as described in ESC-LCRNS-SPEC-0015. A collection of nodes transmitting the AFS constitutes the Lunar Augmented Navigation Service (LANS).

1.2.8.3 Lunar Augmented Navigation Service (LANS)

The LANS via AFS is a multiple access forward link and allows reception by multiple users from the same LCRNS node (one-to-many). Additionally, it also supports a many-to-one concept (i.e., GNSS-like with AFS signals from multiple LCRNS nodes received by one user) owing to the mandatory time synchronization of the nodes, the coordinated generation of PNT-specific navigation messages, and the Code Division Multiple Access (CDMA) differentiation among the LCRNS nodes.

Figure 1-4 LCRNS PNT Services

1.2.9 Configuration Control

Changes to this requirements document shall be controlled using procedures set forth in the NASA LCRNS Configuration Control Board documentation.

Section 3. Lunar Relay Service Requirements

3.1 Lunar Relay Service Functional Requirements

LCRNS.3.0010 Interoperability and Compatibility The Lunar Relay service shall comply with the interfaces specified in the LunaNet Interoperability Specification LNIS V.4 (ESC-LCRNS-SPEC-0015) per the compliance matrix in Appendix C.

Rationale: Lunar relay nodes function within the LunaNet architecture, which specifies a set of standard interfaces enabling interoperability and compatibility between systems including operation between lunar and earth elements that contribute to the network. Appendix C provides the compliance matrix for the subset of requirements within this specification for each phase/increment of missions. This requirement ensures that the Lunar Relay Service interfaces with Lunar User Systems and provide communication and PNT services within an interoperable framework. The primary goal of LCRNS for Artemis is to enable communication and PNT services between the crew and mobility assets on the lunar surface and the Earth. Artemis elements will be able to use lunar relay, Gateway or other assets interchangeably depending on specific needs.

Effectivity: IOC, EOC

LCRNS.3.0020 Lunar Relay Communications Function The Lunar Relay Service shall provide key operational support to lunar systems.

Rationale: Providing key operational support implies the existence of a robust design, including failure tolerance or functional redundancies as well as high-quality design standards. Lunar systems include HLS, LTV, Pressurized Rover, Habitat, ISRU, Robotic Systems.

Effectivity: IOC, EOC

LCRNS.3.0030 Lunar Relay Ubiquitous Signal for Position, Navigation, and Timing and Broadcast Messaging Service The Lunar Relay service shall provide Augmented Forward Signals (AFS) with broadcast messaging.

Rationale: This signal will enable users’ in-situ autonomous lunar orbiting and surface asset navigation, time knowledge, and situational awareness to meet their mission requirements. Crewed, uncrewed, and robotic assets in the lunar space volume region and on the lunar surface need to navigate and have lunar-centric situational awareness independent of Earth-assets (e.g., DSN, NSN, Commercial Stations). The lunar relay provision of signals structured to provide pseudorange, Doppler, and time transfer, with associated message content, enables a lunar-relative and inertially-tied navigation/positioning/time solution to meet their operational requirements for PNT knowledge, network knowledge, and alerts.

Drivers for PNT accuracy and timeliness include HLS landing accuracy, and surface human and robotic mobility asset(s) position knowledge, sampling, ISRU for science-related needs and geographic location, and utilization payload positioning.

Effectivity: IOC, EOC

LCRNS.3.0040 Lunar Relay Position, Navigation, and Timing Function The Lunar Relay service shall provide functionality via dedicated service for in-situ autonomous lunar orbiting and surface asset navigation and time knowledge.

Rationale: Users unable to benefit from the functionality described in LCRNS.3.0030, require PNT services provided via dedicated links. Crewed, uncrewed, and robotic assets in the lunar space volume region and on the lunar surface need to navigate independent of Earth-assets (e.g., DSN, NSN). The lunar relay provision of signals structured to provide pseudorange, Doppler, and time transfer, with associated message content, enables a lunar-relative and inertially-tied navigation / positioning / time solution to meet their operational requirements.

Drivers for PNT accuracy and timeliness include HLS landing accuracy, and surface human and robotic mobility asset(s) position knowledge, ISRU for science-related needs and geographic location, and utilization payload positioning as listed in section 3.2.3.

Effectivity: IOC, EOC

LCRNS.3.0050 Lunar Relay Real-time Data Service Functionality The Lunar Relay Service shall provide a lunar communications relay capable of real-time data relay services between Earth and Lunar Users.

Rationale: The lunar communications network is a critical piece to enable mission execution during all mission phases. This requirement defines the capability required to support the initial crewed missions to the lunar surface. Realtime is defined as data flow through the relay with the minimum latency achievable. This service requires all links between the sender and the receiver to be available.

Effectivity: IOC, EOC

LCRNS.3.0060 Lunar Relay Non-Real-Time Data Service Functionality The Lunar Relay Service shall provide a lunar communications relay capable of store-and-forward data relay services between Earth and Lunar Users.

Rationale: A store-and-forward capability is needed to increase the amount of data that the network can return to Earth and for example, allows coverage of far-side assets when orbital mechanics preclude direct contact with Earth Effectivity: IOC-C, EOC

LCRNS.3.0070 Relay between Lunar Users (Real-Time Data Service) The Lunar Relay Service shall provide a lunar communications relay capable of real-time data relay services between Lunar Users.

Rationale: Communication and commanding between lunar platforms without routing to Earth will be necessary to execute a sustained lunar presence Effectivity: EOC

LCRNS.3.0097 Service Coverage (Phasing) The Lunar Relay Service shall provide coverage within the minimum Service Volumes as shown in Table 3-3 for each of the IOC increments and EOC.

Rationale: Coverage requirements vary per service type and are expected to change both depending on number of users and operational criticality.

Effectivity: IOC, EOC Per Table 3-3

LCRNS.3.0100 Ka-Band Return Data Services Relay Network Coverage The Lunar Relay Service shall provide dedicated Ka-band return data services to lunar users within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: The high-rate data service requires Ka-links.

Effectivity: IOC, EOC Per Table 3-3

LCRNS.3.0105 Ka-Band Forward Data Services Relay Network Coverage The Lunar Relay Service shall provide dedicated Ka-band forward data services to lunar users within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: The high-rate data service requires Ka-band links.

Effectivity: IOC-B, IOC-C, EOC Per Table 3-3

LCRNS.3.0110 S-Band Return Data Services Relay Network Coverage The Lunar Relay Service shall provide dedicated S-band return data services to lunar users within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: Health and status and PNT services can be met with more available and mature S-band systems. Availability of these services can be increased without undue burden on the development effort.

Effectivity: IOC, EOC Per Table 3-3

LCRNS.3.0113 S-Band Forward Data Services Relay Network Coverage The Lunar Relay Service shall provide dedicated S-band forward coverage to lunar users within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: Health and status and PNT services can be met with more available and mature S-band systems. Availability of these services can be increased without undue burden on the development effort.

Effectivity: IOC, EOC Per Table 3-3

LCRNS.3.0115 Point-to-Point PNT Services Relay Network Coverage The Lunar Relay Service shall provide Point-to-Point link PNT services to lunar users within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: PNT coverage is needed for Artemis vehicle autonomy in lunar space for the S-band and Ka-band dedicated links.

Effectivity: IOC, EOC Per Table 3-3

LCRNS.3.0120 Lunar Augmented Navigation System (LANS) Service The Lunar Relay Service shall provide Lunar Augmented Navigation System (LANS) services within the Service Volumes shown in Table 3-3.

Rationale: Availability of the LANS service will be targeted to support IOC-C missions, with full lunar coverage attained in EOC. The LANS consists of multiple AFS signals and associated messages. Table 3-3 represents values for four signals in view to create the necessary geometric diversity.

Effectivity: IOC-C, EOC Per Table 3-3

LCRNS.3.0130 LANS Service Geometric Dilution of Precision (GDOP) The Lunar Relay Service shall provide LANS services with Geometric Dilution of Precision (GDOP) <6 (TBR) in the Service Volumes identified in Table 3-3.

Rationale: GDOP is fundamental in achieving performance, in terms of knowledge and timeliness to meet user needs.

Effectivity: IOC-C, EOC

LCRNS.3.0140 Lunar Service Situational Awareness The Lunar Relay Service shall share relay ephemeris data with other providers.

Rationale: NASA seeks an interoperable network with national and international participants. The ability to share accurate relay information with respect to their orbital ephemerides enables a true navigation network, prevents collisions, and allows scheduling of assets without ground intervention. In IOC ephemeris sharing can be done indirectly through an Earth facility.

Effectivity: IOC, EOC

LCRNS.3.0150 Time Synchronization The Lunar Relay Service shall synchronize time with an external common reference timing source shared with other providers.

Rationale: NASA seeks an interoperable network, per the LunaNet Interoperability Specification, with national and international participants. The ability to share accurate relay information with respect to their time knowledge and residual delay in a common time system and orbital ephemerides enables a true navigation network, prevents collisions, and allows scheduling of assets without ground intervention. A common reference time system will be defined within the

LNIS.

Effectivity: IOC, EOC

LCRNS.3.0160 Provider to Provider Message Exchange The Lunar Relay Service shall support messaging services between different providers, enabling exchange of navigation, schedule and space situational awareness information.

Rationale: NASA seeks an interoperable network with national and international participants. The ability to share relay information with respect to their orbital ephemerides and other attributes enables a true synchronized navigation and communication network, prevents collisions, and allows scheduling of assets without ground intervention.

Effectivity: EOC

LCRNS.3.0170 Dynamic Phases The Lunar Relay Service shall cover dynamic events such as lunar vehicle descent and ascent, lunar orbiting vehicles, and mobility surface vehicles and personnel.

Rationale: The dynamic environment of lunar systems will require sufficient coverage to support precise navigation, DTE communications blockage, and search and rescue operations. Descent to the lunar surface includes landing;

ascent includes lift-off from the lunar surface. It is recognized that during highly dynamic events, some signal services may be degraded or not possible due to the challenges of Doppler tracking. If a service requirement is not met during highly dynamic events, that should be clearly stated and explained. Reference trajectories are provided in this SRD Appendices.

Effectivity: IOC, EOC

LCRNS.3.0180 Dynamic Coverage– Low Lunar Orbit (LLO) The Lunar Relay service shall provide communications and PNT services to crewed and robotic vehicles in a low lunar orbit (LLO) within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: The relay must be able to provide service while tracking user spacecraft in motion relative to the lunar surface.

Effectivity: Per Table 3-3

LCRNS.3.0190 Dynamic Coverage – Descent (IOC) The Lunar Relay Service shall provide communications and PNT services to crewed and robotic vehicles while descending to the lunar surface from LLO within the applicable service volume and at the percent coverage shown in Table 3-3.

Rationale: The LCRNS Relay must be able to provide service while tracking user spacecraft in motion relative to the lunar surface. Descent to the lunar surface includes landing.

Effectivity: IOC per Table 3-3

LCRNS.3.0195 Dynamic Coverage – Descent (EOC) The Lunar Relay Service shall provide continuous communications and PNT services to crewed vehicles while descending to the lunar surface from LLO within SV3 (Table 3-3).

Rationale: The LCRNS Relay must be able to provide service while tracking user spacecraft in motion relative to the lunar surface. Descent to the lunar surface includes landing.

Effectivity: EOC per Table 3-3

LCRNS.3.0200 Dynamic Coverage – Ascent (IOC) The Lunar Relay Service shall provide communications and PNT services to crewed and robotic vehicles while in ascent from the lunar surface to LLO within the applicable service volume and at the percent coverage levels shown in Table 3-3.

Rationale: The LCRNS Relay must be able to provide service while tracking user spacecraft in motion relative to the lunar surface. Ascent includes lift-off from the lunar surface.

Effectivity: IOC per Table 3-3

LCRNS.3.0205 Dynamic Coverage – Ascent (EOC) The Lunar Relay Service shall provide continuous communications and PNT services to crewed vehicles while in ascent from the lunar surface to LLO within SV3 (Table 3-3).

Rationale: The LCRNS Relay must be able to provide service while tracking user spacecraft in motion relative to the lunar surface. Ascent includes lift-off from the lunar surface.

Effectivity: EOC per Table 3-3

LCRNS.3.0210 Surface User Operations Coverage (generic) The Lunar Relay Service shall provide communications and PNT services to users while on the lunar surface within the applicable service volumes shown in Table 3- 3.

Rationale: The LCRNS Relay must be able to provide service on the lunar surface to human and robotic vehicles.

Effectivity: IOC, EOC per Table 3-3

LCRNS.3.0220 Crewed Surface Operations The Lunar Relay Service shall provide communications and PNT services to crewed surface vehicle users within the applicable service volumes shown in Table 3-3.

Rationale: LTV, Unpressurized Rover, Pressurized Rover, and other Artemis mobility vehicle users while out of line of sight of the crewed lander will rely on lunar relay services for communication and PNT coverage in the service volumes shown in Table 3-3.

Effectivity: IOC, EOC per Table 3-3

LCRNS.3.0230 EVA surface extended Operations Duration The Lunar Relay Service shall provide navigation services such that the NASA human spaceflight architecture on the lunar surface can meet a minimum of 24 hours of cumulative surface EVA time per crewmember per 7 Earth-day period during surface stays greater than or equal to 14 Earth-days.

Rationale: The primary goal of Lunar Relay is to enable communication between mobility assets on the lunar surface locally and with the Earth. EVA mobility elements will be able to use Lunar Relay Services for specific operational needs.

LCRNS.3.0240 EVA surface initial Operations Duration

The Lunar Relay Service shall provide PNT services so that the initial Artemis systems can be capable of supporting at least two lunar surface extra-vehicular activities (EVA), each lasting at least 4 hours nominally plus 1 hour contingency.

Rationale: The lunar relay service needs to cover the entirety of EVA operations as relayed through the HLS lander (IOC). This will both cover instances where DTE is not available and provides a backup to DTE if it is available.

Effectivity: IOC-C, EOC

LCRNS.3.0260 User Data Security The Lunar Relay Service shall maintain user provided encryption sent to and from the lunar relays and Earth ground stations.

Rationale: Lunar relays will maintain user data encryption as it moves to and from endpoints – no decryption of user data through the relay path will be provided (TBR for EOC capabilities).

Effectivity: IOC, EOC

LCRNS.3.0270 Earth Independent Services The Lunar Relay Service shall provide services between endpoints in the lunar vicinity without routing data to and from Earth.

Rationale: Routing data to and from Earth increases Earth-station usage, raises latency, and reduces throughput, versus routing data entirely in the lunar domain.

Effectivity: EOC

LCRNS.3.0280 Service Provider Real-time Data Latency The Lunar Relay Service node shall limit the time between receiving real-time data and transmitting that data to the NSN interface point to less than 1.0 (TBR) seconds.

Rationale: Each relay node must limit on board processing of real-time data (voice, video, telemetry) to the minimum needed so as not to be disruptive to end-user operation. The current estimate is 5 seconds end-to-end from users on earth to users on the lunar surface. Each service provider node is allocated 1.0 second.

Does not include light time delays nor the NSN latency beyond the NSN interface point. This is not an end-to-end network latency measurement.

Effectivity: IOC, EOC

LCRNS.3.0310 Service Provider Earth Forward or Return Latency The Lunar Relay Service shall limit the time between receiving/transmitting real-time data from a user to and from the NSN interface point to less than 3.0 (TBR) seconds each way.

Rationale: Command data is related to the real-time health and safety of the user mission platform and must be delivered to the mission platform quickly. Note this is not an end-to-end network latency measurement.

Effectivity: IOC, EOC

LCRNS.3.0320 Concurrency of Operations

The Lunar Relay Service shall provide concurrent operations of relay services for lunar communications, data operations, PNT services, and LunaNet messaging services.

Rationale: The lunar relay service needs to provide concurrent communications, real-time, store and forward data (no later than IOC-C), PNT, and messaging services with one or more lunar users while maintaining high data rate and low latency operations. Concurrent services are listed in Table 3-3.

Effectivity: IOC, EOC

LCRNS.3.0340 Ground Station (commercial or government) Interface to the

NSN

The Lunar Relay Service shall interface with the NSN at the NSN demarcation point in the Cloud, per document ESC-NSN-ICD-0143.

Rationale: An interoperable network will need a way to deconflict data services to/from users on Earth and in lunar space. The NSN provides a central hub where multiple providers are deconflicted and appropriate services selected. Assumes service provider has a mission operations center to manage and control the relay service nodes and includes the information necessary for its own flight operations.

Effectivity: IOC, EOC

LCRNS.3.0350 Quality of Service (QOS) metrics The Lunar Relay Service shall provide real-time status and Quality of Service (QOS) metrics to the NSN per document ESC-NSN-ICD-0143.

Rationale: The overall system (relays, ground segment, users) must have the ability to monitor its own status and provide key performance metrics that prove it satisfies end-user needs. Relay/MOC should be able to determine that the relay is meeting its QOS metrics on a periodic basis based on telemetry received and trended each month. Metrics likely to be required are latency, availability, and data completeness.

LCRNS.3.0490 Cross-Link Capability The Lunar Relay Service shall provide interoperable cross link support between its own nodes and those nodes of other service providers per the LunaNet Interoperability Specification to provide for communication, data services, and intersatellite PNT.

Rationale: Assumes multiple providers working together within one lunar communications and navigation network. Providers are expected to develop capabilities to support waveforms and protocols to communicate with other provider’s satellites, measure intersatellite range and Doppler, exchange and synchronize time, and exchange position and velocity as well navigation sources in compliance with the LunaNet interoperability specification among their own nodes and with other providers independent from Earth.

Effectivity: EOC

3.2.2 Space Internetworking Data Service Requirements

The network requirements are the aggregation of requirements for all data flows between all sources and destinations flowing through lunar relay services.

LCRNS.3.0500 Data Service Capabilities The Lunar Relay service shall implement in-space data service capabilities to support routing of all received user data to the appropriate destination, either with minimal latency/real-time (starting with IOC-A), or through store-and-forward (no later than IOC-C) Rationale: For each unit of data received from the user, the Lunar Relay service must be able to use methods to understand the received user data (e.g. reading headers, etc.) and, in real-time, act on such information where routing, QoS, and other relevant functionality is required. The lunar relay service needs to provide real-time service for those users having specific low latency requirements and provide store and forward service to those users with flexible latency requirements.

Effectivity: IOC, EOC

LCRNS.3.0510 Protocol Configuration The Lunar Relay Service shall be able to configure their protocol to communicate with all compatible user missions.

Rationale: Users requesting data service from the lunar relay service need to understand which nodes support the unique protocol configurations and constraints of their configurations which must be followed when connecting to various relay nodes.

Effectivity: IOC, EOC

LCRNS.3.0520 Store and Forward/Disruption Tolerant Network (DTN) The Lunar Relay Service shall implement DTN BPv7 with custody transfer to provide store and forward data transfers.

Rationale: DTN is the most effective means of ensuring data delivery when disruptions to signal path occur and are extensible to the entire solar system. The lunar relay service needs to provide real-time service for those users having specific low latency requirements and provide store and forward service to those users with flexible latency requirements.

Effectivity: IOC-C, EOC

LCRNS.3.0530 DTN Reliability The Lunar Relay Service DTN shall provide reliable delivery of bundles at or exceeding 95% (TBR) successful delivery.

Rationale: User missions rely on the lunar relay services to provide consistent and dependable service to receive and distribute mission data. Reliable delivery of bundle service is dependent on the availability of the overall lunar relay network.

Effectivity: IOC-C, EOC

LCRNS.3.0540 DTN Routing Rate The Lunar Relay DTN Service shall provide a minimum bundle generation and throughput rate no less than the maximum relay data rates as defined in this document.

Rationale: DTN service data ingest, processing, storage, and output rates must not be a bottleneck in data throughput, and so must process inbound and outbound data as fast as or faster than the maximum aggregate input and output rates of all communications channels that use DTN, and consistent with available per-minute contact times.

Effectivity: IOC-C, EOC

LCRNS.3.0550 DTN Storage Accounting The Lunar Relay DTN Service shall maintain a centralized storage of service accounting and network and node status information and make this accessible for accounting purposes.

Rationale: The NSN will need to collect, store and account for user data to meet user needs and required QOS metrics.

Effectivity: IOC-C, EOC

LCRNS.3.0560 Intermediate DTN Bundle Storage The Lunar Relay DTN Services shall be capable of storing bundles at intermediate relay nodes during bundle routing.

Rationale: The relays will need to provide sufficient intermediate storage of data to meet mission requirements and provide accounting information for such data to satisfy user data accounting needs.

Effectivity: IOC-C, EOC

3.2.3 Position, Navigation, and Timing (PNT) Services

The lunar communications and navigation service shall provide functionality for in-situ autonomous lunar orbiting and surface asset navigation and time knowledge to meet their mission requirements. PNT services support crewed and robotic spacecraft and surface activities, particularly during dynamic phases (low-lunar orbit, during descent and ascent, and during long EVAs) and surface operations.

Table 3-10 describes representative user scenarios and their associated position, velocity, and time (PVT) performance requirements for the IOC increments and EOC. Note that Table 3-10 specifies performance for the final increment of IOC when user performance is required to be met. However, it is expected that IOC-A and IOC-B will verify some of these user PNT requirements. PVT performance in this table includes position, velocity, and time knowledge, time to achieve the first fix of those knowledge levels, and the time delay to meet knowledge updates. All position and velocity numbers are given as RSS values of position and velocity component errors, except for the Powered Descent Initiation (PDI) to Landing scenario. From PDI through the descent sequence, the values are RSS; at the time of landing, the values are specified for position as a radius on the surface and a velocity requirement per axis. Time to first fix is defined as the time it takes to get an initial fix in the scenario environment, or time to recover the position knowledge after a propulsive maneuver (except landing) needed to meet the position and/or velocity knowledge requirement(s). Time delay to meet knowledge is the time it takes to update position and/or velocity and time knowledge (when relays are in view) and this includes landing scenario radiometric update rate.

There are currently four user scenarios defined for PNT. The first scenario represents an asset in a circular low lunar orbit (LLO) (approximately ≤ 100 km from the lunar surface). The navigation solution in that case can either be accomplished on the ground or on-board, depending on the user’s operational concept. The second scenario provides the requirement on PVT knowledge prior to performing the De-orbit Insertion (DOI) to leave LLO. The third scenario describes lander type missions at the time prior to starting their powered descent to the surface (PDI) (e.g., at approximately 15 km from the lunar surface) all the way through landing. The state and time knowledge in that user scenario is primarily envisioned to initialize an on-board full 6-Degree of Freedom (DOF) solution with timely updates from multiple data sources, including radiometrics from the lunar relay. The landing requirement addresses the knowledge portion of a given landing touchdown, assuming that the lander is equipped with hazard detection capabilities. The remaining user case relates to PVT knowledge during surface activities. While there are several sub-scenarios, these have been generalized to absolute knowledge for surface activities. For the IOC-C increment, a lunar rover is envisioned as part of the surface traversing user case with higher speeds (e.g., approximately 10 km/h moving speed). In addition, relative PVT knowledge becomes necessary between two surface assets (human and robotic) or a surface asset and a surface terrain feature. In this user scenario, the lunar relay service contributes to meeting the relative knowledge requirements but is not the sole observation set.

LCRNS.3.0570 Position, Navigation, and Timing - User The Lunar Relay Service shall provide PNT services such that user PNT performance (TBR) listed in Table 3‑10 are met, specified in a lunar-centric inertial frame.

Effectivity: EOC

LCRNS.3.0660 LunarSAR Message Relay Timeline The Lunar Relay Service shall relay the entire beacon message(s), beacon encoded position(s), and timestamps to Earth and selected lunar surface locations within 5 minutes [TBR] of beacon activation.

Rationale: The timeline between LunarSAR beacon activation and reception/processing of LunarSAR data drives response timeframes and ability to successfully perform crewmember rescue operations over extended EVA walk-back distances. Future SAR cases may involve a mixed ecosystem of commercial, international, and governmental users requiring timely coordination and ability to disseminate information.

Effectivity: EOC

LCRNS.3.0670 LunarSAR Independent Location Probability The Lunar Relay Service shall provide a probability of independent location (not relying on LunarSAR beacon-provided location data) of 95% within 10 minutes [TBR] of activation, for a LunarSAR beacon transmitting at 35 [TBR] dBm EIRP.

Rationale: As a future capability, the relay constellations should provide “reverse GPS” for disadvantaged users in potentially PNT-degraded environments (i.e., PNT signal terrain masking or other terrain features causing multipath propagation effects). This aligns with current terrestrial satellite-aided search and rescue (SARSAT) principles for those in potentially degraded GNSS environments.

Effectivity: EOC

LCRNS.3.0680 LunarSAR Independent Location Accuracy The Lunar Relay Service shall locate an emergency beacon within the Lunar South Pole region with an accuracy of 50 meters [TBR], without reliance on the beacon’s self-reported position for a LunarSAR beacon transmitting at 35 [TBR] dBm EIRP.

Rationale: As a future capability, The LCRNS relay constellations should provide “reverse Global Positioning System (GPS)” for disadvantaged users in potentially PNT-degraded environments (i.e., PNT signal terrain masking or other terrain features causing multipath propagation effects). This aligns with current terrestrial satellite-aided search and rescue (SARSAT) principles for those in potentially degraded GNSS environments.

3.2.5 Lunar Relay Service On-orbit Validation Capabilities

LCRNS.3.0690 On-board self and built-in service testing Each Lunar Relay service node shall have internal built-in test and verification capability.

Rationale: Unlike typical earth communication relays, the lunar relay nodes will be performing other services to route, store and forward user data and provide accurate location and position information with lunar user elements. Some method of verifying these services (or degraded services) must be internal to the relay to validate prior to operational certification with the possibility there may not be lunar users available to test services. This includes verifying its operation after recovery from critical faults on-orbit.

3.2.6 Lunar Relay Cybersecurity

LCRNS.3.0700 Command Data Encryption Each Lunar Relay service node shall use FIPS 140-3 certified encryption for all spacecraft commands.

Rationale: Command data must be protected to ensure that only authorized users have access to the system and all services are available during critical events. This must be verified against the NIST FIPS 140-3 Cryptographic Module Validation Program and the communication path must be tested to ensure compatibility between ground infrastructure and space segment prior to launch.

Effectivity: IOC, EOC

LCRNS.3.0710 Information System Authorization The lunar relay providers ground system shall be assessed and authorized as a HIGH system in accordance with the Federal Information System Management Act of 2014 using NIST Special Publication 800-53, Revision 5.

Rationale: All systems processing data for or on behalf of NASA are required to follow the NIST Risk Management Framework and conduct regular assessments and perform continuous monitoring activities.

Effectivity: IOC, EOC

LCRNS.3.0720 Project Protection Plan The lunar relay provider shall complete and update a Project Protection Plan (PPP) to identify known threats and response plans to mitigate associated risks.

Rationale: NASA requires each flight system to complete and maintain a PPP that addresses known risks identified in NASA-STD-1006.

Effectivity: IOC, EOC

LCRNS.3.0730 Service Authentication The lunar relay PNT service shall have the capability to provide authentication to users.

Rationale: The use of authentication will provide resistance to spoofing and ensure that PNT data is coming from a legitimate source.

Effectivity: IOC, EOC

LCRNS.3.0740 Service Availability Protection The lunar relay system shall have anti-jamming capabilities to prevent denial of service via Radio Frequency Interference (RFI) or other electronic attack.

Rationale: The inclusion of anti-jamming capabilities will help ensure that events could not be intentionally disrupted by a malicious actor.

Appendix B. User Mission Specific Information and Timeline Reference

B.1 User- Level Assumptions

Representative User-level assumptions are given throughout this document to help providers size their space and/or ground systems to include capabilities needed to meet requirements. This is needed since the specific missions are still in an evolutionary process, and any evolving details have the potential of leaving important capabilities out of the current requirements base. Specific details about each mission will be updated during the validation process.

B.2 Communications and Data Services Characteristics

For communication and data services, requirement 3.0370 and Table 3-6 Reference User System Performance and Data Rate Requirements provide the most current information on user communication characteristics.

B.3 PNT System Characteristics

Evolving over IOC increments and the EOC to meet the respective service volumes, the user will be able to receive and utilize several simultaneous AFS (1-way forward reference signals and associated messages) from different relay sources, which constitutes the Lunar Augmented Navigation System (LANS). The derived observables are used to estimate user Position, Velocity and Time (PVT). However, in IOC there may be a need for the user to supplement the set of observables from relay(s) with other data sources, such as DTE (Earth to lunar user), Inertial Measurement Unit, etc. The relays shall provide messages with all the information content related to the network that is required by the user to perform their PVT solution.

The user is expected to have the capability to receive signals from multiple relays simultaneously and process the metric tracking observables and message content to obtain a PVT solution.

B.4 User Timelines

This section provides an estimate of expected NASA user operational hours through a relay service in lunar space for IOC increments Alpha, Bravo, and Charlie. During Artemis missions, communication demand will also impact NASA’s ability to provide DTE communication services to science missions. LNSP support will help “offload” NASA’s DTE communication services via allocated LNSP lunar relay-Earth ground station assets.

Figure B-1 Reference Trajectory for HLS Landing

Figure B-2 Reference Trajectory for HLS Departure