Space engineering. Space data links - Telemetry synchronization and channel coding. ECSS-E-ST-50-01C 31 July 2008

Transcription

1 ECSS-E-ST-50-01C Space engineering Space data links - Telemetry synchronization and channel coding ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands

2 Foreword This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance 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 Standard has been prepared by the 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 Standard, 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: Copyright: ESA Requirements and Standards Division ESTEC, P.O. Box 299, 2200 AG Noordwijk The Netherlands 2008 by the European Space Agency for the members of ECSS 2

3 Change log ECSS E 50 01A 6 November 2007 ECSS E 50 01B First issue Never issued Second issue consistency with CCSDS and other ECSS standards 3

4 Table of contents Change log Scope Normative references Terms, definitions and abbreviated terms Terms from other standards Terms specific to the present standard Abbreviations Conventions Overview Introduction Coding Channel codes Connection vectors Convolutional codes Reed-Solomon codes Concatenated codes Turbo codes Synchronization and pseudo-randomization Convolutional coding Properties General Basic convolutional code Punctured convolutional code Reed-Solomon coding Properties General Specification Parameters and general characteristics

5 6.3.2 Generator polynomials Symbol interleaving depth Symbol interleaving mechanism Reed-Solomon codeblock partitioning Shortened codeblock length Dual basis symbol representation and ordering Synchronization Ambiguity resolution Reed-Solomon with E= Introduction General Turbo coding Properties General Specification General Parameters and general characteristics Turbo code permutation Backward and forward connection vectors Turbo encoder block Turbo codeblock specification Turbo codeblock synchronization Frame synchronization Introduction The attached sync marker (ASM) Overview Encoder side Decoder side ASM bit patterns Location of ASM Relationship of ASM to Reed-Solomon and turbo codeblocks ASM for embedded data stream Overview Embedded ASM Pseudo-randomizer General

6 9.1.1 Overview Application Pseudo-randomizer description Synchronization and application of pseudo-randomizer Overview Application Sequence specification...42 Annex A (informative) Transformation between Berlekamp and conventional representations...44 Annex B (informative) Expansion of Reed-Solomon coefficients...52 Annex C (informative) Compatible frame lengths...54 Annex D (informative) Application profiles...56 Annex E (informative) Changes from ESA-PSS Annex F (informative) Differences from CCSDS recommendations...63 Annex G (informative) Mission configuration parameters...64 Annex H (informative) Turbo code patent rights...68 Bibliography...69 Figures Figure 3-1: Bit numbering convention...11 Figure 4-1: Coding, randomization and synchronization (1)...15 Figure 4-2: Coding, randomization and synchronization (2)...16 Figure 5-1: Convolutional encoder block diagram...19 Figure 5-2: Punctured encoder block diagram...20 Figure 6-1: Functional representation of R-S interleaving...24 Figure 6-2: Reed-Solomon codeblock partitioning...25 Figure 7-1: Interpretation of permutation...32 Figure 7-2: Turbo encoder block diagram...33 Figure 7-3: Turbo codeblocks for code rates 1/2 and 1/ Figure 7-4: Turbo codeblock with attached sync marker...35 Figure 8-1: Format of channel access data unit (CADU)...36 Figure 8-2 ASM bit pattern for non-turbo-coded data...37 Figure 8-3: ASM bit pattern for rate 1/2 turbo-coded data...37 Figure 8-4: ASM bit pattern for rate 1/4 turbo-coded data

7 Figure 8-5: Embedded ASM bit pattern...39 Figure 9-1: Pseudo-randomizer configuration...41 Figure 9-2: Pseudo-randomizer logic diagram...43 Figure A-1 : Transformational equivalence...45 Tables Table 5-1: Basic convolutional code characteristics...18 Table 5-2: Punctured convolutional code characteristics...20 Table 5-3: Puncture code patterns for convolutional codes...20 Table 7-1: Specified information block lengths...31 Table 7-2: Codeblock lengths (measured in bits)...31 Table 7-3: Parameters k 1 and k 2 for specified information block lengths...32 Table 7-4: Forward connection vectors...33 Table 8-1: ASM bit patterns in hexadecimal notation...38 Table A-1 : Equivalence of representations (Part 1 of 4)...48 Table B-1 : Expansion for E= Table B-2 : Expansion for E= Table C-1 : Maximum frame lengths for E= Table C-2 : Maximum frame lengths for E= Table D-1 : Preferred coding schemes...58 Table D-2 : Coding gains and bandwidth expansions...60 Table D-3 : Coding gains for R-S(255, 239) and 4D-8PSK-TCM

8 1 Scope This Standard establishes a common implementation of space telemetry channel coding systems. Several space telemetry channel coding schemes are specified in this Standard. The specification does not attempt to quantify the relative coding gain or the merits of each scheme, nor the design requirements for encoders or decoders. However, some application profiles are discussed in Annex D. Performance data for the coding schemes specified in this Standard can be found in CCSDS G 1. Annex G describes the related mission configuration parameters. Further provisions and guidance on the application of this standard can be found in the following publications: ECSS E ST 50, Communications, which defines the principle characteristics of communication protocols and related services for all communication layers relevant for space communication (physical to application layer), and their basic relationship to each other. The handbook ECSS E HB 50, Communications guidelines, which provides information about specific implementation characteristics of these protocols in order to support the choice of a certain communications profile for the specific requirements of a space mission. Users of this present standard are invited to consult these documents before taking decisions on the implementation of the present one. This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS S ST 00. 8

