LunaNet Interoperability Specification Document Version 4 (ESC-LCRNS-SPEC-0015).pdf

ESC-LCRNS-SPEC-0015

LNIS V004 September 12, 2022 1

LunaNet Interoperability Specification Document

Version 4

LNIS V004 September 12, 2022 2

TABLE OF CONTENTS

Tables and Figures

List of To Be Determined and To Be Refined

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Security Considerations

2. LunaNet Interoperability Overview

3. User Services

3.1 Communications Services

3.1.1 Real-Time Communications Services

3.1.2 Store-and-Forward Communications Services

3.1.3 Messaging Services

3.2 Position, Navigation, and Timing Services

3.2.1 Reference Signals

3.2.2 Lunar Augmented Navigation System (LANS)

3.2.3 One-Way Measurements

3.2.4 Two-Way Measurements

3.2.5 Two-Way Transponder

3.2.6 Supplemental Navigation Products (Nav-Supp)

3.2.7 Location Service (Loctn)

3.3 Detection and Information Services

3.3.1 Lunar Search and Rescue (LunaSAR) Services

3.3.2 Space Weather Alerting Services

3.4 Science Services

3.5 Service Access

3.5.1 Earth-based Scheduling Service

4. LunaNet Service Provider to User Interfaces

4.1 LNSP-User Lunar Surface Interfaces

4.2 LNSP-User Proximity Interfaces

4.3 LNSP-User DTE Interfaces

4.4 LNSP-User Terrestrial Interfaces

5. LunaNet Service Provider to LunaNet Service Provider Services

5.1 LNSP A-LNSP B Communications Services

5.2 LNSP A-LNSP B PNT Services

6. LunaNet Service Provider to LunaNet Service Provider Interfaces

6.1 LNSP A-LNSP B Lunar Surface Interfaces

LNIS V004 September 12, 2022 3

6.2 LNSP A-LNSP B Crosslink Interfaces

6.3 LNSP A-LNSP B DTE Interfaces

6.4 LNSP A-LNSP B Terrestrial Interfaces

References

Applicable Documents

Appendix A. LunaNet Interoperability Specification Phase Allocations

Appendix B. Acronyms and Abbreviations

Appendix C. Detailed Signal Definitions

Augmented Forward Signal Structure (PFS5)

Multiple Access Return Signal Structure (PRS5)

Appendix D. LunaNet Application Messages

Overview of Messages

LNIS V004 September 12, 2022 4

Tables and Figures

Table 1 - Lunar Network Service Provider Interfaces Table 2 - IP Service Interfaces Table 3 - Bundle Protocol Service Interfaces Table 4 - Messaging Services Interfaces Table 5 - Message ID and Titles Table 6 - Detection and Information Services Table 7 - LNSP–User Lunar Surface-Surface Link Layer Service Interfaces Table 8– LNSP–User Proximity Link Layer Service Interfaces Table 9 - Coding and Framing of Proximity Signals Table 10 - LNSP–User Direct to Earth Link Layer Service Interfaces Table 11 - Codeword/Message Size for signals in Table 10 Table 12 - LNSP–User Terrestrial Link Layer Service Interfaces Table 13 - LNSP–LNSP Crosslink Layer Interfaces (TBD)

Figure 1 - LunaNet Segments Figure 2 - LunaNet Standard Services and Interfaces between LNSPs and Users Figure 3 - LunaNet Service Providers Interfaces Figure 4 - Three Types of Communications Services Figure 5 – User Application Simplified Protocol Stack Figure 6 - LunaNet Applications Simplified Protocol Stack Figure 7 - LunaNet Node and user exchange messages using messaging services Figure 8 - PNT Services Provided by LunaNet Figure 9 - Reference PNT Signals Provided by a LunaNet Node Figure 10 - LANS PNT Concept Provided by LunaNet Nodes Figure 11 - LANS IOC Service Coverage and Performance Volume Figure 12 - LANS EOC Service Coverage and Performance Volume Figure 13 - One-Way Measurements Performed by a LunaNet Node Figure 14 - Two-Way Measurements Performed by LunaNet Node Figure 15 – Two-Way LunaNet Node Transponder Figure 16 - LunaSAR Data Path ConOps Figure 17 - LunaNet Scheduling Interfaces Overview Figure 18 - Augmented Forward Signal Service Provided by a Single LunaNet Source Figure 19 - Functional Interfaces and Corresponding Frequency Bands Figure 20- LunaNet Interoperability Frequency Plan

LNIS V004 September 12, 2022 5

List of To Be Determined and To Be Refined

The table below lists specific To Be Determined (TBD) and To Be Refined (TBR) items in the LNIS document. These items are yet to be finalized or currenlty undefined at the release of this version.

Each designator is numbered based on the document title, document version number when TBD/TBR was identified, designation of TBD or TBR, parent section number, and number of the particular unresolved item. For example, “LNIS4-TBD-6004” can be dissolved as – 4th unresolved TBD item identified in LunaNet Interoperability Specification Version 4 Section 6. Once each item is dispositioned, the resolution will be substituted in place of the designator and the item will be struckthrough (LNIS4 TBD 6004) in this table. If new unresolved items are identified, it will be added to this table using the above defined designation scheme. All TBD/TBR will retain its original numbers and will not be renumbered as items are added or deleted.

List of TBDs/TBRs

Designation Section Description

LNIS4-TBD-

3.1.2 /Table 3 - Bundle Protocol Service Interfaces

