ISO 22667:2013

INTERNATIONAL ISO
STANDARD 22667
Second edition
2013-06-01
Space data and information transfer
systems — Communications operation
procedure-1
Systèmes de transfert des données et informations spatiales —
Procédure 1 pour les opérations de communication

Reference number
©
ISO 2013
©  ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 22667 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 232.1-B-2, September 2010) and was adopted (without modifications except those stated in Clause 2
of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.
This second edition cancels and replaces the first edition (ISO 22667:2005), which has been technically
revised.
INTERNATIONAL STANDARD ISO 22667:2013(E)

Space data and information transfer systems —
Communications operation procedure-1
1 Scope
1.1 This International Standard specifies the communications operation procedure-1 (COP-1). This
procedure is used with the telecommand (TC) space data link protocol (as defined in ISO 22664:2013) to
enable the delivery of service data units to the receiving end of the layer above, correct and without omission
or duplication, and in the same sequential order in which they were received from the layer above at the
sending end.
1.2 This International Standard defines the COP-1 in terms of
a) the interfaces with the other procedures,
b) the internal variables used by the protocol entity,
c) the actions performed by the protocol entity, and
d) the state transitions of the protocol entity.
1.3 It does not specify
a) individual implementations or products,
b) the implementation of service interfaces within real systems,
c) the methods or technologies required to perform the procedures, or
d) the management activities required to configure and control the protocol.
1.4 The scope and field of application are furthermore detailed in subclauses 1.1, 1.2 and 1.3 of the
enclosed CCSDS publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 232.1-B-2, September 2010, Communications operation procedure-1.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 232.1-B-2.
Pages i to vi
This part is information which is relevant to the CCSDS publication only.
Page 1-5
Add the following information to the reference indicated:
[3] Document CCSDS 232.0-B-2, July 2010, is equivalent to ISO 22664:2013.
3 Revision of publication CCSDS 232.1-B-2
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication CCSDS 232.1-
B-2. To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2013 – All rights reserved

Recommendation for Space Data System Standards
COMMUNICATIONS
OPERATION
PROCEDURE-1
RECOMMENDED STANDARD
CCSDS 232.1-B-2
BLUE BOOK
September 2010
(Blank page)
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
AUTHORITY
Issue: Recommended Standard, Issue 2
Date: September 2010
Location: Washington, DC, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in the Procedures Manual for the
Consultative Committee for Space Data Systems, and the record of Agency participation in
the authorization of this document can be obtained from the CCSDS Secretariat at the
address below.
This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 232.1-B-2 Page i September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. 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 Recommended Standards and are not
considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members 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 Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 232.1-B-2 Page ii September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
FOREWORD
This document is a technical Recommended Standard for use in developing flight and ground
systems for space missions and has been prepared by the Consultative Committee for Space
Data Systems (CCSDS). The Communications Operation Procedure-1 (COP-1) described
herein is intended for missions that are cross-supported between Agencies of the CCSDS.
This Recommended Standard specifies an automatic retransmission procedure to be used by
space missions to transfer space application data over a ground-to-space or space-to-space
communications link. This Recommended Standard has been developed from an existing
CCSDS Recommended Standard that specifies Command Operation Procedure-1
(reference [B2]), which defines essentially the same procedure but in a slightly different
context.
This Recommended Standard does not change the basic technical contents defined in
reference [B2], but the name of the procedure and the presentation of the specification have
been changed so that:
a) COP-1 can be used to transfer any data over any space link in either direction;
b) the specification matches the Open Systems Interconnection (OSI) Basic Reference
Model (references [2] and [3]).
The most notable change in presentation is that COP-1 is defined as a procedure in the Data
Link Layer of the OSI Model in this Recommended Standard, whereas it is defined as a
procedure in the Transfer Layer (a sublayer of the Data Link Layer) in reference [B2].
Together with the change in presentation, a few technical details in reference [B2] have been
changed based upon experience in using this procedure. Also, some technical terms in
reference [B2] have been changed in order to unify the terminology used in all CCSDS
Recommended Standards that define space link protocols. These changes are listed in
annex D of this Recommended Standard.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 232.1-B-2 Page iii September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– Russian Federal Space Agency (RFSA)/Russian Federation.
– UK Space Agency/United Kingdom.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– China Satellite Launch and Tracking Control General, Beijing Institute of Tracking
and Telecommunications Technology (CLTC/BITTT)/China.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
CCSDS 232.1-B-2 Page iv September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
– United States Geological Survey (USGS)/USA.
CCSDS 232.1-B-2 Page v September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
DOCUMENT CONTROL
Document Title Date Status
CCSDS Communications Operation September Original issue
232.1-B-1 Procedure-1, Issue 1 2003
CCSDS Communications Operation September Current issue:
232.1-B-2 Procedure-1, Recommended 2010 – adds text concerning
Standard, Issue 2 a new systematic
retransmission option
(note).
NOTE – Substantive changes from the previous issue are indicated by change bars in the
inside margin.
CCSDS 232.1-B-2 Page vi September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
CONTENTS
Section Page
1 INTRODUCTION. 1-1

