CCSDS Space Communication Protocols

CCSDS standards ensure interoperability in space communications, defining three main protocols:

Space Packet Protocol (SPP): Structures and transports space data.
Telecommand (TC) Protocol: Sends commands from ground to a satellite.
Telemetry (TM) Protocol: Returns satellite telemetry to the ground.

Space Packet Protocol (SPP)

SPP (CCSDS 133.0-B-2) structures and transports data in “space packets.”

SPP Packet Structure

A Space Packet shall include the defined fields, positioned contiguously, in the following sequence: 1. Packet Primary Header (6 octets, mandatory); 2. Packet Data Field (from 1 to 65536 octets, mandatory).

A Space Packet shall consist of at least 7 and at most 65542 octets.

Key Features

Application Identification: Uses the APID (Application Process Identifier) field.
Data Flexibility: Variable packet sizes for adaptability.
Layer Independence: Compatible with various link protocols.

Packet primary header

The Packet Primary Header is mandatory and shall consist of four fields, positioned contiguously, in the following sequence:

Packet Version Number (3 bits, mandatory);
Packet Identification Field (13 bits, mandatory);
Packet Sequence Control Field (16 bits, mandatory);
Packet Data Length (16 bits, mandatory).

Packet secondary header

The purpose of the Packet Secondary Header is to allow (but not require) a mission-specific means for consistently placing ancillary data (time, internal data field format,spacecraft position/attitude, etc.) in the same location within a Space Packet. Theformat of the secondary header, if present, is managed and mission specific.
Secondary Header types are registered with SANA (reference [5]), and the actualcontents of the secondary header are ‘managed’ at the SPP service user interface. The service user of the SPP Packet Service provides the SPP service provider with a predefined space packet in the PACKET.request, while the service user of the SPP Octet String Service provides the SPP service provider with a predefined space

SPP over CAN-TS

When communicating between the ground and the OBC, the packets flow on the CAN bus with CAN-TS protocol and also on and of radio frequency through the intermediary of a radio. Essentially, the packet remains untouched except for the primary header. When the radio receives a TC from the ground, it will send fragment it into 8 byte CAN packets. The first packet to be transmitted onto the bus is the Primary header of the SPP packet which needs to be acknowledged by the OBC in order for it to send the rest of the datafield. The primary header gets two modifications done to it: 1. The addition of a 1 byte “prefix” byte (always 0x01) - the 6 byte header - a 7 bit counter - a 1 bit “first” flag 2. To mitigate all possible confusion between CAN-TS packets and SPP packets, the primary header sends the bytes in reverse order. This is also applied for the TM. For the Radio to understand its an SPP packet, the OBC needs to send the primary header in reverse order.

The rest of the datafield remains untouched.

TC transfert frame

A TC Transfer Frame shall encompass the major fields, positioned contiguously, in the following sequence:

Transfer Frame Header (5 octets, mandatory);
Transfer Frame Data Field (up to 1019 or 1017 octets, mandatory);
Frame Error Control Field (2 octets, optional).

NOTES :

The TC Transfer Frame is the protocol data unit transmitted from the sending end tothe receiving end by the TC Space Data Link Protocol. In this Recommended Standard, the TC Transfer Frame is also called the Transfer Frame or Frame for simplicity.
The maximum Transfer Frame length allowed by a particular spacecraft or ground implementation on a particular Virtual Channel may be less than the maximum specified here.
The structural components of the TC Transfer Frame are shown in figure.

Tranfer frame primary header

The Transfer Frame Primary Header is mandatory and shall consist of eight fields, positioned contiguously, in the following sequence:

Transfer Frame Version Number (2 bits, mandatory);
Bypass Flag (1 bit, mandatory);
Control Command Flag (1 bit, mandatory);
Reserved Spare (2 bits, mandatory);
Spacecraft Identifier (10 bits, mandatory);
Virtual Channel Identifier (6 bits, mandatory);
Frame Length (10 bits, mandatory);
Frame Sequence Number (8 bits, mandatory).
NOTE – The format of the Transfer Frame Primary Header is shown in figure.

TM transfert frame

A TM Transfer Frame shall encompass the major fields, positioned contiguously, in the following sequence:

Transfer Frame Primary Header (6 octets, mandatory);
Transfer Frame Secondary Header (up to 64 octets, optional);
Transfer Frame Data Field (integral number of octets, mandatory);
Operational Control Field (4 octets, optional);
Frame Error Control Field (2 octets, optional).

Transfer frame primary header

The Transfer Frame Primary Header is mandatory and shall consist of six fields, positioned contiguously, in the following sequence:

Master Channel Identifier (12 bits, mandatory);
Virtual Channel Identifier (3 bits, mandatory);
Operational Control Field Flag (1 bit, mandatory);
Master Channel Frame Count (1 octet, mandatory);
Virtual Channel Frame Count (1 octet, mandatory);
Transfer Frame Data Field Status (2 octets, mandatory).

Transfer frame data field status

Bits 32–47 of the Transfer Frame Primary Header shall contain the Transfer Frame Data Field Status.

This 16-bit field shall be sub-divided into five sub-fields, as follows:

Transfer Frame Secondary Header Flag (1 bit, mandatory);
Synchronization Flag (1 bit, mandatory);
Packet Order Flag (1 bit, mandatory);
Segment Length Identifier (2 bits, mandatory);
First Header Pointer (11 bits, mandatory).

Transfer frame secondary header

If present, the Transfer Frame Secondary Header shall follow, without gap, the Transfer Frame Primary Header.

The Transfer Frame Secondary Header shall consist of an integral number of octets as follows:

Transfer Frame Secondary Header Identification Field (1 octet, mandatory);
Transfer Frame Secondary Header Data Field (1 to 63 octets, mandatory).

Protocol Comparison

Protocol	OSI Layer	Main Function	Security
SPP	Application	Transports data as packets	N/A
TC	Data Link	Sends commands	SDLS Support
TM	Data Link	Sends telemetry	SDLS Support

Conclusion

Both CAN-TS and CANopen have crucial roles in embedded systems, each suited for specific applications: CAN-TS for memory-limited aerospace applications, CANopen for complex industrial systems.