Applicable document needed for Bundles / TCPCL. Bundles are forwarded via TCP convergence layer adapter over TCP/IP.

LNIS4-TBD-

3.1.2 /Table 3 - Bundle Protocol Service Interfaces

Applicable document needed for Bundles / UDPCL - Bundles are forwarded via UDP convergence layer adapter over

UDP/IP.

LNIS4-TBD-

3.1.3/ Table 4 - Messaging Services Interfaces

Applicable document needed for Message over Link. Messages inserted directly into AOS frames for transfer over a single link.

LNIS4-TBD-

3.1.3/ Table 4 - Messaging Services Interfaces

Applicable document needed for Message over IP. Messages inserted into IP packets to allow for multiple IP hops to IP destination.

LNIS4-TBD-

3.1.3/ Table 4 - Messaging Services Interfaces

Applicable document needed for Message over DTN. Messages inserted into DTN bundles to allow for multiple hops to any LunaNet destination.

LNIS4-TBD-

3.1.3/ Table 4 - Messaging Services Interfaces

Applicable document needed for Message over AFS. Messages transmitted over the Augmented Forward Signal (AFS) may be carried in a unique manner to accommodate the low AFS data rate.

LNIS4-TBD-

3.2.1.2 Pseudo-Range and

Timing Reference (1wRTRef)

PN codes as identified in CCSDS 414.1-B-2 and CCSDS 415.1- B-1 have traditionally been employed for two-way ranging purposes. To use them as an option for one-way measurements, a method (TBD) must be set in place to convey information to the user correlating source PN phasing and the corresponding time of transmission.

LNIS4-TBD-

3.2.1.3 Time-Transfer

Reference (Tref)

A standardized method (TBD) for a LunaNet node to provide a time reference will be implemented to allow users to have accurate time.

LNIS V004 September 12, 2022 6

LNIS4-TBD-

3.2.4.2 Range Measurement

(2wRMeas)

Frame ranging involves timestamping and identification of synchronized information frames. It is particularly useful in high-rate communications links, where elevated data frame rates facilitate more accurate time resolution. A frame ranging standard is TBD.

LNIS4-TBD-

3.2.5.2 Non-Regenerative

Range Transponder (2Wnrr-

XPND)

In addition to what is performed for the two-way Doppler transponder service, a non-regenerative LunaNet transponder filters and re-modulates the ranging signal onto the forward signal. The LunaNet provider does not require knowledge of the ranging signal type employed by the user. The bandwidth allocated to the ranging signal and used by the LunaNet provider for filtering shall be TBD.

LNIS4-TBD-

3.2.6.1 Lunar Reference

Frame

The use of a common lunar-centered, selenocentric reference frame across LunaNet PNT services enables seamless consumption of the services, irrespective of specific LNSP or users. The lunar reference frame is described in detail in Lunar Reference Frame Standard (TBD).

LNIS4-TBD-

3.2.6.2 Lunar Reference

Time

The use of a common lunar reference time across LunaNet elements is required to enable synchronization of services and time in the lunar domain. This common lunar reference time is described in detail in Lunar Time System Standard (TBD).

LNIS4-TBD-

3.3.1 Lunar Search and

Rescue (LunaSAR) Services

The distress message might include the position of the beacon (if determined through the LunaNet PNT services) or the beacon position might be computed by the LNSP (or another actor) via triangulation of the beacon as received by multiple LunaNet nodes. A beacon might not know where the LNSP satellites are and might not have directive antenna capabilities, so the distress message might be broadcast and arrive at the LNSP with low power, this might require a dedicated, protected band, TBD.

LNIS4-TBD-

3.3.2 Space Weather

Alerting Services

Space Weather alerts and related messages will be communicated using the messaging services, per Appendix D.

The specific standard alert and message content are still TBD.

LNIS4-TBD-

3.5.2.3 User Initiated

Services

User Initiated Services (UIS) may be implemented through service acquisition protocols incorporating messages using the messaging services or through a hailing approach. Standards for both approaches are TBD.

LNIS4-TBD-

4.0 Lunanet Service

Provider To User Interfaces

Standards for optical link interfaces are TBD.

LNIS4-TBD-

4.1 LNSP-User Lunar

Surface Interfaces

LS3 - Short-to-medium range wireless network with mobility and roaming utilizing 3GPP rel. 16 (and higher) (LTE and 5G

TBD).

LNIS4-TBD-

4.1 LNSP-User Lunar

Surface Interfaces

Target Frequency Range is TBD for LS3, Short-to-medium range wireless network with mobility and roaming.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-band Medium Rate w/ Ranging (PFS2) 2025-2110 MHz - Fixed frequency assignments TBD.

LNIS V004 September 12, 2022 7

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-band Medium Rate w/ Ranging (PFS2) 2025-2110 MHz - Symbol & Chip Rates TBD.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS2) 2200-2290 MHz - Fixed frequency assignments TBD.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS2) 2200-2290 MHz - Symbol & Chip Rates TBD.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS5) 2200-2290 MHz Fixed frequency assignments TBD.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS5) 2200-2290 MHz Symbol & Chip Rates TBD.

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward Ka-band Data Only (PFKa1) 23.15-23.55 GHz 1 Msps ≤ Rs ≤ TBD

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward Ka-band Variable Coding and Modulation (PFKa2) 23.15-23.55 GHz 1 Msps ≤ Rs ≤ TBD Msps [6]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward Ka-band High-Rate Data Only (PFKa3) 23.15-23.55 GHz 1 Msps ≤ Rs ≤ TBD Msps [6]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward Ka-band High-Rate Data w/ Ranging (PFKa4) 23.15-23.55 GHz

