ISO 22646:2005

INTERNATIONAL ISO
STANDARD 22646
First edition
2005-07-15
Space data and information transfer
systems — Space packet protocol
Systèmes de transfert des données et informations spatiales —
Protocole pour données spatiales par paquets

Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22646 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 133.0-B-1, September 2003) and was adopted (without modifications except those stated in Clause 2
of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.

INTERNATIONAL STANDARD ISO 22646:2005(E)

Space data and information transfer systems — Space packet
protocol
1 Scope
This International Standard specifies the space packet protocol for transferring space application data over a
network involving a ground-to-space or space-to-space communications link.
The scope and field of application are furthermore detailed in subclauses 1.1 and 1.2 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 133.0-B-1, September 2003, Space packet protocol.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 133.0-B-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-5
Add the following information to the references indicated:
[3] Document CCSDS 301.0-B-3, January 2002, is equivalent to ISO 11104:2003.
1)
[4] Document CCSDS 135.0-B-1, January 2002, is equivalent to ISO 22647:— .
Page B-1
Add the following information to the references indicated:
[B2] Document CCSDS 102.0-B-5, November 2000, is equivalent to ISO 13419:2003.
[B3] Document CCSDS 203.0-B-2, June 2001, is equivalent to ISO 12174:2003.
[B6] Document CCSDS 132.0-B-1, September 2003, is equivalent to ISO 22645:2005.

1) To be published.
[B7] Document CCSDS 232.0-B-1, September 2003, is equivalent to ISO 22664:2005.
[B8] Document CCSDS 732.0-B-1, September 2003, is equivalent to ISO 22666:2005.
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication CCSDS 133.0-B-1.
To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2005 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE PACKET
PROTOCOL
CCSDS 133.0-B-1
BLUE BOOK
September 2003
(blank page)
4 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

AUTHORITY
Issue: Blue Book, Issue 1
Date: September 2003
Location: Not Applicable
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS Recommendations is detailed in reference [B1], and the
record of Agency participation in the authorization of this document can be obtained from
the CCSDS Secretariat at the address below.

This Recommendation is published and maintained by:
CCSDS Secretariat
Office of Space Communication (Code M-3)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 133.0-B-1 Page i September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of member space Agencies. The Committee meets
periodically to address data systems problems that are common to all participants, and to
formulate sound technical solutions to these problems. Inasmuch as participation in the
CCSDS is completely voluntary, the results of Committee actions are termed
Recommendations and are not considered binding on any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
– Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
– Whenever an Agency establishes a CCSDS-related standard, the Agency will provide
other CCSDS member Agencies with the following information:
• The standard itself.
• The anticipated date of initial operational capability.
• The anticipated duration of operational service.
– Specific service arrangements are made via memoranda of agreement. Neither this
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this Recommendation will be reviewed by
the CCSDS to determine whether it should: (1) remain in effect without change; (2) be
changed to reflect the impact of new technologies, new requirements, or new directions; or,
(3) be retired or canceled.
In those instances when a new version of a Recommendation is issued, existing
CCSDS-related Agency standards and implementations are not negated or deemed to
be non-CCSDS compatible. It is the responsibility of each Agency to determine when
such standards or implementations are to be modified. Each Agency is, however,
strongly encouraged to direct planning for its new standards and implementations
towards the later version of the Recommendation.
CCSDS 133.0-B-1 Page ii September 2003
6 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

FOREWORD
This document is a technical Recommendation for use in developing flight and ground
systems for space missions and has been prepared by the Consultative Committee for Space
Data Systems (CCSDS). The Space Packet Protocol described herein is intended for
missions that are cross-supported between Agencies of the CCSDS.
This Recommendation specifies a communications protocol to be used by space missions to
transfer space application data over a network that involves a ground-to-space or space-to-
space communications link. This Recommendation was developed by consolidating the
specifications of the packet portion of three CCSDS Recommendations, references [B2]-
[B4], which define essentially the same protocol and services but in slightly different
contexts.
This Recommendation does not change the major technical contents defined in (references
[B2]-[B4]), but the presentation of the specification has been changed so that:
a) this protocol can be used to transfer any data over any space link in either direction;
b) all CCSDS space link protocols are specified in a unified manner;
c) the specification matches the Open Systems Interconnection (OSI) Basic Reference
Model (references [1] and [2]).
Together with the change in presentation, a few technical specifications in references [B2]-
[B4] have been changed in order to unify the specifications in references [B2]-[B4]. Also,
some technical terms in references [B2]-[B4] have been changed in order to unify the
terminology used in all the CCSDS Recommendations that define space link protocols and to
define this protocol as a general communications protocol. These changes are listed in annex
C of this Recommendation.
Through the process of normal evolution, it is expected that expansion, deletion or
modification to this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures, as defined in reference [B1].
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 addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 133.0-B-1 Page iii September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

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

