SEARCH · Search NASA

Results for “link layer protocols”

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 73 records · Page 4

All sources NASA NTRS DOE OSTI

NASA NTRS1997

Study and Simulation of Enhancements for TCP (Transmission Control Protocol) Performance Over Noisy, High-Latency Links

The designers of the TCP/IP protocol suite explicitly included support of satellites in their design goals. The goal of the Internet Project was to design a protocol which could be layered over different networking technologies to allow them to be concatenated into an internet. The results of this project included two protocols, IP and TCP. IP is the protocol used by all elements in the network and it defines the standard packet format for IP datagrams. TCP is the end-to-end transport protocol commonly used between end systems on the Internet to derive a reliable bi-directional byte-pipe service from the underlying unreliable IP datagram service. Satellite links are explicitly mentioned in Vint Cerf's 2-page article which appeared in 1980 in CCR [2] to introduce the specifications for IP and TCP. In the past fifteen years, TCP has been demonstrated to work over many differing networking technologies, including over paths including satellites links. So if satellite links were in the minds of the designers from the beginning, what is the problem? The problem is that the performance of TCP has in some cases been disappointing. A goal of the authors of the original specification of TCP was to specify only enough behavior to ensure interoperability. The specification left a number of important decisions, in particular how much data is to be sent when, to the implementor. This was deliberately' done. By leaving performance-related decisions to the implementor, this would allow the protocol TCP to be tuned and adapted to different networks and situations in the future without the need to revise the specification of the protocol, or break interoperability. Interoperability would continue while future implementations would be allowed flexibility to adapt to needs which could not be anticipated at the time of the original protocol design.

Shepard, Timothy J.↗

NASA NTRS2009

Use of the Delay-Tolerant Networking Bundle Protocol from Space

The Disaster Monitoring Constellation (DMC), constructed by Survey Satellite Technology Ltd (SSTL), is a multisatellite Earth-imaging low-Earth-orbit sensor network where captured image swaths are stored onboard each satellite and later downloaded from the satellite payloads to a ground station. Store-and-forward of images with capture and later download gives each satellite the characteristics of a node in a Delay/Disruption Tolerant Network (DTN). Originally developed for the Interplanetary Internet, DTNs are now under investigation in an Internet Research Task Force (IRTF) DTN research group (RG), which has developed a bundle architecture and protocol. The DMC is currently unique in its adoption of the Internet Protocol (IP) for its imaging payloads and for satellite command and control, based around reuse of commercial networking and link protocols. These satellites use of IP has enabled earlier experiments with the Cisco router in Low Earth Orbit (CLEO) onboard the constellation's UK-DMC satellite. Earth images are downloaded from the satellites using a custom IPbased high-speed transfer protocol developed by SSTL, Saratoga, which tolerates unusual link environments. Saratoga has been documented in the Internet Engineering Task Force (IETF) for wider adoption. We experiment with use of DTNRG bundle concepts onboard the UKDMC satellite, by examining how Saratoga can be used as a DTN convergence layer to carry the DTNRG Bundle Protocol, so that sensor images can be delivered to ground stations and beyond as bundles. This is the first successful use of the DTNRG Bundle Protocol in a space environment. We use our practical experience to examine the strengths and weaknesses of the Bundle Protocol for DTN use, paying attention to fragmentation, custody transfer, and reliability issues.

Wood, Lloyd↗

NASA NTRS2010

Experience with Delay-Tolerant Networking from Orbit

We describe the first use from space of the Bundle Protocol for Delay-Tolerant Networking (DTN) and lessons learned from experiments made and experience gained with this protocol. The Disaster Monitoring Constellation (DMC), constructed by Surrey Satellite Technology Ltd (SSTL), is a multiple-satellite Earth-imaging low-Earth-orbit sensor network in which recorded image swaths are stored onboard each satellite and later downloaded from the satellite payloads to a ground station. Store-and-forward of images with capture and later download gives each satellite the characteristics of a node in a disruption-tolerant network. Originally developed for the Interplanetary Internet, DTNs are now under investigation in an Internet Research Task Force (IRTF) DTN research group (RG), which has developed a bundle architecture and protocol. The DMC is technically advanced in its adoption of the Internet Protocol (IP) for its imaging payloads and for satellite command and control, based around reuse of commercial networking and link protocols. These satellites use of IP has enabled earlier experiments with the Cisco router in Low Earth Orbit (CLEO) onboard the constellation s UK-DMC satellite. Earth images are downloaded from the satellites using a custom IP-based high-speed transfer protocol developed by SSTL, Saratoga, which tolerates unusual link environments. Saratoga has been documented in the Internet Engineering Task Force (IETF) for wider adoption. We experiment with the use of DTNRG bundle concepts onboard the UK-DMC satellite, by examining how Saratoga can be used as a DTN convergence layer to carry the DTNRG Bundle Protocol, so that sensor images can be delivered to ground stations and beyond as bundles. Our practical experience with the first successful use of the DTNRG Bundle Protocol in a space environment gives us insights into the design of the Bundle Protocol and enables us to identify issues that must be addressed before wider deployment of the Bundle Protocol. Published in 2010 by John Wiley & Sons, Ltd. KEY WORDS: Internet; UK-DMC; satellite; Delay-Tolerant Networking (DTN); Bundle Protocol

