Report Concerning Space Data System Standards

SPACE PACKET
PROTOCOLS

INFORMATIONAL REPORT

CCSDS 130.3-G-1

GREEN BOOK
April 2023
Report Concerning Space Data System Standards

SPACE PACKET
PROTOCOLS

INFORMATIONAL REPORT

CCSDS 130.3-G-1

GREEN BOOK
April 2023
 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

AUTHORITY

Issue: Informational Report, Issue 1

Date: April 2023
Location: Washington, DC, USA

This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and reflects the consensus of
technical panel experts from CCSDS Member Agencies. The procedure for review and
authorization of CCSDS Reports is detailed in Organization and Processes for the
Consultative Committee for Space Data Systems (CCSDS A02.1-Y-4).

This document is published and maintained by:

CCSDS Secretariat
National Aeronautics and Space Administration
Washington, DC, USA
Email: [email protected]

CCSDS 130.3-G-1 Page i April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Report is therefore subject to CCSDS
document management and change control procedures, which are defined in Organization
and Processes for the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-4).
Current versions of CCSDS documents are maintained at the CCSDS Web site:

http://www.ccsds.org/

Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the email address indicated on page i.

CCSDS 130.3-G-1 Page ii April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Science Policy Office (BELSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– China Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Hellenic Space Agency (HSA)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– Mohammed Bin Rashid Space Centre (MBRSC)/United Arab Emirates.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Netherlands Space Office (NSO)/The Netherlands.
– Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.

CCSDS 130.3-G-1 Page iii April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

DOCUMENT CONTROL

Document Title Date Status

CCSDS Space Packet Protocols, April 2023 Original issue

130.3-G-1 Informational Report, Issue 1

CCSDS 130.3-G-1 Page iv April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

CONTENTS
Section Page

1 INTRODUCTION .......................................................................................................... 1-1

1.1 PURPOSE ............................................................................................................... 1-1

1.2 SCOPE .................................................................................................................... 1-1
1.3 ORGANIZATION OF THIS REPORT .................................................................. 1-1
1.4 DEFINITIONS ........................................................................................................ 1-2
1.5 REFERENCES ........................................................................................................ 1-3

2 THE SPACE PACKET PROTOCOL FROM USERS’ PERSPECTIVE ................ 2-1

2.1 BASIC CONCEPTS OF SPACE PACKET PROTOCOL ..................................... 2-1

2.2 COMMON FEATURES OF SPP SERVICES........................................................ 2-4
2.3 BENEFITS OF THE SPACE PACKET PROTOCOL ........................................... 2-5
2.4 FEATURES OF THE SPACE PACKET PROTOCOL .......................................... 2-6
2.5 SPACE PACKET PROTOCOL NOMINAL EXAMPLE ...................................... 2-7

3 THE ENCAPSULATION PACKET PROTOCOL FROM USERS’

PERSPECTIVE .............................................................................................................. 3-1

3.1 BASIC CONCEPTS OF THE ENCAPSULATION PACKET PROTOCOL ........ 3-1

3.2 FEATURES OF THE ENCAPSULATION PACKET PROTOCOL ..................... 3-2
3.3 ADDRESSING ....................................................................................................... 3-3
3.4 PROTOCOL DESCRIPTION ................................................................................. 3-3
3.5 ENCAPSULATION PACKET PROTOCOL DEPLOYMENT EXAMPLE ......... 3-3

4 FREQUENTLY ASKED QUESTIONS ON THE CCSDS PACKET

PROTOCOLS ................................................................................................................. 4-1

ANNEX A ABBREVIATIONS AND ACRONYMS ........................................................ A-1

Figure

2-1 SPP Context within the CCSDS Protocol Stack ........................................................... 2-1
2-2 Configuration of User Applications (An Example) ...................................................... 2-7
3-1 Concept of Encapsulation Packet Protocol ................................................................... 3-1
3-2 Example Deployment of CFDP over the Encapsulation Packet Protocol..................... 3-4

CCSDS 130.3-G-1 Page v April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

1 INTRODUCTION
1.1 PURPOSE

This Report has been developed to present the concept and rationale of the CCSDS Packet
Protocols:
a) the CCSDS Recommended Standard for Space Packet Protocol (SPP) (reference [1]);
and
b) the CCSDS Recommended Standard for Encapsulation Packet Protocol (EPP)
(reference [2]).

It has specifically been prepared to serve the following purposes:

a) to provide an introductory overview on the concept of both the SPP and EPP;
b) to provide information on how these protocols should be applied by end users to
efficiently develop their mission systems (including onboard instruments and ground
support systems);
c) to provide information on how these protocols should be deployed in space data
systems to efficiently develop multi-mission infrastructures (including both onboard
and ground infrastructures);
d) to describe the key distinctions between these protocols, so that both end users and
developers are provided sufficient guidance in order to make the correct choice
between implementing one or both protocols.

1.2 SCOPE

The information contained in this Report is not part of the CCSDS Recommended Standard
for either the SPP (reference [1]) or the EPP (reference [2]). In the event of any conflict
between these Recommended Standards and the material presented herein, the
Recommended Standards shall prevail.

1.3 ORGANIZATION OF THIS REPORT

This document is divided into four numbered sections and an annex:

