ISO 18445:2013

INTERNATIONAL ISO
STANDARD 18445
First edition
2013-06-01
Space data and information transfer
systems — Space Link Extension —
Application Program Interface for the
Forward CLTU Service
Systèmes de transfert des informations et données spatiales —
Extension de liaisons spatiales — Interface du programme d'application
pour le service de l'unité de transmission pour la liaison d'envoi de
télécommande (CLTU)
Reference number
©
ISO 2013
©  ISO 2013
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
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 2013 – 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.
ISO 18445 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 916.1-M-1, October 2008) 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 18445:2013(E)

Space data and information transfer systems — Space Link
Extension — Application Program Interface for the Forward
CLTU Service
1 Scope
This International Standard specifies extensions to the API needed for support of the Command Link
Transmission Unit (CLTU) service defined in Space Link Extension—Forward CLTU Service Specification,
CCSDS 912.1-B-2.
This International Standard defines extensions to the SLE API in terms of:
a) the CLTU-specific functionality provided by API components;
b) the CLTU-specific interfaces provided by API components; and
c) the externally visible behavior associated with the CLTU interfaces exported by the components.
It does not specify
a) individual implementations or products;
b) the internal design of the components; and
c) the technology used for communications.
This International Standard defines only interfaces and behavior that must be provided by implementations
supporting the forward CLTU service in addition to the specification in Space Link Extension—Application
Program Interface for Transfer Services—Core Specification, CCSDS 914.0-M-1.
The scope and field of application are furthermore detailed in subclause 1.3 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 916.1-M-1, October 2008, Space Link Extension — Application Program Interface for the Forward
CLTU Service.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 916.1-M-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-8
Add the following information to the reference indicated:
[1] Document CCSDS 231.0-B-1, September 2003, is equivalent to ISO 22642:2005.
[2] Document CCSDS 232.0-B-1, September 2003, is equivalent to ISO 22664:2005.
[3] Document CCSDS 910.4-B-2, October 2005, is equivalent to ISO 15396:2007.
[4] Document CCSDS 912.1-B-2, December 2004, is equivalent to ISO 22671:2011.
[5] Document CCSDS 914.0-M-1, October 2008, is equivalent to ISO 18441:2013.
Page C-1
Add the following information to the reference indicated:
[C5] Document CCSDS 913.1-B-1, September 2008, is equivalent to ISO 18440:2013.
3 Revision of publication CCSDS 916.1-M-1
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 916.1-
M-1. To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2013 – All rights reserved

