![](media/image1.wmf){width="4.361111111111111in"
height="1.2083333333333333in"}

**REPORT CONCERNING SPACE**

**DATA SYSTEM STANDARDS**

  -----------------------------------------------------------------------
  **OVERVIEW OF SPACE LINK PROTOCOLS**

  -----------------------------------------------------------------------

**CCSDS 130.0-G-1**

**GREEN BOOK**

June 2001

![](media/image2.wmf){width="4.111111111111111in"
height="1.9305555555555556in"}

AUTHORITY

  ---- -------------------- ------------------------------------------ ----
                                                                       

       Issue:               Green Book, Issue 1                        

       Date:                June 2001                                  

       Location:            Oxfordshire, UK                            

                                                                       
  ---- -------------------- ------------------------------------------ ----

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 reference \[1\].

This document is published and maintained by:

> CCSDS Secretariat
>
> Program Integration Division (Code MT)
>
> National Aeronautics and Space Administration
>
> Washington, DC 20546, USA

FOREWORD

This document is a CCSDS Report that contains an overview of the space
link 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 link protocol is a communications protocol
designed to be used over a space link, or in a network that contains one
or multiple space links. Please note that a space link protocol is not
necessarily a protocol of the Data Link Layer of the OSI Basic Reference
Model (reference \[2\]).

Through the process of normal evolution, it is expected that expansion,
deletion, or modification to this Report may occur. This Report is
therefore subject to CCSDS document management and change control
procedures, which are defined in reference \[1\]. 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 Report should be
addressed to the CCSDS Secretariat at the address on page i.

At time of publication, the active Member and Observer Agencies of the
CCSDS were:

[Member Agencies]{.underline}

-   Agenzia Spaziale Italiana (ASI)/Italy.

-   British National Space Centre (BNSC)/United Kingdom.

-   Canadian Space Agency (CSA)/Canada.

-   Centre National d'Etudes Spatiales (CNES)/France.

-   Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.

-   European Space Agency (ESA)/Europe.

-   Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.

-   National Aeronautics and Space Administration (NASA)/USA.

-   National Space Development Agency of Japan (NASDA)/Japan.

-   Russian Space Agency (RSA)/Russian Federation.

[Observer Agencies]{.underline}

-   Austrian Space Agency (ASA)/Austria.

-   Central Research Institute of Machine Building (TsNIIMash)/Russian
    Federation.

-   Centro Tecnico Aeroespacial (CTA)/Brazil.

-   Chinese Academy of Space Technology (CAST)/China.

-   Commonwealth Scientific and Industrial Research Organization
    (CSIRO)/Australia.

-   Communications Research Centre (CRC)/Canada.

-   Communications Research Laboratory (CRL)/Japan.

-   Danish Space Research Institute (DSRI)/Denmark.

-   European Organization for the Exploitation of Meteorological
    Satellites (EUMETSAT)/Europe.

-   European Telecommunications Satellite Organization
    (EUTELSAT)/Europe.

-   Federal Service of Scientific, Technical & Cultural Affairs
    (FSST&CA)/Belgium.

-   Hellenic National Space Committee (HNSC)/Greece.

-   Indian Space Research Organization (ISRO)/India.

-   Institute of Space and Astronautical Science (ISAS)/Japan.

-   Institute of Space Research (IKI)/Russian Federation.

-   KFKI Research Institute for Particle & Nuclear Physics
    (KFKI)/Hungary.

-   MIKOMTEK: CSIR (CSIR)/Republic of South Africa.

-   Korea Aerospace Research Institute (KARI)/Korea.

-   Ministry of Communications (MOC)/Israel.

-   National Oceanic & Atmospheric Administration (NOAA)/USA.

-   National Space Program Office (NSPO)/Taipei.

-   Swedish Space Corporation (SSC)/Sweden.

-   United States Geological Survey (USGS)/USA.

DOCUMENT CONTROL

  -------------- ----------------------- ------------ -----------------------
  **Document**   **Title and Issue**     **Date**     **Status**

  CCSDS\         Overview of Space Link  June 2001    Original Issue.
  130.0-G-1      Protocols, Issue 1                   
  -------------- ----------------------- ------------ -----------------------

CONTENTS

[Section]{.underline} [Page]{.underline}

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 LINK PROTOCOLS 2-1

2.1 HISTORY OF Space Link Protocols 2-1

2.2 Protocol LAYERS 2-2

3 MAJOR FEATURES OF SPACE LINK PROTOCOLS 3-1

3.1 Physical LAYER 3-1

3.2 Data Link LAYER 3-1

3.3 Network LAYER 3-7

3.4 Transport LAYER 3-10

3.5 Application LAYER 3-10

4 EXAMPLES OF PROTOCOL CONFIGURATIONS 4-1

4.1 GENERAL 4-1

4.2 Space Packet Protocol for end-to-end routing 4-2

4.3 SCPS-NP AND IP for End-to-end Routing 4-3

4.4 IP Version 4 for End-to-end Routing 4-5

4.5 IP Version 6 for End-to-end Routing 4-7

4.6 CFDP for End-to-end Routing 4-8

ANNEX A ACRONYMS A-1

Figure

2-1 Space Link Protocols 2-4

2-2 Possible Combinations of Space Link Protocols 2-5

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

4-1 Simple Space Data System Model 4-1

CONTENTS (continued)

[Figure]{.underline} [Page]{.underline}

4-2 Protocol Configuration on a Space Link When Space Packet Protocol\
Is Used for End-to-End Routing 4-3

