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
  
                                
                         
        SPACE LINK EXTENSION--FORWARD CLTU
               SERVICE SPECIFICATION
                                
                                
                                
                         CCSDS 912.1-B-1
                                
                            BLUE BOOK
                                
                                
                           April 2002
                                
                        [IMAGE]AUTHORITY

                                       
  Issue:    Blue Book, Issue 1         
  Date:     April 2002                 
  Location: Oberpfaffenhofen,          
            Germany
                                       
                                

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



This Recommendation is published and maintained by:

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


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

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

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

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

   -- The standard itself.
   
   -- The anticipated date of initial operational capability.
   
   -- The anticipated duration of operational service.
   
o  Specific service arrangements shall be made via memoranda of
   agreement. Neither this Recommendation nor any ensuing
   standard is a substitute for a memorandum of agreement.

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

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


This document is a technical Recommendation for use in developing
ground systems for space missions and has been prepared by the
Consultative Committee for Space Data Systems (CCSDS). The Space
Link Extension (SLE) Forward Command Link Transmission Unit
(CLTU) Service described herein is intended for missions that are
cross supported between Agencies of the CCSDS.

This Recommendation specifies a data service that extends certain
of the space-to-ground communications services previously defined
by CCSDS (references [2] and [3]) within the framework
established by the CCSDS SLE Reference Model (reference [1]).  It
allows implementing organizations within each Agency to proceed
with the development of compatible derived Standards for the
ground systems that are within their cognizance. Derived Agency
Standards may implement only a subset of the optional features
allowed by the Recommendation and may incorporate features not
addressed by the Recommendation.
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, as defined in reference
[E1].  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.

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

Member Agencies

  -    Agenzia Spaziale Italiana (ASI)/Italy.
  -    British National Space Centre (BNSC)/United Kingdom.
  -    Canadian Space Agency (CSA)/Canada.
  -    Centre National d'Etudes Spatiales (CNES)/France.
  -    Deutsches Zentrum fuer Luft- und Raumfahrt e.V.
     (DLR)/Germany.
  -    European Space Agency (ESA)/Europe.
  -    Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
  -    National Aeronautics and Space Administration (NASA)/USA.
  -    National Space Development Agency of Japan (NASDA)/Japan.
  -    Russian Space Agency (RSA)/Russian Federation.

Observer Agencies

  -    Austrian Space Agency (ASA)/Austria.
  -    Central Research Institute of Machine Building
     (TsNIIMash)/Russian Federation.
  -    Centro Tecnico Aeroespacial (CTA)/Brazil.
  -    Chinese Academy of Space Technology (CAST)/China.
  -    Commonwealth Scientific and Industrial Research Organization
     (CSIRO)/Australia.
  -    Communications Research Centre (CRC)/Canada.
  -    Communications Research Laboratory (CRL)/Japan.
  -    Danish Space Research Institute (DSRI)/Denmark.
  -    European Organization for the Exploitation of Meteorological
     Satellites (EUMETSAT)/Europe.
  -    European Telecommunications Satellite Organization
     (EUTELSAT)/Europe.
  -    Federal Service of Scientific, Technical & Cultural Affairs
     (FSST&CA)/Belgium.
  -    Hellenic National Space Committee (HNSC)/Greece.
  -    Indian Space Research Organization (ISRO)/India.
  -    Institute of Space and Astronautical Science (ISAS)/Japan.
  -    Institute of Space Research (IKI)/Russian Federation.
  -    KFKI Research Institute for Particle & Nuclear Physics
     (KFKI)/Hungary.
  -    MIKOMTEK:  CSIR (CSIR)/Republic of South Africa.
  -    Korea Aerospace Research Institute (KARI)/Korea.
  -    Ministry of Communications (MOC)/Israel.
  -    National Oceanic & Atmospheric Administration (NOAA)/USA.
  -    National Space Program Office (NSPO)/Taipei.
  -    Space and Upper Atmosphere Research Commission
     (SUPARCO)/Pakistan.
  -    Swedish Space Corporation (SSC)/Sweden.
  -    United States Geological Survey (USGS)/USA.
                        DOCUMENT CONTROL


Document   Title               Date    Status and Substantive
                                       Changes
                                       
CCSDS      Space Link          April   Original Issue
912.1-B-1  Extension--Forward  2002
           CLTU Service
           Specification
                                       

                            CONTENTS
Section                                                   Page

1 INTRODUCTION                                            1-1
  
  1.1PURPOSE OF THIS RECOMMENDATION                      1-1
  1.2SCOPE                                               1-1
  1.3APPLICABILITY                                       1-1
  1.4RATIONALE                                           1-2
  1.5DOCUMENT STRUCTURE                                  1-2
  1.6DEFINITIONS, NOMENCLATURE, AND CONVENTIONS          1-4
  1.7REFERENCES                                         1-12

2 DESCRIPTION OF THE FORWARD CLTU SERVICE                 2-1
  
  2.1OVERVIEW                                            2-1
  2.2SPACE LINK EXTENSION REFERENCE MODEL                2-2
  2.3SERVICE MANAGEMENT                                  2-3
  2.4ARCHITECTURE MODEL - FUNCTIONAL VIEW                2-4
  2.5ARCHITECTURE MODEL - CROSS-SUPPORT VIEW             2-6
  2.6FUNCTIONAL DESCRIPTION                              2-8
  2.7OPERATIONAL SCENARIO                               2-15

3 OPERATIONS AND THEIR PARAMETERS                         3-1
  
  3.1GENERAL CONSIDERATIONS                              3-1
  3.2CLTU-BIND                                           3-7
  3.3CLTU-UNBIND                                        3-14
  3.4CLTU-START                                         3-17
  3.5CLTU-STOP                                          3-21
  3.6CLTU-TRANSFER-DATA                                 3-24
  3.7CLTU-ASYNC-NOTIFY                                  3-30
  3.8CLTU-SCHEDULE-STATUS-REPORT                        3-36
  3.9CLTU-STATUS-REPORT                                 3-40
  3.10    CLTU-GET-PARAMETER                             3-45
  3.11    CLTU-THROW-EVENT                               3-49
  3.12    CLTU-PEER-ABORT                                3-53

4 CLTU PROTOCOL                                           4-1
  
  4.1GENERIC PROTOCOL CHARACTERISTICS                    4-1
  4.2CLTU SERVICE PROVIDER BEHAVIOR                      4-4

                      CONTENTS (CONTINUED)
Section                                                   Page

ANNEX A DATA TYPE DEFINITIONS                              A-1
ANNEX B INDEX TO DEFINITIONS                               B-1
ANNEX C ACRONYMS                                           C-1
ANNEX D CONFORMANCE OPTIONS MATRIX                         D-1
ANNEX E INFORMATIVE REFERENCES                             E-1
ANNEX F THROW EVENT DEFINITIONS                            F-1
ANNEX G PRODUCTION STATUS                                  G-1

Figure

1-1Space Link Extension (SLE) Services Documentation      1-4
2-1Forward TC Space Link Processing SLE-FG                2-4
2-2Forward CLTU Service Production and Provision          2-6
2-3Example of Management and Provision of Forward CLTU Service 2-
   7
2-4Forward CLTU Service Provider State Transition Diagram2-10
2-5Communications Realization of Forward CLTU Service    2-13
G-1CLTU Production Status Transitions                     G-1

Table

2-1Forward CLTU Service Operations                        2-9
3-1Setting of Forward CLTU Service Configuration Parameters3-7
3-2CLTU-BIND Parameters                                   3-8
3-3CLTU-UNBIND Parameters                                3-15
3-4CLTU-START Parameters                                 3-17
3-5CLTU-STOP Parameters                                  3-21
3-6CLTU-TRANSFER-DATA Parameters                         3-24
3-7CLTU-ASYNC-NOTIFY Parameters                          3-30
3-8CLTU-SCHEDULE-STATUS-REPORT Parameters                3-36
3-9CLTU-STATUS-REPORT Parameters                         3-40
3-10                             CLTU-GET-PARAMETER Parameters 3-
   45
3-11                                   Forward CLTU Parameters 3-
   47
3-12                               CLTU-THROW-EVENT Parameters 3-
   50
3-13                                CLTU-PEER-ABORT Parameters 3-
   53
4-1Behavior of Provider                                   4-7
4-2Event Description References                          4-10
4-3Predicate Definitions                                 4-10
4-4Boolean Flags                                         4-11
4-5Compound Action Definitions                           4-11
                      CONTENTS (CONTINUED)
Table                                                     Page

D-1Conformance Matrix for CLTU Service (Operations)       D-1
D-2Conformance Matrix for CLTU Service (Other Requirements)D-2
F-1Throw Event Examples                                   F-1
G-1Production Status Changes and Notifications            G-2
G-2Effect of Production Status on Operations              G-3


1    INTRODUCTION
1.1  PURPOSE OF THIS RECOMMENDATION
This Recommendation defines the Command Link Transmission Unit
(CLTU) service in conformance with the transfer services
specified in reference [1], Cross Support Reference Model--Part
1: SLE Services. The Forward CLTU service is a Space Link
Extension (SLE) transfer service that enables a mission to send
Command Link Transmission Units (CLTUs) to a spacecraft.


1.2  SCOPE
1.2.1     This Recommendation defines, in an abstract manner, the
Forward CLTU service in terms of:
  
  a)   the operations necessary to provide the transfer service;
  
  b)   the parameter data associated with each operation;
  
  c)   the behaviors that result from the invocation of each
     operation; and
  
  d)   the relationship between, and the valid sequence of, the
     operations and resulting behaviors.
