Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “communication 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 487 records · Page 27

Computer networking at SLR stations

There are several existing communication methods to deliver data from the satellite laser ranging (SLR) station to the SLR data center and back: telephonmodem, telex, and computer networks. The SLR scientific community has been exploiting mainly INTERNET, BITNET/EARN, and SPAN. The total of 56 countries are connected to INTERNET and the number of nodes is exponentially growing. The computer networks mentioned above and others are connected through E-mail protocol. The scientific progress of SLR requires the increase of communication speed and the amount of the transmitted data. The TOPEX/POSEIDON test campaign required to deliver Quick Look data (1.7 kB/pass) from a SLR site to SLR data center within 8 hours and full rate data (up to 500 kB/pass) within 24 hours. We developed networking for the remote SLR station in Helwan, Egypt. The reliable scheme for data delivery consists of: compression of MERIT2 format (up to 89 percent), encoding to ASCII Me (files); and e-mail sending from SLR station--e-mail receiving, decoding, and decompression at the center. We do propose to use the ZIP method for compression/decompression and the UUCODE method for ASCII encoding/decoding. This method will be useful for stations connected via telephonemodems or commercial networks. The electronics delivery could solve the problem of the too late receiving of the FR data by SLR data center.

Novotny, Antonin↗

Internet Technology on Spacecraft

The Operating Missions as Nodes on the Internet (OMNI) project has shown that Internet technology works in space missions through a demonstration using the UoSAT-12 spacecraft. An Internet Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance. This also forms the basis for demonstrating subsequent scenarios. This approach provides capabilities heretofore either too expensive or simply not feasible such as reconfiguration on orbit. The OMNI project recognized the need to reduce the risk perceived by mission managers and did this with a multi-phase strategy. In the initial phase, the concepts were implemented in a prototype system that includes space similar components communicating over the TDRS (space network) and the terrestrial Internet. The demonstration system includes a simulated spacecraft with sample instruments. Over 25 demonstrations have been given to mission and project managers, National Aeronautics and Space Administration (NASA), Department of Defense (DoD), contractor technologists and other decisions makers, This initial phase reached a high point with an OMNI demonstration given from a booth at the Johnson Space Center (JSC) Inspection Day 99 exhibition. The proof to mission managers is provided during this second phase with year 2000 accomplishments: testing the use of Internet technologies onboard an actual spacecraft. This was done with a series of tests performed using the UoSAT-12 spacecraft. This spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 6 months! On board software was modified to add an IP stack to support basic IP communications. Also added was support for ping, traceroute and network timing protocol (NTP) tests. These tests show that basic Internet functionality can be used onboard spacecraft. The performance of data was measured to show no degradation from current approaches. The cost to implement is much less than current approaches due to the availability of highly reliable and standard Internet tools. Use of standard Internet applications onboard reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit. This work is funded through contract with the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC).

Rash, James↗

A Distributed Approach to High-Rate Delay Tolerant Networking Within a Virtualized Environment

The High-Rate Delay Tolerant Networking (HDTN) project has taken a distributed service-based approach to the development of a highly efficient delay tolerant networking (DTN) implementation. Through the analysis of many DTN implementations, system and mission requirements as well as the DTN protocol specifications, HDTN has worked to infuse modern computing technologies into the NASA approach to interplanetary networking. The initial use case of the HDTN software runs on a hypervisor representative of the International Space Station (ISS) DTN Gateway. In this scenario, multiple emulated payloads will send science data through HDTN to a mission operations center. HDTN will provide store and forward capability as well as network flow management. This paper discusses the infusion path of cognitive networking technologies in the NASA Space Communications and Navigation (SCaN) networks using the DTN architecture and protocols as the basis for cognitive routing and network management capabilities. HDTN has been developing the Bundle Protocol encoding and decoding mechanisms and messaging framework that can be used as the basis for integrating DTN with various learning and decision-making processes. The concepts of distributed computing, network virtualization, software defined networking and delay tolerant networking are basic building blocks which will further the development of cognitive networking. In addition to discussion of the HDTN software development and testing, this paper examines the role that each of these technologies play in the evolution of the current state of space networking into an intelligent network of networks.

