ISO/TC 20/SC 13 - Space data and information transfer systems

This document defines the Communications Link Transmission Unit (CLTU) service in conformance with the transfer services specified in reference [1], Cross Support Reference Model—Part 1: SLE Services. The Forward CLTU service is a Space Link Extension (SLE) transfer service that enables a mission to send Communications Link Transmission Units (CLTUs) to a spacecraft. This document defines, in an abstract manner, the Forward CLTU service in terms of: the operations necessary to provide the transfer 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 radiate data to a spacecraft and to acquire telemetry frames from the signals received from that spacecraft for extraction of the Operational Control Field; the methods or technologies required for communications; or the management activities necessary to schedule, configure, and control the Forward CLTU service.

The purpose of this document is to define the Space Link Extension (SLE) Return Operational Control Fields (ROCF) service in conformance with the SLE Reference Model (reference [1]). The ROCF service is an SLE transfer service that delivers to a mission user all operational control fields from one master channel or one virtual channel. This document defines, in an abstract manner, the ROCF 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 ROCF service. NOTE – Reference [1] defines the Return Master Channel Operational Control Field (Rtn MC-OCF) service and the Return Virtual Channel Operational Control Field (Rtn VC-OCF) service as two distinct services. Subsequent study has indicated that it is preferable to define one service that provides the functionality of both. The ROCF service defined here does just that. It is anticipated that a future issue of reference [1] will take the same approach, deleting the Rtn MC-OCF and Rtn VC-OCF services and replacing them with the Rtn OCF service.

The purpose of this document is to define the Space Link Extension (SLE) Return Channel Frames (RCF) service in conformance with the SLE Reference Model (reference [1]). The RCF service is an SLE transfer service that delivers to a mission user all telemetry frames from one master channel or one virtual channel. This document defines, in an abstract manner, the RCF 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 RCF service. NOTE – Reference [1] defines the Return Master Channel Frames (Rtn MC Frames) service and the Return Virtual Channel Frames (Rtn VC Frames) service as two distinct services. Subsequent study has indicated that it is preferable to define one service that provides the functionality of both. The RCF service defined here does just that. It is anticipated that a future issue of reference [1] will take the same approach, deleting the Rtn MC Frames and Rtn VC Frames services and replacing them with the RCF service.

The purpose of this document is to provide a common reference and framework of standards for digital motion video and imagery, and to provide recommendations for utilization of international standards for sharing or distributing motion video and imagery between spacecraft elements and ground systems. The scope of this document includes traditional real-time streaming video and television, including human and robotic spacecraft-to-spacecraft and spacecraft-to-ground systems, as well as video recorded and distributed later, either as a real-time stream or as a file transfer. In this context, real-time streaming includes all modes where video is sent from a spacecraft in a continuous stream and is intended for immediate use when received, regardless of the latency of the transmission path. Other specialized motion imagery applications, such as high-speed scientific motion imagery and multi-spectral motion imagery, are not addressed in this document. However, if a specialized imagery camera system has a requirement to interface to spacecraft systems in a video mode, it would be required to match these interfaces. Ground-systems-to-ground-systems video distribution is obviously a key component of the entire video system. However, this is not the primary focus of this document. Currently, there are significant differences in the ways mission video products are exchanged between the various space agencies on the ground. This is the result of differences in network topologies between space agencies, and agreements for video sharing. Those differences preclude there being a standard methodology for delivering video imagery between agencies. Prior to the commencement of video transmission between space agencies, system design reviews and performance testing should be done between the ground systems in use to assure operability when video imagery comes from spacecraft.

This document defines the Application Program Interface in terms of: the components that provide the services of the API; the functionality provided by each of the components; the interfaces provided by each of the components; and the externally visible behavior associated with the interfaces exported by the components. It does not specify: individual implementations or products; the internal design of the components; and the technology used for communications. This document defines those aspects of the Application Program Interface, which are common for all SLE service types or for a subset of the SLE service types, e.g., all return link services or all forward link services. It also defines a framework for specification of service type-specific elements of the API. Service-specific aspects of the API are defined by supplemental Recommended Practice documents for SLE return link services (references [10], [11], and [12]) and SLE forward link services (references [13] and [14]). This document for the Application Program Interface responds to the requirements imposed on such an API by the CCSDS SLE transfer service Recommended Standards that were available when this document was released.

