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.1             |
                    |   COMMAND OPERATION PROCEDURES   |
                    |                                  |
                    +-----------------------------------+



                              CCSDS 202.1-B-1

                                 BLUE BOOK


                               OCTOBER 1991




                                 AUTHORITY



                *******************************************
                *   Issue:     Blue Book, Issue 1         *
                *   Date:      October 1991               *
                *   Location:  CCSDS Management Council   *
                *              Orlando, Florida           *
                *              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    Centre National d'Etudes Spatiales (CNES)/France
o    Deutsche Forschungsanstalt fO(u,)r Luft- und Raumfahrt (DLR)/Germany
o    European Space Agency (ESA)/Europe
o    Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil
o    National Aeronautics and Space Administration (NASA)/USA
o    National Space Development Agency of Japan (NASDA)/Japan
o    Central Research Institute of Machine Building (TsNIIMash)/USSR

The following observer Agencies also concur with this Recommendation:

o    Australian Space Office (ASO)/Australia
o    Central Research Institute of Physics (CRIP)/Hungary
o    Chinese Academy of Space Technology (CAST)/People's Republic of China
o    Danish Space Research Institute (DSRI)/Denmark
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
     Communications and Data Systems Division (Code-OS)
     National Aeronautics and Space Administration
     Washington, DC  20546
     USA




                            STATEMENT OF INTENT


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

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

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

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

     --   The STANDARD itself

     --   The anticipated date of initial operational capability

     --   The anticipated duration of operational service

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

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




                                 FOREWORD


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

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

The Recommendation for Telecommand, Part 2:  Data Routing Service
(Reference [3]) defines the standard data structures and data communication
procedures within the intermediate telecommand system layers to be used by
conventional missions.  The Command Operation Procedure forms a subpart of
the Data Routing Service, which is described in Reference [3].  This
Recommendation contains the definition of the Command Operation Procedure
in the form of state tables at the level of detail necessary to allow cross
support.  It is assumed that the reader is familiar with the terminology
and data structures defined in Reference [3].

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/
                                                    Remarks

CCSDS 202.1-B-1 Recommendation for      October   Original
                Space                   1991      Issue
                Data System
                Standards.
                Telecommand, Part
                2.1: Command
                Operation Procedures,
                Issue 1









                                 CONTENTS


Sections                                                     Page

     REFERENCES                                              vii

1    INTRODUCTION                                            1-1

     1.1  PURPOSE AND SCOPE                                  1-1
     1.2  APPLICABILITY                                      1-1
     1.3  STATE TABLE FORMAT                                 1-2
     1.4  INTERLAYER INTERFACES                              1-3

2    COP-1                                                   2-1

     2.1  SERVICES AND PROTOCOLS                             2-1
          2.1.1     Services                                 2-2
               2.1.1.1   Sequence-Controlled Service         2-1
               2.1.1.2   Expedited Service (BD Service)      2-3
          2.1.2     Protocols                                2-4
               2.1.2.1   At the Sending End:  FOP-1          2-4
               2.1.2.2   At the Receiving End:  FARM-1       2-4
     2.2  INTERNAL VARIABLES                                 2-5
          2.2.1     FOP-1 Variables                          2-5
               2.2.1.1   State                               2-5
               2.2.1.2   Stored_Lockout_Flag                 2-6
               2.2.1.3   Stored_Wait_Flag                    2-7
               2.2.1.4   Stored_Retransmit_Flag              2-7
               2.2.1.5   Transmitter_Frame_Sequence_Number,
                         V(S)                                2-7
               2.2.1.6   Wait_Queue                          2-7
               2.2.1.7   To_Be_Retransmitted_Flag            2-7
               2.2.1.8   AD_Out_Flag, BC_Out_Flag,
                         and BD_Out_Flag                     2-7
               2.2.1.9   Sent_Queue                          2-8
               2.2.1.10  Expected_Acknowledgement_Frame_
                         Sequence_Number (NN(R))             2-8
               2.2.1.11  Timer_Initial_Value (T1_Initial)    2-8
               2.2.1.12  Transmission Count Variables        2-9
               2.2.1.13  Suspend_State (SS)                  2-11
               2.2.1.14  FOP_Sliding_Window_Width (K)        2-11
          2.2.2     FARM-1 Variables                         2-11
               2.2.2.1   State                               2-12
               2.2.2.2   Lockout_Flag                        2-12
               2.2.2.3   Wait_Flag                           2-12
               2.2.2.4   Retransmit_Flag                     2-12
               2.2.2.5   FARM-B_Counter                      2-13
               2.2.2.6   Receiver_Frame_Sequence_Number V(R) 2-13
               2.2.2.7   FARM Sliding Window Variables       2-13
               2.2.2.8   FARM_Sliding_Window_Width (W)       2-14
               2.2.2.9   FARM_Positive_Window_Width (PW) and
                         FARM_Negative_Window_Width (NW)     2-15
               2.2.2.10  Buffer Administration Variables     2-17
     2.3  COP-1 INTERFACE TO HIGHER LAYER                    2-17
          2.3.1     Sending End                              2-17
               2.3.1.1   Sequence-Controlled Service
                         Management Interface                2-18
               2.3.1.2   Sequence-Controlled Service FDU
                         Transfer Interface                  2-23
               2.3.1.3   Expedited Service Interface         2-25
          2.3.2     Receiving End                            2-26
     2.4  COP-1 INTERFACE TO LOWER LAYER                     2-27
          2.4.1     Sending End                              2-27
               2.4.1.1   From FOP-1 to Frame Generation      2-27
               2.4.1.2   From Frame Generation to FOP-1      2-28
          2.4.2     Receiving End                            2-28
               2.4.2.1   From the Frame Validation Check
                         to FARM-1                           2-28
               2.4.2.2   From FARM-1 to the Frame Validation
                         Check                               2-28
     2.5  ACTIONS   2-28
          2.5.1     FOP-1                                    2-28
          2.5.2     FARM-1                                   2-32

Annexes                                                      Page

A    COMMAND OPERATION PROCEDURES GLOSSARY                   A-1
B    COMMAND OPERATION PROCEDURES INTERLAYER INTERFACES      B-1

Figures                                                      Page

1-1  State Table Format                                      1-2
2-1  COP-1 Variables, Frame and Report Values                2-3
2-2  FARM Sliding Window Concept                             2-14
2-3  FOP-1 State Transitions:  Main Protocol                 2-41
2-4  FOP-1 State Transitions:  Initialisation Protocol       2-42
2-5  FOP-1 State Transitions                                 2-43
2-6  FARM-1 State Transitions                                2-46
B-1  Interlayer Interfaces                                   B-2

Tables                                                       Page

2-1  FOP-1 State Table                                       2-34
2-2  FARM-1 State Table                                      2-44




                                REFERENCES


[1]  "Procedures Manual for the Consultative Committee for Space Data
     Systems", CCSDS A 00.0-Y-4.0, Issue 4, Yellow Book, Consultative
     Committee for Space Data Systems, September 1990 or later issue.

[2]  "Telecommand, Part 1:  Channel Service", Recommendation CCSDS 201.0-B-
     1, Issue 1, Blue Book, Consultative Committee for Space Data Systems,
     January 1987 or later issue.

[3]  "Telecommand, Part 2:  Data Routing Service", Recommendation CCSDS
     202.0-B-1, Issue 1, Blue Book, Consultative Committee for Space Data
     Systems, January 1987 or later issue.

[4]  "Telecommand, Part 3:  Data Management Service", Recommendation CCSDS
     203.0-B-1, Issue 1, Blue Book, Consultative Committee for Space Data
     Systems, January 1987 or later issue.

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

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

This Recommendation contains the detailed specification of the logic
required to carry out Command Operation Procedure-1 (COP-1) of the Transfer
Layer.

The Recommendation for Telecommand, Part 2:  Data Routing Service,
(Reference [3]) contains the standard data structures and data
communication procedures used by the intermediate telecommand system layers
(the Transfer and Segmentation Layers).  In particular, it contains a brief
description of the Command Operation Procedure (COP) within the Transfer
Layer.  This Recommendation contains the detailed definition of COP-1 in
the form of state tables, along with definitions of the terms used.  It is
assumed that the reader of this document is familiar with the data
structures and terminology of Part 2.

In case of conflict between Part 2 (Reference [3]) and this Recommendation,
this Recommendation will take precedence.


1.2    APPLICABILITY

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

The CCSDS has developed a layered concept for future spacecraft
telecommanding, which is summarized in Telecommand, Summary of Concept and
Service (Reference [5]) and defined in the Recommendation for Telecommand,
Part 1:  Channel Service (Reference [2]), Part 2:  Data Routing Service
(Reference [3]), and Part 3:  Data Management Service (Reference [4]).
Standard services are defined within each layer, and Agencies will be
encouraged to develop corresponding facilities to provide these services in
support of Projects.  This Recommendation is applicable only to those
Projects that are compatible with the Transfer Layer as defined in Part 2.

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  STATE TABLE FORMAT