4-3 Protocol Configuration in a Space Data System When Space Packet
Protocol\
Is Used for End-to-End Routing 4-3

4-4 Protocol Configuration on a Space Link When SCPS-NP and IP Are Used
for\
End-to-End Routing 4-4

4-5 Protocol Configuration in a Space Data System When SCPS-NP and IP
Are\
Used for End-to-End Routing 4-5

4-6 Protocol Configuration on a Space Link When IP Version 4 Is Used
for\
End-to-End Routing 4-6

4-7 Protocol Configuration in a Space Data System When IP Version 4 Is
Used\
for End-to-End Routing 4-6

4-8 Protocol Configuration on a Space Link When IP Version 6 Is Used
for\
End-to-End Routing 4-7

4-9 Protocol Configuration in a Space Data System When IP Version 6 Is
Used\
for End-to-End Routing 4-8

4-10 Protocol Configuration on a Space Link When CFDP Is Used for\
End-to-End Routing 4-9

4-11 Protocol Configuration in a Space Data System When CFDP Is Used\
for End-to-End Routing 4-9

Table

3-1 Addressing Capability of Space Data Link Protocols 3-4

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

3-3 Functions of Synchronization and Channel Coding Standards 3-6

3-4 Addressing Capability of Network Protocols 3-9

# Introduction

## Purpose and Scope

The purpose of this report is to provide an architectural overview of
the space link protocols recommended by CCSDS and to show how these
protocols are used in space mission data systems.

A space link is a communications link between a spacecraft and its
associated ground system or between two spacecraft. A space link
protocol is a communications protocol designed to be used over a space
link, or in a network that contains one or multiple space links. Please
note that a space link protocol is not necessarily a protocol of the
Data Link Layer of the OSI Basic Reference Model \[2\].

This report only presents a top-level overview of the space link
protocols and does not contain the specification or rationale of each
protocol. The specification of a space link 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.

## 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 link protocols;

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

d)  section 4 shows some examples of how space link protocols are used
    in space data systems;

e)  annex A lists all acronyms used within this document.

## Definitions

### Definitions from OSI Basic Reference Model

Most of the CCSDS space link protocols are defined using the style
established by the Open Systems Interconnection (OSI) Basic Reference
Model \[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 link
protocols. If the reader is not familiar with this model, an excellent
introduction can be found in a textbook on computer networks such as
\[3\].

The following terms used in this Report are defined in \[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.

### Terms defined in this Report

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

**octet:** an 8-bit word.

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

**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 link 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. A space link protocol is not necessarily a
protocol of the Data Link Layer of the OSI Basic Reference Model \[2\].

## References

The following documents are referenced in the text of this Report. At
the time of publication, the editions indicated were valid. All
documents are subject to revision, and users of this Report are
encouraged to investigate the possibility of applying the most recent
editions of the documents indicated below. The CCSDS Secretariat
maintains a register of currently valid CCSDS Recommendations and
Reports.[^1]

1.  *Procedures Manual for the Consultative Committee for Space Data
    Systems*. CCSDS A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.:
    CCSDS, November 1996.

2.  *Information Technology---Open Systems Interconnection---Basic
    Reference Model: The Basic Model*. International Standard, ISO/IEC
    7498-1. 2nd ed. Geneva: ISO, 1994.

3.  Andrew S. Tanenbaum. *Computer Networks*. 3rd ed.. New Jersey:
    Prentice-Hall, 1996.

4.  *Space Packet Protocol*. Draft Recommendation for Space Data System
    Standards, CCSDS 133.0-R-1. Red Book. Issue 1. Washington, D.C.:
    CCSDS, June 2000.

5.  *TM Space Data Link Protocol*. Draft Recommendation for Space Data
    System Standards, CCSDS 132.0-R-1. Red Book. Issue 1. Washington,
    D.C.: CCSDS, June 2000.

6.  *TC Space Data Link Protocol*. Draft Recommendation for Space Data
    System Standards, CCSDS 232.0-R-1. Red Book. Issue 1. Washington,
    D.C.: CCSDS, June 2000.

7.  *AOS Space Data Link Protocol*. Draft Recommendation for Space Data
    System Standards, CCSDS 732.0-R-1. Red Book. Issue 1. Washington,
    D.C.: CCSDS, June 2000.

8.  *Channel Coding and Synchronization---Part 1: Synchronous*. Draft
    Recommendation for Space Data System Standards, CCSDS 131.0-R-1. Red
    Book. Issue 1. Washington, D.C.: CCSDS, June 2000.

9.  *Channel Coding and Synchronization---Part 2: Asynchronous*. Draft
    Recommendation for Space Data System Standards, CCSDS 231.0-R-1. Red
    Book. Issue 1. Washington, D.C.: CCSDS, June 2000.

10. *Radio Frequency and Modulation Systems---Part 1: Earth Stations and
    Spacecraft*. Recommendations for Space Data System Standards, CCSDS
    401.0-B. Blue Book. Washington, D.C.: CCSDS, June 2001.

11. *Space Communications Protocol Specification (SCPS)---Network
    Protocol (SCPS-NP)*. Recommendation for Space Data System Standards,
    CCSDS 713.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May
    1999.

12. *Space Communications Protocol Specification (SCPS)---Security
    Protocol (SCPS-SP)*. Recommendation for Space Data System Standards,
    CCSDS 713.5-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May
    1999.

13. *Space Communications Protocol Specification (SCPS)---Transport
    Protocol (SCPS-TP)*. Recommendation for Space Data System Standards,
    CCSDS 714.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May
    1999.

14. *Space Communications Protocol Specification (SCPS)---File Protocol
    (SCPS-FP)*. Recommendation for Space Data System Standards, CCSDS
    717.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.

15. *CCSDS File Delivery Protocol (CFDP)*. Draft Recommendation for
    Space Data System Standards, CCSDS 727.0-R-5. Red Book. Issue 5.
    Washington, D.C.: CCSDS, August 2001.

16. *Lossless Data Compression*. Recommendation for Space Data System
    Standards, CCSDS 121.0-B-1. Blue Book. Issue 1. Washington, D.C.:
    CCSDS, May 1997.

17. *Proximity-1 Space Link Protocol*. Draft Recommendation for Space
    Data System Standards, CCSDS 211.0-R-2. Red Book. Issue 2.
    Washington, D.C.: CCSDS, January 2000.

18. *Information Technology---Open Systems Interconnection---Basic
    Reference Model---Conventions for the Definition of OSI Services*.
    International Standard, ISO/IEC 10731:1994. Geneva: ISO, 1994.

19. J. Postel. *Internet Protocol*. STD 5, September 1981. \[RFC 791,
    RFC 950, RFC 919, RFC 922, RFC 792, RFC 1112\][^2]

20. S. Deering and R. Hinden. *Internet Protocol, Version 6 (IPv6)
    Specification*. RFC 1883, December 1995.

21. J. Postel. *Transmission Control Protocol*. STD 7, September 1981.
    \[RFC 793\]

22. J. Postel. *User Datagram Protocol*. STD 6, August 1980. \[RFC 768\]

23. J. Postel and J. Reynolds. *File Transfer Protocol*. STD 9,
    October 1985. \[RFC 959\]

24. *Communications Operation Procedure-1*. Draft Recommendation for
    Space Data System Standards, CCSDS 232.1-R-1. Red Book. Issue 1.
    Washington, D.C.: CCSDS, June 2000.

25. *Space Link Identifiers*. Draft Recommendation for Space Data System
    Standards, CCSDS 135.0-R-1. Red Book. Issue 1. Washington, D.C.:
    CCSDS, November 2000.

26. *Space Packet Protocol---Encapsulation Service*. CCSDS 133.1-W-1.
    White Book. \[Under development\]. n.p.: n.p, n.d..

27. Space Link Extension Service Specifications. \[Space Link Extension
    Service Specifications are in various stages of development. Current
    issues of CCSDS documents are maintained at the CCSDS Web site:
    http://ccsds.org.\]

28. *Space Data Link Protocols---Summary of Concept and Rationale*.
    Draft Report Concerning Space Data System Standards, CCSDS
    130.2-G-0.1. Draft Green Book. Issue 0.1. Sagamihara, Japan: ISAS,
    n.d.

29. *Channel Coding and Synchronization---Part 1: Synchronous---Summary
    of Concept and Rationale*. Draft Report Concerning Space Data System
    Standards, CCSDS 130.1-G-0.1. Draft Green Book. Issue 0.1.
    Sagamihara, Japan: ISAS, n.d.

30. *Channel Coding and Synchronization---Part 2: Asynchronous---Summary
    of Concept and Rationale*. Draft Report Concerning Space Data System
    Standards, CCSDS 230.1-G-0.1. Draft Green Book. Issue 0.1.
    Sagamihara, Japan: ISAS, n.d.

31. *Space Packet Protocol---Summary of Concept and Rationale*. Draft
    Report Concerning Space Data System Standards, CCSDS 130.3-G-0.1.
    Draft Green Book. Issue 0.1. Sagamihara, Japan: ISAS, n.d.

32. *Space Communications Protocol Specification (SCPS)---Rationale,
    Requirements, and Application Notes*. Draft Report Concerning Space
    Data System Standards, CCSDS 710.0-G-0.4. Draft Green Book. Issue
    0.4. Washington, D.C.: CCSDS, October 1997.

33. *CCSDS File Delivery Protocol (CFDP)---Part 1: Introduction and
    Overview*. Draft Report Concerning Space Data System Standards,
    CCSDS 720.1-G-0.8. Draft Green Book. Issue 0.8. n.p.: n.p., July
    2001.

34. *Lossless Data Compression*. Report Concerning Space Data System
    Standards, CCSDS 120.0-G-1. Green Book. Issue 1. Washington, D.C.:
    CCSDS, May 1997.

# INTRODUCTION TO SPACE LINK PROTOCOLS

## HISTORY OF Space Link Protocols

Traditionally, telemetry transmitted from the spacecraft was formatted
with a Time Division Multiplexing (TDM) scheme, where 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, 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 replace the
original standards:

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

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

c)  TM/TC Synchronization and Channel Coding (references \[8\] and
    \[9\], respectively).

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 \[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) \[11\], SCPS Security Protocol
(SCPS-SP) \[12\], SCPS Transport Protocol (SCPS-TP) \[13\], and SCPS
File Protocol (SCPS-FP) \[14\]. The SCPS protocols are basically 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.

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) \[15\]. This protocol provides the
capability to transfer files reliably and efficiently over an unreliable
protocol (for example, the Space Packet Protocol).

In the area of data compression, CCSDS has developed a Lossless Data
Compression standard \[16\] either to increase the science return or 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.

Recently CCSDS has developed a protocol called Proximity-1 Space Link
Protocol \[17\] 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 and RF and modulation characteristics.

## Protocol LAYERS

### Summary

A communications protocol is usually associated with one of the seven
layers defined in the OSI Basic Reference Model \[2\]. Although some
space link protocols do not fit well with the OSI seven-layer model,
this report uses this model for categorizing the space link protocols.

The space link 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.

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 link protocols categorized into the five
layers listed above. Figure 2-2 shows possible combinations of these
protocols.

In figure 2-1, there are two protocols that do not correspond to a
single layer. CCSDS File Delivery Protocol (CFDP) has the functionality
of the Transport and Application Layers. Proximity-1 Space Link Protocol
has the functionality of the Data Link and Physical Layers.

Although CCSDS does not formally define Application Program Interfaces
(APIs) for the space link protocols, most CCSDS standards provide
service definitions in the form of primitives following the conventions
established by ISO (see reference \[18\]). A primitive is an abstract
representation of an API that does not depend on any implementation
technology and thus should be used as the baseline for an API.

![](media/image3.wmf)

Figure 2‑1: Space Link Protocols

![](media/image4.wmf)

Figure 2‑2: Possible Combinations of Space Link Protocols

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.

### Physical LAYER

CCSDS has a standard for the Physical Layer called the Radio Frequency
and Modulation Systems \[10\] to be used for space links between
spacecraft and ground stations. The Proximity-1 Space Link Protocol
\[17\] also contains recommendations for the Physical Layer of proximity
space links.

### Data Link LAYER

CCSDS defines two Sublayers in the Data Link Layer of the OSI Model:
Data Link Protocol Sublayer and Synchronization and Channel Coding
Sublayer. The Data Link Protocol Sublayer specifies methods of
transferring data units provided by the higher layer over a 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 three protocols for the Data Link Protocol Sublayer
of the Data Link Layer:

a)  TM Space Data Link Protocol \[5\];

