During May of 2021, Spatiam Corporation participated in a field experiment to test the interoperability between different implementations of DTN communication protocols, and validate useful applications via the European Space Agency's (ESA) OPS-SAT satellite.

Spatiam Corporation's goal is to be a driving force in creating the interplanetary Internet, and we are currently in an interesting phase where Delay and Disruption Tolerant Networking (DTN) is growing in interest, scalability, and real-world use that extends typical space point-to-point links into network-based communications. As part of this phase, the OPS-SAT experiments serve as a test of current DTN protocols, and a demonstration of what the interplanetary Internet might look like in the future.

What is OPS-SAT?

OPS-SAT is a CubeSat operated by the European Space Agency (ESA) that despite its size (30cm high), has great computing power compared to many other ESA spacecraft. Its goal is to provide a robust testbed to test new protocols and demonstrate future capabilities that will be made possible by more powerful computing in space.

Why OPS-SAT?

While the experiments that will be described can be simulated without the need of a satellite, adding the OPS-SAT into the network introduces several levels of complexity that exist in space. Limited computing power, short satellite passes, automation needs to make the most out of the satellite window (which lasts a few minutes), and bandwidth limitations are some factors that were considered during the experiment and were tested thanks to the OPS-SAT.

The Network

The set-up system demonstrates a “Ring Road Network”, where cold-spots with no Internet access can communicate with hot-spots via satellites (in our case, the OPS-SAT). The hot-spots can then fulfill the cold-spot's request and forward it back via the satellite. Spatiam Corporation, together with ESA and D3TN GmbH tested the interoperability of two Bundle Protocol implementations (μD3TN by D3TN and ION by NASA/JPL) and ran an image recognition application leveraging Google's Cloud Vision API to demonstrate the capabilities of the network.

Previous Experiments - D3TN

This experiment was round 2 for D3TN and ESA's partnership. In December 2020 D3TN set up the base tests to support the latest interoperability and application use-cases. In this first round an HTTP gateway was tested, where hot-spots could fulfill cold-spot HTTP requests that were routed through the OPS-SAT. During this experiment μD3TN was used as the Bundle Protocol version 7 implementation that ran in every node, including the OPS-SAT.

Test 1: Interoperability Tests

The Bundle Protocol (at its latest version, version 7), is the driving protocol behind delay and disruption tolerant communications. While several implementations of “BP's” latest draft exist, interoperability between them remains a topic yet to be fully tested. μD3TN is D3TN's in-house implementation of the Bundle Protocol. It is a modular and lightweight package that provides an easy-to-use interface to build applications on top of it via the Application Agent Protocol (AAP). The Interplanetary Overlay Network (ION) is NASA's BP (v6 and v7) implementation developed at the Jet Propulsion Laboratory (JPL). ION has a strong focus on robustness and performance, supporting a variety of DTN schemes, multicast functionality, and security mechanisms (BPSec) among other features. While the two implementations rely on different underlying processes, they both abide by the Bundle Protocol version 7 draft and interoperability between the two should be possible.

The initial interoperability test was based on replicating the HTTP Gateway use case already proven by D3TN, but with an ION node as part of the network. The OPS-SAT link is made possible by μD3TN's TCPSPP (Space Packet Protocol) adapter, therefore adjacent nodes to the satellite run μD3TN and during the experiment were managed by D3TN (Coldspot, Hotspot 1 and 2). To test interoperability, an ION node managed by us, Spatiam Corporation, was placed in between Hotspot-1 and Hotspot-2. Hotspot-2 exists so that ION can forward messages through a different route back through the OPS-SAT (vs. bouncing packets back to the same Hotspot-1). This test ran successfully and proved that interoperability between multiple DTN nodes running different BP implementations is possible.

Test 2: Cloud Vision Application

To test the capabilities of this network, with the help of Larissa Suzuki from the InterPlanetary Networking Interest Group (IPNSIG), Spatiam Corporation developed an application leveraging μD3TN interfaces that can receive images, gather image labels from Google's Cloud Vision API, and forward them to the original sender. This would not only validate providing Cloud (AI) services via DTN, but also test how the network handles larger data payloads.

Above are two images used to test the cloud vision application, the goal was to determine the existence of a meteorological phenomenon from a satellite image through a ground computer vision service. Below are the labels produced by the cloud vision application and forwarded back to the sender from the hot-spot.

As seen above, the cloud vision application was able to recognize both images and determine when a "tropical cyclone" was present. These tests ran successfully in the OPS-SAT network, where an ION node sat as the gateway to and from the Cloud Vision hotspot, validating interoperability and application tests together.

Troubleshooting

As one of the first field tests where ION and μD3TN were present in the same network, unexpected behaviors between the implementations were identified. At the time of the tests, ION utilized second-based timestamps as defined by a past Bundle Protocol version 7 draft. However, the latest draft at the time defined milliseconds-based timestamps, which were implemented in μD3TN. While solving other issues it was decided to roll back to a previous μD3TN version to prevent any unexpected behavior and use second-based timestamps throughout the network.

Another interoperability hurdle occurred when sending larger payloads between ION and μD3TN. ION's TCP transmission buffer truncated streams that exceeded its predefined value, which prevented μD3TN from processing the data received properly. With the help of Scott C. Burleigh from JPL, this was quickly recognized and fixed by increasing the TCPCLI buffer size.

Due to bandwidth limitations through the OPS-SAT, together with data possibly being corrupted at any time, D3TN focused on making the system as fault-tolerant as possible. This included adding filtering and rate limiting mechanisms to the CLA for the Space Packet Protocol. You can read more about D3TN's focus during the tests on their blog and slides here.

Lastly, ION - μD3TN connections repeatedly stopped after an extended period (~1 day based on our tests). In spite of that, all tests were able to run successfully as ION and μD3TN instances were restarted whenever connectivity problems showed up. Following the successful OPS-SAT rounds, Spatiam Corporation and D3TN have continued to work on this issue as the root of the problem is still to be determined.

Conclusion

The results of this experiment show the value that field tests can bring to the development of DTN protocols. We successfully set up a network that connected to a real satellite, and transmitted packets through multiple implementations, supporting a variety of applications, and getting us one step closer to a true interplanetary Internet.