Search NASA⌕ Search

SEARCH · Search NASA

Results for “CCSDS 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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

The Utilization Profiles of the CCSDS Unified Space Link Protocol (USLP)

The purpose of this paper is to identify the utilization profiles for interfacing the Data Protocol Sublayer using the Unified Space Link Protocols (USLP) (reference 1) with the space link coding procedures as specified in the CCSDS Coding & Synchronization Blue Books (references 2 through 5), used in both telecommand and telemetry applications. This paper describes how the USLP Protocol utilizes the coding and synchronization sublayer to support: a. Direct to Earth (DTE) telemetry links for engineering and science data b. Direct to Earth (DTE) telemetry links for very high rate science data c. Direct from Earth (DFE) command, sequencing and flight software loads d. Space to Space Links (Proximity) utilized by orbiters for data exchange to/from surface bound assets. The CCSDS has divided the functions of the Data Link Layer into two sublayers: the Data Link Protocol Sublayer (DLP-SL) and the Coding and Synchronization Sublayer (CS-SL). The Data Link Protocol Sublayer (DLP-SL) interfaces to the users, accepting the data that is to be transported, on the sending side of the link, and delivering that data on the receiving end. The Transfer Frame is the data unit that is transferred across the Data Link Protocol Sublayer and the Coding and Synchronization Sublayer boundary. The Coding and Synchronization Sublayer (CS-SL) provides the encoding, randomization, and frame synchronization functions that prepares the USLP Transfer Frame for transport across the space link. The CS-SL is divided into 2 processes: 1) The Frame Interface Processes (FIP) performs the interface functions required to prepare the data for delivery to the Coding/Decoding Process (CDP). This process includes prepending a Frame Start Marker to the provided frame, when management has designated that the frame is not to be aligned to the codeblock or when there is no block code used. 2) The Coding/Decoding Process (CDP) performs the forward error correction processes that are used to optimize the performance of the link and minimize the error rate. The CDP creates the symbol stream that is delivered to the Physical Layer. The transfer of the USLP transfer frames across different types of space links is the focus of this paper. The Protocol Data Unit (PDU) that is passed in both directions between the Data Link Protocol Sublayer (DLP-SL) and Coding and Synchronization Sublayer (CS-SL) is the transfer frame. The USLP frame structure provides flexibility that can be constrained by the functions utilized within the CS-SL that prepare the transfer frame for transit. For example, the USLP transfer frame contains a length field that enables the frame to be of variable length but CS-SL under certain conditions may constrain the frame to be fixed in length. This paper describes 5 operational modes available for use by the Data Link Layer to provide data exchange across the USLP space link. These modes are different because different operational requirements apply to vastly different types of space links and thus the communications implementation requirements differ. The environmental issues include the power or energy available, the distance between the end points of the link, the complexity of the equipment available at those end points, the atmospheric conditions and radiometric frequency selection. The CS-SL utilizes different forward error correcting codes supported by specific operational modes to configure the data for transit. This paper describes all of the operational modes in a series of data models which decompose the functionality between the Data Link Protocol Sublayer and the Coding and Synchronization sublayer. The operational modes described are: 1. Uncoded Mode: has been used for short links that contain significant available power to provide an acceptable frame error rate. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 2. Convolutional Only Mode: is currently the prime forward error correction coding used for the proximity links. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 3. Variable Length Frame Aligned to Variable Length Codeblock (TC): is used for Direct from Earth links were power levels are high and the simple, least complex code i.e., the BCH code is used. This mode has been in use since the early 1970s. The BCH code is a short code and the decoder is easy to implement. 4. Fixed Length Frame Aligned to Fixed Length Codeblock (AOS/TM): was introduced when the concatenated Convolutional and Reed-Solomon Code was formulated to provide significant reduction in link data error rate and the ability to determine if there was an error in the decoded codeblock. The frame is aligned to the codeblock so that there is a one to one relationship of frame errors to codeblock errors without additional error detection coding being added. This mode requires the protocol frames to be the exact size of the message portion of the codeblock. 5. Frames Unaligned to Fixed Length Codeblocks (Currently used for very high rates and space to space links): This mode is currently used for missions that have a very high data rate that can be controlled adaptively as the environment changes and as the next generation operating mode for the proximity link. This mode from a coded data stream point of view is exactly like that described in 4. above, except that the frame need not be aligned to the codeblock. There is no requirement on frame length when using this mode. Thus when using USLP it can be used to support links that require short or long frames. There is also no mandatory requirement that frames cannot be separated by idle data reducing the tight data rate connection requirements between the data link protocol sublayer and the coding & synchronization sublayer. In conclusion, how these operational modes can be put to use in mission operational scenarios is described for Direct from Earth links (DFE), Direct to Earth links (DTE), and Proximity links.

