![](media/image1.emf){width="4.416666666666667in"
height="1.2777777777777777in"}

**RECOMMENDATION FOR SPACE**

**DATA SYSTEM STANDARDS**

+-----------------------------------------------------------------------+
| **TELECOMMAND**                                                       |
|                                                                       |
| PART 1                                                                |
|                                                                       |
| CHANNEL SERVICE                                                       |
+-----------------------------------------------------------------------+

**CCSDS 201.0-B-3**

**BLUE BOOK**

June 2000

![](media/image2.emf){width="4.125in" height="1.9305555555555556in"}

AUTHORITY

  ---- -------------------- ------------------------------------------ ----
                                                                       

       Issue:               Blue Book, Issue 3                         

       Date:                June 2000                                  

       Location:            Toulouse, France                           

                                                                       
  ---- -------------------- ------------------------------------------ ----

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 \[C1\], and the record of
Agency participation in the authorization of this document can be
obtained from 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

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 from 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.

FOREWORD

This document, which is a technical Recommendation prepared by the
Consultative Committee for Space Data Systems (CCSDS), is intended for
use by participating space Agencies in their development of space
telecommand systems.

This Recommendation allows the implementing organizations within each
Agency to proceed coherently with the development of compatible
Standards for the flight and ground systems that are within their
cognizance. Agency Standards derived from this Recommendation may
implement only a subset of the optional features allowed herein, or may
incorporate features not addressed by the Recommendation.

In order to establish a common framework within which the Agencies may
develop standardized telecommand services, the CCSDS advocates adoption
of a layered systems architecture. Within this approach, specific layers
of service (including their operational protocol and data structuring
techniques) may be selected for implementation according to mission
requirements.

The current layered set of CCSDS telecommand Recommendations was
developed to match the conventional free-flying mission environment, as
characterized by the transmission of command data at relatively low
uplink data rates to spacecraft of moderate complexity. The CCSDS is
currently examining the extension of these Recommendations (perhaps by
defining expanded protocols and data structures within some of the
layers) to a more complex mission environment, including the
transmission of multiple data types at very high data rates to space
vehicles which include extensive onboard data networking capability.

This Recommendation for Telecommand Channel Service was developed within
the layered architectural framework, and embraces the standard data
structures and data communication procedures which may be used by
conventional missions within the lowest telecommand system layers.

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

http://www.ccsds.org/

Questions relative 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]{.underline}

> -- Agenzia Spaziale Italiana (ASI)/Italy.
>
> -- British National Space Centre (BNSC)/United Kingdom.
>
> -- Canadian Space Agency (CSA)/Canada.
>
> -- Central Research Institute of Machine Building (TsNIIMash)/Russian
> Federation.
>
> -- Centre National d\'Etudes Spatiales (CNES)/France.
>
> -- Deutsche Forschungsanstalt für 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 HQ)/USA.
>
> -- National Space Development Agency of Japan (NASDA)/Japan.

[Observer Agencies]{.underline}

> -- Australian Space Office (ASO)/Australia.
>
> -- Austrian Space Agency (ASA)/Austria.
>
> -- Belgian Science Policy Office (SPO)/Belgium.
>
> -- Centro Tecnico Aeroespacial (CTA)/Brazil.
>
> -- Chinese Academy of Space Technology (CAST)/China.
>
> -- Communications Research Laboratory (CRL)/Japan.
>
> -- Danish Space Research Institute (DSRI)/Denmark.
>
> -- European Organization for the Exploitation of Meteorological
> Satellites (EUMETSAT)/Europe.
>
> -- European Telecommunications Satellite Organization
> (EUTELSAT)/Europe.
>
> -- Hellenic National Space Committee (HNSC)/Greece.
>
> -- Indian Space Research Organization (ISRO)/India.
>
> -- Industry Canada/Communications Research Centre (CRC)/Canada.
>
> -- Institute of Space and Astronautical Science (ISAS)/Japan.
>
> -- Institute of Space Research (IKI)/Russian Federation.
>
> -- KFKI Research Institute for Particle & Nuclear Physics
> (KFKI)/Hungary.
>
> -- MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
>
> -- Ministry of Communications (MOC)/Israel.
>
> -- National Oceanic & Atmospheric Administration (NOAA)/USA.
>
> -- National Space Program Office (NSPO)/Taiwan.
>
> -- Swedish Space Corporation (SSC)/Sweden.
>
> -- United States Geological Survey (USGS)/USA.

DOCUMENT CONTROL

+-----------+----------------------+------------+----------------------+
| **D       | **Title and Issue**  | **Date**   | **Status**           |
| ocument** |                      |            |                      |
+-----------+----------------------+------------+----------------------+
| CCSDS     | Telecommand Part     | January\   | Original Issue       |
| 201.0-B-1 | 1---Channel Service, | 1987       |                      |
|           | Issue 1              |            |                      |
+-----------+----------------------+------------+----------------------+
| CCSDS     | Telecommand Part     | November   | Superseded           |
| 201.0-B-2 | 1---Channel Service, | 1995       |                      |
|           | Issue 2              |            | -- the Tail Sequence |
|           |                      |            | was replaced with a  |
|           |                      |            | new, more            |
|           |                      |            | distinctive pattern, |
|           |                      |            | which is more        |
|           |                      |            | reliably recognized  |
|           |                      |            | at the end of a      |
|           |                      |            | CLTU;                |
|           |                      |            |                      |
|           |                      |            | -- an option was     |
|           |                      |            | added for            |
|           |                      |            | randomizing the      |
|           |                      |            | Telecommand data to  |
|           |                      |            | increase bit         |
|           |                      |            | transitions, for     |
|           |                      |            | those command        |
|           |                      |            | systems that require |
|           |                      |            | frequent bit         |
|           |                      |            | transitions to       |
|           |                      |            | maintain reliable    |
|           |                      |            | bit synchronization; |
|           |                      |            |                      |
|           |                      |            | -- minor format      |
|           |                      |            | changes were made    |
|           |                      |            | based on             |
|           |                      |            | specifications of    |
|           |                      |            | the CCSDS            |
|           |                      |            | Publications Manual. |
+-----------+----------------------+------------+----------------------+
| CCSDS     | Telecommand Part     | June\      | Current Issue        |
| 201.0-B-3 | 1---Channel Service, | 2000       |                      |
|           | Issue 3              |            | -- codeblock length  |
|           |                      |            | options have been    |
|           |                      |            | eliminated in favor  |
|           |                      |            | of a single standard |
|           |                      |            | length of 64 bits    |
|           |                      |            | (the longest and     |
|           |                      |            | most efficient of    |
|           |                      |            | the options          |
|           |                      |            | specified in the     |
|           |                      |            | previous issue).     |
+-----------+----------------------+------------+----------------------+

