ISO 22642:2015

INTERNATIONAL ISO
STANDARD 22642
Second edition
2015-11-15
Space data and information transfer
systems — TC synchronization and
channel coding
Systèmes de transfert des données et informations spatiales —
Synchronisation TC et codage de canal

Reference number
©
ISO 2015
©  ISO 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
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. ISO shall not be held responsible for identifying any or all such patent rights.
This International Standard cancels and replaces ISO 22642:2005 which has been technically revised. It also
incorporates ISO 22642:2005/Cor.1:1997.
ISO 22642 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as CCSDS
231.0-B-2, September 2010) 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.

Recommendation for Space Data System Standards
TC SYNCHRONIZATION
AND CHANNEL CODING
RECOMMENDED STANDARD
CCSDS 231.0-B-2
BLUE BOOK
September 2010
AUTHORITY
Issue: Recommended Standard, Issue 2
Date: September 2010
Location:
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 documents is detailed in the Procedures Manual for the
Consultative Committee for Space Data Systems, and the record of Agency participation in
the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.
This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. 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 Recommended Standards and are
not considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members 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 Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard 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 Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be
non-CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
FOREWORD
This document is a technical Recommended Standard for use in developing synchronization
and channel coding systems and has been prepared by the Consultative Committee for Space
Data Systems (CCSDS). The synchronization and channel coding concept described herein
is intended for missions that are cross-supported between Agencies of the CCSDS.
This Recommended Standard establishes a common framework and provides a common
basis for the synchronization and channel coding schemes to be used by space missions with
the TC Space Data Link Protocol (reference [1]) over ground-to-space and space-to-space
communications links. This Recommended Standard was developed from an older CCSDS
Recommended Standard (reference [C2]), which defines essentially the same schemes but in
a slightly different context.
This Recommended Standard does not change the major technical content defined in
reference [C2], but the presentation of the specification has been changed so that:
a) these schemes can be used to transfer any data over any space link in either direction;
b) all CCSDS space link protocols are specified in a unified manner;
c) the layered model matches the Open Systems Interconnection (OSI) Basic Reference
Model (reference [2]).
Together with the change in presentation, a few technical specifications in reference [C2]
have been changed in order to define all Space Data Link Protocols in a unified way. Also,
some technical terms in reference [C2] have been changed in order to unify the terminology
used in all the CCSDS Recommended Standards that define space link protocols and to
define these schemes as general communications schemes. These changes are listed in
annex D of this Recommended Standard.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– Russian Federal Space Agency (RFSA)/Russian Federation.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
DOCUMENT CONTROL
Document Title Date Status
CCSDS TC Synchronization and Channel September Original Issue
231.0-B-1 Coding, Issue 1 2003
CCSDS TC Synchronization and Channel September Current issue:
231.0-B-2 Coding, Recommended Standard, 2010 – adds an option for
Issue 2 repeated
transmissions of
Transfer Frames
(note).
NOTE – Substantive changes from the previous issue are indicated by change bars in the
inside margin.
CONTENTS
Section Page
1  INTRODUCTION . 1-1

1.1  PURPOSE . 1-1
1.2  SCOPE . 1-1
1.3  APPLICABILITY . 1-1
1.4  RATIONALE . 1-2
1.5  DOCUMENT STRUCTURE . 1-2
1.6  CONVENTIONS AND DEFINITIONS. 1-2
1.7  REFERENCES . 1-5

2  OVERVIEW . 2-1

2.1  ARCHITECTURE . 2-1
2.2  SUMMARY OF FUNCTIONS . 2-1
2.3  INTERNAL ORGANIZATION OF SUBLAYER . 2-3

3  BCH CODING . 3-1

3.1  INTRODUCTION . 3-1
3.2  CODEBLOCK FORMAT . 3-1
3.3  ENCODING PROCEDURE . 3-1
3.4  FILL DATA . 3-2
3.5  DECODING PROCEDURE . 3-3