Greenberg, E.↗
NASA NTRS2009

Architectural Analysis of Complex Evolving Systems of Systems

The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.

Lindvall, Mikael↗
NASA NTRS2014

Enhanced International Space Station Ku-Band Telemetry Service

(1) The ISS is diligently working to increase utilization of the resources this unique laboratory provides; (2) Recent upgrades enabled the use of Internet Protocol communication using the CCSDS IP Encapsulation protocol; and (3) The Huntsville Operations Support Center has extended the onboard LAN to payload teams enabling the use of standard IP protocols for payload operations.

Cecil, Andrew↗
NASA NTRS2020

The Use of the CCSDS Unified Space Data Link Protocol on All Space Links

NASA is actively pursuing the development of data link layer protocols for the human space program with the added intent of infusing the key capabilities of efficient space link security, support for inter-networking, and compatible operational modes with Optical Communications. There seems to be two divergent technical approaches on how to provide these capabilities: one associated with the use of a fixed length Protocol Data Unit (PDU) i.e., a fixed length transfer frame, and the other advocating the use of a variable length transfer frame. The objective of this paper is to evaluate the pros and cons of these two approaches within the context of existing Consultative Committee for Space Data Systems (CCSDS) Space Data Link Protocols and Channel Coding Recommendations for all space links: space to ground (return) link, ground to space (forward) link and space to space (proximity) links.

Kazz, Greg J↗
NASA NTRS2010

High-Performance CCSDS Encapsulation Service Implementation in FPGA

The Consultative Committee for Space Data Systems (CCSDS) Encapsulation Service is a convergence layer between lower-layer space data link framing protocols, such as CCSDS Advanced Orbiting System (AOS), and higher-layer networking protocols, such as CFDP (CCSDS File Delivery Protocol) and Internet Protocol Extension (IPE). CCSDS Encapsulation Service is considered part of the data link layer. The CCSDS AOS implementation is described in the preceding article. Recent advancement in RF modem technology has allowed multi-megabit transmission over space links. With this increase in data rate, the CCSDS Encapsulation Service needs to be optimized to both reduce energy consumption and operate at a high rate. CCSDS Encapsulation Service has been implemented as an intellectual property core so that the aforementioned problems are solved by way of operating the CCSDS Encapsulation Service inside an FPGA. The CCSDS En capsula tion Service in FPGA implementation consists of both packetizing and de-packetizing features

Clare, Loren P.↗
NASA NTRS2021

BPv6 and BPv7 Coexistence in Delay Tolerant Networking (DTN)

As DTN has progressed since its inception in 2002, the community stabilized around Bundle Protocol version 6 (BPv6). This protocol was standardized by the RFC 5050’s definition of BPv6 and was later standardized and refined for space operations by the CCSDS Bundle Protocol Specification. After the release of RFC 5050, a variety of implementations and missions used BPv6 and noted several improvements that could be made to the protocol. These improvements culminated in a push to release a new protocol version, BPv7. Unfortunately, the vast improvements and difference in encoding that separates BPv7 from BPv6 also makes the two versions inherently incompatible. Consequently, there is an issue implementing BPv7 in existing systems while continuing support for BPv6 implementations. In response to this issue, two solutions emerge: (1) Bundle-in-Bundle Encapsulation (BIBE), a capability that wraps a bundle in another bundle for shipping between intermediary nodes, and (2) version agnostic DTN implementations. These concepts have been proven out in the MSFC DTN implementation known as DTNME.