NOTE -- Substantive changes from the previous issue are indicated with
change bars in the outside margin.

CONTENTS

Section Page

1 INTRODUCTION 1-1

1.1 PURPOSE AND SCOPE 1-1

1.2 APPLICABILITY 1-1

1.3 BIT NUMBERING CONVENTION AND NOMENCLATURE 1-2

1.4 REFERENCES 1-2

2 TELECOMMAND CHANNEL SERVICE OVERVIEW 2-1

3 CODING LAYER: STANDARD DATA STRUCTURES\
AND PROCEDURES 3-1

3.1 OVERVIEW OF THE CODING LAYER 3-1

3.2 STANDARD DATA STRUCTURES WITHIN THE CODING LAYER 3-1

3.3 STANDARD PROCEDURES WITHIN THE CODING LAYER 3-3

4 PHYSICAL LAYER: STANDARD DATA STRUCTURES\
AND PROCEDURES 4-1

4.1 OVERVIEW OF THE PHYSICAL LAYER 4-1

4.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 4-1

4.3 STANDARD PROCEDURES WITHIN THE LAYER 4-2

ANNEX A CHANNEL SERVICE ACRONYMS AND TERMINOLOGY A-1

ANNEX B CHANNEL SERVICE SPECIFICATION B-1

ANNEX C INFORMATIVE REFERENCES C-1

Figure

2-1 Telecommand System 2-2

3-1 Telecommand Codeblock Format 3-1

3-2 Components of the CLTU 3-2

3-3 Bit Transition Generator Logic Diagram 3-4

3-4 (63,56) Modified BCH Code Generator 3-5

3-5 TC Channel Service State Diagram (Receiving End) 3-7

4-1 Sequence of CMMs Comprising PLOP-1 4-3

4-2 Sequence of CMMs Comprising PLOP-2 4-5

B-1 TC Channel Service Model B-2

B-2 Sequence of Functions B-4

CONTENTS (continued)

Table Page

3-1 TC Channel Service States (Receiving End) 3-6

3-2 TC Channel Service Events (Receiving End) 3-6

4-1 Carrier Modulation Modes 4-2

B-1 Processing of CLTU Elements B-9

B-2 Recommended Strategies B-9

# INTRODUCTION

## PURPOSE AND SCOPE

The purpose of this document is to establish a common Recommendation
which defines the systems architecture of a spacecraft telecommand
"Channel Service". The intent of this architecture is to provide a
common framework within which the Agencies participating in the
Consultative Committee for Space Data Systems (CCSDS) may implement
compatible future spacecraft telecommanding systems.

This Recommendation primarily addresses the data unit formats and
functions which are implemented within the Coding layer and the Physical
layer of the CCSDS telecommand Channel Service. **THE ASSOCIATED
DETAILED OPERATIONAL PROTOCOLS WHICH OPERATE ACROSS THESE LAYERS, AND
THE FLOW OF CONTROL INFORMATION REQUIRED TO INITIALIZE THE LAYERS AND
DIRECT THE TRANSFER OF DATA BETWEEN THEM, ARE NOT PRESENTLY ADDRESSED
WITHIN THIS DOCUMENT: THESE REMAIN ITEMS FOR POTENTIAL EXTENSION OF THIS
RECOMMENDATION**.

The operating principles and procedures for the CCSDS are defined in
Reference \[C1\]. The context of the Channel Service within the overall
Telecommand System is described in Reference \[C2\]. This is a working
document, subject to update as experience is gained, which provides an
inter-Agency coordination mechanism that ensures that compatible
implementations are facilitated.

## APPLICABILITY

This Recommendation serves as a guideline for the development of
compatible internal Agency standards in the field of spacecraft
commanding. This Recommendation is not retroactive, nor does it commit
any Agency to implement the recommended telecommand concepts at any
future time. Nevertheless, all CCSDS Agencies accept the principle that
all future implementations of telecommand which are used in
cross-support situations will be based on this Recommendation.

The CCSDS has developed a layered concept for spacecraft telecommanding,
which is fully described in Reference \[C2\]. Standard services are
defined within each layer, and Agencies will be encouraged to develop
corresponding facilities to provide these services in support of
Projects. To be fully compatible with the CCSDS concept, a Project's
telecommanding architecture should follow this Recommendation for
Channel Service, plus the Recommendations for telecommand "Data
Management Service" and telecommand "Data Routing Service" which are
described in References \[1\] and \[2\], respectively. Projects may also
elect to be partially compatible with the concept by interfacing with
the standard systems at intermediate layers within any of the service
specifications.

## BIT NUMBERING CONVENTION AND NOMENCLATURE

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".

![](media/image3.emf){width="6.041666666666667in"
height="2.013888888888889in"}

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:

![](media/image4.emf){width="3.013888888888889in"
height="0.5138888888888888in"}

By CCSDS convention, all "spare" bits shall be permanently set to value
zero.

