Space engineering
Adoption Notice of CCSDS 231.0-B-4, TC Synchronization and Channel Coding
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 NetherlandsCopyright: 2023© by the European Space Agency for the members of ECSS## Change log
|
ECSS-E-AS-50-24C
|
First issue
|
|
ECSS-E-AS-50-24C Rev.1
|
First issue, Revision 1
|
Scope
This document identifies the clauses and requirements modified with respect to the standard CCSDS 231.0-B-4, TC Synchronization and Channel Coding, Issue 4, July 2021 for application in ECSS.
Context information
In the standard CCSDS 231.0-B-4, TC Synchronization and Channel Coding, CCSDS specifies synchronization and channel coding schemes, and the Physical Layer Operations Procedures, for use with CCSDS 231.0-B-4, TC Space Data Link Protocol, adopted by ECSS with ECSS-E-AS-50-25C.
With this Adoption Notice ECSS is adopting and applying CCSDS 231.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.
CCSDS 231.0-B-4 is similar to clauses 8 (Synchronization and coding sublayer) and 9 (Physical layer) of 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-AS-50-25 and ECSS-E-AS-50-26 (latest versions).
Differences between this Adoption Notice 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.
Mapping of superseded ECSS-E-50-xx Standards w.r.t. ECSS Adoption Notice versus CCSDS Standards.
|
Superseded ECSS
|
ECSS Adopted Notice
|
Based on CCSDS
|
|
ECSS-E-ST-50-01C
|
ECSS-E-AS-50-21
|
CCSDS 131.0-B-x
|
|
ECSS-E-ST-50-03C
|
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
|
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
|
|
BCH
|
Bose-Chaudhuri-Hocquenghem
|
|
CLTU
|
Communications Link Transmission Unit
|
|
LDPC
|
Low-density Parity-check
|
|
PLOP
|
Physical Layer Operations Procedure
|
|
SEC
|
Single Error Correction
|
|
USLP
|
Unified Space Data Link Protocol
|
Application requirements
ECSS-E-AS-50-24_1550001CCSDS 231.0-B-4, TC Synchronization and Channel Coding, Issue 4, July 2021 shall apply with the following modifications listed in Table 41.
ECSS-E-AS-50-24_1550002Table 41: Applicability table for CCSDS 231.0-B-4
|
Clause or requirement number
|
Applicability
|
Applicable text for ECSS
|
Comments
|
Text as in the original CCSDS document
|
|
Note 2 to Transfer Frame definition in 1.6.1.3
|
Modified
|
The service data unit of the Coding & Synchronization sublayer consists of one TC Transfer Frame or a single USLP Transfer Frame.
|
CCSDS requirement modified: only one TC Transfer Frame in a CLTU
|
The service data unit of the Coding & Synchronization sublayer consists of either one or more TC Transfer Frames or a single USLP Transfer Frame.
|
|
2.2.2
|
Modified (statement in informative section)
|
The modified BCH code specified in this Recommended Standard is decoded in an error-correcting mode.
|
CCSDS informative section modified:
|
The modified BCH code specified in this Recommended Standard may be decoded either in an error-detecting mode or in an error-correcting mode, depending on mission requirements.
|
|
2.2.2
|
Modified (statement in informative section)
|
The Frame Error Control Field (FECF) defined in reference [1] or [6] is used to reduce the probability of undetected errors.
|
CCSDS informative section modified:
|
The Frame Error Control Field (FECF) defined in reference [1] or [6] may be used to reduce the probability of undetected errors, particularly when the modified BCH code is decoded in an error-correcting mode.
|
|
2.2.4
|
Modified (statement in informative section)
|
This Recommended Standard specifies a randomizer to improve bit transition density as an aid to bit synchronization.
|
Randomization is not optional both for BCH and for LDPC. Word “optional” deleted.
|
This Recommended Standard specifies an optional randomizer to improve bit transition density as an aid to bit synchronization.
|
|
3.4.3
|
Modified
|
The fill data mentioned above shall be added either before or after randomization.
|
Randomization is not optional both for BCH and for LDPC. Words “if randomization is used” deleted.
|
If randomization is used, the fill data mentioned above shall be added either before or after randomization.
|
|
3.5
|
Modified
|
Codewords that have been encoded using the modified BCH code described in 3.3 shall be decoded in an error correcting mode (Single Error Correction, or SEC). In error-correcting mode, the code can correct one bit in error and can detect two bits in error.
|
CCSDS requirement modified: SEC decoding not optional for BCH;
|
Codewords that have been encoded using the modified BCH code described in 3.3 may be decoded either in an error-detecting mode (Triple Error Detection, or TED) or in an error correcting mode (Single Error Correction, or SEC), depending on mission requirements. When the error-detecting mode is chosen, one, two or three bits in error will be detected within the codeword (not counting the appended Filler Bit); when the error-correcting mode is chosen, one bit in error will be corrected and two bits in error will be detected.
|
|
Note 2 in section 5.2.3
|
Modified
|
The Transfer Frames contained in the Encoded Data field are randomized either if BCH or LDPC coding is used.
|
Randomization not optional both for BCH and for LDPC.
|
The Transfer Frames contained in the Encoded Data field are randomized if LDPC coding is used; randomization is optional with BCH coding.
|
|
Table 5-1, in row S3 for State Definition bullet 1
|
Modified
|
Codewords, which are either free of error or which can be corrected, are received, decoded, and derandomized, and their contents are transferred to the sublayer above
|
CCSDS text in Table 5-1 modified:
|
Codewords, which are either free of error or
|
|
Note 1 below Table 5-2
|
Modified
|
When BCH code is used, the search for the Start Sequence in State 2 accepts a Start Sequence containing one error.
|
CCSDS NOTE modified: SEC decoding not optional for BCH. Word “in” deleted and replaced by words “when BCH code is used”. Words “no error in the Start Sequence is allowed if the modified BCH code is decoded in the error-detecting mode; one error in the Start Sequence is allowed if the modified BCH code is decoded in the error-correcting mode” deleted and replaced by words ” accepts a Start Sequence containing one error”
|
In the search for the Start Sequence in State 2, no error in the Start Sequence is allowed if the modified BCH code is decoded in the error-detecting mode; one error in the Start Sequence is allowed if the modified BCH code is decoded in the error-correcting mode.
|
|
6.1
|
Modified (statement in informative section)
|
Randomization is always applied either when BCH or LDPC coding is used.
|
CCSDS text modified randomization not optional for both BCH and LDPC.
|
When BCH coding is used, the Pseudo-Randomizer defined in this section is required unless the system designer verifies proper operation of the system if this Randomizer is not used.
|
|
Note 2 in 6.3.1
|
Deleted
|
|
Randomization not optional for BCH
|
Randomization for BCH coding is optional and managed per table 8-2.
|
|
7.2.2
|
Modified
|
The Acquisition Sequence is a data structure forming a preamble which provides for initial symbol synchronization within the incoming stream of detected symbols. The length of the Acquisition Sequence shall be selected according to the communications link performance requirements of the mission. The minimum length shall be 16 octets. The length is not required to be an integral multiple of octets. The pattern of the Acquisition Sequence shall be alternating ‘ones’ and ‘zeros’, starting with either a ‘one’ or a ‘zero’.
|
CCSDS requirement modified. Words “but”, “preferred” and “is” deleted and replaced by word “shall”
|
The Acquisition Sequence is a data structure forming a preamble which provides for initial symbol synchronization within the incoming stream of detected symbols. The length of the Acquisition Sequence shall be selected according to the communications link performance requirements of the mission, but the preferred minimum length is 16 octets. The length is not required to be an integral multiple of octets. The pattern of the Acquisition Sequence shall be alternating ‘ones’ and ‘zeros’, starting with either a ‘one’ or a ‘zero’.
|
|
7.2.4
|
Modified
|
The Idle Sequence is the data structure which provides for maintenance of symbol synchronization in the absence of CLTUs. The bit pattern is a sequence of alternating ‘ones’ and ‘zeros’. The length of the Idle Sequence shall be at least 8 bits. The maximum length of the Idle Sequence is an unconstrained number of bits.
|
CCSDS requirement modified to include minimum length of Idle Sequence . The sentence “The length of the Idle Sequence shall be at least 8 bits” added. The word “maximum” added.
|
The Idle Sequence is the data structure which provides for maintenance of symbol synchronization in the absence of CLTUs. The bit pattern is a sequence of alternating ‘ones’ and ‘zeros’. The length of the Idle Sequence is an unconstrained number of bits.
|
|
7.5.2
|
Modified
|
When operating with PLOP-2, a minimum Idle Sequence of one octet shall be systematically inserted between each CLTU to eliminate the small but finite possibility of synchronization lockout. Such a lockout may occur if the start pattern of one CLTU is not detected (leaving the receiver in SEARCH state) and a start pattern exists over the last bits of the last BCH codeword of that CLTU and the first bits of its Tail Sequence. This creates an erroneous but temporary CLTU start (DECODE state), causing the true start of the following CLTU to be missed. The added Idle Sequence prevents this from happening. The CLTU transmission service specified in reference [5] includes a parameter to set the duration of the Idle Sequence following a CLTU.
|
CCSDS requirement modified. Words “should be noted that’’ deleted.
|
It should be noted that when operating with PLOP-2, it is recommended that a minimum Idle Sequence of one octet be systematically inserted between each CLTU to eliminate the small but finite possibility of synchronization lockout. Such a lockout may occur if the start pattern of one CLTU is not detected (leaving the receiver in SEARCH state) and a start pattern exists over the last bits of the last BCH codeword of that CLTU and the first bits of its Tail Sequence. This creates an erroneous but temporary CLTU start (DECODE state), causing the true start of the following CLTU to be missed. The added Idle Sequence prevents this from happening. The CLTU transmission service specified in reference [5] includes a parameter to set the duration of the Idle Sequence following a CLTU.
|
|
Table 8-2, in row Decoding Mode
|
Modified
|
Error-Correcting
|
CCSDS text in Table 8-2 modified: words “Error-Detecting” deleted. SEC decoding not optional
|
Error-Detecting, Error-Correcting
|
|
Table 8-2, in row Allowed Number of Errors in Start Sequence
|
Modified
|
1
|
CCSDS text in Table-8-2 modified: number “0” deleted.
|
0, 1
|
|
Table 8-2, in row Randomizer
|
Modified
|
Used
|
CCSDS text in the Table 8-2 modified: words “not used” deleted, randomization not optional
|
Used, Not used
|
|
A3
|
Modified
|
The parameter Frames is the service data unit of this service and, at the sending end, shall consist of one TC Transfer Frame defined in reference [1] or a single USLP Transfer Frame defined in reference [6]. At the receiving end, however, the parameter Frames may contain an incomplete Frame or additional fill data, which are discarded by the applicable Space Data Link Protocol.
|
CCSDS requirement modified: only one frame in a CLTU
|
The parameter Frames is the service data unit of this service and, at the sending end, shall consist of one or more TC Transfer Frames defined in reference [1] or a single USLP Transfer Frame defined in reference [6]. At the receiving end, however, the parameter Frames may contain an incomplete Frame or additional fill data, which are discarded by the applicable Space Data Link Protocol.
|
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 231.0-B-4 and related parts of the ECSS standard 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
Coding methods
Section 4 of CCSDS 231.0-B-4 has a normative specification of Low-Density Parity-Check (LDPC) coding such that the Recommended Standard specifies two error-control coding methods: one uses a modified BCH code while the other uses LDPC codes. ECSS-E-ST-50-04 did not include any LDPC codes.
Managed parameters
Section 8 of CCSDS 231.0-B-4 has a normative specification of the managed parameters used by synchronization and channel coding including also managed parameters for LDPC codes. Annex E of ECSS-E-ST-50-04 had an informative specification, and referred to the parameters as mission configuration parameters and did not mention LDPC codes.
Specification of service interfaces
Annex A of CCSDS 231.0-B-4 provides a formal abstract specification of the service interfaces, including service primitives and parameters, provided by TC Synchronization and Channel Coding. There was no equivalent in ECSS-E-ST-50-04.
Addition of optional Repetitions parameter
Annex A of CCSDS 231.0-B-4 includes the optional Repetitions parameter, to specify the number of times the CLTU is transferred. ECSS-E-ST-50-04 did not include this option.
Application profiles
Annex D of ECSS-E-ST-50-04 provided information on performance issues for the frame rejection rate and the frame undetected error rate. There is no equivalent in CCSDS 231.0-B-4 but the CCSDS informational report, CCSDS 230.1-G-3, provides similar performance data.
USLP Transfer Frame
CSDS 231.0-B-4 has normative specifications that support two Space Data Link Protocols: the TC Space Data Link Protocol and the Unified Space Data Link Protocol. ECSS-E-ST-50-04 did not include the latter option.
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 732.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
|
Space engineering - Space data links - Telemetry synchronization and channel coding
|
|
ECSS-E-ST-50-03C
|
Space engineering - Space data links - Telemetry transfer frame protocol
|
|
ECSS-E-ST-50-04C
|
Space engineering - Space data links - Telecommand protocols synchronization and channel coding
|
|
CCSDS 230.1-G-3
|
TC Synchronization and Channel Coding - Summary of Concept and Rationale – Green Book, Issue 3, October 2021
|