1.2.2     It does not specify:
  
  a)   individual implementations or products;
  
  b)   the implementation of entities or interfaces within real
     systems;
  
  c)   the methods or technologies required to radiate data to a
     spacecraft and to acquire telemetry frames from the signals
     received from the spacecraft for extraction of the Operational
     Control Field;
  
  d)   the methods or technologies required for communications;
  
  e)   the management activities necessary to schedule, configure,
     and control the Forward CLTU service.


1.3  APPLICABILITY
1.3.1     APPLICABILITY OF THIS RECOMMENDATION
This Recommendation provides a basis for the development of real
systems that implement the Forward CLTU service. Implementation
of the Forward CLTU service in a real system additionally
requires the availability of a communications service to convey
invocations and returns of Forward CLTU service operations
between service users and providers. This Recommendation requires
that such a communications service ensure that invocations and
returns of operations are transferred:
  
  a)   in sequence;
  
  b)   completely and with integrity;
  
  c)   without duplication;
  
  d)   with flow control that notifies the application layer in the
     event of congestion;  and
  
  e)   with notification to the application layer in the event that
     communications between the Forward CLTU service user and the
     Forward CLTU service provider are disrupted, possibly resulting
     in a loss of data.

It is the specific intent of this Recommendation to define the
Forward CLTU service in a manner that is independent of any
particular communications services, protocols, or technologies.


1.3.2     LIMITS OF APPLICABILITY
This Recommendation specifies the Forward CLTU service that may
be provided by an SLE System for inter-Agency cross support.  It
is neither a specification of, nor a design for, real systems
that may be implemented for the control and monitoring of
existing or future missions.


1.4  RATIONALE
The goal of this Recommendation is to create a standard for
interoperability between the tracking stations or ground data
handling systems of various agencies and the users of forward
services.


1.5  DOCUMENT STRUCTURE
1.5.1     DOCUMENT ORGANIZATION
This Recommendation is organized as follows:
  
  a)   section 1 provides purpose, scope, applicability, and
     rationale of this Recommendation and lists definitions,
     nomenclature, conventions, and references used throughout the
     Recommendation;
  
  b)   section 2 presents an overview of the Forward CLTU service
     including a functional description, the service management
     context, and protocol considerations;
  
  c)   section 3 specifies the operations of the Forward CLTU
     service;
  
  d)   section 4 specifies the dynamic behavior of the Forward CLTU
     service in terms of the state transitions of the Forward CLTU
     service provider;
  
  e)   annex A is a formal specification of Forward CLTU service
     data types, using the Abstract Syntax Notation One (ASN.1);
  
  f)   annex B lists all terms used in this document and identifies
     where they are defined;
  
  g)   annex C lists all acronyms used within this document;
  
  h)   annex D provides a conformance matrix that defines what
     capabilities must be provided for an implementation to be
     considered compliant with this Recommendation;
  
  i)   annex E contains a list of informative references;
  
  j)   annex F contains examples of usage of the CLTU-THROW-EVENT
     operation;
  
  k)   annex G explains the relationship of the Forward CLTU
     service to the status of the forward space link channel.


1.5.2     SLE SERVICES DOCUMENTATION TREE
This Recommendation is based on the architectural model for cross
support defined in the SLE Reference Model (reference [1]). It
expands upon the concept of an SLE transfer service as
interactions between SLE Mission User Entities (MUEs) and an SLE
transfer service provider for the purpose of providing the
Forward CLTU transfer service.
This Recommendation is part of a suite of documents specifying
the SLE Services.  The SLE Services constitute one of the three
types of Cross Support Services:
  
  a)   Part 1:  SLE Services;
  
  b)   Part 2:  Ground Communications Services;
  
  c)   Part 3:  Ground Domain Services.
The basic organization of the SLE services documentation is shown
in figure 1-1.  The documents are described in the following
paragraphs.
                             [IMAGE]
 Figure 1-1:  Space Link Extension (SLE) Services Documentation
  
  a)   Standard Terminology, Conventions and Methodology (TCM) for
     Defining Data Services (reference [E3]): a Report identifying
     selected international standards relevant for the definition of
     data services;
  
  b)   Cross Support Concept - Part 1:  Space Link Extension
     Services (reference [E4]): a Report introducing the concepts of
     cross support and SLE services;
  
  c)   Cross Support Reference Model--Part 1: Space Link Extension
     Services (reference [1]): a Recommendation that defines the
     framework and terminology for the specification of SLE services;
  
  d)   SLE Service Management Specification Suite; a set of
     Recommendations that establish the basis for SLE service
     management (reference [E5] is the primary Recommendation in that
     set);
  
  e)   Forward SLE Transfer Service Specifications; a set of
     Recommendations that will provide specification of all forward
     link SLE transfer services (this Recommendation is one of the
     specifications in that set);
  
  f)   Return SLE Transfer Service Specifications; a set of
     Recommendations that will provide specification of all return
     link SLE transfer services.


1.6   DEFINITIONS, NOMENCLATURE, AND CONVENTIONS
1.6.1     DEFINITIONS
1.6.1.1   Definitions from OSI Basic Reference Model
This Recommendation makes use of a number of terms defined in
reference [7]. The use of those terms in this Recommendation
shall be understood in a generic sense; i.e., in the sense that
those terms are generally applicable to technologies that provide
for the exchange of information between real systems.  Those
terms are:
  
  a)   abstract syntax;
  
  b)   application entity;
  
  c)   application layer;
  
  d)   flow control;
  
  e)   Open System Interconnection (OSI);
  
  f)   real system;
  
  g)   service access point (SAP).


1.6.1.2   Definitions from OSI Abstract Syntax Notation One
This Recommendation makes use of the following terms defined in
reference [6]:
  
  a)   Abstract Syntax Notation One (ASN.1);
  
  b)   object identifier;
  
  c)   (data) type;
  
  d)   (data) value.
NOTE        In annex A of this Recommendation, ASN.1 is used for
       specifying the abstract syntax of the invocations and
       returns of the operations of the Forward CLTU service.
       The use of ASN.1 as a descriptive language is intended to
       support the specification of the abstract Forward CLTU
       service; it is not intended to constrain implementations.
       In particular, there is no requirement for
       implementations to employ ASN.1 encoding rules. ASN.1 is
       simply a convenient tool for formally describing the
       abstract syntax of the invocations and returns of the
       Forward CLTU service.


1.6.1.3   Definitions from OSI Directory - Part 2: Models
This Recommendation makes use of the following terms defined in
reference [8]:
  
  a)   distinguished name (DN);
  
  b)   relative distinguished name (RDN).


1.6.1.4   Definitions from CCSDS Telecommand Channel Service
This Recommendation makes use of the following terms defined in
reference [2]:
  
  a)   acquisition sequence;
  
  b)   command link transmission unit (CLTU);
  
  c)   carrier modulation mode (CMM);
  
  d)   idle sequence;
  
  e)   physical layer operations procedure (PLOP).


1.6.1.5   Definitions from CCSDS Telecommand Data Routing Service
This Recommendation makes use of the following term defined in
reference [3]:
  
  command link control word (CLCW).


1.6.1.6   Definitions from CCSDS SLE Reference Model
This Recommendation makes use of the following terms defined in
reference [1]:
  
  a)   abstract binding;
  
  b)   abstract object;
  
  c)   abstract port;
  
  d)   abstract service;
  
  e)   CLTU channel;
  
  f)   Forward CLTU service;
  
  g)   invoker;
  
  h)   Mission Data Operation System (MDOS);
  
  i)   Mission User Entity (MUE);
  
  j)   offline delivery mode;
  
  k)   online delivery mode;
  
  l)   operation;
  
  m)   performer;
  
  n)   physical channel;
  
  o)   service agreement;
  
  p)   service provider (provider);
  
  q)   service user (user);
  
  r)   SLE Complex;
  
  s)   SLE Complex Management;
  
  t)   SLE data channel;
  
  u)   SLE functional group (SLE-FG);
  
  v)   SLE protocol data unit (SLE-PDU);
  
  w)   SLE service data unit (SLE-SDU);
  
  x)   SLE service package;
  
  y)   SLE System;
  
  z)   SLE transfer service instance;
  
  aa)  SLE transfer service production;
  
  bb)  SLE transfer service provision;
  
  cc)  SLE Utilization Management;
  
  dd)  space link;
  
  ee)  space link data channel;
  
  ff)  space link data unit (SL-DU);
  
  gg)  space link session.


1.6.1.7   Additional Definitions
1.6.1.7.1 General
For the purposes of this Recommendation, the following
definitions also apply.


1.6.1.7.2 Association
An association is a cooperative relationship between an SLE
service-providing application entity and an SLE service-using
application entity. An association is formed by the exchange of
SLE protocol data units through use of an underlying
communications service.


1.6.1.7.3 Communications Service
A communications service is a capability that enables an SLE
service-providing application entity and an SLE service-using
application entity to exchange information.
NOTE   -    If an SLE service user and an SLE service provider
       are implemented using different communications services,
       then interoperability between them is possible only by
       means of a suitable gateway.  Adherence to this
       Recommendation ensures, at least in principle, that it is
       possible to construct such a gateway.


1.6.1.7.4 Confirmed Operation
A confirmed operation is an operation that requires the performer
to return a report of its outcome to the invoker.


1.6.1.7.5 Initiator
The initiator is the object that issues the request to bind to
another object (the responder).


1.6.1.7.6 Invocation
The invocation of an operation is the making of a request by an
object (the invoker) to another object (the performer) to carry
out the operation.