Note that throughout this document, the word "Telecommand" may be
abbreviated as "TC".

## REFERENCES

The following documents are referenced in the text of 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 docu­ments indicated below. The CCSDS
Secretariat maintains a register of currently valid CCSDS
Recommendations.

\[1\] *Telecommand Part 3 --- Data Management Service*. Recommendation
for Space Data Systems Standards, CCSDS 203.0-B-1. Blue Book. Issue 1.
Washington, D.C.: CCSDS, January 1987.

\[2\] *Telecommand Part 2 --- Data Routing Service*. Recommendation for
Space Data Systems Standards, CCSDS 202.0-B-2. Blue Book. Issue 2.
Washington, D.C.: CCSDS, November 1992.

\[3\] *Radio Frequency and Modulation Systems---Part 1: Earth Stations
and Spacecraft*. Recommendations for Space Data System Standards, CCSDS
401.0-B. Blue Book. Washington, D.C.: CCSDS, May 2000.

The latest issues of these documents may be obtained from the CCSDS
Secretariat at the address indicated on page i.

# TELECOMMAND CHANNEL SERVICE OVERVIEW

A complete summary of the terminology which is used internal to this
document is presented in Annex A.

The TC Channel Service (see Figure 2-1) enables an error-controlled data
path to be established for the transfer of telecommands to the
spacecraft. The service contains two distinct layers of data handling
operations:

\(1\) A **CODING LAYER,** which permits telecommand information bits to
be more reliably transmitted through the noisy physical data channel
using standard channel coding techniques. The Coding layer also provides
information about the beginning of the contents of valid codeblocks and
the continuity of the data stream, and it delivers the contents of those
codeblocks to the layer above.

\(2\) A **PHYSICAL LAYER,** which contains the radio frequency and
modulation capabilities that may be invoked to establish the physical
data channel: these capabilities are fully described in Reference \[3\]
and are only addressed within this document as required for clarity. The
Physical layer also contains **PHYSICAL LAYER OPERATIONS PROCEDURES**
(PLOPs) which provide the methods of activating and deactivating the
physical channel.

A complete, detailed specification of the services provided by each
layer within the Channel Service is presented in Annex B. The first-time
reader should digest Annex B before proceeding further in this document.

NOTES

1 Figure 2-1 represents a logical view of the TC System and physical
implementations may not necessarily correspond to the flow of operations
implied by the figure.

2 This Recommendation primarily specifies the data structures and
procedures flowing ACROSS the layers from the sending to the receiving
end of the TC System, since these have a direct impact on the long
lead-time design of future spacecraft hardware and software.
Comprehensive definition of the associated operational protocols within
each layer and the control instructions, which are required to
initialize the layers and to direct the flow of TC data units BETWEEN
the layers, remain items for potential future extension of this
document.

![](media/image5.wmf){width="6.013888888888889in"
height="7.402777777777778in"}

Figure 2-1: Telecommand System

# CODING LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

## OVERVIEW OF THE CODING LAYER

The Coding layer establishes the reliable, error-controlled data channel
through which user telecommand data bits may be transferred. The data
are encoded to reduce the effects of noise in the Physical layer channel
on the user data. A block code has been chosen to provide this
protection. Synchronization for the codeblock and delimiting of the
beginning of user data are provided by the Command Link Transmission
Unit (CLTU) data structure.

Resolution of data ambiguity (sense of "1" and "0") when receiving the
symbol stream shall be a service of the Coding layer. Data ambiguity may
result from the modulation technique utilized in the Physical layer such
as suppressed-carrier modulation. Ambiguity resolution techniques shall
use inherent information in the symbol stream such as either the CLTU
start sequence pattern or NRZ-M modulation.

Standard procedures for randomizing, encoding, and handling fill bits
are described in 3.3.

## STANDARD DATA STRUCTURES WITHIN THE CODING LAYER

The standard data structures within the Coding layer are the TC
Codeblock and the CLTU.

### TC CODEBLOCK FORMAT

The TC 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 in the last octet. The TC Codeblock contains an integer number
of octets with an overall length of 8 octets (64 bits).

![](media/image6.wmf){width="6.0in" height="1.8194444444444444in"}

Figure 3-1: Telecommand Codeblock Format

The COMPLEMENTS of the seven parity check bits, P0 through P6, are
located in the first seven bits of the last octet of the TC 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.2.

The last bit of the last octet, F0, 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.

### COMMAND LINK TRANSMISSION UNIT (CLTU) FORMAT

The CLTU is the data structure which carries the TC data as a contiguous
series of encoded TC Codeblocks across the Channel Service. The encoded
TC data within the CLTU consist of Input Data from the layer above. The
CLTU has the structural components shown in Figure 3-2.

![](media/image7.emf){width="5.583333333333333in"
height="1.7916666666666667in"}

Figure 3-2: Components of the CLTU

**3.2.2.1 CLTU Start Sequence.** The CLTU Start Sequence field delimits
the start of the encoded TC data within the CLTU. It consists of a
16-bit synchronization pattern with low autocorrelation sidelobes and
shall have the following pattern:

![](media/image8.emf){width="2.7222222222222223in"
height="0.6527777777777778in"}

**3.2.2.2 Encoded TC Data.** The Encoded TC Data field consists of a set
of TC Codeblocks which have been encoded in accordance with the TC
Codeblock encoding procedure. In addition to error control bits, these
codeblocks contain the Input Data to this layer, plus any fill bits that
were appended to meet codeblock length constraints. The encoded TC data
field may have been randomized before encoding, or not randomized, as
selected for the mission. (For brevity, "random" is used in place of
"pseudo-random" throughout this document. See Annex A.)

**3.2.2.3 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 TC
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]{.underline}

11000101 11000101 11000101 11000101 11000101 11000101 11000101 01111001

