Overview of Space Communications Protocols

Report Concerning Space Data System Standards

OVERVIEW OF SPACE

COMMUNICATIONS

PROTOCOLS

INFORMATIONAL REPORT

CCSDS 130.0-G-4

GREEN BOOK

April 2023

Report Concerning Space Data System Standards

OVERVIEW OF SPACE

COMMUNICATIONS

PROTOCOLS

INFORMATIONAL REPORT

CCSDS 130.0-G-4

GREEN BOOK

April 2023

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page i April 2023

AUTHORITY

Issue:

Informational Report, Issue 4

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: secretariat@mailman.ccsds.org

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page ii April 2023

FOREWORD

This document is a CCSDS Report that contains an overview of the space communications

protocols recommended by CCSDS. A space link is a communications link between a

spacecraft and its associated ground system or between two spacecraft. A space

communications protocol is a communications protocol designed to be used over a space

link, or in a network that contains one or multiple space links.

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 REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page iii April 2023

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 REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page iv April 2023

DOCUMENT CONTROL

Document

Title

Date

Status

CCSDS

130.0-G-1

Overview of Space Link Protocols,

Issue 1

June

2001

Original issue,

superseded

CCSDS

130.0-G-2

Overview of Space Communications

Protocols, Informational Report,

Issue 2

December

2007

Issue 2, superseded

CCSDS

130.0-G-3

Overview of Space Communications

Protocols, Informational Report,

Issue 3

July 2014 Issue 3, superseded

CCSDS

130.0-G-4

Overview of Space Communications

Protocols, Informational Report,

Issue 4

April 2023 Current issue

EC 1 Editorial Change 1 February

2024

Corrects page numbering

in section 4.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page v April 2023

CONTENTS

Section Page

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

1.1 PURPOSE AND SCOPE ........................................................................................ 1-1

1.2 DOCUMENT STRUCTURE .................................................................................. 1-1

1.3 DEFINITIONS ........................................................................................................ 1-1

1.4 REFERENCES ........................................................................................................ 1-3

2 INTRODUCTION TO SPACE COMMUNICATIONS PROTOCOLS ................... 2-1

2.1 HISTORY OF SPACE COMMUNICATIONS PROTOCOLS .............................. 2-1

2.2 PROTOCOL LAYERS ........................................................................................... 2-3

3 MAJOR FEATURES OF SPACE COMMUNICATIONS PROTOCOLS .............. 3-1

3.1 PHYSICAL LAYER ............................................................................................... 3-1

3.2 DATA LINK LAYER ............................................................................................. 3-1

3.3 NETWORK LAYER ............................................................................................... 3-9

3.4 TRANSPORT LAYER ........................................................................................... 3-9

3.5 APPLICATION LAYER ...................................................................................... 3-10

4 EXAMPLES OF PROTOCOL CONFIGURATIONS ............................................... 4-1

4.1 GENERAL .............................................................................................................. 4-1

4.2 END-TO-END DATA FORWARDING USING PACKETS

DEFINED BY CCSDS ........................................................................................... 4-2

4.3 IP OVER CCSDS FOR END-TO-END ROUTING ............................................... 4-3

4.4 BP FOR END-TO-END DATA ROUTING ........................................................... 4-5

ANNEX A ACRONYMS .................................................................................................. A-1

Figure

2-1 Space Communications Protocols Reference Model .................................................... 2-4

3-1 Relationships between Channels of the Space Data Link Protocols ............................. 3-4

4-1 Simple Space Data System Model ................................................................................ 4-1

4-2 Protocol Configuration on a Space Link When Space Packet or

Encapsulation Packet Protocol Is Used for End-to-End Forwarding ............................ 4-3

4-3 Protocol Configuration in a Space Data System When Space Packet or

Encapsulation Packet Protocol Is Used for End-to-End Forwarding ............................ 4-3

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page vi April 2023

CONTENTS (continued)

Figure Page

4-4 Protocol Configuration on a Space Link When IP over CCSDS Is

Used for End-to-End Routing ....................................................................................... 4-4

4-5 Protocol Configuration in a Space Data System When IP over

CCSDS is Used for End-to-End Routing ...................................................................... 4-5

4-6 Protocol Configuration in a Space Data System When BP Is Used

for End-to-End Data Routing ........................................................................................ 4-6

Table

3-1 Identifiers of Space Data Link Protocols ...................................................................... 3-5

3-2 Summary of Services Provided by Space Data Link Protocols .................................... 3-6

3-3 Functions of Synchronization and Channel Coding Standards ..................................... 3-8

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

1 INTRODUCTION

1.1 PURPOSE AND SCOPE

The purpose of this Report is to provide an architectural overview of the space

communications protocols recommended by CCSDS and to show how these protocols are

used in space mission data systems. The focus is on the recommendations within the Space

Link Services area of CCSDS, while protocols from other areas are covered to a lesser

extent.

A space link is a communications link between a spacecraft and its associated ground system

or between two spacecraft. A space communications protocol is a communications protocol

designed to be used over a space link, or in a network that contains one or multiple space

links.

This Report presents only a top-level overview of the space communications protocols and

does not contain the specification or rationale of each protocol. The specification of a space

communications protocol developed by CCSDS is contained in a CCSDS Blue Book, and its

rationale is described in a CCSDS Green Book that accompanies the Blue Book.

1.2 DOCUMENT STRUCTURE

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

a) section 1 presents the purpose and scope of this Report and lists the definitions and

references used throughout the Report;

b) section 2 provides a brief introduction to the space communications protocols;

c) section 3 presents major features of the space communications protocols;

d) section 4 shows some examples of how space communications protocols are used in

space data systems;

e) annex A lists acronyms and abbreviations used within this document.

1.3 DEFINITIONS

1.3.1 DEFINITIONS FROM OSI BASIC REFERENCE MODEL

Most of the CCSDS space communications protocols are defined using the style established

by the Open Systems Interconnection (OSI) Basic Reference Model (reference [2]). This

model provides a common framework for the development of standards in the field of

systems interconnection. It defines concepts and terms associated with a layered architecture

and introduces seven specific layers. The concepts and terms defined in this model are

extensively used in the Blue Books that define CCSDS space communications protocols. If

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

the reader is not familiar with this model, an excellent introduction can be found in a

textbook on computer networks such as reference [3].

The following terms used in this Report are defined in reference [2]:

a) Application Layer;

b) Data Link Layer;

c) layer;

d) Network Layer;

e) Physical Layer;

f) protocol data unit;

g) service;

h) Transport Layer.

1.3.2 TERMS DEFINED IN THIS REPORT

For the purposes of this Report, the following definitions also apply.

forwarding: The act of transferring data from its source towards its destination, which may

be in space or on the ground.

octet: An 8-bit word.

Physical Channel: A stream of bits transferred over a space link (see below) in a single

direction.

routing: The process of selecting paths from origins to destinations in a network.

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

between two spacecraft. A space link consists of one or more Physical Channels in one or

both directions.

space communications protocol: A communications protocol designed to be used over a

space link (see above), or in a network that contains one or multiple space links.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

1.4 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] Organization and Processes for the Consultative Committee for Space Data Systems.

Issue 4. CCSDS Record (Yellow Book), CCSDS A02.1-Y-4. Washington, D.C.:

CCSDS, April 2014.

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

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

[3] Andrew S. Tanenbaum and David J. Wetherall. Computer Networks. 5th ed. Boston:

Pearson Prentice Hall, 2011.

[4] Space Packet Protocol. Issue 2. Recommendation for Space Data System Standards

(Blue Book), CCSDS 133.0-B-2. Washington, D.C.: CCSDS, June 2020.

[5] 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.

[6] 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.

[7] 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.

[8] TM Synchronization and Channel Coding. Issue 4. Recommendation for Space Data

System Standards (Blue Book), CCSDS 131.0-B-4. Washington, D.C.: CCSDS, April

2022.

[9] TC Synchronization and Channel Coding. Issue 3. Recommendation for Space Data

System Standards (Blue Book), CCSDS 231.0-B-3. Washington, D.C.: CCSDS,

September 2017.

[10] Radio Frequency and Modulation Systems—Part 1: Earth Stations and Spacecraft.

Issue 32. Recommendations for Space Data System Standards (Blue Book), CCSDS

401.0-B-32. Washington, D.C.: CCSDS, October 2021.

[11] Space Communications Protocol Specification (SCPS)—Network Protocol (SCPS-NP).

Issue 1-1. Recommendation for Space Data System Standards (Historical), CCSDS

713.0-B-1-S. Washington, D.C.: CCSDS, (May 1999) August 2010.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

