Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “network 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.

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

At least 415 records · Page 23
All sourcesNASA NTRSDOE OSTI
NASA NTRS1999

Reconfigurable Data Communications Packet-Switch Emulation Test Bed Demonstrated

The Communications Technology Division at the NASA Lewis Research Center has an ongoing program to develop advanced switching and routing technology concepts for future satellite onboard processing systems. Through a university grant as a part of this research, the Cleveland State University is using a flexible reconfigurable data communications packet switch emulation test bed to investigate packet switching techniques. Because of the switching speed and protocol complexity, implementing a data communications network is a tremendous task. Various alternatives should be carefully studied and evaluated in the development stage so that the optimal system configuration can be obtained and implemented later. Therefore, it is desirable to predict the performance of the network before it is actually constructed. This is especially true in the case of satellite systems. In the past, theoretical analysis, software simulation, and prototyping were used to evaluate performance. However, each method has its drawback. There are basic tradeoffs among accuracy, cost, and required evaluation time. No method is completely satisfactory.

Chu, Pong P.↗
NASA NTRS2007

Technical Issues in Implementing DTN in a Flight Software Architecture

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.

Licklider Transmission Protocol (LTP)↗
NASA NTRS2009

Distribution Tolerant Network Technology Flight Validation Report: DINET

In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 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. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions.

networking↗
NASA NTRS2021

Truncated ARQ Statistical Link Analysis for Dynamic Links

The future deep space links are migrating towards higher frequency bands such as Ka band and optical. These links are susceptible to non Gaussian and non linear effects such as atmospheric turbulence, scintillation, antenna mis-pointing, jitter, etc. These dynamic links thus will experience various degrees of fading loss, and some of these link disruptions cannot be effectively mitigated by forward error correction coding and/or interleaving. One effective way to ensure reliable communication is by using Automatic Repeat Request (ARQ) protocol, where the receiver acknowledges to the transmitter whether or not a data unit is successfully received. If a data unit is not successfully received (such as after a pre-set time-out), the transmitter would then re-transmit the lost data unit to the receiver. In a previous paper, we derived a statistical link analysis method of finding the optimal operating Signal-to-Noise Ratio (SNR) and estimating the latency of an ARQ scheme. In a more recent paper, we demonstrated the above method using the SNR distribution constructed from the Ka-band (32 GHz) flight data. To simplify the discussion, we considered the academic approach that the ARQ scheme allows for an infinite number of retransmissions. In this paper, we consider the more practical case of a truncated ARQ scheme, where there is a limit on the number of retransmissions. We derive the error probability, the optimal SNR setting, and the latency statistics of the correctly received frames of the truncated ARQ schemes. We first discuss the truncated ARQ link analysis principles using the Gaussian assumption for SNR distribution with a large variance. Next, we demonstrate the statistical truncated ARQ link analysis using the SNR distribution constructed from the Ka-band flight data. The results in this paper can be applied in the design of reliable communication systems such as the Consultative Committee for Space Data System (CCSDS) File Transfer Protocol (CFTP) and the Delay Tolerant Network (DTN).

Morabito, David↗
NASA NTRS2023

Flexible User Radio for Lunar Missions

