Consultative

Committee for
Space Data Systems
REPORT CONCERNING SPACE
DATA SYSTEM STANDARDS

TELECOMMAND
SUMMARY OF
CONCEPT AND RATIONALE

CCSDS 200.0-G-6

GREEN BOOK

JANUARY 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

AUTHORITY

* * * * * * * * * * * * * * * * * * * * * * * * *
* Issue: Green Book, Issue 6 *
* Date: January 1987 *
* Location: CCSDS Plenary Meeting, *
* November 1986 *
* Frascati, Italy *
* * * * * * * * * * * * * * * * * * * * * * * * *

This Recommendation reflects the consensus technical agreement of the following member
Agencies of the Consultative Committee for Space Data Systems (CCSDS):

o Centre National D'Etudes Spatiales (CNES)/France.

o Deutsche Forschungs-u. Versuchsanstalt fuer Luft und Raumfahrt e.V (DFVLR)/
West Germany.
o European Space Agency (ESA)/Europe.
o Indian Space Research Organization (ISRO)/India.
o Instituto de Pesquisas Espaciais (INPE)/Brazil.
o National Aeronautics and Space Administration (NASA)/USA.
o National Space Development Agency of Japan (NASDA)/Japan.

The panel experts of the following observer Agencies also technically concur with this
report:

o British National Space Centre (BNSC)/United Kingdom.

o Chinese Academy of Space Technology (CAST)/People's Republic of China.
o Department of Communications, Communications Research Centre
(DOC-CRC)/Canada.

This report is published and maintained by:

CCSDS Secretariat
Communications and Data Systems Division (Code-TS)
National Aeronautics and Space Administration
Washington, DC 20546, USA

Issue 6 i January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

FOREWORD

This document is a CCSDS report which summarizes the principal concepts associated with
the recommended CCSDS space mission telecommanding architecture. It is intended to
orient technical personnel to these concepts, prior to reading the three main CCSDS
architectural specifications, which are:

o CCSDS Recommendation for Space Data System Standards. Telecommand, Part

1: Channel Service, Architectural Specification.

o CCSDS Recommendation for Space Data System Standards. Telecommand, Part

2: Data Routing Service, Architectural Specification.

o CCSDS Recommendation for Space Data System Standards. Telecommand, Part

3: Data Management Service, Architectural Definition.

A fourth specification is also under preparation by the CCSDS, containing the more detailed
operational procedures which support the architecture defined in Part 2. This fourth
document is:

o CCSDS Recommendation for Space Data System Standards. Telecommand, Part

2.1: Command Operation Procedures, Detailed Specifications and State Matrices.

The current set of CCSDS Recommendations was developed to match a conventional

mission environment, as characterized by the transmission of command data from a closed
user community, at relatively low uplink data rates, to spacecraft of moderate complexity.
The CCSDS is presently examining the extension of these Recommendations to a more
complex future mission environment, including the transmission of multiple data types from
a networked, more open user community at very high rates to space vehicles which include
extensive onboard data networking capability.

Questions relative to the contents or status of this document should be addressed to the
CCSDS Secretariat.

Issue 6 ii January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

DOCUMENT CONTROL

Document Title Date Status/Remarks

- Telecommand Summary of August Superseded

Concept and Service, Issue 0 1984

- Report for Space Data December Superseded

System Standards: 1984
Telecommand Summary of
Concept and Service, Issue 1

- Report Concerning Space January Superseded

Data System Standards: 1985
Telecommand Summary of
Concept and Service, Issue 2

- Report Concerning Space April Superseded

Data System Standards: 1985
Telecommand Summary of
Concept and Service, Issue 3

- Report Concerning Space July Superseded

Data System Standards: 1985
Telecommand Summary of
Concept and Service, Issue 4

- Report Concerning Space February Superseded

Data System Standards: 1986
Telecommand Summary of
Concept and Service, Issue 5

CCSDS 200.0-G-6 Report Concerning Space January Current

Data System Standards, 1987 Issue
Telecommand: Summary of
Concept and Service, Issue 6

Issue 6 iii January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

[This page intentionally left blank.]

Issue 6 iv January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

CONTENTS

Sections Page

REFERENCES....................................................................................................... vii

1 DOCUMENT PURPOSE AND ORGANIZATION.............................................. 1-1

1.1 PURPOSE ..................................................................................................... 1-1

1.2 ORGANIZATION ........................................................................................ 1-1

2 OVERVIEW OF THE CCSDS TELECOMMAND SYSTEM ............................. 2-1

2.1 INTRODUCTION......................................................................................... 2-1

2.2 TELECOMMAND SERVICE CONCEPT................................................... 2-3

3 TELECOMMAND SERVICES............................................................................. 3-1

3.1 TC DATA MANAGEMENT SERVICE ...................................................... 3-1

3.1.1 TC APPLICATION PROCESS LAYER............................................ 3-1
3.1.2 TC SYSTEM MANAGEMENT LAYER........................................... 3-3
3.1.3 TC PACKETIZATION LAYER......................................................... 3-4
3.2 TC DATA ROUTING SERVICE ................................................................. 3-6
3.2.1 TC SEGMENTATION LAYER ......................................................... 3-6
3.2.2 TC TRANSFER LAYER .................................................................... 3-8
3.3 TC CHANNEL SERVICE ............................................................................ 3-12
3.3.1 TC CODING LAYER......................................................................... 3-12
3.3.2 TC PHYSICAL LAYER..................................................................... 3-13
3.4 INTER-LAYER DATA EXCHANGE ......................................................... 3-14
3.5 INTER-AGENCY CROSS-SUPPORT SERVICES..................................... 3-15

Annexes

A ACRONYMS AND TERMINOLOGY ................................................................. A-1

B TELECOMMAND TRANSFER FRAME ERROR DETECTION
ENCODING/DECODING GUIDELINE .............................................................. B-1
C DATA PROTECTION CONCEPT........................................................................ C-1
D TELECOMMAND SYSTEM PERFORMANCE NOTES.................................... D-1

Issue 6 v January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Figures

2-1 CCSDS Telecommand System ............................................................................. 2-2

2-2 Layered Telecommand Service Model ................................................................. 2-4
2-3 Telecommand/Telemetry System Orientation ...................................................... 2-8
2-4 Telecommand Data Structures.............................................................................. 2-10
3-1 TC Application Process Layer .............................................................................. 3-2
3-2 TC System Management Layer ............................................................................ 3-3
3-3 TC Packetization Layer......................................................................................... 3-5
3-4 TC Segmentation Layer ........................................................................................ 3-7
3-5 TC Transfer Layer................................................................................................. 3-9
3-6 Transfer Layer Numbering Relationships............................................................. 3-11
3-7 TC Coding Layer .................................................................................................. 3-12
3-8 TC Physical Layer................................................................................................. 3-14
B-1 Encoder ................................................................................................................. B-4
B-2 Decoder ................................................................................................................. B-4
D-1 TC Decoder State Diagram................................................................................... D-4
D-2 Probability of Rejection of One or More Contiguous 64-Bit Codeblocks
as a Function of Number of Codeblocks, N.......................................................... D-11
D-3 Single Frame, Single CLTU Organization............................................................ D-12
D-4 Multiple Frame, Single CLTU Organization ........................................................ D-14
D-5 Multiple Frame CLTU Organization .................................................................... D-16
D-6 Multiple CLTU Organization ............................................................................... D-18
D-7 Undetected Error Performance, With and Without Cyclic Redundancy Code..... D-24

Tables

D-1 Probability of Rejection on CLTU Start Sequence............................................... D-7

D-2 Codeblock Organization ....................................................................................... D-8
D-3 Probability of Codeblock Rejection as a Function of Number of Codeblocks, N D-10
D-4 Probability of Rejection of a MINIMUM Length Frame as a Function of
Codeblock Length Chosen.................................................................................... D-13
D-5 Probability of Rejection of a MAXIMUM Length Frame as a Function of
Codeblock Length Chosen.................................................................................... D-14
D-6 Probability of Last Frame Rejection in a Multiple Frame CLTU Using
Maximum Length Frames and 64-Bit Codeblocks............................................... D-15
D-7 Probability of Missing Tail Sequence................................................................... D-17
D-8 Example of Performance of Frames in First and Second Contiguous CLTUs ..... D-18
D-9 Probability of Missing DOUBLE Tail Sequence.................................................. D-19
D-10 Example of Performance of Frames in First and Second Contiguous CLTUs
Using DOUBLE Tail Sequences Between CLTUs .............................................. D-20
D-11 Probability of Missing a Tail Sequence Using the Fill Bit Algorithm ................. D-21
D-12 Example of Performance of Frames in First and Second Contiguous
CLTUs Using Fill Bit Algorithm.......................................................................... D-22

Issue 6 vi January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

REFERENCES

[1] "Procedures Manual for the Consultative Committee for Space Data Systems", Issue 1,
Consultative Committee for Space Data Systems, August 1985 or later issue.

[2] "Telecommand, Part 3: Data Management Service, Architectural Definition",

Recommendation CCSDS 203.0-B-1, Issue 1, Blue Book, Consultative Committee for
Space Data Systems, January 1987 or later issue.

[3] "Telecommand, Part 2: Data Routing Service, Architectural Specification",

Recommendation CCSDS 202.0-B-1, Issue 1, Blue Book, Consultative Committee for
Space Data Systems, January 1987 or later issue.

[4] "Telecommand, Part 1: Channel Service, Architectural Specification",

Recommendation CCSDS 201.0-B-1, Issue 1, Blue Book, Consultative Committee for
Space Data Systems, January 1987 or later issue.

[5] "Telecommand, Part 2.1: Command Operation Procedures, Detailed Specifications and
State Matrices", Document CCSDS 202.1-R-3, Issue 3, Red Book, Consultative
Committee for Space Data Systems, March 1987 or later issue.

[6] "Packet Telemetry", Recommendation CCSDS 102.0-B-2, Issue 2, Blue Book,

Consultative Committee for Space Data Systems, January 1987 or later issue.

[7] "Telemetry Channel Coding", Recommendation CCSDS 101.0-B-2, Issue 2, Blue

Book, Consultative Committee for Space Data Systems, January 1987 or later issue.

[8] Miller, W.H., and Morakis, J.C., Concatenated Coding Scheme for Telecommand Error
Control, GSFC X730-86-20, NASA Goddard Space Flight Center, December 1985.

[9] "Standard Formatted Data Units -- Structure and Construction Rules", Document
CCSDS 620.0-R-2, Red Book, Consultative Committee for Space Data Systems,
February 1987 or later issue.

[10] "CCSDS System Description, Volume 1: Recommended Interfaces and Service Access
Points", Issue 0, Green Book, Consultative Committee for Space Data Systems, January
1986 or later issue.

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

Issue 6 vii January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

1 DOCUMENT PURPOSE AND ORGANIZATION

1 . 1 PURPOSE

This report is a high level technical summary describing architectural concepts for space
mission telecommand systems. These concepts, and their associated telecommanding services,
have been developed by the participating Agencies of the international Consultative Committee
for Space Data Systems (CCSDS). The operating principles and procedures for the CCSDS
are defined in Reference [1]. This report has been prepared to serve two major purposes:

(1) To provide an overview that will introduce a new reader to the system concepts
upon which the detailed CCSDS Telecommand Recommendations (References [2],
[3], [4], and [5]) are based.

(2) To summarize the technical content of the three main architectural

Recommendations (References [2], [3], and [4]), and to describe their context
within the framework of a layered architecture for space mission telecommanding.

This document is a CCSDS report that is intended for informational purposes, and as such it is
not a part of the formal collection of CCSDS Telecommand Recommendations.

1 . 2 ORGANIZATION

This report contains two major sections, supported by four Annexes:

(1) Section 2 presents an overview of the CCSDS Telecommand (TC) System and its
associated concepts. This section describes the application of architectural layering
techniques to achieve transparent and reliable commanding of scientific instruments
or engineering subsystems aboard remote space vehicles.

(2) Section 3 presents a summary of the service concepts that lie behind the three main
CCSDS telecommand Recommendations. The overall service framework
developed in the prior section is used to discuss the services and functions within
each layer.

(3) Annex A contains a Glossary in order to familiarize the reader with the terminology
used throughout the discussion of the CCSDS Telecommand System.

(4) Annex B contains a guideline for generating the Telecommand Transfer Frame error
control polynomial which is specified in Reference [3].

Issue 6 Page 1-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

(5) Annex C describes a concept for the protection of Telecommand data sets so that
security measures may be implemented if required by a particular mission.

(6) Annex D contains some application notes which discuss the performance aspects of
the telecommand system.

Issue 6 Page 1-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

2 OVERVIEW OF THE CCSDS TELECOMMAND SYSTEM

2 . 1 INTRODUCTION

A telecommand system must reliably and transparently convey control information from an
originating source (e.g., a human user) to a remotely located physical device or process. For a
space mission telecommand system, the controlled devices and processes are scientific payload
instruments or engineering subsystems onboard a spacecraft. Conventional space mission
telecommand systems often display a centralized, mission-unique data handling architecture,
with only a low level of data system standardization.

The introduction of more capable microprocessor-based spacecraft payloads and engineering

subsystems will result in data systems with greater throughput needs, and in a corresponding
increase in spacecraft autonomy and complexity. This technical environment, coupled with
fiscal constraints, leads to a common space mission requirement for greater telecommanding
capability and efficiency with reduced costs. The CCSDS telecommand concept addresses this
requirement by recommending standardized approaches to space mission data handling: it is
intended for use in conjunction with the standardized flow of telemetry data from instruments
and subsystems to the user, in accordance with the CCSDS concept for "Packet Telemetry"
(References [6] and [7]). Recognizing the need to cover a broad spectrum of mission needs,
the new CCSDS telecommand concept is applicable to spacecraft and ground data system
architectures which range from very simple and highly centralized to very complex and highly
distributed.

For most past space missions, the telecommanding resources have been wholly contained
within one cognizant space agency. With the exception of elements of the ground tracking
networks, most of these telecommanding resources are completely dedicated and customized to
the requirements of each mission. The lack of effective standardization among the various
missions has forced the "multi-mission" elements of the tracking networks to implement a very
low level of supporting command service, i.e., the transport of bitstreams. Higher level
command services, oriented toward computer to computer transfers and typical of modern day
commercial and military data networks, must presently be custom designed and implemented
for space missions.

The CCSDS telecommanding architecture defines a comprehensive set of layered, standardized

command services which are applicable to a very wide range of mission needs. This
architecture will not only ease the transition towards the provision of more mission-
independent command services within each individual space agency, but also will promote
technical harmony among all space agencies that can result in greater cross-support
opportunities and services. As more and more space missions look towards
internationalization as the key to affordability, these standardized cross-support services will
become increasingly important.