## STANDARD PROCEDURES WITHIN THE CODING LAYER

The following subsections define the procedures for randomization of
Input Data and coding of TC Codeblocks.

### RANDOMIZATION PROCEDURE

In order to maintain bit (or symbol) synchronization with the received
telecommand signal, the incoming signal must have a minimum bit
transition density (see Recommendation 2.2.3 in Reference \[3\]).

If a sufficient bit transition density is not ensured for the channel by
other methods (e.g., by use of certain modulation techniques or data
that is phase-coherent with the subcarrier) then the randomizer defined
in this subsection is required. Its use is optional otherwise.

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 spacecraft and ground system). A random
sequence is exclusively ORed with the **Input Data** to increase the
frequency of bit transitions. On the receiving end, the same random
sequence is exclusively ORed with the decoded data, restoring the
original data form. The random sequence is generated by the Bit
Transition Generator (BTG).

**3.3.1.1 Random Sequence**. The random sequence shall be generated
using the following polynomial:

h(x) = x8 + x6 + x4 + x3 + x2 + x + 1

This sequence repeats after 255 bits, continuing as needed. The first 40
bits of the sequence are

1111 1111 0011 1001 1001 1110 0101 1010 0110 1000

Increasing
Time\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\>

Figure 3-3 is a basic logical diagram of the BTG.

![](media/image9.emf){width="5.722222222222222in"
height="2.5416666666666665in"}

Figure 3-3: Bit Transition Generator Logic Diagram

**3.3.1.2 Application of the Randomizer**. The randomization is applied
at the transmitting end, only to the Input Data. The BTG is preset to
the "all-ones" state and then is exclusively ORed, bit by bit, with the
Input Data until the process ends with the last bit of the Input Data.
The randomization may also be applied to the fill bits added after the
end of the Input Data to complete the last codeblock of the CLTU, but
this is optional.

At the receiving end, the derandomization is applied to the successfully
decoded TC data. The BTG remains in the "all-ones" state until the CLTU
Start Sequence has been detected. The BTG pattern is exclusively ORed,
bit by bit, to the successfully decoded data (after the Error Control
Bits have been removed). The BTG is reset to the "all-ones" state
following a failure of the decoder to successfully decode a TC codeblock
or other loss of TC data.

### TC CODEBLOCK ENCODING PROCEDURE

A systematic block coding procedure is used which always generates 7
parity check bits per codeblock and which is always computed from 56
information bits. The parity check bits are then COMPLEMENTED and placed
into the codeblock as shown in Figure 3-1.

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:

g(x) = x7 + x6 + x2 + 1

The code generator implementation is shown in Figure 3-4. Note that the
shift registers are initialized to zero. The ganged switch is in
position 1 while the 56 TC data bits are being transmitted, in position
2 for the seven parity bits, and in position 3 for the appended fill
bit.

![](media/image10.wmf){width="6.2444444444444445in"
height="3.053472222222222in"}

Figure 3-4: (63,56) Modified BCH Code Generator

### FILL BITS

If the Input Data do not fit exactly within an integral number of TC
Codeblocks, 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".

The Coding layer may require the introduction of these fill bits in the
encoding process; they are not removed by the decoding process. Removal
of fill is the responsibility of the layer above, which delimits the end
of the Input Data and discards extraneous bits (e.g., fill).

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.

### TC CHANNEL SERVICE LOGIC

The TC Channel Service Logic at the receiving end is presented in state
diagram form (Figure 3-5). To support the state diagrams, a list of
"states" and "events" is given in Tables 3-1 and 3-2. There are three
states and four events.

Table 3-1: TC Channel Service States (Receiving End)

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

State State State

Number Name Definition

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