This document contains the state tables for the Telecommand Command
Operation Procedure (TC COP).  For the Frame Operation Procedure (FOP) or
Frame Acceptance and Reporting Mechanism (FARM), the state table shows the
various "states" (columns) in which the process might be at a given time,
and the "events" (rows) which cause "actions" and/or state changes.  The
action and/or state change appropriate to the occurrence of a particular
event, when the processes are in a particular state, is shown at the
intersection of the respective row and column.  State transitions are
indicated by state numbers in parentheses; thus "(S2)" indicates "go to
State Number 2".  See Figure 1-1.

                         [GRAPHIC ELEMENT OMITTED]

                      Figure 1-1:  State Table Format

                                   NOTE

The table describes the processing for one independent Virtual Channel.






1.4  INTERLAYER INTERFACES

In order to define the COP-1 services and protocols completely and clearly,
it was necessary to define some of the characteristics of the interface
between the COP and the Higher and Lower Layers.  For example, a decision
had to be made as to whether the Higher Layer may deliver only one frame at
a time to Frame Operation Procedure-1 (FOP-1) or may deliver a group of
frames.  A strategy for ensuring accountability of sequence-controlled
frames all the way from the sending-end Higher Layer through the spacecraft
and back to the Higher Layer had to be established.

It is realized that there are other ways in which the interfaces could be
defined.  In particular, if two layers are implemented as part of a single
system, their interfaces could be simplified.  It is the responsibility of
the implementers to ensure that all of the requirements for the basic
operation of the COP are met.

Additional information about the assumed interlayer interfaces is included
in Annex B.





2       COP-1

Command Operation Procedure-1 (COP-1) is a closed-loop telecommanding
protocol that utilizes sequential ("go-back-n") retransmission techniques
to correct Telecommand (TC) Frames that were rejected by the spacecraft
because of error.  COP-1 allows Type-A TC Frames to be accepted by the
spacecraft only if they are received in strict sequential order and their
contents can be immediately passed on to the layer above.

Within COP-1, control of sequentiality is provided by the Frame Acceptance
and Reporting Mechanism (FARM), and therefore frame sequence numbering is
explicit.  The Frame Sequence Number must be present in each Type-A frame.
Type-A frames must be transmitted by the FOP with their numbers arranged in
strict upcounting order.  If one or more frames are missed, retransmission
is initiated either in response to a "Retransmit" Flag in the Command Link
Control Word (CLCW) or a timeout on the ground.  Window mechanisms on the
ground and spacecraft prevent a new frame with the same sequence number as
that of a missing frame from being transmitted or accepted.

Valid Type-B frames (i.e., "Bypass" frames) will always be accepted.

                                   NOTE

In this section, although it may be mentioned that COP-1 handles "frames",
these are actually partial frames made up of a TC Frame Data Unit (FDU)
plus the Frame Header data generated by COP-1.  The remainder of the Frame
Header will be generated by the Lower Layer.  The Frame Data Unit consists
of the data to be inserted in the Telecommand Transfer Frame Data Field, as
defined in Reference [3].

COP-1 is just one of the functions performed within the Transfer Layer.  It
is the first function performed when an FDU is received by the Transfer
Layer on the sending end and the last one performed before the FDU is
delivered to the Higher Layer on the receiving end.  For purposes of
defining the interfaces to COP-1, the function following Frame Operation
Procedure-1 (FOP-1) on the sending end will be called "Frame Generation",
and the one preceding Frame Acceptance and Reporting Mechanism-1 (FARM-1)
on the receiving end will be called "Frame Validation Check".


2.1     SERVICES AND PROTOCOLS

2.1.1   SERVICES

COP-1 provides two distinct services to the layer above.  These services
are "Sequence-Controlled Service" and "Expedited Service".





2.1.1.1     Sequence-Controlled Service (AD Service).

This service concerns two types of frames:

     o     "AD" for Telecommand Frame Data Units (TC FDUs), which are
           frames carrying data from the layer above

     o     "BC" for the two frames carrying protocol control information
           for configuring COP-1 ("Unlock" and "Set V(R)")

In COP-1, the Sequence-Controlled Service is based on an automatic request
for retransmission (ARQ) procedure of the "go-back-n" type with sequence-
control mechanisms both on the ground and on board the spacecraft and the
necessary presence of a standard report returned in the telemetry downlink,
the CLCW.

The Sequence-Controlled Service is initiated by means of four distinct
"Initiate AD Service" Directives, as shown in Table 2-1 (FOP-1 State
Table).  Two of these directives result in the transmission of one of the
two control commands (Type-BC frames).  Each of the two control commands
causes a well-defined action in FARM-1, which is then reflected in the
CLCW.  A timer is used to cause retransmission of the control command if
the expected response is not received, with a limit on the number of
automatic retransmissions allowed before the Higher Layer is notified that
there is a problem in initiating the AD Service.  The other two directives
allow the AD Service to be started without waiting for spacecraft action
(although one requires receiving a good CLCW).

Once COP-1 for a particular Virtual Channel has been initialized for an AD
Service, TC FDUs are inserted into frames and transmitted on that Virtual
Channel in the order in which they are presented to COP-1.  The
retransmission mechanism ensures with a high probability of success that

     o     no TC FDU is lost
     o     no TC FDU is duplicated
     o     no TC FDU is delivered out of sequence

The AD Service guarantees in-order delivery of TC FDUs on a single Virtual
Channel.  Because of the possibility of retransmission on only a single
Virtual Channel, there is no guarantee that TC FDUs on separate Virtual
Channels, each using an AD Service, will be delivered to the Higher Layer
in the order initially transmitted.

For the Type-AD frames, the automatic retransmission procedure makes use of
several variables, the most notable being the
Receiver_Frame_Sequence_Number, V(R); the Transmitter_Frame_
Sequence_Number, V(S); the Next Expected Frame Sequence Number contained in
the CLCW, N(R); and the Frame Sequence Number in the TC Frame Header, N(S).
(See Figure 2-1.)  These variables are described in Section 2.2.

                         [GRAPHIC ELEMENT OMITTED]

           Figure 2-1:  COP-1 Variables, Frame and Report Values

The AD Service also offers, if required, a flow control mechanism ("Wait"
system) that permits the Higher Layers on board the spacecraft to signal
that they are not able to cope with the incoming rate of uplink telecommand
data.

For the Type-BC frames, the automatic retransmission procedure makes use of
a very small number of variables, the most notable being the "Lockout" Flag
in the CLCW for the "Unlock" Control Command, and the value "N(R)" in the
CLCW for the "Set V(R)" Control Command.

2.1.1.2     Expedited Service (BD Service).

This service concerns the Type-BD frame.  Type-BD frames are normally used
only in exceptional operational circumstances, typically during spacecraft
recovery operations.

The service operates with one request from the Higher Layer for each TC FDU
(Receive Request to Transfer FDU from Higher Layer:  BD Service in the FOP-
1 State Table).  There is only one transmission for each Type-BD frame
(i.e., no retransmission).  At the sending end, Type-BD frames are given
immediate access, as specified by the FOP-1 State Table.  At the receiving
end, the TC FDU carried by a Type-BD frame will be passed to the Higher
Layer immediately, independent of the value of the Lockout_Flag or
Wait_Flag.

                                   NOTE

Some implementations of FARM-1 may use the same output buffer for FDUs
carried by either Type-AD or Type-BD frames in order to provide increased
reliability through reduced complexity and lower resource consumption.  In
this case, when a Type-BD frame is received, an FDU in the process of being
transferred or "waiting" to be transferred will be erased, without any
indication to the ground in the CLCW.  For this implementation, the sending-
end Higher Layer shall mandatorily and automatically terminate any ongoing
AD Service before starting a BD Service on the same Virtual Channel.


2.1.2   PROTOCOLS

Each end of COP-1 is defined as a protocol machine that is described in a
state table.  The description of the format used for the state tables in
this document is given in Section 1.3.

The basic operation principle of the protocol machine is that it remains in
a "state" until an "event" occurs.  When an event occurs, it is analysed
until it is fully identified and then the operations specified for the
combination of that event and that state are executed.  Finally, the State
variable is updated with the new State value specified for the combination.

2.1.2.1     At the Sending End:  FOP-1.  The FOP-1 protocol machine is
described in the FOP-1 State Table in Table 2-1.

In the case of the arrival of a CLCW, some operations need to be performed
before the FOP-1 protocol for the Virtual Channel is invoked.  In
particular, not included in the FOP-1 State Table are operations such as
checking

     o     the "COP in Effect"
     o     the "Virtual Channel Identifier"

Included in the FOP-1 State Table are the following operations:

     o     checking the value of the "Lockout" Flag
     o     checking the value of N(R)
     o     checking the value of the "Retransmit" Flag
     o     checking the value of the "Wait" Flag

2.1.2.2     At the Receiving End:  FARM-1.  The FARM-1 protocol machine is
described in the FARM-1 State Table in Table 2-2.

FARM-1 constantly generates a standard report, the CLCW, which is made
available to the spacecraft telemetry system at regular intervals (Event
E11 in the FARM-1 State Table).

Not included in the FARM-1 State Table are operations concerning the
validation of the frame.  When a "valid frame arrives", this means that the
Frame Validation Check process has placed a "valid" frame in the front-end
buffer of the FARM-1 protocol machine.  This validation includes verifying
that a control frame contains one of the two COP-1 control commands
("Unlock" and "Set V(R)").

Included in the FARM-1 State Table are the following operations:

     o     checking the value of the "Bypass" Flag
     o     checking the value of the "Control Command" Flag
     o     checking the value of N(S) in Type-AD frames


