DTN: Technical Overview and the NASA Space DTN Project
No abstract available
SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
No abstract available
The International Space Station (ISS) is in an operational configuration and nearing final assembly. With its maturity and diverse payloads onboard, the opportunity exists to extend the orbital lab into a facility to exercise and demonstrate Delay/Disruption Tolerant Networking (DTN). DTN is an end-to-end network service providing communications through environments characterized by intermittent connectivity, variable delays, high bit error rates, asymmetric links and simplex links. The DTN protocols, also known as bundle protocols, provide a store-and-forward capability to accommodate end-to-end network services. Key capabilities of the bundling protocols include: the Ability to cope with intermittent connectivity, the Ability to take advantage of scheduled and opportunistic connectivity (in addition to always up connectivity), Custody Transfer, and end-to-end security. Colorado University at Boulder and the Huntsville Operational Support Center (HOSC) have been developing a DTN capability utilizing the Commercial Generic Bioprocessing Apparatus (CGBA) payload resources onboard the ISS, at the Boulder Payload Operations Center (POC) and at the HOSC. The DTN capability is in parallel with and is designed to augment current capabilities. The architecture consists of DTN endpoint nodes on the ISS and at the Boulder POC, and a DTN node at the HOSC. The DTN network is composed of two implementations; the Interplanetary Overlay Network (ION) and the open source DTN2 implementation. This paper presents the architecture, implementation, and lessons learned. By being able to handle the types of environments described above, the DTN technology will be instrumental in extending networks into deep space to support future missions to other planets and other solar system points of interest. Thus, this paper also discusses how this technology will be applicable to these types of deep space exploration missions.
The main purpose of Distributed interplanetary Delay Tolerant Network Monitor and Control System as a DTN system network management implementation in JPL is defined to provide methods and tools that can monitor the DTN operation status, detect and resolve DTN operation failures in some automated style while either space network or some heterogeneous network is infused with DTN capability. In this paper, "DTN Monitor and Control system in Deep Space Network (DSN)" exemplifies a case how DTN Monitor and Control system can be adapted into a space network as it is DTN enabled.
This slide presentation reviews the testing of the Delay/Disruption Tolerant Network (DTN) designed for use with Lunar Surface applications. This is being done through the DTN experimental Network (DEN), that permit access and testing by other NASA centers, DTN team members and protocol developers. The objective of this work is to demonstrate DTN for high return applications in lunar scenarios, provide DEN connectivity with analogs of Constellation elements, emulators, and other resources from DTN Team Members, serve as a wireless communications staging ground for remote analog excursions and enable testing of detailed communication scenarios and evaluation of network performance. Three scenarios for DTN on the Lunar surface are reviewed: Motion imagery, Voice and sensor telemetry, and Navigation telemetry.
This slide presentation reviews the implementation and future uses of Delay/Disruption Tolerant Networking (DTN) for space communication, using the International Space Station as the primary example. The presentation includes: (1) A brief introduction of the current communications architecture of the ISS (2) How current payload operations are handled in the non-DTN environment (3) Making the case to implement DTN into the current payload science operations model (4) Phase I DTN Operations: early implementation with BioServe's CGBA Payload (5) Phase II DTN Operations: Developing the HOSC DTN Gateway
A Delay-Tolerant Network (DTN) Architecture (Request for Comment, RFC-4838) and Bundle Protocol Specification, RFC-5050, have been proposed for space and terrestrial networks. Additional security specifications have been provided via the Bundle Security Specification (currently a work in progress as an Internet Research Task Force internet-draft) and, for link-layer protocols applicable to Space networks, the Licklider Transport Protocol Security Extensions. This document provides a security analysis of the current DTN RFCs and proposed security related internet drafts with a focus on space-based communication networks, which is a rather restricted subset of DTN networks. Note, the original focus and motivation of DTN work was for the Interplanetary Internet . This document does not address general store-and-forward network overlays, just the current work being done by the Internet Research Task Force (IRTF) and the Consultative Committee for Space Data Systems (CCSDS) Space Internetworking Services Area (SIS) - DTN working group under the DTN and Bundle umbrellas. However, much of the analysis is relevant to general store-and-forward overlays.
A load-balancing technique is proposed, executed, and tested against a Delay Tolerant Network (DTN) implementation with well-known characteristics. This would prove that transparently inserting software defined networking (SDN) to achieve load balancing without re-configuring the DTN portion is possible. Two routes were taken to alleviate a DTN bottleneck threat. The first used a P4 networking switch. This manual load-balancing test will balance the incoming packets without the users at the end-points knowing that its original packet destination and/or source may have been changed. The second route utilized a High-rate Delay Tolerant Networking (HDTN) receiving node instead of the typical the delay tolerance networking (DTN) implementation used. Bench-marking results of the DTN implementation receiving node and the HDTN receiving node will be compared.
It is possible to use a Delay Tolerant Network (DTN) to transport data and/or commanding from one end-point to another end-point where DTN is not used. This implies that at least one or the other end-point is sending and receiving as a non-DTN node. It also implies that at least one intermediate node prior to the non-DTN node has a Convergence Layer Adapter (CLA) or application which supports appropriate protocols. This is the basic concept of Rationale, Scenarios, and Requirements for DTN in Space, section 4.2.2.6.3: An application on the last hop relay node may extract TeleCommands(TCs) from an immediate or delayed TC file and radiate them as TCs to their destination (typically orbiter to lander); Rationale: Such an application could be used to support low-level commanding in case the destination spacecraft’s network layer is not functioning properly.
This slide presentation reviews some of the technical issues in implementing Delay Tolerant Networking (DTN) in a enviornments that lack continuous network connectivity, such as spacecraft in deepspace or submarines. In a DTN, asynchronous variable-length messages (called bundles) are routed in a store and forward manner between participating nodes over a heterogeneous network. The review examines the enabling technologies, the porting steps and issues, operational scenarios for DTN. There is a review of the Licklider Transmission Protocol (LTP) aka Long-haul Transmission Protocol. Also included is a brief review of the current uses of DTN.
This paper delves into network emulation tools essential for evaluating and designing Delay Tolerant Networking (DTN) protocols in space and satellite networking. It surveys and assesses the capability of current testbeds to create realistic test environments crucial for developing and evaluating DTN protocols. Specifically, this study provides a comprehensive overview of key DTN protocol stacks and related network emulation platforms and a detailed exploration of NASA’s research facilities. Finally, the paper underscores the fundamental emulation capabilities and the importance of a standardized framework for scenario creation, highlighting its vital role in evaluating and advancing future emulation platforms for space DTN.
This report covers the initial DARPA DTN Phase 3 activities as JPL provided Core Engineering Support to the DARPA DTN Program, and then further details the culmination of the Phase 3 Program with a systematic development, integration and test of a disruption-tolerant C2 Situation Awareness (SA) system that may be transitioned to the USMC and deployed in the near future. The system developed and tested was a SPAWAR/JPL-Developed Common Operating Picture Fusion Tool called the Software Interoperability Environment (SIE), running over Disruption Tolerant Networking (DTN) protocols provided by BBN and MITRE, which effectively extends the operational range of SIE from normal fully-connected internet environments to the mobile tactical edges of the battlefield network.
The Interplanetary Overlay Network (ION) software suite is an open-source, flight-ready implementation of networking protocols including the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol (BP), the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP), and many others including the Contact Graph Routing (CGR) DTN routing system. While DTN offers the capability to tolerate disruption and long signal propagation delays in transmission, without an appropriate routing protocol, no data can be delivered. CGR was built for space exploration networks with scheduled communication opportunities (typically based on trajectories and orbits), represented as a contact graph. Since CGR uses knowledge of future connectivity, the contact graph can grow rather large, and so efficient processing is desired. These enhancements allow CGR to scale to predicted NASA space network complexities and beyond. This software improves upon CGR by adopting an earliest-arrival-time cost metric and using the Dijkstra path selection algorithm. Moving to Dijkstra path selection also enables construction of an earliest- arrival-time tree for multicast routing. The enhancements have been rolled into ION 3.0 available on sourceforge.net.
As is well known, K-band or higher band communications in space link segment often experience intermittent disruptions caused by heavy rainfall. In view of keeping data integrity and establishing autonomous operations under such situation, it is important to consider introducing a tolerance mechanism such as Delay/Disruption Tolerant Networking (DTN). The Consultative Committee for Space Data Systems (CCSDS) is studying DTN as part of the standardization activities for space data systems. As a contribution to CCSDS and a feasibility study for future utilization of DTN, Japan Aerospace Exploration Agency (JAXA) and National Aeronautics and Space Administration (NASA) conducted an interoperability demonstration for confirming its tolerance mechanism and capability of automatic operation using Data Relay Test Satellite (DRTS) space link and its ground terminals. Both parties used the Interplanetary Overlay Network (ION) open source software, including the Bundle Protocol, the Licklider Transmission Protocol, and Contact Graph Routing. This paper introduces the contents of the interoperability demonstration and its results.
The international space community has begun to recognize that the established model for management of communications with spacecraft - commanded data transmission over individual pair-wise contacts - is operationally unwieldy and will not scale in support of increasingly complex and sophisticated missions such as NASA's Constellation project. Accordingly, the international Inter-Agency Operations Advisory Group (IOAG) ichartered a Space Internetworking Strategy Group (SISG), which released its initial recommendations in a November 2008 report. The report includes a recommendation that the space flight community adopt Delay-Tolerant Networking (DTN) to address the problem of interoperability and communication scaling, especially in mission environments where there are multiple spacecraft operating in concert. This paper explores some of the issues that must be addressed in implementing, deploying, and operating DTN as part of a multi-mission, multi-agency space internetwork as well as benefits and future operational scenarios afforded by DTN-based space internetworking.
As DTN has progressed since its inception in 2002, the community stabilized around Bundle Protocol version 6 (BPv6). This protocol was standardized by the RFC 5050’s definition of BPv6 and was later standardized and refined for space operations by the CCSDS Bundle Protocol Specification. After the release of RFC 5050, a variety of implementations and missions used BPv6 and noted several improvements that could be made to the protocol. These improvements culminated in a push to release a new protocol version, BPv7. Unfortunately, the vast improvements and difference in encoding that separates BPv7 from BPv6 also makes the two versions inherently incompatible. Consequently, there is an issue implementing BPv7 in existing systems while continuing support for BPv6 implementations. In response to this issue, two solutions emerge: (1) Bundle-in-Bundle Encapsulation (BIBE), a capability that wraps a bundle in another bundle for shipping between intermediary nodes, and (2) version agnostic DTN implementations. These concepts have been proven out in the MSFC DTN implementation known as DTNME.
Networks are expanding and becoming more complex. Therefore, they are also increasing bundle packet throughput within the system. IF DTN nodes are constricted in packet throughput, how would the system act? Would it just drop the packet without a flag? What happens IF all DTN node’s send at their limits to the ISS DTN node?
A detailed viewgraph presentation on DTN, AMS, and Sharednet content-based networking is shown. The contents include: 1) DARPA Content-Based Networking Summary of Requirements; 2) Concept; 3) Key Features of AMS; 4) Overview of Sharednet; 5) SharedNet Deployment History; 6) SharedNet AMS DTN; 7) Detailed Structure; and 8) Bottom line.
The NASA Space Network provides a demand access return link service capable of providing users a space link "on demand". An equivalent service in the forward link direction is not possible due to Tracking and Data Relay Spacecraft (TDRS) constraints. A Disruption Tolerant Networking (DTN)-based Multiple Access Fast Forward (MAFF) service has been proposed to provide a forward link to a user as soon as possible. Previous concept studies have identified a basic architecture and implementation approach. This paper reviews the user scenarios and benefits of an MAFF service and proposes an implementation approach based on the use of DTN protocols.