[12] Space Communications Protocol Specification (SCPS)—Security Protocol (SCPS-SP).

Issue 1-S. Recommendation for Space Data System Standards (Historical), CCSDS

713.5-B-1-S. Washington, D.C.: CCSDS, (May 1999) August 2010.

[13] Space Communications Protocol Specification (SCPS)—Transport Protocol (SCPS-

TP). Issue 2. Recommendation for Space Data System Standards (Blue Book), CCSDS

714.0-B-2. Washington, D.C.: CCSDS, October 2006.

[14] Space Communications Protocol Specification (SCPS)—File Protocol (SCPS-FP).

Issue 1-S. Recommendation for Space Data System Standards (Historical), CCSDS

717.0-B-1-S. Washington, D.C.: CCSDS, (May 1999) August 2010.

[15] 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.

[16] Lossless Data Compression. Issue 3. Recommendation for Space Data System

Standards (Blue Book), CCSDS 121.0-B-3. Washington, D.C.: CCSDS, August 2020.

[17] Image Data Compression. Issue 2. Recommendation for Space Data System Standards

(Blue Book), CCSDS 122.0-B-2. Washington, D.C.: CCSDS, September 2017.

[18] 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.

[19] Proximity-1 Space Link Protocol—Coding and Synchronization Sublayer. Issue 3.

Recommendation for Space Data System Standards (Blue Book), CCSDS 211.2-B-3.

Washington, D.C.: CCSDS, October 2019.

[20] Proximity-1 Space Link Protocol—Physical Layer. Issue 4. Recommendation for Space

Data System Standards (Blue Book), CCSDS 211.1-B-4. Washington, D.C.: CCSDS,

December 2013.

[21] Information Technology—Open Systems Interconnection—Basic Reference Model—

Conventions for the Definition of OSI Services. International Standard, ISO/IEC

10731:1994. Geneva: ISO, 1994.

[22] J. Postel. Internet Protocol. STD 5. Reston, Virginia: ISOC, September 1981.

[23] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC

2460. Reston, Virginia: ISOC, December 1998.

[24] J. Postel. Transmission Control Protocol. STD 7. Reston, Virginia: ISOC, September

1981.

[25] J. Postel. User Datagram Protocol. STD 6. Reston, Virginia: ISOC, August 1980.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 1-5 April 2023

[26] J. Postel and J. Reynolds. File Transfer Protocol (FTP). STD 9. Reston, Virginia:

ISOC, October 1985.

[27] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301. Reston,

Virginia: ISOC, December 2005.

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

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

[29] Encapsulation Packet Protocol. Issue 3. Recommendation for Space Data System

Standards (Blue Book), CCSDS 133.1-B-3. Washington, D.C.: CCSDS, May 2020.

[30] 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.

[31] Space Data Link Protocols—Summary of Concept and Rationale. Issue 3. Report

Concerning Space Data System Standards (Green Book), CCSDS 130.2-G-3.

Washington, D.C.: CCSDS, September 2015.

[32] Proximity-1 Space Link Protocol—Rationale, Architecture, and Scenarios. Issue 2.

Report Concerning Space Data System Standards (Green Book), CCSDS 210.0-G-2.

Washington, D.C.: CCSDS, December 2013.

[33] TM Synchronization and Channel Coding—Summary of Concept and Rationale. Issue 3.

Report Concerning Space Data System Standards (Green Book), CCSDS 130.1-G-3.

Washington, D.C.: CCSDS, June 2020.

[34] TC Synchronization and Channel Coding—Summary of Concept and Rationale. Issue

3. Report Concerning Space Data System Standards (Green Book), CCSDS 230.1-G-3.

Washington, D.C.: CCSDS, October 2021.

[35] CCSDS File Delivery Protocol (CFDP)—Part 1: Introduction and Overview. Issue 4.

Report Concerning Space Data System Standards (Green Book), CCSDS 720.1-G-4.

Washington, D.C.: CCSDS, May 2021.

[36] Lossless Data Compression. Issue 4. Report Concerning Space Data System Standards

(Green Book), CCSDS 120.0-G-4. Washington, D.C.: CCSDS, November 2021.

[37] The Application of Security to CCSDS Protocols. Issue 3. Report Concerning Space

Data System Standards (Green Book), CCSDS 350.0-G-3. Washington, D.C.: CCSDS,

March 2019.

[38] Space Link Extension—Return All Frames Service Specification. Issue 4.

Recommendation for Space Data System Standards (Blue Book), CCSDS 911.1-B-4.

Washington, D.C.: CCSDS, August 2016.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 1-6 April 2023

[39] Space Link Extension—Return Channel Frames Service Specification. Issue 3.

Recommendation for Space Data System Standards (Blue Book), CCSDS 911.2-B-3.

Washington, D.C.: CCSDS, August 2016.

[40] Space Link Extension—Return Operational Control Fields Service Specification. Issue

3. Recommendation for Space Data System Standards (Blue Book), CCSDS 911.5-B-3.

Washington, D.C.: CCSDS, August 2016.

[41] Space Link Extension—Forward CLTU Service Specification. Issue 4.

Recommendation for Space Data System Standards (Blue Book), CCSDS 912.1-B-4.

Washington, D.C.: CCSDS, August 2016.

[42] Space Link Extension—Forward Space Packet Service Specification. Issue 3-S.

Recommendation for Space Data System Standards (Historical), CCSDS 912.3-B-3-S.

Washington, D.C.: CCSDS, (August 2016) September 2022.

[43] Space Data Link Security Protocol. Issue 2. Recommendation for Space Data System

Standards (Blue Book), CCSDS 355.0-B-2. Washington, D.C.: CCSDS, July 2022.

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

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

[45] 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.

[46] Asynchronous Message Service. Issue 1. Recommendation for Space Data System

Standards (Blue Book), CCSDS 735.1-B-1. Washington, D.C.: CCSDS, September 2011.

[47] Mission Operations—MAL Space Packet Transport Binding and Binary Encoding.

Issue 1. Recommendation for Space Data System Standards (Blue Book), CCSDS

524.1-B-1. Washington, D.C.: CCSDS, August 2015.

[48] “Registries.” Space Assigned Numbers Authority. https://sanaregistry.org/r.

[49] Low-Complexity Lossless and Near-Lossless Multispectral and Hyperspectral Image

Compression. Issue 2. Recommendation for Space Data System Standards (Blue Book),

CCSDS 123.0-B-2. Washington, D.C.: CCSDS, February 2019.

[50] Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry

Applications. Issue 2. Recommendation for Space Data System Standards (Blue Book),

CCSDS 131.2-B-2. Washington, D.C.: CCSDS, February 2023.

[51] CCSDS Space Link Protocols over ETSI DVB-S2 Standard. Issue 2. Recommendation

for Space Data System Standards (Blue Book), CCSDS 131.3-B-2. Washington, D.C.:

CCSDS, April 2022.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 1-7 April 2023

[52] CCSDS Spacecraft Identification Field Code Assignment Control Procedures. Issue 7.

Recommendation for Space Data System Practices (Magenta Book), CCSDS 320.0-M-7.

Washington, D.C.: CCSDS, November 2017.

[53] Security Architecture for Space Data Systems. Issue 1. Recommendation for Space

Data System Practices (Magenta Book), CCSDS 351.0-M-1. Washington, D.C.:

CCSDS, November 2012.

[54] CCSDS Cryptographic Algorithms. Issue 2. Recommendation for Space Data System

Standards (Blue Book), CCSDS 352.0-B-2. Washington, D.C.: CCSDS, August 2019.

[55] 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.

[56] 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.

[57] 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.

[58] Space Data Link Security Protocol—Extended Procedures. Issue 1. Recommendation

for Space Data System Standards (Blue Book), CCSDS 355.1-B-1. Washington, D.C.:

CCSDS, February 2019.

[59] Overview of the Unified Space Data Link Protocol. Issue 1. Report Concerning Space

Data System Standards (Green Book), CCSDS 700.1-G-1. Washington, D.C.: CCSDS,

June 2020.

[60] Space Communications Cross Support—Architecture Requirements Document. Issue 1.

Recommendation for Space Data System Practices (Magenta Book), CCSDS 901.1-M-

1. Washington, D.C.: CCSDS, May 2015.

[61] Spectral Preprocessing Transform for Multispectral and Hyperspectral Image

Compression. Issue 1. Recommendation for Space Data System Standards (Blue Book),

CCSDS 122.1-B-1. Washington, D.C.: CCSDS, September 2017.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