This document defines the Forward Space Packet (FSP) service in conformance with the transfer services specified in reference [1], Cross Support Reference Model―Part 1: SLE Services. The FSP service is a Space Link Extension (SLE) transfer service that enables a mission to send Space Packets to a spacecraft in sequence-controlled or expedited mode. This document defines, in an abstract manner, the FSP service in terms of: the operations necessary to provide the transfer 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 radiate Space Packets to a spacecraft and to acquire telemetry frames from the signals received from that spacecraft for extraction of the Operational Control Field; the methods or technologies required for communications; or the management activities necessary to schedule, configure, and control the FSP service. NOTE – While the FSP service as described in reference [1] is conceived to handle a variety of packet data structures, this version of the FSP Recommended Standard is restricted to the handling of Space Packets as defined in reference [6]. This version of the FSP Recommended Standard is specific to the transfer of Space Packets to be transmitted via the Telecommand protocol stack as defined in references [3], [4], and [5]. The Cross Support Reference Model (reference [1]) specifies that the FSP service may also be used in conjunction with the Advanced Orbiting System protocol stack, but that mode of operation is outside the scope of this version of the Recommended Standard. The FSP service is provided in the online delivery mode, as defined in reference [1]. The offline delivery mode is the subject of further study.

This document specifies two standard message formats for use in transferring spacecraft attitude information between space agencies: the Attitude Parameter Message (APM) and the Attitude Ephemeris Message (AEM). Such exchanges are used for: - preflight planning for tracking or attitude estimation support; - scheduling attitude and data processing support; - carrying out attitude operations; - performing attitude comparisons; - carrying out attitude propagations and/or sensor predictions; - testing to initialize sub-system simulators (communications, power, etc.). This document includes sets of requirements and criteria that the message formats have been designed to meet. For exchanges where these requirements do not capture the needs of the participating agencies, another mechanism may be selected.

This document defines, in an abstract manner, 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.

1.1.1 This Recommended Standard defines, in an abstract manner, a CSTS in terms of: a) the procedures necessary to provide the service; b) the states of the service; c) the behavior of each procedure; d) the states of the procedures; e) the operations necessary to constitute the procedures; and f) the parameters associated with each operation. 1.1.2 It does not specify: a) individual application services, implementations, or products; b) the implementation of entities or interfaces within real systems; c) the methods or technologies required to acquire data; d) the methods or technologies required to provide a suitable environment for communications; or e) the management activities required to schedule and configure services.

This Recommended Standard defines the Monitored Data service in terms of: a) the CSTS procedures that constitute the service; b) the extensions and refinements of the behavior of those CSTS procedures necessary to provide the transfer service; c) the extensions and refinements of standard CSTS operations associated with each of the procedures; d) the relationships among the procedures that constitute the service. 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 measure the values of monitored parameters and to detect the occurrence of events of interest; d) the methods or technologies required for communication; e) the management activities necessary to schedule, configure, and control the MD-CSTS; f) the specific parameters that are to be reported and events that are to be notified by the MD-CSTS.

ISO 22645:2016 defines the TM Space Data Link Protocol in terms of: a) the services provided to the users of this protocol; b) the protocol data units employed by the protocol; and c) the procedures performed by the protocol. It does not specify: a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the protocol.

ISO 18445:2016 Practice defines extensions to the SLE API in terms of: a) the CLTU-specific functionality provided by API components; b) the CLTU-specific interfaces provided by API components; and c) the externally visible behavior associated with the CLTU interfaces exported by the components. It does not specify a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18445:2016 defines only interfaces and behavior that must be provided by implementations supporting the forward CLTU service in addition to the specification in reference [5].

ISO 18440:2016 defines a protocol for transfer of SLE PDUs between an SLE user and an SLE provider system in terms of: a) the procedures used to establish and release associations; b) the messages exchanged on an established association; c) the procedures used to monitor the status of data communication connections; and d) the methods used to ensure that data are converted between different formats and representations on different platforms. It does not specify: a) individual designs, implementations, or products; b) the configuration of the data communications infrastructure, including configuration of the TCP and IP protocols; c) the means by which addresses (IP addresses and TCP port numbers) are agreed, assigned and communicated.

ISO 18444:2016 defines extensions to the SLE API in terms of: a) the ROCF-specific functionality provided by API components; b) the ROCF-specific interfaces provided by API components; and c) the externally visible behavior associated with the ROCF interfaces exported by the components. It does not specify: a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18444:2016 defines only interfaces and behavior that must be provided by implementations supporting the Return Operational Control Fields service in addition to the specification in reference [3].

