SEARCH · Engineering Papers

Results for “delay-tolerant network”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

NASA NTRS2011

Remote Asynchronous Message Service Gateway

The Remote Asynchronous Message Service (RAMS) gateway is a special-purpose AMS application node that enables exchange of AMS messages between nodes residing in different AMS "continua," notionally in different geographical locations. JPL s implementation of RAMS gateway functionality is integrated with the ION (Interplanetary Overlay Network) implementation of the DTN (Delay-Tolerant Networking) bundle protocol, and with JPL s implementation of AMS itself. RAMS protocol data units are encapsulated in ION bundles and are forwarded to the neighboring RAMS gateways identified in the source gateway s AMS management information base. Each RAMS gateway has interfaces in two communication environments: the AMS message space it serves, and the RAMS network - the grid or tree of mutually aware RAMS gateways - that enables AMS messages produced in one message space to be forwarded to other message spaces of the same venture. Each gateway opens persistent, private RAMS network communication channels to the RAMS gateways of other message spaces for the same venture, in other continua. The interconnected RAMS gateways use these communication channels to forward message petition assertions and cancellations among themselves. Each RAMS gateway subscribes locally to all subjects that are of interest in any of the linked message spaces. On receiving its copy of a message on any of these subjects, the RAMS gateway node uses the RAMS network to forward the message to every other RAMS gateway whose message space contains at least one node that has subscribed to messages on that subject. On receiving a message via the RAMS network from some other RAMS gateway, the RAMS gateway node forwards the message to all subscribers in its own message space.

Wang, Shin-Ywan↗

NASA NTRS2011

Toward a Communications Satellite Network for Humanitarian Relief

Since the introduction in 2008 of the "Ring Road" concept, proposing a communications satellite network designed to support disadvantaged populations, there have been a number of advances in the underlying technologies, CubeSat picosatellites and Delay-Tolerant Networking. We review the original Ring Road proposal, discuss relevant recent technological progress, and offer some tentative notes on projected cost and performance.

CubeSat↗

NASA NTRS2011

Interplanetary Overlay Network Bundle Protocol Implementation

The Interplanetary Overlay Network (ION) system's BP package, an implementation of the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) and supporting services, has been specifically designed to be suitable for use on deep-space robotic vehicles. Although the ION BP implementation is unique in its use of zero-copy objects for high performance, and in its use of resource-sensitive rate control, it is fully interoperable with other implementations of the BP specification (Internet RFC 5050). The ION BP implementation is built using the same software infrastructure that underlies the implementation of the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) built into the flight software of Deep Impact. It is designed to minimize resource consumption, while maximizing operational robustness. For example, no dynamic allocation of system memory is required. Like all the other ION packages, ION's BP implementation is designed to port readily between Linux and Solaris (for easy development and for ground system operations) and VxWorks (for flight systems operations). The exact same source code is exercised in both environments. Initially included in the ION BP implementations are the following: libraries of functions used in constructing bundle forwarders and convergence-layer (CL) input and output adapters; a simple prototype bundle forwarder and associated CL adapters designed to run over an IPbased local area network; administrative tools for managing a simple DTN infrastructure built from these components; a background daemon process that silently destroys bundles whose time-to-live intervals have expired; a library of functions exposed to applications, enabling them to issue and receive data encapsulated in DTN bundles; and some simple applications that can be used for system checkout and benchmarking.

Burleigh, Scott C.↗

NASA NTRS2004

Protocol for a Delay-Tolerant Data-Communication Network

As its name partly indicates, the Delay-Tolerant Networking (DTN) Bundle Protocol is a protocol for delay-tolerant transmission of data via communication networks. This protocol was conceived as a result of studies of how to adapt Internet protocols so that Internet-like services could be provided across interplanetary distances in support of deep-space exploration. The protocol, and software to implement the protocol, is being developed in collaboration among experts at NASA's Jet Propulsion Laboratory and other institutions. No current Internet protocols can accommodate long transmission delay times or intermittent link connectivity. The DTN Bundle Protocol represents a departure from the standard Internet assumption that a continuous path is available from a host computer to a client computer: It provides for routing of data through networks that may be disjointed and may be characterized by long transmission delays. In addition to networks that include deepspace communication links, examples of such networks include terrestrial ones within which branches are temporarily disconnected. The protocol is based partly on the definition of a message-based overlay above the transport layers of the networks on which it is hosted.