9 2 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revisions of any of these publications, do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies. ECSS S ST ECSS system Glossary of terms 9

10 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards For the purpose of this Standard, the terms and definitions from ECSS ST apply. 3.2 Terms specific to the present standard category A category of spacecraft having an altitude above the Earth s surface less than km category B category of spacecraft having an altitude above the Earth s surface equal to, or greater than km octet group of eight bits NOTE 1 NOTE 2 The numbering for octets within a data structure starts with 0. Refer to clause 3.4 for the convention for the numbering of bits physical channel stream of bits transferred over a space link in a single direction 3.3 Abbreviations For the purpose of this Standard, the abbreviated terms from ECSS S ST 00 01and the following apply: Abbreviation 8PSK AOS APP Meaning phase shift keying of eight states advanced orbiting systems a posteriori probability 10

11 ASM AWGN BER BPSK CADU CCSDS CRC FER GF(n) GMSK MSB MS/S NRZ L NRZ M QPSK R S TCM attached sync marker additive white Gaussian noise bit error rate binary phase shift keying channel access data unit Consultative Committee for Space Data Systems cyclic redundancy check frame error rate Galois field consisting of exactly n elements Gaussian minimum shift keying most significant bit mega symbols per second non return to zero level non return to zero mark quadrature phase shift keying Reed Solomon trellis coded modulation 3.4 Conventions bit 0, bit 1, bit N 1 To identify each bit in an N bit field, the first bit in the field to be transferred (i.e. the most left justified in a graphical representation) is defined as bit 0; the following bit is defined as bit 1 and so on up to bit N 1. Figure 3 1: Bit numbering convention most significant bit When an N bit field is used to express a binary value (such as a counter), the most significant bit is the first bit of the field, i.e. bit 0 (see Figure 3 1). 11

12 4 Overview 4.1 Introduction Telemetry channel coding is a method of processing data that is sent from a source to a destination so that distinct messages are created that are easily distinguishable from one another and thus enable reconstruction of the data with low error probability, thus improve the performance of the channel. 4.2 Coding Channel codes A channel code is the set of rules that specify the transformation of elements of a source alphabet to elements of a code alphabet. The elements of the source alphabet and of the code alphabet are called symbols. Depending on the code, the symbols can consist of one or more bits. The source symbols are also called information symbols. The code symbols are called channel symbols when they are the output of the last or only code applied during the encoding process. Block encoding is a one to one transformation of sequences of length k source symbols to sequences of length n code symbols. The length of the encoded sequence is greater than the source sequence, so n> k. The ratio k/n is the code rate, which can be defined more generally as the average ratio of the number of binary digits at the input of an encoder to the number of binary digits at its output. A codeword of an (n,k) block code is one of the sequences of n code symbols in the range of the one to one transformation. A codeblock of an (n,k) block code is a sequence of n channel symbols which are produced as a unit by encoding a sequence of k information symbols. The codeblock is decoded as a unit and, if successful, delivers a sequence of k information symbols. A systematic code is one in which the input information sequence appears in unaltered form as part of the output codeword. A transparent code has the property that complementing the input of the encoder or decoder results in complementing the output. 12

13 4.2.2 Connection vectors Convolutional and turbo coding use connection vectors. A forward connection vector is a vector which specifies one of the parity checks computed by the shift register(s) in the encoder. For a shift register with s stages, a connection vector is an s bit binary number. A bit equal to ʺ1ʺ in position i (counted from the left) indicates that the output of the ith stage of the shift register is used in computing that parity check. In turbo coding, a backward connection vector is a vector which specifies the feedback to the shift registers in the encoder. For a shift register with s stages, a backward connection vector is an s bit binary number. A bit equal to ʺ1ʺ in position i (counted from the left) indicates that the output of the ith stage of the shift register is used in computing the feedback value, except for the leftmost bit which is ignored. 4.3 Convolutional codes A convolutional code is a code in which a number of output symbols are produced for each input information bit. Each output symbol is a linear combination of the current input bit as well as some or all of the previous k 1 bits, where k is the constraint length of the code. The constraint length is the number of consecutive input bits that are used to determine the value of the output symbols at any time. The rate 1/2 convolutional code is specified in clause 5. Depending on performance requirements, this code can be used alone. For telecommunication channels that are constrained by bandwidth and cannot accommodate the increase in bandwidth caused by the basic convolutional code, clause 5 also specifies a punctured convolutional code which has the advantage of a smaller bandwidth expansion. A punctured code is a code obtained by deleting some of the parity symbols generated by the convolutional encoder before transmission. There is an increase in the bandwidth efficiency due to puncturing compared to the original code, however the minimum weight (and therefore its error correcting performance) is less than that of the original code. 4.4 Reed-Solomon codes The Reed Solomon (R S) code specified in clause 6 is a powerful burst error correcting code. In addition, the code has the capability of indicating the presence of uncorrectable errors, with an extremely low undetected error rate. The Reed Solomon code has the advantage of smaller bandwidth expansion than the convolutional code. The Reed Solomon symbol is a set of J bits that represents an element in the Galois field GF(2 J ), the code alphabet of a J bit Reed Solomon code. For the code specified in clause 6, J = 8 bits per R S symbol. 13