1.6.1.7.7 Parameter
A parameter of an operation is data that may accompany the
operation's invocation or return.
NOTE   -    The term parameter is also used to refer to mission-
       dependent configuration information used in production or
       provision of the service.


1.6.1.7.8 Performance
The performance of an operation is the carrying out of the
operation by an object (the performer).


1.6.1.7.9 Port Identifier
A port identifier identifies a source or a destination in a
communications system.
NOTE   -    See 2.6.4.6 for more information.


1.6.1.7.10     Responder
The responder is the object that receives a request to bind and
completes the binding (if possible) with the initiator in order
for a service association to exist between the two objects.


1.6.1.7.11     Return
The return of an operation is a report, from the performer to the
invoker, of the outcome of the performance of the operation.


1.6.1.7.12     Service Instance Provision Period
The service instance provision period is the time during which a
service instance (i.e., the capability to transfer one or more
SLE data channels of a given type) is scheduled to be provided.


1.6.1.7.13      Unconfirmed Operation
An unconfirmed operation is an operation that does not require a
report of its outcome to be returned to the invoker by the
performer.


1.6.2     NOMENCLATURE
The following conventions apply throughout this Recommendation:
  
  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.6.3     CONVENTIONS
1.6.3.1   Specification of Operations
1.6.3.1.1 General
Section 3 of this Recommendation specifies the operations that
constitute the Forward CLTU service. The specification of each
operation is divided into subsections as follows:


1.6.3.1.2 Purpose Subsection
The Purpose subsection briefly describes the purpose and
functioning of the operation.  Additionally, it indicates whether
the operation may be invoked by the user, provider, or both;
whether the operation is confirmed or unconfirmed; and whether
there are any constraints on when the operation may be invoked.


1.6.3.1.3 Invocation, Return, and Parameters Subsection
The Invocation, Return, and Parameters subsection describes the
parameters associated with each operation, including their
semantics. A table accompanying the description of each operation
lists all parameters associated with the operation and, for both
the invocation and return, whether the parameter is always
present, always absent, or conditionally present.
For parameters that are conditionally present, the parameter
description specifies the conditions for the presence or absence
of the parameter.  The condition is generally based on the value
of another parameter in the same invocation or return; for
example, in return of an operation, the parameter diagnostic is
present if and only if the value of the parameter result is
'negative result'.  For a conditional parameter in a return, the
condition may be based on the value of a parameter in the
corresponding invocation.
In the table, the following convention is used to indicate
whether a parameter is always present, always absent, or
conditionally present:
  
  M      Always present (Mandatory)
  
  C      Conditionally present
  
  Blank  Always absent
NOTE   -    Even though a parameter may be characterized as
       always present, its description may specify that its
       value is permitted to be 'null' or 'unused' or the like.


1.6.3.1.4 Effects Subsection
The Effects subsection describes the effects an operation has on
the invoker, the performer, the association between them, or any
combination thereof. The details of how those effects occur or
the mechanisms used are outside the scope of this Recommendation.


1.6.3.2   Typographic Conventions
1.6.3.2.1 Operation Names
Names of Forward CLTU service operations always appear in
uppercase and begin with the characters 'CLTU-' (e.g., CLTU-
TRANSFER-DATA).


1.6.3.2.2 Parameter Names
In the main text, names of parameters of Forward CLTU service
operations generally appear in lowercase and are always typeset
in a fixed-width font (e.g., responder-port-identifier). In annex
A, the corresponding name is generally formed by omitting any
hyphens contained in the name and using mixed-case (e.g.,
responderPortIdentifier).


1.6.3.2.3 Value Names
The values of many parameters discussed in this Recommendation
are represented by names. In the main text, these names are shown
in single quotation marks (e.g., 'no such service instance'). The
corresponding name in annex A is generally formed by omitting any
hyphens or white space contained in the name and using mixed-case
(e.g., noSuchServiceInstance). The actual value associated with
the name is constrained by the type of the parameter taking on
this value. Parameter types are specified in annex A of this
Recommendation.
NOTE   -    The name of a value does not imply anything about
       type.  For example, the value 'no such service instance'
       has the appearance of a character string but might be
       assigned to a parameter whose type is 'integer'.


1.6.3.2.4 State Names
This Recommendation specifies the states of Forward CLTU service
providers.  States may be referred to by number (e.g., state 3)
or by name. State names are always shown in single quotation
marks (e.g., 'active').


1.6.3.2.5 SLE-PDU Names
The names of SLE-PDUs appear in mixed-case (e.g.,
cltuBindInvocation).


1.6.3.2.6 Data Type Definitions
Data type definitions for the Forward CLTU service are presented
in annex A in the form of a set of ASN.1 modules.  Regardless of
the conventions used elsewhere in this Recommendation, the text
of the ASN.1 modules is typeset entirely in a fixed-width font.


1.6.3.3   Other Conventions
This Recommendation uses the conventions specified in reference
[1].


1.7  REFERENCES
The following documents contain provisions which, through
reference in this text, constitute provisions of this
Recommendation.  At the time of publication, the editions
indicated were valid. All documents are subject to revision, and
users of this Recommendation 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 Recommendations.
NOTE   -    A list of informative references forms annex E of
       this Recommendation.
[1]Cross Support Reference Model -- Part 1: Space Link Extension
   Services.  Recommendation for Space Data System Standards,
   CCSDS 910.4-B-1.  Blue Book.  Issue 1.  Washington, D.C.:
   CCSDS, May 1996.
[2]Telecommand Part 1--Channel Service.  Recommendation for
   Space Data System Standards, CCSDS 201.0-B-3.  Blue Book.
   Issue 3.  Washington, D.C.: CCSDS, June 2000.
[3]Telecommand Part 2--Data Routing Service.  Recommendation for
   Space Data System Standards, CCSDS 202.0-B-3.  Blue Book.
   Issue 3.  Washington, D.C.: CCSDS, June 2001.
[4]Telecommand Part 2.1--Command Operation Procedures.
   Recommendation for Space Data System Standards, CCSDS 202.1-B-
   2.  Blue Book.  Issue 2.  Washington, D.C.: CCSDS, June 2001.
[5]Time Code Formats.  Recommendation for Space Data System
   Standards, CCSDS 301.0-B-3.  Blue Book.  Issue 3.
   Washington, D.C.: CCSDS, January 2002.
[6]Information Technology--Open Systems Interconnection--
   Specification of Abstract Syntax Notation One (ASN.1).
   International Standard, ISO/IEC 8824:1990.  2nd ed.  Geneva:
   ISO, 1990.
[7]Information Technology--Open Systems Interconnection--Basic
   Reference Model:  The Basic Model.  International Standard,
   ISO/IEC 7498-1.  2nd ed.  Geneva:  ISO, 1994.
[8]Information Technology--Open Systems Interconnection--The
   Directory:  Models.  International Standard, ISO/IEC 9594-
   2:1998.  3rd ed.  Geneva:  ISO, 1998.
2    DESCRIPTION OF THE FORWARD CLTU SERVICE
2.1  OVERVIEW
The Forward CLTU service enables the user of the service to send
Command Link Transmission Units (CLTUs) to a spacecraft via an
established forward space link channel. A forward space link
channel is a physical channel carrying an asynchronous stream of
CLTUs (reference [1]).
The service user submits CLTUs, encapsulated in Space Link
Extension (SLE) Service Data Units (SLE-SDUs), by means of the
CLTU-TRANSFER-DATA operation. Production of the Forward CLTU
service by the provider entails processing the CLTUs transferred
by the user through the necessary transformations to modulate the
Radio Frequency (RF) carrier channel providing uplink
communications with the spacecraft.
The Forward CLTU service transmits the CLTUs in the order in
which they are submitted by the service user. The provider may
perform checks to determine if the CLTU complies with applicable
constraints, e.g., that the length of the CLTU is within the
maximum size set by service management. However, the provider
does not interpret, interrogate, or modify the contents of a
CLTU. CLTUs are transmitted bit for bit as received from the
service user.
CLTUs may or may not conform to the format defined in reference
[2]. The Forward CLTU service may be used to uplink any octet-
aligned bit pattern.
The operations defined in section 3 of this Recommendation enable
a single Forward CLTU service user to interact with a Forward
CLTU service provider to:
  
  a)   establish an association between the user and the provider;
  
  b)   send annotated CLTUs to the provider;
  
  c)   obtain notifications and reports regarding status,
     configuration, and performance of the service;
  
  d)   temporarily stop and later re-start the sending of CLTUs;
  
  e)   release an association.
The Sequence Controlled (AD) and Expedited (BD) Services, as
defined in the Command Operation Procedures (COP) Recommendation
(reference [4]) are accomplished by higher layer SLE services.
The Forward CLTU service is provided only in the online delivery
mode, as defined in reference [1]. The offline delivery mode is
the subject of further study.
The provision of Forward CLTU service for access to one physical
channel by one service user constitutes one instance of service.
Only a single service instance of the Forward CLTU service may
exist per physical channel at a time.


2.2  SPACE LINK EXTENSION REFERENCE MODEL
2.2.1     INTRODUCTION
The Forward CLTU service is specified within the framework
defined by the SLE Reference Model (reference [1]).  The
following paragraphs summarize selected concepts from the SLE
reference model.


2.2.2     ABSTRACT OBJECT
An abstract object is a functional entity that interacts with
other abstract objects.  Objects are of different types, which
determine their function and behavior.  An object  is
characterized by its interfaces (one or more), which are called
abstract ports, and the operations that are made available
through those interfaces.


2.2.3     ABSTRACT SERVICE
An abstract service is the capability provided by a set of
operations that an abstract object exposes at one or more of its
abstract ports.1