Figure 2-1 illustrates the recommended CCSDS Telecommand System architecture in terms of
a layered set of telecommand services: the operations within each layer are detailed in
Issue 6 Page 2-1 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

APPLICATION PROCESS LAYER

COMMAND DIRECTIVE
TELECOMMAND,
PART 3: DATA SYSTEM MANAGEMENT LAYER
MANAGEMENT SERVICE
TC APPLICATION DATA

PACKETIZATION LAYER

PACKET

SEGMENTATION LAYER
TELECOMMAND,
PART 2: DATA SEGMENT
ROUTING SERVICE
TRANSFER LAYER

TRANSFER FRAME

CODING LAYER

TELECOMMAND, CLTU
PART 1: CHANNEL
SERVICE PHYSICAL LAYER

PHYSICAL WAVEFORM

Figure 2-1: CCSDS Telecommand System

Issue 6 Page 2-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Figure2-2. The layers of TC service are functionally grouped into a "Data Management
Service", a "Data Routing Service", and a "Channel Service". Each of these three major
architectural components of service is separately specified in its own CCSDS technical
Recommendation, i.e., References [2], [3], and [4]. The detailed retransmission protocols
associated with the Data Routing Service are contained in Reference [5]. Taken as a whole,
these four Recommendations (three architectural specifications and one detailed specification)
form a system which provides the user with reliable and transparent delivery of telecommand
information.

The three main architectural components of service reflect increasing sophistication in terms of
telecommand delivery. The Channel Service provides and controls a single reliable physical
connection to the spacecraft. The Data Routing Service may be overlayed on the Channel
Service to provide channel multiplexing capabilities, and to ensure the reliable delivery of
buffers of telecommand data. The Data Management Service may be overlayed on the Data
Routing Service to supply individually addressed end-to-end transportable command data units
to each user, and to provide overall TC System coordination, integration, and management.
Since each layer is independent of the layers above, individual missions may make their own
decisions concerning how "high" in the layered hierarchy they wish to be compatible.

2 . 2 TELECOMMAND SERVICE CONCEPT

