Edward Greenberg

Development and flight performance of CCSDS Proximity-1 on Odyssey and the Mars exploration rovers

The UHF relay link through the Mars Odyssey orbiter exceeded expectations of the Mars exploration rover (MER) project and played a critical role in the return of data from the surface of Mars and in the accuracy of the rover position determination. This paper will discus the development and performance of the UHF transceivers and the Consultative Committee for Spacecraft Data Systems (CCSDS) Proximity-1 space link protocol that were used by Odyssey and the two MER rovers; and some of the more prominent lessons learned during development and operations of the MER-Odyssey relay link

Facilitating information transfer in the Eos era

A simple interactive demonstration program has been written in C to allow a user to input data field descriptions as label format. This program generates a full RECFMT (record format) description and the complete transfer syntax description notation (TSDN) file. It is intended that this program be upgraded to operational quality and be made available to users to simplify the description and TSDN file construction task. The total set of capabilities, from the standard formatted data unit packaging of related files and consistent segment structures, through the type definition techniques and the call server, will constitute a unique tool for the systematic transfer of data. This software on each end may be independent, one end from the other. With it available, local software that will be needed to convert user files to and from the canonical interface will be appreciably simplified. >

End-to-end information system concept for the Mars Telecommunications Orbiter

The Mars Telecommunications Orbiter (MTO) was intended to provide high-performance deep space relay links to landers, orbiters, sample-return missions, and approaching spacecraft in the vicinity of Mars, to demonstrate interplanetary laser communications, to demonstrate autonomous navigation, and to carry out its own science investigations. These goals led to a need for an array of end-to-end information system (EEIS) capabilities unprecedented for a deep space mission. We describe here the EEIS concept for provision of six major types of services by the MTO: relay, open-loop recording, Marscraft tracking, timing, payload data transport, and Earthlink data transport. We also discuss the key design drivers and strategies employed in the EEIS design, and possible extensions of the MTO EEIS concept to accommodate scenarios beyond the original MTO mission requirements

Homogeneity of Frame Secondary Header/Insert Zone across CCSDS link protocols

The CCSDS Telemetry (TM), Telecommand (TC), and AOS (Advanced Orbiting Systems) data link protocols were all developed to support data transfer to/from a single spacecraft with a hands off approach of “security by obscurity”. Each of these protocols was developed at a different point in time and each came into existence based upon slightly different requirements. These differences resulted in a mixed usage of both the Transfer Frame Secondary Header (FSH) and Insert Zone fields. Moreover this mixed usage makes it difficult for users to understand and apply these fields today. Emerging work within CCSDS in the areas of space internetworking and data link layer security is providing a forum for further standardization that could utilize these fields. The primary driver is to provide common services across all the CCSDS Link Layer Protocols for improved dynamic flexibility for virtual channel operations including the flexible addition of security. We envision the coming era containing trunk lines utilizing switching nodes in a network that provide both link layer frame switching and network layer packet routing. In the link layer case, a node is simply taking multiple physical channels and multiplexing them together to form an aggregate physical channel. Here the switching node does not build frames but rather it simply multiplexes them into a single stream or demultiplex them from a single stream and channels them to separate channels based on their Master Channel address. The current design of the AOS protocol allows one to assign a different Master Channel ID or Virtual Channel to the frames produced by different entities within an enterprise; an example would be different agency’s Instrument/Lab on a space platform (ISS) would control the content of the Virtual Channel that they produce and then provide it to the switching node to multiplex the data into the return trunk line channel. When the AOS protocol was established the vision was to use AOS primarily for high rate links but designed in a feature to support low latency data for low rate operations. This low rate support was allocated to the Physical Channel and not the Master or Virtual Channel because having multiple Master Channels on a single Physical Channel was not envisioned at that time. The current view of how the AOS protocol will provide support for mission enlarges the role for supporting low latency data at low data rates and spreading the functionality across the Master Channels and Virtual Channels. For this reason we recommend the use of the Insert Zone for Master Channels and incorporate a self identifying and self delimiting Virtual Channel Secondary Header to provide this capability within a Virtual Channel. Thus we have changed the association of the Insert Zone from the Physical channel to the Master channel. This approach when applied to the TM protocol allows us to redefine the MC-FSH service to be an Insert Zone thus eliminating the duality of the FSH signaling flag and provide for both the Master Channel Insert Zone and Virtual Channel Secondary Header services when desired. Since we are developing approaches for the future then the merging of frames received from different channels may well be a model for a relay node where each mission builds its frames, encrypts/decrypts them and the relay node simply routes the frames onto/off other physical links.

Mars Interoperability 2008-2015: Options for Relay Orbiter Support to Mars Bound Assets

The current relay orbiter infrastructure at Mars, in support of the user assets presently at Mars and those scheduled for the 2008 to 2015 time frame, only have a need to store-and-forward the returned data collected by an asset to Earth as a single non-prioritized data file. In the forward direction, the relay orbiters are only required to relay the forward link data, i.e., command sequences, software and configuration information assembled on the ground, to the Asset. There are currently no requirements for status/control messages or files to be sent in the return direction from an Asset to an application located on the Relay, nor are there requirements in the forward direction to send status/control messages or files originating on a Relay to an Asset. In addition there are currently no networking requirements at Mars where data originally sent by an Asset is to be delivered to another user asset. However, we foresee the day when standard services for 1) on-board file prioritization of user asset data by a Relay, 2) control/status message transfer between assets and a Relay, and 3) networking between assets i.e., Asset to Asset message/file transfer via a Relay will be required. Each of these services will require the Relay to be capable of understanding the data type and routing needs of the user asset data and be capable of processing it for these purposes. This paper will focus on the innovative enhancements required to the existing communications infrastructure at Mars to enable these future services.

CCSDS application profiles for the Mars environment

A common set of communications protocols needs to be agreed upon amongst all participants in a communications network to enable intercommunication. The mechanism to achieve this objective is an application profile, which specifies which protocols within the five layers (physical, data link, network, transport, and application) of the CCSDS protocol stack are applicable to the elements of the network. The first step in establishing an application profile for an enterprise is to evaluate and choose which communication protocols and space data application standards are to be used by the asset classes (e.g., orbiters, landers, probes) defined within the enterprise. Once this list of standards has been chosen, the individual options within these standards need to be evaluated in order that a specific subset of these options can be chosen. The application profile defines a program’s communications policy for that specific enterprise. Application profiles define the baseline communications capabilities for all the missions participating in a given enterprise, enabling each individual mission to select an appropriate set of options when implementing the CCSDS recommendations for space data system standards.