a) section 1 presents the purpose, scope, and organization of this Report and lists the
definitions and references used throughout the Report;
b) section 2 explains what the SPP is and how it may be applied by end users to transfer
either Application Layer data directly to the Data Link Layer or used as a ‘shim’ protocol
to enable the transfer of upper-layer Protocol Data Units (PDUs) to the Data Link Layer;

CCSDS 130.3-G-1 Page 1-1 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

c) section 3 explains what the EPP is and how it may be applied by end users as a ‘shim’
protocol to encapsulate and transfer higher-layer PDUs recognized by CCSDS to the
Data Link Layer;
d) section 4 presents several frequently asked questions concerning the SPP and the
EPP, along with the rationale for choosing one over the other or for using both;
e) annex A lists abbreviations and acronyms used within this document.

1.4 DEFINITIONS

The following definitions are used throughout this Report. Many other terms pertaining to
specific items are defined in the appropriate sections.

CCSDS packet protocols: CCSDS Space Packet Protocol and/or Encapsulation Packet
Protocol.

destination user application: A user application (see below) that receives application data
using the Space Packet Protocol.

Encapsulation Packet Protocol, EPP: A protocol, specified in reference [2], used to

encapsulate higher-layer PDUs recognized by CCSDS over applicable ground-to-space,
space-to-ground, or space-to-space communications links using Space Data Link Protocol
(SDLPs). It is not a Network Layer protocol.

node: A physical entity used as a unit in a system.

source user application: A user application (see below) that sends application data using
the Space Packet Protocol.

space link: A communications link between a spacecraft and its associated ground system or
between two spacecraft.

Space Packet Protocol, SPP: A protocol specified in reference [1], which has been
developed to transfer space application data from one user application to one or more user
applications or to be used as a ‘shim’ protocol between the upper layer CCSDS protocol
stack and the Space Data Link Layer protocols. It is not a Network Layer protocol.

Entity: A functional entity that performs all or a portion of the functions of the SPP or EPP.

Subnetwork: A local network that connects two or more SPP or EPP entities.

user application: A functional entity that sends or receives application data using the Space
Packet Protocol.

CCSDS 130.3-G-1 Page 1-2 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

1.5 REFERENCES

The following publications are referenced in this document. At the time of publication, the
editions indicated were valid. All publications are subject to revision, and users of this
document are encouraged to investigate the possibility of applying the most recent editions of
the publications indicated below. The CCSDS Secretariat maintains a register of currently
valid CCSDS publications.

[1] Space Packet Protocol. Issue 2. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.0-B-2. Washington, D.C.: CCSDS, June 2020.

[2] Encapsulation Packet Protocol. Issue 3. Recommendation for Space Data System
Standards (Blue Book), CCSDS 133.1-B-3. Washington, D.C.: CCSDS, May 2020.

[3] TM Space Data Link Protocol. Issue 3. Recommendation for Space Data System
Standards (Blue Book), CCSDS 132.0-B-3. Washington, D.C.: CCSDS, October 2021.

[4] TC Space Data Link Protocol. Issue 4. Recommendation for Space Data System
Standards (Blue Book), CCSDS 232.0-B-4. Washington, D.C.: CCSDS, October 2021.

[5] AOS Space Data Link Protocol. Issue 4. Recommendation for Space Data System
Standards (Blue Book), CCSDS 732.0-B-4. Washington, D.C.: CCSDS, October 2021.

[6] Proximity-1 Space Link Protocol—Data Link Layer. Issue 6. Recommendation for
Space Data System Standards (Blue Book), CCSDS 211.0-B-6. Washington, D.C.:
CCSDS, July 2020.

[7] Unified Space Data Link Protocol. Issue 2. Recommendation for Space Data System
Standards (Blue Book), CCSDS 732.1-B-2. Washington, D.C.: CCSDS, October 2021.

[8] CCSDS File Delivery Protocol (CFDP). Issue 5. Recommendation for Space Data System
Standards (Blue Book), CCSDS 727.0-B-5. Washington, D.C.: CCSDS, July 2020.

[9] Licklider Transmission Protocol (LTP) for CCSDS. Issue 1. Recommendation for Space
Data System Standards (Blue Book), CCSDS 734.1-B-1. Washington, D.C.: CCSDS,
May 2015.

[10] “Space Packet Protocol Secondary Header Format Document.” Space Assigned
Numbers Authority.
https://sanaregistry.org/r/space_packet_protocol_secondary_header_format_document.

[11] Communications Operation Procedure-1. Issue 2. Recommendation for Space Data System
Standards (Blue Book), CCSDS 232.1-B-2. Washington, D.C.: CCSDS, September 2010.

[12] CCSDS Bundle Protocol Specification. Issue 1. Recommendation for Space Data System
Standards (Blue Book), CCSDS 734.2-B-1. Washington, D.C.: CCSDS, September 2015.

CCSDS 130.3-G-1 Page 1-3 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

[13] IP over CCSDS Space Links. Issue 1. Recommendation for Space Data System Standards
(Blue Book), CCSDS 702.1-B-1. Washington, D.C.: CCSDS, September 2012.

[14] “Packet Version Number.” Space Assigned Numbers Authority.

https://sanaregistry.org/r/packet_version_number.

[15] Information Technology—Open Systems Interconnection—Basic Reference Model: The

Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO, 1994.

[16] “Protocol Identifier for Encapsulation Service.” Space Assigned Numbers Authority.
https://sanaregistry.org/r/protocol_id.

