ISO 22672:2021

INTERNATIONAL ISO
STANDARD 22672
Third edition
2021-06
Space data and information transfer
systems — Space link extension (SLE)
— Forward space packet service
specification
Systèmes de transfert des informations et données spatiales —
Extension de liaisons spatiales (SLE) — Spécification d'envoi de
données spatiales par paquets
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.3-B-3, 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 third edition cancels and replaces the second edition (ISO 22672: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 FSP 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-2
1.4 RATIONALE . 1-2
1.5 DOCUMENT STRUCTURE . 1-3
1.6 DEFINITIONS, NOMENCLATURE, AND CONVENTIONS . 1-5
1.7 REFERENCES . 1-14
2 DESCRIPTION OF THE FORWARD SPACE PACKET SERVICE . 2-1
2.1 OVERVIEW . 2-1
2.2 SPACE LINK EXTENSION REFERENCE MODEL . 2-1
2.3 SERVICE MANAGEMENT . 2-3
2.4 ARCHITECTURE MODEL—FUNCTIONAL VIEW . 2-3
2.5 ARCHITECTURE MODEL—CROSS SUPPORT VIEW . 2-8
2.6 FUNCTIONAL DESCRIPTION . 2-9
2.7 OPERATIONAL SCENARIO . 2-16
2.8 SECURITY ASPECTS OF THE SLE FORWARD SPACE
PACKET (FSP) TRANSFER SERVICE . 2-18
3 FSP SERVICE OPERATIONS . 3-1
3.1 GENERAL CONSIDERATIONS . 3-1
3.2 FSP-BIND . 3-10
3.3 FSP-UNBIND . 3-17
3.4 FSP-START . 3-20
3.5 FSP-STOP . 3-24
3.6 FSP-TRANSFER-DATA . 3-27
3.7 FSP-ASYNC-NOTIFY . 3-38
3.8 FSP-SCHEDULE-STATUS-REPORT . 3-53
3.9 FSP-STATUS-REPORT . 3-57
3.10 FSP-GET-PARAMETER . 3-64
3.11 FSP-THROW-EVENT . 3-70
3.12 FSP-INVOKE-DIRECTIVE . 3-75
3.13 FSP-PEER-ABORT . 3-80
4 FSP PROTOCOL . 4-1
4.1 GENERIC PROTOCOL CHARACTERISTICS . 4-1
4.2 FSP SERVICE PROVIDER BEHAVIOR. 4-4
CCSDS 912.3-B-3 Page vi August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
CONTENTS (continued)
Section Page
ANNEX A DATA TYPE DEFINITIONS (NORMATIVE) . A-1
ANNEX B FSP QUEUES AND MULTIPLEXING BEHAVIOR
DEFINITION (NORMATIVE) .B-1
ANNEX C PRODUCTION STATUS (NORMATIVE) . C-1
ANNEX D FUNCTIONAL GROUP PRODUCTION REQUIREMENTS
FOR FSP (NORMATIVE) . D-1
ANNEX E CONFORMANCE MATRIX (NORMATIVE) .E-1
ANNEX F INDEX TO DEFINITIONS (INFORMATIVE) . F-3
ANNEX G ACRONYMS (INFORMATIVE) . G-1
ANNEX H THROW EVENT DEFINITIONS (INFORMATIVE) . H-1
ANNEX I INFORMATIVE REFERENCES (INFORMATIVE) . I-1
Figure
1-1 SLE Services Documentation . 1-4
2-1 Forward Telecommand Functional Groups . 2-4
2-2 FSP Service Production and Provision . 2-7
2-3 Example of the Management and Provision of FSP Service . 2-8
2-4 Simplified FSP Service Provider State Transition Diagram . 2-11
2-5 Communications Realization of FSP Service . 2-14
B-1 FSP MAP and TC Frame Multiplexing .B-1
B-2 MAP and VC Multiplexing .B-2
B-3 FSP Queues .B-4
C-1 FSP Production Status Diagram .C-1

Table
2-1 FSP Service Operations . 2-10
3-1 Setting of FSP Service Operation Parameters . 3-6
3-2 FSP-BIND Parameters . 3-11
3-3 FSP-UNBIND Parameters . 3-18
3-4 FSP-START Parameters . 3-20
3-5 FSP-STOP Parameters . 3-24
3-6 FSP-TRANSFER-DATA Parameters . 3-28
3-7 FSP-ASYNC-NOTIFY Parameters . 3-38
3-8 FSP-SCHEDULE-STATUS-REPORT Parameters . 3-53
3-9 FSP-STATUS-REPORT Parameters . 3-57
3-10 FSP-GET-PARAMETER Parameters . 3-64
3-11 FSP Service Parameters . 3-65
3-12 FSP-THROW-EVENT Parameters . 3-71
CCSDS 912.3-B-3 Page vii August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
CONTENTS (continued)
Table Page
3-13 FSP-INVOKE-DIRECTIVE Parameters . 3-75
3-14 FSP-PEER-ABORT Parameters . 3-80
4-1 Provider Behavior . 4-6
4-2 Event Description References . 4-10
4-3 Predicate Definitions . 4-11
4-4 Boolean Flags . 4-11
4-5 Compound Action Definitions . 4-12
C-1 Production Status Transitions .C-2
C-2 Effects of Production Status on Operations .C-4
D-1 Forward CLTU Generation Aggregate Production Status . D-3
D-2 Forward TC VC Data Insertion Aggregate Production Status . D-5
E-1 Conformance Matrix for FSP Service (Operations) . E-1
E-2 Conformance Matrix for FSP Service (Other Requirements) . E-2
H-1 Throw Event Examples . H-1

CCSDS 912.3-B-3 Page viii August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED STANDARD
This Recommended Standard defines the Forward Space Packet (FSP) service in
conformance with the transfer services specified in reference [1], Cross Support Reference
Model―Part 1: SLE Services. The FSP service is a Space Link Extension (SLE) transfer
service that enables a mission to send Space Packets to a spacecraft in sequence-controlled or
expedited mode.
1.2 SCOPE
This Recommended Standard defines, in an abstract manner, the FSP 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 Space Packets 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 FSP
service.
NOTE – While the FSP service as described in reference [1] is conceived to handle a
variety of packet data structures, this version of the FSP Recommended Standard
is restricted to the handling of Space Packets as defined in reference [6].
This version of the FSP Recommended Standard is specific to the transfer of Space Packets
to be transmitted via the Telecommand protocol stack as defined in references [3], [4], and
[5]. The Cross Support Reference Model (reference [1]) specifies that the FSP service may
also be used in conjunction with the Advanced Orbiting System protocol stack, but that mode
of operation is outside the scope of this version of the Recommended Standard.
CCSDS 912.3-B-3 Page 1-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
The FSP service is provided in the online delivery mode, as defined in reference [1]. The
offline delivery mode is the subject of further study.
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 FSP service. Implementation of the FSP service in a real system additionally
requires the availability of a communications service to convey invocations and returns of
FSP service operations between FSP service users and providers. This Recommended
Standard requires that such a communications service ensures 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 FSP service user and the FSP service provider are disrupted, possibly resulting in
a loss of data.
It is the specific intent of this Recommended Standard to define the FSP 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 FSP 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 and/or ground data handling systems of various agencies and the users
of forward services.
CCSDS 912.3-B-3 Page 1-2 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This Recommended Standard is organized as follows:
a) section 0 provides the purpose, scope, applicability, and rationale of this
Recommended Standard and lists definitions, nomenclature, conventions, and
references used throughout the Recommended Standard;
b) section 2 provides an overview of the FSP service including a functional description,
the service management context, and protocol considerations;
c) section 3 specifies the operations of the FSP service;
d) section 4 specifies the dynamic behavior of the FSP service in terms of the state
transitions of the FSP service provider;
e) annex A provides a formal specification of FSP service data types, using the Abstract
Syntax Notation One (ASN.1);
f) annex B provides a specification of the multiplexing between concurrent FSP service
instances sharing the same TC Virtual Channel (VC) as well as the multiplexing
between TC VCs sharing the same physical space link data channel;
g) annex C presents the FSP production status and its transitions;
h) annex D defines the production requirements the FSP service imposes on the forward
Functional Groups;
i) annex E provides a conformance matrix that defines what capabilities must be
provided for an implementation to be considered compliant with this Recommended
Standard;
j) annex F lists all terms used in this document and identifies where they are defined;
k) annex G lists all acronyms used within this document;
l) annex H contains examples of usage of the FSP-THROW-EVENT operation;
m) annex I 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 an SLE Mission User Entity (MUE) and an SLE Transfer Service provider for the
purpose of providing the FSP Transfer Service.
CCSDS 912.3-B-3 Page 1-3 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP 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.
Space Link Extension
Cross Support
Cross Support Concept SLE Executive
Reference Model
Summary
Part 1: SLE Services
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 [I3]): 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 reference model that provides a common
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);
CCSDS 912.3-B-3 Page 1-4 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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.
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 [8]. 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 Systems 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 [7]:
a) Abstract Syntax Notation One (ASN.1);
b) object identifier;
c) (data) type;
d) (data) value.
CCSDS 912.3-B-3 Page 1-5 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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 FSP
service. The use of ASN.1 as a descriptive language is intended to support the
specification of the abstract FSP 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 FSP service.
1.6.1.3 Definitions from TC Synchronization and Channel Coding
This Recommended Standard makes use of the following term defined in reference [3]:
Communications Link Transmission Unit (CLTU).
1.6.1.4 Definitions from TC Space Data Link Protocol
This Recommended Standard makes use of the following terms defined in reference [4]:
a) AD, BD, BC;
b) Communications Link Control Word (CLCW);
c) Communications Operation Procedure (COP);
d) Control Word Type;
e) Frame Operation Procedure (FOP);
f) Frame Sequence Number;
g) Multiplexer Access Point (MAP);
h) Operational Control Field (OCF);
i) Segment;
j) Telecommand Transfer Frame (TC Transfer Frame or TC frame);
k) Virtual Channel (VC).
1.6.1.5 Definitions from Communications Operation Procedure-1
This Recommended Standard makes use of the following terms defined in reference [5]:
a) FOP_Sliding_Window_Width;
b) Receiver_Frame_Sequence_Number V(R);
c) Timeout_Type;
CCSDS 912.3-B-3 Page 1-6 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
d) Transmitter_Frame_Sequence_Number V(S);
e) T1_Initial.
1.6.1.6 Definitions from Space Packet Protocol
This Recommended Standard makes use of the following terms defined in reference [6]:
a) Application Process Identifier (APID);
b) Space Packet.
1.6.1.7 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) Forward CLTU SLE data channel (Forward CLTU data channel);
f) Forward Space Packet channel (FSP channel);
g) Forward Space Packet service (FSP service);
h) Forward Telecommand Frame SLE data channel (Forward TC Frame data channel);
i) invoker;
j) Mission Data Operation System (MDOS);
k) Mission User Entity (MUE);
l) offline delivery mode;
m) online delivery mode;
n) operation;
o) Operational Control Field SLE data channel (OCF data channel);
p) performer;
q) physical channel;
r) service agreement;
s) service provider (provider);
CCSDS 912.3-B-3 Page 1-7 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
t) service user (user);
u) SLE Complex;
v) SLE Complex Management;
w) SLE data channel;
x) SLE Functional Group (SLE-FG);
y) SLE protocol data unit (SLE-PDU);
z) SLE service data unit (SLE-SDU);
aa) SLE service package;
bb) SLE transfer service instance;
cc) SLE transfer service production;
dd) SLE transfer service provision;
ee) SLE Utilization Management;
ff) space link;
gg) space link data channel;
hh) space link data unit (SL-DU);
ii) space link session.
1.6.1.8 Additional Definitions
For the purposes of this Recommended Standard, the following definitions also apply.
1.6.1.8.1 Acknowledged (Space Packet)
A Space Packet is said to be acknowledged when evaluation of the CLCWs returned by the
space element shows that all TC frames containing parts of the Space Packet reported have
been acknowledged by the space element.
NOTE — This status applies only to the sequence-controlled transmission mode (AD).
Although a Space Packet is ‘acknowledged’, packet re-assembly and/or
execution may still fail. This can only be determined by examining telemetry.
CCSDS 912.3-B-3 Page 1-8 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
1.6.1.8.2 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 the use of an underlying communications service.
1.6.1.8.3 CLTU Transfer Data SLE-SDU
A CLTU Transfer Data SLE-SDU contains a CLTU plus information (see D1.2.2.2) required
by the Forward TC Space Link Processing SLE Functional Group (see 2.4.1.4) to process
that CLTU. In the context of the FSP SLE transfer service, the CLTU Transfer Data SLE-
SDU is generated by the Forward CLTU Generation SLE Functional Group (see 2.4.1.3).
NOTE – When the F-CLTU transfer service is used, the CLTU Transfer Data SLE-SDU is
carried (along with other information) in the CLTU-TRANSFER-DATA
invocation.
1.6.1.8.4 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.
1.6.1.8.5 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.8.6 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.8.7 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.
CCSDS 912.3-B-3 Page 1-9 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
1.6.1.8.8 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 the production or provision of the service.
1.6.1.8.9 Performance
The performance of an operation is the carrying out of the operation by an object (the
performer).
1.6.1.8.10 Port Identifier
A port identifier identifies a source or a destination in a communications system.
NOTE – See 2.6.4.5 for more information.
1.6.1.8.11 Radiated (Space Packet)
A Space Packet is said to be radiated when, based on the ground equipment monitoring, the
FSP production process can assume that all the CLTUs containing parts of the Space Packet
reported have been transmitted to the spacecraft.
1.6.1.8.12 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.
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.8.13 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.8.14 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.
CCSDS 912.3-B-3 Page 1-10 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
1.6.1.8.15 TC Frame Transfer Data SLE-SDU
A TC Frame Transfer Data SLE-SDU contains a TC Frame plus information (see D1.3.2.2)
required by the Forward CLTU Generation SLE Functional Group (see 2.4.1.3) to process
that TC frame. In the context of the FSP SLE transfer service, the TC Frame Transfer Data
SLE-SDU is generated by the Forward TC VC Data Insertion SLE Functional Group (see
2.4.1.2).
1.6.1.8.16 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 nomenclature applies 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 FSP
service. The specification of each operation is divided into subsections as follows:
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
CCSDS 912.3-B-3 Page 1-11 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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 the 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.
1.6.3.2.1 Operation Names
Names of FSP service operations appear in uppercase and begin with the characters ‘FSP-’
(e.g., FSP-TRANSFER-DATA).
1.6.3.2.2 Parameter Names
In the main text, names of parameters of FSP 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).
CCSDS 912.3-B-3 Page 1-12 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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 its 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 FSP 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., fspBindInvocation).
1.6.3.2.6 Data Type Definitions
Data type definitions for the FSP 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.
1.6.3.3 Other Conventions
This Recommended Standard uses the conventions specified in reference [1].
CCSDS 912.3-B-3 Page 1-13 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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 I.
2 This document takes advantage of the harmonized terminology introduced by
restructured documentation of the space link protocols (references [3], [4], [5], and
[6]). From an interoperability point of view, they do not introduce any
incompatibilities with respect to the original set of space link protocol documents
(references [I4], [I5], [I6], and [I7]).
[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] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[3] 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.
[4] 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.
[5] 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.
[6] Space Packet Protocol. Issue 1. Recommendation for Space Data System Standards
(Blue Book), CCSDS 133.0-B-1. Washington, D.C.: CCSDS, September 2003.
[7] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
[8] 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.3-B-3 Page 1-14 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
[9] Space Link Extension—Forward CLTU Service Specification. Issue 3.
Recommendation for Space Data System Standards (Blue Book), CCSDS 912.1-B-3.
Washington, D.C.: CCSDS, July 2010.

