Section 5 - esc.gsfc.nasa.gov

16th International Conference on Space Operations, Cape Town, South Africa – 3 - 5 May 2021. Copyright ©2021 by the International Astronautical Federation (IAF). All rights reserved. One or more authors of this work are employees of the government of the United States of America, which may preclude the work from being subject to copyright in United States of America, in which

event no copyright is asserted in that country.

SpaceOps-2021,8,x1327 of 19

SpaceOps-2021,8,x1327

LunaNet Architecture and Concept of Operations

David J. Israel a*, James Schier b, Andrew Petro b, Wallace Tai c, Evan Anzalone d, Avinash Sharma e

a NASA Goddard Space Flight Center, Greenbelt, MD USA b NASA Headquarters, Washington, DC USA c Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA USA d NASA Marshall Space Flight Center, Huntsville, AL USA e The Johns Hopkins University Applied Physics Laboratory, Laurel, MD USA * Corresponding Author

Abstract

The LunaNet architecture will provide services to missions in lunar orbit and on the lunar surface. LunaNet's networked communication services among its nodes and users will be through the delay/disruption tolerant network (DTN) Bundle Protocol. Although position, navigation and timing (PNT) services may initially be provided from Earth-based resources, the LunaNet architecture promotes lunar operational independence and increased precision. These services may be derived by users from observables of the communications signals and are provided within network bundle data units. LunaNet includes detection and information services capable of detecting space weather and other events and providing notification to protect crewmembers and space assets. The interoperable nature of the LunaNet architecture encourages global participation: commercial partners, international partners, other government agencies, academia, federally funded research development centers and NASA. This paper summarizes the LunaNet architecture and services and describes concepts for an implementation approach comprised of multiple LunaNet service providers, including lunar relay elements, possible lunar surface elements and Earth ground systems. Keywords: LunaNet, Networking, Interoperability, Lunar, Communications, Navigation

Acronyms

BP Bundle Protocol C&N Communication and Navigation

CCSDS Consultative Committee for Space Data Systems

CIA Confidentiality, Integrity, and Availability

CPNT Communications, Position, Navigation, and Timing

DOR Differential One-Way Ranging DSN Deep Space Network

DTN Delay/Disruption Tolerant Networking

EDL Entry, Descent, and Landing EVA Extravehicular Activity GN&C Guidance, Navigation and Control GNSS Global Navigation Satellite System GPS Global Positioning System

GW Gateway spacecraft / NASA Gateway Program

HLS Human Landing System

ICSIS International Communication System Interoperability Standards

IEEE Institute of Electrical and Electronic Engineers

IOAG Interagency Operations Advisory Group

ISS International Space Station LNS LunaNet System LNSP LunaNet Service Provider LNSU LunaNet Service User MOC Mission Operations Center NME Network Management Element NOC Network Operations Center NSN Near Space Network NTP Network Time Protocol O3K Optical On-Off Keying PN Pseudo-Random Noise/Pseudo Noise PNT Position, Navigation, and Timing PVT Position, Velocity, and Time QoS Quality of Service RF Radio Frequency SAR Search and Rescue S&MA Safety and Mission Assurance SFCG Space Frequency Coordination Group SLA Service Level Agreement




SOA Service-Oriented Architecture SSI Solar System Internet SWaP Size, Weight and Power

TASS TDRSS Augmentation Service for Satellites

TDRSS Tracking and Data Relay Satellite System

TC Telecommand (in connection with CCSDS)

TM Telemetry (in connection with CCSDS)

TT&C/ TTC Tracking, Telemetry, and Command

VLBI Very Long Baseline Interferometry WLAN Wireless Local Area Network XNAV X-Ray Navigation

1 Introduction Space exploration and scientific discovery advance our knowledge of the universe and inspire innovation. Current

plans envision multinational expeditions with many countries cooperating to expand humanity’s presence at the Moon and beyond. In the next decade, scores of missions will be launched to the Moon, and will establish a sustained lunar presence.

Greater distances and extended durations require robust communication and navigation systems. Lunar missions will benefit from a flexible architecture to provide a phased approach for essential communications, position, navigation, and timing (PNT), and other services, collectively referred to as Communication and PNT (CPNT) services. This architecture also provides additional science measurements and event detection services, giving assets situational alerts.

A phased approach recognizes with initial capabilities, capacity, and coverage to support a small number of robotic spacecraft will expand within the decade to meet the rapidly growing needs of the human exploration and science campaigns. Strategic implementation of each phase fosters the development of innovative technologies, enhances capabilities, and increases the quantity and sophistication of future missions.

A flexible and open architecture adapts to the dynamic needs of many missions through a network-of-networks using a Service-Oriented Architecture (SOA) that provides services to cislunar spacecraft and space systems. Standardized services are compatible with each other even when provided by different networks through common application of standard frequency bands, interfaces, and protocols. These networks will be owned and operated by an international set of government agencies, commercial, and academic organizations.

This document defines the operational concepts and architecture for the lunar network, known as LunaNet, and provides the framework needed for any cooperating organization to become a LunaNet Service Provider (LNSP) or a LunaNet Service User (LNSU), i.e., a provider or a user.

2 Overview and Terminology

2.1 LunaNet Overview LunaNet is envisioned to be a set of cooperating networks to provide communications and navigation services to

users on and around the Moon. The LunaNet concept is based upon a framework of mutually agreed-upon standards, protocols, and interface requirements that enable interoperability. LunaNet is intended to allow many lunar mission users – as varied as CubeSats, fixed and mobile surface robots, and human outposts – to engage the services of diverse commercial and government providers in an open and evolvable architecture.

LunaNet is not a particular satellite or constellation of satellites, nor is it a project, program, or organization; it’s a conceptual framework realized by a set of service providers for the benefit of users. This framework can be introduced from the beginning of robotic lunar mission operations and expanded as new spacecraft and missions come online [1]. LunaNet is established using existing ground networks such as those operated by the National Aeronautics and Space Administration (NASA), the European Space Agency (ESA), and the Japanese Aerospace Exploration Agency (JAXA), as well as commercial and academic organizations.

Each organization that operates a network providing lunar CPNT services is called a LunaNet Service Provider (LNSP). Each LNSP decides which standard services to offer via its network, or LunaNet System (LNS). Offered services must comply with the LunaNet architecture to achieve interoperability. Each LNSP establishes agreements with other LNSPs for internetworking in compliance with an LNSP Internetworking Standard. Figure 1 shows the two publicly exposed interfaces – User Services and Internetworking – that create LunaNet. Missions that use LunaNet services are Service Users.




Figure 1. LunaNet is Based on Standard Interfaces for User Services and Internetworking

Figure 2 shows the initial space assets created for LunaNet using existing ground networks that provide services to lunar missions. Existing ground networks form the initial operational LunaNet architecture.

Figure 2. Early LunaNet Architecture – New LunaNet Assets Use Existing Ground Networks Figure 3 shows that the fully developed LunaNet has, for each LNSP, an Earth segment (e.g., ground stations and

network control centers) and a space segment that could comprise a range of off-Earth assets that could be located: • in Earth orbit (relays that may serve lunar users as well as other missions), • in lunar orbit (dedicated relays and relay payloads on user mission spacecraft), and/or • on the lunar surface (e.g., base station terminals and local network nodes).