NASA’s Artemis program and other lunar exploration and development programs are planning over 40 lunar missions before 2030. Lunar missions, both crewed and uncrewed, include orbiters, landers, rovers, and surface stations. All these missions require communications with Earth, either via Direct to Earth (DTE) links or through relays in lunar orbit. Multiple DTE options are available among existing and planned ground stations: Deep Space Network (DSN), European Space Agency, and others. Relay options include the planned Lunar Gateway, LunaNet compliant relays, and some lunar landers propose to launch dedicated orbiters. The dilemma for lunar system designers is to identify a communication link which meets mission requirements but does not have issues of limited access (e.g. DSN is in high demand supporting deep space missions with high priority and some with inflexible schedules), system impacts (high power Radio Frequency (RF) for DTE links), cost (dedicated relay), or operational date. To avoid this difficult decision, a Flexible Radio for Lunar Missions is proposed, which will enable system designs to proceed prior to any final decision on the communication network to be used, by enabling compatibility with any of multiple DTE or orbital relay communication systems. The Flexible Radio will support the necessary frequency, bandwidth, modulation, and power requirements to interoperate with the majority of known or planned DTE or relay systems, and can be designed into a lunar mission without prior knowledge of which link will ultimately be used. Furthermore, the link being used can be changed as needed during the mission, in near real time. The Flexible Radio design will leverage work already completed at NASA in the areas of Wideband RF, Software Defined Radio, Adaptive Coding and Modulation, and Phased Array antennas. The Flexible Radio requires sufficient bandwidth to cover the allocated frequencies for both the operation of links in cislunar space and for space-to-Earth links; the flexibility to support multiple modulations, data rates, and coding schemes; the ability to identify available relays, detect and recognize the signals of those relays, and adapt its own frequency, modulation, symbol rate, and code rate to operate with the detected relay (or DTE station); and finally, it requires appropriate software to support network configuration and interoperability with the detected network. The Flexible Radio can be designed in a sufficiently small, lightweight, and low-power package to be used in a wide variety of lunar systems. The initial implementation, as proposed, will focus on the Ka-band, supporting up to 2 GHz bandwidth around the 27 GHz frequency for return links, and 23 GHz for forward links. Other frequency bands are under consideration for future configurations. The software defined modem will support OQPSK, BPSK, and NASA-defined modulations which also support two-way ranging with data. For near-real time adaptation, the Flexible Radio will scan the sky for available relays, using a phased array antenna with Adaptive/Cognitive Communications. It will then configure for network interoperability supporting DTN and other protocol options. The Flexible Radio will support scheduled connections and on-demand use when available.

Lunar Space Communications↗
NASA NTRSDate not supplied

Flexible User Radio for Lunar Missions

NASA’s Artemis program and other lunar exploration and development programs are planning over 40 lunar missions before 2030. Lunar missions, both crewed and uncrewed, include orbiters, landers, rovers, and surface stations. All these missions require communications with Earth, either via Direct to Earth (DTE) links or through relays in lunar orbit. Multiple DTE options are available among existing and planned ground stations: Deep Space Network (DSN), European Space Agency, and others. Relay options include the planned Lunar Gateway, LunaNet compliant relays, and some lunar landers propose to launch dedicated orbiters. The dilemma for lunar system designers is to identify a communication link which meets mission requirements but does not have issues of limited access (e.g. DSN is in high demand supporting deep space missions with high priority and some with inflexible schedules), system impacts (high power Radio Frequency (RF) for DTE links), cost (dedicated relay), or operational date. To avoid this difficult decision, a Flexible Radio for Lunar Missions is proposed, which will enable system designs to proceed prior to any final decision on the communication network to be used, by enabling compatibility with any of multiple DTE or orbital relay communication systems. The Flexible Radio will support the necessary frequency, bandwidth, modulation, and power requirements to interoperate with the majority of known or planned DTE or relay systems, and can be designed into a lunar mission without prior knowledge of which link will ultimately be used. Furthermore, the link being used can be changed as needed during the mission, in near real time. The Flexible Radio design will leverage work already completed at NASA in the areas of Wideband RF, Software Defined Radio, Adaptive Coding and Modulation, and Phased Array antennas. The Flexible Radio requires sufficient bandwidth to cover the allocated frequencies for both the operation of links in cislunar space and for space-to-Earth links; the flexibility to support multiple modulations, data rates, and coding schemes; the ability to identify available relays, detect and recognize the signals of those relays, and adapt its own frequency, modulation, symbol rate, and code rate to operate with the detected relay (or DTE station); and finally, it requires appropriate software to support network configuration and interoperability with the detected network. The Flexible Radio can be designed in a sufficiently small, lightweight, and low-power package to be used in a wide variety of lunar systems. The initial implementation, as proposed, will focus on the Ka-band, supporting up to 2 GHz bandwidth around the 27 GHz frequency for return links, and 23 GHz for forward links. Other frequency bands are under consideration for future configurations. The software defined modem will support OQPSK, BPSK, and NASA-defined modulations which also support two-way ranging with data. For near-real time adaptation, the Flexible Radio will scan the sky for available relays, using a phased array antenna with Adaptive/Cognitive Communications. It will then configure for network interoperability supporting DTN and other protocol options. The Flexible Radio will support scheduled connections and on-demand use when available.

Lunar Space Communications↗
NASA NTRS1995

Satellite-Enhanced Personal Communications Experiments.