CCSDS 912.3-B-3 Page 1-15 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
2 DESCRIPTION OF THE FORWARD SPACE PACKET SERVICE
2.1 OVERVIEW
The FSP service enables the user of the service to send Space Packets (reference [6]) to a
spacecraft. The FSP service user submits Space Packets encapsulated in SLE-SDUs by
means of the FSP-TRANSFER-DATA operation.
The FSP service provider checks the Packet Primary Header to determine if the Packet sent
by the user complies with the applicable constraints, e.g., that the Packet has an Application
Process Identifier (APID) that falls into the set of APIDs the user is authorized to access. The
FSP service provider does not otherwise interpret, interrogate, or modify the content of the
Packet. Telecommand Packets having valid Packet Primary Header information are
transmitted bit for bit as received from the service user.
The FSP service passes its Space Packets to a production process that collectively
encapsulates the Space Packets into TC Transfer Frames (i.e., one or more frames), encodes
the frames into Communication Link Transmission Units (CLTUs), and radiates the CLTUs
to the receiving spacecraft.
The operations defined in section 3 of this Recommended Standard enable an FSP service
user to interact with an FSP service provider to:
a) establish an association between the user and the provider;
b) send annotated Space Packets 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 Space Packets;
e) change the values of certain parameters (such as transmission-mode) that affect
the behavior of the service; and
f) release an association.
The provision of FSP service for access to one or more TC VCs by one or more MUEs
service users is permitted. Each pairing of TC VC and MUE constitutes a separate service
instance.
2.2 SPACE LINK EXTENSION REFERENCE MODEL
2.2.1 INTRODUCTION
The FSP 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.
CCSDS 912.3-B-3 Page 2-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE FSP SERVICE
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 [8]). 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.
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
...