14 4.5 Concatenated codes Concatenation is the use of two or more codes to process data sequentially, with the output of one encoder used as the input to the next. In a concatenated coding system, the first encoding algorithm that is applied to the data stream is called the outer code. The last encoding algorithm that is applied to the data stream is called the inner code. The data stream that is input to the inner encoder consists of the codewords generated by the outer encoder. To achieve a greater coding gain than the one that can be provided by the convolutional code or Reed Solomon code alone, a concatenation of the convolutional code as the inner code with the Reed Solomon code as the outer code can be used for improved performance. This Standard also specifies the concatenation of the Reed Solomon code with the 4 dimensional 8PSK trellis coded modulation (4D 8PSK TCM) defined in ECSS E ST In this case, the Reed Solomon code with E=8 is the outer code and the 4D 8PSK TCM is the inner code. 4.6 Turbo codes A turbo code is a block code formed by combining two component recursive convolutional codes. A turbo code takes as input a block of information bits. The input block is sent unchanged to the first component code and bit wise interleaved to the second component code. The interleaving process, called the turbo code permutation, is a fixed bit by bit permutation of the entire input block. The output is formed by the parity symbols contributed by each component code plus a replica of the information bits. The turbo codes specified in clause 7 can be used to increase the coding gain in cases where the environment tolerates the bandwidth overhead. 4.7 Synchronization and pseudo-randomization The methods for synchronization specified in clause 8 apply to all telemetry channels, coded or uncoded. An attached sync marker (ASM) is attached to the codeblock or transfer frame. The ASM can also be used for resolution of data ambiguity (sense of 1 and 0 ) if data ambiguity is not resolved by the modulation method used. Successful bit synchronization at the receiving end depends on the incoming signal having a minimum bit transition density. Clause 9 specifies the method of pseudo randomizing the data to improve bit transition density. Figure 4 1 and Figure 4 2 provide an overview of how pseudo randomization and synchronization are combined with the different coding options at the sending and receiving end. 14

15 At the sending end, the order of convolutional encoding and modulation is dependent on the implementation. At the receiving end, the order of demodulation, frame synchronization and convolutional decoding are dependent on the implementation. The figures do not imply any hardware or software configuration in a real system. When designing a communications system, the system designer usually takes into account radio regulations and modulation standardization requirements from other standards, such as ECSS E ST Figure 4 1: Coding, randomization and synchronization (1) 15

16 Figure 4 2: Coding, randomization and synchronization (2) 16

17 5 Convolutional coding 5.1 Properties Convolutional coding is suitable for channels with predominantly Gaussian noise. The basic convolutional code defined in clause 5.3 is a rate 1/2, constraint length 7 transparent code. The basic code can be modified by puncturing, which removes some of the symbols before transmission, thus providing lower overhead and lower bandwidth expansion than the original code, but with reduced error correcting performance. The punctured convolutional codes are defined in clause 5.4 The codes are non systematic. The convolutional decoder is a maximumlikelihood decoder using the Viterbi decoding scheme. Decoding failures are not signalled and produce error bursts. The requirements in clause 5.2 apply to the basic and punctured convolutional codes. The convolutional code, by itself, cannot guarantee sufficient symbol transitions when non binary modulation schemes such as QPSK are used. The pseudorandomizer defined in clause 9 can be used to increase the symbol transition density. If the decoderʹs correction capability is exceeded, undetected burst errors can appear in the output. For this reason, when telemetry transfer frames are used, reference ECSS E ST specifies that a cyclic redundancy check (CRC) field be used to validate the frame unless the Reed Solomon code is used. Similarly, the CRC is used for the AOS transfer frames defined in CCSDS B General a. Soft bit decisions with at least 3 bit quantization shall be used for the decoder. b. The frame synchronization defined in clause 8 shall be used. c. If differential encoding (i.e. conversion from NRZ L to NRZ M) is used at the sending end, the conversions should be as follows: the conversion is performed at the input to the convolutional encoder; 17

18 the corresponding conversion at the receiving end from NRZ M to NRZ L is performed at the output of the convolutional decoder. NOTE 1 NOTE 2 NOTE 3 This prevents avoidable link performance loss. When suppressed carrier modulation systems are used, NRZ M or NRZ L can be used as a modulating waveform. In NRZ M a data ʺ1ʺ is represented by a change in level and a data ʺ0ʺ is represented by no change in level. In NRZ L a data ʺ1ʺ is represented by one of two levels, and a data ʺ0ʺ is represented by the other level. When a fixed pattern (the fixed part of the convolutionally encoded attached sync marker) in the symbol stream is used to provide node synchronization for the Viterbi decoder, the modulating waveform conversion can cause a modification of the pattern. 5.3 Basic convolutional code a. The basic convolutional code shall have the characteristics shown in Table 5 1. NOTE 1 The encoding rule can be represented by the following equations: s1(t) = i(t) + i(t 1) + i(t 2) + i(t 3) + i(t 6) modulo 2 s2(t) = i(t) + i(t 2) + i(t 3) + i(t 5) + i(t 6) + 1 modulo 2 where the equations use modulo 2 addition, and s1 is the first output symbol, s2 is the second output symbol and i(t) is the input information at time t. NOTE 2 An encoder block diagram is shown in Figure 5 1. NOTE 3 The output symbol sequence is: C1(1), C2(1), C1(2), C2(2).... Table 5 1: Basic convolutional code characteristics Characteristic Nomenclature Code rate Constraint length Connection vectors Symbol inversion Value Convolutional code with maximum likelihood (Viterbi) decoding 1/2 bit per symbol 7 bits G1 = (171 octal); G2 = (133 octal) On output path of G2 18