b)  TC Space Data Link Protocol \[6\];

c)  AOS Space Data Link Protocol \[7\].

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

CCSDS has developed two standards for the Synchronization and Channel
Coding Sublayer of the Data Link Layer:

a)  TM Synchronization and Channel Coding \[8\];

b)  TC Synchronization and Channel Coding \[9\].

TM Synchronization and Channel Coding is used with the TM or AOS Space
Data Link Protocol, and TC Synchronization and Channel Coding is used
with the TC Space Data Link Protocol.

The Proximity-1 Space Link Protocol \[17\] also defines a protocol of
the Data Link Protocol Sublayer together with the synchronization and
channel coding methods to be used by this protocol.

The TM, TC and AOS Space Data Link Protocols and the Data Link Protocol
Sublayer portion of the Proximity-1 Space Link Protocol are called the
Space Data Link Protocols in this document.

### Network LAYER

Space link protocols of the Network Layer provide the function of
routing higher-layer data through the entire data system that includes
both onboard and ground subnetworks.

CCSDS has developed two protocols for the Network Layer:

a)  Space Packet Protocol \[4\];

b)  SCPS Network Protocol (SCPS-NP) \[11\].

In some cases, Protocol Data Units (PDUs) of the Space Packet Protocol
are generated and consumed by application processes themselves on a
spacecraft, instead of being generated and consumed by a separate
protocol entity, and in these cases this protocol is used both as a
Network Layer protocol and as an Application Layer protocol.

PDUs of a Network Layer protocol are transferred with Space Data Link
Protocols over a space link.

The following protocols developed by the Internet can also be
transferred with Space Data Link Protocols over a space link,
multiplexed or not-multiplexed with the Space Packet Protocol and/or
SCPS-NP:

a)  Internet Protocol (IP), Version 4 \[19\];

b)  Internet Protocol (IP), Version 6 \[20\].

### Transport LAYER

Space link protocols of the Transport Layer provide users with
end-to-end transport services.

CCSDS has developed the SCPS Transport Protocol (SCPS-TP) \[13\] for the
Transport Layer. The CCSDS File Delivery Protocol (CFDP) \[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.

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 with a Space Data Link Protocol if certain
conditions are met.

Transport protocols used in the Internet (such as TCP \[21\] and UDP
\[22\]) can also be used on top of SCPS-NP, IP Version 4, and IP Version
6 over space links.

SCPS Security Protocol (SCPS-SP) \[12\] may be used with a Transport
protocol to provide end-to-end data protection capability.

### Application LAYER

Space link protocols of the Application Layer provide users with
end-to-end application services such as file transfer and data
compression.

CCSDS has developed two protocols for the Application Layer:

a)  SCPS File Protocol (SCPS-FP) \[14\];

b)  Lossless Data Compression \[16\].

The CCSDS File Delivery Protocol (CFDP) \[15\] provides the
functionality of the Application Layer (i.e., functions for file
management), but it also provides functions of the Transport Layer.

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 link protocols.

PDUs of an Application Layer protocol (excluding CFDP) 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 if certain conditions are met.

Applications protocols used in the Internet (such as FTP \[23\]) can
also be used on top of SCPS-TP, TCP and UDP over space links.

# MAJOR FEATURES OF SPACE LINK PROTOCOLS

## Physical LAYER

The CCSDS Recommendation on Radio Frequency and Modulation Systems
\[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 \[17\] also contains recommendations
for the Physical Layer of proximity space links.

## Data Link LAYER

### 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 \[5\];

b)  TC Space Data Link Protocol \[6\];

c)  AOS Space Data Link Protocol \[7\];

d)  Data Link Protocol Sublayer portion of Proximity-1 Space Link
    Protocol \[17\].

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
knows as packets (i.e., protocol data units of protocols of the Network
Layer such as the Space Packet Protocol, SCPS-NP and IP).