4.1  INTRODUCTION . 4-1
4.2  CLTU UNIT FORMAT . 4-1
4.3  CLTU RECEPTION LOGIC . 4-2

5  RANDOMIZER . 5-1

5.1  INTRODUCTION . 5-1
5.2  RANDOMIZER DESCRIPTION . 5-1
5.3  APPLICATION OF THE RANDOMIZER . 5-2

6  PHYSICAL LAYER OPERATIONS PROCEDURES . 6-1

6.1  INTRODUCTION . 6-1
6.2  DATA FORMATS . 6-1
6.3  CARRIER MODULATION MODES . 6-2
RECOMMENDED STANDARD FOR TC SYNCHRONIZATION AND CHANNEL CODING
CONTENTS (continued)
Section Page
6.4  PLOP-1 . 6-3
6.5  PLOP-2 . 6-4

7  MANAGED PARAMETERS . 7-1

7.1  OVERVIEW OF MANAGED PARAMETERS . 7-1
7.2  MANAGED PARAMETERS FOR BCH CODING . 7-1
7.3  MANAGED PARAMETERS FOR CLTU . 7-1
7.4  MANAGED PARAMETERS FOR THE RANDOMIZER . 7-2
7.5  MANAGED PARAMETERS FOR PLOPS . 7-2

ANNEX A SERVICE DEFINITION (NORMATIVE) . A-1
ANNEX B ACRONYMS AND TERMS (INFORMATIVE) .B-1
ANNEX C INFORMATIVE REFERENCES (INFORMATIVE) . C-1
ANNEX D CHANGES FROM REFERENCE [C2] (INFORMATIVE) . D-1
Figure
2-1  Relationship with OSI Layers . 2-1
2-2  Internal Organization of the Sublayer at the Sending End . 2-3
2-3  Internal Organization of the Sublayer at the Receiving End . 2-4
3-1  BCH Codeblock Format . 3-1
3-2  (63,56) Modified BCH Code Generator . 3-2
4-1  Components of the CLTU . 4-1
4-2  CLTU Reception State Diagram (Receiving End) . 4-2
5-1  Bit Transition Generator Logic Diagram . 5-2
6-1  Sequence of CMMs Composing PLOP-1 . 6-4
6-2  Sequence of CMMs Composing PLOP-2 . 6-5