1.1 PURPOSE . 1-1
1.2 SCOPE . 1-1
1.3 APPLICABILITY . 1-1
1.4 RATIONALE . 1-2
1.5 DOCUMENT STRUCTURE . 1-2
1.6 CONVENTIONS AND DEFINITIONS . 1-3
1.7 REFERENCES . 1-4

2 OVERVIEW . 2-1

2.1 CONCEPT OF COP-1 . 2-1
2.2 SERVICE TYPES . 2-2
2.3 HOW TO READ THIS DOCUMENT . 2-4

3 INTER-PROCEDURE INTERFACES . 3-1

3.1 DEFINITIONS . 3-1
3.2 INTER-PROCEDURE INTERFACES AT THE SENDING END . 3-1
3.3 INTER-PROCEDURE INTERFACES AT THE RECEIVING END . 3-6

4 DETAILED SERVICE DEFINITION . 4-1

4.1 DIRECTIVE REQUEST . 4-1
4.2 DIRECTIVE NOTIFICATION . 4-3
4.3 ASYNCHRONOUS NOTIFICATION . 4-4
4.4 TRANSFER NOTIFICATION . 4-6

5 FOP-1 . 5-1

5.1 FOP-1 VARIABLES. 5-1
5.2 FOP-1 ACTIONS. 5-10
5.3 FOP-1 STATE TABLE . 5-14

6 FARM-1 . 6-1

6.1 FARM-1 VARIABLES. 6-1
6.2 FARM-1 ACTIONS. 6-6
6.3 FARM-1 STATE TABLE . 6-7

CCSDS 232.1-B-2 Page vii September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
CONTENTS (continued)
Section Page
7 MANAGED PARAMETERS. 7-1

7.1 OVERVIEW OF MANAGED PARAMETERS . 7-1
7.2 FOP-1 MANAGED PARAMETERS . 7-1
7.3 FARM-1 MANAGED PARAMETERS . 7-1

ANNEX A GLOSSARY (INFORMATIVE) . A-1
ANNEX B INFORMATIVE REFERENCES (INFORMATIVE) .B-1
ANNEX C STATE TABLE FORMAT (INFORMATIVE) . C-1
ANNEX D CHANGES FROM REFERENCE [B2] (INFORMATIVE) . D-1
Figure
2-1 COP-1 Variables, Frame and Report Values . 2-3
3-1 Internal Organization of Protocol Entity (Sending End). 3-2
3-2 Internal Organization of Protocol Entity (Receiving End) . 3-7
5-1 FOP-1 State Transitions: Main Protocol . 5-24
5-5 FOP-1 State Transitions: Initialization Protocol . 5-25
5-6 FOP-1 State Transitions . 5-26
6-1 FARM Sliding Window Concept . 6-4
6-2 FARM-1 State Transitions . 6-11
C-1 Mapping of Terms That Have Been Changed .C-1

Table
4-1 Directive Types . 4-2
4-2 Notification Types for DIRECTIVE_Notify.indication . 4-3
4-3 Notification Types for Async_Notify.indication . 4-4
4-4 Reasons for the ‘Alert’ Notification . 4-5
4-5 Notification Types for XXX_Notify.indication . 4-7
4-6 Notification Types for Transfer Notification Signal . 4-7
5-1 FOP-1 State Table . 5-17
6-1 FARM-1 State Table (Part 1) . 6-9
7-1 FOP-1 Managed Parameters . 7-1
7-2 FARM-1 Managed Parameters . 7-2
D-1 Mapping of Terms That Have Been Changed . D-2