Each packet format transferred by the Space Data Link Protocols must
have a Packet Version Number (PVN) authorized by CCSDS. A list of the
Packet Version Numbers presently authorized by CCSDS is contained in
reference \[25\]. Packets with authorized Packet Version Numbers can be
transferred by the Space Data Link Protocols directly, but CCSDS has
another mechanism to transfer other packets with a service called the
Encapsulation Service, defined in reference \[26\]. 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 \[26\].

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 on-line 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, where 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 protocol data units used by the Space Data Link Protocols are called
Transfer Frames. The TM and AOS Space Data Link Protocols use
fixed-length Transfer Frames to facilitate robust synchronization
procedures over a noisy link, while the TC Space Data Link Protocol uses
variable-length Transfer Frames to facilitate reception of short
messages with a short delay. The Proximity-1 Space Link Protocol uses
either fixed-length or variable-length Transfer Frames.

A key feature of 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.

The TC Space Data Link Protocol has a function of 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
\[24\]). (This function does not necessarily guarantee end-to-end
complete delivery). The Proximity-1 Space Link Protocol also has a
similar function called COP-P, which is defined in the same document as
the protocol. Neither the TM Space Data Link Protocol nor the AOS Space
Data Link Protocol has such a function, so retransmission should be done
by a higher-layer protocol if complete delivery of data is required.

The TM/TC/AOS Space Data Link Protocols are used on top of the
Recommendation on Radio Frequency and Modulation Systems \[10\]. The
Proximity-1 Space Link Protocol \[17\] contains recommendations for the
Physical Layer in the same book.

A summary of concept and rationale of the TM/TC/AOS Space Data Link
Protocols is contained in reference \[28\].

### ADDRESSING OF Data Link Protocols

The Space Data Link Protocols provide some addresses (or identifiers) to
identify data streams. All the Space Data Link Protocols have the
following three identifiers: Transfer Frame Version Number (TFVN),
Spacecraft Identifier (SCID), and Virtual Channel Identifier (VCID). The
concatenation of a TFVN and a SCID is known as a Master Channel
Identifier (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
a Master Channel (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 only carries 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.

The TC Space Data Link Protocol 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 the Space Data
Link Protocols.

![](media/image5.wmf)

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

The Proximity-1 Space Link Protocol has another identifier called the
Port Identifier that is used 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.

Table 3-1 summarizes the addressing capability of the Space Data Link
Protocols.

Table 3‑1: Addressing Capability of Space Data Link Protocols

  --------------- ------------- ------------- ------------- -------------
  Address         TM Space Data TC Space Data AOS Space     Proximity-1
                  Link Protocol Link Protocol Data Link     Space Link
                                              Protocol      Protocol

  Transfer Frame  Always 1      Always 1      Always 2      Always 3
  Version Number  (binary       (binary       (binary       (binary
  (TFVN)          encoded       encoded       encoded       encoded
                  number is 00) number is 00) number is 01) number is 10)

  Spacecraft      0 to 1023     0 to 1023     0 to 255      0 to 1023
  Identifier                                                
  (SCID)                                                    

  Virtual Channel 0 to 7        0 to 63       0 to 63       0, 1
  Identifier                                                
  (VCID)                                                    

  Multiplexer     N/A           0 to 63       N/A           N/A
  Access Point                                              
  Identifier (MAP                                           
  ID)                                                       

  Port Identifier N/A           N/A           N/A           0 to 7
  --------------- ------------- ------------- ------------- -------------

### 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 or real-time functions, and
bit streams.

Table 3-2 shows a summary of the services provided by the TM/TC/AOS
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\] and \[7\].

NOTE -- The Proximity-1 Space Link Protocol is not included in this
table because no service definition is given in the current draft
Recommendation (reference \[17\]).

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

+-----------------+----------------+----------------+----------------+
| Type of Service | TM Space Data  | TC Space Data  | AOS Space Data |
| Data Units      | Link Protocol  | Link Protocol  | Link Protocol  |
+-----------------+----------------+----------------+----------------+
| Packets (NOTE   | Packet         | MAP Packet     | Packet         |
| 1)              | Service,       | Service,       | Service,       |
|                 |                |                |                |
|                 | Encapsulation  | VC Packet      | Encapsulation  |
|                 | Service        | Service,       | Service        |
|                 |                |                |                |
|                 |                | Encapsulation  |                |
|                 |                | Service        |                |
+-----------------+----------------+----------------+----------------+
| Fixed-length    | VC Access      | (None)         | VC Access      |
| private data    | Service        |                | Service        |
+-----------------+----------------+----------------+----------------+
| Variable-length | (None)         | MAP Access     | (None)         |
| private data    |                | Service,       |                |
|                 |                |                |                |
|                 |                | VC Access      |                |
|                 |                | Service        |                |
+-----------------+----------------+----------------+----------------+
| Short           | VC FSH Service | (None)         | Insert         |
| fixed-length    | (NOTE 2),      |                | Service,       |
| data            |                |                |                |
|                 | MC FSH         |                | VC OCF Service |
|                 | Service,       |                | (NOTE 3)       |
|                 |                |                |                |
|                 | VC OCF Service |                |                |
|                 | (NOTE 3),      |                |                |
|                 |                |                |                |
|                 | MC OCF Service |                |                |
+-----------------+----------------+----------------+----------------+
| Bit stream      | (None)         | (None)         | Bitstream      |
|                 |                |                | Service        |
+-----------------+----------------+----------------+----------------+
| Transfer Frames | VC Frame       | VC Frame       | VC Frame       |
|                 | Service, MC    | Service, MC    | Service, MC    |
|                 | Frame Service  | Frame Service  | Frame Service  |
+-----------------+----------------+----------------+----------------+

NOTES

1.  Packets directly transferred by the Space Data Link Protocols must
    have Packet Version Numbers authorized by CCSDS. A list of
    authorized Packet Version Numbers is found in reference \[25\].
    Other packets can be transferred using the Encapsulation Service
    defined in reference \[26\].

2.  FSH = Frame Secondary Header.

3.  OCF = Operational Control Field.

### 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 two standards for Synchronization and
Channel Coding:

a)  TM Synchronization and Channel Coding \[8\];

b)  TC Synchronization and Channel Coding \[9\].

TM Synchronization and Channel Coding is used with the TM or AOS Space
Data Link Protocol, and TC Synchronization and Channel Coding is used
with the TC Space Data Link Protocol. The synchronization and channel
coding schemes used with the Proximity-1 Space Link Protocol are defined
in the document that defines the protocol (reference \[17\]).

Table 3-3 summarizes the functions and schemes provided by the
Synchronization and Channel Coding standards.

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

+--------------+-----------------+-----------------+-----------------+
| Functions    | TM              | TC              | Proximity-1     |
|              | Synchronization | Synchronization | Space Link      |
|              | and Channel     | and Channel     | Protocol        |
|              | Coding          | Coding          |                 |
+--------------+-----------------+-----------------+-----------------+
| Error        | Convolutional   | BCH Code\*      | Convolutional   |
| Correction   | Codes\*         |                 | Code\*          |
|              |                 |                 |                 |
|              | Turbo Codes\*   |                 | Reed Solomon    |
|              |                 |                 | Code\*          |
|              | Reed Solomon    |                 |                 |
|              | Codes\*         |                 |                 |
+--------------+-----------------+-----------------+-----------------+
| Error        | Reed Solomon    | BCH Code        | Reed Solomon    |
| Detection/   | Codes\*         |                 | Code\*          |
| Frame        |                 | Frame Error     |                 |
| Validation   | Frame Error     | Control Field\* | Attached Cyclic |
|              | Control Field\* | (see NOTE 2)    | Redundancy      |
|              | (see NOTE 2)    |                 | Code\*          |
+--------------+-----------------+-----------------+-----------------+
| Pseudo-R     | Cyclic          | Cyclic          | (Not used)      |
| andomization | Pseudo-noise    | Pseudo-nose     |                 |
|              | Sequence\*      | Sequence\*      |                 |
+--------------+-----------------+-----------------+-----------------+
| Frame        | 32-bit Attached | 16-bit Start    | 24- or 32-bit   |
| Syn          | Sync Marker     | Sequence        | Attached Sync   |
| chronization |                 |                 | Marker          |
+--------------+-----------------+-----------------+-----------------+

NOTES

1.  '\*' in the table denotes an optional function.

2.  The Frame Error Control Field is defined in the Recommendations on
    the TM/TC/AOS Space Data Link Protocols, and not in the
    Recommendations on Synchronization and Channel Coding.

Summaries of concept and rationale for TM and TC Synchronization and
Channel Coding are contained in references \[28\] and \[30\],
respectively.

## Network LAYER

### GENERAL features OF Network PROTOCOLS

CCSDS has developed two protocols for the Network Layer:

a)  Space Packet Protocol \[14\];

b)  SCPS Network Protocol (SCPS-NP) \[11\].

These protocols are developed to transfer data (1) from a source on a
spacecraft to one or multiple destinations on the ground or on (an)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
these protocols traverse the data system of a space mission (i.e.,
onboard networks, onboard data handling system, ground stations, control
centers), the address(es) attached to each packet is used for
determining the route of that packet.

The Space Packet Protocol provides the capability to efficiently
transfer processed data over space links and the capability for routing
data through a space data system. SCPS-NP provides a variety of
addressing and routing capabilities, some of which are compatible with
the Internet, and can be used with SCPS or Internet upper-layer
protocols.

The protocol data units of the Space Packet Protocol are called Space
Packets, while the protocol data units of SCPS-NP are called SCPS-NP
datagrams.

These protocols do not provide a function for retransmitting lost or
corrupted data, so retransmission should be done by a higher-layer
protocol if complete delivery of data is required.

Over a space link, protocol data units of these protocols are
transferred with Space Data Link Protocols.

A summary of concept and rationale of the Space Packet Protocol is
contained in reference \[31\]. A summary of concept and rationale of
SCPS-NP is contained in reference \[32\].

The Space Data Link Protocols have the capability to carry the protocol
data units of the following protocols developed by the Internet,
multiplexed or not-multiplexed with the Space Packet Protocol and/or
SCPS-NP:

a)  Internet Protocol (IP), Version 4 \[19\];

b)  Internet Protocol (IP), Version 6 \[20\].

Protocol data units (datagrams) of IP Version 6 are transferred by Space
Data Link Protocols using Encapsulation Packets defined in reference
\[26\] in order for the Space Data Link Protocols to process IP Version
6 datagrams efficiently. Other protocols can also be transferred with
the Space Data Link Protocols using the Encapsulation Service defined in
reference \[26\].

### ADDRESSING OF Network PROTOCOLS