[17] “Extended Protocol Identifier for Encapsulation Packet Protocol.” Space Assigned
Numbers Authority. https://sanaregistry.org/r/extended_protocol_id.

[18] “Internet Protocol Extension Header.” Space Assigned Numbers Authority.

https://sanaregistry.org/r/ipe_header.

CCSDS 130.3-G-1 Page 1-4 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

2 THE SPACE PACKET PROTOCOL FROM USERS’ PERSPECTIVE

2.1 BASIC CONCEPTS OF SPACE PACKET PROTOCOL

2.1.1 SPP ARCHITECTURE

The SPP is designed as a self-delimited carrier of a data unit (i.e., 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. A typical use would be to carry data from
a specific mission source to a mission user. Different data types often require additional
information (such as time) to fully utilize the contained data, and those parameters and the
format of the data contents must be identified, in the mission context, by using the APID.

The SPP is designed to meet the requirements of space missions to efficiently transfer space
application data of various types and characteristics between nodes over one or more onboard
subnetworks, possibly involving one or more ground-to-space, space-to-ground, space-to-
space, or onboard communication links.

Figure 2-1 illustrates where the SPP can be located in the protocol stack. The SPP is able to
provide the functionality of an Application Layer protocol or a ‘shim’ protocol. For this reason,
the SPP appears twice in the figure. At the Application Layer, the SPP defines the Space
Packet, which can be used directly by the user to contain application data. Additionally, the
SPP, similar to the EPP (reference [2]) can provide the functionality of a ‘shim’ protocol.

Space Packet Protocol Application Layer Protocols

BP

Upper Layers TCP UDP

IP

LTP IPoC

Either Encapsulation Packet Protocol or Space Packet Protocol

Space Data Link Layer Protocols

Data Link Layer USLP TM TC AOS Prox-1 Ethernet

Physical Layer RF/Optical Wire

Figure 2-1: SPP Context within the CCSDS Protocol Stack

CCSDS 130.3-G-1 Page 2-1 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

The identification of the meaning of APID as to source or destination and the path that the SPP
will traverse are entirely determined by the assignment of mission-specific meaning within the
context of any given deployment. Most importantly, the SPP itself defines no path, network, or
routing functionality and does not provide network services. Furthermore, SPP itself has no
networking capabilities and fully relies on the services provided by the applicable subnetworks.

Figure 2-1 illustrates the concept of the SPP within the CCSDS protocol stack when used over
a space link. User data units are incorporated in Space Packets and are eventually transferred
over a space link using either one of the Packet Services of an SDLP (references [3], [4], [5],
[6], and [7]), including the Bundle Protocol (BP) service (reference [12]), which transmits a
bundle to an identified bundle endpoint. Management establishes which underlying protocol
and service is to be used to transfer PDUs. It should be noted that the Coding and
Synchronization sublayer of the Data Link Layer is not explicitly shown in the figure.

The SPP provides a unidirectional data transfer service from a single source user application
to one or more destination user applications through one or more subnetworks. The APID is
the field in the packet primary header that uniquely identifies a stream of packets (indicates
source, destination, or type).

The APID provides a single naming domain within a given mission deployment. The APID
can be used in a variety of ways by a mission, depending on mission needs. It can be used to
designate the intended destination for a stream of packets, to designate the source of a stream
of packets, or to designate different types of packets. The ways that the APID are used, and
the management of the APID naming domain, are mission-specific choices.

If missions wish to use the APID naming domain to service, for instance, a spacecraft that
has multiple processors, a spacecraft that is ‘fractionated’, or even a mission that includes a
deployment of multiple spacecraft, those spacecraft/missions must either manage and
suballocate assignments in the single APID naming domain within the enterprise or define a
way to extend it using mission-specific fields in the packet secondary header. This sort of
extension is supported by the APID and the packet secondary header, but a standard APID
domain naming service is not defined by CCSDS. Similarly, other mechanisms supported by
transfer-frame-level services in the Space Data Link Layer protocols, such as virtual channel
multiplexing/demultiplexing of transfer frames over a master channel, can be utilized.

As the data traverse the subnetworks, they are carried by subnetwork-specific mechanisms using
protocols provided by the subnetworks. The selection of protocols used in the subnetworks is
determined independently for each subnetwork and may not be the same throughout.

The actual path through the end-to-end data system through which the packets flow needs to
be configured by design or by a management system before the data transfer occurs and can
only be reconfigured through the management system. This flow is referred to as a managed
data path; aside from the APID, the SPP does not define any of the mechanisms to define or
manage a managed data path. Each managed data path may consist of a single source end
system, one or more destination end systems, one or more subnetworks, and, if multiple
subnetworks are involved, one or more intermediate systems that interconnect the

CCSDS 130.3-G-1 Page 2-2 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

subnetworks. A managed data path involves only one subnetwork only if the source and
destination end systems are on the same subnetwork. The configuration details of the
managed data path, and of any underlying transport services, are unknown to the SPP entity.
These are all the responsibility of these underlying services, and the only information that
SPP directly provides to assist in this is the APID field.

2.1.2 SPP PROTOCOL FEATURES

The SPP provides the users with abstract services to transfer space application data from a
source to a destination user application. The primary function performed by this protocol is
the identification and encapsulation of application data to facilitate its transfer along the
managed data path through underlying subnetworks.

The PDUs employed by this protocol are Space Packets (unless otherwise stated, the term
‘Packet’ in this document refers to the Space Packet). They are variable in length (or may be
fixed at the discretion of the user) and are transmitted at variable intervals. Aside from the
SPP header that identifies the Packet, the internal data content of Space Packets is completely
under the control of the user application. Each user application can define the organization
and content of Packets independently of other user applications, with a minimum of
constraints imposed by the transmission mechanisms of the underlying subnetworks.

The SPP entity at the source end system either generates Space Packets from Service Data
Units (SDUs) supplied by the source user application or validates Space Packets provided as
SDUs by the source user application. At the source system, the SPP entity examines the
APID of incoming Space Packets and transfers them through appropriate subnetworks using
the services provided by the underlying protocol and communication system. The behavior
of intermediate nodes, and the processes to be used for forwarding data, are implementation
specific and outside the scope of this document. If there are multiple destinations for a Space
Packet, multicasting of Space Packets may be performed by one or more SPP entities at the
source end system and/or intermediate system(s).

2.1.3 SPP ADDRESSING

The addressing feature within the SPP is the APID. APIDs are unique only in a single naming
domain. An APID naming domain usually corresponds to a spacecraft (or an element of a
constellation of cooperating space vehicles). Each space project establishes the allocation of
APIDs to be used in its naming domain. The assignment of APIDs to managed data paths
within a naming domain is controlled by the space project that owns the naming domain.

CCSDS 130.3-G-1 Page 2-3 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

2.1.4 SPP PROTOCOL DESCRIPTION

The SPP is described in terms of

a) the abstract services provided to the users;
b) the PDUs; and
c) the procedures performed by the protocol.