Recommendation for Space Data System Practices
SPACE LINK EXTENSION—
APPLICATION PROGRAM
INTERFACE FOR THE
FORWARD CLTU SERVICE
RECOMMENDED PRACTICE
CCSDS 916.1-M-1
MAGENTA BOOK
October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
AUTHORITY
Issue: Recommended Practice, Issue 1
Date: October 2008
Location: Washington, DC, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in the Procedures Manual for the
Consultative Committee for Space Data Systems, and the record of Agency participation in
the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.
This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 916.1-M-1 Page i October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
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 Recommendations and are not in
themselves considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice 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 Practice is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified. Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
CCSDS 916.1-M-1 Page ii October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
FOREWORD
This document is a technical Recommended Practice for use in developing ground systems
for space missions and has been prepared by the Consultative Committee for Space Data
Systems (CCSDS). The Application Program Interface described herein is intended for
missions that are cross-supported between Agencies of the CCSDS.
This Recommended Practice specifies service type-specific extensions of the Space Link
Extension Application Program Interface for Transfer Services specified by CCSDS
(reference [5]). It allows implementing organizations within each Agency to proceed with
the development of compatible, derived Standards for the ground systems that are within
their cognizance. Derived Agency Standards may implement only a subset of the optional
features allowed by the Recommended Practice and may incorporate features not addressed
by the Recommended Practice.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Practice is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. 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 916.1-M-1 Page iii October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
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.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (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.

Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– 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.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– 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.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 916.1-M-1 Page iv October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Link Extension—Application October Original issue
916.1-M-1 Program Interface for the Forward 2008
CLTU Service, Recommended
Practice, Issue 1
CCSDS 916.1-M-1 Page v October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
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  DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-5
1.7  REFERENCES . 1-8

2  OVERVIEW . 2-1

2.1  INTRODUCTION . 2-1
2.2  PACKAGE CLTU SERVICE INSTANCES . 2-1
2.3  PACKAGE CLTU OPERATIONS . 2-12
2.4  SECURITY ASPECTS OF THE SLE FORWARD CLTU
TRANSFER SERVICE . 2-13

3  CLTU SPECIFIC SPECIFICATIONS FOR API COMPONENTS . 3-1

3.1  API SERVICE ELEMENT . 3-1
3.2  SLE OPERATIONS . 3-14
3.3  SLE APPLICATION . 3-14

ANNEX A CLTU SPECIFIC INTERFACES (Normative) . A-1
ANNEX B ACRONYMS (Informative) .B-1
ANNEX C INFORMATIVE REFERENCES (Informative) . C-1
Figure
1-1  SLE Services and SLE API Documentation . 1-4
2-1  CLTU Service Instances . 2-2
2-2  CLTU Operation Objects . 2-12

Table
2-1  Production Events Reported via the Interface ICLTU_SIUpdate . 2-5
2-2  CLTU Configuration Parameters Handled by the Service Element . 2-7
2-3  CLTU Status Parameters Handled by the Service Element . 2-8
2-4  CLTU Production Status . 2-9
2-5  Mapping of CLTU Operations to Operation Object Interfaces . 2-13

CCSDS 916.1-M-1 Page vi October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
1 INTRODUCTION
1.1 PURPOSE
The Recommended Practice Space Link Extension—Application Program Interface for
Transfer Services—Core Specification (reference [5]) specifies a C++ API for CCSDS Space
Link Extension Transfer Services. The API is intended for use by application programs
implementing SLE transfer services.
Reference [5] defines the architecture of the API and the functionality on a generic level,
which is independent of specific SLE services and communication technologies. It is thus
necessary to add service type-specific specifications in supplemental Recommended
Practices. The purpose of this document is to specify extensions to the API needed for
support of the Command Link Transmission Unit (CLTU) service defined in reference [4].
1.2 SCOPE
This Recommended Practice defines extensions to the SLE API in terms of:
a) the CLTU-specific functionality provided by API components;
b) the CLTU-specific interfaces provided by API components; and
c) the externally visible behavior associated with the CLTU interfaces exported by the
components.
It does not specify
a) individual implementations or products;
b) the internal design of the components; and
c) the technology used for communications.
This Recommended Practice defines only interfaces and behavior that must be provided by
implementations supporting the forward CLTU service in addition to the specification in
reference [5].
1.3 APPLICABILITY
The CLTU Application Program Interface specified in this document supports two versions
of the CLTU service, namely:
a) version 1 as specified by reference [C2]; and
b) version 2 as specified by reference [4].
CCSDS 916.1-M-1 Page 1-1 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
Support for version 1 of these services is included for backward compatibility purposes for a
limited time and may not be continued in future versions of this specification. Support for
version 1 of the CLTU service implies that SLE API implementations of this specification
are able to interoperate with peer SLE systems that comply with the specification of the
Transport Mapping Layer (TML) in ‘Specification of a SLE API Proxy for TCP/IP and
ASN.1’, ESOC, SLES-SW-API-0002-TOS-GCI, Issue 1.1, February 2001.
Version-dependent provisions within this Recommended Practice are marked as follows:
a) [V1:] for provisions specific to version 1; and
b) [V2:] for provisions specific to version 2.
1.4 RATIONALE
This Recommended Practice specifies the mapping of the forward CLTU service
specification to specific functions and parameters of the SLE API. It also specifies the
distribution of responsibility for specific functions between SLE API software and
application software.
The goal of this Recommended Practice is to create a standard for interoperability between:
a) application software using the SLE API and SLE API software implementing the
SLE API; and
b) SLE user and SLE provider applications communicating with each other using the
SLE API on both.
This interoperability standard also allows exchangeability of different products implementing
the SLE API, as long as they adhere to the interface specification of this Recommended
Practice.
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This document is organized as follows:
– section 1 provides purpose and scope of this specification, identifies conventions, and
lists definitions and references used throughout the document;
– section 2 provides an overview of the CLTU service and describes the API model
extension including support for the CLTU service;
– section 3 contains detailed specifications for the API components and for applications
using the API;
CCSDS 916.1-M-1 Page 1-2 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
– annex A provides a formal specification of the API interfaces and data types specific
to the CLTU service;
– annex B lists all acronyms used within this document;
– annex C lists informative references.
1.5.2 SLE SERVICE DOCUMENTATION TREE
The SLE suite of Recommended Standards is based on the cross support model defined in the
SLE Reference Model (reference [3]). The services defined by the reference model
constitute one of the three types of Cross Support Services:
a) Part 1: SLE Services;
b) Part 2: Ground Domain Services; and
c) Part 3: Ground Communications Services.
The SLE services are further divided into SLE service management and SLE transfer
services.
The basic organization of the SLE services and SLE documentation is shown in figure 1-1.
The various documents are described in the following paragraphs.
CCSDS 916.1-M-1 Page 1-3 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU 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 Internet Protocol for SLE Service
Specifications Specifications Transfer Services Management Suite
SLE API for Transfer Services
Core Specification Summary of
Concept and
Rationale
Forward Return
Application
SLE Service SLE Service
Programmer’s
Specifications Specifications
Guide
Recommended Recommended
Legend: Report (Green) Report (Yellow)
Standard (Blue) Practice (Magenta)