2.2.4     ABSTRACT BINDING
When two abstract ports have an association established between
them, they are said to be bound.  The act of establishing such an
association is called abstract binding. One object (the
initiator) invokes a bind operation which is accepted (or
rejected) by another object (the responder).


2.2.5     SERVICE USER/PROVIDER
An object that offers a service to another by means of one or
more of its ports is called a service provider (provider).  The
other object is called a service user (user).  An object may be a
provider of some services and a user of others.
The terms user and provider are used to distinguish the roles of
two interacting objects.  In this Recommendation, when two
objects are involved in provision of a service, the object closer
to the space link is considered to be the provider of the
service, and the object further from the space link is considered
to be the user.


2.2.6     OPERATION
An operation is a procedure or task that one object (the invoker)
can request of another (the performer) through a bound port pair.
The terms invoker and performer are used to describe the
interaction between two objects as the operations that constitute
the service occur.  One object invokes an operation that is
performed by the other.  For most services, each object invokes
some operations and performs others.


2.3  SERVICE MANAGEMENT
2.3.1     INTRODUCTION
Service management determines the number and schedule of Forward
CLTU service instances to be provided, the resources required to
enable those service instances, and the initial configuration of
all service instances and their supporting resources. SLE service
management is the subject of separate CCSDS Recommendations.
The SLE Reference Model (reference [1]) distinguishes between
service provision and service production:
  
  a)   service provision makes available to the user the operations
     necessary to obtain the service;
b)   service production transforms the Forward CLTU data channel
to the RF carrier channel.


2.3.2     CONFIGURATION
Service Management provides initial values of configuration
parameters. Certain configuration parameters are associated with
provision of Forward CLTU service while others are associated
with production.  Configuration parameters that are associated
with the production, such as bit rate and modulation index, can
potentially impact SLE Complex resources.  Consequently, only
service management may modify production configuration parameter
values. The Forward CLTU service user may modify some provision
configuration parameters through operations specified in this
Recommendation.


2.4  ARCHITECTURE MODEL - FUNCTIONAL VIEW
2.4.1     FORWARD TC SPACE LINK PROCESSING SLE FUNCTIONAL GROUP
The Forward Telecommand (TC) Space Link Processing SLE Functional
Group (SLE-FG) (shown in figure 2-1) produces the Forward CLTU
service.
As described in reference [1], the Forward TC Space Link
Processing SLE-FG consumes one CLTU data channel consisting of a
stream of CLTU SLE-SDUs. The SLE-SDUs that encapsulate the CLTUs
contain control and annotation data that specify radiation time
and other parameters to aid in processing the data (see 3.6). The
Forward TC Space Link Processing SLE-FG uses these data to
extract the CLTUs and inject them into the asynchronous physical
channel.
NOTE   -    Per physical forward channel, only a single instance
       of the Forward CLTU service is supported at any point in
       time.
                                
                                
                             [IMAGE]
      Figure 2-1:  Forward TC Space Link Processing SLE-FG


The Forward TC Space Link Processing SLE-FG performs the
following functions with respect to the Forward CLTU service:
  
  a)   consumes one CLTU data channel and extracts CLTUs
     encapsulated in SLE Service Data Units (SLE-SDUs);
  
  b)   consumes one Operational Control Field (OCF) data channel
     and extracts the Command Link Control Words (CLCWs). Based on the
     values in the CLCWs, the Forward CLTU service determines whether
     the physical channel is available;
  NOTE   -    CLCWs may be ignored, as an option set by Service
          Management. See 3.1.10 and table 3-11.
  
  c)   performs the following:
     
     1)   generates the acquisition sequence and idle sequence on the
       physical channel in accordance with the PLOP in effect;
     
     2)   utilizes the underlying antenna steering capabilities
       provided by the ground element;
     
     3)   modulates the CLTUs as a stream of bits on the ground-to-
       space RF channel; and
     
     4)   radiates the signal to the spacecraft.


2.4.2     FORWARD CLTU SERVICE PRODUCTION AND PROVISION
Forward CLTU production is concerned with radiating CLTUs
extracted from a stream of SLE-SDUs according to the CLTU control
and annotation information in the SLE-SDU and according to the
configuration set up by service management. Forward CLTU service
provision is concerned with receiving a stream of SLE-SDUs from a
Forward CLTU service user.  Service provision addresses such
matters as when service is provided (e.g., service start and stop
times), and how service is provided (e.g., which events are
notified to the user).
The SLE-SDUs consumed by the Forward CLTU service are sent by the
service user by means of the Forward CLTU service operations
defined in section 3. These operations also provide additional
functionality to facilitate the provision of service, i.e.,
enabling the exchange of SLE-SDUs across a remote interface. The
service operations are realized as SLE protocol data units (SLE-
PDUs) which are exchanged between the Forward CLTU service
provider and the Forward CLTU service user by means of an
underlying communications service. The general relationship
between SL-DUs, SLE-SDUs, and SLE-PDUs is illustrated in figure
2-2.
NOTE   -    SLE-SDUs correspond to the parameters of the CLTU-
       TRANSFER-DATA and CLTU-ASYNC-NOTIFY operations defined in
       section 3. SL-DUs correspond to the radiated CLTUs.
                             [IMAGE]
   Figure 2-2:  Forward CLTU Service Production and Provision


Production of the Forward CLTU service by the provider occurs
during the space link session; in general, service production
will largely overlap with service provision. Production status
affects the provision of the service, as specified in sections 3
and 4, and reviewed in annex G.


2.5  ARCHITECTURE MODEL - CROSS-SUPPORT VIEW
The management and control of the production and provision of the
SLE transfer services is described in general terms in reference
[1]. Figure 2-3 shows an example operational scenario and the
related binding of the Forward CLTU transfer service ports and
SLE management ports. This example shows an SLE Complex with one
Forward Space Link Processing SLE-FG instance; it is providing
one instance of Forward CLTU service to a Mission Data Operations
System (MDOS). As this figure shows, only a single Mission User
Entity can use the Forward CLTU service provided by a single
Forward Space Link Processing SLE-FG.
                             [IMAGE]
Figure 2-3:  Example of Management and Provision of Forward CLTU
                             Service
2.6  FUNCTIONAL DESCRIPTION
2.6.1     INTRODUCTION
This subsection describes the Forward CLTU service with respect
to scheduling, configuration, underlying services, provider
states and protocol considerations.


2.6.2     SCHEDULING AND CONFIGURATION
The management of the SLE Complex that is providing the Forward
CLTU service negotiates with SLE Utilization Management of the
MDOS to establish mutually agreed upon SLE service packages.
Among other things, SLE service packages specify the services to
be provided, the schedules of service instances, and the
resources needed to enable those services.
Service packages also specify the initial values of the mission-
dependent parameters required for service production and
provision. Forward CLTU service production parameters include
such things as bit rate, modulation index, and subcarrier
frequency. Provision parameters include such things as scheduled
start and stop times of the Forward CLTU service instance.
Service production is guaranteed to occur only as needed to
support service packages that have been scheduled and mutually
agreed upon by SLE Complex Management and SLE Utilization
Management.  Service provision occurs only within the bounds of
the agreed upon schedule of service instances and only during
those periods when there is an association between the service
provider and the service user.


2.6.3     UNDERLYING SERVICES
The CLTU service does not depend on any other SLE transfer
service.  Provision of the CLTU  Transfer service does depend on:
  
  a)   service management for scheduling, resources, and
     configuration; the schedule for a Forward CLTU service instance
     must be compliant with the schedule of the underlying equipment
     such as antennas, etc. The Forward CLTU service relies on service
     management actions for establishment of the space link,
     management of the PLOP and, when possible, recovery from
     production interruption;
  
  b)   the availability of a suitable communications service to
     enable the exchange of information between the CLTU service user
     and provider; and
  
  c)   the functioning of CLTU production resources (e.g.,
     modulator(s), up-converter) to produce the forward physical
     channel.


2.6.4     PROTOCOL DESCRIPTION
2.6.4.1   CLTU Operations
The operations that constitute the Forward CLTU service are
listed in table 2-1. Section 3 of this Recommendation contains
the detailed specification of these operations.
                                
                                
           Table 2-1:  Forward CLTU Service Operations
                                
    Service       Invok             Purpose              Con-
   Operation      ed By                                 firme
                                                          d
CLTU-BIND         User   To establish an association     Yes
                         with the provider
CLTU-UNBIND       User   To release an association       Yes
                         previously established by a
                         CLTU-BIND operation
CLTU-START        User   To request that the SLE         Yes
                         service provider prepare to
                         accept CLTU-TRANSFER-DATA
                         operations
CLTU-STOP         User   To request that the SLE         Yes
                         service provider stop service
                         provision and production.
CLTU-TRANSFER-    User   To transfer a CLTU to the       Yes
DATA                     service provider
CLTU-ASYNC-       Provi  To notify the user of an event   No
NOTIFY             der   affecting production or
                         provision of the Forward CLTU
                         service
CLTU-SCHEDULE-    User   To request that the provider    Yes
STATUS-REPORT            send a status report
                         immediately or periodically,
                         or stop reporting
CLTU-STATUS-      Provi  To send a status report to the   No
REPORT             der   user
CLTU-GET-         User   To ascertain the value of an    Yes
PARAMETER                SLE service parameter (see
                         table 3-11)
CLTU-THROW-EVENT  User   To forward an event that        Yes
                         requires Complex Management to
                         take the actions defined for
                         this event
CLTU-PEER-ABORT   User   To notify the peer system that   No
                   or    the local system detected an
                  Provi  error that requires the
                   der   association to be terminated