The service definitions are given in the form of primitives, which present an abstract model of
the logical exchange of data and control information between the protocol entity and the service
user. The definitions of primitives are independent of specific implementation approaches.

The procedure specifications define the procedures performed by protocol entities for the
transfer of information between peer entities. The definitions of procedures are independent
of specific implementation methods or technologies.

2.2 COMMON FEATURES OF SPP SERVICES

The SPP provides users with data transfer services. The point at which a service is provided
to a user by a protocol entity is called a Service Access Point (SAP) (see reference [15]). The
SAP of the SPP entity accepts SPP SDUs identified with an APID.

SDUs submitted to a SAP are processed in the order of submission. No processing order is
maintained for SDUs submitted to different SAPs.

NOTE – Flow control between the service user and the service provider may be required
at a SAP. However, CCSDS does not define a flow-control scheme between user
and provider.

The categories of services in the Recommended Standard include the following:

a) Preconfigured services: the user can send or receive data only through a preconfigured
managed data path that is established by management.
b) Unidirectional (one way) services: one end of the managed data path can send but
not receive data through the path, while the other end can receive but not send.
c) Asynchronous services: there are no predefined timing rules for the transfer of SDUs
supplied by the service user. The user may request data transfer at any time, but there
may be restrictions imposed by the provider implementation on the data generation rate.
d) Unconfirmed services: the sending user does not receive confirmation from the
receiving end that data has been received.
e) Incomplete services: the services do not guarantee completeness of a sequence of
SDUs, nor do they provide a retransmission mechanism.

CCSDS 130.3-G-1 Page 2-4 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

f) Non-sequence-preserving services: the sequence of SDUs supplied by the sending

user may not be preserved through the end-to-end managed data path.

NOTE – This protocol may be used for sending data from user A to user B and from user
B to user A, but two separate managed data paths, one for each direction, should
be used in such cases.

The actual end-to-end quality of service provided to service users will vary according to the
individual qualities of service provided by the various subnetworks and links along the
managed data path. The SPP does not provide any mechanisms for guaranteeing a particular
quality of service; it is the responsibility of implementing organizations to ensure that the
end-to-end performance of a particular service instance meets the requirements of its users.

2.3 BENEFITS OF THE SPACE PACKET PROTOCOL

2.3.1 INDEPENDENCE

Before the Space Packet Protocol was specified, many activities on board the spacecraft had
to be synchronized with the process of generating telemetry frames, and coordination on
telemetry generation rate and timing among the instruments on board the same spacecraft
was necessary. However, the SPP hides such physical mechanisms from user applications
because it is independent of the data transfer methods of the underlying subnetworks as
explained in 2.1. By using the SPP, developers of instruments can design onboard
applications almost independently of the underlying data transfer mechanisms and of the
activities of the other instruments on the same spacecraft. Therefore instrument developers
have more freedom in designing instrument data systems.

Independence from the data transfer methods of the underlying subnetworks also enables
sharing or reusing of user applications among different projects that may not use the same
technologies in the subnetworks. Further, the SPP can be used as a basis for developing
standard applications that do not depend on specific projects. Therefore it is anticipated that
the SPP will greatly contribute to the reduction of the development cost of space missions.

2.3.2 FLEXIBILITY

The Space Packet Protocol can be used to transfer any kind of application data virtually at
any rate and timing. There are, of course, constraints on the transfer rate and timing imposed
by the capabilities of the underlying subnetworks, but, within the resource allocation
determined by the project management, user applications can send any kind of application
data (commands, operation plans, housekeeping telemetry, science data, memory
uploads/downloads, etc.) at the rate and timing they desire.

On each managed data path, the user can decide what data to send at what rate and timing,
within the allocated resources. On a selected managed data path, for example, a user
application that sends images taken by an onboard instrument can transmit images

CCSDS 130.3-G-1 Page 2-5 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

