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
Space Packet Protocol (SPP) | ||||||||
---|---|---|---|---|---|---|---|---|
IntroductionIn 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. APIDAPIDs 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 implementationsThe following open-source implementations are known at the time of writing:
References
| ||||||||