CAUTION - This text file is provided for the sole purpose of allowing 
text-string searching.  It is NOT a faithful reproduction of the 
published document:  figures, equations, special characters, and 
character attributes used to convey information are not reproduced in 
this text file;  tables, which may be reproduced as text, may have lost 
crucial row or column alignment.

A Portable Document Format (PDF) version of this document is available 
in the main document listing.  The PDF file contains all elements of the 
document as published by the CCSDS.  The PDF file should be used in all 
cases where there is a need for faithful reproduction of the information 
contained in the published document.


                               CONSULTATIVE
                               COMMITTEE FOR
                            SPACE DATA SYSTEMS



                         RECOMMENDATION FOR SPACE
                           DATA SYSTEM STANDARDS


                    +-----------------------------------+
                    |                                  |
                    |           TELECOMMAND            |
                    |                                  |
                    |              PART 2              |
                    |       DATA ROUTING SERVICE       |
                    |                                  |
                    +-----------------------------------+



                              CCSDS 202.0-B-2
                                     
                                 BLUE BOOK
                                     
                                     
                               NOVEMBER 1992




                                 AUTHORITY



                *******************************************
                *   Issue:     Blue Book, Issue 2         *
                *   Date:      November 1992              *
                *   Location:  CCSDS Meeting              *
                *              November 1992              *
                *              Greenbelt, MD, USA         *
                *******************************************
                                     
                                     
                                     
This Recommendation reflects the consensus technical agreement of the
following member Agencies of the Consultative Committee for Space Data
Systems (CCSDS):

o    British National Space Centre (BNSC)/United Kingdom.
o    Canadian Space Agency (CSA)/Canada.
o    Central Research Institute of Machine Building (TsNIIMash)/ Russian
     Federation.
o    Centre National D'Etudes Spatiales (CNES)/France.
o    Deutsche Forschungsanstalt fr Luft- und Raumfahrt e.V.(DLR)/Germany.
o    European Space Agency (ESA)/Europe.
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 following observer Agencies also concur with this Recommendation:

o    Chinese Academy of Space Technology (CAST)/People's Republic of China.
o    Central Research Institute of Physics (CRIP)/Hungary.
o    Department of Communications, Communications Research Centre (DOC-
     CRC)/Canada.
o    Institute of Space and Astronautical Science (ISAS)/Japan.


This Recommendation is published and maintained by:


     CCSDS Secretariat
     Program Integration Division (Code-OI)
     National Aeronautics and Space Administration
     Washington, DC 20546, USA
                                     
                                     
                                     
                                     
                            STATEMENT OF INTENT


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

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

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

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

   -    The STANDARD itself.

   -    The anticipated date of initial operational capability.

   -    The anticipated duration of operational service.

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

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

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

                                     
                                     
                                     
                                     
                                 FOREWORD


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

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

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

The current layered set of CCSDS telecommand Recommendations was developed
to match the conventional free-flying mission environment, as characterized
by the transmission of command data at relatively low uplink data rates to
spacecraft of moderate complexity.  Advanced Orbiting Systems (AOS), which
are characterized by 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, may
choose to use the AOS protocols and data structures defined in Reference
[8] for both uplink and downlink or they may use the telecommand data
structures and protocols defined here for uplink.

This Recommendation for Telecommand Data Routing 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 intermediate 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 which are defined in Reference [1].
                                     
                                     
                                     
                                     
                             DOCUMENT CONTROL



Document    Title                      Date       Status and Substantive
                                               Changes
                                                  
                                                  
CCSDS       Recommendation for Space   January    Original Issue
202.0-B-1   Data System Standards.     1987
           Telecommand, Part 2
           Data Routing Service,
           Issue 1
                                                  
                                                  
CCSDS       Recommendation for Space   November   Supersedes Issue 1
202.0-B-2   Data System Standards      1992        Removal of COP-0 & COP-2
           Telecommand, Part 2 Data              Longer Frame length
           Routing Service, Issue 2              Multiple Packets per
                                                   Frame
                                                 Single Virtual Channel
                                                   not required to have
                                                   Identifier set to "all
                                                   zeros"
                                                 Use of AOS downlink
                                                 Full definition of Frame
                                                   Error Control algorithm
                                                 Removal of mandatory
                                                   performance
                                                   requirements
                                                 Correction of error in
                                                   maximum Packet length
                                                   specification
                                                   (B-2.1(1)(a))
                                                 Segment layer not
                                                   optional (Segment
                                                   Header is still
                                                   optional)
                                                 Consistency with part 2.1
                                                   (Reference [7])
                                                  
                                     
                                     
NOTE:     Substantive changes from the previous issue are flagged with
          change bars in the margin.
                                     
                                     
                                     
                                     
                                 CONTENTS


Sections                                                  Page

   REFERENCES                                               vii

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

2  TELECOMMAND DATA ROUTING SERVICE OVERVIEW                2-1

3  SEGMENTATION 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-2
       3.2.1     Frame Data Unit                            3-2
       3.2.2     Telecommand Segment                        3-2
   3.3 STANDARD PROCEDURES WITHIN THE LAYER                 3-4
       3.3.1     Sending End Procedures                     3-4
       3.3.2     Receiving End Procedures                   3-6


4  TRANSFER 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-1
       4.2.1     TC Transfer Frame Format                   4-3
       4.2.2     Command Link Control Word Format           4-9
   4.3 STANDARD PROCEDURES WITHIN THE LAYER                 4-14
       4.3.1     Frame Delimiting and Fill Removal
                 Procedure                                  4-14
       4.3.2     Frame Validation Check Procedure           4-15
       4.3.3     Command Operation Procedure                4-16

Annexes

A  DATA ROUTING SERVICE ACRONYMS AND TERMINOLOGY            A-1

B  DATA ROUTING SERVICE SPECIFICATION                       B-1





Figures

2-1    Telecommand System                                   2-2
3-1    Orientation of the Segmentation Layer                3-2
3-2    Telecommand Segment Format                           3-3
3-3    Example of the Segmentation Procedure                3-6
4-1    Orientation of the Transfer Layer                    4-2
4-2    TC Transfer Frame Format                             4-3
4-3    Command Link Control Word Format                     4-10
B-1    TC Data Routing Service Elements                     B-3

Tables

4-1    Interpretation of the "Bypass" and
       "Control Command" Flags                              4-5
                                     
                                     
                                     
                                     
                                REFERENCES


[1]  "Procedures Manual for the Consultative Committee for Space Data
     Systems", CCSDS A00.0-Y-5, Issue 5. Yellow Book, Consultative
     Committee for Space Data Systems, May 1992 or later issue.

[2]  "Telecommand, Summary of Concept and Service", CCSDS 200.0-G-6, Issue
     6, Green Book, Consultative Committee for Space Data Systems, January
     1987 or later issue.

[3]  "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.

[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]  "Packet Telemetry", Recommendation CCSDS 102.0-B-3, Issue 3, Blue
     Book, Consultative Committee for Space Data Systems, November 1992 or
     later issue.

[6]  "Telemetry Channel Coding", Recommendation CCSDS 101.0-B-3, Issue 3
     Blue Book, Consultative Committee for Space Data Systems, May 1992 or
     later issue.

[7]  "Telecommand, Part 2.1: Command Operation Procedures", Recommendation
     CCSDS 202.1 B-1, Issue 1, Blue Book, Consultative Committee for Space
     Data Systems, October 1991 or later issue.

[8]  "Advanced Orbiting Systems: Networks and Data Links", Recommendation
     CCSDS 701.0-B-2, Issue 2, Blue Book, Consultative Committee for Space
     Data Systems, November 1992 or later issue.

[9]  "Advanced Orbiting Systems: Summary of Concepts, Rationale and
     Performance," CCSDS 700.0-G-3, Issue 3, Green Book, Consultative
     Committee for Space Data Systems, November 1992 or later issue.

[10] "CCSDS Global Spacecraft Identification Field: Code Assignment
     Control Procedures, CCSDS A10.0-R-1, Issue 1, Red Book, Consultative
     Committee for Space Data Systems, May 1992 or later issue of Blue
     Book.

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




1  INTRODUCTION

1.1    PURPOSE AND SCOPE

The purpose of this document is to establish a common Recommendation for
the implementation of a spacecraft telecommand "Data Routing Service" by
the Agencies participating in the Consultative Committee for Space Data
Systems (CCSDS).  The operating principles and procedures for the CCSDS
are defined in Reference [1].  The context of the Data Routing Service
within the overall Telecommand System is described in Reference [2].

This Recommendation addresses the procedures and data unit formats
implemented within the Segmentation layer and the Transfer layer of the
telecommand Data Routing Service.

1.2    APPLICABILITY

This Recommendation serves as a guideline for the development of
compatible internal Agency standards in the field of conventional
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 conventional spacecraft
telecommanding, which is summarized in Reference [2].  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 conventional Project's
telecommanding architecture should follow this Recommendation for Data
Routing Service, plus the Recommendations for telecommand "Data Management
Service" and telecommand "Channel Service", which are described in
References [3] and [4].  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.

