Communicating Beyond Earth's Boundaries
As our satellites and space probes venture ever further into the solar system, a fundamental question arises, how do we maintain reliable communications with space devices and infrastructure located hundreds of millions of kilometers away ?
Traditional Internet protocols, designed for near-instantaneous exchanges, prove completely inadequate when light itself takes several minutes to travel the distance between two nodes. This physical constraint has pushed engineers to completely rethink the architecture of space communications.
The result ? Delay Tolerant Networking (DTN), a system capable of operating despite extreme latencies, frequent interruptions, and intermittent connections. This article offers a technical analysis of Deep Space Networking mechanisms, examining the operation of the Bundle Protocol and the TCP Convergence Layer.
In the vastness of space, communications don't follow the usual rules of the Internet. Signals take several minutes, even hours, to travel the distances separating Earth from space probes. To meet this challenge, engineers have developed a particular network architecture DTN, or Delay Tolerant Networking.
An Architecture Designed for Latency
DTN refers to an information network capable of supporting latencies of several minutes and operating over very long distances. Unlike traditional Internet protocols that require continuous connections, this technology adopts a "store-and-forward" approach each network node stores data until the next node becomes available.
In the example we'll see below, a host A sends a segmented packet to a host B, which then relays it to a host C. This transmission chain allows for bypassing the frequent communication interruptions in the space environment.
Identity Announcement, First Step of the Dialogue
Before any data transfer, network nodes must identify themselves. If we select one of the UDP packets framed in red, we see in the data section a host announcing its DTN endpoint ID. Thus, host 10.0.0.1 announces that its endpoint ID is n1 (as if it were announcing its name on the network).
This phase does not yet constitute a data transfer. It is simply an identity announcement, a preliminary introduction that will allow future exchanges to occur in a targeted and efficient manner.
Beyond identity announcements, the network reveals its structure through other types of packets. TCPCL (TCP Convergence Layer) packets constitute valuable indicators, even when they carry no data. These connection maintenance packets, though simple, fulfill an essential function they keep links active between nodes despite the absence of data traffic. By periodically sending these presence signals, each host solicits a response from its counterpart, thus confirming that the connection remains operational.
Analysis of these KEEPALIVE packets alone already allows sketching the network topology. By observing who exchanges maintenance signals with whom, it becomes possible to get a general idea of which hosts can see the others. Each KEEPALIVE packet sent and received traces a line of visibility in the space network architecture, revealing direct connections between different nodes before any data transfer even occurs.
N° |
Source |
Destination |
7 |
10.0.0.3 |
10.0.0.4 |
8 |
10.0.0.1 |
10.0.0.3 |
9 |
10.0.0.3 |
10.0.0.1 |
19 |
10.0.0.2 |
10.0.0.4 |
20 |
10.0.0.2 |
10.0.0.1 |
21 |
10.0.0.1 |
10.0.0.2 |
This mapping reveals significant blind spots host 10.0.0.1 doesn't send KEEPALIVE to 10.0.0.4, and vice versa. The same phenomenon is observed between 10.0.0.3 and 10.0.0.2.
These communication absences are not insignificant. They suggest the presence of obstacles between certain nodes, such as a planet whose mass would block direct transmissions. In the space environment, line of sight is often the essential condition for successful exchange two hosts separated by a celestial body simply cannot see each other, and therefore cannot communicate directly.
Back in Wireshark, the analysis now focuses on the moment when data actually begins to transit. A first packet stands out with a length significantly greater than the previous ones, so there is probably data inside.
BUNDLE over TCP
The Bundle Protocol does not constitute a transport protocol, but rather an application layer. This distinction is fundamental other applications can rely on it to operate in the space environment.
Let's say we want to create an SFTP or FTP service in space across the galaxy it's possible. The user would type their usual FTP commands, but these commands would transit through the Bundle Protocol to deliver the data.
The term "bundle" designates an encapsulated data unit, designed to be transferred from one point to another in the network. This bundle can contain very diverse types of data scientific measurements collected by instruments, images captured by onboard cameras, videos, or any other type of information requiring reliable delivery despite the constraints of deep space.
The Bundle Protocol is based on a storage and transfer logic for data. This architecture fundamentally differs from classic Internet protocols instead of requiring a permanent end-to-end connection, each node temporarily stores the data before transmitting it to the next available relay.
Inside a bundle, we find different bundle segments, as illustrated in the diagram below. Each segment constitutes a portion of the original bundle, thus facilitating its progressive transmission through the network.
In the observed case, the bundle being transferred from the first host to the relay has been divided into four distinct segments. If one of the segments fails or suffers corruption during transit, only that portion will need to be retransmitted, rather than the entire bundle. This granularity significantly improves transfer efficiency in an environment where each transmitted bit represents an investment in time and energy.
These bundle segments themselves contain TCP segments. This nested doll structure reveals the multi-layered architecture of the system the Bundle Protocol operates at the application level, while TCP ensures transport.
This double segmentation allows combining the advantages of each protocol. TCP handles the reliability of immediate transport between two adjacent nodes, while the Bundle Protocol orchestrates the global routing of data across the entire space network, even when connections are intermittent or delayed by several minutes.
Non-Aligned Segmentation
A crucial aspect deserves to be highlighted a TCP segment can simultaneously contain data from bundle segment A and data from bundle segment B.
This absence of strict alignment between layers reflects the system's flexibility. TCP fragments data according to its own packet size constraints, without concern for the logical boundaries established by the Bundle Protocol at the upper level.
For example, in the 6th TCP segment, we could see a header indicating that a new bundle is arriving soon.
In frame 14, we can see that frames #11, #13, and #14 were solicited to create this bundle the values in parentheses indicate the amount of data contained in this bundle segment.
Each frame contains a portion of the data necessary to constitute the complete bundle. The values written in parentheses indicate the amount of data contained in each bundle segment. These metadata allow the receiving system to verify the integrity of the transfer by knowing precisely how many bytes each frame is supposed to contribute, the node can ensure that no data has been lost or corrupted during transmission.
This rigorous accounting constitutes an essential safeguard in an environment where transmission errors can occur at any moment, and where requesting data again means waiting several additional minutes.
To simplify the reading and analysis of network captures, two new data fields will be added to Wireshark's columns. But before proceeding with this interface customization, it is necessary to understand in detail each field contained in the "TCP Convergence Layer" section.
- The part framed in red corresponds to the TCP Convergence Header. It should be noted that this header contains more fields than in the simple TCPCL KEEPALIVE packets observed previously.
- The part in green identifies the packet type field. In this specific case, it is data, signaling that this segment carries a payload rather than a control message.
- In the pink section, there is a bit that would indicate if this is the beginning of the bundle.
- Regarding the blue part, it's the opposite there is a bit that would indicate if this is the end of the bundle.
- And finally, the yellow part indicates the size of the TCP bundle segment.
Display Customization
We will want to add a column for:
- Packet type (GREEN)
- Bundle start (PINK)
- Bundle end (BLUE)
We will therefore be able to more easily identify the beginning and end of bundles. However, one element stands out we notice that in frame #49, the values indicating the beginning or end of a bundle are both set to TRUE it is its own bundle.
It serves as a report, telling host 10.0.0.1 "I have successfully delivered the bundle."
The analysis of network captures thus reveals certain mechanics of Deep Space Networking. An interesting detail appears in frame #49 the start and end markers are both set to TRUE. This means it is a complete bundle that fits in a single segment.
In other words, it is an acknowledgment of receipt, adapted to the delays of several minutes characteristic of these networks.
From DTN theory to concrete network captures, we see how these systems actually work. Each KEEPALIVE packet maintains connections, each bundle segment carries its share of data, and each control bit ensures that nothing is lost along the way.
In an environment where even light takes time to travel, these protocols enable maintaining reliable communications with probes millions of kilometers away.
Resources: