TM Space Data Link Protocol

CCSDS 132.0-B-3 · Issue 3, October 2021

A TM Transfer Frame is a 6-octet Primary Header, an optional Secondary Header of up to 64 octets, the Data Field, and an optional Trailer (OCF, FECF). With SDLS (§ 6.3, CCSDS 355.0-B-2) a Security Header and optional Security Trailer surround the Data Field. The Trailer is located from the end of the frame, which is why the Frame Length matters.

Open the interactive diagram, Frame Builder and Frame Decoder

Transfer Frame Primary HeaderPH

BITS 0–47 · 6 OCTETS · MANDATORY · § 4.1.2 · Open in the viewer

The mandatory six-field header of every TM Transfer Frame. It identifies the frame within its Master and Virtual Channel and describes how the Data Field is structured.

The format of the Transfer Frame Primary Header is shown in figure 4-2 of the Standard.

Master Channel IdentifierMCID

BITS 0–11 · 12 BITS · MANDATORY · § 4.1.2.2 · Open in the viewer

Identifies the Master Channel: the concatenation of the Transfer Frame Version Number and the Spacecraft Identifier. All frames with the same MCID on a Physical Channel belong to one Master Channel.

Transfer Frame Version NumberTFVN

BITS 0–1 · 2 BITS · MANDATORY · § 4.1.2.2.2 · Open in the viewer

Identifies the data unit as a TM Version 1 Synchronous Transfer Frame. Always set to ‘00’ — the only version defined by the Standard.

Value	Meaning	Clause
`‘00’`	TM Version 1 Synchronous Transfer Frame — the only version defined by this Standard	§ 4.1.2.2.2 NOTE 1

Although they have the same version number, TC Transfer Frames and TM Transfer Frames are distinguishable by the Attached Sync Marker (reference [3]) or the Start Sequence (reference [C8]).

Spacecraft IdentifierSCID

BITS 2–11 · 10 BITS · MANDATORY · § 4.1.2.2.3 · Open in the viewer

Identifies the spacecraft associated with the data contained in the frame. Assigned by SANA and static throughout all Mission Phases.

The Space Assigned Numbers Authority (SANA) assigns Spacecraft Identifiers according to the procedures in reference [7]. SCIDs are uniquely assigned within the frequency band in which the spacecraft operates.

Virtual Channel IdentifierVCID

BITS 12–14 · 3 BITS · MANDATORY · § 4.1.2.3 · Open in the viewer

Identifies the Virtual Channel — up to eight Virtual Channels can share one Master Channel.

The Virtual Channel Identifier provides the identification of the Virtual Channel.

There are no restrictions on the selection of Virtual Channel Identifiers. In particular, Virtual Channels are not required to be numbered consecutively.

Operational Control Field FlagOCFF

BIT 15 · 1 BIT · MANDATORY · § 4.1.2.4 · Open in the viewer

Signals the presence or absence of the Operational Control Field in the frame trailer. Static within the associated Master or Virtual Channel for a Mission Phase.

Value	Meaning	Clause
`‘1’`	Operational Control Field present	§ 4.1.2.4.2
`‘0’`	Operational Control Field not present	§ 4.1.2.4.2

Master Channel Frame CountMCFC

BITS 16–23 · 8 BITS · MANDATORY · § 4.1.2.5 · Open in the viewer

Running modulo-256 count of every Transfer Frame transmitted on the Master Channel; provides continuity checking across all Virtual Channels of the spacecraft.

If the Master Channel Frame Count is re-set because of an unavoidable re-initialization, the completeness of a sequence of Transfer Frames in the related Master Channel cannot be determined.

Virtual Channel Frame CountVCFC

BITS 24–31 · 8 BITS · MANDATORY · § 4.1.2.6 · Open in the viewer

Running modulo-256 count of every Transfer Frame transmitted on the Virtual Channel; the key input for systematic Packet extraction at the receiving end.

The purpose of this field is to provide individual accountability for each Virtual Channel, primarily to enable systematic Packet extraction from the Transfer Frame Data Field.

Transfer Frame Data Field StatusDFS

BITS 32–47 · 16 BITS · MANDATORY · § 4.1.2.7 · Open in the viewer

Five sub-fields that describe how the Data Field is structured: the Secondary Header Flag, Synchronization Flag, Packet Order Flag, Segment Length Identifier and First Header Pointer.

The format of the Transfer Frame Data Field Status is shown in figure 4-3 of the Standard.

