ISO 22671:2021

INTERNATIONAL ISO
STANDARD 22671
Fourth edition
2021-06
Space data and information transfer
systems — Space link extension
(SLE) — Forward communications
link transmission unit (CLTU) service
specification
Systèmes de transfert des informations et données spatiales —
Extension de liaisons spatiales (SLE) — Service de l'unité de
transmission pour la liaison d'envoi de télécommande (CLTU)
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – 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 (see 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 (see 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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html.
This document was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
912.1-B-4, August 2016) and was adopted (without modifications) by Technical Committee ISO/TC 20,
Space vehicles, Subcommittee SC 13, Space data and information transfer systems.
This fourth edition cancels and replaces the third edition (ISO 22671:2011), which has been technically
revised.
The main changes compared to the previous edition are as follows:
— adds clarifications and corrections.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
CONTENTS
Section Page
1 INTRODUCTION . 1-1
1.1 PURPOSE OF THIS RECOMMENDED STANDARD . 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 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-5
1.7 REFERENCES . 1-12
2 DESCRIPTION OF THE FORWARD CLTU SERVICE . 2-1
2.1 OVERVIEW . 2-1
2.2 SPACE LINK EXTENSION REFERENCE MODEL . 2-2
2.3 SERVICE MANAGEMENT . 2-3
2.4 ARCHITECTURE MODEL – FUNCTIONAL VIEW . 2-3
2.5 ARCHITECTURE MODEL – CROSS-SUPPORT VIEW . 2-6
2.6 FUNCTIONAL DESCRIPTION . 2-7
2.7 OPERATIONAL SCENARIO . 2-14
2.8 SECURITY ASPECTS OF THE SLE FORWARD CLTU
TRANSFER SERVICE . 2-16
3 FORWARD CLTU SERVICE OPERATIONS . 3-1
3.1 GENERAL CONSIDERATIONS . 3-1
3.2 CLTU-BIND . 3-8
3.3 CLTU-UNBIND . 3-15
3.4 CLTU-START . 3-18
3.5 CLTU-STOP . 3-22
3.6 CLTU-TRANSFER-DATA . 3-25
3.7 CLTU-ASYNC-NOTIFY . 3-33
3.8 CLTU-SCHEDULE-STATUS-REPORT . 3-39
3.9 CLTU-STATUS-REPORT . 3-43
3.10 CLTU-GET-PARAMETER . 3-48
3.11 CLTU-THROW-EVENT . 3-53
3.12 CLTU-PEER-ABORT . 3-58
4 CLTU PROTOCOL . 4-1
4.1 GENERIC PROTOCOL CHARACTERISTICS . 4-1
4.2 CLTU SERVICE PROVIDER BEHAVIOR . 4-4
CCSDS 912.1-B-4 Page vi August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
CONTENTS (continued)
Section Page
ANNEX A DATA TYPE DEFINITIONS (NORMATIVE) . A-1
ANNEX B PRODUCTION STATUS (NORMATIVE) .B-1
ANNEX C CONFORMANCE OPTIONS MATRIX (NORMATIVE) . C-1
ANNEX D INDEX TO DEFINITIONS (INFORMATIVE) . D-1
ANNEX E ACRONYMS (INFORMATIVE) .E-1
ANNEX F THROW EVENT DEFINITIONS (INFORMATIVE) . F-1
ANNEX G INFORMATIVE REFERENCES (INFORMATIVE) . G-1
Figure
1-1 SLE Services Documentation . 1-4
2-1 Forward TC Space Link Processing SLE-FG . 2-4
2-2 Forward CLTU Service Production and Provision . 2-5
2-3 Example of Management and Provision of Forward CLTU Service . 2-6
2-4 Simplified Forward CLTU Service Provider State Transition Diagram . 2-9
2-5 Communications Realization of Forward CLTU Service. 2-12
B-1 CLTU Production Status Transitions .B-1

Table
2-1 Forward CLTU Service Operations . 2-8
3-1 Setting of Forward CLTU Service Configuration Parameters . 3-6
3-2 CLTU-BIND Parameters . 3-9
3-3 CLTU-UNBIND Parameters . 3-16
3-4 CLTU-START Parameters . 3-18
3-5 CLTU-STOP Parameters . 3-22
3-6 CLTU-TRANSFER-DATA Parameters . 3-25
3-7 CLTU-ASYNC-NOTIFY Parameters . 3-33
3-8 CLTU-SCHEDULE-STATUS-REPORT Parameters . 3-39
3-9 CLTU-STATUS-REPORT Parameters . 3-43
3-10 CLTU-GET-PARAMETER Parameters . 3-48
3-11 Forward CLTU Parameters . 3-50
3-12 CLTU-THROW-EVENT Parameters . 3-54
3-13 CLTU-PEER-ABORT Parameters . 3-58
4-1 Provider Behavior . 4-7
4-2 Event Description References . 4-10
4-3 Predicate Definitions . 4-10
4-4 Boolean Flags . 4-11
4-5 Compound Action Definitions . 4-11
CCSDS 912.1-B-4 Page vii August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
CONTENTS (continued)
Table Page
B-1 Production Status Changes and Notifications .B-2
B-2 Effect of Production Status on Operations .B-5
C-1 Conformance Matrix for CLTU Service (Operations) .C-1
C-2 Conformance Matrix for CLTU Service (Other Requirements) .C-1
F-1 Throw Event Examples . F-1

CCSDS 912.1-B-4 Page viii August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED STANDARD
This Recommended Standard defines the Communications Link Transmission Unit (CLTU)
service in conformance with the transfer services specified in reference [1], Cross Support
Reference Model—Part 1: SLE Services. The Forward CLTU service is a Space Link
Extension (SLE) transfer service that enables a mission to send Communications Link
Transmission Units (CLTUs) to a spacecraft.
1.2 SCOPE
This Recommended Standard defines, in an abstract manner, the Forward CLTU service in
terms of:
a) the operations necessary to provide the transfer service;
b) the parameter data associated with each operation;
c) the behaviors that result from the invocation of each operation; and
d) the relationship between, and the valid sequence of, the operations and resulting
behaviors.
It does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems;
c) the methods or technologies required to radiate data to a spacecraft and to acquire
telemetry frames from the signals received from that spacecraft for extraction of the
Operational Control Field;
d) the methods or technologies required for communications; or
e) the management activities necessary to schedule, configure, and control the Forward
CLTU service.
1.3 APPLICABILITY
1.3.1 APPLICABILITY OF THIS RECOMMENDED STANDARD
This Recommended Standard provides a basis for the development of real systems that
implement the Forward CLTU service. Implementation of the Forward CLTU service in a
real system additionally requires the availability of a communications service to convey
invocations and returns of Forward CLTU service operations between service users and
CCSDS 912.1-B-4 Page 1-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
providers. This Recommended Standard requires that such a communications service ensure
that invocations and returns of operations are transferred:
a) in sequence;
b) completely and with integrity;
c) without duplication;
d) with flow control that notifies backpressure to the application layer in the event of
congestion; and
e) with notification to the application layer in the event that communications between
the Forward CLTU service user and the Forward CLTU service provider are
disrupted, possibly resulting in a loss of data.
It is the specific intent of this Recommended Standard to define the Forward CLTU service
in a manner that is independent of any particular communications services, protocols, or
technologies.
1.3.2 LIMITS OF APPLICABILITY
This Recommended Standard specifies the Forward CLTU service that may be provided by
an SLE System for inter-Agency cross support. It is neither a specification of, nor a design
for, real systems that may be implemented for the control and monitoring of existing or
future missions.
1.4 RATIONALE
The goal of this Recommended Standard is to create a standard for interoperability between
the tracking stations or ground data handling systems of various agencies and the users of
forward services.
1.5 DOCUMENT STRUCTURE
1.5.1 DOCUMENT ORGANIZATION
This Recommended Standard is organized as follows:
a) section 0 provides purpose, scope, applicability, and rationale of this Recommended
Standard and lists definitions, nomenclature, conventions, and references used
throughout the Recommended Standard;
b) section 2 presents an overview of the Forward CLTU service including a functional
description, the service management context, and protocol considerations;
c) section 3 specifies the operations of the Forward CLTU service;
CCSDS 912.1-B-4 Page 1-2 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
d) section 4 specifies the dynamic behavior of the Forward CLTU service in terms of the
state transitions of the Forward CLTU service provider;
e) annex A is a formal specification of Forward CLTU service data types, using the
Abstract Syntax Notation One (ASN.1);
f) annex B explains the relationship of the Forward CLTU service provisioning on the
production status and its dependency on the status of the forward space link channel.
g) annex C provides a conformance matrix that defines what capabilities must be
provided for an implementation to be considered compliant with this Recommended
Standard;
h) annex D lists all terms used in this document and identifies where they are defined;
i) annex E lists all acronyms used within this document;
j) annex F contains examples of usage of the CLTU-THROW-EVENT operation;
k) annex G contains a list of informative references.
1.5.2 SLE SERVICES DOCUMENTATION TREE
This Recommended Standard is based on the architectural model for cross support defined in
reference [1]. It expands upon the concept of an SLE transfer service as interactions between
SLE Mission User Entities (MUEs) and an SLE transfer service provider for the purpose of
providing the Forward CLTU transfer service.
This Recommended Standard is part of a suite of documents specifying the SLE Services.
The SLE Services constitute one of the three types of Cross Support Services:
a) Part 1: SLE Services;
b) Part 2: Ground Communications Services;
c) Part 3: Ground Domain Services.
The basic organization of the SLE services documentation is shown in figure 1-1. The
documents are described in the following paragraphs.
CCSDS 912.1-B-4 Page 1-3 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
Space Link Extension
Cross Support
Cross Support Concept SLE Executive
Reference Model
Part 1: SLE Services Summary
Part 1: SLE Services
SLE Transfer Services
Forward SLE Service
Return SLE Service
Specifications Specifications
SLE Service
Management Suite
SLE API for Internet Protocol for
Transfer Services Transfer Services
Recommended Recommended Informational
Legend:
Record (Yellow)
Standard (Blue) Practice (Magenta) Report (Green)

