ISO 22669:2021

INTERNATIONAL ISO
STANDARD 22669
Fourth edition
2021-06
Space data and information transfer
systems — Space link extension
(SLE) — Return-all-frames service
specification
Systèmes de transfert des données et informations spatiales —
Extension de liaisons spatiales (SLE) — Service de retour par tout
réseau
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
911.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 22669:2013), which has been technically
revised.
The main changes compared to the previous edition are as follows:
— adds clarifications and corrections;
— adds production status annex;
— updates specifications to accommodate recent additions to the CCSDS Recommended Standards for
coding and synchronization.
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 RAF 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-13
2 DESCRIPTION OF THE RETURN ALL FRAMES 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-4
2.5 ARCHITECTURE MODEL—CROSS SUPPORT VIEW . 2-7
2.6 FUNCTIONAL DESCRIPTION . 2-8
2.7 OPERATIONAL SCENARIO . 2-17
2.8 SECURITY ASPECTS OF THE SLE RAF TRANSFER SERVICE . 2-18
3 RAF SERVICE OPERATIONS . 3-1
3.1 GENERAL CONSIDERATIONS . 3-1
3.2 RAF-BIND . 3-15
3.3 RAF-UNBIND . 3-22
3.4 RAF-START . 3-26
3.5 RAF-STOP . 3-31
3.6 RAF-TRANSFER-DATA . 3-33
3.7 RAF-SYNC-NOTIFY . 3-38
3.8 RAF-SCHEDULE-STATUS-REPORT . 3-41
3.9 RAF-STATUS-REPORT . 3-45
3.10 RAF-GET-PARAMETER . 3-48
3.11 RAF-PEER-ABORT . 3-52
4 RAF PROTOCOL . 4-1
4.1 GENERIC PROTOCOL CHARACTERISTICS . 4-1
4.2 RAF SERVICE PROVIDER BEHAVIOR . 4-4
CCSDS 911.1-B-4 Page vi August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
CONTENTS (continued)
Section Page
ANNEX A DATA TYPE DEFINITIONS (NORMATIVE) . A-1
ANNEX B PRODUCTION STATUS (NORMATIVE) .B-1
ANNEX C CONFORMANCE MATRIX (NORMATIVE) . C-1
ANNEX D INDEX TO DEFINITIONS (INFORMATIVE) . D-1
ANNEX E ACRONYMS (INFORMATIVE) .E-1
ANNEX F INFORMATIVE REFERENCES (INFORMATIVE) . F-1
Figure
1-1 SLE Services Documentation . 1-4
2-1 Return Space Link Processing SLE-FG . 2-4
2-2 RAF Service Production and Provision . 2-6
2-3 Example of the Management and Provision of RAF Service . 2-7
2-4 Simplified RAF Service Provider State Transition Diagram . 2-10
2-5 Communications Realization of RAF Service . 2-12
2-6 Buffers and Delivery Modes . 2-17
B-1 RAF Production Status Transitions .B-1

