![](media/image1.wmf){width="4.388888888888889in"
height="1.2083333333333333in"}

**RECOMMENDATION FOR SPACE**

**DATA SYSTEM STANDARDS**

  -----------------------------------------------------------------------
  **SPACE LINK EXTENSION--- RETURN ALL FRAMES SERVICE SPECIFICATION**

  -----------------------------------------------------------------------

**CCSDS 911.1-B-1**

**BLUE BOOK**

April 2002

![](media/image2.wmf){width="4.111111111111111in"
height="1.9305555555555556in"}

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 the *Procedures Manual for the
Consultative Committee for Space Data Systems*, and the record of Agency
participation in the authorization of this document can be obtained from
the CCSDS Secretariat at the address below.

This 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 Return All Frames 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\], \[3\], and \[4\]) within the framework established by
the CCSDS Space Link Extension 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 the *Procedures Manual for the
Consultative Committee for Space Data Systems*. Current versions of
CCSDS documents are maintained at the CCSDS Web site:

http://www.ccsds.org/

Questions relating to the contents or status of this document should be
addressed to the CCSDS Secretariat at the address indicated on page i.

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

[Member Agencies]{.underline}

-   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 für 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]{.underline}

-   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**

                                                         

  CCSDS          Space Link Extension---\     April 2002 Original Issue
  911.1-B-1      Return All Frames Service               
                 Specification                           

                                                         

                                                         

                                                         
  -------------- ---------------------------- ---------- --------------------

CONTENTS

Section Page

1 Introduction 1-1

1.1 Purpose Of This Recommendation 1-1

1.2 Scope 1-1

1.3 Applicability 1-1

1.4 Rationale 1-2

1.5 Document Structure 1-2

1.6 Definitions, Nomenclature, and Conventions 1-4

1.7 References 1-12

2 Description of the Return All Frames Service 2-1

2.1 Overview 2-1

2.2 Space Link Extension Reference Model 2-1

2.3 Service Management 2-3

2.4 Architecture Model---Functional View 2-4

2.5 Architecture Model---Cross Support View 2-7

2.6 Functional Description 2-8

2.7 Operational Scenario 2-17

3 RAF Service Operations 3-1

3.1 General Considerations 3-1

3.2 RAF-BIND 3-12

3.3 RAF-UNBIND 3-19

3.4 RAF-START 3-23

3.5 RAF-STOP 3-28

3.6 RAF-TRANSFER-DATA 3-30

3.7 RAF-SYNC-NOTIFY 3-34

3.8 RAF-SCHEDULE-STATUS-REPORT 3-37

3.9 RAF-STATUS-REPORT 3-41

3.10 RAF-GET-PARAMETER 3-44

3.11 RAF-PEER-ABORT 3-48

4 RAF Protocol 4-1

4.1 Generic Protocol Characteristics 4-1

4.2 RAF 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 Matrix D-1

ANNEX E Informative References E-1

Figure

1-1 SLE Services Documentation 1-4

2-1 Return Space Link Processing SLE-FG 2-4

2-2 RAF Service Production and Provision 2-6

2-3 Example of the Management and Provision of RAF Service 2-7

2-4 Simplified RAF Service Provider State Transition Diagram 2-10

2-5 Mapping of RAF Service Operations to SLE-PDUs 2-12

2-6 Buffers and Delivery Modes 2-16

Table

2-1 RAF Operations 2-9

3-1 RAF-BIND Parameters 3-13

3-2 RAF-UNBIND Parameters 3-20

3-3 RAF-START Parameters 3-24

3-4 RAF-STOP Parameters 3-28

3-5 RAF-TRANSFER-DATA Parameters 3-30

3-6 RAF-SYNC-NOTIFY Parameters 3-34

3-7 RAF-SCHEDULE-STATUS-REPORT Parameters 3-38

3-8 RAF-STATUS-REPORT Parameters 3-41

3-9 RAF-GET-PARAMETER Parameters 3-44

3-10 RAF-PEER-ABORT Parameters 3-48

4-1 Provider Behavior 4-6

4-2 Event Description References 4-12

4-3 Predicate Descriptions 4-12

4-4 Boolean Flags 4-13

4-5 Compound Action Definitions 4-13

D-1 Conformance Matrix for RAF Service (Operations) D-1

D-2 Conformance Matrix for RAF Service (Other Requirements) D-2

# Introduction

## Purpose Of This Recommendation

The purpose of this Recommendation is to define the Space Link Extension
(SLE) Return All Frames (RAF) service in conformance with the SLE
Reference Model (reference \[1\]). The RAF service is an SLE transfer
service that delivers to a mission user all telemetry frames from one
space link physical channel.

## Scope

This Recommendation defines, in an abstract manner, the RAF service in
terms of:

a)  the operations necessary to provide the 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.

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 acquire telemetry frames
    from signals received from a spacecraft;

d)  the methods or technologies required to provide a suitable
    environment for communications; or

e)  the management activities required to schedule, configure, and
    control the RAF service.

## Applicability

### Applicability Of This Recommendation

This Recommendation provides a basis for the development of real systems
that implement the RAF service. Implementation of the RAF service in a
real system additionally requires the availability of a communications
service to convey invocations and returns of RAF service operations
between RAF service users and providers. This Recommendation requires
that such a communications service must 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 RAF service user and the RAF service
    provider are disrupted, possibly resulting in a loss of data.

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

### Limits Of Applicability

#### Relationship to Real Systems

This Recommendation specifies the RAF 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.

#### RAF Service and Telemetry Channel Coding

Telemetry channel coding on the space link is specified by reference
\[2\]. This specification is more restrictive with respect to telemetry
channel coding than is reference \[2\]. In particular, the provision of
RAF service requires that Reed-Solomon coding must be present or absent
on all frames of a physical channel. RAF service is not supported where
there is a concurrent mix, on one physical channel, of some frames with
Reed-Solomon coding and some frames without.

## 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 consumers of spacecraft telemetry.

## Document Structure

### Organization

This document is organized as follows:

a)  section 1 presents the purpose, scope, applicability and rationale
    of this Recommenda­tion and lists the definitions, conventions, and
    references used throughout the Recommendation;

b)  section 2 provides an overview of the RAF service including a
    functional description, the service management context, and protocol
    considerations;

c)  section 3 specifies the operations of the RAF service;

d)  section 4 specifies the dynamic behavior of the RAF service in terms
    of the state transitions of the RAF service provider;

e)  annex A provides a formal specification of RAF service data types
    using Abstract Syntax Notation One (ASN.1);

f)  annex B lists all terms used in this Recommendation 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 provides a list of informative references.

### SLE Services Documentation Tree

This Recommendation is based on the cross support model defined in the
SLE Reference Model (reference \[1\]). It expands upon the concept of an
SLE transfer service as an interaction between an SLE Mission User
Entity (MUE) and an SLE transfer service provider for the purpose of
providing the RAF 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 Domain Services;

c)  Part 3: Ground Communications Services.

The basic organization of the SLE services documentation is shown in
figure 1‑1. The various documents are described in the following
paragraphs.

![](media/image3.wmf)

Figure 1‑1: SLE Services Documentation

a)  *Standard Terminology, Conventions and Methodology for Defining Data
    Services* (reference \[E2\]): 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 the 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 Return Service Specifications*: a set of Recommendations that
    will provide specification of all return link SLE services (this
    Recommendation is one of the specifications in that set);

e)  *SLE Forward Service Specifications*: a set of Recommendations that
    will provide specification of all forward link SLE services;

f)  *SLE Service Management Specifications*: a set of Recommendations
    that establish the basis of SLE service management (reference \[E3\]
    is the primary Recommendation in that set).

## Definitions, Nomenclature, and Conventions

### definitions

#### Definitions from OSI Basic Reference Model

This Recommendation makes use of a number of terms defined in reference
\[6\]. 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)  application process;

e)  flow control;

f)  Open Systems Interconnection (OSI);

g)  real system;

h)  service access point (SAP).

#### Definitions from Abstract Syntax Notation One

This Recommendation makes use of the following terms defined in
reference \[7\]:

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 RAF service operation invocations and returns.
The use of ASN.1 as a descriptive language is intended to support the
specification of the abstract RAF service; it is not intended to
constrain implementations. In particular, there is no requirement for
implementa­tions to employ ASN.1 encoding rules. ASN.1 is simply a
convenient tool for formally describing the abstract syntax of RAF
service operation invocations and returns.

#### Definitions from Directory Service Models

This Recommendation makes use of the following terms defined in
reference \[8\]:

a)  distinguished name (DN);

b)  relative distinguished name (RDN).

#### Definitions from Telemetry Channel Coding

This Recommendation makes use of the following terms defined in
reference \[2\]:

a)  attached sync marker;

b)  codeblock;

c)  convolutional code;

d)  pseudo-randomization;

e)  Reed-Solomon check symbols;

f)  Reed-Solomon code.

#### Definitions from Packet Telemetry

This Recommendation makes use of the following term defined in reference
\[3\]:

a)  frame error control field;

b)  transfer frame.

#### Definitions from AOS Architecture Specification

This Recommendation makes use of the following terms defined in
reference \[4\]:

a)  coded virtual channel data unit (CVCDU);

b)  cyclic redundancy code (CRC);

c)  VCDU error control field;

d)  virtual channel data unit (VCDU).

#### Definitions from 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)  invoker;

f)  Mission Data Operation System (MDOS);

g)  Mission User Entity (MUE);

h)  offline delivery mode;

i)  online delivery mode;

j)  operation;

k)  performer;

l)  physical channel;

m)  return data;

n)  Return All Frames channel (RAF channel);

o)  Return All Frames service (RAF service);

p)  service agreement;

q)  service provider (provider);

r)  service user (user);

s)  SLE Complex;

t)  SLE Complex Management;

u)  SLE data channel;

v)  SLE functional group (SLE-FG);

w)  SLE protocol data unit (SLE-PDU);

x)  SLE service data unit (SLE-SDU);

y)  SLE service package;

z)  SLE System;

a)  SLE transfer service instance;

b)  SLE transfer service production;

c)  SLE transfer service provision;

d)  SLE Utilization Management;

e)  space link;

f)  space link data channel;

g)  space link data unit (SL-DU);

h)  space link session.

#### Additional Definitions

##### 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 the use of an underlying communications
service.

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

##### Confirmed Operation

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

##### Delivery Criteria

Delivery criteria are rules that determine whether a data unit acquired
from the space link by an SLE service provider shall be delivered to a
user.

NOTE -- For RAF service, the delivery criteria are:

a)  the Earth Receive Time (ERT) of the frame is within the period
    defined by the start and stop times specified in the RAF-START
    operation; and

b)  the frame quality of the frame matches the requested frame quality
    specified in the RAF-START operation.

##### Error Control Field

The error control field of a frame is the frame error control field
(reference \[3\]) if the frame is a transfer frame or the VCDU error
control field (reference \[4\]) if the frame is a VCDU or CVCDU.

##### Initiator

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

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

##### 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 the production or provision of the
service.

##### Performance

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

##### Port Identifier

A port identifier identifies a source or a destination in a
communications system.

NOTE -- See 2.6.4.5 for more information.

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

##### Return

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

##### Service Instance Provision Period

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

##### Telemetry Frame

A telemetry frame is a transfer frame (as defined in reference \[3\]) or
a VCDU or CVCDU (as defined in reference \[4\]).

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

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

### Conventions

#### Specification of Operations

##### General

Section 3 of this Recommendation specifies the operations that
constitute the RAF service. The specification of each operation is
divided into subsections as follows:

##### Purpose Subsection

The Purpose subsection provides a brief description of the purpose 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.

##### 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 the return of an
operation, the diagnostic parameter is present if and only if the value
of the result parameter 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

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.

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

#### Typographic Conventions

##### Operation Names

Names of RAF service operations appear in uppercase and begin with the
characters 'RAF-' (e.g., RAF-TRANSFER-DATA).

##### Parameter Names

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

##### Value Names

The values of many parameters discussed in this Recommendation are
represented by names. In the main text, those names are shown in
quotation marks (e.g., 'no such service instance'). The corresponding
name in annex A is 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 that value. Parameter
types are specified in annex A of this Recommendation.

NOTE -- The name of a value does not imply anything about its 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'.

##### State Names

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

##### SLE-PDU Names

The names of SLE-PDUs appear in mixed-case (e.g., rafBindInvocation).

##### Data Type Definitions

Data type definitions for the RAF 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.

#### Other Conventions

This Recommendation uses the conventions specified in reference \[1\].

## References

The following documents contain provisions that, 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 is provided in annex E.

\[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\] *Telemetry Channel Coding*. Recommendation for Space Data System
Standards, CCSDS 101.0-B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS,
June 2001.

\[3\] *Packet Telemetry*. Recommendation for Space Data System
Standards, CCSDS 102.0-B-5. Blue Book. Issue 5. Washington, D.C.: CCSDS,
November 2000.

\[4\] *Advanced Orbiting Systems, Networks and Data Links: Architectural
Specification*. Recommendation for Space Data System Standards, CCSDS
701.0-B-3. Blue Book. Issue 3. 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---Basic
Reference Model: The Basic Model*. International Standard, ISO/IEC
7498-1. 2nd ed. Geneva: ISO, 1994.

\[7\] *Information Technology---Open Systems
Interconnection---Specification of Abstract Syntax Notation One
(ASN.1)*. International Standard, ISO/IEC 8824:1990. 2nd ed. Geneva:
ISO, 1990.

\[8\] *Information Technology---Open Systems Interconnection---The
Directory: Models*. International Standard, ISO/IEC 9594-2:1998. 3rd ed.
Geneva: ISO, 1998.

# Description of the Return All Frames Service

## Overview

The RAF service enables the user of the service to obtain all telemetry
frames from one space link physical channel. A telemetry frame is a
transfer frame, a virtual channel data unit (VCDU), or a coded virtual
channel data unit (CVCDU). A space link physical channel carries one
stream of telemetry frames separated by attached sync markers. For
delivery to the user, each frame acquired from the space link is
encapsulated in a data unit that also carries annotation (i.e.,
additional information such as the ERT of the frame).

The operations defined in section 3 of this Recommendation enable an RAF
service user to interact with an RAF service provider to:

a)  establish an association between the user and the provider;

b)  receive annotated telemetry frames from the provider;

c)  obtain notifications and reports regarding the status, configuration
    and performance of the service;

d)  temporarily suspend and later re-start the delivery of telemetry
    frames;

e)  change the values of certain parameters that affect the behavior of
    the service; and

f)  release an association.

The provision of RAF service derived from one space link physical
channel for access by one service user constitutes one service instance.
The provision of RAF service from one physical channel to multiple
service users constitutes multiple service instances, one per user. The
provision of RAF service from multiple physical channels to one service
user constitutes multiple service instances, one per physical channel.

## Space Link Extension Reference Model

### Introduction

The RAF 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.

### 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. Objects are characterized by their interfaces,
which are called abstract ports, and the operations that are made
available through those interfaces. One object may provide multiple
abstract ports.

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

NOTE -- 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 \[6\]). 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.

### 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 that is accepted (or rejected) by another object (the
responder).

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

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

## Service Management

SLE service management determines the number and schedule of RAF 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 RF channel to the RAF data
    channel.

Certain configuration parameters are associated with provision of RAF
service while others are associated with production. Changes to RAF
provision configuration parameters (e.g., quality of service) affect
only a single service instance; the values of such parameters are
initialized by service management when the service instance is created
but may be modified subsequently by the user through RAF service
operations specified in this Recommendation. Changes to RAF production
configuration parameters (e.g., bit rate, frame length, coding type)
potentially affect multiple service instances or potentially impact SLE
Complex resources; consequently, those parameters may be modified only
through service management.

RAF service may be user-initiated (i.e., the user invokes the bind
operation) or provider-initiated (i.e., the provider invokes the bind
operation). A particular instance of RAF service shall support either
user initiation or provider initiation but not both. The form of
initiation that applies to a particular service instance is set by
service management.

The SLE Reference Model defines two data delivery modes: online deliver
mode and offline deliver mode. Online delivery mode indicates that the
provision of service is generally coincident in time with the space link
session, whereas offline delivery mode indicates that the telemetry
frames acquired during a space link session are provided to the user
some time after the end of the space link session. Within the online
delivery mode, the RAF service recognizes two variations: timely online
deliver mode and complete online delivery mode. Both the timely and
complete online delivery modes assume the use of a reliable
communications service. They differ in that the timely mode allows for
the controlled discarding of telemetry frames at the application layer
if it is not possible to deliver those frames within a certain amount of
time after they are acquired from the space link (e.g., because of
communications service backlog). While the RAF service is defined for
the complete online delivery mode, the timely online delivery mode, or
the offline delivery mode, any particular instance of RAF service shall
support only one of those modes. The delivery mode applicable to a
particular service instance is set by service management.

## Architecture Model---Functional View

### Return space link processing functional group

The Return Space Link Processing Functional Group (shown in figure 2-1)
is the SLE functional group (SLE-FG) that produces the RAF service and
the Return Insert service. The latter service is not addressed by this
Recommendation but is defined in reference \[1\].

![](media/image4.wmf)

Figure 2-1: Return Space Link Processing SLE-FG

As described in reference \[1\], the Return Space Link Processing
Functional Group consumes a space link data channel consisting of a
stream of space link data units (SL-DUs). It produces an SLE data
channel (viz., an RAF channel) consisting of a stream of SLE service
data units (SLE-SDUs) for delivery to users. The SL-DUs are the
telemetry frames carried on the space link physical channel. Most
SLE-SDUs encapsulate an SL-DU; such SLE-SDUs also carry annotation
information associated with that SL-DU (e.g., its ERT). Other SLE-SDUs
carry notification of the occurrence of certain events while the RAF
service is being produced (e.g., loss of frame synchronization). More
specifically, the Return Space Link Processing Functional Group performs
the following functions with respect to RAF service:

a)  utilizes the underlying antenna steering, microwave amplification,
    and receiver tuning capabilities of the ground element to acquire a
    radio frequency (RF) carrier channel;

b)  demodulates a physical channel, consisting of a stream of digital
    symbols, from the RF carrier channel;

c)  synchronizes and recovers telemetry frames from the physical
    channel;

d)  performs convolutional decoding, removal of pseudo-randomization,
    error control field decoding, and/or Reed-Solomon decoding as
    applicable (see references \[2\], \[3\], and \[4\]);

e)  annotates each frame to form an RAF SLE-SDU and injects the
    resulting RAF SLE-SDU into the RAF channel associated with the
    physical channel from which the frame was extracted;

f)  optionally, stores (and subsequently retrieves) sufficient data to
    reconstruct the RAF channel for delivery through one or more offline
    RAF service instances;

g)  makes the RAF channel available to online and offline RAF service
    instances to enable the provision of RAF service.

The telemetry frames delivered by the RAF service are encapsulated in
SLE-SDUs. RAF SLE-SDUs that encapsulate telemetry frames are annotated
with information that pertains to that specific frame. The annotation
consists of:

a)  the ERT of the frame;

b)  an identifier that indicates the antenna used to acquire the frame;

c)  an indication of whether the frame contains detected, uncorrectable
    bit errors;

d)  a parameter that characterizes the data link continuity of this
    frame with respect to the preceding frame on the space link;

e)  an optional octet string that may be used to provide additional,
    non-standard annotations that are mutually agreed to by the SLE
    Complex providing the service and the Mission Data Operations System
    (MDOS) associated with the user of the service.

In the case that an acquired frame is Reed-Solomon encoded and the frame
quality is 'good' (i.e., the frame is decoded successfully), then the
Reed-Solomon check symbols are removed from the frame prior to its
encapsulation into the SLE-SDU. If the frame quality of a Reed-Solomon
encoded frame is 'erred' (i.e., the frame is undecodable), then the
entire frame, including the Reed-Solomon check symbols, is encapsulated
into the SLE-SDU for delivery to the user.

NOTES

1.  SLE Return Space Link Processing requires that, at any given time,
    the coding options must be the same for all frames on a physical
    channel. This is more restrictive than the constraints imposed by
    references \[2\], \[3\], and \[4\]. In particular, Reed-Solomon
    coding must be present or absent on all of the frames of a physical
    channel. RAF service is not supported where there is a concurrent
    mix, on one physical channel, of some frames with Reed-Solomon
    coding and some frames without.

2.  Acquisition of a frame implies that the attached sync markers
    preceding and following the frame are identified, exhibit the same
    data polarity, and delimit the correct number of bits.

3.  As defined by this Recommendation, telemetry frames do not include
    the attached sync marker but are delimited by them.

4.  Implementations of RAF service may (but are not required to) provide
    an option that delivers to the user the entire frame (i.e.,
    including the Reed-Solomon check symbols) even if the frame decoded
    successfully.

### RAF Service PRODUCTION AND provision

One instance of RAF service production (or, one instance of the Return
Space Link Processing SLE-FG) may be associated with multiple RAF
service instances. RAF production is concerned with the acquisition of
frames from the space link and their annotation to form a stream of
SLE-SDUs independent of any particular instance of service. In contrast,
RAF service provision is concerned with delivering the stream of
SLE-SDUs to an RAF service user. Service provision addresses such
matters as when service is provided (e.g., service start and stop
times), how service is provided (e.g., user-initiated or
provider-initiated), and quality of service (e.g., whether frames
containing known bit errors are delivered to the user).

The SLE-SDUs generated by RAF service production are delivered to the
service user by means of the RAF service operations defined in section
3, which also provide additional functionality to facilitate the
provision of RAF service. In turn, the RAF service operations are
realized as SLE protocol data units (SLE-PDUs) that are exchanged
between the RAF service provider and the RAF service user by means of an
underlying communications service. Typically, an SLE-PDU corresponds to
the invocation or return of an RAF operation. (Because of the buffering
mechanisms described in 3.1.8, there are certain exceptions; for
example, multiple RAF-TRANSFER-DATA invocations may be mapped to a
single SLE-PDU.) 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 RAF-TRANSFER-DATA
and RAF-SYNC-NOTIFY operations defined in section 3.

![](media/image5.wmf)

Figure 2-2: RAF Service Production and Provision

For the online delivery mode, production and provision of the RAF
service by the provider occur, at least in part, concurrently with the
space link session. For the offline delivery mode, service production
and provision are detached, with service provision occurring some time
after the end of the space link session. In the offline case, data
acquired during the space link session are stored for later delivery by
an offline service instance.

## Architecture Model---Cross Support View

The management and control of the production and provision of SLE
transfer services is described in general terms in reference \[1\].
Figure 2-3 shows an example operational scenario and the related binding
of RAF transfer service ports and SLE management ports. This scenario
shows an SLE Complex with one Return Space Link Processing SLE-FG
instance providing two instances of RAF service to a Mission Data
Operations System.

NOTE -- Although not shown in this scenario, many other combinations are
possible. For example, it is also possible to have several SLE-FG
instances, each consuming a different physical channel and each
providing one or more instances of service.

![](media/image6.wmf)

Figure 2-3: Example of the Management and Provision of RAF Service

## Functional Description

### GENERAL

This subsection describes the RAF service with respect to scheduling,
configuration, underlying services, provider states, and protocol
considerations.

### SCHEDULING AND CONFIGURATION

SLE Utilization Management negotiates with SLE Complex Management to
establish mutually agreed upon SLE service packages. Among other things,
SLE service packages specify what service instances are to be provided,
when those services are to be provided, and what resources are needed to
enable those services.

Service packages also specify the initial values of mission-dependent
parameters required for service production and provision. RAF service
production parameters include such things as the frequency of the RF
carrier channel, the modulation type, the bit rate, the telemetry
channel coding in use, and the scheduled start and stop times of the
space link session. RAF service provision parameters include such things
as the scheduled start and stop times of the RAF service instance and
the delivery mode.

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.

### UNDERLYING SERVICES

The RAF service does not depend on any other SLE transfer service.
Provision of RAF Transfer service does depend on:

a)  service management for scheduling, resources, and configuration;

b)  the availability of a suitable communications service to enable the
    exchange of information between the RAF service user and provider;
    and

c)  the functioning of RAF production resources (e.g., receiver,
    decoder, frame synchronizer) that acquire frames from the space
    link.

### PROTOCOL DESCRIPTION

#### RAF Operations

The operations that constitute the RAF service are listed in table 2-1.
Section 3 of this Recommendation provides the detailed specification of
these operations.

Table 2-1: RAF Operations

  ------------------------------------------------------------------------------------------
  **Operation**                **Invoked   **Purpose**                       **Confirmed**
                               By**                                          
  ---------------------------- ----------- --------------------------------- ---------------
  RAF-BIND                     User or     To establish an association with  Yes
                               provider    the peer                          

  RAF-UNBIND                   User or     To release an association         Yes
                               provider    previously established by an      
                                           RAF-BIND operation                

  RAF-START                    User        To request that the SLE service   Yes
                                           provider start the delivery of    
                                           telemetry frames                  

  RAF-STOP                     User        To request that the SLE service   Yes
                                           provider stop the delivery of     
                                           telemetry frames                  

  RAF-TRANSFER-DATA            Provider    To transfer a telemetry frame to  No
                                           the SLE service user              

  RAF-SYNC-NOTIFY              Provider    To notify the user of an event    No
                                           affecting production or provision 
                                           of the RAF service                

  RAF-SCHEDULE-STATUS-REPORT   User        To request that the provider send Yes
                                           a status report immediately or    
                                           periodically or to stop such      
                                           reporting                         

  RAF-STATUS-REPORT            Provider    To send a status report to the    No
                                           user                              

  RAF-GET-PARAMETER            User        To ascertain the value of an SLE  Yes
                                           service parameter                 
                                           (see 3.10.2.5.1)                  

  RAF-PEER-ABORT               User or     To notify the peer that the local No
                               Provider    SLE application detected an error 
                                           that requires the association to  
                                           be terminated                     
  ------------------------------------------------------------------------------------------

#### States of the Service Provider

Once an RAF service instance is created, the RAF 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 RAF 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 RAF 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, the delivery of telemetry frames (by means of the
    RAF-TRANSFER-DATA operation) is not permitted. The user may enable
    the delivery of telemetry frames by means of the appropriate service
    operation (RAF-START); that, in turn, will cause the provider to
    transition to state 3 ('active') and enable frame delivery.

c)  State 3 ('active'): State 3 is identical to state 2 ('ready') except
    that all telemetry frames are delivered to the user as they become
    available. The service continues in this state until the user
    invokes the RAF-STOP operation to suspend frame delivery and
    transition back to state 2 (e.g., in response to an 'end of data'
    notification from the service provider signaling that the space link
    session has ended and all available frames have been delivered).

