LunaNet is the reference architecture for Lunar Communications and Positioning, Navigation and Timing (PNT). It is a multi-national framework led by three space agencies: NASA, ESA and JAXA, and inclusive of the private sector and academia. Its current specification establishes the concept of LunaNet Service Providers (LNSPs), which are analog to the terrestrial Internet Service Providers (ISP) in providing communications and PNT services to lunar surface and cislunar users through a set of standard interfaces.
Figure 1 LunaNet Service Provider Interfaces, from the LunaNet Interoperability specification draft.
The current LunaNet Interoperability Specification draft establishes user to LNSP and inter LNSP interfaces for the provision of these services. For communications, the specification establishes a data protocol layer which relies on Delay and Disruption Tolerant Networking - DTN (and its Bundle Protocol) and the Internet Protocol as internetworking layers that interfaces with the User Application stack.
Figure 2 LunaNet Communications Protocol Stack.
LunaNet Service Provider (LNSP) - Example Scenario
Let's evaluate the capabilities required by looking at an example scenario.
Figure 3 LunaNet Service Provider Example Scenario.
We are going to focus on LNSP 1 (in green), who provides DTN communications services to users in cislunar space and ground through its network:
- A DTN Lunar Gateway in the Lunar Lander (Node 1).
- A DTN Ground Gateway on Earth (Node 2).
- A DTN Relay on a lunar satellite (Node 3).
- A DTN Network Management System, in ground, connected to Network Operations, Cross Support and ultimately to Mission operations.
Through the nodes above, the LNSP 1 offers services to users in cislunar space and ground:
- End-users in lunar surface: Lander Payloads - Node 11 and Node 12.
- End-users in ground: Science users - Node 21 and Node 22.
In addition, LNSP 1 offers services to LNSP 2 (in purple), to connect the lunar LTV Network between the lunar surface and Earth.
- LNSP 2's LTV Network DTN Gateway Node connects to LNSP 1's Lunar Lander Node 1. The LNSP 2 can then offer user services to the LTV Payload Node (Node 13).
- LNSP 2's DTN Ground Gateway Node connects to LNSP 1's Ground Gateway Node 2. The LNSP 2 can then offer user services to the Ground Payload Node 23.
- LNSP 1 augments its network services by getting additional contacts from LNSP 3 lunar DTN Relay Node. This helps LNSP 1 to increase their data volume capacity and/or coverage by selectively using LNSP 3 services.
How real is this scenario? This scenario has been built considering the initial operational capabilities of the government and private missions planned for the Moon within the next four years. NASA, ESA and JAXA, together with the private sector, are working to deploy LunaNet-based networks that include Lunar Landers, Lunar Satellites, Lunar Terrain Vehicles and Ground Stations, together with a myriad of payloads (data applications).
With this network example, the following are the key considerations for LunaNet Service Providers (LNSPs). Note these considerations are focused in delivering communications services (which means we are not covering here the provisioning of PNT services).
- Network Management.
- Securing the User-LNSP interfaces.
- Managing the inter-LNSP interfaces.
- Secure User Applications
- Enable Operations
In this chapter, we will cover Network Management.
DTN Network Management for LNSPs
Network Management represents the ability to setup and manage the lifecycle of the network, and its nodes, ensuring network availability and the optimization of the transfer of data. It is essential to operationalizing networks. Managing configuration, monitoring operations, managing troubleshooting and diagnostics are critical operational elements. With initial networks containing multiple nodes (14 nodes in the example above), having distributed administration is critical to guarantee the availability of the network.
Network and Node Configuration - Logical View
Configuring the network includes a view of the network identifiers, its topology (at DTN level), its connectivity details, including Convergence Layer Adapters (CLAs) and neighborhood (who's connected to whom). In this example, the LNSP nodes are configured, including the nodes configured as user Gateways (Node 1 and 2), from which the administrator can view the payload nodes as child nodes. The management system (in this case the SPATIAM DTN Manager) automatically performs the node configuration based on its logical configuration, as performed by the LNSP 1 DTN Network Administrator user.
Figure 4 Logical view of the LNSP 1 network configuration in the SPATIAM DTN Manager.
Inter-LNSP Interface: Managed vs Unmanaged Nodes
Not every node in the network may be managed by the same LNSP. In our example, it is assumed that each LNSP manage its own network, how is it possible to create a network without managing all the nodes? By sharing key configuration details, which include but are not limited to network and link identifiers (such as node IDs, IP addresses if applicable), Convergence Layer Adapters, and security configuration, it is possible to establish a LNSP interface.
In our example, using the SPATIAM DTN Manager, the LNSP 1 DTN Network Administrator user can create a logical view of the LNSP 2 and LNSP 3 nodes that are part of the network. Note these nodes are not managed by the LNSP 1 but the LNSP 2 and 3 admins. These admins can have their own administration interfaces with the purpose of publishing their node configuration data. When LNSP 1 login, it is possible to see these nodes, but not possible to manage them.
Figure 5 Managed (LNSP 1) and unmanaged (LNSP 2 and LNSP 3) nodes in the same network overlay.
Managing Network Policies
The DTN Management System becomes the host of the policies that are distributed through the DTN. These policies include security (access control lists, BPSec policies), forwarding, and quality of service, among others.
Figure 6 Example Network Policies for the example LNSP 1 scenario.
The importance of policy management strides in providing a consistent but evolving service level agreement (SLA), and the consistent application of security across the entire network. Then, through the DTN Management System, policies get merged into the node(s) configurations which are then applied locally at each node.
Contact Plan management
Space communications are highly scheduled. This is a consequence of celestial mechanics and limited infrastructure which (mostly) prevents continuous line of sight to enable continued communications. As such, communications are based on contacts, and contact plans are built as the schedule of communication events between two elements in the network. In an LNSP scenario, it is important to have a scalable process in which contacts can be managed dynamically between the users’ payloads, the different LNSPs participating in the network, and cross-support and mission operations.
In this example, the LNSP 1 DTN Network Administrator uses the SPATIAM DTN Manager Graphical User Interface to create a new contact between the Node 1 (Lunar Lander) and LNSP 3 DTN Relay Node.
Figure 7 Contact Plan Management in the SPATIAM DTN Manager Graphical User Interface.
The SPATIAM DTN Manager also offers a Contact Plan API, enabling automation of contact plan management for Network, cross support, inter-LNSP and mission operations.
Figure 8 Use of the SPATIAM DTN Manager Contact Plan API to create a contact between Node 1 (LNSP 1) and Node 303 (LNSP 3).
Network Monitoring and Assurance
Monitoring the network is a critical function to ensure the availability of the network and the Service Level Agreement. Network monitoring requires 365 days, 24x7 operational capability. Network monitoring is intended to give an accurate answer to several questions about the state of the network and its nodes, including:
- Network status. Is the network able to send information between the lunar surface to Earth?
- Network performance. Are the network transferring bundles at the appropriate throughput? What's the bundle error rate? Are there points of congestion?
- Network Security. Are the network security measures active? Are there any known vulnerabilities? Is there any suspicious attack?
- Node status. Is a node running, configured, connected to the network, able to send data?
- Node hardware performance. Is the node hardware healthy? CPU? Memory? Storage?
- Node Bundle memory/storage management. Is the DTN Node memory/storage healthy?
The figures below illustrate some potential time series of the Node detailed metrics. Note these metrics are sent as reports from the DTN Nodes to the DTN Management System for processing and visualization by the DTN administrator. The orchestration of these metrics, both in the DTN Node Management Agent and the DTN Manager, allows for the creation of a lifecycle that includes alarms, congestion control, and other functions to guarantee the availability of the network.
Figure 9 Example Hardware Utilization (Node 1).
Figure 10 Example Bundle Storage (SDR Memory in ION) Reporting (Node 1)
The goal of network monitoring is to optimize the operational network deliver the highest possible availability (uptime), with the highest possible throughput and quality, in short, the best service level possible according to the physical limitations (link, hardware types, etc.).
Integrating with Network, cross-support and mission operations - APIs
The DTN Network is a critical element of the entire communication stack, therefore, its management must be integrated to network operations, and cross-support and even mission operations. In an inter-LNSP scenario the number of integrations increases (one network may support multiple missions, the same network overlay may have more than one acting LNSP). Gradually achieving automation of operations will ensure consistency and increase efficiency, critical for the public and private sectors who look for a return of investment.
To achieve this, APIs (Application Programmable Interfaces) become critical to achieve connectivity and automation at operational level. A DTN Network Management System must provide APIs to integrate with higher level operational systems. With this, network administration can react automatically to network and/or mission changes.
Summary: Network Management is an essential function to operationalize LunaNet DTN Service Providers. It includes management of the network, its nodes, inter-LNSP node interfaces, monitoring and troubleshooting, and automation. Its goal is to deliver the best possible service levels, while securing the network and its users and data.
Next Chapter: Securing the user-LNSP Interface (coming soon!).
