![](media/image1.wmf){width="4.361111111111111in"
height="1.2083333333333333in"}

**RECOMMENDATION FOR SPACE**

**DATA SYSTEM STANDARDS**

+-----------------------------------------------------------------------+
| **TELECOMMAND**                                                       |
|                                                                       |
| PART 3                                                                |
|                                                                       |
| DATA MANAGEMENT SERVICE                                               |
|                                                                       |
| ARCHITECTURAL SPECIFICATION                                           |
+-----------------------------------------------------------------------+

**CCSDS 203.0-B-2**

**BLUE BOOK**

June 2001

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

AUTHORITY

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

       Issue:               Blue Book, Issue 2                         

       Date:                June 2001                                  

       Location:            Oxfordshire, UK                            

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

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

This Recommendation is published and maintained by:

CCSDS Secretariat

Program Integration Division (Code MT)

National Aeronautics and Space Administration

Washington, DC 20546, USA

STATEMENT OF INTENT

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

This RECOMMENDATION is issued by, and represents the consensus of, the
CCSDS Plenary body. Agency endorsement of this RECOMMENDATION is
entirely voluntary. Endorsement, however, indicates the following
understandings:

o Whenever an Agency establishes a CCSDS-related STANDARD, this STANDARD
will be in accord with the relevant RECOMMENDATION. Establishing such a
STANDARD does not preclude other provisions which an Agency may develop.

o Whenever an Agency establishes a CCSDS-related STANDARD, the Agency
will provide other CCSDS member Agencies with the following information:

\-- The STANDARD itself.

\-- The anticipated date of initial operational capability.

\-- The anticipated duration of operational service.

o Specific service arrangements shall be made via memoranda of
agreement. Neither this RECOMMENDATION nor any ensuing STANDARD is a
substitute for a memorandum of agreement.

No later than five years from its date of issuance, this Recommendation
will be reviewed by the CCSDS to determine whether it should: (1) remain
in effect without change; (2) be changed to reflect the impact of new
technologies, new requirements, or new directions; or (3) be retired or
cancelled.

FOREWORD

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

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

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

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

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

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

http://www.ccsds.org/

Questions relating to the contents or status of this Report should be
addressed to the CCSDS Secretariat at the address on page i.

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

[Member Agencies]{.underline}

-   Agenzia Spaziale Italiana (ASI)/Italy.

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

-   Canadian Space Agency (CSA)/Canada.

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

-   Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.

-   European Space Agency (ESA)/Europe.

-   Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.

-   National Aeronautics and Space Administration (NASA)/USA.

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

-   Russian Space Agency (RSA)/Russian Federation.

[Observer Agencies]{.underline}

-   Austrian Space Agency (ASA)/Austria.

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

-   Centro Tecnico Aeroespacial (CTA)/Brazil.

-   Chinese Academy of Space Technology (CAST)/China.

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

-   Communications Research Centre (CRC)/Canada.

-   Communications Research Laboratory (CRL)/Japan.

-   Danish Space Research Institute (DSRI)/Denmark.

-   European Organization for the Exploitation of Meteorological
    Satellites (EUMETSAT)/Europe.

-   European Telecommunications Satellite Organization
    (EUTELSAT)/Europe.

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

-   Hellenic National Space Committee (HNSC)/Greece.

-   Indian Space Research Organization (ISRO)/India.

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

-   Institute of Space Research (IKI)/Russian Federation.

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

-   MIKOMTEK: CSIR (CSIR)/Republic of South Africa.

-   Korea Aerospace Research Institute (KARI)/Korea.

-   Ministry of Communications (MOC)/Israel.

-   National Oceanic & Atmospheric Administration (NOAA)/USA.

-   National Space Program Office (NSPO)/Taipei.

-   Swedish Space Corporation (SSC)/Sweden.

-   United States Geological Survey (USGS)/USA.

DOCUMENT CONTROL

+----------+----------------------+-----------+----------------------+
| **Do     | **Title and Issue**  | **Date**  | **Status**           |
| cument** |                      |           |                      |
+----------+----------------------+-----------+----------------------+
| CCSDS\   | Telecommand Part     | January   | Original Issue       |
| 2        | 3---\                | 1987      | (superseded).        |
| 03.0-B-1 | Data Management      |           |                      |
|          | Service, Issue 1     |           |                      |
+----------+----------------------+-----------+----------------------+
| CCSDS\   | Telecommand Part     | June 2001 | Current Issue:       |
| 2        | 3---\                |           |                      |
| 03.0-B-2 | Data Management      |           | adds specifications  |
|          | Service, Issue 2     |           | to support use of TC |
|          |                      |           | Transfer Frame to    |
|          |                      |           | transport various    |
|          |                      |           | types of packets,    |
|          |                      |           | including TC         |
|          |                      |           | Packets, CCSDS       |
|          |                      |           | Network Protocol     |
|          |                      |           | (NP) datagrams, and  |
|          |                      |           | Internet Protocol    |
|          |                      |           | (IP) datagrams.      |
+----------+----------------------+-----------+----------------------+

NOTE: Substantive changes from the previous issue are flagged with
change bars in the inside margin.

CONTENTS

Sections Page

1 INTRODUCTION 1-1

1.1 PURPOSE AND SCOPE 1-1

1.2 APPLICABILITY 1-1

1.3 BIT NUMBERING CONVENTION AND NOMENCLATURE 1-2

1.4 REFERENCES 1-3

2 TELECOMMAND DATA MANAGEMENT SERVICE OVERVIEW 2-1

3 APPLICATION PROCESS LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 3-1

3.1 OVERVIEW OF THE LAYER 3-1

3.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 3-3

3.3 STANDARD PROCEDURES WITHIN THE LAYER 3-3

4 SYSTEM MANAGEMENT LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 4-1

4.1 OVERVIEW OF THE LAYER 4-1

4.2 STANDARD DATA STRUCTURES WITHIN THE LAYER 4-2

4.3 STANDARD PROCEDURES WITHIN THE LAYER 4-2

5 PACKETIZATION LAYER: STANDARD DATA STRUCTURES AND PROCEDURES 5-1

5.1 OVERVIEW OF THE LAYER 5-1

5.2 CCSDS TELECOMMAND PACKET 5-1

5.3 OTHER TYPES OF PACKETS 5-6

5.4 STANDARD PROCEDURES WITHIN THE LAYER 5-9

ANNEX A DATA MANAGEMENT SERVICE ACRONYMS AND TERMINOLOGY A-1

ANNEX B DATA MANAGEMENT SERVICE SPECIFICATION B-1

ANNEX C INFORMATIVE REFERENCES C-1

CONTENTS

Figure Page

2-1 Telecommand System 2-2

3-1 Application Process Layer Functional Overview 3-2

5-1 Telecommand Packet Format 5-2

# INTRODUCTION

## PURPOSE AND SCOPE

The purpose of this document is to establish a common Recommendation
which defines the systems architecture of a spacecraft telecommand
\"Data Management Service\". The intent of this architecture is to
provide a common framework within which the Agencies participating in
the Consultative Committee for Space Data Systems (CCSDS) may implement
compatible future spacecraft telecommanding systems. The operating
principles and procedures for the CCSDS are defined in Reference \[C1\].
The context of the Data Management Service within the overall
Telecommand System is described in Reference \[C2\].

This Recommendation primarily addresses the data unit formats and
functions which are implemented within the the Application Process
layer, the System Management layer and the Packetization layer of the
CCSDS telecommand Data Management Service. Recognizing that much future
work remains to be done relative to these top layers, their
specification has been deliberately minimized by the CCSDS. **IN
PARTICULAR, THE DETAILED OPERATIONAL PROTOCOLS WHICH OPERATE ACROSS
THESE LAYERS, AND THE FLOW OF CONTROL INFORMATION REQUIRED TO INITIALIZE
THE LAYERS AND DIRECT THE TRANSFER OF DATA BETWEEN THEM, ARE NOT
PRESENTLY ADDRESSED WITHIN THIS DOCUMENT: THESE REMAIN ITEMS FOR
POTENTIAL EXTENSION OF THIS RECOMMEN- DATION.**

