As NASA establishes a sustained presence on the Moon and ventures further into the solar system, the need for a robust interplanetary communications and navigation architecture increases. LunaNet, an extensible and scalable lunar communications and navigation architecture, is being developed to answer this growing need. The LunaNet architecture will provide users with three services: networking services, positioning, navigation and timing services, and science utilization services. With LunaNet in place, users will experience an operational environment similar to that experienced by users on Earth. 1)
The agency’s plan for solar system exploration necessitates both government and commercial participation, and the LunaNet architecture supports this goal as well, encouraging global participation from commercial and international partners, other government agencies, academia, and federally funded research development centers.
Through the newly created Artemis program, NASA intends to land the first woman and next man on the Moon by 2024, followed shortly by establishing a sustained lunar presence. As NASA, other government agencies and commercial industry increase their presence in space, the need for a robust communications and navigation network architecture becomes paramount.
Our lives on Earth are almost entirely networked; the ability to connect to the network anytime and anywhere has transformed how humans interact and conduct business on a daily basis. Walking into a coffee shop or store, a visitor is frequently prompted to connect to the Wi-Fi network. We proceed with our daily lives secure in the knowledge that as long as we have a network connection, we are able to communicate with anybody else on the network simply and reliably.
LunaNet is NASA’s answer to networked communications on the Moon. The LunaNet architecture will be flexible and extensible, providing missions at the Moon with the needed communications services. LunaNet is being developed through NASA’s Space Communications and Navigation (SCaN) program office, who oversee the operations, maintenance and advancement of NASA’s current networked operations.
However, through LunaNet’s extensible nature, the pieces of the architecture can be implemented by NASA, other government agencies, commercial industry, academia and more.
To create the LunaNet architecture, engineers will leverage Delay/Disruption Tolerant Networking (DTN) Bundle Protocol (BP) as the principal internetworking protocol. Although similar in foundation to the traditional Internet Protocol (IP), DTN BP will allow end-to-end networking, even under circumstances that IP will not, such as disconnections and/or delays anywhere along the complete end-to-end path.
In contrast to traditional link-centric operations, the LunaNet architecture is based on interconnected network nodes and will create a terrestrial-like internet in space. With the increase in human and robotic exploration at the Moon, it is not feasible for each asset to have its own direct-to-Earth communications link, and LunaNet mitigates this. Spaceborne users, surface assets or lunar orbiters, can utilize LunaNet’s network nodes as access points, analogous in functionality to terrestrial Wi-Fi (Wireless Fidelity) routers and cellular towers. As long as the user has connectivity to the network, and the network has adequate capacity to meet the user’s operational requirements, the user does not need to be concerned about how many relays or hops there are between the user and the user’s data destination. The network service provider has responsibility for managing the operational complexity associated with routing data traffic between user source and destination nodes. 2) LunaNet enables more dynamic and network-centric operations and can be implemented anywhere in the solar system, first at the Moon and then on other, distant planets.
Each LunaNet node will be capable of providing a combination of three standard service types: networking; positioning, navigation, and timing (PNT); and science utilization.
• Networking Services (Net): 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.
• Position, Navigation, and Timing Services (PNT): Services for position and velocity determination, and time synchronization and dissemination. This includes search and rescue location services.
• Science Utilization Services (Sci): Services providing situational alerts and science measurements for human and asset safety and protection. Science instrument data will also allow for further research, increasing return on investment overall (Ref. 2).
Figure 1: A LunaNet Node combining the three standard service types (image credit: NASA)
Networking Services (Net):
LunaNet node providing Net 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. Through DTN BP, the bundled data will flow from one asset through the network to their designated location. This can be another space asset or scientists and researchers on Earth. Figure 2 is an example of the end-to-end path that LunaNet enables.
Similar to networks on Earth, the user will not have to have knowledge of the underlying link topology or DTN functionality. As long as assets are built with standard operating protocols, the assets and nodes can interact as part of the larger architecture. Figure 2 is intentionally simple to indicate that this fundamental architecture is independent of any specific implementation concerning space platforms, frequency bands, protocols, or node providers. Well-defined standards enable this simple architecture to become the scalable, highly functional architecture as experienced with the terrestrial internet. Each node is required to be interoperable with any other node to which it will be directly connected. Networking standards are then required to allow the multi-node path between two endpoints (Ref. 2).
The architecture will aggregate links, funneling different sources of data to come together to one point to get combined into a single stream of data, as appropriate, to more efficiently use available links and to minimize the total number of links required.
PNT (Position, Navigation and Timing Services):
The LunaNet architecture will enable missions to send critical data to other assets in space or on Earth. This data however is not limited to mission objective data, critical PNT data will also be encoded in the bundles. PNT data will enable lunar assets to determine position and velocity, plan and execute maneuvers, plan trajectories, and maintain time.
To provide missions with the needed navigation capabilities, onboard hardware and software conducting orbit determination (OD) must be used in combination with the following provided by the lunar architecture:
1) A common stable time and frequency reference source with synchronized distribution across all elements
2) Radiometrics or optimetrics from each observable communication link
3) Observability of GNSS signals
4) Angular measurements to define plane-of-sky
5) Imaging of nearby celestial body surface features (Ref. 2).
Figure 3: LunaNet PNT (Position, Navigation and Timing) services (image credit: NASA)
PNT data can help mission control on Earth keep track of large and small satellites, astronauts, rovers or any other space-based asset. Additionally, with this data, researchers and scientists can plan their satellites’ next maneuver for new discoveries.
Navigation data is especially critical for astronaut safety. With NASA’s Artemis program, the agency plans to create a sustained presence on the Moon during the late 2020s. With human permanently located on the lunar surface, increased safety precautions must be implemented. The LunaNet engineering team is working closely with NASA’s Search and Rescue (SAR) office, which has already developed astronaut emergency locator beacons for terrestrial use. Together, the teams will develop a robust system, capable of providing SAR support for humans on the Moon, and eventually other planets.
Science Utilization Services (Sci):
The atmosphere around Earth usually protects humans and our assets from harsh solar particles coming off of 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 assets that they receive advanced warning of these incoming particles from solar eruptions. Working with the space weather scientists and engineers, the LunaNet team is integrating science utilization services into the architecture. The LunaNet payloads will include space weather instruments 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 bundled data package. With this constant monitoring, the architecture could warn astronauts exploring the lunar surface of an incoming event and advise them to seek shelter.
Flexibility and Extensibility
LunaNet is both flexible and extensible and will be continually evolving after NASA develops the first instantiation of the architecture. Lunar missions may be part of the LunaNet infrastructure, a LunaNet user, or even both. A lunar mission can conduct its mission objectives while also acting as a LunaNet node or simply be a user of the architecture.
SmallSats as part of the Infrastructure
The LunaNet architecture will provide the collection of services through the aggregation of infrastructure elements. These elements will range from Earth-based ground stations, to lunar orbiters and lunar surface assets. Since each part of the larger infrastructure is not required to be provide all LunaNet services, SmallSats may provide the ideal platform for deployment of capabilities. For example, some SmallSats may primarily function as navigation beacons, while others may be contributing to overall increased communications coverage.
Building up the LunaNet infrastructure with multiple SmallSats, however, leads to additional challenges. If each SmallSat requires its own link with Earth, the required amount of ground stations will be much greater than the number of ground stations actually available. The cost to add additional ground stations capable of lunar support is much greater than the low cost of SmallSats. This will require some SmallSat operations to be more autonomous and for there to be other data aggregation points in the system to in order to reduce the number of required connections with Earth.
Detailed SmallSat Infrastructure Role Implementation Considerations
Payloads: Building upon the infrastructure roles that SmallSats play to benefit the larger lunar architecture, we can take an objective and modular view at the types of payloads onboard the SmallSats that can contribute to the larger SmallSat functionality as a provider node.
Networking Services: A networking services payload function to be considered for infrastructure role SmallSat nodes is described as a Networking Services Instrument (NetSI) function. This function is defined as a suite of functions that provide the DTN BP network layer routing function at its core. Additionally, the functions provide multi-layer protocol interfaces for each communications link interface that exists on the particular SmallSat, i.e. radio frequency (RF), optical communications, etc.
DTN BP is the network layer protocol that provides internetworking between infrastructure SmallSats, user SmallSats, relays in the lunar vicinity, lunar surface assets, and Earth-based systems. Just as distributed routers play a critical role in the Earth-based internet infrastructure, providing multiple routing paths for data to travel through the network, Infrastructure SmallSats similarly can provide DTN BP routing and access points in the lunar region. The BP routing node also includes storage for any received data that is not immediately able to be forwarded.
The DTN BP routers on infrastructure SmallSats can route bundles in the following ways:
• One-to-One: Routing from one source to one destination
• One-to-Many: Routing from one source to many destinations (multi-cast)
• Many-to-One: Routing from many sources to one destination (aggregation or multiplexing of bundles).
Most DTN BP router or access point instantiations can be implemented in software onboard the SmallSats, using DTN BP software applications that follow the DTN BP standards.
The NetSI (Networking Services Instrument) payload function itself is agnostic to the specific physical communication links that are being used by the SmallSat node, therefore it can utilize any existing communication links that are already planned to be present on the spacecraft. Specific frequency bands will be discussed in the next section.
Figure 4: LunaNet access point payload (image credit: NASA)
The networking services payload concept is an example of a payload function that could easily be included as part of an infrastructure SmallSat. Other variations or payloads can be envisioned as well, without being constrained to a particular hardware platform. In fact, the implementation of the network services payloads could potentially be completely implemented in software, depending on the spacecraft avionics configuration.
Infrastructure nodes are envisioned to use frequency bands as defined by the international communities and agreements. When selecting frequency bands for SmallSats that play an infrastructure role, it is strongly recommended to utilize the following frequency band scheme, in order to avoid interference, band-crowding, and to maximize interoperability. First, we define physical link types and terminology as: 3)
• Earth-to-Moon: The uplink from the Earth to cis-lunar, lunar orbit and lunar surface.
• Moon-to-Earth: The downlink from the cis-lunar, lunar orbit and lunar surface to the Earth.
• Cross Link: The link between two relay spacecraft.
• Proximity Link: The link between a relay satellite and its relay service user. Relay service users can be orbital spacecraft, descent/ascent vehicles, landers, and rovers. Potentially, astronauts equipped with portable communications device, communications stations/towers on the surface, and human habitats could also be relay service users.
Within this physical link topology, the band allocations are:
Table 1: Band allocations
As a relay, SmallSat system designs that emphasize performance to reduce the burden on the relay users are highly desirable. This would include designs that maximize the relay’s effective isotropic radiated power (EIRP) or gain over temperature (G/T) for RF links and for antennas and modems that could support multiple users simultaneously.
PNT Services: Payloads can also be included that provide PNT related infrastructure functions, such as ranging devices, autonomous navigation processors, broadcast beacons, and time reference source / distribution modules. SmallSats can provide a unique vantage point in providing the PNT services by including things like broadcast beacons on multiple SmallSat spacecraft, providing multiple signals that surface assets can use for surface location determination, etc. As the topology of SmallSats gets defined, the specific PNT payloads can be fine-tuned to be the precise application or location of that infrastructure SmallSat. Use cases, user needs, and mission modeling should be utilized to define the configuration of these payloads.
One category of PNT services are services to support lunar Search and Rescue (SAR). In the same way that Earth orbiting satellites are able to locate distress beacons on Earth, payloads on lunar orbiting spacecraft will be cable of receiving transmissions from lunar beacons. These payloads may also be capable of receiving and relaying astronaut health and safety data in addition to current position.
Science Utilization Services: SmallSats that play an infrastructure role in the architecture have a unique opportunity for also carrying science instruments or operational detectors onboard that can contribute to the larger mission at hand. These on-board instruments are viewed as the data sources of the LunaNet “Science Utilization Service.” The data generated by the instruments can be used by the SmallSat hosting the instrument for operational decisions, and/or can be routed through the LunaNet distributed network to other infrastructure SmallSats, lunar assets or data users for multiple purposes and use cases.
As introduced in the architecture and service definitions earlier in the paper, space weather instruments and detectors are a use case example of on-board instruments playing a local and distributed role on infrastructure SmallSats. Given the ability for SmallSats to be more widely distributed than large spacecraft assets, SmallSats can use a multi-spacecraft or disaggregated approach to detect space weather events for purposes of early warning detection or science-based observations. As methods are developed to provide early warning of a major solar event, automated alerts can be routed to humans and/or critical assets on the lunar surface. In a similar fashion, that distributed sensor provides a more cohesive, complete view of an environment or event. SmallSats that are internetworked provide the same distributed instrument benefits. The applications of this concept in the lunar domain are bounded only by our imagination.
Multiple space weather instruments have been, and are being, developed in form factors that fit nicely within the size, weight and power (SWaP) allocations consistent with SmallSat spacecraft. Some space weather instruments even stem from the CubeSat community, which allows for SWaP flexibility, or multiple instrument clusters.
SmallSats as Users
The previous section described SmallSats as part of the LunaNet infrastructure. SmallSats will certainly be part of the LunaNet user community too. LunaNet will enable lunar SmallSat missions and allow them do dedicate more of their resources to their science payloads.
With LunaNet, since the user will be able to connect to the larger network through links in the lunar vicinity, they will not need to carry the capability to return all of their science data solely through long links back to Earth. SmallSat missions could even exchange data with other lunar missions, either in orbit or on the surface. Additionally, each mission would be able to use the PNT services for autonomous guidance, navigation, and control. The Science Utilization Services could provide alerts that may allow placing sensitive instruments into safe mode or, perhaps, turning on science instruments designed to capture specific science events. In order to receive all of these benefits, the SmallSat design must include systems that are compatible with the LunaNet architecture.
Payloads: We now focus on LunaNet user payloads that can be implemented on a SmallSat. While some of the inner functions of the user payloads are similar to those in infrastructure payloads, the purpose and perspective is different, and is more focused on user interfaces to the larger network. Just as consumer internet routers provide a resident or business access to the larger network infrastructure, a SmallSat LunaNet payload that plays a user role is purposed for obtaining user access to the larger LunaNet infrastructure.
Examples of types of data that a user payload may send or receive can include:
• Status of onboard systems / instruments
• Data from onboard science instruments or detectors
• Raw data to be processed by other assets or systems
• PNT information to be cross-linked to other assets
• Event-based communications service requests.
Data rates may vary depending on the user node requirements and use cases. Real-time alerts and low-bandwidth messages, broadcast beacons, and service requests can be in the 1 kbit/s – 10 Mbit/s regime. As an example, raw data streams from onboard instruments can possibly be in the >1 Gbit/s regime. Data rates can be tuned and determined by the use case and the on-board communications system or link capabilities from the user node to the next available LunaNet access point, i.e. a provider node
User data may be latency tolerant, or may require low latency transfer. Real-time operations that require rapid feedback or observations to feed into automated or manual operations decisions often require low latency. It is likely that some user SmallSats may be performing operations in this category. Low latency requirements can be met by ensuring one or more immediate access points are available to provide an end-to-end flow of the data to the destination. If the user application is latency tolerant, and doesn’t require low-latency constraints, e.g. transfer of raw science observation data for post-processing, the network can route the data in a more flexible fashion, utilizing the store-and-forward capability of the DTN BP network layer. User payloads that are envisioned to be latency tolerant sources of data should have on-board storage as part of the user’s DTN node. The amount of storage does not need to be excessively large, and can be tailored based on the user’s needs and concept of operations.
Depending on the user application, the routing of data and link management may be considered part of scheduled operations (more deterministic), or part of opportunistic operations (less deterministic, event based). Payloads onboard user SmallSats can use either approach as they are utilizing the LunaNet services.
Frequency Bands: User SmallSats will have options available to them, such as choosing a direct-to-Earth (DTE) link, or using a relay, if available. These link decisions can be made pre-deterministically or in real-time based on relay availability. Referencing the frequency allocations and band assignments described in section ”SmallSats as part of the Infrastructure”, the user would need to keep in mind the differences in bands used between DTE vs. proximity links to users. For example, a user spacecraft may choose to use X-band for a DTE link to Earth vs. S-band for a close proximity link to a nearby relay. This will be important as the user mission works through spectrum allocations and service requests to Earth-based assets vs. relays.
Table 2: Band allocations
Instruments: Instruments onboard user SmallSats can widely vary between various science instruments - imagers, spectrometers, LIDARs, detectors, interferometers, receivers, telescopes, etc. - or operational instruments that are used as part of human or robotic exploration of the Moon - voice communications relays, environmental monitoring such as space weather, etc. Instruments onboard user node SmallSats are only limited by spacecraft accommodation of the instrument, and technology readiness for the lunar environment.
DTN Node: The DTN BP node functionality on a user SmallSat is a simpler implementation than the infrastructure SmallSat. The primary function that the user-based DTN BP node provides is serving as a source and/or sync of DTN bundles that either originate or terminate at the user node. This node provides access for the user to the larger LunaNet infrastructure and network of provider nodes. As part of the user node DTN implementation, additional protocol adapters may exist in order to allow data that may exist in other forms to be properly packaged into DTN bundles, applying the network layer to the data. This is analogous to the example of a consumer laptop taking application layer data, and packaging the data into TCP/IP packets for routing through the internet infrastructure. As long as the user data is ultimately packaged into DTN bundles natively or via a protocol adapter, the data will be routable through the larger LunaNet infrastructure.
Applications exist today within spacecraft software systems that perform this user node DTN BP function, and can be readily re-used on various user spacecraft platforms, providing an open yet standardized approach to user node implementation.
The new era of lunar exploration presents many opportunities for SmallSats, especially since their small size makes it possible to add additional missions on any launch to the Moon. These SmallSat missions may be science missions that add to a growing number of LunaNet users or the SmallSats may become part of the larger LunaNet infrastructure, supporting all users. In some cases they may play a dual role by providing services to others, while also fulfilling their primary science or exploration purpose. It is expected that LunaNet will both enable lunar SmallSat missions and SmallSats will enable LunaNet’s continued growth and evolution.
David Israel, La Vida Cooper, Kendall Mauldin, Katherine Schauer,
”LunaNet: a Flexible and Extensible Lunar Exploration
Communications and Navigation Infrastructure and the Inclusion of
SmallSat Platforms,” Proceedings of the 34th Annual AIAA/USU
Virtual Conference on Small Satellites, August 1-6, 2020, Logan, UT,
USA, paper: SSC20-XII-03, URL: https://digitalcommons.usu.edu
2) Davide J. Israel, Kendall D. Mauldin, Christopher J. Roberts, Jason W. Mitchell, Antti A. Pulkkinen, La Vida D. Cooper, Michael A. Johnson, Steven D. Christe, Cheryl J. Gramling, “LunaNet: a Flexible and Extensible Lunar Exploration Communications and Navigation Infrastructure” IEEE Aerospace Conference. Big Sky, Montana. 7-14 March 2020.“The Future Lunar Communications Architecture” – Interagency Operations Advisory Group (IOAG), Lunar Communications Architecture Working Group, https://doi.org/10.1109/AERO47225.2020.9172509
3) David J.
Israel, Donald M. Cornwell, Gregory D. Menke, and W. John Guineau,
”Demonstration of Disruption Tolerant Networking Across Lunar
Optical Communications Links,” Proceedings of 32nd AIAA
International Communications Satellite Systems Conference, page:4481,
The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: ”Observation of the Earth and Its Environment: Survey of Missions and Sensors” (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates (firstname.lastname@example.org).