2.2     INTERNAL VARIABLES

This section describes the variables used by the COP-1 protocol machines at
each end of the Transfer Layer link.  The complete meaning of these
variables can only be fully understood in conjunction with a careful
reading of the COP-1 (i.e., FOP-1 and FARM-1) State Tables.  It is these
tables which, ultimately, contain the master definition of the COP-1
protocol.

These variables are those which are defined as part of the protocol.  Any
implementation of the protocol machines is likely to have in addition many
private, implementation-dependent variables.


2.2.1   FOP-1 VARIABLES

For each Virtual Channel the sending-end protocol machine maintains the
following variables:

     o     State
     o     Stored_Lockout_Flag
     o     Stored_Wait_Flag
     o     Stored_Retransmit_Flag
     o     Transmitter_Frame_Sequence_Number (usually referred to as
           "V(S)")
     o     Wait_Queue
     o     Sent_Queue
     o     To_Be_Retransmitted_Flag
     o     AD_Out_Flag
     o     BD_Out_Flag
     o     BC_Out_Flag
     o     Expected_Acknowledgement_Frame_Sequence_Number (usually
           referred to as "NN(R)")
     o     Timer_Initial_Value (also known as "T1_Initial")
     o     Transmission_Limit
     o     Transmission_Count
     o     FOP_Sliding_Window_Width (also known as "K")
     o     Timeout_Type (TT)
     o     Suspend_State (SS)

These are described in detail in the following sections.

2.2.1.1     State.  The state of FOP-1 may be one of

     o     Active (S1)
     o     Retransmit without Wait (S2)
     o     Retransmit with Wait (S3)
     o     Initialising without BC Frame (S4)
     o     Initialising with BC Frame (S5)
     o     Initial (S6)

This variable represents the state of FOP-1 for the specific Virtual
Channel.  Each value of the State variable corresponds to a column in the
FOP-1 State Table, Table 2-1.

"Active" State (S1) is the normal state of the protocol machine when there
are no recent errors on the link and no incidents have occurred leading to
flow control problems.

The protocol machine is in the "Retransmit without Wait" State (S2) while
the "Retransmit" Flag is "on" in the CLCW of the Virtual Channel but no
other exceptional circumstances prevail.

The protocol machine is in the "Retransmit with Wait" State (S3) while the
"Wait" Flag is "on" in the CLCW of the Virtual Channel.  (Some frames must
always be retransmitted when the "Wait" Flag is reset, since the "Wait"
Flag is set only when at least one frame has been discarded.)  In this
state the "Retransmit" Flag will also be set (as a consequence of the fact
that frames have been lost).

The protocol machine is in the "Initialising without BC Frame" State (S4)
after receiving an "Initiate AD Service (with CLCW check)" Directive while
in the "Initial" State.  A successful CLCW check will result in a
transition to S1.

The protocol machine is in the "Initialising with BC Frame" State (S5)
after receiving an "Initiate AD Service (with Unlock)" Directive or
"Initiate AD Service (with Set V(R))" Directive while in the "Initial"
State with BC_Out_Flag = Ready.  A successful transmission of the Type-BC
frame and a subsequent "clean" CLCW status will result in a transition to
S1.

The protocol machine is in the "Initial" State (S6) whenever it is
necessary to terminate an ongoing service (this happens when a "Terminate
AD Service" Directive is received or when an "exception", i.e., an event
that causes an "alert", occurs).  In principle, the "Initial" State is the
first state entered by the protocol machine for a particular Virtual
Channel.  Although, in principle, all these Virtual Channels remain open
during the life of the spacecraft, provision has to be made for
interruptions of the physical link between the ground and the spacecraft
and for the operation of the one physical link from different ground
stations.  These considerations mean that it must be possible to start up a
protocol machine on the ground more than once during the life of the
spacecraft.

In the "Initial" State, TC FDUs may only be transmitted if they are Type-BD
frames.  To start the Sequence-Controlled Service, it is necessary to
execute one of the four possible "Initiate AD Service" Directives.  If the
directive is accepted and successfully executed, the protocol machine will
be set to the "Active" State (S1).  If the directive is not successfully
executed (as would be the case if the transmission of an "Unlock" BC frame
were not confirmed in the CLCW reports from the spacecraft after the
maximum allowed number of timer-initiated retransmissions), FOP-1 generates
an "Alert" Indication and reenters the "Initial" State.

2.2.1.2     Stored_Lockout_Flag.  The Stored_Lockout_Flag contains the
value of the "Lockout" Flag from the previous CLCW on that Virtual Channel.

2.2.1.3     Stored_Wait_Flag.  The Stored_Wait_Flag contains the value of
the "Wait" Flag from the previous CLCW on that Virtual Channel.

2.2.1.4     Stored_Retransmit_Flag.  The Stored_Retransmit_Flag contains
the value of the "Retransmit" Flag from the previous CLCW on that Virtual
Channel.

2.2.1.5     Transmitter_Frame_Sequence_Number, V(S).  The
Transmitter_Frame_ Sequence_Number, V(S), contains the value of the Frame
Sequence Number, N(S), to be put in the Transfer Frame Header of the next
Type-AD frame to be transmitted.

2.2.1.6     Wait_Queue.  When Type-AD TC FDUs are received from the Higher
Layer they are held in the Wait_Queue until they can be accepted by the
Transfer Layer.  The Wait_Queue has a maximum capacity of one TC FDU.

The Wait_Queue and "Accept Response to Request to Transfer FDU" form the
primary mechanism by which flow control as seen by the Higher Layer is
governed.  When an FDU is on the Wait_Queue, this means that the Higher
Layer has not yet received an "Accept" Response for the corresponding
"Request to Transfer FDU".

2.2.1.7     To_Be_Retransmitted_Flag.  If retransmissions of the Sent_Queue
are to be done because one or more frames were not acknowledged within the
time allowed or were negatively acknowledged by a CLCW with the "Retransmit
Flag" set, it is not reasonable to shut out all other FOP activity until
the last frame on the Sent_Queue has been accepted by the Lower Layer
(especially since the Lower Layer uses the "Accept" Response as its flow
control mechanism).  During that possibly extended time other events may
occur, such as the arrival of a CLCW, which must be processed.  To handle
this situation, each frame on the Sent_Queue carries a
To_Be_Retransmitted_Flag to distinguish a frame that has been transmitted
(or retransmitted) and is awaiting acknowledgement (Flag reset) from one
that must be retransmitted (Flag set).  Upon receipt of an "Accept"
Response from the Lower Layer, these flags will be used to determine which
frame on the Sent_Queue, if any, to retransmit next.

2.2.1.8     AD_Out_Flag, BC_Out_Flag, and BD_Out_Flag.  FOP-1 records
whether or not a "Transmit Request for Frame" is outstanding for each of
the three types of frames:  AD, BC and BD.  There are therefore three
variables:

     o     AD_Out_Flag (for Type-AD frames)
     o     BC_Out_Flag (for Type-BC frames)
     o     BD_Out_Flag (for Type-BD frames)

These may take one of two values:

     o     Ready
     o     Not_Ready

When FOP-1 issues a "Transmit Request for Frame", it sets the appropriate
"Out" variable to "Not_Ready".  When the "Transmit Request" is accepted by
the Lower Layer, FOP-1 sets the variable to "Ready".

2.2.1.9     Sent_Queue.  The Sent_Queue is a Virtual Channel data structure
in which the master copy of all Type-AD and Type-BC frames on a Virtual
Channel is held between the time a copy of the frame is first passed to the
Lower Layers for transmission and the time the Transfer Layer has finished
processing the frame.

The Transfer Layer has finished processing a Type-AD or Type-BC frame when

     1)    it receives (via the CLCW) a positive acknowledgement of
           receipt of the frame (perhaps after retransmission) or

     2)    an event causes the Transfer Layer to purge the Sent_Queue
           (i.e., an exception or a "Terminate AD Service" Directive)

Once the processing is finished, the master copy of the frame is removed
from the queue and discarded and the (successful or not successful)
transfer of the FDU is reported to the Higher Layer by means of a "Confirm"
Response (Positive or Negative).

2.2.1.10    Expected_Acknowledgement_Frame_Sequence_Number (NN(R)).  The
Expected_Acknowledgement_Frame_Sequence_Number, NN(R), contains the value
of N(R) from the previous CLCW on that Virtual Channel.  "NN(R)-1" is the
value of the sequence number of the latest Type-AD frame which FOP-1 can
guarantee has arrived safely.  Because of the loop delay in the
communications link, this value may lag behind the value of the onboard
Receiver_Frame_Sequence_Number, V(R).

2.2.1.11    Timer_Initial_Value (T1_Initial).  Whenever a Type-AD or Type-
BC frame is transmitted, the Timer is started or restarted with an initial
value of Timer_Initial_Value (T1_Initial).

If a frame is lost on the physical link, no positive acknowledgement for
that frame will be seen in the CLCW.  If no later Type-AD or Type-BC frame
were transmitted on that Virtual Channel, there would be no way for FOP-1
to discover that the frame had not arrived.  Therefore each Virtual Channel
has a Timer which is started whenever a frame is transmitted or
retransmitted.  If an acknowledgement is seen for the frame, and no
subsequent frame has been transmitted, then the Timer is cancelled.  If the
Timer expires and the Transmission_Count has not reached the
Transmission_Limit (see following variables), it causes an event which
initiates recovery action in the FOP-1 protocol machine.