Member Agencies
– 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
– 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 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.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 133.0-B-1 Page iv September 2003
8 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

DOCUMENT CONTROL
Document Title and Issue Date Status
CCSDS 133.0-B-1 Space Packet Protocol, Issue 1 September Original Issue
CCSDS 133.0-B-1 Page v September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

CONTENTS
Section Page
1 INTRODUCTION.1-1

1.1 PURPOSE.1-1
1.2 SCOPE.1-1
1.3 APPLICABILITY.1-1
1.4 RATIONALE.1-2
1.5 DOCUMENT STRUCTURE.1-2
1.6 CONVENTIONS AND DEFINITIONS.1-2
1.7 REFERENCES.1-5

2 OVERVIEW.2-1

2.1 CONCEPT OF SPACE PACKET PROTOCOL .2-1
2.2 OVERVIEW OF SERVICES .2-4
2.3 OVERVIEW OF FUNCTIONS. 2-6
2.4 SERVICES ASSUMED FROM SUBNETWORKS .2-7

3 SERVICE DEFINITION.3-1

3.1 OVERVIEW.3-1
3.2 SOURCE DATA.3-1
3.3 PACKET SERVICE.3-2
3.4 OCTET STRING SERVICE .3-5

4 PROTOCOL SPECIFICATION.4-1

4.1 PROTOCOL DATA UNIT. 4-1
4.2 PROTOCOL PROCEDURES AT THE SENDING END.4-8
4.3 PROTOCOL PROCEDURES AT AN INTERMEDIATE SYSTEM.4-10
4.4 PROTOCOL PROCEDURES AT THE RECEIVING END.4-11

5 MANAGED PARAMETERS .5-1

5.1 OVERVIEW OF MANAGED PARAMETERS . 5-1
5.2 PROTOCOL CONFIGURATION PARAMETERS .5-1
5.3 ROUTING PARAMETERS.5-2

ANNEX A ACRONYMS. A-1
ANNEX B INFORMATIVE REFERENCES. B-1
ANNEX C CHANGES FROM REFERENCES [B2]-[B4]. C-1

CCSDS 133.0-B-1 Page vi September 2003
10 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

CONTENTS (continued)
Figure Page
1-1 Bit Numbering Convention. 1-4
2-1 Protocol Configuration . 2-1
2-2 Example of a Logical Data Path . 2-2
2-3 Internal Organization of Protocol Entity (Sending End) . 2-7
2-4 Internal Organization of Protocol Entity (Intermediate System). 2-7
2-5 Internal Organization of Protocol Entity (Receiving End). 2-7
4-1 Space Packet Structural Components . 4-1
4-2 Packet Primary Header . 4-2
4-3 Packet Secondary Header . 4-7
4-4 Internal Organization of Protocol Entity (Sending End) . 4-9
4-5 Internal Organization of Protocol Entity (Intermediate System). 4-10
4-6 Internal Organization of Protocol Entity (Receiving End). 4-11

Table
2-1 Summary of Services Provided by Space Packet Protocol. 2-5
5-1 Protocol Configuration Parameters. 5-1
5-2 Routing Parameters. 5-2
C-1 Terms That Have Been Changed from Reference [B2].C-2
C-2 Terms That Have Been Changed from Reference [B3].C-2
C-3 Terms That Have Been Changed from Reference [B4].C-3

