Space Data Link Protocol

[Hollie Kipps]

The background to the question is we are working on an implementation of the Yamcs Mission Control System which will use the CCSDS COP-1 protocol. It is intended that the spacecraft will utilise the LibreSpace Open Space Data Link Protocol (which implements COP-1), but whilst we are waiting for the spacecraft implementation to be developed, we were hoping to use the LibreSpace osdlp-operator CLI interface to test the ground system. The version of the CLI interface with the ground side FOP configuration seems to be a nice facility with some built in TCs on the ground side which allows a few permutations using COP-1 to be quickly implemented and tested. Our idea though would be to start an instance of osdlp-operator with the FARM configuration as an emulator for the spacecraft, and send it some TCs from Yamcs, purely just to test that Yamcs and the link handle CCSDS COP-1 correctly.

Are we missing something in the approach, or should we work ourselves on expanding the osdlp-operator FARM implementation to allow data to be sent? The FOP implementation seems to already expect scenarios where data is returned in the response to the TC.

As i understand it you are trying to run locally two instances of the OSDLP one for the FOP and one for the FARM. Unfortunately the FARM implementation for the local execution scenario is very basic. As you said, the only thing it does is to respond with and idle FDU every time it receives a packet as an acknowledgment. Essentially you would have to implement your own functionality and call the osdlp_tm_transmit according to the commands you are sending to it from FOP, based on the needs of your mission. An example of this you can find here Core/Src/telemetry.c master librespacefoundation / Qubik / COMMS Software GitLab. This is the code for the telemetry part of the QUBIK mission. You will find a transmit_tm function which basically does for the satellite what you want to do locally in the FARM instance. But this is always implementation specific. You would also have to populate the farm_configuration and fop_configuration files with the parameters of your mission.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

If you are interested in satellite communications, you may have heard of the CCSDS Space Data Link Protocol (SDLP). This is a standard protocol developed by the Consultative Committee for Space Data Systems (CCSDS), an international organization that defines and promotes interoperability and efficiency for space data systems. The SDLP is a key component of the CCSDS Space Data Link Services (SDLS), which provide reliable and secure data transfer between spacecraft and ground stations. In this article, you will learn about the main features and benefits of the SDLP, and how it supports various types of space missions and applications.

The SDLP is a protocol that operates at the data link layer of the OSI model, which is responsible for framing, encoding, error detection, and error correction of data packets. The SDLP defines two types of data link protocols: the Telemetry (TM) Space Data Link Protocol and the Telecommand (TC) Space Data Link Protocol. The TM protocol is used for transmitting data from spacecraft to ground stations, while the TC protocol is used for sending commands and control signals from ground stations to spacecraft. The SDLP also defines a common part that applies to both TM and TC protocols, such as the frame structure, the synchronization and channel coding schemes, and the transfer frame version number.

The SDLP uses a fixed-length frame structure for both TM and TC protocols, with a size of 256, 512, 1024, or 2048 octets. Each frame consists of four main fields: the transfer frame primary header, the data field, the operational control field, and the frame error control field. The transfer frame primary header contains information such as the spacecraft identifier, the virtual channel identifier, the frame sequence number, and the frame version number. The data field carries the user data or the command packets, which are segmented and encapsulated according to the CCSDS Packet Telemetry and Packet Telecommand standards. The operational control field contains optional fields such as the secondary header, the synchronization marker, the insert zone, and the security header and trailer. The frame error control field contains a cyclic redundancy check (CRC) code for detecting and correcting errors.

The SDLP provides two methods for synchronizing and encoding the frames: the Attached Synchronization Marker (ASM) method and the Channel Access Data Unit (CADU) method. The ASM method uses a predefined bit pattern to mark the beginning of each frame, and applies convolutional encoding and interleaving to the frames to improve error correction. The CADU method uses a pseudo-noise (PN) sequence to modulate the frames, and applies Reed-Solomon (RS) encoding and interleaving to the frames to enhance error detection. The SDLP allows the use of either method or a combination of both, depending on the mission requirements and the channel characteristics.