In addition to relay capabilities within the network, any provider element can provide point-to-point capabilities. For example, an element in lunar orbit can provide PNT services to users, enabling user autonomous navigation. The individual links allow for data transfer between any two elements (nodes) in the network, with the relays acting as data routers and PNT references. LunaNet elements can also provide services directly to each other, allowing for coordinated operations and mission support. LunaNet nodes providing PNT services will make use of onboard sensor systems to maintain onboard knowledge of state, i.e., 3-dimensional position and velocity at a specified time, to a high level of accuracy. This process may include synchronization with other Earth-based services such as Global Navigation Satellite Systems (GNSS); astronomical sources such as X-ray navigation (XNAV); or optical navigation (OpNav) [2]. Nodes operate within the architecture to anchor the timing and location information of other elements. In this way, nodes support PNT independent of Earth-based assets, and enable the network to be autonomous and robust.




LunaNet consists of multiple LNSs provided by different organizations (LNSPs) offering services to user missions. Some spacecraft can be both “users” and “providers;” for example, a LunaNet relay payload can be included on a robotic science spacecraft. Therefore, LunaNet is intentionally agnostic with respect to ownership and is equally applicable to any ownership model.

Figure 3. LunaNet Architecture Overview

LunaNet will be implemented in a series of incremental phases driven by major phases of human exploration and scientific discovery missions:

• Initial Architecture: 2021-2024 – early robotic missions and crewed missions returning humans to the Moon. Initial LunaNet capability will become operational. At least one lunar relay will launch to support far-side robotic landers and science missions, as well as to provide coverage at the southern polar site.

• Enhanced Architecture: 2024-2028 – expansion of scientific capabilities and establishment of a sustainable human presence. The number of surface sites and missions will increase. LunaNet services and capacity will expand as more service providers join.

• Sustainable Architecture: Beyond 2028 – sustained scientific and human lunar capabilities. Service users will conduct Mars analogue missions in the cislunar region to prepare for eventual human missions to Mars. LunaNet will continue to expand capacity and coverage as required to meet mission needs.

LunaNet is similar to the terrestrial internet in several ways: [1] • Network Organization: LunaNet is characterized by a set of nodes and links arranged in a physical and logical

network topology. Physical topology is the placement and connection of the various components of a network (e.g., asset location and cable installation, or antenna field of view), while logical topology illustrates how data flows within a network (e.g., across a grid of connected nodes). Nodes provide services to users (edge nodes) or support data transmission to other LunaNet nodes (internal nodes). Links connect nodes by wired or wireless means of transmission. Transmission occurs over the radio frequency and optical portions of the electromagnetic spectrum. Links permit inter-asset PNT observations, enabling time synchronization, clock disciplining, and orbit estimation through onboard processing.

• Open Architecture: LunaNet operates using an open architecture based on publicly available information. Specifications and protocols are public and intended to allow for modification and evolution. LunaNet is composed of a community of service providers and service users who voluntarily agree to abide by a set of standards and conventions that enable cooperation. Service Providers are organizations that operate network(s) to provide CPNT services to a set of entities that use those services to meet their objectives. Service Users are organizations that operate spacecraft or space elements with associated terrestrial capabilities and require CPNT services to operate their systems. LunaNet relies on standards to achieve interoperability among providers and users. As a result, no one owns LunaNet. The LunaNet community includes government, commercial, and academic entities; it could eventually include individuals as well.

• Unlimited Scalability: LunaNet services can be provided to a nearly unlimited number of users since additional service providers, assets, frequency reuse, and frequency bands can be added over time to increase aggregate bandwidth.




• Ease of Evolution: LunaNet provides the ability to demonstrate new technologies as well as to conduct engineering tests of pre-operational capabilities simultaneously with provision of operational services. Once tested, these new technologies can transition readily into operational use.

LunaNet differs from the terrestrial internet in several ways, offering advantages that Earth’s internet cannot. LunaNet is:

• "Born Secure:” The internet was originally designed without regard to security because no one anticipated malicious activities to deny, degrade, disrupt, or destroy communications. While the internet has evolved to become more secure over the past several decades, the cost of network security is high – and rising higher – while the scope of malicious activities has continued to outpace attempts to contain them. From the outset, LunaNet leverages everything known today about network security, including: Confidentiality, Integrity, and Availability (CIA), secure communication and networking protocols, encryption, and other features. Future LunaNet technologies, with security advantages, include optical communications.

• Highly mobile and intermittently connected: The internet was conceived for fixed installations of computers, message processors, and wired connections. Wireless technologies have extended the internet, adding new topologies such as mesh networks and mobile connectivity to systems moving at relatively slow speeds (e.g., cars to aircraft). LunaNet serves space systems moving at orbital speeds. Satellites come into view of potentially connecting systems and out of view within minutes, requiring rapid establishment and disestablishment of connections. LunaNet defines services to enable inter-asset awareness and synchronization of time with other networks. Shared knowledge permits cross-element operational coordination and enables accurate element-to-element operations (such as pointing maneuvers used to acquire and track communication signals). By providing common understanding of where physical elements are at a given time, LunaNet can expertly coordinate and distribute information.

• Interoperable and capable of incorporating special system functionality: The U.S.’s Global Positioning System (GPS) was conceived as a military capability to disseminate time and position information to military systems around the world. It evolved into a joint civil-military system whose capabilities have been incorporated into a vast number of internet applications, cellular telephones, and other systems as well as spawning development of international GNSS. LunaNet provides similar PNT services as core capabilities to enable operations around and on the Moon. Sharing of navigation information between users and services enables autonomous navigation and precise timing for coordination and delivery of vital commercial services and military capabilities. LunaNet incorporates these PNT capabilities and directly avoids the need for a separate “lunar positioning system.”

The need for interoperability becomes apparent from several perspectives: [3] • Interoperability enables each Service User spacecraft or space element to take advantage of roaming – using

whichever Service Provider’s asset is in view – offering higher overall availability, dissimilar redundancy for high reliability, and multiple paths to and from Earth for higher capacity and coverage.

• Interoperability can result in cost savings. Each Service User spacecraft only needs to develop or procure communication subsystems that work with the interoperable services provided by all Service Providers, allowing use of off-the-shelf equipment, reducing development costs, and offering competitive procurement of operational services.

• Interoperability allows each Service Provider to offer services to an expanding cislunar market. As the cislunar market grows, so does the Service Providers’ business opportunity. Government agencies may choose to partner with emerging commercial Service Providers that are capable of being technologically agile and cost effective.

• Interoperability enables more effective aggregate use of fixed spectrum resources by allowing Service Users flexibility to use a variety of frequency bands.

2.2 LunaNet Service Types LunaNet CPNT services include networked communications, PNT, detection and information, and science

services, as shown in Figure 4. Networked communications services are based on Internet Protocol (IP) or Delay/Disruption Tolerant Networking (DTN) Bundle Protocol (BP). Use of BP allows networking services to function between any two nodes anywhere in the LunaNet, while IP allows for end-to-end data delivery within certain regions and operational conditions [4]. Data link layer services are supported, but network layer services are preferred. PNT services provide tracking, ranging, and timing to support user orbit or position determination and trajectory management. Detection and information services disseminate data from authenticated sources to subscribing users,




including notifications and detection of events such as astronomical events, crew safety alerts, and broadcast messages containing network updates and space situational awareness notices. Finally, LunaNet can be used in some cases as a scientific sensor, corroborate data from a science instrument, or contribute CPNT data used to calibrate an instrument or reduce its errors. These capabilities support radio astronomy and other space sciences.

Figure 4. Types of LunaNet Services

The implementation of the LunaNet infrastructure can take many forms, with a combination of Earth-based ground