A simplified RAF service provider state transition diagram is shown in
figure 2-4. A detailed state transition matrix is provided in section 4.

![](media/image7.wmf)

Figure 2-4: Simplified RAF Service Provider State Transition Diagram

#### Termination of Association

An association is released normally when an RAF-UNBIND operation is
invoked by the initiator of the association and performed by the
responder. An association may be aborted by either the user or the
provider by means of the RAF-PEER-ABORT operation. An association also
may be aborted because of certain failures of the communications
service; such failures are signaled to the local application by the
'protocol abort' event described in 4.1.5.

#### Effects of Termination

When an association is released or aborted, no further operations shall
be invoked by the user or the provider. As a consequence, the delivery
of frames stops immediately. The user and provider may re-establish an
association via a new RAF-BIND operation if that is consistent with the
schedule for the provision of service. However, status information from
the prior association is not preserved and is not available to the new
association except that:

a)  if the delivery mode is complete online, the contents of the online
    frame buffer (see 3.1.8) shall be persistent;

b)  if the delivery mode is offline, the contents of the offline frame
    buffer (see 3.1.8) shall be persistent;

c)  statistics reported by means of the RAF-STATUS-REPORT operation (see
    3.9) shall be accumulated for the entire service instance provision
    period.

#### Technology-specific Aspects

This Recommendation defines the RAF service. Provision of the RAF
service in a real system also requires a specification of how the RAF
service defined here is mapped to a communications service such that all
invocations and returns of RAF service operations can be conveyed
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 RAF 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 operation
invocations and returns to protocol data units that can be exchanged by
means of the underlying communications service. This Recommendation
conceptualizes such a mapping in two parts. First, RAF service operation
invocations and returns (defined in section 3) are mapped to SLE-PDUs
(defined in annex A). Second, SLE-PDUs are mapped to protocol data units
that can be exchanged by means of the underlying communications service.
The mapping of RAF 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 RAF 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 RAF service to the underlying communications service. Figure 2-5
illustrates a communications realization of the RAF service that results
from such a mapping. The specification of such mappings is the subject
of separate CCSDS Recommendations.

![](media/image8.wmf)

Figure 2-5: Communications Realization of RAF Service

The specification of a mapping of the RAF service onto a particular
communications service must address such things as:

a)  selection of communication networks to ensure connectivity;

b)  compatible configuration of protocol stacks;

c)  specification of port-identifiers and their translation onto the
    underlying communications service; and

d)  specification of security related information.

Because the operations of the RAF 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 RAF-BIND and
RAF-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 RAF-BIND operation (initiator). The
responder port identifier identifies the endpoint that will perform the
RAF-BIND operation (responder). Generally speaking, the information
represented by a port identifier consists of:

a)  information needed in order to route data between two real systems
    over a communications channel or network; and

b)  information needed in order 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 RAF service to the underlying
communications service. If the underlying communications service is
connection-oriented, then the mapping may specify a one-to-one
relationship between SLE associations and communications connections;
however, that is not required. For example, two SLE associations
involving the same pair of SLE endpoints may share a single connection.
In that case, it is the responsibility of the mapping of the RAF service
to the underlying communications service to specify how the SLE-PDUs of
one association are distinguished from the SLE-PDUs of the other
association.

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 an RAF-BIND
invocation for that association. The initiator needs the information to
ensure that the RAF-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 RAF-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 RAF service to the underlying communications
service.

The responder port identifier is included as a parameter of the RAF-BIND
operation. Generally speaking, that is unnecessary; it is only necessary
that SLE application communicate the information represented by the port
identifiers to the underlying communications service. The responder port
identifier is provided as a parameter of the RAF-BIND operation to allow
for the possibility that the implementation of a gateway might be
simplified by the inclusion of this parameter in the RAF-BIND operation.

The information represented by the responder port identifier is
technology-specific. In order to define the RAF-BIND operation in a way
that is not technology-specific, the responder-port-identifier parameter
of the RAF-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.

#### Buffering

##### General

Buffering mechanisms used by the RAF protocol are described in the
following paragraphs. They are formally specified by the requirements in
3.1.8 and the state transition matrix in section 4.

##### Transfer Buffer

As described in 2.6.4.5, RAF operations (specified in section 3) are
mapped to SLE-PDUs (specified in annex A) that are conveyed to the peer
SLE entity by means of the underlying communications service. In
general, there is a one-to-one mapping between SLE-PDUs and the
invocations or returns of RAF operations. However, that is not always
the case. In particular, the RAF protocol provides that multiple
RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY operations may be mapped to a
single SLE-PDU (viz., the SLE-PDU named RafTransferBuffer in annex A).
In terms of the RAF service, the release of the RafTransferBuffer to the
communications service provider is equivalent to the near-simultaneous
invocation of multiple RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY operations.
These operations are invoked in the order in which the original
annotated telemetry frames and synchronous notifications occur. However,
the RAF service provider concatenates them in a buffer, the content of
which forms a single RafTransferBuffer SLE-PDU. This SLE-PDU is the
service data unit passed to the communications provider.

The primary rationale for this approach is as follows: when the data
rate on the space link exceeds the available communications bandwidth or
when the ground communication link is congested or unavailable for a
period of time, use of the complete online delivery mode may lead to the
accumulation of a large backlog of undelivered data, resulting in the
delivery of data past the point of usefulness. The timely online
delivery mode is an alternative that limits the size of the backlog that
is allowed to accumulate by discarding data that cannot be delivered
within a certain time. Furthermore, when data is discarded, it is
discarded 'in chunks', i.e., as a sufficiently large block of contiguous
frames rather than as random frames here and there. In general, this
approach maximizes the usefulness of the data that is delivered.

This result is achieved as follows: as the RAF service provider acquires
telemetry frames and as events that must be synchronously notified
occur, that information is stored in a buffer named the transfer buffer.
The size of this buffer is set by service management to achieve the
appropriate level of 'chunking' of data; this size corresponds to the
maximum-sized RafTransferBuffer SLE-PDU that will be passed to the
communications service provider. (This size must also be compatible with
the size of the service data units that can be handled by the underlying
communications service.) When data is inserted into the transfer buffer,
if the transfer buffer was previously empty, a timer, named the release
timer, is started. The release timer counts down from an initial time
value, named the latency limit, that is set by service management. If
the transfer buffer becomes full or if the release timer expires, the
entire transfer buffer, in the form of one RafTransferBuffer SLE-PDU, is
passed to the communications service provider as one service data unit.
If new data needs to be inserted into the transfer buffer, but the
transfer buffer is full and cannot be passed to the communications
service provider because of congestion of the communications service,
then the entire transfer buffer is discarded as one unit. When this
happens, the new data is inserted into the newly-emptied transfer
buffer, along with a synchronous notification that some data was
intentionally discarded because of timeliness considerations.

Strictly speaking, the transfer buffer is only required in the case of
timely online delivery mode. However, the transfer buffer mechanism has
a secondary benefit: it allows for 'tuning' of the size of the service
data units that are normally passed to the communications service
provider. In some cases, this may contribute to enabling the
communications service to operate more efficiently. Thus, the transfer
buffer is used in all delivery modes. However, in the case of complete
online delivery mode and offline delivery mode, data in the transfer
buffer is never discarded. Rather, the contents of the transfer buffer
are held until they can be passed to the communications service
provider. Any backlog that may accumulate is handled by means of the
online frame buffer or offline frame buffer (see 2.6.4.6.3).

##### Online Frame Buffer and Offline Frame Buffer

In the case of the timely online delivery mode, the only buffering that
occurs is that provided by the transfer buffer. For complete online
delivery mode and for offline delivery mode, additional buffering is
needed because of the nature of the service. Since the complete online
delivery mode is supposed to deliver all data even in the case of
extended communications service outages or congestion and since the
offline delivery mode is supposed to deliver all data even several days
after the space link session, more extensive buffering is required for
these modes. This buffering is provided by means of the online frame
buffer or the offline frame buffer, respectively. These buffers are
relatively large and intended to hold all data (i.e., RAF-TRANSFER-DATA
and, in the case of online delivery mode, RAF-SYNC-NOTIFY) for
significant periods of time. In the case of complete online delivery
mode, the online frame buffer is intended to overcome limitations of the
communications service: bandwidth limitations, outages, and congestion.
In the case of offline delivery mode, the offline frame buffer is
intended to enable data to be delivered hours or days after the
completion of the space link session. The exact size of these buffers is
set by service management. It is normally expected that the online frame
buffer is sufficiently large to hold all data that might be accumulated
during one space link session and that the offline frame buffer is
sufficiently large to hold all data that might be accumulated during
several space link sessions.

NOTE -- Synchronous notifications are generally not provided in offline
mode, so the data associated with such notifications is not stored in
the offline frame buffer.

Figure 2‑6 illustrates the differences between timely online delivery
mode, complete online deliver mode, and offline delivery mode with
respect to the buffers that are used.

![](media/image9.wmf)

Figure 2‑6: Buffers and Delivery Modes

## Operational Scenario

The following paragraphs illustrate a typical operational scenario for a
user-initiated, online delivery mode RAF service instance:

a)  Prior to the actual provision of service, start and stop times for
    both the space link session and the associated RAF service instance
    are mutually agreed upon by SLE Complex Management and SLE
    Utilization Management. Configuration and other information needed
    to enable the service are also agreed upon.

b)  Some time before the scheduled start time of the RAF 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 Complex
    acquires the signal from the spacecraft and initiates the production
    of RAF service. 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.

c)  The user invokes the RAF-BIND operation to establish an association.

d)  The provider transitions from state 1 to state 2 ('ready') and
    returns a report of the successful completion of the bind operation
    to the user.

e)  The user may now check parameters that control service provision by
    means of the RAF-GET-PARAMETER operation.

f)  If the user is interested in obtaining periodic status reports, the
    RAF-SCHEDULE-STATUS-REPORT operation may be invoked to configure
    status reporting.

g)  The user invokes the RAF-START operation to enable data flow.

h)  The provider transitions from state 2 to state 3 ('active') and
    confirms the RAF-START operation to the user. As telemetry frames
    that meet the delivery criteria established by the user become
    available, they are delivered to the user by means of
    RAF-TRANSFER-DATA operations. In addition, notifications may be
    delivered by means of RAF-SYNC-NOTIFY operations, and requested
    status reports are delivered by means of RAF-STATUS-REPORT
    operations.

i)  When all available frames are delivered, the provider will invoke
    the RAF-SYNC-NOTIFY operation to provide an 'end of data'
    notification. The 'end of data' notification may be triggered, for
    example, because the space link session ended and all frames have
    been delivered or because the user specified a value for the
    stop-time parameter when invoking the RAF-START operation.

j)  By invoking the RAF-STOP operation the user will cause the provider
    to transition to state 2 ('ready'). The user may then ask for
    another set of frames by invoking another RAF-START command or may
    terminate the association by invoking RAF-UNBIND.

# RAF Service Operations

NOTE -- This section (3) specifies the processing of valid SLE-PDUs
(i.e., those that are recognized as the invocation or return of an RAF
service operation). Subsection 3.1 specifies behaviors that are
generally applicable to all operations. Subsections 3.2 through 3.11
specify individual operations. Handling of invalid SLE-PDUs is specified
in 4.1.

## General Considerations

### result of operations

#### All confirmed operations shall report on the outcome of the operation in a return, except as specified otherwise in section 4. {#all-confirmed-operations-shall-report-on-the-outcome-of-the-operation-in-a-return-except-as-specified-otherwise-in-section-4. .Paragraph-4}

#### All returns shall include a result parameter that indicates whether the outcome of the operation was successful ('positive result') or unsuccessful ('negative result'). {#all-returns-shall-include-a-result-parameter-that-indicates-whether-the-outcome-of-the-operation-was-successful-positive-result-or-unsuccessful-negative-result. .Paragraph-4}

#### In the event of a 'negative result', the return shall also include a diagnostic parameter, the value of which is descriptive of the reason for the 'negative result'. {#in-the-event-of-a-negative-result-the-return-shall-also-include-a-diagnostic-parameter-the-value-of-which-is-descriptive-of-the-reason-for-the-negative-result. .Paragraph-4}

NOTE -- Possible values of the diagnostic parameter are listed in the
description of each operation.

#### A diagnostic parameter value of 'other reason' shall be returned only if no other value in the list adequately describes the reason for the 'negative result'. {#a-diagnostic-parameter-value-of-other-reason-shall-be-returned-only-if-no-other-value-in-the-list-adequately-describes-the-reason-for-the-negative-result. .Paragraph-4}

### 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 such 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 may be specified as being of the 'named integer' type.

### Parameter chECKING

#### Validity checks shall be performed on the values of parameters associated with an operation. {#validity-checks-shall-be-performed-on-the-values-of-parameters-associated-with-an-operation. .Paragraph-4}

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.

#### A parameter value shall be treated as invalid if it is outside the range or not in the set of values currently permitted by service management for the given parameter. {#a-parameter-value-shall-be-treated-as-invalid-if-it-is-outside-the-range-or-not-in-the-set-of-values-currently-permitted-by-service-management-for-the-given-parameter. .Paragraph-4}

NOTE -- A conforming implementation shall be capable of supporting the
full range or set of values as specified in annex A.

#### A parameter value shall be treated as invalid if it is in conflict with the value of another parameter in the same invocation. {#a-parameter-value-shall-be-treated-as-invalid-if-it-is-in-conflict-with-the-value-of-another-parameter-in-the-same-invocation. .Paragraph-4}

NOTE -- For example, the value of the start-time parameter in an
invocation of RAF-START is invalid if it is later than the value of the
stop-time parameter.

#### If a parameter value is not valid, the operation shall not be performed, and, for confirmed operations, a report of 'negative result' shall be returned to the invoker. {#if-a-parameter-value-is-not-valid-the-operation-shall-not-be-performed-and-for-confirmed-operations-a-report-of-negative-result-shall-be-returned-to-the-invoker. .Paragraph-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. {#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. .Paragraph-4}

#### In the case that an implementation does not adhere to the sequence of checks as specified by the sequence of diagnostics values, such implementation shall specify the sequence in which the checks are actually performed. {#in-the-case-that-an-implementation-does-not-adhere-to-the-sequence-of-checks-as-specified-by-the-sequence-of-diagnostics-values-such-implementation-shall-specify-the-sequence-in-which-the-checks-are-actually-performed. .Paragraph-4}

### Access Control

#### For each instance of RAF service, service management shall specify the authorized initiator and responder. {#for-each-instance-of-raf-service-service-management-shall-specify-the-authorized-initiator-and-responder. .Paragraph-4}

#### When processing an RAF-BIND invocation, the responder shall verify that the initiator, as indicated by the initiator-identifier parameter of the invocation, is the authorized initiator for this service instance; if not, the responder shall not perform the RAF-BIND and shall return a 'negative result' to the initiator. {#when-processing-an-raf-bind-invocation-the-responder-shall-verify-that-the-initiator-as-indicated-by-the-initiator-identifier-parameter-of-the-invocation-is-the-authorized-initiator-for-this-service-instance-if-not-the-responder-shall-not-perform-the-raf-bind-and-shall-return-a-negative-result-to-the-initiator. .Paragraph-4}

#### When processing the return from RAF-BIND, the initiator shall verify that the responder, as indicated by the responder-identifier parameter of the return, is the authorized responder for this service instance; if not, the initiator shall abnormally terminate the association by invoking RAF-PEER-ABORT. {#when-processing-the-return-from-raf-bind-the-initiator-shall-verify-that-the-responder-as-indicated-by-the-responder-identifier-parameter-of-the-return-is-the-authorized-responder-for-this-service-instance-if-not-the-initiator-shall-abnormally-terminate-the-association-by-invoking-raf-peer-abort. .Paragraph-4}

### Authentication

NOTE -- Requirements for security depend on the application and 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.

#### The RAF service shall provide the following options with respect to the level of authentication of invocations and returns of operations: {#the-raf-service-shall-provide-the-following-options-with-respect-to-the-level-of-authentication-of-invocations-and-returns-of-operations .Paragraph-4}

a)  'all': all RAF invocations and returns, except the invocation of
    RAF-PEER-ABORT, shall be authenticated;

b)  'bind': only the RAF-BIND invocation and return shall be
    authenticated;

c)  'none': no RAF invocations or returns shall be authenticated.

#### SLE Complex Management and SLE Utilization Management shall agree on the level of authentication to be required for an association between a service user and a service provider and shall configure both entities accordingly. {#sle-complex-management-and-sle-utilization-management-shall-agree-on-the-level-of-authentication-to-be-required-for-an-association-between-a-service-user-and-a-service-provider-and-shall-configure-both-entities-accordingly. .Paragraph-4}

#### SLE Complex Management and SLE Utilization Management shall agree on the algorithm used to generate and check credentials parameters and shall make this algorithm known to the service user and service provider together with associated parameters such as passwords or keys as necessary for the selected algorithm. {#sle-complex-management-and-sle-utilization-management-shall-agree-on-the-algorithm-used-to-generate-and-check-credentials-parameters-and-shall-make-this-algorithm-known-to-the-service-user-and-service-provider-together-with-associated-parameters-such-as-passwords-or-keys-as-necessary-for-the-selected-algorithm. .Paragraph-4}

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
    RAF-BIND operation identify the user and provider and therefore the
    applicable authentication level and algorithm necessary to generate
    and check credentials.

#### For operations for which authentication is required by the terms of the agreement between SLE Complex Management and SLE Utilization Management: {#for-operations-for-which-authentication-is-required-by-the-terms-of-the-agreement-between-sle-complex-management-and-sle-utilization-management .Paragraph-4}

a)  invocations shall include an invoker-credentials parameter to permit
    the performer to authenticate the invocation;

b)  returns shall include a performer-credentials parameter to permit
    the invoker to authenticate the return.

#### For operations for which authentication 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. {#for-operations-for-which-authentication-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. .Paragraph-4}

### Blocking and Non-Blocking Operations

#### To support applications that may need to invoke several operations concurrently, the parameter invoke-ID is specified for all confirmed operations except RAF-BIND and RAF-UNBIND. {#to-support-applications-that-may-need-to-invoke-several-operations-concurrently-the-parameter-invoke-id-is-specified-for-all-confirmed-operations-except-raf-bind-and-raf-unbind. .Paragraph-4}

NOTES

1.  The invoke-ID parameter allows the invoker to correlate a particular
    return to the invocation that prompted it.

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

#### 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 RAF-PEER-ABORT to terminate the association. {#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-raf-peer-abort-to-terminate-the-association. .Paragraph-4}

#### After invoking a non-blocking operation, the invoker may invoke another operation without waiting for the return from the first invocation. {#after-invoking-a-non-blocking-operation-the-invoker-may-invoke-another-operation-without-waiting-for-the-return-from-the-first-invocation. .Paragraph-4}

#### The value of the invoke-ID parameter shall be an invoker-supplied arbitrary integer value that shall be returned, unchanged, by the performer. {#the-value-of-the-invoke-id-parameter-shall-be-an-invoker-supplied-arbitrary-integer-value-that-shall-be-returned-unchanged-by-the-performer. .Paragraph-4}

#### An error condition shall exist if an invocation 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. {#an-error-condition-shall-exist-if-an-invocation-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. .Paragraph-4}

#### To ensure that the RAF 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. {#to-ensure-that-the-raf-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. .Paragraph-4}

#### 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. {#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. .Paragraph-4}

NOTE -- An invoker wishing to operate in blocking mode (i.e., to invoke
a new operation only when 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.

#### 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. {#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. .Paragraph-4}

### TIME

#### The time reference for all parameters containing a time value shall be based on Coordinated Universal Time (UTC). {#the-time-reference-for-all-parameters-containing-a-time-value-shall-be-based-on-coordinated-universal-time-utc. .Paragraph-4}

NOTE -- The type of all time parameters is specified in annex A.

#### The earth-receive-time parameter (see 3.6.2.3) shall be expressed using the CCSDS Day Segmented (CDS) time code (reference \[5\]) with a resolution of one microsecond, an epoch of 1958-01-01, and a 16-bit day segment. {#the-earth-receive-time-parameter-see-3.6.2.3-shall-be-expressed-using-the-ccsds-day-segmented-cds-time-code-reference-5-with-a-resolution-of-one-microsecond-an-epoch-of-1958-01-01-and-a-16-bit-day-segment. .Paragraph-4}

#### The earth-receive-time parameter shall have a precision of one millisecond or better. {#the-earth-receive-time-parameter-shall-have-a-precision-of-one-millisecond-or-better. .Paragraph-4}

#### The earth-receive-time parameter shall be accurate to within one millisecond or better. {#the-earth-receive-time-parameter-shall-be-accurate-to-within-one-millisecond-or-better. .Paragraph-4}

### DELIVERY MODES

#### Timely Online Delivery Mode

##### For timely online delivery mode, the RAF service provider shall store frames acquired from the space link and certain information associated with those frames (as per 3.6.2) in a buffer called the transfer buffer. The stored information shall be an RAF-TRANSFER-DATA invocation or the equivalent thereof. {#for-timely-online-delivery-mode-the-raf-service-provider-shall-store-frames-acquired-from-the-space-link-and-certain-information-associated-with-those-frames-as-per-3.6.2-in-a-buffer-called-the-transfer-buffer.-the-stored-information-shall-be-an-raf-transfer-data-invocation-or-the-equivalent-thereof. .Paragraph-5}

NOTE -- For convenience, the following paragraphs are written as if the
contents of the transfer buffer consist of an ordered list of records of
type Raf­Transfer­Data­Invocation (see A2.6) or type
RafSyncNotifyInvocation (see 3.1.8.1.2 and A2.6). However, that is not
intended to constrain how the transfer buffer is implemented in a real
system. It is sufficient that a real system provide the externally
visible behaviors that are specified herein.

##### Upon the occurrence of any of several events that cause a change to or disruption of the data being provided to the service instance, the RAF service provider shall store a synchronous notification record of the event in the transfer buffer. The notification record shall be an RAF-SYNC-NOTIFY invocation or the equivalent thereof. The notification record shall be stored in the transfer buffer after the last annotated frame acquired before the event and before the first annotated frame acquired following the event. The events and associated information that are stored shall be as defined in 3.7; in particular, at the end of the space link session, an 'end of data' RafSyncNotifyInvocation shall be stored following the last RafTransferDataInvocation. {#upon-the-occurrence-of-any-of-several-events-that-cause-a-change-to-or-disruption-of-the-data-being-provided-to-the-service-instance-the-raf-service-provider-shall-store-a-synchronous-notification-record-of-the-event-in-the-transfer-buffer.-the-notification-record-shall-be-an-raf-sync-notify-invocation-or-the-equivalent-thereof.-the-notification-record-shall-be-stored-in-the-transfer-buffer-after-the-last-annotated-frame-acquired-before-the-event-and-before-the-first-annotated-frame-acquired-following-the-event.-the-events-and-associated-information-that-are-stored-shall-be-as-defined-in-3.7-in-particular-at-the-end-of-the-space-link-session-an-end-of-data-rafsyncnotifyinvocation-shall-be-stored-following-the-last-raftransferdatainvocation. .Paragraph-5}

##### If the transfer buffer was empty before the service provider inserted an RafTransferDataInvocation or RafSyncNotifyInvocation record into the transfer buffer, the service provider shall start a timer for the transfer buffer. This timer shall be named the release timer. {#if-the-transfer-buffer-was-empty-before-the-service-provider-inserted-an-raftransferdatainvocation-or-rafsyncnotifyinvocation-record-into-the-transfer-buffer-the-service-provider-shall-start-a-timer-for-the-transfer-buffer.-this-timer-shall-be-named-the-release-timer. .Paragraph-5}

##### The duration from the time that the release timer is started until it expires is given by the parameter latency-limit, the value of which shall be set by service management. {#the-duration-from-the-time-that-the-release-timer-is-started-until-it-expires-is-given-by-the-parameter-latency-limit-the-value-of-which-shall-be-set-by-service-management. .Paragraph-5}

##### For a given instance of RAF service, the transfer buffer shall accommodate a set number of RafTransferDataInvocation and/or RafSyncNotifyInvocation records. That number, given by the parameter transfer-buffer-size, shall be set by service management. {#for-a-given-instance-of-raf-service-the-transfer-buffer-shall-accommodate-a-set-number-of-raftransferdatainvocation-andor-rafsyncnotifyinvocation-records.-that-number-given-by-the-parameter-transfer-buffer-size-shall-be-set-by-service-management. .Paragraph-5}

##### The contents of the transfer buffer shall be passed to the communications service (in the form of one RafTransferBuffer SLE-PDU) and the transfer buffer shall be cleared as soon as one of the following conditions is met: {#the-contents-of-the-transfer-buffer-shall-be-passed-to-the-communications-service-in-the-form-of-one-raftransferbuffer-sle-pdu-and-the-transfer-buffer-shall-be-cleared-as-soon-as-one-of-the-following-conditions-is-met .Paragraph-5}

a)  the buffer is full (i.e., the number of RafTransferDataInvocation
    and/or RafSyncNotifyInvocation records contained in the buffer is
    equal to the value of the transfer-buffer-size parameter); or

b)  the release timer expires.

##### The RafTransferBuffer SLE-PDU shall contain the records in the same sequence as they were inserted into the transfer buffer. {#the-raftransferbuffer-sle-pdu-shall-contain-the-records-in-the-same-sequence-as-they-were-inserted-into-the-transfer-buffer. .Paragraph-5}

##### If the underlying communications service generates backpressure because of congestion (e.g., it does not accept the RafTransferBuffer SLE-PDU or would block the RAF service provider from continuing), the RAF service provider shall discard this RafTransferBuffer SLE-PDU and clear the transfer buffer. It shall then insert a 'data discarded because of excessive backlog' RafSyncNotifyInvocation record into the transfer buffer and restart the release timer. {#if-the-underlying-communications-service-generates-backpressure-because-of-congestion-e.g.-it-does-not-accept-the-raftransferbuffer-sle-pdu-or-would-block-the-raf-service-provider-from-continuing-the-raf-service-provider-shall-discard-this-raftransferbuffer-sle-pdu-and-clear-the-transfer-buffer.-it-shall-then-insert-a-data-discarded-because-of-excessive-backlog-rafsyncnotifyinvocation-record-into-the-transfer-buffer-and-restart-the-release-timer. .Paragraph-5}

