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.