Table
4-1  CLTU Reception States (Receiving End) . 4-3
4-2  CLTU Reception Events (Receiving End) . 4-3
6-1  Carrier Modulation Modes . 6-3
7-1  Managed Parameters for BCH Coding . 7-1
7-2  Managed Parameters for CLTU . 7-1
7-3  Managed Parameters for Randomizer. 7-2
7-1  Managed Parameters for Repeated Transmissions . 7-2
7-4  Managed Parameters for PLOPs . 7-2
D-1  Terms That Have Been Changed from Reference [C2] . D-2
CCSDS 231.0-B-2 Page vii September 2010
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommended Standard is to specify synchronization and channel
coding schemes used with the Telecommand (TC) Space Data Link Protocol (reference [1]).
These schemes are to be used over ground-to-space or space-to-space communications links
by space missions.
1.2 SCOPE
This Recommended Standard defines synchronization and channel coding schemes in terms
of:
a) the services provided to the users of this specification;
b) data formats; and
c)
It does not specify:
a) individual implementations or products;
b) the methods or technologies required to perform the procedures; or
c) the management activities required to configure and control the system.
1.3 APPLICABILITY
This Recommended Standard applies to the creation of Agency standards and to the future
data communications over space links between CCSDS Agencies in cross-support situations.
This Recommended Standard includes comprehensive specification of the data formats and
procedures for inter-Agency cross support. It is neither a specification of, nor a design for,
real systems that may be implemented for existing or future missions.
The Recommended Standard specified in this document is to be invoked through the normal
standards programs of each CCSDS Agency, and is applicable to those missions for which
cross support, based on capabilities described in this Recommended Standard, is anticipated.
Where mandatory capabilities are clearly indicated in sections of this Recommended
Standard, they must be implemented when this document is used as a basis for cross support.
Where options are allowed or implied, implementation of these options is subject to specific
bilateral cross support agreements between the Agencies involved.
1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the
recommendations chosen, so that future evaluations of proposed changes or improvements
will not lose sight of previous decisions.
1.5 DOCUMENT STRUCTURE
This document is divided into seven numbered sections and four annexes:
a) section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the conventions, definitions, and references used
throughout the Recommended Standard;
b) section 2 provides an overview of synchronization and channel coding;
c) section 3 specifies the Bose-Chaudhuri-Hocquenghem (BCH) coding;
d) section 4 specifies the Communications Link Transmission Unit (CLTU);
e) section 5 specifies the randomizer;
f) section 6 specifies the Physical Layer Operations Procedures (PLOPs);
g) section 7 lists the managed parameters associated with synchronization and channel
coding;
h) annex A defines the service provided to the users;
i) annex B lists acronyms and terms used within this document;
j) annex C provides a list of informative references;
k) D lists the changes from the older CCSDS Recommended Standard (reference
[C2]).
1.6 CONVENTIONS AND DEFINITIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from the Open Systems Interconnection (OSI) Basic Reference
Model
This Recommended Standard makes use of a number of terms defined in reference [2]. The
use of those terms in this Recommended Standard shall be understood in a generic sense; i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are as follows:
a) Data Link Layer;
b) Physical Layer;
c) service;
d) service data unit.
1.6.1.2 Definitions from OSI Service Definition Conventions
This Recommended Standard makes use of a number of terms defined in reference [3]. The
use of those terms in this Recommended Standard shall be understood in a generic sense; i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are as follows:
a) indication;
b) primitive;
c) request;
d) service provider;
e) service user.
1.6.1.3 Terms Defined in This Recommended Standard
For the purposes of this Recommended Standard, the following definitions apply. Many
other terms that pertain to specific items are defined in the appropriate sections.
asynchronous: not synchronous.
Mission Phase: a period of a mission during which specified communications
characteristics are fixed. The transition between two consecutive mission phases may cause
an interruption of the communications services.
Physical Channel: a stream of bits transferred over a space link in a single direction.
space link: a communications link between a spacecraft and its associated ground system or
between two spacecraft. A space link consists of one or more Physical Channels in one or
both directions.
1.6.2 NOMENCLATURE
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.6.3 CONVENTIONS
In this document, the following convention is used to identify each bit in an 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’.
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’ (see figure 1-1).
BITN-1
BIT 0
N-BIT DATA FIELD
FIRST BIT TRANSMITTED = MSB
Figure 1-1: Bit Numbering Convention
In accordance with standard data-communications practice, data fields are often grouped into
8-bit ‘words’ which conform to the above convention. Throughout this Recommended
Standard, such an 8-bit word is called an ‘octet’. The numbering for octets within a data
structure starts with 0. By CCSDS convention, all ‘spare’ bits shall be permanently set to
‘0’.
RECOMMENDED STANDARD FOR TC SYNCHRONIZATION AND CHANNEL CODING
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
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 Recommended Standards.
[1] TC Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 232.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, July 2010.
[2] Information Technology—Open Systems Interconnection—Basic Reference Model:
The Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO,
1994.
[3] Information Technology—Open Systems Interconnection—Basic Reference Model—
Conventions for the definition of OSI services. International Standard, ISO/IEC
10731:1994. Geneva: ISO, 1994.
[4] Radio Frequency and Modulation Systems—Part 1: Earth Stations and Spacecraft.
Recommendation for Space Data System Standards, CCSDS 401.0-B-20. Blue Book.
Issue 20. Washington, D.C.: CCSDS, April 2009.
[5] Space Link Extension—Forward CLTU Service Specification. Recommendation for
Space Data System Standards, CCSDS 912.1-B-3. Blue Book. Issue 3. Washington,
D.C.: CCSDS, July 2010.
NOTE – Informative references are listed in annex C.