Figure 1-1: SLE Services and SLE API Documentation
a) Cross Support Reference Model—Part 1: Space Link Extension Services, a
Recommended Standard that defines the framework and terminology for the
specification of SLE services.
b) Cross Support Concept—Part 1: Space Link Extension Services, a Report introducing
the concepts of cross support and the SLE services.
c) Space Link Extension Services—Executive Summary, an Administrative Report
providing an overview of Space Link Extension (SLE) Services. It is designed to
assist readers with their review of existing and future SLE documentation.
d) Forward SLE Service Specifications, a set of Recommended Standards that provide
specifications of all forward link SLE services.
e) Return SLE Service Specifications, a set of Recommended Standards that provide
specifications of all return link SLE services.
CCSDS 916.1-M-1 Page 1-4 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
f) Internet Protocol for Transfer Services, a Recommended Standard providing the
specification of the wire protocol used for SLE transfer services.
g) SLE Service Management Specifications, a set of Recommended Standards that
establish the basis of SLE service management.
h) Application Program Interface for Transfer Services—Core Specification, a
Recommended Practice document specifying the generic part of the API for SLE
transfer services.
i) Application Program Interface for Transfer Services—Summary of Concept and
Rationale, a Report describing the concept and rationale for specification and
implementation of a Application Program Interface for SLE Transfer Services.
j) Application Program Interface for Return Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for return link
SLE services.
k) Application Program Interface for Forward Services, a set of Recommended Practice
documents specifying the service type-specific extensions of the API for forward link
SLE services.
l) Application Program Interface for Transfer Services—Application Programmer’s
Guide, a Report containing guidance material and software source code examples for
software developers using the API.
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from Telecommand Channel Service
This Recommended Practice makes use of the following terms defined in reference [1]:
a) Command Link Transmission Unit (CLTU);
b) Physical Layer Operations Procedure (PLOP).
1.6.1.2 Definitions from Telecommand Data Routing Service
This Recommended Practice makes use of the following terms defined in reference [2]:
Command Link Control Word (CLCW).
CCSDS 916.1-M-1 Page 1-5 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
1.6.1.3 Definitions from SLE Reference Model
This Recommended Practice makes use of the following terms defined in reference [3]:
a) Forward CLTU service;
b) operation;
c) service provider (provider);
d) service user (user);
e) SLE transfer service instance;
f) SLE transfer service production;
g) SLE transfer service provision;
h) space link data unit (SL-DU).
1.6.1.4 Definitions from CLTU Service
This Recommended Practice makes use of the following terms defined in reference [4]:
a) association;
b) communications service;
c) confirmed operation;
d) invocation;
e) parameter;
f) performance;
g) port identifier;
h) return;
i) service instance provision period;
j) unconfirmed operation.
1.6.1.5 Definitions from ASN.1 Specification
This Recommended Practice makes use of the following terms defined in reference [7]:
a) Object Identifier;
b) Octet String.
CCSDS 916.1-M-1 Page 1-6 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
1.6.1.6 Definitions from UML Specification
This Recommended Practice makes use of the following terms defined in reference [C8]:
a) Attribute;
b) Base Class;
c) Class;
d) Data Type;
e) Interface;
f) Method.
1.6.1.7 Definitions from API Core Specification
This Recommended Practice makes use of the following terms defined in reference [5]:
a) Application Program Interface;
b) Component.
1.6.2 NOMENCLATURE
The following conventions apply throughout this Recommended Practice:
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
This document applies the conventions defined in reference [5].
The model extensions in section 2 are presented using the Unified Modeling Language
(UML) and applying the conventions defined in reference [5].
The CLTU-specific specifications for API components in section 3 are presented using the
conventions specified in reference [5].
The CLTU-specific interfaces in annex A are specified using the conventions defined in
reference [5].
CCSDS 916.1-M-1 Page 1-7 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Practice. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Practice
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 documents.
NOTE – A list of informative references is provided in annex C.
[1] TC Synchronization and Channel Coding. Recommendation for Space Data System
Standards, CCSDS 231.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS,
September 2003.
[2] TC Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 232.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
[3] Cross Support Reference Model—Part 1: Space Link Extension Services.
Recommendation for Space Data System Standards, CCSDS 910.4-B-2. Blue Book.
Issue 2. Washington, D.C.: CCSDS, October 2005.
[4] Space Link Extension—Forward CLTU Service Specification. Recommendation for
Space Data System Standards, CCSDS 912.1-B-2. Blue Book. Issue 2. Washington,
D.C.: CCSDS, December 2004.
[5] Space Link Extension—Application Program Interface for Transfer Services—Core
Specification. Specification Concerning Space Data System Standards, CCSDS 914.0-
M-1. Magenta Book. Issue 1. Washington, D.C.: CCSDS, October 2008.
[6] Programming Languages—C++. International Standard, ISO/IEC 14882:2003. 2nd
ed. Geneva: ISO, 2003.
[7] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. International Standard, ISO/IEC 8824-1:2002. 3rd ed. Geneva: ISO,
2002.
CCSDS 916.1-M-1 Page 1-8 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
2 OVERVIEW
2.1 INTRODUCTION
This section describes the extension of the SLE API model in reference [5] for support of the
CLTU service. Extensions are needed for the API components API Service Element and
SLE Operations.
In addition to the extensions defined in this section, the component API Proxy must support
encoding and decoding of CLTU-specific protocol data units.
2.2 PACKAGE CLTU SERVICE INSTANCES
2.2.1 OVERVIEW
The CLTU extensions to the component API Service Element are defined by the package
CLTU Service Instances. Figure 2-1 provides an overview of this package. The diagram
includes classes from the package API Service Element specified in reference [5], which
provide applicable specifications for the CLTU service.
The package adds two service instance classes:
a) CLTU SI User, supporting the service user role; and
b) CLTU SI Provider, supporting service provider role.
These classes correspond to the placeholder classes I_SI User and I_SI
Provider defined in reference [5].
Both classes are able to handle the specific CLTU operations.
For the class CLTU SI User, this is the only extension of the base class SI User.
The class CLTU SI Provider adds two new interfaces:
a) ICLTU_SIAdmin by which the application can set CLTU-specific configuration
parameters; and
b) ICLTU_SIUpdate by which the application must update dynamic status
information, required for generation of status reports.
These interfaces correspond to the placeholder interfaces I_SIAdmin and
I_SIUpdate defined in reference [5].
CCSDS 916.1-M-1 Page 2-1 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
<>
<>
API Service Instance
ISLE_SIAdmin
(from API Service Element)
(from API Service Element)
- return timeout period
<>
<>
SI Provider
SI User
(from API Service Element)
(from API Service Element)
- report request type
- reporting cycle
<>
ICLTU_SIAdmin
<> <>
CLTU SI Provider CLTU SI User
<> 11
ICLTU_SIUpdate
0.0.11
+ CltuStarted()
+ CltuRadiated()
<>
+ CltuNotStarted()
CLTU Last OK
+ ProductionStatusChange()
- cltu identification
+ Set_UplinkStatus()
- radiation stop time
+BufferEmpty()
+ EventProcCompleted()
0.0.11
<>
<>
CLTU Last Processed
<>
CLTU Configuration
CLTU Status Information
- cltu identification
- bit lock required
-productionstatus - radiation start time
- maximum cltu length
- cltu buffer available -cltustatus
- modulation frequency
- number of cltus received
- modulation index
- number of cltus processed
-plopineffect
- number of cltus radiated
-rfavailable required
- expected cltu identification
- subcarrier to bitrate ratio
- expected event invocation identifier
-maximum cltu buffersize
- uplink status
- notification mode
Figure 2-1: CLTU Service Instances
CLTU-specific configuration parameters are defined by the internal class CLTU
Configuration. The class CLTU Status Information defines dynamic status parameters
maintained by the service instance. In addition, the service instance maintains a set of
parameters for the last CLTU processed and for the last CLTU that was successfully radiated.
These parameters are defined by the classes CLTU Last Processed and CLTU Last OK.
Although the CLTU service allows only a single service instance to be bound to a service
provider at any point of time, the service element does not constrain the number of CLTU
CCSDS 916.1-M-1 Page 2-2 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
service instances on the user side or the provider side. More than one service instance might
be needed for back-up purposes. In addition, this specification does not exclude that a single
service element be used to serve several CLTU production engines or to connect to several
providers. Therefore, the service element shall not enforce that only a single CLTU service
instance is bound.
All specifications provided in this section refer to a single service instance. If more than one
service instance is used, each service instance must be configured and updated
independently.
2.2.2 COMPONENT CLASS CLTU SI USER
The class defines a CLTU service instance supporting the service user role. It ensures that
SLE PDUs passed by the application and by the association are supported by the CLTU
service and handles the CLTU operation objects defined in 2.3. It does not add further
features to those provided by the base class SI User.
2.2.3 COMPONENT CLASS CLTU SI PROVIDER
2.2.3.1 General
The class defines a CLTU service instance supporting the service provider role. It exports
the interfaces ICLTU_SIAdmin for configuration of the service instance after creation and
ICLTU_SIUpdate for update of dynamic status parameters during operation.
2.2.3.2 Responsibilities
2.2.3.2.1 Service Specific Configuration
The service instance implements the interface ICLTU_SIAdmin to set the CLTU-specific
configuration parameters defined by the class CLTU Configuration. The methods of this
interface must be called after creation of the service instance. When all configuration
parameters (including those set via the interface ISLE_SIAdmin) have been set, the method
ISLE_SIAdmin::ConfigCompleted() must be called. This method verifies that all
configuration parameters values are defined and are in the range defined in reference [4].
In addition, the interface ICLTU_SIAdmin provides read access to the configuration
parameters.
2.2.3.2.2 Update of Dynamic Status Parameters
The class implements the interface ICLTU_SIUpdate to inform the service instance of
specific events in the CLTU production process. The methods of this interface update status
parameters defined by the classes CLTU Status Information, CLTU Last Processed, and
CCSDS 916.1-M-1 Page 2-3 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
CLTU Last OK. The events reported via ICLTU_SIUpdate and the parameters updated
via this interface are listed in table 2-1.
In order to ensure that the status information is always up to date the events listed in table
2-1 must be reported to the service instance during its complete lifetime, independent of the
state of the service instance.
In addition, the class derives some of the parameters in CLTU Status Information from
CLTU PDUs exchanged between the service user and the service provider. The methods
used to update each of the parameters are defined in 2.2.5.
The interface ICLTU_SIUpdate provides read access to all status parameters.
2.2.3.2.3 Generation of Notifications
If events reported via the interface ICLTU_SIUpdate require that a CLTU–ASYNC–
NOTIFY invocation be sent to the service user, the class generates and transmits these
invocations if that is requested by the application and if the state of the service instance is
‘active’ or ‘ready’. The notifications that are generated and transmitted by the class are listed in
table 2-1.
The application can opt not to use this feature, but to generate the notification itself and
transmit it using the interface ISLE_ServiceInitiate. It is noted that reference [4]
defines additional notifications that must always be generated and transmitted by the
application.
The SLE API supports different modes for generation of notifications. In ‘deferred’
notification mode, if no CLTU is affected and the production status changes to ‘interrupted’;
the notification is deferred until the attempt is made to radiate the next CLTU. In ‘immediate’
notification mode, the ‘production interrupted’ notification is generated immediately.
2.2.3.2.4 Handling of the CLTU–GET-PARAMETER Operation
The class responds autonomously to CLTU–GET–PARAMETER invocations. It generates
the appropriate CLTU–GET–PARAMETER return using the parameters maintained by the
classes CLTU Configuration and CLTU Status Information.
2.2.3.2.5 Status Reporting
The class generates CLTU–STATUS–REPORT invocations when required using the
parameters maintained by the classes CLTU Status Information and CLTU Information.