19 Figure 5 1: Convolutional encoder block diagram 5.4 Punctured convolutional code a. The punctured convolutional code shall have the characteristics shown in Table 5 2. NOTE 1 NOTE 2 NOTE 3 A single code rate of 2/3, 3/4, 5/6 or 7/8 is selected when it provides the appropriate level of error correction and symbol rate for a given service or data rate. Figure 5 2 depicts the punctured encoding scheme. The punctured convolutional code does not include the symbol inverter associated with G2 in the rate 1/2 code defined above. b. The puncturing patterns for each of the punctured convolutional code rates shall be the patterns defined in Table

20 Table 5 2: Punctured convolutional code characteristics Characteristic Nomenclature Value Punctured convolutional code with maximumlikelihood (Viterbi) decoding. Code rate 1/2, punctured to 2/3, 3/4, 5/6 or 7/8 Constraint length Connection vectors Symbol inversion 7 bits G1 = (171 octal); G2 = (133 octal) None Figure 5 2: Punctured encoder block diagram Table 5 3: Puncture code patterns for convolutional codes Puncturing pattern (a) Code rate Output sequence (b) C 1 : 1 0 C 2 : 1 1 2/3 C 1 (1) C 2 (1) C 2 (2)... C 1 : C 2 : /4 C 1 (1) C 2 (1) C 2 (2) C 1 (3)... C 1 : C 2 : C 1 : C 2 : /6 7/8 C 1 (1) C 2 (1) C 2 (2) C 1 (3) C 2 (4) C 1 (5)... C 1 (1) C 2 (1) C 2 (2) C 2 (3) C 2 (4) C 1 (5) C 2 (6) C 1 (7)... (a) (b) 1 = transmitted symbol 0 = non transmitted symbol C 1 (t), C 2 (t) denote values at bit time t 20

21 6 Reed-Solomon coding 6.1 Properties The Reed Solomon code defined in this clause provides an excellent forward error correction capability in a burst noise channel with an extremely low undetected error rate. This means that the decoder can reliably indicate whether it can make the proper corrections or not. For this reason, when telemetry transfer frames are used, ECSS E ST does not specify the use of a cyclic redundancy check (CRC) field to validate the frame when this Reed Solomon Code is used. The Reed Solomon error correction and detection presupposes correct frame synchronization. The Reed Solomon frame validation can only deliver a valid frame if the frame is correctly synchronized. If a frame is not correctly synchronized, then the Reed Solomon decoder can perform a meaningless error correction of the frame and deliver it as valid. The reliability of the Reed Solomon error correction and detection depends on the correct operation of the pseudo randomization defined in clause 9. If frames are randomized and then not derandomized, or not randomized and then derandomized, then the Reed Solomon decoder can perform meaningless error correction of a frame and deliver it as valid. In particular, this can happen when the Reed Solomon interleaving depth, I, is 5. The Reed Solomon coding, by itself, cannot guarantee sufficient channel symbol transitions to keep receiver symbol synchronizers in lock. The pseudorandomizer defined in clause 9 can be used to increase the symbol transition density. 6.2 General a. For Reed Solomon coding, the frame synchronization defined in clause 8 shall be used. NOTE The reliability of the Reed Solomon code depends on proper codeblock synchronization b. To provide additional coding gain, the Reed Solomon code may be concatenated with one of the convolutional codes defined in clause 5. 21

22 NOTE Used this way, the Reed Solomon code is the outer code, while the convolutional code is the inner code. Figure 4 2 shows the order of the codes at the sending and receiving ends. 6.3 Specification Parameters and general characteristics The Reed Solomon code shall have the following parameters and general characteristics: J = 8, where J is the number of bits per R S symbol. E = 16, where E is the Reed Solomon error correction capability, in symbols, within an R S codeword. J, E, and I (the depth of interleaving) are independent parameters. n = 2 J 1 = 255, where n is the number of symbols per R S codeword. 2E is the number of parity check symbols in each codeword. Therefore there are 32 parity check R S symbols in each 255 symbol codeword. k = n 2E, where k is the number of information symbols in each codeword. Therefore there are 223 information R S symbols in each 255 symbol codeword. NOTE The specified Reed Solomon code is a systematic code and results in a systematic codeblock Generator polynomials a. The Reed Solomon code shall have the following field generator polynomial over GF(2): F(x) = x 8 + x 7 + x 2 + x + 1 b. The Reed Solomon code shall have the following code generator polynomial over GF(2 8 ), where F(α) = 0: 127+ E g( x) = ( x α 11 j ) = 2E j= 128 E i= 0 G x NOTE 1 α 11 is a primitive element in GF(2 8 ). NOTE 2 For E=16, F(x) and g(x) characterize a (255,223) Reed Solomon code. NOTE 3 Each coefficient of the code generator polynomial can be represented as a power of α or as a binary polynomial in α of degree less than 8, where F(α) = 0 (i.e. α is one of the roots of the field generator polynomial F(x)). The two representations are given in Annex B. i i 22