Ivancic, W.↗

NASA NTRS1986

Network design consideration of a satellite-based mobile communications system

Technical considerations for the Mobile Satellite Experiment (MSAT-X), the ground segment testbed for the low-cost spectral efficient satellite-based mobile communications technologies being developed for the 1990's, are discussed. The Network Management Center contains a flexible resource sharing algorithm, the Demand Assigned Multiple Access scheme, which partitions the satellite transponder bandwidth among voice, data, and request channels. Satellite use of multiple UHF beams permits frequency reuse. The backhaul communications and the Telemetry, Tracking and Control traffic are provided through a single full-coverage SHF beam. Mobile Terminals communicate with the satellite using UHF. All communications including SHF-SHF between Base Stations and/or Gateways, are routed through the satellite. Because MSAT-X is an experimental network, higher level network protocols (which are service-specific) will be developed only to test the operation of the lowest three levels, the physical, data link, and network layers.

Yan, T.-Y.↗

NASA NTRS2011

CCSDS Advanced Orbiting Systems Virtual Channel Access Service for QoS MACHETE Model

To support various communications requirements imposed by different missions, interplanetary communication protocols need to be designed, validated, and evaluated carefully. Multimission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE), described in "Simulator of Space Communication Networks" (NPO-41373), NASA Tech Briefs, Vol. 29, No. 8 (August 2005), p. 44, combines various tools for simulation and performance analysis of space networks. The MACHETE environment supports orbital analysis, link budget analysis, communications network simulations, and hardware-in-the-loop testing. By building abstract behavioral models of network protocols, one can validate performance after identifying the appropriate metrics of interest. The innovators have extended the MACHETE model library to include a generic link-layer Virtual Channel (VC) model supporting quality-of-service (QoS) controls based on IP streams. The main purpose of this generic Virtual Channel model addition was to interface fine-grain flow-based QoS (quality of service) between the network and MAC layers of the QualNet simulator, a commercial component of MACHETE. This software model adds the capability of mapping IP streams, based on header fields, to virtual channel numbers, allowing extended QoS handling at link layer. This feature further refines the QoS v existing at the network layer. QoS at the network layer (e.g. diffserv) supports few QoS classes, so data from one class will be aggregated together; differentiating between flows internal to a class/priority is not supported. By adding QoS classification capability between network and MAC layers through VC, one maps multiple VCs onto the same physical link. Users then specify different VC weights, and different queuing and scheduling policies at the link layer. This VC model supports system performance analysis of various virtual channel link-layer QoS queuing schemes independent of the network-layer QoS systems.

Jennings, Esther H.↗

NASA NTRS2021

Applying the Cognitive Space Gateway to Swarm Topologies

NASA's future vision for interplanetary networking includes a lunar network, Cube Satellite (CubeSat) constellations, and deep space robotic missions, comprising what could be viewed as a network of networks. Delay-tolerant networking (DTN) architecture and protocols provide a standard network layer among these varying scenarios and mitigate many challenges of the space environment, such as long delays, unplanned service interruptions, and asymmetric links. The Cognitive Space Gateway (CSG) is a routing method in a DTN architecture that uses spiking neural networks as the learning element to optimize routing decisions in a complex environment. This work aims to further develop cognitive networking technologies in several critical areas, including DTN, the CSG algorithm, CubeSat swarm topologies, and cloud services. To test the algorithm in a realistic scenario, the emulated network topology is based on a CubeSat swarm. The swarm may function as a mesh of nodes or as a hub-and-spoke network. An emulation environment will be built upon a commercial cloud service, such as Amazon Web Services (AWS) Elastic Compute Cloud. The cloud environment may enable a flexible, lower maintenance approach versus a multi-hop network based in a physical laboratory. The cloud platform will provide a secure environment allowing for collaboration among government and academic entities.