## APPLICABILITY

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

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

Where preferred options or mandatory capabilities are clearly indicated
herein, the indicated sections of the specification must be implemented
when this Recommendation is used as a basis for cross-support. Where
optional subsets or capabilities are allowed or implied in this
specification, implementation of these options or subsets is subject to
specific bilateral cross-support agreements between the Agencies
involved.

The recommendations in this document are to be invoked through the
normal standards programs of each member Agency, and are applicable to
those missions for which cross-support based on capabilities described
in these recommendations is anticipated.

No later than five years from its date of issue, this Recommendation
should be reviewed by the CCSDS Agencies to determine whether it
should: 1) remain in effect without change; 2) be changed to reflect the
impact of new technologies, new requirements, or new directions; or 3)
be retired or canceled.

## BIT NUMBERING CONVENTION AND NOMENCLATURE

In this document, the following convention is used to identify each bit
in an N-bit field. The first bit in the field to be transmitted (i.e.,
the most left justified when drawing a figure) is defined to be \"Bit
0\"; the following bit is defined to be \"Bit 1\" and so on up to \"Bit
N-1\". When the field is used to express a binary value (such as a
counter), the Most Significant Bit (MSB) shall be the first transmitted
bit of the field, i.e., \"Bit 0\".

![](media/image3.wmf)

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

![](media/image4.wmf)

By CCSDS convention, all \"spare\" bits shall be permanently set to
value \"zero\". Note that throughout this document, the word
\"Telecommand\" may be abbreviated as \"TC\".

## REFERENCES

\[1\] *Telecommand Part 2---Data Routing Service*. Recommendation for
Space Data System Standards, CCSDS 202.0-B-3. Blue Book. Issue 3.
Washington, D.C.: CCSDS, June 2001.

\[2\] *Telecommand Part 1---Channel Service*. Recommendation for Space
Data System Standards, CCSDS 201.0-B-3. Blue Book. Issue 3. Washington,
D.C.: CCSDS, June 2000.

\[3\] *Packet Telemetry*. Recommendation for Space Data System
Standards, CCSDS 102.0-B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS,
November 2000.

\[4\] *Telemetry Channel Coding*. Recommendation for Space Data System
Standards, CCSDS 101.0-B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS,
June 2001.

\[5\] *Space Communications Protocol Specification (SCPS)---Network
Protocol (SCPS-NP)*. Recommendation for Space Data System Standards,
CCSDS 713.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, May 1999.

\[6\] J. Postel. *Internet Protocol*. STD 5, September 1981. \[RFC 791,
RFC 950, RFC 919, RFC 922, RFC 792, RFC 1112\][^1]

\[7\] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995.

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

# TELECOMMAND DATA MANAGEMENT SERVICE OVERVIEW

A complete summary of the acronyms and terminology used internal to this
document is presented in Annex A, and a detailed specification of the
services provided by each layer is presented in Annex B. The first-time
reader should digest these Annexes before proceeding further in this
document.

Figure 2-1 illustrates the significance of the TC Data Management
Service within the overall Telecommand System, which contains three
principal elements of service: Telecommand Data Management Service;
Telecommand Data Routing Service; and Telecommand Channel Service. Each
of these services is documented in separate Recommendations. A more
thorough discussion of the layered services, including expansion of
Figure 2-1 in greater detail, is contained in Reference \[C2\]. The
Telecommand System is related to the Telemetry System as documented in
Reference \[3\] and Reference \[4\].

The TC Data Management Service enables user requests for command
activity to be generated, integrated, aggregated, translated and
scheduled for delivery to the spacecraft by drawing upon the Data
Routing and Channel Services. The Data Management Service contains three
distinct layers of data handling operations:

\(1\) An **APPLICATION PROCESS** layer, which allows human users to
control a space mission by generating commands and supervising their
delivery and execution.

\(2\) A **SYSTEM MANAGEMENT** layer, which translates user command
directives into detailed command application data and delivery
instructions, and which manages their end-to-end delivery to the proper
Application Process on the spacecraft.

\(3\) A **PACKETIZATION** layer, which formats the command application
data into transportable telecommand data units and moves them to the
spacecraft.

![](media/image5.wmf)

Figure 2-1: Telecommand System

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

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

NOTE C: Inter-Agency cross-support gateways for telecommand are
discussed in Reference \[C2\].

# APPLICATION PROCESS LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

## OVERVIEW OF THE LAYER

The service provided by the Application Process layer is to allow users
to control remote instruments or subsystems in space. The layer performs
this service by providing its own internal functions, and by drawing on
services provided by the lower layers of the TC System. A functional
overview of the Application Process layer is presented in Figure 3-1.

The sending end of the layer contains a large number of diverse
Application Processes, arranged to form a system which is used to
supervise a particular space mission. For the purpose of illustration, a
few representative clusters of application processes are shown in the
figure. The Application Processes are supervised by an \"Application
Executive\" which controls the overall flow of activities within the
layer. Within the system, clusters of specialized application processes
(e.g., flight path control, spacecraft and communication network monitor
and control) exist to support the users.

Users enter the Application Process layer via application processes in
their workstations. These application processes provide the man/machine
interface which permit them to communicate via the Application Executive
with the other application processes within the system.

One cluster of application processes provides the planning, scheduling
and \"mission sequencing\" function that integrates all user command
requests into a workable flight profile. The output of these application
processes is an integrated, aggregated, validated, constraint-checked
set of \"Command Directives\" which specify (in a high-level language)
the sets of user commands that are to be delivered to the spacecraft for
execution. Some of these Command Directives, which are addressed to the
onboard sequence control process, define the system conditions which
must exist before the remaining sets of commands are released for
execution. The mission sequencing process provides control and
coordination of the assignment of names which identify the sets of
commands throughout delivery and execution.

Command Directives, formatted in a logical notation known as an
\"abstract transfer syntax\", contain high-level expressions of the
desired command activity. They contain the commands themselves, plus
requirements for control of their delivery such as time windows,
interrelationship and interdependency information, user naming
conventions, contingency procedures, etc.

Management of the end-to-end delivery of commands is provided by another
cluster of specialized \"delivery control\" application processes, which
interface the Application Process layer with the supporting telecommand
layers that interconnect its sending and receiving ends.

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

Figure 3-1: Application Process Layer Functional Overview

The highest of the supporting telecommand layers is the System
Management layer. Downwards across the sending-end interface with the
System Management layer flow named sets of Command Directives containing
abstract-syntax commands and delivery instructions, while upwards flow
reports describing the status of their delivery. The System Management
layer provides the service of translating between the abstract transfer
syntax of the Application Process layer and the \"concrete transfer
syntax\" used by the lower layers of the data communication part of the
Telecommand System.

The receiving end of the Application Process layer mirrors the sending
end, i.e., an Application Executive which orchestrates clusters of
onboard application processes. Sets of commands are received from the
onboard System Management layer by a group of delivery control
processes, which report status back to the sending end. The sets of
commands are forwarded to a spacecraft sequence control function (e.g.,
a central onboard computer) or directly to the addressed spacecraft
instrument or subsystem. The receiving elements themselves are supported
by specialized application processes that convert command directives
into desired actions, and report their execution.

## STANDARD DATA STRUCTURES WITHIN THE LAYER

The CCSDS is developing standard data interchange structures for the
exchange of data between application processes.