##### If the transfer buffer size is 1 when the 'data discarded because of excessive backlog' RafSyncNotifyInvocation record is inserted into the transfer buffer, the size of the transfer buffer shall be incremented to 2. That new size shall remain in effect until the contents of the transfer buffer are passed to the communications service, after which the transfer buffer size shall be decremented back to 1. {#if-the-transfer-buffer-size-is-1-when-the-data-discarded-because-of-excessive-backlog-rafsyncnotifyinvocation-record-is-inserted-into-the-transfer-buffer-the-size-of-the-transfer-buffer-shall-be-incremented-to-2.-that-new-size-shall-remain-in-effect-until-the-contents-of-the-transfer-buffer-are-passed-to-the-communications-service-after-which-the-transfer-buffer-size-shall-be-decremented-back-to-1. .Paragraph-5}

NOTE -- The temporary increment in the transfer buffer size ensures a
minimum of telemetry flow in case of congestion. Otherwise, only 'data
discarded because of excessive backlog' notifications might be sent.

##### When the RAF service provider accepts an RAF-STOP invocation from the user, it shall immediately build from the transfer buffer contents an RafTransferBuffer SLE-PDU and shall immediately pass that to the communications service, subject to the provisions in 3.1.8.1.8. {#when-the-raf-service-provider-accepts-an-raf-stop-invocation-from-the-user-it-shall-immediately-build-from-the-transfer-buffer-contents-an-raftransferbuffer-sle-pdu-and-shall-immediately-pass-that-to-the-communications-service-subject-to-the-provisions-in-3.1.8.1.8. .Paragraph-5}

##### The transfer buffer shall be cleared whenever the association is aborted. {#the-transfer-buffer-shall-be-cleared-whenever-the-association-is-aborted. .Paragraph-5}

##### Only RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY invocations shall be buffered through the transfer buffer. The invocations or returns of all other operations shall be asynchronous (in the sense that they are not required to be invoked or returned in sequence with respect to the delivery of the contents of the transfer buffer). Therefore, they shall be invoked or returned as soon as possible without regard to the contents of the transfer buffer. {#only-raf-transfer-data-and-raf-sync-notify-invocations-shall-be-buffered-through-the-transfer-buffer.-the-invocations-or-returns-of-all-other-operations-shall-be-asynchronous-in-the-sense-that-they-are-not-required-to-be-invoked-or-returned-in-sequence-with-respect-to-the-delivery-of-the-contents-of-the-transfer-buffer.-therefore-they-shall-be-invoked-or-returned-as-soon-as-possible-without-regard-to-the-contents-of-the-transfer-buffer. .Paragraph-5}

#### Complete Online Delivery Mode

##### For complete online delivery mode, the RAF service provider shall store frames acquired from the space link and certain information associated with those frames (as per 3.6.2) in a buffer called the online frame buffer. The stored information shall be an RAF-TRANSFER-DATA invocation or the equivalent thereof. {#for-complete-online-delivery-mode-the-raf-service-provider-shall-store-frames-acquired-from-the-space-link-and-certain-information-associated-with-those-frames-as-per-3.6.2-in-a-buffer-called-the-online-frame-buffer.-the-stored-information-shall-be-an-raf-transfer-data-invocation-or-the-equivalent-thereof. .Paragraph-5}

NOTES

1.  Complete online delivery mode attempts to deliver all acquired
    frames, in order, with minimum delay consistent with the available
    ground communications bandwidth. Complete online delivery requires
    that the online frame buffer be sufficiently large to deal with
    communications service delays, outages, and bandwidth limitations.

2.  For convenience, the following paragraphs are written as if the
    contents of the online frame buffer and the transfer buffer consist
    of an ordered list of records of type Raf­Transfer­Data­Invocation (see
    A2.6) or type RafSyncNotifyInvocation (see 3.1.8.2.2 and A2.6).
    However, that is not intended to constrain how the online frame
    buffer or the transfer buffer is implemented in a real system. It is
    sufficient that a real system provide the externally-visible
    behaviors that are specified herein.

##### Upon the occurrence of any of several events that cause a change to or disruption of the data being provided to the service instance, the RAF service provider shall store a synchronous notification record of the event in the online frame buffer. The notification record shall be an RAF-SYNC-NOTIFY invocation or the equivalent thereof. The notification record shall be stored following the last annotated frame acquired before the event and before the first annotated frame acquired following the event. The events and associated information that are stored shall be as defined in 3.7; in particular, at the end of the space link session, an 'end of data' RafSyncNotifyInvocation shall be stored following the last RafTransferDataInvocation. {#upon-the-occurrence-of-any-of-several-events-that-cause-a-change-to-or-disruption-of-the-data-being-provided-to-the-service-instance-the-raf-service-provider-shall-store-a-synchronous-notification-record-of-the-event-in-the-online-frame-buffer.-the-notification-record-shall-be-an-raf-sync-notify-invocation-or-the-equivalent-thereof.-the-notification-record-shall-be-stored-following-the-last-annotated-frame-acquired-before-the-event-and-before-the-first-annotated-frame-acquired-following-the-event.-the-events-and-associated-information-that-are-stored-shall-be-as-defined-in-3.7-in-particular-at-the-end-of-the-space-link-session-an-end-of-data-rafsyncnotifyinvocation-shall-be-stored-following-the-last-raftransferdatainvocation. .Paragraph-5}

##### The RAF service provider shall start to fill the online frame buffer as soon as both the service instance provision period and the space link session have started and frames are being acquired from the space link. {#the-raf-service-provider-shall-start-to-fill-the-online-frame-buffer-as-soon-as-both-the-service-instance-provision-period-and-the-space-link-session-have-started-and-frames-are-being-acquired-from-the-space-link. .Paragraph-5}

##### While the RAF service provider is in state 3 ('active') and the transfer buffer is not full, the provider shall remove RafTransferDataInvocation and RafSyncNotifyInvocation records from the online frame buffer and insert them, in the same sequence, into the transfer buffer. {#while-the-raf-service-provider-is-in-state-3-active-and-the-transfer-buffer-is-not-full-the-provider-shall-remove-raftransferdatainvocation-and-rafsyncnotifyinvocation-records-from-the-online-frame-buffer-and-insert-them-in-the-same-sequence-into-the-transfer-buffer. .Paragraph-5}

##### As soon as the transfer buffer is full or an 'end of data' RafSyncNotifyInvocation record is inserted into the transfer buffer or the provider has accepted an RAF-STOP invocation, the service provider shall stop extracting RafTransferData or RafSyncNotify records from the online frame buffer and build an RafTransferBuffer SLE-PDU from the transfer buffer contents. The provider shall attempt to pass this SLE-PDU to the communications service until it is accepted. {#as-soon-as-the-transfer-buffer-is-full-or-an-end-of-data-rafsyncnotifyinvocation-record-is-inserted-into-the-transfer-buffer-or-the-provider-has-accepted-an-raf-stop-invocation-the-service-provider-shall-stop-extracting-raftransferdata-or-rafsyncnotify-records-from-the-online-frame-buffer-and-build-an-raftransferbuffer-sle-pdu-from-the-transfer-buffer-contents.-the-provider-shall-attempt-to-pass-this-sle-pdu-to-the-communications-service-until-it-is-accepted. .Paragraph-5}

##### When the communications service provider has accepted the RafTransferBuffer SLE-PDU, the RAF service provider shall clear the transfer buffer and resume removing frames and synchronous notifications from the online frame buffer as described above. {#when-the-communications-service-provider-has-accepted-the-raftransferbuffer-sle-pdu-the-raf-service-provider-shall-clear-the-transfer-buffer-and-resume-removing-frames-and-synchronous-notifications-from-the-online-frame-buffer-as-described-above. .Paragraph-5}

##### The RAF service provider shall continue to remove Raf­Transfer­Data­Invocation and Raf­Sync­Notify­Invocation records from the online frame buffer, insert them into the transfer buffer, and pass the contents of the transfer buffer to the communications service as long as the service instance remains in state 3 ('active'). {#the-raf-service-provider-shall-continue-to-remove-raftransferdatainvocation-and-rafsyncnotifyinvocation-records-from-the-online-frame-buffer-insert-them-into-the-transfer-buffer-and-pass-the-contents-of-the-transfer-buffer-to-the-communications-service-as-long-as-the-service-instance-remains-in-state-3-active. .Paragraph-5}

##### In the complete online delivery mode, the transfer buffer shall be cleared and removal of frames and synchronous notifications from the online frame buffer shall stop whenever: {#in-the-complete-online-delivery-mode-the-transfer-buffer-shall-be-cleared-and-removal-of-frames-and-synchronous-notifications-from-the-online-frame-buffer-shall-stop-whenever .Paragraph-5}

a)  the user stops data flow by invoking the RAF-STOP operation; or

b)  the association is aborted.

##### The RAF service provider shall continue to store acquired frames and notification records in the online frame buffer until the end of the service instance provision period, regardless of the state of the service instance and regardless of whether an association with the service user is established. {#the-raf-service-provider-shall-continue-to-store-acquired-frames-and-notification-records-in-the-online-frame-buffer-until-the-end-of-the-service-instance-provision-period-regardless-of-the-state-of-the-service-instance-and-regardless-of-whether-an-association-with-the-service-user-is-established. .Paragraph-5}

##### In the case that the user invokes the RAF-STOP operation or the association becomes unbound, the user may, after re-binding if necessary, invoke a new RAF-START operation, with a start time in the past, to effect delivery of the data buffered in the online frame buffer. Any frames with an ERT older than the start time specified in the RAF-START operation and any notifications falling into the same interval shall be removed from the online frame buffer. {#in-the-case-that-the-user-invokes-the-raf-stop-operation-or-the-association-becomes-unbound-the-user-may-after-re-binding-if-necessary-invoke-a-new-raf-start-operation-with-a-start-time-in-the-past-to-effect-delivery-of-the-data-buffered-in-the-online-frame-buffer.-any-frames-with-an-ert-older-than-the-start-time-specified-in-the-raf-start-operation-and-any-notifications-falling-into-the-same-interval-shall-be-removed-from-the-online-frame-buffer. .Paragraph-5}

##### If the online frame buffer becomes full (e.g., because an extended communications outage prevents it from being emptied), the provider shall discard Raf­Transfer­Data­Invocation and Raf­Sync­Notify­Invocation records from the online frame buffer in oldest-first order. The number of frames to be discarded in such event is set by service management. The RAF service provider shall also insert an RafSyncNotifyInvocation record indicating a 'data discarded' event into the transfer buffer as soon as this is possible. Extraction of Raf­Transfer­Data­Invocation and Raf­Sync­Notify­Invocation records from the online frame buffer shall then resume as before. {#if-the-online-frame-buffer-becomes-full-e.g.-because-an-extended-communications-outage-prevents-it-from-being-emptied-the-provider-shall-discard-raftransferdatainvocation-and-rafsyncnotifyinvocation-records-from-the-online-frame-buffer-in-oldest-first-order.-the-number-of-frames-to-be-discarded-in-such-event-is-set-by-service-management.-the-raf-service-provider-shall-also-insert-an-rafsyncnotifyinvocation-record-indicating-a-data-discarded-event-into-the-transfer-buffer-as-soon-as-this-is-possible.-extraction-of-raftransferdatainvocation-and-rafsyncnotifyinvocation-records-from-the-online-frame-buffer-shall-then-resume-as-before. .Paragraph-5}

NOTE -- For the complete online delivery mode, it is intended that the
size of the online frame buffer be selected such that overflow of the
buffer is a very rare event.

##### If the service user, in the RAF-START invocation, requests a start time earlier than any frame still held in the online frame buffer, the provider shall deliver the earliest data available. {#if-the-service-user-in-the-raf-start-invocation-requests-a-start-time-earlier-than-any-frame-still-held-in-the-online-frame-buffer-the-provider-shall-deliver-the-earliest-data-available. .Paragraph-5}

##### At the end of the scheduled service instance provision period, the contents of the online frame buffer shall be discarded. {#at-the-end-of-the-scheduled-service-instance-provision-period-the-contents-of-the-online-frame-buffer-shall-be-discarded. .Paragraph-5}

##### Only RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY invocations shall be buffered through the online frame buffer and the transfer buffer. The invocations or returns of all other operations shall be asynchronous (in the sense that they are not required to be invoked or returned in sequence with respect to the delivery of the contents of the online frame buffer). Therefore, they shall be invoked or returned as soon as possible without regard to the contents of the online frame buffer or the transfer buffer. {#only-raf-transfer-data-and-raf-sync-notify-invocations-shall-be-buffered-through-the-online-frame-buffer-and-the-transfer-buffer.-the-invocations-or-returns-of-all-other-operations-shall-be-asynchronous-in-the-sense-that-they-are-not-required-to-be-invoked-or-returned-in-sequence-with-respect-to-the-delivery-of-the-contents-of-the-online-frame-buffer.-therefore-they-shall-be-invoked-or-returned-as-soon-as-possible-without-regard-to-the-contents-of-the-online-frame-buffer-or-the-transfer-buffer. .Paragraph-5}

##### During complete online service provision, the RAF service provider shall extract Raf­Transfer­Data­Invocation and RafSyncNotify records from the online frame buffer, insert them into the transfer buffer, and pass RafTransferBuffer SLE-PDUs to the communications service without undue delay, subject only to limitations imposed by the underlying communications service, or to any maximum data rate limitation ('metering') that may be imposed through service management. {#during-complete-online-service-provision-the-raf-service-provider-shall-extract-raftransferdatainvocation-and-rafsyncnotify-records-from-the-online-frame-buffer-insert-them-into-the-transfer-buffer-and-pass-raftransferbuffer-sle-pdus-to-the-communications-service-without-undue-delay-subject-only-to-limitations-imposed-by-the-underlying-communications-service-or-to-any-maximum-data-rate-limitation-metering-that-may-be-imposed-through-service-management. .Paragraph-5}

##### For complete online delivery mode, the size of the online frame buffer and the transfer buffer shall be determined by arrangement between SLE Complex Management and SLE Utilization Management and shall be set by service management. {#for-complete-online-delivery-mode-the-size-of-the-online-frame-buffer-and-the-transfer-buffer-shall-be-determined-by-arrangement-between-sle-complex-management-and-sle-utilization-management-and-shall-be-set-by-service-management. .Paragraph-5}

#### Offline Delivery Mode

##### Any frame acquired from the space link that may need to be provided through an offline delivery mode service instance, as well as certain information associated with the frame (as per 3.6.2), shall be stored in a buffer called the offline frame buffer. The stored information shall be an RAF-TRANSFER-DATA invocation or the equivalent thereof. There should be one offline frame buffer for all service instances associated with a particular service agreement. {#any-frame-acquired-from-the-space-link-that-may-need-to-be-provided-through-an-offline-delivery-mode-service-instance-as-well-as-certain-information-associated-with-the-frame-as-per-3.6.2-shall-be-stored-in-a-buffer-called-the-offline-frame-buffer.-the-stored-information-shall-be-an-raf-transfer-data-invocation-or-the-equivalent-thereof.-there-should-be-one-offline-frame-buffer-for-all-service-instances-associated-with-a-particular-service-agreement. .Paragraph-5}

NOTE -- For convenience, the following paragraphs are written as if the
contents of the offline frame buffer and the transfer buffer consist of
an ordered list of records of type Raf­Transfer­Data­Invocation (see A2.6).
However, that is not intended to constrain how the offline frame buffer
or the transfer buffer is implemented in a real system. It is sufficient
that a real system provide the externally-visible behaviors that are
specified herein.

##### There may be a significant delay from the time when a frame is acquired from the space link until that frame is available for delivery through an offline delivery mode service instance. Every service provider shall document the characteristics of their service with respect to that delay. {#there-may-be-a-significant-delay-from-the-time-when-a-frame-is-acquired-from-the-space-link-until-that-frame-is-available-for-delivery-through-an-offline-delivery-mode-service-instance.-every-service-provider-shall-document-the-characteristics-of-their-service-with-respect-to-that-delay. .Paragraph-5}

##### When an RAF-START operation is invoked in the context of an offline delivery mode RAF service instance, the RAF service provider shall extract Raf­Transfer­Data­Invocation records from the offline frame buffer and insert them into the transfer buffer. Such extraction shall begin with the Raf­Transfer­Data­Invocation record in the offline frame buffer with the earliest ERT that is equal to or later than the start time designated in the RAF-START invocation. Subsequent Raf­Transfer­Data­Invocation records shall be extracted from the offline frame buffer and inserted into the transfer buffer in the same order in which they were originally received from the space link. {#when-an-raf-start-operation-is-invoked-in-the-context-of-an-offline-delivery-mode-raf-service-instance-the-raf-service-provider-shall-extract-raftransferdatainvocation-records-from-the-offline-frame-buffer-and-insert-them-into-the-transfer-buffer.-such-extraction-shall-begin-with-the-raftransferdatainvocation-record-in-the-offline-frame-buffer-with-the-earliest-ert-that-is-equal-to-or-later-than-the-start-time-designated-in-the-raf-start-invocation.-subsequent-raftransferdatainvocation-records-shall-be-extracted-from-the-offline-frame-buffer-and-inserted-into-the-transfer-buffer-in-the-same-order-in-which-they-were-originally-received-from-the-space-link. .Paragraph-5}

##### Extraction of Raf­Transfer­Data­Invocation records from the offline frame buffer and their insertion into the transfer buffer shall continue until: {#extraction-of-raftransferdatainvocation-records-from-the-offline-frame-buffer-and-their-insertion-into-the-transfer-buffer-shall-continue-until .Paragraph-5}

a)  the transfer buffer is full;

b)  a frame is retrieved with an ERT that is later than the stop time in
    the RAF-START invocation (in which case an 'end of data'
    notification shall be generated and inserted into the transfer
    buffer);

c)  the user invokes the RAF-STOP operation; or

d)  the association is aborted.

##### Whenever the transfer buffer is full or an 'end of data' notification is inserted into the transfer buffer, the RAF service provider shall build an RafTransferBuffer SLE-PDU from the contents of the transfer buffer and shall attempt to pass this SLE-PDU to the communications service until it is accepted. The RafTransferBuffer SLE-PDU shall contain the RafTransferDataInovcation records in the same order as they were originally received from the space link. {#whenever-the-transfer-buffer-is-full-or-an-end-of-data-notification-is-inserted-into-the-transfer-buffer-the-raf-service-provider-shall-build-an-raftransferbuffer-sle-pdu-from-the-contents-of-the-transfer-buffer-and-shall-attempt-to-pass-this-sle-pdu-to-the-communications-service-until-it-is-accepted.-the-raftransferbuffer-sle-pdu-shall-contain-the-raftransferdatainovcation-records-in-the-same-order-as-they-were-originally-received-from-the-space-link. .Paragraph-5}

##### Once the RafTransferBuffer SLE-PDU has been accepted by the communications service, the RAF service provider shall clear the transfer buffer. It shall also resume extracting frames from the offline frame buffer unless the 'end of data' notification was generated. {#once-the-raftransferbuffer-sle-pdu-has-been-accepted-by-the-communications-service-the-raf-service-provider-shall-clear-the-transfer-buffer.-it-shall-also-resume-extracting-frames-from-the-offline-frame-buffer-unless-the-end-of-data-notification-was-generated. .Paragraph-5}

##### In the offline delivery mode, the transfer buffer shall be cleared and extraction of frames from the online frame buffer shall stop whenever: {#in-the-offline-delivery-mode-the-transfer-buffer-shall-be-cleared-and-extraction-of-frames-from-the-online-frame-buffer-shall-stop-whenever .Paragraph-5}

a)  the user stops data flow by invoking the RAF-STOP operation; or

b)  the association is aborted.

##### In the case that the user invokes the RAF-STOP operation or the association becomes unbound, the user may, after re-binding if necessary, invoke a new RAF-START operation, specifying a new ERT interval for which frames shall be delivered from the offline frame buffer. The start and stop times of such an RAF-START invocation may be earlier, later, or the same as the start and stop times of any previous RAF-START invocation, provided that they are valid start and stop times as specified in 3.4. {#in-the-case-that-the-user-invokes-the-raf-stop-operation-or-the-association-becomes-unbound-the-user-may-after-re-binding-if-necessary-invoke-a-new-raf-start-operation-specifying-a-new-ert-interval-for-which-frames-shall-be-delivered-from-the-offline-frame-buffer.-the-start-and-stop-times-of-such-an-raf-start-invocation-may-be-earlier-later-or-the-same-as-the-start-and-stop-times-of-any-previous-raf-start-invocation-provided-that-they-are-valid-start-and-stop-times-as-specified-in-3.4. .Paragraph-5}

##### If the user, in the RAF-START invocation, requests a start time earlier than any frame still held in the offline frame buffer, the provider shall deliver frames beginning with the earliest data available. If there are no frames with an ERT in the interval specified by the start and stop times of the RAF-START invocation, then only the 'end of data' notification shall be delivered. {#if-the-user-in-the-raf-start-invocation-requests-a-start-time-earlier-than-any-frame-still-held-in-the-offline-frame-buffer-the-provider-shall-deliver-frames-beginning-with-the-earliest-data-available.-if-there-are-no-frames-with-an-ert-in-the-interval-specified-by-the-start-and-stop-times-of-the-raf-start-invocation-then-only-the-end-of-data-notification-shall-be-delivered. .Paragraph-5}

##### Except for 'end of data' notifications as described above, synchronous notifications shall not be provided in the offline delivery mode. {#except-for-end-of-data-notifications-as-described-above-synchronous-notifications-shall-not-be-provided-in-the-offline-delivery-mode. .Paragraph-5}

##### Only RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY invocations shall be buffered through the offline frame buffer. Except for the RAF-TRANSFER-DATA and RAF-SYNC-NOTIFY invocations, the invocations or returns of all other operations shall be asynchronous (in the sense that they are not required to be invoked or returned in sequence with respect to the delivery of the contents of the offline frame buffer). Therefore, they shall be invoked or returned as soon as possible without regard to the contents of the offline frame buffer or the transfer buffer. {#only-raf-transfer-data-and-raf-sync-notify-invocations-shall-be-buffered-through-the-offline-frame-buffer.-except-for-the-raf-transfer-data-and-raf-sync-notify-invocations-the-invocations-or-returns-of-all-other-operations-shall-be-asynchronous-in-the-sense-that-they-are-not-required-to-be-invoked-or-returned-in-sequence-with-respect-to-the-delivery-of-the-contents-of-the-offline-frame-buffer.-therefore-they-shall-be-invoked-or-returned-as-soon-as-possible-without-regard-to-the-contents-of-the-offline-frame-buffer-or-the-transfer-buffer. .Paragraph-5}

##### During offline service provision, the RAF service provider shall extract Raf­Transfer­Data­Invocation records from the offline frame buffer, insert them into the transfer buffer, and pass RafTransferBuffer SLE-PDUs to the communications service without undue delay, subject only to limitations imposed by the underlying communications service, or to any maximum data rate limitation ('metering') that may be imposed through service management. {#during-offline-service-provision-the-raf-service-provider-shall-extract-raftransferdatainvocation-records-from-the-offline-frame-buffer-insert-them-into-the-transfer-buffer-and-pass-raftransferbuffer-sle-pdus-to-the-communications-service-without-undue-delay-subject-only-to-limitations-imposed-by-the-underlying-communications-service-or-to-any-maximum-data-rate-limitation-metering-that-may-be-imposed-through-service-management. .Paragraph-5}

##### The size of the offline frame buffer and the transfer buffer shall be determined by arrangement between SLE Complex Management and SLE Utilization Management and shall be set by service management. {#the-size-of-the-offline-frame-buffer-and-the-transfer-buffer-shall-be-determined-by-arrangement-between-sle-complex-management-and-sle-utilization-management-and-shall-be-set-by-service-management. .Paragraph-5}

##### Every service provider shall document its policy regarding when, or under what circumstances, records in the offline frame buffer are deleted.  {#every-service-provider-shall-document-its-policy-regarding-when-or-under-what-circumstances-records-in-the-offline-frame-buffer-are-deleted. .Paragraph-5}

## RAF-BIND

### Purpose

#### The RAF-BIND operation shall be used to establish an association between the initiator and the responder. {#the-raf-bind-operation-shall-be-used-to-establish-an-association-between-the-initiator-and-the-responder. .Paragraph-4}

#### For every instance of RAF service, service management shall establish whether that instance of service is to be user-initiated or provider-initiated: {#for-every-instance-of-raf-service-service-management-shall-establish-whether-that-instance-of-service-is-to-be-user-initiated-or-provider-initiated .Paragraph-4}

a)  for a user-initiated service instance, only the service user is
    permitted to invoke the RAF-BIND operation;

b)  for a provider-initiated service instance, only the service provider
    is permitted to invoke the RAF-BIND operation.

#### The responder shall return a report of the outcome of the performance of the RAF-BIND operation to the initiator. {#the-responder-shall-return-a-report-of-the-outcome-of-the-performance-of-the-raf-bind-operation-to-the-initiator. .Paragraph-4}

#### Except as provided in 3.2.1.5, the invoker of RAF-BIND shall not invoke any further operations for this service instance until the return from the responder is received. {#except-as-provided-in-3.2.1.5-the-invoker-of-raf-bind-shall-not-invoke-any-further-operations-for-this-service-instance-until-the-return-from-the-responder-is-received. .Paragraph-4}

#### If the return from RAF-BIND is not received after a sufficiently long time, the initiator may attempt to recover by invoking the RAF-PEER-ABORT operation followed by another RAF-BIND. {#if-the-return-from-raf-bind-is-not-received-after-a-sufficiently-long-time-the-initiator-may-attempt-to-recover-by-invoking-the-raf-peer-abort-operation-followed-by-another-raf-bind. .Paragraph-4}

NOTE -- The length of the duration that constitutes 'a sufficiently long
time' is determined by service management.

#### The RAF-BIND operation is valid only in state 1 ('unbound'). {#the-raf-bind-operation-is-valid-only-in-state-1-unbound. .Paragraph-4}

### INVOCATION, RETURN, and parameters

#### General

The parameters of the RAF-BIND operation shall be present in the
invocation and return as specified in table 3-1.

#### invoker-credentials

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

Table 3-1: RAF-BIND Parameters

  ------------------------------------------ -------------- --------------
  Parameter                                  Invocation     Return

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

#### performer-credentials

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

#### initiator-identifier

The **initiator-identifier** parameter shall identify the authority on
whose behalf the initiating SLE application is initiating the
association.

NOTES