CCSDS 133.0-B-1 Page vii September 2003
(blank page)
12 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommendation is to specify the Space Packet Protocol. Space
missions will use this protocol to transfer space application data over a network that involves
a ground-to-space or space-to-space communications link.
1.2 SCOPE
This Recommendation defines the Space Packet Protocol in terms of:
a) the services provided to the users of this protocol;
b) the protocol data units employed by the protocol; and
c) the procedures performed by the protocol.
It does not specify:
a) individual implementations or products;
b) the implementation of service interfaces within real systems;
c) the methods or technologies required to perform the procedures; or
d) the management activities required to configure and control the protocol.
1.3 APPLICABILITY
This Recommendation applies to the creation of Agency standards and to future data
communications over space links between CCSDS Agencies in cross-support situations. The
Recommendation includes comprehensive specification of the services and protocol for inter-
Agency cross-support. It is neither a specification of, nor a design for, real systems that may
be implemented for existing or future missions.
The Recommendation specified in this document is to be invoked through the normal
standards programs of each CCSDS Agency and is applicable to those missions for which
cross-support, based on capabilities described in this Recommendation, is anticipated.
Where mandatory capabilities are clearly indicated in sections of the Recommendation, they
must be implemented when this document is used as a basis for cross-support. Where
options are allowed or implied, implementation of these options is subject to specific
bilateral cross- support agreements between the Agencies involved.
CCSDS 133.0-B-1 Page 1-1 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the
recommendations chosen, so that future evaluations of proposed changes or improvements
will not lose sight of previous decisions.
1.5 DOCUMENT STRUCTURE
This document is divided into five numbered sections and three annexes:
a) section 1 presents the purpose, scope, applicability, and rationale of this
Recommendation and lists the conventions, definitions, and references used
throughout the Recommendation;
b) section 2 provides an overview of the Space Packet Protocol;
c) section 3 defines the services provided by the protocol entity;
d) section 4 specifies the protocol data units and procedures employed by the protocol
entity;
e) section 5 lists the managed parameters associated with this protocol;
f) annex A lists all acronyms used within this document;
g) annex B provides a list of informative references;
h) annex C lists the changes from the older CCSDS Recommendations (references [B2]-
[B4]).
1.6 CONVENTIONS AND DEFINITIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from the Open Systems Interconnection (OSI) Basic Reference
Model
This Recommendation makes use of a number of terms defined in reference [1]. The use of
those terms in this Recommendation shall be understood in a generic sense; i.e., in the sense
that those terms are generally applicable to any of a variety of technologies that provide for
the exchange of information between real systems. Those terms are:
a) blocking;
b) connection;
c) entity;
d) flow control;
CCSDS 133.0-B-1 Page 1-2 September 2003
14 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

e) peer entities;
f) protocol control information;
g) protocol data unit;
h) real system;
i) segmenting;
j) service;
k) Service Access Point (SAP);
l) SAP address;
m) service data unit.
1.6.1.2 Definitions from OSI Service Definition Conventions
This Recommendation makes use of a number of terms defined in reference [2]. The use of
those terms in this Recommendation shall be understood in a generic sense; i.e., in the sense
that those terms are generally applicable to any of a variety of technologies that provide for
the exchange of information between real systems. Those terms are:
a) indication;
b) primitive;
c) request;
d) service provider;
e) service user.
1.6.1.3 Terms Defined in this Recommendation
For the purposes of this Recommendation, the following definitions also apply. Many other
terms that pertain to specific items are defined in the appropriate sections.
asynchronous: not synchronous (see below).
delimited: having a known (and finite) length; applies to data in the context of data handling.
Mission Phase: a period of a mission during which specified communications
characteristics are fixed. The transition between two consecutive mission phases may cause
an interruption of the communications services.
Physical Channel: a stream of bits transferred over a space link in a single direction.
CCSDS 133.0-B-1 Page 1-3 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

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.
synchronous: of or pertaining to a sequence of events occurring in a fixed time relationship
(within specified tolerance) to another sequence of events.
1.6.2 NOMENCLATURE
The following conventions apply throughout this Recommendation:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.6.3 CONVENTIONS
In this document, the following convention is used to identify each bit in an N-bit field. The
first bit in the field to be transmitted (i.e., the most left justified when drawing a figure) is
defined to be ‘Bit 0’; the following bit is defined to be ‘Bit 1’ and so on up to ‘Bit N–1’.
When the field is used to express a binary value (such as a counter), the Most Significant Bit
(MSB) shall be the first transmitted bit of the field, i.e., ‘Bit 0’ (see figure 1-1).
BIT N–1
BIT 0
N-BIT DATA FIELD
FIRST BIT TRANSFERRED = MSB
Figure 1-1: Bit Numbering Convention
In accordance with standard data-communications practice, data fields are often grouped into
eight-bit ‘words’ which conform to the above convention. Throughout this
Recommendation, such an eight-bit word is called an ‘octet’.
The numbering for octets within a data structure starts with zero.
By CCSDS convention, all ‘spare’ bits shall be permanently set to ‘0’.
CCSDS 133.0-B-1 Page 1-4 September 2003
16 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were
valid. All documents are subject to revision, and users of this Recommendation 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.
[1] Information Technology—Open Systems Interconnection—Basic Reference Model:
The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO,
1994.
[2] Information Technology—Open Systems Interconnection—Basic Reference Model—
Conventions for the Definition of OSI Services. International Standard, ISO/IEC
10731:1994. Geneva: ISO, 1994.
[3] Time Code Formats. Recommendation for Space Data Systems Standards, CCSDS
301.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, January 2002.
[4] Space Link Identifiers. Recommendation for Space Data System Standards, CCSDS
135.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, January 2002.
NOTE – Informative references are listed in annex B.
CCSDS 133.0-B-1 Page 1-5 September 2003
(blank page)
18 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