ISO 21323:2016 is designed to be applicable to any kind of space mission or infrastructure that is communication-resource poor and is subject to long latencies and/or temporary network partitions, regardless of complexity. It is intended that this Recommended Standard become a uniform standard among all CCSDS Agencies. In addition, this specification exists to utilize the underlying service of various internetworking protocols both onboard and in transit between ground and space-based assets. ISO 21323:2016 is intended to be applied to all systems that claim conformance to the CCSDS Bundle Protocol. It is agnostic to the choice of underlying transmission protocol in that BP can function over AOS, Space Packet, Proximity-1 Space Link Protocol, and various Internet and ground based protocols. The CCSDS believes it is important to document the rationale underlying the recommendations chosen, so that future evaluations of proposed changes or improvements will not lose sight of previous decisions. The concept and rationale for the use of a bundle protocol in space links may be found in reference [H1].

ISO 22666:2016 defines the AOS Space Data Link Protocol in terms of: a) the services provided to the users of this protocol; b) the protocol data units employed by the protocol; and c) the procedures performed by the protocol. It does not specify: a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the protocol.

ISO 18446:2016 defines extensions to the SLE API in terms of: a) the FSP-specific functionality provided by API components; b) the FSP-specific interfaces provided by API components; and c) the externally visible behavior associated with the FSP interfaces exported by the components. It does not specify: a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18446:2016 defines only interfaces and behavior that must be provided by implementations supporting the Forward Space Packet service in addition to the specification in reference [5].

ISO 10537:2016 defines the Encapsulation Service in terms of: a) the service primitives provided to the users of this service; b) the protocol data units employed by the service provider; and c) the procedures performed by the service provider. It does not specify: a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the service.

ISO 18443:2016 Practice defines extensions to the SLE API in terms of: a) the RCF-specific functionality provided by API components; b) the RCF-specific interfaces provided by API components; and c) the externally visible behavior associated with the RCF interfaces exported by the components. It does not specify: a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18443:2016 defines only interfaces and behavior that must be provided by implementations supporting the Return Channel Frames service in addition to the specification in reference [3].

The purpose of ISO 21324:2016 is to specify the Space Data Link Security Protocol (hereafter referred as the Security Protocol) for CCSDS data links. This protocol provides a security header and trailer along with associated procedures that may be used with the CCSDS Telemetry, Telecommand, and Advanced Orbiting Systems Space Data Link Protocols (references [1]-[3]) to provide a structured method for applying data authentication and/or data confidentiality at the Data Link Layer.

ISO 18442:2016 defines extensions to the SLE API in terms of: a) the RAF-specific functionality provided by API components; b) the RAF-specific interfaces provided by API components; and c) the externally visible behavior associated with the RAF interfaces exported by the components. It does not specify a) individual implementations or products; b) the internal design of the components; and c) the technology used for communications. ISO 18442:2016 defines only interfaces and behavior that must be provided by implementations supporting the Return All Frames service in addition to the specification in reference [3].

ISO 22664:2016 defines the TC Space Data Link Protocol in terms of: a) the services provided to the users of this protocol; b) the protocol data units employed by the protocol; and c) the procedures performed by the protocol. It does not specify: a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the protocol.

The scope of ISO 21082:2016 is the specification of the binding in terms of technology mapping to the Space Packet Protocol of: a) MAL message; b) MAL Transport Interface. The MAL Blue Book (reference [2]) specifies the MAL protocol in an abstract way, i.e., without defining the concrete protocol data units. The MAL Space Packet Transport Binding and Binary Encoding specifies: a) a complete and unambiguous mapping of the MAL message to the Space Packet; b) a complete and unambiguous mapping of the MAL transport interface to the Space Packet Protocol interface; c) a complete and unambiguous mapping of the MAL data types to fixed and variable length binary encoding formats. This Recommended Standard does not specify: a) individual implementations or products; b) the implementation of entities or interfaces within real systems. MO services defined in terms of MAL using the Space Packet Transport Binding as defined in this Recommended Standard are fully interoperable.

ISO 21076:2016 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. ISO 21076:2016 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; - mission operations except for those involved in planning, scheduling, and executing space communications; - spacecraft onboard cross support, except for space communication services. ISO 21076:2016 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. A