constrained by the project’s end-to-end information system. The volume of each image does
not need to be the same and the user application can use the available data compression
schemes. On a different managed data path, another user application that monitors the status
of an instrument may send status engineering data periodically. A third user application that
controls the instrument may receive commands through a third managed data path. All of
these cases of data transfer can be implemented using the Space Packet Protocol and the end
users do not have to devise special data transfer schemes that suit their user applications.

2.4 FEATURES OF THE SPACE PACKET PROTOCOL

2.4.1 UNCONFIRMED AND INCOMPLETE

The Space Packet Protocol does not provide to the source user application a confirmation
whether data units it has sent have actually arrived at the destination user application(s). Nor
does it perform retransmission to recover lost data units. Therefore the destination may not
receive all data units sent by the source, and the source does not know whether the
destination has received all data units it sent. Further, the Space Packet Protocol may not
deliver data units to the destination in the order in which the source sent them. However, at
the discretion of the user, an optional field containing an error detection code may be
included in the application data in order to verify that the overall integrity of the Space
Packet has been preserved during the transport process.

When there is a need to provide a confirmation to the source, perform retransmission of lost data,
or preserve the sequence of transferred data, the user applications must perform these functions.
Actually, it is a common practice for the destination user application to send back a confirmation
to the source user application when it has received important data (such as commands) using
another managed data path in the opposite direction. CCSDS does not have a standard for
sending back confirmation or performing retransmission with the SPP, but it has developed
several higher-layer protocols on top of the SPP to perform reliable transfer of PDUs. Examples
are the CCSDS Licklider Transmission Protocol (LTP) (reference [9]) for reliable transfer of
LTP blocks and the CCSDS File Delivery Protocol (CFDP) (reference [8]) for reliable transfer
of files.

Whether to send back confirmation or perform retransmission depends on many factors

associated with the spacecraft design policies, spacecraft operations policies, and
communications link performance. If simplicity is more important than performance for the
mission, users may choose to perform retransmission of lost data with an action of an
operator or rely on a retransmission capability provided by the underlying Data Link Layer.
They may also choose to send the same data multiple times to achieve reliability if they can
sacrifice efficiency. If reliability of data is the most important requirement for the mission, a
higher-layer protocol like LTP or CFDP may be used on top of the SPP.

CCSDS 130.3-G-1 Page 2-6 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

2.4.2 UNIDIRECTIONAL (ONE-WAY)

Each managed data path only provides one-way transfer from a source user application to
one or more destination user applications. User applications on board spacecraft usually
receive commands from other user applications, and they send telemetry back to the original
user applications that sent the commands. In such cases, the managed data paths for sending
telemetry are separate from the managed data paths for sending commands.

The SPP does not provide two-way communications between peer user applications over a
single managed data path, but this is not a big disadvantage because data flows of commands
and telemetry of space missions are not always symmetric (usually the number of user
applications that receive telemetry from a spacecraft is much larger than that of user
applications that send commands to the same spacecraft).

2.5 SPACE PACKET PROTOCOL NOMINAL EXAMPLE

2.5.1 INTRODUCTION

The example in figure 2-2 illustrates how the SPP is used to operate an onboard instrument.
On a Spacecraft On the Ground

Instrument Control System Analysis System

Image Pre- Monitor & Instrument Image

processing Control Operations Analysis

Managed Data Path 3

Managed Data Path 2
Managed Data Path 1

Figure 2-2: Configuration of User Applications (An Example)

2.5.2 CONFIGURATION OF USER APPLICATIONS

An instrument on a spacecraft takes images and sends them to an image analysis system
located on the ground. The instrument takes images according to commands received from a
control system on the ground and sends its status back to the control system.

The instrument has two user applications: one for monitoring and controlling itself and one
for preprocessing (e.g., compression) acquired images. The image preprocessing process
communicates with an image analysis process in the analysis system, and the monitor-and-
control process communicates with an instrument operations process in the control system.

CCSDS 130.3-G-1 Page 2-7 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

The configuration of the user applications of this system is shown in figure 2-2. In this
figure, there are three physical entities, shown as boxes: the instrument, the control system,
and the analysis system. The instrument is on the spacecraft, while the control and analysis
systems are at a space operations center on the ground. The four user applications in this
system are shown as ovals.

There are other elements involved in this mission that are not shown in this figure, for example,
other instruments and subsystems on the spacecraft and other supporting facilities (like a
tracking network) on the ground. Figure 2-2 only shows elements that directly perform the
operations of this instrument. The user applications for this instrument can be designed almost
independently of the other elements involved in the mission.

2.5.3 COMMUNICATIONS BETWEEN USER APPLICATIONS

The image preprocessing process of the instrument sends preprocessed images to the image
analysis process on the ground through managed data path 1. Images are transferred by the
SPP packed in Space Packets. However, since the size of acquired images is usually larger
than the maximum size of the Space Packet, an image must be transferred in a group of Space
Packets. The source user application (the image preprocessing process, in this case) must
break images into smaller segments and make sure that each segment fits into a Space
Packet. There is a limit on the transmission rate imposed by the underlying transfer
mechanisms, but within that limit, the onboard preprocessing process can send images of any
desired size and at any time. Therefore the preprocessing process can compress images with
a suitable method and send them whenever it has images to send.