stations, lunar relays, lunar orbiting assets, and surface elements serving as nodes in the network-of-networks topology. Communication and navigation payloads hosted on a variety of spacecraft could provide relay and PNT services.

3 LunaNet Concept of Operations

3.1 General Operations Concept In contrast to traditional link-centric operations, LunaNet takes advantage of interconnected network nodes and

creates a network-of-networks extending from Earth to the Moon. As human and robotic exploration increases, it becomes less feasible for each asset to have its own direct-to-Earth communications link due to increasing spectrum contention. LunaNet mitigates this issue through use of LNS communication relays located close to the user’s space system. This has two benefits: a) It allows the user to send data at a higher data rate at lower power, which reduces the duration of connections and, thus, the use of spectrum; and b) It allows providers to aggregate the data generated by many users into a single link, thus achieving more efficient use of spectrum.

Space-based users, surface assets, and lunar orbiters can all utilize LunaNet’s network nodes as access points, analogous in functionality to terrestrial Wi-Fi routers and cellular towers. If a mission asset has connectivity to the network, and the network has adequate capacity to meet the user’s operational requirements, the Service User can ignore the number of hops there are between the Service User’s source and the intended data destination.

Multiple organizations can act as LunaNet Service Providers. The primary LNSP selected by a Service User has responsibility for handling the operational complexity associated with routing data traffic between user source and destination nodes. Standard services should be available from any LNS consistent with Figure 1. The interfaces and methods for obtaining those services may vary between LNSPs but the service interfaces should be standardized to make services more accessible to users.

Each LNSP will be responsible for the management and control of its LNS. An LNSP will provide services and interfaces to Service Users, as well as to other LNSPs. A LunaNet user may receive services from access points maintained by its primary LNSP; however, the data may travel through multiple LNS networks before reaching its destination. An individual user will work with a single primary LNSP for mission planning, ongoing operations and scheduling; and that LNSP will make the necessary arrangements, agreements, and schedules to allow the user to receive services from another LNS. The primary LNSP has responsibility for handling the operational complexity




associated with routing data traffic between user source and destination nodes, though part of the end-to-end path may require services from other LNSP(s). In some cases, a user may choose or be required to work with a second LNSP to receive essential services; ideally, both LNSPs would endeavour to reduce any resulting operational burdens to achieve an optimal user experience.

Some user mission events such as orbit insertion, docking, and landing, entail higher risk to the mission but are critical to mission success. LNSPs may be required by Service Users to provide enhanced support during these events. For the duration of the event, this may include guaranteed availability of specific links, added redundancy (including support from other LNSPs), and higher staffing for rapid response to off-nominal conditions.

3.2 Services Each LunaNet node may be capable of providing four standard service types: Networked Communications, PNT,

Detection and Information, and Science (Figure 5). The degree to which a node provides services of different types may vary. For example, it is possible that some nodes will provide only networking or only PNT. The performance levels of each node may vary as well. • Networked Communications Services (Com): Data transfer services capable of moving addressable and routable

data units between nodes – in a single link or over a multi-node, end-to-end path – via networking. • Position, Navigation, and Timing Services (PNT): Services to determine position, velocity and time as well as

determine orbit parameters and disseminate data relevant to other navigation functions. This includes Search and Rescue (SAR) location services.

• Detection and Information Services (Det): Event detection and notification generate timely alerts to protect crewmembers and space assets. These services disseminate information detected by instruments such as space weather (e.g., solar particle events) and cosmic events (e.g., detection of stellar bursts) to users as well.

• Science (Sci): Services that use radio frequnecy and/or optical capabilities of the node as a science instrument or part of an instrument.

Figure 5. A LunaNet Node Combining the Standard Service Types

3.2.1 Networked Communication Services A LunaNet node providing Com services will enable networked communications across multiple space-based

assets. With LunaNet capabilities, a rover on the Moon can communicate with an orbiter in space and so on, creating an end-to-end path for data.

As with network service on Earth, a LunaNet User will not need to have knowledge of the underlying link topology or DTN functionality to carry out a mission. LunaNet’s standard operating protocols encapsulate (i.e., hide details from the user) the process of managing network topology and data routing. Figure 6 shows, in a simplified diagram, how the fundamental architecture provides a variety of services from Node 1 to User A but does not expose User A to details of the communications links (Node 1-Node 3, Node 3-Node 4, Node 4-User B) and networking (routing) required to deliver data to User B. Well-defined standards enable LunaNet’s building blocks to become a scalable, highly functional architecture. Each node is required to be interoperable with any other directly connecting node. Networking standards then allow the establishment of one or more multi-node paths between the two endpoints.




Figure 6. User A Receives Services through Node 1 and Communicates with User B through LunaNet

Nodes may be provided by different LNSPs. Figure 7 expands on Figure 6 to show how the path could be handled by more than one LNSP. The interface is transparent to the user but must be approved by the LNSPs operating the two networks to support both the actual communications that provide the path for the user’s data and the service management coordination to establish the link between Nodes 3 and 4.

Figure 7. End-to-End Path through Two LNSP Requires Internetwork Service Management

The architecture will aggregate links, funnelling different sources of data to come together to one point combining those sources into a single stream of data, as appropriate, to more efficiently use available links and to minimize the total number of links required.

If each node is capable of interoperating with its immediate neighbor and relaying data at the necessary link and/or network layers, the LunaNet architecture can be assembled through multiple infrastructure systems. The use of standard interoperable protocols for network layer functions is essential to allow the exchange of data across multiple hops or links.

DTN BP will be the network layer protocol that provides end-to-end connectivity across the full LunaNet using bundles. Only adjacent nodes must be interoperable down to the physical layer in order to transfer DTN bundles over their immediate links. Therefore, not all nodes need to be fully interoperable to be part of the LunaNet infrastructure. For example, a lunar surface-to-relay link could be based on commercial standards that are not part of the current IOAG standards. If those links can carry bundles or tunnel other framing, they may still act as an integral part of the network. A relay would then insert the bundles into a fully IOAG-compatible trunk link back to Earth. The use of non-standard lower layer protocols may have consequences - increasing the complexity of user communication systems or restricting certain access points. The choice, however, may reduce some costs and present a path for some providers to build out part of the infrastructure.

3.2.1.1 Link Layer Services A user may prefer to receive link layer services only, i.e., the transfer of data frames. However, this service does

not allow for any routing or storage at intermediate nodes. A series of nodes may be connected by a series of link services to produce an end-to-end circuit between source and destination. This connection may be necessary when




user communications are not interoperable above the link layer due to encryption or other factors. Some intermediate nodes may switch or forward data at the link or lower layer to minimize onboard processing requirements to reduce latency or to support very-high-data-rates such as trunk links.

3.2.1.2 Network Layer Services Networking services based on the use of the DTN BP will act as the foundation for network layer communication

services to users over paths that cannot guarantee end-to-end short delay connections. BP supports end-to-end networking functionality with the bundle serving as the network data unit, allowing networked communications between any two nodes connected to LunaNet. Any node that is to provide DTN network layer services must include a DTN bundle agent. The DTN bundle agent will be capable of storing bundles when individual links are unavailable and forwarding bundles when they become available (i.e., an active connection). It will also be capable of inserting and removing the bundles from the lower layers, as required, to communicate over its immediate links [4]. Note that some nodes in the lunar or Earth systems may perform IP routing; however, IP is not guaranteed to be able to provide full end-to-end data delivery to all nodes in the larger LunaNet. Regions that use local wireless, proximity links, or onboard local area networks, to connect all nodes within that region may use IP within that local region. In those cases, bundles will be inserted into IP packets to travel through that region or to reach an endpoint in that region.

