Skip to main content

Image

Space engineering

Foreword

This Adoption Notice is one document of the series of ECSS Standards intended to be applied together for the management, engineering, product assurance and sustainability in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Adoption Notice has been prepared by the ECSS Space Communications Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this document, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Section    ESTEC, P.O. Box 299,    2200 AG Noordwijk    The Copyright:     2023© by the European Space Agency for the members of ECSS## Change log

ECSS-E-AS-50-25C


1 March 2021


 First issue


NOTE:    This document, together with ECSS-E-AS-50-24C and ECSSEAS-50-26C, replace ECSS-E-ST-50-04C.


ECSS-E-AS-50-25C Rev.1


13 January 2023


 First issue, Revision 1


Changes with respect to ECSS-E-AS-50-25C (1 March 2021) are:


Update of the ECSS Adoption Notice with respect to the new version of CCSDS Standard. This version:


adds corrections and clarifications;


adds a protocol implementation conformance statement proforma as new normative Annex A.


Scope

This document identifies the clauses and requirements modified with respect to the standard CCSDS 232.0-B-4TC Space Data Link Protocol, Issue 4, October 2021 for application in ECSS.

Context information

In the standard CCSDS 232.0-B-4, TC Space Data Link Protocol, CCSDS specifies a data link layer protocol for the efficient transfer of space application data of various types and characteristics over ground-to-space links.

With this Adoption Notice ECSS is adopting and applying CCSDS 232.0-B-4 with a minimum set of modifications, identified in the present document, to allow for reference and for a consistent integration in the ECSS system of standards.

The TC Transfer Frame specified in CCSDS 232.0-B-4 is similar to the TC Transfer Frame specified in clauses 5 (Segmentation sublayer) and 6 (Transfer sublayer) in the ECSS-E-ST-50-04 Space data links – Telecommand protocols synchronization and channel coding (31 July 2008), that is superseded by this Adoption Notice together with the following two Adoption Notices: ECSS-E-ST-50-24, and ECSS-E-AS-50-26 (latest versions).

Differences between this Adoption Note and the relevant part of ECSS-E-ST-50-04 that are not covered by the normative modifications in clause 4 are described in the informative Annex A.

Overview of superseded ECSS-E-50-xx Standards

Superseded ECSS


ECSS Adopted Notice


Based on CCSDS


ECSS-E-ST-50-01C


31 July 2008


 ECSS-E-AS-50-21


CCSDS 131.0-B-x


ECSS-E-ST-50-03C


31 July 2008


 ECSS-E-AS-50-22


CCSDS 132.0-B-x


ECSS-E-AS-50-23


CCSDS 732.0-B-x


ECSS-E-ST-50-04C


31 July 2008


 ECSS-E-AS-50-24


CCSDS 231.0-B-x


ECSS-E-AS-50-25


CCSDS 232.0-B-x


ECSS-E-AS-50-26


CCSDS 232.1-B-x


NOTE:    The applicable CCSDS Standard referred to by the ECSS Adoption Notice is stated per latest version of the ECSS Adoption Notice.


Abbreviated terms

Abbreviation


Meaning


COP


Communications Operation Procedure


FARM


Frame Acceptance and Reporting Mechanism


FDU


Frame Data Unit


GVCID


Global Virtual Channel Identifier


SDLS


Space Data Link Security


Application requirements

ECSS-E-AS-50-25_1560001CCSDS 232.0-B-4, TC Space Data Link Protocol, Issue 4, October 2021 shall apply with the following modifications listed in Table 41.
ECSS-E-AS-50-25_1560002Table 41: Applicability table for CCSDS 232.0-B-4

Clause or requirement number


Applicability


Applicable text for ECSS


(the new/added text is underlined)


 Comments


Text as in the original CCSDS document


(deleted text with strikethrough)


4.1.1b


Modified


Transfer Frame Data Field (up to 1017 octets, mandatory);


CCSDS requirement modified:


number “1019” deleted


 Transfer Frame Data Field (up to 1019 or 1017 octets, mandatory);


4.1.1c


Modified


Frame Error Control Field (2 octets, mandatory).


CCSDS requirement modified: word “optional” replaced by the word “mandatory.”


Frame Error Control Field (2 octets, optional).


4.1.3.2.1.4


Modified


(renumbered NOTE)


 NOTE 1


CCSDS existing NOTE is given a new number – the content of the note is unchanged


NOTE


4.1.3.2.1.4


Modified


(new NOTE)


 NOTE 2 – If the Packet Assembly Controller Function specified in 4.4.9 is used, there can be Frame Data Units that carry a MAP Reset command. In this case, the Frame Data Unit consists of a Segment Header only and the User Data field is absent. See 4.4.9.4.