Although it is assumed that CCSDS standard data interchange structures
will be used extensively within the layer, particularly at the sending
end of the TC System, the only formal requirement in this issue of the
Recommendation is that standard data interchange structures must be used
to carry information bidirectionally across the interface at the sending
end of the system between the Application Process layer and the System
Management layer. The concrete formats of the standard data interchange
structures which pass information \"downwards\" and \"upwards\" across
this interface are presently unspecified. The standard data interchange
structures shall contain the Telecommand data themselves, plus the
control instructions which must be passed to lower layers in order to
specify the services required during the delivery process. The use of
CCSDS standard data interchange structures is discussed in Reference
\[C2\].

## STANDARD PROCEDURES WITHIN THE LAYER

In the future, it is possible that a standardized core of mission
independent services and procedures may be provided within both ends of
this layer. Projects will then be able to augment this core with their
own unique application processes.

However, in this issue of the Recommendation the procedures internal to
this layer are left unspecified by the CCSDS. This reflects an
evolutionary philosophy whereby it is recognized that many of these
functions will continue to be developed on a mission-by-mission basis in
the near or medium term, or perhaps will be standardized within one
Agency or one Center. The approach of the CCSDS is therefore to first
agree on standardization of the lower layers of the Telecommand System
(i.e., the Packetization, Segmentation, Transfer, Coding and Physical
layers), and then to gradually migrate upwards into standardization of
the higher layers as experience is gained with actual operational use of
the automated system.

Potential items for future standardization include:

\(1\) Selection of a standard language and procedures to be used at the
interface between the human user and sending end of the layer.

\(2\) Selection of a standard abstract transfer syntax for Command
Directives.

# SYSTEM MANAGEMENT LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

## OVERVIEW OF THE LAYER

The service provided by the System Management layer is to translate
between the high-level commanding language used within the layer above
and the detailed communications and control language used by the layers
below, and to manage the overall operation of the lower layers so that
reliable and error-free delivery of commands may be assured. The System
Management layer therefore performs the interface transformations
between the output of the Application Process layer, and the lower layer
bit-level data communication systems which move these commands to the
spacecraft.

To provide this service, the System Management layer parses the Command
Directives and prepares them for transport. The user-named sets of
commands and their execution conditions are translated between the
abstract transfer syntax used within the Application Process layer and
the concrete telecommand transfer syntax which is used by lower layers
during communication. At the sending end, this involves formatting the
actual command application data into a presentation syntax which is
compatible with direct insertion into the data units of the layer below
(e.g., the data field of Telecommand Packets) for delivery to the
spacecraft. The System Management layer instructs lower layers whether
the user application data are to be handled as individual command
messages, sequences of messages, or as an integrated file.

The delivery instructions from the layer above are translated into TC
Session control instructions by the System Management layer by:

\(1\) Specifying the class of transport service required from lower
layers (single messages, or files of messages) and requesting any
related lower-layer services such as the attachment of telecommands to
particular data routing paths, the selection of retransmission protocols
to be used during transfer to the spacecraft, communications security
procedures, etc.

\(2\) Managing the traceability of sets of telecommands by translating
the user names into identifiers which can be inserted into the
transportable data units of the layer below.

\(3\) Calling the appropriate lower-layer services required during the
session, including selection of operational procedures and time windows.

\(4\) Specifying the recovery procedures to be used in the event of
service interruption during a session.

The System Management layer provides management of interrelated sets of
commands during delivery. Local names are assigned to the sets of
commands in order to trace and supervise their transport: the local
names are correlated with user names by the layer, so that user
visibility into the delivery process is provided.

## STANDARD DATA STRUCTURES WITHIN THE LAYER

Although it is assumed that standard data interchange structures will be
used extensively within the sending end of the layer, the only formal
requirement in this issue of the Recommendation is that these data
structures must be used to carry information bidirectionally across the
interface between the sending end of the System Management layer and
lower layers. The concrete formats of the standard data interchange
structures which pass information \"downwards\" and \"upwards\" across
this interface are presently unspecified.

## STANDARD PROCEDURES WITHIN THE LAYER

In this issue of the Recommendation, operational procedures within the
System Management layer are unspecified by the CCSDS.

# PACKETIZATION LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

## OVERVIEW OF THE LAYER

The service provided by the Packetization layer is to provide end-to-end
transport of user application data between the sending and receiving
ends of the TC System. At the sending end, user application data are
given to the Packetization layer in concrete transfer syntax by the
layer above (i.e., the System Management layer): these data are
encapsulated within standard data interchange structures containing
transport control instructions. The Packetization layer draws upon the
lower-layer capabilities of the Telecommand Data Routing Service
(Segmentation and Transfer layers) and the TC Channel Service (Coding
and Physical layers) in order to establish a transport path in response
to a call for connection by the System Management layer.

A packet is a standard data structure which encapsulates the user
application data that are to be transported from the output of the
sending end to the input of the receiving end of the System Management
layer. Packets may exist as standalone entities, or may be batched
together into interdependent \"TC Files\". At the sending end TC Packets
or Files are passed to the layer below (e.g., the Data Routing Service)
for transfer to the spacecraft by encapsulating them within CCSDS
standard data interchange structures which also contain their routing
control instructions.

The abstract content and concrete format of the CCSDS standard data
interchange structures which are used at the sending end of the TC
System to pass data between the Packetization layer and lower layers is
presently unspecified.

## CCSDS TELECOMMAND PACKET

The TC Packet is one of the standard transport data structure of the TC
System. The CCSDS TC Packet data structure is shown in Figure 5-1. It
consists of the following major fields:

**Major Field Length (Octets)**

Primary Header 6

Secondary Header Variable (optional)

Application Data Variable, up to 65,536

It should be noted that the format of the TC Packet is virtually
identical to that of the Telemetry Packet (Reference \[3\]). The maximum
end-to-end length of the current version of the TC Packet is constrained
by the implementation to be no more than 65,542 octets.

![](media/image7.wmf)Figure 5-1: Telecommand Packet Format

### PRIMARY HEADER

The Primary Header consists of 6 octets subdivided into the following
fields:

**Field Length (Bits)**

PACKET IDENTIFICATION 16

\- Version Number (3)

\- Type (1)

\- Secondary Header Flag (1)

\- Application Process ID (11)

PACKET SEQUENCE CONTROL 16

\- Sequence Flags (2)

\- Packet Name

or Sequence Count (14)

PACKET LENGTH 16

\-\-\--

Total = 48 bits (6 octets)

#### **Packet Identification (2 octets)**. This 16-bit field is divided into four subfields: {#packet-identification-2-octets.-this-16-bit-field-is-divided-into-four-subfields .Paragraph-4}

\(1\) Version Number (Bits 0 through 2)

The Version Number occupies the three most significant bits of the TC
Packet Primary Header. The Version-1 TC Packet is specified by setting
the Bits 0 through 2 to value \"000\", and is the version described
herein.

\(2\) Type (Bit 3)

This single bit is used to identify that this is a Telecommand Packet
rather than a Telemetry Packet. A Telemetry Packet has this bit set to
value \"0\": therefore, for all Telecommand Packets Bit 3 shall be set
to value \"1\".

\(3\) Secondary Header Flag (Bit 4)