Transfer Frame Secondary Header FlagSHF

BIT 32 · 1 BIT · MANDATORY · § 4.1.2.7.2 · Open in the viewer

Signals the presence or absence of the Transfer Frame Secondary Header. Static within the associated Master or Virtual Channel for a Mission Phase.

Value	Meaning	Clause
`‘1’`	Secondary Header present	§ 4.1.2.7.2.2
`‘0’`	Secondary Header not present	§ 4.1.2.7.2.2

The Transfer Frame Secondary Header Flag shall be static within the associated Master or Virtual Channel throughout a Mission Phase (4.1.2.7.2.3).

Synchronization FlagSYNC

BIT 33 · 1 BIT · MANDATORY · § 4.1.2.7.3 · Open in the viewer

Signals the type of data inserted into the Data Field: octet-synchronized, forward-ordered Packets or Idle Data (‘0’), or a VCA_SDU (‘1’).

Value	Meaning	Clause
`‘0’`	Octet-synchronized, forward-ordered Packets or Idle Data in the Data Field	§ 4.1.2.7.3.2
`‘1’`	A VCA_SDU (Virtual Channel Access service data unit) in the Data Field	§ 4.1.2.7.3.2

Packet Order FlagPOF

BIT 34 · 1 BIT · MANDATORY · § 4.1.2.7.4 · Open in the viewer

Reserved bit. Set to ‘0’ when the Synchronization Flag is ‘0’; undefined when the Synchronization Flag is ‘1’.

Value	Meaning	Clause
`‘0’`	Reserved for future use by the CCSDS (when Synchronization Flag = ‘0’)	§ 4.1.2.7.4 NOTE

If the Synchronization Flag is set to ‘0’, the Packet Order Flag is reserved for future use by the CCSDS and is set to ‘0’. If the Synchronization Flag is set to ‘1’, the use of the Packet Order Flag is undefined.

Segment Length IdentifierSLID

BITS 35–36 · 2 BITS · MANDATORY · § 4.1.2.7.5 · Open in the viewer

Legacy field kept from earlier versions of the Standard (Source Packet Segments are no longer defined). Set to ‘11’ when the Synchronization Flag is ‘0’.

Value	Meaning	Clause
`‘11’`	Denotes non-use of Source Packet Segments (mandatory value when Sync Flag = ‘0’)	§ 4.1.2.7.5.2

This Identifier was required for earlier versions of this Recommended Standard to allow for the use of Source Packet Segments, which are no longer defined.

If the Synchronization Flag is set to ‘1’, then the Segment Length Identifier is undefined.

First Header PointerFHP

BITS 37–47 · 11 BITS · MANDATORY · § 4.1.2.7.6 · Open in the viewer

Points to the first octet of the first Packet that starts in the Data Field, enabling delimiting of variable-length Packets. Two reserved values signal ‘no Packet starts here’ and ‘Only Idle Data’.

Value	Meaning	Clause
`‘11111111111’`	No Packet starts in the Transfer Frame Data Field (e.g. a long Packet spans the whole frame)	§ 4.1.2.7.6.4
`‘11111111110’`	Only Idle Data in the Data Field — an OID Transfer Frame	§ 4.1.2.7.6.5

If the last Packet of frame N spills over into frame M of the same Virtual Channel, the First Header Pointer in frame M ignores the residue of the split Packet and indicates the start of the next Packet that starts in frame M.

If the Synchronization Flag is set to ‘1’, the First Header Pointer is undefined.

Transfer Frame Secondary HeaderTFSH

UP TO 64 OCTETS · OPTIONAL · § 4.1.3 · Open in the viewer

Optional fixed-length extension for mission-specific data transferred synchronously with a Master or Virtual Channel. Its presence is signaled by the Secondary Header Flag in the Primary Header.

If present, this field occurs within every Transfer Frame transmitted through the associated Master or Virtual Channel throughout a Mission Phase (4.1.3.1.5).

Secondary Header Identification Field

SH BITS 0–7 · 1 OCTET · MANDATORY WITHIN SH · § 4.1.3.2 · Open in the viewer

The first octet of the Secondary Header: a 2-bit version number followed by a 6-bit length field.

Secondary Header Version NumberSHVN

SH BITS 0–1 · 2 BITS · MANDATORY WITHIN SH · § 4.1.3.2.2 · Open in the viewer

Indicates which of up to four Secondary Header versions is used; only Version 1 (‘00’) is defined.