The Timer is not used when a Type-BD frame is transmitted.

The value to which the Timer is set when it is started or restarted is
referred to as "T1_Initial" and may be changed using the "Set T1_Initial"
Directive.

For normal operation, the smallest value of T1_Initial shall be the sum of
the following delays for a given Virtual Channel:

     o     ground processing time of the layers below FOP-1
     o     time required to transmit a maximum-length frame, including the
           bits needed for the Command Link Transmission Unit (CLTU) and
           coding, as a serial bit stream
     o     uplink propagation time (one-way light time, including relay
           satellite path)
     o     onboard processing time of the layers below FARM-1
     o     worst-case time required to sample and encode FARM-1 status
           data as a CLCW in the telemetry Transfer Frame
     o     time required to transmit a telemetry Transfer Frame
     o     downlink propagation time (one-way light time, including relay
           satellite path)
     o     ground processing time to extract the CLCW from the telemetry
           Transfer Frame and to deliver it to FOP-1

A smaller value of T1_Initial may be useful for deep space commanding with
long round-trip light times.  It can be used to force retransmission of the
entire Sent_Queue a specified number of times prior to receipt of any
acknowledgement CLCWs.  Assuming Timeout_Type is set to "1" (see below),
FOP-1 will be suspended once the maximum number of transmissions is made.
Its operation will then be resumed by the Higher Layer to process the
acknowledgement CLCWs.  In addition, a small value of T1_Initial can be
used to allow the "Set V(R)" Control Command to be sent without having to
verify its acceptance via a CLCW before sending the Type-AD frames.  In
this case the Higher Layer will be alerted once the allowed number of
transmissions of the Set V(R) is made and it can then issue an "Initiate AD
Service (without CLCW Check)" Directive.

2.2.1.12    Transmission Count Variables.  When a Type-AD or Type-BC frame
is lost, the normal recovery procedure is to retransmit it.  If, however,
there is a serious problem on the underlying physical link, no amount of
retransmissions will permit an acknowledgement for the frame to appear in
the CLCW for the Virtual Channel.

If nothing were done, there would be no way for COP-1 to detect the error.
Therefore all FDUs containing user data passed from the ground Higher Layer
(as well as all directives from the Higher Layers) have associated with
them, at least implicitly, a limit to the number of times the corresponding
frame is to be transmitted.

In order to keep from declaring that the link has failed when it is in fact
getting frames into the spacecraft, the transmission count limit applies
only to the first frame on the Sent_Queue.  Once that frame is
acknowledged, the count is reset, even though the remaining frames on the
Sent_Queue have been transmitted, possibly more than once.  The effect is
that the transmission count can be considered to be associated with the
Sent_Queue, rather than with each frame.





Three FOP-1 variables are used for controlling the retransmissions.

     1)    Transmission_Limit

           The Transmission_Limit holds a value which represents the
           maximum number of times the first frame on the Sent_Queue may
           be transmitted.  This includes the first "transmission" and any
           subsequent "retransmissions" of the frame.

           The value of the Transmission_Limit may be changed using the
           "Set Transmission_Limit" Directive.

     2)    Timeout_Type (TT)

           The Timeout_Type variable is referred to as "TT".  It may take
           one of two values, "0" or "1".  It specifies the action to be
           performed when both the Timer expires and the
           Transmission_Count (see next variable) has reached the
           Transmission_Limit.

     3)    Transmission_Count

           There are two different sorts of events which may cause FOP-1
           to initiate retransmission of either a Type-BC frame or one or
           more Type-AD frames:

           o a CLCW arrives which negatively acknowledges a frame
             ("Retransmit Flag" = 1)

             Whenever a CLCW arrives which negatively acknowledges a
             frame, FOP-1 checks whether the value of the
             Transmission_Count has reached the value of the
             Transmission_Limit.  If it has not, FOP-1 increments the
             count and initiates retransmission of the frames on the
             Sent_Queue.  If it has, FOP-1 generates an "Alert"
             Indication.

           o the Timer expires (a CLCW positively acknowledging the last
             frame on the Sent_Queue has not been received within the
             specified time)

             Whenever the Timer expires, FOP-1 checks whether the value of
             the Transmission_Count has reached the value of the
             Transmission_Limit.  If it has not, FOP-1 increments the
             count and initiates retransmission of the frames on the
             Sent_Queue.  If it has, FOP-1 selects one of two types of
             possible actions depending on the value of the Timeout_Type,
             TT:

             -  If TT = 0, FOP-1 generates an "Alert" Indication.

             -  If TT = 1, FOP-1 suspends the AD Service, which may be
                resumed later if so required (see definitions of
                Suspend_State variable (SS) and "Resume AD Service"
                Directive).

           Whenever one or more frames are acknowledged and therefore
           removed from the Sent_Queue, the Transmission_Count is reset to
           "1".  The Transmission_Count is also set to "1" when FOP-1
           prepares a Type-AD or Type-BC frame for transmission and the
           Sent_Queue was previously empty.  All these actions are defined
           in detail in Section 2.5, "Actions".

           For the Expedited Service (BD Service), there is no
           Transmission_Count variable, because each Type-BD frame is only
           transmitted once.

2.2.1.13    Suspend_State (SS).  The Suspend_State variable is referred to
as "SS".  It may take one of five values, from "0" to "4".  It records the
state that FOP-1 was in when the AD Service was suspended (as described in
Section 2.2.1.12, "Transmission Count Variables", above).  This is the
state to which FOP-1 will return should the AD Service be resumed.  If
SS = 0, the AD Service is deemed not suspended.

2.2.1.14    FOP_Sliding_Window_Width (K).  The value to which the
FOP_Sliding_ Window_Width is set is referred to as "K" and may be changed
using the "Set FOP_ Sliding_Window_Width" Directive.

The FOP Sliding Window is a mechanism which limits the number of frames
which can be transmitted ahead of the last acknowledged frame, i.e., before
a telemetered CLCW report is received which updates the status of
acknowledged frames.  This is to prevent sending a new frame with the same
sequence number as a rejected frame.

The value "K" shall be set to a value between the following limits:

                         [GRAPHIC ELEMENT OMITTED]

where "PW" is the FARM_Positive_Window_Width as defined in Section 2.2.2.7,
"FARM Sliding Window Variables".


2.2.2   FARM-1 VARIABLES

For each Virtual Channel the receiving-end protocol machine maintains the
following variables:

     o     State
     o     Lockout_Flag
     o     Wait_Flag
     o     Retransmit_Flag
     o     Receiver_Frame_Sequence_Number (usually referred to as "V(R)")
     o     FARM-B_Counter
     o     FARM_Sliding_Window_Width (also known as "W")
     o     FARM_Positive_Window_Width (also known as "PW")
     o     FARM_Negative_Window_Width (also known as "NW")
     o     Buffer administration variables

Finally, each Virtual Channel must have available some storage to be used
for buffers.  This implies the existence of data structures for
administering the buffers.

These variables are described in detail in the following sections.

2.2.2.1     State.  The State may be one of

     o     Open (S1)
     o     Wait (S2)
     o     Lockout (S3)

This variable represents the state of FARM-1.  Each value of the State
variable corresponds to a column in the FARM-1 State Table, Table 2-2.

In "Open" State, the protocol machine accepts in-sequence frames and passes
them to the Higher Layer.

In "Wait" State, there is no buffer space available in which to place any
further received Type-AD user data frames.  The protocol machine enters the
"Wait" State when it has received a Type-A TC FDU, but is unable to deliver
it to the Higher Layer.  It leaves the "Wait" State upon receipt of a
buffer release signal from the Higher Layer.

"Lockout" State is entered if the protocol machine receives a frame with
sequence number N(S) outside the range expected if FOP-1 is operating
correctly.  It is a safe state in that no user data will be accepted or
transferred to the Higher Layer when in the "Lockout" State (unless bypass
is used).  The protocol machine leaves the "Lockout" State upon receipt of
an "Unlock" Control Command.

2.2.2.2     Lockout_Flag.  The Lockout_Flag is set to "1" whenever the
protocol machine is in "Lockout" State; otherwise, it is "0".  When the
CLCW is to be encoded for a particular Virtual Channel, the value of this
flag is inserted into the "Lockout" Flag field of the CLCW of that Virtual
Channel.

2.2.2.3     Wait_Flag.  The Wait_Flag is set to "1" whenever the protocol
machine is in "Wait" State; otherwise, it is "0".  When the CLCW is to be
encoded for a particular Virtual Channel, the value of this flag is
inserted into the "Wait" Flag field of the CLCW of that Virtual Channel.

2.2.2.4     Retransmit_Flag.  The Retransmit_Flag is set to "1" whenever
the protocol machine knows that a Type-AD frame has been lost in
transmission or has been discarded because there was no buffer space
available; otherwise, it is "0".  When the CLCW is to be encoded for a
particular Virtual Channel, the value of this flag is inserted into the
"Retransmit" Flag field of the CLCW of that Virtual Channel.  The
appearance of the "set" condition of the flag on the ground forms a
negative acknowledgement of all previously transmitted frames with N(S)
equal to or greater than N(R).  The flag will be reset to "0" upon
successful receipt of a frame with N(S) = V(R), receipt of a "Set V(R)"
Control Command (unless in "Lockout" State) or receipt of an "Unlock"
Control Command.

