Text Size
Disruption Tolerant Networking
March 24, 2014


Space Communications and Navigation (SCaN) is developing a set of international standards, collectively referred to as Disruption Tolerant Networking (DTN) standards, to support internetworking in space. The DTN standards support a network service (similar to Internet Protocol (IP)), reliability (similar to Transmission Control Protocol (TCP), but implemented very differently), and security. These are all designed to work in environments where end-to-end paths may not be available, such as when an orbiter needs to receive data from Earth and then wait, before it can forward it to a lander on another planet.

Presently, when you think of the Internet you think of an information network that is always interconnected, or "always on" and has very few delays. Many of the Internet Protocols in fact assume this type of always-on, low-latency connectivity, and will not function, or function poorly, when those assumptions are violated. Unfortunately, the space communications environment prospers in these types of disruptions to communications. Planets and satellites orbit, but they are not always aligned so that data transmission can occur immediately. Therefore, the ability to send and receive data is disrupted. Information processing nodes, satellites or ground stations, need to be able to store the data that they receive until they are able to safely send it to the next node in the network.

The NASA DTN work began in the standards program in the office of SCaN, and standardization continues there in coordination with the Consultative Committee for Space Data Systems (CCSDS). In 2014, prototyping and deployment work shifted from SCaN to Advanced Exploration Systems (AES) which is deploying DTN on the International Space Station (ISS). The ongoing SCaN and AES efforts are complementary and result in a spiral evolution, where capabilities are first developed and prototyped by AES , then standardized by SCaN so that standardized and interoperable versions can then be leveraged by multiple missions from different space agencies (including NASA).


Why Develop DTN?

DTN provides a general-purpose network- /transport-layer service that is logically similar to what TCP/IP provides for the terrestrial Internet, but suitable for use in the space environment. In addition to the basic store-and-forward internetworking service, DTN also provides: efficient reliability; security; in-order delivery; duplicate suppression; class of service (prioritization); remote management; a ‘DVR-like’ streaming service, rate buffering, and data accounting, all over possibly asymmetric and time-disjoint paths. Multiple applications including file transfer, messaging (e.g. for mission operations), and streaming audio/video can all be implemented on top of DTN and leverage its services to reduce risk, cost, and complexity.

CCSDS has other specifications that individually implement some aspects of the network and transport-layer services that DTN provides, but none of them provide the flexibility or automated data transfer that DTN does.  For example:

  • Space Packet Protocol: The space packet protocol supports a path addressing capability – essentially the ability to forward packets across a managed end-to-end data path through the network – but this capability has never been implemented in a space system.  No provisions are made for addressing the scheduled nature of connectivity, nor does the space packet protocol support any of the DTN capabilities listed above (beyond a simple unreliable data transport).
  • CCSDS File Delivery Protocol (CFDP): CFDP is a file transfer protocol that provides reliable delivery of files, and includes its own optional application-layer store-and-forward mechanisms. These store-and-forward operations form the basis for the DTN reliable data transfer mechanisms, but CFDP itself only supports file transfers (not messaging, streaming, or other applications).

What are SCaN's Goals as they develop DTN?

  • Produce an internationally standardized and off-the-shelf family of interoperable DTN protocols that is ready for space mission use.
  • Encourage the transition / infusion of DTN protocols to multiple ground data systems and missions to achieve synergy and promote a ‘network effect’ whereby multiple missions can cooperate to increase mission data return and reliability while decreasing cost and risk.

Date Event
December 2013 Bundle Protocol (BP) completes CCSDS evaluation process; still requires interoperability testing in order to become full Recommended Specification
November 2013 BP and Licklider Transmission Protocol (LTP) are demonstrated over the NASA Lunar Laser Communication Demonstration (LLCD) optical links to and from lunar orbit
› DTN Experiments with Optical Communications
June 2013 JAXA completes ground testing of Bundle Protocol in advance of experimentation over Data Relay Test Satellite (DRTS)
October 2012 As part of its Multipurpose End-To-End Robotic Operations Network (METERON) project, the European Space Agency (ESA) uses the BP to control a Lego ‘Rover’ from the International Space Station
› NASA, ESA Use Experimental Interplanetary Internet to Test Robot From International Space Station
August 2012 LTP completes second CCSDS Agency review; still requires interoperability testing in order to become full Recommended Specification
July 2012 The Spheres project tests DTN on free-floating sensors on board the International Space Station
› Human Exploration Telerobotics Project Demonstrates Remote Operation of “Smart Spheres” on Space Station
December 2010 DTN flight test on Earth Observer 1 (EO-1) spacecraft.  The BP was successfully demonstrated and mitigated an issue with the flight avionics whereby some data was being lost because it could not be stored until transmitted
› Benefits of Delay Tolerant Networking for Earth Science Missions
August 2010 CCSDS Green Book 734.0-G-1 published
› Rationale, Scenarios, and Requirements for DTN in Space
June 2009 BP deployed into Common Generic BioServe Apparatus (CGBA), a payload on the International Space Station. The BP allowed the Commercial Generic Bioprocessing Apparatus (CGBA) system to reduce its communication overhead by roughly three orders of magnitude (due to the reliability and automatic acknowledgement mechanisms in BP).
› Delay/Disruption-Tolerant Networking: Flight Test Results from the International Space Station
October 2008 NASA experiments with the BP on the Deep-Impact Networking experiment (DINET).
› DTN Technology Flight Validation Report
September 2008 LTP (reliable data link layer protocol for use underneath BP) published as Internet RFC 5326.
March 2008 Space Internetworking Services (SIS) Delay Tolerant Networking working group formed within CCSDS to develop ‘profiles’ of the dtnrg Internet Drafts of BP and LTP for use in space.
› DTN SIS Working Group
November 2007 BP specification published as Internet RFC 5050.
January 2004 NASA teams up with the Defense Advanced Research Projects Agency (DARPA, inventors of the Internet) to drive a second-generation DTN protocol and demonstrate DTN utility in a range of terrestrial environments.
May 2002 Demonstration of proof-of-concept DTN protocols, including store-and-forward and reaction to changing connectivity.
First version of the DTN protocol (Bundle Protocol) specification drafted.
Internet IPN research group re-chartered as ‘Delay Tolerant Networking Research Group’ (dtnrg) to acknowledge the applicability of the protocols to terrestrial environments and scenarios.
December 2000 NASA reaches out to the terrestrial Internet research community and forms the InterPlanetary Netowork (IPN) research group as a research group in the Internet Research Task Force.
July 1998 In the wake of successes with relay experiments for Mars spacecraft, NASA begins investigating the design for a standard protocol that can provide ‘Internet-like’ services to spacecraft that may be in deep-space and/or only intermittently-connected to Earth. A team of researchers is formed that includes Dr. Vint Cerf, co-author of the TCP/IP protocols.
Image Token: 
Image Token: 
Disruption Tolerant Networking can reduce delay and increase throughput
Disruption Tolerant Networking can reduce delay and increase throughput
Image Token: 
The ongoing SCaN and AES efforts are complementary and result in a spiral evolution
The ongoing SCaN and AES efforts are complementary and result in a spiral evolution
Image Token: 
Image Token: 
Page Last Updated: March 25th, 2014
Page Editor: Thuy Mai