This one bit flag signals the presence (Bit 4 = \"1\") or absence (Bit 4
= \"0\") of a Secondary Header data structure within the TC Packet.

\(4\) Application Process Identifier (Bits 5 through 15)

This 11-bit field uniquely identifies the individual \"receiving\"
application process within a particular space vehicle to which the
application data encapsulated within the TC Packet are to be sent.
Application Process ID\'s are tailored to local mission needs and are
assigned by the Mission Manager. Users should note that accounting
implementation considerations may limit the number of different
application processes which may be simultaneously open during a given
session. For many spacecraft, the \"sending\" address is a direct
one-to-one mapping of the receiving address: however, if a separate
sending address is also required, this information may be formatted into
a Secondary Header.

NOTE: The space vehicle itself is physically addressed by lower layers
within the TC system, e.g., using the SPACECRAFT IDENTIFIER field in the
Telecommand Transfer Frame Header. At the sending end of the system, the
System Management layer defines to which spacecraft the packets are to
be sent, and passes these instructions to lower layers via control
instructions contained in the CCSDS standard data interchange structures
within which the user application data are encapsulated.

#### **Packet Sequence Control (2 octets).** This 16-bit field is divided into two subfields: {#packet-sequence-control-2-octets.-this-16-bit-field-is-divided-into-two-subfields .Paragraph-4}

\(1\) Sequence Flags (Bits 0,1)

The Sequence Flags, which occupy the two most-significant bits of the
16-bit Packet Sequence Control Field, provide a method for defining
whether this packet is a first, last or intermediate component of a
higher layer data structure, such as a set of packets which are
addressed to one particular Application Process. For instance, this
packet may contain data to load one location of a memory, and may be
followed by several more related packets which together load a complete
subroutine. The Sequence Flags therefore may be used to delimit this
higher-layer data structure.

The assignment of the Sequence Flags is as follows:

\(a\) Last Sequential Component (Bit 0)

When Bit 0 is set to value \"1\", it indicates that this packet is the
last component of a higher-layer data structure which is addressed to
one particular spacecraft Application Process.

\(b\) First Sequential Component (Bit 1)

When Bit 1 is set to value \"1\", it indicates that this packet is the
first component of a higher layer data structure which is addressed to
one particular spacecraft Application Process.

Based on the above assignments, the Sequence Flags may be interpreted as
follows:

**Bit 0 Bit 1 Interpretation**

0 0 Continuation component of higher data structure

0 1 First component of higher data structure

1 0 Last component of higher data structure

1 1 Standalone Packet

\(2\) Packet Name or Sequence Count (Bits 2 through 15)

This 14-bit subfield allows a particular TC Packet to be identified
(i.e., given a unique name) with respect to others occurring within a
Telecommand Session. The naming capability permits the packet to be
traced and supervised prior to its release for execution. If the control
activity directed by the packet is independent of other spacecraft
activities, naming may consist of simply placing a straight sequence
number within this field. If the packet is a member of a larger
interrelated group of packets (i.e., a TC File), the field may be
internally partitioned (see Section 5.3) to include the File Name.

#### **Packet Length (2 Octets).** This field contains a sequential 16-bit binary count \"C\" of the length (in octets) of the remainder of the data structure which is enclosed between the first bit of the Secondary Header and the last bit of the Packet (i.e., the last bit of the Application Data field). The field is expressed as follows: {#packet-length-2-octets.-this-field-contains-a-sequential-16-bit-binary-count-c-of-the-length-in-octets-of-the-remainder-of-the-data-structure-which-is-enclosed-between-the-first-bit-of-the-secondary-header-and-the-last-bit-of-the-packet-i.e.-the-last-bit-of-the-application-data-field.-the-field-is-expressed-as-follows .Paragraph-4}

C = { (Number of octets) - 1 }

The size of this field dictates that the maximum TC Packet length is
65,542 octets (65,536 octets of Secondary Header and Application Data,
plus 6 octets of Primary Header).

### SECONDARY HEADER

The Secondary Header field is optional. Its length shall always be an
integral number of octets. The purpose of the Secondary Header is to
provide a means for encoding, within a TC Packet, any ancillary data
(time, sending address, data field format, etc.) which may be necessary
for the interpretation of the application data contained within the
packet.

If a Secondary Header is present, this shall be indicated by setting the
Secondary Header Flag to value \"1\". At present, the CCSDS has not
developed recommendations for the internal format of the Secondary
Header: therefore, local conventions may be used as required. However,
in order to permit future standardization of this data structure the
most-significant bit (Bit 0) of the leading octet within the Secondary
Header shall be reserved and assigned as follows whenever the Secondary
Header Flag is set to value \"1\":

Bit 0 = \"0\" : non-CCSDS-defined Secondary Header follows

Bit 0 = \"1\" : CCSDS-defined Secondary Header follows

### APPLICATION DATA

The Application Data field contains the user telecommand information to
be transported to the System Management layer onboard the spacecraft.
Users are free to adopt whatever formatting conventions are convenient:
the only formal restriction imposed on the Application Data field is
that the total length must be an integral number of octets equal to or
less than the maximum field length.

At the discretion of the user, an error detection code may be included
in the Application Data Field in order to verify that the overall
integrity of the TC Packet has been preserved during the transport
process. The length and location of the field, and the choice of the
encoding polynomial, is left to the user.

## OTHER TYPES OF PACKETS

### General

Besides the Source Packets described in Chapter 3, three other types of
packets may be carried directly in the Packet Data Field of CCSDS
Frames.

NOTES

1.  These packets all have a version field as their first field, which
    allows them to be distinguished from one another, and some type of
    length field. Once the type of packet is known by checking the
    version field, the unique rules for determining its length and
    finding the start of the next packet can be determined. Since the
    next packet begins where the first ended, subsequent packets may be
    extracted from the frame by \"chaining\" (i.e., again checking the
    version number at the start of the next packet, finding its length
    field, and interpreting the meaning of that length to find the start
    of the next packet, and so on).

2.  The term "packet" is used generically in this document to refer to
    packet-type data structures that include CCSDS Network Protocol and
    Internet Protocol datagrams.

### CCSDS Network Protocol (NP) Datagram

NOTE -- The complete definition of the NP datagram is contained on
reference \[5\].

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

#### **Version ID.** The first three bits of the NP Datagram are the version number. Reference \[5\] defines these binary values as 001. {#version-id.-the-first-three-bits-of-the-np-datagram-are-the-version-number.-reference-5-defines-these-binary-values-as-001. .Paragraph-4}

#### **Length Field.** The length field is a 13-bit field starting at bit 3. {#length-field.-the-length-field-is-a-13-bit-field-starting-at-bit-3. .Paragraph-4}

#### **Interpretation of Length Field.** The length field is a binary number corresponding to the total length of the NP Datagram in octets. {#interpretation-of-length-field.-the-length-field-is-a-binary-number-corresponding-to-the-total-length-of-the-np-datagram-in-octets. .Paragraph-4}

NOTE -- Unlike the CCSDS Source Packet, the length field is a binary
number corresponding to the total length of the NP datagram, including
the header.

### Internet Protocol Datagram (IPv4)

NOTE -- The complete definition of the IPV4 datagram is contained on
reference \[6\].

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

#### **Version ID.** The first four bits of the IPv4 Datagram are the version number. Reference \[6\] defines these binary values as 0100. For this application, only the first three bits are checked; the fourth bit is ignored. {#version-id.-the-first-four-bits-of-the-ipv4-datagram-are-the-version-number.-reference-6-defines-these-binary-values-as-0100.-for-this-application-only-the-first-three-bits-are-checked-the-fourth-bit-is-ignored. .Paragraph-4}

#### **Length Field.** The length field is a 16-bit field starting at bit 16. {#length-field.-the-length-field-is-a-16-bit-field-starting-at-bit-16. .Paragraph-4}

#### **Interpretation of Length Field.** The length field is a binary number corresponding to the total length of the IPv4 Datagram in octets. {#interpretation-of-length-field.-the-length-field-is-a-binary-number-corresponding-to-the-total-length-of-the-ipv4-datagram-in-octets. .Paragraph-4}

NOTE -- Unlike the CCSDS Source Packet, the length field is a binary
number corresponding to the total length of the IPv4 datagram, including
the header.

### Encapsulation Packet

![](media/image10.emf){width="6.166666666666667in"
height="1.4722222222222223in"}