2.2.2.5     FARM-B_Counter.  This variable is incremented whenever a valid
Type-BD or Type-BC frame arrives.  The value of this variable is inserted
into the CLCW, but is not used by the COP-1 protocol machines at either end
of the link.  The counter is intended for use by layers above the Transfer
Layer to offer a minimal facility for a Higher Layer error-control loop
when the Expedited Service (BD Service) is used.

How the Higher Layers access the CLCW to obtain the value of the FARM-
B_Counter is not defined in this Recommendation.  It is implementation
dependent.

2.2.2.6     Receiver_Frame_Sequence_Number V(R).  This variable records the
value of N(S) expected to be seen in the next Type-AD frame on this Virtual
Channel.

2.2.2.7     FARM Sliding Window Variables.  The purpose of the COP-1
Sliding Windows is to protect FARM-1 against the unauthorized
(uncontrolled) transfer of a sequence of frames such that the Frame
Sequence Number, N(S), of one or more of these frames will exceed the
current value of the Receiver_Frame_Sequence_Number, V(R), by at least 256.

The purpose of the FOP Sliding Window (defined in terms of its width, "K",
in Section 2.2.1.14, "FOP_Sliding_Window_Width (K)") is to limit the number
of frames which can be transmitted safely ahead of the last acknowledged
frame.  The purpose of the FARM Sliding Window is to protect FARM-1 against
any malfunction or erroneous setup of FOP-1.

The FARM Sliding Window is defined in terms of three variables:

     o     its total width, referred to as "W"
     o     the width of its positive part, referred to as "PW"
     o     the width of its negative part, referred to as "NW"

The three variables are specified in the next paragraphs, as are the main
related actions.  Figure 2-2 illustrates the FARM Sliding Window concept
with its different sections and actions.

                         [GRAPHIC ELEMENT OMITTED]

                 Figure 2-2:  FARM Sliding Window Concept

2.2.2.8     FARM_Sliding_Window_Width (W).  The FARM_Sliding_Window_Width
is referred to as "W" and gives the range over which the Frame Sequence
Numbers of received Type-AD frames may vary without lockout occurring.

The value "W" shall be set to a value between the following limits:


                         [GRAPHIC ELEMENT OMITTED]

where "W" is always an EVEN integer.

Unless otherwise specified, the value "W" shall be fixed for the entire
duration of the mission.  In particular, there are no COP-1 control
commands for changing the value.

2.2.2.9     FARM_Positive_Window_Width (PW) and FARM_Negative_Window_Width
(NW).  As shown in Figure 2-2:

     o     The FARM Positive Window area starts with V(R) and extends PW
           frames in the positive direction.

     o     The FARM Negative Window area starts at V(R) - 1 (the number of
           the last accepted frame) and extends NW frames in the negative
           direction.

The widths of both parts of the FARM Sliding Window are specified as
follows:

                         [GRAPHIC ELEMENT OMITTED]

A Frame Sequence Number, N(S), falls outside the FARM Sliding Window (e.g.,
into the lockout area of width 256 - W) when

                         [GRAPHIC ELEMENT OMITTED]

When the frame is in the lockout area, FARM-1 will discard the frame, go
into the "Lockout" State and set the "Lockout" Flag.

When N(S) falls inside the FARM Sliding Window, one of the following three
cases will occur:

     1)    First case:

                         [GRAPHIC ELEMENT OMITTED]

           The frame is in the Positive Window and contains the expected
           Frame Sequence Number; the frame is accepted.  This is the case
           when COP-1 is operating correctly and no previous frames have
           been lost or discarded.  It is also the case when retransmitted
           frames are received after they have been lost or discarded.





     2)    Second case:

                         [GRAPHIC ELEMENT OMITTED]

           The frame is in the Positive Window and does not contain the
           expected Frame Sequence Number; the frame is discarded and the
           Retransmit_Flag is set, if it has not already been set.  This
           case occurs when a previous frame has been lost or discarded
           and retransmission has not yet started.

     3)    Third case:

                         [GRAPHIC ELEMENT OMITTED]

           The frame is in the Negative Window and is discarded without
           any other action being taken.  This case occurs if frames are
           retransmitted even though they have been accepted.  This could
           happen, for example, if the FOP T1_Initial has been set to a
           too-small value or if there is a telemetry outage.  It may
           occur during operations using the forced-retransmission
           mechanism for deep space missions.

                                   NOTE

Certain missions may require only a single transmission of a sequence of
Type-AD frames in one COP-1 session (Transmission_Limit = 1), whether in
the Suspend/Resume mode of operation or not.  For such missions and in such
a mode, it is permitted to set PW > NW, with, ultimately, NW = 0 and PW =
W, where "W" can be any integer between 1 and 256 inclusive.  Thus:

                         [GRAPHIC ELEMENT OMITTED]

Whatever the value of PW, the value of the FOP_Sliding_Window_Width (K) may
never exceed 255.

2.2.2.10    Buffer Administration Variables.  The receiving end of the
Transfer Layer requires storage to process the frames arriving from the
ground and to contain data to be passed to the Higher Layer.

The actual storage allocation strategy is implementation dependent.
However, the way FARM-1 is defined in the state tables implies that certain
aspects of this strategy are not implementation dependent.  These are
described here.

The FARM-1 State Table (Table 2-2) implies the existence of the following
FARM-1 buffers:

     o     one "front-end" buffer to contain one maximum-length frame for
           use while the Transfer Layer Frame Validation Checks are
           performed

     o     at least one "back-end" buffer to contain the data (TC FDUs) to
           be passed to the Higher Layer

If only one back-end buffer is provided, the main requirement is that the
data contained in incoming Type-BD frames have priority;  if the back-end
buffer still contains data, these data shall be erased and the buffer made
available to the incoming (BD) FDU.  (See "Note" in Section 2.1.1.2.)


2.3     COP-1 INTERFACE TO HIGHER LAYER

A BRIEF DESCRIPTION OF INTERFACE TERMINOLOGY IS CONTAINED IN ANNEX B.


2.3.1   SENDING END

In addition to supporting the normal data transfer interfaces to the FOP-1
protocol machine, a number of management functions may be performed by the
Higher Layers.  These may be regarded as either a special set of commands
from the Higher Layer (with the Higher Layer description modified to
include them) or they may be regarded as a separate higher interface to the
Transfer Layer.  It is also expected that additional status information
will be passed from FOP-1 to the Higher Layer for use in performance
monitoring and problem diagnosis.

In order to describe the way the Transfer Layer responds to requests from
the Higher Layers, we consider the Higher Layer to Transfer Layer interface
as two separate interfaces:

     1)    a Sequence-Controlled Service Interface

           The Sequence-Controlled Service (AD Service) consists
           essentially of guaranteeing the successful transfer of TC FDUs
           by means of Type-AD frames.  However, the two Type-BC frames
           are also generated and serviced when the proper directive is
           sent.

           The following service primitives are defined for the Sequence-
           Controlled Service Interface:

           o Management Interface

             -  many different Directives
             -  Accept Response to Directive
             -  Reject Response to Directive
             -  Positive Confirm Response to Directive
             -  Negative Confirm Response to Directive
             -  Alert Indication
             -  Suspend Indication

           These service primitives are described in detail in Section
           2.3.1.1.

           o FDU Transfer Interface

             -  Request to Transfer FDU
             -  Accept Response to Request to Transfer FDU
             -  Reject Response to Request to Transfer FDU
             -  Positive Confirm Response to Request to Transfer FDU
             -  Negative Confirm Response to Request to Transfer FDU

           These service primitives are described in detail in Section
           2.3.1.2.

     2)    an Expedited Service Interface

           The Expedited Service (BD Service) consists essentially of
           transmitting each TC FDU in one BD frame.

           The following service primitives are defined for the Expedited
           Service Interface:

           o Request to Transfer FDU
           o Accept Response to Request to Transfer FDU

           These service primitives are described in detail in Section
           2.3.1.3.

2.3.1.1     Sequence-Controlled Service Management Interface.  The Sequence-
Controlled Service Management Interface is the service access point for
exchanging information between the management functions of the Higher
Layers and the Transfer Layer.

This access point serves to permit the Higher Layer to request services
from the Transfer Layer in connection with managing a Virtual Channel.
These service requests are referred to in this document as "directives".

In addition, the access point serves to permit the Transfer Layer to report
the status of a Virtual Channel to the Higher Layers.  In particular,
exception conditions are signalled by means of a service primitive called
an "Alert" Indication.

The service primitives defined on this interface are described hereafter.

                                   NOTE