New NOTE is added



4.1.4.1.1


Modified


(deleted requirement)
Requirement deleted


The Frame Error Control Field is optional; its presence or absence shall be established by management.


4.1.4.1.2


Modified


The Frame Error Control Field shall occupy the two octets following, without gap, the Transfer Frame Data Field.


CCSDS requirement modified: words “if present” deleted.


If present, the Frame Error Control Field shall occupy the two octets following, without gap, the Transfer Frame Data Field.


4.1.4.1.3


Modified


(deleted requirement)
Requirement deleted


If present, the Frame Error Control Field shall occur within every Transfer Frame transmitted within the same Physical Channel throughout a Mission Phase.


Note 2, below 4.1.4.1.3


Modified


(deleted NOTE)
NOTE deleted


Whether this field should be used on a particular Physical Channel will be determined based on the mission requirements for data quality and the selected options for the underlying Channel Coding Sublayer.


Note 1 in 4.2.1.8.3.1


Modified


(modified NOTE)


 The No Bit Lock Flag provides a performance quality indicator that indicates specifically whether the Physical Layer is working normally by having enough signal energy to achieve bit synchronization with the received data stream.


CCSDS requirement modified: words “mission specific engineering measurement that” deleted.


The No Bit Lock Flag is an optional, mission-specific engineering measurement that provides a performance quality indicator that indicates specifically whether the Physical Layer is working normally by having enough signal energy to achieve bit synchronization with the received data stream.


4.2.1.8.3.2


Modified


The No Bit Lock Flag shall be set as follows:‘0’ when at least one of the spacecraft demodulation units for the physical channel has achieved bit lock;‘1’ when none of the spacecraft demodulation units for the physical channel has achieved bit lock.


CCSDS requirement modified to refer to spacecraft demodulation units for the physical channel. Sentences “Use of the No Bit Lock Flag is optional; if used,a) ‘0’ shall indicate bit lock has been achieved;b) ‘1’ shall indicate bit lock has not been achieved.”deleted.


Use of the No Bit Lock Flag is optional; if used,a) ‘0’ shall indicate bit lock has been achieved;b) ‘1’ shall indicate bit lock has not been achieved.


4.2.1.8.3.3


Modified


The No Bit Lock Flag shall always carry an actual report of the status of the physical channel, even when other fields in the CLCW report the status of an inactive virtual channel.


CCSDS requirement modified to refer to actual report of the status of the physical channel. Sentence “The single No Bit Lock Flag shall apply to all Virtual Channels and shall be updated whenever a change is signaled by the Physical Layer”. deleted.


The single No Bit Lock Flag shall apply to all Virtual Channels and shall be updated whenever a change is signaled by the Physical Layer.


4.2.1.8.3.4


Modified


(deleted requirement)
Requirement deleted


If the No Bit Lock Flag is not used, it shall be set permanently to ‘0’.


4.4.1.6 (new)


New requirement


When extracting and reconstructing Packets from Frame Data Units, the Packet Assembly Controller Function specified in 4.4.9 may be used.


New requirement added:


added the Packet Assembly Controller
4.4.2.5 (new)


New requirement


When extracting and reconstructing MAP_SDUs from Frame Data Units, the Packet Assembly Controller Function specified in 4.4.9 may be used.


New requirement added:


added the Packet Assembly Controller
4.4.9


New section


Packet Assembly Controller Function


New section with new requirements added (4.4.9)



4.4.9.1


New


Overview


The Packet Assembly Controller Function can be used by the MAP Packet Extraction Function to reassemble Packets and by the MAP Reception Function to reassemble MAP_SDUs.


The Packet Assembly Controller Function includes the handling of exceptions. When the function detects an exception it enters a lockout state. In the lockout state, it does not reassemble or deliver Packets or MAP_SDUs. When it receives a valid MAP Reset command, the Packet Assembly Controller Function exits lockout state.


Despite the word “packet” in its name, the function can be used for Packets and for MAP_SDUs: the name is inherited from earlier standards.


 New



4.4.9.2


New


MAP Identifiers for the Packet Assembly Controller Function




4.4.9.2.1


New requirement


Each instance of the Packet Assembly Controller Function shall use a pair of MAP Identifiers with the following properties:


a) The pair of MAP Identifiers identifies one MAP for data and one MAP for control.


b) The MAP Identifier for the data MAP has the most significant bit set to ‘0’.


c) The MAP Identifier for the control MAP has the same value as the data MAP except that the most significant bit is set to ‘1’.


