SEARCH · Search NASA

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.

SourceResearch connectionFrom yearThrough year

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

At least 469 records · Page 26

All sources NASA NTRS DOE OSTI

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

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)↗

DOE OSTI2026

SoS-SDQN: System of Systems Software-defined Quantum Networking

Quantum networks are needed for quantum domain applications that may run across different network deployments - point-to-point, multi-node networks, and possibly across inter-domain quantum networks, like the quantum internet. Unlike classical computing networks, quantum networks involve heterogeneous systems nodes that currently require local and manual control. This needs a unified control approach to help them integrate, work seamlessly, and have global knowledge. Software-defined Networking (SDN) has been successfully leveraged in classical networking for seamless and software-driven control of network infrastructure and packet switching, but not in management of quantum network applications across heterogeneous systems. In this paper, we review the current state of the art and present early developments of a System-of-Systems Software-defined Quantum Networking architecture (SoS-SDQN), a generic architecture that supports software-driven quantum network experiments across heterogeneous quantum systems. The architecture modifies the generic SDN to address the domain requirements of quantum networks and proposes a multilevel SDQN to provide a global view of network status, running applications, and control of incorporated heterogeneous quantum systems. We also design and implement a SoS SouthBound Quantum Interface (SoS-SBQI), a quantum infrastructure protocol that abstracts automation of applications across the network.

Alnajjar, Anees [ORNL] (ORCID:0000000237101601)↗

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 ﬁrst 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 ﬁles. 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 signiﬁcant step towards the Solar System Internet.

dtn↗

NASA NTRS1986

Global system data bus using the Digital Autonomous Terminal Access Communication protocol

Modern digital avionic systems with distributed processing require networking to connect the many elements. Digital Autonomous Terminal Access Communication (DATAC) is one of many such networks. DATAC has been implemented on the Transport Systems Research Vehicle (TSRV), a Boeing 737 aircraft operated by the National Aeronautics and Space Administration's Advanced Transport Operating Systems Program Office (ATOPS). This paper presents the TSRV implementation of the DATAC bus, a description of the DATAC system, a synchronization mechanism, details of data flow throughout the system, and a discussion of the modes available with DATAC. Numerous flight tests have been conducted using DATAC as the only means of communication between systems with outstanding results. DATAC is now an integral part of the TSRV and is expected to satisfy near term as well as future requirements for growth and flexibility.

Holmes, David C. E.↗

NASA NTRS1998

Remote Observing with the Keck Telescope Using the ACTS Satellite

As a technical demonstration project for the NASA Advanced Communications Technology Satellite (ACTS), we have implemented remote observing on the 10-meter Keck II telescope on Mauna Kea in Hawaii from the California Institute of Technology campus in Pasadena. The data connection consists of optical fiber networks in Hawaii and California, connecting the end-points to high data rate (HDR) ACTS satellite antennae at JPL in Pasadena and at the Tripler Army Medical Center in Honolulu. The terrestrial fiber networks run the asynchronous transfer mode (ATM) protocol at DS-3 (45 Mbit/sec) speeds, providing ample bandwidth to enable remote observing with a software environment identical to that used for on-site observing in Hawaii. This experiment has explored the data requirements of remote observing with a modern research telescope and large-format detector arrays. While the maximum burst data rates are lower than those required for many other applications (e.g., HDTV), the network reliability and data integrity requirements are critical. As we show in this report, the former issue particularly may be the greatest challenge for satellite networks for this class of application. We have also experimented with the portability of standard TCP/IP applications to satellite networks, demonstrating the need for alternative TCP congestion algorithms and minimization of bit error rates (BER). Reliability issues aside, we have demonstrated that true remote observing over high-speed networks provides several important advantages over standard observing paradigms. Technical advantages of the high-speed network access include more rapid download of data to a user's home institution and the opportunity for alternative communication facilities between members of an observing team, such as audio- and videoconferencing.

SATELLITE COMMUNICATIONS↗

NASA NTRS2006

Spacecraft Data and Relay Management using Delay Tolerant Networking

NASA's demonstration of the successful transmission of relay data through the orbiting Mars Odyssey, Mars Global Surveyor, and Mars Express by the Mars Exploration Rovers has shown not only the benefit of using a relay satellite for multiple landed assets in a deep space environment but also the benefit of international standards for such architecture. As NASA begins the quest defined in the Vision for Exploration with robotic and manned missions to the Moon, continues its study of Mars, and is joined in these endeavors by countries world-wide, landed assets transmitting data through relay satellites will be crucial for completing mission objectives. However, this method of delivery of data will result in increased complexity in routing and prioritization of data transmission as the number of missions increases. Also, there is currently no standard method among organizations conducting such missions to return these data sets to Earth given a complex environment. One possibility for establishing such a standard is for mission designers to deploy protocols which fall under the umbrella of Delay Tolerant Networking (DTN). These developing standards include the Bundle Protocol (BP) which provides a standard, secure, store and forward mechanism designed for high latency and asymmetric communication links and the Licklider Transmission Protocol (LTP) which is used to provide a reliable deep space link transmission service.

network congestion control algorithm↗

NASA NTRS2002

Mobile Router Technology Development

Cisco Systems and NASA have been performing joint research on mobile routing technology under a NASA Space Act Agreement. Cisco developed mobile router technology and provided that technology to NASA for applications to aeronautic and space-based missions. NASA has performed stringent performance testing of the mobile router, including the interaction of routing and transport-level protocols. This paper describes mobile routing, the mobile router, and some key configuration parameters. In addition, the paper describes the mobile routing test network and test results documenting the performance of transport protocols in dynamic routing environments.

Ivancic, William D.↗