The instrument operations process on the ground sends commands to control the instrument
to the instrument’s monitor-and-control process through managed data path 2. When the
instrument is controlled in real time from the ground, each individual command is transferred
in a Space Packet. When the instrument performs observations autonomously according to
the observation plans generated on the ground, each observation plan is transferred in a
Space Packet.

The monitor-and-control process of the instrument periodically sends status of the instrument
to the instrument operations process on the ground through managed data path 3. A set of
status data taken at a time is transferred in a Space Packet.

The instrument generates images and status data regardless of whether the spacecraft is in
contact with the ground. When the spacecraft is not in contact with the ground, images and
status data are temporarily stored in the onboard data store on the spacecraft. Stored data are
transferred to the ground when the spacecraft is in contact with the ground. These ‘store and
forward’ operations are performed as management actions within the managed data path, and
the instrument need not be aware of whether data are being transferred to the ground in real
time or stored in the onboard data store.

The user applications for this instrument are designed with the above assumptions on how to
use the managed data paths, but the instrument designer need not be concerned with how

CCSDS 130.3-G-1 Page 2-8 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

Space Packets are physically transferred through the underlying subnetworks or where and
how they are temporarily stored.

If the underlying subnetworks do not provide enough reliability, the user applications may
implement reliable transfer mechanisms using these three, or other, managed data paths. For
example, the instrument may use managed data path 3 to return to the control system an
acknowledgment of receipt of each command it has received through managed data path 2 so
that the control system can resend lost commands.

CCSDS 130.3-G-1 Page 2-9 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

3 THE ENCAPSULATION PACKET PROTOCOL FROM USERS’

PERSPECTIVE
3.1 BASIC CONCEPTS OF THE ENCAPSULATION PACKET PROTOCOL

The Encapsulation Packet Protocol is used to transfer PDUs, defined in SANA by CCSDS,
using the SDLPs (references [3]–[7]) over an applicable ground-to-space, space-to-ground, or
space-to-space communications link.

Data units that can be directly transferred by the SDLPs have a Packet Version Number (PVN)
defined in SANA by CCSDS. (A list of the Packet Version Numbers presently defined by
CCSDS is contained in reference [14].) The main purpose of the EPP is to provide a
mechanism to transfer PDUs without an authorized PVN over a space link.

The EPP is a ‘shim’ protocol that utilizes the packet services of the SDLPs of the Data Link
Layer defined in references [3]–[7], and therefore it is intended to be used together with one
of these references.

OSI Layers

Protocol X Protocol Y

Upper Layers
Encapsulation
Packet Protocol

Packet Service

Space Data Link

Data Link Layer
Protocol
Synchronization &
Channel Coding

Physical Layer

Figure 3-1: Concept of Encapsulation Packet Protocol

Figure 3-1 illustrates the concept of this protocol. PDUs of protocols X and Y, which do not
have an authorized PVN, are transferred with the EPP within the Data Link Layer. PDUs of
protocols X and Y are encapsulated in Encapsulation Packets and are eventually transferred
using one of the VC/MAP/Proximity-1 Packet Services of an SDLP. Management
establishes which SDLP is to be used to transfer encapsulated PDUs. Figure 2-1 also
provides a more encompassing view of the EPP as a shim-layer protocol between the CCSDS
upper-layer protocols and the CCSDS Space Data Link Layer.

CCSDS 130.3-G-1 Page 3-1 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

3.2 FEATURES OF THE ENCAPSULATION PACKET PROTOCOL

The EPP transfers a sequence of variable-length, delimited, octet-aligned PDUs within the
data field of an SDLP over a space link. A user of this protocol is a protocol entity that sends
or receives PDUs that do not have an authorized PVN.

A data unit supplied by the protocol user is encapsulated unchanged into an Encapsulation
Packet. One and only one data unit is encapsulated into a single packet.

The protocol permits a data unit to be of any length that is an integral number of octets and
that is subject to the maximum and minimum sizes established by the project organization.
Although the maximum length of a data unit that can be accommodated by an Encapsulation
Packet is 4,294,967,287 octets, individual project organizations may establish the maximum
and minimum sizes for the encapsulated data unit.

The point at which an instance of this protocol is provided to a user is a SAP. Data units
submitted to a SAP are processed in the order of submission. No processing order is maintained
for data units submitted to different SAPs.

NOTE – Implementations may be required to perform flow control at a SAP between the
service user and the service provider. However, CCSDS does not recommend a
scheme for flow control between the user and the provider.

Features of the EPP are as follows:

a) Unidirectional (one way) service: one end of a connection can send, but not receive,
data through the space link, while the other end can receive, but not send, data
through the space link.
b) Asynchronous service: there are no timing relationships between the transfer of data
units supplied by the user and any data transmission mechanism within the Data Link
Layer. The user may request data transfer at any time, but there may be restrictions
imposed by the service provider on the data generation rate.
c) Unconfirmed service: the sending user does not receive confirmation from the
receiving end indicating that data has been received.
d) Incomplete service: the service does not guarantee completeness, but the service
provider may signal gaps in the sequence of data units delivered to the receiving user.
e) Sequence-preserving service: the sequence of data units supplied by the sending user
is preserved through the transfer over the space link, although there may be gaps in
the sequence of data units delivered to the receiving user.

CCSDS 130.3-G-1 Page 3-2 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

3.3 ADDRESSING

A user of the EPP is identified by the Encapsulated Protocol Identifier (EPI). The
Encapsulation Packet is a PDU defined in section 4 of reference [2].