2 OVERVIEW
2.1 CONCEPT OF SPACE PACKET PROTOCOL
2.1.1 ARCHITECTURE
The Space Packet Protocol is designed to meet the requirements of space missions to
efficiently transfer space application data of various types and characteristics over a network
that involves a ground-to-space or space-to-space communications link (hereafter called
space link).
Figure 2-1 illustrates where the Space Packet Protocol is located in the protocol stack. The
Space Packet Protocol provides a unidirectional data transfer service from a single source
user application to one or more destination user applications through one or more
subnetworks. The path from the source user application to the destination user application(s)
through the subnetwork(s) is called a Logical Data Path (LDP).
LOGICAL
USER USER
DATA
APPLICATION APPLICATION
PATH
SPACE SPACE
PACKET PACKET
PROTOCOL PROTOCOL
SUBNETWORK SUBNETWORK
PROTOCOLS PROTOCOLS
INTERVENING
SUBNETWORKS
Figure 2-1: Protocol Configuration
As the data traverse the subnetworks of the LDP, they are carried by subnetwork-specific
mechanisms using protocols provided by the subnetworks. The selection of protocols used in
the subnetworks is determined independently for each subnetwork and may not be the same
through the entire LDP.
The LDP is configured by a service of a management system before actual data transfer
occurs, and can only be reconfigured through the management system. Every LDP is
uniquely identified by a Path Identifier (Path ID). Each LDP consists of a single source end
system, one or more destination end systems, one or more subnetworks, and, if multiple
CCSDS 133.0-B-1 Page 2-1 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

subnetworks are involved, one or more intermediate systems that interconnect the
subnetworks. An LDP involves only one subnetwork only if the source and destination end
systems are on the same subnetwork.
Figure 2-2 shows an example of an LDP from a single source user application to a single
destination user application. In this example, the source and destination end systems are
connected via three subnetworks interconnected by two intermediate systems.
NOTES
1 For typical configurations of LDPs, see reference [B5].
2 In some implementations, the functions of the source or destination Space Packet
Protocol entity depicted in figure 2-2 may be performed by the user application itself.
In such cases, the portion of the user application that performs the functions described
in this Recommendation should be regarded as the Space Packet Protocol entity.
SOURCE DESTINATION
USER USER
APPLICATION APPLICATION
SOURCE INTERMEDIATE INTERMEDIATE DESTINATION
SPACE PACKET SPACE PACKET SPACE PACKET SPACE PACKET
PROTOCOL PROTOCOL PROTOCOL PROTOCOL
ENTITY ENTITY ENTITY ENTITY
LOCAL INTERMEDIATE LOCAL
SUBNETWORK SUBNETWORK SUBNETWORK

Figure 2-2: Example of a Logical Data Path
2.1.2 PROTOCOL FEATURES
The Space Packet Protocol provides the users with services to transfer space application data
through an LDP. The major function performed by this protocol is the routing of application
data along the LDP through underlying subnetworks.
The protocol data units employed by this protocol are Space Packets (unless otherwise stated,
the term ‘Packet’ in this document refers to the Space Packet). They are variable in length
(or may be fixed at the discretion of the user) and are transmitted at variable intervals. Aside
from a header that identifies the Packet, the internal data content of Space Packets is
completely under the control of the user application. Each user application can define the
organization and content of Packets independently of other user applications and with a
CCSDS 133.0-B-1 Page 2-2 September 2003
20 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