23 6.3.3 Symbol interleaving depth a. The interleaving depth, I, shall take one of the following values: NOTE 1 NOTE 2 I = 1, 2, 3, 4, 5 or 8. I=1 is equivalent to the absence of interleaving. The maximum codeblock length Lmax, measured in R S symbols, depends on the value of I as follows: Lmax = ni = (2 J 1)I = 255I b. The interleaving depth on a physical channel shall be fixed for a mission phase Symbol interleaving mechanism Symbol interleaving is accomplished as shown functionally in Figure 6 1. The physical implementation of an encoder can differ from this functional description. Data bits to be encoded into a single Reed Solomon codeblock enter at the port labelled ʺINʺ. Switches S1 and S2 are synchronized together and advance from encoder to encoder in the sequence 1,2,, I, 1,2,, I,, spending one R S symbol time (8 bits) in each position. One codeblock is formed from ki R S symbols entering ʺINʺ. In this functional representation, a space of 2EI R S symbols in duration occurs between each entering set of ki R S information symbols. Due to the action of S1, each encoder accepts k of these symbols, each symbol spaced I symbols apart (in the original stream). These k symbols are passed directly to the output of each encoder. The synchronized action of S2 reassembles the symbols at the port labelled ʺOUTʺ in the same way as they entered at ʺINʺ. Following this, each encoder outputs its 2E check symbols, one symbol at a time, as it is sampled in sequence by S2. If, for I=5, the original symbol stream is d 1... d 1 d 2... d 2... d k... d k [2E 5 ] then the output is the same sequence with the [2E 5] filled by the [2E 5] check symbols as shown below: p 1... p 1... p 2E... p 2E where i i i d 1 d 2... d k i i p 1... p 2E is the R S codeword produced by the ith encoder. If q virtual fill symbols (see clause 6.3.6) are used in each codeword, then replace k by (k q) in this functional description. 23

24 With this method of interleaving, the original ki consecutive information symbols that enter the encoder appear unchanged at the output of the encoder with 2EI R S check symbols appended. Figure 6 1: Functional representation of R S interleaving Reed-Solomon codeblock partitioning The R S codeblock is partitioned as shown in Figure 6 2. The attached sync marker used with R S coding is a 32 bit pattern specified in clause 8 as an aid to synchronization. It precedes the transmitted codeblock. Frame synchronizers are therefore set to expect a marker at every transmitted codeblock + 32 bits. The telemetry transfer frame is defined in ECSS E ST When used with R S coding, only specified lengths can be contained within the codeblock s data space. See Annex C for the maximum lengths, not including the 32 bit attached sync marker. The Reed Solomon check symbols consist of the trailing 2EI symbols (2EIJ bits) of the codeblock. For example, when E=16 and I=5, then the length occupied by the check symbols is always 1280 bits. The transmitted codeblock consists of the telemetry transfer frame (without the 32 bit sync marker) and R S check symbols, which is the received data entity physically fed into the R S decoder. For example, when E=16, k=223 and I=5, the length of the transmitted codeblock is bits, unless virtual fill is used. If virtual fill is used, the length of the transmitted codeblock is reduced by the length of the virtual fill. A description of the use of virtual fill is provided in clause The logical codeblock is the logical data entity operated upon by the R S decoder. It can have a different length than the transmitted codeblock because it accounts for the amount of virtual fill that was introduced. For example, when E=16, k=223 and I=5, the logical codeblock always appears to be exactly bits in length. 24

25 Figure 6 2: Reed Solomon codeblock partitioning Shortened codeblock length Overview In a systematic block code, a codeword can be divided into an information part and a parity (check) part. If the information part is k symbols long, a shortened code is created by taking only s (s < k) information symbols as input, appending a fixed string of length k s and then encoding in the normal way. This fixed string is called virtual fill. Since the fill is a predetermined sequence of symbols, it is not transmitted over the channel, resulting in a shortened codeblock length. Thus the length of the transmitted codeblock is reduced by the length of the virtual fill. At the receiving end, the decoder appends the same fill sequence before decoding. The transmitted codeblock together with the virtual fill forms the logical codeblock. Figure 6 2 illustrates the transmitted codeblock and the logical codeblock. Shortening the transmitted codeblock length in this way changes the overall performance to a degree dependent on the amount of virtual fill used. Since it incorporates no virtual fill, the maximum codeblock length provides full performance General a. A shortened codeblock length may be used to accommodate frame lengths smaller than the maximum. b. Virtual fill shall be inserted only in integer multiples of 8I bits. c. The virtual fill shall not change in length during a mission phase. d. Virtual fill shall be inserted only at the beginning of the codeblock (i.e. after the attached sync marker but before the beginning of the transmitted codeblock). e. Virtual fill shall not be transmitted. NOTE Virtual fill is used to logically complete the codeblock. 25