CCSDS 232.1-B-2 Page viii September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommended Standard is to specify the Communications Operation
Procedure-1 (COP-1). This procedure is used with the Telecommand (TC) Space Data Link
Protocol (reference [3]) to enable the delivery of service data units to the receiving end of the
layer above, correct and without omission or duplication, and in the same sequential order in
which they were received from the layer above at the sending end.
It is assumed that the reader of this document is familiar with the data structures and
terminology contained in reference [3].
1.2 SCOPE
This Recommended Standard defines the COP-1 in terms of:
a) the interfaces with the other procedures;
b) the internal variables used by the protocol entity;
c) the actions performed by the protocol entity; and
d) the state transitions of the protocol entity.
It does not specify:
a) individual implementations or products;
b) the implementation of service interfaces within real systems;
c) the methods or technologies required to perform the procedures; or
d) the management activities required to configure and control the protocol.
In case of conflict between reference [3] and this Recommended Standard, this
Recommended Standard will take precedence.
1.3 APPLICABILITY
This Recommended Standard applies to the creation of Agency standards and to the future
data communications over space links between CCSDS Agencies in cross-support situations.
This Recommended Standard includes comprehensive specification of the procedure for
inter-Agency cross support. It is neither a specification of, nor a design for, real systems that
may be implemented for existing or future missions.
The recommendation specified in this document is to be invoked through the normal
standards programs of each CCSDS Agency, and is applicable to those missions for which
CCSDS 232.1-B-2 Page 1-1 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
cross support, based on capabilities described in this Recommended Standard, is anticipated.
Where mandatory capabilities are clearly indicated in sections of this Recommended
Standard, they must be implemented when this document is used as a basis for cross support.
Where options are allowed or implied, implementation of these options is subject to specific
bilateral cross support agreements between the Agencies involved.
This Recommended Standard is applicable only to those Projects that implement the TC
Space Data Link Protocol (reference [3]).
1.4 RATIONALE
The CCSDS believes it is important to document the rationale underlying the
recommendations chosen, so that future evaluations of proposed changes or improvements
will not lose sight of previous decisions.
1.5 DOCUMENT STRUCTURE
This document is divided into seven numbered sections and four annexes:
a) section 1 presents the purpose, scope, applicability and rationale of this
Recommended Standard and lists the conventions, definitions, and normative
references used throughout the Recommended Standard;
b) section 2 provides an overview of the COP-1;
c) section 3 describes the interfaces between COP-1 and the other procedures used in the
TC Space Data Link Protocol;
d) section 4 describes the detailed service definition related to COP-1, and complements
the service definition of reference [3];
e) section 5 specifies the Frame Operation Procedure-1 (FOP-1), which is the procedure
used at the sending side of COP-1;
f) section 6 specifies the Frame Acceptance and Reporting Mechanism-1 (FARM-1),
which is the procedure used at the receiving side of COP-1;
g) section 7 specifies the managed parameters used by COP-1;
h) annex A lists all acronyms used within this document;
i) annex B provides a list of informative references;
j) annex C shows the format of the state tables used in sections 5 and 6;
k) annex D lists the changes contained in this Recommended Standard as compared to
the previously issued CCSDS COP Recommended Standard (reference [B2]).
CCSDS 232.1-B-2 Page 1-2 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
1.6 CONVENTIONS AND DEFINITIONS
1.6.1 DEFINITIONS
1.6.1.1 Definitions from Open Systems Interconnection (OSI) Basic Reference Model
This Recommended Standard makes use of a number of terms defined in reference [1]. The
use of those terms in this Recommended Standard shall be understood in a generic sense; i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are:
a) blocking;
b) Data Link Layer;
c) entity;
d) flow control;
e) real system;
f) segmenting;
g) service;
h) Service Access Point (SAP);
i) service data unit.
1.6.1.2 Definitions from OSI Service Definition Conventions
This Recommended Standard makes use of a number of terms defined in reference [2]. The
use of those terms in this Recommended Standard shall be understood in a generic sense; i.e.,
in the sense that those terms are generally applicable to any of a variety of technologies that
provide for the exchange of information between real systems. Those terms are:
a) indication;
b) primitive;
c) request;
d) service provider;
e) service user.
1.6.1.3 Definitions from TC Space Data Link Protocol
This Recommended Standard makes use of the following terms defined in reference [3]:
CCSDS 232.1-B-2 Page 1-3 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
a) Communications Link Control Word (CLCW);
b) Control Command;
c) Frame Data Unit (FDU);
d) Global Virtual Channel Identifier (GVCID);
e) Transfer Frame;
f) Type-A Service;
g) Type-A Transfer Frame;
h) Type-AD Transfer Frame;
i) Type-B Service;
j) Type-B Transfer Frame;
k) Type-BC Transfer Frame;
l) Type-BD Transfer Frame;
m) Virtual Channel Identifier (VCID);
n) Virtual Channel (VC).
1.6.2 NOMENCLATURE
The following conventions apply throughout this Recommended Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.7 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommended Standards.
[1] Information Technology—Open Systems Interconnection—Basic Reference Model: The
Basic Model. International Standard, ISO/IEC 7498-1. 2nd ed. Geneva: ISO, 1994.
CCSDS 232.1-B-2 Page 1-4 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
[2] Information Technology—Open Systems Interconnection—Basic Reference Model—
Conventions for the definition of OSI services. International Standard, ISO/IEC
10731:1994. Geneva: ISO, 1994.
[3] TC Space Data Link Protocol. Recommendation for Space Data System Standards,
CCSDS 232.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, July 2010.
NOTE – Informative references are listed in annex B.