Figure 8 illustrates an example of network layer services supporting BP-based applications communicating between a user’s lunar surface rover and a user’s mission operations center (MOC) on Earth over a BP network. The physical view (top) shows the nodes on the physical path and the type of link connecting each pair of nodes. The network view on the bottom shows the user nodes and their interface to the network, whose internal path and protocol conversions are hidden from the user. The protocol stack view (middle) reveals the complete set of protocol stacks employed across the nodes along the path. BP provides the end-to-end networking with the possibility of assured delivery of user data in spite of the potential or periodic loss of connectivity between nodes on the path, e.g., when the lander is not in view of the ground station, while portions of the path incorporate IP to connect two adjacent bundle nodes of a particular bundle hop or “bop.”

Figure 8. Example Networking Service for the end-to-end path between the Rover and Science Operations

Center. Note that IP can be employed to transport bundles on bops where IP is functional.

The provision of networking services implies that the provider network is able to maintain and update routing information; intermediate nodes determine how to move data towards the destination or put the data into storage until the right link becomes available.

Networking services introduce the potential for network security vulnerabilities, like those experienced in the terrestrial internet. Such vulnerabilities must be addressed. LunaNet achieves a secure architecture by incorporating a layered approach, including bundle layer security for DTN networking.

Lander Ground Station

Science Operations

CenterRover

Bop1 Bop2 Bop3

App

TCPIP

LNKPHY

TCPIP

LNKPHY

BP BP

BHP

LNKPHY

TCPIP

LNKPHY

BP

BHP

LNKPHY

App

TCPIP

LNKPHY

BP

BP Network

IP Network

IP NetworkRover

Science Operations

Center

Legend:App: ApplicationBHP: Bundle Hop Protocol(s)Bop: Bundle HopBP: Bundle ProtocolIP: Internet ProtocolLNK: LinkPHY: PhysicalTCP: Transmission Control

ProtocolTCPCL: TCP Convergence Layer

Adapter

TCPCL TCPCL TCPCL TCPCL




3.2.1.3 PNT Message and Coordination Services LunaNet will employ several existing standards to cover mechanisms for transferring tracking measurements,

states, and timing references within the LunaNet framework. Current Consultative Committee for Space Data Systems (CCSDS) standards allow for robust mechanisms to support PNT functions [6]. For example, all nodes within LunaNet will maintain onboard knowledge of the current time and location (ephemeris), and provide information on its projected state (i.e., any planned maneuvers), as well as information regarding its onboard uncertainty. The spacecraft needs to integrate PNT navigation observables (data types) to generate additional information needed to close the loop onboard and enable the spacecraft to perform autonomous processing and state estimation. Estimates focus on knowledge of the vehicle’s state referenced to where it is traveling (whether fixed or in orbit). The precision of this knowledge directly limits the accuracy of the state estimation. To improve estimation, primary nodes within LunaNet will maintain high accuracy state knowledge provided by either Earth-based tracking or autonomous observations to some other reference. One method utilizes optical navigation to process an image of an object with a known state to determine the vehicle’s state [7]. An alternate use case is for the various Service Users in the network (spacecraft, fixed surface nodes, or mobile surface nodes) is to share their state information with each other, which is needed for situational awareness and coordinated maneuvering - for rendezvous or collision avoidance. The following sections describe this in detail, explain the need for data, and outline potential implementations within the LunaNet framework.

Terrestrial and space networks utilize several formats to facilitate data transfer. A key factor in determining which format(s) to use will be the location of the assets. For example, broadcast knowledge needed for a fixed surface asset will be less complex than for an element in a three-body orbit. As different user and provider systems are added, it is important to identify and standardize the data formats shared between users. Several types of ephemeris transfer mechanisms will be included within the network to support users. This data will be maintained at central relay locations for distribution, available on request from LunaNet Users.

3.2.2 PNT Services Future missions in space will require support for coordinated cislunar activity and autonomous operations. For any

asset approaching lunar orbit, in lunar orbit, or operating across the lunar surface, distributed PNT services are needed to provide onboard knowledge of the asset’s current location and globally referenced time. LunaNet services will pass critical PNT information to both ground and orbital elements. Consider the scenario of a spacecraft preparing to point a high-gain antenna toward another asset for a pre-planned communication pass. With LunaNet’s PNT services, a User’s MOC or an autonomous user spacecraft can plan when to point, where to point, when to enable onboard radio, when to begin and end transmissions, and how to maintain pointing during the pass. This enhanced knowledge enables high accuracy pointing, maximizing received power and enabling increased bandwidth throughout the network. Accurate and stable timing improves data rates and the efficiency of the individual spacecraft, enabling greater coordination and planning across the architecture. An external method for updating state knowledge allows a system to operate autonomously (e.g., using cognitive communications) or perform coordinated activities with other systems. Specific applications might include onboard planning of orbital change maneuvers, descent operations, or autonomous surface exploration [8].

Establishing local services in cislunar space also reduces demand on ground-based assets by pushing tracking capabilities into the space-based portion of the architecture. Determining absolute positioning with Earth-based networks traditionally involves taking lengthy observations of spacecraft radiometric characteristics, such as coding phase change or Doppler shift, and processing with ground-operated algorithms to develop an updated state for mission planners. As ground infrastructure supports more operational assets simultaneously, less time will be allowed per spacecraft. Current strategies to address this trade-off include placing multi-user simultaneous operations on a single antenna or expanding the number of ground assets. LunaNet will shift PNT capability to the local planetary networks; and, in so doing, create autonomous capabilities for selected celestial bodies throughout the solar system.

LunaNet PNT services can be characterized in terms of the function(s) being supported. Because each element in the architecture provides some measure of cross-vehicle support, an individual element may act in multiple modes – as a relay, a ground station, or a mobile user (whether constrained to surface operations or not). In terms of navigation, these functions break down as shown in Tables 1, 2, and 3. The following sections provide detail on planned functionality, implementation, and interfaces.

Table 1. Description of Positioning Services

Function Description Generate ranging observable Produces time-synchronized ranging code.




Function Description Operate as turn-around relay Enables two-way ranging between elements, using a known code where the

transmission source also performs measurement. Identify and measure range to transmitting assets

Uses code phase and time of reception to produce a range estimate between two assets.

Measure Doppler frequency of received signal

Calculates Doppler shift (received frequency vs. expected frequency) and provides information on relative velocity between two assets along the line of sight.

Provide measurements via telemetry Transmits the measurements of relative range and range-rate to a receiving vehicle via standard telemetry.

Measure onboard position using in situ measurements

Estimates state using onboard sensors, such as optical navigation or low-signal GNSS, to determine an autonomous estimate of location.

Table 2. Description of Navigation Services

Function Description Process multiple measurements into an integrated PVT solution

Uses algorithms to integrate a set of independent, single-dimensional measurements to provide an estimated state, either as an onboard or external service.

Transmit integrated PVT state to user

Communicates estimated PVT state to a user in external tracking scenarios. Enables onboard/autonomous operations.

Transmit vehicle ephemeris for use in measurement processing

Provides current spacecraft state to allow processing and integration of low-dimensional measurement. Enables onboard estimate of state.

Table 3. Description of Timing Services

Function Description Maintain a stable onboard time reference