1.5 Msps ≤ Rs ≤ TBD Msps [6], [8]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return Ka-band Data Only (PRKa1) 27.0-27.5 GHz 1 Msps ≤ Rs ≤ TBD Msps [6]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return Ka-band Variable Coding and Modulation (PRKa2) 27.0-27.5 GHz 1 Msps ≤ Rs ≤ TBD Msps [6], [8]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return Ka-band High-Rate Data Only (PRKa3) 27.0-

27.5 GHz 1 Msps ≤ Rs ≤ TBD Msps [6]

LNIS4-TBD-

4.2 / Table 8 – LNSP–User Proximity Link Layer Service Interfaces

Proximity Return Ka-band Data w/ Ranging (PRKa4) 27.0-27.5 GHz

1.5 Msps ≤ Rs ≤ TBD Msps [6]

LNIS4-TBD-

4.2 / Table 9 - Coding and Framing of Proximity Signals

PFS/PRS 1e coding is TBD

LNIS4-TBD-

4.2 / Table 9 - Coding and Framing of Proximity Signals

PFS/PRS 1e frequency and rate is TBD

LNIS V004 September 12, 2022 9

LNIS4-TBR-

3.3.1 Lunar Search and

Rescue (LunaSAR) Services

LunaSAR’s distress alert service is potentially received on PRS5 [TBR] and responded to over the PFS5 [TBR] links and are prioritized for rebroadcasting when received by the LunaNet orbiting asset(s).

LNIS4-TBR-

4.1 / Table 7 - LNSP–User Lunar Surface-Surface Link Layer Service Interfaces

For LS1 Short-range wireless network Targeted Frequency Range 5.150-5.835 GHz (Lunar Near-side use only) (TBR) under study.

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-Band Medium Rate w/ Ranging (PFS1b) Chip rate TBR

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-Band Medium Rate w/ Ranging (PFS1b) See Note [1] See CCSDS 401.0-B Section 2.2.7 for explanation of PCM/PM/bi-phase-L.TBR: supplemental reference for implementation of PN ranging. Presence of residual carrier aids demodulation (e.g. large doppler dynamics scenarios).

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-Band Low Rate w/ Ranging (PFS1c) See Note [1] See CCSDS 401.0-B Section 2.2.4 for explanation of

PCM/PSK/PM.

TBR: supplemental reference for implementation of PN ranging.

Presence of residual carrier aids demodulation (e.g., large doppler dynamics scenarios).

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Forward S-band Medium Rate w/ Ranging (PFS2) SS-BPSK CDMA (~3Mcps) or SS-UQPSK TBR.

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band Medium Rate w/ Ranging (PRS1b) Chip rate TBR

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band Medium Rate w/ Ranging (PRS1b) See Note [1] See CCSDS 401.0-B Section 2.2.7 for explanation of PCM/PM/bi-phase-L. TBR: supplemental reference for implementation of PN ranging.

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS2) SS-SQPN

TBR.

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS2) See Note [2] Intent is for a wide beam spread spectrum return intended for P2P links. Similar to PRS5 but allows for higher data rates (less spreading) and ranging. There is a possibility to support multiple users simultaneously, albeit much less than PRS5.

Signal parameters could also be modified for user specific needs (TBR).

LNIS4-TBR-

4.2 / Table 8– LNSP–User Proximity Link Layer Service Interfaces

Proximity Return S-Band CDMA Return (PRS5) SS-BPSK

CDMA

(~3Mcps) or SS-UQPSK(Appendix C) TBR.

LNIS V004 September 12, 2022 10

4.2 / Table 9 - Coding and Framing of Proximity Signals

PFS/PRS 1b uncoded is TBR

LNIS4-TBR-

4.2 / Table 9 - Coding and Framing of Proximity Signals

PFS/PRS 1d uncoded is TBR

LNIS4-TBR-

AP0001

Detailed Signal Definitions / Augmented Forward Signal Structure (PFS5)

To transmit a carrier center frequency of 2492.028 MHz, the reference clock can be at 1.023MHz utilizing a reference clock multiplier of 2436. The detailed definition of the signal is provided in LunaNet and User Signal Structure Definition Document [AD1]. The AFS data rate is expected to be between 250sps and 1ksps (TBR).

LNIS V004 September 12, 2022 11

1. INTRODUCTION

LunaNet is envisioned as a set of cooperating networks providing communications, navigation, and other services for users on and around the Moon. The LunaNet concept is based on a framework of mutually agreed-upon standards, protocols, and interface specification that enable interoperability. LunaNet is intended to allow many lunar mission users to engage the services of diverse commercial and government service providers in an open and evolvable architecture. LunaNet services can include communications, messaging, data transmission and distribution of position, navigation, timing, and situational awareness information. The LunaNet concept can be introduced as part of the earliest missions and accommodate expansion as new users and service providers come online. Many nations, agencies, and private companies can contribute to and participate in the establishment and operation of LunaNet.

This document, along with its companion documents, provides the basis for a comprehensive set of specifications for operation of a lunar communications and navigation network capable of interoperating with other networks compliant with the Lunar Network (LunaNet). LunaNet will include Earth ground stations and orbiting spacecraft and will provide services to a variety of missions including those for human exploration, lunar science, and space technology.