Rachel Mary Dudukovich↗

CCSDS Overview

The primary goal of Consultative Committee for Space Data Systems (CCSDS) is interoperability between communications and data systems of space agencies' vehicles, facilities, missions and programs. Of all of the technologies used in spaceflight, standardization of communications and data systems brings the most benefit to multi-agency interoperability. CCSDS Started in 1982 developing standards at the lower layers of the protocol stack. The CCSDS scope has grown to cover standards throughout the entire ISO communications stack, plus other Data Systems areas (architecture, archive, security, XML exchange formats, etc.

Kearney, Mike↗

A hierarchically distributed architecture for fault isolation expert systems on the space station

The Space Station Axiomatic Fault Isolating Expert Systems (SAFTIES) system deals with the hierarchical distribution of control and knowledge among independent expert systems doing fault isolation and scheduling of Space Station subsystems. On its lower level, fault isolation is performed on individual subsystems. These fault isolation expert systems contain knowledge about the performance requirements of their particular subsystem and corrective procedures which may be involved in repsonse to certain performance errors. They can control the functions of equipment in their system and coordinate system task schedules. On a higher level, the Executive contains knowledge of all resources, task schedules for all systems, and the relative priority of all resources and tasks. The executive can override any subsystem task schedule in order to resolve use conflicts or resolve errors that require resources from multiple subsystems. Interprocessor communication is implemented using the SAFTIES Communications Interface (SCI). The SCI is an application layer protocol which supports the SAFTIES distributed multi-level architecture.

Miksell, Steve↗

Network architectures and protocols for the integration of ACTS and ISDN

A close integration of satellite networks and the integrated services digital network (ISDN) is essential for satellite networks to carry ISDN traffic effectively. This also shows how a given (pre-ISDN) satellite network architecture can be enhanced to handle ISDN signaling and provide ISDN services. It also describes the functional architecture and high-level protocols that could be implemented in the NASA Advanced Communications Technology Satellite (ACTS) low burst rate communications system to provide ISDN services.

Chitre, D. M.↗

Global synchronization algorithms for the Intel iPSC/860

In a distributed memory multicomputer that has no global clock, global processor synchronization can only be achieved through software. Global synchronization algorithms are used in tridiagonal systems solvers, CFD codes, sequence comparison algorithms, and sorting algorithms. They are also useful for event simulation, debugging, and for solving mutual exclusion problems. For the Intel iPSC/860 in particular, global synchronization can be used to ensure the most effective use of the communication network for operations such as the shift, where each processor in a one-dimensional array or ring concurrently sends a message to its right (or left) neighbor. Three global synchronization algorithms are considered for the iPSC/860: the gysnc() primitive provided by Intel, the PICL primitive sync0(), and a new recursive doubling synchronization (RDS) algorithm. The performance of these algorithms is compared to the performance predicted by communication models of both the long and forced message protocols. Measurements of the cost of shift operations preceded by global synchronization show that the RDS algorithm always synchronizes the nodes more precisely and costs only slightly more than the other two algorithms.

Seidel, Steven R.↗

A proven approach for more effective software development and maintenance

Modern space flight mission operations and associated ground data systems are increasingly dependent upon reliable, quality software. Critical functions such as command load preparation, health and status monitoring, communications link scheduling and conflict resolution, and transparent gateway protocol conversion are routinely performed by software. Given budget constraints and the ever increasing capabilities of processor technology, the next generation of control centers and data systems will be even more dependent upon software across all aspects of performance. A key challenge now is to implement improved engineering, management, and assurance processes for the development and maintenance of that software; processes that cost less, yield higher quality products, and that self-correct for continual improvement evolution. The NASA Goddard Space Flight Center has a unique experience base that can be readily tapped to help solve the software challenge. Over the past eighteen years, the Software Engineering Laboratory within the code 500 Flight Dynamics Division has evolved a software development and maintenance methodology that accommodates the unique characteristics of an organization while optimizing and continually improving the organization's software capabilities. This methodology relies upon measurement, analysis, and feedback much analogous to that of control loop systems. It is an approach with a time-tested track record proven through repeated applications across a broad range of operational software development and maintenance projects. This paper describes the software improvement methodology employed by the Software Engineering Laboratory, and how it has been exploited within the Flight Dynamics Division with GSFC Code 500. Examples of specific improvement in the software itself and its processes are presented to illustrate the effectiveness of the methodology. Finally, the initial findings are given when this methodology was applied across the mission operations and ground data systems software domains throughout Code 500.