The system design technique of layering is a key tool for transforming service concepts into
sets of operational and data formatting procedures. Layering (the strategy of "dividing and
conquering") allows a complex procedure such as spacecraft commanding to be decomposed
into sets of relatively simple peer functions residing in common architectural strata. Within
each layer, the functions exchange information using standard data formatting techniques and
standard procedural rules or "protocols".

Each layer of the TC System draws upon a well defined set of services provided by the layer
below, and provides a similarly well defined set of services to the layer above. As long as
these service boundaries are preserved, the internal operations within an individual layer are
unconstrained. Consequently, an entire layer within a system may be removed and replaced as
needed by user or technological requirements without destroying the integrity of the rest of the
system. Further, as long as the appropriate interface protocol is satisfied, a customer (user)
can conceptually interact with the system/service at any of its component layers. Layering is
therefore a powerful tool for designing structured, user-responsive data systems which may
easily change owing to the evolution of requirements or technology.

As shown in the service model (Figure 2-2), the CCSDS TC System contains the following
seven distinct layers:

(1) TC Application Process layer

(2) TC System Management layer

Issue 6 Page 2-3 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

LAYER SERVICE PROVIDED BY LAYER

APPLICATION ALLOWS HUMAN USERS TO SUPERVISE REMOTE PROCESSES

PROCESS LAYER BY INTERFACING WITH SPACE TELECOMMAND SYSTEMS.

COMMAND
DIRECTIVE
CONVERTS USER COMMAND DIRECTIVES INTO TRANSPORT-
SYSTEM MGMT
ABLE APPLICATION DATA UNITS AND SUPERVISES THEIR
LAYER
DELIVERY AND EXECUTION.
TC APPLICATION
DATA
TRANSPORTS APPLICATION DATA UNITS IN AN ERROR-FREE
PACKETIZATION MANNER TO THE RECEIVING END OF THE SYSTEM
LAYER MANAGEMENT LAYER ON THE SPACECRAFT.

TC PACKET

BREAKS LONG HIGHER-LAYER TC DATA UNITS INTO SHORTER

SEGMENTATION
COMMUNICATIONS-ORIENTED PIECES, AND MULTIPLEXES
LAYER
DIFFERENT DATA UNITS TOGETHER (OPTIONAL SERVICES).

TC SEGMENT

RELIABLY TRANSFERS HIGHER LAYER TC DATA UNITS TO

TRANSFER
THE SPACECRAFT, THROUGH THE SPACE DATA CHANNEL,
LAYER
UNDER ERROR-CONTROLLED CONDITIONS.
TC TRANSFER
FRAME
PROTECTS HIGHER LAYER TC DATA UNITS AGAINST ERRORS
CODING
INDUCED DURING TRANSMISSION THROUGH THE PHYSICAL
LAYER
PATH TO SPACECRAFT.

CLTU

PROVIDES THE PHYSICAL CONNECTION, VIA RADIO

PHYSICAL
FREQUENCY SIGNALS, BETWEEN A TRANSMITTING STATION
LAYER
AND THE RECEIVING SPACECRAFT.
PHYSICAL
WAVEFORM

Figure 2-2: Layered Telecommand Service Model

Issue 6 Page 2-4 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

(3) TC Packetization layer

(4) TC Segmentation layer

(5) TC Transfer layer

(6) TC Coding layer

(7) TC Physical layer

The TC DATA MANAGEMENT SERVICE, containing the top three layers, provides
command data delivery and management services for the user.

(1) The TC Application Process layer provides the first-level interface between
the user and the TC System, by insulating the user from the physical aspects of the
command delivery processes. The Application Process layer translates the user
requests into high-level command directives which are interpretable by the
underlying System Management layer.

(2) The TC System Management layer translates the high-level command

directives into process-interpretable TC application data, plus control instructions to
lower layers which establish the parameters for their transport to the spacecraft.
The System Management layer draws upon services provided by the underlying
Packetization layer in order to initiate the data transport process.

(3) The TC Packetization layer formats TC application data into end-to-end

transportable data units called TC Packets. A TC Packet is a basic user data unit
that is transported "up" to the spacecraft by the TC System: it is virtually identical
to a Telemetry Packet, which is the basic user measurement data unit that is
transferred "down" to the user through the CCSDS Telemetry System. The
Packetization layer utilizes the underlying services of the TC Data Routing Service
to accomplish its functions.

The TC DATA ROUTING SERVICE contains the intermediate two layers: the TC
Segmentation layer and the TC Transfer layer. The Data Routing Service supports the error-
controlled transmission and retransmission of standard TC Packets or TC Segments through
the data link to the spacecraft, or other user data structures from non-standard higher layers.

(1) The TC Segmentation layer provides flow control services. Recognizing that
user data units from the layer above may be too long for efficient handling by lower
layer processes, the Segmentation layer is available to break them into smaller
communications-oriented pieces (TC Segments) for transfer through the space data
channel. It also provides "Multiplexer Access Points" (MAPs) which allow
different user data units to be multiplexed together for data flow control purposes.
TC Segments are of proper size for placement into the data unit of the next lower
layer, the TC Transfer Frame. If the user data units are already short enough to be
Issue 6 Page 2-5 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

compatible with insertion into the TC Transfer Frame, and the MAP feature is not
required, the entire Segmentation layer may be bypassed.

(2) The TC Transfer layer uses its own data structure, the TC Transfer Frame, to
reliably transport TC Packets, TC Segments or other higher layer user data
structures through the telecommand channel to the receiving spacecraft. As the
heart of the CCSDS Telecommand System, the Transfer layer offers a range of
delivery service options designed to satisfy various mission needs. It contains the
retransmission procedures required to reliably deliver TC Transfer Frames to the
spacecraft, plus the facility to multiplex these frames together into "Virtual
Channels" (VCs). The Transfer layer uses the underlying TC Channel Service to
accomplish its role.

The TC CHANNEL SERVICE contains the bottom two layers: the TC Coding layer and
the TC Physical layer. The Channel Service supports the radiation of telecommand information
through the physical uplink path to the spacecraft.

(1) The TC Coding layer satisfies the TC System requirement for the error-free
delivery of commands to the spacecraft, by encoding the TC user data from the
layer above to protect them against noise-induced errors during transmission
through the underlying ground-to-spacecraft radio frequency (rf) channel. The
basic protocol data unit of the Coding layer is the TC Codeblock, which appends a
small block of information bits with parity bits that provide error detection and
(optionally) correction capability. Strings of TC Codeblocks, conveying the
information bits representing one or more TC Transfer Frames in the form of
parity-protected channel symbols, are encapsulated within a Command Link
Transmission Unit (CLTU) before being passed to the layer below. Any errors that
occur in the encoded information bits as a result of the physical transmission
process may be detected or corrected at the spacecraft receiving end of the Coding
layer.

(2) The TC Physical layer modulates the CLTUs onto the rf carrier, and provides
the procedures necessary to activate and deactivate the channel.

Reflecting an evolutionary philosophy, the CCSDS has focussed its attention on the Channel
Service and the Data Routing Service and, with the exception of the Packetization layer, has at
present left many of the functions within the Data Management Service for future specification.
(Note: this is the reason why the Part 3 Recommendation is called an "architectural definition"
whereas the other two Parts are called "architectural specifications".) A more complete
specification of the upper layer functions and data structures may be performed once more
operational experience is gained with the lower layer services.

Full advantage of the CCSDS TC System architecture would be realized if a space project
organization complied with all of its fully specified layers of protocol: at present, this
effectively means the Packetization, Segmentation, Transfer, Coding, and Physical layers.
However, a project organization can conceptually interface at any layer of the TC System,
Issue 6 Page 2-6 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

provided that all lower layers are used, as long as it conforms to the interface data structures
that are defined in the three main CCSDS TC Recommendations (References [2], [3], and [4]).
In such cases, only a reduced set of standard services may be made available to the project.

2 . 2 . 1 TELECOMMAND/TELEMETRY SYSTEMS RELATIONSHIP

The Telecommand System is balanced by a return link Telemetry (TLM) System. Figure 2-3
shows the conceptual relationship, in an operational environment, between the TC System
(which allows users to control remote instruments or subsystems) and the TLM System (which
returns measurement data from those instruments or subsystems back to the user). As far as
the flow of telecommands is concerned, the two systems work hand-in-hand to assure the
transfer of data from the sending end to the receiving end of the TC System.

CCSDS recommendations for the standardization of the Packet Telemetry and Telemetry
Channel Coding data structures and procedures are contained in References [6] and [7]. It
should be noted that these two TLM Recommendations were written before the CCSDS
telecommand work was mature, and therefore the TLM System does not contain the same
formal layering hierarchy as the TC System. However, these same layers are implicit in the
telemetry documentation, and hence Figure 2-3 synthesizes the equivalent TLM System layers
for the purpose of illustration.

As shown in Figure 2-3, there are two possible protocol mechanisms inherent to the TC
System for reporting command transfer status and verification information to the sending end
via the TLM System. The primary mechanism is the Command Link Control Word (CLCW),
which contains key information concerning the status of receipt of TC Transfer Frames by the
receiving end of the TC Transfer layer. The CLCW is periodically sampled by the TLM
System, and is returned to the sending end of the TC Transfer layer via the CLCW word in the
trailer of the standard CCSDS TLM Transfer Frame. The information conveyed in the CLCW
is used by the sending end of the TC Transfer layer to continue, retransmit or otherwise modify
the transmission of the stream of TC Transfer Frames.

Reliable, mission-independent operations within the TC Transfer layer form the cornerstone of
the CCSDS telecommanding concept. The closed-loop retransmission protocols between the
sending and receiving ends of the TC Transfer layer (using the CLCW reporting services of the
TLM Transfer layer) are specified in Reference [5].

A second reporting loop conceptually exists within the higher Packetization layer, where TLM
Packets may be prepared by the receiving end of the layer to acknowledge receipt or indicate
problems with the TC Packets it received from the TC Segmentation layer. These reporting
TLM Packets may then be sent back to the sending end of the TC Packetization layer via the
TLM System. However, at present the CCSDS has made no attempt to standardize any
reporting procedures within the Packetization layer, since these are likely to involve mission-
unique processes. The TC Packetization layer therefore relies fully on the standardized,
guaranteed service provided by the Transfer layer.

Issue 6 Page 2-7 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

RECEIVING TLM * SENDING TLM *

EVENT
APPLICATION CMD APPLICATION
PROCESS LAYER PROCESS LAYER
SENDING TC RECEIVING TC
APPLICATION APPLICATION
PROCESS LAYER PROCESS LAYER

RECEIVING TLM * SENDING TLM *

SYSTEM MGMT SYSTEM MGMT
LAYER LAYER
SENDING TC RECEIVING TC
SYSTEM MGMT SYSTEM MGMT
LAYER LAYER

PKT RECEIVING TLM SENDING TLM

PACKETIZATION PACKETIZATION
LAYER LAYER
SENDING TC RECEIVING TC
PACKETIZATION PACKETIZATION
LAYER LAYER

RECEIVING TLM SENDING TLM

SEGMENTATION SEGMENTATION
LAYER LAYER
SENDING TC RECEIVING TC
SEGMENTATION SEGMENTATION
LAYER LAYER

CLCW RECEIVING TLM SENDING TLM

TRANSFER CLCW TRANSFER
LAYER LAYER
SENDING TC RECEIVING TC
TRANSFER TRANSFER
LAYER LAYER

RECEIVING TLM SENDING TLM

CODING CODING
LAYER LAYER
SENDING TC RECEIVING TC
CODING CODING
LAYER LAYER

RECEIVING TLM SENDING TLM

PHYSICAL PHYSICAL
LAYER LAYER
SENDING TC RECEIVING TC
PHYSICAL PHYSICAL
LAYER LAYER

* THESE LAYERS DO NOT EXIST IN REFERENCE [5].

Figure 2-3: Telecommand/Telemetry System Orientation

Issue 6 Page 2-8 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

The final verification of proper command delivery and execution is, of course, provided when
the user observes the effect of the command via measurement data received from the TLM
System.

2 . 2 . 2 TELECOMMAND DATA STRUCTURES

Figure 2-4 illustrates how the various TC data structures within the Packetization,
Segmentation, Transfer, and Coding layers map into one another. As previously noted, there
is presently no attempt by the CCSDS to define the data structures of the top two layers of the
TC System, i.e., the Application Process layer and System Management layer.

TC Packets which are longer than the data field of a TC Transfer Frame are broken into
suitable-sized pieces and placed into the data field of TC Segments. A TC Segment can only
contain a portion of one TC Packet, i.e., if a string of Packets is input to the Segmentation
layer, new Segments must begin at each Packet boundary. A very long TC Packet will be
broken into "n" TC Segments, where the length of segments (1) through (n-1) will match the
maximum length of the TC Frame data field, and segment (n) will be of a length that
corresponds to the residue of data from the Packet. TC Segments are, on a one-to-one basis,
placed into the data fields of individual TC Transfer Frames and are encapsulated by the frame
header and (optionally) the trailing Frame Error Control code.

NOTE

As specified in Reference [3], the Transfer Frame Error Control field may be
needed in order to meet certain mission-defined Transfer layer performance
requirements. A guideline which describes the recommended
encoding/decoding procedure for the Frame Error Control field is contained in
Annex B of this report. Reference [8] discusses the performance of this code
in more detail.

Each TC Transfer Frame is piecewise-encoded into a series of short, fixed length TC

Codeblocks which provide error detection or correction capabilities. Successive blocks of
information bits from each TC Frame are placed into the data space of each codeblock, to
which computed parity bits are appended.

The resulting string of TC Codeblocks is encapsulated within a "Command Link Transmission

Unit" (CLTU) data structure. Note that each CLTU may contain the encoded
representation of one or more TC Frames, i.e., several frames may be placed back-to-
back, encoded and inserted into one CLTU. Each CLTU contains a Start Sequence and ends
with a Tail Sequence. It is these delimited CLTUs which are modulated onto the rf carrier and
physically radiated to the receiving spacecraft.

Issue 6 Page 2-9 January 1987

 CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE
Issue 6

TC PACKET PKT HDR USER DATA

• SEGMENTATION SEG HDR SEG HDR SEG HDR

• FRAME
FRM HDR FRM HDR FRM HDR
CONSTRUCTION

K BITS K BITS K BITS K BITS K BITS

Page 2-10

• CODEBLOCK
CB#1 CB#2 • • • CB#N CB#1 CB#2
CONSTRUCTION

• COMMAND LINK
TRANSMISSION ST SEQ TAIL SEQ ST SEQ
UNIT
CONSTRUCTION
CLTU 1 CLTU 2

NOTE: THE DATA FIELD OF EACH CLTU CONTAINS THE ENCODED

REPRESENTATION OF ONE OR MORE TRANSFER FRAMES.
January 1987

Figure 2-4: Telecommand Data Structures

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

2 . 2 . 3 COMMUNICATIONS SECURITY/DATA PROTECTION CONCEPT

For many missions there is a requirement to prevent any intentional or accidental attempts to
manipulate or control the spacecraft by an unauthorized party, including efforts to deny access
to authorized users. Some missions may also have requirements to render the contents of
telecommand messages unintelligible to unauthorized users. The CCSDS has developed a
telecommand data protection concept, which is described in Annex C of this report, that
permits authentication and encryption measures to be implemented when required by a
particular mission.

2 . 2 . 4 TELECOMMAND SYSTEM PERFORMANCE

Performance considerations associated with the CCSDS TC System are discussed in Annex D
of this report.

Issue 6 Page 2-11 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

3 TELECOMMAND SERVICES

This section summarizes the services, functions, inputs, and outputs characterizing each layer
of the Telecommand System. The component layers are discussed for both the sending end
(where the user resides) and the receiving end (where the control actions are effected).

3 . 1 TC DATA MANAGEMENT SERVICE

The Data Management Service, Reference [2], provides the primary user interface with the TC
System. This service enables user requests for command activity to be generated, integrated,
aggregated, translated, and scheduled for delivery to a spacecraft.

3 . 1 . 1 TC APPLICATION PROCESS LAYER

The basic service of the Application Process layer is to provide users with a method by which
they can formulate instructions to control a remote device in space, and to interface those
instructions with the systems which provide the physical delivery of telecommands. Figure 3-1
depicts the activities and interfaces of the Application Process layer.

Inputs to the sending end of the layer take the form of user requests for specific command
actions, plus associated requests concerning any desired overall delivery and execution
conditions. The user command requests are translated into corresponding machine
interpretable "command directives" which are passed to the layer below, along with control
instructions to lower layers that specify the overall configuration of the TC System required for
their delivery. Control instructions are also sent ACROSS the layer (to the peer application
process in space) to define the overall conditions which must exist within that process at the
time of execution of the command directives.

At the receiving end of the Application Process layer, named sets of command directives, and
their associated delivery status information, are received from the System Management layer.
The receiving application process executes the command directives when specified operational
conditions are satisfied: the resulting executed command actions cause changes in the state of
spacecraft instruments or subsystems, which may be observed and confirmed by the user via
telemetered measurements.

Issue 6 Page 3-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

APPLICATION PROCESS LAYER

SENDING PEER RECEIVING

END PROCESS END
USER SUBSYSTEM

INPUT: USER REQUESTS FOR OUTPUT: EXECUTED

COMMAND ACTIONS. COMMAND ACTIONS WHICH
DELIVERY INSTRUCTIONS. CHANGE SPACECRAFT STATE.

FUNCTION: TRANSLATE USER CONTROL FUNCTION: EXECUTE NAMED

REQUESTS TO NAMED SETS SERVICE REMOTE SET OF COMMAND DIRECTIVES
OF CMD DIRECTIVES AND WHEN OPERATIONAL
EXECUTION CONDITIONS. PROCESSES CONDITIONS ARE MET.
TRANSLATE DELIVERY
INSTRUCTIONS TO OVERALL
SESSION CONTROL COMMAND
PARAMETERS (DELIVERY DIRECTIVES
REQUIREMENTS).

OUTPUT: NAMED SETS OF CMD UNDEFINED INPUT: NAMED SETS OF CMD

DIRECTIVES, DELIVERY DIRECTIVES, EXECUTION
REQUIREMENTS. EXECUTION CONDITIONS.
CONDITIONS.

SYSTEM MANAGEMENT LAYER

Figure 3-1: TC Application Process Layer

Issue 6 Page 3-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

3.1.2 TC SYSTEM MANAGEMENT LAYER

The basic service of the TC System Management layer is to provide translation of command
directives into transportable telecommand application data units, supervise their delivery to
the receiving end of the layer, and to translate the application data back into command
directives (if required) prior to delivery to the receiving application process. Figure 3-2
depicts the activities and interfaces of the TC System Management layer.

SYSTEM MANAGEMENT LAYER

SENDING PEER RECEIVING

END PROCESS END
APPLICATION PROCESS LAYER

INPUT: NAMED SETS OF CMD OUTPUT: NAMED SETS OF CMD

DIRECTIVES. DELIVERY RQMTS DIRECTIVES. EXECUTION
EXECUTION CONDITIONS. CONDITIONS.

FUNCTION: TRANSLATE DELIVER TC FUNCTION: DELIVER NAMED

NAMED SETS OF COMMAND SERVICE APPLICATION SETS OF TC APPLICATION
DIRECTIVES TO NAMED SETS DATA (TRANSLATED TO
OF TRANSPORTABLE DATA NAMED SETS OF COMMAND
APPLICATION DATA UNITS. DIRECTIVES, IF REQUIRED
MANAGE TC SESSIONS. BY APPLICATION PROCESS).
SPECIFY TRANSPORT TELECOMMAND GENERATE DELIVERY STATUS
CONTROL PARAMETERS. APPLICATION REPORTS FOR TELEMETRY
CONSTRAINT CHECKING. SYSTEM.
DATA UNITS
OUTPUT: NAMED SETS OF INPUT: NAMED SETS OF TC
APPLICATION DATA. APPLICATION DATA.
UNDEFINED
TRANSPORT CONTROL
PARAMETERS.

PACKETIZATION LAYER

Figure 3-2: TC System Management Layer

Issue 6 Page 3-3 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Inputs at the sending end of the TC System Management layer are integrated, aggregated, and
named sets of multi-user command directives, along with control instructions specifying their
overall delivery requirements. The named command directives are parsed by the System
Management layer and translated (if required) into correspondingly named sets of TC
application data which are compatible with handling by the layer below.

The TC application data are partitioned into appropriate blocks for transmission during
individual TC sessions, and (along with necessary control instructions) are passed to the layer
below for transport. At the receiving end of the TC System Management layer, named sets of
user application data may (if required by the application processes) be translated back into
correspondingly named sets of command directives, or may be passed directly to the layer
above. Status reports may be formulated and returned to the sending end of the layer (via
Telemetry Packets) if information relating to the correctness, completeness, and sequentiality of
the received data is required by particular mission processes: the CCSDS presently does not
define these reports.

Session control instructions are created by the sending end of the System Management layer,
which are addressed to the receiving end of the layer and are passed to the layer below for
transport. These session control instructions to the receiving end of the layer define naming
conventions and conditions for delivering either the application data or the retranslated
command directives to the TC Application Process layer.

3 . 1 . 3 TC PACKETIZATION LAYER

The TC Packetization layer is currently the highest layer which CCSDS Recommendations
cover in detail. The TC Packet is an autonomous command data unit which may be directly
interpreted by the device that is being controlled. The format of the TC Packet is specified in
Reference [2].

The basic service of the TC Packetization layer is to provide error-free transport of one set of
application data to the System Management layer on the spacecraft. An enhanced service is to
provide error-free transport of the application data content of named sets of interdependent TC
Packets (i.e., TC Files) to the TC System Management layer on the spacecraft. Figure 3-3
depicts the activities and interfaces of the TC Packetization layer.

Inputs to the sending end of the Packetization layer are named sets of transportable TC
application data, plus transport control instructions including naming conventions. The TC
application data are placed within the data field of TC Packets, and encapsulated within Packet
headers containing information such as the name of destination application, sequence control,
and packet length. If required, TC Files are constructed according to the procedures defined in
Reference [2].

The TC Packets, or files of TC Packets, are passed to the layer below along with control
instructions that request lower layer services such as the segmentation or multiplexing of
packets or files. TC Packets may also be created for routing to the receiving end of the
Issue 6 Page 3-4 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

PACKETIZATION LAYER

SENDING PEER RECEIVING

END PROCESS END
SYSTEM MANAGEMENT LAYER

INPUT: NAMED SETS OF APPLI- OUTPUT: NAMED SETS OF

CATION DATA. TRANSPORT APPLICATION DATA.
CONTROL PARAMETERS.

FUNCTION: ENCAPSULATE END-TO-END FUNCTION: EXTRACT AND

APPLICATION DATA INTO TRANSPORT–TC RECONSTRUCT NAMED SETS
TC PACKETS OR FILES SERVICE OF APPLICATION DATA IN
OF TC PACKETS. APPLICATION SEQUENTIAL ORDER.
REQUEST DATA ROUTING DATA FORMULATE TRANSPORT
SERVICE (E.G., MULTIPLEXER STATUS REPORTS.
ACCESS POINTS).
TELECOMMAND
PACKETS
OUTPUT: TC PACKETS. INPUT: TC PACKETS.
TC FILES. TC FILES.
UNDEFINED
ROUTING INSTRUCTIONS.

SEGMENTATION LAYER

Figure 3-3: TC Packetization Layer

Packetization layer, containing control instructions which define the system conditions that
must exist before the TC application data are passed back across the interface to the TC System
Management layer.

At the receiving end of the TC Packetization layer, the named sets of TC application data are
extracted from the data fields of the TC Packets in the sequential order in which they were
given at the sending end, and passed to the layer above. Status reports may be formulated and
returned to the sending end of the layer (via Telemetry Packets) if information relating to the
correctness, completeness, and sequentiality of the received data is required by particular
mission processes: the CCSDS presently does not define these reports.

It should be noted that many of the telecommanding functions within and above the
Issue 6 Page 3-5 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Packetization layer will probably be implemented within user application processes, such as the
instrument and subsystems themselves, rather than as external supporting services.

3 . 2 TC DATA ROUTING SERVICE

The TC Data Routing Service provides a pivotal function within the TC System by performing
the error-controlled communication of higher layer TC data through the ground-to-space data
link, relying on the lower layer TC Channel Service in order to perform its task. The
combination of the Data Routing and Channel Services provides users with a powerful
mechanism for the flow control and guaranteed transfer of TC data between the sending and
receiving ends of the TC System. The CCSDS therefore has focussed its attention on fully
specifying these services so that robust, mission-independent user support systems may be
rapidly developed. The Data Routing Service contains two layers: the TC Segmentation
layer and the TC Transfer layer. The detailed protocols and formats for the TC Data
Routing Service are specified in References [3] and [5].

3 . 2 . 1 TC SEGMENTATION LAYER

The TC Segmentation layer is optional, i.e., it may be bypassed if its services are not required.

The basic service of the Segmentation layer is to prepare variable-length TC data units from the
layer above (e.g., TC Packets, or other user-supplied data structures) for transfer through the
space data link, using the lower TC Transfer layer service. Since the data unit of the TC
Transfer layer (the TC Frame) has an upper length limit, the Segmentation layer must break the
higher layer TC data units into suitable sized pieces for insertion into the data field of the frame.
A second aspect of its service is the capability to multiplex together segments of data from
different TC data units for the purpose of flow control: to accomplish this, the Segmentation
layer provides "Multiplexer Access Points" (MAPs) to the layer above. Figure 3-4 depicts the
activities and interfaces of the TC Segmentation layer.

TC Packets (or other higher layer user data structures) are input to the sending end of the layer,
plus data routing control instructions (assignment of TC Packets or TC Files to particular
MAPs). The input data are first broken into pieces (segments) which will fit into the data field
of the lower layer TC Transfer Frames. Each segment must only contain a piece of ONE input
data unit, i.e., a new segment must be started at each boundary between higher layer data units.
Every segment is labelled with a Segment Header that conveys segment order. The segment is
further labelled to identify with which multiplexing port it is associated, so that it may be
properly routed and reconstructed at the receiving end: this is accomplished by assigning a
MAP identifier to each segment, also conveyed in the Segment Header. The completed TC
Segment is output to the layer below, the TC Transfer layer, for encapsulation within the data
field of one TC Transfer Frame.

Issue 6 Page 3-6 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

SEGMENTATION LAYER

SENDING PEER RECEIVING

END PROCESS END
PACKETIZATION LAYER

INPUT: TC PACKETS. OUTPUT: TC PACKETS.

TC FILES. TC FILES.

FUNCTION: SEGMENT SETS INTERFACE FUNCTION: RECONSTRUCT

OF PACKETS TO FIT PACKETS WITH SETS OF PACKETS FROM
TRANSFER FRAMES. SERVICE SEGMENTS.
MULTIPLEX SEGMENTS BY TRANSFER
MULTIPLEXER ACCESS LAYER
POINT (MAPs).

SEGMENTS

OUTPUT: SEGMENTS AND NONE INPUT: SEGMENTS.

DELIVERY CONDITIONS.

TRANSFER LAYER

Figure 3-4: TC Segmentation Layer

At the receiving end of the TC Segmentation layer, TC Segments are received from the layer
below, sorted by MAP, and the individual higher layer TC data units are reconstructed prior to
passing them across the interface to the layer above. Since the Segmentation layer relies
completely on the guaranteed delivery service of the layer below, it contains no layer-unique
reporting procedures.

Appreciating the functional utility of the multiplexing feature of the Segmentation layer requires
an understanding of the characteristics of the underlying Transfer layer. The Transfer layer,
which utilizes TC Frames as its data units, interfaces with the single physical data channel in
the layer below it. The TC Frames themselves feature an independent multiplexing capability,
since each frame may be assigned with its own "Virtual Channel" (VC) identifier. Individual
TC Frames may (by giving them different VC identifiers) each carry different higher layer TC
Issue 6 Page 3-7 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

data units: this therefore provides a Transfer layer multiplexing capability which is functionally
similar to the Segmentation layer MAPs.

However, since the Transfer layer contains the closed-loop retransmission procedures which
control the delivery of TC Frames to the spacecraft, having a large number of VCs that are
simultaneously "open" will increase the complexity of the reporting mechanism between the
receiving and sending end of this layer. The MAP feature of the Segmentation layer allows the
user data multiplexing to be performed ABOVE the Transfer layer, i.e., on one Virtual
Channel, thus potentially simplifying the Transfer layer reporting and reducing its associated
telemetered traffic. Conversely, it is important to recognize that this potential simplification of
the Transfer layer is bought at the price of the increased complexity and communications
overhead associated with the Segmentation layer.

Missions are therefore free to decide whether or not to implement a Segmentation layer: if the
higher layer TC data units (e.g., TC Packets) are all short enough to fit within a maximum-
length TC Transfer Frame (and the reporting complexity is acceptable), the Virtual Channel
feature of the TC Transfer Frame may be used for multiplexing, and the Segmentation layer
may be completely omitted. It will be noted when reading Reference [3] that the CCSDS
Recommendations theoretically allow up to 64 Virtual Channels in the Transfer layer, each with
up to 64 MAPs attached to it within the Segmentation layer. This theoretically huge
multiplexing capability is an artifact of the decision to provide alternative multiplexing
mechanisms, and a real implementation will usually use a much more restricted repertoire of
MAP and VC capabilities.

3 . 2 . 2 TC TRANSFER LAYER

The basic service of the TC Transfer layer is the GUARANTEED error-free communication of
higher layer TC data units to the receiving end of the layer above, correct and without omission
or duplication, and in the same sequential order in which they were received from the layer
above at the sending end. THIS GUARANTEED SERVICE IS CENTRAL TO THE
OPERATING PHILOSOPHY OF THE TC SYSTEM: the Transfer layer is therefore the
"core" of the standard CCSDS telecommanding concept. In order to provide this service, the
TC Transfer layer draws upon the supporting lower layer TC Channel Service. Figure 3-5
depicts the activities and interfaces of the TC Transfer layer.

The sending end of the TC Transfer layer encapsulates each higher layer TC data unit (e.g., TC
Packet, TC Segment or a non-standard user data structure) within the data field of a TC
Transfer Frame: one (and ONLY one) TC data unit is inserted into the data field of each frame.
The header of the TC Frame contains key data link control information such as spacecraft and
Virtual Channel identification, frame sequence number, and frame length.

The operating configuration of the TC Transfer layer is specified by control instructions

received from higher layers. The sending end of the Transfer layer formulates special TC
Transfer Frames called "Control Commands" which it transmits to a "Frame Acceptance and

Issue 6 Page 3-8 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

TRANSFER LAYER

SENDING PEER RECEIVING

END PROCESS END
SEGMENTATION LAYER

INPUT: SEGMENTS. OUTPUT: SEGMENTS.

DELIVERY CONDITIONS.

FUNCTION: ENCAPSULATE RELIABLY FUNCTION: RECONSTITUTE

SEGMENTS AND DELIVERY DELIVER ORDERED SET OF TRANSFER
CONDITIONS INTO SERVICE FRAMES. PERFORM FRAME
TRANSFER FRAMES. TRANSFER ACCEPTANCE AND
MULTIPLEX FRAMES BY FRAMES VALIDATION CHECKS.
VIRTUAL CHANNEL. REPORT STATUS OF SAME VIA
MONITOR FRAME ACCEPTANCE. TRANSFER CONSTRUCTED CLCWs.
INITIATE TRANSMISSION/ FRAMES EXTRACT SEGMENTS.
RETRANSMISSION AS REQ'D.
COMMAND LINK
OUTPUT: BUFFER OF TC DATA CONTROL WORD INPUT: "CLEAN" TC DATA PLUS
BITS (REPRESENTING, E.G., FILL BITS. DATA START/STOP
(CLCW)
TRANSFER FRAMES). INDICATORS. STATUS

CODING LAYER

Figure 3-5: TC Transfer Layer

Reporting Mechanism" (FARM) at the receiving end of the layer in order to set up the receiving
parameters.

The sending end of the layer passes the assembled TC Frames to a "Frame Operation
Procedure" (FOP), which provides the control of their transmission to the spacecraft. The
FOP batches the TC Frames and delivers them to the layer below (the Coding layer) as buffers
of serial information bits (corresponding to one or more back-to-back frames) for encoding and
transmission to the spacecraft.

At the receiving end of the TC Transfer layer, the inputs from the layer below are "clean"
decoded information bits and data stop/start indicators which mark the gross boundaries of the
buffers of bits that were given to the Coding layer at the sending end: however, trailing fill bits
Issue 6 Page 3-9 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

may have been inserted by the encoding process. The Transfer layer therefore uses the length
information in each TC Frame to delimit each frame in the buffer, and to discard any trailing
fill.

The reconstructed, delimited frames are input to the receiving-end FARM, which performs
validation and acceptance checks based on sequence information and other criteria that are fully
specified in Reference [3]. The status of frame acceptance by the FARM is telemetered back to
the FOP at the sending end via the Command Link Control Word (CLCW) in the trailers of
standard Telemetry Transfer Frames. The pair of peer-layer procedures executed by the FOP
and FARM are together known as a "Command Operation Procedure" (COP). Based on
CLCW reports from the FARM, the FOP makes appropriate retransmission decisions for
frames which were rejected or otherwise missed by the FARM, according to the rules of the
governing COP.

Under closed-loop retransmission control of the selected COP, and utilizing the error-
protection services of lower layers, the TC Frames are assembled at the receiving end of the
layer so that they are error-free, in sequence and with no omission or duplication. Once this
service is guaranteed, their data contents are then stripped and passed to higher layers.

Three COPs, which are recursively related to each other, are presently defined. In order of
increasing complexity they are:

(1) COP-0

COP-0 operates on the principle of sequential frame acceptance and retransmission,

without frame sequence numbering. The FOP initiates the transmission of TC
Frames whose sequence numbers are not used. The FARM only accepts frames if
they are received without detected error. As soon as an error is encountered, the
FARM enters a lockout condition and rejects all subsequent frames until reset by a
Control Command from the FOP. The FOP monitors a CLCW counter, generated
by the FARM, that indicates how many good frames were accepted. When it
observes the FARM in lockout, it uses this counter to compute how far to back up,
sends an unlock command, and begins retransmission.

(2) COP-1

COP-1 operates on the principle of sequential frame acceptance and retransmission,

with frame sequence numbering. The FOP initiates the transmission of TC Frames
whose sequence numbers are arranged in upcounting sequential order. The FARM
only accepts frames if their sequence numbers match the expected upcounting
order. As soon as a sequence error is encountered, the FARM rejects all
subsequent frames whose sequence numbers do not match the expected order. The
FOP monitors the CLCW to determine if frames are being rejected, and if so backs
up and retransmits the series of frames, beginning with the frame whose sequence
number matches the number which the FARM is expecting.

Issue 6 Page 3-10 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

(3) COP-2

COP-2 operates on the principle of sequence-independent frame acceptance and

selective retransmission, with frame sequence numbering. The FOP initiates the
transmission of TC Frames whose sequence numbers are originally arranged in
upcounting sequential order. Although nominally expecting the received frames to
be in sequential order, the FARM will accept any frame whose sequence number
falls within certain allowable windows. Any discontinuities in the received
sequence are noted by the FARM, and the sequence numbers of detected "missing"
frames are reported to the FOP via telemetered CLCWs. The FOP then schedules
the retransmission of these missing frames at an opportune time.

Since the numbering of frames is a key feature of COP-1 and COP-2, it is important to
understand the terminology which is used within the CCSDS Recommendations:

(1) The FOP, which is the numbering authority, maintains a master counter which
assigns the frame sequence number. The current value of this master counter, i.e.,
the number which will be assigned to the NEXT TC Frame, is called V(S).

(2) The frame sequence number which is contained within any particular transmitted
TC Frame is called N(S).

(3) The FARM maintains a counter which contains the value of the next TC Frame
sequence number which it expects to receive. The current value of this counter is
called V(R).

(4) The telemetered CLCW contains reports of the observed values of V(R). The
observed value of V(R), received by the FOP in a particular CLCW, is called N(R).
This relationship is summarized in Figure 3-6.

"N (S)"
SENDING END RECEIVING END

TC FRAME
FOP FARM
"V (S)" "V (R)"
CLCW

"N (R)"

COP

Figure 3-6: Transfer Layer Numbering Relationships

Issue 6 Page 3-11 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

3 . 3 TC CHANNEL SERVICE

Operation of the TC Channel Service begins when at least one complete TC Transfer Frame is
prepared for radiation through the telecommand channel to the spacecraft. The TC Channel
Service provides error-controlled transmission of the TC Frame(s) through the channel. Error
control is achieved via forward error detection/correction techniques. The TC Channel Service
is composed of two layers, the Coding layer and the Physical layer. The operating data
structures and protocols for the Channel Service are specified in Reference [4].

3 . 3 . 1 TC CODING LAYER

The basic service of the TC Coding layer is to provide for the reliable delivery of TC
information bits across the physical medium to the spacecraft. Figure 3-7 depicts the activities
and interfaces of the TC Coding layer.

CODING LAYER

SENDING PEER RECEIVING

END PROCESS END
TRANSFER LAYER

INPUT: BUFFER OF TC DATA OUTPUT: "CLEAN" TC DATA PLUS

BITS (REPRESENTING, E.G., FILL BITS. DATA START/STOP
TRANSFER FRAMES). INDICATORS. STATUS

FUNCTION: ENCODE RELIABLY FUNCTION: SYNCHRONIZE

TRANSFER FRAMES (ADD TRANSMIT DECODER.
FILL BITS AS REQUIRED). SERVICE TRANSFER DECODE CODEBLOCKS.
CREATE CLTUs. FRAMES THRU ERROR DETECT OR
LINK TO S/C CORRECT.

COMMAND
LINK
TRANSMISSION
UNITS (CLTU)
OUTPUT: CLTUs INPUT: "DIRTY" SYMBOL
NONE STREAM. STATUS.

PHYSICAL LAYER

Figure 3-7: TC Coding Layer

Issue 6 Page 3-12 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Inputs to the sending end of the Coding layer are buffers of TC information bits from the layer
above. Each buffer corresponds to one or more serial, back-to-back TC Transfer Frames. The
information bits are encoded, piece by piece, into short fixed length TC Codeblocks, whose
format and encoding technique is specified in Reference [4]. Each Codeblock contains parity
bits that provide error detection or correction capabilities for the information bits. Fill bits may
be added by the Coding layer to complete the last Codeblock.

The sequence of TC Codeblocks (i.e., the symbol representation of one or more TC Frames
plus any appended fill) is then encapsulated into a Command Link Transmission Unit (CLTU).
The boundaries of the CLTU are delimited for the receiving end of the Coding layer by the
Start and Tail sequences. The delimited CLTUs are passed to the layer below, the TC Physical
layer, for modulation onto the space data channel.

At the receiving end of the TC Coding layer, a "dirty" (potentially corrupted by channel noise)
symbol stream plus control information (e.g., whether the physical channel is active or
inactive) is received from the layer below. Searching for the Start sequence, the Coding layer
finds the boundaries of the CLTU, synchronizes the decoder with the TC Codeblocks, and
decodes them. The decoder may operate in an error-detecting-only mode, or may optionally
perform error correction. If no errors are detected, or (optionally) if errors are detected and
corrected, the Coding layer passes "clean" octets of decoded TC data to the layer above
(including any appended fill): CLTU Start and Tail Sequences, which are not decodable
codeblocks, are not transferred. Should an (optionally uncorrectable) error be estimated to have
occurred within any TC Codeblock within a given sequence, the remainder of the sequence is
discarded and no further data are passed to the layer above until the Coding layer is reset by the
detection of another Start sequence. There are no reporting mechanisms between the receiving
and sending ends of the Coding layer.

3 . 3 . 2 TC PHYSICAL LAYER

The service of the TC Physical layer is to provide a physical connection, via radio signals,
between the transmitting station and the receiving spacecraft. Figure 3-8 depicts the activities
and interfaces of the TC Physical layer.

Inputs to the sending end of the Physical layer are CLTUs, plus control information from the
layer above defining the requested transmission services. The Physical layer controls the
activation and deactivation of the physical channel by invoking various "Physical Layer
Operations Procedures" (PLOPs).

A PLOP consists of sequential application of different "Carrier Modulation Modes" (CMMs).

The CMMs include an unmodulated carrier, a carrier modulated with an Acquisition sequence,
a carrier modulated with TC symbols corresponding to one CLTU, and a carrier modulated
with an Idle sequence. Using an appropriate PLOP, the CLTUs are radiated to the spacecraft
as physical waveforms.

Issue 6 Page 3-13 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

PHYSICAL LAYER

SENDING PEER RECEIVING

END PROCESS END
CODING LAYER

INPUT: CLTUs OUTPUT: "DIRTY" SYMBOL

STREAM. STATUS.

PROVIDE
FUNCTION: CREATE PLOPs. FUNCTION: SYMBOL DETECT.
ACTIVATE TELECOMMAND PHYSICAL DEMODULATE. SYNCHRONIZE.
SERVICE
CHANNEL. ESTABLISH CONNECTION
CARRIER/SUBCARRIER.
TO S/C
MODULATE WAVEFORMS.

PHYSICAL
WAVEFORM

OUTPUT: MODULATED INPUT: MODULATED

PHYSICAL WAVEFORMS. NONE PHYSICAL WAVEFORMS.

PHYSICAL MEDIUM

Figure 3-8: TC Physical Layer

At the receiving end of the TC Physical layer, the modulated radio frequency waveforms are
received, detected, demodulated, and symbol-synchronized: the Acquisition sequence provides
a preamble for synchronization purposes. The synchronized "dirty" symbol stream is delivered
to the layer above, along with control information describing the status of the rf processes.

3 . 4 INTER-LAYER DATA EXCHANGE

The present set of CCSDS Recommendations for telecommand deals primarily with the
specification of the layered architecture and the data structures and protocols which operate
ACROSS each layer. The mechanisms for transferring TC data and their associated control

Issue 6 Page 3-14 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

instructions BETWEEN the layers are currently left unspecified. However, the CCSDS is
currently developing a concept for a general set of "standard data interchange structures"
(Reference [9]) which could facilitate such inter-layer communication, particularly at the
sending end of the TC System. Instances of standard data interchange structures known as
"Standard Formatted Data Units" (SFDUs) will probably be developed to perform the
interconnection of the sending-end layers: at present these are left as potential items of future
work for the CCSDS.

It should also be noted that the layered hierarchy does not also imply that the time-ordered
FLOW of operations through the layers is necessarily sequential. For instance, it is perfectly
valid to pre-assemble and pre-number TC Frames, pre-encode them, batch them into CLTUs
and then put the prefabricated CLTUs "on the shelf" for later radiation under control of the
Transfer layer FOP and the Physical layer PLOP. The inter-layer control instructions must
accommodate such non-time-sequential operations.

3 . 5 INTER-AGENCY CROSS-SUPPORT SERVICES

A major feature of the layered CCSDS TC System architecture is its potential for providing a
significantly more comprehensive level of cross support between Agencies than is possible at
present, thus enabling the development of simple and cost-effective interfaces for the wide
range of international space missions which are anticipated in the future. However, the present
CCSDS Recommendations have not addressed the physical implications of cross support.

The CCSDS has established a systems panel to study and recommend the various inter-Agency
cross-support gateways and service access points. The current status of this work may be
found in Reference [10].

Issue 6 Page 3-15 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

ANNEX A

ACRONYMS AND TERMINOLOGY

Issue 6 Page A-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

ACRONYMS

CCSDS: CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS

CLCW: COMMAND LINK CONTROL WORD
CLTU: COMMAND LINK TRANSMISSION UNIT
CMD: COMMAND
CMM: CARRIER MODULATION MODE
COP: COMMAND OPERATION PROCEDURE
FARM: FRAME ACCEPTANCE AND REPORTING MECHANISM
FOP: FRAME OPERATION PROCEDURE
HDR: HEADER
ID: IDENTIFIER
MAP: MULTIPLEXER ACCESS POINT
N(R): THE VALUE OF V(R) WHICH IS OBSERVED BY THE FOP IN A
PARTICULAR CLCW
N(S): THE SEQUENCE NUMBER ASSIGNED BY THE FOP TO A
PARTICULAR TRANSMITTED TC FRAME
PKT: PACKET
PLOP: PHYSICAL LINK OPERATIONS PROCEDURE
RF, rf: RADIO FREQUENCY
S/C: SPACECRAFT
SEG: SEGMENT
ST SEQ: START SEQUENCE
TC: TELECOMMAND
TLM: TELEMETRY
VC: VIRTUAL CHANNEL
V(R): THE NEXT EXPECTED TC FRAME SEQUENCE NUMBER; A
COUNTER MAINTAINED BY THE FARM
V(S): THE SEQUENCE NUMBER WHICH THE FOP WILL ASSIGN TO THE
NEXT TRANSMITTED TC FRAME

Issue 6 Page A-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

TERMINOLOGY

ACCEPT:

Within the Transfer layer, recognition by the receiving end that a TC Frame has passed the
validation and acceptance test criteria as programmed into the Frame Acceptance and Reporting
Mechanism.

APPLICATION PROCESS LAYER:

The upper layer of the Telecommand Data Management Service.

CHANNEL SERVICE:

In the space data systems layered service architecture, the bottom service of the Telecommand
System. Among its services it delivers the encoded bits of a buffer of transfer frames across
the physical communications link under error-controlled conditions.

CLEAN:

Data which are declared to be error free within the error detection and (optional) error
correction capabilities of the TC Coding layer.

CODEBLOCK:

The protocol data unit of the TC Coding layer. A TC Codeblock contains the encoded symbol
representation of a small set of contiguous TC information bits.

CODING LAYER:

The upper layer of the TC Channel Service.

COMMAND:

An instruction sent from a user to a receiving application process in space in order to effect a
change in that process.

COMMAND DIRECTIVE:

A machine-interpretable representation of a user-desired command action.

Issue 6 Page A-3 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

COMMAND LINK CONTROL WORD:

The TC Transfer layer protocol data unit for telecommand reporting, which is embedded in the
trailer of a CCSDS Telemetry Transfer Frame. It conveys status information from the
receiving end to the sending end of the TC Transfer layer.

COMMAND LINK TRANSMISSION UNIT:

Within the Coding layer, the protocol data unit which carries buffers of error-protected
symbols (corresponding to one or more encoded Telecommand Transfer Frames) during
transfer through the data channel to the spacecraft.

COMMAND OPERATION PROCEDURE (COP):

A sequence of procedural activities designed to assure the reliable, error-controlled delivery of

Telecommand Transfer Frames. Each COP comprises a Frame Operation Procedure operating
within the sending end and a Frame Acceptance and Reporting Mechanism operating within the
receiving end.

CONTROL COMMAND:

A special, dedicated TC Transfer Frame containing control information to set up the receiving
parameters of the spacecraft end of the TC Transfer layer.

CONTROL INSTRUCTION:

A data object which is passed between layers within the TC System in order to set up the
parameters of data transfer.

DATA MANAGEMENT SERVICE:

In the space data systems layered telecommand architecture, the top service of the
Telecommand System. It includes the primary facilities for interfacing the user with the
systems used to communicate telecommands. Its bottom layer provides a protocol data unit
known as a Telecommand Packet, which provides data formatting services so that command
data may be transported between user application processes.

DATA ROUTING SERVICE:

In the space data systems layered telecommand architecture, the middle service of the
Telecommand System. It provides a fundamental service within the TC System by
guaranteeing the delivery of TC data from the sending to the receiving ends of the ground-to-
space data link.

Issue 6 Page A-4 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

DELIVERY:

The process of passing transported telecommand data across the interface to the Application
Process layer at the receiving end of the TC System.

DELIVERY CONDITIONS:

Control instructions, generated by the Application Process layer, which specify the parameters
and conditions that are required to exist within lower layers in order to perform the delivery of
telecommands from the sending to the receiving end of the TC System.

EXECUTION:

The act of effecting a commanded change within a spacecraft application process, in response
to a telecommand which has been delivered to that process.

FILE:

An ordered aggregation of interrelated Telecommand Packets corresponding to a single, well

defined spacecraft activity. A TC File has three distinguishing characteristics: 1) it has a File
name; 2) it has a pre-defined length; and 3) it must be delivered intact and complete before
being released for execution.

