ISO 21076:2016

INTERNATIONAL ISO
STANDARD 21076
First edition
2016-07-01
Space data and information transfer
systems — Space communications
cross support — Architecture
requirements document
Données spatiales et systèmes de transfert d’information - Support
croisé des communications spatiales - Exigences d’architecture
Reference number
©
ISO 2016
© ISO 2016, Published in Switzerland
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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
ISO 21076 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 901.1-M-1, May 2015) 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.
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommendations and are not in
themselves considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Practice is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified. Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
CCSDS 901.1-M-1 Page ii May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Practice is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-4). 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 sent to the CCSDS
Secretariat at the e-mail address indicated on page i.
CCSDS 901.1-M-1 Page iii May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– 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 (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Federal Space Agency (FSA)/Russian Federation.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking and
Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– Electronics and Telecommunications Research Institute (ETRI)/Korea.
– 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 Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– South African National Space Agency (SANSA)/Republic of South Africa.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– Swiss Space Office (SSO)/Switzerland.
– United States Geological Survey (USGS)/USA.
CCSDS 901.1-M-1 Page iv May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications Cross May 2015 Original issue
901.1-M-1 Support—Architecture Requirements
Document, Recommended Practice,
Issue 1
CCSDS 901.1-M-1 Page v May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-3
1.4 RATIONALE . 1-4
1.5 DOCUMENT STRUCTURE . 1-4
1.6 DEFINITIONS AND CONVENTIONS. 1-5
1.7 REFERENCES . 1-12

2 OVERVIEW . 2-1

2.1 BACKGROUND . 2-1
2.2 ROLE OF THIS ARCHITECTURE REQUIREMENTS DOCUMENT . 2-1
2.3 STRUCTURE OF THE ARD: FOUR VIEWS OF SYSTEM ARCHITECTURE 2-3
2.4 RELATIONSHIPS BETWEEN SCCS AND OTHER CCSDS DOCUMENTS . 2-5
2.5 CROSS SUPPORT SERVICE SYSTEM ELEMENTS . 2-6
2.6 BASIC SYSTEM-ELEMENT CONFIGURATIONS . 2-9
2.7 NETWORK TERMINOLOGY . 2-11
2.8 PRACTICAL LIMITS ON PROTOCOL CHOICES . 2-14
2.9 HOW TO USE THIS DOCUMENT . 2-15

3 CROSS SUPPORT OVERVIEW OF ABA AND SSI TECHNICAL
ARCHITECTURE—CROSS SUPPORT BUILDING BLOCKS . 3-1

3.1 OVERVIEW . 3-1
3.2 BUILDING-BLOCK FUNCTIONS . 3-2

4 SERVICE VIEW . 4-1

4.1 OVERVIEW . 4-1
4.2 ABA SERVICES . 4-2
4.3 SSI SERVICES . 4-7
4.4 SECURITY REQUIREMENTS FOR SERVICES . 4-12

5 PHYSICAL VIEW . 5-1

5.1 OVERVIEW . 5-1
5.2 ABA-SPECIFIC ELEMENTS . 5-2
5.3 SSI PHYSICAL ELEMENTS . 5-13
5.4 SECURITY REQUIREMENTS FOR PHYSICAL ELEMENTS . 5-25

CCSDS 901.1-M-1 Page vi May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
CONTENTS (continued)
Section Page
6 COMMUNICATIONS VIEW . 6-1

6.1 OVERVIEW . 6-1
6.2 PROTOCOL BUILDING BLOCKS . 6-6

7 END-TO-END DEPLOYMENT VIEW . 7-1

7.1 OVERVIEW . 7-1
7.2 ABA END-TO-END PROTOCOL VIEWS—REQUIREMENTS . 7-1
7.3 SSI END-TO-END PROTOCOL VIEWS: REQUIREMENTS . 7-3
7.4 DISCUSSION—SECURITY REQUIREMENTS FOR END-TO-END
DEPLOYMENTS . 7-5

ANNEX A SECURITY AND SANA CONSIDERATIONS (INFORMATIVE) . A-1
ANNEX B GLOSSARY (INFORMATIVE) .B-1
ANNEX C ABBREVIATIONS (INFORMATIVE) . C-1
ANNEX D INFORMATIVE REFERENCES (INFORMATIVE) . D-1
Figure
1-1 Graphical Conventions . 1-10
2-1 Roles of the SCCS Architecture Documents . 2-2
2-2 Basic ABA Configuration . 2-10
2-3 SSI Core Configuration . 2-11
2-4 The SSI . 2-13
3-1 Generic ABA End-to-End Deployment . 3-1
3-2 Generic SSI End-to-End Deployment . 3-2
4-1 ABA Service Interfaces . 4-2
4-2 SSI End-to-End Run-Time Service Interfaces . 4-7
4-3 SSI ESLT Service Interfaces for Earth Routing Node . 4-8
5-1 ABA Node—Generic Building Block . 5-2
5-2 SSI Node—Generic Building Block . 5-13
6-1 ABA ESLT Protocol Building Blocks . 6-8
6-2 ABA ESLT Radiometric Processing Protocol Building Blocks . 6-10
6-3 ABA ESLT Service Management Protocol Building Blocks . 6-11
6-4 ABA ESLT Service Management Configuration and Execution Building Blocks . 6-12
6-5 ABA ESLT Monitor Data Protocol Building Blocks . 6-13
6-6 ESLT Service Control Service-Provider Protocol Stack Building Blocks . 6-14
6-7 ESLT Delta-DOR Service-Provider Protocol Stack Building Blocks . 6-15
6-8 ABA ESLT Forward-File Protocol Building Blocks . 6-16
6-9 ABA ESLT Return File Protocol Building Blocks . 6-17
CCSDS 901.1-M-1 Page vii May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
CONTENTS (continued)
Figure Page
6-10 ABA Earth User Forward Protocol Building Blocks . 6-19
6-11 ABA Earth User Node Return Protocol Building Blocks . 6-20
6-12 ABA Earth User Radiometric, Monitor and Control Protocol Building Blocks . 6-22
6-13 ABA Space User Forward Protocol Building Blocks . 6-25
6-14 ABA Space User Return Protocol Building Blocks . 6-26
6-15 ABA Space User Ranging Protocol Building Blocks . 6-27
6-16 ABA Space User Delta-DOR Protocol Building Blocks . 6-28
6-17 Secure ABA Earth User F-Frame and Forward-File Protocol Building Blocks . 6-28
6-18 Secure ABA Space User F-Frame and Forward-File Protocol Building Blocks . 6-29
6-19 SSI ESLT and User DTN Protocol Building Blocks . 6-32
6-20 SSI ESLT and User DTN Forward-File Building Blocks . 6-33
6-21 SSI ESLT and User Service Management Building Blocks . 6-35
6-22 SSI Space User and Routing Node DTN Protocol Building Blocks . 6-36
6-23 SSI ESLT and Space Routing DTN Network Management Building Blocks . 6-37
6-24 SSI Earth Routing Node Forward Building Blocks . 6-38
6-25 SSI Earth Routing Node Return Building Block . 6-39
6-26 SSI Earth User Node DTN Forward Building Blocks . 6-40
6-27 SSI Space User DTN Forward-File Building Blocks . 6-42
6-28 SSI Space User and Routing Node Local LAN Building Blocks . 6-42
6-29 SSI Secure Forward-File Building Blocks . 6-43
6-30 SSI Secure Space User and Space Routing Node Building Blocks . 6-45
6-31 SSI Last-Hop/First-Hop Delivery Agent Building Blocks . 6-47
6-32 SSI User Last-Hop/First-Hop Transfer File Building Block . 6-50
7-1 ABA End-to-End Forward: ABA Agency Supporting ABA Agency . 7-2
7-2 SSI End-to-End Forward: SSI Agency Supporting SSI Agency . 7-3
7-3 ABA Secure End-to-End Forward: ABA Agency Supporting ABA Agency . 7-6
7-4 SSI Secure End-to-End Forward: SSI Agency Supporting SSI Agency . 7-6

Table
2-1 Cross Support Service Elements and Nominal Locations . 2-7
2-2 User Elements and Nominal Locations . 2-8
2-3 Examples of Provider Cross Support Service Systems and Related Elements . 2-9
2-4 Examples of User Cross Support Service Systems and Related User Elements . 2-9
2-5 Example BDPs for Different Earth and Space Applications . 2-15
2-6 Examples of Mission Application-Specific Views . 2-17
5-1 ABA CSSE Node Type, Interfaces, and Functions . 5-3
5-2 ABA UE Node Types, Interfaces, and Functions . 5-7
5-3 SSI CSSE Node Types, Interfaces, and Functions . 5-14
5-4 SSI UE Node Types, Interfaces, and Functions . 5-21
CCSDS 901.1-M-1 Page viii May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
CONTENTS (continued)
Table Page
6-1 Referenced Communications Protocols . 6-2
6-2 Referenced Cross Support Protocols . 6-4
6-3 Referenced Security Protocols . 6-5
6-4 Required and Optional ABA ESLT Terrestrial Side Protocols . 6-6
6-5 Required and Optional ABA ESLT Space Side Protocols . 6-7
6-6 Required and Optional ABA Earth User Node Protocols . 6-18
6-7 Required and Optional ABA Space User Node Protocols . 6-24

CCSDS 901.1-M-1 Page ix May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommended Practice is to define a set of requirements for CCSDS-
recommended configurations for secure Space Communications Cross Support (SCCS)
architectures. This architecture is to be used as a common framework when CCSDS
Agencies 1) provide and use SCCS services, and 2) develop systems that provide
interoperable SCCS services. These SCCS services include both elements on the ground and
elements in space. These services cover both single-hop, space Data Link Layer services
(Mission Operations Center [MOC]-to-spacecraft), and Solar System Internet (SSI), multi-
hop, Network Layer services that involve data routing and internetworking using multiple
space assets.
NOTE – The term ‘agency’ is used in CCSDS, but users of CCSDS cross support concepts
include satellite operators and service providers, and the context of the cross
support is not limited to a user/provider interface with an agency.
This Space Communications Cross Support—Architecture Requirements Document (SCCS-
ARD) provides normative specifications and definitions; its companion Space
Communications Cross Support—Architecture Description Document (SCCS-ADD)
(reference [D5]) provides the descriptive information, explanatory materials, and other
graphical representations that support the understanding of these requirements.
1.2 SCOPE
This document describes SCCS architecture in terms of the following:
– definitions of all key elements, on ground and in space, that are involved in space
communications;
– definitions of concepts that characterize SCCS services;
– requirements on system elements and components that provide secure SCCS services;
– recommended protocol stack configurations for each element type; and
– recommended end-to-end system configurations to provide interoperable and cross-
supportable space communications services.
This document does not specify:
− the details of how to implement systems that provide SCCS services;
− explicit technologies needed to implement SCCS services;
− application or mission operations protocols except for those used for data transfer;
CCSDS 901.1-M-1 Page 1-1 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
− mission operations except for those involved in planning, scheduling, and executing
space communications;
− spacecraft onboard cross support, except for space communication services.
This document contains references to other CCSDS technical engineering and architectural
recommendations describing how systems doing space communication cross support should
be engineered, deployed, organized, and operated to provide interoperable SCCS services.
While this document does not specify detailed internal implementation approaches, which
are a private matter, it does recommend specific protocols and protocol stacks, service
interfaces, element behaviors, and end-to-end architectures.
Some of the standards that are referenced in this document, especially those relating to the
SSI, are still in development. They are included here so the reader gets a clear understanding
of how they fit into an overall architecture.
The protocol-related parts of this document make liberal reference to the layers defined in the
Open Systems Interconnection (OSI) Basic Reference Model (reference [4]). Subsection 6.2
of the Architecture Description Document (ADD) (reference [D5]) contains a discussion of
the OSI stack and the functions associated with each layer.
The technical scope of single-hop cross support is the provision of Data Link Layer (Layer 2)
data communications services across the Solar System in support of space mission users,
using the interoperable infrastructure of one or more space agencies. Services above the
Data Link Layer, such as CCSDS File Delivery Protocol (CFDP), Cross-Support File Service
(CXFS), or Delta-Differential One-way Range (DOR), may also be provided. All mission
operations application in CCSDS-compliant, interoperable, single-hop deployments are
expected to utilize these underlying space link and file communications layers.
The technical scope of the SSI is the provision of internetworked (Layer 3) data
communications services across the Solar System in support of space mission users, using
the confederated and interoperable infrastructure of one or more space agencies to achieve a
level of service that individual agencies would otherwise be unlikely to achieve. All mission
operations application in CCSDS-compliant, interoperable, SSI deployments are expected to
utilize these underlying space internetworking communications layers.
The temporal scope of this document covers current, single-hop, secure interoperable cross
support installations, future deployments of an interoperable and evolving space networking
infrastructure, and the transition strategies to evolve from current deployments to a future
SSI state. Included in this discussion are mission-driven considerations, such as use of hybrid
science/routing missions, as well as identification of optional configurations that are
considered acceptable because they are in line with the transition strategies defined in this
document.
Any agency that wishes to participate as a peer in the SSI should implement interoperable
services and interfaces at least up to the Network Layer, along with related support services,
as described in this document and specified in the relevant CCSDS and Internet standards.
CCSDS 901.1-M-1 Page 1-2 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
Agencies that are not yet ready to adopt the SSI themselves, but that wish to offer compliant
ground station cross support services that can support SSI services, may also take advantage
of this document for guidance on developing Data Link Layer services that will both meet
their immediate needs and also interoperate with SSI-enabled missions.
1.3 APPLICABILITY
1.3.1 APPLICABILITY OF THIS RECOMMENDED PRACTICE
This Recommended Practice provides a set of reference architecture requirements for the
development of CCSDS compatible agency systems for space communications. This
Recommended Practice is applicable to all space communication systems that are involved in
cross support.
The SCCS systems that are addressed in this Recommended Practice explicitly include
ground stations and related systems that provide cross support services, user mission control
and mission operations ground systems, and a variety of spacecraft systems. In all cases the
applicability is to both single space link (ABA) and internetworked (SSI) systems. The term
‘spacecraft systems’ includes free-flying spacecraft, landers, rovers, and even balloons and
other ‘platforms’ that are users of space communication services. It also includes spacecraft
that are themselves providers of space communication services.
1.3.2 LIMIT OF APPLICABILITY
This Recommended Practice is not a design for real SCCS systems that may be implemented
for communication with existing or future missions. It provides detailed, but broadly stated,
requirements that may be tailored or adapted for use in constructing such systems.
Future CCSDS requirements (e.g., service interfaces, protocols, or data formats) that are
planned, but still under development, are included for completeness so that the directions of
CCSDS are clear; these are marked ‘[Future]’ to avoid ambiguity. Any requirements that are
considered optional are marked ‘[Opt]’. The [Opt] requirements are things like security,
which may or may not be implemented by any given system. All other core standards, those
that are expected to be used by the bulk of missions and implemented by the bulk of service
providers, are defined as mandatory, with ‘shall’ rather than ‘should’ language. Any specific
system deployment may treat these as ‘shall’ if they are required for that use.
Any requirements marked ‘[Future]’ should not be relied upon in the design of current real
SCCS systems. This Recommended Practice will be updated periodically. When updates of
this document are published, any requirements now marked ‘[Future]’ whose conditions are
met will be reviewed and evaluated for inclusion as full requirements. Many of these future
specifications are completely applicable to either ABA or SSI deployments.
CCSDS 901.1-M-1 Page 1-3 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
1.4 RATIONALE
CCSDS has developed a body of space communications recommendations that specify
protocols and related services for specific types of functionality that are usually defined at a
single layer of the OSI stack, or define how to format and exchange a specific type of
information. In order to build end-to-end space communications systems that will
interoperate, systems designers need to understand how to select, configure, and deploy
different kinds of system elements that implement a complete stack of protocols in each
element and how these are assembled to deliver end-to-end services. Single-hop
communications configurations often require cross support, where one space agency
develops the spacecraft and the corresponding MOC, and another agency provides the
ground communications assets. This is the typical cross support configuration used today.
Multi-hop communications configurations may require that space assets developed by one
agency offer cross support to space elements developed by another agency, with both being
supported by ground communications assets from yet another agency.
Since cross support among agencies has become the norm, and since future agency
collaborative missions require elements developed by different agencies, at different times,
to interoperate as a network, agreed-upon interoperable standards and architectures must be
adopted in an end-to-end sense. As the only international body that defines standards to link
space communication service providers with space missions, CCSDS is defining this
recommended standard architecture for SCCS services, so that interoperable cross support
between agencies can be defined and operated more efficiently and effectively for single-hop
and multi-hop mission configurations.
Similar to existing ABA architectures, it is fundamental to the SSI concept that all full
participants in the confederation must expose standard and agreed-upon cross support
services at the Network Layer of the OSI communications stack, while observing common
network management strategies and governance mechanisms. Agencies that provide only
single-hop Data Link Layer services may still participate in the SSI if they provide compliant
services at that layer.
1.5 DOCUMENT STRUCTURE
This document consists of several sections plus annexes.
– Section 1 presents the purpose, scope, and rationale of this document and lists the
definitions, conventions, and references used throughout the document.
– Section 2 provides context and an overview of the SCCS architecture.
– Section 3 provides a brief overview of ABA and SSI technical architecture and some
guidance on how to use the document.
– Section 4 defines top-level service requirements of ABA and SSI configurations from
user and provider perspectives.
CCSDS 901.1-M-1 Page 1-4 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
– Section 5 defines physical requirements of spacecraft and ground system nodes that
are used to create deployed ABA and SSI configurations, their allocated functions,
and behavior.
– Section 6 defines communications requirements and protocol ‘stacks’ for the ABA
and SSI node types.
– Section 7 defines end-to-end deployment requirements for representative examples of
space communication configurations.
– Annexes provide a brief reference to security and Space Assigned Numbers Authority
(SANA) information, a normative glossary, an acronym list, and a list of informative
references.
Each of sections 4 through 7 includes a brief descriptive introduction and normative
subsections that define the required elements, attributes, and behaviors for both ABA and
SSI deployments. The ADD (reference [D5]) contains an extended set of descriptive
materials that provide explanations and examples.
1.6 DEFINITIONS AND CONVENTIONS
1.6.1 TERMS
For the purposes of this document, the following normative definitions apply. Many of these
terms are derived from other sources. Primary sources of definitions are references [1], [2],
[4], [5], [6], [D6], [D7], and [D8].
NOTE – Many other terms that pertain to specific items are defined in the appropriate
sections. A glossary with additional definitions can be found in annex B, and a
list of acronyms can be found in annex C.
ABA: A ‘single-hop’ space communications configuration that involves only a single direct
to/from Earth space link. Term derives from the notion of an Agency ‘A’ using the ground
station of an Agency ‘B’ to communicate between its MOC and its spacecraft, hence ABA.
ABCBA: A multi-hop space communications configuration that involves multiple space and
ground elements and one or more direct to/from Earth space links or space-space links.
ABCBA configurations nominally include elements from three or more agencies.
Application Layer: OSI Layer 7 contains all those functions that imply communication
between open systems that are not already performed by the lower layers.
building block: The set of nodes, with specific defined characteristics, that are used to
describe end-to-end system configurations in this document.
CCSDS 901.1-M-1 Page 1-5 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
CCSDS-compliant credential: One or more CCSDS baseline recommended credentials that
have the minimum recommended level of security. Higher-level security credentials (to be
defined in an update to reference [7]) may be employed where required.
Coding and Synchronization sublayer: CCSDS-defined sublayer (of the OSI Data Link
Layer) that provides error detection and correction for the space Data Link Layer protocols
and deals with noisy, low signal-to-noise ratio, space link physical channel characteristics.
credential: A physical/tangible object, a piece of knowledge, or a facet of a person’s
physical being, that enables an individual to have access to a given physical facility or
computer-based information system.
cross support: An agreement between two or more organizations to exploit the technical
capability of interoperability for mutual advantage, such as one organization offering support
services to another in order to enhance or enable some aspect of a space mission.
cross support service: A function provided by one space agency to support operations of a
space mission of another space agency.
cross support service element, CSSE: A physical element involved in providing one or
more cross support services (including functions for managing services).
cross support service system, CSSS: A set of CSSEs or user elements that are managed by
a single authority with a single set of management policies. These may be user or provider
systems.
Cross Support Transfer Service, CSTS: A family of cross support services, based upon a
common framework derived from space link extension, that provides reliable, access-
controlled transfer of spaceflight mission-related data between ground CSSEs and user
elements. Each type of CSTS is qualified by the kind of data it transfers (e.g., telemetry
frames, tracking data, monitor data).
data delivery services: The generic term for the CSTS and space link extension services
used to deliver data between an Earth-Space Link Terminal (ESLT) and the ground user
elements that use it.
Data Link Layer: The OSI Layer (Layer 2, often referred to as ‘link layer’) that provides
functional and procedural means for the establishment, maintenance, and release of data link
connections among Network Layer entities (where they are used) and for the transfer of data
link service data units.
Earth User Node: A physical element, located on the ground, that uses a cross support
service provided by a CSSS.
element management, EM: A set of functions that manage elements and interact with PM
for purposes of ascertaining element resource availability, configuration and execution of
element resources, and reporting status of those resources.
CCSDS 901.1-M-1 Page 1-6 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
forward data: Data sent from a ground element to a space element.
forwarding: The act of transferring data from its source towards its destination, which may
be in space or on the ground.
functional resource: The functions or capabilities that are provided by physical resources
(e.g., transmitters and receivers) of a CSSE, but not those physical resources themselves. A
functional resource is a logical construct not necessarily linked to any single system
component.
interface binding signature: A ‘signature’ that results from a service user and service
provider implementing the proper stack of interface protocols in order to bind to service
elements. This signature may involve Transmission Control Protocol/Internet Protocol
(TCP/IP), Hypertext Transfer Protocol (HTTP), or some set of CCSDS space-communication
protocols.
internetwork: A ‘network of networks’ (often shortened to internet), where two or more
distinct computer networks are connected together using routing devices that allow traffic to
flow back and forth between the networks.
internetworking: Practice of connecting two or more distinct computer networks or network
segments together to form an internetwork, using devices which operate at OSI Layer 3
(Network Layer) to connect them together to allow traffic to flow back and forth between
them.
interoperability: A property of protocols or systems whereby elements adopt a commonly
defined and implemented set of protocols, data, and behaviors.
logical link: A link that shows a relationship between various types of logical objects (e.g.,
functions, protocols, or organizations). It may be considered separately from any particular
implementation or deployment and has no physical manifestation except as part of a model.
network: One or more computers or other processing elements that are owned by a single
organization, communicating using a single OSI Layer 3 protocol and sharing a single
Layer-2 technology.
Network Layer: OSI Layer 3, which provides the means to establish, maintain, and
terminate network connections between open systems and provides transport entities
independence from routing and relay considerations.
node: A space data system physical entity operating in a physical environment. A node is a
configuration of engineering objects forming a single unit for the purpose of location in
space, and embodying a set of processing, storage, and communication functions. A node has
some well-understood, possibly rapidly moving location, and it may be composed of two or
more (sub-) nodes.
physical channel: A stream of bits transferred over a space link in a single direction.
CCSDS 901.1-M-1 Page 1-7 May 2015
CCSDS RECOMMENDED PRACTICE FOR SPACE COMMUNICATIONS CROSS SUPPORT—
ARCHITECTURE REQUIREMENTS DOCUMENT
Physical Layer: OSI Layer 1, which provides for the transparent transmission of bit streams
between data-link entities across physical connections and the mechanical, electrical,
functional, and procedural means to activate, maintain, and deactivate physical connections.
protocol data unit, PDU: A unit of data which is specified in a protocol of a given layer and
which consists of protocol-control information, addressing information, and possibly user
data for that layer (typically defined as a Service Data Unit [SDU]).
provider system: A CSSS that provides services to a user CSSS. A provider CSSS may also
be a user of other CSSS services.
provision management, PM: A set of functions of a CSSS, related to the acquisition and
management of services provided by that CSSS to other CSSSes. PM interacts with the
utilization management of user CSSSes to negotiate provision of services to their respective
CSSSes.
Proximity link: A communications link between an element in space and another nearby
element in space or on the surface of a planetary body (<1 second Round-Trip Light Time
[RTLT]).
relaying: A managed process for forwarding frame, packet, or physical data that involves no
decision making.
return data: Data sent from a space element to a ground element.
router: A device that forwards Network Layer PDUs between computer networks, creating
an Internetwork. A router is connected to two or more data links from different subnetworks
and uses address information in the PDU and information in its routing table or routing
policy to direct the PDU to the next subnetwork.
routing: The process of selecting paths from origins to destinations in a network.
service management, SM: 1) The set of
...