#### **Version ID.** The first three bits (0-2) of the Encapsulation Packet shall contain the version number. Their value shall be set to binary 111. {#version-id.-the-first-three-bits-0-2-of-the-encapsulation-packet-shall-contain-the-version-number.-their-value-shall-be-set-to-binary-111. .Paragraph-4}

#### Protocol ID: {#protocol-id .Paragraph-4}

a\) **Location of Protocol ID.** The next three bits (3-5) shall
identify the protocol whose data units are being encapsulated.

NOTE -- The Protocol ID may be used to route the data unit being
encapsulated from or to a Port or Service Access Point for acceptance or
delivery of the encapsulated contents.

b\) **Interpretation of Protocol ID Field.** The following protocol IDs
are allowed by CCSDS in this Encapsulation Packet; other assignments are
reserved by CCSDS for future use:

> -- Fill (no encapsulated data) Binary 000
>
> -- IPv6 datagram (reference \[7\]) Binary 100
>
> -- Arbitrary aggregation of octets Binary 111

#### Length of Length Field: {#length-of-length-field .Paragraph-4}

a)  **Location of Length of Length Field.** The last two bits (6-7) of
    the first octet shall specify the Length of the Encapsulation
    Packet\'s Length field to follow, in octets.

b)  **Interpretation of Length of the Length Field**:

> Value Length of Length Field
>
> Binary 00 Null \"Length of the Length Field\"
>
> Binary 01 1 octet
>
> Binary 10 2 octets
>
> Binary 11 4 octets

NOTE -- A null \"Length of the Length Field\" signifies that 1) the
length field does not exist, 2) therefore there is no encapsulated data,
and 3) the length of the Encapsulation Packet is one octet. This
one-octet Encapsulation Packet can thus also be used as a single,
self-identified octet of fill which may be cascaded to provide any
number of octets to fill a fixed-length frame.

#### Length Field: {#length-field .Paragraph-4}

a\) **Location of Length Field.** The Length Field is a binary field of
0, 1, 2 or 4 octets starting at bit 8.

NOTE -- Although unlikely to be used in space, a 4-octet length field
permits accommodating IPv6 \"Jumbograms\" up to 4,294,967,296 octets in
length.

b\) **Interpretation of Length Field.** The Length Field shall contain a
binary number corresponding to the total length of the Encapsulation
Packet (in octets), including the header.

*NOTE -- The values 00000000 (zero) and 00000001 (one) are not allowed.*

#### **Encapsulated Content.** The Encapsulation Packet header shall end at the end of the Length Field and is immediately followed by the data unit being encapsulated. {#encapsulated-content.-the-encapsulation-packet-header-shall-end-at-the-end-of-the-length-field-and-is-immediately-followed-by-the-data-unit-being-encapsulated. .Paragraph-4}

NOTE -- Since the Encapsulation Packet is only a tool used by the Frame
Layer for local packet handling, the Frame Layer (or Protocol Service
Access Point) must add the encapsulation packet header upon receipt of
the data unit to be encapsulated and removed prior to delivery of the
packet from the Frame Layer (or Protocol Service Access Point.) To do
this, the length of the Encapsulation Packet Header must first be
determined according to the header information (as defined above).

## STANDARD PROCEDURES WITHIN THE LAYER

TC Packets may be transmitted to the spacecraft as standalone entities,
or may be batched together into TC Files. A TC File is a complex data
structure which contains an interrelated group of TC Packets, often
addressed to different onboard application processes. The entire File
must be transferred to the spacecraft complete and without error, though
it is not necessarily required to transmit its internal elements in
sequential order. However, the File may not be released for execution
within the destination application processes until it is complete and
all of its parts are in sequence. At the sending end of the TC System,
the knowledge that the TC data units must be handled as a File is passed
to the layer below (e.g., the Data Routing Service) by encapsulating the
data units within CCSDS standard data interchange structures that
contain appropriate control instructions.

Since the TC Packets within the File are interrelated, they must be
given a common \"name\" to identify this relationship for the purposes
of system control. For example, it may be required to be able to
activate, suspend or cancel an entire File via a single command, even if
the individual component packets of the File have been distributed for
storage within their addressed application processes. This issue of the
Recommendation therefore defines the required \"File Handling and
Naming\" procedure.

### FILE HANDLING AND NAMING PROCEDURE

Indication that a set of user application data is to be aggregated into
a TC File is conveyed to the Packetization layer by means of session
control instructions from the System Management layer. A TC File has
three main attributes:

\(1\) It has a distinct \"File Name\" by which it may be identified
throughout all phases of transport and delivery. The File Name supports
the facility to modify, activate, suspend, resume or abort all elements
within the File at any time prior to their release for execution.

\(2\) It contains a predefined number of interrelated TC Packets.

\(3\) It must be delivered intact and complete before any of its
internal elements may be released for execution.

The structure of a TC File shall conform to either of the following
conventions:

A. It shall consist of one long named \"parent\" TC Packet, containing
all of the individual interrelated packets encapsulated within its data
field, or

B. It shall consist of an aggregated, delimited string of distinct named
TC Packets, beginning with a leading TC Packet which \"opens\" the file
and defines its internal structure (e.g., how many other packets
follow). A trailing TC Packet may be used to \"close\" the file if
desired.

The TC Packet format features which support File addressing and naming
are the \"Application Process ID\" and \"Packet Sequence Control\"
fields. For convention \"A\", the parent TC Packet shall contain an
Application Process ID which addresses it to an onboard File handling
process. The encapsulated packets shall have identifiers of their
eventual destination application processes. For convention \"B\", only
the opening and closing packets shall contain the Application Process ID
of the onboard File handling process: intermediate packets shall contain
identifiers of their eventual destination application processes.

