Lunar Relay Services Requirements Document (SRD) 12-05-2022 (Rev B).pdf

ii

ESC-LCRNS-REQ-0090

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

Document (SRD)

Prepared by:

Signature on File

Nick Speciale Systems Engineer, LCRNS

NASA GSFC

Concurred by:

12/05/2022

Nick Speciale Date Systems Engineer, LCRNS

Juan Crenshaw

Justine Long

NASA GSF

Date

Sanjeev Sharma Date

SMA, LCRNS

iii

Approved by:

Jaime Esper Date Project Manager, LCRNS iv

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) vii

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 viii

B.5 Reference Trajectories for Descent and Ascent

Appendix C. LunaNet Interoperability Compliance Matrix

Appendix D. Glossary and Acronym List ix

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 63

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) or Service Providers (SP) 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. 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.

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.

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.

on historical space systems. Note: Although the addition of a RHCP signal of equivalent specification is optional for IOC (both LHCP or RHCP required for EOC), the Lunar Relay Service provider is encouraged to implement both polarizations for IOC to increase the early applicability and flexibility of service to Artemis and NASA vehicles.

Effectivity: IOC

LCRNS.3.0362 S-band Forward Antenna Polarization (EOC) The Lunar Relay Service shall be capable of selecting LHCP or Right Hand Circularly Polarization (RHCP) with an axial ratio of less than 3 dB for each user link on the S-band Single Access Forward service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates clockwise in space. This definition is consistent with observing a counter-clockwise rotation when the electric field vector is viewed in the direction of propagation. A right-hand circularly polarized wave would have rotation in the opposite direction. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems. Having both LHCP and RHCP will be beneficial to support the greatest user flexibility.

Effectivity: EOC

LCRNS.3.0363 S-band Return Antenna Polarization (IOC) The Lunar Relay Service shall receive a LHCP signal with an axial ratio of less than 3 dB for the S-band single access return service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates clockwise in space. This definition is consistent with observing a counter-clockwise rotation when the electric field vector is viewed in the direction of propagation. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems. Note: Although the addition of a RHCP signal of equivalent specification is optional for IOC (both LHCP or RHCP required for EOC), the Lunar Relay Service provider is encouraged to implement both polarizations for IOC to increase the early applicability and flexibility of service to Artemis and NASA vehicles.

Effectivity: IOC

LCRNS.3.0364 S-band Return Antenna Polarization (EOC)

The Lunar Relay Service shall be capable of selecting LHCP or RHCP with an axial ratio of less than 3 dB for each user link on the S-band Single Access Return service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates clockwise in space. This definition is consistent with observing a counter-clockwise rotation when the electric field vector is viewed in the direction of propagation. A right-hand circularly polarized rotates in the opposite direction. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems. Having both LHCP and RHCP will be beneficial to support the greatest user flexibility.

Effectivity: EOC

LCRNS.3.0365 Ka-band Forward Antenna Polarization The Lunar Relay Service shall be capable of selecting LHCP or RHCP with an axial ratio of less than 3 dB for each user link on the Ka-band Forward service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates clockwise in space. This definition is consistent with observing a counter-clockwise rotation when the electric field vector is viewed in the direction of propagation. A right-hand circularly polarized wave rotates in the opposite direction. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems. Having both LHCP and RHCP will be beneficial to support the greatest user flexibility.

Effectivity: IOC, EOC

LCRNS.3.0366 Ka-band Return Antenna Polarization The Lunar Relay Service shall be capable of selecting LHCP or RHCP with an axial ratio of less than 3 dB for each user link on the Ka-band Return service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates clockwise in space. This definition is consistent with observing a counter-clockwise rotation when the electric field vector is viewed in the direction of propagation. A right-hand circularly polarized wave rotates in the opposite direction. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems. Having both LHCP and RHCP will be beneficial to support the greatest user flexibility.

LCRNS.3.0367 AFS Antenna Polarization The Lunar Relay Service shall transmit an RHCP signal with an axial ratio of less than 3 dB for the AFS service. The 3 dB axial ratio shall be met over the full operational beamwidth of the antenna.

Rationale: Space systems typically use circular polarization to avoid the large mismatches possible with linear polarization. IEEE Standard 211-2018, IEEE Standard Definition of Terms for Radio Wave Propagation, defines a LHCP wave as a circularly or an elliptically polarized electromagnetic wave for which the electric field vector, when viewed with the wave approaching the observer, rotates counter-clockwise in space. This definition is consistent with observing a clockwise rotation when the electric field vector is viewed in the direction of propagation.

RHCP is the LunaNet defined polarization for AFS. 3 dB axial ratio has been selected as a realistically achievable performance target based on historical space systems.

Effectivity: IOC, EOC

LCRNS.3.0370 Lunar Relay Proximity Signal Services The Lunar Relay Service shall provide the LunaNet proximity service signals shown in Table 3‑5. The Lunar Relay Service shall be capable of providing these services over the range of symbol rates specified in Table 3‑5, and for all coding options specified in the LNIS V.4.

Rationale: Users must have knowledge of what services will be provided prior to system development. These signals were selected to provide IOC users their required services, while providing service providers the flexibility to implement more advanced signal types in later EOC phases. It is understood that many details within the LunaNet Interoperability Specification are TBR and under discussion, and those signals will be defined in future releases. The IOC signals shown here have priority for discussion and finalization.

Effectivity: See Table 3‑5

Rationale: It is commonplace to put the burden of acquisition on the network side in order to reduce complexity of the user mission. This is a capability that modern ground stations have.

Effectivity: IOC, EOC

LCRNS.3.0470 Dynamic Signal The Lunar Relay Service shall be capable of maintaining the communication and navigation links through the dynamic mission reference trajectories shown in Appendix B [TBR].

Rationale: This requirement implies that the relay system receiver must meet Doppler tracking requirements and antenna slewing or beamforming requirements to support dynamic mission phases.

Effectivity: IOC, EOC

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.

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.

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.