Torgerson, Jordan↗

NASA NTRS2011

A Study of an Optical Lunar Surface Communications Network with High Bandwidth Direct to Earth Link

Analyzed optical DTE (direct to earth) and lunar relay satellite link analyses, greater than 200 Mbps downlink to 1‐m Earth receiver and greater than 1 Mbps uplink achieved with mobile 5‐cm lunar transceiver, greater than 1Gbps downlink and greater than 10 Mpbs uplink achieved with 10‐cm stationary lunar transceiver, MITLL (MIT Lincoln Laboratory) 2013 LLCD (Lunar Laser Communications Demonstration) plans to demonstrate 622 Mbps downlink with 20 Mbps uplink between lunar orbiter and ground station; Identified top five technology challenges to deploying lunar optical network, Performed preliminary experiments on two of challenges: (i) lunar dust removal and (ii)DTN over optical carrier, Exploring opportunities to evaluate DTN (delay-tolerant networking) over optical link in a multi‐node network e.g. Desert RATS.

lunar surface system↗

NASA NTRS2008

The Interplanetary Overlay Networking Protocol Accelerator

A document describes the Interplanetary Overlay Networking Protocol Accelerator (IONAC) an electronic apparatus, now under development, for relaying data at high rates in spacecraft and interplanetary radio-communication systems utilizing a delay-tolerant networking protocol. The protocol includes provisions for transmission and reception of data in bundles (essentially, messages), transfer of custody of a bundle to a recipient relay station at each step of a relay, and return receipts. Because of limitations on energy resources available for such relays, data rates attainable in a conventional software implementation of the protocol are lower than those needed, at any given reasonable energy-consumption rate. Therefore, a main goal in developing the IONAC is to reduce the energy consumption by an order of magnitude and the data-throughput capability by two orders of magnitude. The IONAC prototype is a field-programmable gate array that serves as a reconfigurable hybrid (hardware/ firmware) system for implementation of the protocol. The prototype can decode 108,000 bundles per second and encode 100,000 bundles per second. It includes a bundle-cache static randomaccess memory that enables maintenance of a throughput of 2.7Gb/s, and an Ethernet convergence layer that supports a duplex throughput of 1Gb/s.

Pang, Jackson↗

NASA NTRS2006

In-Space Crew-Collaborative Task Scheduling

As humans venture farther from earth for longer durations, it will become essential for those on the journey to have significant control over the scheduling of their own activities as well as the activities of their companion systems and robots. However, there are many reasons why the crew will not do all the scheduling; timelines will be the result of collaboration with ground personnel. Emerging technologies such as in-space message buses, delay-tolerant networks, and in-space internet will be the carriers on which the collaboration rides. Advances in scheduling technology, in the areas of task modeling, scheduling engines, and user interfaces will allow the crew to become virtual scheduling experts. New concepts of operations for producing the timeline will allow the crew and the ground support to collaborate while providing safeguards to ensure that the mission will be effectively accomplished without endangering the systems or personnel.

Jaap, John↗

NASA NTRS2006

In-Space Crew-Collaborative Task Scheduling

As humans venture farther from Earth for longer durations, it will become essential for those on the journey to have significant control over the scheduling of their own activities as well as the activities of their companion systems and robots. However, the crew will not do all the scheduling; timelines will be the result of collaboration with ground personnel. Emerging technologies such as in-space message buses, delay-tolerant networks, and in-space internet will be the carriers on which the collaboration rides. Advances in scheduling technology, in the areas of task modeling, scheduling engines, and user interfaces will allow the crew to become virtual scheduling experts. New concepts of operations for producing the timeline will allow the crew and the ground support to collaborate while providing safeguards to ensure that the mission will be effectively accomplished without endangering the systems or personnel.

Jaap, John↗

NASA NTRS2006

Remote Collaboration on Task Scheduling for Humans at Mars

Jaap, John↗

NASA NTRS2011