2 INTRODUCTION TO SPACE COMMUNICATIONS PROTOCOLS

2.1 HISTORY OF SPACE COMMUNICATIONS PROTOCOLS

Traditionally, telemetry transmitted from the spacecraft was formatted with a Time Division

Multiplexing (TDM) scheme in which data items were multiplexed into a continuous stream

of fixed-length frames based on a predefined multiplexing rule. To design and implement a

data system for spacecraft, each project was forced to develop a custom system used by that

project alone, with the exception of the ground tracking network, because of the lack of

established standards in this field.

The advent of microprocessor-based spacecraft instruments and subsystems, however,

enabled telemetry systems to become more flexible and have greater throughput so that data

processed by onboard software could be transmitted efficiently.

In the early 1980s, CCSDS developed an international standard for a Packet Telemetry

protocol capable of sending processed telemetry efficiently using a variable-length data unit

called the Source Packet. Source Packets generated by various instruments and subsystems

on a spacecraft are transmitted to the ground in a stream of continuous, fixed-length Transfer

Frames. This standard has been used by many space projects enabling them to share onboard

and ground data processing equipment.

Based on a similar concept, another international standard on Telecommand was developed

by CCSDS, shortly after Packet Telemetry, for sending commands to a spacecraft with a data

unit known as the TC Packet. TC Packets destined for various instruments and subsystems

on a spacecraft are transmitted from the ground in a stream of sporadic, variable-length

Transfer Frames.

In the late 1980s, CCSDS extended the above standards to meet the requirements of the

Advanced Orbiting Systems (AOS), such as the International Space Station, and came up

with a third standard known as AOS. The AOS standard added to the Packet Telemetry

standard services for transmitting various types of online data (such as audio and video data),

and it may be used on both space-to-ground and ground-to-space links. The AOS uses the

same packet structure as the Packet Telemetry standard, but the frame format is slightly

different.

These three standards (Packet Telemetry, Telecommand, and AOS) were later restructured by

CCSDS in order to define the protocols in a more structured and unified way, and the

following standards replaced the original standards:

a) Space Packet Protocol (SPP) (reference [4]);

b) TM, TC, and AOS Space Data Link Protocols (references [5], [6], and [7],

respectively);

c) TM and TC Synchronization and Channel Coding (references [8] and [9],

respectively).

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-2 April 2023

As an international standard for the Radio Frequency (RF) signal between a spacecraft and a

ground station, CCSDS developed a standard called Radio Frequency and Modulation

Systems (reference [10]). This standard specifies the characteristics of the RF signal used to

carry Packets and Frames.

In the 1990s, CCSDS developed another set of protocols collectively known as Space

Communications Protocol Specifications (SCPS), which include SCPS Network Protocol

(SCPS-NP) (reference [11]), SCPS Security Protocol (SCPS-SP) (reference [12]), SCPS

Transport Protocol (SCPS-TP) (reference [13]), and SCPS File Protocol (SCPS-FP)

(reference [14]). The SCPS protocols are generally based on Internet protocols, but

modifications and extensions to the Internet protocols are incorporated in the design of the

SCPS protocols to meet the specific needs of space missions. CCSDS has retired all of the

SCPS protocols with the exception of SCPS-TP.

In response to the needs of space missions to transfer files to and from an onboard mass

memory, CCSDS has developed a protocol called the CCSDS File Delivery Protocol (CFDP)

(reference [15]). This protocol provides the capability to transfer files reliably and efficiently

over an unreliable protocol (for example, the Space Packet Protocol).

In July 1998, following the successes with relay experiments for Mars spacecraft, NASA

began investigating the design for a standard protocol that can provide ‘Internet-like’

services to spacecraft that may be in deep-space and/or only intermittently-connected to

Earth. A team of researchers was formed that included Dr. Vint Cerf, co-author of the

TCP/IP protocols. Today, Delay Tolerant Networking (DTN) (references [55] and [56])

provides a general-purpose Network/Transport-Layer service that is logically similar to what

TCP/IP provides for the terrestrial Internet, but suitable for use in the space environment. In

addition to the basic store-and-forward internetworking service, DTN also provides efficient

reliability, security, in-order delivery, duplicate suppression, class of service (prioritization),

remote management, a ‘DVR-like’ streaming service, rate buffering, and data accounting, all

over possibly asymmetric and time-disjoint paths. Multiple applications, including file

transfer, messaging (e.g., for mission operations), and streaming audio/video, can all be

implemented on top of DTN and leverage its services to reduce risk, cost, and complexity.

CCSDS has other specifications that individually implement some aspects of the network and

transport-layer services that DTN provides, but none of them provide the flexibility or

automated data transfer that DTN does.

In the area of data compression, CCSDS has developed standards for general-purpose

lossless data compression (reference [16]), compressors specialized for compression of two-

dimensional image data (reference [17]), and three-dimensional (multispectral/hyperspectral)

images (references [49] and [61]), either to increase the science return or to reduce the

requirement for onboard memory, station contact time, and data archival volume. The first

standard provides lossless compression, guaranteeing full reconstruction of the original data

without incurring any distortion in the process. The other standards can be used to provide

lossless or lossy/near-lossless compression, in which case, quantization or other

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-3 April 2023

approximations used in the compression process may result in the inability to reproduce the

original data set without some distortion, but in return for higher compression ratios.

Recently CCSDS has developed a protocol called Proximity-1 Space Link Protocol

(references [18], [19], [20], and [32]), to be used over proximity space links. Proximity space

links are defined to be short range, bi-directional, fixed or mobile radio links, generally used to

communicate among fixed probes, landers, rovers, orbiting constellations, and orbiting relays.

This protocol defines a data link protocol (reference [18]), coding and synchronization methods

(reference [19]), and RF and modulation characteristics (reference [20]).

In addition, CCSDS in 2018 released the Unified Space Data Link Protocol (USLP)

(reference [57]). This protocol has been designed to meet the requirements of space missions

for efficient transfer of space application data of various types and characteristics over space-

to-ground, ground-to-space, or space-to-space communications links. It is envisioned that

USLP will be used as the data link layer protocol for all future robotic and crewed space

missions.

Security is of great concern to many space missions. CCSDS has published several

documents, including The Application of CCSDS Protocols to Secure Systems

(reference [37]), Security Architecture for Space Data Systems (reference [53]), CCSDS

Cryptographic Algorithms (reference [54]), the Space Data Link Security (SDLS) protocol,

and the SDLS Extended Procedures (references [43] and [58]), to provide guidance to

missions that wish to use the CCSDS space communications protocols for spacecraft control

and data handling but also require a level of security or data protection.

2.2 PROTOCOL LAYERS

2.2.1 SUMMARY

A communications protocol is usually associated with one of the seven layers defined in the

OSI Basic Reference Model (reference [2]). Although some space communications protocols

do not fit well with the OSI seven-layer model, this Report uses this model for categorizing

the space communications protocols.

The space communications protocols are defined for the following five layers of the ISO

model:

a) Physical Layer;

b) Data Link Layer;

c) Network Layer;

d) Transport Layer;

e) Application Layer.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-4 April 2023

As in most terrestrial networks, protocols of the Session and Presentation Layers of the OSI

model are rarely used over space links.

Figure 2-1 shows the space communications protocols categorized into upper layers

(Network, Transport, and Application) as well as the Physical and Data Link Layers.

LTP

AMSCFDP

LTPCLA ENCAPCLA TCPCLA

UDPCLA

TCP

IPoC

LTP

RF/Optical

USLP TM TC AOS Prox-1 Ethernet

Wire

UDP

Physical Layer

Data Link Layer

Either Encapsulation Packet Protocol or Space Packet Protocol

Upper Layers

Space Data Link Layer Protocols

SPP

MO-MAL

Figure 2-1: Space Communications Protocols Reference Model

CCSDS does not formally define Application Program Interfaces (APIs) for the space

communications protocols, but most CCSDS standards provide abstract service definitions in

the form of primitives following the conventions established by ISO (see reference [21]). A

primitive is an abstract representation of the services provided by the protocol layer, but it

does not depend on any implementation technology. This abstract specification may be used

as a reference for developing an API.

In the following subsections, the protocols shown in figure 2-1 are briefly introduced. Major

features of these protocols will be explained in section 3.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-5 April 2023

2.2.2 PHYSICAL LAYER

CCSDS has an omnibus standard for the Physical Layer called the Radio Frequency and

Modulation Systems (reference [10]), to be used for space links between spacecraft and

ground stations. The Proximity-1 Space Link Protocol also contains recommendations for

the Physical Layer of proximity space links (reference [20]).