2.6.4.2   States of the Service Provider
Once a Forward CLTU service instance is created, the Forward CLTU
service provider is in one of three states, as follows:
  
  a)   State 1 ('unbound'): In state 1, all resources required to
     enable the provision of the Forward CLTU service have been
     allocated, and all objects required to provide the service have
     been instantiated.  However, no association yet exists between
     the user and the provider (i.e., the Forward CLTU transfer
     service provider port is not bound).
  
  b)   State 2 ('ready'): In state 2, an association has been
     established between the user and the provider, and they may
     interact by means of the operations described in section 3 of
     this Recommendation.  However, sending of CLTUs from the user to
     the provider (by means of the CLTU-TRANSFER-DATA operation) is
     not permitted.  The user may enable the delivery of CLTUs by
     means of the appropriate service operation (CLTU-START), which,
     in turn, will cause the provider to transition to state 3
     ('active').
  
  c)   State 3 ('active'): State 3 resembles state 2 ('ready'),
     except that now the user can send CLTUs and the provider is
     enabled to radiate CLTUs to the spacecraft.  The service
     continues in this state until the user invokes the CLTU-STOP
     operation to cause the provider to suspend transmission of CLTUs
     and transition back to state 2.
A simplified state transition diagram for the Forward CLTU
service provider is shown in figure 2-4. A detailed state
transition matrix is provided in section 4.
                             [IMAGE]
                                
   Figure 2-4:  Forward CLTU Service Provider State Transition
                             Diagram


2.6.4.3   Terminating an Association
An association is released normally when a CLTU-UNBIND is issued
by the user (the initiator of the association) and accepted by
the provider. An association may be aborted by either the user or
the provider by means of the CLTU-PEER-ABORT operation. An
association may also be aborted because of a failure in the
underlying communications system. Such failures are signaled to
the local application by the 'protocol abort' event described in
4.1.5.


2.6.4.4   Effects of Association Termination
The production of CLTUs stops immediately following the
termination of an association, except for a CLTU in the process
of being radiated. Any buffered CLTUs are discarded. The only
exception to this occurs when the association is terminated due
to a protocol abort, and the protocol-abort-mode option has been
set to 'continue'; in this case, production of CLTUs continues,
and buffered CLTUs are not discarded.
When an association is terminated, no further operations can be
exchanged between the user and the provider. The systems may re-
establish an association via a new CLTU-BIND operation, if that
is consistent with the schedule for provision of service. Status
information is not preserved after an association terminates and
is not available to the new association with the following
exceptions:
  
  a)   statistics reported by means of the CLTU-STATUS-REPORT
     operation, such as the number of CLTUs processed (see 3.9), shall
     be accumulated for the entire service instance provision period;
  
  b)   parameters that serve to relate notifications on an activity
     to operations that triggered this activity will not be altered
     when the association is released or aborted.


2.6.4.5   Buffering
The Forward CLTU service buffers the CLTUs for the primary
purpose of maintaining radiation of a steady stream of CLTUs
despite variable latency over the ground communications channel.
All transfers of CLTUs from the service user to the service
provider must occur within the scheduled service instance
provision period.


2.6.4.6   Technology-specific Aspects--Interoperability and the
      Underlying Communications Service
This Recommendation defines the Forward CLTU service.  Provision
of the Forward CLTU service in a real system also requires a
specification of how the service is mapped to a communications
service, such that all invocations and returns of the Forward
CLTU service operations can be exchanged between the user and the
provider.  In order not to restrict the applicability of this
Recommendation to a specific communications technology, as few
assumptions as possible have been made about the characteristics
of the underlying communications service (see 1.3.1).
The service interface between the user and the provider is
specified in this Recommendation in terms of the operations that
the service provides. Those operations are realized by mapping
the service operation invocations and returns to protocol data
units that can be conveyed by means of the underlying
communications service.  This Recommendation conceptualizes such
mapping in two parts:
  
  a)   Forward CLTU service operation invocations and returns
     (defined in section 3) are mapped to SLE-PDUs (defined in annex
     A);
  
  b)   SLE-PDUs are mapped to protocol data units that can be
     conveyed by means of the underlying communications service.
The mapping of Forward CLTU service operation invocations and
returns to SLE-PDUs is specified by this Recommendation.  The
mapping of SLE-PDUs to an underlying communications service is
intentionally outside the scope of this Recommendation (e.g., so
that the Forward CLTU service may be mapped to more than one
communications technology).  In order to achieve
interoperability, the user and provider must conform not only to
this Recommendation but also to an agreed upon specification of
the mapping of the Forward CLTU service to the underlying
communications service. The specification of a mapping of the
Forward CLTU service onto a particular communications service
must address such points as:
  
  a)   selection of  communications network(s) to ensure
     connectivity;
  
  b)   compatible configuration of protocol stacks (e.g., timeout
     values);
  
  c)   specification of port-identifiers, and their translation
     onto the communications technology;
  
  d)   specification of security related information.
Figure 2-5 illustrates a communications realization of the
Forward CLTU service that results from such a mapping.  The
specification of such mappings is the subject of separate CCSDS
Recommendations.


                             [IMAGE]
 Figure 2-5:  Communications Realization of Forward CLTU Service
Because the operations of the Forward CLTU service are relatively
simple, once an association is in place between the service user
and the service provider, the technology specific elements
involved in the exchange of SLE-PDUs are generally minor.
However, the way an association is established (i.e., the
binding) tends to vary significantly depending on the
communications technology in use.  Nonetheless, the CLTU-BIND and
CLTU-UNBIND operations as specified in this document are intended
to be 'technology neutral'. This neutrality is achieved as
described in the following paragraphs.
For purposes of the communications mapping, the endpoints of an
SLE association are identified by port identifiers, namely, an
'initiator port identifier' and a 'responder port identifier'.
The port identifiers represent all the technology-specific
addressing information needed to establish communications between
the user and provider and to route SLE-PDUs between them.  The
initiator port identifier identifies the endpoint that will
invoke the CLTU-BIND operation (initiator).  The responder port
identifier identifies the endpoint that will perform the CLTU-
BIND operation (responder).  Generally speaking, the information
represented by a port identifier consists of:
  
  a)   information needed to route data between two real systems
     over a communications channel or network; and
  
  b)   information needed to route data within a real system to a
     particular application entity.
For example, the information represented by a port identifier
might be the combination of an Internet Protocol (IP) network
address and a Transmission Control Protocol (TCP) port number or
the combination of an OSI network address and an associated set
of service access points (SAPs).
The exact relationship between SLE port identifiers and
communications ports provided by the underlying communications
service must be specified by the mapping of the Forward CLTU
service to the underlying communications service.
In order for an SLE association to be established, SLE Complex
Management and SLE Utilization Management must agree beforehand
on the responder port identifier for the association.  The
responder needs the information represented by the responder port
identifier to ensure that resources are allocated to recognize
and respond to a CLTU-BIND invocation for that association.  The
initiator needs the information to ensure that the CLTU-BIND
invocation will be communicated to the appropriate responder.
In general, it is not necessary for SLE Complex Management and
SLE Utilization Management to agree beforehand on the initiator
port identifier for the association.  Rather, the initiator
should communicate that information to the responder in
conjunction with the CLTU-BIND invocation.  The exact means by
which the initiator port identifier is provided to the responder
is technology-specific and must be specified by the mapping of
the Forward CLTU service to the underlying communications
service.
The responder port identifier is included as a parameter of the
CLTU-BIND operation.  Generally speaking, that is unnecessary; it
is only necessary that SLE applications communicate the
information represented by the port identifiers to the underlying
communications service.  The responder port identifier is
provided as a parameter of the CLTU-BIND operation to allow for
the possibility that the implementation of a gateway might be
simplified by the inclusion of this parameter in the CLTU-BIND
operation.
The information represented by the responder port identifier is
technology-specific.  In order to define the CLTU-BIND operation
in a way that is not technology-specific, the responder-port-
identifier parameter of the CLTU-BIND operation is defined to be
a logical name.  A logical name is an arbitrary identifier that
has an appropriately chosen and agreed upon translation to
technology-specific information.  Prior to the start time of a
service instance, SLE Complex Management and SLE Utilization must
mutually agree upon the value of the responder port identifier
(and its translation) applicable to that service instance.  The
actual process of translating logical names to technology-
specific information is considered a local matter.  The
translation methodology may rely on simple techniques such as
look-up tables or may use more elaborate mechanisms such as
naming or directory services.
The above discussion describes the case that both the user and
provider applications are implemented using the same
communications service.  It is possible to achieve
interoperability even if the user and provider use different
communications services.  However, in that case interoperability
requires the use of an appropriate gateway.