Bundle Security Protocol for ION

This software implements bundle authentication, conforming to the Delay-Tolerant Networking (DTN) Internet Draft on Bundle Security Protocol (BSP), for the Interplanetary Overlay Network (ION) implementation of DTN. This is the only implementation of BSP that is integrated with ION.

Burleigh, Scott C.↗

NASA NTRS2011

Licklider Transmission Protocol Implementation

This software is an implementation of the Licklider Transmission Protocol (LTP), a communications protocol intended to support the Bundle Protocol in Delay-Tolerant Network (DTN) operations. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting long-haul reliable transmission over deep-space RF links. Like any reliable transport service employing ARQ (Automatic Repeat re-Quests), LTP is stateful. In order to assure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block which might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far, and which are not, together with any additional information needed for purposes of retransmitting part, or all, of the block. Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgement from the block s destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgement of the arrival of all prior blocks, valuable opportunities to use what little deep space transmission bandwidth is available would be forever lost. For this reason, LTP is based in part on a notion of massive state retention. Any number of requested transmission conversations (sessions) may be concurrently in flight at various displacements along the link between two LTP engines, and the LTP engines must necessarily retain transmission status and retransmission resources for all of them. Moreover, if any of the data of a given block are lost en route, it will be necessary to retain the state of that transmission during an additional round trip while the lost data are retransmitted; even multiple retransmission cycles may be necessary. LTP's possible multiplicity of sessions per association makes it necessary for each segment of application data to include an additional demultiplexing token: a session ID that uniquely identifies the session in which the segment was issued and, implicitly, the block of data being conveyed by this session. This software comprises a prototype implementation developed by Johns Hopkins University APL in cooperation with JPL, together with adaptations that improve the robustness, correctness, and operability of that implementation.

Burleigh, Scott C.↗

NASA NTRS2011

Defining Tolerance: Impacts of Delay and Disruption when Managing Challenged Networks

Challenged networks exhibit irregularities in their communication performance stemming from node mobility, power constraints, and impacts from the operating environment. These irregularities manifest as high signal propagation delay and frequent link disruption. Understanding those limits of link disruption and propagation delay beyond which core networking features fail is an ongoing area of research. Various wireless networking communities propose tools and techniques that address these phenomena. Emerging standardization activities within the Internet Research Task Force (IRTF) and the Consultative Committee for Space Data Systems (CCSDS) look to build upon both this experience and scalability analysis. Successful research in this area is predicated upon identifying enablers for common communication functions (notably node discovery, duplex communication, state caching, and link negotiation) and how increased disruptions and delays affect their feasibility within the network. Networks that make fewer assumptions relating to these enablers provide more universal service. Specifically, reliance on node discovery and link negotiation results in network-specific operational concepts rather than scalable technical solutions. Fundamental to this debate are the definitions, assumptions, operational concepts, and anticipated scaling of these networks. This paper presents the commonalities and differences between delay and disruption tolerance, including support protocols and critical enablers. We present where and how these tolerances differ. We propose a set of use cases that must be accommodated by any standardized delay-tolerant network and discuss the implication of these on existing tool development.

mobility drivers↗

NASA NTRS2011

Toward a Communications Satellite Network for Humanitarian Relief

No abstract available

communications satellite network↗

NASA NTRS2010

Moving Toward Space Internetworking via DTN: Its Operational Challenges, Benefits, and Management

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.

Delay Tolerant Networking↗

NASA NTRS2011

Deep Space Networking Experiments on the EPOXI Spacecraft