2.2.3 DATA LINK LAYER

CCSDS defines two Sublayers in the Data Link Layer of the OSI Model: the Data Link

Protocol Sublayer and the Synchronization and Channel Coding Sublayer. The Data Link

Protocol Sublayer specifies methods of transferring data units provided by the higher layer

over a point-to-point space link using data units known as Transfer Frames. The

Synchronization and Channel Coding Sublayer specifies methods of synchronization and

channel coding for transferring Transfer Frames over a space link.

CCSDS has developed several protocols for the Data Link Protocol Sublayer of the Data Link

Layer:

a) TM Space Data Link Protocol (reference [5]);

b) TC Space Data Link Protocol (reference [6]);

c) AOS Space Data Link Protocol (reference [7]);

d) Proximity-1 Space Link Protocol—Data Link Layer (reference [18]);

e) USLP (reference [57]).

The above protocols provide the capability to send data over a single space link. TM, TC,

AOS, and USLP have provisions for inserting secured user data into a frame using the SDLS

Protocol (reference [43]) and the associated SDLS Extended Procedures (reference [58]).

However, there have been no security requirements to date established for Proximity-1. The

SDLS protocol can provide security services, such as authentication and confidentiality, for

TM Transfer Frames, AOS Transfer Frames, TC Transfer Frames, or USLP Transfer Frames.

It should be noted that the use of the SDLS function within these protocols is optional. The

SDLS Extended Procedures provides Key and Security Associations management services

needed to operate an SDLS secured space link.

CCSDS has developed three standards for the Synchronization and Channel Coding Sublayer

of the Data Link Layer:

a) TM Synchronization and Channel Coding (reference [8]);

b) TC Synchronization and Channel Coding (reference [9]);

c) Proximity-1 Space Link Protocol—Coding and Synchronization Layer (reference [19]);

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-6 April 2023

d) Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry

Applications (reference [50]), or ‘SCCC’;

e) CCSDS Space Link Protocols over ETSI DVB-S2 Standard (reference [51]), or ‘DVB-S2’.

TM Synchronization and Channel Coding is used with the TM or AOS Space Data Link

Protocol or USLP, TC Synchronization and Channel Coding is used with the TC Space Data

Link Protocol or USLP, and the Proximity-1 Space Link Protocol—Coding and

Synchronization Layer is used with the Proximity-1 Space Link Protocol or USLP.

The TM, TC, and AOS Space Data Link Protocols; the Proximity-1 Space Link Protocol

(Data Link Layer); and USLP are called the Space Data Link Protocols in this document.

2.2.4 BETWEEN DATA LINK AND NETWORK LAYERS

Licklider Transmission Protocol (LTP) provides optional reliability mechanisms on top of an

underlying (usually data link layer) communication service.

From the point of view of protocols above LTP (e.g., Bundle Protocol), the service LTP

provides is optionally reliable delivery of layer-(N+1) Protocol Data Units (PDUs) across a

link. Layer-(N+1) PDUs are encapsulated within LTP blocks, which are segmented for

transmission over data link protocols; typically, each LTP segment is encapsulated within a

single link-layer protocol data unit, that is, an Encapsulation Packet. It should be noted that

LTP segments may also be encapsulated within Space Packets. The limited size of the Space

Packet does not in itself argue against the use of Space Packets to carry DTN traffic, because

large bundles encapsulated within large LTP blocks will in most cases be segmented into

smaller LTP segments for transmission. However, the reduced overhead of the Encapsulation

Packet makes it a more bandwidth-efficient alternative to the Space Packet. For more

information, see reference [56]).

CCSDS-recognized Internet datagrams (listed in reference [44]) can also be transferred by

CCSDS Space Data Link Protocols over a space link, multiplexed or not-multiplexed, using

the shim protocol, IP over CCSDS (reference [45]).

2.2.5 NETWORK LAYER

Space communications protocols of the Network Layer provide the function of routing or

forwarding higher-layer data through the entire data system that includes both onboard and

ground subnetworks.

CCSDS recognizes two standards for interfacing at the Network Layer:

a) CCSDS-recognized Internet Protocol datagrams (listed in reference [44]);

b) The DTN architecture’s Bundle Protocol (references [55] and [56]).

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-7 April 2023

Delay Tolerant Networking is an architecture that provides automated network

communications much as the Internet architecture does, but it does so over networks

characterized by one or more of the following:

– intermittent connectivity;

– variable delays, which may be large and irregular;

– high bit error rates;

– asymmetric and simplex links.

One core element of DTN is the Bundle Protocol (BP), which serves as the network-layer

protocol in a delay-tolerant network. BP provides end-to-end network services, operating

above the data transport services provided by links or networks accessed via Convergence

Layer Adapters (CLAs),

and forming a store-and-forward network; a BP-based network is

an ‘overlay’ network that may span multiple networks just as the Internet is an overlay

network that spans multiple subnets or local area networks. The Bundle Protocol uses the

‘native’ local protocols (at what is termed the ‘convergence layer’) for communications

within a given network. The interface between the Bundle Protocol and a specific lower-layer

protocol suite is known as a convergence layer adapter. Figure 2-1 shows within the protocol

reference model the Bundle Protocol and several optional convergence layer adapters. On the

right, two CLAs running above a transport protocol (intended to be interpreted in the context

of the Internet stack) are shown. On the left, the two CLAs running over LTP and the CLA

running on EPP/SPP are shown. (For more information, see reference [56].)

2.2.6 TRANSPORT LAYER

Space communications protocols of the Transport Layer provide users with end-to-end

transport services.

CCSDS has developed SCPS-TP (reference [13]) for the Transport Layer.

PDUs of a Transport Layer protocol are usually transferred with a protocol of the Network

Layer over a space link, but they can be transferred directly by a Space Data Link.

Transport protocols used in the Internet (such as TCP, reference [24], and UDP, reference [25])

can also be used on top of IP datagrams over CCSDS space links, reference [45]. IPSec

(reference [27]) may be used with a Transport protocol of the Internet suite to provide end-

to-end data protection capability.

convergence layer adapter, CLA: Adapter that sends and receives bundles on behalf of

the Bundle Protocol Adapter, that is, the Node component that offers the BP services and

executes the procedures of the Bundle Protocol.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 2-8 April 2023

2.2.7 APPLICATION LAYER

Space communications protocols of the Application Layer provide users with end-to-end

application services such as file transfer and data compression.

CCSDS has developed several protocols for the Application Layer:

a) Asynchronous Messaging Service (AMS) (reference [46]);

b) CFDP (reference [15]);

c) Lossless Data Compression (reference [16]);

d) Image Data Compression (reference [17]);

e) Multispectral & Hyperspectral Image Compression (references [49] and [61]);

f) Space Packet Protocol (reference [4]);

g) Message Abstraction Layer (MAL) Space Packet Transport Binding and Binary

Encoding (reference [47]).

AMS is an application layer protocol for end-to-end mission data system message transfer.

CFDP provides the functionality of the Application Layer (i.e., functions for file

management). The CFDP Store-and-Forward Overlay procedures provide application-

specific transfer of data across multiple link-layer hops.

Each project (or Agency) may also elect to use application-specific protocols not

recommended by CCSDS to fulfill their mission requirements in the Application Layer over

CCSDS space communications protocols.

PDUs of an Application Layer protocol are usually transferred with a protocol of the

Transport Layer over a space link, but they can be transferred directly with a protocol of the

Network Layer.

For the Space Packet Protocol, PDUs are generated and consumed by application processes

that are on a spacecraft or on the ground.

CCSDS Encapsulation Packet Protocol allows encapsulation of PDUs of CCSDS-recognized

protocols, as defined in a SANA registry (reference [48]) into Encapsulation Packets (one

PDU per Encapsulation Packet). These packets can then be transferred over a space link

using the VC/MAP Packet Service provided by CCSDS Space Data Link Protocols.

Applications protocols used in the Internet (such as FTP, reference [26]) can also be used on

top of SCPS-TP, TCP, and UDP over space links.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

3 MAJOR FEATURES OF SPACE COMMUNICATIONS

PROTOCOLS

3.1 PHYSICAL LAYER

The CCSDS Recommended Standard for Radio Frequency and Modulation Systems

(reference [10]) recommends the characteristics of the RF and modulation systems used for

communications over space links between spacecraft and ground stations.

The Proximity-1 Space Link Protocol—Physical Layer (reference [20]) also contains

recommendations for the Physical Layer of proximity space links.

3.2 DATA LINK LAYER

3.2.1 GENERAL FEATURES OF DATA LINK PROTOCOLS

