ISO 22669:2013
(Main)Space data and information transfer systems - Space link extension (SLE) - Return-all-frames service
Space data and information transfer systems - Space link extension (SLE) - Return-all-frames service
ISO 22669:2013 defines the space link extension (SLE) return-all-frames (RAF) service in conformance with the SLE reference model (ISO 15396:2007). The RAF service is an SLE transfer service that delivers to a mission user all telemetry frames from one space link physical channel. ISO 22669:2013 defines the RAF service in terms of the operations necessary to provide the service, the parameter data associated with each operation, the behaviors that result from the invocation of each operation, and the relationship between, and the valid sequence of, the operations and resulting behaviors. It does not specify individual implementations or products, the implementation of entities or interfaces within real systems, the methods or technologies required to acquire telemetry frames from signals received from a spacecraft, the methods or technologies required to provide a suitable environment for communications, or the management activities required to schedule, configure, and control the RAF service.
Systèmes de transfert des données et informations spatiales — Extension de liaisons spatiales (SLE) — Service de retour par tout réseau
General Information
Relations
Frequently Asked Questions
ISO 22669:2013 is a standard published by the International Organization for Standardization (ISO). Its full title is "Space data and information transfer systems - Space link extension (SLE) - Return-all-frames service". This standard covers: ISO 22669:2013 defines the space link extension (SLE) return-all-frames (RAF) service in conformance with the SLE reference model (ISO 15396:2007). The RAF service is an SLE transfer service that delivers to a mission user all telemetry frames from one space link physical channel. ISO 22669:2013 defines the RAF service in terms of the operations necessary to provide the service, the parameter data associated with each operation, the behaviors that result from the invocation of each operation, and the relationship between, and the valid sequence of, the operations and resulting behaviors. It does not specify individual implementations or products, the implementation of entities or interfaces within real systems, the methods or technologies required to acquire telemetry frames from signals received from a spacecraft, the methods or technologies required to provide a suitable environment for communications, or the management activities required to schedule, configure, and control the RAF service.
ISO 22669:2013 defines the space link extension (SLE) return-all-frames (RAF) service in conformance with the SLE reference model (ISO 15396:2007). The RAF service is an SLE transfer service that delivers to a mission user all telemetry frames from one space link physical channel. ISO 22669:2013 defines the RAF service in terms of the operations necessary to provide the service, the parameter data associated with each operation, the behaviors that result from the invocation of each operation, and the relationship between, and the valid sequence of, the operations and resulting behaviors. It does not specify individual implementations or products, the implementation of entities or interfaces within real systems, the methods or technologies required to acquire telemetry frames from signals received from a spacecraft, the methods or technologies required to provide a suitable environment for communications, or the management activities required to schedule, configure, and control the RAF service.
ISO 22669:2013 is classified under the following ICS (International Classification for Standards) categories: 49.140 - Space systems and operations. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 22669:2013 has the following relationships with other standards: It is inter standard links to ISO 8385:2018, ISO 22669:2021, ISO 22669:2007. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 22669:2013 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 22669
Third edition
2013-06-01
Space data and information transfer
systems — Space link extension (SLE) —
Return-all-frames service
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 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 22669 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 911.1-B-3, January 2010) and was adopted (without modifications except those stated in Clause 2 of
this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
This third edition cancels and replaces the second edition (ISO 22669:2007), which has been technically
revised.
INTERNATIONAL STANDARD ISO 22669:2013(E)
Space data and information transfer systems — Space link
extension (SLE) — Return-all-frames service
1 Scope
1.1 This International Standard defines the space link extension (SLE) return-all-frames (RAF) service in
conformance with the SLE reference model (ISO 15396:2007). 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 This International Standard defines 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.
1.3 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.4 The scope and field of application are furthermore detailed in subclauses 1.1, 1.2 and 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 911.1-B-3, January 2010, Space link extension — Return all frames service specification.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 911.1-B-3.
Pages i to vi
This part is information which is relevant to the CCSDS publication only.
Pages 1-13 to 1-14
Add the following information to the reference indicated:
[1] Document CCSDS 910.4-B-2, October 2005, is equivalent to ISO 15396:2007.
1)
[2] Document CCSDS 131.0-B-1, September 2003, is equivalent to ISO 22641:2005. .
[3] Document CCSDS 132.0-B-1, September 2003, is equivalent to ISO 22645:2005.
[4] Document CCSDS 732.0-B-2, July 2006, is equivalent to ISO 22666:2007.
2)
[5] Document CCSDS 301.0-B-3, January 2002, is equivalent to ISO 11104:2003.
[7] ISO/IEC 8824-1:2002 has been cancelled and replaced by ISO/IEC 8824-1:2008.
Page E-1
Add the following information to the reference indicated:
[E6] Document CCSDS 913.1-B-1, September 2008, is equivalent to ISO 18440:2013.
3 Revision of publication CCSDS 911.1-B-3
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 911.1-B-
3. To this end, NASA will act as a liaison body between CCSDS and ISO.
1)
ISO 22641:2005 has been cancelled and replaced by ISO 22641:2012.
2)
ISO 11104:2003 has been cancelled and replaced by ISO 11104:2011.
2 © ISO 2013 – All rights reserved
Recommendation for Space Data System Standards
SPACE LINK EXTENSION—
RETURN ALL FRAMES
SERVICE SPECIFICATION
RECOMMENDED STANDARD
CCSDS 911.1-B-3
BLUE BOOK
January 2010
(Blank page)
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
AUTHORITY
Issue: Recommended Standard, Issue 3
Date: January 2010
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 911.1-B-3 Page i January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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 Recommended Standards and are not
considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither
this Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 911.1-B-3 Page ii January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
FOREWORD
This document is a Recommended Standard for use in developing ground systems for space
missions and has been prepared by the Consultative Committee for Space Data Systems
(CCSDS). The Space Link Extension Return All Frames Service described herein is intended
for missions that are cross-supported between Agencies of the CCSDS.
This Recommended Standard specifies a data service that extends certain of the space-to-
ground communications services previously defined by CCSDS (references [2], [3], and [4])
within the framework established by the CCSDS Space Link Extension Reference Model
(reference [1]). 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 Standard and may incorporate features not addressed
by the Recommended Standard.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in 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 911.1-B-3 Page iii January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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.
– Russian Federal Space Agency (RFSA)/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.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
CCSDS 911.1-B-3 Page iv January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
– United States Geological Survey (USGS)/USA.
CCSDS 911.1-B-3 Page v January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Link Extension— April 2002 Original issue, superseded
911.1-B-1 Return All Frames Service
Specification
CCSDS Space Link Extension— November Issue 2, superseded
911.1-B-2 Return All Frames Service 2004
Specification
CCSDS Space Link Extension—Return All January Current issue:
911.1-B-3 Frames Service Specification, 2010 – corrects/clarifies/
Recommended Standard, Issue 3 updates text and adds
the option of
picosecond resolution
to the earth-receive-
time parameter.
EC1 Editorial Change 1 August Corrects editorial errors in
2010 A2.4.
NOTE – Substantive changes from the previous issue are indicated by change bars in the
inside margin.
CCSDS 911.1-B-3 Page vi JAanuaugusryt 2010 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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-7
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-14
3.3 RAF-UNBIND . 3-20
3.4 RAF-START . 3-24
3.5 RAF-STOP. 3-29
3.6 RAF-TRANSFER-DATA . 3-31
3.7 RAF-SYNC-NOTIFY . 3-36
3.8 RAF-SCHEDULE-STATUS-REPORT . 3-39
3.9 RAF-STATUS-REPORT. 3-43
3.10 RAF-GET-PARAMETER . 3-46
3.11 RAF-PEER-ABORT . 3-50
4 RAF PROTOCOL . 4-1
4.1 GENERIC PROTOCOL CHARACTERISTICS . 4-1
4.2 RAF SERVICE PROVIDER BEHAVIOR . 4-4
CCSDS 911.1-B-3 Page vii January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
CONTENTS (continued)
Section Page
ANNEX A DATA TYPE DEFINITIONS (NORMATIVE) . A-1
ANNEX B CONFORMANCE MATRIX (NORMATIVE) .B-1
ANNEX C INDEX TO DEFINITIONS (INFORMATIVE) . C-1
ANNEX D ACRONYMS (INFORMATIVE) . D-1
ANNEX E INFORMATIVE REFERENCES (INFORMATIVE) .E-1
Figure
1-1 SLE Services Documentation . 1-4
2-1 Return Space Link Processing SLE-FG . 2-4
2-2 RCF Service Production and Provision . 2-6
2-3 Example of the Management and Provision of RCF Service . 2-7
2-4 Simplified RCF Service Provider State Transition Diagram . 2-10
2-5 Mapping of RCF Service Operations to SLE-PDUs . 2-12
2-6 Buffers and Delivery Modes . 2-17
Table
2-1 RAF Operations . 2-9
3-1 Setting of RAF Service Configuration Parameters . 3-6
3-2 RAF-BIND Parameters . 3-15
3-3 RAF-UNBIND Parameters . 3-21
3-4 RAF-START Parameters . 3-25
3-5 RAF-STOP Parameters . 3-29
3-6 RAF-TRANSFER-DATA Parameters . 3-31
3-7 RAF-SYNC-NOTIFY Parameters . 3-36
3-8 RAF-SCHEDULE-STATUS-REPORT Parameters . 3-40
3-9 RAF-STATUS-REPORT Parameters . 3-43
3-10 RAF-GET-PARAMETER Parameters . 3-46
3-11 RAF Parameters . 3-48
3-12 RAF-PEER-ABORT Parameters . 3-50
4-1 Provider Behavior . 4-6
4-2 Event Description References . 4-12
4-3 Predicate Descriptions . 4-12
4-4 Boolean Flags. 4-13
4-5 Compound Action Definitions . 4-13
B-1 Conformance Matrix for RAF Service (Operations) . B-1
B-2 Conformance Matrix for RAF Service (Other Requirements) . B-2
CCSDS 911.1-B-3 Page viii January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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;
b) completely and with integrity;
CCSDS 911.1-B-3 Page 1-1 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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 reference [2]. This specification
is more restrictive with respect to telemetry channel coding than is reference [2]. In
particular, the provision of RAF service requires that Reed-Solomon coding must be present
or absent on all frames of a physical channel. RAF service is not supported where there is a
concurrent mix, on one physical channel, of some frames with Reed-Solomon coding and
some frames without.
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:
a) section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the definitions, conventions, and references used
throughout the Recommended Standard;
CCSDS 911.1-B-3 Page 1-2 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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 provides a conformance matrix that defines what capabilities must be
provided for an implementation to be considered compliant with this Recommended
Standard;
g) annex C lists all terms used in this Recommended Standard and identifies where they
are defined;
h) annex D lists all acronyms used within this document;
i) annex E 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-3 Page 1-3 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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
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 [E2]): 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-3 Page 1-4 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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 [6]. 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 [7]:
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-3 Page 1-5 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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 [3]:
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 [4]:
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;
CCSDS 911.1-B-3 Page 1-6 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
f) Mission Data Operation System (MDOS);
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-3 Page 1-7 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES 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 [3]), or the FECF of an AOS Transfer Frame (reference [4]), as applicable.
1.6.1.7.6 Initiator
The initiator is the object that issues the request to bind to another object (the responder).
CCSDS 911.1-B-3 Page 1-8 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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.
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.
CCSDS 911.1-B-3 Page 1-9 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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 [3] if the
frame is a TM Transfer Frame or as defined in reference [4] 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 [3]) or an
AOS Transfer Frame (as defined in reference [4]). In case a distinction of the frame versions
is necessary, the full term as per references [3] or [4] 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 [3]
or the TFVN as defined in reference [4].
NOTE – The definitions of TFVN given in references [3] and [4] 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.
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;
CCSDS 911.1-B-3 Page 1-10 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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.
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.
CCSDS 911.1-B-3 Page 1-11 January 2010
CCSDS RECOMMENDED STANDARD FOR SLE RETURN ALL FRAMES SERVICE
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’.
1.6.3.2.4 State Names
This Recommended Sta
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...