Two types of addresses are used by the Network Layer protocols: Path
Address and End System Address. A Path Address identifies a logical data
path in the network from a source to one or multiple destinations.
Configuration of logical data paths is done by management activities,
and not by the protocol that transfers data. An End System Address
identifies a single end system or a group of end systems. When an End
System Address is used, a pair of End System Addresses must be used to
identify both source and destination end systems.

Table 3-4 shows the addressing capability of the Network Layer
protocols.

Table 3‑4: Addressing Capability of Network Protocols

  ----------- ---------------- ----------- ---------- --------------------
  Protocol    Address Name     Address     Address    Note
                               Type        Length     

  Space       Application      Path        11 bits    When APIDs have to
  Packet      Process          Address                be uniquely
  Protocol    Identifier                              identified in a
              (APID)                                  global network, the
                                                      Spacecraft
                                                      Identifier (SCID) is
                                                      used to qualify
                                                      APIDs.

  SCPS-NP     Extended End     End System  4 octets + IP addresses or SCPS
              System Address   Address     4 octets   address family
                                                      addresses

              Extended Path    Path        4 octets   SCPS address family
              Address          Address                addresses

              Basic End System End System  1 octet +\ SCPS address family
              Address          Address     1 octet    addresses

              Basic Path       Path        1 octet    SCPS address family
              Address          Address                addresses

              IPv6 Address     End System  16         IP version 6
                               Address     octets +   addresses
                                           16 octets  

  IP Version  IP Address       End System  4 octets + 
  4                            Address     4 octets   

  IP Version  IP Version 6     End System  16         
  6           Address          Address     octets +   
                                           16 octets  
  ----------- ---------------- ----------- ---------- --------------------

NOTES

1.  The SCPS address family addresses are a subset of the IP version 4
    address space with the first octet fixed to the decimal value of 10.
    They can be truncated to one octet (Basic Addresses) when there is
    no ambiguity in interpretation of the addresses.

2.  Any of the five addresses shown above may be used for a SCPS-NP
    datagram.

## Transport LAYER

CCSDS has developed the SCPS Transport Protocol (SCPS-TP) \[13\] for the
Transport Layer. The CCSDS File Delivery Protocol (CFDP) \[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 is
based on TCP and UDP of the Internet and is intended to be used on top
of SCPS-NP, IP Version 4 or IP Version 6. A summary of concept and
rationale of SCPS-TP is contained in reference \[32\].

CFDP is designed to meet the needs of space missions to transfer files
to and from an onboard mass memory. It is a file transfer protocol, but
it also provides the functionality of the Transport Layer for detecting
and retransmitting corrupted or lost data. It can be used on top of any
protocol of the Network Layer (e.g., Space Packet Protocol, SCPS-NP, IP
Version 4 or IP Version 6), or directly on top of the TC Space Data Link
Protocol or Proximity-1 Space Link Protocol if a Virtual Channel, a MAP
or a Port is dedicated to CFDP. In some circumstances it can be used on
top of UDP, TCP or SCPS-TP. A summary of concept and rationale of CFDP
is contained in reference \[33\].

Transport protocols used in the Internet (such as TCP \[21\] and UDP
\[22\]) can also be used on top of SCPS-NP, IP Version 4 and IP Version
6 over space links.

SCPS Security Protocol (SCPS-SP) \[12\] can be used with the above
protocols to provide end-to-end data protection capability. A summary of
concept and rationale of SCPS-SP is contained in reference \[32\].

## Application LAYER

CCSDS has developed two protocols for the Application Layer:

a)  SCPS File Protocol (SCPS-FP) \[14\];

b)  Lossless Data Compression \[16\].

The CCSDS File Delivery Protocol (CFDP) \[15\] also provides the
functionality of the Application Layer (i.e., functions for file
management), but it provides functions of the Transport Layer as well.

SCPS-FP provides a file transfer service and is designed to meet the
needs of current and future space missions. It is based on FTP of the
Internet and is intended to be used on top of SCPS-TP or TCP. A summary
of concept and rationale of SCPS-FP is contained in reference \[32\].

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

Applications protocols used in the Internet (such as FTP \[23\]) can
also be used on top of SCPS-TP, TCP and UDP over space links.

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 link protocols.

# EXAMPLES OF PROTOCOL CONFIGURATIONS

## GENERAL

This section shows some examples of how space link 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 link
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 link protocols are used
in an end-to-end space data system. It will be shown that some space
link protocols are used for end-to-end communications between onboard
and ground end systems, and some space link protocols are used only for
communications over the space link.

![](media/image6.wmf)

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. 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. This functionality is called 'end-to-end
routing' in this Report.

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

a)  Space Packet Protocol;

b)  SCPS-NP and IP (version 4 or 6);

c)  IP version 4;

d)  IP version 6;

e)  CFDP.

NOTES

1.  In the following figures, 'Prox Space Data Link Protocol' denotes
    the Data Link Layer portion of the Proximity-1 Space Link Protocol.
    When the Proximity-1 Space Link Protocol is used in the Data Link
    Layer, it is also in the Physical Layer.

2.  In the following figures, the Synchronization and Channel Coding
    standards are omitted for simplicity reasons.

## Space Packet Protocol for end-to-end routing

In this example, the Space Packet Protocol is used for end-to-end
routing. 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 addressing and routing 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.

When the Space Packet Protocol is used for end-to-end routing, Space
Packets are usually transferred with a Space Link Extension (SLE)
Service (see reference \[27\]) in the ground subnetwork.

![](media/image7.wmf)

