ISO 22645:2016

INTERNATIONAL ISO
STANDARD 22645
Second edition
2016-11-15
Space data and information transfer
systems — TM (telemetry) space data link
protocol
Systèmes de transfert des données et informations spatiales — Protocole de
liaison de données spatiales TM (télémétrie)
Reference number
©
ISO 2016
©  ISO 2016
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Ch. de Blandonnet 8  CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2016 – 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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2. www.iso.org/directives
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. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 22645 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 132.0-B-2, September 2015) 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.
This second edition cancels and replaces the first edition (ISO 22645:2005), which has been technically
revised. It also incorporates the amendment ISO 22645:2005/Amd.1:2015.
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. 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 Recommended Standards and are not
considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard 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 Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 132.0-B-2 Page ii September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK 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 TM Space Data Link Protocol described herein is intended for
missions that are cross-supported between Agencies of the CCSDS.
Attention is drawn to the possibility that some of the elements of this document may be the
subject of patent rights. CCSDS has processes for identifying patent issues and for securing
from the patent holder agreement that all licensing policies are reasonable and non-
discriminatory. However, CCSDS does not have a patent law staff, and CCSDS shall not be
held responsible for identifying any or all such patent rights.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 132.0-B-2 Page iii September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 132.0-B-2 Page iv September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
DOCUMENT CONTROL
Document Title Date Status
CCSDS TM Space Data Link Protocol, September Original issue, superseded
132.0-B-1 Recommended Standard, Issue 1 2003
CCSDS TM Space Data Link Protocol, September Current issue:
132.0-B-2 Recommended Standard, Issue 2 2015 – adds specifications to
support the Space
Data Link Security
Protocol;
– updates Frame Error
Control Field
Encoding Procedure to
be consistent with
other CCSDS Space
Data Link Protocol
specifications;
– changes all
occurrences of ‘Packet
Service’ and ‘Packet
Transfer Service’ to
‘Virtual Channel
Packet Service’;
– corrects/clarifies
Service Specification
‘.indication’ text;
– updates/clarifies text
relating to Idle Packet
generation;
– removes obsolete
informative annex
detailing changes from
Historical
Recommendations
CCSDS 102.0-B-5-S
(1984–2005) and
CCSDS 103.0-B-2-S
(1996–2005).
NOTE – Substantive changes from the previous issue are marked by change bars in the
inside margin. For terminology changes affecting the entire document, only the first
instances are marked.
CCSDS 132.0-B-2 Page v September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK 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-6

2 OVERVIEW . 2-1

2.1 CONCEPT OF TM SPACE DATA LINK PROTOCOL . 2-1
2.2 OVERVIEW OF SERVICES . 2-4
2.3 OVERVIEW OF FUNCTIONS . 2-12
2.4 SERVICES ASSUMED FROM LOWER LAYERS . 2-14

3 SERVICE DEFINITION. 3-1

3.1 OVERVIEW . 3-1
3.2 SOURCE DATA. 3-1
3.3 VIRTUAL CHANNEL PACKET (VCP) SERVICE . 3-4
3.4 VIRTUAL CHANNEL ACCESS (VCA) SERVICE . 3-8
3.5 VIRTUAL CHANNEL FRAME SECONDARY HEADER (VC_FSH)
SERVICE . 3-12
3.6 VIRTUAL CHANNEL OPERATIONAL CONTROL FIELD (VC_OCF) SERVICE3-15
3.7 VIRTUAL CHANNEL FRAME (VCF) SERVICE . 3-18
3.8 MASTER CHANNEL FRAME SECONDARY HEADER (MC_FSH)
SERVICE . 3-21
3.9 MASTER CHANNEL OPERATIONAL CONTROL FIELD (MC_OCF)
SERVICE . 3-24
3.10 MASTER CHANNEL FRAME (MCF) SERVICE . 3-27

4 PROTOCOL SPECIFICATION WITHOUT SDLS OPTION . 4-1

4.1 PROTOCOL DATA UNIT . 4-1
4.2 PROTOCOL PROCEDURES AT THE SENDING END . 4-15
4.3 PROTOCOL PROCEDURES AT THE RECEIVING END . 4-22

CCSDS 132.0-B-2 Page vi September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
CONTENTS (continued)
Section Page
5 MANAGED PARAMETERS WITHOUT SDLS OPTION . 5-1