MULTIPLEXER ACCESS POINT (MAP):

An input port to the TC Segmentation layer which enables all user data units who are members
of the sequence present at that port to be uniquely identified. Use of MAPs permits different
streams of user data to be multiplexed together onto one Virtual Channel for flow control
purposes.

OCTET:

An 8-bit word consisting of eight contiguous bits.

PACKET:

The protocol data unit of the TC Packetization layer which facilitates the end-to-end transport of
command application data. The application data are encapsulated within a leading packet
header.

PACKETIZATION LAYER:

The bottom layer in the Telecommand Data Management Service.

Issue 6 Page A-5 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

PHYSICAL LAYER:

The bottom layer of the TC Channel Service.

PHYSICAL LAYER OPERATION PROCEDURE (PLOP):

A sequence of procedural activities designed to activate and deactivate the physical

telecommand channel by invoking radio frequency carrier and modulation techniques.

PROTOCOL:

A set of standard rules and procedures, plus their accompanying format conventions, that
define the orderly exchange of information between peer entities within a given layer of the TC
System.

RELIABLE:

Meeting the data quality, quantity, continuity, and completeness performance criteria which are
specified for the Telecommand System.

SEGMENT:

The protocol data unit of the TC Segmentation layer which facilitates breaking long user data
units into shorter, communications-oriented pieces and multiplexing them together for flow
control purposes.