S 1 INACTIVE The telecommand channel is INACTIVE (i.e.,

"no bit lock is achieved", or, alternatively,

"no bit modulation is detected".

S 2 SEARCH The incoming bit stream is searched, bit by

bit, for the Start Sequence pattern.

S 3 DECODE TC 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 layer above.

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

Table 3-2: TC Channel Service Events (Receiving End)

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

Event Event Event

Number Name Definition

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

E 1 CHANNEL Bit modulation is detected and bit lock is

ACTIVATION achieved: telecommand bit stream is present.

E 2 CHANNEL Bit lock is lost or telecommand signal is lost:

DEACTIVATION telecommand bit stream is NOT present.

E 3 START The Start Sequence pattern has been detected,

SEQUENCE signaling the beginning of the first

FOUND codeblock of the CLTU.

E 4 CODEBLOCK The decoder has indicated uncorrected errors

REJECTION in a codeblock. No data from this codeblock

are transferred to the layer above.

![](media/image11.emf){width="6.208333333333333in"
height="4.1666666666666664e-2in"}

![](media/image12.wmf){width="6.013888888888889in"
height="2.0277777777777777in"}

Figure 3-5: TC Channel Service State Diagram (Receiving End)

### TC CODEBLOCK DECODING PROCEDURES [^1]

Codeblocks that have been encoded using the modified BCH code described
in 3.3.2 may be decoded either in an error-detecting mode or in an
error-correcting mode, 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 used, one bit in error will be
corrected and two bits in error will be detected.

# PHYSICAL LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

## OVERVIEW OF THE PHYSICAL LAYER

The Physical layer provides the radio frequency data path which connects
the transmitting station to the spacecraft, and its associated Physical
Layer Operational Procedures (PLOPs), in order to support the
transmission of telecommand data.

## STANDARD DATA STRUCTURES WITHIN THE LAYER

The standard data structures within this layer are the Acquisition
Sequence, CLTU, and the Idle Sequence. They are used to provide
synchronization of the symbol stream, and are described below.

### ACQUISITION SEQUENCE

The Acquisition Sequence is a data structure forming a preamble which
provides for initial symbol synchronization within the incoming stream
of detected symbols. The length of the Acquisition Sequence shall be
selected according to the mission telecommand link performance
requirements but the preferred minimum length is 16 octets. The length
is not required to be an integral multiple of octets. The pattern of the
Acquisition Sequence shall be alternating "ones" and "zeros", starting
with either a "one" or a "zero".

### CLTU

The CLTU is the data structure (symbol sequence) furnished from the
layer above, and defined in 3.2.2. It contains the data symbols that are
to be transmitted to the spacecraft. Each codeblock within the CLTU,
having the format specified in 3.2.1, provides at least 2 data
transitions per codeblock. If the spacecraft symbol synchronization
design necessitates more frequent transitions, either the CLTU as
delivered to the physical layer must have been randomized as described
in 3.3.1 or the Physical Layer must invoke a technique (modulation type,
phase-coherent data and subcarrier, or other) to guarantee sufficiently
frequent transitions for adequate symbol synchronization.

### IDLE SEQUENCE

The Idle Sequence is the data structure which provides for maintenance
of symbol synchronization in the absence of CLTUs. The bit pattern is a
sequence of alternating "ones" and "zeros".[^2] The length of the Idle
Sequence is an unconstrained number of bits.

## STANDARD PROCEDURES WITHIN THE LAYER

Operations within the Physical layer begin with the activation of the
physical telecommand channel by invoking the radio frequency carrier and
modulation techniques. These techniques include provision of any
required command link subcarrier(s) and data modulation in order to
establish the physical connection from the transmitting station to the
proper spacecraft hardware.

### CARRIER MODULATION MODES

Carrier Modulation Modes (CMMs) consist of different states of data
modulation upon the RF carrier which creates the physical telecommand
channel. The physical methods of modulating the carrier, which may be
either spread spectrum (e.g., TDRSS) or subcarrier (e.g., conventional
ground station) techniques, are described in Reference \[3\]. The
Carrier Modulation Modes are shown in Table 4-1.

Table 4-1: Carrier Modulation Modes

![](media/image13.emf){width="4.021527777777778in"
height="0.10208333333333333in"}

Mode State

![](media/image13.emf){width="4.021527777777778in"
height="0.10208333333333333in"}

CMM-1 Unmodulated CARRIER only

CMM-2 CARRIER modulated with

ACQUISITION SEQUENCE

CMM-3 CARRIER modulated with

TC data (e.g., CLTU)

CMM-4 CARRIER modulated with

IDLE SEQUENCE

![](media/image13.emf){width="4.021527777777778in"
height="0.10208333333333333in"}

### TELECOMMAND SESSION

During a Telecommand Session, a series of CLTUs is transmitted to a
remote spacecraft. The session begins with the initial application of
the RF carrier (CMM-1) and ends with the removal of the carrier. The
path is further controlled (activated or deactivated) by the selection
of appropriate Physical Layer Operations Procedures (PLOPs).

### PHYSICAL LAYER OPERATIONS PROCEDURES (PLOPs)

A PLOP consists of a sequential application of the various CMMs in order
to activate and deactivate the physical telecommand channel. Two
procedures, PLOP-1 and PLOP-2, are currently defined. The selection of
PLOPs is mission-specific.

**4.3.3.1 PLOP-1.** PLOP-1 is a procedure for individually radiating
CLTUs, whereby the spacecraft TC decoder is always forced into the
INACTIVE state (S1) by deactivating the physical telecommand channel
after the end of transmission of each CLTU (or CLTU followed by an Idle
Sequence).

PLOP-1 invokes the sequence of CMMs shown in Figure 4-1. Note that
"unmodulated" is defined as the state in which no *telecommand*
modulation is present.

![](media/image14.wmf){width="4.513888888888889in"
height="5.583333333333333in"}

Figure 4-1: Sequence of CMMs Comprising PLOP-1

**4.3.3.2 PLOP-2.** PLOP-2 is a procedure whereby the physical
telecommand channel is not deactivated after each transmitted CLTU. The
termination of an individual CLTU is provided only through the data
path, using the CLTU Tail Sequence and, optionally, Idle Sequences. This
places the decoder in the SEARCH state (S2) after each CLTU. The decoder
is forced into the INACTIVE state (S1), by deactivating the physical
telecommand channel only at the end of transmission of a series of
CLTUs, which may be followed by an Idle Sequence or not.

It should be noted that when operating with PLOP-2, it is recommended to
systematically insert a minimum Idle Sequence of one octet between each
CLTU to eliminate the small but finite possibility of synchronization
lockout. Such a lockout may occur if the start pattern of one CLTU is
not detected (leaving the decoder in SEARCH state) and a start pattern
exists over the last bits of the last frame of that CLTU and the first
bits of its Tail Sequence. This creates an erroneous but temporary CLTU
start (DECODE state), causing the true start of the following CLTU to be
missed. The added Idle Sequence prevents this from happening.

PLOP-2 invokes the sequence of CMMs shown in Figure 4-2. Note that
"unmodulated" is defined as the state in which no *telecommand*
modulation is present.

![](media/image15.wmf){width="4.527777777777778in"
height="6.333333333333333in"}

Figure 4-2: Sequence of CMMs Comprising PLOP-2

########   CHANNEL SERVICE  ACRONYMS AND TERMINOLOGY

(THIS ANNEX **IS** PART OF THE RECOMMENDATION)

**Purpose:**

This Annex defines the key acronyms and terms which are used throughout
this Recommendation to describe activities within the Channel Service.

**ACRONYMS**

BCH: BOSE-CHAUDHURI-HOCQUENGHEM

BTG: BIT TRANSITION GENERATOR

CCSDS: CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS

CLTU: COMMAND LINK TRANSMISSION UNIT

CMM: CARRIER MODULATION MODE

MSB: MOST SIGNIFICANT BIT

NRZ-M: NON-RETURN-TO-ZERO-MARK

PLOP: PHYSICAL LAYER OPERATIONS PROCEDURE

TC: TELECOMMAND

**TERMINOLOGY**

Terminology for the overall CCSDS Telecommand concept is summarized in
Reference \[C2\]. Key elements of Channel Service terminology, as used
in this document, are defined in this annex. These definitions are meant
to be used by the reader as an aid to understanding the concept of
Telecommand; no attempt is being made to universally define these terms.
Definitions which may be found in a standard English dictionary have
been omitted.

**ACQUISITION SEQUENCE:**

A specific high transition density bit pattern transmitted to permit the
receiving end to acquire symbol synchronization.

**BIT TRANSITION GENERATOR:**

A generator that produces a specific random sequence of 255 bits to be
ORed with the input TC data bits to increase the frequency of bit
transitions (between "1" and "0"). No additional bits are added by this
process.

**CARRIER MODULATION MODE:**

The data type being used to modulate the RF carrier or subcarrier.

**CLEAN DATA BITS:**

TC data bits which have been decoded and are outputted from the Coding
layer.

**CODEBLOCK:**

A fixed-length data entity containing information and check bits that
have been structured by an encoding algorithm.

**CODING LAYER:**

That layer of the TC Channel Service which uses a prescribed coding
technique to reliably transfer information bits through the potentially
noisy Physical layer.

**COMMAND LINK TRANSMISSION UNIT:**

A Coding layer protocol data entity which is used to synchronize and
delimit the beginning of a continuum of bits consisting of a start
sequence followed by an integral number of codeblocks.

**COMMAND SESSION:**

A continuous period of time during which the signal path is established
for the communications channel.

**COMMAND THRESHOLD:**

The telecommand channel operating point at which a deletion rate of 1
frame per 1000 frames is obtained.

**DECODER (Hard Decision):**

A Coding layer algorithmic process which utilizes the check bits
contained in a codeblock for detecting or correcting errors in the
information bits. The check bits are then removed before the information
bits are outputted.

**DECODER (Soft Decision):**

A Coding layer algorithmic process which uses quantization of the
detector output into n levels for each received bit to decide upon the
most likely codeblock and to estimate the reliability of that decision.
The check bits are then removed before the best-estimate information
bits and any reliability information are outputted.

**ENCODED TC DATA:**

The TC data contained in a codeblock.

**ENCODER:**

As used in this document, a Coding layer algorithmic process which adds
check bits to a series of information bits to create a codeblock.

**EVENT:**

As used in this document, an action which causes the TC Channel Service
to change states.

**FILL:**

Bits appended by the Coding layer to the Input Data to enable the data
entity to exactly fit an integer number of codeblocks. These fill bits
ARE transmitted and must be removed by the layer above.

**IDLE SEQUENCE:**

A specific high transition density bit pattern transmitted during a
command session in the absence of a CLTU to maintain symbol
synchronization in the channel.

**INPUT DATA:**

A discrete collection of data bits provided at the input to the Coding
layer from the Data Routing Service.

**OCTET:**

A contiguous string of 8 bits; an 8-bit word.

**PHYSICAL LAYER:**

The lower layer of the TC Channel Service which provides the RF channel.
At the sending end it provides the radio frequency and modulation
techniques required to create and operate the channel. At the receiving
end, it provides the reception, demodulation, and symbol synchronization
for the channel.

**PHYSICAL LAYER OPERATIONS PROCEDURE:**

A specific procedure of the Physical layer designed to activate and
deactivate the physical telecommand channel by invoking RF carrier and
modulation techniques.

**PROTOCOL:**

A set of procedures, supported by format conventions, that define the
orderly exchange of information between entities within a given layer of
the TC System or between layers.

**PSEUDO-RANDOMIZATION:**

Pseudo-Randomization, herein called Randomization, is a
bandwidth-efficient technique of algorithmically translating the data
bits to insure frequent bit transitions in the communications channel.

**RELIABLE:**

Meets the quality, quantity, continuity and completeness criteria which
are specified by the Telecommand System.

**START SEQUENCE:**

A specific bit pattern at the beginning of a CLTU having a high
autocorrelation function following an idle or acquisition sequence and
which: a) synchronizes start of a CLTU; b) delimits start of first
codeblock; and c) resolves the sense of a "1" and "0" in the CLTU, if
necessary.