1.  The initiator-identifier parameter permits the responder to
    determine if the RAF-BIND operation is being invoked by the
    authorized initiator for this service instance.

2.  Each value of the initiator-identifier parameter is associated with
    exactly one authentication level and exactly one authentication
    scheme.

3.  If authentication based on credentials is used, this parameter may
    be redundant since the initiator-identifier value may be one
    constituent of the invoker-credentials parameter. However, the
    encoding may differ, and it may be convenient to have this parameter
    available in 'clear text' form.

#### 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 RAF-BIND return is from the authorized responder
    for this service instance.

2.  Each value of the responder-identifier parameter is associated with
    exactly one authentication level and exactly one authentication
    scheme.

3.  If authentication based on credentials is used, this parameter may
    be redundant since the responder-identifier value may be one
    constituent of the performer-credentials parameter. However, the
    encoding may differ, and it may be convenient to have this parameter
    available in 'clear text' form.

#### 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.5 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 RAF-BIND
    invocation to support its possible use by particular kinds of
    gateways.

#### service-type

##### The **service-type** parameter shall specify the type of service that will be provided if the bind operation succeeds. {#the-service-type-parameter-shall-specify-the-type-of-service-that-will-be-provided-if-the-bind-operation-succeeds. .Paragraph-5}

##### For RAF service, the value of service-type shall be 'Rtn All Frames'.[^1] {#for-raf-service-the-value-of-service-type-shall-be-rtn-all-frames. .Paragraph-5}

#### version-number

##### The **version-number** parameter shall identify the version number of the RAF service specification that is to govern this association if RAF-BIND succeeds. {#the-version-number-parameter-shall-identify-the-version-number-of-the-raf-service-specification-that-is-to-govern-this-association-if-raf-bind-succeeds. .Paragraph-5}

##### version-number is conditionally present in the return based on the result parameter: {#version-number-is-conditionally-present-in-the-return-based-on-the-result-parameter .Paragraph-5}

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 in the return.

##### If the value of the result parameter is 'positive result', the responder shall either: {#if-the-value-of-the-result-parameter-is-positive-result-the-responder-shall-either .Paragraph-5}

a)  accept the version proposed by the initiator by putting the same
    version number into the return; or,

b)  if the responder supports version negotiation, propose a lower
    (earlier) version number by putting the lower number into the
    return.

##### 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'. {#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. .Paragraph-5}

##### If the responder proposes a lower version and the initiator implementation does not support version negotiation, the initiator shall unbind the association. {#if-the-responder-proposes-a-lower-version-and-the-initiator-implementation-does-not-support-version-negotiation-the-initiator-shall-unbind-the-association. .Paragraph-5}

##### The value of the version-number parameter for the RAF service defined by this issue of this Recommendation shall be '1'. {#the-value-of-the-version-number-parameter-for-the-raf-service-defined-by-this-issue-of-this-recommendation-shall-be-1. .Paragraph-5}

NOTE -- The version negotiation process as outlined above is feasible
only as long as future versions of the RAF service do not modify the
specification of the RAF-BIND operation.

#### service-instance-identifier

The **service-instance-identifier** parameter shall uniquely identify
this service instance within the scope of the service-providing SLE
Complex.

NOTE -- It is recommended that the service-instance-identifier parameter
be specified as a distinguished name (see reference \[8\]). In that
case, the attributes of the distinguished name should include the SLE
service agreement and the SLE service package applicable to this service
instance. Reference \[E3\] specifies a suitable definition for the
service-instance-identifier parameter.

#### result

The **result** parameter shall specify the result of the RAF-BIND
operation and shall contain one of the following values:

a)  'positive result'---the RAF-BIND invocation is accepted by the
    responder, and the association is established;

b)  'negative result' ---the RAF-BIND invocation is rejected by the
    responder for the reason specified in the diagnostic parameter, and
    the association is not established.

#### diagnostic

##### If result is 'negative result', the diagnostic parameter shall be present in the return, and its value shall be one the following: {#if-result-is-negative-result-the-diagnostic-parameter-shall-be-present-in-the-return-and-its-value-shall-be-one-the-following .Paragraph-5}

a)  'access denied'---the value of the initiator-identifier parameter is
    not recognized by the responder (e.g., the value does not identify
    the authorized initiator of any service instance known to the
    responder);

b)  'service type not supported'---the value of the service-type
    parameter of the RAF-BIND invocation does not identify a service
    type supported by the responder;

c)  'version not supported'---the responder does not support the
    requested version, and the responder implementation does not permit
    version negotiation or 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 in 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 authorized
    initiator for the service instance identified by the
    service-instance-identifier parameter does not match the initiator
    identified by the initiator-identifier parameter of the RAF-BIND
    invocation;

g)  'inconsistent service type'---the value of the service-type
    parameter of the RAF-BIND invocation is not 'Return All Frames', or
    the value of the service-type parameter does not match the service
    type of the service instance identified by the
    service-instance-identifier parameter;

h)  'invalid time'---the RAF-BIND operation was invoked outside the
    service instance provision period of the service instance identified
    by the service-instance-identifier parameter;

i)  'out of service'---the responder has been taken out of service for
    an indefinite period by management action (i.e., RAF production
    status is 'halted', see 3.7.2.4);

j)  'other reason'---the reason for the negative result will have to be
    found by other means.

NOTES

1.  In some implementations, under some circumstances, it may not be
    possible for the intended performer to provide a return in the event
    of the conditions indicated by diagnostics d), h), or i).

2.  Implementations should consider that, under some conditions,
    RAF-BIND may fail with no return (e.g., if the value of the
    responder-port-identifier parameter is incorrect).

##### If result is 'positive result', the diagnostic parameter shall not be present in the return. {#if-result-is-positive-result-the-diagnostic-parameter-shall-not-be-present-in-the-return. .Paragraph-5}

### Effects

#### If result is 'positive result', the RAF-BIND operation shall have the following effects: {#if-result-is-positive-result-the-raf-bind-operation-shall-have-the-following-effects .Paragraph-4}

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)  all service parameters shall be set to the initial values determined
    by service management;

d)  upon receipt of the positive return, the user may proceed to invoke
    other RAF service operations (e.g., to configure the service and
    begin data transfer).

#### If result is 'negative result', the RAF-BIND operation shall have the following effects: {#if-result-is-negative-result-the-raf-bind-operation-shall-have-the-following-effects .Paragraph-4}

a)  an 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:

```{=html}
<!-- -->
```
1)  the initiator should examine the diagnostic parameter for the cause;

2)  the initiator may attempt to re-invoke the RAF-BIND.

## RAF-UNBIND

### Purpose

#### The initiator shall invoke the RAF-UNBIND operation to release an association previously established by RAF-BIND. {#the-initiator-shall-invoke-the-raf-unbind-operation-to-release-an-association-previously-established-by-raf-bind. .Paragraph-4}

#### The responder shall return a report of the outcome of the performance of the RAF-UNBIND operation to the initiator. {#the-responder-shall-return-a-report-of-the-outcome-of-the-performance-of-the-raf-unbind-operation-to-the-initiator. .Paragraph-4}

#### Except as provided in 3.3.1.4, the initiator shall not invoke any further operations for this service instance until the return from RAF-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. {#except-as-provided-in-3.3.1.4-the-initiator-shall-not-invoke-any-further-operations-for-this-service-instance-until-the-return-from-raf-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. .Paragraph-4}

NOTE -- The initiator may invoke the RAF-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 RAF-UNBIND invocation. It
may then happen that the RAF-UNBIND return is not received before one of
the missing returns causes a 'missing return' timeout (see section 4).

#### If the return from RAF-UNBIND is not received after a sufficiently long time, the initiator should invoke the RAF-PEER-ABORT operation to abort the association. {#if-the-return-from-raf-unbind-is-not-received-after-a-sufficiently-long-time-the-initiator-should-invoke-the-raf-peer-abort-operation-to-abort-the-association. .Paragraph-4}

NOTES

1.  The length of the duration that constitutes 'a sufficiently long
    time' is determined by service management.

2.  Following receipt of the return from RAF-UNBIND or following the
    invocation of RAF-PEER-ABORT, the initiator may issue another
    RAF-BIND if otherwise permitted (e.g., if the end of the service
    instance provision period has not been reached).

#### The RAF-UNBIND operation is valid only in state 2 ('ready'). {#the-raf-unbind-operation-is-valid-only-in-state-2-ready. .Paragraph-4}

#### The RAF-UNBIND operation shall be invoked only by the initiator (i.e., the invoker of the RAF-BIND operation that established this association). {#the-raf-unbind-operation-shall-be-invoked-only-by-the-initiator-i.e.-the-invoker-of-the-raf-bind-operation-that-established-this-association. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-UNBIND operation shall be present in the
invocation and return as specified in table 3-2.

Table 3-2: RAF-UNBIND Parameters

+------------------------------------------+-------------+-------------+
| Parameter                                | Invocation  | Return      |
+------------------------------------------+-------------+-------------+
| > invoker-credentials                    | M           |             |
+------------------------------------------+-------------+-------------+
| > performer-credentials                  |             | M           |
+------------------------------------------+-------------+-------------+
| > unbind-reason                          | M           |             |
+------------------------------------------+-------------+-------------+
| > result                                 |             | M           |
+------------------------------------------+-------------+-------------+

#### invoker-credentials

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

#### performer-credentials

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

#### unbind-reason

##### The **unbind-reason** parameter shall indicate the reason the RAF-UNBIND operation is being invoked. {#the-unbind-reason-parameter-shall-indicate-the-reason-the-raf-unbind-operation-is-being-invoked. .Paragraph-5}

##### If the RAF-UNBIND operation is invoked by the user, the unbind-reason parameter shall take one of the following values: {#if-the-raf-unbind-operation-is-invoked-by-the-user-the-unbind-reason-parameter-shall-take-one-of-the-following-values .Paragraph-5}

a)  'end'---the user has obtained all frames that are needed or expected
    and is releasing the association normally; the provider may delete
    the service instance and release all resources associated with it;

NOTE -- If unbind-reason is 'end', any subsequent attempt to invoke
RAF-BIND will fail 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 user is suspending usage of this service instance
    for an unspecified period of time; the user may or may not re-bind
    to the provider to continue data transfer at some time prior to the
    end of the service instance provision period;

c)  'version not supported'---the user does not support the version of
    the RAF service proposed by the provider in the return from
    RAF-BIND; this value of unbind-reason shall be used only if the
    RAF-UNBIND is the first operation invoked following the RAF-BIND;

d)  'other'---the reason for the release will have to be found by other
    means.

##### If the RAF-UNBIND operation is invoked by the provider, the unbind-reason parameter shall take one of the following values: {#if-the-raf-unbind-operation-is-invoked-by-the-provider-the-unbind-reason-parameter-shall-take-one-of-the-following-values .Paragraph-5}

a)  'end'---the provider has transferred all available frames to the
    user and is releasing the association normally; the provider shall
    not attempt to re-bind to the user in the context of this service
    instance;

b)  'suspend'---the provider is suspending service provision for an
    unspecified period of time; the provider may attempt to re-bind to
    the user to continue data transfer at some time prior to the end of
    the service instance provision period;

c)  'version not supported'---the provider does not support the version
    of the RAF service proposed by the user in the return from RAF-BIND;
    this value of unbind-reason shall be used only if the RAF-UNBIND is
    the first operation invoked following the RAF-BIND;

d)  'other'---the reason for the release will have to be found by other
    means.

#### result

The **result** parameter shall specify the result of the RAF-UNBIND
operation and shall always contain the following value:

'positive result'---the RAF-UNBIND operation has been performed by the
responder, and the association is released.

NOTES

1.  If RAF-UNBIND is invoked while the provider is not in the 'ready'
    state, the responder invokes RAF-PEER-ABORT; if the authentication
    level is 'all' and the invocation of RAF-UNBIND cannot be
    authenticated, the responder ignores it; but there is no situation
    in which the response to the invocation of RAF-UNBIND is to return
    'negative result'.

2.  The result parameter is returned for the RAF-UNBIND operation, even
    though the only permitted value is 'positive result', for
    consistency with other confirmed operations.

3.  RAF-UNBIND is a confirmed operation in order to provide a definite
    indication to the initiator that the responder has performed the
    operation and the association is released.

### Effects

The RAF-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');

c)  if unbind-reason is 'end', the provider may delete the service
    instance and release its resources;

d)  if unbind-reason is not 'end', the initiator may attempt to re-bind
    at any time prior to the end of the service instance provision
    period.

NOTE -- The performance of RAF-UNBIND for a particular service instance
does not necessarily terminate the associated RAF production process
(e.g., if unbind-reason is not 'end' and the delivery mode is complete
online or if another service instance is dependent on the production).

## RAF-START

### Purpose

#### The user shall invoke the RAF-START operation to request that the provider begin the delivery of telemetry frames. {#the-user-shall-invoke-the-raf-start-operation-to-request-that-the-provider-begin-the-delivery-of-telemetry-frames. .Paragraph-4}

#### The provider shall return a report of the outcome of the performance of the RAF-START operation to the user. {#the-provider-shall-return-a-report-of-the-outcome-of-the-performance-of-the-raf-start-operation-to-the-user. .Paragraph-4}

#### Following a successful RAF-START, the provider shall deliver telemetry frames acquired from the space link to the user as quickly as those frames are available. {#following-a-successful-raf-start-the-provider-shall-deliver-telemetry-frames-acquired-from-the-space-link-to-the-user-as-quickly-as-those-frames-are-available. .Paragraph-4}

NOTES

1.  Frames are delivered to the user by means of the RAF-TRANSFER-DATA
    operation (see 3.6).

2.  Communications service delays may affect the rate at which available
    frames are delivered.

#### All frames delivered following the RAF-START but prior to the next RAF-STOP (see 3.5) shall be delivered in the order in which they were received from the space link. {#all-frames-delivered-following-the-raf-start-but-prior-to-the-next-raf-stop-see-3.5-shall-be-delivered-in-the-order-in-which-they-were-received-from-the-space-link. .Paragraph-4}

#### The user may specify, as parameters of the RAF-START invocation, the ERTs of the first and last telemetry frames that are to be delivered by the provider. {#the-user-may-specify-as-parameters-of-the-raf-start-invocation-the-erts-of-the-first-and-last-telemetry-frames-that-are-to-be-delivered-by-the-provider. .Paragraph-4}

#### The time parameters may be changed during an association by invoking an RAF-STOP followed by an RAF-START with new time parameters. {#the-time-parameters-may-be-changed-during-an-association-by-invoking-an-raf-stop-followed-by-an-raf-start-with-new-time-parameters. .Paragraph-4}

NOTE -- This capability is intended primarily to support the offline
delivery mode.

#### RAF-START is valid only in state 2 ('ready') and shall be invoked only by the user. {#raf-start-is-valid-only-in-state-2-ready-and-shall-be-invoked-only-by-the-user. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-START operation shall be present in the
invocation and return as specified in table 3-3.

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the performer to authenticate the RAF-START invocation (see
3.1.5).

Table 3-3: RAF-START Parameters

+------------------------------------------+-------------+-------------+
| Parameter                                | Invocation  | Return      |
+------------------------------------------+-------------+-------------+
| > invoker-credentials                    | M           |             |
+------------------------------------------+-------------+-------------+
| > performer-credentials                  |             | M           |
+------------------------------------------+-------------+-------------+
| > invoke-ID                              | M           | M           |
+------------------------------------------+-------------+-------------+
| > start-time                             | M           |             |
+------------------------------------------+-------------+-------------+
| > stop-time                              | M           |             |
+------------------------------------------+-------------+-------------+
| > requested-frame-quality                | M           |             |
+------------------------------------------+-------------+-------------+
| > result                                 |             | M           |
+------------------------------------------+-------------+-------------+
| > diagnostic                             |             | C           |
+------------------------------------------+-------------+-------------+

#### performer-credentials

The **performer-credentials** parameter shall provide information that
enables the invoker to authenticate the return from the performance of
RAF-START (see 3.1.5).

#### invoke-ID

The RAF service provider shall return unchanged the user-supplied value
of the invoke-ID parameter (see 3.1.6).

#### start-time

##### The value of the **start-time** parameter shall be 'null', or it shall be a time value that indicates that only frames with an ERT equal to or later than start-time shall be delivered. {#the-value-of-the-start-time-parameter-shall-be-null-or-it-shall-be-a-time-value-that-indicates-that-only-frames-with-an-ert-equal-to-or-later-than-start-time-shall-be-delivered. .Paragraph-5}

##### For the online delivery mode, only frames acquired during the space link session associated with this service instance shall be delivered, regardless of the value of start-time. {#for-the-online-delivery-mode-only-frames-acquired-during-the-space-link-session-associated-with-this-service-instance-shall-be-delivered-regardless-of-the-value-of-start-time. .Paragraph-5}

##### For the offline delivery mode, the provider shall deliver all available frames that meet the delivery criteria regardless of the space link session in which they were acquired. {#for-the-offline-delivery-mode-the-provider-shall-deliver-all-available-frames-that-meet-the-delivery-criteria-regardless-of-the-space-link-session-in-which-they-were-acquired. .Paragraph-5}

##### For the online delivery mode, if start-time is 'null', the data transfer shall begin with the next frame that is acquired from the space link. {#for-the-online-delivery-mode-if-start-time-is-null-the-data-transfer-shall-begin-with-the-next-frame-that-is-acquired-from-the-space-link. .Paragraph-5}

##### For the offline delivery mode, start-time must not be 'null'. {#for-the-offline-delivery-mode-start-time-must-not-be-null. .Paragraph-5}

##### To be valid, start-time must satisfy the following criteria: {#to-be-valid-start-time-must-satisfy-the-following-criteria .Paragraph-5}

a)  for the online delivery mode, start-time must be equal to or later
    than the start time of the service instance provision period for
    this service instance;

b)  for the online delivery mode, start-time must be earlier than the
    end time of the service instance provision period for this service
    instance;

c)  start-time must be earlier than stop-time (see 3.4.2.6).

NOTE -- The provider is able to deliver only frames that have been
acquired from the space link. For example, in an online service
instance, if start-time is earlier than the start time of the space link
session, the first frame that is delivered will be the first frame
acquired after the start of the space link session.

#### stop-time

##### The value of the **stop-time** parameter shall be 'null', or it shall be a time value that indicates that delivery of frames should cease when the next frame that would be delivered has an ERT later than stop-time. {#the-value-of-the-stop-time-parameter-shall-be-null-or-it-shall-be-a-time-value-that-indicates-that-delivery-of-frames-should-cease-when-the-next-frame-that-would-be-delivered-has-an-ert-later-than-stop-time. .Paragraph-5}

##### For the online delivery mode, only frames acquired during the space link session associated with this service instance shall be delivered, regardless of stop-time. {#for-the-online-delivery-mode-only-frames-acquired-during-the-space-link-session-associated-with-this-service-instance-shall-be-delivered-regardless-of-stop-time. .Paragraph-5}

##### For the offline delivery mode, the provider shall deliver all available frames that meet the delivery criteria regardless of the space link session in which they were acquired. {#for-the-offline-delivery-mode-the-provider-shall-deliver-all-available-frames-that-meet-the-delivery-criteria-regardless-of-the-space-link-session-in-which-they-were-acquired.-1 .Paragraph-5}

##### For the online delivery mode, if stop-time is 'null', the provider shall continue to transfer all frames that are acquired from the space link and satisfy the delivery criteria until either the user invokes an RAF-STOP operation or the association is released or aborted. {#for-the-online-delivery-mode-if-stop-time-is-null-the-provider-shall-continue-to-transfer-all-frames-that-are-acquired-from-the-space-link-and-satisfy-the-delivery-criteria-until-either-the-user-invokes-an-raf-stop-operation-or-the-association-is-released-or-aborted. .Paragraph-5}

##### For the offline delivery mode, stop-time must not be 'null'. {#for-the-offline-delivery-mode-stop-time-must-not-be-null. .Paragraph-5}

##### To be valid, stop-time must satisfy the following criteria: {#to-be-valid-stop-time-must-satisfy-the-following-criteria .Paragraph-5}

a)  stop-time must be later than the start-time (see 3.4.2.5);

b)  for the online delivery mode, stop-time, if not 'null', must be
    earlier than or equal to the end time of the service instance
    provision period for this service instance;

c)  for the offline delivery mode, stop-time plus the offline processing
    latency must be earlier than the current time.

NOTES

1.  Offline processing latency is the length of time after a frame is
    acquired from the space link before it is available for retrieval
    using the offline delivery mode. The actual value of offline
    processing latency is negotiated between SLE Complex Management and
    SLE Utilization Management.

2.  Offline delivery is only available for frames which already have
    been acquired when the RAF-START operation is invoked.

#### requested-frame-quality

The **requested-frame-quality** parameter specifies a criteria based on
frame quality for determining whether a given frame is to be delivered
to the user. Its value shall be one of the following:

a)  'good frames only'---only frames for which delivered-frame-quality
    (see 3.6) is 'good' shall be delivered to the user;

b)  'erred frames only'---only frames for which delivered-frame-quality
    is 'erred' shall be delivered to the user;

c)  'all frames'---all frames, regardless of delivered-frame-quality,
    shall be delivered to the user.

#### result

The **result** parameter shall specify the result of the RAF-START
operation and shall contain one of the following values:

a)  'positive result'---the RAF-START operation has been performed by
    the provider, and the provider shall henceforth invoke
    RAF-TRANSFER-DATA operations as needed to transfer to the user all
    available frames that meet the specified delivery criteria;

b)  'negative result'---the RAF-START operation has not been performed
    by the provider, and the provider shall not invoke any
    RAF-TRANSFER-DATA operations even if frames are available.

#### diagnostic

##### If result is 'negative result', the diagnostic parameter shall be present in the return, and its value shall be one of the following: {#if-result-is-negative-result-the-diagnostic-parameter-shall-be-present-in-the-return-and-its-value-shall-be-one-of-the-following .Paragraph-5}

a)  'duplicate Invoke-ID'---the value of the invoke-ID parameter is the
    same as the invoke-ID of a previous, outstanding operation;

b)  'out of service'---the provider has been taken out of service for an
    indefinite period by management action;

c)  'unable to comply'---the provider is unable to transfer data at this
    time because of a fault affecting the provider;

d)  'missing time value'---for the offline delivery mode, the value of
    start-time and/or stop-time was 'null';

e)  'invalid start time'---the value of the start-time provided in the
    invocation is not valid;

f)  'invalid stop time'---the value of the stop-time provided in the
    invocation is not valid;

g)  'other reason'---the reason for the negative result will have to be
    found by other means.

##### If result is 'positive result', the diagnostic parameter shall not be present in the return. {#if-result-is-positive-result-the-diagnostic-parameter-shall-not-be-present-in-the-return.-1 .Paragraph-5}

### Effects

#### If result is 'positive result', the RAF-START operation shall have the following effects: {#if-result-is-positive-result-the-raf-start-operation-shall-have-the-following-effects .Paragraph-4}

a)  the provider shall transition to state 3 ('active');

b)  in the 'active' state, the provider shall transfer frames to the
    user whenever they are available and satisfy the delivery criteria.

#### If result is 'negative result', the RAF-START operation shall have the following effects: {#if-result-is-negative-result-the-raf-start-operation-shall-have-the-following-effects .Paragraph-4}

a)  the provider shall remain in state 2 ('ready') and shall not deliver
    frames even if they are available;

b)  if the diagnostic is 'unable to comply':

```{=html}
<!-- -->
```
1)  the user may re-invoke the RAF-START operation at a later time
    within the constraints of the service instance provision period;

2)  if the provider's SLE Complex Management determines that being
    'unable to comply' is more than a transient problem, the provider
    may invoke the RAF-PEER-ABORT operation.

## RAF-STOP

### Purpose

#### The user shall invoke the RAF-STOP operation to request that the provider stop delivering telemetry frames. {#the-user-shall-invoke-the-raf-stop-operation-to-request-that-the-provider-stop-delivering-telemetry-frames. .Paragraph-4}

NOTE -- Within the constrains of the service provision period, the user
may re-enable frame delivery by invoking the RAF-START operation.

#### The provider shall provide a report of the outcome of the performance of the RAF-STOP operation to the user. {#the-provider-shall-provide-a-report-of-the-outcome-of-the-performance-of-the-raf-stop-operation-to-the-user. .Paragraph-4}

#### RAF-STOP is valid only in state 3 ('active') and shall be invoked only by the user. {#raf-stop-is-valid-only-in-state-3-active-and-shall-be-invoked-only-by-the-user. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-STOP operation shall be present in the
invocation and return as specified in table 3-4.

Table 3-4: RAF-STOP Parameters

+------------------------------------------+-------------+-------------+
| Parameters                               | Invocation  | Return      |
+------------------------------------------+-------------+-------------+
| > invoker-credentials                    | M           |             |
+------------------------------------------+-------------+-------------+
| > performer-credentials                  |             | M           |
+------------------------------------------+-------------+-------------+
| > invoke-ID                              | M           | M           |
+------------------------------------------+-------------+-------------+
| > result                                 |             | M           |
+------------------------------------------+-------------+-------------+
| > diagnostic                             |             | C           |
+------------------------------------------+-------------+-------------+

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the performer to authenticate the RAF-STOP invocation (see
3.1.5).

#### performer-credentials

The **performer-credentials** parameter shall provide information that
enables the invoker to authenticate the return from the performance of
RAF-STOP (see 3.1.5).

#### invoke-ID

The RAF service provider shall return unchanged the user-supplied value
of the invoke-ID parameter (see 3.1.6).

#### result

The **result** parameter shall specify the result of the RAF-STOP
operation and shall contain one of the following values:

a)  'positive result'---the RAF-STOP operation has been performed by the
    provider, and the delivery of telemetry frames to the user has
    ceased;

b)  'negative result'---the RAF-STOP operation has not been performed by
    the provider for the reason specified by the diagnostic parameter,
    and the delivery of telemetry frames to the user continues.

#### diagnostic

##### If result is 'negative result', the diagnostic parameter shall be present in the return, and its value shall be one of the following: {#if-result-is-negative-result-the-diagnostic-parameter-shall-be-present-in-the-return-and-its-value-shall-be-one-of-the-following-1 .Paragraph-5}

a)  'duplicate Invoke-ID'---the value of the invoke-ID parameter is the
    same as the invoke-ID of a previous, outstanding operation;

b)  'other reason'---the reason for the negative result will have to be
    found by other means.

##### If result is 'positive result', the diagnostic parameter shall not be present in the return. {#if-result-is-positive-result-the-diagnostic-parameter-shall-not-be-present-in-the-return.-2 .Paragraph-5}