Pajerski, Rose↗

NASA GRC and MSFC Space-Plasma Arc Testing Procedures

Tests of arcing and current collection in simulated space plasma conditions have been performed at the NASA Glenn Research Center (GRC) in Cleveland, Ohio, for over 30 years and at the Marshall Space Flight Center (MSFC) in Huntsville, Alabama, for almost as long. During this period, proper test conditions for accurate and meaningful space simulation have been worked out, comparisons with actual space performance in spaceflight tests and with real operational satellites have been made, and NASA has achieved our own internal standards for test protocols. It is the purpose of this paper to communicate the test conditions, test procedures, and types of analysis used at NASA GRC and MSFC to the space environmental testing community at large, to help with international space-plasma arcing-testing standardization. To be discussed are: 1.Neutral pressures, neutral gases, and vacuum chamber sizes. 2. Electron and ion densities, plasma uniformity, sample sizes, and Debuy lengths. 3. Biasing samples versus self-generated voltages. Floating samples versus grounded. 4. Power supplies and current limits. Isolation of samples from power supplies during arcs. 5. Arc circuits. Capacitance during biased arc-threshold tests. Capacitance during sustained arcing and damage tests. Arc detection. Prevention sustained discharges during testing. 6. Real array or structure samples versus idealized samples. 7. Validity of LEO tests for GEO samples. 8. Extracting arc threshold information from arc rate versus voltage tests. 9. Snapover and current collection at positive sample bias. Glows at positive bias. Kapon (R) pyrolisis. 10. Trigger arc thresholds. Sustained arc thresholds. Paschen discharge during sustained arcing. 11. Testing for Paschen discharge threshold. Testing for dielectric breakdown thresholds. Testing for tether arcing. 12. Testing in very dense plasmas (ie thruster plumes). 13. Arc mitigation strategies. Charging mitigation strategies. Models. 14. Analysis of test results. Finally, the necessity of testing will be emphasized, not to the exclusion of modeling, but as part of a complete strategy for determining when and if arcs will occur, and preventing them from occurring in space.

Ferguson, Dale C.↗

NASA GRC and MSFC Space-Plasma Arc Testing Procedures

Tests of arcing and current collection in simulated space plasma conditions have been performed at the NASA Glenn Research Center (GRC) in Cleveland, Ohio, for over 30 years and at the Marshall Space flight Center (MSFC) for almost as long. During this period, proper test conditions for accurate and meaningful space simulation have been worked out, comparisons with actual space performance in spaceflight tests and with real operational satellites have been made, and NASA has achieved our own internal standards for test protocols. It is the purpose of this paper to communicate the test conditions, test procedures, and types of analysis used at NASA GRC and MSFC to the space environmental testing community at large, to help with international space-plasma arcing testing standardization. To be discussed are: 1. Neutral pressures, neutral gases, and vacuum chamber sizes. 2. Electron and ion densities, plasma uniformity, sample sizes, and Debye lengths. 3. Biasing samples versus self-generated voltages. Floating samples versus grounded. 4. Power supplies and current limits. Isolation of samples from power supplies during arcs. Arc circuits. Capacitance during biased arc-threshold tests. Capacitance during sustained arcing and damage tests. Arc detection. Preventing sustained discharges during testing. 5. Real array or structure samples versus idealized samples. 6. Validity of LEO tests for GEO samples. 7. Extracting arc threshold information from arc rate versus voltage tests. 8 . Snapover and current collection at positive sample bias. Glows at positive bias. Kapton pyrolization. 9. Trigger arc thresholds. Sustained arc thresholds. Paschen discharge during sustained arcing. 10. Testing for Paschen discharge thresholds. Testing for dielectric breakdown thresholds. Testing for tether arcing. 11. Testing in very dense plasmas (ie thruster plumes). 12. Arc mitigation strategies. Charging mitigation strategies. Models. 13. Analysis of test results. Finally, the necessity of testing will be emphasized, not to the exclusion of modeling, but as part of a complete strategy for determining when and if arcs will occur, and preventing them from occurring in space.