NOTE    The MAP Identifier is a 6-bit value. Therefore, the data MAP has an identifier in the range 0 to 31 and the control MAP has an identifier in the range 32 to 63. So, control MAP Identifier = data MAP Identifier + 32, and the least significant 5 bits of the two MAP Identifiers are the same.

4.4.9.2.2


New requirement


The MAP Identifier in the Segment Header of a frame carrying Packet or MAP_SDU data shall be set to the MAP Identifier of the data MAP.




4.4.9.2.3


New requirement


The MAP Identifier in the Segment Header of a frame carrying a control segment shall be set to the MAP Identifier of the control MAP.


NOTE    A control segment can contain a MAP Reset command: see 4.4.9.4.

4.4.9.3


New


Behaviour of the Packet Assembly Controller Function




4.4.9.3.1


New requirement


For frames with the MAP Identifier of the data MAP, the Packet Assembly Controller Function shall reconstruct the Packets or MAP_SDUs from the Frame Data Units, using the Sequence Flags of the Segment Header of each Frame Data Unit.




4.4.9.3.2


New requirement


The Packet Assembly Controller Function shall have a reassembly status flag set as follows:


a) ‘0’ when the Packet Assembly Controller Function has completed reconstruction of a Packet or MAP_SDU;


b) ‘1’ when reconstruction of a Packet or MAP_SDU is in progress in the Packet Assembly Controller Function.

4.4.9.3.3


New requirement


The Packet Assembly Controller Function shall enter a lockout state when it detects one of the following errors:


a) an incorrect sequence of Frame Data Units, as indicated by the Sequence Flags;


b) a control segment with an invalid format.


NOTE - The following is a list of the incorrect sequences of Sequence Flags that cause the Packet Assembly Controller Function to enter lockout state. The values for the Sequence Flags are shown in parentheses:


a first segment (‘01’) followed by a first segment (‘01’);
a first segment (‘01’) followed by a no segmentation (‘11’);
a continuing segment (‘00’) followed by a first segment (‘01’);
a continuing segment (‘00’) followed by a no segmentation (‘11’);
a last segment (‘10’) followed by a continuing segment (‘00’);
a last segment (‘10’) followed by a last segment (‘10’);
a no segmentation (‘11’) followed by a continuing segment (‘00’;
a no segmentation (‘11’) followed by a last segment (‘10’).

4.4.9.3.4


New requirement


The Packet Assembly Controller Function shall have a lockout status flag set as follows:


a) ‘1’ when the Packet Assembly Controller Function is in a lockout state;


b) ‘0’ when the Packet Assembly Controller Function is not in a lockout state.

4.4.9.3.5


New requirement


When the Packet Assembly Controller Function is in a lockout state, it shall not reconstruct Packets or MAP_SDUs.




4.4.9.3.6


New requirement


When the Packet Assembly Controller Function is in a lockout state, it shall remain in that state until it receives a MAP Reset command as specified in 4.4.9.4.




4.4.9.3.7


New requirement


The Packet Assembly Controller Function shall report its status to the sending end, including the following:


a) the MAP Identifier of the data MAP, and


b) the reassembly status flag, and


c) the lockout status flag.


NOTE - The correct operation of the Packet Assembly Controller Function relies on its status being known by the sending end. This Standard does not specify the format of the status information nor the mechanism to be used to transport it from the Packet Assembly Controller Function to the appropriate entity at the sending end. It also does not specify any resulting behaviour at the sending end, such as the decision to send a control segment containing a MAP Reset command.

4.4.9.3.8


New requirement


When the Packet Assembly Controller Function receives a MAP Reset command and the reassembly status flag is ‘1’, the function shall:


a) discard the partially reconstructed Packet or MAP_SDU, and


b) set the reassembly status flag to ‘0’.

4.4.9.3.9


New requirement


When the Packet Assembly Controller Function receives a MAP reset command and the function is in lockout state, the function shall exit lockout state.


NOTE    The MAP Reset command is used, for example, to recover from breaks in the sequence of received frames due to link difficulties or unplanned termination of transfer services.

4.4.9.4


New


Control segment and MAP Reset command




4.4.9.4.1


New requirement


A control segment shall have a length of one octet.




4.4.9.4.2


New requirement


The Sequence Flags in the Segment Header of a control segment shall be set to ‘11’.




4.4.9.4.3


New requirement


The MAP Identifier in the Segment Header of a control segment shall contain the MAP Identifier of a control MAP.




4.4.9.4.4


New requirement


A valid control segment shall be considered to be a MAP Reset command.


