Tiêu chuẩn iso 11754 2003 scan

--`,,,`-`-`,,`,,`,`,,`---CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING STATEMENT OF INTENT The Consultative Committee for Space Data Systems CCSDS is an organization officially esta

Second edition 2003-02-1 5

Space data and information transfer

Systèmes de transfert des informations et données spatiales -

Codage de canal pour télémesure

Reference number

IS0 1 1754:2003(E)

@ IS0 2003

`,,,`-`-`,,`,,`,`,,` -PDF disclaimer

This PDF file may contain embedded typefaces In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy The IS0 Central Secretariat accepts no liability in this area

Adobe is a trademark of Adobe Systems Incorporated

Details of the sofiware products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing Every care has been taken to ensure that the file is suitable for use by IS0 member bodies In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below

O IS02003

All rights reserved Unless othetwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IS0 at the address below or

ISOs member body in the country of the requester

IS0 copyright office

Case postale 56 CH-I211 Geneva 20

International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2 The main task of technical committees is to prepare International Standards Draft International Standards adopted by the technical committees are circulated to the member bodies for voting Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights I S 0 shall not be held responsible for identifying any or all such patent rights

International Standard IS0 11754 was prepared by the Consultative Committee for Space Data Systems

(CCSDS) (as CCSDS 101.0-B-5, June 2001) and was adopted (without modifications except those stated in

Clause 2 of this International Standard) by Technical Committee ISOíTC 20, Aircraft and space vehicles, Subcommittee SC 13, Space data and information transfer systems

This second edition cancels and replaces the first edition (IS0 1 1754: 1994), which has been technically

revised

`,,,`-`-`,,`,,`,`,,` -Space data and information transfer systems - Telemetry

Document CCSDS 102.0-B-5, November 2000, is equivalent to I S 0 1341 9:2003

Document CCSDS 701.0-B-3, June 2001, is equivalent to I S 0 13420:-1)

It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee

ISOíTC 20/SC 13 will be consulted in the event of any revision or amendment of publication

CCSDS 101.0-B-5 To this end, NASA will act as a liaison body between CCSDS and SO

1) To be published (Revision of I S 0 13420:1997)

`,,,`-`-`,,`,,`,`,,` -(Blank page)

`,,,`-`-`,,`,,`,`,,` -Consultative

RECOMMENDATION FOR SPACE DATA SYSTEM STANDARDS

TELEMETRY CHANNEL CODING

`,,,`-`-`,,`,,`,`,,` -4

DEDICATION

This document is dedicated to the memory of Mr Warner H Miller of NASA

Warner had been with the CCSDS since its beginning and throughout the years

he was a major contributor to numerous standards for error control coding, radio frequency modulation, data architecture, and data compression Warner was a superb technologist, a gentleman, and a friend always ready to help, especially young colleagues Warner and his approach to work and life in general will be

deeply missed by his many friends and colleagues in the CCSDS

O IS0 2003 -All rights reserved

`,,,`-`-`,,`,,`,`,,` -AUTHORITY

Issue: Blue Book, Issue 5

Date: June 2001 Location: Oxfordshire, UJS

This document has been approved for publication by the Management Council of the Consultative Committee for Space Data Systems (CCSDS) and represents the consensus technical agreement of the participating CCSDS Member Agencies The procedure for review and authorization of CCSDS Recommendations is detailed in reference [Dl], and the record of Agency participation in the authorization of this document can be obtained fi-om the CCSDS Secretariat at the address below

This Recommendation is published and maintained by:

CCSDS Secretariat Program Integration Division (Code MT) National Aeronautics and Space Administration Washington, DC 20546, USA

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

STATEMENT OF INTENT

The Consultative Committee for Space Data Systems (CCSDS) is an organization officially established by the management of member space Agencies The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems Inasmuch as participation in the CCSDS is completely voluntary, the results of Committee actions are termed

Recommendations and are not considered binding on any Agency

This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary body Agency endorsement of this Recommendation is entirely voluntary Endorsement,

however, indicates the following understandings:

o Whenever an Agency establishes a CCSDS-related standard, this standard will be in accord with the relevant Recommendation Establishing such a standard does not

preclude other provisions which an Agency may develop

o Whenever an Agency establishes a CCSDS-related standard, the Agency will provide

other CCSDS member Agencies with the following information:

The standard itself

The anticipated date of initial operational capability