Figure 1-1: SLE Services Documentation

a) Cross Support Concept – Part 1: Space Link Extension Services (reference [G3]): a
Report introducing the concepts of cross support and SLE services;
b) Cross Support Reference Model—Part 1: Space Link Extension Services
(reference [1]): a Recommended Standard that defines the framework and
terminology for the specification of SLE services;
c) Return SLE Transfer Service Specifications: a set of Recommended Standards that
will provide specification of all return link SLE transfer services.
d) Forward SLE Transfer Service Specifications: a set of Recommended Standards that
will provide specification of all forward link SLE transfer services (this
Recommended Standard is one of the specifications in that set);
e) SLE API for Transfer Services Specifications: a set of Recommended Practices that
provide specifications of an Application Program Interface; a set of Recommended
Standards that provide specifications of an Application Program Interface and a
mapping to TCP/IP as underlying communications service for SLE services;
f) Internet Protocol for Transfer Services: defines a protocol for transfer of SLE Protocol
Data Units using TCP/IP as underlying communications service for SLE services;
g) SLE Service Management Specification Suite: a set of Recommended Standards that
establish the basis for SLE service management.
CCSDS 912.1-B-4 Page 1-4 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from Open Systems Interconnection (OSI) Basic Reference Model
This Recommended Standard makes use of a number of terms defined in reference [7]. The
use of those terms in this Recommended Standard shall be understood in a generic sense, i.e.,
in the sense that those terms are generally applicable to technologies that provide for the
exchange of information between real systems. Those terms are:
a) abstract syntax;
b) application entity;
c) application layer;
d) flow control;
e) Open System Interconnection (OSI);
f) real system;
g) service access point (SAP).
1.6.1.2 Definitions from Abstract Syntax Notation One
This Recommended Standard makes use of the following terms defined in reference [6]:
a) Abstract Syntax Notation One (ASN.1);
b) object identifier;
c) (data) type;
d) (data) value.
NOTE − In annex A of this Recommended Standard, ASN.1 is used for specifying the
abstract syntax of the invocations and returns of the operations of the Forward
CLTU service. The use of ASN.1 as a descriptive language is intended to
support the specification of the abstract Forward CLTU service; it is not intended
to constrain implementations. In particular, there is no requirement for
implementations to employ ASN.1 encoding rules. ASN.1 is simply a
convenient tool for formally describing the abstract syntax of the invocations and
returns of the Forward CLTU service.
1.6.1.3 Definitions from TC Synchronization and Channel Coding
This Recommended Standard makes use of the following terms defined in reference [2]:
CCSDS 912.1-B-4 Page 1-5 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
a) acquisition sequence;
b) Communications Link Transmission Unit (CLTU);
c) Carrier Modulation Mode (CMM);
d) idle sequence;
e) Physical Layer operations procedure (PLOP).
1.6.1.4 Definitions from TC Space Data Link Protocol
This Recommended Standard makes use of the following term defined in reference [3]:
Communications Link Control Word (CLCW).
1.6.1.5 Definitions from SLE Reference Model
This Recommended Standard makes use of the following terms defined in reference [1]:
a) abstract binding;
b) abstract object;
c) abstract port;
d) abstract service;
e) CLTU channel;
f) Forward CLTU service;
g) invoker;
h) Mission Data Operation System (MDOS);
i) Mission User Entity (MUE);
j) offline delivery mode;
k) online delivery mode;
l) operation;
m) performer;
n) physical channel;
o) service agreement;
p) service provider (provider);
q) service user (user);
CCSDS 912.1-B-4 Page 1-6 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
r) SLE Complex;
s) SLE Complex Management;
t) SLE data channel;
u) SLE functional group (SLE-FG);
v) SLE protocol data unit (SLE-PDU);
w) SLE service data unit (SLE-SDU);
x) SLE service package;
y) SLE transfer service instance;
z) SLE transfer service production;
aa) SLE transfer service provision;
bb) SLE Utilization Management;
cc) space link;
dd) space link data channel;
ee) space link data unit (SL-DU);
ff) space link session.
1.6.1.6 Additional Definitions
For the purposes of this Recommended Standard, the following definitions also apply.
1.6.1.6.1 Association
An association is a cooperative relationship between an SLE service-providing application
entity and an SLE service-using application entity. An association is formed by the
exchange of SLE protocol data units through use of an underlying communications service.
1.6.1.6.2 Communications Service
A communications service is a capability that enables an SLE service-providing application
entity and an SLE service-using application entity to exchange information.
NOTE – If an SLE service user and an SLE service provider are implemented using
different communications services, then interoperability between them is possible
only by means of a suitable gateway. Adherence to this Recommended Standard
ensures, at least in principle, that it is possible to construct such a gateway.
CCSDS 912.1-B-4 Page 1-7 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1.6.1.6.3 Confirmed Operation
A confirmed operation is an operation that requires the performer to return a report of its
outcome to the invoker.
1.6.1.6.4 Initiator
The initiator is the object that issues the request to bind to another object (the responder).
NOTE – In other words, the initiator is always the invoker of the request to bind to
another object. Therefore, in the context of the request to bind, the terms
‘initiator’ and ‘invoker’ refer to the same object and are synonyms.
1.6.1.6.5 Invocation
The invocation of an operation is the making of a request by an object (the invoker) to
another object (the performer) to carry out the operation.
1.6.1.6.6 Parameter
A parameter of an operation is data that may accompany the operation’s invocation or return.
NOTE – The term parameter is also used to refer to mission-dependent configuration
information used in production or provision of the service.
1.6.1.6.7 Performance
The performance of an operation is the carrying out of the operation by an object (the
performer).
1.6.1.6.8 Port Identifier
A port identifier identifies a source or a destination in a communications system.
NOTE – See 2.6.4.6 for more information.
1.6.1.6.9 Responder
The responder is the object that receives a request to bind and completes the binding (if
possible) with the initiator in order for a service association to exist between the two objects.
CCSDS 912.1-B-4 Page 1-8 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
NOTE – In other words, the responder is always the performer of the binding. Therefore,
in the context of binding, the terms ‘responder’ and ‘performer’ refer to the same
object and are synonyms.
1.6.1.6.10 Return
The return of an operation is a report, from the performer to the invoker, of the outcome of
the performance of the operation.
1.6.1.6.11 Service Instance Provision Period
A service instance provision period is the time during which a service instance (i.e., the
capability to transfer one or more SLE data channels of a given type) is scheduled to be
provided.
1.6.1.6.12 Unconfirmed Operation
An unconfirmed operation is an operation that does not require a report of its outcome to be
returned to the invoker by the performer.
1.6.2 NOMENCLATURE
The following conventions apply throughout 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.
1.6.3 CONVENTIONS
1.6.3.1 Specification of Operations
1.6.3.1.1 General
Section 3 of this Recommended Standard specifies the operations that constitute the Forward
CLTU service. The specification of each operation is divided into subsections as follows:
CCSDS 912.1-B-4 Page 1-9 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1.6.3.1.2 Purpose Subsection
The Purpose subsection briefly describes the purpose and functioning of the operation.
Additionally, it indicates whether the operation may be invoked by the user, provider, or
both; whether the operation is confirmed or unconfirmed; and whether there are any
constraints on when the operation may be invoked.
1.6.3.1.3 Invocation, Return, and Parameters Subsection
The Invocation, Return, and Parameters subsection describes the parameters associated with
each operation, including their semantics. A table accompanying the description of each
operation lists all parameters associated with the operation and, for both the invocation and
return, whether the parameter is always present, always absent, or conditionally present.
For parameters that are conditionally present, the parameter description specifies the
conditions for the presence or absence of the parameter. The condition is generally based on
the value of another parameter in the same invocation or return; for example, in return of an
operation, the diagnostic parameter is present if and only if the value of the result
parameter is ‘negative result’. For a conditional parameter in a return, the condition may be
based on the value of a parameter in the corresponding invocation.
In the table, the following convention is used to indicate whether a parameter is always
present, always absent, or conditionally present:
M always present (mandatory)
C conditionally present
Blank always absent
NOTE – Even though a parameter may be characterized as always present, its description
may specify that its value is permitted to be ‘null’ or ‘unused’ or the like.
1.6.3.1.4 Effects Subsection
The Effects subsection describes the effects an operation has on the invoker, the performer,
the association between them, or any combination thereof. The details of how those effects
occur or the mechanisms used are outside the scope of this Recommended Standard.
1.6.3.2 Typographic Conventions
Typographic conventions used in this Recommended Standard are described in the following
subsections.
CCSDS 912.1-B-4 Page 1-10 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1.6.3.2.1 Operation Names
Names of Forward CLTU service operations appear in uppercase and begin with the
characters ‘CLTU-’ (e.g., CLTU-TRANSFER-DATA).
1.6.3.2.2 Parameter Names
In the main text, names of parameters of Forward CLTU service operations appear in
lowercase and are typeset in a fixed-width font (e.g., responder-port-identifier).
In annex A, the corresponding name is formed by omitting any hyphens contained in the
name and using mixed-case (e.g., responderPortIdentifier).
1.6.3.2.3 Value Names
The values of many parameters discussed in this Recommended Standard are represented by
names. In the main text, these names are shown in single quotation marks (e.g., ‘no such
service instance’). The corresponding name in annex A is formed by omitting any hyphens
or white space contained in the name and using mixed-case (e.g.,
noSuchServiceInstance). The actual value associated with the name is constrained
by the type of the parameter taking on this value. Parameter types are specified in annex A
of this Recommended Standard.
NOTE – The name of a value does not imply anything about type. For example, the value
‘no such service instance’ has the appearance of a character string but might be
assigned to a parameter whose type is integer.
1.6.3.2.4 State Names
This Recommended Standard specifies the states of Forward CLTU service providers. States
may be referred to by number (e.g., state 3) or by name. State names are always shown in
single quotation marks (e.g., ‘active’).
1.6.3.2.5 SLE-PDU Names
The names of SLE-PDUs appear in mixed-case (e.g., cltuBindInvocation).
1.6.3.2.6 Data Type Definitions
Data type definitions for the Forward CLTU service are presented in annex A in the form of a
set of ASN.1 modules. Regardless of the conventions used elsewhere in this Recommended
Standard, the text of the ASN.1 modules is typeset entirely in a fixed-width font.
CCSDS 912.1-B-4 Page 1-11 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
1.6.3.3 Other Conventions
This Recommended Standard uses the conventions specified in reference [1].
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
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 Recommended Standards.
NOTES
1 A list of informative references is provided in annex G.
2 This document takes advantage of the harmonized terminology introduced by
restructured documentation of the space link protocols (references [2], [3], and [4]).
From an interoperability point of view, they do not introduce any incompatibilities
with respect to the original set of space link protocol documents (references [G4],
[G5], [G6], and [G7]).
[1] Cross Support Reference Model—Part 1: Space Link Extension Services. Issue 2.
Recommendation for Space Data System Standards (Blue Book), CCSDS 910.4-B-2.
Washington, D.C.: CCSDS, October 2005.
[2] TC Synchronization and Channel Coding. Issue 2. Recommendation for Space Data
System Standards (Blue Book), CCSDS 231.0-B-2. Washington, D.C.: CCSDS,
September 2010.
[3] TC Space Data Link Protocol. Issue 3. Recommendation for Space Data System
Standards (Blue Book), CCSDS 232.0-B-3. Washington, D.C.: CCSDS, September 2015.
[4] Communications Operation Procedure-1. Issue 2. Recommendation for Space Data
System Standards (Blue Book), CCSDS 232.1-B-2. Washington, D.C.: CCSDS,
September 2010.
[5] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[6] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
[7] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO, 1994.
CCSDS 912.1-B-4 Page 1-12 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
2 DESCRIPTION OF THE FORWARD CLTU SERVICE
2.1 OVERVIEW
The Forward CLTU service enables the user of the service to send Communications Link
Transmission Units (CLTUs) to a spacecraft via an established forward space link channel.
A forward space link channel is a physical channel carrying an asynchronous stream of
CLTUs (reference [1]).
The service user submits CLTUs, encapsulated in Space Link Extension (SLE) Service Data
Units (SLE-SDUs), by means of the CLTU-TRANSFER-DATA operation. Production of
the Forward CLTU service by the provider entails processing the CLTUs transferred by the
user through the necessary transformations to modulate the Radio Frequency (RF) carrier
channel providing uplink communications with the spacecraft.
The Forward CLTU service transmits the CLTUs in the order in which they are submitted by
the service user. The provider may perform checks to determine if the CLTU complies with
applicable constraints, e.g., that the length of the CLTU is within the maximum size set by
service management. However, the provider does not interpret, interrogate, or modify the
contents of a CLTU. CLTUs are transmitted bit for bit as received from the service user.
CLTUs may or may not conform to the format defined in reference [2]. The Forward CLTU
service may be used to uplink any octet-aligned bit pattern.
The operations defined in section 3 of this Recommended Standard enable a single Forward
CLTU service user to interact with a Forward CLTU service provider to:
a) establish an association between the user and the provider;
b) send annotated CLTUs to the provider;
c) obtain notifications and reports regarding status, configuration, and performance of
the service;
d) temporarily stop and later re-start the sending of CLTUs;
e) release an association.
The Sequence Controlled (AD) and Expedited (BD) Services, as defined in the
Communications Operation Procedures (COP) Recommended Standard (reference [3]) are
accomplished by higher layer SLE services.
The Forward CLTU service is provided only in the online delivery mode, as defined in
reference [1]. The offline delivery mode is the subject of further study.
The provision of Forward CLTU service for access to one physical channel by one service
user constitutes one instance of service. Only a single service instance of the Forward CLTU
service may exist per physical channel at a time.
CCSDS 912.1-B-4 Page 2-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
2.2 SPACE LINK EXTENSION REFERENCE MODEL
2.2.1 INTRODUCTION
The Forward CLTU service is specified within the framework defined by the SLE Reference
Model (reference [1]). The following subsections summarize selected concepts from the
SLE reference model.
2.2.2 ABSTRACT OBJECT
An abstract object is a functional entity that interacts with other abstract objects. Objects are
of different types, which determine their function and behavior. An object is characterized
by its interfaces (one or more), which are called abstract ports, and the operations that are
made available through those interfaces.
2.2.3 ABSTRACT SERVICE
An abstract service is the capability provided by a set of operations that an abstract object

