top of page

Many people new to InterPlanetary Networking are surprised to discover that DTN is also considered effective for many terrestrial use cases. That’s because the same kind of constraints exist in many networking environments right here on planet earth. These primarily include disruptions and delays—or perhaps even the absence of traditional Internet infrastructure that would make network communications via TCP/IP unfeasible or prohibitively expensive.


It’s not too difficult to envision some of those environments. Some constraints are inherent in the communication environment itself:

  • Like water as a communication medium. RF waves do not propagate well, but sound waves do, which are incredibly slow and whose speed varies unpredictably with the density of the water column.

  • Or think of underground applications like mining. Cable can be expensive to lay and subject to disruption through unintentional damage by mining equipment. RF does not penetrate the earth.

  • First responders searching through rubble are subject to unpredictable disruptions caused by loss of LOS with wireless signals.

  • Battlefield sensors cannot maintain constant RF contact for security reasons.

  • Finally, many regions that would benefit from Internet services find them unavailable (or prohibitively expensive) simply because they are not located where traditional Internet infrastructure exists. A look at any light pollution map shows you how much of the world does not have ready access to traditional Internet infrastructure.



Examples of experimental implementations of DTN to overcome these constraints include:

  • Providing basic Internet services to reindeer herders in the Arctic Circle in Sweden.

  • Monitoring air quality in a karst cave in Romania.

  • Monitoring the cardiac health of first responders during emergency operations

  • Providing basic Internet services to remote villages in Africa that had no access to traditional network infrastructure


An area of particular interest to the DTN community is the Internet of Things (IoT), where communication is primarily amongst things and not people: sensors in buildings, roadways, on farms and even in our bodies. Because of the mobility of many of these Things, and limitations in power and signal strength, continuous end-to-end connectivity is either not achievable at all, or not maintainable. Since DTN assumes that such continuity does not exist, it can perform a valuable function in the world of IoT (sometimes called the “DTN of Things”).


Our next blog will dive into DTN’s potential role in IoT in more detail.


This blog is a product of the usual suspects: Scott Burleigh (NASA/JPL); Keith Scott (Mitre Corp./CCSDS and Mike Snell (IPNSIG)

As NASA contemplated longer space missions involving multiple spacecraft, they foresaw the need for network automation, much the same as exists on the terrestrial Internet. Missions had to include not only coding for the applications to perform navigation and scientific observations—they also had to support communications with earth. NASA wanted to standardize and automate network communications in space, and at interplanetary distances.


Network automation is a huge advantage of the terrestrial Internet. Application developers in general do not have to worry about the performance of the network, and TCP/IP requires relatively little centralized administration. The Transmission Control Protocol (TCP) in particular, assures reliable communication for applications (almost anything of significance on the Internet uses TCP). TCP does this through a series of exchanges back-and-forth between the sending and receiving hosts in order to establish a communication session; establish communication speed and verify that all of the disparate pieces of a message have been properly received and reassembled at the destination in the right order. If anything is missing, it gets retransmitted.


All of these behind-the-scenes messages between sender and receiver assume that a communication pathway exists between the two that is almost instantaneous in nature. If that assumption breaks, TCP breaks. The session times out and must be re-established.

TCP works relatively well on planet earth because the velocity of light provides almost instantaneous bidirectional communication speeds given the relatively short distances involved (after all, a photon could circumnavigate the globe about 7.5 times a second). However, NASA was contemplating traveling very long distances indeed. The minimum distance from Earth to Mars is about 54.6 million kilometers (about 33.5 million miles). The farthest apart they can be is about 401 million km (about 350 million miles). The average distance is about 225 million km (about 140 million miles). This means round trip times for radio frequency communications ranging from a minimum of about 7 minutes to a maximum of about 40 minutes.


Not only would communications at interplanetary distances involve many, many times the signal delay experienced on earth, but they would also experience significant periods of disruption. Planets have this pesky habit of rotating. Anything on the surface of Mars would experience long periods of communication blackouts while the planet Mars itself blocked line of sight with the earth.


While other factors also constrained data communications at interplanetary distances, delay and disruption were the two primary limitations preventing the architecture of the terrestrial TCP/IP Internet from working in that environment. Which is how Delay/Disruption Tolerant Networking (DTN) got its name.


How to deal with this extreme environment? Change the store-and-forward (albeit for only a few milliseconds) architecture of the Internet to what has come to be called a “store-carry-and-forward” architecture. This uses local storage in network devices themselves to hold onto a much larger “bundle” of data (than an IP packet), and only forward that packet onto its target destination when an opportunity to do so presents itself.


We’ll be explaining this architecture in more detail in future blogs, but first, we’ll explain how DTN, which was designed for use in outer space, has very useful applications in network environments displaying very similar constraints right here on planet earth. That will be the topic of our next blog…


This blog is a product of the usual suspects: Scott Burleigh (NASA/JPL); Keith Scott (Mitre Corp./CCSDS and Mike Snell (IPNSIG)

As promised, here are a number of short videos (none over 7 minutes) that explain basic elements of DTN. Some also include historical information and explanations of the problems DTN solves in constrained environments.


Short (slightly under two minutes) simple animation developed by JPL to explain the basic problems that DTN solves and the basic store-carry-forward architecture.

A slightly longer (about 5 minutes) and slightly more technical animation developed by JPL to illustrate how DTN store-carry-forward approach and custody transfer work.


Basically audio playing against a simple (and non-changing) background with an animated speaker. Good verbal content, but in the later portions, it presupposes a level of computer networking knowledge that would probably make the content difficult for a newbie to absorb.



Another simple NASA video that should be useful for the newbie. This one graphically demonstrates how DTN significantly increases throughput compared to traditional IP in a space data communications environment.

Another pretty simple JPL animation that should be easily understood by the newbie. This one graphically compares the throughput of TCP, UDP and DTN—particularly emphasizing the difference in data throughput between TCP and DTN and the difference in data loss between UDP and DTN.


NASA Jet Propulsion Laboratory. Disruption Tolerant Networking Summary comprised of video clips and animations. Vint Cerf is prominently featured, but if you look carefully, you can spot other


IPNSIG board members (Scott Burleigh and Jay Wyatt) and friends (Leigh Torgerson)


bottom of page