CCSDS 231.0-B-2 Page 1-5 September 2010
2 OVERVIEW
2.1 ARCHITECTURE
Figure 2-1 illustrates the relationship of this Recommended Standard to the Open Systems
Interconnection (OSI) reference model (reference [2]). Two sublayers of the Data Link
Layer are defined for CCSDS space link protocols. The TC Space Data Link Protocols
specified in reference [1] corresponds to the Data Link Protocol Sublayer, and provides
functions for transferring data using the protocol data unit called the Transfer Frame. The
Synchronization and Channel Coding Sublayer provides additional functions necessary for
transferring Transfer Frames over a space link. These functions are error-control
coding/decoding, delimiting/synchronizing codeblocks, and bit transition
generation/removal.
CCSDS
OSI LAYERS CCSDS LAYERS
PROTOCOLS
NETWORK AND NETWORK AND
UPPER LAYERS UPPER LAYERS
DATA LINK
TCSPACEDATALINK
PROTOCOL
PROTOCOL
SUBLAYER
DATA LINK LAYER
SYNCHRONIZATION TC SYNCHRONIZATION
AND CHANNEL AND
CODING SUBLAYER CHANNEL CODING
PHYSICAL LAYER PHYSICAL LAYER
Figure 2-1: Relationship with OSI Layers
2.2 SUMMARY OF FUNCTIONS
2.2.1 FUNCTIONS
The Synchronization and Channel Coding Sublayer provides the following four functions for
transferring Transfer Frames over a space link:
error-control coding;
b) synchronization;
c) pseudo-randomizing (optional); and
d) repeated transmissions (optional).
2.2.2 ERROR-CONTROL CODING
This Recommended Standard specifies an error-control coding method using a modified
BCH code. This is described in section 3.
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.
If the modified BCH code is decoded in an error-detecting mode, the Frame Error Control
Field (FECF) defined in reference [1] may be used to reduce the probability of undetected
errors.
NOTE – In this Recommended Standard, the characteristics of the codes are specified only
to the extent necessary to ensure interoperability and cross-support. The
specification does not attempt to quantify the relative coding gain or the merits of
each approach discussed, nor the design requirements for encoders or decoders.
2.2.3 SYNCHRONIZATION
This Recommended Standard specifies a method for synchronizing BCH Codeblocks using a
data unit called the Communications Link Transmission Unit (CLTU), which consists of a
Start Sequence, BCH Codeblocks, and a Tail Sequence. This is described in section 4.
The Start Sequence of the CLTU may also be used for resolution of data ambiguity (sense of
‘1’ and ‘0’) if data ambiguity is not resolved by the modulation method used in the Physical
Layer.
This Recommended Standard also specifies a procedure called the Physical Layer Operations
Procedure (PLOP) for activating and deactivating the physical communications channel so
that the Physical Layer of the receiving end can achieve and maintain bit synchronization.
NOTE – Although PLOP belongs to the Physical Layer, it is included in this
Recommended Standard because it must be used to transmit CLTUs specified in
this document. The other specifications of the Physical Layer are contained in
reference [4].
2.2.4 PSEUDO-RANDOMIZING
This Recommended Standard specifies an optional randomizer to improve bit transition
density as an aid to bit synchronization. This is described in section 5.
NOTE – For brevity, the word ‘random’ is used in place of ‘pseudo-random’ throughout
this document. See annex B.
2.2.5 REPEATED TRANSMISSIONS
This Recommended Standard specifies an option for repeated transmissions of Transfer
Frames. Annex A contains the service definition for the user in a higher sublayer to request
data transfer, including an optional Repetitions parameter for repeated transmissions. This
Recommended Standard does not specify how the repeated transmissions are performed
within the Synchronization and Channel Coding Sublayer. Availability of the repeated
transmissions option is in accordance with parameters set by management.
2.3 INTERNAL ORGANIZATION OF SUBLAYER
2.3.1 SENDING END
Figure 2-2
At the sending end, the Synchronization and Channel Coding Sublayer accepts Transfer
Frames from the Data Link Protocol Sublayer (see figure 2-1), performs functions selected
for the mission, and delivers CLTUs to the Physical Layer. If necessary, fill data are added
either before or after randomization to complete the integral number of BCH Codeblocks.
The Physical Layer transmits CLTUs using the PLOP.
Data Link ProtocolSublayer
Transfer Frames
Random Sequence Generation (optional)
(Randomized) Transfer Frames
BCH Encoding
BCH Codeblocks
CLTU Generation
CLTUs
Physical Layer
Physical Layer Operations Procedure (PLOP)
Modulated Radio Waveforms
Figure 2-2: Internal Organization of the Sublayer at the Sending End
RECOMMENDED STANDARD FOR TC SYNCHRONIZATION AND CHANNEL CODING
2.3.2 RECEIVING END
Figure 2-3 shows the internal organization of the Synchronization and Channel Coding
Sublayer of the receiving end. This figures identifies functions performed by the sublayer
and shows logical relationships among these functions. The figure is not intended to imply
any hardware or software configuration in a real system.
At the receiving end, the Synchronization and Channel Coding Sublayer accepts streams of
channel bits together with information on the state of the physical communications channel
from the Physical Layer, performs functions selected for the mission, and delivers Transfer
Frames (possibly incomplete or with fill data) to the Data Link Protocol Sublayer.
Data Link ProtocolSublayer
Transfer Frames (+Fill)
Random Sequence Removal (optional)
(Randomized) Transfer Frames (+Fill)
BCH Decoding
BCH Codeblocks+Tail Sequence
Search for Start Sequence
Channel Bits
Physical Layer
Figure 2-3: Internal Organization of the Sublayer at the Receiving End