Ricardo Lent↗

NASA NTRSDate not supplied

Applying the Cognitive Space Gateway to Swarm Topologies

NASA’s future vision for interplanetary networking includes a lunar network, Cube Satellite (CubeSat) constellations, and deep space robotic missions, comprising what could be viewed as a network of networks. Delay-tolerant networking (DTN) architecture and protocols provide a standard network layer among these varying scenarios and mitigate many challenges of the space environment, such as long delays, unplanned service interruptions, and asymmetric links. The Cognitive Space Gateway (CSG) is a routing method in a DTN architecture that uses spiking neural networks as the learning element to optimize outing decisions in a complex environment. This work aims to further develop cognitive networking technologies in several critical areas, including DTN, the CSG algorithm, SmallSat swarm topologies, and cloud services. The CSG algorithm is tested in a realistic scenario in which the emulated network topology is based on a SmallSat swarm. The emulation environment will be built upon a commercial cloud service, such as Amazon Web Services (AWS) Elastic Compute Cloud. This work investigates the ability of such a platform to enable a flexible, lower maintenance approach to creating a multihop network outside of a physical laboratory. The cloud platform will provide a secure environment allowing for collaboration among government and academic entities.

Ricardo Lent↗

NASA NTRS2015

A Modeling Pattern for Layered System Interfaces

Communications between systems is often initially represented at a single, high level of abstraction, a link between components. During design evolution it is usually necessary to elaborate the interface model, defining it from several different, related viewpoints and levels of abstraction. This paper presents a pattern to model such multi-layered interface architectures simply and efficiently, in a way that supports expression of technical complexity, interfaces and behavior, and analysis of complexity. Each viewpoint and layer of abstraction has its own properties and behaviors. System elements are logically connected both horizontally along the communication path, and vertically across the different layers of protocols. The performance of upper layers depends on the performance of lower layers, yet the implementation of lower layers is intentionally opaque to upper layers. Upper layers are hidden from lower layers except as sources and sinks of data. The system elements may not be linked directly at each horizontal layer but only via a communication path, and end-to-end communications may depend on intermediate components that are hidden from them, but may need to be shown in certain views and analyzed for certain purposes. This architectural model pattern uses methods described in ISO 42010, Recommended Practice for Architectural Description of Software-intensive Systems and CCSDS 311.0-M-1, Reference Architecture for Space Data Systems (RASDS). A set of useful viewpoints and views are presented, along with the associated modeling representations, stakeholders and concerns. These viewpoints, views, and concerns then inform the modeling pattern. This pattern permits viewing the system from several different perspectives and at different layers of abstraction. An external viewpoint treats the systems of interest as black boxes and focuses on the applications view, another view exposes the details of the connections and other components between the black boxes. An internal view focuses on the implementation within the systems of interest, either showing external interface bindings and specific standards that define the communication stack profile or at the level of internal behavior. Orthogonally, a horizontal view isolates a single layer and a vertical viewpoint shows all layers at a single interface point between the systems of interest. Each of these views can in turn be described from both behavioral and structural viewpoints.

Shames, Peter M.↗

NASA NTRS1998

Asynchronous Transfer Mode Quality-of-Service Testing

In support of satellite-ATM interoperability, researchers at the NASA Lewis Research Center performed asynchronous transfer mode (ATM) quality-of-service experiments using MPEG-2 (ATM application layer 5, AAL5) over ATM over an emulated satellite link. The purpose of these experiments was to determine the free-space link quality necessary to use the ATM protocol to transmit high-quality multimedia information. The experimental results have been submitted to various International Telecommunications Union (ITU) study groups in order to improve and modify current standards and recommendations for the telecommunications industry. Quality-of-service parameters for Class I, stringent class requirements for ITU-T I.356 are currently being debated. The experimental results presented will help to establish these quality-of-service thresholds. This material will also be useful in the development of the ITU-R WP-4B's Draft Preliminary New Recommendation on the Transmission of Asynchronous Transfer Mode Traffic via Satellite (Rec. S.atm).

Ivancic, William D.↗

NASA NTRS2012

Integrated RF/Optical Interplanetary Networking Preliminary Explorations and Empirical Results