As an initial step in exploring the opportunities afforded by the merging of satellite and terrestrial networks, Bellcore and JPL conducted several experiments utilizing Bellcore's experimental Personal Communications System, NASA's Advanced Communications Technology Satellite (ACTS) and JPL's ACTS Mobile Terminal. These experiments provided valuable information on the applications, interfaces, and protocols needed for seamless integration of satellite and terrestrial networks. Looking a loss of bits, packets, and higher layer blocks over various satellite-terrestrial networks with mobile and stationary users under various conditions, our initial results indicate that the communication channel can vary dramatically, even within a single network. The effect of these conditions on error control protocols is highlighted, with a concentration on those that correct for losses of packets and higher layer blocks.

Satellite↗
NASA NTRS2016

Interoperable End-To-End Space Communications Architecture Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗
NASA NTRS2016

Interoperable End-To-End Space Communications Architectures Using CCSDS Building Blocks

End-to-end space communication architectures must connect system elements that may be in space, on the ground in mission operations centers, or are shared assets such as ground communications stations. End-to-end connectivity involves space communications over RF links, but also cross support services, terrestrial network circuits, and a variety of application layer protocols for commanding, telemetry, and mission operations. CCSDS has developed a large suite of interoperable, and cross-supportable, protocols for these purposes. Each of these defines a specific “layer” of functionality, such as: RF modulation, space link error coding, cross support frame delivery, or network layer routing. CCSDS has recently published a Space Communication Cross Support Architecture Requirements Document (SCCS-ARD) that describes how many of these standards fit together and how they are intended to be used. This paper provides an overview of this document, presented so as to explain the concepts so that others may use them. These concepts will be described from several key viewpoints.

Shames, Peter M.↗
NASA NTRS2014

Time Synchronization Prototype, Server Upgrade Procedure Support and Remote Software Development

Networks are roadways of communication that connect devices. Like all roadways, there are rules and regulations that govern whatever (information in this case) travels along them. One type of rule that is commonly used is called a protocol. More specifically, a protocol is a standard that specifies how data should be transmitted over a network. The project outlined in this document seeks to implement one protocol in particular, Precision Time Protocol, within the Kennedy Ground Control Subsystem network at Kennedy Space Center. This document also summarizes work completed for server upgrades, remote software developer training and how all three assignments demonstrated the importance of accountability and security.

Computer Science↗
NASA NTRS2014

Space Link Extension (SLE) Emulation for High-Throughput Network Communication

As the data rate requirements for space communications increases, signicant stressis placed not only on the wireless satellite communication links, but also on the groundnetworks which forward data from end-users to remote ground stations. These wide areanetwork (WAN) connections add delay and jitter to the end-to-end satellite communicationlink, eects which can have signicant impacts on the wireless communication link. It isimperative that any ground communication protocol can react to these eects such that theground network does not become a bottleneck in the communication path to the satellite.In this paper, we present our SCENIC Emulation Lab testbed which was developed to testthe CCSDS SLE protocol implementations proposed for use on future NASA communica-tion networks. Our results show that in the presence of realistic levels of network delay,high-throughput SLE communication links can experience signicant data rate throttling.Based on our observations, we present some insight into why this data throttling happens,and trace the probable issue back to non-optimal blocking communication which is sup-ported by the CCSDS SLE API recommended practices. These issues were presented aswell to the SLE implementation developers which, based on our reports, developed a newrelease for SLE which we show xes the SLE blocking issue and greatly improves the pro-tocol throughput. In this paper, we also discuss future developments for our end-to-endemulation lab and how these improvements can be used to develop and test future spacecommunication technologies.

Networking↗
NASA NTRS2005

A model to assess the Mars Telecommunications Network relay robustness

The relatively long mission durations and compatible radio protocols of current and projected Mars orbiters have enabled the gradual development of a heterogeneous constellation providing proximity communication services for surface assets. The current and forecasted capability of this evolving network has reached the point that designers of future surface missions consider complete dependence on it. Such designers, along with those architecting network requirements, have a need to understand the robustness of projected communication service. A model has been created to identify the robustness of the Mars Network as a function of surface location and time. Due to the decade-plus time horizon considered, the network will evolve, with emerging productive nodes and nodes that cease or fail to contribute. The model is a flexible framework to holistically process node information into measures of capability robustness that can be visualized for maximum understanding. Outputs from JPL's Telecom Orbit Analysis Simulation Tool (TOAST) provide global telecom performance parameters for current and projected orbiters. Probabilistic estimates of orbiter fuel life are derived from orbit keeping burn rates, forecasted maneuver tasking, and anomaly resolution budgets. Orbiter reliability is estimated probabilistically. A flexible scheduling framework accommodates the projected mission queue as well as potential alterations.