26 f. Virtual fill shall consist of all zeros. g. If virtual fill is used, the resulting rate of codeblocks per unit time shall be calculated to ensure that the maximum operating speed of the decoder is not exceeded. NOTE As virtual fill in a codeblock is increased (at a specific bit rate), the number of codeblocks per unit time increases Use of virtual fill Since the Reed Solomon code is a block code, the decoder always operates on a full block basis. To achieve a full codeblock, virtual fill is added to make up the difference between the shortened block and the maximum codeblock length. Successful decoding depends on the configuration of the encoder and decoder to insert the correct length of virtual fill. Otherwise, the decoding cannot be carried out properly. When an encoder (initially cleared at the start of a block) receives ki Q symbols representing information (where Q, representing fill, is a multiple of I, and is less than ki), 2EI check symbols are computed over ki symbols, of which the leading Q symbols are treated as all zero symbols. A (ni Q, ki Q) shortened codeblock results where the leading Q symbols (all zeros) are neither entered into the encoder nor transmitted Dual basis symbol representation and ordering Each 8 bit Reed Solomon symbol is an element of the finite field GF(256). Since GF(256) is a vector space of dimension 8 over the binary field GF(2), the actual 8 bit representation of a symbol is a function of the particular basis that is chosen. One basis for GF(256) over GF(2) is the set ( 1, α 1, α 2,..., α 7 ). This means that any element of GF(256) has a representation of the form u 7 α 7 + u 6 α u 1 α 1 + u 0 α 0 where each u i is either a 0 or a 1. Another basis over GF(2) is the set ( 1, β 1, β 2,..., β 7 ) where β = α 117. To this basis there exists a so called ʺdual basisʺ (l 0, l 1,..., l 7 ). This has the property Tr(l i β j ) = 1, if i = j 0, otherwise for each j = 0, 1,..., 7. The function Tr(z), called the ʺtraceʺ, is defined by 7 Tr(z) = z 2k k=0 26

27 for each element z of GF(256). Each Reed Solomon symbol can also be represented as z 0 l 0 + z 1 l z 7 l 7 where each z i is either a 0 or a 1. The representation used in this Standard is the dual basis 8 bit string z 0, z 1,..., z 7, transmitted in that order (i.e. with z 0 first). The relationship between the two representations is given by the two equations and [z 0,..., z 7 ] = [u 7,..., u 0 ] [u 7,..., u 0 ] = [z 0,..., z 7 ] Further information relating the dual basis (Berlekamp) and conventional representations is given in Annex A. Also included is a scheme for transforming the symbols generated in a conventional encoder to the symbol representation used by this Standard Synchronization Codeblock synchronization of the Reed Solomon decoder is achieved by synchronization of the attached sync marker associated with each codeblock (see clause 8.) Ambiguity resolution a. The ambiguity between true and complemented data shall be resolved so that only true data is provided to the Reed Solomon decoder. NOTE Data in NRZ L form is normally resolved using the 32 bit attached sync marker. NRZ M data is selfresolving. 27

28 6.4 Reed-Solomon with E= Introduction There is a Reed Solomon code which has E=8 and which otherwise follows the specification in clauses to This alternative code has lower overhead with reduced performance and can correct 8 Reed Solomon symbols per codeword. For E=8: 2E, the number of parity check symbols in each codeword, is 16. k, the number of information symbols in each codeword, is 239. J = 8 and n = 255 as for the E=16 code in clause For E=8, the generator polynomials F(x) and g(x) specified in clause characterize a (255,239) Reed Solomon code. In this Standard, the use is limited to links which have 4 dimensional 8PSK trellis coded modulation (4D 8PSK TCM). When Reed Solomon with E=8 is used, then the requirements in clause apply General a. The Reed Solomon code with E=8 shall only be used if the modulation scheme is 4D 8PSK TCM. NOTE The modulation scheme 4D 8PSK TCM is defined in ECSS E ST 05. b. The Reed Solomon code with E=8 shall not be concatenated with one of the convolutional codes defined in clause 5. c. For the Reed Solomon code with E=8, the interleaving depth, I, shall take the value 8. NOTE The error correction and detection capability of Reed Solomon code with E=8 is limited and the output of a 4D 8PSK TCM decoder is liable to burst errors. An interleaving depth of I=8 improves the combined error correction and detection capability of the Reed Solomon code with 4D 8PSK TCM. 28

29 7 Turbo coding 7.1 Properties Turbo codes are binary block codes with large code blocks (hundreds or thousands of bits). They are systematic and inherently non transparent. Phase ambiguities are resolved using frame markers, which are used for codeblock synchronization. Turbo codes can be used to obtain even greater coding gain than those provided by concatenated coding systems. Turbo coding, by itself, cannot guarantee sufficient bit transitions to keep receiver symbol synchronizers in lock. The pseudo randomizer defined in clause 9 can be used to increase the symbol transition density. Further details on the operational environment and performance of the specified turbo codes can be found in CCSDS G 1. While providing significant coding gain, turbo codes can still leave some residual errors in the decoded output. For this reason, when telemetry transfer frames are used, reference ECSS E ST specifies that a cyclic redundancy check (CRC) field be used to validate the frame. Similarly, the CRC is used for the AOS transfer frames defined in CCSDS B-2. Implementers are informed that a wide class of turbo codes is covered by patent rights (see Annex H). 7.2 General a. For turbo coding, the frame synchronization defined in clause 8 shall be used. b. Differential encoding (i.e. NRZ M signalling) after the turbo encoder should not be used. NOTE Soft decoding implies the use of differential detection with considerable loss of performance. Differential encoding before the turbo encoder cannot be used because the turbo codes specified in this Standard are non transparent. This implies that phase ambiguities are detected and resolved by the frame synchronizer. 29