Over the last decade interplanetary telecommunication capabilities have been significantly expanded--specifically in support of the Mars exploration rover and lander missions. NASA is continuing to drive advances in new, high payoff optical communications technologies to enhance the network to Gbps performance from Mars, and the transition from technology demonstration to operational system is examined through a hybrid RF/optical approach. Such a system combines the best features of RF and optical communications considering availability and performance to realize a dual band trunk line operating within characteristic constraints. Disconnection due to planetary obscuration and solar conjunction, link delays, timing, ground terminal mission congestion and scheduling policy along with space and atmospheric weather disruptions all imply the need for network protocol solutions to ultimately manage the physical layer in a transparent manner to the end user. Delay Tolerant Networking (DTN) is an approach under evaluation which addresses these challenges. A multi-hop multi-path hybrid RF and optical test bed has been constructed to emulate the integrated deep space network and to support protocol and hardware refinement. Initial experimental results characterize several of these challenges and evaluate the effectiveness of DTN as a solution to mitigate them.

Raible, Daniel E.↗

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 NTRS2006

Transferring Files Between the Deep Impact Spacecrafts and the Ground Data System Using the CCSDS File Delivery Protocol (CFDP): A Case Study

The CCSDS File Delivery Protocol (CFDP) Standard could reshape ground support architectures by enabling applications to communicate over the space link using reliable-symmetric transport services. JPL utilized the CFDP standard to support the Deep Impact Mission. The architecture was based on layering the CFDP applications on top of the CCSDS Space Link Extension Services for data transport from the mission control centers to the ground stations. On July 4, 2005 at 1:52 A.M. EDT, the Deep Impact impactor successfully collided with comet Tempel 1. During the final 48 hours prior to impact, over 300 files were uplinked to the spacecraft, while over 6 thousand files were downlinked from the spacecraft using the CFDP. This paper uses the Deep Impact Mission as a case study in a discussion of the CFDP architecture, Deep Impact Mission requirements, and design for integrating the CFDP into the JPL deep space support services. Issues and recommendations for future missions using CFDP are also provided.

CCSDS File Delivery Protocol (CFDP)↗

NASA NTRS1998

MPEG-2 Over Asynchronous Transfer Mode (ATM) Over Satellite Quality of Service (QoS) Experiments: Laboratory Tests

Asynchronous transfer mode (ATM) quality of service (QoS) experiments were performed using MPEG-2 (ATM application layer 5, AAL5) over ATM over an emulated satellite link. The purpose of these experiments was to determine the free-space link quality necessary to transmit high-quality multimedia information by using the ATM protocol. The detailed test plan and test configuration are described herein as are the test results. MPEG-2 transport streams were baselined in an errored environment, followed by a series of tests using, MPEG-2 over ATM. Errors were created both digitally as well as in an IF link by using a satellite modem and commercial gaussian noise test set for two different MPEG-2 decoder implementations. The results show that ITU-T Recommendation 1.356 Class 1, stringent ATM applications will require better link quality than currently specified; in particular, cell loss ratios of better than 1.0 x 10(exp -8) and cell error ratios of better than 1.0 x 10(exp -7) are needed. These tests were conducted at the NASA Lewis Research Center in support of satellite-ATM interoperability research.

Ivancic, William D.↗

NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗

NASA NTRS2008

Spacewire Cable and Connector Variations

SpaceWire spaceflight applications are growing steadily and the data protocol is well documented and standardized. Yet, unique requirements for various programs often make it necessary to deviate from the standard. The introduction of new technologies into the SpaceWire community can only serve to support increased technology growth. The physical layer is often overlooked as a critical component of the SpaceWire link but experience will show that in certain situations a good physical layer design may be crucial to the success of the program. The SpaceWire cable assembly, consisting of the SpaceWire connector and cable, is one of the components that may offer design variations.

Allen, Shaune S.↗

NASA NTRS1993

A packet switched communications system for GRO

This paper describes the packet switched Instrumenters Communication System (ICS) that was developed for the Command Management Facility at GSFC to support the Gamma Ray Observatory (GRO) spacecraft. The GRO ICS serves as a vital science data acquisition link to the GRO scientists to initiate commands for their spacecraft instruments. The system is ready to send and receive messages at any time, 24 hours a day and seven days a week. The system is based on X.25 and the International Standard Organization's (ISO) 7-layer Open Systems Interconnection (OSI) protocol model and has client and server components. The components of the GRO ICS are discussed along with how the Communications Subsystem for Interconnection (CSFI) and Network Control Program Packet Switching Interface (NPSI) software are used in the system.

Husain, Shabu↗

NASA NTRS2023

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking↗