Mars Telecommunications Orbiter (MTO)↗
NASA NTRS2009

Wireless Avionics Packet to Support Fault Tolerance for Flight Applications

In this protocol and packet format, data traffic is monitored by all network interfaces to determine the health of transmitter and subsystems. When failures are detected, the network inter face applies its recover y policies to provide continued service despite the presence of faults. The protocol, packet format, and inter face are independent of the data link technology used. The current demonstration system supports both commercial off-the-shelf wireless connections and wired Ethernet connections. Other technologies such as 1553 or serial data links can be used for the network backbone. The Wireless Avionics packet is divided into three parts: a header, a data payload, and a checksum. The header has the following components: magic number, version, quality of service, time to live, sending transceiver, function code, payload length, source Application Data Interface (ADI) address, destination ADI address, sending node address, target node address, and a sequence number. The magic number is used to identify WAV packets, and allows the packet format to be updated in the future. The quality of service field allows routing decisions to be made based on this value and can be used to route critical management data over a dedicated channel. The time to live value is used to discard misrouted packets while the source transceiver is updated at each hop. This information is used to monitor the health of each transceiver in the network. To identify the packet type, the function code is used. Besides having a regular data packet, the system supports diagnostic packets for fault detection and isolation. The payload length specifies the number of data bytes in the payload, and this supports variable-length packets in the network. The source ADI is the address of the originating interface. This can be used by the destination application to identify the originating source of the packet where the address consists of a subnet, subsystem class within the subnet, a subsystem unit, and the local ADI number. The destination ADI is used to route the packet to its ultimate destination. At each hop, the sending interface uses the destination address to determine the next node for the data. The sending node is the node address of the interface that is broadcasting the packet. This field is used to determine the health of the subsystem that is sending the packet. In the case of a packet that traverses several intermediate nodes, it may be the node address of the intermediate node. The target node is the node address of the next hop for the packet. It may be an intermediate node, or the final destination for the packet. The sequence number is used to identify duplicate packets. Because each interface has multiple transceivers, the same packet will appear at both receivers. The sequence number allows the interface to correlate the reception and forward a single, unique packet for additional processing. The subnet field allows data traffic to be partitioned into segregated local networks to support large networks while keeping each subnet at a manageable size. This also keeps the routing table small enough so routing can be done by a simple table lookup in an FPGA device. The subsystem class identifies members of a set of redundant subsystems, and, in a hot standby configuration, all members of the subsystem class will receive the data packets. Only the active subsystem will generate data traffic. Specific units in a class of redundant units can be identified and, if the hot standby configuration is not used, packets will be directed to a specific subsystem unit.

Block, Gary L.↗
NASA NTRS2005

New Applications for the Testing and Visualization of Wireless Networks

Traditional techniques for examining wireless networks use physical link characteristics such as Signal-to-Noise (SNR) ratios to assess the performance of wireless networks. Such measurements may not be reliable indicators of available bandwidth. This work describes two new software applications developed at NASA Glenn Research Center for the investigation of wireless networks. GPSIPerf combines measurements of Transmission Control Protocol (TCP) throughput with Global Positioning System (GPS) coordinates to give users a map of wireless bandwidth for outdoor environments where a wireless infrastructure has been deployed. GPSIPerfView combines the data provided by GPSIPerf with high-resolution digital elevation maps (DEM) to help users visualize and assess the impact of elevation features on wireless networks in a given sample area. These applications were used to examine TCP throughput in several wireless network configurations at desert field sites near Hanksville, Utah during May of 2004. Use of GPSIPerf and GPSIPerfView provides a geographically referenced picture of the extent and deterioration of TCP throughput in tested wireless network configurations. GPSIPerf results from field-testing in Utah suggest that it can be useful in assessing other wireless network architectures, and may be useful to future human-robotic exploration missions.

Griffin, Robert I.↗
NASA NTRS2001

Networks for Autonomous Formation Flying Satellite Systems