NOTE 1:    A control segment is a special case of a Frame Data Unit. It has no User Data field and therefore consists of a Segment Header only.


NOTE 2:    If a Frame Data Unit has the MAP Identifier of a control MAP but it does not conform to these rules then it is considered to be an invalid control segment.

Table 5-1, in row Presence of Frame Error Control


Modified


(Text in a Table 5-1)


 Present


CCSDS text in Table 5-1 modified: word “absent” deleted.


Present, Absent


Table 5-4, in row Maximum Frame Data Unit Length


Modified


(Text in a Table 5-1)


 Integer (up to 1017)


CCSDS text in Table 5-1 modified: number “1019” changed into number“1017”.


Integer (up to 1019)


6.3.7


Modified



In a Transfer Frame with SDLS, the Frame Error Control Field shall occupy the two octets following, without gap, the Security Trailer if the Security Trailer is present, or the Transfer Frame Data Field if a Security Trailer is not present.


The Frame Error Control Field of a frame with SDLS shall conform to the specifications of 4.1.4.2 and 4.1.4.3.


 CCSDS requirement modified: words “if present” deleted; references to the sections 4.1.4.1.1, 4.1.4.1.3 deleted.


In a Transfer Frame with SDLS, the Frame Error Control Field, if present, shall occupy the two octets following, without gap, the Security Trailer if the Security Trailer is present, or the Transfer Frame Data Field if a Security Trailer is not present.


The Frame Error Control Field of a frame with SDLS shall conform to the specifications of 4.1.4.1.1, 4.1.4.1.3, 4.1.4.2, and 4.1.4.3.


ANNEX(informative)Differences from ECSS-E-ST-50-04C

General

Clause 4 of this document contains normative additions and modifications concerning some of the differences between CCSDS 232.0-B-4 and ECSS-E-ST-50-04 (superseded by this Adoption Notice). This Annex describes some additional differences that are not covered by Clause 4.

This Annex lists the differences of technical content, but it is not the purpose of this Annex to provide complete details on each item in the list or to describe the consequences of each item in the list.

Differences

Specification of service interfaces

Section 3 of CCSDS 232.0-B-4 provides a formal abstract specification of a set of service interfaces, including service primitives and parameters, provided by the TC Space Data Link Protocol. There was no equivalent in ECSS-E-ST-50-04.

CCSDS 232.0-B-4 specifies the optional interfaces for using the Space Data Link Security (SDLS) protocol with TC Transfer Frames. ECSS-E-ST-50-04 did not include support for interfacing to SDLS. Therefore, this Adoption Notice – unlike the ECSS-E-ST-50-04C - offers to ECSS users the option of using the Space Data Link Security (SDLS) protocol with TC Transfer Frames.

Managed parameters

Sections 5 and 6.6 of CCSDS 232.0-B-4 have a normative specification of the managed parameters used by the TC Space Data Link Protocol. Annex E of ECSS-E-ST-50-04 had an informative specification, and referred to the parameters as mission configuration parameters.

Protocol Implementation Conformance Statement

Annex A of CCSDS 232.0-B-4 has a normative specification of the Protocol Implementation Conformance Statement (PICS) Requirements List (RL) for an implementation fulfilling the standard. Instructions for PICS generation are given. ECSS-E-ST-50-04 did not include a PICS.

Bibliography

ECSS-E-AS-50-21C Rev.1


Space engineering - Adoption Notice of CCSDS 131.0-B-4, TM Synchronization and Channel Coding


ECSS-E-AS-50-22C Rev.1


Space engineering - Adoption Notice of CCSDS 132.0-B-3, TM Space Data Link Protocol


ECSS-E-AS-50-23C Rev.1


Space engineering -Adoption Notice of CCSDS 232.0-B-4, AOS Space Data Link Protocol


ECSS-E-AS-50-24C Rev.1


Space engineering - Adoption Notice of CCSDS 231.0-B-4, TC Synchronization and Channel Coding


ECSS-E-AS-50-25C Rev.1


Space engineering - Adoption Notice of CCSDS 232.0-B-4, TC Space Data Link Protocol


ECSS-E-AS-50-26C


Space engineering - Adoption Notice of CCSDS 232.1-B-2, Communications Operation Procedure-1


ECSS-E-ST-50-01C


31 July 2008


 Space engineering - Space data links - Telemetry synchronization and channel coding


ECSS-E-ST-50-03C


31 July 2008


 Space engineering - Space data links - Telemetry transfer frame protocol


ECSS-E-ST-50-04C


31 July 2008


 Space engineering - Space data links - Telecommand protocols synchronization and channel coding