Joshua Deaton↗
NASA NTRS2016

A Multi-Center Space Data System Prototype Based on CCSDS Standards

Deep space missions beyond earth orbit will require new methods of data communications in order to compensate for increasing Radio Frequency (RF) propagation delay. The Consultative Committee for Space Data Systems (CCSDS) standard protocols Spacecraft Monitor & Control (SM&C), Asynchronous Message Service (AMS), and Delay/Disruption Tolerant Networking (DTN) provide such a method. However, the maturity level of this protocol stack is insufficient for mission inclusion at this time. This Space Data System prototype is intended to provide experience which will raise the Technical Readiness Level (TRL) of this protocol set. In order to reduce costs, future missions can take advantage of these standard protocols, which will result in increased interoperability between control centers. This prototype demonstrates these capabilities by implementing a realistic space data system in which telemetry is published to control center applications at the Jet Propulsion Lab (JPL), the Marshall Space Flight Center (MSFC), and the Johnson Space Center (JSC). Reverse publishing paths for commanding from each control center are also implemented. The target vehicle consists of realistic flight computer hardware running Core Flight Software (CFS) in the integrated Power, Avionics, and Power (iPAS) Pathfinder Lab at JSC. This prototype demonstrates a potential upgrade path for future Deep Space Network (DSN) modification, in which the automatic error recovery and communication gap compensation capabilities of DTN would be exploited. In addition, SM&C provides architectural flexibility by allowing new service providers and consumers to be added efficiently anywhere in the network using the common interface provided by SM&C's Message Abstraction Layer (MAL). In FY 2015, this space data system was enhanced by adding telerobotic operations capability provided by the Robot API Delegate (RAPID) family of protocols developed at NASA. RAPID is one of several candidates for consideration and inclusion in a new international standard being developed by the CCSDS Telerobotic Operations Working Group. Software gateways for the purpose of interfacing RAPID messages with the existing SM&C based infrastructure were developed. Telerobotic monitor, control, and bridge applications were written in the RAPID framework, which were then tailored to the NAO telerobotic test article hardware, a product of Aldebaran Robotics.

Rich, Thomas M.↗
NASA NTRS2014

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

As the data rate requirements for space communications increases, significant stress is placed not only on the wireless satellite communication links, but also on the ground networks which forward data from end-users to remote ground stations. These wide area network (WAN) connections add delay and jitter to the end-to-end satellite communication link, effects which can have significant impacts on the wireless communication link. It is imperative that any ground communication protocol can react to these effects such that the ground 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 test the CCSDS SLE protocol implementations proposed for use on future NASA communication networks. Our results show that in the presence of realistic levels of network delay, high-throughput SLE communication links can experience significant 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 as well to the SLE implementation developers which, based on our reports, developed a new release for SLE which we show fixes the SLE blocking issue and greatly improves the protocol throughput. In this paper, we also discuss future developments for our end-to-end emulation lab and how these improvements can be used to develop and test future space communication technologies.

Networking↗
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 NTRS2006

Evaluation of the Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Array

The current implementation of the Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Arrays (TRIGA) is equipped with CFDP protocol and CCSDS Telemetry and Telecommand framing schemes to replace the CPU intensive software counterpart implementation for reliable deep space communication. We present the hardware/software co-design methodology used to accomplish high data rate throughput. The hardware CFDP protocol stack implementation is then compared against the two recent flight implementations. The results from our experiments show that TRIGA offers more than 3 orders of magnitude throughput improvement with less than one-tenth of the power consumption.

protocol processing hardware↗
NASA NTRS2002

An Analysis for an Internet Grid to Support Space Based Operations

