Our inspiration came from our backgrounds and interest in communications and space. We know Space is a very lonely place. Imagine you are an astronaut and landed on Mars. What are you going to experience when trying to reach to Earth? Are you going to be able to talk to your family? Are you trained for it?

We know NASA have big plans for human exploration of space: The commercialization of the low-end orbit, returning to the Moon with permanent presence and bringing humans to Mars. NASA has been using each mission as a steppingstone for the next one. 

Artemis mission to bring humans back to the Moon will prepare humans to living in Space. In the short term, one of its main goals is to prepare humans for their journey to Mars. This cover testing new tools, instruments and equipment that could also be used in Mars, including human habitats, life support systems, and technologies and practices that could help us creating self-sustaining settlements outside of earth. The mission will also serve to expose and understand better the effects of deep space radiation on the human body, as Astronauts live for months on Moon Gateway as preparation for to the years-long commitment to Mars. And it will also set precedence in using and managing local and earth resources for the benefit of the settlement.

As part of these new systems, NASA is working on LunaNet, a network architecture with the purpose of providing data transfer, positioning, location, navigation as well as science services. This network is going to be based on the Delay and Disruption Tolerant Networking (DTN) architecture, NASA ION (Interplanetary Overlay Network). NASA is also working on Optical-based links which aim to provide higher throughput when compared to more traditional Microwave Radio Systems currently used in the Deep Space Network and spacecrafts.

As you see, NASA is preparing well for the Moon-to-Mars journey, however going to Mars is much more complex than going to the Moon in many aspects:

•Much longer trip – 17 to 21 Months. Estimated at 7-to-9 Months each way, plus 3 months stay. Astronauts will be confined with communications being the main “window” to Earth. In contrast, traveling to the Moon takes only ~3 days.

•Much longer communications delays – between 3 to 20 min one-way light trip time (OWLT). Moon 1-way light trip time is about 1.3 seconds. That means that it is impossible to maintain a normal conversation between an earthling and a Mars resident.

How do we prepare our astronauts for the Mars mission communications challenges? How do we create the right systems, devices and tools that deliver the best experience to Astronauts and mission goals under these conditions?

Our solution, MarsNetwork Toolkit for communications, or MarsNet-c, is a toolkit for exploring human communications in space.

Our approach to developing this project followed these steps:

•Research and understand the state-of-the-art: We researched on multiple NASA sites to understand: Networking architectures (DTN), current network deployments that we could use as example in our definition: NASA Deep Space Network, NASA Curiosity Rover, NASA Mars Reconnaissance Orbiter (MRO); projects in progress such as LunaNet, and other NASA sites to understand some basic measures such as how you measure time in space. With this, we were able to establish a set of basic principles: 

a)Communications will be based on a messaging service to exchange, messages, images, videos, files and even commands, for human and machine-human communications. Communications cannot be real time (e.g. phone) since the 3-20 min OWLT delay makes it impossible. 

b)We will use environmental/link variables based on NASA Data, such as ephemeris-based OWLT (one way delay) tables between Earth and Mars for a long period of time (using Horizon data), how long is the connection time between DSN and MRO per day (~8 hours) or what’s the throughput of the link depending on the OWLT (between 500 kbps and 6 Mbps), or the throughput for the uplink UHF link between a rover (or Astronaut) and the MRO – 1 Mbps, which passes on between ~1 to 13 times per day, with contact duration of about 8 minutes each depending on user location on Mars surface. For the prototype we focused on the delay data to emulate a Mars environment. We used a satellite relay as it provides the best flexibility to provide wide coverage on Mars surface as well as dealing better with the fact that both Earth and Mars are rotating and line of sight would not be possible for long periods during the day. We decided to work with real references (MRO, Electra Radio, DSN) that although provides lower performance when compared to some of the new concepts such as optical links (higher throughput) or orbit-synchronous or network of satellites, gives us real reference data about how things work.

c)Networking based on Delay Tolerant Networking as it is the only networking technology proven to work in deep space, because of the long delays and the disruptions. We chose NASA ION DTN as it is the obvious choice for a space application. More specifically we used version 3.7.1 since it supports Bundle Protocol v6 which provides for better interoperability compared to the newer v7. 

•We brainstormed to define and refine the system requirements beyond the principles specified above, and make the first pass to define the system architecture

a)Established User Requirements which are exposed through the Communicator Interface. 

As a user, I would like to: 

-Communicate with Earth as a user from Mars (and vice versa), as well as other users that are local or in other deep space locations with MarsNet-c connectivity

-Send text, video, photos, and files from within the platform, 