Value	Meaning	Clause
`‘00’`	Version 1 — the only Secondary Header version recognized by this Standard	§ 4.1.3.2.2.2 NOTE

Secondary Header LengthSHLEN

SH BITS 2–7 · 6 BITS · MANDATORY WITHIN SH · § 4.1.3.2.3 · Open in the viewer

The total length of the Secondary Header in octets, minus one, binary encoded. Static within the associated channel for a Mission Phase.

Value	Meaning	Clause
`VALUE = LENGTH − 1`	e.g. a 12-octet Secondary Header carries the value 11 (‘001011’)	§ 4.1.3.2.3.2

When a Secondary Header is present, this length may be used to compute the location of the start of the field following the Secondary Header.

Secondary Header Data FieldSHDF

1–63 OCTETS · MANDATORY WITHIN SH · § 4.1.3.3 · Open in the viewer

Carries the mission-specific Secondary Header data (FSH_SDUs supplied through the MC_FSH or VC_FSH service). Fixed length within the associated channel.

Transfer Frame Data FieldDF

VARIES · MANDATORY · § 4.1.4 · Open in the viewer

Carries the mission data: octet-synchronized Packets, one VCA_SDU, or Idle Data. Its length equals the fixed frame length minus the headers and trailer present.

Value	Meaning	Clause
`FHP = ‘11111111110’`	OID Transfer Frame — the Data Field is filled with the mandatory Pseudo-Noise idle pattern	§ 4.1.4.6
`D⁰+D¹+D²+D²²+D³²`	Polynomial of the 32-cell LFSR that generates the PN idle sequence (annex D)	§ 4.1.4.6.2
`FF FF FF FF 6D B6 D8 61 45 1F`	First 10 bytes of the OID data pattern, in hexadecimal	§ 4.1.4.6.2 NOTE

The first and last Packets of the Data Field are not necessarily complete: the first may be a continuation from the previous frame, and the last may continue in the subsequent frame of the same Virtual Channel.

Operational Control FieldOCF

4 OCTETS · OPTIONAL · § 4.1.5 · Open in the viewer

Standardized real-time reporting slot in the frame trailer. Carries a Type-1 Report (the COP-1 Communications Link Control Word) or a Type-2 Report (project-specific or an SDLS Frame Security Report).

Value	Meaning	Clause
`BIT 0 = ‘0’`	Type-1 Report — Communications Link Control Word (COP-1, reference [C6])	§ 4.1.5.4
`BIT 0 = ‘1’`	Type-2 Report	§ 4.1.5.4
`BIT 1 = ‘0’`	Type-2 Report contents are project-specific	§ 4.1.5.5
`BIT 1 = ‘1’`	Type-2 Report contains an SDLS Frame Security Report (reference [11])	§ 4.1.5.5

The Type Flag may vary between Transfer Frames on the same Master or Virtual Channel that carries this field.

VCs carrying OCFs must be transmitted frequently enough not to disrupt the COP in use, which can time out if OCFs are not delivered in a timely fashion.

Frame Error Control FieldFECF

2 OCTETS · OPTIONAL · § 4.1.6 · Open in the viewer

A 16-bit CRC computed over the whole frame, for detecting errors introduced during transmission and data handling. If used, it is present in every frame of the Physical Channel.

Value	Meaning	Clause
`G(X) = X¹⁶ + X¹² + X⁵ + 1`	Generating polynomial of the CRC	§ 4.1.6.2.2
`L(X) = X¹⁵ + X¹⁴ + … + X + 1`	Presetting polynomial — the shift register is preset to the all-‘1’ state before encoding	§ 4.1.6.2.2

At the receiving end the syndrome S(X) is zero if no error is detected and non-zero if an error is detected (4.1.6.3).

This field may be mandatory depending on the selected options of the underlying Channel Coding Sublayer.

Rules

Frame length is constant for a Physical Channel during a Mission Phase. § 4.1.1.2
Data Field length = frame − Primary and Secondary Headers − Trailer. § 4.1.4.2
Packets are contiguous and in forward order; the first and last may be split across frames. § 4.1.4.5
FHP skips the residue of a split Packet, and points to the next one that starts. § 4.1.2.7.6.3
With SDLS: Security Header follows the Secondary Header; Security Trailer precedes the OCF. § 6.3.1
An OID frame identifies a Virtual Channel that does not use SDLS. § 6.4.6.2