CCSDS has developed four protocols for the Data Link Protocol Sublayer of the Data Link

Layer:

a) TM Space Data Link Protocol (reference [5]);

b) TC Space Data Link Protocol (reference [6]);

c) AOS Space Data Link Protocol (reference [7]);

d) USLP Data Link Layer (reference [57]);

e) Data Link Protocol Sublayer portion of Proximity-1 Space Link Protocol

(reference [18]).

These protocols (collectively known as Space Data Link Protocols) provide the capability to

transfer various types of data on space links, but their principal function is to transfer

variable-length data units known as packets.

Each packet format transferred by the Space Data Link Protocols must have a Packet Version

Number (PVN) recognized by CCSDS. These numbers are contained in SANA

(reference [28]). Packets with authorized Packet Version Numbers can be transferred by the

Space Data Link Protocols directly, but CCSDS has another mechanism to transfer PDUs of

CCSDS and non-CCSDS protocols using the Encapsulation Packet Protocol, defined in

reference [29]. With this service, packets are transferred by the Space Data Link Protocols

encapsulated in either Space Packets defined in reference [4] or Encapsulation Packets defined

in reference [29].

The TM Space Data Link Protocol is usually used for (but not limited to) sending telemetry

from a spacecraft to a ground station (i.e., on a return link). The TC Space Data Link

Protocol is usually used for (but not limited to) sending commands from a ground station to a

spacecraft (i.e., on a forward link). The AOS Space Data Link Protocol may be used on a

return link alone, or on both forward and return links if there is a need for two-way higher-

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-2 April 2023

speed communications (e.g., audio and video) between a spacecraft and the ground. The

Proximity-1 Space Link Protocol is to be used over proximity space links, for which

proximity space links are defined to be short range, bi-directional, fixed or mobile radio

links, generally used to communicate among fixed probes, landers, rovers, orbiting

constellations, and orbiting relays. The Unified Space Link Protocol can be used over space-

to-ground, ground-to-space, or space-to-space communications links by space missions. It is

envisioned that USLP may be used by future space missions in lieu of TM, TC, AOS, and

Proximity-1.

The protocol data units used by the Space Data Link Protocols are called Transfer Frames.

TM, AOS, and USLP use fixed-length Transfer Frames to facilitate robust synchronization

procedures over a noisy link; TC, Proximity-1, and USLP use variable-length Transfer

Frames to facilitate reception of variable-length messages with various latency requirements

for telecommand.

A key feature of all the Space Data Link Protocols is the concept of ‘Virtual Channels’. The

Virtual Channel facility allows one Physical Channel (a stream of bits transferred over a

space link in a single direction) to be shared among multiple higher-layer data streams, each

of which may have different service requirements. A single Physical Channel may therefore

be divided into several separate logical data channels, each known as a Virtual Channel

(VC). Each Transfer Frame transferred over a Physical Channel belongs to one of the Virtual

Channels of the Physical Channel.

All Transfer Frames with the same Master Channel ID (MCID), that is, Transfer Frame

Version Number (TFVN) + Spacecraft ID (SCID) on a Physical Channel, constitute a Master

Channel (MC). A Master Channel consists of one or more VCs. In most cases, a Physical

Channel carries only Transfer Frames of a single MCID, and the MC will be identical with

the Physical Channel. However, a Physical Channel may carry Transfer Frames with multiple

MCIDs (with the same TFVN, but different SCIDs). In such a case, the Physical Channel

consists of multiple MCs.

Both the TC Space Data Link Protocol and USLP have a function for retransmitting lost or

corrupted data to ensure delivery of data in sequence without gaps or duplication over a space

link. This function is provided by a retransmission control mechanism called the

Communications Operation Procedure-1 (COP-1), which is defined in a separate document

(reference [30]). (This function does not necessarily guarantee end-to-end complete delivery.)

Both the Proximity-1 Space Link Protocol and USLP also have a similar function called

COP-P, which is defined in the Data Link Layer Recommended Standard (reference [18]).

Neither the TM Space Data Link Protocol nor the AOS Space Data Link Protocol has such a

function, so retransmission must be done by a higher-layer protocol if complete delivery of

data is required.

The TM and AOS Space Data Link Protocols, along with USLP, can be used together with

the TM Synchronization and Channel Coding Recommended Standard (reference [8]). The

TC Space Data Link Protocol, along with USLP, can be used together with the TC

Synchronization and Channel Coding Recommended Standard (reference [9]). The TM, TC,

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-3 April 2023

AOS Space Data Link Protocols and USLP can be used on top of the Recommended

Standard for Radio Frequency and Modulation Systems (reference [10]).

Proximity-1 Space Link Protocol—Data Link Layer (reference [18]) as well as USLP can be

used together with the Proximity-1 Space Link Protocol—Coding and Synchronization

Sublayer (reference [19]), and on top of the Proximity-1 Space Link Protocol—Physical

Layer (reference [20]).

A summary of the concept and rationale of the TM, TC, and AOS Space Data Link Protocols

is contained in reference [31]. Similarly for Proximity-1 Space Link Protocol, that

information is contained in reference [32], and for the USLP, in reference [59].

3.2.2 IDENTIFIERS USED BY DATA LINK PROTOCOLS

The Space Data Link Protocols provide link identifiers to identify data streams. The identifier

names as well as their values reside in the Space Assigned Numbers Authority (SANA).

SANA is the registrar for all protocol registries created under CCSDS. SANA replaces the

retired Space Link Identifiers Blue Book. The CCSDS Global Spacecraft Identification Field:

Code Assignment Control Procedures Magenta Book (reference [52]) contains the

procedures governing requesting, assigning, and relinquishing CCSDS SCID field codes.

The TM, TC, AOS, and USLP Space Data Link Protocols have the following three

identifiers: TFVN, SCID, and the Virtual Channel Identifier (VCID).

The TFVN is used to distinguish among different Transfer Frames. However, different

Transfer Frames must not be multiplexed on a Physical Channel.

The concatenation of a TFVN and a SCID is known as an MCID, which is used for

identifying a spacecraft associated with a space link.

All Transfer Frames with the same MCID on a Physical Channel constitute an MC. A

Master Channel consists of one or more Virtual Channels, each of which is identified with a

VCID. In most cases, a Physical Channel carries only Transfer Frames of a single MCID,

and the Master Channel will be identical with the Physical Channel. However, a Physical

Channel may carry Transfer Frames with multiple MCIDs (with the same TFVN). In such a

case, the Physical Channel consists of multiple Master Channels. A Physical Channel is

identified with a Physical Channel Name, which is set by management and not included in

the header of Transfer Frames.

Both the TC Space Data Link Protocol and USLP uses an optional identifier, called the

Multiplexer Access Point Identifier (MAP ID), that is used to create multiple streams of data

within a Virtual Channel. All the Transfer Frames on a Virtual Channel with the same MAP ID

constitute a MAP Channel. If the MAP ID is used, a Virtual Channel consists of one or multiple

MAP Channels.

Figure 3-1 shows the relationship among the channels of TM, TC, AOS and USLP.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-4 April 2023

MAP Channel (TC or USLP; Optional):

Identified by MAP ID

Physical Channel:

Identified by Physical Channel Name

Virtual Channel (VC):

Identified by VCID

Master Channel (MC):

Identified by MCID=TFVN+SCID

Figure 3-1: Relationships between Channels of the Space Data Link Protocols

The Proximity-1 Space Link Protocol—Data Link Layer uses a triad of multiplexing

capabilities, which is incorporated for specific functionality within the link. The SCID

identifies the source or destination of Transfer Frames transported in the link connection

based upon the Source-or-Destination Identifier. The Physical Channel Identifier (PCID)

provides up to two independently multiplexed channels. The Port ID provides the means to

route user data internally (at the transceiver’s output interface) to specific logical ports, such

as applications or transport processes, or to physical ports, such as onboard buses or physical

connections (including hardware command decoders).

Table 3-1 summarizes the identifiers of the Space Data Link Protocols. The values of these

IDs are maintained by the SANA registries (reference [48]).

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-5 April 2023

Table 3-1: Identifiers of Space Data Link Protocols

Identifiers

TM Space

Data Link

Protocol

TC Space

Data Link

Protocol

AOS Space

Data Link

Protocol

Proximity-1

Space Link

Protocol—Data

Link Layer

USLP

TFVN

Version 1

Synchronous

Transfer

Frame

Version 1

Asynchronous

Transfer

Frame

Version 2 AOS

Synchronous

Transfer Frame

Version 3

Proximity-1

Transfer Frame

Version 4 USLP

Transfer Frame