The anticipated duration of operational service

o Specific service arrangements shall be made via memoranda of agreement Neither this

Recommendation nor any ensuing standard is a substitute for a memorandum of

agreement

No later than five years fi-om its date of issuance, this Recommendation will be reviewed by

the CCSDS to determine whether it should: (1) remain in effect without change; (2) be changed to reflect the impact of new technologies, new requirements, or new directions; or, (3) be retired or canceled

In those instances when a new version of a Recommendation is issued, existing CCSDS-

related Agency standards and implementations are not negated or deemed to be non-CCSDS compatible It is the responsibility of each Agency to determine when such standards or implementations are to be modified Each Agency is, however, strongly encouraged to direct planning for its new standards and implementations towards the later version of the Recommendation

O IS0 2003 -All rights reserved

6

`,,,`-`-`,,`,,`,`,,` -FOREWORD

This document is a technical Recommendation for use in developing channel coding systems and has been prepared by the Consultative Committee for Space Data Systems (CCSDS) The telemetry channel coding concept described herein is the baseline concept for spacecraft- to-ground data communication within missions that are cross-supported between Agencies of the CCSDS

This Recommendation establishes a common framework and provides a common basis for the coding schemes used on spacecraft telemetry streams It allows implementing organizations within each Agency to proceed coherently with the development of compatible derived Standards for the flight and ground systems that are within their cognizance Derived Agency Standards may implement only a subset of the optional features allowed by the Recommendation and may incorporate features not addressed by the Recommendation

Through the process of normal evolution, it is expected that expansion, deletion, or modification of this document may occur This Recommendation is therefore subject to CCSDS document management and change control procedures as defined in reference [Dl] Current versions of CCSDS documents are maintained at the CCSDS Web site:

http ://www ccsds orgl Questions relating to the contents or status of this document should be addressed to the CCSDS Secretariat at the address indicated on page i

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies

- Agenzia Spaziale Italiana (ASI)/Italy

- British National Space Centre (BNSC)/United Kingdom

- Canadian Space Agency (CSA)/Canada

- Centre National d'Etudes Spatiales (CNES)/France

- Deutsches Zentrum fi Luft- und Raumfahrt e.V (DLR)/Germany

- European Space Agency (ESA)/Europe

- Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil

- National Aeronautics and Space Administration (NASA)/üSA

- National Space Development Agency of Japan (NASDA)/Japan

- Russian Space Agency (RSA)/Russian Federation

Observer Agencies

- Austrian Space Agency (ASA)/Austria

- Central Research Institute of Machine Building (TsNIIMash)/Russian Federation

- Centro Tecnico Aeroespacial (CTA)/Brazil

- Chinese Academy of Space Technology (CAST)/China

- Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia

- Communications Research Centre (CRC)/Canada

- Communications Research Laboratory (CRL)/Japan

- Danish Space Research Institute (DSRI)/Denmark

- European Organization for the Exploitation of Meteorological Satellites (EUMET SAT)/Europe

- European Telecommunications Satellite Organization (EUTELSAT)/Europe

- Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium

- Hellenic National Space Committee ("SC)/Greece

- Indian Space Research Organization (ISRO)/India

- Institute of Space and Astronautical Science (ISAS)/Japan

- Institute of Space Research (IKI)/Russian Federation

- KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary

- MIJSOMTEK: CSIR (CSIR)/Republic of South Africa

- Korea Aerospace Research Institute (KARI)/Korea

- Ministry of Communications (MOC)/Israel

- National Oceanic & Atmospheric Administration (NOAA)/üSA

- National Space Program Office (NSPO)/Taipei

- Swedish Space Corporation (SSC)/Sweden

- United States Geological Survey (USGS)/üSA

`,,,`-`-`,,`,,`,`,,` -Document

CCSDS

1 O 1 O-B-1 CCSDS

2 Removes ASM from R-S encoded data space

3 Specifies marker pattern for ASM

4 Transfers Annex A (“Rationale”) to Green Book

1 Supersedes Issue 2

2 Deletes Section 3 (“Convolutional Coding with Interleaving for Tracking and Data Relay Satellite Operations”)

3 Adds R-S interleave depths of 1=2,3,4 to existing 1=1 and 5

4 Allows R-S code to be operated in

“Standalone Mode” (Le., not concatenated with the convolutional code)

5 Consolidates codeblock and transfer frame sync specifications (new Section 5)

6 Specifies a standard Pseudo-Randomizer to improve bit synchronization (new Section 6)

7 Corrects several editorial errors

1 Supersedes Issue 3

2 Adds turbo code specification (new Section

3 Moves normative references from front matter to Section 1

4 Moves informative references to Annex D

4)

1 Supersedes Issue 4

2 Corrects misleading encoder diagrams

3 Adds the following options to help near-earth users:

- Reed-Solomon 8-error correcting code;

- a set of punctured convolutional codes comparable to the DVB-S standard

4 Specifies maximum frame lengths

Substantive technical changes fi-om the previous issue are flagged with change bars in the right margin

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

5.2 THE ATTACHED SYNC MARKER (ASM) 5-1

5.3 ASM BIT PATTERNS 5-1

5.4 LOCATION OF ASM 5-3

5.5 RELATIONSHIP OF ASM TO REED-SOLOMON AND TURBO

CODEBLOCKS 5-3 ASM FOR EMBEDDED DATA STREAM 5-3 5.6

`,,,`-`-`,,`,,`,`,,` -CONTENTS (continued)

ANNEX A TRANSFORMATION BETWEEN BERLEKAMP AND

CONVENTIONAL REPRESENTATIONS A-1

GLOSSARY OF ACRONYMS AND TERMS C-1 INFORMATIVE REFERENCES D-1

ANNEX B ANNEX C ANNEX D ANNEX E

Figure

1-1 2- 1 2-2 3-1

3 -2 4- 1 4-2 4-3 4-4 5-1 5-2 5-3 6- 1 6-2

A- 1

Bit Numbering 1-2

Convolutional Encoder Block Diagram 2.3

Punctured Encoder Block Dia gram 2-4

Functional Representation of R-S Interleaving 3-3

Reed-Solomon Codeblock Partitioning 3-5

Interpretation of Permutation 4-4

Turbo Encoder Block Diagram 4-5

Turbo Codeblocks for Different Code Rates 4-7

Turbo Codeblock with Attached Sync Marker 4-8

ASM Bit Pattern for Non-Turbo-Coded Data 5-2

ASM Bit Pattern for Turbo-Coded Data 5-2

Embedded ASM Bit Pattern 5-3

Pseudo-Randomizer Configuration 6-1

Pseudo-Randomizer Logic Diagram 6-3

Transformational Equivalence A-2 Table

2-1 Puncture Code Patterns for Convolutional Code Rates 2-5 4- 1 Specified Information Block Lengths 4.2 4-2 Codeblock Lengths for Supported Code Rates (Measured in Bits) 4-3 4-3 Parameters ki and k2 for Specified Information Block Lengths 4-4

A-1 Equivalence of Representations A-5

CCSDS 101.0-B-5

O IS0 2003 -All rights reserved

11

(Blank page)

`,,,`-`-`,,`,,`,`,,` -1 INTRODUCTION

The purpose of this document is to establish a common Recommendation for space telemetry channel coding systems to provide cross-support among missions and facilities of member Agencies of the Consultative Committee for Space Data Systems (CCSDS) In addition, it provides focusing for the development of multi-mission support capabilities within the respective Agencies to eliminate the need for arbitrary, unique capabilities for each mission Telemetry channel coding is a method of processing data being sent fi-om a source to a destination so that distinct messages are created which are easily distinguishable fi-om one another This allows reconstruction of the data with low error probability, thus improving the performance of the channel

Several space telemetry channel coding schemes are described in this document The characteristics of the codes are specified only to the extent necessary to ensure interoperability and cross-support The specification does not attempt to quantifj the relative coding gain or the merits of each approach discussed, nor the design requirements for encoders or decoders Some performance information is included in Reference [D2]

This Recommendation does not require that coding be used on all cross-supported missions However, for those planning to use coding, the recommended codes to be used are those described in this document

The rate 1/2 convolutional code recommended for cross-support is described in Section 2,

“Convolutional Coding” Depending on performance requirements, this code alone may be satisfactory

For telecommunication channels which are bandwidth-constrained and cannot tolerate the increase in bandwidth required by the basic convolutional code specified in 2.1, the punctured convolutional code specified in 2.2 has the advantage of smaller bandwidth expansion The Reed-Solomon code specified in Section 3 also has the advantage of smaller bandwidth expansion and has the capability to indicate the presence of uncorrectable errors

Where a greater coding gain is needed than 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 may be used for improved performance The turbo codes recommended in Section 4 may be used to obtain even greater coding gain where the environment permits

The recommended methods for fi-ame (or codeblock) synchronization are described in Section 5

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

To improve bit transition density as an aid to bit synchronization, a recommended method of

pseudo-randomizing data to be sent over the telemetry channel is described in Section 6

Annex A provides a discussion of the transformation between the Berlekamp and

conventional Reed-Solomon symbol representations; Annex B provides a table showing the

expansion of Reed-Solomon coefficients; and Annex C is a glossary of coding terminology

used in this document

1.3 APPLICABILITY

This Recommendation applies to telemetry channel coding applications of space missions

anticipating cross-support among CCSDS member Agencies at the coding layer In addition,

it serves as a guideline for the development of compatible internal Agency Standards in this

field, based on good engineering practice

In addition to being applicable to conventional Packet Telemetry systems [i], the codes in

this recommendation are applicable to the forward and return links of Advanced Orbiting

Systems (AOS) [2] For coding purposes, the terms ?Transfer Frame? and ?Reed-Solomon

Codeblock? as used in this recommendation are understood to be equivalent to the AOS

terms ?Virtual Channel Data Unit? (VCDU), and ?Coded Virtual Channel Data Unit?

(CVCDU) , respectively

In this document, the following convention is used to identifj each bit in a forward-justified

N-bit field The first bit in the field to be transmitted (i.e., the most left justified when

drawing a figure) is defined to be ?Bit 0?; the following bit is defined to be ?Bit 1? and so on

up to ?Bit N-1?, as shown in Figure 1-1 When the field is used to express a binary value

(such as a counter), the Most Significant Bit (MSB) shall be the first transmitted bit of the

field, i.e., ?Bit 0?

T FIRST BIT TRANSMITTED = MSB

Figure 1-1: Bit Numbering

O IS0 2003 -All rights reserved

14

`,,,`-`-`,,`,,`,`,,` -In accordance with modern data communications practice, spacecraft data fields are often grouped into 8-bit “words” which conform to the above convention Throughout this Recommendation, the following nomenclature is used to describe this grouping:

8-BIT WORD = “OCTET”

1.5 RATIONALE

The CCSDS believes it is important to document the rationale underlying the standards chosen, so that future evaluations of proposed changes or improvements will not lose sight of previous decisions The concept and rationale for Telemetry Channel Coding may be found

in Reference [D2]

1.6 REFERENCES

The following documents are referenced in this Recommendation At the time of publication, the editions indicated were valid All documents are subject to revision, and users of this Recommendation are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below The CCSDS Secretariat maintains a register of currently valid CCSDS Recommendations

Packet Telemetry Recommendation for Space Data System Standards, CCSDS 102.0-

B-5 Blue Book Issue 5 Washington, D.C.: CCSDS, November 2000

Advanced Orbiting Systems, Networks and Data Links: Architectural Specijkation

Recommendation for Space Data System Standards, CCSDS 701.0-B-3 Blue Book Issue 3 Washington, D.C.: CCSDS, June 2001

Recommendation 2.4.9, “Minimum Modulated Symbol Transition Density on the

Space-to-Earth Link” in Radio Frequency and Modulation Systems-Part 1: Earth

Stations and Spacecraft Recommendations for Space Data System Standards, CCSDS

401 O-B Blue Book Washington, D.C.: CCSDS, June 2001

`,,,`-`-`,,`,,`,`,,` -(Blank page)

The convolutional decoder is a maximum-likelihood (Viterbi) decoder

NOTES

1 Basic convolutional code, by itself, cannot guarantee sufficient symbol transitions

when multiplexing schemes are used, e.g., those implemented in QPSK Unless sufficient symbol transition density is assured by other means, the Pseudo-randomizer defined in section 6 is required

2 If the decoder’s correction capability is exceeded, undetected burst errors may appear

in the output For this reason, when CCSDS Transfer Frames or Virtual Channel Data Units are used, references [ i ] and [2], respectively, require that a cyclic redundancy check (CRC) be used to validate the fi-ame unless the Reed-Solomon code is used

It is recommended that soft bit decisions with at least 3-bit quantization be used whenever

constraints (such as location of decoder) permit

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

This recommendation is a non-systematic code and a specific decoding procedure, with the

following characteristics:

(1) Nomenclature: Convolutional code with maximum-likelihood

(Viterbi) decoding

(2) Code rate: 1/2 bit per symbol

(3) Constraint length: 7 bits

(4) Connection vectors: G1 = 11 11001 (171 octal); G2 = 101 101 1 (133 octal)

An encoder block diagram is shown in Figure 2-1

The output symbol sequence is: Cl(l), C2(1), C1(2), C2(2)

When suppressed-carrier modulation systems are used, NRZ-M or NRZ-L may be used as a modulating waveform If the

user contemplates conversion of his modulating waveform ftom NRZ-L to NRZ-M, such conversion should be performed

on-board at the input to the convolutional encoder Correspondingly, the conversion on the ground ftom NRZ-M to NRZ-

L should be performed at the output of the convolutional decoder This avoids unnecessary link performance loss

CAUTION - When a fixed pattern (the fiied part of the convolutionally encoded Attached Sync Marker) in the

symbol stream is used to provide node synchronization for the Viterbi decoder, care must be taken to account for any modification of the pattern due to the modulating waveform conversion

SI : POSITION 1, POSITION 2

3 SI IS IN THE POSITION SHOWN (1) FOR THE FIRST SYMBOL ASSOCIATED WITH AN INCOMING BIT

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

The code rate (1=1/2), constraint length (k7) convolutional code can be modified to achieve

an increase in bandwidth efficiency This modification is achieved by using a puncture

pattern P(r) Puncturing removes some of the symbols before transmission, providing lower

overhead and lower bandwidth expansion than the original code, but with slightly reduced

error correcting performance

Puncturing allows a single code rate of either 2/3, 3/4, 5/6 or 7/8 to be selected The four

different puncturing schemes allow selection of the most appropriate level of error correction

and symbol rate for a given service or data rate Figure 2-2 depicts the punctured encoding

scheme

NOTE - The symbol inverter associated with G2 in the rate 1/2 code (defined in 2.1.2) is

omitted here If sufficient symbol transition density is not ensured by other means then the Pseudo-randomizer defined in section 6 is required

`,,,`-`-`,,`,,`,`,,` -Puncturing Pattern

1 =transmitted symbol

O = non-transmitted symbol

Code Rate

The punctured convolutional code has the following characteristics:

(1) Nomenclature: Punctured convolutional code with

maximum-likelihood (Viterbi) decoding

112, punctured to 213 314, 516 or 718 (2) Code rate:

(3) Constraint length: 7 bits (4) Connection vectors:

`,,,`-`-`,,`,,`,`,,` -(Blank page)

`,,,`-`-`,,`,,`,`,,` -3 REED-SOLOMON CODING

3.1 INTRODUCTION

The Reed-Solomon code defined in this section is a powerful burst error correcting code In addition, the code chosen has an extremely low undetected error rate This means that the decoder can reliably indicate whether it can make the proper corrections or not To achieve this reliability, proper codeblock synchronization is mandatory

One of two different error-correcting options may be chosen For maximum performance (at the expense of accompanying overhead) the E=16 option can correct 16 R-S symbols in error per codeword For lower overhead (with reduced performance) the E=8 option can correct 8 R-S symbols per codeword The two options shall not be mixed in a single telemetry stream

NOTES

1 The extremely low undetected error rate of this code means that the R-S decoder can,

with a hi& degree of certainty, validate the decoded codeblock and consequently the contained CCSDS Transfer Frame (reference [i]) or Virtual Channel Data Unit (reference [2]) For this reason, [ i ] and [2] do not require a Cyclic Redundancy Check when this Reed-Solomon Code is used

2 The Reed-Solomon coding, by itself, cannot guarantee sufficient channel symbol

transitions to keep receiver symbol synchronizers in lock Unless sufficient channel symbol transition density is ensured by other means, the Pseudo-randomizer defined

in section 6 is required

The Reed-Solomon code may be used alone, and as such it provides an excellent forward error correction capability in a burst-noise channel However, should the Reed-Solomon code alone not provide sufficient coding gain, it may be concatenated with the convolutional

code defined in Section 2 Used this way, the Reed-Solomon code is the outer code, while the convolutional code is the inner code

The parameters of the selected Reed-Solomon (R-S) code are as follows:

(1) J = 8 bits per R-S symbol

(2) B = Reed-Solomon error correction capability, in symbols, within an R-S

codeword B may be selected to be 16 or 8 R-S symbols

(3) General characteristics of the Reed-Solomon code:

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

(a) J, E, and I (the depth of interleaving) are independent parameters

(b) n = 2J-1 = 255 symbols per R-S codeword

(c) 2E is the number of R-S symbols among n symbols of an R-S codeword

representing parity checks

(d) k = n-2E is the number of R-S symbols among n R-S symbols of an R-S

codeword representing information

(4) Field generator polynomial:

over GF(28), where F(a) = O

It should be recognized that d' is a primitive element in GF(28) and that F(x) and

g(x) characterize a (255,223) Reed-Solomon code when E = 16 and a (255,239)

Reed-Solomon code when E = 8

( 6 ) The selected code is a systematic code This results in a systematic codeblock

(7) Symbol Interleaving:

The allowable values of interleaving depth are I=1, 2, 3, 4, and 5 I=1 is equivalent to the absence of interleaving The interleaving depth shall normally

be fixed on a physical channel for a mission Symbol interleaving is

accomplished in a manner functionally described with the aid of Figure 3-1 (It

should be noted that this functional description does not necessarily correspond to the physical implementation of an encoder.)

24

O IS0 2003 -All rights reserved

`,,,`-`-`,,`,,`,`,,` -CI R-S ENCODER #I i

R-S ENCODER #I

IN

Figure 3-1: Functional Representation of R-S Interleaving

Data bits to be encoded into a single Reed-Solomon Codeblock enter at the port labeled “IN” Switches S 1 and S2 are synchronized together and advance fi-om

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 will be formed fi-om kl R-S symbols entering “IN” In this

functional representation, a space of 2EI R-S symbols in duration is required

between each entering set of kl R-S information symbols

Due to the action of S 1 , 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 labeled “OUT” in the same way as they entered at “IN”

Following this, each encoder outputs its 2E check symbols, one symbol at a time,

then the output is the same sequence with the [2E x 5 spaces] filled by the

[2E x 51 check symbols as shown below:

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

is the R-S codeword produced by the ith encoder If q virtual fill symbols are

used in each codeword, then replace k by (k - q ) in the above discussion

With this method of interleaving, the original H consecutive information symbols that entered the encoder appear unchanged at the output of the encoder with 2E1

R-S check symbols appended

(8) Maximum Codeblock Length:

The maximum codeblock length, in R-S symbols, is given by:

L,, = n1= (2J- 1)1= 2551

(9) Shortened Codeblock Length:’

A shortened codeblock length may be used to accommodate fi-ame lengths smaller than the maximum However, since the Reed-Solomon code is a block code, the decoder must always operate on a full block basis To achieve a full codeblock,

“virtual fill” must be added to make up the difference between the shortened block and the maximum codeblock length The characteristics and limitations of virtual fill are covered in paragraph (10) Since the virtual fill is not transmitted, both encoder and decoder must be set to insert it with the proper length for the encoding and decoding processes to be carried out properly

When an encoder (initially cleared at the start of a block) receives H-Q symbols representing information (where Q, representing fill, is a multiple of 1, and is less than kl), 2EI check symbols are computed over H symbols, of which the leading

Q symbols are treated as all-zero symbols A (n1-Q, H-Q) shortened codeblock results where the leading Q symbols (all zeros) are neither entered into the encoder nor transmitted

(1 O ) Reed-Solomon Codeblock Partitioning and Virtual Fill:

The R-S codeblock is partitioned as shown in Figure 3-2

It should be noted that 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 allows full performance In addition, as virtual fill in a codeblock is increased (at a specific bit rate), the number of codeblocks per unit time that the decoder must handle increases Therefore, care should be taken so that the maximum operating speed of the decoder (codeblocks per unit time) is not exceeded

O IS0 2003 -All rights reserved

26

VIRTUAL FILL (OPTIONAL)

Figure 3-2: Reed-Solomon Codeblock Partitioning

The Reed-Solomon Check Symbols consist of the trailing 2BI symbols (2BIJ

bits) of the codeblock (As an example, when B = 16 and k = 223, for I=5 this is

always 1280 bits.)

The Telemetry Transfer Frame is defined by the CCSDS Recommendation for

Packet Telemetry (Reference [i]) When used with R-S coding, it has a maximum length of 8920 bits, not including the 32-bit Attached Sync Marker

The Attached Sync Marker used with R-S coding or convolutional coding alone

is a 32-bit pattern specified in Section 5 as an aid to synchronization It precedes the Telemetry Transfer Frame or the Transmitted Codeblock (if R-S coding is used) Frame synchronizers should, therefore, be set to expect a marker at every Telemetry Transfer Frame + 32 bits or at every Transmitted Codeblock + 32 bits (if R-S coding is used)

The Transmitted Codeblock consists of the Telemetry Transfer Frame (without

the 32-bit sync marker) and R-S check symbols It is the received data entity physically fed into the R-S decoder (As an example, when B = 16 and k = 223,

using I=5 and no virtual fill, the length of the transmitted codeblock will be

10,200 bits; if virtual fill is used, it will be incrementally shorter, depending on the amount used.)

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 (As an example, when

B = 16 and k = 223, for I=5 the logical codeblock always appears to have exactly

`,,,`-`-`,,`,,`,`,,` -CCSDS RECOMMENDATION FOR TELEMETRY CHANNEL CODING

Virtual fill is used to logically complete the codeblock and is not transmitted If used, virtual fill shall:

(a) consist of all zeros;

(b) not be transmitted;

(c) not change in length during a tracking pass;

(d) 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) be inserted only in integer multiples of 81 bits

(1 1) Dual basis symbol representation and ordering for transmission:

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, a’, a2, , d) This means that any element of GF(256) has a representation of the form

where each ut is either a zero or a one

Another basis over GF(2) is the set ( 1, B’, B2, , B7) where p= all7 To this basis there exists a so-called “dual basis” (6, el, , 6) It has the property that

l , i f i = j Tr(@’ = { O,

for each j = O, 1, ., 7 The function Tr(z), called the “trace”, is defined by

7 Tr(z) = z2k

`,,,`-`-`,,`,,`,`,,` -The representation used in this Recommendation is the dual basis eight-bit string ZO, z1, ., z7, transmitted in that order (i.e., with zo first) The relationship between the two representations is given by the two equations

(1 2) Synchronization:

Codeblock synchronization of the Reed-Solomon decoder is achieved by synchronization of the Attached Sync Marker associated with each codeblock (See Section 5 )

(1 3) Ambiguity Resolution:

The ambiguity between true and complemented data must be resolved so that only true data is provided to the Reed-Solomon decoder Data in NRZ-L form is normally resolved using the 32-bit Attached Sync Marker, while NRZ-M data is self-resolving

`,,,`-`-`,,`,,`,`,,` -(Blank page)

`,,,`-`-`,,`,,`,`,,` -4 TURBO CODING~

Turbo codes are binary block codes with large code blocks (hundreds or thousands of bits) They are systematic and inherently non-transparent.2 Phase ambiguities are resolved using fi-ame markers, which are required for Codeblock synchronization

Turbo codes may be used to obtain even greater coding gain than those provided by concatenated coding systems Operational environment and performance of the recommended turbo codes are discussed in Reference [D2]

NOTES

1 Turbo coding, by itself, cannot guarantee sufficient bit transitions to keep receiver

symbol synchronizers in lock Unless sufficient symbol transition density is ensured

by other means (such as data, coding or modulation technique), then the Pseudo- randomizer defined in section 6 is required

2 While providing outstanding coding gain, turbo codes may still leave some residual

errors in the decoded output For this reason, when CCSDS Transfer Frames or Virtual Channel Data Units are used, references [ i ] and [2], respectively, require that

a cyclic redundancy check (CRC) be used to validate the fi-ame

1 Implementers should be aware that a wide class of turbo codes is covered by a patent by France Télécom and Télédiffusion de France under US Patent 5,446,747 and its counterparts in other countries Potential user agencies should direct their requests for licenses to:

Mr Christian HAMON CCETT GIE/CVP

4 rue du Clos Courtel BP59

35512 CESSON SEVIGNE Cedex France

Tel: +33 2 99 12 48 05 Fax: +33 2 99 12 40 98

E-mail: christian.hamon@cnet.fiancetelecom.fi

2 Differential encoding (Le., NRZ-M signaling) after the turbo encoder is not recommended since soft decoding would require the use of differential detection with considerable loss of performance Differential encoding before the turbo encoder cannot be used because the turbo codes recommended in this document are non-transparent This implies that phase ambiguities have to be detected and resolved by the fiame synchronizer