1.1 Purpose ISO 21080:2016 defines a Recommended Standard for the CCSDS Licklider Transmission Protocol (LTP) and associated service for application in the space environment. LTP provides optional reliability mechanisms on top of an underlying (usually data link) communication service. 1.2 Scope LTP is intended for use over the current and envisaged packet delivery services used in the space environment, including: - CCSDS conventional packet telecommand; - CCSDS conventional packet telemetry. For space data links, LTP will typically be deployed over a CCSDS data link that supports CCSDS Encapsulation Packets so that one LTP segment can be encapsulated in a single Encapsulation Packet. LTP may also operate over a wide variety of ground-network services including those specified by the CCSDS for cross-support purposes.

ISO 18202:2015 defines, in an abstract manner, the MAL in terms of: a) the concepts that it builds upon; b) the basic types it provides; c) the message headers required by the layer; d) the relationship between, and the valid sequence of, the messages and resulting behaviours. 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 for communications.

ISO 22642:2015 defines synchronization and channel coding schemes in terms of: a) the services provided to the users of this specification; b) data formats; and c) the procedures performed to generate and process the data formats. It does not specify: a) individual implementations or products; b) the methods or technologies required to perform the procedures; or c) the management activities required to configure and control the system.

The DVB-S2 standard (reference [1]) proposes advanced modulation techniques (QPSK, 8PSK, 16APSK, and 32APSK) and a wide range of coding rates (from 1/4 to 9/10) with near-Shannon coding schemes (LDPC codes). This high number of modulation and coding schemes allows a wide range of possibilities to satisfy specific mission constraints. Moreover, to maximize the telemetry system throughput, it appears possible to adapt the transmitted waveform (and the useful data rate) to the variable conditions of the link. The DVB-S2 standard can actually implement Variable Coding and Modulation (VCM) mode, which adapts the transmission scheme to the channel conditions following a predetermined schedule (for example, following a dynamic link budget). When a channel is available to provide feedback (e.g., via a telecommand link), the transmission scheme can be dynamically adjusted using the Adaptive Coding and Modulation (ACM) mode. The use of the DVB-S2 standard for telemetry makes possible the use of generic Very High Scale Integrated Circuits (VHSIC) Hardware Description Language (VHDL) Intellectual Property (IP) modules for developments. The use of a widely implemented standard simplifies finding transmitting or receiving equipment to check compatibility. Finally, for the ground part, some telecom DVB-S2 receivers or Application Specific Integrated Circuits (ASICs) developed for the telecom market could be reused. ISO 20207:2015 is an adaptation profile describing how to use the DVB-S2 standard to transmit CCSDS Transfer Frames for telemetry purpose. The interface between CCSDS and DVB-S2 is based on the Attached Synchronization Marker (ASM) and Channel Access Data Unit (CADU) already introduced in reference [2]. DVB-S2 is used in this adaptation profile as a complete and self-sufficient standard, and definitions and specifications taken from DVB-S2 are applicable only in the context of this Recommended Standard. However, individual DVB-S2 functions or components (e.g., VCM/ACM, 8-PSK, and higher-order modulations) might be reused, redefined, and/or respecified by CCSDS in future Recommended Standards.

ISO 20210:2015 is the definition of all concepts and terms that establish a Java API for consuming and providing MO services on top of the MAL. The MAL Java API is intended to maximize the portability of the MO components across various underlying MAL implementations and transport protocols.

ISO 21459:2015 defines synchronization and channel coding schemes for Proximity-1 links in terms of: a) the services provided to the users of this specification; b) data formats; and c) the procedures performed to generate and process the data formats. It does not specify: a) individual implementations or products; b) the methods or technologies required to perform the procedures; or c) the management activities required to configure and control the protocol. The Coding and Synchronization Sublayer is part of the Data Link Layer. The rest of the Data Link Layer is defined in the separate CCSDS Recommended Standard entitled, Proximity-1 Space Link Protocol?Data Link Layer (reference [3]). The Physical Layer is defined in the separate CCSDS Recommended Standard entitled, Proximity-1 Space Link Protocol?Physical Layer (reference [4]).