-Know an estimate of when my message is expected to arrive, 

-Know when my message has been received and read, 

-Be notified when I receive a message, and when a message has been received and read.

b)Defined specific user requirements for the Rover.

As a Rover user, I would like to:

-Send commands and receive telemetry data from a rover connected to MarsNeT-c. Data includes commands, files, and telemetry data.

c)Defined the system architecture:  

-Use of Amazon Web Services (AWS) as the public cloud to host the Mars node, Mars Relay (+delay) Node and Earth Node. Use of EC2 instances with Linux operating system and separate VPCs (virtual networks) to assume no local area network services are available.

-Use of ION-DTN services, more specifically the bundle protocol (BPv6) for all DTN nodes. Uses ION-DTN version 3.7.1.

-Use of Python to create delay, listener (and Rover functions) modules integrated with the different DTN nodes.

-Use of Raspberry Pi 4 (Rpi4) as the rover hardware platform, with a connected camera, and LED and TCP/IP over local WiFi connection.

Figure 4. MarsNeT-c Systems Architecture

•We developed an execution plan according to our resources: time, budget and capabilities.

We divided our main responsibilities:

-Heather: User Experience lead. Definition of personas and UI explorations.

-Shawn: Communicator Front-end development.

-Alberto Montilla Ochoa: AWS infrastructure, backend DTN node installation and configuration, Delay module, and listener/forwarding co-development and validation.

-Eric: Rover hardware and software development, installation and configuration, and listener/forwarding co-development and validation.

-Alberto Montilla Bravo: Research, Systems Requirements documentation and scrum master, main interface with NASA SpaceApps Ambassadors. 

We established our ceremonies and toolset: One sync-up every morning, noon, afternoon and evening. We used chat and meeting tools to keep continuous communications.

•We started the development of the main components

a)Persona definition and user experience details for the communicator.

-User: We defined Astronauts, Mission Center comms personnel, friends and family as the main users. We did iterations to understand better potential options for the interfaces given the device carrying the Communicator functionality, for example Computers with a keyboard (https://share.proto.io/0AHW5N/), and touch-screens attached to the Astronauts spacesuit or arm for example (https://share.proto.io/IGXQK9/).

-Network Operations Admin: Specially on Deep Space it is important to understand the status of the network, its links, as well as being able to manage buffers/queues, to deal to unexpected situations. For example, visuals (https://share.proto.io/SD293H/) that shows node and link status can be used to monitor the status as well as clicking on the nodes to see queue status and even modifying priorities.

-Simulation Admin: As we initially use MarsNeT-c as a toolkit to emulate communication scenarios, the simulation admin will need to adjust parameters such as link characteristics (X-band vs Optical), existence of Relays, which fundamentally change the communications characteristics and then the overall experience.

b)Software and Infrastructure development, i.e. software development for all the components, i.e. front-end and backend services. Picture below depicts the software implementation in the backend services including the listening scripts that connects to the ION-DTN implementation on each node, the delay service connected to NASA-provided ephemerides data, and the Rover command functions. Configuration data to initialize and configure the DTN nodes is not shown here.

Figure 5. MarsNeT-c Software Implementation

c)Documentation. We have documented everything. It is important to be able to understand reasoning, progress and to reflect all work that happened.

•System Integration and validation: As components were developed, system integration sessions took place to integrate all services together, so we exercised end to end messaging and file delivery:

a)Earth-Mars user messaging

b)Rover command and telemetry data exchange

As we started testing, it was clear that waiting for 3 minutes and many seconds (current OWLT between Mars and Earth) to read a message received would be very time consuming, so we found a way to manually “edit” the delay forwarding plan so messages would be sent faster than normal after reception. This in itself is an example of how challenging human communication is in presence of “Mars” delays.

•We packed everything and delivered the solution!

Our hacking experience has been tremendous. Following are our main accomplishments.

We completed the cycle from research, requirements, design, implementation, integration, validation and documentation successfully for our primary objective: A MarsNeT-c prototype

We delivered a prototype implementation of MarsNeT-c with the following capabilities:

•A Delay and Tolerant network which consists of a Mars Communicator Node, a Mars Rover Node, Mars Relay Node, and Earth Terrestrial Node.

•Mars Rover Node with support of: Echoing a command (sort of ping), taking a real picture and sending it to Earth upon command, sending real Mars weather data upon command (sensor data obtained using NASA Mars Weather API), and to receive a generic command (which turns an LED on).

