Space Communication

DTN

Network data transfer uses routers that forward data through wire or fiber optic links. The UDP protocol used to send packets from source to destination needs a perfect path to succeed 100% but comm links between routers are not always reliable or available. Internet routers discard any packets that cannot be forwarded because a link is down. The result is that data is lost between sender and receiver if the end-to-end connection is not perfect. With DTN, routers are replaced with DTN nodes that can store and later forward bundles of data. If a link is down, a DTN node will hold the bundle until the link comes back up. DTN uses this store and forward mechanism to handle disruptions in the end-to-end path so all bundles can get through. Sometimes even if a router or DTN node thinks a link is up, a packet or bundle can still be lost enroute. For this reason, both the standard internet and DTN have reliability protocols to retransmit missing data. The internet has TCP (Transmission Control Protocol) for reliability. TCP requires end-to-end acknowledgments as it first establishes a connection with control packets. If a packet is lost due to a bad link, the sender will retransmit the packet.

DTN uses hop-by-hop custody transfer, successive nodes take custody and the bundles migrate toward the destination. If a bundle is lost, and custody isn't acknowledged by the next node, the last custodian retransmits. As a result, DTN provides:

Reliable data transfer without a complete contemporaneous end-to-end path to destination.
Retransmission from the closest relay node rather than from the sender.
Custody transfer and return receipt operations.

The DTN bundle protocol was flown on the Epoxi spacecraft for the first deep-space use of DTN and DTN experiments are currently being conducted on the ISS. With one-way light times up to ~20 minutes from Earth to Mars, DTN provides internet-like data transfer at interplanetary distances. With future crosslinks, DTN will provide multiple data paths between Earth and landed assets and will also enable in-situ autonomous science missions and sensor cueing.

LTP

Licklider Transmission Protocol is a point-to-point protocol for use in deep space links. LTP is commonly seen as the standard underlying convergence layer protocol for the Bundle Protocols (RFC 5050).

LTP is designed to run directly over a data link layer (e.g. the Advanced Orbiting Systems (AOS) Space Data Link Protocol). It can also run on the User Datagram Protocol (UDP), e.g. if used in a sensor network, in a private network (where bandwidth contestation isn’t an issue), or for software debug purposes. Therefore, it does not address issues like routing or congestion control. It was originally designed to support “long-haul” transmission in an interplanetary network.

Features

Reliable data transport for important data (such as a file header)
Unreliable data transport for less important data (such as image pixels—a damaged pixel can be overcome)
The protocol operates without needing message exchanges for negotiation, eliminating delays that arise from long round-trip times and preventing underutilization of the link.
It's designed for energy efficiency, transmitting data only when a link is active and differentiating between critical and non-critical information.
The protocol's timers are integrated with communication schedules, allowing for suspension during planned link outages.
It requires knowledge of link layer availability, round-trip time, and communication schedules, necessitating a management information base (MIB).
The protocol, known as LTP, is characterized by maintaining extensive state information. It supports one-way transmission sessions to overcome challenges related to long round-trip times or the inability of a communicating peer to transmit.

The application divides its data into two parts (either part may have a size of 0):

a red part: It contains data that has to be transported reliably, has to be acknowledged by the receiver, and has to be held available until acknowledged. This could, e.g., be a header that contains important information to decode the following data, and whose corruption would render all following data useless.
a green part. It contains data that does not require reliable transport. Since reception of this data is not acknowledged, it can be discarded after transmission.

Reference implementations

ION, written in C by the Jet Propulsion Laboratory and maintained at Ohio University.
LTPlib, written in C by Trinity College, Dublin.

Multicolor LTP

After a thorough examination of basic LTP mechanisms for all color variants, orange seems particularly appealing for video streaming and optical interplanetary links. In orange sessions sender is notified so BP whether the block has really been received, but without implying the burden of segment retransmissions unlike green sessions.

Because orange data segments are never retransmitted, the Tx-buffer is immediately deallocated, as in green, but by contrast to green the reception session must stay open for at least one RTT until arrival of the success/failure notification. An orange notification timer is set to cope with possible notification loss.

Page updated

Google Sites

Report abuse