Browse the glossary using this index

Special | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ALL
Picture of Yee Wei Law

Space Packet Protocol (SPP)

by Yee Wei Law - Saturday, 27 May 2023, 3:51 PM
 

Introduction

In many space applications, it is desirable to have a single, common application-layer data structure for the creation, storage, and transport of variable-length application-layer data.

These data is expected to be 1️⃣ exchanged and stored on board, 2️⃣ transferred over one or more space data links, and 3️⃣ used within ground systems.

It is often necessary to identify the 1️⃣ type, 2️⃣ source, and/or 3️⃣ destination of these data.

The preceding needs motivate the definition of the Space Packet Protocol (SPP).

The SPP is designed as a self-delimited carrier of a data unit — called a Space Packet — that contains an application process identifier (APID) used to identify the data contents, data source, and/or data user within a given enterprise [CCS20d, Sec. 2.1.1].

Fig. 1 shows where the SPP sits in the CCSDS protocol stack.

Fig. 2 shows a communication scenario between a spacecraft and a ground terminal, where the SPP plays an important role.

Fig. 1: The SPP sits above the data link layer and below the upper layers in the CCSDS protocol stack [CCS20d, Figure 2-1], where CLA = convergence layer adapter.

Fig. 2: A sample communication scenario [CCS20a, Figure 9-12], featuring mission operations (MO) applications residing in the spacecraft’s onboard computer (OBC).

All OBC apps are under the control of a real-time operating system (RTOS); with the striped blocks running in hard real time.

Science operations (SO) functions are executed through Message Transfer Service, File and Packet Store Services, etc.

The yellow blocks represent the spacecraft onboard interface services (SOIS), and the SPP is one of these services.

Between the SPP and the MO applications sits the Message Abstraction Layer (MAL) [CCS13a], an important component of CCSDS’s Missions Operations Framework.

For applications on separate onboard computers, communications pass through the whole stack and use the physical subnetwork to communicate.

For applications on the same computer, communications pass through the stack to a local loopback function in the software bus.

APID

APIDs are unique in a single naming domain [CCS20d, Sec. 2.1.3]

An APID naming domain usually corresponds to a spacecraft, or an element of a constellation of space vehicles.

Every space project allocates the APIDs to be used in a naming domain.

More precisely, the space project assigns APIDs to managed data paths within a naming domain.

Open-source implementations

The following open-source implementations are known at the time of writing:

References

[CCS13a] CCSDS, Mission Operations Message Abstraction Layer, Recommended Standard CCSDS, The Consultative Committee for Space Data Systems, March 2013. Available at https://public.ccsds.org/Pubs/521x0b2e1.pdf.
[CCS20a] CCSDS, Application and Support Layer Architecture, Informational Report CCSDS 371.0-G-1, The Consultative Committee for Space Data Systems, November 2020. Available at https://public.ccsds.org/Pubs/371x0g1.pdf.
[CCS20d] CCSDS, Space Packet Protocol, Recommended Standard CCSDS 133.0-B-2, The Consultative Committee for Space Data Systems, June 2020. Available at https://public.ccsds.org/Pubs/133x0b2e1.pdf.