•A network Delay function, which uses NASA HORIZON Ephemeris data, more specifically the One-Way light trip time (OWLT), to delay the bundles on the relay node emulating the long delays. This delay function effectively changes the delay based on the ephemeris data (e.g. delay is approx. 3.4 min now, and it can get up to 20 min in the next two years).

•The Communicator: A web application aimed by Astronauts in Mars to communicate with local users, Earth Mission Control and with Friend and Family thru MarsNeT-c. The prototype implementation has the capabilities to send messages, video, images and other files. The communicator is available on http://18.210.189.182:4200/spatiam-platform but not fully integrated with the MarsNeT-c network given some issues with the file system approach (see lessons learned below).

We were able to use NASA (and CSA) resources, data, software and tools: NASA Interplanetary Overlay Network (ION) DTN distribution, NASA Horizon services for ephemeris data, NASA Mars Weather API, and multiple documents containing valuable information to understand the challenge.

We were able to brainstorm and discuss the potential of MarsNeT-c provided we get support for continued research and implementation:

•Training testbed for humans (both Astronauts, Control Center and even family) to understand the behavior in front of heavily delayed communications, as well adapting the tools for the best experiences.

•A training vehicle to incorporate additional functionality such as cognitive behavioral therapy to manage the long trips and the solitude of space.

•MarsNeT-c can itself evolve to incorporate Position, Navigation and Timing as well as Science Functions and contribute to the development of LunaNet.

•We can evolve MarsNeT-c to support/emulate various connectivity options. Currently our architecture is based on a Mars (satellite) relay using UHF (Relay-to-Mars) and X-band (Relay-to-DSN). This can incorporate another link and physical layer architecture, e.g. using optical links to understand how better throughput could allow access to other type of content, e.g. Internet web caching to allow visualization of a number of curated Internet sites (information services).

•On the Earth Terrestrial node, MarsNeT-c can evolve to support a multi-tenant, multi-agency/user scenarios. Security, scalability and connectivity flexibility are areas of consideration.

And, we were successful in having fun working together as a multidisciplinary group with experience on system architecture, software development, instructional design to learn and deliver on this challenge.

This is just an initial list of examples of our accomplishments. We also had some learnings, some of which we had to work around, and given the time, resources and support, we would like to tackle in the near future.

•We initially decided to use a file exchange mechanism between the Communicator and the network nodes in order to provide a very lightweight integration mechanism that would work for embedded systems. We discovered that the security architecture of commercial internet browsers imposes very restrictive ways to deal with the file system. This affected our capabilities to extend our work in the communicator, e.g. our reception mechanism did not work well with the communicator (however it worked great for the rover). We explored other integration mechanisms (a REST API) or a native application that does not rely on the browser for the communicator, but it was too late to change implementation.

•DTN is written in C language (given its main/initial purpose to run on a spacecraft). There is not an easy way to have a DTN node on a tablet or smartphone. The DTN distribution on Android does not work (it is a few years old). That also limited our options for the Communicator device to a laptop interface.

•The ION Contact Plan is more complex than what we originally anticipated. For example, in addition to each contact (creating a contact table), there is the possibility to specify bandwidth, contact times and contact windows for each contact. We did not have time to experiment to fine tune and connect these parameters to an administrator interface. This would be useful when using MarNeT-c to simulate different network connectivity scenarios.

We used the following Data, Software and Tools (the reference section contains the links):

NASA ION DTN Distribution: ION is the Interplanetary Overlay Network, or NASA Delay and Disruption Tolerant Networking implementation. It is open source. We are using version 3.7.1 which incorporates the Bundle Protocol (BP) version 6. It is worth noting that ION is written in C language. We customized/enhanced the solution with several python software modules: (a) Listeners: Integrated into every DTN node. The listener module search for new messages, files to be transferred. (b) Delay function: This is a configurable DTN node that emulated the 1-way light trip time (delay) for the data to travel from a celestial body or spacecraft in deep space and earth. Current version relies on a text file that is pulled from Horizon DB to modify the delays obtained from the ephemerides table. (c) Node Routing function: IP-address based routing function, which resides on every node to understand where to send the bundles based on the final destination address. Currently using IP-addressed. It is to be discussed (with NASA) whether it should remain IP-based or it should be EID based (there is value on keeping IP as the addressing – different than networking – layer). (d) Rover function: The Rover Node is heavily based on the DTN functionality already described. It was extended to support command-based telemetry for the delivery of echo, command weather, imaging data functions.