An abstract-syntax User File Name is created within the Application
Process layer. This User File Name (e.g., \"Calibration 23\" or \"Orbit
426\") provides the capability for the user to track the status of the
File as it progresses through the delivery process, so that it may be
activated, suspended, resumed or aborted at any point prior to
execution. The System Management layer translates the abstract-syntax
User File Name into concrete transfer syntax for use by the
Packetization layer, and creates the corresponding session control
instructions which request services from lower layers of the telecommand
system in order to deliver the File. (Note: the details of these control
instructions are not presently specified within this Recommendation.)

Successful transport of the File is reported back to the sending end of
the Packetization layer via a Telemetry Packet from the receiving end
which contains the concrete-syntax File Name as the single identifier of
the entire collection. The abstract contents of such a reporting packet
are an item for potential future standardization.

The Packetization layer shall use the following rules for inserting the
concrete File Name into the \"Packet Sequence Control\" field of the
header of each TC Packet which is a component of the File:

\(1\) The concrete File Name shall be inserted into the 14-bit \"Packet
Name or Sequence Count\" subfield of the Packet Header. Local rules for
formatting this subfield may be adopted by the using Project; for
instance, it may be internally partitioned to include both the File Name
AND a counter which provides sequence control information to the
destination application process.

\(2\) If more than 14 bits are required for the concrete File Name, the
name may be extended into the Secondary Header.

The Packetization layer draws upon the layers below (e.g., the Data
Routing Service) in order to transfer a named File to the spacecraft.
The File is passed to the layer below by encapsulating it within a CCSDS
standard data interchange structure which also contains the control
instructions for transfer to the spacecraft. For instance, these
instructions may specify that for the duration of transfer, the File
must be attached to a specific Virtual Channel by the Data Routing
Service, and must be moved to the spacecraft according to a selected
Command Operation Procedure.

########   DATA MANAGEMENT SERVICE  ACRONYMS AND TERMINOLOGY

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

**Purpose:**

This Annex defines the key acronyms and terms which are used throughout
this Recommendation to describe activities within the Application
Process, System Management and Packetization layers.

**ACRONYMS**

**CCSDS:** CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS

**COMM. NET:** COMMUNICATION NETWORK

**ID:** IDENTIFIER

**MSB:** MOST SIGNIFICANT BIT

**OPT:** OPTIONAL

**S/C:** SPACECRAFT

**SEC. HDR:** SECONDARY HEADER

**TC:** TELECOMMAND

**TERMINOLOGY**

**ABSTRACT TRANSFER SYNTAX:**

A formal logical notation used within the Application Process layer to
express a user command request.

Example: a user request might take the form of \"Request #426/34: turn
on Spectrometer Scanner Motor #5 at perigee on Orbit-426, providing that
Baseplate Temperature does not exceed 42-degrees Centigrade\". The
Abstract Transfer Syntax might define the command to lower layers of the
Telecommand System as follows: \"::Spacecraft(82):: Session(2187)::
Day(234):: Window(17:00-18:30):: File(O426):: Contingency(A56)::
COP(2/VC-34):: Instrument(10):: SM5ON(Temp\<42):: Powermargin(10w)::
UserID(426/34)::\"

**APPLICATION PROCESS:**

Application Processes provide the facilities and interfaces whereby
which a user directs a receiving element in space. Application Processes
exist at both ends of the Telecommand System.

At the sending end, Application Processes formulate Command Directives
in response to requests for commands submitted by a user. Other
Application Processes integrate, aggregate, assemble, validate and
\"name\" sets of Command Directives for delivery to the spacecraft in
order to execute desired mission sequences. Application Processes also
direct and monitor the end-to-end process of delivering and executing
the commands, including the selection of recovery strategies in case of
abnormal performance by lower layers of the system. At the receiving
end, Application Processes execute and confirm the spacecraft actions
specified by the Command Directives.

**APPLICATION PROCESS LAYER:**

The upper layer of the TC System is the Application Process layer. It
contains the Application Processes that support spacecraft commanding at
the sending and receiving ends, and includes the data formats and
protocols which are used to exchange information. The layer translates
user requests into Command Directives.

**COMMAND:**

An instruction from a user to a receiving element (spacecraft
application process) to perform a specific control action.

A user may input a request for a command into the Telecommand System in
the form of either a high-level language expression of the desired
activity (which must be translated prior to delivery to the spacecraft),
or actual executable data bits.

**COMMAND DIRECTIVE:**

A Command Directive is a high-level language representation of a desired
control action, which has been formulated by an Application Process in
an \"Abstract Transfer Syntax\" in response to a request for command
activity submitted by a user.

A Command Directive contains three abstract components:

\(1\) An identifier by which the user may trace the command(s) during
transit.

\(2\) The requested command(s).

\(3\) The instructions for delivering and executing the command(s) (time
windows,

required system state at execution time, contingency procedures, etc.).

**CONCRETE TRANSFER SYNTAX:**

The actual Telecommand data which are transported to the spacecraft as
the contents of TC Packets, consisting of binary-encoded representations
of the abstract command.

**CONTROL INSTRUCTION:**

Information required to set up a TC System layer to support the handling
of Telecommands.

**NAMED SET:**

A collection of user Command Directives which must be delivered as a
complete entity. The set of interrelated directives is given a \"name\"
by the user to facilitate control and traceability of the collection
during the delivery process.

**PACKETIZATION LAYER:**

The Packetization layer (which resides immediately below the System
Management layer) formats the Telecommand application data into
end-to-end transportable data units called \"Telecommand Packets\",
possibly arranges the packets into interdependent batches called
\"Telecommand Files\", moves the packets to the receiving end, and
confirms their correct receipt.

**RECEIVING ELEMENT:**

That part of the space system which executes a command to produce a
desired control action.

**RECEIVING END:**

Those parts of the Telecommand System which are in the vicinity of the
receiving element.

**SENDING END:**

Those parts of the Telecommand System which are in the vicinity of the
user.

**STANDARD DATA INTERCHANGE STRUCTURE:**

A CCSDS-defined standard method for passing data between application
processes.

**SYSTEM MANAGEMENT LAYER:**

The System Management layer (which resides immediately below the
Application Process layer) provides the transformation between
high-level user Command Directives and the detailed information and
instructions used within lower layers to deliver sets of commands. In
particular, the layer translates between the Abstract Transfer Syntax
used by the application processes and the \"Concrete Transfer Syntax\"
used by the Packetization and lower layers.

**TELECOMMAND:**

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

**TELECOMMAND DELIVERY:**

Telecommand Delivery is the end-to-end process of transferring
telecommands from an Application Process at the sending end to an
Application Process at the receiving end. An intermediate step within
the delivery process is Telecommand Transport.

**TELECOMMAND FILE (TC File):**

A TC File is a named set of interrelated and ordered TC Packets which
together control an independent unit of activity on board the receiving
spacecraft, and which must be transported intact and complete (but not
necessarily in sequence) prior to being released for delivery and
execution. The TC File contains all the telecommands to perform one
complete, well-defined sequence of activities for a specific segment of
a mission, e.g., a trajectory maneuver, a scientific data-taking
exercise, or an emergency routine, and therefore often contains commands
addressed to multiple destinations. The activities directed by a File
are theoretically independent of those directed by other Files.

**TELECOMMAND PACKET (TC Packet):**

A TC Packet is a protocol data unit consisting of a two elements:

\(1\) A Header conveying identification information, and

\(2\) A Data Field containing user command application data destined for
delivery to a specific application process onboard a desired receiving
spacecraft.

Conceptually, the length of a TC Packet is unconstrained: however, the
present concrete implementation of the TC Packet has a finite maximum
length.

**TELECOMMAND SESSION:**

A TC Session is the period of time when Application Processes at the
sending and receiving ends of the TC System are physically and/or
logically interconnected for the purpose of delivering Telecommand data.
A TC Session is established to transport all of the telecommands
required to execute a specific set of actions that implement a
particular phase of the overall mission profile.

**TELECOMMAND SYSTEM:**

The end-to-end confederation of layered data handling services which
exist to enable a user to send commands to receiving element in space.
An end-to-end space Telecommand System contains both a \"sending end\"
and a \"receiving end\".

**TELECOMMAND TRANSPORT:**

Telecommand Transport is the process of moving a set of TC user data
from the sending end to the receiving end of the Packetization layer,
using services provided by the lower layers. When correct receipt of the
set is confirmed at the receiving end, the commands are passed to the
System Management layer for delivery.

**USER:**

A human or machine-intelligent process which directs the progress of a
space mission by sending commands to a space system.

**USER DATA:**

Telecommand information bits which are to be delivered without
alteration to a user application process.

**USER FILE NAME:**

Naming of the file is performed by an Application Process. The User File
Name (e.g., \"Orbit 426\") provides the capability for the user to track
the status of the file as it progresses through the delivery process, so
that it may be activated, suspended, resumed or aborted at any point
prior to execution. The System Management layer translates the
high-level User File Name into an appropriate concrete transfer syntax
for use by the Packetization layer, and creates the corresponding TC
Session control instructions which request services from lower layers of
the TC System in order to deliver the file.

########   DATA MANAGEMENT SERVICE SPECIFICATION

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

**Purpose:**

This Annex provides the detailed specification of the service provided
by the Application Process, System Management and Packetization layers.

######## OVERVIEW OF THE LAYERS WITHIN THE DATA MANAGEMENT SERVICE {#overview-of-the-layers-within-the-data-management-service .Annex-2}

Human users are the supervisors of a space mission. It is they (or their
machine-intelligent delegates) who establish an overall data acquisition
profile, monitor the incoming data, and decide on changes to future
data-taking sequences based on observed results. The mechanism which
permits control of the data acquisition process is the Telecommand
System: the Data Management Service provides the primary user interface
with the Telecommand System.

The Data Management Service is distributed between elements of service
provided at the sending end (where the user resides) and the receiving
end (where commanded actions are effected). The two ends may be remotely
located, or coincident.

The first layer of human interface with the Telecommand System consists
of a diverse set of user-controlled application processes. The
Application Process layer assists the users in the preparation of the
overall mission sequence of events by: identifying where data-taking
opportunities exist; formulating the command directives which will cause
changes in the state of the mission system; integrating and aggregating
the directives from many users to form a validated, workable series of
actions which are to be performed; partitioning the series of actions
into independent pieces; directing the overall delivery of telecommands
which implement those actions to the spacecraft; and reporting
successful execution to the user.

The Application Process layer draws upon the services of a System
Management layer to provide the transformation between the high-level
actions requested by the user and the detailed (bit-level) application
data which are required by lower layers of the automated Telecommand
System.

The System Management layer provides these services by: translating
abstract user command directives into concrete telecommand application
data which are to be transmitted to the receiving Application Processes
in space; providing a local concrete presentation syntax for these
application data; formulating the detailed session control and
scheduling parameters required by this and other layers to deliver the
telecommand data to the spacecraft; passing the detailed session control
requirements to other layers; and reporting successful onboard delivery
of telecommand data to the Application Process layer.

The System Management layer draws upon the services of the Packetization
layer to assemble the actual concrete data objects which are used to
move the application data to the receiving end in space, to establish
the transport connection, and to perform and verify their transport.

The Packetization layer provides these services by: encapsulating the
application data within standard labelling information required to
ensure reliable transport; possibly packaging the labelled data units
(packets) into interrelated batches (files) which must be transported
intact; transporting these packets or batches of packets through the
lower layers which provide physical data routing and transmission to the
spacecraft; and reporting the successful transport of application data.

The Packetization layer draws upon the Data Routing Service
(Segmentation and Transfer layers) and the Channel Service (Coding and
Physical layers) to physically transmit the batches of data units to the
spacecraft, as described in References \[C2\], \[1\], and \[2\].

######## APPLICATION PROCESS LAYER SERVICE SPECIFICATION {#application-process-layer-service-specification .Annex-2}

The basic Quality of Service of the Application Process layer is to
permit a single user to formulate one instruction to control a single
remote function in space, interface that instruction with the systems
which provide physical delivery, and execute the instruction as directed
by the user. When multiple users are involved who share common
resources, the enhanced Quality of Service is to integrate multiple user
instructions which control multiple, interdependent functions in space,
validate the integrated instructions to verify that common resource
constraints are not violated, interface the aggregated instructions with
the systems which provide physical delivery, and execute the
instructions as directed by the users.

1.  Application Process Layer: Sending End Service Specification

\(1\) INPUTS

From the user:

\(a\) Individual requests for mission scheduling information.

\(b\) Individual requests for specific named command actions, formulated
in a suitable high-level language.

\(c\) Instructions defining the delivery and execution requirements
associated with the named commands.

From the receiving end of the layer:

\(d\) Reports describing telecommand execution status.

From the layer below:

\(e\) Reports describing TC System delivery performance.

\(2\) OUTPUTS

To the user:

\(a\) Mission scheduling and sequencing information.

\(b\) Reports defining the naming conventions used to label the
requested command actions, and describing the status of their delivery.

\(c\) Reports which indicate the proper execution of specific command
actions.

To the receiving end of the layer:

\(d\) Control instructions defining the overall spacecraft system
conditions which must exist at the time of execution of the commands.

To the layer below:

\(e\) Integrated, aggregated, named sets of multi-user command
directives for translation into transportable application data and
delivery instructions.

\(f\) Requests for the status of delivery of named sets of command
directives.

\(g\) Control instructions which select the particular overall
Telecommand System configuration that is required for delivery of the
command directives.

\(3\) INTERNAL FUNCTIONS

\(a\) Maintains a current data base of mission scheduling information
(integrated mission sequence, data acquisition profile, telecommanding
opportunities, Telecommand System operational schedules and resource
constraints, etc.).

\(b\) Displays selected scheduling information in response to queries
from individual users.

\(c\) Iteratively responds to individual user requests for specific
command actions by indicating system resource availability.

\(d\) Translates individual user requests for named command actions into
correspondingly named command directives which are interpretable by the
layer below.

\(e\) Provides facilities for the user to suspend, resume or abort the
transfer of the named sets at any time prior to execution.

\(f\) Integrates the command directives from multiple users into named
sets, and communicates the naming conventions to the user.

\(g\) Organizes the named sets of directives into telecommand sessions,
validates the workability of the sessions by appropriate checking of
interactions and system resource constraints and allocations, and
possibly estimates the overall effect of the telecommand sessions by
simulating the integrated spacecraft response to set of command
directives.

\(h\) Generates the control instructions which are required by the layer
below in order to communicate the named sets of command directives to
the spacecraft in a timeframe which is responsive to user objectives,
including the selection of the overall Telecommand System configuration
that is required.

\(i\) Generates control instructions to the receiving end of the layer
which define the system conditions that must exist at time of execution
of the named sets of command directives.

\(j\) Analyzes reports from the receiving end of the layer, and from the
layer below, and formulates on-demand reports to the user on the status
of delivery and execution of named sets of command directives.

2.  Application Process Layer: Receiving End Service Specification

\(1\) INPUTS

From the spacecraft system:

\(a\) Current spacecraft state, resource status, time.

From the layer below:

\(b\) Named sets of executable commands.

From the sending end of the layer:

\(c\) Control instructions which define the operational conditions that
must exist in order to execute the named sets of commands.

\(2\) OUTPUTS

To the spacecraft system:

\(a\) Executed command actions which cause changes in spacecraft state
at the appropriate time.

To the sending end of the layer:

\(b\) Reports describing telecommand execution status.

To the layer below:

\(c\) Reports describing ability of the layer to accept new deliveries.

\(3\) INTERNAL FUNCTIONS

\(a\) Receives named sets of executable commands, which have been
translated as appropriate by the layer below from the local syntax that
was used during delivery from the sending end.

\(b\) Analyzes control instructions from the sending end of the layer
which define the operational conditions that must exist at time of
execution.

\(c\) Executes named sets of commands when operational conditions are
satisfied, including possibly checking to verify that resource
constraints are not violated.

\(d\) Provides the capability for the user to suspend, resume or abort
named sets of commands at any time prior to release for execution.

\(e\) Formulates reports to the sending end of the layer describing the
status of command execution.

\(f\) Notifies the layer below if unable to accept new deliveries.

######## SYSTEM MANAGEMENT LAYER SERVICE SPECIFICATION {#system-management-layer-service-specification .Annex-2}

The basic Quality of Service of the System Management layer is to
deliver a single, named user command across this layer (from the output
of the sending end of the layer above to the input of the receiving end
of the layer above), according to control instructions generated by the
layer above, and to verify its correct delivery. When multiple users are
involved who share common resources, the enhanced Quality of Service is
to deliver named sets of interdependent user commands across the layer,
and to verify correct delivery of the entire sets without omission or
duplication and in sequence.

3.  System Management Layer: Sending End Service Specification

\(1\) INPUTS

From the layer above:

\(a\) Individual user-named command directives, or sets of integrated,
aggregated, named user command directives, containing commands and their
delivery control instructions.

\(b\) Requests for reports of delivery status.

From the receiving end of the layer:

\(c\) Reports defining the status of receipt of commands or named sets
of commands.

From the layer below:

\(d\) Reports defining the overall status of end-to-end transport of
named sets of telecommands.

\(2\) OUTPUTS

To the layer above:

\(a\) Reports describing the overall delivery status of named sets of
telecommands.

To the receiving end of the layer:

\(b\) Control instructions defining naming conventions and system
conditions which must exist at time of delivery of the telecommands to
the layer above.

To the layer below:

\(c\) Named sets of telecommand application data for transport.

\(d\) Transport control instructions to enable movement of telecommand
application data to the spacecraft.

\(e\) Requests for the status of transport of named sets of
telecommands.

\(f\) Requests to implement security/privacy measures.

\(3\) INTERNAL FUNCTIONS

\(a\) Translates named sets of abstract-syntax user command directives
into correspondingly-named sets of transportable concrete-syntax
telecommand application data.

\(b\) Prepares the named sets of application data for transport to the
spacecraft during a TC Session, including requesting security/privacy
measures from the layer below.

\(c\) Establishes the TC Sessions by requesting physical connection
services from lower layers, and passing the named sets of application
data to the layer below.

\(d\) Manages and supervises the TC Sessions by specifying the transport
control parameters to the layer below, by monitoring the progress of
transport during\
\
the sessions, and by permitting modification of the transport process if
so instructed by Application Processes (e.g., by permitting named sets
of telecommand data to be suspended, resumed, released for delivery or
aborted as required).

\(e\) Generates control instructions to the receiving end of the layer
defining the system conditions which must exist at time of delivery of
the application data to the layer above.

\(f\) Analyzes reports from the layer below which describe the overall
status of transport of the telecommand application data, and creates
appropriate recovery instructions in the even of interruption of service
within the lower layers.

\(g\) Formulates on-demand reports to the layer above which describe the
delivery status of named sets of telecommand application data.

4.  System Management Layer: Receiving End Service Specification

\(1\) INPUTS

From the layer above:

\(a\) Information concerning the ability of the layer to accept new
deliveries of data.

From the sending end of the layer:

\(b\) Session control instructions defining the conditions for delivery
of the telecommand data to the layer above on the spacecraft.

From the layer below:

\(c\) Named sets of telecommand application data.

\(d\) Transport status information relating to the correctness,
completeness and sequentiality of the received sets of application data.

\(2\) OUTPUTS

To the layer above:

\(a\) Named sets of commands.

To the sending end of the layer:

\(b\) Reports defining the status of delivery of named sets of commands.

To the layer below:

\(c\) Reports defining the ability of the layer to accept more data.

\(3\) INTERNAL FUNCTIONS

\(a\) Receives named sets of telecommand application data from the layer
below.

\(b\) Receives control instructions from the sending end of the layer
defining the conditions for delivery of application data to the layer
above.

\(c\) Receives transport status information from the layer below, and
determines when the telecommand application data are ready for delivery
to the layer above.

\(d\) Translates concrete-syntax telecommand application data back into
abstract-syntax commands, if required by the layer above.

\(e\) Delivers named sets of user commands to appropriate addresses
within the layer above when the delivery conditions are satisfied.

\(f\) Formulates reports back to the sending end of the layer describing
the delivery status of named sets of user commands.

\(g\) Formulates reports to the layer below describing its ability to
accept more data.

######## PACKETIZATION LAYER SERVICE SPECIFICATION {#packetization-layer-service-specification .Annex-2}

The basic Quality of Service of the Packetization layer is to transport
the application data corresponding to one user telecommand across this
layer (from the output of the sending end of the layer above to the
input of the receiving end of the layer above), according to transport
control instructions generated by the layer above, and to verify its
error-free delivery within the error detecting and optional error
correcting capability of this and lower layers.

When named sets of interdependent user telecommands are being used, the
enhanced Quality of Service is to deliver the executable application
data corresponding to the entire set of telecommands across this layer
without omission or duplication and in sequence. A further enhancement
of the service is to optionally provide security and/or privacy measures
in order to protect the transported telecommands from unauthorized
interference (Reference \[C2\]).

5.  Packetization Layer: Sending End Service Specification

\(1\) INPUTS

From the layer above:

\(a\) Named sets of transportable telecommand application data.

\(b\) Transport control instructions.

\(c\) Requests for reports of the status of transport of named sets of
telecommand application data.

\(d\) Requests for security/protection measures.

From the receiving end of the layer:

\(e\) Reports (e.g., Telemetry Packets) describing the status of receipt
of named sets of telecommand application data (e.g., TC Packets or TC
Files).

From the layer below:

\(f\) Reports describing the status of the data routing process.

\(2\) OUTPUTS

To the layer above:

\(a\) On-demand reports defining the transport status of named sets of
telecommands.

To the receiving end of the layer:

\(b\) Transport control instructions (e.g., special control TC Packets)
defining the data reassembly and forwarding procedures which are to be
used, including parameters for algorithms which implement optional data
security/privacy measures.

To the layer below:

\(c\) Transportable sets of telecommand data (e.g., TC Packets or TC
Files) which are to be routed to the spacecraft, including
security/privacy encoding of these data if required.

\(d\) Routing control instructions which are required in order to
transfer the telecommand data to the spacecraft.

\(3\) INTERNAL FUNCTIONS

\(a\) Encapsulates named sets of user application data into the data
field of TC Packets.

\(b\) Constructs transport parameters for insertion into the header of
the TC Packets, including application address, sequence control and
length information.

\(c\) Assembles TC Packets into TC Files, if required.

\(d\) Inserts local naming syntax into the TC Packets or TC Files to
identify them during transport, and maintains traceability with respect
to the corresponding user names for the sets of commands.

\(e\) Encodes the application data contents of TC Packets as required to
implement data security/privacy measures.

\(f\) Generates data routing control instructions to the layer below,
including the selection of services such as the temporary attachment of
particular packets, sequences or files to particular virtual channels
for transfer to the spacecraft.

\(g\) Generates control instructions to the receiving end of the
Packetization layer relative to the system conditions which must exist
when telecommand data are reassembled and passed to the System
Management layer.

\(h\) Analyzes reports from the receiving end of the layer which
describe the reassembly status of particular TC Packets or TC Files.

\(i\) Analyzes reports from the layer below which describe data routing
status.

\(j\) Generates on-demand reports to the layer above describing the
status of end-to-end transport of named sets of telecommands.

6.  Packetization Layer: Receiving End Service Specification

\(1\) INPUTS

From the layer above:

\(a\) Information concerning the ability of the layer to accept more
data.

From the sending end of the layer:

\(b\) Control instructions defining system conditions which must exist
in order to reassemble and pass the telecommand data to the layer above,
including security/privacy measures.

From the layer below:

\(c\) Transported telecommand data (e.g., TC Packets or TC Files).

\(d\) Information describing the status of the data routing process.

\(2\) OUTPUTS

To the layer above:

\(a\) Named sets of Telecommand application data, corresponding to the
data content of TC Packets.

\(b\) Transport status information relating to the correctness,
completeness and sequentiality of the received sets of Telecommand data.

To the sending end of the layer:

\(c\) Reports describing the status of receipt of named sets of
Telecommand data (Packets or Files).

To the layer below:

\(d\) Reports describing the ability of the layer to accept more data.

\(3\) INTERNAL FUNCTIONS

\(a\) Extracts named sets of Telecommand application from the data
fields of TC Packets and reassembles the sets into the same sequential
order in which they were given to the Packetization layer at the sending
end.

\(b\) Analyzes control instructions from the sending end of the layer
which define the system conditions that must exist in order to pass the
Telecommand application data to the layer above, including implementing
data security/privacy checks if required.

\(c\) Passes the named sets of Telecommand application data to the layer
above when appropriate system conditions are satisfied.

\(d\) Formulates reports to the sending end of the layer describing the
status of receipt and reassembly of particular named sets of Telecommand
application data (Packets or Files).

\(e\) Formulates reports to the layer below describing its ability to
accept more data.

########   INFORMATIVE REFERENCES

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

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

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

[^1]: ^†^ Internet Request for Comments (RFC) texts are available on
    line in various locations (e.g., http://ietf.org/rfc/); Internet
    standards are made up of one or more RFCs, which are identified in
    square brackets following the entry.