LunaNet will start with a simple architecture of a few nodes to meet the needs of the early missions and evolve to meet the growing needs of a sustained lunar presence. All relay network services are not expected to be met by a single spacecraft, or node. The expectation is that the needs of users will be met through a combination of interoperable systems supplied by commercial and government providers. Interoperability across this network-of-networks can be achieved through negotiation of mutually-agreed-upon standards that will be reflected in this document and in the specifications defined by other participants in the cooperative lunar network.

This current version of the document was written and reviewed by NASA and the European Space Agency

(ESA).

1.1 Purpose

The purpose of this specification is to define the standard services and interfaces for LunaNet service providers to administer interoperable services to meet the needs of missions operating in the lunar vicinity.

This document is not intended to replace either the International Communication System Interoperability Standards (ICSIS) or the Interagency Operations Advisory Group’s (IOAG) Lunar Communications Architecture Documents. This document provides the minimum set of standard services and interfaces that will be available to lunar users, such that users may design their systems with the expectation of available providers. Any individual provider is not required to offer all services and interfaces in this document, but the aggregation of providers will have the interfaces and services described. It is also possible for providers to offer services and interfaces beyond what is described in this document. However, those services and interfaces will likely not be interoperable between service providers, thereby limiting the service options for a user.

This current document captures all services and needs for LunaNet, as currently identified. These needs are expected to be met through a consortium of providers. To the extent that service providers follow the mutually-agreed-upon standards for the services and interfaces, which are reflected in this and applicable documents, the combined network can provide seamless services to multiple users.

LNIS V004 September 12, 2022 12

Appendix A contains a table allocating these specifications to two operational time periods. These time periods are Initial Operations Capability (IOC) phase and Sustained Capability phase. The IOC intends to incorporate those requirements to support the first Artemis missions and robotic missions with the lunar south pole and lunar far side as primary locations of interest. The evolution towards the sustained capability will be aligned with the plans for the increased human and robotic lunar missions.

1.2 Scope

This document defines the standards and specifications for interoperations within LunaNet on the lunar surface and in cislunar space. NASA is seeking international and commercial inputs to reach consensus on the contents of this document.

This document will provide the necessary guidance for potential providers and users to design and build systems compatible with the broad LunaNet architecture. These standards and specifications are intended for broad use by all parties operating in cislunar space and will be levied as requirements on systems and services required to be interoperable.

1.3 Security Considerations

This section should be considered an informational reference as the LunaNet architecture and associated security continues to mature and the international community further defines interoperable security requirements. A LunaNet Interoperability Security Specifications [AD8], referenced at the end of this section, will be the repository for detailed implementation specifications.

There are general expectations that Users and Providers shall protect the confidentiality, integrity, and availability of the systems, data, and communication pathways that will be part of LunaNet. These protections should be ensured using a combination of software and hardware that prevents unauthorized access, as well as corruption, interception, and loss of data.

NIST Definitions for clarity:

• Confidentiality - Defined as preserving authorized restrictions on information access and disclosure, including ensuring the means for protecting personal privacy and proprietary information from access and disclosure.

• Integrity - Defined as guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity.

• Availability - Defined as ensuring timely and reliable access to and use of information.

Users are expected to protect their data through encryption and authentication mechanisms appropriate to the type of data they are transmitting and/or receiving. All user protocols with security enhancements will be required to comply with communications standards outlined in this document and shall not result in architectural changes to LunaNet.

Network layer services, including but not limited to, Internet Protocol and Bundle Protocol will be natively supported by LunaNet; this includes end-to-end data transport using IPSEC and BPSec. All other data transport methods may be considered for approval with appropriate secure interfaces on a case-by-case basis for consideration and inclusion in the LunaNet Interoperability Specification.

LunaNet relays and nodes shall capture and transmit updated availability status and configuration controls to enable rapid response to facilitate troubleshooting any communications anomalies.

LNIS V004 September 12, 2022 13

[AD8]: LunaNet Interoperability Security Specifications is under development. Once approved, this will be the authoritative source for interoperable LunaNet security requirements.

2. LUNANET INTEROPERABILITY OVERVIEW

The term “LunaNet” encompasses all systems that provide communications and navigation (or position, navigation, and timing (PNT)) services to user systems on and around the Moon (User Lunar Segment) and the users’ associated systems on Earth (User Earth Segment). As seen in Figure 1, LunaNet has a Lunar Segment and an Earth Segment. The Lunar Segment contains elements that could either be in lunar orbit or on the lunar surface. Though they may be referred to in general as “lunar relays,” it is possible that some elements of the Lunar Segment may not provide any communications relay functions, but support PNT or other non-data relay functions.

The User Lunar Segment may interface with LunaNet by either an interface with the LunaNet Lunar Segment or with the LunaNet Earth Segment. The LunaNet Earth Segment is comprised of ground stations on Earth. Note that there are also interfaces between the LunaNet Lunar Segment and the LunaNet Earth Segment, these may be either intra-network, i.e., within a network provided by a single provider, or it may be inter-network, i.e., between cooperating providers. Standardization of the Lunar Relay-Earth Interface will enable the inter-network or cross support of lunar relays by multiple providers. The Lunar Relay-Earth Interface, shown in Figure 1, is an intra-network example and the single provider in this case may use a non-standardized interface. The LunaNet Lunar Relay-User Interface and LunaNet-Direct-to-Earth Interface are standardized. The interface between the LunaNet Earth Segment and the User Earth Segment will also be standardized. Note that the user could provide a private direct link between its lunar and Earth segments. This is outside the scope of LunaNet and is not addressed in this specification.