Table
2-1 RAF Operations . 2-9
3-1 Setting of RAF Service Configuration Parameters . 3-6
3-2 RAF-BIND Parameters . 3-16
3-3 RAF-UNBIND Parameters . 3-23
3-4 RAF-START Parameters . 3-27
3-5 RAF-STOP Parameters . 3-31
3-6 RAF-TRANSFER-DATA Parameters . 3-33
3-7 RAF-SYNC-NOTIFY Parameters . 3-38
3-8 RAF-SCHEDULE-STATUS-REPORT Parameters . 3-42
3-9 RAF-STATUS-REPORT Parameters . 3-45
3-10 RAF-GET-PARAMETER Parameters . 3-48
3-11 RAF Parameters . 3-50
3-12 RAF-PEER-ABORT Parameters . 3-52
4-1 Provider Behavior . 4-6
4-2 Event Description References . 4-13
4-3 Predicate Descriptions . 4-13
4-4 Boolean Flags . 4-14
4-5 Compound Action Definitions . 4-14
B-1 Production Status Changes and Notifications .B-2
B-2 Effect of Production Status on Operations .B-3
C-1 Conformance Matrix for RAF Service (Operations) .C-1
C-2 Conformance Matrix for RAF Service (Other Requirements) .C-2
CCSDS 911.1-B-4 Page vii August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1 INTRODUCTION
1.1 PURPOSE OF THIS RECOMMENDED STANDARD
The purpose of this Recommended Standard is to define the Space Link Extension (SLE)
Return All Frames (RAF) service in conformance with the SLE Reference Model
(reference [1]). The RAF service is an SLE transfer service that delivers to a mission user all
telemetry frames from one space link physical channel.
1.2 SCOPE
This Recommended Standard defines, in an abstract manner, the RAF service in terms of:
a) the operations necessary to provide the 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 acquire telemetry frames from signals
received from a spacecraft;
d) the methods or technologies required to provide a suitable environment for
communications; or
e) the management activities required to schedule, configure, and control the RAF 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 RAF service. Implementation of the RAF service in a real system additionally
requires the availability of a communications service to convey invocations and returns of
RAF service operations between RAF service users and providers. This Recommended
Standard requires that such a communications service must ensure that invocations and
returns of operations are transferred:
a) in sequence;
CCSDS 911.1-B-4 Page 1-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
b) completely and with integrity;
c) without duplication;
d) with flow control that notifies the application layer in the event of congestion; and
e) with notification to the application layer in the event that communications between
the RAF service user and the RAF service provider are disrupted, possibly resulting
in a loss of data.
It is the specific intent of this Recommended Standard to define the RAF service in a manner
that is independent of any particular communications services, protocols, or technologies.
1.3.2 LIMITS OF APPLICABILITY
1.3.2.1 Relationship to Real Systems
This Recommended Standard specifies the RAF service that may be provided by an SLE
Complex 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.3.2.2 RAF Service and Telemetry Channel Coding
Telemetry channel coding on the space link is specified by references [2], [3], and [4]. The
provision of RAF service requires, as specified in reference [2], that, at any given time, the
coding options must be the same for all frames on a physical channel.
Reference [F5] allowed multiplexing of coded Transfer Frames (encoded with the Reed-
Solomon code) with non-coded Transfer Frames on a Physical Channel. This is not allowed
anymore by recommendations in force.
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 consumers
of spacecraft telemetry.
1.5 DOCUMENT STRUCTURE
1.5.1 ORGANIZATION
This document is organized as follows:
CCSDS 911.1-B-4 Page 1-2 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
a) section 0 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the definitions, conventions, and references used
throughout the Recommended Standard;
b) section 2 provides an overview of the RAF service including a functional description,
the service management context, and protocol considerations;
c) section 3 specifies the operations of the RAF service;
d) section 4 specifies the dynamic behavior of the RAF service in terms of the state
transitions of the RAF service provider;
e) annex A provides a formal specification of RAF service data types using Abstract
Syntax Notation One (ASN.1);
f) annex B specifies the relationship of the RAF service provision to the production
status;
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 Recommended Standard and identifies where they
are defined;
i) annex E lists all acronyms used within this document;
j) annex F provides a list of informative references.
1.5.2 SLE SERVICES DOCUMENTATION TREE
This Recommended Standard is based on the cross support model defined in the SLE
Reference Model (reference [1]). It expands upon the concept of an SLE transfer service as
an interaction between an SLE Mission User Entity (MUE) and an SLE transfer service
provider for the purpose of providing the RAF 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 Domain Services;
c) Part 3: Ground Communications Services.
The basic organization of the SLE services documentation is shown in figure 1-1. The
various documents are described in the following subsections.
CCSDS 911.1-B-4 Page 1-3 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF 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 [F2]): a
Report introducing the concepts of cross support and the 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) SLE Return Service Specifications: a set of Recommended Standards that will provide
specification of all return link SLE services (this Recommended Standard is one of the
specifications in that set);
d) SLE Forward Service Specifications: a set of Recommended Standards that will provide
specification of all forward link SLE services;
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 Specifications: a set of Recommended Standards that establish
the basis of SLE service management.
CCSDS 911.1-B-4 Page 1-4 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF 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 [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) application process;
e) flow control;
f) Open Systems Interconnection (OSI);
g) real system;
h) 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 [9]:
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 RAF service operation invocations and returns. The use of
ASN.1 as a descriptive language is intended to support the specification of the
abstract RAF 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 RAF service operation invocations and returns.
CCSDS 911.1-B-4 Page 1-5 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1.6.1.3 Definitions from TM Synchronization and Channel Coding
This Recommended Standard makes use of the following terms defined in reference [2]:
a) Attached Sync Marker;
b) codeblock;
c) convolutional code;
d) pseudo-randomization;
e) Reed-Solomon check symbols;
f) Reed-Solomon code;
g) turbo code.
1.6.1.4 Definitions from TM Space Data Link Protocol
This Recommended Standard makes use of the following term defined in reference [5]:
a) Frame Error Control Field (FECF);
b) TM Transfer Frame.
1.6.1.5 Definitions from AOS Space Data Link Protocol
This Recommended Standard makes use of the following terms defined in reference [6]:
a) Cyclic Redundancy Code (CRC);
b) AOS Transfer Frame;
c) Frame Error Control Field (FECF).
1.6.1.6 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) invoker;
f) Mission Data Operation System (MDOS);
CCSDS 911.1-B-4 Page 1-6 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
g) Mission User Entity (MUE);
h) offline delivery mode;
i) online delivery mode;
j) operation;
k) performer;
l) physical channel;
m) return data;
n) Return All Frames channel (RAF channel);
o) Return All Frames service (RAF service);
p) service agreement;
q) service provider (provider);
r) service user (user);
s) SLE Complex;
t) SLE Complex Management;
u) SLE data channel;
v) SLE Functional Group (SLE-FG);
w) SLE Protocol Data Unit (SLE-PDU);
x) SLE Service Data Unit (SLE-SDU);
y) SLE service package;
z) SLE transfer service instance;
aa) SLE transfer service production;
bb) SLE transfer service provision;
cc) SLE Utilization Management;
dd) space link;
ee) space link data channel;
ff) Space Link Data Unit (SL-DU);
gg) space link session.
CCSDS 911.1-B-4 Page 1-7 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1.6.1.7 Additional Definitions
1.6.1.7.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 the use of an underlying communications
service.
1.6.1.7.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.
1.6.1.7.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.7.4 Delivery Criteria
Delivery criteria are rules that determine whether a data unit acquired from the space link by
an SLE service provider shall be delivered to a user.
NOTE – For RAF service, the delivery criteria are:
a) the Earth Receive Time (ERT) of the frame is within the period defined by the
start and stop times specified in the RAF-START operation; and
b) the frame quality of the frame matches the requested frame quality specified
in the RAF-START operation.
1.6.1.7.5 Frame Error Control Field
The Frame Error Control Field (FECF) of a frame is the FECF of a TM Transfer Frame
(reference [5]), or the FECF of an AOS Transfer Frame (reference [6]), as applicable.
CCSDS 911.1-B-4 Page 1-8 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1.6.1.7.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.7.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.
1.6.1.7.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.7.9 Performance
The performance of an operation is the carrying out of the operation by an object (the
performer).
1.6.1.7.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.7.11 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.
CCSDS 911.1-B-4 Page 1-9 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1.6.1.7.12 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.7.13 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.
NOTE – Reaching of the beginning of this period constitutes the event ‘start of service
instance provision period’ (see 4.2.2).
1.6.1.7.14 Spacecraft Identifier
The spacecraft identifier (SCID) of a telemetry frame is as defined in reference [5] if the
frame is a TM Transfer Frame or as defined in reference [6] if the frame is an AOS Transfer
Frame.
1.6.1.7.15 Telemetry Frame
A (telemetry) frame is a transfer frame TM Transfer Frame (as defined in reference [5]) or an
AOS Transfer Frame (as defined in reference [6]). In case a distinction of the frame versions
is necessary, the full term as per references [5] or [6] is used.
1.6.1.7.16 Transfer Frame Version Number
The Transfer Frame Version Number (TFVN) is either the TFVN as defined in reference [5]
or the TFVN as defined in reference [6].
NOTE – The definitions of TFVN given in references [5] and [6] are equivalent. If a
CCSDS-compatible telemetry frame is known to contain no errors, the TFVN
enables one to distinguish between a TM Transfer Frame and an AOS Transfer
Frame.
1.6.1.7.17 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.
CCSDS 911.1-B-4 Page 1-10 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
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 RAF
service. The specification of each operation is divided into subsections as described in
1.6.3.1.2 through 1.6.3.1.4.
1.6.3.1.2 Purpose Subsection
The Purpose subsection provides a brief description of the purpose 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 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.
CCSDS 911.1-B-4 Page 1-11 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
In the table, the following convention is used to indicate whether a parameter is always
present, always absent, or conditionally present:
M Always present
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
1.6.3.2.1 Operation Names
Names of RAF service operations appear in uppercase and begin with the characters ‘RAF-’
(e.g., RAF-TRANSFER-DATA).
1.6.3.2.2 Parameter Names
In the main text, names of parameters of RAF service operations generally 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, those names are shown in 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 that 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’.
CCSDS 911.1-B-4 Page 1-12 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
1.6.3.2.4 State Names
This Recommended Standard specifies the states of RAF service providers. States may be
referred to by number (e.g., state 2) or by name. State names are always shown in quotation
marks (e.g., ‘active’).
1.6.3.2.5 SLE-PDU Names
The names of SLE-PDUs appear in mixed-case (e.g., rafBindInvocation).
1.6.3.2.6 Data Type Definitions
Data type definitions for the RAF 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].
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 F.
2 This document takes advantage of the harmonized terminology introduced by
restructured documentation of the space link protocols (references [2], [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 [F3],
[F4], and [F5]).
[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.
CCSDS 911.1-B-4 Page 1-13 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
[2] TM Synchronization and Channel Coding. Issue 2. Recommendation for Space Data
System Standards (Blue Book), CCSDS 131.0-B-2. Washington, D.C.: CCSDS, August
2011.
[3] Flexible Advanced Coding and Modulation Scheme for High Rate Telemetry
Applications. Issue 1. Recommendation for Space Data System Standards (Blue Book),
CCSDS 131.2-B-1. Washington, D.C.: CCSDS, March 2012.
[4] CCSDS Space Link Protocols over ETSI DVB-S2 Standard. Issue 1. Recommendation
for Space Data System Standards (Blue Book), CCSDS 131.3-B-1. Washington, D.C.:
CCSDS, March 2013.
[5] TM Space Data Link Protocol. Issue 2. Recommendation for Space Data System
Standards (Blue Book), CCSDS 132.0-B-2. Washington, D.C.: CCSDS, September
2015.
[6] AOS Space Data Link Protocol. Issue3. Recommendation for Space Data System
Standards (Blue Book), CCSDS 732.0-B-3. Washington, D.C.: CCSDS, September
2015.
[7] Time Code Formats. Issue 4. Recommendation for Space Data System Standards (Blue
Book), CCSDS 301.0-B-4. Washington, D.C.: CCSDS, November 2010.
[8] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. 2nd ed. International Standard, ISO/IEC 7498-1:1994. Geneva: ISO,
1994.
[9] Information Technology—Abstract Syntax Notation One (ASN.1): Specification of
Basic Notation. 4th ed. International Standard, ISO/IEC 8824-1:2008. Geneva: ISO,
2008.
CCSDS 911.1-B-4 Page 1-14 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
2 DESCRIPTION OF THE RETURN ALL FRAMES SERVICE
2.1 OVERVIEW
The RAF service enables the user of the service to obtain all telemetry frames from one
space link physical channel. A telemetry frame is a TM Transfer Frame or an AOS Transfer
Frame. A space link physical channel carries one stream of telemetry frames separated by
attached sync markers. For delivery to the user, each frame acquired from the space link is
encapsulated in a SLE SDU that also carries annotation (i.e., additional information such as
the ERT of the frame).
The operations defined in section 3 of this Recommended Standard enable an RAF service
user to interact with an RAF service provider to:
a) establish an association between the user and the provider;
b) receive annotated telemetry frames;
c) obtain notifications and reports regarding the status, configuration and performance
of the service;
d) temporarily suspend and later re-start the delivery of telemetry frames;
e) change the values of certain parameters that affect the behavior of the service; and
f) release an association.
The provision of RAF service derived from one space link physical channel for access by one
service user constitutes one instance of service. The provision of RAF service from one
physical channel to multiple service users and the provision of RAF service concurrently to
one or more service are permitted but are specified to constitute multiple service instances.
2.2 SPACE LINK EXTENSION REFERENCE MODEL
2.2.1 INTRODUCTION
The RAF 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. Objects are characterized by
their interfaces, which are called abstract ports, and the operations that are made available
through those interfaces. One object may provide multiple abstract ports.
CCSDS 911.1-B-4 Page 2-1 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
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 that 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 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.
CCSDS 911.1-B-4 Page 2-2 August 2016
CCSDS RECOMMENDED STANDARD FOR SLE RAF SERVICE
2.3 SERVICE MANAGEMENT
SLE service management determines the number and schedule of RAF 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 RF channel to the RAF data channel.
Certain configuration parameters are associated with provision of RAF service while others
are associated with production. Changes to RAF provision configuration parameters (e.g.,
quality of service) affect only a single service instance; the values of such parameters are
initialized by service management when the service instance is created but may be modified
subsequently by the user through RAF service operations specified in this Recommended
Standard. Changes to RAF production configuration parameters (e.g., bit rate, frame length,
coding type) potentially affect multiple service instances or potentially impact SLE Complex
resources; consequently, those parameters may be modified only through service
management.
RAF service may be user-initiated (i.e., the user invokes the bind operation) or provider-
initiated (i.e., the provider invokes the bind operation). A particular instance of RAF service
supports either user initiation or provider initiation but not both. The form of initiation that
applies to a particular service instance is set by service management.
The SLE Reference Model defines two delivery modes: online delivery mode and offline
delivery mode. Online delivery mode indicates that the provision of service is generally
coincident in time with the space link session, whereas offline delivery mode indicates that
the telemetry frames acquired during a space link session are provided to the user some time
after the end of the space link session. Within the online delivery mode, the SLE Reference
Model defines two quality factors: timeliness and completeness. Within this RAF service
specification, the two variants of online delivery are regarded distinct delivery modes: online
timely and online complete. Both assume the use of a reliable communications service.
They differ in that the timely mode allows for the controlled discarding of telemetry frames
at the application layer if it is not possible to deliver those frames within a certain amount of
time after they are acquired from the space link (e.g., because of communications service
backlog). While the RAF service is defined for the complete online delivery mode, the
timely online delivery mode, or the offline delivery mode, any particular instance of RAF
service supports only one of those modes. The delivery mode applicable to a particular
service instance is set by ser
...