30 7.3 Specification General A turbo encoder is a combination of two simple encoders. The input is a frame of k information bits. The two component encoders generate parity symbols from two simple recursive convolutional codes, each with a small number of states. The information bits are also sent uncoded. A key feature of turbo codes is an interleaver which permutes, bit wise, the original k information bits before input to the second encoder. The turbo code defined in this Standard is a systematic code Parameters and general characteristics a. The turbo code shall have the following parameters and general characteristics: 1. The code type is a systematic parallel concatenated turbo code. 2. There are 2 component codes, and there is also an uncoded component to make the code systematic. 3. The component codes are recursive convolutional codes. 4. Each convolutional component code has 16 states. b. The nominal code rate, r, shall be selected from one of the following values: r = 1/2 or 1/4. NOTE Due to trellis termination symbols (see clause 7.3.6), the true code rates (defined as the ratios of the information block lengths to the codeblock lengths in Table 7 2) are slightly smaller than the nominal code rates. In this Standard, code rate always refers to the nominal code rates, r = 1/2 or 1/4. c. The information block length k shall be selected from one of the values specified in Table 7 1. NOTE 1 NOTE 2 The lengths are chosen for compatibility with the corresponding Reed Solomon interleaving depths, also shown in Table 7 1. The corresponding codeblock lengths in bits, n=(k+4)/r, for the specified code rates are shown in Table 7 2. NOTE 3 An additional information block length of bits (2048 octets) is currently under study. d. If the information block length of 1784 bits is used, the resulting rate of codeblocks per unit time shall be calculated to ensure that the maximum operating speed of the decoder is not exceeded. 30

31 NOTE A short block length can result in a high number of codeblocks per unit time. The decoding latency and performance are considered in this case. Table 7 1: Specified information block lengths Information block length k, bits Corresponding Reed Solomon interleaving depth I 1784 (=223 1 octets) (=223 2 octets) (=223 4 octets) (=223 5 octets) 5 Table 7 2: Codeblock lengths (measured in bits) Information block length k, bits Codeblock length n, bits rate 1/2 rate 1/ Turbo code permutation The interleaver is a fundamental component of the turbo encoding and decoding process. The interleaver for turbo codes is a fixed bit by bit permutation of the entire block of data. Unlike the symbol by symbol rectangular interleaver used with Reed Solomon codes, the turbo code permutation scrambles individual bits and resembles a randomly selected permutation in its lack of apparent orderliness. The permutation for each specified block length k is given by a specific reordering of the integers 1, 2,..., k as generated by the following algorithm. First, k is expressed as k=k 1 k 2. The parameters k 1 and k 2 for the specified block sizes are given in Table 7 3. Next, the following operations are performed for s=1 to s=k to obtain permutation numbers π(s). In the equations below, x denotes the largest integer less than or equal to x, and p q denotes one of the following eight prime integers: p 1 = 31; p 2 = 37; p 3 = 43; p 4 = 47; p 5 = 53; p 6 = 59; p 7 = 61; p 8 = 67 m = (s 1) mod 2 i = s 1 2 k 2 31

32 j = s 1 2 i k 2 k 1 t = (19i + 1) mod 2 q = t mod c = (p q j + 21m) mod k 2 π(s) = 2(t + c k ) m The interpretation of the permutation numbers is such that the sth bit read out on line ʺin bʺ in Figure 7 2 is the π(s)th bit of the input information block, as shown in Figure 7 1. Table 7 3: Parameters k1 and k2 for specified information block lengths Information block length (bits) k 1 k Figure 7 1: Interpretation of permutation 32

33 7.3.4 Backward and forward connection vectors The backward connection vector for both component codes and all code rates is: G0 = The forward connection vectors are shown in Table 7 4. Table 7 4: Forward connection vectors Rate Components Vectors Puncturing 1/2 both codes G1 = every other symbol from each component code 1/4 1 st component code G2 = G3 = nd component code G1 = none Figure 7 2: Turbo encoder block diagram 33

34 7.3.5 Turbo encoder block In Figure 7 2 each input frame of k information bits is held in a frame buffer, and the bits in the buffer are read out in two different orders for the two component encoders. The first component encoder (a) operates on the bits in unpermuted order (ʺin aʺ), while the second component encoder (b) receives the same bits permuted by the interleaver (ʺin bʺ). The read out addressing for ʺin aʺ is a simple counter, while the addressing for ʺin bʺ is specified by the turbo code permutation described in clause The component encoders are recursive convolutional encoders realized by feedback shift registers as shown in Figure 7 2. The circuits shown in this figure implement the backward connection vector, G0, and the forward connection vectors, G1, G2, G3, specified in Table 7 4. The block diagram also shows the encoding for rate 1/3 and rate 1/6 codes which are not specified in this Standard. A key difference between these convolutional component encoders and the standalone convolutional encoder specified in clause 5 is their recursiveness. In the figure this is indicated by the signal (corresponding to the backward connection vector G0) fed back into the leftmost adder of each component encoder Turbo codeblock specification Both component encoders in Figure 7 2 are initialized with zeros in all registers, and both are run for a total of k+4 bit times, producing an output codeblock of (k+4)/r encoded symbols, where r is the nominal code rate. For the first k bit times, the input switches are in the lower position (as indicated in the figure) to receive input data. For the final 4 bit times, these switches move to the upper position to receive feedback from the shift registers. This feedback cancels the same feedback sent (unswitched) to the leftmost adder and causes all four registers to become filled with zeros after the final 4 bit times. Filling the registers with zeros is called terminating the trellis. During trellis termination the encoder continues to output non zero encoded symbols. In particular, the ʺsystematic uncodedʺ output (line ʺout 0aʺ in the figure) includes an extra 4 bits from the feedback line in addition to the k information bits. In Figure 7 2, the encoded symbols are multiplexed from top to bottom along the output line for the selected code rate to form the turbo codeblock. For the rate 1/2 code, the output sequence is (out 0a, out 1a, out 0a, out 1b), repeated (k+4)/2 times. This pattern implies that puncturing is applied first to out 1b, second to out 1a, and so forth. For the rate 1/4 code, the output sequence is (out 0a, out 2a, out 3a, out 1b). This sequence is repeated for (k+4) bit times. The turbo codeblocks constructed from these output sequences are depicted in Figure 7 3 for the two nominal code rates. 34