CCSDS 916.1-M-1 Page 2-4 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
CCSDS 916.1-M-1 Page 2-5 October 2008
Table 2-1: Production Events Reported via the Interface ICLTU_SIUpdate
NOTE – The notification type actually transmitted depends on the method arguments and partially or the value of the production status.
Event Method Arguments Status parameters updated Notification sent
CltuStarted
Radiation of a CLTU started. CLTU identification CLTU identification last processed none
radiation start time radiation start time
available buffer size CLTU status
number of CLTUs processed
available buffer size
CltuRadiated
Radiation of a CLTU radiation stop time CLTU identification last OK CLTU radiated
completed. radiation start time radiation stop time
(see note below) CLTU status
number of CLTUs radiated
CltuNotStarted
Radiation of a CLTU could not
CLTU identification CLTU identification last processed SLDU expired
be started because the latest
failure reason radiation start time production interrupted
radiation time expired or the
available buffer size CLTU status
production status was
number of CLTUs processed
interrupted.
available buffer size
BufferEmpty
The CLTU buffer is empty.  available buffer size buffer empty
ProductionStatusChan
The production status production status available buffer size production operational
ge
changed with or without available buffer size production status production interrupted
affecting a CLTU being CLTU status production halted
radiated.
EventProcCompleted
Processing of a thrown event event id  action list completed
completed event processing action list not
result completed
event condition
evaluated to false
Set_UplinkStatus
The uplink status changed uplink status uplink status none

CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
NOTE – for the method CltuRadiated the start time is an optional parameter that can be
supplied if the exact start time is known only after radiation of the CLTU. In such a
case the start time passed to the method CltuStarted should be the best
available estimate.
2.2.3.2.6 Processing of CLTU Protocol Data Units
The class ensures that SLE PDUs passed by the application and by the association are
supported by the CLTU service and handles the CLTU operation objects defined in 2.3.
2.2.3.2.7 Processing of CLTU–TRANSFER–DATA Invocations
For incoming CLTU–TRANSFER–DATA invocations the class performs the following
checks in addition to those defined in [5]:
a) if the ‘earliest radiation time’ and the ‘latest radiation time’ are both specified, the
‘earliest radiation time’ must not be later than the ‘latest radiation time’;
b) the size of the CLTU contained in the PDU must not be larger than the value of the
configuration parameter ‘maximum-sldu-length’ allows.
In contrast to handling of other confirmed operations, the service instance is allowed to pass
the operation object to the application after setting the correct diagnostic if these checks fail.
The application is expected to insert the next expected CLTU identification and the available
buffer size into the operation object and pass it back to service instance via the interface
ISLE_ServiceInitiate. The reasons for this specification are explained in 2.2.8.3.
2.2.3.2.8 Processing of CLTU–THROW-EVENT invocations
In contrast to handling of other confirmed operations, the service instance is allowed to pass the
operation object to the application after setting the correct diagnostic if checks performed by
the service element fail. The application is expected to insert the next expected event
invocation identifier into the operation object and pass it back to service instance via the
interface ISLE_ServiceInitiate. The reasons for this specification are explained in
2.2.8.3.
2.2.4 INTERNAL CLASS CLTU CONFIGURATION
The class defines the configuration parameters that can be set via the interface
ICLTU_SIAdmin. These parameters are defined by reference [4]. Table 2-2 describes
how the service instance uses these parameters. The column labeled ‘Upd’ indicates whether
an update of these parameters is allowed after the initial configuration has been completed.
It is noted that an update might be inhibited by service management also when an update is
possible according to the table.
CCSDS 916.1-M-1 Page 2-6 October 2008
CCSDS RECOMMENDED PRACTICE: API FOR THE SLE FORWARD CLTU SERVICE
Table 2-2: CLTU Configuration Parameters Handled by the Service Element
Parameter Used for Upd
bit-lock-required
CLTU–GET–PARAMETER Y
maximum-cltu-length
CLTU–GET–PARAMETER Y
modulation-frequency
CLTU–GET–PARAMETER Y
plop-in-effect
CLTU–GET–PARAMETER Y
rf-available-required
CLTU–GET–PARAMETER Y
subcarrier-to-bit
...