Currently, and in the past, dedicated communication circuits and "network services" with very stringent performance requirements have been used to support manned and unmanned mission critical ground operations at GSFC, JSC, MSFC, KSC and other NASA facilities. Because of the evolution of network technology, it is time to investigate other approaches to providing mission services for space ground and flight operations. In various scientific disciplines, effort is under way to develop network/komputing grids. These grids consisting of networks and computing equipment are enabling lower cost science. Specifically, earthquake research is headed in this direction. With a standard for network and computing interfaces using a grid, a researcher would not be required to develop and engineer NASA/DoD specific interfaces with the attendant increased cost. Use of the Internet Protocol (IP), CCSDS packet spec, and reed-solomon for satellite error correction etc. can be adopted/standardized to provide these interfaces. Generally most interfaces are developed at least to some degree end to end. This study would investigate the feasibility of using existing standards and protocols necessary to implement a SpaceOps Grid. New interface definitions or adoption/modification of existing ones for the various space operational services is required for voice both space based and ground, video, telemetry, commanding and planning may play a role to some undefined level. Security will be a separate focus in the study since security is such a large issue in using public networks. This SpaceOps Grid would be transparent to users. It would be anagulous to the Ethernet protocol's ease of use in that a researcher would plug in their experiment or instrument at one end and would be connected to the appropriate host or server without further intervention. Free flyers would be in this category as well. They would be launched and would transmit without any further intervention with the researcher or ground ops personnel. The payback in developing these new approaches in support of manned and unmanned operations is lower cost and will enable direct participation by more people in organizations and educational institutions in space based science. By lowering the high cost of space based operations and networking, more resource will be available to the science community for science. With a specific grid in place, experiment development and operations would be much less costly by using standardized network interfaces. Because of the extensive connectivity on a global basis, significant numbers of people would participate in science who otherwise would not be able to participate.

Bradford, Robert↗
NASA NTRS2016

In-Space Networking on NASA's SCAN Testbed

The NASA Space Communications and Navigation (SCaN) Testbed, an external payload onboard the International Space Station, is equipped with three software defined radios and a flight computer for supporting in-space communication research. New technologies being studied using the SCaN Testbed include advanced networking, coding, and modulation protocols designed to support the transition of NASAs mission systems from primarily point to point data links and preplanned routes towards adaptive, autonomous internetworked operations needed to meet future mission objectives. Networking protocols implemented on the SCaN Testbed include the Advanced Orbiting Systems (AOS) link-layer protocol, Consultative Committee for Space Data Systems (CCSDS) Encapsulation Packets, Internet Protocol (IP), Space Link Extension (SLE), CCSDS File Delivery Protocol (CFDP), and Delay-Tolerant Networking (DTN) protocols including the Bundle Protocol (BP) and Licklider Transmission Protocol (LTP). The SCaN Testbed end-to-end system provides three S-band data links and one Ka-band data link to exchange space and ground data through NASAs Tracking Data Relay Satellite System or a direct-to-ground link to ground stations. The multiple data links and nodes provide several upgradable elements on both the space and ground systems. This paper will provide a general description of the testbeds system design and capabilities, discuss in detail the design and lessons learned in the implementation of the network protocols, and describe future plans for continuing research to meet the communication needs for evolving global space systems.

space networks↗
NASA NTRS1993

Verification of technical elements of the advanced spacecraft based upon the CCSDS recommendation

We are going to meet the era when advanced spacecraft such as space stations are developed and operated. The current system of the satellite operations control will need to undergo many changes. We consider that the future system will require the following functions: the function for interchanging data between international agencies, processing the various kinds of space data, and distributing data as many unspecified users require. However, we have to solve the following problems in order to satisfy these requirements: the problem of standardization of space data communication protocol, establishment of multimedia data management method, and standardization of the user interface. This paper describes three techniques to solve the above mentioned problems. That is, standardization of the data communication protocol between space and ground by AOS (Advanced Orbiting System) protocol of CCSDS (Consultative Committee for Space Data Systems) Recommendation, management of multimedia data by catalog reference, standardization of user interface by SFDU(Standard Formatted Data Unit) of CCSDS Recommendation.

Hara, Hideo↗
NASA NTRS2001

Chip for CCSDS Compatible Serial Data Streams