**SYMBOL:**

A bit in an encoded data stream.

**TAIL SEQUENCE:**

A specific data pattern which delimits the end of a CLTU.

**TC DATA:**

The data content (after decoding) of the CLTU which is outputted to the
Data Routing Service (layer above) and which may include fill.

**TC TRANSFER FRAME:**

The protocol data unit of the Transfer layer. (See Reference \[2\], Data
Routing Service.)

**TELECOMMAND:**

A generic term used to describe the process of telecommunicating
commands to the spacecraft.

**TELECOMMAND CHANNEL SERVICE:**

A Telecommand Service which provides error-controlled communications
across the space link.

**TELECOMMAND DATA ROUTING SERVICE:**

A Telecommand Service which provides error-controlled message
communications between remote entities.

########   CHANNEL SERVICE SPECIFICATION

(THIS ANNEX **IS** PART OF THE RECOMMENDATION)

**Purpose:**

This Annex provides the detailed specification for the service provided
by the Coding and Physical layers of the Telecommand System.

######## OVERVIEW OF THE LAYERS WITHIN THE TELECOMMAND {#overview-of-the-layers-within-the-telecommand .Annex-2}

1.  CHANNEL SERVICE

The TC Channel Service consists of two layers: the Coding layer and the
Physical layer. Each of the layers provides services to the layer above
(e.g., the CCSDS Transfer layer, Reference \[2\]) at a "sending end"
(located in the region of the user) and at a "receiving end" (located in
space). A model of the activities within the Channel Service is
presented in Figure B-1.