Figure 4‑2: Protocol Configuration on a Space Link When Space Packet
Protocol Is Used for End-to-End Routing

![](media/image8.wmf)

Figure 4‑3: Protocol Configuration in a Space Data System When Space
Packet Protocol Is Used for End-to-End Routing

## SCPS-NP AND IP for End-to-end Routing

In the second example, SCPS-NP and IP (either version 4 or 6) is used
for end-to-end routing. This configuration is suited to space missions
that require the extended addressing and routing capabilities provided
by SCPS-NP and/or need to use SCPS or Internet upper-layer protocols.

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. In this configuration, SCPS-NP is used for
routing except in the ground subnetwork where IP is used for routing. A
gateway at the ground relay system performs protocol conversion between
SCPS-NP and IP.

Most SCPS and Internet end-to-end protocols can be used on top of
SCPS-NP and IP. SCPS-TP can be converted to TCP/UDP at a relay system.
More information on this configuration is found in reference \[31\].

![](media/image9.wmf)

Figure 4‑4: Protocol Configuration on a Space Link When SCPS-NP and IP
Are Used for End-to-End Routing

![](media/image10.wmf)

Figure 4‑5: Protocol Configuration in a Space Data System When SCPS-NP
and IP Are Used for End-to-End Routing

## IP Version 4 for End-to-end Routing

In the third example, IP version 4 is used for end-to-end routing. IP
Version 4 is the protocol used for routing in the Internet, but it can
also be carried by a Space Data Link Protocol over a space link. This
configuration is suited to space missions that require integration of
their space segments into the Internet.

Figure 4-6 shows an example of protocol configuration on a space link,
and figure 4-7 shows an example of protocol configuration in an
end-to-end space data system.

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 Version 4. SCPS-TP can be converted to TCP/UDP
at a relay system.

![](media/image11.wmf)

Figure 4‑6: Protocol Configuration on a Space Link When IP Version 4 Is
Used for End-to-End Routing

![](media/image12.wmf)

Figure 4‑7: Protocol Configuration in a Space Data System When IP
Version 4 Is Used for End-to-End Routing

## IP Version 6 for End-to-end Routing

In the fourth example, IP Version 6 is used for end-to-end routing. IP
Version 6 is an upgraded version of IP Version 4 and is expected to
replace the latter in the near future in the Internet. This
configuration is suited to space missions that require integration of
their space segments into the Internet when IP Version 6 is deployed.

Figure 4-8 shows an example of protocol configuration on a space link,
and figure 4-9 shows an example of protocol configuration in an
end-to-end space data system.

Protocol data units (datagrams) of IP version 6 are transferred by Space
Data Link Protocols using Encapsulation Packets in order for the Space
Data Link Protocols to process IP Version 6 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 Version 6. SCPS-TP can be converted to TCP/UDP
at a relay system.

![](media/image13.wmf)

Figure 4‑8: Protocol Configuration on a Space Link When IP Version 6 Is
Used for End-to-End Routing

![](media/image14.wmf)

Figure 4‑9: Protocol Configuration in a Space Data System When IP
Version 6 Is Used for End-to-End Routing

## CFDP for End-to-end Routing

In the final example, CFDP is used for end-to-end routing. CFDP is a
file transfer protocol, but it also has the capability to route files
through a space data system. This configuration is suited to space
missions in which most data are transferred as files.

Figure 4-10 shows an example of protocol configuration on a space link,
and figure 4-11 shows an example of protocol configuration in an
end-to-end space data system.

In this example, it is assumed that protocol data units of CFDP are
carried by the Space Packet Protocol over the space link, but they can
also be carried by SCPS-NP, IP Version 4 or IP Version 6. They can also
be carried directly by the TC Space Data Link Protocol or Proximity-1
Space Link Protocol if a Virtual Channel, a MAP or a Port is dedicated
to CFDP.

![](media/image15.wmf)

Figure 4‑10: Protocol Configuration on a Space Link When CFDP Is Used
for End-to-End Routing

![](media/image16.wmf)

Figure 4‑11: Protocol Configuration in a Space Data System When CFDP Is
Used for End-to-End Routing

########   ACRONYMS

This annex lists the acronyms used in this Report.

AOS Advanced Orbiting Systems

APID Application Process Identifier

CCSDS Consultative Committee for Space Data Systems

CFDP CCSDS File Delivery Protocol

FSH Frame Secondary Header

FTP File Transfer Protocol

IP Internet Protocol

MAP Multiplexer Access Point

MC Master Channel

MCID Master Channel Identifier

N/A Not Applicable

OCF Operational Control Field

PVN Packet Version Number

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

SLE Space Link Extension

TC Telecommand

TCP Transmission Control Protocol

TFVN Transfer Frame Version Number

TM Telemetry

UDP User Datagram Protocol

VC Virtual Channel

VCID Virtual Channel Identifier

[^1]: ^†^ At time of publication, several documents referenced in this
    list had not yet been approved by the CCSDS for final release. For
    such documents, current draft versions have been referenced, even
    though in some cases those draft versions may not be generally
    available. For all draft CCSDS documents referenced, users of this
    Report are advised to substitute released versions as soon as they
    become available.

[^2]: ^‡^ Internet Request for Comments (RFC) texts are available on
    line in various locations (e.g., http://ietf.org/rfc/). In this
    list, Internet Standards are identified by 'STD' followed by the
    number of the standard, and RFCs are identified by 'RFC' followed by
    the number of the RFC. RFCs comprised by Internet Standards are
    given in square brackets following the citation.