The performance of three communications networks to support autonomous multi-spacecraft formation flying systems is presented. All systems are comprised of a ten-satellite formation arranged in a star topology, with one of the satellites designated as the central or "mother ship." All data is routed through the mother ship to the terrestrial network. The first system uses a TCP/lP over ATM protocol architecture within the formation the second system uses the IEEE 802.11 protocol architecture within the formation and the last system uses both of the previous architectures with a constellation of geosynchronous satellites serving as an intermediate point-of-contact between the formation and the terrestrial network. The simulations consist of file transfers using either the File Transfer Protocol (FTP) or the Simple Automatic File Exchange (SAFE) Protocol. The results compare the IF queuing delay, and IP processing delay at the mother ship as well as application-level round-trip time for both systems, In all cases, using IEEE 802.11 within the formation yields less delay. Also, the throughput exhibited by SAFE is better than FTP.

Knoblock, Eric J.↗
NASA NTRS2007

The Earth Based Ground Stations Element of the Lunar Program

The Lunar Architecture Team (LAT) is responsible for developing a concept for building and supporting a lunar outpost with several exploration capabilities such as rovers, colonization, and observatories. The lunar outpost is planned to be located at the Moon's South Pole. The LAT Communications and Navigation Team (C&N) is responsible for defining the network infrastructure to support the lunar outpost. The following elements are needed to support lunar outpost activities: A Lunar surface network based on industry standard wireless 802.xx protocols, relay satellites positioned 180 degrees apart to provide South Pole coverage for the half of the lunar 28-day orbit that is obscured from Earth view, earth-based ground stations deployed at geographical locations 120 degrees apart. This paper will focus on the Earth ground stations of the lunar architecture. Two types of ground station networks are discussed. One provides Direct to Earth (DTE) support to lunar users using Kaband 23/26Giga-Hertz (GHz) communication frequencies. The second supports the Lunar Relay Satellite (LRS) that will be using Ka-band 40/37GHz (Q-band). This paper will discuss strategies to provide a robust operational network in support of various lunar missions and trades of building new antennas at non-NASA facilities, to improve coverage and provide site diversification for handling rain attenuation.

Gal-Edd, Jonathan↗
NASA NTRS2011

Delay and Disruption Tolerant Networking MACHETE Model

To verify satisfaction of communication requirements imposed by unique missions, as early as 2000, the Communications Networking Group at the Jet Propulsion Laboratory (JPL) saw the need for an environment to support interplanetary communication protocol design, validation, and characterization. JPL's Multi-mission 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 commercial, non-commercial, and in-house custom 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. As NASA is expanding its Space Communications and Navigation (SCaN) capabilities to support planned and future missions, building infrastructure to maintain services and developing enabling technologies, an important and broader role is seen for MACHETE in design-phase evaluation of future SCaN architectures. To support evaluation of the developing Delay Tolerant Networking (DTN) field and its applicability for space networks, JPL developed MACHETE models for DTN Bundle Protocol (BP) and Licklider/Long-haul Transmission Protocol (LTP). DTN is an Internet Research Task Force (IRTF) architecture providing communication in and/or through highly stressed networking environments such as space exploration and battlefield networks. Stressed networking environments include those with intermittent (predictable and unknown) connectivity, large and/or variable delays, and high bit error rates. To provide its services over existing domain specific protocols, the DTN protocols reside at the application layer of the TCP/IP stack, forming a store-and-forward overlay network. The key capabilities of the Bundle Protocol include custody-based reliability, the ability to cope with intermittent connectivity, the ability to take advantage of scheduled and opportunistic connectivity, and late binding of names to addresses.

Segui, John S.↗
NASA NTRSDate not supplied

Implementing Delay/Disruption Tolerant Networking for NASA’s Plankton, Aerosol, Clouds, ocean Ecosystem (PACE) Mission

NASA’s Plankton, Aerosol, Clouds, ocean Ecosystem (PACE) mission will be the first NASA science mission to use Delay/Disruption Tolerant Networking (DTN) for routine operations. The DTN Bundle Protocol (BP) is being integrated into the core Flight Software (cFS) for the transfer of house-keeping files. DTN nodes will also be integrated into the Near Space Network (NSN) ground stations and the PACE Mission Operations Center. This paper will describe the DTN implementations, the PACE DTN operations concept and how this mission is a significant step towards the Solar System Internet.

dtn↗