SCID

0 to 1023

0 to 255

0 to 1023

0 to 65535

PCID

N/A

0 to 1

N/A

VCID

0 to 7

0 to 63

N/A

0 to 63

MAP ID

N/A

0 to 63

N/A

0 to 15

Port Identifier

N/A

0 to 7

N/A

3.2.3 SERVICES PROVIDED BY DATA LINK PROTOCOLS

The Space Data Link Protocols provide several services to transfer a variety of data on a

space link. The most important service is a service to transfer variable-length data units

known as packets (i.e., protocol data units of protocols of the Network Layer). In addition to

this service, the Space Data Link Protocols provide services to transfer fixed- or variable-

length data units with private (non-CCSDS) formats, short fixed-length data units for

reporting on real-time functions, and bit streams.

Table 3-2 shows a summary of the services provided by the TM/TC/AOS/USLP Space Data

Link Protocols categorized by the types of data transferred by the services. For complete

definition of these services, refer to references [5], [6], [7], and [57].

NOTE – The Proximity-1 Space Link Protocol—Data Link Layer is not included in this

table because no formal service definition is given in the Recommended Standard

(references [18]).

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-6 April 2023

Table 3-2: Summary of Services Provided by Space Data Link Protocols

Type of

Service

Data Units

TM Space Data

Link Protocol

TC Space Data

Link Protocol

AOS Space Data

Link Protocol

USLP

Packets

(NOTE 1)

Virtual Channel

Packet Service

MAP Packet

Service,

VC Packet Service

Virtual Channel

Packet Service

MAP Packet

Service

Fixed-length

private data

Virtual Channel

Access Service

(None)

Virtual Channel

Access Service

MAP Access

Service

Variable-length

private data

(None)

MAP Access

Service,

VC Access

Service

(None)

MAP Access

Service

Short fixed-

length data

VC FSH Service

(NOTE 2),

MC FSH Service,

VC OCF Service

(NOTE 3),

MC OCF Service

(None)

Insert Service,

VC OCF Service

(NOTE 3)

Insert Service,

USLP MC OCF

Service

Stream

(None)

Bitstream Service

Octet Stream

Service

Transfer

Frames

VC Frame Service,

MC Frame Service

VC Frame Service,

MC Frame Service

VC Frame Service,

MC Frame Service

VC Frame Service,

MC Frame Service

NOTES

1 Packets directly transferred by the Space Data Link Protocols must have Packet

Version Numbers authorized by CCSDS. These Packet Version Numbers are found

in reference [28]. Other PDUs of CCSDS recognized protocols can be transferred

using the Encapsulation Packet Protocol defined in reference [29].

2 FSH = Frame Secondary Header.

3 OCF = Operational Control Field.

3.2.4 SYNCHRONIZATION AND CHANNEL CODING

The standards of the Synchronization and Channel Coding Sublayer provide some additional

functions necessary for transferring Transfer Frames over space links. These functions are

delimiting/synchronizing Transfer Frames, error-correction coding/decoding, and bit transition

generation/removal. CCSDS has five standards for Synchronization and Channel Coding:

a) A set of three TM specifications:

1) TM Synchronization and Channel Coding (reference [8]),

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-7 April 2023

2) Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry

Applications (reference [50]), or ‘SCCC’,

3) CCSDS Space Link Protocols over ETSI DVB-S2 Standard (reference [51]), or

‘DVB-S2’;

b) TC Synchronization and Channel Coding (reference [9]);

c) Proximity-1 Space Link Protocol—Coding and Synchronization Sublayer

(reference [19]).

The three TM specifications define alternative synchronization and channel coding schemes

used with the TM, AOS, or USLP Space Data Link Protocol. TC Synchronization and

Channel Coding defines synchronization and channel coding schemes used with the TC or

USLP Space Data Link Protocol. Proximity-1 Space Link Protocol—Coding and

Synchronization Sublayer defines synchronization and channel coding schemes used with

both the Proximity-1 Space Link Protocol or USLP.

Options a-2) and a-3) are recommended only for high rate downlink.

The various coding specifications offer to the Data Link Protocol sublayer two types of

services at the sending end:

a) for fixed-length frames provided periodically to the lower layer at sending end (see

reference [8]);

b) for variable-length frames provided intermittently to the lower layer at sending end

(see references [9] and [19]).

While the first service is always delivering validated frames at the receiving end, the latter

type of service can present two different qualities of service at the receiving end:

a) delivering NOT validated frames at receiving end (see reference [9]); or

b) delivering validated frames at receiving end (see reference [19]).

Table 3-3 summarizes the functions and schemes provided by the Synchronization and

Channel Coding standards.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-8 April 2023

Table 3-3: Functions of Synchronization and Channel Coding Standards

Functions

TM Synchronization and

Channel Coding

TC Synchronization

and Channel Coding

Proximity-1 Space

Link Protocol—

Coding and

Synchronization

Layer

Error Correction

Scheme +

Frame

Validation

(see NOTE 3)

– Convolutional Coding + FECF;

– Reed Solomon Coding;

– Concatenated Coding;

– Turbo Coding + FECF ;

– Low-Density Parity-Check

(LDPC) Coding;

– SCCC + FECF;

– DVB-S2 + FECF

– BCH Coding

– BCH Coding + FECF

– Convolutional Coding

+ Attached CRC;

– LDPC Coding +

Attached CRC;

Pseudo-

Randomization

(see NOTE 3)

Cyclic pseudo-noise

sequence*

Cyclic pseudo-noise

sequence*

Cyclic pseudo-noise

sequence (used

mandatorily—only for

LDPC Coding)

Frame

Synchronization

32-bit (or longer) Attached

Sync Marker (ASM) depending

on applied coding scheme

16-bit Start Sequence

24-bit ASM

NOTES

1 ‘*’ in the table denotes an optional function.

2 When a box of the table shows several options, only one option can be applied at a

given time.

3 When only an Error Correction scheme is mentioned, it means that the scheme is also

capable of validating the frame, that is, declaring it erroneous or error free. In other

cases, for TM/TC/AOS/USLP, a Frame Error Control Field is used for error

detection, while Proximity-1 uses a Cyclic Redundancy Code (CRC) attached to the

frame (but not part of the frame). The Frame Error Control Field is defined in the

Recommended Standards on the TM/TC/AOS/USLP Space Data Link Protocols, and

not in the Recommended Standards on Synchronization and Channel Coding.

4 The cyclic pseudo-noise sequence used by TM Synchronization and Channel Coding

differs from that one used for both TC Synchronization and Channel Coding and

Proximity-1 Space Link Protocol—Coding and Synchronization Layer.

Summaries of concept and rationale for TM Synchronization and Channel Coding, TC

Synchronization and Channel Coding, and Proximity-1 Space Link Protocol—Coding and

Synchronization Layer are contained in references [33], [34], and [32], respectively.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-9 April 2023

3.3 NETWORK LAYER

3.3.1 GENERAL FEATURES OF NETWORK PROTOCOLS

Data Forwarding differs greatly from data routing, defined in reference [60] as ‘the process

of selecting paths from origins to destinations in a network’. Here, the concept of an endpoint

is global over a series of open and extensible subnetworks. Whenever routing is done across

multiple subnetworks, a network routing protocol is required, which is not in the purview of

SPP. It is essential that when one plans to route data over an open network composed of

multiple subnetworks, one uses a network protocol.

By using the Encapsulation Packet Protocol as a shim, other CCSDS-recognized Network

Protocols such as BP (references [55] and [56]) and IP can be used over space links. The data

units of network protocols can also be transferred using the Space Packet Protocol done in a

mission-specific manner using APID(s) as set by management. Over a space link, protocol

data units of the network protocols (i.e., BP, IP, or others carried through SPP or EPP) are

transferred within the Space Data Link Protocols. In particular, the Space Data Link

Protocols have the capability to carry several protocol data units of the Internet Protocol,

multiplexed or not-multiplexed, within the Encapsulation packet. IP over CCSDS

(reference [45]) specifies how CCSDS-recognized IP datagrams are transferred over the link.

3.3.2 ADDRESSING OF NETWORK PROTOCOLS

An End System Identifier, as used by IP and BP, unambiguously identifies a single end

system or a group of end systems. If it is necessary to identify both the source and

destination when using End System Identifiers, a pair of End System Identifiers must be

used. These identifiers, which either identify or map to locations in network topology, are

specified in the IP or BP PDUs, and they are used by the IP or BP routing nodes to perform

routing decisions at each step along the end-to-end path.

As already mentioned, CCSDS Encapsulation Packet Protocol allows the use of other