minimum of constraints imposed by the transmission mechanisms of the underlying
subnetworks.
The Space Packet Protocol entity at the source end system either generates Space Packets
from service data units supplied by the source user application, or validates Space Packets
provided as service data units by the source user application. At the source and intermediate
systems, the Space Packet Protocol entity examines the Path ID of incoming Space Packets
and routes them through appropriate subnetworks using the mechanisms provided by the
subnetworks. Routing information (i.e., mapping from Path IDs to subnetwork addresses) is
provided to the Space Packet Protocol entities by management. If there are multiple
destinations for an LDP, multicasting of Space Packets may be performed by one or more
Space Packet Protocol entities at the source end system and/or intermediate system(s).
2.1.3 ADDRESSING
Each LDP is uniquely identified by a Path ID. A Path ID consists of an Application Process
Identifier (APID) and an optional APID Qualifier.
An APID Qualifier identifies a naming domain for APIDs and APIDs are unique only in a
single naming domain. An APID naming domain usually corresponds to a spacecraft (or an
element of a constellation of cooperating space vehicles). Each space project shall establish
APID naming domains to be used in their project. The assignment of APIDs to LDPs within
a naming domain is controlled by the space project that owns the naming domain. If a
system (or a subnetwork) handles only Space Packets associated with a single naming
domain, the APID Qualifier need not be used in the system (or the subnetwork).
While the APID is contained in the Packet Primary Header of the Space Packet, the APID
Qualifier does not appear in the data structure defined by the Space Packet Protocol. The
value of the APID Qualifier is usually carried by a protocol (or protocols) of the underlying
subnetworks.
If Space Packets are transferred over a space-to-ground or space-to-space communications
link with one of the Space Data Link Protocols (references [B6]-[B8]), the Master Channel
Identifier (MCID), carried by the Space Data Link Protocol and defined therein, shall be used
as the APID Qualifier.
2.1.4 PROTOCOL DESCRIPTION
The Space Packet Protocol is described in terms of:
a) the services provided to the users;
b) the protocol data units; and
c) the procedures performed by the protocol.
CCSDS 133.0-B-1 Page 2-3 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

The service definitions are given in the form of primitives, which present an abstract model
of the logical exchange of data and control information between the protocol entity and the
service user. The definitions of primitives are independent of specific implementation
approaches.
The procedure specifications define the procedures performed by protocol entities for the
transfer of information between peer entities. The definitions of procedures are independent
of specific implementation methods or technologies.
This protocol specification also specifies the requirements for the services provided by the
underlying subnetworks.
2.2 OVERVIEW OF SERVICES
2.2.1 COMMON FEATURES OF SERVICES
The Space Packet Protocol provides users with data transfer services. The point at which a
service is provided by a protocol entity to a user is called an SAP (see reference [1]). A
Service Access Point of the Space Packet Protocol is identified by a Path ID and each service
user is also identified by a Path ID.
Service data units submitted to a SAP are processed in the order of submission. No
processing order is maintained for service data units submitted to different SAPs.
NOTE – Implementations may be required to perform flow control at a SAP between the
service user and the service provider. However, CCSDS does not recommend a
scheme for flow control between the user and the provider.
The followings are features common to the services defined by this Recommendation:
a) Pre-configured Services. The user can send or receive data only through a pre-
configured LDP established by management.
b) Unidirectional (one way) Services. One end of an LDP can send, but not receive,
data through the LDP, while the other end can receive, but not send.
c) Asynchronous Services. There are no predefined timing rules for the transfer of
service data units supplied by the service user. The user may request data transfer at
any time it desires, but there may be restrictions imposed by the provider on the data
generation rate.
d) Unconfirmed Services: the sending user does not receive confirmation from the
receiving end that data has been received.
e) Incomplete Services. The services do not guarantee completeness, nor do they
provide a retransmission mechanism.
CCSDS 133.0-B-1 Page 2-4 September 2003
22 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

f) Non–sequence Preserving Services. The sequence of service data units supplied by
the sending user may not be preserved through the LDP.
NOTE – This protocol may be used for sending data from user A to user B and from user
B to user A, but two LDPs, one for each direction, should be used in such cases.
The end-to-end quality-of-service provided to service users will vary according to the
individual qualities-of-service provided by the various subnetworks along the LDP. The
Space Packet Protocol does not provide any mechanisms for guaranteeing a particular
quality-of-service; it is the responsibility of implementing organizations to ensure that the
end-to-end performance of a particular service instance meets the requirements of its users.
2.2.2 SUMMARY OF SERVICES
2.2.2.1 General
The Space Packet Protocol provides two services: Packet Service and Octet String Service.
Table 2-1 summarizes these services.
Table 2-1: Summary of Services Provided by Space Packet Protocol