Figure 1 - LunaNet Segments

LNIS V004 September 12, 2022 14

Figure 2 - LunaNet Standard Services and Interfaces between LNSPs and Users

Like the terrestrial internet, LunaNet will be built up through multiple LunaNet Service Providers (LNSPs) combined to provide services to users. To allow users to receive those services from any provider such that it appears as a single provider to that individual user, two categories of interoperable interfaces are required (See Figure 2).

The first category is the LNSP-User Interface, which include the service interfaces between a user and a provider. These include both the physical interfaces and the protocols and messages that provide services over those interfaces. A user shall be able to operationally receive the same service from different providers in the same way, such that the user will be able to use any connection as a LunaNet access point.

The second category is the LNSP – LNSP Interface. These include the physical interfaces and protocols and the messages that allow different LNSPs to work together to provide the larger LunaNet infrastructure by augmenting individual LNSP capabilities with LNSP partners.

Figure 3 - LunaNet Service Providers Interfaces

LNIS V004 September 12, 2022 15

The LNSP interfaces are depicted in Figure 3. Each LNSP may have any combination of lunar surface, proximity, direct-to-Earth, and terrestrial interfaces with users. Interfaces between LNSPs may be any combination of lunar surface, crosslink, direct-to-Earth, and terrestrial interfaces. Lunar surface interfaces are interfaces between a LNSP lunar surface node and a user surface node. Proximity interfaces are between a LNSP lunar orbiting node and an orbiting or surface node.

Table 1 - Lunar Network Service Provider Interfaces

This document identifies the standards to be used for the physical and service interfaces described above and depicted in red in Figure 3.

3. USER SERVICES

3.1 Communications Services

There are three communications service types (see Figure 4). Real-time data services provide end-to-end data delivery between source and destination with minimal delay. The latency on these services will be due to the signal travel time, any channel coding, and data operations only. Store-and-forward data services provide end-to-end data delivery with additional latency incurred by storage of data along the end-to-end path. This storage allows for the delivery of data when discontinuities or significant rate buffering occurs along the path. Messaging services provide a means to send standardized messages from LunaNet protocols or applications over specified LunaNet message channels within communications services, while abstracting the specifics of those services from the messaging application.

Interface Name Interface Description Document Section

LNSP-User Lunar Surface Interfaces Surface to surface interfaces between user and provider 4.1

LNSP-User Proximity Interfaces User interfaces with lunar orbiting provider nodes 4.2

LNSP-User DTE Interfaces Interfaces between user lunar systems and provider earth systems 4.3

LNSP-User Terrestrial Interfaces Terrestrial interfaces between user and provider 4.4

LNSP A-LNSP B Lunar Surface Interfaces Surface to surface interfaces between two LNSPs 6.1

LNSP A-LNSP B Crosslink Interfaces Interfaces between two LNSP’s lunar orbiting nodes 6.2

LNSP A-LNSP B DTE Interfaces Interfaces between an LNSP lunar system and a different LNSP earth system 6.3

LNSP A-LNSP B Terrestrial Interfaces Terrestrial interfaces between two LNSPs 6.4

LNIS V004 September 12, 2022 16

Figure 4 - Three Types of Communications Services

Figure 5 is a simplified view of the protocol stack options for LunaNet user applications. The applications are expected to be network-based using either the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol (BP) or Internet Protocol (IP). However, a user application may use link layer services (dashed line) using the Consultative Committee on Space Data Standards (CCSDS) Advanced Orbiting Systems (AOS) standard. The direct use of link layer services is intended for message services for LunaNet applications only and should be deprecated for user applications. Connections to a LunaNet access point over any available link will allow the user’s data to route to its destination. Though LunaNet will provide link layer services, network-based applications will allow for the evolution and scalability of both user and provider systems.

Figure 5 – User Application Simplified Protocol Stack

3.1.1 Real-Time Communications Services

Real-time communications services may be provided at both the link layer and the network layer.

3.1.1.1 Real-Time Link Layer Communications Services

Link layer services will allow the relaying of data at the frame level and requires no processing of user data within those frames. This may be required due to user link layer security or to enable higher speed operations. The link layer service may include the multiplexing, de-multiplexing, and forwarding of user data frames. For interoperability, the link layer services initially will require CCSDS AOS frames. Future

LNIS V004 September 12, 2022 17 transition to available length frame standard is planned to simplify multiplexing and de-multiplexing data frames for users having different frame lengths, because AOS frames are fixed length. CCSDS Unified Space Data Link Protocol (USLP) is an expected link layer standard that will be included later. End-to-end delivery of data over a series of multiple links using link layer services will require pre-configuration of the full end-to-end path and is subject to interruption due to unplanned events.

3.1.1.2 Real-Time Network Layer Communications Services

Real-time network layer services provide end-to-end delivery of data over a series of multiple links with increased functionality and flexibility over the link layer services. The only network layer service guaranteed to provide end-to-end delivery to any network user is the DTN BP. However, operation assumptions for specific user applications will allow successful application support through real-time network layer services provided using the IP. Use of IP requires both source and destination to be operating within a portion of the network capable of supporting IP, such as the lunar surface. IP services are provided over AOS frames on the links described above or commercial standards, such as local wireless systems.