ISO 20214:2015 is intended as a high-level systems engineering reference to enable engineers to better understand the layered security concepts required to secure a space system. As such, this document is a Security Architecture for Space Data Systems (SASDS). This architecture uses the views described in the Reference Architecture for Space Data Systems (reference [B1]) developed by the CCSDS Architecture Working Group. The SASDS will be used: ? to establish an overall CCSDS conceptual framework for the incorporation of security into the data systems of space missions; ? to define common language and representation so that risks, requirements, and solutions in the area of security within space data systems can be readily communicated; ? to provide a source of information for the security architects on a space mission to use to develop the system security design; ? to facilitate development of standards in a consistent way so that any standard can be used with other appropriate standards in a system.

Delta-DOR (Delta Differential One-Way Ranging) is a Very Long Baseline Interferometry (VLBI) technique that can be used in conjunction with Doppler and ranging data to improve spacecraft navigation by more efficiently determining spacecraft angular position in the plane of sky. It involves the use of multiple ground stations, possibly belonging to different agencies, for simultaneous acquisition of either spacecraft or quasar signals (see reference [D2]). This Delta-DOR Raw Data Exchange Format (RDEF) Recommended Standard specifies a standard format for use in exchanging Delta-DOR raw data among space agencies. Delta-DOR raw data exchange is required every time the data correlation involves at least one participating station not belonging to the agency responsible for the correlation. ISO 20208:2015 includes specifications on the parameter fields that the data format has been designed to meet. For exchanges where these specifications do not capture the needs of the participating agencies another mechanism may be selected.

ISO 20206:2015 addresses the recommended method for transferring IP Protocol Data Units (PDUs) over CCSDS space links.

ISO 22663:2015 defines the Data Link Layer (Framing, Medium Access Control, Data Services, and Input/Output [I/O] Sublayers). The specifications for the protocol data units, framing, media access control, expedited and sequenced-controlled data transfer, timing service, I/O control, and the procedures for establishing and terminating a session between a caller and responder are defined in this document. The Coding and Synchronization Sublayer is defined in the separate CCSDS Recommended Standard entitled, Proximity-1 Space Link Protocol?Coding and Synchronization Sublayer (reference [5]). The Physical Layer is defined in the separate CCSDS Recommended Standard entitled, Proximity-1 Space Link Protocol?Physical Layer (reference [6]). ISO 22663:2015 does not specify a) individual implementations or products, b) implementation of service interfaces within real systems, c) the methods or technologies required to perform the procedures, or d) the management activities required to configure and control the protocol.

ISO 21460:2015 defines the Proximity-1 Space Link Protocol Physical Layer. The specification for the channel connection process, provision for frequency bands and assignments, hailing channel, polarization, modulation, data rates, and performance requirements are defined in this document. Currently, the Physical Layer only defines operations at UHF frequencies for the Mars environment. The Data Link Layer is defined in the two separate CCSDS Recommended Standards entitled, Proximity-1 Space Link Protocol?Coding and Synchronization Sublayer (reference [2]), and Proximity-1 Space Link Protocol?Data Link Layer (reference [3]). ISO 21460:2015 does not specify a) individual implementations or products; b) implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the protocol.

The algorithms contained in ISO 20215:2015 are recommended for use on space missions with a requirement for information (e.g., data, voice, and video) confidentiality, authentication, or authenticated confidentiality. The algorithms may be employed on any or all mission communications links such as the forward space link (e.g., telecommand), the return space link (e.g., telemetry, science data), as well as across the ground data network. They could as well be used to ensure confidentiality and authenticity of stored data. A symmetric algorithm assumes that all communicating entities possess a shared secret (i.e., a ?key') which enables them to encrypt, decrypt, and authenticate information shared among them. The manner in which the shared secret is distributed and managed (key management) is not within the scope of this document. Further information on key management can be found in Space Missions Key Management Concept (reference [B22]).

ISO 20205:2015 is targeted towards monitoring and control systems, typically low data-rate and low-power wireless-based applications.

ISO 20104:2015 is to provide a standard method for formally defining the digital information objects to be transferred by an information Producer to an Archive and for effectively packaging these objects in the form of Submission Information Packages (SIPs). This supports effective transfer and validation of SIP data. ISO 20104:2015 fits into the context defined by: ? The Reference Model for an Open Archival Information System (OAIS) Recommended Standard (see reference [3]). ? The Producer-Archive Interface Methodology Abstract Standard (PAIMAS) Recommended Standard (see reference [2]). ? The XML Formatted Data Unit (XFDU) Structure and Construction Rules Recommended Standard (see reference [1]). The PAIMAS Recommended Standard (see reference [2]) defines a methodology based on the four following phases: Preliminary, Formal Definition, Transfer, Validation. ISO 20104:2015 applies specifically to the implementation of the main part of the Formal Definition Phase and the Transfer Phase, taking into account part of the Validation Phase. The proposed implementation should help in the automation and management of the Transfer and Validation Phases. The proposed implementation may also be used, to some extent, for the Preliminary Phase. ISO 20104:2015 does not exclude other PAIMAS implementation Recommended Standards.

ISO 18423:2015 defines both transparent and regenerative PN ranging systems for non?data relay satellite users. The specification for PN code components and generation, on-board spacecraft regenerative/transparent processing, ground station processing, and uplink and downlink signal modulation are defined in this document. This Recommended Standard does not specify a) individual implementations or products, b) implementation of service interfaces within real systems, or c) the management activities required to configure and control the protocol.