CCSDS 232.1-B-2 Page 1-5 September 2010
(Blank page)
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
2 OVERVIEW
2.1 CONCEPT OF COP-1
The Communications Operation Procedure-1 (COP-1) is a closed-loop procedure executed by
the sending and receiving ends of the TC Space Data Link Protocol (reference [3]). COP-1
utilizes an Automatic Request for Retransmission (ARQ) procedure of the ‘go-back-n’ type
to retransmit Transfer Frames that were rejected by the receiving end of the protocol. COP-1
allows Type-A Transfer Frames to be accepted by the receiving end only if they are received
in strict sequential order. This enables the service data units to be delivered correctly to the
layer above at the receiving end, without omission or duplication, and in the same sequential
order in which they were received from the layer above at the sending end.
COP-1 consists of a pair of synchronized procedures for each Virtual Channel: a Frame
Operation Procedure-1 (FOP-1) that executes within the sending entity, and a Frame
Acceptance and Reporting Mechanism-1 (FARM-1) that executes within the receiving entity.
The FOP-1 transmits Transfer Frames of a particular Virtual Channel to the FARM-1 of the
same Virtual Channel. The FARM-1 returns reports of the status of Transfer Frame
acceptance to the FOP-1 using the Communications Link Control Words (CLCWs).
NOTE – This Recommended Standard states that COP-1 handles ‘Transfer Frames’;
however, these are actually partial Transfer Frames made up of Frame Data Units
(FDUs) plus some parameters in the Transfer Frame Primary Header generated by
COP-1. The Transfer Frame will be generated by the Frame Generation
Procedure, as defined in reference [3]. The Frame Data Unit consists of the data
to be inserted in the Transfer Frame Data Field.
Within COP-1, control of sequentiality is maintained using the Frame Sequence Number,
which must be present in each Type-A Transfer Frame. Type-A Transfer Frames are
transmitted by the FOP-1 with their Frame Sequence Numbers arranged in strict up-counting
order. The FARM-1 permits Type-A Transfer Frames to be accepted only if they are
received bearing Frame Sequence Numbers in the proper up-counting sequential order. Upon
detection of the first sequence error, the FARM-1 will reject all subsequent Type-A Transfer
Frames on that Virtual Channel which do not contain the expected Frame Sequence Number.
FOP-1 initiates retransmission either in response to a ‘Retransmit’ Flag in the CLCW or by
detecting a timeout. FOP-1 performs retransmission by re-sending all unacknowledged
Type-A Transfer Frames on that Virtual Channel. FOP-1 and FARM-1 also have a window
mechanism to prevent a new Transfer Frame with the same Frame Sequence Number as that
of a missing Transfer Frame from being transmitted or accepted.
Valid Type-B Transfer Frames will always be accepted by FARM-1, and processed only to
the extent of incrementing a counter for Type-B Transfer Frames in the CLCW. Type-B
Transfer Frames are also used to send Control Commands from the FOP-1 to the FARM-1.
Both Type-A and Type-B Transfer Frames are protected by the error correction/detection
capability of the underlying Channel Coding Sublayer and also must pass the Frame
CCSDS 232.1-B-2 Page 2-1 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
Validation Check defined in reference [3]. Therefore, Type-B Transfer Frames accepted by
FARM-1 have a very high probability of being error-free. However, their sequentiality is not
controlled by COP-1.
2.2 SERVICE TYPES
NOTE – The TC Space Data Link Protocol provides two service types (Sequence-
Controlled and Expedited) that determine how reliably service data units supplied
by the sending user are delivered to the receiving user. COP-1 provides two
services (Sequence-Controlled Service and Expedited Service) to support these
service types, as described in 2.2.1 and 2.2.2.
2.2.1 SEQUENCE-CONTROLLED SERVICE (AD SERVICE)
The Sequence-Controlled Service (AD Service) is realized by an automatic ARQ procedure
of the ‘go-back-n’ type, with sequence-control mechanisms of both sending and receiving
ends and a standard report returned from the receiving end to the sending end.
For the AD Service, COP-1 ensures with a high probability of success that:
a) no FDU is lost;
b) no FDU is duplicated;
c) no FDU is delivered out of sequence.
Two types of Transfer Frames are used for providing the AD Service:
a) Type-AD Transfer Frames, for carrying FDUs;
b) Type-BC Transfer Frames, for carrying Control Commands for configuring COP-1
(‘Unlock’ and ‘Set V(R)’).
The AD Service is initiated by means of four distinct ‘Initiate AD Service’ Directives. Two
of these Directives result in the transmission of one of the two Control Commands (Type-BC
Transfer 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 it is declared that there is a problem in initiating the
AD Service. The other two Directives allow the AD Service to be started without waiting for
an action by the receiving end (although one requires receiving a good CLCW).
Once COP-1 for a particular Virtual Channel has been initialized for AD Service, FDUs are
inserted into Transfer Frames and transmitted on that Virtual Channel in the order in which
they are presented to COP-1.
CCSDS 232.1-B-2 Page 2-2 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
The AD Service guarantees in-order delivery of FDUs on a single Virtual Channel. Because
of the possibility of retransmission on only a single Virtual Channel, there is no guarantee
that FDUs on separate Virtual Channels, each using the AD Service, will be delivered in the
order initially transmitted.
For the Type-AD Transfer 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 Transfer Frame
Primary Header, N(S) (see figure 2-1). These variables are explained in more detail in
subsections 5.1 and 6.1.
SENDING TRANSFER RECEIVING
END FRAME END
N(S)
V(S)
V(R)
N(R)
FOP-1 FARM-1
CLCW
Figure 2-1: COP-1 Variables, Frame and Report Values
For transferring Type-AD Transfer Frames, if required, a flow control mechanism (‘Wait’
mechanism) is provided that permits the receiving end to signal that it does not have enough
resources to cope with incoming data.
For Type-BC Transfer Frames, COP-1 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.2.2 EXPEDITED SERVICE (BD SERVICE)
The Expedited Service (BD Service) is normally used either in exceptional operational
circumstances, typically during spacecraft recovery operations, or when a higher layer
protocol provides a retransmission capability.
Type-BD Transfer Frames are used for carrying FDUs of the BD Service. Type-BD Transfer
Frames are transmitted only once (i.e., no retransmission). There is no guarantee that all
Type-B FDUs are delivered.
In the FOP-1 at the sending end, Type-BD Transfer Frames are given immediate access in so
far as is permitted by delays in the lower layers and procedures by other traffic on the
CCSDS 232.1-B-2 Page 2-3 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
communications link. At the receiving end, the FDUs carried by Type-BD Transfer Frames
will be passed to the next procedure immediately.
NOTES
1 Some implementations of FARM-1 may use the same buffer to deliver FDUs carried
by either Type-AD or Type-BD Transfer Frames in order to provide increased
reliability through reduced complexity and lower resource consumption. In this case,
when a Type-BD Transfer Frame is received, an FDU in the process of being
delivered or ‘waiting’ to be delivered will be erased, without any indication to the
sending end in the CLCW. For this implementation, the sending end should terminate
any ongoing AD Service before starting a BD Service on the same Virtual Channel.
2 Although the BD mode of transmission carries the name ‘Expedited’, BD mode is
neither a required method nor a faster method for inserting a Transfer Frame for
immediate delivery into a stream of Transfer Frames. If the link currently supports a
reliable AD service, then AD mode is recommended in such cases. Regardless of
whether AD or BD mode is used, the inserted Transfer Frame must not use the same
MAP address as an unfinished, multi-segment packet delivery process (a possible
exception would be delivering a control command to the Packet Assembly Process).
2.3 HOW TO READ THIS DOCUMENT
COP-1 is one of the procedures performed by the protocol entity of the TC Space Data Link
Protocol (reference [3]). Section 3 of this document defines the interfaces between COP-1
and other procedures of the protocol entity that are used to define COP-1 in the succeeding
sections of this document.
COP-1 processes requests submitted by the users of the protocol with request primitives and
generates information to be given to the users with notification primitives (these interactions
with the users are performed indirectly through the Higher Procedures as explained in 3.2.2
and 3.3.2). Section 4 of this document defines details of the request and notification
primitives and complements the service definition of reference [3].
Each end of COP-1 (FOP-1 or FARM-1) is defined as a state machine. A state machine is an
abstract model of a machine that is in a state at a particular instance and transitions to a new
state performing certain actions when an event occurs. Sections 5 and 6 define the state
machine of FOP-1 and FARM-1, respectively. In each of these sections, internal variables
used by the state machine, actions performed by the state machine, and the state table of the
state machine are defined in this order.
Finally, the parameters used for managing COP-1 are specified in section 7.

CCSDS 232.1-B-2 Page 2-4 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
3 INTER-PROCEDURE INTERFACES
3.1 DEFINITIONS
COP-1 is one of the procedures performed by the protocol entity of the TC Space Data Link
Protocol (reference [3]). In order to define the operations of COP-1 completely and clearly, it
is necessary to define some of the characteristics of the interfaces between COP-1 and other
procedures of the protocol entity. This subsection defines the interfaces between COP-1 and
other procedures of the protocol entity that are used to define COP-1 in the succeeding
sections of this document.
The inter-procedure interfaces are defined only for the purpose of specifying the operations of
COP-1 completely and clearly, and are not intended to imply any implementation technology
or hardware/software configuration in a real system.
The inter-procedure interfaces are specified in the form of inter-procedure signals, which
present an abstract model of the logical exchange of data and control information between
procedures. The parameters of the primitives are specified in an abstract sense and specify
the information to be made available to the procedure that uses the signal. The way in which
a specific implementation makes this information available is not constrained by this
specification. In addition to the parameters specified here, an implementation may provide
other parameters (e.g., parameters for controlling activities, monitoring performance,
facilitating diagnosis, and so on).
3.2 INTER-PROCEDURE INTERFACES AT THE SENDING END
3.2.1 INTERNAL ORGANIZATION OF PROTOCOL ENTITY
NOTE – Figure 3-1 shows the internal organization of the TC Space Data Link Protocol
entity at the sending end, together with the interfaces with the other protocols
used with the TC Space Data Link Protocol. The set of procedures performed
above FOP-1 is collectively called the Higher Procedures, and the set of
procedures performed below FOP-1 is collectively called the Lower Procedures.
CCSDS 232.1-B-2 Page 3-1 September 2010
RECOMMENDED STANDARD FOR COMMUNICATIONS OPERATION PROCEDURE-1
User (Higher Layer Protocol)
Service Data Units
Notifications
and Directives
TC Data Link
Protocol
Higher Procedures
CLCWs
FrameOperation Procedure-1 (FOP-1)
Lower Procedures
Protocol Used in the
Opposite Direction
Transfer Frames
Channel Coding and Synchronization

Figure 3-1: Internal Organization of Protocol Entity (Sending End)
3.2.1.1 The users of the TC Space Data Link Protocol shall interact with the protocol entity
through Service Access Points (SAPs) using service primitives defined in reference [3]. The
users shall request the protocol entity to transfer service data units, and shall receive from the
protocol entity notifications associated with the transfer of service data units. The users may
also request the protocol entity to perform Directives defined in section 4.
3.2.1.2 The Higher Procedures shall perform blocking an
...