Table 2 provides a summary of the IP service interfaces. Since DTN BP also provides the store-and-forward communications services, the interfaces for BP services are described by Table 3 in the following section.

Table 2 - IP Service Interfaces

Interface Name Description Applicable Interfaces Applicable Documents

IP over CCSDS Encap/AOS

IP packets encapsulated using CCSDS encapsulation service and inserted into AOS frames

All AOS link layer service interfaces CCSDS 702.1-B-1

IETF Standards IP packets over current terrestrial standards

All terrestrial standard based interfaces

3.1.2 Store-and-Forward Communications Services

Interoperable store-and-forward communications services will be provided using DTN BP. In situations where DTN nodes are connected via an IP network, lunar surface networks, terrestrial networks, and/or on-board networks, the DTN bundles can be carried via Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) convergence layer protocols over standard terrestrial internet protocols (see Section 3.1.1.2). For those cases where no direct IP connection is available or not suitable due to the link characteristics, the DTN bundles are carried by either a Licklider Transmission Protocol (LTP) convergence layer with LTP segments encapsulated in encapsulation packets or directly in encapsulation packets, which will be carried over an AOS or USLP link layer (see Section 3.1.1.1). Table 3 provides a summary of these options.

Table 3 - Bundle Protocol Service Interfaces

Interface Name Description Applicable Documents

Bundles / TCPCL Bundles are forwarded via TCP convergence layer adapter over TCP/IP LNIS4-TBD-3001

Bundles / UDPCL Bundles are forwarded via UDP convergence layer adapter over UDP/IP LNIS4-TBD-3002

Bundles / LTPCL Bundles are forwarded via LTP convergence layer adapter over Encapsulation Packet Protocol

CCSDS 734.1-B-1

CCSDS 133.1-B-3

LNIS V004 September 12, 2022 18

Bundles / EPPCL Bundles are forwarded via EPP convergence layer adapter over Encapsulation Packet Protocol CCSDS 133.1-B-3

3.1.3 Messaging Services

Messaging services will provide a standard way for messages to be transferred directly over a link layer service or a network layer service. These messaging services will be utilized by LunaNet applications or protocols. LunaNet applications are applications for service acquisition, PNT, alerts, and other LunaNet services. These standard messages are to be employed across user links, provider crosslinks, as well as direct-to-Earth (DTE) links. Methods for carrying these messages over the other communications service are also standardized.

Figure 6 - LunaNet Applications Simplified Protocol Stack

Table 4 - Messaging Services Interfaces

Interface Name Description Applicable Documents

Message over Link Messages inserted directly into AOS frames for transfer over a single link. LNIS4-TBD-3003

Message over IP Messages inserted into IP packets to allow for multiple IP hops to IP destination. LNIS4-TBD-3004

Message over DTN Messages inserted into DTN bundles to allow for multiple hops to any LunaNet destination. LNIS4-TBD-3005

Message over AFS Messages transmitted over the Augmented Forward Signal (AFS) may be carried in a unique manner to accommodate the low AFS data rate.

LNIS4-TBD-3006

Standardized protocols for navigation (PNT) services, network acquisition, space weather alerts, search and rescue, etc. will define the specific messages for those functions. The messaging services are not intended for user data flows from applications other than LunaNet applications. A generic use of the messaging

LNIS V004 September 12, 2022 19 service is shown below in Figure 7. Messages are being exchanged between a LunaNet node and a user as part of the execution of a LunaNet application or protocol. The messages being exchanged are formatted within a standardized messaging format and carried over the interfaces as indicated in Table 4.

Figure 7 - LunaNet Node and user exchange messages using messaging services

The messaging services will provide methods for identifying message priorities. A publish and subscribe capability may be used for this service, except for specific messages needed for PNT observables via the PNT reference signals described in Section 3.2.1. The AFS link, described later in this document, will carry messages differently than the other space links due to the lower available data rate.

The specific standards for the messaging services are still being determined. Until the messaging services are in place, the LunaNet application messages will be transported along with the user application as depicted in Figure 5. In this case, the messages may be included in CCSDS encapsulation packets directly inserted into an AOS virtual channel. This is depicted by the dashed line in Figure 5. For ease in interpreting the remainder of this document, the message IDs and titles are provided in Table 5. Appendix D provides information on the LunaNet application messages expected to be carried on the AFS link.

Table 5 - Message ID and Titles

Message ID Message Title

MSG-G1 LunaNet Network Access Information

MSG-G2 Health and Safety

MSG-G3 MAntennaProperties

MSG-G4 SOrbit Ephemeris+Clock correction

MSG-G5 MOrbit Almanac

MSG-G6 SOrbit Almanac

MSG-G7 SOrbitState /Location

LNIS V004 September 12, 2022 20

MSG-G8 Time and Frequency Synchronization (fine)

MSG-G9 Time and Frequency Synchronization (frame)

MSG-G10 Maneuver

MSG-G11 SAttitude State/Ephemeris

MSG-G12 MAttitudeEphem

MSG-G13 Observations

MSG-G14 Conjunction

MSG-G15 Maplet

MSG-G16 Map Comprehensive

MSG-G17 Ancillary info

MSG-S18 Search and Rescue Alert

MSG-S19 Acknowledge- of SAR - LvL1

MSG-S20 Acknowledge- of SAR - LvL2