Service Service Data Unit SAP Address
Packet Space Packet Path ID
Octet String Octet String Path ID

Each source or destination SAP of an LDP has an associated type of service, either Packet or
Octet String. The service type need not be preserved from end to end of the LDP; i.e.,
asymmetric services may be provided. For instance, an invocation of the Octet String
Service at the source end system may (at the user’s request) result in an instance of the
Packet Service at the destination end system(s) of the same LDP.
NOTE – As explained in 2.1.2, the protocol data unit is the Space Packet for both service
types. In the case of the Packet Service, the same Space Packet is used both as
the service data unit and as the protocol data unit.
2.2.2.2 Packet Service
The Packet Service transfers Space Packets, pre-formatted by the service user, intact through
the LDP. The service user must generate Space Packets according to the specification given
in subsection 4.1 of this Recommendation. Space Packets supplied by the service user are
transferred by the service provider without further formatting.
CCSDS 133.0-B-1 Page 2-5 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL
2.2.2.3 Octet String Service
The Octet String service transfers delimited strings of octets supplied by the service user
through the LDP. The service provider transfers the strings of octets by formatting them into
Space Packets.
2.3 OVERVIEW OF FUNCTIONS
2.3.1 GENERAL FUNCTIONS
The Space Packet Protocol transfers service data units, supplied by sending users,
encapsulated in a sequence of protocol data units known as Space Packets, using services of
underlying subnetworks. The Space Packets have variable lengths and are transferred
through subnetworks asynchronously.
The protocol entity performs the following protocol functions:
a) generation (or validation) and processing of protocol control information included in
the header to perform data identification;
b) routing of protocol data units through a series of underlying subnetworks;
c) multiplexing/demultiplexing in order for various service users (i.e., various LDPs) to
share a logical connection provided by an underlying subnetwork.
The protocol entity does not perform the following protocol functions:
a) connection establishment and release;
b) segmenting and blocking of service data units;
c) retransmission of missing service data units;
d) flow control.
2.3.2 INTERNAL ORGANIZATION OF PROTOCOL ENTITY
Figures 2-3, 2-4, and 2-5 show the internal organization of the protocol entity of the sending,
intermediate, and receiving systems, respectively. In figure 2-3, data flow from top to
bottom of the figure. In figure 2-4, data flow between top and bottom in both directions. In
figure 2-5, data flow from bottom to top.
These figures identify data-handling functions performed by the protocol entity. The
purpose of these figures is to show logical relationships among the functions of the protocol
entity. The figures are not intended to imply any hardware or software configuration in a
real system. Depending on the services actually used for a real system, not all of the
functions may be present in the protocol entity.
CCSDS 133.0-B-1 Page 2-6 September 2003
24 © ISO 2005 – All rights reserved

CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

Octet String
Packet
Service
Service
Packet
Assembly
Packet Transfer
Subnetwork
Figure 2-3: Internal Organization of Protocol Entity (Sending End)

Packet Relay
Subnetworks
Figure 2-4: Internal Organization of Protocol Entity (Intermediate System)
Octet String
Packet
Service
Service
Packet
Extraction
Path Recovery
Subnetwork
Figure 2-5: Internal Organization of Protocol Entity (Receiving End)
2.4 SERVICES ASSUMED FROM SUBNETWORKS
2.4.1 SERVICES ASSUMED FROM SUBNETWORKS
As described in 2.1.1, the Space Packet Protocol uses services provided by the underlying
subnetworks. It is intended that the Space Packet Protocol be capable of operating over
services derived from a wide variety of real subnetworks and data links. Therefore, in order
to simplify the specifications of the protocol, its operation is defined with respect to an
abstract underlying service rather than any particular real subnetwork service.
CCSDS 133.0-B-1 Page 2-7 September 2003
CCSDS RECOMMENDATION FOR SPACE PACKET PROTOCOL

It is assumed in this specification that the underlying subnetworks provide the following
capabilities to the Space Packet Protocol:
a) addressing and routing capability in the subnetwork to be used for establishing LDPs;
b) capability for associating an APID Qualifier (see 2.1.3) with each Space Packet that
traverses the subnetwork (if necessary).
2.4.2 PERFORMANCE REQUIREMENTS TO SUBNETWORKS
The performance of the underlying subnetworks shall be chosen according to the following
criteria:
a) the probability of misidentifying the APID and other values in t
...