Space Packet Protocol

CCSDS 133.0-B-2 · Issue 2, June 2020 · EC 1 October 2020 · EC 2 September 2024

A Space Packet is a 6-octet Primary Header followed by a Packet Data Field of 1 to 65536 octets (7 to 65542 octets in total). The Packet Secondary Header has no structure defined by the Standard; its split into Time Code and Ancillary Data Fields comes from the mission settings.

Open the interactive diagram, Frame Builder and Frame Decoder

Packet Primary HeaderPH

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

The mandatory six-octet header of every Space Packet: version number, identification, sequence control and data length.

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

Packet Version NumberPVN

BITS 0–2 · 3 BITS · MANDATORY · § 4.1.3.2 · Open in the viewer

Identifies the data unit as a Version 1 CCSDS Packet. Always set to ‘000’.

Value	Meaning	Clause
`‘000’`	Version 1 CCSDS Packet — the only version defined by this Standard	§ 4.1.3.2.2 NOTE

The Version Number is used to reserve the possibility of introducing other packet structures.

Packet Identification Field

BITS 3–15 · 13 BITS · MANDATORY · § 4.1.3.3 · Open in the viewer

Identifies the packet: its type (TM/TC), the presence of a Secondary Header, and the APID naming the managed data path.

Packet TypeTYPE

BIT 3 · 1 BIT · MANDATORY · § 4.1.3.3.2 · Open in the viewer

Distinguishes telemetry (reporting) Packets from telecommand (requesting) Packets.

Value	Meaning	Clause
`‘0’`	Telemetry (reporting) Packet	§ 4.1.3.3.2.3
`‘1’`	Telecommand (requesting) Packet	§ 4.1.3.3.2.3

The exact definition of ‘telemetry Packets’ and ‘telecommand Packets’ needs to be established by the project that uses this protocol.

Secondary Header FlagSHF

BIT 4 · 1 BIT · MANDATORY · § 4.1.3.3.3 · Open in the viewer

Indicates the presence or absence of the Packet Secondary Header within this Space Packet. Static per APID throughout a Mission Phase.

Value	Meaning	Clause
`‘1’`	Packet Secondary Header present	§ 4.1.3.3.3.2
`‘0’`	Packet Secondary Header not present — mandatory value for Idle Packets	§ 4.1.3.3.3.2 / .4

Application Process IdentifierAPID

BITS 5–15 · 11 BITS · MANDATORY · § 4.1.3.3.4 · Open in the viewer

The naming mechanism for the managed data path; may uniquely identify the sending or receiving application process within a space vehicle.

Value	Meaning	Clause
`‘11111111111’`	Idle Packet — the only APID value reserved by the CCSDS	§ 4.1.3.3.4.4

The APID is unique only within its naming domain (see 2.1.1 and 2.1.3).

There are no other restrictions on the selection of APIDs; they are not required to be numbered consecutively.

Packet Sequence Control Field

BITS 16–31 · 16 BITS · MANDATORY · § 4.1.3.4 · Open in the viewer

Sequence Flags plus the Packet Sequence Count or Packet Name — orders the Packets generated by one APID.

Sequence FlagsSEQF

BITS 16–17 · 2 BITS · MANDATORY · § 4.1.3.4.2 · Open in the viewer

May indicate that the User Data in this Packet is a segment of a larger set of application data.

Value	Meaning	Clause
`‘00’`	Continuation segment of User Data	§ 4.1.3.4.2.2 a)
`‘01’`	First segment of User Data	§ 4.1.3.4.2.2 b)
`‘10’`	Last segment of User Data	§ 4.1.3.4.2.2 c)
`‘11’`	Unsegmented User Data — mandatory whenever the Octet String service is invoked	§ 4.1.3.4.2.2 d) / .3

The use of the Sequence Flags is not mandatory for the users of the SPP.

Packet Sequence Count or Packet NamePSC

BITS 18–31 · 14 BITS · MANDATORY · § 4.1.3.4.3 · Open in the viewer

For telemetry Packets: a continuous modulo-16384 count per APID. For telecommand Packets: either the count or a free-form 14-bit Packet Name.

Value	Meaning	Clause
`MODULO-16384`	Count range 0–16383; for Type ‘1’ (telecommand) Packets the field may instead hold a Packet Name — any 14-bit binary pattern	§ 4.1.3.4.3

The purpose of the Packet Sequence Count is to order the Packets generated by the same user application, even though their order may be disturbed during transport, and to support the detection of missing packets.

The Packet Name allows a particular Packet to be identified with respect to others occurring within the same communications session.

Packet Data LengthPDL

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

A length count C equal to one fewer than the length in octets of the Packet Data Field.

Value	Meaning	Clause
`C = DATA FIELD OCTETS − 1`	Encoded length count — Data Field range 1 to 65536 octets	§ 4.1.3.5.3

Packet Data FieldPDF

1 TO 65536 OCTETS · MANDATORY · § 4.1.4 · Open in the viewer

Carries the packet content: an optional Packet Secondary Header followed by the User Data Field — at least one of the two must be present.

Packet Secondary HeaderPSH

VARIABLE · OPTIONAL · § 4.1.4.2 · Open in the viewer

A mission-specific means for consistently placing ancillary data (time, position/attitude, format info) in the same location within a Space Packet: a Time Code Field, an Ancillary Data Field, or both.

The Packet Secondary Header is not allowed for Idle Packets.

Secondary Header types are registered with SANA (reference [5]); the actual contents are managed at the SPP service user interface.

The chosen option shall remain static for a specific managed data path throughout all Mission Phases (4.1.4.2.1.6).

Time Code FieldTCF

VARIABLE · OPTIONAL · § 4.1.4.2.2 · Open in the viewer

One of the CCSDS segmented or unsegmented binary time codes (reference [3]): an optional P-Field (preamble) plus the mandatory T-Field.

Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code; characteristics include ambiguity period, epoch, length, and resolution.

Ancillary Data FieldADF

VARIABLE · OPTIONAL · § 4.1.4.2.3 · Open in the viewer

Mission-defined ancillary information: data needed to interpret the User Data Field, mission-specific header fields, or an extension of the APID naming domain.

The content and format of the data contained in the Ancillary Data Field are not specified in this Recommended Standard.

User Data FieldUDF

VARIABLE · MANDATORY IF NO SEC. HDR · § 4.1.4.3 · Open in the viewer

The application data supplied by the sending user — or Idle Data in an Idle Packet.

The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard.

Rules

A Packet is 7 to 65542 octets: 6 of header, then a Packet Data Field of 1 to 65536. § 4.1.2.2
The Packet Data Field holds at least one octet. § 4.1.4.1.2
The Secondary Header is mandatory if there is no User Data Field. § 4.1.4.2.1.2
The User Data Field is mandatory if there is no Secondary Header. § 4.1.4.3.2
Secondary Header contents are not in the packet: they are set per APID, by management. § 4.1.4.2.1.4
A Secondary Header is a Time Code Field, an Ancillary Data Field, or both, in that order. § 4.1.4.2.1.5
The time code’s P-field, if used, is fixed for the data path. § 4.1.4.2.2.5