Encapsulation Protocol Identifiers are registered as ‘defined Protocol IDs’ in the SANA
registries, Protocol Identifier for Encapsulation Service (reference [16]) and Extended Protocol
Identifier for Encapsulation Packet Protocol (reference [17]). A SAP is identified by the
combination of a PVN, an EPI, and an SDLP channel through which the data units supplied by
the user are to be transferred.

3.4 PROTOCOL DESCRIPTION

The EPP is described in terms of

a) the primitives provided to the users of this protocol;
b) the PDUs employed by the protocol for encapsulation; and
c) the procedures performed by the protocol.

The primitives present an abstract model of the logical exchange of data and control
information between the service provider and the service user. The definitions of primitives
are independent of specific implementation approaches.

The PDU (i.e., the Encapsulation Packet) defines the data structure in which data units
supplied by the service user are encapsulated.

The procedure specifications define the procedures performed by the service provider for the
transfer of data units. The definitions of procedures are independent of specific implementation
methods or technologies.

3.5 ENCAPSULATION PACKET PROTOCOL DEPLOYMENT EXAMPLE

An example illustrating how the EPP is used as a shim protocol to encapsulate a CFDP PDU
and transfer it across the space link using the underlying CCSDS Space Data Link Layer is
shown in figure 3-2.

CCSDS 130.3-G-1 Page 3-3 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

Filestore Flight CFDP Implementation

Shim Protocol: Encapsulation Packet Protocol

Space Data Link Layer: USLP, TC, TM, AOS, Proximity-1

Physical Layer: R/F, Optical

Filestore Ground CFDP Implementation

Figure 3-2: Example Deployment of CFDP over the Encapsulation Packet Protocol

In order to transfer a file in either direction shown in figure 3-2 between the filestores
implemented on the ground and/or on the flight system, the user chooses CFDP as the upper
layer protocol. The contents of the file is transformed into a series of CFDP PDUs, which are
encapsulated one for one within an Encapsulation Packet. The EPI assigned to the
Encapsulation Packet Header identifies CFDP as the encapsulated protocol so that on the
receive side, the contents of the Encapsulation Packet will be routed to the receiving CFDP
engine. One or more Encapsulation Packets are placed into the applicable CCSDS transfer
frame for a given space data link. The Space Data Link Layer resides above the Physical
Layer, that is, either RF or optical link.

CCSDS 130.3-G-1 Page 3-4 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

4 FREQUENTLY ASKED QUESTIONS ON THE CCSDS PACKET

PROTOCOLS
In what layers do the CCSDS Packet Protocols belong?

Figure 2-1 illustrates where both the SPP and the EPP can be located in the protocol stack.
The SPP is able to provide the functionality of either an Application Layer protocol or a
‘shim’ protocol. For this reason, the SPP appears twice in that figure. At the Application
Layer, the SPP defines the Space Packet, which can be used directly by the user to contain
application data. As a ‘shim’ protocol, the Space Packet can encapsulate the PDUs of other
protocols recognized by CCSDS. Additionally, the EPP exclusively provides the
functionality of a ‘shim’ protocol. It also provides a mechanism of transferring PDUs of other
protocols across the CCSDS SDLPs.

Can the CCSDS Packet Protocols coexist with Internet technologies and DTN?

The answer is a resounding yes. Applications, for example, telemetry and telecommand, are
activities in the Application Layer, and users may choose the SPP and the associated Space
Packet as the data structure with which to transport their data within the Application Layer.
Delay Tolerant Networking (DTN) as well as Internet technologies can be used to support the
operations of the SPP in the Transport and Network Layers in subnetworks in which either DTN
or the Internet protocols provide the required end-to-end performance.

As mentioned previously, either the EPP or the SPP can be used as a ‘shim’ protocol between
the upper layer DTN, CFDP, LTP, or Internet protocols and the CCSDS Space Data Link
Layer protocols (references [3]–[7]). These packets can be placed directly into CCSDS Space
Data Link Layer transfer frames.

The IP over CCSDS (IPoC) ‘shim’ protocol (reference [13]) is used to transfer specifically
recognized Internet Protocol (IP) versions identified in the Internet Protocol Extension
Header SANA registry (reference [18]) over the space link. IP PDUs are transferred by
encapsulating them, one-for-one, within CCSDS Encapsulation Packets. The Encapsulation
Packets are transferred directly within one or more CCSDS SDLP transfer frames. This method
uses the CCSDS Internet Protocol Extension (IPE) convention defined in (reference [13]).

How can CCSDS Packets be transmitted reliably?

Neither the SPP nor the EPP has provision for recovering missing packets via a
retransmission mechanism. Reliable transmission of packets can be accomplished by using
an additional protocol.

By using either COP-1 (reference [11]), which supports the reliable transfer of direct-from-
Earth (telecommand) transfer frames, or COP-P (reference [6]), which supports the reliable
transfer of Proximity/space-to-space transfer frames, packets contained within these transfer
frames can be reliably transferred point to point between nodes.

CCSDS 130.3-G-1 Page 4-1 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

In addition, CCSDS provides several upper-layer protocols that perform reliable transfer, such
as CFDP (reference [8]), which could be used to reliably transfer a file composed of packets.
Furthermore, LTP (reference [9]), is another upper-layer CCSDS protocol, which could be used
to transmit packets contained in LTP segments reliably across the space link. When IPoC
(reference [13]) is used, Transmission Control Protocol (TCP) supplies the reliability. Finally,
the user application itself could provide a reliable retransmission mechanism.