Other management information, such as spacecraft identification, TC
codeblock length, uplink bit rate, etc., which must be provided by the
Higher Layers, is not included here for the sake of clarity; detailed
implementation not only reflects the layered nature of the telecommand
system, but also the operational philosophy of the network facilities,
which is outside the scope of this Recommendation.

     1)    Directives

           Service requests from the Higher Layer management function are
           referred to here as "directives".  These are

           o four "Initiate AD Service" Directives
           o one "Terminate AD Service" Directive
           o one "Resume AD Service" Directive
           o five "FOP-1 Setup" Directives

           Furthermore, any other Directive will be rejected and reported
           as

           o an invalid Directive

           The 12 directives correspond to Events E23 through E40 in the
           FOP-1 State Table (Table 2-1).  They are

           o "Initiate AD Service (without CLCW check)" Directive
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Initiate AD Service (with CLCW check)" Directive
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Initiate AD Service (with Unlock)" Directive
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier





           o "Initiate AD Service (with Set V(R))" Directive
             Parameters:
             -  V*(R), the new value for V(R)
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Terminate AD Service" Directive
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Resume AD Service" Directive
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Set V(S) to V*(S)" Directive
             Parameters:
             -  V*(S), the new value for V(S)
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Set FOP_Sliding_Window_Width" Directive
             Parameters:
             -  new value for width of FOP Sliding Window (K)
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Set T1_Initial" Directive
             Parameters:
             -  new value for Timer_Initial_Value (T1_Initial)
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Set Transmission_Limit" Directive
             Parameters:
             -  new value for Transmission_Limit
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Set Timeout_Type" Directive
             Parameters:
             -  new value for Timeout_Type (TT)
             -  Directive Identifier
             -  Virtual Channel Identifier

           o Invalid Directive
             Parameters:
             -  any invalid Directive Identifier
             -  Virtual Channel Identifier

     2)    Responses

           Asynchronously from the directive, the Transfer Layer returns a
           "Response to Directive".  This indicates whether FOP-1 will try
           to execute the Directive.  This may be one of

           o "Accept Response to Directive"
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Reject Response to Directive"
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           After each "Accept Response to Directive", but asynchronously
           from that Response, the Transfer Layer signals to the Higher
           Layer a "Confirm" Response referring to the Directive.  This
           indicates whether or not COP-1 (including FARM-1 for directives
           requiring receiving-end action) was able to complete the
           execution of the Directive.  This may be one of

           o "Positive Confirm Response to Directive"
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

           o "Negative Confirm Response to Directive"
             Parameters:
             -  Directive Identifier
             -  Virtual Channel Identifier

             The "Negative Confirm Response to Directive" service
             primitive does not carry a parameter giving the reason for
             the failure to confirm performance of the service requested
             by the Directive.  However, whenever a condition is detected
             which might give rise to "Negative Confirm Response to
             Directive" service primitives, an "Alert" Indication is
             signalled from the Transfer Layer to the Higher Layer.





     3)    Alert Indications

           If an unrecoverable error occurs on the link, then the Transfer
           Layer passes an indication to the Higher Layer.

           o Alert Indication
             Parameters:
             -  reason for Alert
             -  Virtual Channel Identifier

           This "Alert" Indication serves as notice of the termination of
           the Sequence-Controlled Service guarantee.

           The reason for an "Alert" Indication may be one of the
           following:

           o Allowed number of transmissions exhausted for a Type-AD
             frame:  Alert[limit].  (Note:  This "Alert" Indication cannot
             occur if the Timer has expired and the Timeout_Type variable
             is set to "1".)

           o Allowed number of transmissions exhausted for a Type-BC frame
             derived from a directive (e.g., "Initiate AD Service"
             Directive with "Unlock" or with "Set V(R)"):  Alert[limit].

           o Lockout detected:  Alert[lockout].

           o CLCW with "Retransmit" Flag = 0 and N(R) = NN(R) has arrived,
             when last CLCW showed "Retransmit" Flag = 1:  Alert[synch].

           o All frames sent are acknowledged but "Retransmit" Flag = 1:
             Alert[synch].

           o An attempt to acknowledge frames is made during the
             initialising phase corresponding to State (S4):
             Alert[synch].

           o CLCW with invalid N(R) has arrived:  Alert[NN(R)].

           o CLCW with = "Wait" Flag = 1 and "Retransmit" Flag = 0 has
             arrived:  Alert[CLCW].

           o CLCW with invalid pattern of bits has arrived:  Alert[CLCW].

           o FOP-1 and Lower Layer are out of synchronisation (Lower Layer
             rejects frame even though appropriate "Out" Flag is set to
             "Ready"):  Alert[LLIF].  ("LLIF"  refers to the Lower Layer
             Interface.)

           o A "Terminate AD Service" Directive has arrived:  Alert[term].

           The "Alert" Indication implies the end of the Sequence-
           Controlled Service guarantee on the error-free transfer of data
           to the spacecraft.  Higher Layer recovery actions are necessary
           to try to ensure that data are not lost, duplicated or
           erroneous.

           The "Alert" Indications relating to the transmission count may
           occur as a result of a break in the underlying physical link
           and may therefore be caused by problems outside the Transfer
           Layer.

           All other "Alert" Indications report the breakdown of the
           Transfer Layer protocol.  This means that some part of the
           system is not operating to specification (therefore, reports
           already received by the layers above FOP-1 are likely to have
           been incorrect).

           In particular, an "Alert" Indication carries the Virtual
           Channel Identifier corresponding to the FOP-1 in which the
           error condition was detected; but, given that the protocol
           mechanism has broken down, it is possible that the Virtual
           Channel Identifier is incorrect.  A single failure may cause
           the same or different "Alert" Indications on more than one
           Virtual Channel.

           A "Lockout Detected Alert" will not occur if the Lockout was
           detected and reported by an earlier "Alert" Indication and it
           has not changed since that Indication.

     4)    "Suspend" Indication

           By setting Timeout_Type to "1" and setting a small value of
           T1_Initial it is possible to cause FOP-1 to transmit a sequence
           of Type-AD frames a specified number of times and then suspend
           its operation, without clearing its buffers.  The "Suspend"
           Indication is used to notify the Higher Layer that the
           transmissions have been completed and that the operation has
           been suspended.  A subsequent "Resume" Directive will then
           cause FOP-1 to resume operation in the same state it was in
           when it was suspended.

2.3.1.2     Sequence-Controlled Service FDU Transfer Interface.  Data
transferred through this interface enjoy the protection of all the Transfer
Layer facilities and are covered by the guarantee to deliver data without
error, in order and without omission or duplication to the spacecraft.

Only one operation may be performed by the Higher Layer on the interface.
This is to present to the Transfer Layer





     o     Request to Transfer FDU (AD Service)
           Parameters:
           -  FDU
           -  Request Identifier
           -  Virtual Channel Identifier

After each Request, perhaps immediately, perhaps after a delay, the
Transfer Layer returns to the Higher Layer a Response referring to the
Request.  This may be one of

     o     Accept Response to Request to Transfer FDU (AD Service)
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

     o     Reject Response to Request to Transfer FDU (AD Service)
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

In response to this Request the Transfer Layer signals its acceptance or
rejection of the Request.  However, if the Transfer Layer is unable to
transmit the FDU immediately (for example, because the spacecraft has
indicated it cannot immediately accept any more data), then the Transfer
Layer will delay signalling to the Higher Layer its acceptance of the FDU
from the Higher Layer, even though it places the FDU in its Wait_Queue.
The Higher Layer may not issue another "Request to Transfer FDU" until the
current one has been accepted or rejected.

Whenever it has transfer capacity after a period when there was no extra
capacity available, the FOP-1 protocol machine looks at the AD Service
Interface to see if an FDU is in the Wait_Queue.  If so, the Transfer Layer
accepts the FDU, which is then deemed to be under control of the Transfer
Layer.

After each "Accept Response to Request to Transfer FDU (AD Service)", but
asynchronously from the Response, the Transfer Layer signals to the Higher
Layer a "Confirm" Response referring to the Request.  This may be one of

     o     "Positive Confirm Response to Request to Transfer FDU (AD
           Service)"
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

     o     "Negative Confirm Response to Request to Transfer FDU (AD
           Service)"
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

Because there may be a number of FDUs which have been accepted, but not
confirmed, the two layers need to share a common system of request
identifiers for use when referring to a particular request (and, therefore,
to a particular FDU).

The "Positive Confirm Response to Request to Transfer FDU (AD Service)"
notifies the Higher Layer that the FDU was received on board and
acknowledged by a CLCW.  If the Transfer Layer is unable to guarantee that
an FDU was transferred on board despite retry attempts, a "Negative
Confirm" Response for that FDU is passed to the Higher Layer.

The "Negative Confirm Response to Request to Transfer FDU (AD Service)"
does not carry a parameter giving the reason for the failure to confirm the
requested data transfer service.  However, whenever a condition is detected
which might give rise to such responses, an "Alert" Indication is signalled
from the Transfer Layer to the Higher Layer.

From the point of view of the Higher Layer, between the time of acceptance
of an FDU by the Transfer Layer until a "Positive Confirm" Response is
received, the FDU is in a "grey area" in which it is not possible to know
if it has been transferred on board.  FDUs for which a "Negative Confirm"
Response is received may have been successfully uplinked or they may not.
Therefore, a "Negative Confirm" Response signals a break in the Sequence-
Controlled Service guarantee.

If an FDU has not been accepted, it is deemed to be still under the control
of the Higher Layer and is not covered by the Sequence-Controlled Service
guarantee.  Once FOP-1 detects a problem (for example, a failure of the
automatic error-recovery mechanism to ensure transfer on board) leading to
a break in the Sequence-Controlled Service guarantee, it rejects the
outstanding "Request to Transfer FDU".  Therefore, an FDU which has not
been accepted can never be in the "grey area".