Ferguson, Dale C.a↗

NASA GRC and MSFC Space-Plasma Arc Testing Procedures

Tests of arcing and current collection in simulated space plasma conditions have been performed at the NASA Glenn Research Center (GRC) in Cleveland, Ohio, for over 30 years and at the Marshall Space Flight Center (MSFC) in Huntsville, Alabama, for almost as long. During this period, proper test conditions for accurate and meaningful space simulation have been worked out, comparisons with actual space performance in spaceflight tests and with real operational satellites have been made, and NASA has achieved our own internal standards for test protocols. It is the purpose of this paper to communicate the test conditions, test procedures, and types of analysis used at NASA GRC and MSFC to the space environmental testing community at large, to help with international space-plasma arcing-testing standardization. Discussed herein are neutral gas conditions, plasma densities and uniformity, vacuum chamber sizes, sample sizes and Debye lengths, biasing samples versus self-generated voltages, floating samples versus grounded samples, test electrical conditions, arc detection, preventing sustained discharges during testing, real samples versus idealized samples, validity of LEO tests for GEO samples, extracting arc threshold information from arc rate versus voltage tests, snapover, current collection, and glows at positive sample bias, Kapton pyrolysis, thresholds for trigger arcs, sustained arcs, dielectric breakdown and Paschen discharge, tether arcing and testing in very dense plasmas (i.e. thruster plumes), arc mitigation strategies, charging mitigation strategies, models, and analysis of test results. Finally, the necessity of testing will be emphasized, not to the exclusion of modeling, but as part of a complete strategy for determining when and if arcs will occur, and preventing them from occurring in space.

Ferguson, Dale C.↗

NASA Tech Briefs, August 2004

Topics covered include: Data Relay Board with Protocol for High-Speed, Free-Space Optical Communications; Software and Algorithms for Biomedical Image Data Processing and Visualization; Rapid Chemometric Filtering of Spectral Data; Prioritizing Scientific Data for Transmission; Determining Sizes of Particles in a Flow from DPIV Data; Faster Processing for Inverting GPS Occultation Data; FPGA-Based, Self-Checking, Fault-Tolerant Computers; Ultralow-Power Digital Correlator for Microwave Polarimetry; Grounding Headphones for Protection Against ESD; Lightweight Stacks of Direct Methanol Fuel Cells; Highly Efficient Vector-Inversion Pulse Generators; Estimating Basic Preliminary Design Performances of Aerospace Vehicles; Framework for Development of Object-Oriented Software; Analyzing Spacecraft Telecommunication Systems; Collaborative Planning of Robotic Exploration; Tools for Administration of a UNIX-Based Network; Preparing and Analyzing Iced Airfoils; Evaluating Performance of Components; Fuels Containing Methane of Natural Gas in Solution; Direct Electrolytic Deposition of Mats of MnxOy Nanowires; Bubble Eliminator Based on Centrifugal Flow; Inflatable Emergency Atmospheric-Entry Vehicles; Lightweight Deployable Mirrors with Tensegrity Supports; Centrifugal Adsorption Cartridge System; Ultrasonic Apparatus for Pulverizing Brittle Material; Transplanting Retinal Cells using Bucky Paper for Support; Using an Ultrasonic Instrument to Size Extravascular Bubbles; Coronagraphic Notch Filter for Raman Spectroscopy; On-the-Fly Mapping for Calibrating Directional Antennas; Working Fluids for Increasing Capacities of Heat Pipes; Computationally-Efficient Minimum-Time Aircraft Routes in the Presence of Winds; Liquid-Metal-Fed Pulsed Plasma Thrusters; Personal Radiation Protection System; and Attitude Control for a Solar-Sail Spacecraft.