2.7  OPERATIONAL SCENARIO
Prior to the actual provision of service, start and stop times
for both the space link session and the associated Forward CLTU
service instance are negotiated between SLE Complex Management
and SLE Utilization Management.  Configuration and other
information needed to enable the service are also agreed.
Some time before the scheduled start time of the Forward CLTU
service instance, the service instance is created by SLE Complex
Management.  Initially, the service provider is in state 1
('unbound').  At the scheduled start time of the space link
session, the SLE Complexes involved establish the forward link to
the spacecraft and initiate the production of Forward CLTU
service and, if applicable, of the underlying FTCF and Forward
CLTU services.  Typically (but not necessarily) the start time of
the service instance will precede by a small margin the start
time of the space link session to allow the user to bind to the
service before the start of the space link session.
The following illustrates a typical sequence of operations
between the user and the provider of the Forward CLTU service. A
complete definition of the operations is found in section 3; the
formal specification of provider behavior is presented in section
4.
  
  a)   The user invokes the CLTU-BIND operation to establish an
     association.
  
  b)   The provider, when configured to monitor uplink status by
     examining the No RF Available and/or No Bit Lock flags returned
     from the spacecraft in the Command Link Control Word (CLCW),
     performs the necessary operations to receive the Operational
     Control Field (OCF) as provided by the Return Frame Processing
     SLE-FG.
  
  c)   The provider monitors equipment readiness, the status of the
     physical channel and (when configured to do so) the uplink
     status. When production status changes to 'operational' the
     provider sends CLTU-ASYNC-NOTIFY to the user.
  NOTE   -    Modulation of the uplink signal with acquisition
          sequence and idle sequence, in accordance with the
          PLOP in effect, is under the control of service
          management.
  
  d)   The user sends CLTU-START, and the provider transitions to
     state 3, 'active'.
  
  e)   The user sends a CLTU-TRANSFER-DATA operation to the
     provider.  The provider verifies the invocation, and if
     acceptable, buffers the CLTU until the specified earliest-
     radiation-time is reached.
  
  f)   Additional CLTUs may be sent by the user and buffered.
  NOTE   -    The user may perform steps, d), e) and f),
          invoking CLTU-START and CLTU-TRANSFER-DATA, before the
          production status becomes operational as described in
          step c).
  
  g)   At the time specified for start of radiation, if production
     status is operational, the first CLTU is injected into the
     physical channel and modulated onto the RF carrier.  The signal
     is radiated to the spacecraft. If no start time was specified in
     the CLTU-TRANSFER-DATA operation, the CLTU is radiated as soon as
     received, or whenever the production status becomes operational,
     if that is later.
  
  h)   Successive CLTUs are processed in similar fashion after the
     delay period (if any) specified in the preceding CLTU is
     satisfied.
  
  i)   The user transfers the last CLTU to the provider.
  
  j)   The provider completes processing the buffered CLTUs. When
     the provider's CLTU buffer is empty, it sends CLTU-ASYNC-NOTIFY
     to inform the user.
  
  k)   The user sends CLTU-STOP and the provider transitions to
     state 2, 'ready'.
  
  l)   The user performs CLTU-UNBIND to release the association.
3    OPERATIONS AND THEIR PARAMETERS
3.1  GENERAL CONSIDERATIONS
NOTES
1    This subsection specifies the processing of valid (i.e.,
     recognized) SLE-PDUs. It defines common aspects of the operations
     of the Forward CLTU service.
2    Handling of invalid SLE-PDUs is specified in 0.


3.1.1     RESULT OF OPERATIONS
3.1.1.1   All confirmed operations shall report on the outcome of
the operation in a return.
3.1.1.2   With the exception of CLTU-UNBIND, all returns shall
include a result parameter that indicates whether the outcome of
the operation was successful ('positive result') or unsuccessful
('negative result').
3.1.1.3   In the event of a 'negative result', the return shall
also include a diagnostic parameter that is descriptive of the
reason for the 'negative result'.
NOTE   -    Possible values of the diagnostic parameter are
       listed in the description of each operation.
3.1.1.4    A diagnostic of 'other reason' shall be returned  only
if no other value in the list adequately describes the reason for
the 'negative result'.


3.1.2     PARAMETER TYPES
The types of all parameters shall conform to the abstract syntax
specified in annex A.
NOTE   -    Some parameter types in annex A are chosen so that
       possible future extensions of the range of allowed values
       of a parameter will not cause a type mismatch. For
       example, parameters that logically are of the
       'enumerated' type are specified as being of the 'named
       integer' type.


3.1.3     PARAMETER CHECKING
3.1.3.1    Validity checks shall be performed on  the  values  of
parameters associated with an operation.
NOTE   -    Rules governing the validity of parameter values are
       included in the specification of individual operations.
       General reasons for regarding a parameter value as
       invalid are specified in the following paragraphs.
3.1.3.2   A parameter shall be treated as invalid if:
  
  a)   its value is outside the range or not in the set of values
     currently permitted by service management for the given
     parameter;
  NOTE   -    A conformant implementation shall be capable of
          supporting the full range or set as specified in annex
          A.
  
  b)   its value is in conflict with the value of another parameter
     in the same invocation (e.g., if in CLTU-TRANSFER-DATA the time
     specified in the earliest-radiation-time parameter is later than
     the time specified in the latest-radiation-time parameter);
  
  c)   its value is in conflict with the current provider
     configuration (e.g., the minimum delay time between CLTUs
     parameter as set by service management is longer than the delay-
     time value the CLTU-TRANSFER-DATA invocation contains).
3.1.3.3   If a parameter value is not valid, the operation  shall
not  be performed, and, for confirmed operations other than CLTU-
UNBIND,  a report of 'negative result' shall be returned  to  the
invoker.
3.1.3.4   Except as noted in 3.2.2.11, checks for invalid
parameters or for other conditions that can cause a report of
'negative result' should be performed in the order in which
diagnostics are listed in the descriptions of the operations, and
the diagnostic parameter should be set to the value defined for
the first problem found.
3.1.3.5   In the case that an implementation does not adhere to
the sequence of checks as specified by the sequence of diagnostic
values, such implementation shall specify the sequence in which
checks are actually performed.


3.1.4     ACCESS CONTROL
3.1.4.1   The Forward CLTU service shall implement access control
based  on  the  identity of the initiator and  responder.  Access
control is performed at two levels:
  
  a)   the initiator must be registered at the responder and the
     responder must be registered at the initiator;
  
  b)   the initiator and responder must be authorized for the given
     service instance.
3.1.4.2    The  initiator  shall have access  to  a  registry  of
authorized  responders and the responder shall have access  to  a
registry  of  authorized initiators. These  registries  shall  be
maintained   by  SLE  Complex  Management  and  SLE   Utilization
Management, respectively.
3.1.4.3   Service management shall specify the authorized
initiator and responder for each service instance.
3.1.4.4   The initiator and responder shall indicate their
identity by setting the parameters initiator-identifier and
responder-identifier in the CLTU-BIND operation to the values
assigned by service management.


3.1.5     AUTHENTICATION
NOTE   -    Requirements for security depend on the application
       and on the SLE system environment (e.g., whether closed
       or public networks are used or if access is only from
       physically restricted areas).  In many environments,
       security may be provided by the communications service
       transparently to the SLE application. This Recommendation
       does not preclude the use of security features that are
       provided by the communications service or the local
       environment, nor does it assume the availability of such
       features.
3.1.5.1    The  Forward CLTU service shall provide the  following
options with respect to level of authentication:
  
  a)   'all'--all Forward CLTU invocations and returns, except the
     invocation of CLTU-PEER-ABORT, shall be authenticated;
  
  b)   'bind'--only the CLTU-BIND invocation and return shall be
     authenticated;
  
  c)   'none'--no Forward CLTU invocations or returns shall be
     authenticated.
3.1.5.2    SLE Complex Management and SLE Utilization  Management
shall agree on the level of authentication to be required for  an
association between a user and the Forward CLTU service  provider
and configure both entities accordingly.
3.1.5.3   SLE Complex Management and SLE Utilization Management
shall agree on the algorithms used to generate and check
credentials parameters and make these algorithms known to the
service user and provider, together with associated parameters
such as passwords or keys as necessary for the adopted
algorithms.
NOTES
1    The specification of the algorithms themselves is outside
     the scope of this Recommendation.
2    The initiator-identifier and responder-identifier parameters
     of the CLTU-BIND operation identify the user and provider,
     respectively, and therefore the applicable authentication level
     and the algorithms necessary to generate and check credentials.
3.1.5.4    For operations for which authentication of credentials
is  required  by  terms  of  the agreement  between  SLE  Complex
Management and SLE Utilization Management:
  
  a)   invocations shall include an invoker-credentials parameter
     to permit the performer to authenticate the invocation; and
  
  b)   returns shall include a performer-credentials parameter to
     permit the invoker to authenticate the return.
3.1.5.5    For operations for which authentication of credentials
is not required, the invoker-credentials or performer-credentials
parameter should be set to the value 'unused' to signify that the
invocation or return does not carry credentials.


3.1.6     THREADED APPLICATIONS
NOTES
1    Multi-threading has evolved to a widely used technique to
     optimize systems' performance. To support applications that may
     be implemented using multiple threads of execution, the parameter
     invoke-ID is specified for all confirmed operations except CLTU-
     BIND and CLTU-UNBIND.
2    The invoke-ID parameter allows the invoker to correlate a
     particular return to the invocation that prompted it.
3    Confirmed operations that include the invoke-ID parameter
     are non-blocking operations; those that do not are blocking
     operations.  Unconfirmed operations are always non-blocking.
3.1.6.1   After invoking a blocking operation, the invoker  shall
not  invoke another operation for the same service instance until
the  return from the blocking operation is received; except that,
if the return is not received in a timely manner, the invoker may
invoke CLTU-PEER-ABORT to terminate the association.
3.1.6.2   After invoking a non-blocking operation, the invoker
may invoke another operation without waiting for the return from
the first invocation.
3.1.6.3   The value of the invoke-ID parameter shall be an
invoker-supplied arbitrary integer value that shall be returned,
unchanged, by the performer.
3.1.6.4   The invocation of a non-blocking operation shall be
rejected with the diagnostic 'duplicate invoke-ID' if it includes
an invoke-ID whose value is the same as that of another
invocation that is awaiting confirmation within the context of
the same service instance.
3.1.6.5   To ensure that the Forward CLTU service behaves in a
predictable manner, the effects of operations shall be as though
the operations were performed in the order that their invocations
were received by the performer.
3.1.6.6   The invoker may choose not to exploit the non-blocking
capability and always wait for the return from a non-blocking
operation before invoking another operation.
NOTE   -    An invoker wishing to operate in blocking mode
       (i.e., to invoke a new operation only after the return
       from the previous operation has been received) may use a
       constant value for the invoke-ID parameter. As long as a
       return is still outstanding, the performer will reject
       any further invocations.