![](media/image16.emf){width="5.805555555555555in"
height="6.541666666666667in"}

Figure B-1: TC Channel Service Model

Within a fully implemented CCSDS Telecommand system, operation of the
Channel Service begins when the buffer of information bits corresponding
to one or more complete TC Transfer Frames (plus their related
operational control information) is delivered from the Transfer layer to
the sending end of the Coding layer for radiation through the physical
telecommand channel to the spacecraft. (See Figure B-2.)

The TC Transfer Frames are encoded by the Coding layer into short, fixed
length TC Codeblocks which provide a noise immunity capability that is
compatible with overall TC Frame rejection and undetected error
requirements. A TC Transfer Frame is transmitted as a sequential set of
TC Codeblocks, with the entire set of Codeblocks being encapsulated by
the Coding layer within a "Command Link Transmission Unit" (CLTU) data
structure: a CLTU may contain one or more encoded Transfer Frames. If
there is a concern that the CLTU does not have adequate symbol
transitions to maintain symbol synchronization, then the Input TC data
may be randomized using the sequence specified by the BTG in 3.3.1. The
CLTU provides the data interface mechanism for passing the TC Codeblocks
between the Coding layer and the Physical layer.

To activate the telecommand channel in support of the Coding layer, the
services of the sending end Physical layer are invoked. An RF carrier
data path is first established, upon which various "Carrier Modulation
Modes" (CMMs) may be established to support data transfer. By selecting
an appropriate sequence of CMMs, a "Physical Layer Operations Procedure"
(PLOP) is formed which activates and deactivates the link so that one or
more CLTUs may be transmitted to the spacecraft.

Upon activation of the channel by the selected PLOP, modulated radio
waveforms are radiated to the spacecraft. The receiving end of the
Physical layer receives this waveform and detects a stream of channel
symbols. Control information which indicates the readiness of the
channel is passed to the layer above.

The spacecraft telecommand channel decoder within the receiving end of
the Coding layer awaits this symbol stream containing an Acquisition
sequence, a CLTU Start sequence, and the set of sequential TC Codeblocks
which carry the encoded TC Transfer Frame information bits. The
Acquisition sequence provides a preamble for symbol synchronization
purposes. The CLTU Start sequence marks the start of the first TC
Codeblock (which contains the leading bits of a TC Transfer Frame). TC
Codeblock decoding begins after the CLTU Start sequence is detected: the
TC Codeblocks are sequentially decoded to reconstruct the information
(Input TC data) bits which, together with control data, are passed to
the layer above which reassembles the TC Transfer Frame. If the Input TC
data have been randomized, it is here that they are derandomized before
being passed to the layer above. After transmission of all TC Codeblocks
contained within the CLTU, a Tail sequence is transmitted which signals
the end of the CLTU, and may be followed by an (optional) Idle sequence
and more CLTUs. Finally, when the last CLTU has been transmitted
(followed or not by an Idle sequence), the link is deactivated by the
PLOP.

Figure B-2: Sequence of Functions

If the probability of erroneous data (as measured by the channel
decoder) is sufficiently high, the spacecraft channel decoder will enter
a "Search for Start Sequence" condition until reset by the next CLTU
Start sequence or (optionally) by deactivation of the link by the PLOP.
(See 4.3.3.2.) In the case where the channel decoder is in the "SEARCH"
state, no further data bits will be transferred to the process which
reassembles and accepts the TC Transfer Frame (the layer above) until
the decoder returns to the DECODE state.

Reporting of individual decoded TC Codeblock acceptance by telemetry
will NOT be performed, unless this is implemented on a mission-specific
basis for the purposes of spacecraft diagnosis (e.g., via engineering
telemetry data). Since no data will be transferred to the spacecraft TC
Transfer Frame reassembler in case of TC Codeblock error, the
operational reporting of acceptance is performed on a TC Transfer Frame
basis via the Frame Acceptance and Reporting Mechanism (FARM) as
described in Reference \[2\].

######## CODING LAYER SERVICE SPECIFICATION {#coding-layer-service-specification .Annex-2}

The basic Quality of Service of the Coding layer is to provide a
reliable, error-controlled data channel through which user telecommand
data bits may be transferred.

2.  Coding Layer: Sending End Service Specification

\(1\) INPUTS

From the layer above:

> \(a\) "Input Data" from the Data Routing Service, to be included in a
> single CLTU.
>
> \(b\) Control instructions.

From the layer below:

> \(c\) Status of the physical telecommand channel (i.e., report from
> the Physical layer).

\(2\) OUTPUTS

To the layer above:

> \(a\) Status of the physical telecommand channel.

To the layer below:

> \(b\) Command Link Transmission Units (CLTUs).
>
> \(c\) Control instructions.

\(3\) INTERNAL FUNCTIONS

> \(a\) Conditions Input TC Data by randomizing it if used by a mission.
>
> \(b\) Adds fill as necessary to complete the last codeblock of the
> CLTU (may be done before or after randomizing).
>
> \(c\) Encodes the Input TC Data or conditioned Input TC Data into TC
> Codeblocks.
>
> \(d\) Forms the TC Codeblocks into a CLTU by adding the Start and Tail
> Sequence.

3.  Coding Layer: Receiving End Service Specification

\(1\) INPUTS

From the layer below:

> \(a\) Synchronized detected "dirty" symbol stream (with possible
> errors if hard-decision decoding is used).
>
> \(b\) Symbol clock (if required).
>
> \(c\) Control information and status (e.g., physical telecommand
> channel active or inactive).

\(2\) OUTPUTS

To the layer above:

> \(a\) "Clean" decoded and derandomized (if used) TC data from each
> codeblock which have passed the decoder quality check. May include
> fill from last codeblock of CLTU.
>
> \(b\) Decode Status, indicating start, continuity, and end of valid TC
> data.
>
> \(c\) Control information describing status of the physical
> telecommand channel (e.g., RF and bit synchronization).