SEGMENTATION LAYER:

The upper layer of the TC Data Routing Service.

SESSION:

A period of time throughout which the sending and receiving ends of the TC System
communicate for the purpose of transferring TC data.

SYMBOL:

A serial representation of bits, or binary digits, which have been encoded to protect them
against transmission induced errors.

SYSTEM MANAGEMENT LAYER:

The middle layer of the Telecommand Data Management Service.

Issue 6 Page A-6 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

TELECOMMAND:

A generic term used to describe command data during the time that they are being
telecommunicated to the spacecraft.

TELECOMMAND SYSTEM:

The end-to-end system of layered space mission telecommunication services which exist to
enable a user to send commands, in a reliable and transparent error-controlled environment, to
receiving elements in space.

TRANSFER FRAME:

The protocol data unit of the TC Transfer layer, which facilitates the transfer of TC data to a
spacecraft through a space data link.

TRANSFER LAYER:

The lower layer of the TC Data Routing Service.

TRANSPARENT:

As viewed by the user, the invisible and seemingly direct (virtual) transfer of command data
from the command originating point to the controlled process.

USER:

A human or machine-intelligent process which directs the progress of a space mission by

sending commands to a space system.

VALIDATION:

A process performed at the receiving end of the Transfer layer to check the integrity of a TC
Transfer Frame.

VIRTUAL CHANNEL:

Within the TC Data Routing Service, an identifier which permits all Transfer Frames who are
members of a given sequence to be uniquely identified. It permits multiple user data types to
be multiplexed together so that they may share the finite capacity of the single physical space
data channel.

Issue 6 Page A-7 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

ANNEX B

TELECOMMAND TRANSFER FRAME

ERROR DETECTION

ENCODING/DECODING GUIDELINE

Purpose:

This Annex provides a description of the error detection encoding and decoding procedures
which may be used in association with the optional Frame Error Control field of the
Telecommand Transfer Frame.

Issue 6 Page B-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

B - 1 CODING FOR ERROR DETECTION IN TRANSFER FRAMES

This Annex describes the error detection encoding/decoding procedure that is recommended for
Transfer Frame coding.

The code specifies the same generator polynomial used by HDLC (ISO), ADCCP (ANSI),
V.41 (CCITT), etc. It has the following capabilities when applied to an encoded block of less
than 32,768 (215) bits:

(1) All error sequences composed of an odd number of bit errors are detected.

(2) All error sequences containing at most two bit errors anywhere in the encoded block
will be detected.

(3) If a random error sequence containing an even number of bit errors (greater than or
equal to 4) occurs within the block, the probability that the error will be undetected
is approximately 2-15 (or approximately 3 x 10-5).

(4) All single error bursts spanning 16 bits or less will be detected provided no other
errors occur within the block.

B-1.1 ENCODING PROCEDURE

The encoding procedure accepts an (n-16)-bit data block and generates a systematic binary
(n,n-16) block code by appending a 16-bit Frame Check Sequence (FCS) as the final 16 bits of
the codeblock. This FCS is inserted into the Frame Error Control Word of the Transfer Frame
Trailer. The equation for the FCS is:

FCS = [X16 . M(X) ⊕ X(n-16) . L(X)] modulo G(X)

where

M(X) is the (n-16)-bit message to be encoded expressed as a polynomial with binary

coefficients

L(X) is the presetting polynomial given by:

15
L(X) = ∑ xi (all "1" polynomial of order 15)
i=0

Issue 6 Page B-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

G(X) is the generating polynomial given by:

G(X) = X16 + X12 + X5 + 1

n is the number of bits in the encoded message

⊕ is the modulo 2 addition operator (Exclusive OR)

Note that the encoding procedure differs from that of a conventional cyclic block encoding
operation in that:

The X(n-16) . L(X) term has the effect of presetting the shift register to an all "1" state
prior to encoding.

B-1.2 DECODING PROCEDURE

The error detection syndrome, S(X), is given by

S(X) = [X16 . C*(X) ⊕ Xn . L(X)] modulo G(X)

where C*(X) is the received block in polynomial form and S(X) is the syndrome polynomial
which will be zero if no error is detected and non-zero if an error is detected.

B - 2 POSSIBLE IMPLEMENTATION

A possible implementation of the above-defined encoding/decoding procedure is described

below.

B-2.1 ENCODING

Figure B-1 shows an arrangement for encoding using the shift register. To encode, the storage
stages are set to "one", gates A and B are enabled (closed), gate C is inhibited (open), and
(n-16) message bits are clocked into the input. They will appear simultaneously at the output.
After the bits have been entered, the output of gate A is clamped to "zero", gate B is inhibited,
gate C is enabled, and the register is clocked a further 16 counts. During these counts the
required check bits will appear in succession at the output.

Issue 6 Page B-3 January 1987

 CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

GATE A

GATE C

GATE B
INPUT OUTPUT

Figure B-1: Encoder

B-2.2 DECODING

Figure B-2 shows an arrangement for decoding using the shift register. To decode, the storage
stages are set to "one" and gate B is enabled. The received n-bits [the (n-16) message bits plus
the 16 bits of the FCS] are then clocked into the input. After n-16 counts, gate B is inhibited,
the 16 check bits are then clocked into the input, and the contents of the storage stages are then
examined. For an error-free block, the contents will be zero. A non-zero content indicates an
erroneous block.

GATE B
INPUT OUTPUT

Figure B-2: Decoder

Issue 6 Page B-4 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

ANNEX C

DATA PROTECTION CONCEPT

Purpose:

This Annex defines a concept for the protection of Telecommand data sets so that security
measures may be implemented if required by a particular mission.

Status:

This Annex is currently under development by the CCSDS.

Issue 6 Page C-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

For many missions, there is a firm requirement to prevent intentional or accidental commanding
of the spacecraft by an unauthorized party. Some missions may also have user requirements to
render the application data private so that they cannot be interpreted by unauthorized users.
The methods which are implemented within the Telecommand System to satisfy these
requirements are called Data Protection mechanisms.

Data Protection may be provided by physical or logical mechanisms. Physical mechanisms

involve restricting personnel and terminal access to the networks through which command data
flow. Logical mechanisms involve transformations of the command data in a manner which
makes unauthorized manipulation or interpretation extremely difficult.

The necessarily open nature of most space data networks makes physical protection of the
entire network impractical. In this environment, the Data Protection mechanisms must permit
operation identical to "clear-text" communications flow through the mission's data networks
insofar as provision of normal network telecommunications services are concerned. The
CCSDS has therefore adopted two techniques which facilitate providing logical Data Protection
within the Telecommand System: these are ENCRYPTED AUTHENTICATION and
DATA ENCRYPTION.

These techniques provide means to ensure that either:

(1) a command comes from an authorized source and that an unauthorized party cannot
modify the information which is conveyed within its structure (Encrypted
Authentication) and/or

(2) that an unauthorized user cannot interpret its meaning (Data Encryption).

A given system may use Encrypted Authentication only, or both Encrypted Authentication and
Data Encryption together.