Are the CCSDS Packet Protocols suitable for real-time operations?

Neither the SPP nor the EPP guarantees a minimum delay in data transfer from source to
destination, since they are asynchronous protocols. But there are ways to transfer real-time
data as speedily as possible over multiple managed data paths.

One way is to use high-priority services of the underlying subnetworks when either Space or
Encapsulation Packets are transferred over subnetworks. When these Packets are transferred
over space links, the CCSDS SDLPs (references [3]–[7]) are typically used. These Data Link
Protocols divide the capacity of a space link into multiple Virtual Channels, each of which is
used for transferring a specific type of user data. If some Virtual Channels are set up for
transferring high-priority data, then Space or Encapsulation Packets for real-time operations
can be transferred over those Virtual Channels. In some cases, the SPP or EPP entities
themselves can prioritize packets by controlling their order of transmission over
subnetworks, based on the quality-of-service requirement associated with specific managed
data paths.

Another method of transferring isochronous data (e.g., voice, launch-vehicle telemetry) is by

using the Insert Zone Field within either the AOS (reference [5]) or USLP (reference [7])
SDLPs.

Is the Space Packet too small for sending images and memory data?

It is true that the maximum size of the Space Packet (i.e., 65536 octets) is sometimes too
small to completely contain images and memory uploads/downloads. In such cases, an
application data unit such as a file (an image or a chunk of memory data) that does not fit into
a single Space Packet must be transferred within a group of Space Packets. The source user
application must segment the application data unit into smaller segments and make sure that
each segment fits into a Space Packet.

The Space Packet has fields called the ‘Sequence Flags’ in its primary header to identify the
first and last segments of a group, and reconstruction of the original application data unit at
the destination is possible using these flags. If the segment number of each segment needs to
be transferred with the segment itself, the Packet Secondary Header can be used to send the
segment number. (For the specification of the Space Packet Sequence Flags and the Packet
Secondary Header, see reference [1].)

CCSDS 130.3-G-1 Page 4-2 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

In comparison to the maximum Space Packet size, the optional 4-octet Encapsulation Packet
32
Length field accommodates Encapsulation packet sizes up to 4,294,967,287 (= 2 − 5) octets
in length (see reference [2]).

Does the Space Packet Protocol support an enterprise-wide data-management scheme

based upon APID assignments?

If missions wish to share the APID naming domain amongst multiple spacecraft to service,
for instance, a spacecraft that has multiple processors, a spacecraft that is ‘fractionated’, or
even a mission that includes a deployment of multiple spacecraft, those missions must either
manage and suballocate assignments in the single APID naming domain within the enterprise
or define a way to extend it using mission-specific fields in the Space Packet Secondary
Header. An enterprise-specific extension to the APID naming domain is supported by the
APID and the Packet Secondary Header fields within the SPP, but a universal APID domain
naming service is not defined by CCSDS. However, CCSDS does offer a better long-term
approach: DTN supports an endpoint identifier, which is a type of Uniform Resource
Identifier (URI) designed to meet the requirements for endpoint identification (source,
destination) as defined in the BP specification (reference [12]).

Packet Secondary Header types are registered with SANA (reference [10]), and the actual
contents of the secondary header are ‘managed’ at the SPP service user interface. (To view
existing SPP Secondary Header formats registered with SANA or to register a new SPP
Secondary Header format, see annex B, Security, SANA, and Patent Considerations, in
reference [1]). From the point of view of an implementer, annex B contains a description of
the registry for SPP Secondary Header format documents and also a description of structure
of the SPP secondary packet data structure document registry.

What are the tradeoffs between implementing Space Packets vs Encapsulation Packets?

Both SPP and EPP can be used as ‘shim’ protocols to transfer PDUs of protocols that CCSDS
recognizes across the space link. The biggest reason for choosing EPP over SPP is efficiency.
The Encapsulation Packet Header size is configurable between 1 to 8 octets in length vs the
Space Packet Primary Header which is 6 octets long. However, the Encapsulation Packet
contains no header field for sending ancillary data (such as time) or for extending the APID
domain naming space concurrent with the payload data. As stated above, the Encapsulation
Packet may be provisioned to be much larger than the 65536-octet Space Packet size.

CCSDS 130.3-G-1 Page 4-3 April 2023

 CCSDS REPORT CONCERNING THE PACKET PROTOCOLS

ANNEX A

ABBREVIATIONS AND ACRONYMS

AOS Advanced Orbiting Systems

APID application process identifier

BP Bundle Protocol

CCSDS Consultative Committee for Space Data Systems

CFDP CCSDS File Delivery Protocol

COP-1 Communications Operation Procedure-1

COP-P Communications Operation Procedure for Proximity links

DTN Delay Tolerant Networking

EPI Encapsulated Protocol Identifier

EPP Encapsulation Packet Protocol

ID identifier

IP Internet Protocol

IPE Internet Protocol Extension

IPoC IP over CCSDS

PDU protocol data unit

PVN Packet Version Number

SAP service access point

SDLP Space Data Link Protocol

SDU service data unit

SPP Space Packet Protocol

TCP Transmission Control Protocol

URI Uniform Resource Identifier

CCSDS 130.3-G-1 Page A-1 April 2023