2.3.1.3     Expedited Service Interface.  The Expedited Service Interface
is the service access point used for FDUs to be transmitted via Type-BD
frames.

Data transferred through this interface are covered by the Expedited
Service guarantee to deliver data without error, in order, without
duplication but with possible omissions.  (The data are not duplicated
because there is no automatic retransmission mechanism; the frame is
transmitted only once.)  If any error recovery is required, it has to be
performed by the Higher Layers.

Only one operation is performed by the Higher Layer on this interface.
This is to present an FDU to the Transfer Layer:

     o     Request to Transfer FDU (BD Service)
           Parameters:
           -  FDU
           -  Request Identifier
           -  Virtual Channel Identifier

After each Request, perhaps immediately, perhaps after a delay, the
Transfer Layer returns to the Higher Layer a Response referring to the
Request.  This may be one of

     o     Accept Response to Request to Transfer FDU (BD Service)
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

     o     Reject Response to Request to Transfer FDU (BD Service)
           Parameters:
           -  Request Identifier
           -  Virtual Channel Identifier

As long as the sending-end Lower Layers are capable of accepting the Type-
BD frame, it will be accepted from the Higher Layer and transmitted.  If
the Lower Layers cannot accept the Type-BD frame, it will be rejected;
there is no Wait_Queue for Type-BD frames.

As no error recovery is performed by COP-1 for a Type-BD frame, a copy of
the data is not kept by FOP-1 and no confirmation of acceptance of the
frame by the receiving end is signalled on this interface.


2.3.2   RECEIVING END

At the receiving end of COP-1 (i.e., FARM-1), the user data are delivered
as a buffer containing an accepted TC FDU.  No distinction is made between
a TC FDU delivered by means of a Type-AD frame and one delivered by a Type-
BD frame.  However, the management of the FARM-1 back-end buffer is
affected as follows:

     1)    Type-BD frames

           When a frame of this type is accepted by FARM-1, the TC FDU it
           contains shall be placed in the BD back-end buffer of FARM-1
           even if this buffer still contains data (partially read out or
           not), in which case these data will be erased, an "Abort"
           Signal sent to the Higher Layer to signal the erasure and the
           new data signalled as "arrived".

     2)    Type-AD frames

           When a frame of this type is accepted by FARM-1, the TC FDU it
           contains shall be placed in the AD back-end buffer of FARM-1
           and a signal sent to the Higher Layer only when the buffer is
           available (empty).  If the buffer still contains data, the
           newly arrived Type-AD frame shall be discarded.

Therefore, FARM-1 must always know when its back-end buffers still contain
data.  (See also the related "Note" in Section 2.1.1.2, "Expedited
Service".)
All this can be expressed by the following service primitives:

     o     From FARM-1 to Higher Layer

           -  FDU Arrived Indication
             Parameters:
             -  TC FDU data
             -  Virtual Channel Identifier (normally implicit)
             -  FDU Aborted Indication

     o     From Higher Layer to FARM-1

           No specific service primitive is defined.  Any required data
           flow control signalling may be defined, as long as the back
           pressure is felt by FARM-1; i.e., FARM-1 must always know
           whether its AD back-end buffer is empty or not.

No interface with the Higher Layer exists for control frames (Type-BC);
control commands are used only within COP-1.

Finally, data link service anomalies may result in discontinuities in the
data transfer service.  This may or may not require erasing incomplete data
in the Higher Layers.  This problem is mentioned in Section 2.5 ("Actions";
see the "Note" in Section 2.5.2).


2.4     COP-1 INTERFACE TO LOWER LAYER

2.4.1   SENDING END

2.4.1.1     From FOP-1 to Frame Generation.

     o     Transmit Request for Frame
           Parameters:
           -  Request Identifier
           -  Frame data including:
           -  Version (format) Identifier
           -  Type Identifier (AD, BD or BC)
           -  Spacecraft Identifier
           -  Virtual Channel Identifier
           -  Frame Sequence Number, N(S), for Type-AD frames
           -  Data (TC FDU or Control Command)

     o     Abort Request
           Parameters:
           -  Virtual Channel Identifier


2.4.1.2     From Frame Generation to FOP-1.

Each "Transmit" Request is acknowledged with one of two possible responses:

     o     Accept Response
           Parameters:
           -  Request Identifier of Transmit Request
           -  Virtual Channel Identifier

     o     Reject Response
           Parameters:
           -  Request Identifier of Transmit Request
           -  Virtual Channel Identifier


2.4.2   RECEIVING END

2.4.2.1     From the Frame Validation Check to FARM-1.

     o     Valid Frame Arrived Indication
           Parameters:
           -  Frame Type (AD, BD or BC)
           -  Virtual Channel Identifier
           -  Frame Sequence Number, N(S), for Type-AD frames
           -  Data (TC FDU or Control Command)

The frame type information is used for demultiplexing the frame data of
different services (AD, BD, BC).  The Virtual Channel Identifier is
normally implicit, since there is a separate FARM-1 for each Virtual
Channel.  Note:  all of this information could be transferred by providing
the entire frame, including the header.

2.4.2.2     From FARM-1 to the Frame Validation Check.

No service primitives are specified.


2.5     ACTIONS

2.5.1   FOP-1

The actions related to the interface between FOP-1 and the Higher Layer
have been covered in Section 2.3.

The FOP-1 State Table (See Table 2-1) expresses the operations to be
performed for each event/state combination.  Description of the state table
format is included in Section 1.3.

Because of space considerations in the table and in order to avoid
repeating the same material several times in the text of this section,
certain terms have been used in the table, and are explained below:

     o     "Purging the Sent_Queue" includes clearing the Sent_Queue by
           generating a "Negative Confirm" Response for each frame on the
           queue and deleting the frame.  (Note:  Purging the Sent_Queue
           only occurs as part of the termination of an AD Service.)

     o     "Purging the Wait_Queue" includes clearing the Wait_Queue and
           generating a "Reject" Response for the queued FDU.

     o     "Transmit Type-AD frame" or "Transmit Type-BC frame" (i.e., for
           the Sequence-Controlled Service), includes all the functions
           necessary to prepare a frame for transmission.  In particular
           it includes

          -  inserting the current value of V(S) into the N(S) field of
             the frame and then incrementing V(S) (for Type-AD frames
             only)

          -  adding the master copy of the frame to the Sent_Queue (for
             Type-AD and Type-BC frames) with the To_Be_Retransmitted_Flag
             NOT set

           -  if the Sent_Queue was previously empty, setting the
             Transmission_Count to "1" (for Type-AD and Type-BC frames)

          -  starting the Timer (for Type-AD and Type-BC frames)

          -  setting the AD_Out (or BC_Out) Flag to "Not_Ready"

          -  passing a copy of the frame (Type-AD or Type-BC) to the
             Lower Layer as a parameter of a "Transmit Request for (AD or
             BC) Frame"

     o     "Transmit Type-BD frame" (i.e., for the Expedited Service),
           includes all the functions necessary to prepare the frame for
           transmission.  In particular it includes

          -  setting the BD_Out_Flag to "Not_Ready"

          -  passing a copy of the Type-BD frame to the Lower Layer as a
             parameter of a "Transmit Request for (BD) Frame"

     o     "Initiate AD (or BC) Retransmission" includes

          -  passing an "Abort" Request to the Lower Layer

          -  incrementing the Transmission_Count
          -  starting the Timer

          -  marking all Type-AD frames (or the Type-BC frame) on the
             Sent_Queue as "To_Be_Retransmitted"

     o     "Remove Acknowledged Frames from Sent_Queue" includes

          -  generating a "Positive Confirm Response to Request to
             Transfer FDU" for each acknowledged frame and deleting the
             frame

          -  updating the value of NN(R)

          -  setting the Transmission_Count to "1"

     o     "Alert" includes

          -  cancelling the Timer

          -  purging the Sent_Queue

          -  purging the Wait_Queue

          -  completing the processing of any "Initiate AD Service"
             Directive by generating a "Negative Confirm" Response for the
             Directive

          -  generating an "Alert" Indication to the Higher Layer

     o     "Look for Directive" includes

          -  checking if the BC_Out_Flag is set to "Ready".  If not, no
             further processing can be performed for retransmitting the
             Type-BC frame until an "Accept" Response is received for the
             outstanding "Transmit Request for (BC) Frame", setting the
             BC_Out_Flag to "Ready".

          -  if the BC_Out_Flag is set to "Ready", checking if the Type-
             BC frame on the Sent_Queue is flagged "To_Be_Retransmitted".
             If so, the flag is set to "Not_Ready" and a copy of the BC
             frame is passed to the Lower Layer as a parameter of a
             "Transmit Request for (BC) Frame".

     o     "Look for FDU" includes

          -  checking if the AD_Out_Flag is set to "Ready".  If not, no
             further processing can be performed for transmitting Type-AD
             frames.  (When an "Accept" Response is received for the
             outstanding "Transmit Request for (AD) Frame", FOP-1 will set
             the AD_Out_Flag to "Ready" and execute a new "Look for FDU".)
          -  if the AD_Out_Flag is set to "Ready", checking if a Type-AD
             frame on the Sent_Queue is flagged "To_Be_Retransmitted".  If
             so, the flag is set to "Not_Ready" and a copy of the first
             such AD frame is passed to the Lower Layer as a parameter of
             a "Transmit Request for (AD) Frame" and the
             To_Be_Retransmitted_Flag for that frame is reset.

          -  if no Type-AD frame is marked "To_Be_Retransmitted",
             checking if both V(S) < NN(R) + K and an FDU is available at
             the AD Service Interface on the Wait_Queue.  If so, the FDU
             is removed from the Wait_Queue, an "Accept Response to
             Request to Transfer FDU" is passed to the Higher Layer and
             the "Transmit" action for an AD frame (see above) is
             performed.

          -  if no FDU is available on the Wait_Queue, no further
             processing is performed.

     o     "Initialise" includes
          -  purging the Sent_Queue
          -  purging the Wait_Queue
          -  setting Suspend_State (SS) to "0"

     o     "Suspend" includes
          -  generating a "Suspend" Indication to the Higher Layer

     o     "Resume" includes
          -  starting the Timer
          -  setting Suspend_State (SS) to "0"