NASA Horizon data for ephemerides between Mars and Earth: More specifically, we are using the 1-way light trip time (OWLT), to estimate delay of transmitting a signal from Mars to Earth across different dates. The delay function on the Relay node incorporates the Ephemeris Database, so based on time of the day it selects the right delay to apply (currently about 3 min, 45 sec). The Horizon website allows to select any two celestial bodies and calculate the ephemeris data according to the time table provided.

NASA - Insight Mars Weather API. We used it with our Rover implementation (Raspberry Pi4) to emulate sensor data capture. Basically once the Rover is queried for weather data, it uses the API to gather the real value, basically simulating all sensors. Together with the API we used a simple python code to extract the data.

Various information about NASA network capabilities between Mars and Earth: NASA DSN contact windows with Mars (~10 hour/day: 16 hours of operation by 2/3 observation time), characteristics of the links (500kbps-6Mbps) at UHF and X-band, using MRO orbit times as examples (orbit every 112 min).

Demo video: https://youtu.be/oJLhNbJB2UA

External Data, Software & Tools 

1. NASA. ION DTN. The Interplanetary Overlay Network (ION) software distribution is an implementation of Delay-Tolerant Networking (DTN) architecture, as described in Internet RFC 4838, that is intended to be usable in embedded environments including spacecraft flight computers. Open Source Distribution. https://sourceforge.net/projects/ion-dtn/
2. NASA – HORIZONS Web Interface. Jet Propulsion Laboratory, California Institute of Technology. It provides data thru a web interface about Ephemerides, 1-way light trip time (OWLT) between celestial bodies, based on a time-range query. We used the OWLT as the one way delay estimation (as radio waves travel at light speed) https://ssd.jpl.nasa.gov/horizons.cgi
3. NASA - Insight Mars Weather API. Used with our (RPi4) rover to emulate sensor data capture. Available at https://api.nasa.gov
4. Holypython.com - Mars Weather Service. Simple python code used together with the API to extract the data. Available at https://holypython.com/api-2-mars-weather/
5. Jim Taylor, Dennis K. Lee, and Shervin Shambayati. Mars Reconnaissance Orbiter (Chapter 6), (NASA – DESCANSO). Used to derive contact windows and orbits as well as data rates for the Curiosity Rover contacts. https://descanso.jpl.nasa.gov/monograph/series13/DeepCommo_Chapter6--141029.pdf
6. NASA – Mars Reconnaissance Orbiter communications with Earth summary. Used to extract information about orbit time and data transfer rates with NASA Deep Space Network (DSN) stations. https://www.nasa.gov/mission_pages/MRO/spacecraft/communication.html
7. CSA - Canadian Space Agency. README for 2019 LEAD Campaign Data. CSA partnered with the European Space Agency (ESA) to conduct a series of field tests to replicate scenarios of a lunar sample return mission. Data and documents located here served to setup a command-control scenario using DTN on an emulated rover (Raspberry Pi 4). We emulated the ROS syntax over the real DTN network and the Rover connected via WiFi. ftp://data.asc-csa.gc.ca/users/OpenData_DonneesOuvertes/pub/Lunar Exploration Analogue Deployment (LEAD) - Rover Data/ 

References & Documents

1. NASA – Delay/Disruption Tolerant Networking. Human Exploration and Operations Directorate, Space Communications and Navigation (SCaN). Sept 29 2020. https://www.nasa.gov/directorates/heo/scan/engineering/technology/disruption_tolerant_networking
2. NASA – Artemis Plan. NASA’s Lunar Exploration Program Overview. September 2020. Used to understand networking and communications plan, including use of DTN on LunaNet. https://www.nasa.gov/sites/default/files/atoms/files/artemis_plan-20200921.pdf
3. NASA – LunaNet: A Flexible and Extensible Lunar Exploration Communication and Navigation Infrastructure. Goddard Space Flight Center. ESC - Exploration & Space Communications. September 2019. https://esc.gsfc.nasa.gov/news/_LunaNetConcept
4. NASA – What Time is it in Space? NASA Science, Solar System Exploration. https://solarsystem.nasa.gov/what-time-is-it-in-space/ 
5. Wikipedia – Electra (Radio). Detailed explanation of NASA’s Electra UHF SDR (Software Defined Radio) relay used in MRO. Used to model our uplink data transfer characteristics. https://en.wikipedia.org/wiki/Electra_(radio) 

Acknowledgments

•Interplanetary Networking Special Interest Group (IPNSIG) of Internet Society for promoting the Interplanetary Internet to all. http://ipnsig.org/ 

•NASA and CSA for providing valuable data and references to expand our knowledge. CSA data was very valuable for us to understand some rover concepts we could incorporate in our concept and demo.