exposes at one or more of its abstract ports.
NOTE – The concept of an abstract service is to be distinguished from the concept of an
(N)-service as defined in the OSI Basic Reference Model (reference [7]). The
definition of (N)-service is in terms of the capability provided by one layer in the
OSI architecture to the layer above it. The definition of abstract service is in
terms of the capability provided by one abstract object to another abstract object.
In a cross support scenario, where one Agency is providing an SLE service to
another Agency, the object that provides the service typically is associated with
one Agency, and the object that uses the service typically is associated with the
other Agency.
2.2.4 ABSTRACT BINDING
When two abstract ports have an association established between them, they are said to be
bound. The act of establishing such an association is called abstract binding. One object (the
initiator) invokes a bind operation which is accepted (or rejected) by another object (the
responder).
2.2.5 SERVICE USER/PROVIDER
An object that offers a service to another by means of one or more of its ports is called a
service provider (provider). The other object is called a service user (user). An object may
be a provider of some services and a user of others.
CCSDS 912.1-B-4 Page 2-2 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
The terms user and provider are used to distinguish the roles of two interacting objects. In
this Recommended Standard, when two objects are involved in provision of a service, the
object closer to the space link is considered to be the provider of the service, and the object
further from the space link is considered to be the user.
2.2.6 OPERATION
An operation is a procedure or task that one object (the invoker) can request of another (the
performer) through a bound port pair.
The terms invoker and performer are used to describe the interaction between two objects as
the operations that constitute the service occur. One object invokes an operation that is
performed by the other. For most services, each object invokes some operations and
performs others.
2.3 SERVICE MANAGEMENT
SLE service management determines the number and schedule of Forward CLTU service
instances to be provided, the resources required to enable those service instances, and the
initial configuration of all service instances and their supporting resources. SLE service
management is the subject of separate CCSDS Recommended Standards.
The SLE Reference Model (reference [1]) distinguishes between service provision and
service production:
a) service provision makes available to the user the operations necessary to obtain the
service;
b) service production transforms the Forward CLTU data channel to the RF carrier
channel.
Certain configuration parameters are associated with provision of Forward CLTU service
while others are associated with production. Configuration parameters that are associated
with the production, such as bit rate and modulation index, can potentially impact SLE
Complex resources. Consequently, only service management may modify production
configuration parameter values. The Forward CLTU service user may modify some
provision configuration parameters through operations specified in this Recommended
Standard.
2.4 ARCHITECTURE MODEL – FUNCTIONAL VIEW
2.4.1 FORWARD TC SPACE LINK PROCESSING SLE FUNCTIONAL GROUP
The Forward Telecommand (TC) Space Link Processing SLE Functional Group (SLE-FG)
(shown in figure 2-1) produces the Forward CLTU service.
CCSDS 912.1-B-4 Page 2-3 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
As described in reference [1], the Forward TC Space Link Processing SLE-FG consumes one
CLTU data channel consisting of a stream of CLTU SLE-SDUs. The SLE-SDUs that
encapsulate the CLTUs contain control and annotation data that specify radiation time and
other parameters to aid in processing the data (see 3.6). The Forward TC Space Link
Processing SLE-FG uses these data to extract the CLTUs and inject them into the
asynchronous physical channel.
NOTE – Per physical forward channel, only a single instance of the Forward CLTU
service is supported at any point in time.
Space Link Channel
Forward TC Space Link Fwd CLTU
Processing
T-U T-P
SLE Functional Group
T-U
Operational Control Field
Figure 2-1: Forward TC Space Link Processing SLE-FG
The Forward TC Space Link Processing SLE-FG performs the following functions with
respect to the Forward CLTU service:
a) consumes one CLTU data channel and extracts CLTUs encapsulated in SLE Service
Data Units (SLE-SDUs);
b) consumes one Operational Control Field (OCF) data channel and extracts the
Communications Link Control Words (CLCWs). Based on the values in the CLCWs,
the Forward CLTU service determines whether the physical channel is available;
NOTE – CLCWs may be ignored, as an option set by Service Management. See 3.1.9
and table 3-11.
c) performs the following:
1) generates the acquisition sequence and idle sequence on the physical channel in
accordance with the PLOP in effect;
2) utilizes the underlying antenna steering capabilities provided by the ground
element;
CCSDS 912.1-B-4 Page 2-4 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FCLTU SERVICE
3) modulates the CLTUs as a stream of bits on the ground-to-space RF channel; and
4) radiates the signal to the spacecraft.
2.4.2 FORWARD CLTU SERVICE PRODUCTION AND PROVISION
Forward CLTU production is concerned with radiating CLTUs extracted from a stream of
SLE-SDUs according to the CLTU control and annotation information in the SLE-SDU and
according to the configuration set up by service management. Forward CLTU service
provision is concerned with receiving a stream of SLE-SDUs from a Forward CLTU service
user. Service provision addresses such matters as when service is provided (e.g., service start
and stop times), and how service is provided (e.g., which events are notified to the user).
The SLE-SDUs consumed by the Forward CLTU service are sent by the service user by
means of the Forward CLTU service operations defined in section 3. These operations also
provide additional functionality to facilitate the provision of service, i.e., enabl
...