### Effects

#### If result is 'positive result', the RAF-STOP operation shall have the following effects: {#if-result-is-positive-result-the-raf-stop-operation-shall-have-the-following-effects .Paragraph-4}

a)  the provider shall cease invoking RAF-TRANSFER-DATA operations;

b)  the provider shall discard the contents of transfer buffer;

c)  the provider shall transition to state 2 ('ready').

#### If result is 'negative result', the provider shall remain in state 3 ('active') and shall continue processing unchanged.  {#if-result-is-negative-result-the-provider-shall-remain-in-state-3-active-and-shall-continue-processing-unchanged. .Paragraph-4}

## RAF-TRANSFER-DATA

### Purpose

#### The provider shall invoke the RAF-TRANSFER-DATA operation to deliver a telemetry frame to the user. {#the-provider-shall-invoke-the-raf-transfer-data-operation-to-deliver-a-telemetry-frame-to-the-user. .Paragraph-4}

#### The RAF-TRANSFER-DATA operation shall be an unconfirmed operation. {#the-raf-transfer-data-operation-shall-be-an-unconfirmed-operation. .Paragraph-4}

NOTE -- Although RAF-TRANSFER-DATA is an unconfirmed operation, it is
assumed that the communications service provides certain guarantees, as
described in 1.3.1.

#### RAF-TRANSFER-DATA is valid only in state 3 ('active') and shall be invoked only by the provider. {#raf-transfer-data-is-valid-only-in-state-3-active-and-shall-be-invoked-only-by-the-provider. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-TRANSFER-DATA operation shall be present in
the invocation as specified in table 3-5.

Table 3-5: RAF-TRANSFER-DATA Parameters

+------------------------------------------------+---------------------+
| Parameters                                     | Invocation          |
+------------------------------------------------+---------------------+
| > invoker-credentials                          | M                   |
+------------------------------------------------+---------------------+
| > earth-receive-time                           | M                   |
+------------------------------------------------+---------------------+
| > antenna-ID                                   | M                   |
+------------------------------------------------+---------------------+
| > data-link-continuity                         | M                   |
+------------------------------------------------+---------------------+
| > delivered-frame-quality                      | M                   |
+------------------------------------------------+---------------------+
| > private-annotation                           | M                   |
+------------------------------------------------+---------------------+
| > data                                         | M                   |
+------------------------------------------------+---------------------+

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the user to authenticate the RAF-TRANSFER-DATA invocation (see
3.1.5).

#### earth-receive-time

The **earth-receive-time** parameter shall contain the UTC time at which
the signal event corresponding to the leading edge of the first bit of
the telemetry frame was presented at the phase center of the antenna
used to acquire the frame.

NOTE -- The first bit of the frame is the first bit following the
attached sync marker.

#### antenna-ID

##### The **antenna-ID** parameter shall indicate which antenna of the SLE Complex was used to acquire this frame of data. {#the-antenna-id-parameter-shall-indicate-which-antenna-of-the-sle-complex-was-used-to-acquire-this-frame-of-data. .Paragraph-5}

NOTE -- antenna-ID is provided specifically to identify the physical
location used as the reference point for the earth-receive-time
parameter.

##### SLE Complex Management and SLE Utilization Management shall mutually agree upon the allowable values for antenna-ID and their interpretation. {#sle-complex-management-and-sle-utilization-management-shall-mutually-agree-upon-the-allowable-values-for-antenna-id-and-their-interpretation. .Paragraph-5}

NOTE -- It is assumed that the value of the antenna-ID parameter is a
reference to the actual location information, which is provided outside
the scope of this service.

#### data-link-continuity

##### The **data-link-continuity** parameter shall indicate whether this frame was the direct successor on the space link of the previous frame acquired by the instance of RAF production associated with this service instance. {#the-data-link-continuity-parameter-shall-indicate-whether-this-frame-was-the-direct-successor-on-the-space-link-of-the-previous-frame-acquired-by-the-instance-of-raf-production-associated-with-this-service-instance. .Paragraph-5}

NOTE -- Even though this frame may have been the direct successor of the
previous frame acquired from the space link, it may not be the direct
successor of the previous frame delivered to the user of this service
instance (e.g., because of the setting of requested-frame-quality, see
3.4.2.7).

##### The **data-link-continuity** parameter shall contain an integer value: {#the-data-link-continuity-parameter-shall-contain-an-integer-value .Paragraph-5}

a)  a value of '--1' shall indicate that this is the first frame after
    the start of production;

b)  a value of '0' shall indicate that this frame is the direct
    successor to the last frame acquired from the space link by RAF
    production;

c)  any non-zero positive value shall indicate that this frame is not
    the direct successor to the last frame acquired from the space link:

```{=html}
<!-- -->
```
1)  a non-zero positive value further indicates an estimate of the
    number of frames that were missed since the last frame acquired
    before this frame;

2)  a value of '1' may be used if no better estimate is available.

#### delivered-frame-quality

##### The **delivered-frame-quality** parameter shall indicate the result of Reed-Solomon decoding or error control field decoding and shall contain one of the following values: {#the-delivered-frame-quality-parameter-shall-indicate-the-result-of-reed-solomon-decoding-or-error-control-field-decoding-and-shall-contain-one-of-the-following-values .Paragraph-5}

a)  'good'---for Reed-Solomon encoded frames, the frame, after decoding,
    consists entirely of codewords of the Reed-Solomon code; or, for
    frames that are not Reed-Solomon encoded, decoding of the error
    control field indicates that the frame does not contain any errors;

b)  'erred'---for Reed-Solomon encoded frames, the frame, after
    decoding, contains at least one codeword that is not a codeword of
    the Reed-Solomon code; or, for frames that are not Reed-Solomon
    encoded, decoding of the error control field indicates that the
    frame contains at least one error.

##### If a Reed-Solomon encoded frame is successfully decoded, it is assumed to be error free, and the error control field of such a frame may be ignored. {#if-a-reed-solomon-encoded-frame-is-successfully-decoded-it-is-assumed-to-be-error-free-and-the-error-control-field-of-such-a-frame-may-be-ignored. .Paragraph-5}

NOTES

1.  Reed-Solomon coding is specified in reference \[2\]. Decoding of the
    error control field is specified in references \[3\] and \[4\].

2.  As indicated in 1.3.2.2, provision of RAF service requires that, at
    any given time, the coding options must be the same for all frames
    on a physical channel, which is more restrictive than what is
    specified in references \[2\], \[3\], and \[4\].

3.  Whether Reed-Solomon coding is in use or not is managed information;
    i.e., it is not signaled in the data itself but must be known a
    priori. It is assumed that this information is conveyed through
    service management.

#### private-annotation

The **private-annotation** parameter shall be used to convey additional
information that may be associated with a frame:

a)  it may be set to 'null' to indicate that there is no private
    annotation;

b)  if not 'null', there must be a prior arrangement between SLE Complex
    Management and SLE Utilization Management regarding the contents and
    interpretation of this parameter.

#### data

The value of the **data** parameter shall be the telemetry frame
acquired by the provider from the space link for delivery to the user.

a)  if delivered-frame-quality is 'good', data is a transfer frame or a
    VCDU;

b)  if delivered-frame-quality is 'erred', data is a data unit of the
    same length as a frame that, during frame synchronization, was
    identified as a frame but, on decoding, was found to contain errors.

NOTES

1.  The value of the data parameter does not include the attached sync
    marker.

2.  For Reed-Solomon encoded frames, if a codeblock or CVCDU is
    successfully Reed-Solomon decoded and the user has requested the
    delivery of 'all frames' or 'good frames only' (see 3.4.2.7), the
    Reed-Solomon check symbols are discarded, and the resulting transfer
    frame or VCDU is delivered with delivered-frame-quality set to
    'good'. If a candidate codeblock or CVCDU cannot be Reed-Solomon
    decoded and the user has requested the delivery of 'all frames' or
    'erred frames only', the entire candidate codeblock or CVCDU is
    delivered with delivered-frame-quality set to 'erred'.

### Effects

The RAF-TRANSFER-DATA operation shall have the following effects:

a)  a telemetry frame acquired by the provider from the space link shall
    be delivered to the user;

b)  the provider shall remain in state 3 ('active').

## RAF-SYNC-NOTIFY

### Purpose

#### The RAF service provider shall invoke the RAF-SYNC-NOTIFY operation to notify the user of the occurrence of an event affecting the production of the RAF service. {#the-raf-service-provider-shall-invoke-the-raf-sync-notify-operation-to-notify-the-user-of-the-occurrence-of-an-event-affecting-the-production-of-the-raf-service. .Paragraph-4}

NOTE -- Notification of events may be of value to the user in
understanding specific provider behavior, such as an interruption in
frame delivery.

#### The RAF-SYNC-NOTIFY operation shall be an unconfirmed operation. {#the-raf-sync-notify-operation-shall-be-an-unconfirmed-operation. .Paragraph-4}

#### The order in which the RAF-SYNC-NOTIFY and RAF-TRANSFER-DATA operations are invoked shall reflect the actual chronology of events. {#the-order-in-which-the-raf-sync-notify-and-raf-transfer-data-operations-are-invoked-shall-reflect-the-actual-chronology-of-events. .Paragraph-4}

NOTE -- For example, if an RAF-SYNC-NOTIFY operation is invoked after
one RAF-TRANSFER-DATA operation but before another, then the event
indicated by the notification occurred after the ERT of the frame
associated with the preceding RAF-TRANSFER-DATA but before the ERT of
the frame associated with the following RAF-TRANSFER-DATA.

#### RAF-SYNC-NOTIFY is valid only in state 3 ('active') and shall be invoked only by the provider. {#raf-sync-notify-is-valid-only-in-state-3-active-and-shall-be-invoked-only-by-the-provider. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-SYNC-NOTIFY operation shall be present in the
invocation as specified in table 3-6.

Table 3-6: RAF-SYNC-NOTIFY Parameters

+-----------------------------------------------------+-----------------+
| Parameter                                           | Invocation      |
+-----------------------------------------------------+-----------------+
| > invoker-credentials                               | M               |
+-----------------------------------------------------+-----------------+
| > notification-type                                 | M               |
+-----------------------------------------------------+-----------------+
| > notification-value                                | C               |
+-----------------------------------------------------+-----------------+

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the user to authenticate the RAF-SYNC-NOTIFY invocation (see
3.1.5).

#### notification-type

The **notification-type** parameter shall indicate the event that the
user is being notified of, and its value shall be one of the following:

a)  'loss of frame synchronization'---the delivery of frames has been
    interrupted because the frame synchronization process is not able to
    synchronize to the stream of frames from the space link:

```{=html}
<!-- -->
```
1)  the notification shall be invoked at most once for each occurrence
    of a frame synchronizer transition from 'in-lock' to 'out-of-lock';

2)  the provider shall minimize the latency from the time the loss of
    frame synchronization event occurs until the notification is
    invoked;

3)  there shall be no explicit notification when the frame synchronizer
    transitions from 'out-of-lock' to 'in-lock'; rather, the next
    invocation of RAF-TRANSFER-DATA shall implicitly indicate the
    occurrence of that event;

4)  loss of frame synchronization notifications shall not be invoked in
    the offline delivery mode;

```{=html}
<!-- -->
```
b)  'production status change'---the status of RAF production has
    changed:

```{=html}
<!-- -->
```
1)  the notification shall be invoked when the RAF production status
    changes;

2)  the production status shall be 'running', 'halted', or 'interrupted'
    (see 3.7.2.4);

3)  production status change notifications shall not be invoked in the
    offline delivery mode;

```{=html}
<!-- -->
```
c)  'data discarded due to excessive backlog'---some data was discarded
    by the RAF service provider, either because of timeliness
    considerations (timely online mode) or because of online frame
    buffer overflow (complete online mode):

```{=html}
<!-- -->
```
1)  if data are discarded two or more times in a row without a
    successful intervening delivery of frames to the user, no more than
    one data discarded notification shall be delivered to the user;

2)  data discarded notifications shall not be invoked in the offline
    delivery mode;

```{=html}
<!-- -->
```
d)  'end of data'---the provider has no more data to send.

NOTE -- The 'end of data' notification is invoked in all delivery modes.
For example, for an online service instance, the space link session has
ended, and there are no more frames to be delivered; or, for an offline
service instance, all available frames between the specified start and
end times (see 3.4) have been delivered).

#### notification-value

##### The presence of the **notification-value** parameter in the return from RAF-SYNC-NOTIFY shall be conditional on the value of notification-type. {#the-presence-of-the-notification-value-parameter-in-the-return-from-raf-sync-notify-shall-be-conditional-on-the-value-of-notification-type. .Paragraph-5}

##### If notification-type is 'loss of frame synchronization', then notification-value shall be present and shall convey the following information: {#if-notification-type-is-loss-of-frame-synchronization-then-notification-value-shall-be-present-and-shall-convey-the-following-information .Paragraph-5}

a)  the UTC time when the frame synchronizer transitioned from 'in-lock'
    to 'out-of-lock';

b)  the current status of the carrier demodulation process, which shall
    be 'in-lock', 'out-of-lock', 'not in use', or 'unknown';

c)  the current status of the subcarrier demodulation process, which
    shall be 'in-lock', 'out-of-lock', 'not in use', or 'unknown';

d)  the current status of the symbol synchronization process, which
    shall be 'in-lock', 'out-of-lock', 'not in use', or 'unknown'.

NOTE -- The determinations of the lock statuses of carrier demodulation,
subcarrier demodulation, and symbol synchronization typically are based
on measurements that are integrated over some time period. To that
extent, the values reported here may reflect the statuses of the
corresponding processes at a time slightly earlier than the time when
the notification is invoked.

##### If notification-type is 'production status change', then the notification-value parameter shall be present, and its value shall indicate the current production status, which shall be one of the following: {#if-notification-type-is-production-status-change-then-the-notification-value-parameter-shall-be-present-and-its-value-shall-indicate-the-current-production-status-which-shall-be-one-of-the-following .Paragraph-5}

a)  'running'---the RAF production process is capable of processing a
    return space link physical channel, if available;

b)  'halted'---the RAF production process is stopped and production
    equipment is out of service because of management action;

c)  'interrupted'---the RAF production process is stopped because of a
    fault.

##### If notification-type is 'data discarded due to excessive backlog' or 'end of data', the notification-value parameter shall not be present. {#if-notification-type-is-data-discarded-due-to-excessive-backlog-or-end-of-data-the-notification-value-parameter-shall-not-be-present. .Paragraph-5}

### Effects

The RAF-SYNC-NOTIFY operation shall have the following effects:

a)  information about the occurrence of the specified event shall be
    delivered to the user;

b)  the state of the provider shall not change.

## RAF-SCHEDULE-STATUS-REPORT

### Purpose

#### The user shall invoke the RAF-SCHEDULE-STATUS-REPORT operation to request that the provider send a status report either immediately or periodically or to stop the sending of such reports. {#the-user-shall-invoke-the-raf-schedule-status-report-operation-to-request-that-the-provider-send-a-status-report-either-immediately-or-periodically-or-to-stop-the-sending-of-such-reports. .Paragraph-4}

#### The provider shall return a report of the outcome of the performance of the RAF-SCHEDULE-STATUS-REPORT operation to the user. {#the-provider-shall-return-a-report-of-the-outcome-of-the-performance-of-the-raf-schedule-status-report-operation-to-the-user. .Paragraph-4}

#### The provider shall send the requested status report(s) by means of the RAF-STATUS-REPORT operation (see 3.9). {#the-provider-shall-send-the-requested-status-reports-by-means-of-the-raf-status-report-operation-see-3.9. .Paragraph-4}

#### Initially (i.e., whenever the RAF-BIND operation is performed and the provider transitions from state 1 to state 2), periodic reporting shall be stopped. {#initially-i.e.-whenever-the-raf-bind-operation-is-performed-and-the-provider-transitions-from-state-1-to-state-2-periodic-reporting-shall-be-stopped. .Paragraph-4}

#### When periodic reporting is enabled, the user may change the reporting period by invoking another RAF-SCHEDULE-STATUS-REPORT operation. {#when-periodic-reporting-is-enabled-the-user-may-change-the-reporting-period-by-invoking-another-raf-schedule-status-report-operation. .Paragraph-4}

#### The RAF-SCHEDULE-STATUS-REPORT operation shall be rejected by the provider if this service instance is configured to the offline delivery mode. {#the-raf-schedule-status-report-operation-shall-be-rejected-by-the-provider-if-this-service-instance-is-configured-to-the-offline-delivery-mode. .Paragraph-4}

#### The RAF-SCHEDULE-STATUS-REPORT operation is valid only in states 2 ('ready') and 3 ('active'). {#the-raf-schedule-status-report-operation-is-valid-only-in-states-2-ready-and-3-active. .Paragraph-4}

#### The RAF-SCHEDULE-STATUS-REPORT operation shall be invoked only by the user. {#the-raf-schedule-status-report-operation-shall-be-invoked-only-by-the-user. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-SCHEDULE-STATUS-REPORT operation shall be
present in the invocation and return as specified in table 3-7.

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the performer to authenticate the RAF-SCHEDULE-STATUS-REPORT
invocation (see 3.1.5).

#### performer-credentials

The **performer-credentials** parameter shall provide information that
enables the invoker to authenticate the return from the performance of
RAF-SCHEDULE-STATUS-REPORT (see 3.1.5).

Table 3-7: RAF-SCHEDULE-STATUS-REPORT Parameters

+------------------------------------------+-------------+-------------+
| Parameters                               | Invocation  | Return      |
+------------------------------------------+-------------+-------------+
| > invoker-credentials                    | M           |             |
+------------------------------------------+-------------+-------------+
| > performer-credentials                  |             | M           |
+------------------------------------------+-------------+-------------+
| > invoke-ID                              | M           | M           |
+------------------------------------------+-------------+-------------+
| > report-request-type                    | M           |             |
+------------------------------------------+-------------+-------------+
| > reporting-cycle                        | C           |             |
+------------------------------------------+-------------+-------------+
| > result                                 |             | M           |
+------------------------------------------+-------------+-------------+
| > diagnostic                             |             | C           |
+------------------------------------------+-------------+-------------+

#### invoke-ID

The performer shall return unchanged the invoker-supplied value of the
invoke-ID parameter (see 3.1.6).

#### report-request-type

##### The **report-request-type** parameter shall specify how reporting shall be done, and its value shall be one of the following: {#the-report-request-type-parameter-shall-specify-how-reporting-shall-be-done-and-its-value-shall-be-one-of-the-following .Paragraph-5}

a)  'immediately'---send a single status report immediately;

b)  'periodically'---send a status report every reporting-cycle seconds;

c)  'stop'---do not send further status reports.

##### If report-request-type is 'immediately',  {#if-report-request-type-is-immediately .Paragraph-5}

a)  the provider shall stop sending status reports after the immediate
    status report has been sent;

b)  periodic reporting may be restarted by means of another
    RAF-SCHEDULE-STATUS-REPORT operations.

#### reporting-cycle

##### If the value of the report-request-type parameter is 'periodically', then the reporting-cycle parameter shall be present and shall specify the requested interval between status reports in seconds. {#if-the-value-of-the-report-request-type-parameter-is-periodically-then-the-reporting-cycle-parameter-shall-be-present-and-shall-specify-the-requested-interval-between-status-reports-in-seconds. .Paragraph-5}

##### If the value of the report-request-type parameter is not 'periodically', then the reporting-cycle parameter shall not be present. {#if-the-value-of-the-report-request-type-parameter-is-not-periodically-then-the-reporting-cycle-parameter-shall-not-be-present. .Paragraph-5}

#### result

The **result** parameter shall specify the result of the
RAF-SCHEDULE-STATUS-REPORT operation, and its value shall be one of the
following:

a)  'positive result'---the RAF-SCHEDULE-STATUS-REPORT operation has
    been performed, and the provider will send the requested report(s)
    or stop sending periodic status reports;

b)  'negative result'--- the RAF-SCHEDULE-STATUS-REPORT operation has
    not been performed for the reason specified in the diagnostic
    parameter. The previous setting for status reporting remains in
    effect.

#### diagnostic

##### If result is 'negative result', the diagnostic parameter shall be present in the return, and its value shall be one of the following: {#if-result-is-negative-result-the-diagnostic-parameter-shall-be-present-in-the-return-and-its-value-shall-be-one-of-the-following-2 .Paragraph-5}

a)  'duplicate Invoke-ID'---the value of the invoke-ID parameter is the
    same as the invoke-ID of a previous, outstanding operation;

b)  'not supported in this delivery mode'---the service instance is
    configured to the offline delivery mode;

c)  'already stopped'---the provider is not currently providing periodic
    reports (applicable only when report-request-type is 'stop');

d)  'invalid reporting cycle'---the requested reporting-cycle value is
    outside the range mutually agreed upon by SLE Complex Management and
    SLE Utilization Management;

e)  'other reason'---the reason for rejection of the operation will have
    to be found by other means.

##### If result is 'positive result', the diagnostic parameter shall not be present in the return. {#if-result-is-positive-result-the-diagnostic-parameter-shall-not-be-present-in-the-return.-3 .Paragraph-5}

### Effects

#### If result is 'positive result', the RAF-SCHEDULE-STATUS-REPORT operation shall have the following effects, depending on the value of the reporting-request-type parameter: {#if-result-is-positive-result-the-raf-schedule-status-report-operation-shall-have-the-following-effects-depending-on-the-value-of-the-reporting-request-type-parameter .Paragraph-4}

a)  if the value of reporting-request-type is 'immediately':

```{=html}
<!-- -->
```
1)  a status report shall be sent immediately;

2)  the sending of any previously requested periodic status reports
    shall cease;

```{=html}
<!-- -->
```
b)  if the value of reporting-request-type is 'periodically':

```{=html}
<!-- -->
```
1)  a status report shall sent immediately;

2)  subsequent status reports shall be sent at the interval specified in
    the reporting-cycle parameter;

```{=html}
<!-- -->
```
c)  if the value of reporting-request-type is 'stop', periodic status
    reporting shall cease.

#### If result is 'negative result', the RAF-SCHEDULE-STATUS-REPORT operation shall have no effect, and the previous setting for status reporting shall not change. {#if-result-is-negative-result-the-raf-schedule-status-report-operation-shall-have-no-effect-and-the-previous-setting-for-status-reporting-shall-not-change. .Paragraph-4}

#### The state of the provider shall not change.  {#the-state-of-the-provider-shall-not-change. .Paragraph-4}

## RAF-STATUS-REPORT

### Purpose

#### The provider shall invoke the RAF-STATUS-REPORT operation to send a status report to the user. {#the-provider-shall-invoke-the-raf-status-report-operation-to-send-a-status-report-to-the-user. .Paragraph-4}

#### RAF-STATUS-REPORT shall be an unconfirmed operation. {#raf-status-report-shall-be-an-unconfirmed-operation. .Paragraph-4}

#### Status reports shall be sent (or not sent) in accordance with user requests conveyed by means of the RAF-SCHEDULE-STATUS-REPORT operation (see 3.8). {#status-reports-shall-be-sent-or-not-sent-in-accordance-with-user-requests-conveyed-by-means-of-the-raf-schedule-status-report-operation-see-3.8. .Paragraph-4}

#### The RAF-STATUS-REPORT operation is valid only in states 2 ('ready') and 3 ('active') and shall be invoked only by the provider. {#the-raf-status-report-operation-is-valid-only-in-states-2-ready-and-3-active-and-shall-be-invoked-only-by-the-provider. .Paragraph-4}

### INVOCATION, RETURN, and parameters

#### General

The parameters of the RAF-STATUS-REPORT operation shall be present in
the invocation as specified in table 3-8.

Table 3-8: RAF-STATUS-REPORT Parameters

+-----------------------------------------------------+-----------------+
| Parameters                                          | Invocation      |
+-----------------------------------------------------+-----------------+
| > invoker-credentials                               | M               |
+-----------------------------------------------------+-----------------+
| > number-of-error-free-frames-delivered             | M               |
+-----------------------------------------------------+-----------------+
| > number-of-frames-delivered                        | M               |
+-----------------------------------------------------+-----------------+
| > frame-sync-lock-status                            | M               |
+-----------------------------------------------------+-----------------+
| > symbol-sync-lock-status                           | M               |
+-----------------------------------------------------+-----------------+
| > subcarrier-lock-status                            | M               |
+-----------------------------------------------------+-----------------+
| > carrier-lock-status                               | M               |
+-----------------------------------------------------+-----------------+
| > production-status                                 | M               |
+-----------------------------------------------------+-----------------+

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the performer to authenticate the RAF-STATUS-REPORT invocation
(see 3.1.5).

#### number-of-error-free-frames-delivered

The **number-of-error-free-frames-delivered** parameter shall specify
the number of telemetry frames that were annotated with a frame-quality
of 'good' and delivered to the user since the start of the service
instance provision period.

#### number-of-frames-delivered

The **number-of-frames-delivered** parameter shall specify the total
number of telemetry frames that have been delivered to the user since
the start of the service instance provision period.

#### frame-sync-lock-status

The frame-sync-lock-status parameter shall specify the current lock
status of the frame synchronization process, the value of which shall be
'in-lock', 'out-of-lock', 'not in use', or 'unknown'.

#### symbol-sync-lock-status

The symbol-sync-lock-status parameter shall specify the current lock
status of the symbol (or bit) synchronization process, the value of
which shall be 'in-lock', 'out-of-lock', 'not in use', or 'unknown'.

#### subcarrier-lock-status

The subcarrier-lock-status parameter shall specify the current lock
status of the subcarrier demodulation process, the value of which shall
be 'in-lock', 'out-of-lock', 'not in use', or 'unknown'.

#### carrier-lock-status

The carrier-lock-status parameter shall specify the current lock status
of the carrier demodulation process, the value of which shall be
'in-lock', 'out-of-lock', 'not in use', or 'unknown'.

#### production-status

The production-status parameter shall specify the current status of RAF
production, the value of which shall be 'running', 'halted', or
'interrupted'.

NOTE -- See 3.7.2.4 for a description of the production-status values.

### Effects

The RAF-STATUS-REPORT operation shall have the following effects:

a)  status information shall be delivered to the user;

b)  the state of the provider shall not change.

## RAF-GET-PARAMETER

### Purpose

#### The user shall invoke the RAF-GET-PARAMETER operation to ascertain the value of an RAF service parameter. {#the-user-shall-invoke-the-raf-get-parameter-operation-to-ascertain-the-value-of-an-raf-service-parameter. .Paragraph-4}