The state tables show the new State value at the bottom of each box (for
example, "(S1)").

References to

     o     Lockout Flag
     o     Wait Flag
     o     Retransmit Flag
     o     N(R)

pertain to the values in the current CLCW.

The FOP-1 table is large and the state transitions complex.  Therefore, the
newcomer may find it helpful to consider initially only the state changes
relating to the main protocol.  This is shown, for the normal situation in
which no exception conditions occur, in Figure 2-3.  This protocol is
capable of handling automatically flow control and error control (providing
the quality of the link is not so low that a maximum of Transmission_Limit
transmissions fail to transfer a frame on board).  It is not capable of
handling improper operation of the spacecraft link, which can be caused,
for example, by two ground stations simultaneously sending frames to the
same spacecraft.
Next, consideration should be given to the initialisation protocol, which
is used to initiate and terminate a session using the AD Service.  This is
shown in Figure 2-4, which shows the main protocol States (S1), (S2) and
(S3) coalesced into a single state.  The FOP-1 State Table (Table 2-1)
distinguishes among many events, all of which should never occur.  If one
of these situations is detected, an "Alert" Indication is passed to the
Higher Layer and FOP-1 enters the "Initial" State (S6).  Except for
Alert[term] after a "Terminate AD Service" Directive, all these traps are
grouped under "Exceptions" in Figure 2-4.

A detailed summary of the way FOP-1 moves between all states is given in
Figure 2-5.


2.5.2   FARM-1

The actions related to the interface between FARM-1 and the Higher Layer
have been covered in Section 2.3.

The FARM-1 State Table (See Table 2-2) expresses the operations to be
performed for each event/state combination.  Description of the state table
format is included in Section 1.3.

Because of space considerations in the table and in order to avoid
repeating the same material several times in the text of this section,
certain terms have been used in the table, and are explained below:

     o     "Valid frame arrives" means that the Frame Validation Check has
           placed a "valid" frame in the front-end buffer.

     o     "Accept" for a Type-AD frame may be subject to a buffer release
           signal from the Higher Layers if the Higher Layer is
           implemented to take advantage of the "Wait" concept.  When no
           AD back-end buffer is available (Event E2), the frame must be
           discarded.

     o     "Accept" for a Type-BD frame means that the data contents of
           the frame (TC FDU) are placed in the back-end buffer even when
           this buffer still contains data, in which case these previous
           data are erased.  The "Wait" concept does not apply to BD
           frames;  the FDU is deemed to have unimpaired access to the
           Higher Layers, and the necessary interfaces must be implemented
           to this effect.

A summary of the way FARM-1 moves between states is given in Figure 2-6.

In Table 2-2, Events E7 and E8 are concerned with the execution of,
respectively, an "Unlock" Control Command and a "Set V(R)" Control Command.
The specification of each action in each box is self-explanatory.  The
action described for Event E8 in State (S3) means that the "Set V(R)"
Control Command is not executed (FARM-1 must be "unlocked" first), but its
receipt is accounted for by means of the FARM-B_Counter since the control
command was validated as "legal" and found "executable".

                                   NOTE

The execution of an "Unlock" Control Command resets only FARM-1, not the
Higher Layers.  Some mechanism should be provided to ensure that the data
management functions of the Higher Layers purge/reset their buffers as
required for spacecraft operations.




                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]

           Figure 2-3:  FOP-1 State Transitions:  Main Protocol






                         [GRAPHIC ELEMENT OMITTED]

      Figure 2-4:  FOP-1 State Transitions:  Initialisation Protocol






                         [GRAPHIC ELEMENT OMITTED]

                   Figure 2-5:  FOP-1 State Transitions





                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]



                         [GRAPHIC ELEMENT OMITTED]

                   Figure 2-6:  FARM-1 State Transitions













                                  ANNEX A

                       COMMAND OPERATION PROCEDURES
                                 GLOSSARY




                (THIS ANNEX IS PART OF THE RECOMMENDATION.)




                                 GLOSSARY


AD, BD,        These abbreviations reflect the state of the "Bypass" and
               "Control Command"
BC             Flags in the Transfer Frame Header:

          1)   Bypass Flag = 0 = A = Acceptance Check.

          2)   Bypass Flag = 1 = B = Bypass of Acceptance Check.

          3)   Control Command Flag = 0 = D = Data.

          4)   Control Command Flag = 1 = C = Control.

It should be noted that only "AD", "BD" and "BC" are legal;  "AC" is an
               illegal combination since control commands cannot reliably
               use a transfer service which they are meant to modify.
               (Detailed definition of these flags is provided in Reference
               [3].)

CLCW           Command Link Control Word (defined in Reference [3])

COP            Command Operation Procedure

COP-1          The particular COP defined in this Recommendation.

FARM           Frame Acceptance and Reporting Mechanism

FARM-1         The particular FARM defined in this Recommendation.

FDU            Frame Data Unit.  The data conveyed in a single Frame Data
               Field.

FOP            Frame Operation Procedure

FOP-1          The particular FOP defined in this Recommendation.

K              FOP_Sliding_Window_Width

LLIF           Lower Layer Interface

N(R)           The Next Expected Frame Sequence Number in a CLCW.

NN(R)          Expected_Acknowledgement_Frame_Sequence_Number.  The value
               of N(R) from the previous CLCW on the same Virtual Channel.

N(S)           The Frame Sequence Number in the Telecommand Transfer Frame
               Header.

NW             FARM_Negative_Window_Width

PW             FARM_Positive_Window_Width

SS             Suspend_State

TC             Telecommand

TT             Timeout_Type

T1_Initial     The initial value to which the countdown Timer is set.

V(R)           Receiver_Frame_Sequence_Number.  The value of N(S) expected
               to be seen by FARM-1 in the next Type-AD frame on the
               Virtual Channel.

V(S)           Transmitter_Frame_Sequence_Number.  The value of the
               Frame_Sequence_ Number, N(S), to be assigned by FOP-1 to the
               next Type-AD frame to be transmitted.

W              FARM_Sliding_Window_Width














                                  ANNEX B

                       COMMAND OPERATION PROCEDURES
                           INTERLAYER INTERFACES




              (THIS ANNEX IS NOT PART OF THE RECOMMENDATION.)




                           INTERLAYER INTERFACES


Communication interfaces are commonly defined in terms of "service
primitives", which may contain parameters.  The relationship among the
different types of service primitives is shown in Figure B-1.

                         [GRAPHIC ELEMENT OMITTED]

                    Figure B-1:  Interlayer Interfaces

A Higher Layer "requests" that an action be taken by the Lower Layer.  The
Lower Layer returns an "Accept" or "Reject" Response, depending on whether
or not it will attempt to execute the request.  The Response does not have
to be issued immediately; the Lower Layer may wait until it has determined
whether it can attempt execution.  For example, FOP-1 does not issue the
"Accept" Response for a Request to Transfer Frame Data Unit (FDU) to its
Higher Layer until it has actually passed the FDU to its Lower Layer.  This
way, the Higher Layer can use the "Accept Response" from one FDU to
initiate the Request to Transfer for the next FDU.

For some requests, it is necessary to know whether the action was
successfully completed.  In these cases, a "Confirm" Response is used in
addition to the "Accept" Response.  A "Positive Confirm" Response means
that the action was successfully completed.  A "Negative Confirm" Response
means either that the action was not successfully completed or that it will
not be possible to determine whether it was successfully completed.  There
may be a considerable time period between the "Accept" Response and the
"Confirm" Response.  For example, if the request is to transfer an FDU
using the Sequence-Controlled Service (AD Service), the "Confirm" Response
will not be issued until receipt of the FDU on board has been acknowledged
by a CLCW ("Positive Confirm") or it has been established that the Sequence-
Controlled Service has failed ("Negative Confirm").
In this document, requests from a sending-end Higher Layer to a Lower Layer
for management activities are referred to as "directives".

Any service primitive from a receiving-end Lower Layer to a Higher Layer is
called an "indication".  An indication is used for delivery of the data
being received.

An indication is also used to provide status information from a sending-end
Lower Layer to a Higher Layer.  For example, an "Alert" Indication is used
to notify the Higher Layer that COP-1 has failed, with a parameter giving
the type of failure.

There are no specific responses defined in this document from the receiving-
end Higher Layer to a Lower Layer.