The SDLP defines three versions of the transfer frame format: version 1, version 2, and version AOS. Version 1 is the original format that supports only the ASM method and has a fixed frame size of 1024 octets. Version 2 is an enhanced format that supports both the ASM and CADU methods and has variable frame sizes. Version AOS is a special format that is compatible with the Advanced Orbiting Systems (AOS) Space Data Link Protocol, which is another CCSDS standard for complex and high-performance spacecraft. The SDLP uses a two-bit field in the transfer frame primary header to indicate the version number, and allows the coexistence of different versions on the same link.

The SDLP offers several advantages for space data systems, including interoperability and compatibility among different spacecraft and ground stations, improved reliability and security of data transmission, optimized use of bandwidth and power resources, and support for various types of space missions and applications. This is accomplished by following a common standard, using robust synchronization and channel coding schemes, allowing variable frame sizes and different modulation techniques, supporting optional security features such as encryption and authentication, and providing different levels of service quality and functionality.

Yamcs supports to a certain extent all three of them. The main support is around the "packet service" - that is describing how the telemetry packets are extracted from the frames. The implementation is however generic enough (hopefully) such that it is possible to add additional functionality for processing non-packet data (e.g. sending video to external application).

The packets are inserted into frames which are sent as part of Virtual Channels (VC). The VCs can have different priority on-board, for example one VC can be used to transport low volume HK data, while another one to transport high volume science data.

Note that The USLP frames (as well as the TC frames used for commanding) support a second level of multiplexing called Multiplexer Access Point (MAP) which allows multiplexing data inside a VC. The MAP service is not supported by Yamcs.

Currently the built-in way to receive frame data inside Yamcs is by using the UdpTmFrameLink data link. The yamcs-sle project provides an implementation of the Space Link Extension (SLE) which allows receiving frame data from SLE-enabled Ground Stations (such as those from NASA Deep Space Network or ESA ESTRACK). The options described below are valid for both link types.

Decodes raw frame data using an error correction scheme and/or randomization. For the moment only the Reed-Solomon codec is supported. If this is not set, the frames are considered already decoded. See below for the options to the Reed-Solomon codec.

Required. One of AOS, TM or USLP. The first 2 bits for AOS/TM and 4 bits for USLP represent the version number and have to have the value 0, 1 or 12 respectively. If a frame is received that has a different version, it is discarded (with a warning log message).

Required. The expected spacecraft identifier. The spacecraftId is encoded in the frame header. If a frame with a different identifier is received, it is discarded (with a warning log message).

The expected frame length. This parameter is mandatory for AOS and TM frames and optional for USLP frames which can have variable length. If a frame is received that does not have this length, it is discarded (with a warning log message).For USLP frames, if this parameter is specified, the following two are ignored; Yamcs will use maxFrameLength = minFrameLength = frameLength.

Used only for AOS frames to specify the presence/absence of the 2 bytes Frame Header Error Control. This can be used to detect and correct errors in parts of the AOS frame headers using a Reed-Solomon (10,6) code.

The AOS and USLP frames can optionally use an Insert Service to transfer fixed-length data synchronized with the release of the frames. The insert data follows immediately the frame primary header. If the Insert Service is used, this parameter specifies the length of the insert data. If not used, please set it to 0 (default). For TM frames this parameter is ignored.Currently Yamcs ignores any data in the insert zone.

One of NONE, CRC16 or CRC32. Specifies the error detection scheme used. TM and AOS frames support either NONE or CRC16 while USLP supports NONE, CRC16 or CRC32. If present, the last 2 respectively 4 bytes of the frame will contain an error control field. If the CRC does not match the computation, the frame will be discarded (with a warning message).

Can be used to specify the name of the stream where the Command Link Control Words (CLCW) will be sent. The CLCW is the mechanism used by COP-1 to acknowledge uplinked frames. For TM and USLP frames, there is an OCF flag part of the frame header indicating the presence or not of the CLCW. For AOS frames it has to be configured with the ocfPresent flag below.If present, the CLCW is also extracted from idle frames (i.e. frames that are inserted when no data needs to be transmitted in order to keep the constant bitrate required for downlink).

c80f0f1006