#### The provider shall return a report of the outcome of the performance of the RAF-GET-PARAMETER operation to the user. {#the-provider-shall-return-a-report-of-the-outcome-of-the-performance-of-the-raf-get-parameter-operation-to-the-user. .Paragraph-4}

#### If the operation is successful, the current value of the specified RAF service parameter shall be provided to the user in the return from the operation. {#if-the-operation-is-successful-the-current-value-of-the-specified-raf-service-parameter-shall-be-provided-to-the-user-in-the-return-from-the-operation. .Paragraph-4}

#### RAF-GET-PARAMETER is valid in state 2 ('ready') and state 3 ('active') and shall be invoked only by the user. {#raf-get-parameter-is-valid-in-state-2-ready-and-state-3-active-and-shall-be-invoked-only-by-the-user. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-GET-PARAMETER operation shall be present in
the invocation and return as specified in table 3-9.

Table 3-9: RAF-GET-PARAMETER Parameters

+------------------------------------------+-------------+-------------+
| Parameters                               | Invocation  | Return      |
+------------------------------------------+-------------+-------------+
| > invoker-credentials                    | M           |             |
+------------------------------------------+-------------+-------------+
| > performer-credentials                  |             | M           |
+------------------------------------------+-------------+-------------+
| > invoke-ID                              | M           | M           |
+------------------------------------------+-------------+-------------+
| > raf-parameter                          | M           | C           |
+------------------------------------------+-------------+-------------+
| > parameter-value                        |             | C           |
+------------------------------------------+-------------+-------------+
| > result                                 |             | M           |
+------------------------------------------+-------------+-------------+
| > diagnostic                             |             | C           |
+------------------------------------------+-------------+-------------+

#### invoker-credentials

The **invoker-credentials** parameter shall provide information that
enables the performer to authenticate the RAF-GET-PARAMETER invocation
(see 3.1.5).

#### performer-credentials

The **performer-credentials** parameter shall provide information that
enables the invoker to authenticate the return from the performance of
RAF-GET-PARAMETER (see 3.1.5).

#### invoke-ID

The performer shall return unchanged the invoker-supplied value of the
invoke-ID parameter (see 3.1.6).

#### raf-parameter

##### The **raf-parameter** parameter shall specify the RAF service parameter whose value is to be returned to the user and shall contain one of the following values: {#the-raf-parameter-parameter-shall-specify-the-raf-service-parameter-whose-value-is-to-be-returned-to-the-user-and-shall-contain-one-of-the-following-values .Paragraph-5}

a)  'requested frame quality'---the frame quality criteria, set by the
    RAF-START operation, used to determine which frames are selected for
    delivery: if the provider is in state 3 ('active'), its value shall
    be 'good frames only', 'erred frames only', or 'all frames';
    otherwise, its value shall be 'undefined';

b)  'latency limit'---the maximum allowable delivery latency time (in
    seconds) for the timely online delivery mode, as defined in 3.1.8.1
    (i.e., the maximum delay from when the frame is acquired by the
    provider until it is delivered to the user): the value of this
    parameter shall be 'null' if the delivery mode is not timely online;

c)  'transfer buffer size'---the size of the transfer buffer (see
    3.1.8): the value of this parameter shall indicate the number of
    RAF-TRANSFER-DATA invocations that can be stored in the transfer
    buffer;

d)  'delivery mode'---the delivery mode for this instance of RAF
    service, which is set by service management (see 3.1.8): its value
    shall be 'timely online delivery mode', 'complete online delivery
    mode', or 'offline delivery mode';

e)  'reporting cycle'---the current setting of the reporting cycle for
    status reports (see 3.8 and 3.9): the value is 'null' if cyclic
    reporting is off, otherwise it is the time (in seconds) between
    successive RAF-STATUS-REPORT invocations (see 3.8);

f)  'return timeout period'---the maximum time period (in seconds)
    permitted from when a confirmed RAF operation is invoked until the
    return is received by the invoker (see 4.1.3).

##### The raf-parameter parameter is conditionally present in the return based on the result parameter: {#the-raf-parameter-parameter-is-conditionally-present-in-the-return-based-on-the-result-parameter .Paragraph-5}

a)  if the value of result is 'positive result', raf-parameter shall be
    present;

b)  if the value of result is 'negative result', raf-parameter shall not
    be present.

#### parameter-value

##### The **parameter-value** parameter shall contain the value of the RAF service parameter indicated by raf-parameter (see 3.10.2.5). {#the-parameter-value-parameter-shall-contain-the-value-of-the-raf-service-parameter-indicated-by-raf-parameter-see-3.10.2.5. .Paragraph-5}

##### The parameter-value parameter is conditionally present in the return based on the result parameter: {#the-parameter-value-parameter-is-conditionally-present-in-the-return-based-on-the-result-parameter .Paragraph-5}

a)  if the value of result is 'positive result', parameter-value shall
    be present;

b)  if the value of result is 'negative result', parameter-value shall
    not be present.

#### result

The **result** parameter shall specify the result of the
RAF-GET-PARAMETER operation and shall contain one of the following
values:

a)  'positive result'---the RAF-GET-PARAMETER operation has been
    performed, and the value of the specified RAF service parameter is
    provided in the return to the user;

b)  'negative result'---the RAF-GET-PARAMETER operation has not been
    performed for the reason specified in the diagnostic parameter.

#### diagnostic

##### If result is 'negative result', the diagnostic parameter shall be present in the return, and its value shall be one of the following: {#if-result-is-negative-result-the-diagnostic-parameter-shall-be-present-in-the-return-and-its-value-shall-be-one-of-the-following-3 .Paragraph-5}

a)  'duplicate Invoke-ID'---the value of the invoke-ID parameter is the
    same as the invoke-ID of a previous, outstanding operation;

b)  'unknown parameter'---the value of raf-parameter does not identify
    an RAF parameter that is recognized by the service provider;

c)  'other reason'---the reason for the negative result will have to be
    found by other means.

##### If result is 'positive result', the diagnostic parameter shall not be present in the return. {#if-result-is-positive-result-the-diagnostic-parameter-shall-not-be-present-in-the-return.-4 .Paragraph-5}

### Effects

#### If result is 'positive result', the value of the RAF parameter specified in the invocation shall be provided to the user in the return. {#if-result-is-positive-result-the-value-of-the-raf-parameter-specified-in-the-invocation-shall-be-provided-to-the-user-in-the-return. .Paragraph-4}

#### If result is 'negative result', no RAF parameter value shall be returned to the user. {#if-result-is-negative-result-no-raf-parameter-value-shall-be-returned-to-the-user. .Paragraph-4}

#### The state of the provider shall not change.  {#the-state-of-the-provider-shall-not-change.-1 .Paragraph-4}

## RAF-PEER-ABORT

### Purpose

#### The user or provider shall invoke the RAF-PEER-ABORT operations to notify the peer system that the local application detected an error that requires that the association between them be terminated abnormally. {#the-user-or-provider-shall-invoke-the-raf-peer-abort-operations-to-notify-the-peer-system-that-the-local-application-detected-an-error-that-requires-that-the-association-between-them-be-terminated-abnormally. .Paragraph-4}

#### RAF-STATUS-REPORT shall be an unconfirmed operation. {#raf-status-report-shall-be-an-unconfirmed-operation.-1 .Paragraph-4}

#### RAF-PEER-ABORT is valid only in states 2 ('ready') and 3 ('active') and may be invoked by either the user or the provider. {#raf-peer-abort-is-valid-only-in-states-2-ready-and-3-active-and-may-be-invoked-by-either-the-user-or-the-provider. .Paragraph-4}

### invocation, return, and parameters

#### General

The parameters of the RAF-PEER-ABORT operation shall be present in the
invocation as specified in table 3-10.

Table 3-10: RAF-PEER-ABORT Parameters

+-----------------------------------------------------+-----------------+
| Parameters                                          | Invocation      |
+-----------------------------------------------------+-----------------+
| > diagnostic                                        | M               |
+-----------------------------------------------------+-----------------+

#### diagnostic

The **diagnostic** parameter shall specify why the RAF-PEER-ABORT is
being invoked, and its value shall be one of the following:

a)  'access denied'---a responder with an identity as presented in the
    responder-identifier parameter of the RAF-BIND return is not known
    to the initiator (e.g., the value of the responder-identifier
    parameter does not match the authorized responder for any service
    instance known to the initiator);

b)  'unexpected responder ID'---the value of the responder-identifier
    parameter in the RAF-BIND return does not match the identity of the
    authorized responder for this service instance as specified by
    service management;

c)  'operational requirement'---the local system had to terminate the
    association to accommodate some other operational need;

d)  'protocol error'---the local application detected an error in the
    sequencing of RAF service operations;

e)  'communications failure'---the communications service on the other
    side of a gateway was disrupted;

NOTE -- This diagnostic value is only applicable when the SLE
applications are communicating via a gateway.

f)  'encoding error'---the local application detected an error in the
    encoding of one or more operation parameters or did not recognize
    the operation;

g)  'return timeout'---the local application detected that the return
    from a confirmed operation was not received within a specified time
    limit;

h)  'end of service provision period'---the local application detected
    that the service instance provision period has ended and the
    initiator has not invoked the RAF-UNBIND operation;

i)  'unsolicited invoke-ID'---the local application received a return
    with an invoke-ID that does not match the invoke-ID of any of the
    operations for which a return is pending;

j)  'other reason'---the local application detected an unspecified error
    during the processing of one or more operations.

NOTE -- RAF-PEER-ABORT does not carry an invoker-credentials parameter.
It is conceivable that an intruder may use the RAF-PER-ABORT operation
for a denial-of-service attack. If an intruder has that capability, then
a denial-of-service attack can be much more easily accomplished by
disrupting communications at a layer lower than the applications layer.
Therefore, authentication of RAF-PEER-ABORT would not provide improved
protections against such attacks.

### Effects

The RAF-PEER-ABORT operation shall have the following effects:

a)  the association shall be aborted, and the user and the provider
    shall cease to communicate with each other;

NOTE -- The RAF-PEER-ABORT operation shall be truly abortive. This
implies that the transfer of the SLE-PDU carrying this invocation shall
not be delayed by other invocations submitted earlier.

b)  the provider shall transition to state 1 ('unbound');

c)  the provider shall discard the contents of the transfer buffer;

d)  the values of RAF service parameters shall return to the initial
    values set by service management, including the values of any
    parameters changed by the service user;

e)  statistical information required for the generation of the status
    report shall be retained throughout the service instance provision
    period.

# RAF Protocol

## Generic Protocol Characteristics

NOTE -- This section specifies the handling of invalid SLE-PDUs and
other failures affecting the protocol.

### Unexpected Protocol Data Unit

If the peer application invokes an operation not allowed in the current
state of the performer, the performer shall abort the association by
invoking the RAF-PEER-ABORT operation with the diagnostic parameter set
to 'protocol error'.

### Invalid Protocol Data Unit

If the application receives an invocation or return that contains an
unrecognized operation type, contains a parameter of the wrong type, or
is otherwise not decodable, the application shall abort the association
by invoking the RAF-PEER-ABORT operation with the diagnostic parameter
set to 'encoding error'.

### Missing return

For confirmed operations, if the invoker does not receive the return
from the performer within a timeout period specified by service
management, the invoker shall abort the association by invoking the
RAF-PEER-ABORT operation with the diagnostic parameter set to 'return
timeout'.

NOTES

1.  The timeout period shall be chosen taking into account performance
    of user and provider applications as well as the delays introduced
    by the underlying communications service.

2.  In order to provide responsive service and short timeout periods,
    the generation of the return from an operation must not depend on
    any human interaction.

3.  After invoking the RAF-UNBIND operation, the initiator must not
    invoke any further operations nor send any returns. The responder is
    not required to send any pending returns after having received the
    RAF-UNBIND invocation. Therefore, following a RAF-UNBIND invocation,
    the 'missing return' event may occur.

### Unsolicited Return

If the application receives a return with an invoke-ID parameter value
that does not correspond to any invocation for which a return is still
pending, the application shall abort the association by invoking the
RAF-PEER-ABORT operation with the diagnostic parameter set to
'unsolicited Invoke-ID'.

### Communications Failure

#### Every SLE entity (i.e., every SLE user or provider) that is in an association (bound) with a peer SLE entity shall maintain knowledge of the health of the communications interface with the peer. {#every-sle-entity-i.e.-every-sle-user-or-provider-that-is-in-an-association-bound-with-a-peer-sle-entity-shall-maintain-knowledge-of-the-health-of-the-communications-interface-with-the-peer. .Paragraph-4}

#### Every SLE implementation shall provide that, for every association, the two SLE entities in the association maintain a consistent view of the health of the communications interface between them. {#every-sle-implementation-shall-provide-that-for-every-association-the-two-sle-entities-in-the-association-maintain-a-consistent-view-of-the-health-of-the-communications-interface-between-them. .Paragraph-4}

#### If an SLE entity determines that communications with the peer SLE entity have been disrupted (e.g., because of a communications service fault), then the SLE entity shall consider that the association with the peer has been aborted. {#if-an-sle-entity-determines-that-communications-with-the-peer-sle-entity-have-been-disrupted-e.g.-because-of-a-communications-service-fault-then-the-sle-entity-shall-consider-that-the-association-with-the-peer-has-been-aborted. .Paragraph-4}

NOTE -- The exact criteria for determining when communications have been
disrupted may depend on the characteristics of the underlying
communications service and may be specific to a given implementation.
However, every RAF user and provider implementation shall provide for
monitoring the health of the communications interface and for ensuring
that the user and the provider have a consistent view of the health of
the communications interface. If the underlying communications service
does not intrinsically provide such a capability, the transmission of a
periodic 'heartbeat' indicator or equivalent may need to be implemented.

#### Occurrence of the above described communications failure event shall be referred to as a 'protocol abort'. {#occurrence-of-the-above-described-communications-failure-event-shall-be-referred-to-as-a-protocol-abort. .Paragraph-4}

#### Subsequent to a 'protocol abort' event: {#subsequent-to-a-protocol-abort-event .Paragraph-4}

a)  the RAF provider shall transition to state 1 ('unbound');

b)  neither the user nor the provider shall attempt further
    communications with the peer except that the initiator may attempt
    to re-establish the association by invoking the RAF-BIND operation;

c)  the provider shall discard the contents of the transfer buffer;

d)  the values of RAF service parameters shall return to the initial
    values set by service management for that service instance; and

e)  statistical information required for the generation of the status
    report shall be retained throughout the service instance provision
    period.

### Access Control

#### The initiator of an association shall present its own identity in the initiator-identifier parameter of the RAF-BIND invocation. {#the-initiator-of-an-association-shall-present-its-own-identity-in-the-initiator-identifier-parameter-of-the-raf-bind-invocation. .Paragraph-4}

#### If the RAF-BIND operation is invoked with a value of initiator-identifier that is not known to the responder, the responder shall not make any attempt to authenticate that invocation. Instead, the responder shall generate an RAF-BIND return with result set to 'negative result', diagnostic set to 'access denied', and performer-credentials set to 'unused'. {#if-the-raf-bind-operation-is-invoked-with-a-value-of-initiator-identifier-that-is-not-known-to-the-responder-the-responder-shall-not-make-any-attempt-to-authenticate-that-invocation.-instead-the-responder-shall-generate-an-raf-bind-return-with-result-set-to-negative-result-diagnostic-set-to-access-denied-and-performer-credentials-set-to-unused. .Paragraph-4}

#### If the value of initiator-identifier is known to the responder, the responder shall attempt to authenticate the RAF-BIND invocation (see 3.1.5) as required for the given initiator. If authentication succeeds but the initiator is not the authorized initiator for the service instance indicated in the service-instance-identifier parameter of the RAF-BIND invocation, the responder shall generate an RAF-BIND return with result set to 'negative result' and diagnostic set to 'service instance not accessible to this initiator'. {#if-the-value-of-initiator-identifier-is-known-to-the-responder-the-responder-shall-attempt-to-authenticate-the-raf-bind-invocation-see-3.1.5-as-required-for-the-given-initiator.-if-authentication-succeeds-but-the-initiator-is-not-the-authorized-initiator-for-the-service-instance-indicated-in-the-service-instance-identifier-parameter-of-the-raf-bind-invocation-the-responder-shall-generate-an-raf-bind-return-with-result-set-to-negative-result-and-diagnostic-set-to-service-instance-not-accessible-to-this-initiator. .Paragraph-4}

NOTE -- If authentication fails, the responder shall behave as specified
in 4.1.7. If authentication is not required for the given initiator, it
shall be as if authentication was successful.

#### If the initiator receives an RAF-BIND return with a responder-identifier value that is not known to the initiator, the initiator shall not make any attempt to authenticate this return but shall abort the association by invoking RAF-PEER-ABORT with diagnostic set to 'access denied'. {#if-the-initiator-receives-an-raf-bind-return-with-a-responder-identifier-value-that-is-not-known-to-the-initiator-the-initiator-shall-not-make-any-attempt-to-authenticate-this-return-but-shall-abort-the-association-by-invoking-raf-peer-abort-with-diagnostic-set-to-access-denied. .Paragraph-4}

#### If the initiator receives an RAF-BIND return with a responder-identifier value that is known to the initiator, the initiator shall attempt to authenticate the RAF-BIND return (see 3.1.5) as required for the given responder. If authentication succeeds but the responder-identifier is not the authorized initiator for this service instance as specified by service management, the initiator shall abort the association by means of the RAF-PEER-ABORT operation with diagnostic set to 'unexpected responder ID'. {#if-the-initiator-receives-an-raf-bind-return-with-a-responder-identifier-value-that-is-known-to-the-initiator-the-initiator-shall-attempt-to-authenticate-the-raf-bind-return-see-3.1.5-as-required-for-the-given-responder.-if-authentication-succeeds-but-the-responder-identifier-is-not-the-authorized-initiator-for-this-service-instance-as-specified-by-service-management-the-initiator-shall-abort-the-association-by-means-of-the-raf-peer-abort-operation-with-diagnostic-set-to-unexpected-responder-id. .Paragraph-4}

NOTE -- If authentication fails, the initiator shall behave as specified
in 4.1.7. If authentication is not required for the given responder, it
shall be as if authentication was successful.

### Failing Authentication

#### An incoming invocation or return shall be ignored if the credentials parameter cannot be authenticated when, by management arrangement, credentials are required. {#an-incoming-invocation-or-return-shall-be-ignored-if-the-credentials-parameter-cannot-be-authenticated-when-by-management-arrangement-credentials-are-required. .Paragraph-4}

#### If an invocation is ignored, the operation shall not be performed, and a report of the outcome shall not be returned to the invoker. {#if-an-invocation-is-ignored-the-operation-shall-not-be-performed-and-a-report-of-the-outcome-shall-not-be-returned-to-the-invoker. .Paragraph-4}

#### If a return is ignored, it shall be as if no report of the outcome of the operation has been received. {#if-a-return-is-ignored-it-shall-be-as-if-no-report-of-the-outcome-of-the-operation-has-been-received. .Paragraph-4}

## RAF Service Provider Behavior

### General Requirements

#### The behavior of the RAF service provider shall conform to the state transition matrix specified in table 4-1. {#the-behavior-of-the-raf-service-provider-shall-conform-to-the-state-transition-matrix-specified-in-table-4-1. .Paragraph-4}

#### The state transition matrix specified in table 4-1 represents one instance of service and thus one association. Once the association is established, if an RAF-BIND invocation for a different association but for the same service instance is received, it shall be rejected with an RAF-BIND return with the result parameter set to 'negative result' and the diagnostic parameter set to 'already bound'. This event shall not affect the association already in place. {#the-state-transition-matrix-specified-in-table-4-1-represents-one-instance-of-service-and-thus-one-association.-once-the-association-is-established-if-an-raf-bind-invocation-for-a-different-association-but-for-the-same-service-instance-is-received-it-shall-be-rejected-with-an-raf-bind-return-with-the-result-parameter-set-to-negative-result-and-the-diagnostic-parameter-set-to-already-bound.-this-event-shall-not-affect-the-association-already-in-place. .Paragraph-4}

### State TRANSITION Table

NOTES

1.  The state table specifies operation interactions and state
    transitions for the service provider in its role as either initiator
    or responder.

2.  The leftmost column simply numbers the rows of the table.

3.  The leftmost column of the state table lists all incoming events.
    Where these events correspond to the arrival of an incoming SLE-PDU,
    the ASN.1 type defined for this SLE-PDU in annex A is indicated in
    parentheses ( ).

4.  Where an event is internal to the provider, its description is put
    in single quotation marks ' '. These events are defined in table
    4-2.

5.  The three columns (one column per state) on the right side of the
    table specify the behavior the provider will exhibit, which depends
    on the current state and the incoming event. In some cases, the
    behavior in addition depends on Boolean conditions, also referred to
    as predicates. Such conditions are put in double quotation marks "
    ". The predicates are defined in table 4‑3. Predicates that are
    simple Boolean variables set only by that state machine itself are
    referred to as Boolean flags and specified in table 4-4. The
    dependency on a predicate is presented in form of an IF
    \<condition\> THEN \<action\> \[ELSEIF \<condition\> THEN
    \<action\>\] ELSE \<action\> clause.

6.  If the action given in the table is simply to send a specific
    SLE-PDU, that is indicated by the appearance of the name of ASN.1
    type of the SLE-PDU to be sent in parentheses ( ). If that SLE-PDU
    is a return, the name may be preceded by the plus symbol ('+') to
    indicate that result is 'positive result' or by the negative symbol
    ('‑') to indicate 'negative result'. Where several actions are to be
    taken (referred to as a 'compound action'), the name of the compound
    action is put in curly braces { }. The individual actions making up
    each compound action are identified in table 4-5.

7.  'Not applicable' is stated where the given event can only occur in
    the given state because of an implementation error on the provider
    side.

8.  Where the consequences of an incoming event are not visible to the
    user because the provider does not send any SLE-PDU in reaction to
    the given event, the action is put in square brackets \[\].

9.  State transitions are indicated by an arrow and the number of the
    state that will be entered; for example, à 1 indicates the
    transition to state 1.

10. The actions to be taken and the state transition are considered to
    be one atomic action. The sequence shown in the table is irrelevant
    except that SLE-PDUs shall be sent in the sequence stated in the
    table.

11. Whenever the provider invokes a confirmed operation with invoke-ID
    set to \<n\>, it shall start an associated return \<n\> timer.
    Should this timer expire before the return \<n\> is received, the
    provider shall invoke RAF-PEER-ABORT.

Table 4-1: Provider Behavior