A configurable service processor for telemetry ground stations is totally implemented in VLSI/ASIC hardware and finds use in spacecraft systems and other communications systems that operate according to CCSDS and CCSDS-like protocols. The service processor performs the traditional functions of data extraction at very high data and packet rates.

Jason T Dowling↗
NASA NTRS2004

Data Management for Mars Exploration Rovers

Data Management for the Mars Exploration Rovers (MER) project is a comprehensive system addressing the needs of development, test, and operations phases of the mission. During development of flight software, including the science software, the data management system can be simulated using any POSIX file system. During testing, the on-board file system can be bit compared with files on the ground to verify proper behavior and end-to-end data flows. During mission operations, end-to-end accountability of data products is supported, from science observation concept to data products within the permanent ground repository. Automated and human-in-the-loop ground tools allow decisions regarding retransmitting, re-prioritizing, and deleting data products to be made using higher level information than is available to a protocol-stack approach such as the CCSDS File Delivery Protocol (CFDP).

Mars missions↗
NASA NTRS2010

NASA Tech Briefs, September 2010

Topics covered include: Instrument for Measuring Thermal Conductivity of Materials at Low Temperatures; Multi-Axis Accelerometer Calibration System; Pupil Alignment Measuring Technique and Alignment Reference for Instruments or Optical Systems; Autonomous System for Monitoring the Integrity of Composite Fan Housings; A Safe, Self-Calibrating, Wireless System for Measuring Volume of Any Fuel at Non-Horizontal Orientation; Adaptation of the Camera Link Interface for Flight-Instrument Applications; High-Performance CCSDS Encapsulation Service Implementation in FPGA; High-Performance CCSDS AOS Protocol Implementation in FPGA; Advanced Flip Chips in Extreme Temperature Environments; Diffuse-Illumination Systems for Growing Plants; Microwave Plasma Hydrogen Recovery System; Producing Hydrogen by Plasma Pyrolysis of Methane; Self-Deployable Membrane Structures; Reactivation of a Tin-Oxide-Containing Catalys; Functionalization of Single-Wall Carbon Nanotubes by Photo-Oxidation; Miniature Piezoelectric Macro-Mass Balance; Acoustic Liner for Turbomachinery Applications; Metering Gas Strut for Separating Rocket Stages; Large-Flow-Area Flow-Selective Liquid/Gas Separator; Counterflowing Jet Subsystem Design; Water Tank with Capillary Air/Liquid Separation; True Shear Parallel Plate Viscometer; Focusing Diffraction Grating Element with Aberration Control; Universal Millimeter-Wave Radar Front End; Mode Selection for a Single-Frequency Fiber Laser; Qualification and Selection of Flight Diode Lasers for Space Applications; Plenoptic Imager for Automated Surface Navigation; Maglev Facility for Simulating Variable Gravity; Hybrid AlGaN-SiC Avalanche Photodiode for Deep-UV Photon Detection; High-Speed Operation of Interband Cascade Lasers; 3D GeoWall Analysis System for Shuttle External Tank Foreign Object Debris Events; Charge-Spot Model for Electrostatic Forces in Simulation of Fine Particulates; Hidden Statistics Approach to Quantum Simulations; Reconstituted Three-Dimensional Interactive Imaging; Determining Atmospheric-Density Profile of Titan; Digital Microfluidics Sample Analyzer; Radiation Protection Using Carbon Nanotube Derivatives; Process to Selectively Distinguish Viable from Non-Viable Bacterial Cells; and TEAMS Model Analyzer.

Source record↗
NASA NTRS2006

TRIGA: Telecommunications Protocol Processing Subsystem Using Reconfigurable Interoperable Gate Arrays

We present the Telecommunications protocol processing subsystem using Reconfigurable Interoperable Gate Arrays (TRIGA), a novel approach that unifies fault tolerance, error correction coding and interplanetary communication protocol off-loading to implement CCSDS File Delivery Protocol and Datalink layers. The new reconfigurable architecture offers more than one order of magnitude throughput increase while reducing footprint requirements in memory, command and data handling processor utilization, communication system interconnects and power consumption.

protocol processing hardware engine↗