35 Figure 7 3: Turbo codeblocks for code rates 1/2 and 1/ Turbo codeblock synchronization Codeblock synchronization of the turbo decoder is achieved by synchronization of an attached sync marker (ASM) associated with each turbo codeblock. The ASM is a bit pattern specified in clause 8. The ASM precedes the turbo codeblock. Frame synchronizers are set to expect a marker at a recurrence interval equal to the length of the ASM plus that of the turbo codeblock. A diagram of a turbo codeblock with attached sync marker is shown in Figure 7 4. The length of the turbo codeblock is inversely proportional to the nominal code rate r. Figure 7 4: Turbo codeblock with attached sync marker 35

36 8 Frame synchronization 8.1 Introduction Frame or codeblock synchronization is an essential part of the processing of the telemetry data stream. The following actions depend on accurate synchronization: Correct decoding of Reed Solomon codeblocks and turbo codeblocks. Processing of the transfer frames. Synchronization of the pseudo random generator, if used (see clause 9). It is also useful in assisting the node synchronization process of the Viterbi decoder for the convolutional code. 8.2 The attached sync marker (ASM) Overview Synchronization of the Reed Solomon or turbo codeblock (or transfer frame, if the telemetry channel is not Reed Solomon coded or turbo coded) is achieved by using a stream of fixed length codeblocks (or transfer frames) with an attached sync marker (ASM) between them. The data unit that consists of the ASM and the Reed Solomon or turbo codeblock or transfer frame is called the channel access data unit (CADU), as shown in Figure 8 1. Figure 8 1: Format of channel access data unit (CADU) Figure 4 1 and Figure 4 2 show how synchronization is combined with the different coding options. Synchronization is acquired at the receiving end by recognizing the specific bit pattern of the ASM in the telemetry channel data stream; synchronization is then customarily confirmed by making further checks. 36

37 8.2.2 Encoder side a. If the telemetry channel is uncoded, Reed Solomon coded, or turbo coded, the code symbols comprising the ASM shall be attached directly to the encoder output without being encoded by the Reed Solomon or turbo code. b. If an inner convolutional code is used in conjunction with an outer Reed Solomon code, the ASM shall be encoded by the inner code but not by the outer code Decoder side a. For a concatenated Reed Solomon and convolutional coding system, the ASM may be acquired either in the channel symbol domain (i.e. before any decoding) or in the domain of bits decoded by the inner code (i.e. the code symbol domain of the Reed Solomon code). b. For a turbo coding system, the ASM shall be acquired in the channel symbol domain (i.e. the code symbol domain of the turbo code). 8.3 ASM bit patterns a. The ASM for telemetry data that is not turbo coded shall consist of a 32 bit (4 octet) marker with the pattern shown in Figure 8 2. b. The ASM for data that is turbo coded with nominal code rate r = 1/2 or 1/4 shall consist of a 32/r bit (4/r octet) marker with bit patterns shown in Figure 8 3 and Figure 8 4. NOTE Table 8 1 shows the ASM bit patterns in hexadecimal notation. Figure 8 2 ASM bit pattern for non turbo coded data Figure 8 3: ASM bit pattern for rate 1/2 turbo coded data 37

38 Figure 8 4: ASM bit pattern for rate 1/4 turbo coded data Table 8 1: ASM bit patterns in hexadecimal notation Data type ASM in hexadecimal notation non turbo coded data 1ACFFC1D rate 1/2 turbo coded data C B0 rate 1/4 turbo coded data C B0 FCB88938 D8D76A4F 8.4 Location of ASM a. The ASM shall be attached to, and immediately precede, the Reed Solomon or turbo codeblock, or the transfer frame if the telemetry channel is not Reed Solomon or turbo coded. b. The ASM for one codeblock (or transfer frame) shall immediately follow the end of the preceding codeblock (or transfer frame). NOTE This implies that there are no intervening bits (i.e. data or fill) preceding the ASM. 8.5 Relationship of ASM to Reed-Solomon and turbo codeblocks a. The ASM shall not be presented to the input of the Reed Solomon encoder or decoder. NOTE 1 This prevents the encoder from routinely regenerating a second, identical marker in the check symbol field under certain repeating datadependent conditions (e.g. a test pattern of ) which can cause synchronization difficulties at the receiving end. NOTE 2 NOTE 3 The ASM is not a part of the encoded data space of the Reed Solomon codeblock. The relationship between the ASM, Reed Solomon codeblock, and transfer frame is illustrated in Figure 6 2. b. The ASM shall not be presented to the input of the turbo encoder or decoder. NOTE The ASM is directly attached to the turbo codeblock as shown in Figure