NASA's Space Communications & Navigation Program within the Space Operations Directorate is operating a program to develop and deploy Disruption Tolerant Networking [DTN] technology for a wide variety of mission types by the end of 2011. DTN is an enabling element of the Interplanetary Internet where terrestrial networking protocols are generally unsuitable because they rely on timely and continuous end-to-end delivery of data and acknowledgments. In fall of 2008 and 2009 and 2011 the Jet Propulsion Laboratory installed and tested essential elements of DTN technology on the Deep Impact spacecraft. These experiments, called Deep Impact Network Experiment (DINET 1) were performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. The DINET 1 software was installed on the backup software partition on the backup flight computer for DINET 1. For DINET 1, the spacecraft was at a distance of about 15 million miles (24 million kilometers) from Earth. During DINET 1 300 images were transmitted from the JPL nodes to the spacecraft. Then, they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. The first DINET 1 experiment successfully validated many of the essential elements of the DTN protocols. DINET 2 demonstrated: 1) additional DTN functionality, 2) automated certain tasks which were manually implemented in DINET 1 and 3) installed the ION SW on nodes outside of JPL. DINET 3 plans to: 1) upgrade the LTP convergence-layer adapter to conform to the international LTP CL specification, 2) add convergence-layer "stewardship" procedures and 3) add the BSP security elements [PIB & PCB]. This paper describes the planning and execution of the flight experiment and the validation results.

automated data communication↗

NASA NTRS2006

Deep Space Internet

Explore the source record for details and available documents.

delay-tolerant network (DTN)↗

NASA NTRS2004

NASA Tech Briefs, January 2004

Topics covered include: Multisensor Instrument for Real-Time Biological Monitoring; Sensor for Monitoring Nanodevice-Fabrication Plasmas; Backed Bending Actuator; Compact Optoelectronic Compass; Micro Sun Sensor for Spacecraft; Passive IFF: Autonomous Nonintrusive Rapid Identification of Friendly Assets; Finned-Ladder Slow-Wave Circuit for a TWT; Directional Radio-Frequency Identification Tag Reader; Integrated Solar-Energy-Harvesting and -Storage Device; Event-Driven Random-Access-Windowing CCD Imaging System; Stroboscope Controller for Imaging Helicopter Rotors; Software for Checking State-charts; Program Predicts Broadband Noise from a Turbofan Engine; Protocol for a Delay-Tolerant Data-Communication Network; Software Implements a Space-Mission File-Transfer Protocol; Making Carbon-Nanotube Arrays Using Block Copolymers: Part 2; Modular Rake of Pitot Probes; Preloading To Accelerate Slow-Crack-Growth Testing; Miniature Blimps for Surveillance and Collection of Samples; Hybrid Automotive Engine Using Ethanol-Burning Miller Cycle; Fabricating Blazed Diffraction Gratings by X-Ray Lithography; Freeze-Tolerant Condensers; The StarLight Space Interferometer; Champagne Heat Pump; Controllable Sonar Lenses and Prisms Based on ERFs; Measuring Gravitation Using Polarization Spectroscopy; Serial-Turbo-Trellis-Coded Modulation with Rate-1 Inner Code; Enhanced Software for Scheduling Space-Shuttle Processing; Bayesian-Augmented Identification of Stars in a Narrow View; Spacecraft Orbits for Earth/Mars-Lander Radio Relay; and Self-Inflatable/Self-Rigidizable Reflectarray Antenna.

Source record↗

NASA NTRS2011

The Impact of Traffic Prioritization on Deep Space Network Mission Traffic

A select number of missions supported by NASA's Deep Space Network (DSN) are demanding very high data rates. For example, the Kepler Mission was launched March 7, 2009 and at that time required the highest data rate of any NASA mission, with maximum rates of 4.33 Mb/s being provided via Ka band downlinks. The James Webb Space Telescope will require a maximum 28 Mb/s science downlink data rate also using Ka band links; as of this writing the launch is scheduled for a June 2014 launch. The Lunar Reconnaissance Orbiter, launched June 18, 2009, has demonstrated data rates at 100 Mb/s at lunar-Earth distances using NASA's Near Earth Network (NEN) and K-band. As further advances are made in high data rate space telecommunications, particularly with emerging optical systems, it is expected that large surges in demand on the supporting ground systems will ensue. A performance analysis of the impact of high variance in demand has been conducted using our Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) simulation tool. A comparison is made regarding the incorporation of Quality of Service (QoS) mechanisms and the resulting ground-to-ground Wide Area Network (WAN) bandwidth necessary to meet latency requirements across different user missions. It is shown that substantial reduction in WAN bandwidth may be realized through QoS techniques when low data rate users with low-latency needs are mixed with high data rate users having delay-tolerant traffic.

prioritization↗