Utilizes high-stability onboard oscillators or time source or external measurements to maintain a stable time-base.

Provide a coarse time synchronization capability

Broadcasts current time scale in a two- or one-way transmission to update onboard estimates of current global time.

Provide fine time synchronization capability

Uses specific ranging and broadcast code within signals to permit high-accuracy disciplining of clocks within the network.

LunaNet PNT services also build on the foundational architecture developed and designed for Earth-centric

operations (such as the proposed terrestrial Space Mobile Network) that take advantage of concepts developed for and tested on the Tracking and Data Relay Satellite System (TDRSS) Augmentation Service for Satellites (TASS) [9][10]. TDRSS transmits accurate, in-space reference signals for PNT, providing a present-day analogy to a future lunar-focused implementation. The following sections describe the foundational services to enable LunaNet PNT, with many parallels to the TASS approach. Tracking and positioning services will focus on the mechanization of relative state measurements between nodes. LunaNet timing services will establish accurate knowledge, at the node level, of when the measurements occurred and allow for integration and processing into an absolute state, in addition to relative tracking between nodes.

3.2.2.1 Tracking and Positioning Services To determine one’s location in space, measurements must be made to some known reference(s). Modern navigation

systems take measurements that can be categorized according to several fundamental properties: range to a known location, velocity relative to some point, or bearing to some object. For positioning within a 3-dimensional space, systems gather a minimum of three unique measurements. Additional observations, taken simultaneously, help to reduce positioning errors; they may also help users estimate system errors. For example, to obtain an instantaneous GPS fix, systems routinely measure ranges to four different satellites. The fourth measurement removes any user-side clock biases that could affect the actual range measurements. Additionally, with information about the dynamics of the system, whether the asset is in orbit about the Moon or Earth, filtering algorithms can be used to integrate time-separated, one-dimensional observations. For a satellite passing overhead, observations of range or range-rate between




ground station and spacecraft can be processed together to perform an estimated state of the spacecraft’s position and velocity. The base tracking observables within LunaNet consist of bearing angles between nodes, range between nodes, and range-rate between nodes. Tracking these observables is important for LunaNet, which will not have a separate GPS-like constellation to provide instantaneous fixes.

Measurables can be directly observed by a specific node within LunaNet or provided to LunaNet by an external reference. For radiometric (and in the future, optimetric) systems, two-way ranging is a baseline approach to tracking a node. In this architecture, a tone with a known frequency is transmitted from a navigation host to a node, which then sends that same signal back to the host. The host then compares the tone received to the one generated to determine the distance between the two elements (measuring time of flight). Two-way ranging thus involves a signal traveling from a host to a node and back. The resulting observations can be provided to the user as range measurements for inflight processing. Proximity operations use two-way ranging, for example, to track relative positions of spacecraft. In an alternate approach, measurements are collected over a period of time and processed to estimate the position and velocity of a vehicle with critical measurements then transmitted back to the host. In a one-way tracking system, there is sufficient information to recreate the original tone at the host. GNSS systems, use one-way ranging [11]. This approach provides on-host measurement processing but requires additional onboard timing accuracy and processing capability for generation and correlation of the received-versus-expected signals. LunaNet tracking services will support both types of ranging observations, allowing users to select the solution best suited to its capabilities and requirements.

LunaNet will also support Doppler Tracking (DT) between nodes. In DT, the transmitted signal provides insight to the relative motion between the node and host. The frequency shift can be correlated to a range-rate and utilized in orbit determination (OD) routines to update the user’s current state. The accuracy of this measurement depends on the stability of the transmitting node. Relay nodes within LunaNet are designed to have stable time and frequency generation to support accurate DT. Data can be collected onboard the host from a node or captured at a node based on the user’s signal and then provided to the user or utilized in host OD routines.

The one-way and two-way approaches to ground-based tracking are used extensively to support space vehicle navigation and are standardized within NASA’s Deep Space Network (DSN) and Near Space Network (NSN). Similarly, they serve as an integral part of tracking nodes within the LunaNet architecture. Several experiments have been performed to show the promise of expanding these services within the overall architecture [12]. Two-way ranging functionality will expand to all elements within LunaNet to enable inter-asset relative and absolute navigation.

The above sections described two tracking and positioning services: range to a known location, and velocity relative to some point. The remaining key observable is bearing angle to a known reference. In an onboard tracking application, this requires knowledge of the user’s state at the time of observation, while in a navigation solution, the location of the host node is known and angles to the user provide an estimate of the user’s state. The latter can be captured in multiple ways. For high accuracy ground stations, one approach is Delta Differential One-way Ranging (Delta-DOR) which uses well-known angular positions of high-energy galactic sources to serve as anchors to identify a broadcasting user’s location in the sky. This approach can result in a high-precision angular measurement, with multiple observations noted to solve for a user’s state. Other approaches use optical observation from an onboard camera for near-field relative navigation (OpNav) or radar observations for longer-range operations [7].

Surface users will require additional tracking services to support direction-finding to a known reference. For example, emergency tracking scenarios enable these elements to understand direction and range to a reference point. For scenarios with limited ground infrastructure, this type of tracking involves radio direction-finding techniques. As LunaNet infrastructure grows, more advanced techniques can be performed based on inter-relay ranging and power signal observation. These services form the basis of LunaNet surface navigation services.

LunaNet tracking capabilities will expand as more users join the network, and infrastructure is established to support new mission scenarios. Initial implementations focus on the use of LunaNet ground stations to provide tracking observables and integrated state solutions. As elements are deployed in lunar orbit and to the lunar surface, tracking capabilities will evolve, permitting enhanced observation geometry, accuracy, and availability. Lunar surface elements will provide tracking capability for extended extra vehicular activities and provide direction-finding support to surface users. Future deployments may include dedicated lunar tracking stations in cislunar space, which could provide local tracking services to multiple users. They may also serve as high accuracy, well-defined reference points.




3.2.2.2 Time and Time Dissemination Navigation observables must be integrated to provide an estimate of a spacecraft’s position and velocity state. Part

of this processing requires knowledge of the PNT asset’s location at the time of the observation. When processing this data onboard, errors in time between two elements can feed into further errors downstream, particularly in position and velocity estimates. Position and timing are inexorably linked for absolute ranging. Even for relative navigation, any timing errors will show up as system latencies, but due to typically lower relative velocities, these errors have a smaller effect. Similarly, performing a time transfer between two elements requires a measurement of the light travel time between them. Any errors in state, on either element, will cause timing synchronization errors between the assets. For the traditional ground-based OD approach, extremely accurate clocks are used to timestamp the measurements observed. With this knowledge, and timestamps of digital data received from an onboard clock, spacecraft timers can be correlated to absolute time [13].

LunaNet proposes an autonomous capability to enable time transfer within the communication network and between any participating members. For assets within proximity link range with low system latency and small light travel times, a coarse update can be effected simply by applying a broadcast time to update onboard time. Other approaches may achieve finer resolution. Network Time Protocol (NTP), for example, uses call-and-response timestamps between assets to measure the time of flight delay at the host site. The process applies broadcast time with a correction to account for the signal travel time. NTP can enable high-fidelity synchronized time across the network with accuracy on the order of microseconds. Similarly, ground testing can help to identify internal system latencies to provide better timing updates.

LunaNet nodes will utilize two types of timing subsystems to ensure accuracy and improve PNT services: a high-stability onboard oscillator, such as an Ultra Stable Oscillator or an atomic clock, and synchronization of onboard time with Earth-based master clocks via use of weak signal GNSS [14].