3.1.6.7    Compliance with this Recommendation does  not  require
the  performer to process invocations concurrently; however,  the
performer must accept invocations from a non-blocking invoker and
buffer and serialize them by local means not visible externally.


3.1.7     MANDATORY PARAMETERS
All providers shall be able to accept and respond to parameters
specified as mandatory in annex D.
NOTE   -    All parameters of operations are mandatory except
       where stated differently in annex D. The actual presence
       of a parameter in a particular invocation or return may
       be conditional based on the value of another parameter in
       the same invocation or return.  For some parameters, a
       value of 'null' is allowed, as discussed in the
       description of the relevant operations.


3.1.8     TIME
3.1.8.1   The time reference for all parameters containing a time
value shall be based on Coordinated Universal Time (UTC).
3.1.8.2   The type of parameters containing a time value shall be
the CCSDS Day Segmented (CDS) time code format (reference [5])
with a resolution of microseconds, an epoch of 1958-01-01 and a
16-bit day segment.
3.1.8.3   All time values shall be expressed to a precision of at
least one-tenth (0.1) of a second.
3.1.8.4   All time value shall be accurate to within one-tenth
(0.1) of a second or better.


3.1.9     DELIVERY MODES
3.1.9.1   Forward Online Delivery
3.1.9.1.1  Forward online delivery service provision shall  occur
at the same time as service production, i.e., during a space link
session.
3.1.9.1.2 CLTUs supplied by the service user shall be buffered by
the service provider until they are processed.
3.1.9.1.3 The timing of CLTU processing shall be determined by
the order of CLTUs in the buffer and any annotation data provided
with the CLTUs.
NOTE   -    The forward online delivery mode is defined in this
       Recommendation.


3.1.9.2   Forward Offline Delivery
3.1.9.2.1  Service  provision and service  production  shall  not
overlap.
3.1.9.2.2 CLTUs supplied by the service user during service
provision shall be buffered by the provider in persistent storage
until service production.
NOTE   -    The forward offline delivery mode is outside the
       scope of this version of this Recommendation.


3.1.10    SETTING OF PARAMETERS
3.1.10.1   A  Forward CLTU provider shall permit setting  of  the
service configuration parameters as specified in table 3-1.
3.1.10.2  The range or set of values a parameter may assume is
constrained by specification of its data type (see annex A).
3.1.10.3  Service management may further constrain the allowed
values for a given service instance.


3.1.11    PROVIDER BUFFERING REQUIREMENTS
3.1.11.1   The  service  package  shall  specify  the  amount  of
buffering the provider must maintain.
3.1.11.2  The amount of buffer space shall be specified in terms
of the number of octets that can be stored.
3.1.11.3  The service provider shall buffer only complete CLTUs.


3.1.12    ACCOUNTING SUMMARY
Statistical information to be collected over a period of time
shall always refer to the service instance provision period.
                                
                                
    Table 3-1:  Setting of Forward CLTU Service Configuration
                           Parameters
                                
    Parameter      Service     CLTU-     CLTU-     CLTU-
                  Managemen    START   SCHEDULE-  THROW-
                      t      Operatio   STATUS-    EVENT
                                 n      REPORT   Operatio
                                       Operatio   n (NOTE
                                           n        3)
bit-lock-required     X                              
delivery-mode         X                              
expected-cltu-                   X                   
identification
expected-event-                                      X
invocation-
identification
maximum-cltu-         X                              
length
modulation-           X                              
frequency
modulation-index      X                              
notification-mode     X                              
plop-in-effect        X                              
protocol-abort-       X                              
mode
reporting-cycle                            X         
return-timeout-       X                              
period
rf-available-         X                              
required
subcarrier-to-bit-    X                              
rate-ratio


NOTES
1    Further details on protocol-abort-mode are discussed in
     4.1.5. The notification-mode parameter is described in
     3.7.2.3. Other parameters are presented and described in
     table 3-11. A complete list of parameters that may affect
     service production may be found in references [E5] and [E6].
2    The user can ascertain the current value of the parameters
     presented in table 3-11 by means of the CLTU-GET-PARAMETER
     operation.
3    The ability to modify selected service configuration
     parameters using the CLTU-THROW-EVENT operation is allowed
     but not mandated in this Recommendation.


3.2  CLTU-BIND
3.2.1     PURPOSE
3.2.1.1    The initiator shall invoke the CLTU-BIND operation  to
establish  an association between the initiator and responder  as
defined in 1.6.1.7.2.
3.2.1.2   The responder shall confirm the CLTU-BIND operation.
3.2.1.3   Except as provided in 3.2.1.4, the initiator shall not
invoke any further CLTU operations on this service instance until
the bind is confirmed.
3.2.1.4   If the return from the invocation of CLTU-BIND is not
received after a sufficiently long time (to be determined by
service management), the initiator may attempt to recover by
invoking the CLTU-PEER-ABORT operation (see 3.12) followed by
another CLTU-BIND.
3.2.1.5   The CLTU-BIND operation is valid only in state 1
('unbound') and shall be invoked only by the user.


3.2.2     INVOCATION, RETURN, AND PARAMETERS
3.2.2.1   General
The parameters of the CLTU-BIND operation shall be present in the
invocation and return as specified in table 3-2.
                                
                                
                Table 3-2:  CLTU-BIND Parameters
                                
            Parameter             Invocati   Return
                                     on
invoker-credentials              M          
performer-credentials                      M
initiator-identifier             M          
responder-identifier                       M
responder-port-identifier        M          
service-type                     M          
version-number                   M         C
service-instance-identifier      M          
result                                     M
diagnostic                                 C


3.2.2.2   invoker-credentials
The invoker-credentials parameter shall provide information that
enables the performer to authenticate the CLTU-BIND invocation
(see 3.1.5).


3.2.2.3   performer-credentials
The performer-credentials parameter shall provide information
that enables the invoker to authenticate the return from the
performance of CLTU-BIND (see 3.1.5).


3.2.2.4   initiator-identifier
The initiator-identifier parameter shall identify the authority
on whose behalf the SLE application is initiating an association.
NOTES
1    The initiator-identifier parameter permits the responding
     SLE application to determine if this user is registered at this
     responder and which authentication scheme is to be applied.
2    In case authentication based on credentials is used, this
     information may be redundant since the initiator-identifier value
     is normally one constituent of the invoker-credentials parameter.
     However, its encoding may differ and it may be convenient to have
     this parameter also available in 'clear text' form.


3.2.2.5   responder-identifier
The responder-identifier parameter shall identify the authority
on whose behalf the responding SLE application is acting.
NOTES
1    The responder-identifier parameter permits the initiator to
     determine if the responder from which the CLTU-BIND return
     originates is registered at this initiator.
2    The initiator uses this parameter, if applicable, after
     having successfully authenticated the CLTU-BIND return to
     determine if this return originates from the intended responder.


3.2.2.6   responder-port-identifier
The responder-port-identifier parameter shall specify the port
identifier of the responding SLE application entity with which
the initiator seeks to establish an association.
NOTES
1    The value of the responder-port-identifier parameter is a
     logical name that can be translated into the technology-specific
     addressing information required to establish a connection with
     the responder using the agreed upon communications service.  See
     2.6.4.6 for more information.
2    SLE Complex Management and SLE Utilization Management must
     have previously agreed on the responder-port-identifier and its
     translation that is applicable to a particular instance of
     service.
3    The responder-port-identifier parameter is included in the
     CLTU-BIND invocation to support its possible use by particular
     kinds of gateways.


3.2.2.7   service-type
The service-type parameter shall specify the type of service that
will be present if the bind operation succeeds.2


3.2.2.8   version-number
3.2.2.8.1 The version-number parameter shall identify the version
number  of  the  Forward CLTU service specification  that  is  to
govern this association if the CLTU-BIND succeeds.
3.2.2.8.2 version-number is conditionally present in the return
based on the result parameter:
  
  a)   if the value of result is 'positive result', version-number
     shall be present in the return;
  
  b)   if the value of result is 'negative result', version-number
     shall not be present.
3.2.2.8.3  If  the  value  of result is  'positive  result',  the
responder shall either:
  
  a)   accept the version proposed by the initiator by putting the
     same version number into the positive return; or
  
  b)   if the responder implementation supports version
     negotiation, propose a lower (earlier) version number by putting
     the lower version number in the positive return.
3.2.2.8.4  If the responder implementation does not  support  the
requested version and does not support a lower version  (or  does
not  support version negotiation), the responder shall reject the
bind   with   the  diagnostic  parameter  set  to  'version   not
supported'.
3.2.2.8.5 If the responder proposes a lower version in the return
than supported by the initiator, the initiator shall unbind the
association.
3.2.2.8.6 The version-number value of the Forward CLTU service
defined by this issue of this Recommendation shall be '1'.
NOTE   -    The version negotiation process as outlined above is
       only feasible as long as a future version of the Forward
       CLTU service retains the specification of the CLTU-BIND
       operation.