(1) Encrypted Authentication

The CCSDS concept for providing Encrypted Authentication is that the sending end
of the authentication process generates a unique authentication word by sending an
encrypted block. This Encrypted Authentication word accompanies each clear-text
block (user data unit) that is transmitted. The receiving equipment recognizes the
Encrypted Authentication word by performing complementary decryption and
checking functions, thus fully establishing the authenticity of the received user data
unit. When Encrypted Authentication alone is used, the command application data
themselves are not modified.

The Encrypted Authentication word is attached to the user data unit before transport
to the spacecraft, and when received and recognized, an appropriate status message
must be telemetered in clear-text back to the sending end for verification. This
feature enables the system to recover from an interruption of the communications
channel.
Issue 6 Page C-2 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

(2) Data Encryption

Data Encryption, which is a logical mechanism for providing Data Protection,

implies that the command application data are transformed (rendered secret) to make
them unintelligible to an unauthorized observer. A system using both Data
Encryption and Encrypted Authentication thus differs from a system using only
Encrypted Authentication since in the latter the application data are not transformed.
In a Data Encryption system, the telecommand application data are transformed by
applying special algorithms and can only be interpreted after processing by a
complementary process at the receiving end.

The CCSDS makes no recommendation for the choice of an Encrypted

Authentication or Data Encryption algorithm, or for the associated management
procedures. The choice of algorithms is therefore left to the participating Agencies.
However, the CCSDS does have some system-level requirements which are
intended to ensure that the Encrypted Authentication or Data Encryption system
characteristics are consistent with interoperability. These requirements are the
following:

(a) The command Encrypted Authentication and/or Data Encryption system shall
operate normally within the Packetization, and/or Segmentation, and/or
Transfer layers. For those missions which do not implement the TC Packet,
Segment, or Transfer Frame data structures, the Encrypted Authentication or
Data Encryption system should operate within the corresponding layers of the
non-standard system. A standardized mechanism for implementing the
system at the sending and receiving ends of the Packetization, Segmentation,
and Transfer layers is recommended as being the most secure and
manageable.

(b) The Encrypted Authentication or Data Encryption mechanism shall not

interfere with the standard telecommand verification techniques which operate
within the CCSDS TC Transfer layer, and shall permit recovery from the
effects of errors or interruptions in the communications process.

(c) If implemented above the TC Packetization layer, the Encrypted

Authentication word or transformed portion of the data shall be included
completely within the Application Data field of the TC Packet.

(d) If implemented above the TC Segmentation layer, the Encrypted

Authentication word or transformed portion of the data shall be included
completely within the Segment Data Field of the TC Segment.

(e) If implemented above the TC Transfer layer, the Encrypted Authentication

word or transformed portion of the data shall be included completely within
the "Frame Data" field of the TC Transfer Frame (AD or BD frames only); if
implemented within the TC Transfer layer, these shall be included completely
Issue 6 Page C-3 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

within the "Qualifying Data" field of a TC Transfer Frame (Type BC) which
carries a Control Command.

(f) The selected Encrypted Authentication or Data Encryption technique shall be

transparent to the lowest layers of the TC System; i.e., the TC Coding and TC
Physical layers. The Encrypted Authentication or Data Encryption technique
shall not require the implementation of any physical security mechanisms
within these lowest layers.

It should be noted that since bulk-encryption of Telecommand data at the Physical layer does
not allow any interoperability except at the bit level, it is not a CCSDS-recommended
technique.

Issue 6 Page C-4 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

ANNEX D

TELECOMMAND SYSTEM

PERFORMANCE NOTES

Purpose:

This Annex provides information on the performance that may be achieved for the various
telecommand strategies and options given in the Recommendation for Telecommand.

Status:

This Annex is currently under development by the CCSDS.

Issue 6 Page D-1 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

D-1 INTRODUCTION

This Annex discusses the Telecommand (TC) Performance which may be obtained using the
data units, techniques, and strategies described in the CCSDS Recommendation for
Telecommand, Part 1: Channel Service (Reference [4]) and Recommendation for
Telecommand, Part 2: Data Routing Service (Reference [3]). Performance data are presented
to enable the system engineer to select values of relevant coding parameters and operational
strategies so that system performance requirements may be satisfied. Telecommand operating
strategies are described for different environments, as well as the procedures that are elements
of the strategies.

D-2 PERFORMANCE CRITERIA AND NATURE OF THE PROBLEM

The objective of the Telecommand Service is to provide a highly reliable uplink service.
"Reliable" service is considered to be achieved when the following two performance criteria are
simultaneously met by the overall telecommand system:

(1) TC Frame Deletion Rate

A maximum of one telecommand frame is deleted (rejected) for every 1000 frames
transmitted. This operating point is defined to be "Command Threshold".

(2) TC Frame Undetected Error Rate

A maximum of one telecommand frame for every 109 telecommand frames

transmitted is erroneously accepted (that is, contains one or more undetected bit
errors).

It should be noted that since performance is measured in terms of frames, considerations

discussed herein extend through the physical and coding layers of the Channel Service and the
transfer layer of the Data Routing Service.

D-2.1 Performance Components

The basic accounting unit of Telecommand is therefore the TC frame. To meet these
performance objectives for the frame, the Channel Service and Data Routing Service specify
standard techniques for constructing and handling the TC frame and its components:

(1) To achieve bit acquisition (synchronization).

(2) To delimit the beginning of a continuum of bits (CLTU) comprising the

telecommand bit stream.

Issue 6 Page D-2 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

(3) To encode the bit stream into a series of standard codeblocks which can provide
error detection and/or correction.

(4) To delimit the beginning and end of each telecommand frame.

(5) To provide an optional error check over each telecommand frame to improve
protection against undetected errors.

(6) To delimit the end of a CLTU to prepare the spacecraft decoder to recognize the
start of the next continuum (CLTU).

In addition, Reference [4] describes certain optional strategies (e.g., no errors vs. one error
allowed in the CLTU start sequence). The performance of each of these is also discussed.

STRATEGIES

Reference [4], Section B-4, recommends two alternative strategies for combining telecommand
options when a CLTU is sent. These are:

Strategy 1:

START - CLTU Start Sequence with no errors allowed

CODEBLOCKS - Decoded in Triple Error Detection mode
FINISH - Tail Sequence Codeblock Rejection or Stop modulation

Strategy 2:

START - CLTU Start Sequence with 0 or 1 error allowed

CODEBLOCKS - Decoded in Single Error Correction, Double Error Detection mode
FINISH - Tail Sequence Codeblock Rejection or Stop modulation

In general, Strategy 1 may be used when it is important to reduce the undetected error rate,
while Strategy 2 may be used to reduce the operational complexities of retransmission.

Each of the data units and their performance will be reviewed in the following material.
References [4] and [3] specify the details of constructing the above elements; this Annex
describes how the on-board telecommand system handles each element and the performance
that may be obtained. Throughout this note a binary symmetric telecommand channel with
additive white gaussian noise is assumed.

Issue 6 Page D-3 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

D-2.2 On-Board Telecommand Logic

The Receiving End (i.e., spacecraft) telecommand decoder state diagram, upon which these
discussions are based, is shown in Figure 3-4 of Reference [4] and is duplicated in this report
as Figure D-1.

E4

E1 E3

S1 S2 S3
(INACTIVE) (SEARCH) (DECODE)
E2

E2

Figure D-1: TC Decoder State Diagram

Inactive State. The initial state for the TC channel is State 1 (S1), the INACTIVE state,
where no bit modulation is detected. When a TC bit stream is detected (telecommand
modulation applied and bit synchronization achieved), Event 1 (E1) occurs, CHANNEL
ACTIVE. If the TC signal is lost or there is a loss of bit lock, Event 2, CHANNEL
INACTIVE, occurs, and the spacecraft decoder returns to the INACTIVE state (S1).

Search State. When E1 occurs, the logic goes into the SEARCH state (S2). The unit that
governs this event is the CLTU Start Sequence. The bit stream is searched for the CLTU Start
Sequence; when the pattern has been detected, the decoder declares Event 3 (E3), START
SEQUENCE FOUND, and assumes the next bit delimits the beginning of the first codeblock
of a continuum of codeblocks of the CLTU. (Note: a codeblock is a codeword plus a filler
bit.)

The probability of E3 occurring depends upon: 1) the decoder actually being in the SEARCH
state when the start sequence arrives; 2) the bit error rate (BER) of the channel; and 3) the
decoding strategy used. If, at this point, the TC signal is lost or there is a loss of bit lock, E2
occurs and the telecommand decoder returns to S1.

Decode State. Assuming E3 has occurred, the decoder enters the DECODE state, S3. The
data unit that governs the DECODE state is the TC Codeblock. All TC Codeblocks are
received and decoded in either the Triple Error Detection (TED) mode, or the Single Error
Correction (SEC) mode. The use of mixed decoding modes may require additional
coordination and more complex analysis. The data contents of decoded (valid) codeblocks are
transferred to the layer above (i.e., the TC Frame Layer). The probability of the telecommand
Issue 6 Page D-4 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

decoder remaining in this state is a function of the decoding strategy, the BER, the length of the
codeword (n), in bits, and the number of codewords in the CLTU.

Return from Decode State. If, during the decoding process, the decoder rejects a
codeblock due to errors, no data from this codeblock are transferred to the layer above. This
situation corresponds to Event 4 (E4), CODEBLOCK REJECTION, which returns the decoder
to the SEARCH state (S2).

To end a CLTU, a Tail Sequence is included. The Tail Sequence is a codeblock (of the same
length as all other codeblocks in the stream) having a unique pattern constructed in such a way
to fail the decoder parity check and cause a CODEBLOCK REJECTION (E4), thereby
interrupting the telecommand continuum. No further codeblocks are decoded, no further
transfer of codeblock contents to the frame layer is possible, and the decoder logic returns to
the SEARCH state (S2). Note that the ONLY function of the Tail Sequence is to force the
decoder logic to the SEARCH STATE at the end of a CLTU: the Tail Sequence should not be
used to delimit the end of a frame. This is because, in general, 1) there may be more than one
frame in the CLTU, and 2) a frame that is not long enough to fill the last codeblock must be
followed by fill bits (which are not part of the frame) to complete that codeblock.

If, during the decoding process, the physical layer signal is lost (carrier, modulation or bit
sync), event E2, CHANNEL INACTIVE, occurs. Upon this event, the decoder returns to the
INACTIVE state, S1.

Assembling the Frame. If all codeblocks comprising a complete transfer frame are
successfully decoded, the frame layer recognizes that the frame it has been assembling from
each codeblock is complete when the number of octets received equals one more than the count
presented in the "Frame Length" field of the Transfer Frame Header. The frame can then be
transferred to the addressee. Other frames in the CLTU are similarly transferred upon
completion. If the continuum of codeblocks from the decoder is interrupted (i.e.,
CODEBLOCK REJECTION has been declared for whatever reason) and the frame length
received does NOT yet equal one more than the count in the "Frame Length" field, that frame is
rejected by the frame layer. Further action by the frame layer to recover the frame is dependent
on the Command Operations Procedure (COP) in use. This process is more fully described in
Reference [3]. Other checks on the frame, such as testing for previously undetected errors,
may also be made at the frame layer before declaring acceptance or rejection, and before
forwarding to the addressee.

D-3 FACTORS AFFECTING FRAME REJECTION RATE

Each of the factors of performance of frame rejection rate are detailed below. In subsequent
sections, the performance for several different CLTU organizations is given.

Issue 6 Page D-5 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

D-3.1 Bit Synchronization Factor

Initially, the on-board decoder is in the INACTIVE state. When a signal first appears
(subsequent to achieving rf carrier lock), it will contain an acquisition pattern consisting of a
series of alternating "ones" and "zeros". This pattern has the maximum transition density so as
to provide the fastest lock-up time for the on-board bit synchronizer. The preferred length of
128 bits was chosen to provide 0.9999 probability of acquisition of bit sync based on
experience with a number of hardware implementations operating at the command threshold
level.1 Clearly, this length may be modified as needed to suit different hardware characteristics
or channel bit error rates (such as, for example, a noise-free channel used during ground
testing). When bit synchronization has been achieved, the decoder leaves the INACTIVE state
and enters the SEARCH state.

BECAUSE THE PROBABILITY OF ACHIEVING BIT SYNCHRONIZATION IS

PRIMARILY HARDWARE-DEPENDENT, THIS ANALYSIS WILL ASSUME THAT BIT
SYNCHRONIZATION HAS ALREADY BEEN ACHIEVED.

D-3.2 CLTU Start Sequence Factor

Once the on-board decoder is in the SEARCH state, it begins looking for the required CLTU
Start Sequence. The Start Sequence provides two functions: 1) to resolve the ambiguity
between a "one" and a "zero" if needed (e.g., when NRZ-L symbol representation is used),
and 2) to delimit the beginning of the CLTU.

The Start Sequence is a fixed-pattern marker 16 bits long. It follows immediately after the
acquisition sequence and before the first codeblock of the CLTU. As a consequence of
recognizing the CLTU Start, the start of the first codeblock is then also delimited, since it
immediately follows the start sequence. In decoding serially transmitted block codes, it is
usually necessary to know the point at which the block starts and its length. The codeblock
length which has been chosen for the mission must be known a priori, and must remain
constant.

Two operating strategies for recognizing the start sequence are presented in Reference [4]: In
the first strategy (denoted by subscript A), the decoder requires that the entire 16 bits be
received without error. In the second (denoted by subscript B), the decoder allows one of the
16 bits to be in error and will still declare the start of a CLTU.

For the first strategy (that is, all 16 bits must be correct to declare a CLTU start) the probability
of rejecting (missing) a CLTU start is found by simply taking the probability that one or more
bit errors may fall on any of the 16 bits of the start sequence:

1 For example, the probability of the TDRSS transponder achieving bit lock in response to
this acquisition sequence is equal or greater than 0.9999.
Issue 6 Page D-6 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

<Prob. of rejecting a START, no errors allowed> = PsA

= 1 - (1 - p)16 [EQ. A]

where p is the channel bit error rate.

For the second strategy (in which one bit error is allowed) it is necessary for TWO or more bit
errors to appear in the start sequence before it will be rejected. In this case,
<Prob. of rejecting a START, 1 error allowed> = PsB

= 1 - [(1 - p)16 + 16p(1-p)15] [EQ. B]

These values are tabulated in Table D-1.

Table D-1: Probability of Rejection of CLTU Start Sequence

(for case where no errors are allowed (PsA ) and
one error allowed (PsB ))
________________________________________________________________

Channel Bit Error Rate

Case 10-4 10-5 10-6

________________________________________________________________

PsA 1.60 x 10-3 1.60 x 10-4 160 x 10-5