5.1 MANAGED PARAMETERS FOR A PHYSICAL CHANNEL . 5-1
5.2 MANAGED PARAMETERS FOR A MASTER CHANNEL . 5-2
5.3 MANAGED PARAMETERS FOR A VIRTUAL CHANNEL. 5-2
5.4 MANAGED PARAMETERS FOR PACKET TRANSFER . 5-3

6 PROTOCOL SPECIFICATION WITH SDLS OPTION . 6-1

6.1 OVERVIEW . 6-1
6.2 USE OF SDLS PROTOCOL . 6-1
6.3 TM TRANSFER FRAME WITH SDLS . 6-1
6.4 SENDING END PROTOCOL PROCEDURES WITH SDLS . 6-4
6.5 RECEIVING END PROTOCOL PROCEDURES WITH SDLS . 6-7
6.6 MANAGED PARAMETERS WITH SDLS . 6-9

ANNEX A ACRONYMS (INFORMATIVE) . A-1
ANNEX B INFORMATIVE REFERENCES (INFORMATIVE) .B-1
Figure
1-1 Bit Numbering Convention . 1-5
2-1 Relationship with OSI Layers . 2-1
2-2 Relationships Between Channels . 2-3
2-3 Asynchronous Service Model . 2-5
2-4 Synchronous Service Model . 2-6
2-5 Internal Organization of Protocol Entity (Sending End). 2-13
2-6 Internal Organization of Protocol Entity (Receiving End) . 2-13
2-7 TM Space Data Link Protocol Channel Tree . 2-14
4-1 TM Transfer Frame Structural Components . 4-2
4-2 Transfer Frame Primary Header. 4-2
4-3 Transfer Frame Data Field Status . 4-5
4-4 Transfer Frame Secondary Header . 4-8
4-5 Logic Diagram of the Encoder . 4-13
4-6 Logic Diagram of the Decoder . 4-14
4-7 Internal Organization of Protocol Entity (Sending End). 4-15
4-8 Abstract Model of Packet Processing Function . 4-16
4-9 Abstract Model of Virtual Channel Generation Function . 4-18
4-10 Abstract Model of Virtual Channel Multiplexing Function . 4-19
4-11 Abstract Model of Master Channel Generation Function . 4-20
CCSDS 132.0-B-2 Page vii September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
CONTENTS (continued)
Figure Page
4-12 Abstract Model of Master Channel Multiplexing Function . 4-21
4-13 Abstract Model of All Frames Generation Function . 4-22
4-14 Internal Organization of Protocol Entity (Receiving End) . 4-22
4-15 Abstract Model of Packet Extraction Function . 4-24
4-16 Abstract Model of Virtual Channel Reception Function . 4-25
4-17 Abstract Model of Virtual Channel Demultiplexing Function . 4-26
4-18 Abstract Model of Master Channel Reception Function . 4-27
4-19 Abstract Model of Master Channel Demultiplexing Function . 4-28
4-20 Abstract Model of All Frames Reception Function . 4-28
6-1 Frame without SDLS Compared to Frame with SDLS. 6-2

Table
2-1 Summary of Services Provided by TM Space Data Link Protocol . 2-7
2-2 Summary of TM Services Supported by the Space Data Link Security Protocol . 2-8
5-1 Managed Parameters for a Physical Channel . 5-1
5-2 Managed Parameters for a Master Channel . 5-2
5-3 Managed Parameters for a Virtual Channel . 5-2
5-4 Managed Parameters for Packet Transfer . 5-3
6-1 Additional Managed Parameters for a Virtual Channel when
TM Space Data Link Protocol Supports SDLS . 6-9