3.2.2.9   service-instance-identifier
The service-instance-identifier parameter shall uniquely identify
this service instance within the scope of the service-providing
SLE Complex.
NOTE   -    The service-instance-identifier parameter takes the
       form of a Distinguished Name (see reference [8]). The
       attributes of the Distinguished Name should include the
       SLE service agreement and the SLE service package
       applicable to this instance of service. More details on
       the way the service-instance-identifier is built can be
       found in reference [E5].


3.2.2.10  result
3.2.2.10.1     The result parameter shall specify the  result  of
the  CLTU-BIND invocation and shall contain one of the  following
values:
  
  a)   'positive result'--the CLTU-BIND  invocation is accepted by
     the responder and the association is established;
  
  b)   'negative result'--the CLTU-BIND invocation is rejected by
     the responder for the reason specified in the diagnostic
     parameter.


3.2.2.11  diagnostic
3.2.2.11.1      If result is 'negative result', diagnostic  shall
be present and shall contain one of the following values:
  
  a)   'access denied'--an initiator with the initiator-identifier
     value presented in the CLTU-BIND invocation is not registered at
     the responder;
  
  b)   'service type not supported'--the service-type value in the
     CLTU-BIND invocation does not identify a service type supported
     by the responder;
  
  c)   'version not supported'--
     
     1)   the responder does not support the requested version, and
     
     2)   the responder implementation does not permit version
       negotiation or the responder does not support any version of the
       service lower than the one requested by the initiator;
  
  d)   'no such service instance'--the requested service instance
     is not defined by any agreed upon service package known to the
     responder;
  
  e)   'already bound'--the service instance is already bound via a
     different association;
  
  f)   'service instance not accessible to this initiator'--the
     service instance identified by the value of the service-instance-
     identifier parameter has not been created for use by the
     initiator specified in the initiator-identifier parameter;
  
  g)   'inconsistent service type'--the service-type value in the
     CLTU-BIND invocation is not consistent with the service type of
     this service instance;  i.e., it is not 'fwdCltu;
  
  h)   'invalid time'--the CLTU-BIND operation was invoked outside
     the service instance provision period agreed to in the service
     package;
  
  i)   'out of service'--the responder has been taken out of
     service for an indefinite period by management action, i.e.,
     production-status is 'halted';
  
  j)   'other reason'--the reason for the negative result will have
     to be found by other means.
  NOTE   -    Initiators should consider that, under some
          conditions, CLTU-BIND might fail with no return, e.g.,
          if responder-port-identifier has an incorrect value.
3.2.2.11.2      If result is 'positive result', diagnostic  shall
not be present.


3.2.3     EFFECTS
3.2.3.1   If result is 'positive result':
  
  a)   an association between the user and the provider shall be
     established;
  
  b)   the provider shall transition from state 1 ('unbound') to
     state 2 ('ready');
  
  c)   upon receipt of the positive return, the user may proceed to
     invoke other Forward CLTU service operations to initialize the
     service and enable data transfer (e.g., CLTU-SCHEDULE-STATUS-
     REPORT and CLTU-START).
3.2.3.2   If result is 'negative result':
  
  a)   the association between the user and the provider shall not
     be established;
  
  b)   the provider shall remain in state 1 ('unbound');
  
  c)   upon receipt of the negative return:
     
     1)   the initiator should examine the diagnostic parameter for
       the cause;
     
     2)   the initiator may attempt to re-invoke the CLTU-BIND.
3.3  CLTU-UNBIND
3.3.1     PURPOSE
3.3.1.1    The initiator shall invoke the CLTU-UNBIND to  release
an association previously established by CLTU-BIND (see 0).
3.3.1.2   The responder shall confirm the CLTU-UNBIND operation.
3.3.1.3   Except as provided in 3.3.1.4, the initiator shall not
invoke any further Forward CLTU operations for this service
instance until the return from CLTU-UNBIND is received; nor shall
it perform any further operations invoked by the responder; nor
shall it return to the responder any further reports of the
outcome of operations invoked by the responder.
NOTE   -    The initiator may invoke the CLTU-UNBIND operation
       even if it did not yet receive all returns from
       previously invoked operations. The initiator should be
       aware that the responder may choose not to send any
       further returns as soon as it has received the CLTU-
       UNBIND invocation. It may then happen that the CLTU-
       UNBIND return is not received before one of the missing
       returns causes a 'missing return' timeout (see 4.1.3).
3.3.1.4    If the return from the CLTU-UNBIND invocation  is  not
received  after  a  sufficiently long time (to be  determined  by
service  management), the initiator shall invoke  the  CLTU-PEER-
ABORT operation (see 3.12).
NOTE   -    The 'sufficiently long time' as determined by
       service management can be estimated by invoking the CLTU-
       GET-PARAMETER operation and selecting 'return-timeout-
       period' as the value of cltu-parameter.
3.3.1.5    The  CLTU-UNBIND operation is valid only  in  state  2
('ready') and shall be invoked only by the user.


3.3.2     INVOCATION, RETURN, AND PARAMETERS
3.3.2.1   General
The parameters of the CLTU-UNBIND operation shall be present in
the invocation and return as specified in table 3-3.
                                
                                
               Table 3-3:  CLTU-UNBIND Parameters
                                
        Parameter             Invoca    Return
                               tion
invoker-credentials             M          
performer-credentials                     M
unbind-reason                   M          
result                                    M


3.3.2.2   invoker-credentials
The invoker-credentials parameter shall provide information that
enables the performer to authenticate the CLTU-UNBIND invocation
(see 3.1.5).


3.3.2.3   performer-credentials
The performer-credentials parameter shall provide information
that enables the invoker to authenticate the return from the
performance of CLTU-UNBIND (see 3.1.5).


3.3.2.4   unbind-reason
The unbind-reason parameter shall specify why the CLTU-UNBIND
operation is being invoked and shall contain one of the following
values:
  
  a)   'end'--the initiator has completed the transfer of its data
     and is releasing the association normally:  the provider may end
     the service instance and release its resources allocated to this
     service instance;
  NOTE   -    Further invocation of the CLTU-BIND operation is
          not permitted even if the service instance provision
          period has not expired, since the service provider may
          release the resources allocated to that service
          instance.
  
  b)   'suspend'--the initiator is suspending this service usage
     for an unspecified period of time:  the initiator may attempt to
     re-bind to the responder to continue data transfer at any time
     prior to the end of the provision period scheduled for this
     service instance;
  
  c)   'version not supported'--the initiator does not support the
     version of the Forward CLTU service proposed by the responder in
     the return from CLTU-BIND: this value of unbind-reason shall be
     used only if the CLTU-UNBIND is the first operation invoked
     following the CLTU-BIND;
  
  d)   'other reason'--the reason for the release will have to be
     found by other means.


3.3.2.5   result
The result parameter shall specify the result of the CLTU-UNBIND
invocation and shall always contain the following value:
'positive result'--the CLTU-UNBIND  invocation is accepted by the
responder and the association is released.
NOTE   -    The result parameter is returned for the CLTU-UNBIND
       operation even though the only permitted value is
       'positive result', for consistency with other confirmed
       operations.


3.3.3     EFFECTS
3.3.3.1    The  CLTU-UNBIND operation shall  have  the  following
effects:
  
  a)   the association between the initiator and the responder
     shall be released, and the initiator and the responder shall
     cease to communicate with each other;
  
  b)   the provider shall transition to state 1 ('unbound').
3.3.3.2    If unbind-reason is 'end', the provider may  terminate
the service instance and release its resources.
3.3.3.3   If unbind-reason is not 'end':
  
  a)   the initiator may attempt to re-bind at any time prior to
     the end of the provision period scheduled for this service
     instance;
  
  b)   the provider shall maintain accumulated statistics such as
     are reported in CLTU-STATUS-REPORT for the duration of the
     service instance provision period;
  
  c)   parameters that serve to relate notifications on an activity
     to operations that triggered that activity shall not be altered
     when the association is released.
  
3.4  CLTU-START
3.4.1     PURPOSE
3.4.1.1    The  user  shall  invoke the CLTU-START  operation  to
request that the Forward CLTU service provider prepare to receive
CLTU-TRANSFER-DATA invocations (see 3.6).
3.4.1.2   The Forward CLTU service provider shall confirm the
CLTU-START operation.
3.4.1.3   The CLTU-START operation shall allow the Forward CLTU
service provider to return to the user the times scheduled for
start and stop of production.
3.4.1.4   CLTU-START is valid only in state 2 ('ready') and shall
be invoked only by the user.


3.4.2     INVOCATION, RETURN AND  PARAMETERS
3.4.2.1   General
The parameters of the CLTU-START operation shall be present in
the invocation and return as specified in table 3-4.
                                
                                
                Table 3-4:  CLTU-START Parameters
                                
_______________________________
1     The concept of an abstract service is to be distinguished
 from the concept of an (N)-service as defined in the OSI Basic
 Reference Model (reference [7]). The definition of (N)-service
 is in terms of the capability provided by one layer in the OSI
 architecture to the layer above it.  The definition of abstract
 service is in terms of the capability provided by one abstract
 object to another abstract object.  In a cross support
 scenario, where one Agency is providing an SLE service to
 another Agency, the object that provides the service typically
 is associated with one Agency, and the object that uses the
 service typically is associated with the other Agency.
2For the CLTU-BIND operation, the service-type parameter is
 redundant, because the only valid value of service-type is
 'fwdCltu'.  However, it is anticipated that future work by
 CCSDS will result in CLTU-BIND being superseded by a generic
 SLE-BIND operation that is invoked with any one of several SLE
 service types.  The CLTU-BIND service-type parameter is
 provided in an attempt to facilitate such a change.