PsB 1.20 x 10-6 1.20 x 10-8 1.20 x 10-10

________________________________________________________________

PsA or PsB, above (depending on the strategy selected), constitutes the first factor of the overall
frame rejection rate.

It should be noted that there is also the remote possibility that the proper start sequence may be
missed because of a false (premature) start. The start pattern was chosen for its property that it
would require at least 6 changed bits to declare such a premature start.

D-3.3 Codeblock Factor

Once CLTU Start has been recognized, the decoding process begins for the codeblocks that
follow.

Issue 6 Page D-7 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

The code specified in Reference [4] is a (63,56) BCH code. The codeword2 contains an
information field of one of the lengths shown in Table D-2, followed by 7 parity bits. To
complete the codeblock (which, to meet general formatting rules for ease of handling, must be
an integral number of octets), a single final fill bit set to "zero" is always appended to the
codeword. Normally, one TC codeblock length is selected for a mission, and all codeblocks
are this length.

When decoding in the "Triple Error Detection" (TED) mode, the code has the property that it
can detect one-, two- or three-bit errors. Alternatively, when decoding in the "Single-Bit Error
Correction" (SEC) mode, it can correct one bit in error, and detect two bits in error within the
codeblock.

Decoding is performed by the Channel Service on a continuum basis. That is, as long as each
codeblock is valid (after correction, if error correction is employed) the information content of
each codeblock as it is accepted continues to be passed from the Coding layer to the Transfer
layer where each frame is assembled. If a codeblock failure occurs, the continuum is broken;
the decoder notifies the Transfer layer and ceases transferring any further data to it.

While 64 bits is the preferred codeblock length (because it allows minimum coding overhead to
achieve the given performance), it is possible to shorten the codeblock while still using the
same coding algorithm. Permitted lengths for shortened codeblocks are 56, 48, and 40 bits,
and are made possible by simply setting both encoder and decoder to assume the leading
untransmitted octets of each codeblock are always "zero". This is called "virtual fill".

The permitted organizations of the codeblock, including the relationship between codeblock
length, virtual fill, information bits, parity bits, and fill bits, are shown below:
Table D-2: Codeblock Organization

___________________________________________________________________________
Codeblock Virtual Codeword Information Parity Fill
length, fill, length, bits (k) bits bit
bits bits bits (n)
___________________________________________________________________________

64 0 63 56 7 1

56 8 55 48 7 1

48 16 47 40 7 1

40 24 39 32 7 1
___________________________________________________________________________

2 "Codeword" refers to the code itself; for an (n,k) code, the codeword is always n bits long.
"Codeblock" as used here refers to the physical implementation in the bit stream and
includes the final fill bit. Codeblocks may be 40, 48, 56 or 64 bits in length.
Issue 6 Page D-8 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

The equation characterizing codeblock rejection using TED mode is:

<Prob. of 1 or more codeblocks

of the CLTU being detected as
in error (using TED mode)> = PCA
= 1 - [1 - p)n]N [EQ. C]

where
p = channel bit error rate
n = number of bits in codeword (1 less than codeblock)
N = number of codeblocks

For the SEC case, the equation for rejection of 1 or more codeblocks becomes:

<Prob. of 1 or more codeblock of

the CLTU being in error AND
UNCORRECTABLE (SEC mode)> = PCB
= 1 - [(1-p)n + np(1-p)n-1]N [EQ. D]

Table D-3 provides values for both PCA and PCB for different numbers of 64-bit codeblocks
for the three different channel error rates, and these values are plotted in Figure D-2.

The codeblock factor is the second factor affecting frame rejection performance. Performance
is discussed next.

Issue 6 Page D-9 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Table D-3: Probability of Codeblock Rejection

(for 64-bit codeblocks, n=63) as a Function of Number
of Codeblocks, N

N BER = 10-4 BER = 10-5 BER = 10-6

P CA (TED mode)

1 6.28 x 10-3 6.30 x 10-4 6.30 x 10-5

2 1.25 x 10-2 1.26 x 10-3 1.26 x 10-4
4 2.49 x 10-2 2.52 x 10-3 2.52 x 10-4
6 3.71 x 10-2 3.77 x 10-3 3.78 x 10-4
9 5.51 x 10-2 5.65 x 10-3 5.67 x 10-4
12 7.28 x 10-2 7.53 x 10-3 7.56 x 10-4
16 9.59 x 10-2 1.00 x 10-2 1.01 x 10-3
20 1.18 x 10-1 1.25 x 10-2 1.26 x 10-3
24 1.40 x 10-1 1.50 x 10-2 1.51 x 10-3
28 1.62 x 10-1 1.74 x 10-2 1.76 x 10-3
32 1.83 x 10-1 2.00 x 10-2 2.01 x 10-3
36 2.03 x 10-1 2.24 x 10-2 2.27 x 10-3
37 2.08 x 10-1 2.30 x 10-2 2.33 x 10-3
74 3.73 x 10-1 4.56 x 10-2 4.65 x 10-3
110 5.00 x 10-1 6.70 x 10-2 6.91 x 10-3
149 6.09 x 10-1 8.96 x 10-2 9.34 x 10-3

P CB (SEC mode)

1 1.95 x 10-5 1.95 x 10-7 1.95 x 10-9

2 3.90 x 10-5 3.90 x 10-7 3.91 x 10-9
4 7.78 x 10-5 7.81 x 10-7 7.81 x 10-9
6 1.17 x 10-4 1.17 x 10-6 1.17 x 10-8
9 1.75 x 10-4 1.76 x 10-6 1.76 x 10-8
12 2.33 x 10-4 2.34 x 10-6 2.34 x 10-8
16 3.11 x 10-4 3.12 x 10-6 3.12 x 10-8
20 3.89 x 10-4 3.90 x 10-6 3.91 x 10-8
24 4.67 x 10-4 4.69 x 10-6 4.69 x 10-8
28 5.44 x 10-4 5.47 x 10-6 5.47 x 10-8
32 6.22 x 10-4 6.25 x 10-6 6.25 x 10-8
36 7.00 x 10-4 7.03 x 10-6 7.03 x 10-8
37 7.19 x 10-4 7.22 x 10-6 7.23 x 10-8
74 1.44 x 10-3 1.44 x 10-5 1.45 x 10-7
110 2.14 x 10-3 2.15 x 10-5 2.15 x 10-7
149 2.89 x 10-3 2.91 x 10-5 2.91 x 10-7

Issue 6 Page D-10 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

10-0
P CA
, , USING
TED BER = 10-4
10-1

PROBABILITY OF REJECTION OF ONE OR MORE CODEBLOCKS

BER = 10-5
10-2

BER = 10-6
10-3 BER = 10-4

10-4

10-5
BER = 10-5

10-6 P CB , USING
SEC

10-7 BER = 10-6

10-8

10-9
0 10 20 30 40 50 60
NUMBER OF CODEWORDS PER FRAME, N
(BASED ON 64-BIT CODEBLOCKS)

Figure D-2: Probability of Rejection of One or

More Contiguous 64-Bit Codeblocks
as a Function of Number of
Codeblocks, N

Issue 6 Page D-11 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

D-4 FRAME REJECTION RATE: TYPICAL TC ORGANIZATIONS

The Telecommand Transfer Frame is the accounting entity for telecommand performance. A
frame may be any integral number of octets in length, from a minimum consisting of only a
primary header (5 octets or 40 bits) to the maximum number of octets that can be counted by
the "Frame Length" field in the header (256 octets or 2048 bits).

The TC Frame is serially inserted into the "information" fields of as many Codeblocks as
necessary. If the length of a frame is not exactly the same as the total data space of the
Information fields in the required codeblocks, fill is added to the Information field of only the
LAST codeblock. If more than one frame resides in a CLTU, frames are organized
contiguously and any necessary fill is added only in the LAST codeblock of the CLTU.

The necessary TC building blocks are the TC Frame, CLTU, and the codeblocks. These may
be organized in several different ways depending on the performance required, operational
convenience, accounting convenience, etc. Three organizations are described below: One
frame per CLTU; multiple frames per CLTU; and multiple CLTUs. Frame performance may
be assessed by considering the performance of a sequence of codeblocks and the effect of their
organization into CLTUs.

D-4.1 One Frame, One CLTU

This section deals with the organization where each frame is contained in its own CLTU, as
shown in Figure D-3. A codeblock rejection anywhere in the frame will cause rejection of that
frame.

CLTU

START TAIL
ACQ INFO P INFO P INFO P

FRAME
(CONTAINED IN INFO FIELDS)

Figure D-3: Single Frame, Single CLTU Organization

The probability of frame rejection is determined from a) the probability of missing a CLTU
start, OR b) the probability of finding a CLTU start AND the probability of rejecting one or
more codeblocks.

Issue 6 Page D-12 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

For Strategy 1 (using TED mode, denoted by subscript A),

<Prob. of frame rejection in a

standalone CLTU, TED mode> = PFA
= PSA + (1 - PSA) PCA [EQ. E]

and for Strategy 2 (using SEC mode, denoted by subscript B),

PFB = PSB + (1 - PSB) PCB [EQ. F]

Examples. To illustrate the range of performance obtained with this organization (one frame
per CLTU), let us consider the shortest and longest permitted frame lengths. The shortest
frame permitted is just a header: 5 octets or 40 bits. This frame could be organized into a single
48-, 56- or 64-bit codeblock, or two 40-bit codeblocks. The probability of rejection for such a
frame is shown in Table D-4.

Table D-4: Probability of Rejection of a MINIMUM Length Frame

as a Function of Codeblock Length Chosen

__________________________________________________________________________

MINIMUM LENGTH FRAME

Code- Infor- No. of De- Probability of frame rejection

block mation code- coding for channel BER of
length, field, blocks mode
bits bits needed 10-4 10-5 10-6
___________________________________________________________________________

64 56 1 TED 7.87x10-3 7.90x10-4 7.90x10-5

SEC 2.06x10-5 2.07x10-7 2.07x10-9

56 48 1 TED 7.08x10-3 7.10x10-4 7.10x10-5

SEC 1.60x10-5 1.60x10-7 1.60x10-9

48 40 1 TED 6.28x10-3 6.30x10-4 6.30x10-5

SEC 1.20x10-5 1.20x10-7 1.20x10-9

40 32 2 TED 9.36x10-3 9.40x10-4 9.40x10-5

SEC 1.60x10-5 1.60x10-7 1.60x10-9
___________________________________________________________________________

At the other extreme, the maximum frame length permitted is 256 octets or 2048 bits. Such a
frame could be organized into either 40-, 48-, 56- or 64-bit codeblocks as shown in Table D-5.
Tables D-4 and D-5 show how frame rejection performance varies with different parameters. It
can be seen that the rejection performance is affected little by length of codeblocks, moderately
by number of codeblocks, and greatly by the decoding mode.

Issue 6 Page D-13 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Table D-5: Probability of Rejection of a MAXIMUM Length Frame

as a Function of Codeblock Length Chosen

___________________________________________________________________________
MAXIMUM LENGTH FRAME
Code- Infor- No. of De- Probability of frame rejection
block mation code- coding for channel BER of
length, field, blocks mode
bits bits needed 10-4 10-5 10-6
___________________________________________________________________________

64 56 37 TED 2.09x10-1 2.32x10-2 2.34x10-3

SEC 7.21x10-4 7.24x10-6 7.24x10-8

56 48 43 TED 2.12x10-1 2.35x10-2 2.36x10-3

SEC 6.37x10-4 6.40x10-6 6.40x10-8

48 40 52 TED 2.18x10-1 2.43x10-2 2.46x10-3

SEC 5.61x10-4 5.63x10-6 5.63x10-8

40 32 64 TED 2.22x10-1 2.48x10-2 2.51x10-3

SEC 4.74x10-4 4.75x10-6 4.75x10-8
___________________________________________________________________________

D-4.2 Multiple Frames, One CLTU

Since the CCSDS Recommendation (Reference [4]) does not limit the size of a CLTU, it is
possible to have more than one frame in a single CLTU. An example of such an organization
is shown in Figure D-4.

CLTU

START FRAME 1 FRAME 2 FRAME 3 TAIL

ACQ
N1 CODEBLOCKS N2 CODEBLOCKS N3 CODEBLOCKS

Figure D-4: Multiple Frame, Single CLTU Organization

The performance of multiple frames contained in a single CLTU is complicated by the fact that
acceptance of each frame in the CLTU requires acceptance of the frame before it. If at any time
a particular frame is rejected, frames preceding it will have been accepted, and the rejected
frame and all those following are rejected. Thus it would appear prudent to base performance
comparisons on the probability of rejection of the LAST frame in the CLTU, since the last
frame is dependent on the performance of each of the preceding frames.

Issue 6 Page D-14 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

A simplification can be made if one realizes that the rejection of the LAST frame is simply
dependent on the performance of the codeblock continuum through the last frame. Thus the
same equations (Eqs. E and F) can be used as for a single frame if we consider the contiguous
string of frames to be equivalent to one very long frame: the meaning of N then becomes the
total number of codeblocks contained in the last frame plus all the preceding frames of the
CLTU in question.

As an example, Table D-6 shows the probability of rejection of the LAST frame for a single
CLTU containing 1, 2, 3, and 4 maximum length frames. Figures are derived only for the 64-
bit codeblock (n=63).

Table D-6: Probability of Last Frame Rejection in a Multiple Frame CLTU

Using Maximum Length Frames and 64-Bit Codeblocks

___________________________________________________________________________

No. of Total Total De- Probability of rejection of last

maximum- number No. of coding frame, with channel BER of
length of code- mode
frames bits blocks 10-4 10-5 10-6
________________________(N)________________________________________________

1 2048 37 TED 2.09x10-1 2.32x10-2 2.34x10-3

SEC 7.21x10-4 7.24x10-6 7.24x10-8

2 4096 74 TED 3.74x10-1 4.57x10-2 4.67x10-3

SEC 1.44x10-3 1.45x10-5 1.45x10-7

3 6144 110 TED 5.04x10-1 6.77x10-2 6.98x10-3

SEC 2.16x10-3 2.17x10-5 2.17x10-7

4 8192 147 TED 6.07x10-1 8.92x10-2 9.30x10-3

SEC 2.88x10-3 2.89x10-5 2.89x10-7
___________________________________________________________________________

D-4.3 Multiple CLTUs

While in theory any number of frames may be sent in one CLTU, very long CLTUs tend to be
counter-productive: that is, the probability of frame rejection increases as the CLTU is made
excessivey long. In such cases it may be preferable to divide a large command load into a
number of CLTUs sent sequentially. These CLTUs may either be: 1) sent as independent
entities (modulation is dropped between CLTUs and the entire resynchronization process
begins anew as in the single CLTU case), or 2) strung together in sequence while maintaining
bit sync on the channel.