Two independent time services will be included in LunaNet: coarse measurement and fine measurement. Time comparisons between two nodes can provide a coarse understanding of time on the milli- or micro-second level. LunaNet, however, will support finer accuracy using a high-stability clock reference that broadcasts signals at a fixed, well-established rate, with an objective of 10 nanosecond accuracy. This repeatable information on a broadcast signal will help to discipline clocks across the architecture. Correlating time transfer services with onboard state knowledge to account for any Doppler effects may present some challenge, so optical PNT capabilities within LunaNet are anticipated in the future. Optical PNT functionality will push fine timing accuracy to the sub-nanosecond level, reducing propellant usage and enabling unprecedented accuracy on numerous scientific experiments.

3.2.3 Detection and Information Services The atmosphere around Earth usually protects humans and space assets from harsh solar particles coming off the

Sun during a solar flare. However, because of the lack of protective atmosphere at the Moon, there is an increased chance of solar storms impacting our astronauts, satellites, and systems. It is imperative for the safety of our people and assets that they receive advanced warning of these incoming particles from solar eruptions. LunaNet services will enable dissemination of space weather data and event alerts from instruments (e.g., on heliophysics missions) that will constantly monitor the Sun for any increase in solar activity that could result in a solar eruption. This data will be sent through the LunaNet architecture as part of the Detection and Information (Det) services. With this constant monitoring, the architecture could warn astronauts exploring the lunar surface of an incoming event and advise them to seek shelter without the delay of routing the alert through mission control on Earth. Robotic missions could benefit from these alerts as well, using such information to autonomously shut down experiments, shed the power load, and prepare to ride out the storm.

3.2.4 Science Services LunaNet assets will be able to support some science objectives through use of available radio/optical links and

telemetry. Some opportunities for science services only require that LunaNet space equipment operate in a special mode within the capabilities of the communication and PNT subsystem.

LunaNet services could be scheduled, for example, to support radio science investigations. The DSN supports radio science services, radio astronomy / very long baseline interferometry services, and radar science services, or the data and meta-data generated by these services. LunaNet assets could be designed to deliver measurements of the spacecraft downlink signal from open-loop receivers for use in radio science. This service could also be used to support mission-critical events such as a spacecraft emergency search.




Other opportunities may occur only if the LunaNet space equipment is designed to act as a multifunction device, e.g., for both communications and radar. This would require the LunaNet antenna and equipment string to also be designed as a science instrument - or at least as one end of an instrument. In the transmission process, the equipment may use more power and send pulses instead of coding or modulating. On receiving, the equipment would not decode, demodulate, or filter out noise. Instead, it would save the entire digitized spectral result; that is, it would save exactly what a communications device would filter out. Science services would be specific to specially designed nodes and would not provide interoperable services over the network [15].

3.3 Service Management Service management will be a collaborative function between LNSPs and Service Users. Both parties will jointly

plan, execute, and track accounting/evaluation of services provided by LunaNet assets. The services to be managed encompass those provided by each network as well as the “end-to-end” services across the set of Earth networks and LunaNet networks involved in the path(s) between communication source(s) and destination(s). LunaNet service management will exist at two levels. At the individual LNSP level, services include the functionality to be provided by their network. At the LunaNet network-of-networks level, services encompass the “end-to-end” functionality to be implemented across the networks [16].

3.3.1 Strategic Planning To create a long-range plan for LunaNet, a strategic planning process is necessary to assess and project the overall

network capacity and the ability to meet aggregate user needs. Each LNSP will conduct its own needs assessment independently, followed by a process of coordination with

other LNSPs and users, perhaps managed through an industry association. The extent of coordination may vary, depending on government, commercial, and academic processes. For example, government agencies are likely to disclose their planned missions with adequate lead time to plan for the evolution of network capabilities. Commercial LNSPs may not be able to share their private market analyses; however, industry associations may procure commercial market analysis and distribute aggregate findings.

Service Users may also share important planning information. The following information is helpful to ensure the development of high-fidelity mission models: mission identification and number of elements, key mission timelines and trajectory, and relevant communication parameters at the link and network layers - frequency bands, symbol rates, contact hours, and data paths.

The supplier model will encompass not only Earth-based networks as they are at present but also cislunar communication assets such as LNS relay satellites and surface stations. Coordination among LNSPs (e.g., incremental evolution plans for each Service Provider) will be needed, in conjunction with LunaNet procedures to be defined.

3.3.2 Service Planning Service planning includes activities such as: negotiating service level agreements (SLA) with users; planning and

allocating communications and navigation resources; performing link, coverage, and loading analyses; and assessing the impact of proposed commitments. These activities will lead to the generation, approval, and maintenance of SLA for the commitment of LNSP service provision to Service Users. Significantly different from a traditional approach, the LunaNet service planning will be characterized by these significant features: 1. End-to-end service planning: The link, coverage, and loading analyses for LNSP support to an individual Service

User will be conducted by taking into account all of the service-providing assets on the end-to-end communication paths, including those of other cooperating LNSPs if required (e.g., for sufficient coverage). Analysis can no longer be conducted for each service-providing asset independent of other assets. Instead, LunaNet implementation calls for a conjoint analysis approach; if the primary LNSP identifies shortfalls in its capability, it may request cross-support from a second LNSP.

2. Integrated service provision trades: Given the available options for end-to-end paths, trades for LunaNet service provision will be performed in an integrated fashion, so that each Service User can reach an affordable and effective mission solution.

3. Federated or integrated SLA for commitment process: For a Service User requiring services from multiple LNSs, the commitment process will lead to the generation of federated SLAs. This process is to accommodate terms and




conditions that may vary among providers, like cost and liability. An integrated approach to SLA may be employed when all supporting assets are managed by the same agency or company.

3.3.3 Service Provision Management Due to the broad scope and diversity of providers within LunaNet, it is imperative to establish a system for

automated tracking of service instances throughout the life cycle of each user - from the creation of service requests (scheduled or user-initiated) to the execution of service instances and the final delivery of data. LNSP will automatically report anomalous conditions or events occurring in service provision to the User and track them for resolution. Any event occurrences that could affect the committed service provision will be resolved with affected Users, including reported outage of communications links, failure to meet committed quality of service, detection of security breaches, and/or downtime of network assets due to maintenance. At the end of the service life cycle, a post-service reporting of results will take place, in the form of service accountability and performance summary.

4 LunaNet Architecture Implementation

4.1 General Architecture Characteristics LunaNet provides an open, scalable, interoperable network-of-networks to support future missions in cislunar

space. After assessing the needs of projected international lunar missions and conducting joint studies on lunar CPNT capabilities, an international community [17] concluded the following characteristics are essential to LunaNet: 1. The communications capacity to service an unprecedented number of missions: For the period between 2020

and 2028, LunaNet must have ample communications capacity to meet the demands of more than 30 missions. Approximately 60 space systems are planned by, or involve, 10 space agencies. In addition to the missions announced by international agencies, an unknown number of commercial missions may be added.

2. Cross-supportability among the communications service-providing systems “owned” by the various space agencies/commercial companies: As the aggregate demands on communications capacity increase, more missions will require cross-support from communication assets of other agencies. This leads to the concept of cooperative LNSPs.

3. The inclusion of communications infrastructure to support lunar surface exploration: More extensive exploration of the Moon’s surface will change the communications paradigm. Instead of one-to-one point-to-point links, future communications will feature a lunar vicinity network involving multiple landed vehicles or platforms. Lunar surface networking will become an essential element of LunaNet.