MSG-G21 User Message Request

MSG-G22 Acknowledge- of non-SAR MSG

MSG-G23 GNSS Augmentation

MSG-G24 Detection Alert

MSG-G25 Science

MSG-G26 UIS Request

MSG-G27 UIS Response

MSG-G28 User Schedule Notice

MSG-G29 FF Commands

3.2 Position, Navigation, and Timing Services

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 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 AFS provides PNT functionality independent of dedicated user communications links to enable multiple user reception of the signal simultaneously. Through the build-up of LunaNet nodes, this will establish a Lunar Augmented Navigation System (LANS) as described in section 3.2.2, leading to a Global Navigation Satellite System (GNSS)-like capability for lunar PNT services. Similar to GNSS, a Code Division Multiple Access (CDMA) signal structure will be used for the AFS communications link and can also be applied to dedicated proximity links.

LNIS V004 September 12, 2022 21

For communications links other than CDMA, with a known transmit frequency, the receiver could measure the Doppler shift on the carrier. Non-CDMA links supported by pseudo-noise (PN) codes could provide an alternate method to derive pseudo-range measurements beyond the traditional two-way methods with ground source and measurement. In addition, a method whereby a specific data frame at an integer modulo 1-second based on an accurate and stable time reference source can be used to provide pseudo-range and time-transfer capability on these links.

For full interoperability, additional specifications will be developed as follows:

1. LunaNet and User Signal Structure Definition Document [AD1]

2. LunaNet Measurement Schema and Parameters Document [AD2]

3. LunaNet Detailed Message Definition Document [AD3]

4. LunaNet Location Services for Users Document [AD4]

5. Lunar Reference Frame Standard [AD5]

6. Lunar Time System Standard [AD6]

For effective interoperability in the PNT domain, these signal structures for LunaNet providers and for LunaNet users must be defined [AD1], along with the implementation schemas for measurements [AD2] and lunar reference systems [AD5], [AD6] for obtaining the measurements to ensure consistency in performance.

Appendix D identifies the PNT services and associated messages required for interoperability. The specific service identifications are explained in the subsections of 3.2. The specifics of the messages will be defined in standard protocols used as part of the provision of the services [AD3]. Interoperability also relies on defining the formats and contents; transmission periodicity, cadence, and latency; and prioritization for the messages for each signal type and service.

All PNT services described in sections 3.2.1 through 3.2.5 require the LunaNet provider to have knowledge of its own PVT state, as well as future predicted values. This information is required to be forwarded to users for the consumption of the related services, in the form of messages MSG-G4 and MSG-G5. Appendix D identifies additional messages that can be used to inform a comprehensive state of LunaNet provider node(s) or a LunaNet user.

The PNT services can be grouped into two categories, as shown in Figure 8:

1) Dedicated Links: This group of services include all the options described in the following sections that are not broadcast in 2483.5-2500 Megahertz (MHz). These services are expected to be provided by direct links between the user and the provider. Not all links will provide all the services described in sections 3.2.1 and 3.2.3 - 3.2.5. A dedicated 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.

2) Lunar Augmented Navigation System (LANS): This service is provided from multiple provider nodes to multiple users at the same time, as described in section 3.2.2. The concept is similar to GNSS. This service is provided in 2483.5-2500MHz band via the AFS using the PFS5 signal. This service is expected to be provided with relatively large field-of-view LunaNet antennas to cover a large part of the service volume with the same signal. EOC service will be composed of a collection of LNSP nodes aimed at achieving global lunar coverage of a minimum of four simultaneous LANS nodes in view at any given time. Users employing omnidirectional or hemispherical antennas can therefore receive signals from multiple LunaNet nodes simultaneously.

LNIS V004 September 12, 2022 23

3.2.1.1 One-Way Doppler Reference (1wDRef)

Most radio communications links may be employed for the purposes of obtaining one-way Doppler measurements by a user, provided the user has accurate knowledge of the center frequency employed by the source. This is best accomplished with the use of a fixed frequency transmission.

Differences in the measured frequency by the user will be due to Doppler, as well as frequency offsets from both the LunaNet and user’s frequency oscillator sources. The LunaNet source conveys reference frequency value and deviations via a message, as identified in Appendix D.

3.2.1.2 Pseudo-Range and Timing Reference (1wRTRef)

The pseudo-range measurement approximates the distance between a LunaNet source and the user’s receiver. The source emits a recognizable pattern at a given instant in time, which the user receives moments later, identifies, and timestamps. The delay measurement represents a one-way time of flight.

Depending on the characteristics of the communications link, these patterns will take the form of PN sequences or high-rate frame synchronization and identification (i.e., frame ranging). Frame ranging is the term used in this document to refer to “telecommand/telemetry ranging”, with the telemetry ranging as defined in [RD24], and telecommand ranging definition proposed in [RD25]. While the latter is currently a work in progress, PN sequences have been employed in satellite ranging technologies for quite some time.

PN codes as identified in CCSDS 414.1-B-2 and CCSDS 415.1-B-1 have traditionally been employed for two-way ranging purposes. To use them as an option for one-way measurements, a method (LNIS4-TBD- 3007) must be set in place to convey information to the user correlating source PN phasing and the corresponding time of transmission. Signal structures like those utilized in GNSS, such as PFS5 links described later in this document, include PN sequences that repeat an integer number of times each second.

This establishes a simple method for the LunaNet source to inform users of PN phasing and timing information to form a pseudo-range observation.