CCSDS 132.0-B-2 Page viii September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommended Standard is to specify the Telemetry (TM) Space Data
Link Protocol. This protocol is a Data Link Layer protocol (see reference [1]) to be used over
space-to-ground or space-to-space communications links by space missions.
1.2 SCOPE
This Recommended Standard defines the TM Space Data Link 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 Recommended Standard applies to the creation of Agency standards and to future data
communications over space links between CCSDS Agencies in cross-support situations. The
Recommended Standard 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 Recommended Standard 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 Recommended Standard is anticipated.
Where mandatory capabilities are clearly indicated in sections of the Recommended
Standard, 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 132.0-B-2 Page 1-1 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK 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 six numbered sections and two annexes:
– Section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the conventions, definitions, and references used
throughout the Recommended Standard.
– Section 2 provides an overview of the TM Space Data Link Protocol.
– Section 3 defines the services provided by the protocol entity.
– Section 4 specifies the protocol data units and procedures employed by the protocol
entity.
– Section 5 specifies the managed parameters used by the protocol entity.
– Section 6 specifies the protocol entity with support for the Space Data Link Security
Protocol.
– Annex A lists all acronyms used within this document.
– Annex B provides a list of informative references.
1.6 CONVENTIONS AND DEFINITIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from the Open Systems Interconnection (OSI) Basic Reference
Model
This Recommended Standard makes use of a number of terms defined in reference [1]. The
use of those terms in this Recommended Standard is to 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) Data Link Layer;
d) entity;
CCSDS 132.0-B-2 Page 1-2 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
e) flow control;
f) Network Layer;
g) peer entities;
h) Physical Layer;
i) protocol control information;
j) protocol data unit;
k) real system;
l) segmenting;
m) service;
n) Service Access Point (SAP);
o) SAP address;
p) service data unit.
1.6.1.2 Definitions from OSI Service Definition Conventions
This Recommended Standard makes use of a number of terms defined in reference [2]. The
use of those terms in this Recommended Standard is to 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) confirmation;
b) indication;
c) primitive;
d) request;
e) response;
f) service provider;
g) service user.
1.6.1.3 Terms Defined in This Recommended Standard
For the purposes of this Recommended Standard, the following definitions also apply. Many
other terms that pertain to specific items are defined in the appropriate sections.
aperiodic: not periodic (see below).
CCSDS 132.0-B-2 Page 1-3 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
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.
periodic: of or pertaining to a sequence of events in which each event occurs at a fixed time
interval (within specified tolerance) after the previous event in the sequence.
Physical Channel: a stream of bits transferred over a space link 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.
synchronous: of or pertaining to a sequence of events occurring in a fixed time relationship
(within specified tolerance) to another sequence of events. It should be noted that
‘synchronous’ does not necessarily imply ‘periodic’ or ‘constant rate’.
(TM) Transfer Frame: The protocol data unit of the Telemetry (TM) Space Data Link
Protocol.
1.6.2 NOMENCLATURE
1.6.2.1 Normative Text
The following conventions apply for the normative specifications in this Recommended
Standard:
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.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.6.2.2 Informative Text
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
CCSDS 132.0-B-2 Page 1-4 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
– Overview;
– Background;
– Rationale;
– Discussion.
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).
BITN-1
BIT 0
N-BIT DATA FIELD
FIRST BIT TRANSMITTED = 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 Recommended
Standard, 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 132.0-B-2 Page 1-5 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
1.7 REFERENCES
The following publications contain provisions which, through reference in this text,
constitute provisions of this document. At the time of publication, the editions indicated
were valid. All publications are subject to revision, and users of this document are
encouraged to investigate the possibility of applying the most recent editions of the
publications indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS publications.
[1] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. 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] TM Synchronization and Channel Coding. Issue 2. Recommendation for Space Data
System Standards (Blue Book), CCSDS 131.0-B-2. Washington, D.C.: CCSDS, August
2011.
[4] Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry
Applications. Issue 1. Recommendation for Space Data System Standards (Blue Book),
CCSDS 131.2-B-1. Washington, D.C.: CCSDS, March 2012.
[5] CCSDS Space Link Protocols over ETSI DVB-S2 Standard. Issue 1. Recommendation
for Space Data System Standards (Blue Book), CCSDS 131.3-B-1. Washington, D.C.:
CCSDS, March 2013.
[6] “Packet Version Number.” Space Assigned Number Authority.
http://sanaregistry.org/r/packet_version_number/.
[7] CCSDS Global Spacecraft Identification Field Code Assignment Control Procedures.
Issue 6. Recommendation for Space Data System Standards (Blue Book), CCSDS
320.0-B-6. Washington, D.C.: CCSDS, October 2013.
[8] Space Packet Protocol. Issue 1. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.0-B-1. Washington, D.C.: CCSDS, September 2003.
[9] Encapsulation Service. Issue 2. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.1-B-2. Washington, D.C.: CCSDS, October 2009.
[10] Space Data Link Security Protocol. Issue 1. Recommendation for Space Data System
Standards (Blue Book), CCSDS 355.0-B-1. Washington, D.C.: CCSDS, September
2015.
NOTE – Informative references are listed in annex B.
CCSDS 132.0-B-2 Page 1-6 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
2 OVERVIEW
2.1 CONCEPT OF TM SPACE DATA LINK PROTOCOL
2.1.1 ARCHITECTURE
The TM Space Data Link Protocol is a Data Link Layer protocol (see reference [1]) to be
used by space missions. This protocol has been designed to meet the requirements of space
missions for efficient transfer of space application data of various types and characteristics
over space-to-ground or space-to-space communications links (hereafter called space links).
Figure 2-1 illustrates the relationship of this protocol to the Open Systems Interconnection
(OSI) reference model (reference [1]). Two sublayers of the Data Link Layer are defined for
CCSDS space link protocols as shown in reference [B2]. The TM Space Data Link Protocol
corresponds to the Logical Link Sublayer, and provides functions of transferring various data
using a fixed-length protocol data unit called the Transfer Frame. The optional Space Data
Link Security Protocol (reference [10]) is provided within the Data Link Protocol Sublayer,
as illustrated below. The Synchronization and Channel Coding Sublayer provides some
additional functions necessary for transferring Transfer Frames over a space link. These
functions are delimiting/synchronizing Transfer Frames, error-correction coding/decoding
(optional), and bit transition generation/removal (optional). For the Synchronization and
Channel Coding Sublayer, the set of TM Synchronization and Channel Coding
Recommended Standards (references [3], [4], and [5]) must be used with the TM Space Data
Link Protocol. How the TM Space Data Link Protocol is used in overall space data systems
is shown in references [B2], [B3], and [B4].
OSI LAYERS CCSDS LAYERS
CCSDS
PROTOCOLS
NETWORK AND NETWORK AND
UPPER LAYERS UPPER LAYERS
TM SPACE DATA LINK
DATA LINK
PROTOCOL
PROTOCOL
&
SUBLAYER
SPACE DATA LINK
SECURITY PROTOCOL
DATA LINK LAYER
SYNCHRONIZATION TM SYNCHRONIZATION
AND CHANNEL AND
CODING SUBLAYER CHANNEL CODING
PHYSICAL LAYER PHYSICAL LAYER
Figure 2-1: Relationship with OSI Layers
CCSDS 132.0-B-2 Page 2-1 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
2.1.2 PROTOCOL FEATURES
2.1.2.1 Transfer Frames and Virtual Channels
The TM Space Data Link Protocol provides the users with several services to transfer service
data units over a space link. To facilitate simple, reliable, and robust synchronization
procedures, fixed-length protocol data units are used to transfer data through the weak-signal,
noisy space links: their length is established for a particular Physical Channel (a single stream
of bits transferred over a space link in a single direction) during a particular Mission Phase by
management. These protocol data units are known as TM Transfer Frames (unless otherwise
stated, the terms ‘Transfer Frame’ and ‘Frame’ in this document refer to the TM Transfer
Frame). Each Transfer Frame contains a header which provides protocol control information,
and a fixed-length data field within which higher-layer service data units are carried.
A key feature of the TM Space Data Link Protocol is the concept of ‘Virtual Channels’ (VC).
The Virtual Channel facility allows one Physical Channel 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’. Each Transfer Frame transferred over a Physical Channel
belongs to one of the Virtual Channels of the Physical Channel.
2.1.2.2 Optional Space Data Link Security Protocol
The Data Link Protocol Sublayer includes the Space Data Link Security (SDLS) Protocol
specified in reference [10]. The SDLS protocol can provide security, such as authentication
and confidentiality, for TM Transfer Frames. Support for the SDLS protocol is an optional
feature of the TM Space Data Link Protocol.
NOTE – The introduction of the SDLS protocol makes no changes to any requirements in
this Recommended Standard that apply to a TM Space Data Link Protocol that
does not support the SDLS protocol.
The security provided by the SDLS protocol can vary between Virtual Channels. So, for
example, there can be some Virtual Channels with security and some without. The type of
security can vary from one Virtual Channel to another.
2.1.3 ADDRESSING
There are three identifier fields in the header of Transfer Frames: 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), and
the concatenation of an MCID and a VCID is called a Global Virtual Channel Identifier
(GVCID). Therefore,
MCID = TFVN + SCID;
CCSDS 132.0-B-2 Page 2-2 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
GVCID = MCID + VCID = TFVN + SCID + VCID.
Each Virtual Channel in a Physical Channel is identified by a GVCID. Therefore, a Virtual
Channel consists of Transfer Frames with the same GVCID.
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. In most cases, a
Physical Channel carries only Transfer Frames of a single MCID, and the Master Channel
will be identical with the Physical Channel. However, a Physical Channel may carry Transfer
Frames with multiple MCIDs (with the same TFVN). In such a case, the Physical Channel
consists of multiple Master Channels. A Physical Channel is identified with a Physical
Channel Name, which is set by management and not included in the header of Transfer
Frames.
The relationships between these Channels are shown in figure 2-2.
Virtual Channel:
Identified by GVCID
Master Channel:
Identified by MCID
Physical Channel:
Identified by Physical
Channel Name
Figure 2-2: Relationships Between Channels
2.1.4 PROTOCOL DESCRIPTION
The TM Space Data Link 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.
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.
CCSDS 132.0-B-2 Page 2-3 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
This protocol specification also specifies the requirements for the underlying services
provided by the Channel Coding Sublayer and the Physical Layer.
2.2 OVERVIEW OF SERVICES
2.2.1 COMMON FEATURES OF SERVICES
The TM Space Data Link Protocol provides users with data transfer services. The point at
which a service is provided by a protocol entity to a user is called a Service Access Point
(SAP) (see reference [1]). Each service user is identified by a SAP address.
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 make any
recommendations for a scheme for flow control between the user and the
provider.
The followings are features common to all the services defined by this Recommended
Standard:
a) unidirectional (one way) services: one end of a connection can send, but not receive,
data through the space link, while the other end can receive, but not send;
b) unconfirmed services: the sending user does not receive confirmation from the
receiving end that data has been received;
c) incomplete services: the services do not guarantee completeness, but some services
may signal gaps in the sequence of service data units delivered to the receiving user;
d) sequence-preserving services: the sequence of service data units supplied by the
sending user is preserved through the transfer over the space link, although there may
be gaps and duplications in the sequence of service data units delivered to the
receiving user.
NOTE – This Recommended Standard assumes that these services are provided at the end
points of a space link. However, this Recommended Standard makes no
assumptions concerning how these end points are composed or configured either
on-board a spacecraft or in a ground system. In a ground system, the services
defined by this Recommended Standard may be extended or enhanced with Space
Link Extension Services (reference [B5]).
CCSDS 132.0-B-2 Page 2-4 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
2.2.2 SERVICE TYPES
2.2.2.1 Overview
The TM Space Data Link Protocol provides three service types (asynchronous, synchronous,
and periodic) that determine how service data units supplied by the user are transferred in
protocol data units over a space link.
The models shown below are intended only to illustrate the characteristics of services. They
are not intended to guide or restrict design of on-board or ground systems.
2.2.2.2 Asynchronous Service
In asynchronous service, there are no timing relationships between the transfer of service data
units supplied by the service user and the transmission of Transfer Frames generated by the
service provider. The user may request data transfer at any time it desires, but there may be
restrictions imposed by the service provider on the data generation rate. In this service
(figure 2-3), each service data unit from a sending user is placed in a queue, the contents of
which are sent to a receiving user in the order in which they were presented. Although
transmission errors may prevent delivery of some data units, the service provider attempts to
transfer all data units provided by the user exactly once. The timing of data transfer is
determined by the provider in accordance with mission-specific rules, and may depend on the
traffic at the time of transfer. The key feature of this service is that all of the service data
units from the sending user are transferred, and transferred only once.
Sending Receiving
User User
Provider
Transfer from sending end to
receiving end
Figure 2-3: Asynchronous Service Model
2.2.2.3 Synchronous Service
In synchronous service, the transfer of service data units is synchronized with the release of
either (1) Transfer Frames of a Virtual Channel, (2) Transfer Frames of a Master Channel, or
(3) all Transfer Frames of a Physical Channel. The transfer timing may be periodic or
aperiodic.
CCSDS 132.0-B-2 Page 2-5 September 2015
CCSDS RECOMMENDED STANDARD FOR TM SPACE DATA LINK PROTOCOL
In this service (figure 2-4), each service data unit from a sending user is placed in a buffer
that can hold only one service data unit; the content of the buffer is sent to a receiving user at
the time when a Transfer Frame is transmitted. The transmission timing of Transfer Frames
is determined by the service provider according to mission-specific rules (usually known to
the user). The key feature of this service, which is essentially time-division multiplexing, is
that the timing of data transfer is driven by the transfer mechanism, not by individual service
requests from the user. Thus a particular service data unit from a user might be sent once,
several times (if the ‘new’ value is not placed in the buffer soon enough), or not at all (if one
value is replaced by a second before the service provider can send it).
Sending Receiving
User User
Buffer
Provider
Buffer content is transferred
once per Transfer Frame
Transfer from buffer at sending end
to receiving end
Figure 2-4: Synchronous Service Model
2.2.2.4 Periodic Service
Periodic service is a special case of synchronous service in which service data units are
transferred at a constant rate. Periodic transfer from service interface to service interface is
provided with a specified max
...