CCSDS recognized Network Protocols within their own end system identification notations.

CCSDS developed Delay Tolerant Networking (references [55] and [56]) as the means to

perform interoperable internetworking in space, in either disrupted or delayed end-to-end

communication environments.

3.4 TRANSPORT LAYER

CCSDS has developed SCPS-TP (reference [13]) for the Transport Layer. CFDP (reference [15])

also provides the functionality of the Transport Layer, but it provides some functions (i.e.,

functions for file management) of the Application Layer as well.

SCPS-TP supports end-to-end communications between applications and is designed to meet

the needs of a broad range of space missions. It defines extensions to TCP and incorporates

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-10 April 2023

UDP by reference. It may be used on top of the Space Packet, Encapsulation Packet, or IP

over CCSDS.

CFDP provides the functionality of the Application Layer (i.e., functions for file

management), but it also provides functions of the Transport Layer.

Transport protocols used in the Internet (such as TCP, reference [24], and UDP, reference [25])

can also be used on top of the Encapsulation packet, or IP over CCSDS space links.

IPSec (reference [27]) can be used with the Internet Protocol suite to provide end-to-end data

protection capability.

3.5 APPLICATION LAYER

CCSDS has developed several protocols for the Application Layer:

a) AMS (reference [46]);

b) CFDP (reference [15]);

c) Lossless Data Compression (reference [16]);

d) Image Data Compression (reference [17]);

e) Low-Complexity Lossless and Near-Lossless Multispectral and Hyperspectral Image

Compression (references [49]);

f) Spectral Preprocessing Transform for Multispectral & Hyperspectral Image

Compression (reference [61]);

g) Space Packet Protocol (reference [4]).

AMS implements an interoperable protocol under which the mission modules (distinct

sequential flows of application control logic, whether called processes, tasks, or threads, each

one producing and consuming mission information) may be designed without explicit

awareness of which other modules are currently operating or of where they are deployed.

CFDP is designed to meet the needs of space missions to transfer files. It is a file transfer

protocol, but it also provides services typically found in the Transport Layer, that is,

complete, in-order, and without duplicate data delivery. It can be used on top of any protocol

of the Network Layer (i.e., IP over CCSDS or DTN BP), on top of the Space Packet Protocol

(mission specific APID assignment to CFDP required) or Encapsulation Packet Protocol, or

directly on top of the CCSDS Space Data Link Protocols if a Virtual Channel, a MAP, or a

Port is assigned to CFDP. In some circumstances, it can be used on top of UDP, TCP, or

SCPS-TP. Alternatively, CFDP can be used in Unacknowledged Mode (i.e., with Transport

Layer functionality disabled) on top of DTN (BP/LTP, providing Transport Layer

functionality at the layer underlying CFDP). A summary of concept and rationale of CFDP is

contained in reference [35].

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-11 April 2023

The Lossless Data Compression standard was developed to increase the science return as

well as to reduce the requirement for onboard memory, station contact time, and data archival

volume. This standard guarantees full reconstruction of the original data without incurring

any distortion in the process. It is intended to be used together with the Space Packet

Protocol or CFDP. A summary of concept and rationale of Lossless Data Compression is

contained in reference [36].

The Image Data Compression standard was developed to establish a standard for a data

compression algorithm applied to digital image two-dimensional spatial data from payload

instruments. With this standard, quantization or other approximations used in the

compression process may result in the inability to reproduce the original data set without

some distortion. It is intended to be used together with the Space Packet Protocol, CFDP, or

the AOS Space Data Link Protocol.

Compression standards for multispectral and hyperspectral images (references [49] and [61],

respectively) exploit the three-dimensional structure of such images to provide effective

compression. Reference [49] specifies a compression approach capable of providing lossless

compression as well as near-lossless compression, in which case the error in the reconstruted

image is guaranteed to meet a user-specified maximum allowed error. Reference [61] defines

a spectral preprocessing transform to be used in conjunction with the two-dimensional image

compressor specified in reference [17].

Applications protocols used in the Internet can be used over TCP (with or without the SCPS-TP

extensions) or UDP, as long as the underlying links are sufficiently short (<1 sec) and

continuously available. Typically, an application is written to use the reliable stream-oriented

service of TCP or the unreliable datagram service of UDP, but not both. Some exceptions to

this exist, however, in which applications are written to operate over either service.

Each project (or Agency) may elect to use application-specific protocols not recommended

by CCSDS to fulfill their mission requirements in the Application Layer over CCSDS space

communications protocols.

Over a space link, protocol data units of the network protocols (i.e., DTN bundles

, IP

datagrams) are encapsulated into Encapsulation Packets via the Encapsulation Protocol

(reference [29]) and then transferred by one of the the Space Data Link Protocols.

The Space Packet Protocol was developed to transfer data (1) from a source on a spacecraft

to one or multiple destinations on the ground or on other spacecraft, or (2) from a source on

the ground to one or multiple destinations on one or multiple spacecraft. When protocol data

units of this protocol traverse the data system of a space mission (i.e., onboard networks,

onboard data handling system, ground stations, control centers), the Application Identifier

(APID) that is part of each packet is used for determining the managed data path that packet

bundle: A protocol data unit of the DTN Bundle Protocol.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 3-12 April 2023

will take. All decisions about how packets are to be handled and forwarded, based on this

APID, are set by management agreement and are not a formal part of the protocol. There

should be no expectation of interoperable handling of APIDs and managed data paths in a

cross support situation unless agreements have been clearly defined as to how such

forwarding is to be done. Cross support is defined in reference [60], and interested readers

should refer to it for further details.

The Space Packet Protocol provides the capability to transfer space application data over a

managed data path that involves a ground-to-space or a space-to-space communications link.

However, unlike DTN, no provisions are made in SPP for addressing the scheduled nature of

connectivity between any of the end points or intermediate links. By encapsulating the PDUs of

other CCSDS-recognized Network Protocols such as the DTN Bundle Protocol (references [55]

and

[56]) or IP, one for one into an Encapsulation Packet, these Network Protocols can be used

over CCSDS space links.

The protocol data units of the Space Packet Protocol are called Space Packets, while the

protocol data units of IP are called IP datagrams. SPP and IP do not provide any Quality of

Service (QoS) mechanisms for reliable delivery, in-order delivery, or duplicate suppression.

If these functions are required, they must be implemented by a higher-layer (e.g., transport

layer) protocol.

The Space Data Link Protocols have the capability to carry several protocol data units of the

Internet Protocol, multiplexed or not multiplexed, within the Encapsulation packet. IP over

CCSDS (reference [45]) specifies how CCSDS-recognized IP datagrams are transferred over

the link.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

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

4 EXAMPLES OF PROTOCOL CONFIGURATIONS

4.1 GENERAL

This section shows some examples of how space communications protocols of various layers

are used in space data systems.

Five examples of protocol configurations are shown in this section. There are many other

combinations of protocols that can be used in space data systems, but it is not the intention of

this Report to enumerate all possible combinations of protocols. The following examples are

selected to illustrate the basic functionality of the space communications protocols.

For each example in this section, two diagrams are shown. The first diagram shows a stack

of protocols used over a space link (i.e., a link between a spacecraft and a ground station, or

between two spacecraft).

A space data system consists of one or more onboard subnetworks, one or more space links,

and one or more ground subnetworks. In this section, however, a simple space data system

consisting of four major elements (see figure 4-1) is used to illustrate how space

communications protocols are used in an end-to-end space data system. It will be shown that

some space communications protocols are used for end-to-end communications between

onboard and ground-end systems, and some space communications protocols are used only

for communications over the space link.

Space Segment Ground Segment

(e.g., Central

Data Handling

System of the

Spacecraft)

(e.g., Payload) (e.g., Ground

Station)

(e.g., Ground

User)

Onboard

End

System

Onboard

Relay

System

Ground

Relay

System

Ground

End

System

Figure 4-1: Simple Space Data System Model

The primary difference among the five examples shown in this section is the selection of the

protocol used for end-to-end routing or forwarding. In a space data system, user data

traverse subnetworks (i.e., one or more onboard subnetworks, one or more space links, and

one or more ground subnetworks). One of the protocols used in a space data system provides

the capability of routing user data from a source to a destination through these subnetworks.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 4-2 April 2023

This functionality is called ‘end-to-end routing’ in this Report (see definitions of ‘routing’

and ‘forwarding’ in 1.3.2).

SPP is used for end-to-end data forwarding in a closed subnetwork within an A-B-A

configuration in Section 4.2.

The following protocols are used for end-to-end data routing in the following sections:

a) IP over CCSDS over the Encapsulation Packet (4.3);

b) BP that supports DTN (4.4).

NOTES

1 In the following figures, ‘Prox Space Data Link Protocol’ denotes the Proximity-1

Space Link Protocol—Data Link Layer.

2 In the following figures, the Synchronization and Channel Coding standards are

omitted for simplicity reasons.

3 CCSDS is developing DTN (references [55] and [56]) as the means to internetwork in

space.

4.2 END-TO-END DATA FORWARDING USING PACKETS DEFINED BY CCSDS

In this example, the Space Packet is used for end-to-end forwarding. The Space Packet

Protocol was designed by CCSDS to meet the requirements of space missions for efficient

transfer of processed data over space links. This configuration is suited to space missions that

require the simple APID source or destination labeling and forwarding capabilities provided by

the Space Packet Protocol.

Figure 4-2 shows an example of protocol configuration on a space link, and figure 4-3 shows

an example of protocol configuration in an end-to-end space data system. At each

intermediate system, some mechanism, not specified in SPP, examines the APID and

forwards the data to the next node that it has been instructed to use. There is no endpoint

address, and there is no specified mechanism for doing this interoperably. It is done by

management and external agreement between user and service provider.

When the Space Packet Protocol is used for end-to-end forwarding, in the ground

subnetwork, Space Packets are usually transferred with a Space Link Extension (SLE)

Service (see references [38]–[42]). Data Forwarding differs greatly from data routing,

defined in reference [60] as ‘the process of selecting managed data paths from origins to

destinations in a network’. Here, the concept of an endpoint is global over a series of open

and extensible subnetworks. Whenever we route across multiple subnetworks a network

routing protocol is required, which is not in the purview of SPP.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 4-3 April 2023

Space Packet or Encapsulation Packet Protocol

Lossless

Data

Compression

RF & Modulation Systems

CCSDS Space Data Link Protocols

CFDP

Application

Specific

Protocols

Figure 4-2: Protocol Configuration on a Space Link When Space Packet or

Encapsulation Packet Protocol Is Used for End-to-End Forwarding

CFDP, etc. CFDP, etc.

Space Packet

Encapsulation

Space Packet

Encapsulation

Space Packet or

Encapsulation

Space Packet or

Encapsulation

Onboard

Subnetwork

Protocols

Onboard

Subnetwork

Protocols

Onboard End

System

Onboard Relay

System

Ground Relay

System

Ground End

System

Ground

Subnetwork

Protocols

Ground

Subnetwork

Protocols

RF &

Modula-

tion

RF &

Modula-

tion

Space

Data Link

Protocols

Space

Data Link

Protocols

Figure 4-3: Protocol Configuration in a Space Data System When Space Packet or

Encapsulation Packet Protocol Is Used for End-to-End Forwarding

4.3 IP OVER CCSDS FOR END-TO-END ROUTING

In the fourth example, one of the CCSDS recognized IP datagrams defined in SANA is used

for end-to-end routing. This configuration is suited to space missions that require integration

of their space segments into the Internet when end-to-end internetworking is required and

when connectivity and Round Trip Light Time (RTLT) is suitable to support this approach.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 4-4 April 2023

Figure 4-4 shows an example of protocol configuration on a space link, and figure 4-5 shows

an example of protocol configuration in an end-to-end space data system.

Protocol data units (datagrams) of IP are transferred by Space Data Link Protocols using the IP

over CCSDS protocol in order for the Space Data Link Protocols to process IP datagrams

efficiently.

In this example, it is assumed that the Internet is directly extended into the space segment.

Most Internet end-to-end protocols and SCPS-TP can be used on top of IP. SCPS-TP can be

converted to TCP/UDP at a relay system.

over CCSDS

Encapsulation Packet

RF & Modulation Systems

CCSDS Space Data Link Protocols

Application Specific Protocols

TCP UDP

Figure 4-4: Protocol Configuration on a Space Link When IP over CCSDS Is Used

for End-to-End Routing

At each intermediate system in an IP deployment, a routing mechanism, specified in the IP

protocol, examines the destination address and makes a routing decision that sends the data

to the next node in the route. The endpoint address is explicit, and all of the mechanisms for

doing this interoperably are fully specified. The Encapsulation Packet Protocol provides the

shim to insert the IP datagrams into a CCSDS space link and to extract it at the other end.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 4-5 April 2023

Applications,

etc.

Ground

Subnetwork

Protocols

TCP/UDP

Applications,

etc.

Ground

Subnetwork

Protocols

RF &

Modulation

Space

Data Link

Protocols

RF &

Modulation

Space

Data Link

Protocols

Onboard

Subnetwork

Protocols

Onboard

Subnetwork

Protocols

TCP/UDP

Onboard End

System

Onboard Relay

System

Ground Relay

System

Ground End

System

IP over CCSDS

Encapsulation

Packet

IP over CCSDS

Encapsulation

Packet

Figure 4-5: Protocol Configuration in a Space Data System When IP over CCSDS is

Used for End-to-End Routing

4.4 BP FOR END-TO-END DATA ROUTING

In the final example, BP (reference [56]) is used for end-to-end data routing for the exchange

of messages (bundles) that support DTN. BP provides end-to-end network services, operating

above the data transport services provided by links or networks accessed via CLAs and

forming a store-and-forward network.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page 4-6 April 2023

CL B

Bundle

CL A

Conv. Layer A

Applications

Bundle

Transport A Trans A

Network A

Network A Net A

Link A1 Link A1 Link An Link B1

Phy A1 Phy A1 Phy An Phy B1Phy A2

Link A2 Link B1

Phy B1

An internet A link-layer hop

Applications

Figure 4-6: Protocol Configuration in a Space Data System When BP Is Used for

End-to-End Data Routing

The Bundle Protocol uses the ‘native’ local protocols for communications within a given

network. The interface between the Bundle Protocol and a specific lower-layer protocol suite is

known as a convergence layer adapter. Figure 4-6 shows an example configuration with the

Bundle Protocol and a CLA running above a transport protocol (intended to be interpreted in

the context of the Internet stack) on the left, and running directly over a Data Link Layer on the

right. The ‘CL B’ on the right could, for example, be the interface to the Licklider

Transmission Protocol, with the ‘Link B1’ representing LTP running over one of the CCSDS

Data Link Layer protocols. Alternatively, BP could be used to connect together two internets

that may exist, such as an on-orbit (or lunar) network and a ground network.

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page A-1 April 2023

ANNEX A

ACRONYMS

This annex lists the acronyms and abbreviations used in this Report.

AOS Advanced Orbiting Systems

AMS Asynchronous Messaging Service

APID Application Process Identifier

ASM Attached Synchronization Marker

BCH Bose–Chaudhuri–Hocquenghem (code)

BP Bundle Protocol

CCSDS Consultative Committee for Space Data Systems

CFDP CCSDS File Delivery Protocol

CL Convergence Layer

CLA Convergence Layer Adapter

DTN Delay Tolerant Networking

DVB-S2 Digital Video Broadcasting - Satellite - Second Generation

EPP Encapsulation Packet Protocol

FECF Frame Error Control Field

FSH Frame Secondary Header

FTP File Transfer Protocol

ID Identifier

IP Internet Protocol

LDPC Low Density Parity Check (code)

LTP Linklider Transmission Protocol

MAP Multiplexer Access Point

MC Master Channel

MCID Master Channel Identifier

N/A Not Applicable

CCSDS REPORT: OVERVIEW OF SPACE COMMUNICATIONS PROTOCOLS

CCSDS 130.0-G-4 Page A-2 April 2023

OCF Operational Control Field

PCID Physical Channel Identifier

PDU Protocol Data Unit

PVN Packet Version Number

QoS Quality of Service

RTLT Round Trip Light Time

SANA Space Assigned Numbers Authority

SCCC Serial Concatenated Convolutional Code

SCID Spacecraft Identifier

SCPS Space Communications Protocol Standards

SCPS-FP Space Communications Protocol Standards File Protocol

SCPS-NP Space Communications Protocol Standards Network Protocol

SCPS-SP Space Communications Protocol Standards Security Protocol

SCPS-TP Space Communications Protocol Standards Transport Protocol

SDLS Space Data Link Security (Protocol)

SLE Space Link Extension

SPP Space Packet Protocol

TC Telecommand

TCP Transmission Control Protocol

TDM Time Division Multiplexing

TFVN Transfer Frame Version Number

TM Telemetry

USLP Unified Space Link Protocol

UDP User Datagram Protocol

VC Virtual Channel

VCID Virtual Channel Identifier