Advanced Orbiting Systems (AOS) may use the AOS data structures and
protocols defined in Reference [8] for uplinking data and control
information or they may use the telecommand data structures and protocols
defined here and in References [3], [4] and [7] in a hybrid fashion.  See
Reference [9] for a discussion of hybrid support.

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.

1.3    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 transferred (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 bit of the field, i.e., "Bit 0".

                                     
                         [GRAPHIC ELEMENT OMITTED]


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:


                         [GRAPHIC ELEMENT OMITTED]


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




2    TELECOMMAND DATA ROUTING SERVICE OVERVIEW

A complete summary of the acronyms and terminology used internal to this
document is presented in Annex A.  A detailed specification of the services
provided by each layer is presented in Annex B.

Figure 2-1 illustrates the significance of the Telecommand (TC) Data
Routing Service in the overall Telecommand System, which contains three
principal service elements:  Telecommand Data Management Service;
Telecommand Data Routing Service; and Telecommand Channel Service.  Each
service is documented in its own Recommendation.  A more thorough
discussion of the layered services, including expansion of Figure 2-1 in
greater detail, is contained in Reference [2].  The Telecommand System is
related to the Telemetry System as documented in Reference [5] and
Reference [6].

The TC Data Routing Service enables user telecommand data units associated
with higher layers to be reliably transferred to the spacecraft, drawing
upon the Channel Service to perform its functions.  The Data Routing
Service contains two distinct layers of data handling operations:

   (1) A SEGMENTATION layer, which prepares the user data units for
       transfer by forming them into suitable-sized routable pieces and
       permitting these pieces to be multiplexed together for transmission
       through the command channel.

   (2) A TRANSFER layer, which encapsulates the routable pieces of user
       data into transfer data structures and controls their transmission
       through the channel, including any retransmissions needed to ensure
       delivery of the routable pieces in sequence without gaps or
       duplication.

The detailed specification of the retransmission mechanism, called the
Command Operation Procedure, is given in Part 2.1 of the Telecommand
Recommendation (Reference [7]).

The Data Routing Service provides an interface between the high-layer
"user" elements of the TC System and the low-layer communications channel
through which data flow.

Because the underlying Channel Service inherently includes a noisy signal
path, there is a finite probability that it will introduce an error.  Since
any error in the user's data will render them invalid, it is desirable to
break large user data units into relatively small pieces (which will thus
each have a lower probability of being invalidated by transmission error
than if the entire user data unit were sent contiguously).  This improves
system throughput efficiency since only small pieces have to be
retransmitted when errors are detected.  However, there may also be
situations in which the user data units are very small.  For efficient
transfer, the Data Routing Service provides the capability to group these
small units into larger pieces.

Analysis of the performance of the Channel Service and Data Routing Service
under various conditions is contained in Reference [2].






                         [GRAPHIC ELEMENT OMITTED]


                      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
       protocols flowing ACROSS the layers 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 flow of control instructions, which are required to
       initialize the layers and to direct the flow of TC data units
       BETWEEN the layers, remains an item for potential future extension
       of this document.

NOTE C:Although the layers defined in this document may be used without
       necessarily implementing those defined in the Channel Service
       (Reference [4]) and Data Management Service (Reference [3]), the
       names of the layers in those Services will be used to denote the
       external interfaces for the Data Routing Service, when appropriate.



3      SEGMENTATION LAYER: STANDARD DATA STRUCTURES AND PROCEDURES

3.1    OVERVIEW OF THE LAYER

The data unit received by the Segmentation layer from the higher layer is
called a "TC User Data Unit".  If the higher layer is the Packetization
layer, defined in Reference [3], it will be a TC Packet; otherwise, it may
be any other user-provided data unit.

The data unit passed from the Segmentation layer to the Transfer layer is
the "TC Frame Data Unit".  It will normally consist of a TC Segment.  If
neither segmentation nor multiplexing is used on a particular Virtual
Channel, the Segment Header may be omitted on that Virtual Channel.

The TC Segmentation layer accepts variable-length TC User Data Units from
the layer above and prepares them for transmission by the layers below by:

   (1) forming the TC User Data Units into TC Frame Data Units, which are
       compatible with insertion into the data field of the TC Transfer
       Frame.

   (2) enabling TC User Data Units from different sources to be multiplexed
       together so that they may share one Virtual Channel.

To accomplish service (1), the Segmentation layer breaks large TC User Data
Units into smaller TC Segments or aggregates small TC Packets into a larger
TC Segment or TC Frame Data Unit.

To accomplish service (2), the Segmentation layer provides "Multiplexer
Access Points" (MAPs).  A TC User Data Unit arriving at the input to the
Segmentation layer is allocated to a MAP at the sending end of the layer
and is transferred to the corresponding MAP at the receiving end of the
layer using the transfer service of the layers below.  The layers below may
provide one "real" physical channel, or may logically divide the real
channel into multiple, named "Virtual Channels" (as defined in Section 4).
Each of "m" (m = 1 to 64) Virtual Channels (VCs) may have "n" (n = 1 to 64)
distinct MAPs associated with it.  The orientation of the Segmentation
layer is shown in Figure 3-1.

Section 3.2 defines the format of the protocol data unit (the TC Segment),
which is implemented within the Segmentation layer.  Section 3.3 describes
the procedures used within the Segmentation layer.  It should be noted that
the Segmentation layer does not include a telemetry reporting mechanism,
since it relies on closed-loop procedures performed within the Transfer
layer.

                         [GRAPHIC ELEMENT OMITTED]

            Figure 3-1:  Orientation of the Segmentation Layer

3.2  STANDARD DATA STRUCTURES WITHIN THE LAYER

3.2.1  TC FRAME DATA UNIT

The TC Frame Data Unit is the data unit transferred from the Segmentation
Layer to the Transfer layer.  The length of the TC Frame Data Unit may vary
from one TC Frame to the next.  Its length shall not exceed the maximum
allowed length of the Transfer Frame Data Field.

The maximum length of the TC Frame Data Unit depends on whether Frame Error
Control is being used (See Section 4.2.1.3).

   With Frame Error Control        1017 octets
   Without Frame Error Control     1019 octets

The maximum length allowed by a particular spacecraft or ground system
implementation on a particular Virtual Channel may be shorter than the
maximum specified here.

The content of a TC Frame Data Unit is defined in Section 3.3.1.

3.2.2  TELECOMMAND SEGMENT

The use of a TC Segment is required for any Virtual Channel which has more
than one MAP or which transfers TC User Data Units which are larger than
permitted in a single TC Frame.  Its use is optional otherwise, except that
if it is used in any TC Frame carried on a Virtual Channel, it must be used
for all TC Frames on that Virtual Channel.

The format of the TC Segment is shown in Figure 3-2.


                         [GRAPHIC ELEMENT OMITTED]

                  Figure 3-2:  Telecommand Segment Format


3.2.2.1   Segment Header.  The Segment Header contains the following two
fields:

   (1) Sequence Flags (Bits 0,1)

       This two bit field delimits the higher layer TC User Data Unit by
       indicating the sequential position of the TC Segment relative to
       the TC User Data Unit (e.g., TC Packet) of which the TC Segment is
       a part. The flags are interpreted as follows:

       Bit 0   Bit 1             Interpretation

        0       1      First Segment of TC User Data Unit on one MAP
        0       0      Continuing Segment of TC User Data Unit on one MAP
        1       0      Last Segment of TC User Data Unit on one MAP
        1       1      No segmentation (one TC User Data Unit or multiple
                       complete TC Packets)

   (2) Multiplexer Access Point (MAP) Identifier (Bits 2 through 7)

       The MAP facility allows user command data from different sources to
       be multiplexed together so that they share the communications
       capacity of one Virtual Channel, thus preventing any one user from
       monopolizing the data transmission resource.

       This six-bit field enables up to 64 MAP addresses (from MAP 0 to MAP
       63) to be associated with each Virtual Channel provided by the
       Transfer layer.  Different TC User Data Units (e.g., separate TC
       Packets) arriving at the input to the Segmentation layer are
       allocated to a MAP.  The segmentation and aggregation processes are
       conducted independently for each MAP.  The resulting TC Frame Data
       Units from up to 64 MAPs are then multiplexed onto one Virtual
       Channel in accordance with user's delivery priorities and
       instructions.  Certain MAPs may have higher transmission priorities
       than others.
       There are no restrictions on the selection of MAP Identifiers.  In
       particular, MAPs are not required to be numbered consecutively.

       If multiple MAPs are not used on a particular Virtual Channel, but
       the Segment Header is otherwise required to be present, Bits 2
       through 7 shall be set to a constant value for all TC Segments
       which are placed on that Virtual Channel.

3.2.2.2   Segment Data Field.  The Segment Data Field contains all or a
portion of the higher layer TC User Data Unit (e.g., TC Packet) or an
aggregation of TC Packets.  The Segment Data Field length is variable with
a maximum length of one octet less that the maximum length of the TC Frame
Data Unit.

3.3    STANDARD PROCEDURES WITHIN THE LAYER

Figure 3-3 illustrates the process of segmenting and aggregating TC User
Data Units (in this example, TC Packets) and inserting them as TC Segments
into TC Frame Data Units.  The procedures are as follows.

3.3.1  SENDING END SEGMENTATION PROCEDURES

The sending end of the Segmentation layer performs the following processing
steps:

   (1) Allocates the TC User Data Unit to a particular Multiplexer Access
       Point.

   (2) If the TC User Data Unit (e.g., the TC Packet) exceeds a
       predetermined length, the Segmentation layer divides it into
       portions that are compatible with insertion into the TC Frame Data
       Unit and attaches a Segment Header to each portion, forming the TC
       Segment/Frame Data Unit.  If the TC User Data Unit is a TC Packet,
       the first octet of the TC Packet Primary Header shall appear in the
       leading octet of the first corresponding Segment Data Field.  The
       first and continuing Segments may each have a length equal to the
       maximum allowable length of the TC Frame Data Unit on that
       particular Virtual Channel.  The last Segment shall have a length
       equal to the residue of the TC User Data Unit plus the Segmentation
       Header.

   (3) If aggregation is permitted on a particular MAP, the Segmentation
       layer places complete TC packets into the TC Segment in the order
       of arrival.  If Segment Headers (and hence MAPs) are not used on a
       particular Virtual Channel, but aggregation is permitted, the
       Segmentation layer places the TC Packets directly into the TC Frame
       Data Unit.  In either case, the aggregated packets (plus Segment
       Header, if used) must fit within the maximum size TC Frame Data
       Unit permitted for the Virtual Channel.  The limitations on the
       number of MAPs which can be aggregating TC Packets simultaneously
       and mechanisms for ensuring transmission of all TC Packets are
       implementation dependent.

   (4) Multiplexes together the TC Frame Data Units from one group of up to
       64 MAPs onto one Virtual Channel, according to the mission's
       priority scheme, and passes the multiplexed stream to the layer
       below.

                         C A U T I O N

A TC FRAME DATA UNIT SHALL CONSIST OF ONLY ONE OF THE FOLLOWING:

 (a)   A TC SEGMENT CONTAINING A PORTION OF ONE TC USER DATA UNIT (E.G. A
       PORTION OF ONE TC PACKET);  or

 (b)   A TC SEGMENT CONTAINING ONE COMPLETE TC USER DATA UNIT(E.G., ONE
       COMPLETE TC PACKET);  or

 (c)   A TC SEGMENT CONTAINING MULTIPLE COMPLETE TC PACKETS;  or

 (d)   ONE COMPLETE TC USER DATA UNIT (E.G., ONE COMPLETE TC PACKET);  or

 (e)   MULTIPLE COMPLETE TC PACKETS.

TC Packets and user-defined data units may not be intermixed.  Each MAP (if
Segment Headers are used) or Virtual Channel (if Segment Headers are not
used) shall carry either TC Packets or user-defined data units, but not
both.

TC Packets with different destinations, as denoted by the Application
Process Identifier in the TC Packet Header, may be carried on a single MAP
or Virtual Channel and may be aggregated within a single TC Frame Data
Unit.

Figure 3-3 shows how TC Packets assigned to one MAP are aggregated or
segmented to form TC Segments/Frame Data Units.

                         [GRAPHIC ELEMENT OMITTED]
                                     
            Figure 3-3:  Example of the Segmentation Procedure


3.3.2  RECEIVING END SEGMENTATION PROCEDURES

The receiving end of the TC Segmentation layer performs the following
processing steps:

  (1)  Accepts a stream of multiplexed TC Segments/Frame Data Units on one
       Virtual Channel from the Transfer layer.

  (2)  Sorts these Segments according to the MAP IDs which appear in their
       Segment Headers.

  (3)  a.   For TC Frame Data Units containing a segment of a TC User Data
       Unit:  reassembles the Segments (less headers) for each MAP, using
       the Sequence Flags, in order to recreate the original TC User Data
       Unit.

       b.   For all other TC Frame Data Units:  extracts the TC Packets or
       TC User Data Unit, using the Frame and Packet Length fields.

  (4)  Passes the resulting TC User Data Unit(s) to the layer above.




4    TRANSFER LAYER:  STANDARD DATA STRUCTURES AND PROCEDURES

4.1  OVERVIEW OF THE LAYER

The TC Transfer layer is the "heart" of the standard conventional TC
System.  It is this layer which takes care of most of the operations
required to move sets of user TC data reliably from the sending end of the
system to the receiving end in space.

Section 4.2 defines the format of the two standard data structures that
reside within the layer:  the "TC Transfer Frame", which flows from the
sending end of the TC System to its receiving end, and the "Command Link
Control Word" (CLCW), which is formatted by the receiving end and is
transmitted back to the sending end via corresponding layers within the
Telemetry System.

Section 4.3 defines the standard procedures which are associated with
       the layer:

   - Frame Delimiting and Fill Removal Procedure
   - Frame Validation Check Procedure
   - Command Operation Procedure (COP)

 A COP consists of a pair of synchronized procedures which execute within
one TC Virtual Channel (VC) at the sending and receiving ends of the layer.
At the sending end a "Frame Operation Procedure" (FOP) is executed.  At the
receiving end a corresponding spacecraft "Frame Acceptance and Reporting
Mechanism" (FARM) is executed.  Detail specification of the COPs are
contained in Reference [7].

Only one COP is defined in this Recommendation:  COP-1.

The orientation of these elements within the Transfer layer is shown in
Figure 4-1.


4.2  STANDARD DATA STRUCTURES WITHIN THE LAYER

This section describes the formats of the following two standard protocol
data units which reside within the TC Transfer layer:

   (1) The TC Transfer Frame, which is the data structure that is
       "uplinked" to the receiving end of the layer on the spacecraft.

   (2) The TC Command Link Control Word (CLCW), which is the data structure
       that is "downlinked" by the spacecraft back to the sending end of
       the layer in order to provide reports which describe the status of
       acceptance and reassembly of TC Frames.


                         [GRAPHIC ELEMENT OMITTED]


              Figure 4-1:  Orientation of the Transfer Layer





4.2.1     TC TRANSFER FRAME FORMAT

The TC Frame (Figure 4-2) contains the following major fields:

Major Field                             Length (Octets)
                                        
FRAME HEADER                              5
FRAME DATA FIELD                     Variable (up to 1019)
FRAME ERROR CONTROL (Optional)           (2)
                                       1024 octets (maximum)

The maximum TC Frame length allowed by a particular spacecraft or ground
implementation on a particular Virtual Channel may be less than the maximum
specified here.

                         [GRAPHIC ELEMENT OMITTED]
                                     
                   Figure 4-2:  TC Transfer Frame Format
                                     
4.2.1.1   Transfer Frame Header.  The FRAME HEADER of the TC Transfer Frame
consists of the following fields, grouped into octets as shown:

     Field                         #Bits    #Octets
                                              
     Version Number                    2           
     Bypass Flag                       1           
     Control Command Flag              1           
     Reserved Spares                   2           
     Spacecraft ID                    10         2 
                                                   
     Virtual Channel ID                6           
     Frame Length                     10         2 
                                                   
     Frame Sequence Number             8         1 
                                                 5 octets

The first two octets of the FRAME HEADER contain the following field
allocations:

   (1) VERSION NUMBER (Bits 0,1)

       The VERSION NUMBER occupies the two most significant bits of the
       Frame Header.  Future changes in the TC Transfer Frame structure
       may be accommodated by changing the VERSION NUMBER.  At present,
       only Version "1" of the TC Transfer Frame (the format specified
       herein) is defined.  It shall be identified by setting Bits 0,1 to
       value "00".

   (2) BYPASS FLAG (Bit 2)

       The single-bit BYPASS FLAG controls the application of "Frame
       Acceptance Checks" by the receiving spacecraft.  ALL Frames
       received by the spacecraft first undergo a basic standard set of
       "Frame Validation Checks", which are applied regardless of the
       setting of the BYPASS FLAG.

       The Frame Acceptance and Reporting Mechanism (FARM) associated with
       the COP can be made to operate in a normal "Acceptance" (frame
       "Type-A") mode or a "Bypass" (frame "Type-B") mode, according to
       the setting of the BYPASS FLAG.

       Setting Bit 2 to value "0" specifies a Type-A TC Frame;  acceptance
       of this Type of frame by the spacecraft shall be subject to the
       normal frame acceptance checks of the FARM.

       Setting Bit 2 to value "1" specifies a Type-B TC Frame;  the normal
       frame acceptance checks of the FARM shall be bypassed.

       Necessarily, it must be possible to send Type-A and Type-B TC
       Frames on the same TC Virtual Channel in order to conduct some
       operations.

   (3) CONTROL COMMAND FLAG (Bit 3)

       The CONTROL COMMAND FLAG specifies whether the data field of the TC
       Transfer Frame is conveying transfer "Control Commands" (the "C"
       mode), or "Data" (the "D" mode).

       In the "C" mode the Frame Data Field contains control information
       which is used to set the parameters of the FARM to the proper
       configuration to accept telecommand data.

       In the "D" mode the Frame Data Field contains a Frame Data Unit
       (e.g., a TC Packet or a TC Segment).

       Setting Bit 3 to value "0" indicates the "D" mode to the receiving
       spacecraft, i.e., that the Frame Data Field contains data.

       Setting Bit 3 to value "1" indicates the "C" mode to the receiving
       spacecraft, i.e., that the Frame Data Field contains Control
       Commands.  The combined states of the BYPASS FLAG and the CONTROL
       COMMAND FLAG are interpreted by the receiving spacecraft as shown
       in Table 4-1.


  Table 4-1:  Interpretation of the "Bypass" and "Control Command" Flags

_________________________________________________________________________
 Bypass Flag                    Control Command Flag   Interpretation
_________________________________________________________________________
   0             0            Type-AD.  Frame Data Field carries TC data
                               (e.g., Packets or Segments), subject to
                               acceptance check under control of the FARM.
                               These Frames use the Sequence-Controlled
                               (or AD) Service of the COP.
   
   0             1            Reserved for future application.
   
   1             0            Type-BD.  Frame Data Field carries TC data
                               (e.g., Packets or Segments), with all frame
                               acceptance checks bypassed under control of
                               the FARM.  These Frames use the Expedited
                               (or BD) Service of the COP.
   
   1             1            Type-BC.  Frame Data Field carries FARM
                               Control Commands, with all frame acceptance
                               checks bypassed under control of the FARM.
                               These Frames control the Sequence-
                               Controlled Service of the COP.
_________________________________________________________________________
   (4) RESERVED SPARES (Bits 4,5)

       These two bits are reserved for future application.  At present,
       Bits 4,5 shall be set to value "00".

   (5) SPACECRAFT IDENTIFIER (Bits 6 through 15)

       These ten bits carry the identification code for the spacecraft
       being commanded.  The Secretariat of the CCSDS assigns the
       SPACECRAFT IDENTIFIER to each vehicle within a particular mission
       as defined in Reference [10].
The third and fourth octets of the FRAME HEADER contain the following field
       allocations:

   (6) VIRTUAL CHANNEL IDENTIFIER (Bits 16 through 21)

       As described in Section 3, the Transfer layer provides a "Virtual
       Channel" service to the Segmentation layer.  Beneath the Transfer
       layer is the single physical telecommand data channel which is
       provided by the Channel Service (Reference [4]).  The Virtual
       Channel facility allows this single physical channel to be
       logically multiplexed, on a frame-by-frame basis, so that its
       transmission capacity may be shared.

       Every TC Transfer Frame shall have a 6-bit VIRTUAL CHANNEL ID field
       present in the Frame Header.  Each state of the identifier creates
       one Virtual Channel, from VC 0 to VC 63, so that up to 64 different
       logical paths may be defined through the single physical channel.
       The Transfer layer may therefore present up to 64 Virtual Channels
       to the Segmentation layer.

       Each Virtual Channel may also have up to 64 Multiplexer Access
       Points (MAPs) attached to it by the Segmentation layer for the
       purpose of multiplexing user data together.

                                   NOTE

           If multiplexing is not performed in the Segmentation layer
           (i.e., if only one MAP is activated per Virtual Channel) or if
           the Segment Header is omitted for a particular mission, then
           the Virtual Channel feature of the Transfer layer provides an
           alternative method for multiplexing user data onto the physical
           channel.  Using this feature of the Transfer layer, up to 64
           concurrent users may be multiplexed together by attaching each
           to its own dedicated Virtual Channel during transfer through
           the physical channel.  However, since every open Virtual
           Channel has its own CLCW reporting scheme, Virtual Channel
           multiplexing may increase the spacecraft reporting complexity.

       The internal partitioning and use of the Virtual Channel field is
       mission-specified; e.g., some of the bits may be allocated by a
       mission to form a "Spacecraft Sub-ID", which allows different
       spacecraft data handling chains to be addressed.

   (7) FRAME LENGTH (Bits 22 through 31)

       This 10-bit field contains a length count "C" which equals one fewer
       than the total octets in the TC Transfer Frame.  The count is
       measured from the first bit of the FRAME HEADER to the last bit of
       the FRAME ERROR CONTROL FIELD (if present), or the last bit of the
       FRAME DATA FIELD if the error control is omitted.  The size of this
       field limits the maximum length of a TC Transfer Frame to 1024
       octets.  The length count "C" is expressed as:

                    "C" = (Total Number of Octets) - 1

The fifth octet of the FRAME HEADER contains the following field:

   (8) FRAME SEQUENCE NUMBER (Bits 32 through 39)

       The FRAME SEQUENCE NUMBER, which within this Recommendation is
       denoted as N(S), is an up-counting binary number which is assigned
       to each TC Frame by the TC Transfer layer, and which remains a
       viable entity only within this layer.

       The FRAME SEQUENCE NUMBER enables the FARM to check the
       sequentiality of incoming Type-A TC Frames.  The 8-bit FRAME
       SEQUENCE NUMBER field supports a modulo-256 sequence count.

       The FRAME SEQUENCE NUMBER is Virtual Channel dependent;  i.e., the
       Transfer layer shall maintain a separate FRAME SEQUENCE NUMBER for
       each of the (up to 64) VIRTUAL CHANNELS.

Note that the COP does not use this field when operating with Type-B TC
Frames;  in this case the contents of the FRAME SEQUENCE NUMBER field shall
be set to "all zeros".

4.2.1.2   Transfer Frame Data Field.  The FRAME DATA FIELD, which is of
variable length up to a maximum of 1019 octets (1017 octets if the FRAME
ERROR CONTROL FIELD is present), shall contain either an integral number of
octets of telecommand data corresponding to one TC Frame Data Unit or an
integral number of octets of Control Command information.  The FRAME DATA
FIELD shall be inserted directly after the Frame Header with no filler
between.

4.2.1.2.1 TC Frame Data Unit.  The TC Frame Data Unit is supplied by the
Segmentation layer.  The content of a TC Frame Data Unit is defined in
Section 3.3.1.

4.2.1.2.2 Control Commands.  There are two Control Commands defined:
UNLOCK and SET V(R).  The action to be taken when the FARM receives one of
the Control Commands is defined in Reference [7].  All other bit
combinations for Control Commands are reserved by the CCSDS for future
application.

     UNLOCK:  The UNLOCK Control Command consists of a single octet
     containing "all zeroes".

     SET V(R):  The SET V(R) Control Command consists of three octets with
     the following values:

       10000010   00000000   XXXXXXXX

     where XXXXXXXX is the value to which the FARM should set V(R), the
     Receiver_Frame_Sequence_Number.  This octet should therefore be set to
     the Sequence Number which will be put into the Header of the next Type-
     A TC Frame to be transmitted on that Virtual Channel.

4.2.1.3   Transfer Frame Error Control Field.  The purpose of this optional
16-bit field (which occupies the two trailing octets of the TC Frame) is to
provide frame error control information.  The Frame Error Control Field is
used only for error detection, but it is particularly useful when project
requirements dictate an undetected frame error performance that exceeds the
inherent performance provided by the underlying Channel Service.
Performance information is found in Annex B and Reference [2].  If used,
the preferred error control technique is the Cyclic Redundancy Check (CRC)
described in the following sections.

4.2.1.3.1 Encoding Procedure.  The encoding procedure accepts a Transfer
Frame, excluding the Frame Error Control Field, and generates a systematic
binary block code by appending a 16-bit Frame Error Control Word (FECW) as
the final 16 bits of the codeblock.

The equation for the FECW is:

         FECW = [(X**16 . M(X)) + (X**(n-16) . L(X))] modulo G(X)

  where  all arithmetic is modulo 2
  
       M(X)   = the (n-16)-bit message to be encoded expressed as a
                polynomial with binary coefficients
  
       L(X)   = the presetting polynomial given by:
     
                         [GRAPHIC ELEMENT OMITTED]
     
                (i.e., all "1" polynomial of order 15)
     
       G(X)   = the generating polynomial given by:
     
                     G(X) = X**16  + X**12  + X**5 + 1
     
       n      = the number of bits in the encoded message
  
       The X**(n-16) . L(X) term has the effect of presetting the shift
       register to an all "1" state prior to encoding.

A possible implementation of an encoder is described in Reference [2].

4.2.1.3.2 Decoding Procedure.  The entire TC Frame, including the Frame
Error Control field is provided to the decoder.

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

           S(X) = [(X**16 . C*(X)) + (X**n . L(X))] modulo G(X)

where C*(X)  = the received block in polynomial form
 
      S(X)   = the syndrome polynomial, which will be zero if no error
                is detected and non-zero if an error is detected.
  
A possible implementation of a decoder is contained in Reference [2].

4.2.2     COMMAND LINK CONTROL WORD (CLCW) FORMAT

The CLCW, which is a four-octet word that is conveyed in the Operational
Control Field of a CCSDS Telemetry Transfer Frame (Reference [5]) or
Virtual Channel Data Unit (VCDU) (Reference [8]), provides the mechanism by
which the FARM reports the status of frame acceptance to the Frame
Operation Procedure (FOP) at the sending end of the Transfer layer.

                                   NOTE
                                     
   The controlling specification for how the CLCW is used within the COP
   is contained in Reference [7].

The CLCW is the only reporting mechanism for the TC Transfer layer.
Although it is not necessary that the Telemetry reporting rate match the
Telecommand transfer rate, some minimum CLCW sampling rate is necessary for
the proper operation of the COP.

The format of the CLCW is shown in Figure 4-3.


                         [GRAPHIC ELEMENT OMITTED]

               Figure 4-3:  Command Link Control Word Format

The CLCW contains the following fields:

                    Field               Length (Bits)

               CONTROL WORD TYPE          1
               CLCW VERSION               2
               STATUS FIELD               3
               COP IN EFFECT              2
               VIRTUAL CHANNEL ID         6
               RESERVED SPARE             2
               FLAGS:                     5
               - No rf available  (1)
               - No bit lock      (1)
               - Lockout          (1)
               - Wait             (1)
               - Retransmit       (1)
               FARM B COUNTER             2
               RESERVED SPARE             1
               REPORT VALUE               8
                                         32 bits (4 octets)

Unless otherwise stated, all fields are required elements.

  (1) CONTROL WORD TYPE (Bit 0)

     This one-bit field shall be set to zero to indicate that the
      Operational Control Field contains a CLCW.
  
  (2) CLCW VERSION NUMBER (Bits 1,2)
   
     The two-bit CLCW VERSION NUMBER field is included to provide future
      growth flexibility.  However, at present a single "Version-1" CLCW
      format is defined in this Recommendation.  It shall be indicated by
      setting Bits 1,2 to value "00".  The format of the Version-1 CLCW
      report is described herein.
  
  (3) STATUS FIELD (Bits 3,4,5)
  
     Application of this field is mission-specified.  It may be used by
      Agencies or Centers for local enhancements to TC operations and is
      not part of the COP protocol.
  
  (4) COP IN EFFECT (Bits 6,7)
  
     These two bits indicate the COP which is being used.  At present a
      single COP, COP-1, is defined.  It shall be identified by setting
      Bits 6,7 to the binary value "01".
  
  (5) VIRTUAL CHANNEL ID (Bits 8-13)
  
     This field contains the VIRTUAL CHANNEL Identifier of the TC Virtual
      Channel with which this report is associated.  Each Virtual Channel
      which is open shall have its own CLCW reporting activated.
  
  (6) RESERVED SPARES (Bits 14,15)
  
     These two bits are reserved by CCSDS for future application.  For
      the present, Bits 14,15 shall be set to value "00".
  
  (7) FLAGS (Bits 16,17,18,19,20)
  
      (a) NO RF AVAILABLE flag (Bit 16)
      
          The NO RF AVAILABLE flag provides a logical indication of the
          "ready" status of the radio frequency (rf) elements within the
          physical data channel provided by the Channel Service layers.
          Precise definition of the set of physical states which must each
          be in the "ready" condition before commanding is possible is
          mission-specified.  For example, the flag can represent a logical
          sum of the overall ready status of components such as the rf
          transponder and the demodulator.
       
          Whenever Bit 16 is set to value "0", the physical channel is
          AVAILABLE (i.e., any TC Transfer Frame will be received and
          processed by the Channel Service layers and passed on to the
          Transfer layer if correct).
      
          Whenever Bit 16 is set to value "1", the physical channel is NOT
          AVAILABLE and TC Transfer Frames cannot be transferred without
          corrective action within the Channel Service layers.
      
          The single NO RF AVAILABLE flag applies to all Virtual Channels.
          This input parameter to the CLCW is updated whenever a change is
          signaled by the Channel Service.
      
      (b) NO BIT LOCK flag (Bit 17)
      
          The NO BIT LOCK flag is an optional, mission-specific engineering
          measurement which provides a performance quality indicator that
          indicates specifically whether the Channel Service layers are
          working normally by having enough signal energy to achieve bit
          synchronization with the received data stream.  If bit lock is
          not achieved, this may indicate that the Channel Service layers
          are operating at a non-nominal performance level and that the TC
          Frame rejection rate may be correspondingly abnormally high.
       
          When Bit 17 is used and set to value "0", this indicates BIT LOCK
          ACHIEVED.  When Bit 17 is used and set to value "1", this
          indicates NO BIT LOCK ACHIEVED.
      
          This flag is not part of the COP protocol, and may therefore be
          used by Agencies or Centers for local enhancements to TC
          operations.  If not used, it shall be set permanently to value
          "0".
      
          The single NO BIT LOCK flag applies to all Virtual Channels.
          This input parameter to the CLCW is updated whenever a change is
          signaled by the Channel Service.
      
      (c) LOCKOUT flag (Bit 18)
      
          Bit 18 is set to value "1" to indicate LOCKOUT whenever a Type-A
          TC Frame is received on a particular Virtual Channel which
          violates certain frame acceptance checks.  Once the FARM is in
          LOCKOUT, all subsequent Type-A TC Frames are rejected by that
          FARM until the condition is cleared.  The conditions for entering
          and exiting LOCKOUT for the COP are specified in Reference [7].
          If the FARM is not in LOCKOUT, Bit 18 shall be set to value "0".
      
          Necessarily, separate LOCKOUT flags shall be maintained for each
          Virtual Channel.
      (d) WAIT flag (Bit 19)
      
          When Bit 19 is set to value "1", this indicates that the
          receiving end of the Transfer layer is unable to pass data to the
          Segmentation layer on a particular Virtual Channel.  This may be
          caused by temporary lack of storage and/or processing resources
          in the receiving end of the Transfer or higher layers.
      
          When Bit 19 is set to value "1" (i.e., WAIT) for a particular
          Virtual Channel, all further Type-A TC Frames on that channel
          shall be rejected by the FARM until the condition is cleared by
          freeing the congestion, either automatically or by taking
          appropriate control action as defined in Reference [7].
      
          When Bit 19 is set to value "0" (i.e., DON'T WAIT), normal Type-A
          commanding may proceed on that channel.
      
          The precise specifications for use of the WAIT Flag are contained
          in Reference [7].  Necessarily, separate WAIT flags shall be
          maintained for each Virtual Channel.
      
      (e) RETRANSMIT Flag (Bit 20)
      
          The RETRANSMIT flag speeds the operation of the COP by providing
          immediate indication (Bit 20 set to value "1") to the FOP at the
          sending end that one or more Type-A frames on a particular TC
          Virtual Channel have been rejected or found missing by the FARM
          and therefore retransmission is required.  The conditions which
          cause the flag to be set are specified in Reference [7].
      
          When Bit 20 is set to value "0", this indicates that there are no
          outstanding Type-A frame rejections in the sequence received so
          far, and thus retransmissions are not required.
      
          The precise specifications for use of the RETRANSMIT Flag are
          contained in Reference [7].  Necessarily, separate RETRANSMIT
          flags shall be maintained for each Virtual Channel.
       
  (8) FARM-B COUNTER (Bits 21,22)
  
      This field contains the two least significant bits of a FARM-B
      COUNTER.  This counter is maintained within the FARM and increments
      once each time a Type-B TC Transfer Frame is accepted in BYPASS mode
      on a particular Virtual Channel.  The field supports the
      verification that BYPASS mode frames (Control or user Data) were
      accepted by the spacecraft.
   
      Necessarily, separate FARM-B COUNTERs shall be maintained for each
      Virtual Channel.

  (9) RESERVED SPARE (Bit 23)
  
      This bit is reserved by CCSDS for future application.  For the
      present, Bit 23 shall be set to value "0".
  
  (10)    REPORT VALUE (Bits 24-31)
  
      This field, which shall always be one octet long, contains the value
      of "N(R)", i.e., the current observed value of the FARM's NEXT
      EXPECTED FRAME SEQUENCE NUMBER V(R).  The FARM V(R) counter shall
      increment once each time a Type-AD TC Frame is accepted on a
      particular Virtual Channel.
  
      The precise specifications for use of the REPORT VALUE are contained
      in Reference [7].  Necessarily, separate counters shall be
      maintained for each Virtual Channel.

4.3  STANDARD PROCEDURES WITHIN THE LAYER

Standard procedures within the Transfer layer are concerned with the
following operations:

   (1) At the receiving end of the system, reconstituting TC Frames from
       the data stream provided by the Channel Service Coding layer and
       removing any Fill Data transferred from that layer.

   (2) At the receiving end of the system, performing standard "Frame
       Validation Checks" on all TC Frames reconstituted from the Coding
       layer.

   (3) At both ends of the system, executing the Command Operation
       Procedure which is used to move TC Frames across the Transfer
       layer, including performing frame acceptance checks and
       establishing and using various counters, numbers and windows.

4.3.1     FRAME DELIMITING AND FILL REMOVAL PROCEDURE

The Telecommand Channel Service (Reference [4]) resides immediately below
the Transfer layer.  At the sending end of the TC System, the Transfer
layer passes one or more TC Frames to the Channel Service Coding layer,
which encodes the frames to protect them from errors which may be
introduced as they are transmitted through the physical channel.  Fill Data
may have to be inserted by the Channel Service to ensure correct
transmission of all valid data.

The receiving end of the Transfer layer receives as an input from the
Coding layer a series of data octets, corresponding to the decoded
frame(s), which have been declared "clean" by the Coding layer insofar as
they contain no detected errors.  The Coding layer provides a "Data Start"
signal to the Transfer layer, indicating that data are being transferred.

The Data Start signal shall be set TRUE while the Coding layer is in the
process of actively transferring data octets.  Since the first octet
transferred after Data Start goes TRUE corresponds to the first octet of
the first TC Transfer Frame, the receiving end of the Transfer layer may
delimit this frame-and each of any successive TC Transfer Frames-by reading
the FRAME LENGTH field in the first header, and then successively reading
the FRAME LENGTH field in each subsequent header.

The Data Start signal shall become FALSE (indicating "Data Stop") when the
Coding layer stops transferring octets because of a decoder failure or
channel deactivation.  Decoding failure may be caused by the normal end of
the transmitted TC Frame(s), or by a genuine channel-induced error.

If one or more valid FRAME LENGTH fields are detected by the receiving end
of the Transfer layer and the number of octets received when the Data Stop
condition occurs equals the number of octets specified by the FRAME
LENGTH(s), then each Frame shall be passed on to the Frame Validation Check
procedure (see 4.3.2) as it is delimited.

If a valid FRAME LENGTH field is detected by the receiving end of the
Transfer layer but the number of octets received when the Data Stop
condition occurs is less than the number of octets specified by that FRAME
LENGTH, this entire Frame shall be discarded since this indicates that a
failure has occurred, possibly due to a channel error detected during
reception of the data stream within the Channel Service layers below.

If a valid FRAME LENGTH field is detected by the receiving end of the
Transfer layer but the number of octets received when the Data Stop
condition occurs is greater than the number of octets specified by that
FRAME LENGTH, Fill Data was probably appended by the sending end Coding
layer to complete the last TC Codeblock (Reference [4]).  Because the
receiving end Coding layer cannot distinguish between valid data and Fill
Data, the Fill Data must be stripped by the Transfer layer.

The characteristics of the present TC Codeblock structure are such that no
more than six octets of Fill Data can occur.  If LESS THAN FIVE trailing
octets of Fill Data are present, then they cannot possibly form a Frame
Header, and they will be immediately discarded by the Transfer layer.  If
FIVE OR SIX trailing octets of Fill Data exist, the Transfer layer data
handling process might attempt to interpret the Fill Data as a new Transfer
Frame Header;  however, the subsequent Frame Validation Check (see 4.3.2)
will prevent this from happening because the Fill pattern of "01010101"
appearing in each octet will violate at least one of the validation tests;
in particular, this pattern appearing where the FRAME LENGTH field might be
expected will indicate a frame length that exceeds the number of octets
received from the Coding layer, thus failing a test and causing the
trailing five or six octets to be discarded.


4.3.2     FRAME VALIDATION CHECK PROCEDURE

After each TC Transfer Frame is reconstituted from the string of octets
provided by the Coding layer, it will next be subjected to a set of
standard tests called a "Frame Validation Check".  The Frame Validation
Check shall be applied to ALL incoming TC Transfer Frames, regardless of
whether they are Type-A or Type-B.  Failure to pass any test within the
Frame Validation Check shall cause the Transfer Frame to be rejected
(discarded).  The Frame Validation Check consists of the following tests:

   (1) The TC Frame must have an expected VERSION NUMBER.
   
   (2) The TC Frame must have the expected SPACECRAFT ID.
   
   (3) The TC Frame Header must not contain any values which are not
       consistent with the implemented features for that spacecraft.
   
   (4) The value of the FRAME LENGTH must be consistent with the number of
       octets that are present.
   
   (5) If implemented, the FRAME ERROR CONTROL test must pass.
   
   (6) The Data Field of a TC Frame containing a Control Command must be
       consistent with the allowed Control Commands.


4.3.3     COMMAND OPERATION PROCEDURE (COP)

The Command Operation Procedure fully specifies the closed-loop protocols
executed by the sending and receiving ends of the Transfer layer of the TC
System.  The COP, which exists wholly within the Transfer layer, consists
of a pair of synchronized procedures for each Virtual Channel:  a Frame
Operation Procedure (FOP) that executes within the sending entity; and a
Frame Acceptance and Reporting Mechanism (FARM) that executes within the
receiving entity.  The sending FOP transmits TC Frames to the receiving
FARM.  The FARM returns telemetered Command Link Control Words (CLCWs) to
the FOP and thus closes the loop by providing reports of the status of
frame acceptance.

The COP provides a basic Quality Of Service (QOS) within the Transfer layer
that is central to the operation of the TC System, i.e., the delivery of
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.

Only one COP is defined in this Recommendation:  COP-1.

                               C A U T I O N

THE CONTROLLING SPECIFICATIONS FOR THE LOGICAL OPERATIONS WHICH MUST BE
EXECUTED TO PERFORM THE COP ARE CONTAINED IN A MORE DETAILED CCSDS
RECOMMENDATION (REFERENCE [7]).  IN THE EVENT OF ANY CONFLICT BETWEEN THE
DESCRIPTIVE TEXT CONTAINED IN THIS RECOMMENDATION AND THE TEXT OF REFERENCE
[7], THE MORE DETAILED SPECIFICATIONS CONTAINED IN REFERENCE [7] SHALL
PREVAIL.

Underlying the Transfer layer is the physical telecommand data channel
which interconnects its sending and receiving ends.  If a perfect data
channel existed, the QOS would be assured since the exact duplicate of the
series of data units which was input to the sending end would appear at the
receiving end.  However, space data channels are noisy and may introduce
errors or discontinuities into transmitted data streams.  The job of the
COP within the Transfer layer is therefore to ensure the correctness,
completeness and sequentiality of the delivered data units, in the presence
of such errors or discontinuities introduced by the layer below.

Correctness of the delivered data units is guaranteed (within known error
probabilities) by means of the error-protection encoding applied by the
Channel Service, and by the Frame Validation Check performed by the
Transfer layer.  However, validation of the completeness, sequentiality and
non-duplication of the delivered data units on a particular Virtual Channel
requires that a frame accounting (i.e., numbering) scheme be implemented by
the COP.

FARM-1 permits Type-AD frames to be accepted only if they are received
bearing absolute FRAME SEQUENCE NUMBERS which are in the proper up-counting
sequential order;  upon detection of the first frame sequence error, the
FARM will reject all subsequent Type-AD frames on that Virtual Channel
which do not contain the expected FRAME SEQUENCE NUMBER, and the FOP must
go back n frames and resume sequential retransmission by repeating all
unacknowledged Type-AD frames.

Type-BC frames are used to send Control Commands to the FARM.  Type-BD
frames are processed by the COP only to the extent of causing the FARM to
increment the FARM-B COUNTER in the CLCW.


















                                  ANNEX A

                           DATA ROUTING 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 Segmentation and
Transfer Layers.




                                     
                                     
                                     
                                     
                                 ACRONYMS


A:         ACCEPTANCE CHECK MODE
B:         BYPASS MODE
CCSDS:     CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS
CLCW:      COMMAND LINK CONTROL WORD
COP:       COMMAND OPERATION PROCEDURE
COP-1:     COMMAND OPERATION PROCEDURE #1
CTRL:      CONTROL
FARM:      FRAME ACCEPTANCE AND REPORTING MECHANISM
FARM-1:    FARM PART OF COP-1
FOP:       FRAME OPERATION PROCEDURE
FOP-1:     FOP PART OF COP-1
ID:        IDENTIFIER
MAP:       MULTIPLEXER ACCESS POINT
MSB:       MOST SIGNIFICANT BIT
N(R):      THE OBSERVED VALUE OF V(R) CONTAINED IN ONE CLCW
N(S):      TRANSMITTED FRAME SEQUENCE NUMBER
QOS:       QUALITY OF SERVICE
RF or rf:  RADIO FREQUENCY
TC:        TELECOMMAND
TF:        TRANSFER FRAME
VC:        VIRTUAL CHANNEL
V(R):      RECEIVER_FRAME_SEQUENCE_NUMBER
                                     
                                     
                                     
                                     
                                TERMINOLOGY

CODING LAYER:

The top layer of the Channel Service, specified in Reference [4].  This is
the layer immediately below the Transfer layer.

COMMAND LINK CONTROL WORD (CLCW):

The CLCW is the protocol data unit for TC reporting via telemetry from the
FARM back to the FOP.  The CLCW resides wholly within the Transfer layer,
though it does include a few parameters describing the readiness state of
lower layers, which aid the efficient operation of the COP.  The CLCW does
not perform any reporting service for the Segmentation layer.

COMMAND OPERATION PROCEDURE (COP):

A sequence of procedural activities designed to assure the reliable, error-
controlled delivery of a TC Transfer Frame across the Transfer layer.  The
COP consists of a Frame Operation Procedure (FOP) operating within the
sending end of the layer and a Frame Acceptance and Reporting Mechanism
(FARM) operating within the receiving end of the layer.

COP-1 = Sequential acceptance and retransmission with frame sequence
numbering.

CONTROL COMMAND:

A special Type-B TC Frame which carries control instructions in its Data
Field to set up the internal operating parameters of the FARM.

CONTROL INSTRUCTION:

Information that is required to set up a TC System layer to support the
handling of telecommands.

DATA START:

A signal from the Coding layer which becomes "true" to notify the Transfer
layer that valid decoded data octets are being transferred.

DATA STOP:

A signal from the Coding layer corresponding to Data Start becoming
"false", which notifies the Transfer layer that no more valid data octets
are being transferred by the layer below.

FARM-B COUNTER:

A counter, reported in the CLCW, which increments once for every Type-B
frame that is accepted by the FARM on a particular Virtual Channel.

FILL DATA:

Extra trailing octets of meaningless data added by the sending end Coding
layer to complete the last TC Codeblock.  Because information in the TC
Transfer Frame is needed by the receiving end to determine how much Fill
Data has been added, Fill Data must be removed by the receiving end
Transfer layer, not by the receiving end Coding layer.

FRAME ACCEPTANCE AND REPORTING MECHANISM (FARM):

The FARM is the set of procedures executed by the receiving end of the
Transfer layer to decide whether to accept a TC Transfer Frame and how to
report operation and status back to the FOP via Command Link Control Words.

FRAME OPERATION PROCEDURE (FOP):

The FOP is the procedure executed by the sending end of the Transfer layer
to transmit a TC Transfer Frame.  The FOP conducts a transfer sequence
using the communication services of the underlying TC Channel Service.
Actions of the FOP are dictated by the rules of the COP and the FARM status
information passed back to it via the telemetered Command Link Control Word
(CLCW).

FRAME SEQUENCE NUMBER N(S):

The up-counting absolute number that is placed into each Type-A TC Frame.

FRAME VALIDATION CHECK:

A set of common integrity and quality tests to which ALL TC Transfer Frames
are first subjected when they are processed by the receiving end of the
Transfer layer.

LOCKOUT:

A condition whereby the FARM has detected a severe sequentiality anomaly
and rejects all subsequent Type-A frames until reset by a Type-B UNLOCK
Control Command.

MULTIPLEXER ACCESS POINT (MAP):

A MAP is a mechanism provided within the Segmentation layer to allow
different user data structures to be multiplexed together for transmission
on one Virtual Channel provided by the Transfer layer.  Multiplexing allows
user data structures with different delivery priorities to share the same
Virtual Channel and thus provides flow control.

NEXT EXPECTED FRAME SEQUENCE NUMBER N(R):

The observed current value of V(R) that is telemetered from the FARM to the
FOP via each CLCW.
PACKETIZATION LAYER:

The bottom layer of the Data Management Service, specified in Reference
[3].  This is the layer immediately above the Segmentation layer.

RECEIVER_FRAME_SEQUENCE_NUMBER V(R):

The value of the Frame Sequence Number, N(S), which the FARM expects to see
in the next Type-A frame in order to preserve up-counting sequence.

RETRANSMIT:

A flag indication from the FARM, contained in a CLCW, that at least one
Type-A frame has been rejected and that retransmission is required from the
FOP.

SEGMENTATION LAYER:

The top layer of the Data Routing Service, which interfaces user data
structures with the protocols used during transfer to the receiving
spacecraft.

TELECOMMAND FRAME DATA UNIT (TC FRAME DATA UNIT)

The data unit generated by the Segmentation layer to be placed in the data
field of the TC Transfer Frame which will convey the data to the
spacecraft.  It will consist of a TC Segment, one or more complete TC
Packets or a single TC User Data Unit.

TELECOMMAND SEGMENT (TC SEGMENT):

The protocol data unit of the TC Segmentation layer.  A TC Segment consists
of a Segment Header and Segment Data Field.

TELECOMMAND TRANSFER FRAME (TC TRANSFER FRAME or TC FRAME):

The protocol data unit of the Transfer layer.  TC Transfer Frames contain a
Frame Header, a Frame Data Field, and an optional Frame Error Control
Field.  The Data Field carries either a TC Frame Data Unit (e.g., a TC
Segment or TC Packet(s)) or a Control Command, which establishes the
internal operations of the Transfer layer.

TELECOMMAND USER DATA UNIT (TC USER DATA UNIT):

A finite-length user data structure provided by the layers above to be
carried from the ground to the spacecraft.  If the layer above the
Segmentation layer is the Packetization layer, the TC User Data Unit will
be a TC Packet.  If the layers above the Segmentation layer do not conform
to the CCSDS telecommand architecture, the TC User Data Unit may be any
other higher-layer user data structure.  Certain services of the
Segmentation layer are provided only for TC Packets.

TRANSFER LAYER:

The bottom layer of the Data Routing Service, which performs the transfer
of user data structures to the receiving spacecraft.

TYPE-A (ACCEPTANCE MODE) FRAMES:

TC Transfer Frames which have a flag set indicating that they are to be
tested against the Frame Acceptance Check.

TYPE-B (BYPASS MODE) FRAMES:

TC Transfer Frames which have a flag set indicating that they are NOT to be
tested against the Frame Acceptance Check, but should be delivered as soon
as they pass the Frame Validation Check.

UNLOCK:

A Type-B Control Command which resets a FARM LOCKOUT condition.

VIRTUAL CHANNEL (VC):

Virtual Channels are provided by the Transfer layer, which interfaces with
the single physical channel in the layers below and presents the service of
apparently separating this single channel into multiple "virtual" paths to
the Segmentation layer.

A Virtual Channel (VC) is simply a unique, multi-bit ID code assigned to a
particular sequence of TC Transfer Frames to enable all the frames which
are members of that sequence to be identified.  When different Virtual
Channel IDs are assigned to different TC Transfer Frame sequences, the
sequences can be multiplexed onto the physical channel at the sending end
and then sorted at the receiving end back into their proper parent
sequences.  Necessarily, when Virtual Channels are not used, the physical
channel in concept is the same as one Virtual Channel.  Virtual Channels
provide an alternative method for multiplexing user data structures if the
multiplexing feature of the Segmentation layer is not used.

WAIT:

An indication from the FARM, contained in a CLCW, that the receiving end of
the Transfer layer has encountered congestion in passing data to the layer
above and cannot accept any more Type-A frames.


















                                  ANNEX B

                    DATA ROUTING SERVICE SPECIFICATION




                (THIS ANNEX IS PART OF THE RECOMMENDATION)





                                 Purpose:

This Annex provides the detailed specification of the service provided by
the Segmentation and Transfer layers.








B-1    OVERVIEW OF THE LAYERS WITHIN THE DATA ROUTING SERVICE

The Data Routing Service is implemented using two layers of protocol:  the
Segmentation layer and the Transfer layer.  The function of the
Segmentation layer is to prepare user telecommand messages for transmission
to the spacecraft, using services of the Transfer layer, by forming them
into TC Frame Data Units.  The function of the Transfer layer is to
reliably move Transfer Frames from the sending end of the Telecommand
System to the receiving end, using the Channel Service, including
retransmission of any frames which were found by the receiving end to have
been damaged or lost during transfer.

A diagram defining the principal elements within the Data Routing Service
is presented in Figure B-1.

Higher-layer TC User Data Units (e.g., TC Packets) may range in length from
very short units to very long ones.  The characteristics of the physical
data channel which interconnects the sending and receiving end of the
system are such that the most effective method of transmission requires
intermediate length (up to 8 k bit) data structures (see Reference [2]).
Furthermore, since this physical data channel has a finite data-carrying
capacity, a method must be provided to prevent one user from monopolizing
the channel to the exclusion of others.  The task of the Data Routing
Service is therefore to provide the transformation between the
characteristics of the user layers of the TC System and the constraints of
the physical channel, including breaking large user messages into smaller
communications-oriented pieces or aggregating very small user messages into
larger pieces and multiplexing these pieces to provide responsive virtual
access to the channel for all users.

A "TC Segment" is the specific form of the "TC Frame Data Unit" containing
a Segment Header.

B-2    TC SEGMENTATION LAYER SERVICE SPECIFICATION

The services provided by the Telecommand Segmentation layer are as follows:

   (1) The layer breaks long user data structures from the layer above
       (i.e., TC Packets, or other user data structures which have been
       generated by a non-standard higher layer) into pieces ("TC Frame
       Data Units") which will fit the data field of TC Transfer Frames,
       and reassembles them after passage through the Transfer layer.
   
   (2) The layer optionally aggregates multiple TC Packets into a single TC
       Frame Data Unit, which fits into the data field of a TC Transfer
       Frame and separates them after passage through the Transfer layer.
   
   (3) The layer provides a mechanism for multiplexing different TC Frame
       Data Units together onto a single Virtual Channel, for the purpose
       of flow control.

The Segmentation service described in this Recommendation is designed to
support the standard CCSDS telecommand Packetization layer (Reference [3]).
It can also provide services to other non-standard higher-layer TC
processes as long as the interface requirements of the Segmentation layer
are satisfied.


                         [GRAPHIC ELEMENT OMITTED]

               Figure B-1:  TC Data Routing Service Elements




B-2.1  Segmentation Layer:  Sending End Service Specification

   (1) INPUTS

       From the Packetization layer or other layer above:

       (a) Transportable TC User Data Units (e.g., TC Packets) which are to
           be routed to the spacecraft.  The length of the TC User Data
           Unit is unconstrained; however, if they are TC Packets, then
           each will have a maximum length of 65542 octets.
       
       (b) Control instructions which are required in order to transfer the
           user data structures to the spacecraft.  Those control
           instructions specifying delivery priority are read and
           processed by the Segmentation layer and establish the
           multiplexing hierarchy within this layer.  Other control
           instructions (e.g., directives to abort specific commands) are
           passed through to the layer below.
       
          NOTE: The abstract content and concrete format of the control
                 instructions are not presently specified and remain an
                 item for potential future extension.
       
       From the receiving end of the Segmentation layer:

       None.

       From the Transfer layer below:

       (c) Information describing the status of transfer of TC Frame Data
           Units through a given Virtual Channel.

   (2) OUTPUTS

       To the Packetization layer or other layer above:

       (a) Information describing the status of transfer of TC User Data
           Units.

       To the receiving end of the Segmentation layer:

       None.





       To the Transfer layer below:

       (b) User data structures which have been formed into TC Frame Data
           Units.
       
       (c) Control instructions, possibly passed through from the layer
           above.

   (3) INTERNAL FUNCTIONS

       (a) Assigns individual TC User Data Units to particular Multiplexer
           Access Points (MAPs) for routing to the spacecraft through a
           Virtual Channel (VC) provided by the Transfer layer.
       
       (b) Breaks or aggregates the TC User Data Units into pieces which
           are compatible with insertion into the data field of the TC
           Frame Data Unit.
       
       (c) Optionally labels each piece with sequence control and MAP
           identification information to create a TC Segment.  The TC
           Segment or the piece from (b), if the Segment Header is not
           used, becomes the TC Frame Data Unit.
       
       (d) Multiplexes TC Frame Data Units from different MAPs together
           onto one Virtual Channel for flow control purposes.
       
       (e) Monitors the process of transferring TC Frame Data Units through
           Virtual Channels by the layers below, and maintains cognizance
           of the status and availability of particular Virtual Channels.


B-2.2  Segmentation Layer:  Receiving End Service Specification

   (1) INPUTS

       From the Packetization layer or other layer above:

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

       From the sending end of the Segmentation layer:

       None.

       From the Transfer layer below:

       (b) TC Frame Data Units in sequence and complete, without omission
           or duplication (if sent as Type-A Frames).





   (2) OUTPUTS

       To the Packetization layer or other layer above:

       (a) Reconstructed User Data Units.

       To the sending end of the Segmentation layer:

       None.

       To the Transfer layer below:

       (b) Information concerning the ability of the Segmentation layer to
           accept more data.

   (3) INTERNAL FUNCTIONS

       (a) Receives TC Frame Data Units from the Transfer layer, delivered
           on individual Virtual Channels.
       
       (b) Sorts TC Frame Data Units associated with individual VCs
           according to their MAP identifier and reassembles the Segments
           associated with a particular MAP to reconstruct the TC User
           Data Unit.
       
       (c) Determines when all TC Segments associated with a particular TC
           User Data Unit have been received correctly.
       
       (d) Extracts the TC Packets.
       
       (e) Passes the reconstructed TC User Data Units to the Packetization
           layer or other higher layer.


B-3    TC TRANSFER LAYER SERVICE SPECIFICATION

The service provided by the TC Transfer Frame layer is to encapsulate Data
Units within a suitable data structure, the TC Transfer Frame, for
transmission through the physical channel which interconnects the sending
and receiving ends of the TC System, and to reliably convey them without
detected error from the sending to the receiving ends of the layer.

Efficient telecommand operation can usually be achieved when the Channel
Service (Reference [2]) rejects less than 1 frame per 10**3 frames
transmitted.  To achieve the performance required for a particular mission,
an acceptable combination of Channel Service parameters (e.g., codeblock
decoding method, number of contiguous TC Codeblocks, error characteristics
of the physical layer) must be selected.  Information on the frame
rejection performance is given in Reference [2].

Project operations are compromised by undetected frame errors.  The
selected Channel Service parameters not only control the frame rejection
rate but also dictate the inherent undetected frame error rate. If the
undetected frame error rate provided by the Channel Service is inadequate
for a project's needs, the Cyclic Redundancy Check described in sec 4.2.1.3
should be applied to the transfer frame to bring this error rate into
conformance. Information on undetected frame error performance is given in
Reference [2].

B-3.1  Transfer Layer:  Sending End Service Specification

   (1) INPUTS

       From the Segmentation layer above:

       (a) TC Frame Data Units.
       
       (b) Control instructions, Management Directives and Data Transfer
           Requests for the FOP.  (See Reference [7] for details.)
       
       From the receiving end of the Transfer layer:

       (c) Information concerning the status of receipt of individual TC
           Frames, formatted into a Command Link Control Word (CLCW) and
           extracted from the Telemetry Transfer Frame (Reference [5]) or
           the Virtual Channel Data Unit (Reference [8]).

       From the Coding layer below:

       (d) Status of the physical channel.

   (2) OUTPUTS

       To the Segmentation layer above:

       (a) Status of the data routing process, including the progress of
           delivering individual TC Frame Data Units and the availability
           of Virtual Channels.

       To the receiving end of the Transfer layer:

       (b) "Control Command" TC Transfer Frames, which instruct the
           receiving end how to accept and report the received frames.

       To the Coding layer below:

       (c) Buffers of TC data bits containing protocol data units from the
           TC Transfer layer (i.e., one or more TC Transfer Frames).
       
       (d) Control instructions defining the operational procedures to be
           used to transmit the buffer of bits to the spacecraft.

   (3) INTERNAL FUNCTIONS

       (a) Encapsulates TC Frame Data Units into TC Transfer Frames.
       
       (b) Translates control instructions received from layers above into
           the appropriate set of operational procedures to be used to
           transfer the TC Transfer Frames to the spacecraft, including
           selection of the correct mode (Acceptance Test or Bypass) of
           the Command Operation Procedure (COP).
       
       (c) Creates Control Command TC Transfer Frames for transmission to
           the receiving end of the layer in order to control the Frame
           Acceptance and Reporting Mechanism (FARM).
       
       (d) Supervises the transfer of TC Transfer Frames to the receiving
           end by executing a Frame Operation Procedure (FOP) in
           accordance with the selected mode of the COP.
       
       (e) Retransmits TC Frames as required to rectify channel-induced
           errors.
       
       (f) Responds to control instructions from layers above to abort
           command transmission by issuing the appropriate set of control
           instructions to the layer below.


B-3.2  Transfer Layer: Receiving End Service Specification

   (1) INPUTS

       From the Segmentation layer above:

       (a) Information defining the ability of the Segmentation layer to
           accept more data (optional).
       
       From the sending end of the Transfer layer:

       (b) Control Command TC Transfer Frames which contain instructions
           defining how the data-carrying TC Transfer Frames are to be
           processed.

       From the Coding layer below:

       (c) "Clean" octets of decoded TC data.  (Note: only correct data,
           which have passed the decoder quality check, will normally be
           received.)
       
       (d) "Data Start" signal (indication of the start of the first valid
           octet of TC data).
       
       (e) "Data Stop" signal (indication of the last valid octet of TC
           data).  (Note: trailing octets of Fill Data could be present
           just before the Data Stop signal is received.)
       
       (f) Control information describing the status of the physical
           channel (e.g., rf and bit synchronization).

   (2) OUTPUTS

       To the Segmentation layer above:

       (a) TC Frame Data Units which have been extracted from TC Transfer
           Frames that passed the validation and, optionally, the
           acceptance tests.

       To the sending end of the Transfer layer:

       (b) CLCWs which will be utilized by the FOP to control the
           transmission of additional TC Transfer Frames, or the
           retransmission of previously sent frames, in accordance with
           the rules of the COP.

       To the Coding layer below:

       None.

   (3) INTERNAL FUNCTIONS

       (a) Responds to Control Command TC Transfer Frames received from the
           sending end of the layer.
       
       (b) Performs the Frame Validation Check Procedure for all TC
           Transfer Frames and the frame acceptance checks of the Frame
           Acceptance and Reporting Mechanism for Type-A Frames.
       
       (c) Creates reports (CLCWs) to the sending end describing the status
           of TC Transfer Frame acceptance.
       
       (d) Processes TC Transfer Frames which have been retransmitted as
           required to rectify channel-induced errors.
       
       (e) Extracts TC Frame Data Units.
       
       (f) Passes the extracted TC Frame Data Units to the Segmentation
           layer.
       
       (g) Responds to control instructions from layers below to abort
           command transmission by ceasing the processing of the current
           TC Transfer Frame, and awaiting new control instructions.