4. The inclusion of lunar relay orbiters to service missions with no, or low, Earth visibility: Unlike current relays which are provided by science orbiters as a secondary capability, future lunar relays will include spacecraft dedicated to providing CPNT services. Moreover, relays will be designed to provide services for inter-agency cross-support.

5. Support for disadvantaged users: Small systems with little power and low gain will drive LunaNet to make provisions for disadvantaged Service Users. For example, plans indicate that at least six CubeSat missions and two SmallSat missions will launch during Artemis I. Additional CubeSat missions are planned with the Artemis II launch. Lunar exploration systems are expected to allocate minimal size, weight, and power for communications. Missions requiring less communication capability may also drive costs. LunaNet must be ready to provide low-cost solutions that support these users [18].

6. High reliability, especially for crewed missions: For crewed missions, there are a set of data types which are considered mission-critical because of their importance to astronaut health and safety, as well as mission success. These data types could include biomedical measurements, caution and warning, health and status, standard videos, training, situational awareness videos, family interaction, and recreational entertainment. This kind of data must be delivered at a reliability higher than that for ordinary robotic missions. The need to provide high-bandwidth communications to astronauts also drives a 1000x increase in uplink data rates from tens of kbps for command uplink to tens of Mbps.

7. The cost-effectiveness of providing CPNT service as a common utility: Space communications and tracking have been provided since Sputnik, using expensive, largely government-owned systems driven by national security, prestige, and science goals, with limited sensitivity to cost. Reduced government budgets and increasing commercial capabilities will drive a shift to much lower-cost solutions for services. At the same time, a growing number of missions and demand for services will offer the potential market opportunities to establish




commercially provided services. LunaNet is conceived as a set of multiple service providers providing CPNT solutions with competition simultaneously driving technical innovation and reducing costs for LunaNet users.

8. The ability to accommodate commercially owned service-providing assets: A number of companies have set their sights on the Moon. As they are ramping up plans to deliver relay satellites, surface assets, and Earth stations, the LunaNet architecture must be sufficiently agile to incorporate their service-providing systems.

9. The infusion of new communications and PNT technology for the advancement of lunar exploration: Chief examples of new technologies in the near term are optical communications and real-time positioning for lunar surface elements. As always, the infusion of any new technology will have some ramifications to end-to-end systems. The overall LunaNet architecture must be designed with sufficient scalability and expandability to accommodate future technology infusion.

10. The ability to meet a rapid rate of expansion in capabilities: Driven by high-rate science missions (e.g., synthetic aperture radar and multi-spectral/hyper-spectral imagers); human exploration (e.g., the need for multi-channel, high-definition video); and the low latency of certain mission critical data, future lunar communications will experience an unprecedented growth in demand for capacity over a steadily increasing portion of the lunar surface. In addition, a rising number of low data-rate missions will collectively require rapidly increasing capacity while providing opportunities for new services. For some LNSPs, this increasing capacity may offer opportunities to introduce small, modular platforms that can be manufactured at a low unit cost and are designed to evolve rapidly to match the needs of a dynamic market. Modular added capacity can be brought online rapidly.

11. Security protection of the end-to-end lunar communications and PNT paths: Security must be implemented as an integrated and inherent part of LunaNet. It must be done within the context of an open architecture that allows the entire LunaNet community to contribute to secure solutions while recognizing that vulnerabilities in the architecture will be visible to all, including those who would exploit those vulnerabilities.

12. Backward compatibility with the existing communications infrastructure(s) resulting from decades of investment by space agencies: To the degree possible, the LunaNet architecture must use the existing communications architecture, which is more Earth network-centric and dominated by point-to-point, space-Earth links, as the basis and expand from it into an interplanetary internetworking architecture. As systems migrate towards the new era, infusing new capabilities and preserving existing capabilities or assets must be traded on an individual basis and designed to allow transparent support for earlier versions.

LunaNet will be implemented in multiple phases to support human exploration and scientific discovery missions. The initial phase includes: upgrades to Earth networks, the deployment of lunar relays to form an initial lunar relay network, the incorporation of commercial communication assets, the emplacement of some limited lunar surface CPNT capabilities (likely via peer-to-peer mode only), and the integration of assets operated by participants in LunaNet development. In this initial phase, LunaNet exhibits a rudimentary space internet architecture in which end-to-end communications at the network layer and above interconnect the diversely deployed heterogeneous communication assets. Basic architecture of this Solar System Internetwork is defined in CCSDS Green Book 730.1-G-1 [6].

The enhanced development phase is between 2024 and 2028. To support extensive human exploration and science investigations, the architecture will feature additional lunar relay orbiters, lunar surface infrastructure, a significant number of commercial and international partner assets, and an introduction of optical CPNT capabilities. Additionally, LunaNet will be expanded into a full space internet that interconnects the various elements of lunar relay network, lunar surface network, and Earth network. Emerging as a new element, the Network Management Element (NME), will become operational to coordinate management of LunaNet at the space-internet level, encompassing all LNSPs.

4.2 Projected LunaNet Architecture Implementation Conceptually, the LunaNet architecture embodies three types of networks: the lunar relay network, the lunar

surface network, and the Earth network. In that sense, it is a lunar space internet, which is architecturally like the terrestrial internet. As in the case of multiple Earth networks, both orbiting relays and surface networks may operate as separate or integrated networks across the cislunar regions.

Each LNSP will define the internal architecture that comprises its LNS and system architecture may be implemented differently by each LNSP. To act as a member of LunaNet, the only requirements are compliance with the User Services and Internetworking Standards defined in Figure 1.




4.2.1 Lunar Relay Network Element Within LunaNet, a lunar relay network consists of one or more lunar relay orbiters, each of which provides

communications and/or PNT services to users over proximity links. When the relay interfaces provide network layer services, the relay orbiter(s) and the user nodes form a relay network together. The relay orbiter, in this context, can be a dedicated relay satellite, a LunaNet payload on a spacecraft with other payloads, or the relay function of the communications subsystem of a spacecraft acting as a LunaNet node.

4.2.2 Lunar Surface Network Element It is expected that the next decade will see deployment of multiple vehicles, platforms, and/or facilities, clustered

near the lunar south pole for human exploration as well as robotic science missions in scattered locations around the Moon. More persistent surface-to-surface communications infrastructure will be required to support a variety of missions, such as those to gather and return samples, gather and process regolith to extract in situ resources, and to study the composition and evolution of the Moon. Future missions will lead to the establishment of lunar surface network(s).

Within an exploration zone or human outpost, a wireless LAN (WLAN), RF and/or optical, is used for the lunar surface network [19]. The mesh WLAN facilitates vicinity wireless communications between various landed and deployed elements. It also gives mobile elements, e.g., rovers and astronauts, the ability to move around within the area and still be connected to the network. Network Communications Terminals (NCT) act as local gateways, interfacing to the surface users via the WLAN, with the lunar relay network elements via proximity links, and with the Earth network via trunk links.

A typical lunar surface network will include two key entities: • NCT – At the edge of the LunaNet surface network is the network terminal node, a physical entity that ends a

RF/optical link and is the point at which a Service User signal enters and/or leaves a network. It serves multiple Service Users via a multiplexer/demultiplexer device. This node may provide PNT services such as range, range-rate, and bearing angle. Depending on further selection of surface standards, e.g., IEEE 802.11 or 4G/5G cellular, sub-terminals may be used to support mesh networking with the ability to triangulate Service Users within the local area to provide precise position and elevation.