+---+----------------+----------------+----------------+----------------+
| * | **Incoming     | **Unbound (    | **Ready (State | **Active       |
| * | Event**        | State 1)**     | 2)**           | (State 3)**    |
| N |                |                |                |                |
| o |                |                |                |                |
| . |                |                |                |                |
| * |                |                |                |                |
| * |                |                |                |                |
+===+================+================+================+================+
| 1 | 'start of      | IF "provider   | Not applicable | Not applicable |
|   | service        | initiated"     |                |                |
|   | instance       |                |                |                |
|   | provision      | THEN {invoke   |                |                |
|   | period'        | bind} à 1      |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | \[ignore\] à 1 |                |                |
+---+----------------+----------------+----------------+----------------+
| 2 | 'return \<n\>  | IF "bind       | {peer abort    | {peer abort    |
|   | timer expired' | pending"       | 'return        | 'return        |
|   |                |                | timeout'} à 1  | timeout'} à 1  |
|   |                | THEN {return   |                |                |
|   |                | timeout} à 1   |                |                |
|   |                |                |                |                |
|   |                | IF NOT 'end of |                |                |
|   |                | service        |                |                |
|   |                | instance\      |                |                |
|   |                | provision      |                |                |
|   |                | period'        |                |                |
|   |                |                |                |                |
|   |                | THEN {invoke   |                |                |
|   |                | bind}          |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | \[ignore\]     |                |                |
|   |                |                |                |                |
|   |                | ELSE Not       |                |                |
|   |                | applicable à 1 |                |                |
+---+----------------+----------------+----------------+----------------+
| 3 | (-             | IF "bind       | {peer abort    | {peer abort    |
|   | rafBindReturn) | pending"       | 'protocol      | 'protocol      |
|   |                |                | error'} à 1    | error'} à 1    |
|   |                | THEN set "bind |                |                |
|   |                | pending" FALSE |                |                |
|   |                | à 1            |                |                |
|   |                |                |                |                |
|   |                | stop return    |                |                |
|   |                | \<n\> timer    |                |                |
|   |                |                |                |                |
|   |                | IF "retry      |                |                |
|   |                | permitted"     |                |                |
|   |                |                |                |                |
|   |                | THEN {invoke   |                |                |
|   |                | bind}          |                |                |
|   |                |                |                |                |
|   |                | ELSE release   |                |                |
|   |                | resources      |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | \[ignore\] à 1 |                |                |
+---+----------------+----------------+----------------+----------------+
| 4 | (+             | IF "bind       | {peer abort    | {peer abort    |
|   | rafBindReturn) | pending"       | 'protocol      | 'protocol      |
|   |                |                | error'} à 1    | error'} à 1    |
|   |                | THEN set "bind |                |                |
|   |                | pending" FALSE |                |                |
|   |                | à 2            |                |                |
|   |                |                |                |                |
|   |                | stop return    |                |                |
|   |                | \<n\> timer    |                |                |
|   |                |                |                |                |
|   |                | IF NOT         |                |                |
|   |                | "compatible"   |                |                |
|   |                |                |                |                |
|   |                | THEN {invoke   |                |                |
|   |                | unbind}        |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | \[ignore\]     |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | \[ignore\] à 1 |                |                |
+---+----------------+----------------+----------------+----------------+
| 5 | (rafB          | IF "provider   | {peer abort    | {peer abort    |
|   | indInvocation) | initiated"     | 'protocol      | 'protocol      |
|   |                |                | error'} à 1    | error'} à 1    |
|   |                | THEN           |                |                |
|   |                | \[ignore\] à 1 |                |                |
|   |                |                |                |                |
|   |                | ELSE IF        |                |                |
|   |                | "positive      |                |                |
|   |                | result"        |                |                |
|   |                |                |                |                |
|   |                | THEN           |                |                |
|   |                | (+             |                |                |
|   |                | rafBindReturn) |                |                |
|   |                | à 2            |                |                |
|   |                |                |                |                |
|   |                | ELSE           |                |                |
|   |                | (-             |                |                |
|   |                | rafBindReturn) |                |                |
|   |                | à 1            |                |                |
+---+----------------+----------------+----------------+----------------+
| 6 | 'end of        | \[ignore\]     | IF "provider   | {peer abort    |
|   | service        |                | initiated"     | 'end of        |
|   | instance       |                |                | service        |
|   | provision      |                | THEN {invoke   | instance\      |
|   | period'        |                | unbind} à 2    | provision      |
|   |                |                |                | period'} à 1   |
|   |                |                | ELSE {peer     |                |
|   |                |                | abort 'end of  |                |
|   |                |                | service\       |                |
|   |                |                | instance       |                |
|   |                |                | provision      |                |
|   |                |                | period'} à 1   |                |
+---+----------------+----------------+----------------+----------------+
| 7 | (ra            | \[ignore\]     | IF "unbind     | {peer abort    |
|   | fUnbindReturn) |                | pending"       | 'protocol      |
|   |                |                |                | error'} à 1    |
|   |                |                | THEN {provider |                |
|   |                |                | unbind} à 1    |                |
|   |                |                |                |                |
|   |                |                | IF "done"      |                |
|   |                |                |                |                |
|   |                |                | THEN release   |                |
|   |                |                | resources      |                |
|   |                |                |                |                |
|   |                |                | ELSE           |                |
|   |                |                | \[ignore\]     |                |
|   |                |                |                |                |
|   |                |                | ELSE {peer     |                |
|   |                |                | abort          |                |
|   |                |                | 'protocol      |                |
|   |                |                | error'} à 1    |                |
+---+----------------+----------------+----------------+----------------+
| 8 | (rafUnb        | \[ignore\]     | IF "provider   | {peer abort    |
|   | indInvocation) |                | initiated"     | 'protocol      |
|   |                |                |                | error'} à 1    |
|   |                |                | THEN {peer     |                |
|   |                |                | abort          |                |
|   |                |                | 'protocol      |                |
|   |                |                | error'} à 1    |                |
|   |                |                |                |                |
|   |                |                | ELSE {user     |                |
|   |                |                | unbind} à 1    |                |
|   |                |                |                |                |
|   |                |                | IF "end"       |                |
|   |                |                |                |                |
|   |                |                | THEN release   |                |
|   |                |                | resources      |                |
|   |                |                |                |                |
|   |                |                | ELSE           |                |
|   |                |                | \[ignore\]     |                |
+---+----------------+----------------+----------------+----------------+
| 9 | (rafSt         | \[ignore\]     | IF "unbind     | {peer abort    |
|   | artInvocation) |                | pending"       | 'protocol      |
|   |                |                |                | error'} à 1    |
|   |                |                | THEN {peer     |                |
|   |                |                | abort          |                |
|   |                |                | 'protocol      |                |
|   |                |                | error'} à 1    |                |
|   |                |                |                |                |
|   |                |                | ELSE IF        |                |
|   |                |                | "positive      |                |
|   |                |                | result"        |                |
|   |                |                |                |                |
|   |                |                | THEN           |                |
|   |                |                | (+r            |                |
|   |                |                | afStartReturn) |                |
|   |                |                | à 3            |                |
|   |                |                |                |                |
|   |                |                | initialize     |                |
|   |                |                | transfer       |                |
|   |                |                | buffer         |                |
|   |                |                |                |                |
|   |                |                | ELSE           |                |
|   |                |                | (-r            |                |
|   |                |                | afStartReturn) |                |
|   |                |                | à 2            |                |
+---+----------------+----------------+----------------+----------------+
| 1 | (rafS          | \[ignore\]     | {peer abort    | IF "positive   |
| 0 | topInvocation) |                | 'protocol      | result"        |
|   |                |                | error'} à 1    |                |
|   |                |                |                | THEN stop      |
|   |                |                |                | release timer  |
|   |                |                |                | à 2            |
|   |                |                |                |                |
|   |                |                |                | (+             |
|   |                |                |                | rafStopReturn) |
|   |                |                |                |                |
|   |                |                |                | ELSE           |
|   |                |                |                | (-             |
|   |                |                |                | rafStopReturn) |
|   |                |                |                | à 3            |
+---+----------------+----------------+----------------+----------------+
| 1 | 'data          | Not applicable | Not applicable | IF "buffer     |
| 1 | available',\   |                |                | full"          |
|   | "complete      |                |                |                |
|   | online"        |                |                | THEN submit    |
|   | delivery mode  |                |                | buffer         |
|   | or "offline"   |                |                | contents       |
|   | delivery mode  |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested") à |
|   |                |                |                | 3              |
|   |                |                |                |                |
|   |                |                |                | reinitialize   |
|   |                |                |                | transfer       |
|   |                |                |                | buffer         |
|   |                |                |                |                |
|   |                |                |                | {insert        |
|   |                |                |                | annotated      |
|   |                |                |                | frame}         |
|   |                |                |                |                |
|   |                |                |                | ELSE {insert   |
|   |                |                |                | annotated      |
|   |                |                |                | frame} à 3     |
+---+----------------+----------------+----------------+----------------+
| 1 | 'data          | Not applicable | Not applicable | IF "buffer     |
| 2 | available',\   |                |                | full"          |
|   | "timely        |                |                |                |
|   | online"        |                |                | THEN {pass     |
|   | delivery mode  |                |                | buffer         |
|   |                |                |                | contents} à 3  |
|   |                |                |                |                |
|   |                |                |                | IF "congested" |
|   |                |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'data   |
|   |                |                |                | discarded'}    |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | {insert        |
|   |                |                |                | annotated      |
|   |                |                |                | frame}         |
|   |                |                |                |                |
|   |                |                |                | ELSE {insert   |
|   |                |                |                | annotated      |
|   |                |                |                | frame}         |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | ELSE IF        |
|   |                |                |                | "buffer empty" |
|   |                |                |                |                |
|   |                |                |                | THEN {insert   |
|   |                |                |                | annotated      |
|   |                |                |                | frame} à 3     |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | ELSE {insert   |
|   |                |                |                | annotated      |
|   |                |                |                | frame} à 3     |
+---+----------------+----------------+----------------+----------------+
| 1 | 'release timer | Not applicable | Not applicable | {pass buffer   |
| 3 | expired',\     |                |                | contents} à 3  |
|   | "timely        |                |                |                |
|   | online"        |                |                | IF "congested" |
|   | delivery mode  |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'data   |
|   |                |                |                | discarded'}    |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | ELSE           |
|   |                |                |                | \[ignore\]     |
+---+----------------+----------------+----------------+----------------+
| 1 | 'end of        | Not applicable | Not applicable | IF "buffer     |
| 4 | data',\        |                |                | full"          |
|   | "timely        |                |                |                |
|   | online"        |                |                | THEN {pass     |
|   | delivery mode  |                |                | buffer         |
|   |                |                |                | contents} à 3  |
|   |                |                |                |                |
|   |                |                |                | IF "congested" |
|   |                |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'data   |
|   |                |                |                | discarded'}    |
|   |                |                |                |                |
|   |                |                |                | {sync notify   |
|   |                |                |                | 'end of data'} |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents       |
|   |                |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
|   |                |                |                |                |
|   |                |                |                | ELSE {sync     |
|   |                |                |                | notify 'end of |
|   |                |                |                | data'}         |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents       |
|   |                |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
|   |                |                |                |                |
|   |                |                |                | ELSE IF        |
|   |                |                |                | "buffer empty" |
|   |                |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'end of |
|   |                |                |                | data'} à 3     |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents UNTIL |
|   |                |                |                |                |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
|   |                |                |                |                |
|   |                |                |                | ELSE stop      |
|   |                |                |                | release timer  |
|   |                |                |                | à 3            |
|   |                |                |                |                |
|   |                |                |                | {sync notify   |
|   |                |                |                | 'end of data'} |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents       |
|   |                |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
+---+----------------+----------------+----------------+----------------+
| 1 | 'end of        | Not applicable | Not applicable | IF "buffer     |
| 5 | data',\        |                |                | full"          |
|   | "complete      |                |                |                |
|   | online"        |                |                | THEN submit    |
|   | delivery mode  |                |                | buffer         |
|   | or\            |                |                | contents       |
|   | "offline"      |                |                | UNTIL\         |
|   | delivery mode  |                |                | (NOT           |
|   |                |                |                | "congested") à |
|   |                |                |                | 3              |
|   |                |                |                |                |
|   |                |                |                | reinitialize   |
|   |                |                |                | transfer       |
|   |                |                |                | buffer         |
|   |                |                |                |                |
|   |                |                |                | {sync notify   |
|   |                |                |                | 'end of data'} |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents       |
|   |                |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
|   |                |                |                |                |
|   |                |                |                | ELSE {sync     |
|   |                |                |                | notify 'end of |
|   |                |                |                | data'} à 3     |
|   |                |                |                |                |
|   |                |                |                | submit buffer  |
|   |                |                |                | contents       |
|   |                |                |                | UNTIL\         |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested")   |
+---+----------------+----------------+----------------+----------------+
| 1 | 'loss of frame | Not applicable | \[ignore\] à 2 | IF "buffer     |
| 6 | sync           |                |                | full"          |
|   | hronization',\ |                |                |                |
|   | "timely        |                |                | THEN {pass     |
|   | online"        |                |                | buffer         |
|   | delivery mode  |                |                | contents} à 3  |
|   |                |                |                |                |
|   |                |                |                | IF "congested" |
|   |                |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'data   |
|   |                |                |                | discarded'}    |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | {sync notify   |
|   |                |                |                | 'loss of frame |
|   |                |                |                | sync'}         |
|   |                |                |                |                |
|   |                |                |                | ELSE {sync     |
|   |                |                |                | notify 'loss   |
|   |                |                |                | of frame       |
|   |                |                |                |                |
|   |                |                |                | sync'}         |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | ELSE IF        |
|   |                |                |                | "buffer empty" |
|   |                |                |                |                |
|   |                |                |                | THEN {sync     |
|   |                |                |                | notify 'loss   |
|   |                |                |                | of frame\      |
|   |                |                |                | sync'} à 3     |
|   |                |                |                |                |
|   |                |                |                | {start release |
|   |                |                |                | timer}         |
|   |                |                |                |                |
|   |                |                |                | ELSE (sync     |
|   |                |                |                | notify 'loss   |
|   |                |                |                | of frame\      |
|   |                |                |                | sync'} à 3     |
+---+----------------+----------------+----------------+----------------+
| 1 | 'loss of frame | Not applicable | \[ignore\] à 2 | IF "buffer     |
| 7 | sync           |                |                | full"          |
|   | hronization',\ |                |                |                |
|   | "complete      |                |                | THEN submit    |
|   | online"        |                |                | buffer         |
|   | delivery mode  |                |                | contents UNTIL |
|   |                |                |                |                |
|   |                |                |                | (NOT           |
|   |                |                |                | "congested") à |
|   |                |                |                | 3              |
|   |                |                |                |                |
|   |                |                |                | reinitialize   |
|   |                |                |                | transfer       |
|   |                |                |                | buffer         |
|   |                |                |                |                |
|   |                |                |                | {sync notify   |
|   |                |                |                | 'loss of frame |
|   |                |                |                | sync'}         |
|   |                |                |                |                |
|   |                |                |                | ELSE {sync     |
|   |                |                |                | notify 'loss   |
|   |                |                |                | of frame       |
|   |                |                |                | sync'} à 3     |
+---+----------------+----------------+----------------+----------------+
| 1 | 'production    | Not applicable | IF NOT "unbind | {sync notify   |
| 8 | status         |                | pending")      | production     |
|   | change',\      |                |                | status         |
|   | "timely        |                | THEN {sync     | change'} à 3   |
|   | online"        |                | notify         |                |
|   | delivery mode  |                | 'production\   |                |
|   | or\            |                | status         |                |
|   | "complete      |                | change'} à 2   |                |
|   | online"        |                |                |                |
|   | delivery mode  |                | ELSE           |                |
|   |                |                | \[ignore\] à 2 |                |
+---+----------------+----------------+----------------+----------------+
| 1 | (rafSch        | \[ignore\]     | IF "positive   | IF "positive   |
| 9 | eduleStatusRep |                | result"        | result"        |
|   | ortInvocation) |                |                |                |
|   |                |                | THEN           | THEN           |
|   |                |                | (+rafSchedul   | (+rafSchedul   |
|   |                |                | eStatusReport) | eStatusReport) |
|   |                |                | à 2            | à 3            |
|   |                |                |                |                |
|   |                |                | IF             | IF             |
|   |                |                | "immediately"  | "immediately"  |
|   |                |                |                |                |
|   |                |                | THEN           | THEN           |
|   |                |                | {immediate     | {immediate     |
|   |                |                | report}        | report}        |
|   |                |                |                |                |
|   |                |                | ELSE IF        | ELSE IF        |
|   |                |                | "periodically" | "periodically" |
|   |                |                |                |                |
|   |                |                | THEN {periodic | THEN {periodic |
|   |                |                | report}        | report}        |
|   |                |                |                |                |
|   |                |                | ELSE stop      | ELSE stop      |
|   |                |                | r              | r              |
|   |                |                | eporting-cycle | eporting-cycle |
|   |                |                | timer          | timer          |
|   |                |                |                |                |
|   |                |                | ELSE à 2       | ELSE à 3       |
|   |                |                |                |                |
|   |                |                | (-ra           | (-ra           |
|   |                |                | fScheduleStatu | fScheduleStatu |
|   |                |                | sReportReturn) | sReportReturn) |
+---+----------------+----------------+----------------+----------------+
| 2 | 'r             | Not applicable | {periodic      | {periodic      |
| 0 | eporting-cycle |                | report} à 2    | report} à 3    |
|   | timer expired' |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 2 | (rafGetParame  | \[ignore\]     | IF "positive   | IF "positive   |
| 1 | terInvocation) |                | result"        | result"        |
|   |                |                |                |                |
|   |                |                | THEN           | THEN           |
|   |                |                | (+rafGetPa     | (+rafGetPa     |
|   |                |                | rameterReturn) | rameterReturn) |
|   |                |                | à 2            | à 3            |
|   |                |                |                |                |
|   |                |                | ELSE           | ELSE           |
|   |                |                | (-rafGetPa     | (-rafGetPa     |
|   |                |                | rameterReturn) | rameterReturn) |
|   |                |                | à 2            | à 3            |
+---+----------------+----------------+----------------+----------------+
| 2 | (rafPeerAb     | \[ignore\]     | {clean up} à 1 | {clean up} à 1 |
| 2 | ortInvocation) |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 2 | 'invalid       | \[ignore\]     | {peer abort    | {peer abort    |
| 3 | SLE-PDU'       |                | ('encoding     | ('encoding     |
|   |                |                | error')} à 1   | error')} à 1   |
+---+----------------+----------------+----------------+----------------+
| 2 | 'return        | \[ignore\]     | {peer abort    | {peer abort    |
| 4 | SLE-PDU with   |                | ('unsolicited  | ('unsolicited  |
|   | unsolicited    |                | Invoke-ID')} à | Invoke-ID')} à |
|   | Invoke-ID'     |                | 1              | 1              |
+---+----------------+----------------+----------------+----------------+
| 2 | 'protocol      | \[ignore\]     | {clean up} à 1 | {clean up} à 1 |
| 5 | abort'         |                |                |                |
+---+----------------+----------------+----------------+----------------+
| 2 | 'not           | \[ignore\] à 1 | \[ignore\] à 2 | \[ignore\] à 3 |
| 6 | authenticated  |                |                |                |
|   | SLE-PDU'       |                |                |                |
+---+----------------+----------------+----------------+----------------+

Table 4‑2: Event Description References

  --------------------------------------------------- -------------------
  **Event**                                           **Reference**

  'data available'                                    3.4.1.3

  'end of data'                                       3.7.2.3

  'end of service instance provision period'          3.11.2.2

  'invalid SLE-PDU'                                   4.1.2

  'loss of frame synchronization'                     3.7.2.3

  'not authenticated SLE-PDU'                         4.1.7

  'production status change'                          3.7.2.3

  'release timer expired'                             3.1.8.1.1

  'reporting-cycle timer expired'                     3.8.2.6

  'return SLE-PDU with unsolicited Invoke-ID'         4.1.4

  'return \<n\> timer expired'                        4.1.3

  'start of service instance provision period'        3.2.1.2
  --------------------------------------------------- -------------------

Table 4‑3: Predicate Descriptions

  ------------------------------------------------------------------------
  **Predicate**    **Evaluates to TRUE if**
  ---------------- -------------------------------------------------------
  "buffer empty"   There are no RAF SLE-PDUs in the transfer buffer

  "buffer full"    The transfer buffer cannot accommodate the currently
                   available annotated frame or synchronous notification

  "compatible"     The version number contained in (+rafBindReturn) is
                   supported by the provider

  "complete        Delivery mode is complete online
  online"          

  "congested"      The underlying communications service cannot accept the
                   contents of the transfer buffer because of congestion

  "done"           The unbind-reason parameter value in the
                   provider-initiated BIND invocation was 'end'

  "end"            All checks on the UNBIND invocation are passed and the
                   unbind-reason parameter value is 'end'

  "immediately"    All parameter checks on the RAF-SCHEDULE-STATUS-REPORT
                   are passed and the report-request-type value is
                   'immediately'

  "offline"        Delivery mode is offline

  "online"         Delivery mode is timely online or complete online

  "periodically"   All parameter checks on the RAF-SCHEDULE-STATUS-REPORT
                   are passed and the report-request-type value is
                   'periodically'

  "positive        All checks on the invocation are passed
  result"          

  "provider        The RAF-BIND operation is specified to be initiated by
  initiated"       the provider for this service instance

  "retry           The diagnostic value contained in the (-rafBindReturn)
  permitted"       is 'unable to comply' or 'other', and the service
                   instance provision period is still active

  "timely online"  Delivery mode is timely online
  ------------------------------------------------------------------------

Table 4‑4: Boolean Flags

  -----------------------------------------------------------------------
  **Flag Name**                       **Initial Value**
  ----------------------------------- -----------------------------------
  "bind pending"                      FALSE

  "unbind pending"                    FALSE
  -----------------------------------------------------------------------

Table 4‑5: Compound Action Definitions

+--------------------+-------------------------------------------------+
| **Name**           | **Actions Performed**                           |
+====================+=================================================+
| {clean up}         | stop release timer                              |
|                    |                                                 |
|                    | stop all return timers                          |
|                    |                                                 |
|                    | stop reporting-cycle timer                      |
|                    |                                                 |
|                    | reinitialize transfer buffer                    |
|                    |                                                 |
|                    | reset parameter values to those specified in    |
|                    | service package                                 |
+--------------------+-------------------------------------------------+
| {immediate report} | (rafStatusReportInvocation)                     |
|                    |                                                 |
|                    | stop reporting-cycle timer                      |
+--------------------+-------------------------------------------------+
| {insert annotated  | annotate the available frame with the           |
| frame}             | parameters of the RAF- TRANSFER-DATA operation  |
|                    |                                                 |
|                    | insert the annotated frame into the transfer    |
|                    | buffer                                          |
+--------------------+-------------------------------------------------+
| {invoke bind}      | (rafBindInvocation)                             |
|                    |                                                 |
|                    | set "bind pending" to TRUE                      |
|                    |                                                 |
|                    | start return \<n\> timer                        |
+--------------------+-------------------------------------------------+
| {invoke unbind}    | (rafUnbindInvocation)                           |
|                    |                                                 |
|                    | stop reporting-cycle timer                      |
|                    |                                                 |
|                    | set "unbind pending" to TRUE                    |
|                    |                                                 |
|                    | start return \<n\> timer                        |
+--------------------+-------------------------------------------------+
| {pass buffer       | stop release timer                              |
| contents}          |                                                 |
|                    | submit contents of transfer buffer to           |
|                    | underlying communications service               |
|                    |                                                 |
|                    | reinitialize transfer buffer                    |
+--------------------+-------------------------------------------------+
| {peer abort        | stop release timer                              |
| 'xxxx'}            |                                                 |
|                    | stop all return timers                          |
|                    |                                                 |
|                    | stop reporting-cycle timer                      |
|                    |                                                 |
|                    | reinitialize transfer buffer                    |
|                    |                                                 |
|                    | (rafPeerAbortInvocation) with diagnostic set to |
|                    | 'xxxx'                                          |
+--------------------+-------------------------------------------------+
| {periodic report}  | (rafStatusReportInvocation)                     |
|                    |                                                 |
|                    | set reporting-cycle timer to the                |
|                    | reporting-cycle value in the most recent        |
|                    | SCHEDULE-STATUS-REPORT invocation               |
|                    |                                                 |
|                    | start reporting-cycle timer                     |
+--------------------+-------------------------------------------------+
| {provider unbind}  | set "unbind pending" to FALSE                   |
|                    |                                                 |
|                    | stop all return timers                          |
+--------------------+-------------------------------------------------+
| {return timeout}   | (rafPeerAbortInvocation) with diagnostic        |
|                    | 'return timeout'                                |
|                    |                                                 |
|                    | set "bind pending" to FALSE                     |
|                    |                                                 |
|                    | set "unbind pending" to FALSE                   |
+--------------------+-------------------------------------------------+
| {start release     | set release timer to latency limit              |
| timer}             |                                                 |
|                    | start release timer                             |
+--------------------+-------------------------------------------------+
| {sync notify       | create an RAF synchronous notification with     |
| 'xxxx'}            | diagnostic set to 'xxxx'                        |
|                    |                                                 |
|                    | insert the notification into the transfer       |
|                    | buffer                                          |
+--------------------+-------------------------------------------------+
| {user unbind}      | stop reporting-cycle timer                      |
|                    |                                                 |
|                    | stop all return timers                          |
|                    |                                                 |
|                    | (rafUnbindReturn)                               |
+--------------------+-------------------------------------------------+

########   Data Type Definitions

(This annex **is** part of the Recommendation)

######## Introduction {#introduction-2 .Annex-2}

1.  This annex defines the data types that are used by the RAF service.
    It is intended to provide a clear specification of these data types
    and to avoid ambiguity. It is not intended to constrain how these
    data types are implemented or encoded. These definitions are
    suitable for inclusion in any type of ASN.1 based protocol that
    implements the RAF service.

2.  The data type definitions are presented in six ASN.1 modules.

3.  Subsection A2.1 contains basic types that are common with other SLE
    Transfer Services. As more services become specified by CCSDS,
    further types may be added to this module or existing types may be
    extended. However, that eventuality is not expected to invalidate
    the module in its present form because it is expected that an
    implementation compliant with a future extended version of this
    module will be interoperable with an implementation based on its
    present version.

4.  Subsection A2.2 specifies the SLE-PDUs exchanged between an SLE user
    and an SLE provider application in order to establish, release or
    abort an association. They are common among SLE transfer service
    types.

5.  Subsection A2.3 specifies SLE-PDUs related to invocations and
    returns that are common to SLE transfer service types.

6.  Subsection A2.4 specifies data types specific to the RAF service. In
    part, these specific types are derived from types specified in A2.1
    by means of subtyping.

7.  Subsection A2.5 specifies all incoming (from a provider point of
    view) SLE-PDUs. Where applicable, these SLE-PDUs are mapped to the
    generic SLE-PDUs defined in A2.2 and A2.3.

8.  Subsection A2.6 specifies in the same way the outgoing SLE-PDUs.

9.  Although subsections A2.2, A2.3, A2.5 and A2.6 define the SLE-PDUs
    that will be exchanged between the SLE provider and user
    applications, they shall not be interpreted as requiring that these
    SLE-PDUs shall be completely mapped to the user data field of the
    underlying communications protocol. For example, depending on the
    communications protocol(s) used, part of the SLE-PDUs may be used to
    determine the appropriate setting of protocol control information.

######## RAF Data Type Specification {#raf-data-type-specification .Annex-2}

1.  SLE TRANSFER SERVICE---COMMON TYPES

CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-common-types(1)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

EXPORTS ConditionalTime

, Credentials

, DeliveryMode

, Diagnostics

, Duration

, ForwardDuStatus

, IntPosLong

, IntPosShort

, IntUnsignedLong

, IntUnsignedShort

, InvokeId

, ParameterName

, SlduStatusNotification

, SpaceLinkDataUnit

, Time

;

ConditionalTime ::= CHOICE

{ undefined \[0\] NULL

, known \[1\] Time

}

\-- If credentials are used, it will be necessary that

\-- the internal structure of the octet string is known

\-- to both parties. Since the structure will depend on

\-- algorithm used, it is not specified here. However,

\-- the peer entities may use ASN.1 encoding to make the

\-- internal structure visible.

Credentials ::= CHOICE

{ unused \[0\] NULL

, used \[1\] OCTET STRING (SIZE (8 .. 256))

}

DeliveryMode ::= INTEGER

{ rtnTimelyOnline (0)

, rtnCompleteOnline (1)

, rtnOffline (2)

, fwdOnline (3)

, fwdOffline (4)

}

Diagnostics ::= INTEGER

{ duplicateInvokeId (100)

, otherReason (127)

}

\-- The Duration is expressed in microseconds

Duration ::= IntUnsignedLong

ForwardDuStatus ::= INTEGER

{ radiated (0)

, expired (1)

, interrupted (2)

, acknowledged (3) \-- FSP

, productionStarted (4) \-- CLTU: \`radiation started'

, undefined (5) \-- CLTU

, unsupportedTransmissionMode (6) \-- FSP

}

\-- 1 to (2\^32)-1

IntPosLong ::= INTEGER (1 .. 4294967295)

\-- 1 to (2\^16)-1

IntPosShort ::= INTEGER (1 .. 65535)

\-- 0 to (2\^32)-1

IntUnsignedLong ::= INTEGER (0 .. 4294967295)

\-- 0 to (2\^16)-1

IntUnsignedShort ::= INTEGER (0 .. 65535)

InvokeId ::= IntUnsignedShort

ParameterName ::= INTEGER

{ aggregationTimeoutPeriod (0)

, aggregationUsage (1)

, apidList (2)

, bitLockRequired (3)

, bufferSize (4)

, deliveryMode (6)

, directiveInvocation (7)

, expectedDirectiveIdentification (8)

, expectedEventInvocationIdentification (9)

, expectedSlduIdentification (10)

, fopSlidingWindow (11)

, fopState (12)

, idlePattern (13)

, latencyLimit (15)

, mapList (16)

, mapMuxControl (17)

, mapMuxScheme (18)

, maximumFrameLength (19)

, maximumPacketLength (20)

, maximumSlduLength (21)

, modulationFrequency (22)

, modulationIndex (23)

, permittedGvcidSet (24)

, plopInEffect (25)

, reportingCycle (26)

, requestedFrameQuality (27)

, requestedGvcid (28)

, returnTimeoutPeriod (29)

, rfAvailable (30)

, rfAvailableRequired (31)

, segmentHeader (32)

, subcarrierToBitRateRatio (34)

, timeoutType (35)

, timerInitial (36)

, transmissionLimit (37)

, transmitterFrameSequenceNumber (38)

, vcMuxControl (39)

, vcMuxScheme (40)

, virtualChannel (41)

}

SlduStatusNotification ::= INTEGER

{ produceNotification (0)

, doNotProduceNotification (1)

}

SpaceLinkDataUnit ::= OCTET STRING (SIZE (7 .. 65536))

Time ::= CHOICE

{ ccsdsFormat \[0\] TimeCCSDS

}

TimeCCSDS ::= OCTET STRING (SIZE(8))

\-- P-field is implicit (not present, defaulted to 41 hex)

\-- T-field:

\-- 2 octets: number of days since 1958-01-01

\-- 4 octets: number of milliseconds of the day

\-- 2 octets: number of microseconds of the millisecond

\-- (must be set to 0 if not used)

\-- This definition conforms to the CCSDS Day Segmented Time Code

\-- (see CCSDS Recommendation 301.0-B-2)

END

2.  SLE TRANSFER SERVICE---BIND TYPES

CCSDS-SLE-TRANSFER-SERVICE-BIND-TYPES

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-bind-types(2)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

EXPORTS SleBindInvocation

, SleBindReturn

, SlePeerAbort

, SleUnbindInvocation

, SleUnbindReturn

;

IMPORTS Credentials

, IntPosShort

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

;

\-- =============================================================

\-- The first part of the module definition contains the SLE-PDUs

\-- =============================================================

SleBindInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, initiatorIdentifier AuthorityIdentifier

, responderPortIdentifier PortId

, serviceType ApplicationIdentifier

, versionNumber VersionNumber

, serviceInstanceIdentifier ServiceInstanceIdentifier

}

SleBindReturn ::= SEQUENCE

{ performerCredentials Credentials

, responderIdentifier AuthorityIdentifier

, result CHOICE

{ positive \[0\] VersionNumber

, negative \[1\] BindDiagnostic

}

}

SlePeerAbort ::= PeerAbortDiagnostic

SleUnbindInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, unbindReason UnbindReason

}

SleUnbindReturn ::= SEQUENCE

{ responderCredentials Credentials

, result CHOICE

{ positive \[0\] NULL

}

}

\-- =============================================================

\-- The second part of the module definition contains the types

\-- used by the SLE-PDUs declared in the first part.

\-- =============================================================

ApplicationIdentifier ::= INTEGER

{ rtnAllFrames (0)

, rtnInsert (1)

, rtnChFrames (2)

\-- rtnChFrames includes rtnMcFrames and rtnVcFrames

, rtnChFsh (3)

\-- rtnChFsh includes rtnMcFsh and rtnVcFsh

, rtnChOcf (4)

\-- rtnChOcf includes rtnMcOcf and rtnVcOcf

, rtnBitstr (5) \-- AOS

, rtnSpacePkt (6)

, fwdAosSpacePkt (7)

, fwdAosVca (8)

, fwdBitstr (9)

, fwdProtoVcdu (10)

, fwdInsert (11)

, fwdCVcdu (12)

, fwdTcSpacePkt (13) \-- conventional

\-- telecommand

, fwdTcVca (14) \-- conventional

\-- telecommand

, fwdTcFrame (15)

, fwdCltu (16)

}

ATTRIBUTE ::= CLASS

{ &attributeId OBJECT IDENTIFIER UNIQUE

, &AttributeType

}

AttributeTypeAndValue ::= SEQUENCE

{ attributeIdentifier ATTRIBUTE.&attributeId

({ServManagementAttributeSet})

, attributeValue ATTRIBUTE.&AttributeType

({ServManagementAttributeSet}

{@attributeIdentifier})

}

AuthorityIdentifier ::= IdentifierString (SIZE (3 .. 16))

BindDiagnostic ::= INTEGER

{ accessDenied (0)

, serviceTypeNotSupported (1)

, versionNotSupported (2)

, noSuchServiceInstance (3)

, alreadyBound (4)

, siNotAccessibleToThisInitiator (5)

, inconsistentServiceType (6)

, invalidTime (7)

, outOfService (8)

, otherReason (127)

}

IdentifierString ::= VisibleString (FROM (ALL EXCEPT \" \"))

LogicalPortName ::= IdentifierString (SIZE (1 .. 128))

PeerAbortDiagnostic ::= INTEGER

{ accessDenied (0)

, unexpectedResponderId (1)

, operationalRequirement (2)

, protocolError (3)

, communicationsFailure (4)

, encodingError (5)

, returnTimeout (6)

, endOfServiceProvisionPeriod (7)

, unsolicitedInvokeId (8)

, otherReason (127)

\-- The range of this INTEGER shall be (0 .. 255).

\-- (128 .. 255) is reserved for diagnostic codes

\-- that are specific to the communications technology used.

}

PortId ::= LogicalPortName

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET SIZE (1) OF AttributeTypeAndValue

ServiceInstanceIdentifier ::= RDNSequence

ServManagementAttributeSet ATTRIBUTE ::= {\...}

\-- For a real implementation, the above type definition must

\-- be replaced by importing the corresponding information object set

\-- specification from the applicable service management specification.

\-- It is assumed that all attributes are of the type IdentifierString.

UnbindReason ::= INTEGER

{ end (0)

, suspend (1)

, versionNotSupported (2)

, other (127)

}

VersionNumber ::= IntPosShort

END

3.  SLE TRANSFER SERVICE---COMMON PDUs

CCSDS-SLE-TRANSFER-SERVICE-COMMON-PDUS

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-common-pdu(3)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

EXPORTS ReportingCycle

, SleAcknowledgement

, SleScheduleStatusReportInvocation

, SleScheduleStatusReportReturn

, SleStopInvocation

;

IMPORTS Credentials

, Diagnostics

, InvokeId

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

;

\-- =============================================================

\-- The first part of the module definition contains the SLE-PDUs

\-- =============================================================

SleAcknowledgement ::= SEQUENCE

{ credentials Credentials

, invokeId InvokeId

, result CHOICE

{ positiveResult \[0\] NULL

, negativeResult \[1\] Diagnostics

}

}

SleScheduleStatusReportInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, invokeId InvokeId

, reportRequestType ReportRequestType

}

SleScheduleStatusReportReturn ::= SEQUENCE

{ performerCredentials Credentials

, invokeId InvokeId

, result CHOICE

{ positiveResult \[0\] NULL

, negativeResult \[1\] DiagnosticScheduleStatusReport

}

}

SleStopInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, invokeId InvokeId

}

\-- =============================================================

\-- The second part of the module definition contains the types

\-- used by the SLE-PDUs declared in the first part.

\-- =============================================================

DiagnosticScheduleStatusReport ::= CHOICE

{ common \[0\] Diagnostics

, specific \[1\] INTEGER

{ notSupportedInThisDeliveryMode (0)

, alreadyStopped (1)

, invalidReportingCycle (2)

}

}

\-- The cycle duration is expressed in seconds

ReportingCycle ::= INTEGER (2 .. 600)

ReportRequestType ::= CHOICE

{ immediately \[0\] NULL

, periodically \[1\] ReportingCycle

, stop \[2\] NULL

}

END

4.  SLE TRANSFER SERVICE---RAF STRUCTURES

CCSDS-SLE-TRANSFER-SERVICE-RAF-STRUCTURES

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-raf-structures(4)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

EXPORTS AntennaId

, DiagnosticRafGet

, DiagnosticRafStart

, FrameQuality

, LockStatus

, Notification

, RafGetParameter

, RafProductionStatus

, RafParameterName

, RequestedFrameQuality

;

IMPORTS DeliveryMode

, Diagnostics

, IntPosShort

, IntPosLong

, ParameterName

, Time

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

ReportingCycle

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-PDUS

;

AntennaId ::= CHOICE

{ globalForm \[0\] OBJECT IDENTIFIER

, localForm \[1\] OCTET STRING (SIZE (1 .. 16))

}

CurrentReportingCycle ::= CHOICE

{ periodicReportingOff \[0\] NULL

, periodicReportingOn \[1\] ReportingCycle

}

DiagnosticRafGet ::= CHOICE

{ common \[0\] Diagnostics

, specific \[1\] INTEGER

{ unknownParameter (0)

}

}

DiagnosticRafStart ::= CHOICE

{ common \[0\] Diagnostics

, specific \[1\] INTEGER

{ outOfService (0)

, unableToComply (1)

, invalidStartTime (2)

, invalidStopTime (3)

, missingTimeValue (4)

}

}

FrameQuality ::= INTEGER

{ good (0)

, erred (1)

}

LockStatus ::= INTEGER

{ inLock (0)

, outOfLock (1)

, notInUse (2)

, unknown (3)

}

LockStatusReport ::= SEQUENCE

{ time Time

, carrierLockStatus LockStatus

, subcarrierLockStatus LockStatus

, symbolSyncLockStatus LockStatus

}

Notification ::= CHOICE

{ lossFrameSync \[0\] LockStatusReport

, productionStatusChange \[1\] RafProductionStatus

, excessiveDataBacklog \[2\] NULL

, endOfData \[3\] NULL

}

RafGetParameter ::= CHOICE

{ parBufferSize \[0\] SEQUENCE

{ parameterName ParameterName (bufferSize)

, parameterValue IntPosShort

\-- bufferSize in number of invocations

\-- that can be held in buffer

}

, parDeliveryMode \[1\] SEQUENCE

{ parameterName ParameterName (deliveryMode)

, parameterValue RafDeliveryMode

}

, parLatencyLimit \[2\] SEQUENCE

{ parameterName ParameterName (latencyLimit)

, parameterValue CHOICE

{ timelyOnline \[0\] IntPosShort

\-- latencyLimit in seconds

, notTimelyOnline \[1\] NULL

}

}

, parReportingCycle \[3\] SEQUENCE

{ parameterName ParameterName (reportingCycle)

, parameterValue CurrentReportingCycle

}

, parReqFrameQuality \[4\] SEQUENCE

{ parameterName ParameterName (requestedFrameQuality)

, parameterValue INTEGER

{ goodFramesOnly (0)

, erredFrameOnly (1)

, allFrames (2)

, undefined (3)

}

}

, parReturnTimeout \[5\] SEQUENCE

{ parameterName ParameterName (returnTimeoutPeriod)

, parameterValue TimeoutPeriod

}

}

RafDeliveryMode ::= DeliveryMode

( rtnTimelyOnline

\| rtnCompleteOnline

\| rtnOffline

)

RafParameterName ::= ParameterName

( bufferSize

\| deliveryMode

\| latencyLimit

\| reportingCycle

\| requestedFrameQuality

\| returnTimeoutPeriod

)

RafProductionStatus ::= INTEGER

{ running (0)

, interrupted (1)

, halted (2)

}

RequestedFrameQuality ::= INTEGER

{ goodFramesOnly (0)

, erredFrameOnly (1)

, allFrames (2)

}

TimeoutPeriod ::= INTEGER (1 .. 600)

\-- measured in seconds

END

5.  SLE TRANSFER SERVICE---RAF INCOMING PDUs

CCSDS-SLE-TRANSFER-SERVICE-RAF-INCOMING-PDUS

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-raf-incoming-pdu(5)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

IMPORTS ConditionalTime

, Credentials

, InvokeId

, ParameterName

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

SleScheduleStatusReportInvocation

, SleStopInvocation

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-PDUS

RafParameterName

, RequestedFrameQuality

FROM CCSDS-SLE-TRANSFER-SERVICE-RAF-STRUCTURES

SleBindInvocation

, SleBindReturn

, SlePeerAbort

, SleUnbindInvocation

, SleUnbindReturn

FROM CCSDS-SLE-TRANSFER-SERVICE-BIND-TYPES

;

\-- =============================================================

\-- The first part of the module definition contains the RAF type

\-- that contains all the possible PDUs the provider may receive.

\-- =============================================================

RafUsertoProviderPdu ::= CHOICE

{ rafBindInvocation \[100\] SleBindInvocation

, rafBindReturn \[101\] SleBindReturn

, rafUnbindInvocation \[102\] SleUnbindInvocation

, rafUnbindReturn \[103\] SleUnbindReturn

, rafStartInvocation \[0\] RafStartInvocation

, rafStopInvocation \[1\] SleStopInvocation

, rafScheduleStatusReportInvocation \[2\]
SleScheduleStatusReportInvocation

, rafGetParameterInvocation \[3\] RafGetParameterInvocation

, rafPeerAbortInvocation \[104\] SlePeerAbort

}

\-- =============================================================

\-- The second part of the module definition contains the types

\-- used by the RAF-PDUs declared in the first part.

\-- =============================================================

RafGetParameterInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, invokeId InvokeId

, rafParameter RafParameterName

}

RafStartInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, invokeId InvokeId

, startTime ConditionalTime

, stopTime ConditionalTime

, requestedFrameQuality RequestedFrameQuality

}

END

6.  SLE TRANSFER SERVICE---RAF OUTGOING PDUs

CCSDS-SLE-TRANSFER-SERVICE-RAF-OUTGOING-PDUS

{iso org(3) standards-producing-organization{112) ccsds(4)

space-link-extension(3) sle-transfer-services(1)

return-all-frames-service(1) version-one(1) asn1-outgoing-pdu(6)}

DEFINITIONS

IMPLICIT TAGS

::= BEGIN

IMPORTS Credentials

, IntUnsignedLong

, InvokeId

, SpaceLinkDataUnit

, Time

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-TYPES

SleAcknowledgement

, SleScheduleStatusReportReturn

FROM CCSDS-SLE-TRANSFER-SERVICE-COMMON-PDUS

AntennaId

, DiagnosticRafGet

, DiagnosticRafStart

, FrameQuality

, LockStatus

, Notification

, RafGetParameter

, RafProductionStatus

FROM CCSDS-SLE-TRANSFER-SERVICE-RAF-STRUCTURES

SleBindInvocation

, SleBindReturn

, SlePeerAbort

, SleUnbindInvocation

, SleUnbindReturn

FROM CCSDS-SLE-TRANSFER-SERVICE-BIND-TYPES

;

\-- =============================================================

\-- The first part of the module definition contains the RAF type

\-- that contains all the possible PDUs the provider may send.

\-- =============================================================

RafProviderToUserPdu ::= CHOICE

{ rafBindInvocation \[100\] SleBindInvocation

, rafBindReturn \[101\] SleBindReturn

, rafUnbindInvocation \[102\] SleUnbindInvocation

, rafUnbindReturn \[103\] SleUnbindReturn

, rafStartReturn \[0\] RafStartReturn

, rafStopReturn \[1\] SleAcknowledgement

, rafTransferBuffer \[2\] RafTransferBuffer

, rafScheduleStatusReportReturn \[3\] SleScheduleStatusReportReturn

, rafStatusReportInvocation \[4\] RafStatusReportInvocation

, rafGetParameterReturn \[5\] RafGetParameterReturn

, rafPeerAbortInvocation \[104\] SlePeerAbort

}

\-- =============================================================

\-- The second part of the module definition contains the types

\-- used by the RAF-PDUs declared in the first part.

\-- =============================================================

FrameOrNotification ::= CHOICE

{ annotatedFrame \[0\] RafTransferDataInvocation

, syncNotification \[1\] RafSyncNotifyInvocation

}

RafGetParameterReturn ::= SEQUENCE

{ performerCredentials Credentials

, invokeId InvokeId

, result CHOICE

{ positiveResult \[0\] RafGetParameter

, negativeResult \[1\] DiagnosticRafGet

}

}

RafStartReturn ::= SEQUENCE

{ performerCredentials Credentials

, invokeId InvokeId

, result CHOICE

{ positiveResult \[0\] NULL

, negativeResult \[1\] DiagnosticRafStart

}

}

RafStatusReportInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, errorFreeFrameNumber IntUnsignedLong

, deliveredFrameNumber IntUnsignedLong

, frameSyncLockStatus LockStatus

, symbolSyncLockStatus LockStatus

, subcarrierLockStatus LockStatus

, carrierLockStatus LockStatus

, productionStatus RafProductionStatus

}

RafTransferBuffer ::= SEQUENCE OF FrameOrNotification

RafSyncNotifyInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, notification Notification

}

RafTransferDataInvocation ::= SEQUENCE

{ invokerCredentials Credentials

, earthReceiveTime Time

, antennaId AntennaId

, dataLinkContinuity INTEGER (-1 .. 65535)

, deliveredFrameQuality FrameQuality

, privateAnnotation CHOICE

{ null \[0\] NULL

, notNull \[1\] OCTET STRING (SIZE (1 .. 128))

}

, data SpaceLinkDataUnit

}

END

########   Index to Definitions

(This annex **is not** part of the Recommendation)

This annex lists terms used in this Recommendation and, for each term,
provides a reference to the definition of that term.

  -----------------------------------------------------------------------
  **Term**                                        **Reference**
  ----------------------------------------------- -----------------------
  (data) type                                     reference \[7\]

  (data) value                                    reference \[7\]

  abstract binding                                reference \[1\]

  abstract object                                 reference \[1\]

  abstract port                                   reference \[1\]

  abstract service                                reference \[1\]

  abstract syntax                                 reference \[6\]

  Abstract Syntax Notation One (ASN.1)            reference \[7\]

  active (state)                                  2.6.4.2

  application entity                              reference \[6\]

  application layer                               reference \[6\]

  association                                     1.6.1.8.1

  attached sync marker                            reference \[2\]

  codeblock                                       reference \[2\]

  coded virtual channel data unit (CVCDU)         reference \[4\]

  communications service                          1.6.1.8.2

  complete (online delivery mode)                 2.3, 3.1.8.2

  concatenation                                   reference \[6\]

  confirmed operation                             1.6.1.8.3

  convolutional code                              reference \[2\]

  cyclic redundancy check (CRC)                   reference \[4\]

  delivery criteria                               1.6.1.8.4

  distinguished name (DN)                         reference \[8\]

  error control field                             1.6.1.8.5

  flow control                                    reference \[6\]

  frame error control field                       reference \[3\]

  initiator                                       1.6.1.8.6

  invocation                                      1.6.1.8.6

  invoker                                         reference \[1\]

  latency limit                                   2.6.4.6.2, 3.1.8.1

  Mission Data Operation System (MDOS)            reference \[1\]

  Mission User Entity (MUE)                       reference \[1\]

  object identifier                               reference \[7\]

  offline delivery mode                           reference \[1\]

  offline frame buffer                            2.6.4.6.3, 3.1.8.3

  online delivery mode                            reference \[1\]

  online frame buffer                             2.6.4.6.3, 3.1.8.2

  Open Systems Interconnection (OSI)              reference \[6\]

  operation                                       reference \[1\]

  parameter                                       1.6.1.8.8

  performance                                     1.6.1.8.9

  performer                                       reference \[1\]

  physical channel                                reference \[1\]

  port identifier                                 1.6.1.8.10

  provider-initiated                              2.3, 3.2.1

  pseudo-randomization                            reference \[2\]

  ready (state)                                   2.6.4.2

  real system                                     reference \[6\]

  Reed-Solomon check symbols                      reference \[2\]

  Reed-Solomon code                               reference \[2\]

  relative distinguished name (RDN)               reference \[8\]

  release timer                                   2.6.4.6.2, 3.1.8.1

  responder                                       1.6.1.8.11

  return (of an operation)                        subsection 1.6.1.8.11

  Return All Frames channel                       reference \[1\]

  Return All Frames service                       reference \[1\]

  return data                                     reference \[1\]

  service access point (SAP)                      reference \[6\]

  service agreement                               reference \[1\]

  service instance provision period               subsection 1.6.1.8.13

  service provider (provider)                     reference \[1\]

  service user (user)                             reference \[1\]

  SLE Complex                                     reference \[1\]

  SLE Complex Management                          reference \[1\]

  SLE data channel                                reference \[1\]

  SLE functional group (SLE-FG)                   reference \[1\]

  SLE protocol data unit (SLE-PDU)                reference \[1\]

  SLE service data unit (SLE-SDU)                 reference \[1\]

  SLE service package                             reference \[1\]

  SLE System                                      reference \[1\]

  SLE transfer service instance                   reference \[1\]

  SLE transfer service production                 reference \[1\]

  SLE transfer service provision                  reference \[1\]

  SLE Utilization Management                      reference \[1\]

  space link                                      reference \[1\]

  space link data channel                         reference \[1\]

  space link data unit (SL-DU)                    reference \[1\]

  space link session                              reference \[1\]

  telemetry frame                                 subsection 1.6.1.8.14

  timely (online delivery mode)                   subsections 2.3,
                                                  3.1.8.1

  transfer buffer                                 subsections 2.6.4.6.2,
                                                  3.1.8

  transfer frame                                  reference \[3\]

  unbound (state)                                 subsection 2.6.4.2

  unconfirmed operation                           subsection 1.6.1.8.15

  user-initiated                                  subsection 2.3, 3.2.1

  VCDU error control field                        reference \[4\]

  virtual channel data unit (VCDU)                reference \[4\]
  -----------------------------------------------------------------------

########   Acronyms

(This annex **is not** part of the Recommendation)

This annex lists the acronyms used in this Recommendation.

  ----------------- -----------------------------------------------------
  ASDC              Abstract Service Definition Conventions

  ASN.1             Abstract Syntax Notation One

  C                 Conditional

  CCSDS             Consultative Committee for Space Data Systems

  CDS               CCSDS Day Segmented (time code)

  CM-P              Complex Management Port

  CRC               Cyclic Redundant Code

  CVCDU             Coded Virtual Channel Data Unit

  ERT               Earth Receive Time

  FG                Functional Group

  IEC               International Electrotechnical Commission

  IP                Internet Protocol

  ISO               International Organization for Standardization

  M                 Mandatory

  MDOS              Mission Data Operation System

  MUE               Mission User Entity

  OSI               Open Systems Interconnection

  PDU               Protocol Data Unit

  RAF               Return All Frames

  RF                Radio Frequency

  SAP               Service Access Point

  SDU               Service Data Unit

  SL-DU             Space Link Data Unit

  SLE               Space Link Extension

  SLE-FG            SLE Functional Group

  SLE-PDU           SLE Protocol Data Unit

  SLE-SDU           SLE Service Data Unit

  SL-DU             Space Link Data Unit

  TCP               Transmission Control Protocol

  T-P               Transfer Provider Port

  T-U               Transfer User Port

  UTC               Coordinated Universal Time

  VC                Virtual Channel

  VCDU              Virtual Channel Data Unit
  ----------------- -----------------------------------------------------

########   Conformance Matrix

(This annex **is not** part of the Recommendation)

This annex provides the Conformance Matrix for implementations of Space
Link Extension (SLE) Return All Frames (RAF) Service systems. An SLE RAF
Service system will be considered to conform to this Recommendation if
the mandatory elements identified in the Tables D-1 and D-2 are
implemented as described in this Recommendation.

Table D-1: Conformance Matrix for RAF Service (Operations)

  ----------------------------------- -----------------------------------
  RAF Service Operation               Optional/Mandatory

  RAF-BIND\                           These operations are mandatory. All
  RAF-UNBIND                          parameters are also mandatory with
                                      the exception of:\
                                      invoker-credentials\
                                      performer-credentials

  RAF-START\                          These operations are mandatory. All
  RAF-STOP\                           parameters are also mandatory with
  RAF-TRANSFER-DATA\                  the exception of:\
  RAF-SYNC-NOTIFY\                    invoker-credentials\
  RAF-SCHEDULE-STATUS-REPORT\         performer-credentials
  RAF-STATUS-REPORT\                  
  RAF-GET-PARAMETER                   

  RAF-PEER-ABORT                      This operation is mandatory. All
                                      parameters are also mandatory with
                                      the exception of:\
                                      invoker-credentials
  ----------------------------------- -----------------------------------

Table D-2: Conformance Matrix for RAF Service (Other Requirements)

  ----------------------------------- -----------------------------------
  Requirement                         Optional / Mandatory

  State transition table (see 4.2)    Mandatory.

  ASN.1 protocol specification (see   All data types are mandatory.
  annex A)                            Implementations may vary as
                                      described in the annex.

  Transfer buffer size (see 3.1.8.1)  Mandatory minimum size shall be
                                      sufficient to contain 200
                                      RAF-TRANSFER-DATA invocations (or
                                      the equivalent thereof).

  Online buffer size (see 3.1.8.2)    Mandatory minimum size shall be
                                      sufficient to contain 100,000
                                      RAF-TRANSFER-DATA invocations (or
                                      the equivalent thereof).

  Offline buffer size (see 3.1.8.3)   Mandatory minimum size shall be
                                      sufficient to contain 1,000,000
                                      RAF-TRANSFER-DATA invocations (or
                                      the equivalent thereof).
  ----------------------------------- -----------------------------------

########   Informative References

(This annex **is not** part of the Recommendation)

\[E1\] *Procedures Manual for the Consultative Committee for Space Data
Systems*. CCSDS A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.:
CCSDS, November 1996*.*

\[E2\] *Standard Terminology, Conventions, and Methodology (TCM) for
Defining Data Services*. Report Concerning Space Data Systems Standards,
CCSDS 910.2-G-1. Green Book. Issue 1. Washington, D.C.: CCSDS, November
1994.

\[E3\] *Space Link Extension---Service Management Specification*. Draft
Recommendation for Space Data System Standards, CCSDS 910.5-R-2. Red
Book. Issue 2. CCSDS, September 2001.

\[E4\] *Cross Support Concept --- Part 1: Space Link Extension
Services*. Report Concerning Space Data System Standards, CCSDS
910.3-G-2. Green Book. Issue 2. Washington, D.C.: CCSDS, April 2002.

[^1]: For the RAF-BIND operation, the service-type parameter is
    redundant, because the only valid value of service-type is 'Rtn All
    Frames'. However, it is anticipated that future work by CCSDS may
    result in RAF-BIND being superseded by a generic SLE-BIND operation
    that is invoked with any one of several SLE service types. The
    RAF-BIND service-type parameter is provided in an attempt to
    facilitate such a change.