Source record↗

High Speed A/D DSP Interface for Carrier Doppler Tracking

As on-board satellite systems continue to increase in ability to perform self diagnostic checks, it will become more important for satellites to initiate ground communications contact. Currently, the NASA Space Network requires users to pre-arranged times for satellite communications links through the Tracking and Data Relay Satellite (TDRS). One of the challenges in implementing an on-demand access protocol into the Space Network, is the fact that a low Earth orbiting (LEO) satellite's communications will be subject to a doppler shift which is outside the capability of the NASA ground station to lock onto. In a prearranged system, the satellite's doppler is known a priori, and the ground station is able to lock onto the satellite's signal. This paper describes the development of a high speed analog to digital interface into a Digital Signal Processor (DSP). This system will be used for identifying the doppler shift of a LEO satellite through the Space Network, and aiding the ground station equipment in locking onto the signal. Although this interface is specific to one application, it can be used as a basis for interfacing other devices with a DSP.

Baggett, Timothy↗

NAND Flash Qualification Guideline

Better performing Forward Error Correction on the forward link along with adequate power in the data open an uplink operations trade space that enable missions to: Command to greater distances in deep space (increased uplink margin). Increase the size of the payload data (latency may be a factor). Provides space for the security header/trailer of the CCSDS Space Data Link Security Protocol. Note: These higher rates could be used for relief of emergency communication margins/rates and not limited to improving top-end rate performance. A higher performance uplink could also reduce the requirements on flight emergency antenna size and/or the performance required from ground stations. Use of a selective repeat ARQ protocol may increase the uplink design requirements but the resultant development is deemed acceptable, due the factor of 4 to 8 potential increase in uplink data rate.

Floating Gate Memory↗

Replacing the CCSDS Telecommand Protocol with Next Generation Uplink

Better performing Forward Error Correction on the forward link along with adequate power in the data open an uplink operations trade space that enable missions to: Command to greater distances in deep space (increased uplink margin) Increase the size of the payload data (latency may be a factor) Provides space for the security header/trailer of the CCSDS Space Data Link Security Protocol Note: These higher rates could be used for relief of emergency communication margins/rates and not limited to improving top-end rate performance. A higher performance uplink could also reduce the requirements on flight emergency antenna size and/or the performance required from ground stations. Use of a selective repeat ARQ protocol may increase the uplink design requirements but the resultant development is deemed acceptable, due the factor of 4 to 8 potential increase in uplink data rate.

Low Density Parity Check (LDPC)↗

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↗

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↗

Advanced Communication and Networking Technologies for Mars Exploration

Next-generation Mars communications networks will provide communications and navigation services to a wide variety of Mars science vehicles including: spacecraft that are arriving at Mars, spacecraft that are entering and descending in the Mars atmosphere, scientific orbiter spacecraft, spacecraft that return Mars samples to Earth, landers, rovers, aerobots, airplanes, and sensing pods. In the current architecture plans, the communication services will be provided using capabilities deployed on the science vehicles as well as dedicated communication satellites that will together make up the Mars network. This network will evolve as additional vehicles arrive, depart or end their useful missions. Cost savings and increased reliability will result from the ability to share communication services between missions. This paper discusses the basic architecture that is needed to support the Mars Communications Network part of NASA's Space Science Enterprise (SSE) communications architecture. The network may use various networking technologies such as those employed in the terrestrial Internet, as well as special purpose deep-space protocols to move data and commands autonomously between vehicles, at disparate Mars vicinity sites (on the surface or in near-Mars space) and between Mars vehicles and earthbound users. The architecture of the spacecraft on-board local communications is being reconsidered in light of these new networking requirements. The trend towards increasingly autonomous operation of the spacecraft is aimed at reducing the dependence on resource scheduling provided by Earth-based operators and increasing system fault tolerance. However, these benefits will result in increased communication and software development requirements. As a result, the envisioned Mars communications infrastructure requires both hardware and protocol technology advancements. This paper will describe a number of the critical technology needs and some of the ongoing research activities.

Bhasin, Kul↗