ISO 20106:2015 defines, in an abstract manner, the COM in terms of: a) the operations necessary to provide the service; b) the parameter data associated with each operation; c) the required behaviour of each operation; d) the use of the model. 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 for communications.

The CCSDS File Delivery Protocol (CFDP?reference [1]) has been designed to support the transfer of files in a variety of mission scenarios. CFDP offers different qualities of service ranging from best effort to fully reliable and has been specifically optimized for long delay, noisy, and disjoint links. CFDP requires a simple minimum service from the underlying protocols, operating over any link providing a packet communication service. ISO 20105:2015 is to specify how to operate CFDP over the CCSDS Encapsulation Service (reference [2]) as provided for Earth-to-spacecraft, spacecraft-to-Earth, and spacecraft-to-spacecraft communications. It sets out the communications architecture for CFDP operating over the Encapsulation Service. It describes the service expected by CFDP of the underlying layers and reconciles this with the service provided by the Encapsulation Service.

ISO 16919:2014 is meant primarily for those setting up and managing the organization performing the auditing and certification of digital repositories. It should also be of use to those who work in or are responsible for digital repositories seeking objective measurement of the trustworthiness of their repository and wishing to understand the processes involved. The main purpose is to define a CCSDS Recommended Practice (and ISO International Standard) on which to base the operations of the organization(s) which assess the trustworthiness of digital repositories using ISO 16363 and provide the appropriate certification. ISO 16919:2014 specifies requirements for bodies providing audit and certification of digital repositories, based on the metrics contained within ISO/IEC 17021 and CCSDS 652.0-M-1/ISO 16363. It is primarily intended to support the accreditation of bodies providing such certification. ISO/IEC 17021 provides the bulk of the requirements on bodies offering audit and certification for general types of management systems. However, for each specific type of system, specific additional requirements will be needed, for example, to specify the standard against which the audit is to be made and the qualifications which auditors require. ISO 16919:2014 provides the (small number of) specific additions required for bodies providing audit and certification of candidate trustworthy digital repositories. Trustworthy here means that they can be trusted to maintain, over the long-term, the understandability and usability of digitally encoded information placed into their safekeeping. In order improve readability, the clause numbers are kept consistent with those of ISO/IEC 17021. Some subclauses are applicable as they stand, and these are simply enumerated; otherwise additions to subclauses are explicitly given. In the former case, the clauses may consist of just a few sentences. As a result, this document must be read in conjunction with ISO/IEC 17021. The requirements contained in this document need to be demonstrated in terms of competence and reliability by any organization or body providing certification of digital repositories.

Delta Differential One-Way Ranging (Delta-DOR) operations are applicable to space agencies that operate deep space missions that require accurate determination of the spacecraft position in the plane of the sky. For operations where these requirements do not capture the needs of the participating agencies, Delta-DOR operations may not be appropriate. ISO 17809:2014 addresses rationale, requirements and criteria that Delta-DOR operations processes should be designed to meet.