Issue 6 Page D-15 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

If CLTUs are separated by dropping modulation, each CLTU will perform as an independent
entity and may be analyzed as shown in Sections D-4.1 or D-4.2. However, if the CLTUs are
strung together tail-to-start with an uninterrupted bit stream as shown in Figure D-5, some
further considerations are necessary.

CLTU 1 CLTU 2

START TAIL START TAIL

ACQ INFO P INFO P INFO P INFO P INFO P

FRAME 1 FRAME 2

Figure D-5: Multiple Frame CLTU Organization (Contiguous CLTUs)

With this organization, the CLTU Tail Sequence becomes important, since the Tail Sequence
must be relied upon to declare a CODEBLOCK REJECTION and force the decoder into
SEARCH STATE at the end of each CLTU. ONLY IF THE DECODER IS IN SEARCH
STATE WILL IT BE ABLE TO RECOGNIZE THE START SEQUENCE OF THE NEXT
CLTU.

The decoder enters SEARCH state when a CODEBLOCK REJECTION is encountered (in this
case caused by the tail sequence.) However, it is possible for the decoder to "miss" a tail
sequence (i.e., the intended function, CODEBLOCK REJECTION, does not occur). Such a
condition could happen if bit errors on the channel suitably change the tail sequence to make it
an apparently valid codeblock, or (in SEC mode) make it appear (wrongly) to be correctable.
This requires the received tail sequence to have at least 2 introduced bit changes in the TED
mode, or 1 introduced bit change in the SEC mode.

Upon missing a tail sequence, the decoder remains in DECODE state after the first CLTU's tail
and cannot recognize the next CLTU's START sequence which follows immediately.
Although the Start Sequence of the next CLTU is NOT part of a codeblock and so has a high
probability of causing CODEBLOCK REJECTION, this attribute is of no help at this point,
since the start sequence has already passed. As a result, the entire CLTU which follows is
missed.

The probability of missing a tail sequence when using the TED decoding mode is the
probability that 2 or more changes are introduced into the tail sequence during transmission:

PTA = 1 - [(1 - p)n + np(1 - p)n-1] [EQ. G]

where n = length of tail sequence in bits.

Issue 6 Page D-16 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

The probability of missing a tail sequence when using the SEC decoding mode is the
probability that one or more changes are introduced into the tail sequence during transmission:

PTB = 1 - (1 - p)n [EQ. H]

It should be noted that Equations G and H are conservative approximations, since changes in
certain locations may not result in a missed tail. Values are tabulated in Table D-7.

Table D-7: Probability of Missing Tail Sequence, PTA (TED) and PTB (SEC)
___________________________________________________________________________
Probability of missing a tail,
Tail Sequence Decoding for a Channel BER of
length, bits mode 10-4 10-5 10-6
___________________________________________________________________________
64 TED (PTA) 1.95x10-5 1.95x10-7 1.95x10-9
SEC (PTB) 6.28x10-3 6.30x10-4 6.30x10-5

56 TED (PTA) 1.48x10-5 1.48x10-7 1.48x10-9

SEC (PTB) 5.49x10-3 5.50x10-4 5.50x10-5

48 TED (PTA) 1.08x10-5 1.08x10-7 1.08x10-9

SEC (PTB) 4.69x10-3 4.70x10-4 4.70x10-5

40 TED (PTA) 7.39x10-6 7.41x10-8 7.41x10-10

SEC (PTB) 3.89x10-3 3.90x10-4 3.90x10-5
___________________________________________________________________________

The probability of rejection of the last frame in a CLTU which follows another CLTU (without
reacquisition) may be evaluated as the probability of missing the tail of the preceding CLTU
(PTA or PTB) OR the probability of rejecting the last frame of the subject CLTU.

That is,

<Prob. of frame rejection in

subsequent CLTU, TED decoding> = PF2A

= PTA + (1-PTA)PFA

= PTA + (1-PTA)[(PSA + (1-PSA)PCA] [EQ. I]

where PFA refers to the frame performance as previously calculated in Equation E (independent
of a previous CLTU); and

Issue 6 Page D-17 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

<Prob. of frame rejection in

subsequent CLTU, SEC decoding> = PF2B
= PTB + (1-PTB)PFB
= PTB + (1-PTB)[(PSB + (1-PSB)PCB] [EQ. J]

where PFB refers to the frame performance as previously calculated in Equation F (independent
of a previous CLTU).

Given equal length CLTUs, one can see that each subsequent CLTU will have a higher
probability of rejection than the previous CLTU.

Example. Two maximum length frames could be packaged into two separate but contiguous
CLTUs in an organization as shown in Figure D-5. The probability of rejection of the first
(PF1) and second (PF2) frames in this organization may be compared (assuming 64-bit
codeblocks, and BER of 10-5) as shown in Table D-8.

Table D-8: Example of Performance of Frames in

First and Second Contiguous CLTUs
__________________________________________________________

Mode PF1 PF2

__________________________________________________________

TED 2.32x10-2 2.32x10-2

SEC 7.24x10-6 6.37x10-4

__________________________________________________________

D - 4 . 3 . 1 Performance Augmentation Using Double Tail Sequences. The

performance of subsequent CLTUs can be improved by doubling all tail sequences. That is,
the normal tail sequence of the CLTU is followed by an added second tail of the same length
(or, equivalently, with an idle sequence having the same bit alignment as the tail sequence,
which produces the same effect). It is less likely the combination of TWO tails will be missed,
thus improving the reliability of the decoder reaching SEARCH state. Such an organization is
shown in Figure D-6.

CLTU 1 CLTU 2

START TAIL 2nd TAIL START TAIL

ACQ INFO P INFO P OR IDLE INFO P INFO P

FRAME 1 FRAME 2

Figure D-6: Multiple CLTU Organization (With Added Tail/Idle)

Issue 6 Page D-18 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

With this organization, the probability of missing both tails is the probability of missing the
first one AND the probability of missing the second; that is,

<Prob. of missing a double tail

sequence, using TED decoding> = PTAD

= (PTA)2 [EQ. K]

and

<Prob. of missing a double tail

sequence, using SEC decoding> = PTBD

= (PTB)2 [EQ. L]

With double tails, the probabilities of missing a tail shown in Table D-7 take on the new values
shown in Table D-9.

Table D-9: Probability of Missing DOUBLE Tail Sequence,

P TAD (TED) and PTBD (SEC)
___________________________________________________________________________

Probability of missing a double tail,

for a Channel BER of
Tail Sequence Decoding
length, bits Mode 10-4 10-5 10-6
___________________________________________________________________________

64 TED (PTAD ) 3.78x10-10 3.81x10-14 3.81x10-18

SEC (PTBD ) 3.94x10-5 3.97x10-7 3.97x10-9

56 TED (PTAD ) 2.19x10-10 2.20x10-14 2.21x10-18

SEC (PTBD ) 3.01x10-5 3.02x10-7 3.02x10-9

48 TED (PTAD ) 1.16x10-10 1.17x10-14 1.17x10-18

SEC (PTBD ) 2.20x10-5 2.21x10-7 2.21x10-9

40 TED (PTAD ) 5.46x10-11 5.49x10-15 5.49x10-19

SEC (PTBD ) 1.52x10 -5 1.52x10 -7 1.52x10-9
___________________________________________________________________________

Issue 6 Page D-19 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

Example. If we take the example above of two maximum-length frames in separate but
contiguous CLTUs (Table D-8) and use double tail sequences between the CLTUs (assuming
64-bit codeblocks and channel BER of 10-5), the probability of rejection of the first and second
frames is shown in Table D-10.

Table D-10: Example of Performance of Frames in First and

Second Contiguous CLTUs Using DOUBLE Tail
Sequences Between CLTUs

____________________________________________________________

Mode PF1 PF2

____________________________________________________________

TED 2.32x10-2 2.32x10-2

SEC 7.24x10-6 7.63x10-6

____________________________________________________________

D - 4 . 3 . 2 Performance Augmentation Using Fill Bit. When using the SEC decoding
mode (single bit error correction/double bit error detection), a single bit error in reception of a
normal codeword will be corrected, making the codeblock acceptable. The following
discussion only applies when using the SEC decoding mode where such corrections are
possible. The tail sequence is not a codeword but is instead a specially constructed sequence
designed to appear to the decoder as an "uncorrectable pattern". This means that when the tail
sequence is received without change, the decoder will declare that the received sequence is an
uncorrectable pattern, which forces it to leave the DECODE state and enter the SEARCH state.

However, if a single bit of this tail sequence becomes altered in the channel, the received
sequence may no longer be recognized as "uncorrectable", and an improper correction may take
place. Because the expected CODEBLOCK REJECTION did not occur, we say the tail
sequence was "missed" (not recognized). The probability of this happening is given by
Equation H.

Missing a tail sequence has far-reaching effects, since it is possible that the decoder will not be
in SEARCH state for the next CLTU and therefore the entire subsequent CLTU may be
missed.

This problem may be significantly reduced and the reliability of identifying a tail sequence
improved by using the fill bit to selectively inhibit the SEC mode. As described in Reference
[4], each valid codeblock terminates on a fill bit which is always set to "0". A tail sequence
(which consists of an alternating pattern of ones and zeros starting with a zero) will always
contain a "1" in the position normally occupied by the fill bit in a regular codeblock. This
information can be exploited at the receiving end to inhibit the SEC mode whenever the fill bit
is a "one". This process substantially improves the ability to identify a tail sequence with a
negligible effect on the codeword acceptance process.
Issue 6 Page D-20 January 1987
CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

The recommended algorithm at the receiving end is as follows:

(1) Test the received pattern alone (ignoring the fill bit) for errors.

(2) If NO errors are detected in the received pattern, ACCEPT the codeword and
IGNORE the fill bit.

(3) If ONE error is detected in the received pattern, TEST the fill bit.
(a) If the fill bit = 0, correct the error in the pattern and ACCEPT it.

(b) If the fill bit = 1, declare a CODEBLOCK REJECTION.

(4) If TWO errors are detected in the received pattern, declare a CODEBLOCK
REJECTION. IGNORE the fill bit.

By selectively testing the fill bit, the probability of missing a tail sequence can be found from
the probability of a single bit being changed in any portion of the tail sequence except the fill
bit, AND that the received fill bit has also been changed. That is, TWO changes have to occur
in the same codeblock, one of which must be the fill bit position.

<Prob. of missing a tail

sequence using fill bit test> = PTBF
= [1 - (1 - p)n]p [EQ. M]

Comparing this with Equation H, one can see that the probability of missing a tail sequence has
now been reduced by several orders of magnitude (i.e., by the bit error rate, p.) Values are
given in Table D-11.

Table D-11. Probability of Missing a Tail Sequence, P TBF , Using the Fill Bit
Algorithm (SEC Decoding Mode Only)

___________________________________________________________________________
Probability of missing tail sequence
Codeblock n, for channel BER of
length, bits bits 10-4 10-5 10-6
___________________________________________________________________________

64 63 6.26x10-7 6.30x10-9 6.30x10-11

56 55 5.47x10-7 5.50x10-9 5.50x10-11

48 47 4.68x10-7 4.70x10-9 4.70x10-11

40 39 3.89x10-7 3.90x10-9 3.90x10-11

___________________________________________________________________________

Issue 6 Page D-21 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

It should be noted that while this technique substantially reduces the likelihood of missing a tail
sequence, there is a penalty in the form of a slight increase in frame rejection rate. That is, a
codeblock containing one error which would normally be corrected and accepted may (but
rarely) also have an error in its fill bit. If this algorithm were not used, the erroneous fill bit
would not be tested and the codeblock would be accepted. Under this algorithm, such a
codeblock would be rejected even though the information was correctable. The equation for
codeblock rejection (PCB, Equation D) must be modified to account for testing the fill bit (as
shown for PCBF, Equation N) but the effect on codeblock rejection is very slight:

<Prob. of codeblock rejection,

SEC mode and using fill bit test> = PCBF (fill bit test)
= 1 - [(1-p)n + (1-p)np(1-p)n-1]N [EQ. N]

Frame rejection performance for the frame in the second CLTU is then:

<Prob. of last frame rejection

in subsequent CLTU,
using SEC decoding
and the fill bit algorithm> = PF2BF
= PTBF + (1-PTBF)PFBF [EQ. O]

where

PTBF = prob. of missing tail when using fill bit test (Equation M)
PFBF = PSB + (1 - PSB)PCBF

and

PCBF = prob. of codeblock rejection when using fill bit test (Equation N)

Example. The probability of frame rejection for the example of two maximum-length frames
organized into separate CLTUs (as shown in Figure D-5) using SEC decoding mode, 64-bit
codeblocks, channel BER of 10-5 and the fill bit algorithm is shown in Table D-12.

Table D-12: Example of Performance of Frames in First and

Second Contiguous CLTUs Using Fill Bit Algorithm
_______________________________________________________
Mode PF1 PF2
_______________________________________________________
SEC 7.47x10-6 7.47x10-6
_______________________________________________________

Issue 6 Page D-22 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

D-5 UNDETECTED ERROR PERFORMANCE

The second performance requirement deals with undetected error, and requires that the
probability of accepting a frame with an undetected error is greater than 10-9. Again, the unit
of accountability is the frame.

Often the methods used to improve frame rejection rate (such as SEC) cause reduced
performance on undetected errors, and vice versa. Therefore an acceptable balance must be
found between these two objectives. Reference [8] shows that the required undetected error
performance will be met by the prescribed system using either TED or SEC decoding in a
channel operating at a BER of 10-5 without extra precautions. However, if a greater margin of
safety against undetected errors is desired, the cyclic redundancy code specified in Reference
[8] may be added to each frame. For an overhead of 16 bits per frame and the same channel
BER of 10-5, this will provide an undetected frame error rate of 10-19 when using SEC
decoding; with TED decoding, the performance is better. Figure D-7 shows curves comparing
undetected error performance (with and without the added CRC) as a function of number of
codeblocks in a frame for channel BER of 10-5. These curves are from Reference [8].

Issue 6 Page D-23 January 1987

CCSDS REPORT CONCERNING TELECOMMAND: SUMMARY OF CONCEPT AND SERVICE

10 -09
(SEC DECODING)

10 -10

PROBABILITY OF UNDETECTED FRAME ERROR 10 -11 BCH CODEBLOCKS

ALONE

10 -14

10 -15 (TED DECODING)

10 -16

10 -19

10 -20 BCH CODEBLOCKS

CONCATENATED
WITH FRAME CRC
10 -21 (SEC DECODING)

10 -22
0 10 20 30 40 50 60
NUMBER OF CODEBLOCKS PER FRAME

Figure D-7: Undetected Error Performance, With and

Without Cyclic Redundancy Code

END OF DOCUMENT. o

Issue 6 Page D-24 January 1987