Pseudo-range measurements will include errors due to source and receiver time offsets, unaccounted equipment delays on both ends, and time dilation effects. Information concerning errors originating from the LunaNet source is provided to users via messages as identified in the tables in Appendix D.

3.2.1.3 Time-Transfer Reference (Tref)

A standardized method (LNIS4-TBD-3008) for a LunaNet node to provide a time reference will be implemented to allow users to have accurate time.

3.2.2 Lunar Augmented Navigation System (LANS)

The AFS is a special case instantiation of the reference signals described in section 3.2.1. The compatible LNSP nodes will transmit the AFS, as described in sections 3.5.2.1 and Appendix C, in the 2483.5-2500 MHz band (PFS5). A collection of LNSP nodes transmitting the AFS constitutes the LANS, which is illustrated in Figure 10.

LNSP nodes broadcasting AFS shall be synchronized among themselves and against a common reference time scale. Frequency offsets will be estimated against the reference by each provider. The user computes the time of arrival and frequency of the received CDMA signal by using the information provided in the broadcast navigation messages (e.g., ephemeris, clock corrections, and time and frequency information) to compute a pseudo-range, Doppler shift, and carrier phase. Considering the collection of observables from different LNSP nodes and the correlated broadcast navigation messages, the user can autonomously compute its position, velocity, and the difference between the local receiver clock and the LNSP system reference clock. Appendix D contains the mapping of messages to the LANS via the AFS.

LNIS V004 September 12, 2022 24

As with all other PNT services, a common lunar-centric reference frame and time system is defined per section 3.2.6. Each LNSP shall ensure they either implement these reference systems directly (e.g., signals are synchronized with the lunar reference time and the lunar reference frame is used in the navigation products) or provide sufficient information to the user in the broadcast navigation messages to refer to these common reference systems (e.g., broadcast of the time offset of the specific LNSP time to the lunar reference time). Like GNSS, the LANS service will allow the user to compute code pseudo-ranges and carrier phase measurements from the AFS signal. Each LNSP shall ensure the AFS is provided with Signal- In-Space-Error (SISE) limited below the maximum values specified in Appendix C, which allows users to derive consistent and reliable navigation solutions based on AFS signals from multiple LNSPs.

Figure 10 - LANS PNT Concept Provided by LunaNet Nodes

The LANS via AFS is a multiple access forward link and allows reception by multiple users from the same LNSP node (one-to-many). Additionally, it also supports a many-to-one concept (i.e., GNSS-like with AFS signals from multiple LNSP nodes received by one user) owing to the mandatory time synchronization of the nodes, the coordinated generation of PNT-specific navigation messages, and the CDMA differentiation among the LNSP nodes. Further details about the AFS and the PFS5 signal structure are provided in Appendix C.

The LANS service volume identifies the minimum space volume in which the LANS must be provided and performance must be met. For the IOC timeframe the service volume includes lunar surface areas below - 75 degrees latitude and up to an altitude of 200 kilometers, supporting surface missions as well as users in low lunar orbit or in transit to/from the surface. The IOC service volume is depicted in Figure 11.

LNIS V004 September 12, 2022 25

Figure 11 - LANS IOC Service Coverage and Performance Volume

The LANS service volume for the EOC timeframe includes lunar surface areas for all latitudes and altitudes up to a minimum of 200 kilometers for full global coverage of the moon. The EOC service volume is depicted in Figure 12.

Figure 12 - LANS EOC Service Coverage and Performance Volume

3.2.3 One-Way Measurements

One-way measurements performed by LunaNet nodes are in reverse fashion to what is described in section

3.2.1 and explained herein and depicted in Figure 13. The users generate signals similar to the construct of a LunaNet transmitted reference signal, so that they enable LunaNet nodes to compute one-way Doppler and pseudo-range observables from the user. The resulting one-way measurement observables are forwarded to the necessary element via MSG-G13 messages, as identified in Appendix D.

LNIS V004 September 12, 2022 26

Note: A navigation system may elect to complement LunaNet observations with other measurement types, but those are not addressed in this document. Note: A navigation system may elect to complement LunaNet observations with other measurement types, but those are not addressed in this document. Note: A navigation system may elect to complement LunaNet observations with other measurement types, but those are not addressed in this document.

Figure 13 - One-Way Measurements Performed by a LunaNet Node

3.2.3.1 One-Way Doppler Measurement (1wDMeas)

One-way Doppler measurements may be carried out for most incoming radio communications signals by tracking the frequency of the received signal and reporting the delta with respect to a defined source frequency. These measurements become valuable when the original frequency transmitted by the user is known. The quality of the measurement will depend on the stability of the user’s frequency source, as well as the signal-to-noise ratios of the received signal. Errors due to frequency offsets between user and LunaNet frequency references may be estimated by the corresponding navigation system. Users employ messages, as identified in Appendix D, to convey their transmitted frequency values and deviations.

3.2.3.2 Pseudo-Range Measurement (1wRTMeas)

The pseudo-range measurement is as described in section 3.2.1.2, though for a measurement concept the user generates the constructed signal that is utilized by the measuring LunaNet system to obtain a pseudo-range observable. The LunaNet system must be compatible with, and knowledgeable of, the ranging signal characteristics employed by the user as indicated in the LunaNet and User Signal Structure Definition [AD1] interoperability specification.

Pseudo-range measurements will include errors due…