ISO 17810:2014 defines CDMA spread spectrum modulation schemes in terms of: a) the services provided to the users of this specification; b) spreading code formats; and c) the procedures performed to generate and process the code formats. It does not specify: a) individual implementations or products; b) the methods or technologies required to perform the procedures; or c) the management activities required to configure and control the system. ISO 17810:2014 provides only those parameter requirements relating to signal compatibility with the existing SNIP PN spread modulation systems (see C.1). There are many other types of requirements, not specifically related to PN spread modulation signal formats, which must be met to ensure system compatibility with existing SNIP hardware. Examples would include forward error correction coding format, data signal formats, etc. ISO 17810:2014 applies to the creation of agency standards and to the future data communications over space links between CCSDS agencies in cross-support situations. ISO 17810:2014 includes comprehensive specification of the data formats and procedures for inter-agency cross support. It is neither a specification of, nor a design for, real systems that may be implemented for existing or future missions. ISO 17810:2014 is to be invoked through the normal standards programs of each CCSDS agency, and is applicable to those missions for which cross support based on capabilities described in ISO 17810:2014 is anticipated. Where mandatory capabilities are clearly indicated in sections of ISO 17810:2014, they must be implemented when this document is used as a basis for cross support. Where options are allowed or implied, implementation of these options is subject to specific bilateral cross-support agreements between the agencies involved.

ISO 17808:2014 presents recommendations regarding the usage of coding schemes described in references [1]-[2] in the various mission profiles that are encountered in space research, space operations, and Earth exploration. Within this document, it is assumed that at the sending end the Synchronization and Channel Coding sublayer accepts at a constant rate transfer frames of fixed length from the Data Link protocol sublayer; performs the encoding and synchronization functions selected for the mission; and delivers a continuous and contiguous stream of channel symbols to the Physical layer. At the receiving end, the Synchronization and Channel Coding sublayer: accepts a continuous and contiguous stream of channel symbols from the Physical layer; performs the synchronization and decoding functions selected for the mission; delivers transfer frames to the Data Link protocol sublayer. Profiles for Earth-to-space and Proximity links are out of scope and are not addressed in this document. Communication profiles for space-to-Earth links that are currently not supported by CCSDS, e.g. via data relay satellites, are not addressed in this document.

ISO 19389:2014 specifies a standard message format for use in exchanging spacecraft conjunction information between originators of Conjunction Assessments (CAs) and satellite owner/operators and other authorized parties. Such exchanges are used to inform satellite owner/operators of conjunctions between objects in space to enable consistent warning by different organizations employing diverse CA techniques. ISO 19389:2014 will: facilitate interoperability and enable consistent warning between data originators who supply CA and the satellite owner/operators who use it; facilitate automation for the CA processes; and provide critical information to enable timely CA decisions. This document includes requirements and criteria that the message format has been designed to meet (see Annex D). Also included are informative descriptions of conjunction information pertinent to performing CA (see Annex E). ISO 19389:2014 is applicable to satellite operations in all environments in which close approaches and collisions among satellites are concerns. It contains the specification for a Conjunction Data Message (CDM) designed for applications involving conjunction information interchange between originators of CAs and recipients. Conjunction information includes data types such as miss distance, probability of collision, Time of Closest Approach (TCA), and closest approach relative position and velocity. Further information describing the conjunction information contained in this message can be found in section 3 and Annex E. This message is suited for exchanges that involve manual or automated interaction. The attributes of a CDM make it suitable for use in machine-to-machine interfaces because of the large amount of data typically present. The CDM is self contained. However, additional information could be specified in an Interface Control Document (ICD) written jointly by the service originator and recipients. It is desirable that CDM originators maintain consistency with respect to the optional keywords provided in their implementations; i.e., it is desirable that the composition of the CDMs provided not change on a frequent basis. ISO 19389:2014 is applicable only to the message format and content, but not to its transmission nor to the algorithms used to produce the data within. The method of transmitting the message between exchange partners is beyond the scope of this document and could be specified in an ICD. The methods used to predict conjunctions and calculate the probability of collision, and the definition of the conjunction assessment accuracy underlying a particular CDM, are also outside the scope of ISO 19389:2014 (the interested reader can consult references in Annex F).

ISO 18427:2013 is one of a family of documents specifying the SOIS-compliant services to be provided by onboard subnetworks. ISO 18427:2013 defines services and service interfaces provided by the SOIS Subnetwork Synchronisation Service. Its scope is to specify the service only and not to specify methods of providing the service over a variety of onboard data links. ISO 18427:2013 conforms to the principles set out in the Spacecraft Onboard Interface Services Green Book and is intended to be applied together with it. The protocols which provide this service are to be documented for individual links, and this can be in the purview of individual missions, agencies, or CCSDS, depending on future circumstances.