CCSDS 231.0-B-2 Page 2-4 September 2010
3 BCH CODING
3.1 INTRODUCTION
The Synchronization and Channel Coding Sublayer establishes the reliable, error-controlled
data channel through which user data bits may be transferred. The data are encoded to
reduce the effects of noise in the Physical Layer on the user data. A modified Bose-
Chaudhuri-Hocquenghem (BCH) code has been chosen to provide this protection.
3.2 CODEBLOCK FORMAT
3.2.1 The BCH Codeblock format is a fixed-length data entity shown in figure 3-1. The
Codeblock is formulated using a systematic coding technique which contains 56 information
bits in the leading octets, and the error control bits in the last octet. The BCH Codeblock
contains an integer number of octets with an overall length of 8 octets (64 bits).
BCH CODEBLOCK
INFORMATION ERROR CONTROL
I , I , I ,…, I P' ,P' ,…,P' F
0 1 2 55 0 1 6 0
56 INFORMATION BITS (may be 7PARITY CHECK APPENDED
randomized) BITS FILLER BIT
Figure 3-1: BCH Codeblock Format
3.2.2 The COMPLEMENTS of the seven parity check bits, P through P , are located in
0 6
the first seven bits of the last octet of the BCH Codeblock. The complements are used to aid
in maintaining bit synchronization and detection of bit slippage. The encoding procedure for
generating these parity bits is described in 3.3.
3.2.3 The last bit of the last octet, F , is a Filler Bit appended to provide an overall
Codeblock length which is an integer number of octets. This Filler Bit shall always be a
zero.
3.3
3.3.1 A systematic block coding procedure shall be used which always generates 7 parity
check bits per Codeblock and which shall always be computed from 56 information bits.
The parity check bits are then COMPLEMENTED and placed into the Codeblock as shown
in figure 3-1.
3.3.2 The code used is a (63,56) modified Bose-Chaudhuri-Hocquenghem (BCH) code
which uses the following generator polynomial to produce the seven parity bits:
7 6 2
g(x) = x + x + x + 1
NOTE – The code generator implementation is shown in figure 3-2. The shift registers are
initialized to zero. The ganged switch is in position 1 while the 56 information
bits are being transmitted, in position 2 for the seven parity bits, and in position 3
for the appended Filler Bit.
INFORMATION BITS I •• •  I
0 55
CODED
DATA
(1) (1) OUTPUT
(2) (2)
(3)
(3)
ZERO
PP PP
P P P ZERO
6 43 10
5 2
0 2 3 5 6
1 4
I
X X X X X
X X
PARITY BITS
Figure 3-2: (63,56) Modified BCH Code Generator
3.4 FILL DATA
3.4.1 If the Transfer Frame(s) to be transmitted in a Communications Link Transmission
Unit (CLTU) do not fit exactly within an integral number of BCH Codeblocks, then the last
octet(s) and ONLY the last octet(s) of the information field of the last Codeblock within the
CLTU may contain ‘Fill’ bits. The pattern of the fill shall consist of a sequence of
alternating ‘ones’ and ‘zeros’, starting with a ‘zero’.
3.4.2 The Synchronization and Channel Coding Sublayer may require the introduction of
these fill data in the encoding process; they are not removed by the decoding process.
Removal of fill is the responsibility of the sublayer above, which delimits the end of the
Transfer Frame(s) and discards extraneous bits (e.g., fill).
3.4.3 If randomization is used, the fill data mentioned above shall be added either before or
after randomization.
NOTE – If randomization is being used, any fill octets that were added to the last
Codeblock of the CLTU will be derandomized even if they were not randomized.
RECOMMENDED STANDARD FOR TC SYNCHRONIZATION AND CHANNEL CODING
3.5 DECODING PROCEDURE
Codeblocks 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 Codeblock (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 – The decoding procedure described in 3.5 assumes the use of a hard-limiting
detector before decoding, but the use of a soft-limiting detector is not intended to
be precluded.
Page 3-3 September 2010
4 COMMUNICATIONS LINK TRANSMISSION UNIT
4.1 INTRODUCTION
4.1.1 Synchronization for the Codeblock and delimiting of the beginning of user data are
provided by the Communications Link Transmission Unit (CLTU) data structure.
4.1.2 Resolution of data ambiguity (sense of ‘1’ and ‘0’) when receiving the symbol stream
shall be a service of the Synchronization and Channel Coding Sublayer if it is not performed
by the Physical Layer (e.g., with a differential modulation technique). In the
Synchronization and Channel Coding Sublayer, ambiguity resolution shall use inherent
information in the CLTU Start Sequence.
4.2 CLTU UNIT FORMAT
4.2.1 STRUCTURE OF CLTU
The CLTU is the data structure which carries the data as a contiguous series of encoded BCH
Codeblocks across the Synchronization and Channel Coding Sublayer. The data contained in
the BCH Codeblocks in the CLTU consist of Transfer Frame(s) from the sublayer above
(possibly with fill data). The CLTU has the structural components shown in figure 4-1.
COMMUNICATIONS LINK TRANSMISSION UNIT
START TAIL
ENCODED DATA
SEQUENCE SEQUENCE
LENGTH OF
16 BITS BCH CODEBLOCKS
ONE BCH
CODEBLOCK
Figure 4-1: Components of the CLTU
START SEQUENCE
The CLTU Start Sequence field shall delimit the start of the encoded data within the CLTU.
It consists of a 16-bit synchronization pattern with low autocorrelation side lobes and shall
have the following pattern:
111 0 1 0 1 11 00 1 0000
BIT 0 BIT 15
4.2.3 ENCODED DATA
The Encoded Data field shall consist of a set of BCH Codeblocks which have been encoded
in accordance with the BCH Codeblock encoding procedure. In addition to error control bits,
these Codeblocks contain the Transfer frame(s), plus any fill data that were appended to meet
codeblock length constraints. The Transfer Frames contained in the Encoded Data field may
have been randomized before encoding, or not randomized, as selected for the mission.
4.2.4 TAIL SEQUENCE
The CLTU Tail Sequence field is a data structure which is constructed specifically to be a
noncorrectable sequence which delimits the end of a CLTU by stopping the decoding
process. The Tail Sequence shall have the same length as the BCH Codeblock that is being
used. The Tail Sequence shall consist of leading octets having the pattern 11000101,
repeated as necessary until the next-to-last octet of the Tail Sequence field is reached. The
last octet completes the Tail Sequence field, and always has the pattern 01111001.
Therefore, the bit pattern for the standard Tail Sequence may be described as follows:
Tail Sequence Pattern
11000101 11000101 11000101 11000101 11000101 11000101 11000101 01111001
NOTE – A pattern of alternating ‘zeros’ and ‘ones’ identical to the Idle Sequence
throughout the length of a Codeblock was defined in the first issue of reference
[C2]. The new pattern introduced later and specified above is preferred for new
designs because of its improved performance.
4.3 CLTU RECEPTION LOGIC
The CLTU Reception Logic at the receiving end is presented in state diagram form (figure
4-2). To support the state diagrams, a list of ‘states’ and ‘events’ is given in tables 4-1 and
4-2. There are three states and four events.
E4
E1 E3
S1 S2 S3
(INACTIVE) (SEARCH) (DECODE)
E2
E2
Figure 4-2: CLTU Reception State Diagram (Receiving End)
RECOMMENDED STANDARD FOR TC SYNCHRONIZATION AND CHANNEL CODING

Table 4-1: CLTU Reception States (Receiving End)
State State State
Number Name Definition
S1 INACTIVE The communications channel is INACTIVE
(i.e., ‘no bit lock is achieved’, or, alternatively,
‘no bit modulation is detected’).
S2 SEARCH The incoming bit stream is searched, bit by bit,
for the Start Sequence pattern.
S3 DECODE BCH Codeblocks, which are either free of error
or which can be corrected, are received,
decoded, and derandomized (if used), and
their contents are transferred to the sublayer
above.
Table 4-2: CLTU Reception Events (Receiving End)

Event Event Event
Number Name Definition
E1 CHANNEL Bit modulation is detected and bit lock is
ACTIVATION achieved: channel bit stream is present.
E2 CHANNEL Bit lock is lost or communications signal is lost:
DEACTIVATION channel bit stream is NOT present.
E3 START The Start Sequence pattern has been
SEQUENCE detected, signaling the beginning of the first
FOUND Codeblock of the CLTU.
E4 CODEBLOCK The decoder has indicated uncorrected errors
REJECTION in a Codeblock. No data from this Codeblock
are transferred to the sublayer above.
NOTE – 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.
CCSDS 231.0-B-2 Page 4-3 September 2010
5 RANDOMIZER
5.1 INTRODUCTION
5.1.1 In order to maintain bit (or symbol) synchronization with the received
communications signal, every data capture system at the receiving end requires that the
incoming signal must have a minimum bit transition density (see subsection 2.2.3 in
reference [4]).
5.1.2 In order to ensure proper receiver operation, the data stream must be sufficiently
random. The Pseudo-Randomizer defined in this section is the preferred method to ensure
sufficient randomness for all combinations of CCSDS-recommended modulation and coding
schemes. 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.
5.1.3 The presence or absence of randomization is fixed for a Physical Channel and is
managed (i.e., its presence or absence is not signaled but must be known a priori by the
receiver). A random sequence is exclusively ORed with the Transfer Frame(s) to increase
the frequency
...