\(3\) INTERNAL FUNCTIONS

> \(a\) Permits the resolution of the sense of 1 and 0 in the incoming
> stream of dirty symbols, if not already provided by modulation
> techniques within the layer below.
>
> \(b\) Detects the CLTU Start sequence which provides decoder
> synchronization for the first codeblock; subsequent codeblocks are
> automatically synchronized by being contiguous. Signals the start of
> valid TC data.
>
> \(c\) Within the capability of the decoding algorithm, makes an
> estimate to determine if an error has probably occurred within the TC
> Codeblock.
>
> \(d\) Within the capability of the decoding algorithm, optionally
> makes an estimate of the correct value of the information bits if
> errors are suspected to have occurred within the group of symbols that
> correspond to one TC Codeblock, and continues decoding.
>
> \(e\) If a TC Codeblock is encountered which is sufficiently likely to
> contain a detected or uncorrectable error, declares a codeblock error,
> leaves the DECODE state, enters the SEARCH state and ceases to output
> further data. Signals the stop of valid TC data.
>
> \(f\) If the Physical layer signals loss of modulation, leaves the
> DECODE state, enters the INACTIVE state, ceases to output further
> data, and signals the stop of valid TC data.
>
> \(g\) If the mission is randomizing its TC Data, the "Valid TC Data"
> is derandomized before being passed to the layer above.
>
> \(h\) Informs the layer above of status of the Channel Service.

######## PHYSICAL LAYER SERVICE SPECIFICATION {#physical-layer-service-specification .Annex-2}

The basic Quality of Service of the Physical layer is to establish a
physical path which connects the sending end of the Telecommand System
to the receiving end in space.

4.  Physical Layer: Sending End Service Specification

\(1\) INPUTS

From the layer above:

> \(a\) Buffers of bits corresponding to a CLTU.
>
> \(b\) Control information.

\(2\) OUTPUTS

To the layer above:

> \(a\) Status of the physical telecommand channel.

To the receiving end of the layer:

> \(b\) Modulated radio frequency waveforms, radiated as described in
> Reference \[3\].

\(3\) INTERNAL FUNCTIONS

> \(a\) Establishes the physical radio frequency path to the spacecraft
> using CMM-1.
>
> \(b\) Radiates a buffer of data bits serially according to the PLOP
> requested by the layer above.

5.  Physical Layer: Receiving End Service Specification

\(1\) INPUTS

From the sending end of the layer:

> \(a\) Modulated radio frequency waveforms which have been radiated by
> a transmitting station as described and specified in Reference \[3\].

\(2\) OUTPUTS

To the layer above:

> \(a\) Synchronized detected "dirty" symbol stream.
>
> \(b\) Symbol clock (if required).
>
> \(c\) Channel Active (modulated carrier/subcarrier present); used by
> layer above to select between Inactive and Search states, to validate
> the Decode state and in some cases to initiate inter-layer control
> instructions.
>
> \(d\) Status of the RF lock and bit synchronization processes.

\(3\) INTERNAL FUNCTIONS

> \(a\) Receives and detects the modulated carrier/subcarrier.
>
> \(b\) Performs demodulation and symbol synchronization.
>
> \(c\) Determines the state of the physical telecommand channel
> (CHANNEL ACTIVE or CHANNEL INACTIVE).
>
> \(d\) Performs symbol detection (hard decisions or quantized, soft
> decisions).
>
> \(e\) Informs the layer above of status of the Physical layer.

######## CHANNEL SERVICE PERFORMANCE SPECIFICATION {#channel-service-performance-specification .Annex-2}

The performance of the Channel Service is specified to meet the
requirements defined for the layer above. In the case where the layer
above is a TC Transfer Frame, the performance specification is given in
Reference \[2\]. The performance provided by the Channel Service depends
on the performance of the individual elements and procedures for a CLTU
defined in Sections 3 and 4, and as shown in Figure 3-4.

Suggested processing alternatives for each of the elements of a CLTU are
shown in Table B‑1.

Table B-1: Processing of CLTU Elements

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

Element Implementation Procedure

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

Modulation Start Acquisition Sequence

CLTU "Start" Start Sequence A: 0 error in start seq.

B: 0 or 1 error in start

sequence

CLTU "Data Unit" Codeblock A: Triple error detection

B: 1-bit error correction

CLTU "Finish" Tail Sequence Codeblock rejection

Idle Sequence Codeblock rejection

Modulation End Physical link Stop modulation (post-CLTU):

A: PLOP-1

B: PLOP-2

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

The overall performance for different combinations of the above
strategies (plus variables such as CLTU length) is given in Reference
\[C2\]. Accordingly, the recommended Channel Service strategies are as
shown in Table B-2.

Table B-2: Recommended Strategies

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

CLTU CLTU Modulation

Strategy Start Data Unit End

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

1 A A A or B

2 B B A or B

> ![](media/image17.emf){width="5.376388888888889in"
> height="0.10208333333333333in"}

########   INFORMATIVE REFERENCES

(This annex is **not** part of the Recommendation.)

\[C1\] *Procedures Manual for the Consultative Committee for Space Data
Systems*. CCSDS A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.:
CCSDS, November 1996.

\[C2\] *Telecommand: Summary of Concept and Rationale*. Report
Concerning Space Data Systems Standards, CCSDS 200.0-G-6. Green Book.
Issue 6. Washington, D.C.: CCSDS, January 1987.

[^1]: The description to follow assumes a hard-limiting detector before
    decoding, but a soft- limiting detector is not intended to be
    precluded.

[^2]: Previously, the idle sequence was constrained to begin with a
    "zero" to be continuous with the tail sequence. Because of the
    improved performance of the tail sequence in this issue, the
    constraint is no longer necessary.