• Network management controller – in the form of software or firmware, orchestrates network functions for a LunaNet surface network. The network controller:

o Maintains an inventory of devices in the network and monitors their operational status; o Executes automated device operations such as configuration setup and updates; o Executes automated network initialization; o Detects and responds to network anomalies; o Stores user traffic temporarily until network connectivity is restored; o Performs network-wide traffic analysis and maintains relevant performance statistics; o Manages local PNT services for surface users; and o Provides local network management interfaces with Earth network management.

4.2.3 Earth Network Element The LunaNet architecture includes a set of Earth-based network assets that provide CPNT services to relevant

lunar missions. These assets also connect each LNSP’s lunar relay orbiters/payloads and surface elements to its ground-based network operations center. Operating together, they form a global network capable of expanding to provide 24x7 coverage for lunar exploration.

4.2.4 Network Management Element (NME) In addition to a variety of communication assets, LunaNet includes a network management element (NME) that

performs the service management and network control functions. Since LunaNet is a set of cooperating networks, the LunaNet NME is the set of NMEs for all LNSs. Analogous to the terrestrial internet, the LunaNet NME embodies a set of policies, rules, standard operating procedures, and network monitor and control capabilities provided collectively by all LNSPs. Standard communications and PNT protocols allow LunaNet to operate over a variety of networks. Cybersecurity-related capabilities are inherent aspects of the network architecture.

Key functions of the NME are to: • Coordinate the service management functions for missions requiring services from multiple communication assets

owned or operated by other LNSPs;




• Ensure each LunaNet node meets the regulatory standards and complies with applicable laws and regulations of each relevant country;

• Monitor the status of LNS assets, at the LunaNet node level, and the collective behavior of an LNSP’s portion of the LunaNet architecture;

• Identify network faults and suggest recovery actions; • Coordinate with LNSPs to resolve internetwork issues; • Perform LNS configuration management, this also includes DTN-related items such as source/destination

addressing, routing paths, and quality of service assignments. • Analyze LNSP network performance based on traffic data collected to detect bottlenecks, generate past/present

performance summary statistics, and analyze trends. • Coordinate cybersecurity actions and practices taken by all LNSPs and identify security risks based on data.

4.3 Spectrum and Interoperability Standards

Figure 9. LunaNet Spectrum and Interoperability Standards

The goals of LunaNet can only be met through the use of standards defined for both the services and the interfaces over which those services are provided. Figure 9 is a conceptual view of the lunar architecture from the IOAG’s The Future Lunar Communications Architecture report. This report, as well as, the International Communication System Interoperability Standards (ICSIS) document published by NASA, identify the frequency bands and standards to be applied in the lunar architecture [3]. The phased approach for the implementation of LunaNet will include the identification of the subset of standards in these documents required for minimum interoperability in specific timeframes [20]. Any standards for other services not included in those documents will also be identified.

Conclusions A communications and navigation infrastructure will be required to support and enable the plans for sustained

human and robotic presence on the Moon. Like the Earth’s internet, this infrastructure will need to increase in size and complexity as the number of users and innovative applications grow. A standards-based approach as described in this paper will allow multiple provider systems, owned and operated by a combination of international and commercial entities, to establish the LunaNet.




Acknowledgements This work was performed in support of the NASA Space Communications and Navigation Office. The authors

would like to thank the many engineers and authors that contributed this effort and the many other efforts upon which these concepts are based. Nan vonDeak and Katherine Schauer performed heroic technical writing and editing to this paper and related documents.

References [1] Israel, D. et al., “LunaNet: a Flexible and Extensible Lunar Exploration Communications and Navigation

Infrastructure,” IEEE Aerospace Conference, Big Sky, MO, 2020 [2] Anzalone, E., et al. “Lunar Navigation Beacon Network using GNSS Receivers”, Proceedings of the 70th

International Astronautical Congress (IAC), Washington, DC, October 2019. [3] “International Communication System Interoperability Standards (ICSIS), Revision A,” September 2020 [4] Israel, D. et al., “The Benefits of Delay/Disruption Tolerant Networking (DTN) for Future NASA Science

Missions” Proceedings of the 70th International Astronautical Congress (IAC), Washington, DC, October 2019.

[5] “The Future Lunar Communications Architecture,” Report of the Interagency Operations Advisory Group Lunar Communications Architecture Working Group, September 2019.

[6] CCSDS, 730.1-G-1, Solar System Internetwork (SSI) Architecture, Informational Report, Green Book, Issue 1, July 2014.

[7] Riedel, J. E., et al. "Autonomous Optical Navigation (AutoNav) DS 1 technology validation report." Deep Space 1 Technology Validation Reports, Pasadena, CA, Jet Propulsion Laboratory, 2000.

[8] McCabe, J., and DeMars, K., "Anonymous Feature-Based Terrain Relative Navigation." Journal of Guidance, Control, and Dynamics 43.3 (2020): 410-421.

[9] Heckler, G., Gramling, C., Donaldson, J., Baldwin, P., “TDRSS Augmentation Service for Satellites,” Proceedings of the 14th International Conference on Space Operations, 16-20 May, 2016, Daejeon, Korea

[10] Valdez, J., Ashman, B., Gramling, C., Heckler, G., “Navigation Architecture for a Space Mobile Network,” Proceedings of the 39th American Astronautical Society Guidance and Control Conference, Breckenridge, CO, 5-10 February 2016.

[11] Ashman, B., et al. “Exploring the Moon with GNSS: Applications of GNSS within and Beyond the Space Service Volume.”

[12] Winternitz, L., et al. "Global Positioning System Navigation above 76,000Km for NASA's Magnetospheric Multiscale Mission." Navigation: Journal of the Institute of Navigation 64.2 (2017): 289-300.

[13] Mills, D. et al. Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space. CRC press, 2017.

[14] Ely, T., et al. “The Deep Space Atomic Clock Mission”, 23rd International Symposium on Space Flight Dynamics, Pasadena, California, October 29 - November 2, 2012, http://hdl.handle.net/2014/43016.

[15] Dille, M., et al. “PHALAX: Expendable Projectile Sensor Networks for Planetary Exploration”, 2020 IEEE Aerospace Conference, Big Sky, MT, 2020.

[16] IOAG “Space Internetworking Strategy Group (SISG) Recommendations on the Selection of End-to-end Space Internetworking Protocol,” IOAG Report, February 2021.

[17] Wallace, T., InKyu, K., SangMan, M., Day K,, Kar-Ming C., “The Lunar Space Communications Architecture from the KARI-NASA Joint Study,” AIAA SpaceOps 2016 Conference, 6 May 2016

[18] Israel, D., Mauldin, K., et al., “LunaNet: a Flexible and Extensible Lunar Exploration Communications and Navigation Infrastructure and the Inclusion of SmallSat Platforms,” 34th Annual Small Satellite Conference

[19] Cheung, K., Lee, C., “Lunar Relay Coverage Analysis for RF and Optical Links,” AIAA SpaceOps 2018 Conference, 31 May 2018.

[20] Johnson, S., Vitalpur, S., Tai, W., Schier, J., Bussey, D. B., Bleacher, J. E., “Communications Interoperability for Lunar Missions”, 70th International Astronautical Congress (IAC), Washington, D. C., October 2019.

http://hdl.handle.net/2014/43016

Section 5 - esc.gsfc.nasa.gov

Documents

Transcript of Section 5 - esc.gsfc.nasa.gov