![](media/image1.pct){width="4.416666666666667in"
height="1.2777777777777777in"}

**RECOMMENDATION FOR SPACE**

**DATA SYSTEM STANDARDS**

+-----------------------------------------------------------------------+
| **CROSS SUPPORT REFERENCE MODEL**                                     |
|                                                                       |
| **PART 1**                                                            |
|                                                                       |
| **SPACE LINK EXTENSION SERVICES**                                     |
+-----------------------------------------------------------------------+

**CCSDS 910.4-B-1**

**BLUE BOOK**

May 1996

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

**AUTHORITY**

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

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

  ---- -------------------- ------------------------------------------ ----
       Issue:               Blue Book, Issue 1                         

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

  ---- -------------------- ------------------------------------------ ----
       Date:                May 1996                                   

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

  ---- -------------------- ------------------------------------------ ----
       Location:            Pasadena, California, USA                  

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

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

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

This document has been approved for publication by the Management
Council of the Consultative Committee for Space Data Systems (CCSDS) and
represents the consensus technical agreement of the participating CCSDS
Member Agencies. The procedure for review and authorization of CCSDS
Recommendations is detailed in reference \[1\], 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 OI)
>
> 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 Cross
Support reference model described herein is intended for missions that
are cross-supported between Agencies of the CCSDS.

This **Recommendation** establishes a common framework and provides a
common basis for the specification of data services that extend the
space to ground communication services previously defined by CCSDS. It
allows implementing organizations within each Agency to proceed
coherently with the development of compatible derived Standards for the
ground systems that are within their cognizance. Derived Agency
Standards may implement only a subset of the optional features allowed
by the **Recommendation** and may incorporate features not addressed by
the **Recommendation**.

Through the process of normal evolution, it is expected that expansion,
deletion or modification to this document may occur. This
**Recommendation** is therefore subject to CCSDS document management and
change control procedures, as defined in reference \[1\].

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

[Member Agencies]{.underline}

> -- British National Space Centre (BNSC)/United Kingdom.
>
> -- Canadian Space Agency (CSA)/Canada.
>
> -- Central Research Institute of Machine Building (TsNIIMash)/Russian
> Federation.
>
> -- Centre National d'Etudes Spatiales (CNES)/France.
>
> -- Deutsche Forschungsanstalt 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 HQ)/USA.
>
> -- National Space Development Agency of Japan (NASDA)/Japan.

[Observer Agencies]{.underline}

> -- Australian Space Office (ASO)/Australia.
>
> -- Austrian Space Agency (ASA)/Austria.
>
> -- Belgian Science Policy Office (SPO)/Belgium.
>
> -- Centro Tecnico Aeroespacial (CTA)/Brazil.
>
> -- Chinese Academy of Space Technology (CAST)/China.
>
> -- 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.
>
> -- Hellenic National Space Committee (HNSC)/Greece.
>
> -- Indian Space Research Organization (ISRO)/India.
>
> -- Industry Canada/Communications Research Centre (CRC)/Canada.
>
> -- 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.
>
> -- Ministry of Communications (MOC)/Israel.
>
> -- National Oceanic & Atmospheric Administration (NOAA)/USA.
>
> -- National Space Program Office (NSPO)/Taiwan.
>
> -- Swedish Space Corporation (SSC)/Sweden.
>
> -- United States Geological Survey (USGS)/USA.

**DOCUMENT CONTROL**

  -------------- ------------------------- ---------- -------------------------
  **Document**   **Title**                 **Date**   **Status**

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

  ----------- ------------------------- -------- -------------------------
  CCSDS       Cross Support Reference   May 1996 Original Issue
  910.4-B-1   Model---Part 1: Space              
              Link Extension Services            

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

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

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

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

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

**CONTENTS**

[Section]{.underline} [Page]{.underline}

**1 INTRODUCTION 1-1**

> 1.1 PURPOSE OF THIS RECOMMENDATION 1-1
>
> 1.2 SCOPE 1-2
>
> 1.3 APPLICABILITY 1-3
>
> 1.4 RATIONALE 1-3
>
> 1.5 DOCUMENT STRUCTURE 1-4
>
> 1.6 DEFINITIONS 1-4
>
> 1.7 REFERENCES 1-9

**2 OVERVIEW 2-1**

> 2.1 PURPOSE OF THIS SECTION 2-1
>
> 2.2 CROSS SUPPORT CONTEXT 2-1
>
> 2.3 SLE SERVICES DOCUMENTATION TREE 2-2

**3 SLE SYSTEM ENVIRONMENT, DATA, AND SERVICES 3-1**

> 3.1 PURPOSE OF THIS SECTION 3-1
>
> 3.2 SLE SYSTEM ENVIRONMENT---SPACE MISSION DATA SYSTEM 3-1
>
> 3.3 SLE SYSTEM DATA AND SERVICES---DATA EXCHANGE 3-4
>
> 3.4 SPACE LINK EXTENSION SERVICES 3-7

**4 SLE ARCHITECTURE MODEL 4-1**

> 4.1 INTRODUCTION TO SLE ARCHITECTURE MODEL 4-1
>
> 4.2 TOP-LEVEL ARCHITECTURE MODEL 4-2
>
> 4.3 ARCHITECTURE MODEL---FUNCTIONAL VIEW 4-5
>
> 4.4 ARCHITECTURE MODEL---CROSS-SUPPORT VIEW 4-20

**5 SPECIFICATION OF SLE SERVICES 5-1**

> 5.1 PURPOSE AND ORGANIZATION 5-1
>
> 5.2 ABSTRACT MODEL OF SLE SERVICE 5-1
>
> 5.3 SLE SERVICE SPECIFICATION 5-2
>
> 5.4 SLE TRANSFER SERVICE PORTS 5-3
>
> 5.5 SLE MANAGEMENT SERVICE PORTS 5-7
>
> 5.6 SLE TRANSFER SERVICE PRODUCTIONS 5-8

**ANNEX A SPACE LINK EXTENSION DATA STRUCTURES A-1**

**ANNEX B CROSS SUPPORT REFERENCE MODEL\
INDEX TO DEFINITIONS B-1**

**ANNEX C CROSS SUPPORT REFERENCE MODEL\
ACRONYMS AND ABBREVIATIONS C-1**

**CONTENTS (continued)**

[Figure]{.underline} [Page]{.underline}

1-1 CCSDS Space Mission Data System 1-1

1-1a Drawing Conventions for an Object-Type 1-7

1-1b Drawing Conventions for an Object-Instance 1-8

1-1c Drawing Conventions for Multiple Object-Instances 1-8

1-2 Object Refinement 1-9

2-1 SLE Services Documentation Tree 2-2

3-1 Space Mission Data System 3-1

3-2 Ground Element of a Space Mission Data System 3-2

3-3 Data Exchange 3-4

3-4a An Illustration of Mapping Return SL-DUs to Return SLE-SDUs 3-5

3-4b An Illustration of Mapping Forward SLE-SDUs to Forward SL-DUs 3-6

4-1 Abstract Model of the SLE System Environment 4-2

4-2 Ports of an SLE-FG 4-6

4-3 Interconnection of SLE-FGs Ports 4-7

4-4 Return Functional Groups 4-8

4-5 AOS Forward Functional Groups 4-14

4-6 Forward Telecommand Functional Groups 4-17

4-7 SLE Complexes 4-20

4-8 Mission and SLE Utilization Management 4-21

4-9 An Example of SLE Complex Ports 4-23

4-10 Binding SLE Complex Transfer Ports 4-25

4-11 Binding of SLE Complex Management Ports 4-25

4-12 Composite Example of SLE Management 4-26

5-1 Abstract Model of an SLE Service 5-1

A-1 Return SLE Channel Tree A-9

A-2 Forward SLE Channel Tree A-11

[Table]{.underline}

4-1 Return SLE Functional Groups 4-5

4-2 Forward AOS SLE-FG 4-5

4-3 Forward Telecommand SLE-FG 4-5

5-1 Return SLE Transfer Ports, SLE Services, Provider SLE-FGs,\
and User SLE Objects 5-4

**CONTENTS (continued)**

[Table]{.underline} [Page]{.underline}

5-2 Forward SLE Transfer Ports, SLE Services, Provider SLE-FGs,\
and User SLE Objects 5-6

5-3 SLE Management Ports and Supplier SLE-FGs 5-7

A-1 Packet Telemetry SL-DUs A-2

A-2 Telecommand SL-DUs A-2

A-3 AOS SL-DUs A-3

A-4 Return SLE Data Channels A-6

A-5 Forward SLE Data Channels A-10

1 INTRODUCTION

**1.1 PURPOSE OF THIS RECOMMENDATION**

**1.1.1 BASELINE AND REFERENCE FOR SLE SERVICE SPECIFICATIONS**

This Recommendation defines a Cross Support reference model which
provides a common basis for coordinating the development of CCSDS
Recommendations for Space Link Extension (SLE) service specifications
and serves as a reference to maintain the consistency of these
Recommendations.

**1.1.2 RELATIONSHIP TO SPACE LINK RECOMMENDATIONS**

**1.1.2.1** CCSDS Space Link Recommendations (Advanced Orbiting System
(AOS), Packet Telemetry, and Telecommand, references \[2\]--\[7\])
define formats and protocols for the transfer of data from/to data
sources/sinks on board a space vehicle to/from data sinks/sources on the
ground as shown on figure 1-1. These Space Link protocols are designed
to work efficiently in the noisy, high-delay environment of space/ground
radio links; thus they do not carry information needed to configure and
operate the ground systems that link numerous ground stations with the
ground sinks and sources of data.

![](media/image3.pct){width="4.805555555555555in"
height="0.5277777777777778in"}

**Figure 1-1: CCSDS Space Mission Data System**

**1.1.2.2** The SLE Recommendations complement the CCSDS Space Link
Recommendations with a range of services that are required to configure,
operate, and supervise the ground data systems.

**1.1.2.3** The SLE Recommendations apply to data systems that are
able 1) to receive CCSDS Space Link data structures from a spacecraft
via a Space Link, or 2) to send CCSDS Space Link data structures to a
spacecraft via a Space Link, or 3) to transfer such CCSDS Space Link
data structures between ground-based entities.

**1.1.3 SLE SERVICES**

SLE services comprise:

> a\) SLE transfer services, which are concerned with the ground part of
> the data transfer described in 1.1.2. This transfer is either within
> the ground data system or between the ground data system and the
> ground data sources/sinks.
>
> b\) SLE management services, which control the scheduling and
> provision of SLE transfer services by ground systems.

**1.1.4 SLE SYSTEMS**

Ground systems that provide services that comply with the CCSDS
Recommendations for SLE service specifications are called SLE systems.

**1.1.5 FRAMEWORK FOR SLE SERVICES**

This Recommendation provides the framework for definition of SLE service
specifications to be used in support of space missions. This framework
comprises:

> a\) the identification of an SLE system and of its environment;
>
> b\) an architectural model of an SLE system including:
>
> 1\) a functional view;
>
> 2\) a management view;
>
> c\) the common characteristics of SLE services and the template for
> SLE service specifications:
>
> 1\) each individual SLE service specification expresses its
> requirement on supporting telecommunication services in a respective
> quality-of-service clause;
>
> 2\) it is assumed that the provider and user of a given SLE service
> ensure that appropriate telecommunication facilities are in place;
>
> d\) the identification of the SLE transfer services;
>
> NOTE -- In d), SLE transfer services are identified; however, the
> complete service specification will be provided in a separate
> Recommendation.

**1.2 SCOPE**

**1.2.1** The scope of this Recommendation is the definition of all
concepts and terms that establish a common basis for coordinating the
development of CCSDS Recommendations for SLE services specifications. In
defining these concepts and terms the following assumptions are made:

> a\) the context is that of a single space mission;
>
> b\) within this space mission a single spacecraft is considered;
>
> c\) this spacecraft's telemetry and telecommand are compliant with
> CCSDS Space Link Recommendations;
>
> d\) all ground end-users (i.e., data sinks or sources) are affiliated
> with a single mission management entity.

**1.2.2** The following points are not covered by this Recommendation:

**1.2.2.1** Although sharing ground systems between multiple space
missions or between multiple spacecraft of the same space mission is not
explicitly modeled, this Recommendation does not in any way preclude
sharing ground systems.

**1.2.2.2** Ground systems and/or services that are not directly
concerned with the transport of data compliant to CCSDS Space Link
Recommendations are not described. Processing data held within the data
fields of Source Packet Protocol Data Units (PDUs) described in CCSDS
Packet Telemetry, Telecommand, and AOS Recommendations (references
\[2\]--\[7\]) is outside the scope of this Recommendation.

**1.2.2.3** This reference model assumes that ground communications
services are used in conjunction with the SLE services to support a
space mission, but does not explicitly model these communications
services.

**1.3 APPLICABILITY**

**1.3.1 APPLICABILITY OF THIS RECOMMENDATION**

This Recommendation serves as a guideline for the development of
compatible Agency standards for SLE systems. Systems embraced by this
Recommendation include manned and unmanned free-flying spacecraft and
space transportation systems. This Recommendation is particularly
relevant to the SLE systems that are involved in cross support.

**1.3.2 LIMIT OF APPLICABILITY**

This Recommendation is neither a specification of, nor a design for,
real SLE systems that may be implemented for the control and monitoring
of existing or future missions.

**1.4 RATIONALE**

The primary goal of CCSDS is to increase the level of interoperability
among Agencies. This Recommendation furthers that goal by establishing
the basis for a set of SLE services to be used in the area where most
cross-support activity occurs: between the tracking stations or ground
data handling systems of various Agencies and the mission specific
components of a mission ground system. Reference \[11\], *Cross Support
Concept --- Part 1: Space Link Extension Services*, provides further
discussion of the rationale for this Recommendation.

**1.5 DOCUMENT STRUCTURE**

This Recommendation is organized as follows:

> a\) Section 1 provides purpose, scope, applicability and rationale of
> this Recommendation and lists the definitions, conventions, and
> references used throughout the Recommendation.
>
> b\) Section 2 provides the context of cross support, presents the
> cross-support documentation structure, and shows how this
> Recommendation fits into that framework. It expands on the scope of
> this Recommendation to provide an overview of the document.
>
> c\) Section 3 defines the SLE system environment, data handled by an
> SLE system, and introduces SLE services.
>
> d\) Section 4 defines an architectural model for the SLE system. This
> architectural model comprises two views:
>
> 1\) A functional view which defines the system concepts, including
> functions and data, from which the SLE services are derived. In this
> functional view, the SLE system is decomposed into SLE Functional
> Groups (SLE-FGs), which implement and augment the ground side of the
> Space Link protocols described in CCSDS Packet Telemetry, Telecommand,
> and AOS Recommendations (references \[2\]-\[7\]).
>
> 2\) A cross-support management view, which defines the management
> interactions between the entities involved in the provision of SLE
> services and provides the baseline for the SLE Service Management
> Specification. In this management view, the SLE system is decomposed
> into SLE Complexes and the notion of SLE Service Package is
> introduced.
>
> e\) Section 5 defines the common characteristics of SLE services,
> provides the template for SLE transfer services specifications, and
> provides an initial description of each SLE service including
> operations and parameters at the corresponding ports.
>
> f\) Annex A expands upon the description, in Section 3, of the data
> handled in SLE systems.

**1.6 DEFINITIONS**

**1.6.1 DEFINITIONS FROM REFERENCES**

This Recommendation uses the Abstract Service Definition Conventions
(ASDC) methodology, which provides the means to create a model of a
system composed of objects that provide services to one another. This
Architecture Model is composed of abstract-objects which have abstract
ports, through which they provide abstract-services to other
abstract-objects. The definitions below are from reference \[10\].

**1.6.1.1 Definition: Abstract-Object**. An abstract-object is a
functional entity which interacts with other abstract-objects. Objects
are of different types, which determine their function and behavior.
These abstract-objects are characterized by their interfaces, which are
called abstract-ports, and the operations which can be performed through
those ports.

**1.6.1.2 Definition: Abstract-Service**. ASDC defines an
abstract-service as a set of capabilities that one abstract-object
offers to another by means of one or more of its abstract-ports. For the
purpose of defining SLE Services in this reference model, an
abstract-service is considered to be the capability provided by a set of
operations that an abstract-object exposes at one or more of its
abstract-ports.

**1.6.1.3 Definition: Abstract Refinement**. A model may be defined as
consisting of a few high-level objects. These objects may be decomposed
into lower-level, component objects. This decomposition is called
abstract refinement.

NOTE -- To improve readability, the term "abstract" is used from here
onward only when it is necessary to distinguish a feature of the model
from its implementation, or to emphasize the use of an ASDC concept or
term.

**1.6.1.4 Definition: Port Types**. Ports that are involved in providing
different services are said to be of different types.

**1.6.1.5 Definition: Symmetric/Asymmetric Ports**. Two ports (of two
objects) involved in the provision of a service may be either symmetric
ports or asymmetric ports. The ports are symmetric if each offers all of
the operations associated with the service. The ports are asymmetric if
each offers different operations; in this case, one port is called a
consumer, and the other is called a supplier.

**1.6.1.6 Definition: 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.

NOTE -- "Provide" is used in the sense of "make available to be used"
and does not necessarily imply that the service is being used.

**1.6.1.7 Definition: Abstract Binding**. When two abstract ports of the
same type have an association established between them such that an
abstract service can be provided, the two ports are said to be bound.
The act of establishing such an association is called abstract binding.

**1.6.1.8 Definition: Operation**. An operation is a procedure that one
object (the invoker) can request of another (the performer) through a
port pair bound within the terms of an agreement.

NOTES

1 The relationships among the terms user/provider, supplier/consumer,
and invoker/performer are explained in reference \[10\]. Briefly:

2 The terms user and provider are used to distinguish the roles of two
interacting objects. Usually these terms are applied so as to indicate
which object (the provider) is performing a function on behalf of the
other object (the user). 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, regardless of the
direction of data flow.

3 The terms consumer and supplier are used to distinguish the roles of
two ports, each attached to one of two objects, that are bound. In this
Recommendation, these terms indicate direction of transfer of data:
*from* the supplier port *to* the consumer port.

4 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 which is performed by the other.
For most services, each object, whether consumer or supplier, invokes
some operations and performs others.

**1.6.2 DEFINITIONS IN THIS DOCUMENT**

The definitions provided below are those needed for understanding this
Recommendation as a whole. Many other terms are defined throughout this
Recommendation.

**1.6.2.1** **Definition: return data**. For the purposes of this
Recommendation, Return Data is all data that is sent from the space
element to the ground element (e.g., telemetry).

**1.6.2.2** **Definition: forward data**. For the purposes of this
Recommendation, forward data is all data that is sent from the ground
element to the space element (e.g., telecommand).

**1.6.3 CONVENTIONS**

**1.6.3.1 Style**

Within this Recommendation, each formal statement stands in a paragraph
by itself and is identified uniquely by a subsection number or by a
combination of subsection number and list item number.

**1.6.3.2 Notes**

Notes are not formally part of this Recommendation. They are isolated
from the formal statements and are introduced by the word NOTE.

EXAMPLE

> NOTE -- This is an example of a note.

**1.6.3.3 Usage of Capital Letters**

Names of system components, data units, and other elements of the
reference model are shown with the first letter of each word
capitalized.

**1.6.3.4 Types And Instances**

As noted in 1.6.1, ASDC allows definition of groups, or classes, of
objects that can provide the same services. Such objects are said to be
of the same *type*. In this reference model, it is sometimes necessary
to distinguish between characteristics that are common to all objects of
a type and characteristics of a particular object of a type. Often, this
is clear from context, but when necessary to avoid ambiguity the word
"instance" is used to emphasize the notion of a single object of a type;
the word "type" or the phrase "of a type" is used to refer to all
objects of the same class. Generally, "the \<type-name\>" is used in
describing the object-type. Often, characteristics of a class (i.e.,
objects of a type) are defined by referring to "a (or any, every, each)
\<type-name\>". When specific objects are discussed, they are given
names (e.g., X, Y, Mission ABC). This wording is also used with regard
to ports, services, and operations defined in the reference model.

**1.6.3.5 Drawing Conventions**

In figures illustrating this reference model, the following conventions
are used.

> a\) A type of (abstract) object is shown as a round-cornered box. The
> type-name is shown at the bottom of the box, preceded by the word
> "Type" and a colon; see figure 1-1a. The initial letter of the
> type-name is always upper case. The ports and services associated with
> an object type are also types.

![](media/image4.pct){width="5.805555555555555in"
height="2.611111111111111in"}

**Figure 1-1a: Drawing Conventions for an Object-Type**

> b\) An instance of an object is shown as a round-cornered box. The
> type-name is again shown at the bottom of the box, but is *not*
> preceded by the word "Type" and a colon; see figure 1-1b. The ports
> and services associated with an instance of an object type are also
> instances.

![](media/image5.pct){width="5.805555555555555in"
height="2.4722222222222223in"}

**Figure 1-1b: Drawing Conventions for an Object-Instance**

> c\) If a figure shows two or more instances of the same type of
> object, each is given a name by showing the type-name followed by a
> colon and the name of the instance. The initial letter of the
> instance-name is always lower case. See figure 1-1c.
>
> d\) Instances of a port type are distinguished by the names of the
> service instances that are provided at the port. Multiple instances of
> a single service are permitted. See example instances 1 and 2 of
> service D in figure 1-1c.

![](media/image6.pct){width="6.194444444444445in"
height="2.8472222222222223in"}

**Figure 1-1c: Drawing Conventions for Multiple Object-Instances**

**1.6.3.6 Object Refinement**

In ASDC terms, this document decomposes a system and other objects into
component objects. When a port of a component object is exposed as a
port of the parent object, it is shown as illustrated by ports G, H, K,
and L in figure 1-2.

![](media/image7.pct){width="5.708333333333333in"
height="2.4166666666666665in"}

**Figure 1-2: Object Refinement**

**1.7 REFERENCES**

The following documents are referenced in the text 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.

\[1\] *Procedures Manual for the Consultative Committee for Space Data
Systems*. CCSDS A00.0-Y-6. Yellow Book. Issue 6. Washington, D.C.:
CCSDS, May 1994.

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

\[3\] *Telemetry Channel Coding*. Recommendation for Space Data System
Standards, CCSDS 101.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS,
May 1992.

\[4\] *Advanced Orbiting Systems, Networks and Data Links: Architectural
Specification*. Recommendation for Space Data Systems Standards, CCSDS
701.0-B-2. Blue Book. Issue 2. Washington, D.C.: CCSDS, November 1992.

\[5\] *Telecommand Part 1 --- Channel Service*. Recommendation for Space
Data System Standards, CCSDS 201.0-B-2. Blue Book. Issue 2. Washington,
D.C.: CCSDS, November 1995.

\[6\] *Telecommand Part 2 --- Data Routing Service*. Recommendation for
Space Data System Standards, CCSDS 202.0-B-2. Blue Book. Issue 2.
Washington, D.C.: CCSDS, November 1992.

\[7\] *Telecommand Part 3 --- Data Management Service*. Recommendation
for Space Data System Standards, CCSDS 203.0-B-1. Blue Book. Issue 1.
Washington, D.C.: CCSDS, January 1987.

\[8\] *CCSDS Global Spacecraft Identification Field Code Assignment
Control Procedures*. Recommendation for Space Data Systems Standards,
CCSDS 320.0-B-1. Blue Book. Issue 1. Washington, D.C.: CCSDS, October
1993.

\[9\] *CCSDS Publications Manual*. CCSDS A20.0-Y-1. Yellow Book.
Issue 1. Washington, D.C.: CCSDS, May 1994.

\[10\] *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.

\[11\] *Cross Support Concept --- Part 1: Space Link Extension
Services*. Report Concerning Space Data Systems Standards, CCSDS
910.3-G-1. Green Book. Issue 1. Washington, D.C.: CCSDS, May 1995.

\[12\] *Information technology --- Text Communication ---
Message-Oriented Text Interchange Systems (MOTIS) --- Part 3: Abstract
Service Definition Conventions,* *Technical Corrigendum 1*. ISO/IEC
10021-3: 1990/Cor. 1: 1992. Geneva: ISO, 1992.

\[13\] *Information technology --- Open Systems Interconnection ---
Specification of Abstract Syntax Notation One (ASN.1)*. ISO 8824. 2nd
ed. Geneva: ISO, 1990.

\[14\] *Packet Telemetry Services*. Recommendation for Space Data System
Standards, CCSDS 103.0-B-1. Blue Book. Issue 1. May 1996.

2 OVERVIEW

**2.1 PURPOSE OF THIS SECTION**

Section 2 of this Recommendation provides the context for reading this
Recommendation. Subsections 2.2 and 2.3 introduce the Cross Support
Context and the associated SLE services documentation tree.

**2.2 CROSS SUPPORT CONTEXT**

The term Cross Support is applied when one Agency uses part of another
Agency's resources to complement its own for the purpose of operating a
spacecraft.

**2.2.1 CROSS SUPPORT SERVICES**

Cross Support Services is a generic term that encompasses all services
that can be provided by one Agency to support another Agency in
operating a spacecraft. On the ground, cross support services are of
three kinds:

> a\) SLE services: defined to extend CCSDS Space Link services as
> defined in CCSDS Space Link Recommendations (references \[2\]--\[7\]);
>
> b\) ground communications services: to provide ground communications
> support, e.g., to relay operational data;
>
> c\) ground domain services: which cover all services which handle data
> related to spacecraft operations but not directly mappable to Space
> Link data structures defined in CCSDS Space Link Recommendations.
> Examples of ground domain services are tracking a spacecraft,
> exchanging spacecraft data bases, mission planning.

**2.2.2 CROSS SUPPORT DOCUMENTATION**

The cross support documentation is divided according to the kinds of
services listed in 2.2.1:

> a\) Part 1 of the Cross Support Recommendation will address SLE
> services;[^1]
>
> b\) Part 2 of the Cross Support Recommendation will address ground
> communications services;
>
> c\) Part 3 of the Cross Support Recommendation will address ground
> domain services.

**2.3 SLE SERVICES DOCUMENTATION TREE**

This document constitutes the root of the SLE services documentation
tree shown in figure 2-1. Directly attached to it are:

> a\) *Cross Support Concept --- Part 1: Space Link Extension Services*:
> a Report introducing the concepts of cross support and SLE services;
>
> b\) SLE Service Management Specification: a Recommendation that
> defines the service management required for the provision of one or
> more SLE services;
>
> c\) SLE Service Specifications: Recommendation(s) will provide
> specification of all SLE services.
>
> NOTE -- It is anticipated that a similar document approach will be
> adopted for Part 2 and 3 of this Recommendation (for the ground
> communications services and ground domain services).

![](media/image8.pct){width="5.986111111111111in" height="3.625in"}

**Figure 2-1: SLE Services Documentation Tree**

3 SLE SYSTEM ENVIRONMENT, DATA, AND SERVICES

**3.1 PURPOSE OF THIS SECTION**

Section 3 of this Recommendation defines the SLE system environment,
data, and services. It introduces terms and concepts of the SLE System
Architectural Model that will be formally defined in Section 4.

**3.2 SLE SYSTEM ENVIRONMENT---SPACE MISSION DATA SYSTEM**

**3.2.1** A Space Mission Data System, as illustrated in figure 3-1, is
the set of on-board and ground data systems that support a mission. It
consists of a space element and a ground element connected via the Space
Link. The space element and ground element exchange return and forward
data.

![](media/image9.pct){width="4.319444444444445in"
height="2.0833333333333335in"}

**Figure 3-1: Space Mission Data System**

NOTE -- The Space Mission Data System corresponds to the CCSDS
AOS/Packet data system illustrated in figure 1-1.

**3.2.2** **Definition: Space Element**. The space element acts as a
source of return data and as a sink for forward data. From the viewpoint
of this Recommendation, the space element represents a single spacecraft
and comprises the platform and all payloads/instruments of this
spacecraft.

NOTES

1 The space vehicles in a multi-spacecraft mission are treated as
individual space elements, from the SLE point of view.

2 Platform and payloads/instruments are considered here only for their
capability of generating or receiving data. Processing they perform on
this data is not within the scope of this Recommendation.

**3.2.3** **Definition: Physical channel.** A physical channel is the
capability to transfer a single stream of bits, in a single direction
(space to ground or ground to space).

**3.2.4** **Definition: Space Link**. The exchange of forward and return
data is performed over a Space Link. A Space Link (SL) consists of one
or both of a forward RF carrier channel and/or a return RF carrier
channel, each of which may provide one or more physical channels. The
simultaneous coexistence of several forward and several return links
with a given spacecraft is possible.

**3.2.5** **Definition: Space Link Session.** A Space Link Session is a
continuous period during which an SLE system provides the capability to
use one or more physical channels on a space link.

**3.2.6** **Definition: Ground Element**. The ground element of a Space
Mission Data System includes a Mission Data Operation System (MDOS) and
an SLE system. It may also contain other components, but these are not
within the scope of this Recommendation. See figure 3-2.

![](media/image10.pct){width="4.888888888888889in"
height="2.888888888888889in"}

**Figure 3-2: Ground Element of a Space Mission Data System**

> NOTE -- The ground element may perform other functions, such as
> instrument data processing or archiving.

**3.2.7** **Definition: Space Link Extension System**. The Space Link
Extension (SLE) System extends the transfer and delivery of forward and
return data between a Space Link ground termination point and the MDOS.
For a given mission, an SLE system provides its services according to
specifications that have been prepared and issued by the respective
MDOS.

NOTE -- Transfer and delivery involve implementing the ground processing
of the protocol described in CCSDS Packet Telemetry, Telecommand, and
AOS Recommendations (references \[2\]--\[7\]).

**3.2.8** **Definition: Mission Data Operation System**. The Mission
Data Operation System (MDOS) acts as a source of forward data and as a
sink of return data. For a given SLE system, the MDOS selects SLE
services and specifies respective service detail as necessary.

**3.2.9** **Definition: Mission User Entities (MUEs)**. Within the MDOS,
the MUEs are sources of forward data or sinks of return data. The SLE
system provides the forward and return data in the form of transfer
services to these MUEs. Several transfer service instances may be
provided to a single MUE.

> a\) Service selection and specification are based on the requirements
> of the MUEs that are affiliated with the MDOS.
>
> b\) In order to cover all requirements, a given MDOS may cooperate
> with several SLE systems; it is the responsibility of the MDOS to
> harmonize its cooperation with several SLE systems. (See figure 3-3.)
> The MDOS contains one SLE Utilization Management and one or more MUEs.

NOTES

1 The MDOS may not be the ultimate source of forward data or sink of
return data on the ground element, but from the perspective of this
Recommendation it acts as if it is.

2 The MDOS negotiates and manages the services provided by the SLE
system for a space mission.

3 This model of an MDOS is not intended to represent physical aspects of
a space mission. For example, the MUEs may be distributed geographically
or belong to several Agencies.

**3.2.10** **Definition: SLE Utilization Management**. Within the MDOS,
the SLE Utilization Management negotiates with the SLE system the
provision of transfer services and controls and monitors the provision
of these services.

NOTES

1 The SLE Utilization Management (SLE-UM) is responsible only for the
management of the MDOS related to the SLE system (and is not responsible
for the management of the complete MDOS) or the space element.

2 The SLE-UM coordinates, internally to the MDOS, the provision of the
transfer services of forward and return data transfer to the MUEs.

3 The management of the SLE system by the SLE-UM is the subject of a
separate management service specification.

**3.3 SLE SYSTEM DATA AND SERVICES---DATA EXCHANGE**

**3.3.1** The MDOS utilizes the SLE to transfer return and forward data
to/from the space element. In addition the MDOS and the SLE system
exchange management data for the purpose of managing the data transfer.
These information exchanges are illustrated in figure 3-3.

![](media/image11.pct){width="5.291666666666667in"
height="3.5972222222222223in"}

**Figure 3-3: Data Exchange**

NOTE -- The management data exchanged between the space element and the
MDOS is illustrated for the sake of completeness; however, it is outside
the scope of this Recommendation and will not be further discussed. It
is simply part of the total data being forwarded to and returned from
the space element. Owing to the lack of a pertinent standard it can not
be recognized or interpreted by the SLE system.

**3.3.2** **Definition: Space Link Data Unit**. The SLE system exchanges
with the space element streams of Space Link Data Units (SL-DUs). SL-DUs
are either Return SL-DUs or Forward SL-DUs.

**3.3.3** **Definition: Return Space Link Data Unit**. A return SL-DU is
a data structure defined by the CCSDS Packet Telemetry and AOS
Recommendations (references \[2\]--\[4\]). The types of return SL-DUs
are provided in tables A-1 and A-3 of annex A.

NOTE -- Examples of return SL-DUs are: a Space Packet; a telemetry
Transfer Frame, as defined in the above references.

**3.3.4** **Definition: Forward Space Link Data Unit**. A Forward SL-DU
is a data structure defined by the CCSDS Telecommand or AOS
Recommendations (references \[4\]--\[7\]). The types of Forward SL-DUs
are provided in tables A-2 and A-3 of annex A.

NOTE -- Examples of Forward SL-DUs are: a Telecommand Packet; a
Telecommand Frame, as defined in the above references.

**3.3.5** **Definition: Space Link Data Channel**. A Space Link data
channel is a uniquely identifiable stream of SL-DUs of the same type
received from, or sent to, a space element. Annex A explains the
relationship between SL-DUs and the Space Link protocols.

NOTE -- Examples of Space Link data channels are: a Return Space Packet
channel with a specific application identifier; a Return VC Frame
channel with a specific virtual channel identifier.

**3.3.6** **Definition: Space Link Extension Service Data Unit**. An SLE
Service Data Unit (SLE-SDU) contains an annotated SL-DU and/or control
information related to the processing and transfer of SL-DUs by the SLE
System.

**3.3.7** To extend the Space Link protocols described in CCSDS Packet
Telemetry, Telecommand, and AOS Recommendations (references
\[2\]--\[7\]), the SLE System transfers streams of SL-DUs, encapsulated
in SLE-SDUs. The mapping between SL-DU and SLE-SDU is illustrated in
figure 3-4a for return data and in figure 3-4b for forward data.

![](media/image12.pct){width="6.0in" height="2.3055555555555554in"}

**Figure 3-4a: An Illustration of Mapping Return SL-DUs to Return
SLE-SDUs**

![](media/image13.pct){width="5.958333333333333in"
height="2.236111111111111in"}

**Figure 3-4b: An illustration of Mapping Forward SLE-SDUs to Forward
SL-DUs**

NOTES

1 Examples of annotation are: ground reception time; quality indication
(return data) and requested transmission time, uplink path (forward
data). Examples of control are: loss-of-service indication;
recovery-of-service indication (return data) and directives related to
the Command Operation Procedure (forward data).

2 In the case of return and forward RF signals, the SLE-SDUs are
identical to the SL-DUs, i.e., they contain no annotation or control
information. They are, nevertheless, referred to as SLE-SDUs in this
Recommendation.

3 Figures 3-4a and 3-4b are not meant to specify the order in which SLE
control information, SLE annotation of an SL-DU, or the SL-DU appear in
an SLE-SDU.

4 Figures 3-4a and 3-4b (like the reference model) do not address the
PDUs that may be used to implement the transfer of SLE-SDUs across
ground networks.

5 Figure 3-4a illustrates the concept of deriving a stream of Return
SLE-SDUs from a stream of Return SL-DUs. The top line shows a stream of
SL-DUs. The lower line shows the corresponding stream of SLE-SDUs, where
each SL-DU has been "wrapped up" with annotation, and sometimes with
control information, and where some control information has been
provided in an SLE-SDU that contains no SL-DU. Thus one kind of SLE-SDU
is derived from a specific SL-DU, while another kind of SLE SDU provides
supplementary control information that does not pertain to a specific
SL-DU.

6 Figure 3-4b above illustrates the concept of deriving a stream of
Forward SL-DUs from a stream of Forward SLE-SDUs. The lower line shows a
stream of SLE-SDUs, where each SL-DU has been wrapped up with annotation
and sometimes with control information. An SLE-SDU also may carry
control information alone (i.e., no Space link-DU). Such an SLE-SDU
might result in generation of an Space link-DU (e.g., a TC COP directive
to send an "Unlock" command to the space element), or might be relevant
only within the SLE System (e.g., a TC COP directive to set values of
ground-end parameters).

**3.3.8** **Definition: Space Link Extension Data Channel.** An SLE data
channel is a uniquely identifiable stream of SLE-SDUs of the same type
derived from a Space Link data channel. The types and identification are
the same as for space data channels. SLE data channels are the streams
of data processed and transferred by an SLE System. The types of Space
Link Extension Data Channels are listed in tables A-4 and A-5 of Annex
A.

NOTE -- Formally speaking, an SLE data channel cannot be transferred by
an SLE System. It is the SLE-SDUs belonging to an SLE data channel that
are transferred by an SLE System.

**3.3.9** The detailed structure and semantics of each component of an
SLE-SDU, as well as the rules for their composition into SLE-SDUs, are
defined in the pertinent SLE service specifications.

**3.4 SPACE LINK EXTENSION SERVICES**

SLE services are provided by an SLE system to an MDOS. SLE services
comprise:

> a\) the SLE transfer services, which transfer SLE data channels
> from/to the space element to/from the MDOS through the SLE system;
>
> b\) the SLE management service, which controls the scheduling and
> provision of instances of SLE transfer services by the SLE system.
>
> NOTES
>
> 1 In the realm of a specific mission, one speaks of instances of SLE
> service provided by the SLE system and not of SLE services. The
> distinction between SLE service and instances of SLE service is
> discussed in sections 4 and 5.
>
> 2 In the realm of a specific mission, there may be several instances
> of SLE management service and of SLE transfer service at any time
> provided by an SLE system to an MDOS.

**3.4.1 OVERVIEW OF SLE TRANSFER SERVICES**

> a\) Each of the SLE transfer services delivers one type of SLE data
> channel.
>
> b\) The following subsections identify the baseline Return SLE
> transfer services, Forward AOS SLE transfer services, and Forward
> Telecommand SLE transfer services, respectively. This baseline may be
> modified in the future through the addition or deletion of SLE
> services. These service identifications do not address the details of
> the services. Subsection 4.3.2 of this document provides more detail
> on each of the services listed below. For each service listed below,
> its corresponding description in 4.3.2 is identified.

**3.4.1.1 Return SLE transfer services**

Return SLE transfer services include:

> a\) Return All Frames (RAF) service, which delivers the RAF SLE data
> channel resulting from a single physical channel (4.3.2.1.1 a) 1));
>
> b\) Return Insert service, which delivers the Return Insert SLE data
> channel decommutated from a single physical channel (AOS only)
> (4.3.2.1.1 a) 2));
>
> c\) Return Master Channel (MC) Frame service, which delivers a Master
> Channel (Master SLE data channels) demultiplexed from an RAF channel
> (4.3.2.1.2 a) 1));
>
> d\) Return Master Channel Operational Control Field (MC-OCF) service,
> which delivers an Operational Control Field SLE data channel
> decommutated from its associated Master Channel (4.3.2.1.2 a) 2));
>
> e\) Return Master Channel Frame Secondary Header (MC-FSH) service,
> which delivers a Frame Secondary Header SLE data channel decommutated
> from its associated Master Channel (Packet Telemetry only) (4.3.2.1.2
> a) 3));
>
> f\) Return Virtual Channel Frame (VC Frame) service, which delivers a
> Virtual Channel (Virtual SLE data channel) demultiplexed from an MC
> channel (4.3.2.1.2 a) 4));
>
> g\) Return Virtual Channel Operational Control Field (VC-OCF) service,
> which delivers an Operational Control Field SLE data channel
> decommutated from its associated Virtual Channel (4.3.2.1.2 a) 5));
>
> h\) Return Virtual Channel Frame Secondary Header (VC-FSH) service,
> which delivers a Frame Secondary Header SLE data channel decommutated
> from its associated Virtual Channel (Packet Telemetry only) (4.3.2.1.2
> a) 6));
>
> i\) Return Bitstream service, which delivers a Bitstream SLE data
> channel decommutated from its associated virtual channel (AOS only)
> (4.3.2.1.3 a) 1)); and
>
> j\) Return Space Packet (RSP) service, which delivers a set of RSP SLE
> data channels demultiplexed from a Version-1 or Version-2 virtual
> channel (4.3.2.1.3 a) 2)).

**3.4.1.2 Forward AOS SLE Transfer Services**

Forward AOS SLE transfer services include:

> a\) Forward Bitstream service, which receives a Bitstream SLE data
> channel from the MDOS (4.3.2.2.1 a) 1));
>
> b\) Forward VCA service, which receives a VCA SLE data channel from
> the MDOS (4.3.2.2.1 a) 2));
>
> c\) Forward Space Packet service, which receives Forward Space Packet
> data channels from the MDOS (4.3.2.2.1 a) 3));
>
> d\) Forward ProtoVCDU service, which receives a protoVCDU SLE data
> channel (4.3.2.2.2 a) 1)) (A protoVCDU is a VCDU that does not yet
> have data in its insert zone and has not yet been coded);
>
> e\) Forward Insert service, which receives a Forward AOS Insert SLE
> data channel (4.3.2.2.2 a) 2)); and
>
> f\) Forward C/VCDU service, which receives C/VCDU SLE data channels
> (4.3.2.2.2 a) 3)).

**3.4.1.3 Forward Telecommand SLE Transfer Services**

Forward Telecommand SLE transfer services include:

> a\) Telecommand VCA (TC-VCA) service, which receives a TC-VCA SLE data
> channel (4.3.2.3.1 a) 1));
>
> b\) Forward Space Packet service, which receives Forward Space Packet
> SLE data channels (4.3.2.3.1 a) 2));
>
> c\) Telecommand Frame service which receives Forward Telecommand Frame
> SLE data channels (4.3.2.3.2 a));
>
> d\) Command Link Transmission Unit (CLTU) service which receives
> Forward CLTU SLE data channels (4.3.2.3.3 a)).

**3.4.2 SLE TRANSFER SERVICE DELIVERY MODES**

There are two modes of delivery for SLE transfer services: *online* and
*offline*.

**3.4.2.1 Online Delivery Mode**

The online delivery mode is employed to transfer a stream of SLE service
data through all or part of the SLE system during the time that the
associated Space Link session is active.

**3.4.2.1.1 Forward Online Delivery**

> a\) On-line delivery for forward data is provided during a forward
> space link session, i.e., the period of time when application
> processes at the sending and receiving ends of the forward link are
> physically and/or logically interconnected for the purpose of
> delivering forward link data.
>
> b\) The basic quality of on-line delivery is characterized by the
> types of services available: 1) complete and in-sequence and 2)
> expedited.
>
> c\) The complete and in-sequence service guarantees that the service
> data are delivered according to routing control instructions (e.g.,
> multiplexing scheme) with the sequence preserved for a given space
> packet, with no ground-induced errors, with no data omitted and with
> no data duplicated.
>
> d\) The expedited service delivers the service data in the sequence
> received, with no ground-induced errors but does not guarantee
> complete delivery (i.e., data may be lost).
>
> e\) The on-line delivery of forward data cannot extend beyond the end
> of the space link session.

**3.4.2.1.2 Return Online Delivery**

> a\) The quality of online delivery is characterized by two factors:
> the *completeness* of data delivery, and the *timeliness* of data
> delivery.
>
> b\) Unless otherwise constrained for timeliness considerations (see
> item d), below), Return SLE services provide complete delivery, in
> which the service data are delivered in the sequence received, with no
> ground-induced errors, and with no data omitted. Completeness is
> guaranteed, even if the rate at which the data is received by the SLE
> system is greater than the rate at which it is delivered to the user.
>
> NOTE -- Completeness of delivery from a high-rate source to a
> lower-rate sink is dependent on the availability of sufficient
> buffering capability in the SLE system. The guarantee of such
> completeness therefore requires that sufficient resources have been
> reserved by the SLE system.
>
> c\) The online delivery of return data may extend beyond the end of
> the Space Link session.
>
> NOTE -- Complete, in-sequence delivery may result in large delays
> between the time a data item is received by the SLE system and the
> time it is delivered to the user. Return online services support this
> situation by allowing the delivery of the data to the user to extend
> beyond the end of the Space Link session.
>
> d\) The large delays resulting from complete, in-sequence delivery may
> result in the delivery of data past the point of its usefulness. The
> SLE online services provide two mechanisms for dealing with timely
> data (that is, data that are desired or required to be delivered
> within a certain delay from the time of receipt by the SLE system):
>
> 1\) Delay notification: When the delay in delivery exceeds a
> user-specified notification delay, Tdelay-notify, the Return SLE
> service notifies the user. If and when the delay subsequently shortens
> to be within Tdelay-notify, the Return service notifies the user that
> the delay has been recovered.
>
> 2\) Data deletion: When the delay in delivery exceeds a user-specified
> deletion delay, Tdelete, the return SLE service deletes the
> outstanding queue of SLE-SDUs for that service and notifies the user
> of the deletion and the number of SLE-SDUs deleted.
>
> e\) The Return SLE services allow the notification and deletion
> features to be disabled by the service user.

**3.4.2.2 Offline Delivery Mode**

The offline delivery mode is employed to transfer sets of SLE service
data through all or part of the SLE system, and this transfer typically
occurs outside the associated Space Link session.

NOTE -- It is possible to provide a finer granularity of service
delivery than one data set per Space Link session. CCSDS may define such
mechanisms in future releases of this Recommendation. However, one data
set per Space Link session will always be a legitimate subset of the
offline delivery selection criteria.

**3.4.2.2.1 Forward Offline Delivery**

> a\) The offline delivery mode is employed to transfer a set of forward
> SLE service data through all or part of the SLE system. This transfer
> must be complete before the transmission of that data set to the space
> element during the associated Space Link session.
>
> b\) Offline delivery is provided in the form of a data set containing
> all SLE-SDUs (that is, SL-DUs, annotation data, control information,
> and control messages), complete and in sequence, to be transmitted
> during the Space Link session.
>
> c\) The complete and in-sequence service guarantees that the service
> data are delivered according to the routing control instructions
> (e.g., multiplexing scheme) with the sequence preserved for a given
> data set, with no ground-induced errors, with no data omitted, and
> with no data duplicated.
>
> d\) Provisioning for offline delivery includes the reservation of
> sufficient storage in the SLE system. The reservation of such storage
> by the MDOS occurs concurrently with the reservation of SLE system
> resources to receive the source data to be stored.
>
> e\) The offline delivery service includes delivery to the space
> element at a time defined by the associated SLE management.

**3.4.2.2.2 Return Offline Delivery**

> a\) The offline delivery mode is employed to transfer a set of return
> SLE service data through all or part of the SLE system once the
> acquisition of that data set from the space element is complete. This
> transfer occurs during or after the associated Space Link session.
>
> b\) Offline delivery is provided in the form of a data set containing
> all SLE-SDUs (that is, SL-DUs, annotation data, control information,
> and control messages), complete and in sequence, stored during the
> Space Link session.
>
> c\) Provisioning for offline delivery includes the reservation of
> sufficient storage in the SLE system. The reservation of such storage
> by the MDOS occurs concurrently with the reservation of SLE system
> resources to receive the source data to be stored.
>
> d\) In general, storage for subsequent offline delivery is reserved by
> the SLE system in one of two ways:
>
> 1\) Source data storage: Storage of the full set of source data that
> is received by the SLE system for the Space Link session. Storage of
> the source data allows the MDOS to defer the selection of offline data
> sets until the time at which those data sets are retrieved by the
> MDOS.
>
> 2\) User service data storage: Storage of the complete set of service
> data that has been extracted from the source data that has been
> received by the SLE system for the Space Link session. Storage of user
> service data requires that the MDOS establish, concurrent with the
> reservation of resources needed to receive the source data, the exact
> service data sets to be subsequently delivered offline.
>
> NOTES
>
> 1 From the perspective of the MDOS, source data storage is usually the
> preferred option, because it allows the user to defer deciding the
> exact sets of service data to be delivered offline. However, as the
> ratio of data to be delivered offline to the amount of source data
> decreases, the relative cost of storing the source data increases for
> the SLE system. Therefore, real SLE systems may constrain or disregard
> altogether storing offline data at the source data level.
>
> 2 There may be multiple data sets (corresponding to multiple services)
> extracted from the source data corresponding to a single Space Link
> session.
>
> 3 Even if the MDOS arranges for offline storage in terms of user
> service data, an implementation of the SLE system may actually
> implement the storage at the source data level (or even in some
> intermediate form). The issue relevant to cross support (and therefore
> to this Recommendation and the specifications of the various SLE
> services) is the context in which the MDOS and the SLE system arrange
> for the data to be stored.
>
> e\) The MDOS arranges for the offline delivery of stored service data
> as a separate activity from the reception and capture of the source
> data.
>
> NOTE -- The mechanism for arranging for online and offline service
> delivery and the associated resources and processing is called the SLE
> Service Package (see 4.4.1.2).

4 SLE ARCHITECTURE MODEL

**4.1 INTRODUCTION TO SLE ARCHITECTURE MODEL**

**4.1.1 PURPOSE AND SCOPE OF ARCHITECTURE MODEL**

**4.1.1.1** The purpose of the Architecture Model is to provide the
functional and management concepts of the framework for specifications
of SLE services. These functional and management concepts are elaborated
in the context of the SLE system environment introduced in section 3.

**4.1.1.2** This Architecture Model provides an abstract model of an SLE
system. This abstract model is refined in two ways: one to provide a
functional view of an SLE system, and the second to provide a
cross-support view.

**4.1.1.3** The functional view, presented in 4.3, defines the functions
(and their management) that may be performed by an SLE system, without
regard to the way these functions are allocated to various management
authorities in real systems. The functional view decomposes the SLE
system into elementary functions, called SLE Functional Groups
(SLE-FGs), that transfer and deliver return and forward data between the
space element and the MUEs.

**4.1.1.4** The cross-support view, presented in 4.4, provides the means
to model allocation of the functions identified in the functional view
to real systems under independent management authorities, which are
named SLE Complexes. The cross-support view also describes the
management interactions between SLE Complexes and the SLE Utilization
Management on behalf of the MDOS.

**4.1.1.5** The relationship between the functional and cross-support
view is covered in 4.4.2, which discusses how SLE-FGs relate to SLE
Complexes.

**4.1.2 MODELING TECHNIQUE**

a\) The functional and cross-support views of the architecture model are
based upon the ASDC methodology (reference \[12\]), which models real
systems through functional entities called abstract-objects.

> NOTES
>
> 1 Subsection 1.6.1 summarizes the terms and concepts defined in
> reference \[10\] and used here.
>
> 2 Subsection 1.6.3 extends the definitions of 1.6.1 to support
> specific aspects of the architecture model.

b\) A given port has identical structure and behavior independent of the
level where it is exposed. Port characteristics at SLE-System level are
described in 4.2.3; characteristics at SLE-Complex level are described
in 4.4.2.2, 4.4.2.3 and 4.4.2.4; characteristics at SLE-FG level are
described in 4.3.1.2 and 4.3.1.3.

**4.2 TOP-LEVEL ARCHITECTURE MODEL**

**4.2.1 ABSTRACT SLE SYSTEM ENVIRONMENT**

**4.2.1.1** The Space Mission Data System, described in section 3, can
be modeled as an abstract-object which is decomposed into a central
abstract-object, the SLE system, and two peripheral abstract-objects,
the space element and the MDOS. The SLE system interacts with both the
space element and the MDOS by means of a number of different ports, as
illustrated in figure 4-1.

NOTES

1 It is not within the scope of this Recommendation to describe the
functionality of the space element or of the MDOS.

2 The SLE system interacts with the space element and with the MDOS
through the ports which it exposes. These ports are described in 4.2.3.

3 In this Recommendation, the MDOS represents the mission-specific
ground systems that are directly involved with the day-to-day operations
of a mission spacecraft, and specifically, with the transfer of Space
Link data to or from the spacecraft via the SLE system. Thus the MDOS
includes the sources of forward data (e.g., telecommand packets), and
the sinks of return data (e.g., telemetry packets). Although it is
modeled as a single entity, in a real ground system the MDOS could
comprise many separate systems, including control centers or data
processing centers that handle CCSDS SL-DUs. However, other systems that
process, catalog, distribute, or archive mission data are not considered
in this discussion.

![](media/image14.pct){width="5.722222222222222in"
height="2.5972222222222223in"}

**Figure 4-1: Abstract Model of the SLE System Environment**

**4.2.1.2** **Definition: SLE System object**. An object of the type SLE
system performs the ground part of the data transfer between the space
element and the MDOS. This data transfer is an extension of the Space
Link data transfer, which is specified in Recommendations (references
\[2\]--\[7\]).

**4.2.2 PROVISION AND PRODUCTION OF SLE TRANSFER SERVICES**

**4.2.2.1 Definition: SLE Transfer Service Provision**. An SLE system is
said to *provide* an SLE transfer service when it exposes the operations
necessary to obtain the service. Provision of an SLE transfer service
implies making available to the service user the capability to obtain
the service. Provision involves the interface between the service user
and the service provider, and is characterized by what SLE data channels
are transferred, when they are transferred, and the quality of service
with which they are transferred (e.g., completely, reliably).

**4.2.2.2** **Definition: SLE Transfer Service Production**. In order to
provide an SLE transfer service, an SLE system must perform the
necessary transformations between the RF carrier channel and the SLE
data channels(s) to be transferred to/from the user of the SLE transfer
service. Performance of these transformations is called *production* of
the SLE transfer service.

**4.2.3 PORTS OF AN SLE SYSTEM**

An SLE system has Transfer Ports and Management Ports. Through its
Transfer Ports it receives or sends one or more space data channels. The
service provided by an SLE system at a Transfer Provider Port is called
an SLE transfer service. The SLE System Management Ports provide SLE
management services, which expose the operations required for
negotiation, monitoring and control of the production and provision of
SLE transfer services by the MDOS.

> a\) All SLE services are provided by asymmetric ports.
>
> b\) In describing SLE services, ports are designated as consumer
> (input) or supplier (output) to indicate the direction of space data
> flow.
>
> c\) Although ASDC terminology allows a service to be provided via
> several ports, each SLE service is defined as being provided at an
> interface of a single pair of ports, i.e., provided from a single port
> (instance) of one object to a single port (instance) of another
> object.

**4.2.3.1 Transfer Ports**

An SLE system may have multiple Transfer Ports of multiple Transfer Port
types. It usually has at least one return RF-signal port and/or one
forward RF-signal port. A Transfer Port is either a service-user port,
denoted T-U (for Transfer User Port), or a service-provider port,
denoted T-P (for Transfer Provider Port), but can not be both.

**4.2.3.1.1 Transfer User Port**

At a Transfer User Port, an SLE-System uses an SLE transfer service
provided by the space element. If the SLE transfer service used is a
return SLE transfer service, the port is a consumer of a return space
data channel. If the SLE transfer service used is a forward SLE transfer
service, the port is a supplier of a space data channel.

**4.2.3.1.2 Transfer Provider Port**

At a provider port, an SLE-System provides an SLE transfer service. If
the SLE transfer service provided is a return SLE transfer service, the
port is a supplier of a return space data channel. If the SLE transfer
service provided is a forward SLE transfer service, the port is a
consumer of a space data channel.

**4.2.3.1.3 Transfer Port Type**

A Transfer Port type is named for the type of space data channel that it
transfers.

**4.2.3.2 Management Ports**

**4.2.3.2.1** An SLE system may have multiple instances of Management
Ports. The SLE System Management Port Type is discussed further in the
cross-support view of the Architectural Model (4.4).

**4.2.3.2.2** Through its Management Ports, an SLE system exchanges
management information such as set-up or configuration related to the
supervision of the SLE transfer services provided by the SLE system at
its Transfer Provider Ports.

NOTE -- As described in 1.6.3, the convention in this Recommendation is
that for any abstract-object, one service-provider port provides one
(and only one) abstract service.

**4.3 ARCHITECTURE MODEL---FUNCTIONAL VIEW**

**4.3.1 FUNCTIONAL VIEW CONCEPTS**

**4.3.1.1 Functional Decomposition of SLE System**

**4.3.1.1.1** This reference model functional view is a decomposition,
or abstract refinement, of an SLE system that focuses on the functions
that provide SLE transfer services. In this view, the SLE data transfer
is implemented within the SLE system by abstract-objects called SLE-FGs.
Each SLE-FG performs a related set of functions that provide one or more
related SLE transfer services.

**4.3.1.1.2** **Definition: SLE-FG object**. An SLE-FG performs the
functions that transform SLE-SDUs from an SLE data channel of a given
type to produce and provide a related group of SLE transfer services.

**4.3.1.1.3** SLE-FGs are of one of eight types of abstract-object,
which fall into three categories: return SLE-FGs (listed in table 4-1),
forward AOS SLE-FGs (listed in table 4-2), and forward telecommand
SLE-FGs (listed in table 4-3). The management, such as set-up and
configuration, of SLE-FGs is performed by the SLE system.

NOTES

1 The eight SLE-FG types are described in more detail in 4.3.2. The
services provided by the SLE-FGs are described in section 5. The
rationale for the breakdown of the SLE system into the eight specific
SLE-FG types is provided in annex B.

2 The relationship between the management of SLE-FG and the
cross-support view of the SLE System Architectural Model is discussed in
4.4.

**Table 4-1: Return SLE Functional Groups**

  -----------------------------------------------------------------------
  Return Space Link Processing SLE-FG

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

  -----------------------------------------------------------------------
  Return Frame Processing SLE-FG

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

  -----------------------------------------------------------------------
  Return Frame Data Extraction SLE-FG

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

**Table 4-2: Forward AOS SLE-FG**

  -----------------------------------------------------------------------
  Forward AOS VC Data Insertion SLE-FG

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

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

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

  -----------------------------------------------------------------------
  Forward AOS Space Link Processing SLE-FG

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

**Table 4-3: Forward Telecommand SLE-FG**

  -----------------------------------------------------------------------
  Forward TC VC Data Insert SLE-FG

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

  -----------------------------------------------------------------------
  Forward CLTU Generation SLE-FG

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

  -----------------------------------------------------------------------
  Forward TC Space Link Processing SLE-FG

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

**4.3.1.2 Ports of an SLE-FG**

An SLE-FG may have multiple instances of multiple types of Transfer
Ports through which it provides one or more SLE transfer services. An
SLE-FG has one Function-Management Port through which it exchanges
management information such as set-up or configuration relative to the
supervision of the SLE transfer services provided by the SLE-FG at its
Transfer Provider Ports. An illustration of an SLE-FG is given in figure
4-2.

NOTES

1 As described in 1.6.3, the convention in this Recommendation is that
for any abstract-object, one service-provider port provides one (and
only one) instance of abstract service.

2 Because the focus of this section is on the functions that produce SLE
transfer services, there is no further discussion of service management
here. Management of SLE services is discussed in the cross-support view
of the architecture model in the SLE Service Management specification
and in section 5, Specification of SLE services.

**Figure 4-2: Ports of an SLE-FG**

**4.3.1.2.1 SLE-FG Transfer User Port**

At a Transfer User Port, an SLE-FG uses an SLE transfer service provided
by another SLE-FG, or by the space element. If the SLE transfer service
used is a return SLE transfer service, the port is a consumer of a
return space data channel. If the SLE transfer service used is a forward
SLE transfer service, the port is a supplier of a space data channel.

**4.3.1.2.2 SLE-FG Transfer Provider Port**

At a provider port, an SLE-FG provides an SLE transfer service. If the
SLE transfer service provided is a return SLE transfer service, the port
is a supplier of a return space data channel. If the SLE transfer
service provided is a forward SLE transfer service, the port is a
consumer of a space data channel.

**4.3.1.3 Binding Rules of SLE-FG Transfer Ports**

Pairs of (instances of) SLE-FG Transfer Ports may be bound, as
illustrated in figure 4-3, in the following ways:

> a\) a Transfer User Port (of a given type) is bound to a Transfer
> Provider Port (of the same type) of another SLE-FG, or to the space
> element;
>
> b\) a Transfer Provider Port (of a given type) is bound to a Transfer
> User Port (of the same type) of another SLE-FG, or of a MUE within the
> MDOS;
>
> c\) each instance of service is provided on a separate pair of
> (instances of) SLE-FG Transfer Ports.

![](media/image15.pct){width="5.666666666666667in"
height="2.2222222222222223in"}

**Figure 4-3: Interconnection of SLE-FGs Ports**

**4.3.2 INTRODUCTION TO SPECIFIC SLE FUNCTIONAL GROUPS**

**4.3.2.1 RETURN SLE Functional Groups**

> a\) There are three Functional Groups (FGs) that provide return SLE
> services:
>
> 1\) Return Space Link Processing;
>
> 2\) Return Frame Processing;
>
> 3\) Return Frame Data Extraction.
>
> b\) These are illustrated in figure 4-4, below, and are described in
> the three subsections that follow. In figure 4-4, all services exposed
> between FGs are available to the MDOS, including the two services used
> for cross support between FGs (RAF and Return VC Frames).
>
> c\) In each subsection, the services provided by that FG are
> identified, followed by the functions performed by that FG in order to
> produce those services. Each FG is formally defined as providing all
> of the services listed and performing all of the functions listed.
> Real implementations of the FGs may provide all or only a subset of
> these services, and consequently may perform all or only a subset of
> the functions identified. The applicable SLE service specifications
> define the relationship between services implemented and functionality
> required to produce those services.

![](media/image16.pct){width="6.430555555555555in"
height="2.1527777777777777in"}

**Figure 4-4: Return Functional Groups**

**4.3.2.1.1 Return Space Link Processing SLE-FG**

> a\) The Return Space Link Processing SLE-FG provides the following
> services:
>
> 1\) RAF service, which delivers the RAF SLE data channel resulting
> from a single physical channel.
>
> 2\) Return Insert service, which delivers the Return Insert SLE data
> channel from a single physical channel. Return Insert service is
> delivered in online mode only.
>
> b\) The Return Space Link Processing SLE-FG performs the following
> functions:
>
> 1\) utilizes the underlying antenna steering capabilities of the
> ground element and acquires the RF carrier channel;
>
> 2\) demodulates the RF carrier channel into one or more physical
> channels, each of which consists of a digital symbol stream;
>
> 3\) frame synchronizes and extracts CCSDS frames from each physical
> channel;
>
> 4\) error-decodes the frames and corrects the correctable errors:
> error decoding includes convolutional decoding (optionally applied),
> bit derandomization (optionally applied), Reed-Solomon decoding
> (optionally applied) and cyclic redundancy check (CRC) decoding
> (optionally applied);
>
> NOTES
>
> 1 Depending upon the implementation, convolutional decoding may be
> applied before or after frame synchronization.
>
> 2 SLE Return Space Link Processing requires that at any given time,
> the coding options must be the same for all frames on the physical
> channel. In some cases, this is more restrictive than the constraints
> imposed by the corresponding Space Link Recommendations. In
> particular, Reed-Solomon coding must be present or absent on all of
> the frames on the physical channel; that is, there cannot be a
> concurrent mix of some frames with Reed-Solomon coding and some frames
> without.
>
> 5\) annotates each frame to form an RAF SLE-SDU;
>
> 6\) injects the resulting RAF SLE-SDU into the RAF channel associated
> with the physical channel from which the frame was originally
> extracted;
>
> NOTE -- The RAF channel also contains service control information not
> carried in the RAF SLE-DUs.
>
> 7\) for an RAF channel containing a Return Insert Space Link data
> channel, decommutates the complete insert zone from every frame within
> the physical channel, annotates each insert zone to form a Return
> Insert SLE-SDU, and injects the resulting Return Insert SLE-SDUs into
> the Return Insert SLE data channel identified by the RAF Channel ID;
>
> 8\) stores sufficient data to subsequently reconstruct the RAF SLE
> data for delivery through one or more offline SLE service instances;
>
> 9\) retrieves stored data and reconstructs the RAF SLE data channel
> for delivery through one or more offline SLE service instances;
>
> 10\) performs telecommunication functions necessary to supply the
> Return Space Link Processing SLE data channels (RAF, Return Insert)
> through both online and offline SLE service instances.

**4.3.2.1.2 Return Frame Processing SLE-FG**

> a\) The Return Frame Processing SLE-FG provides the following
> services:
>
> 1\) Return Master Channel (MC) Frame service, which delivers one
> Master Channel (Master SLE data channel) demultiplexed from a
> particular RAF channel;
>
> 2\) Return Master Channel Operational Control Field (MC-OCF) service,
> which delivers one Operational Control Field SLE data channel
> decommutated from its associated Master Channel;
>
> 3\) Return Master Channel Frame Secondary Header (MC-FSH) service,
> which delivers one Frame Secondary Header SLE data channel
> decommutated from its associated Master Channel;
>
> 4\) Return Virtual Channel Frame (VC Frame) Service, which delivers
> one Virtual Channel (Virtual SLE data channel) demultiplexed from a
> particular MC channel;
>
> 5\) Return Virtual Channel Operational Control Field (VC-OCF) service,
> which delivers one Operational Control Field SLE data channel
> decommutated from its associated Virtual Channel;
>
> 6\) Return Virtual Channel Frame Secondary Header (VC-FSH) service,
> which delivers one Frame Secondary Header SLE data channel
> decommutated from its associated Virtual Channel; and
>
> b\) The Return Frame Processing SLE-FG performs the following
> functions:
>
> 1\) consumes a single RAF SLE data channel;
>
> 2\) demultiplexes the RAF channel into its component Master Channels,
> each identified by its Master Channel ID (MCID = Frame Version Number
> and SCID), annotates each MC Frame in the Master Channel to form an MC
> Frame SLE-SDU, and injects the resulting MC Frame SLE-SDUs into the
> Master Channel SLE data channels;
>
> 3\) demultiplexes each Master Channel into its component Virtual
> Channels, each identified by its Global Virtual Channel ID (GVCID =
> MCID and VCID), annotates each VC Frame in the Virtual Channel to form
> a VC Frame SLE-SDU, and injects the resulting VC Frame SLE-SDUs into
> the Virtual Channel SLE data channels;
>
> 4\) for a Master Channel containing an MC-OCF Space Link data channel,
> decommutates the OCF field from each MC Frame, annotates the OCF field
> data to form an MC-OCF SLE-SDU, injects the resulting MC-OCF SLE-SDUs
> into their respective MC-OCF SLE data channels;
>
> 5\) for a Master Channel containing an MC-FSH Space Link data channel,
> decommutates the FSH field from each MC Frame, annotates the FSH field
> data to form an MC-FSH SLE-SDU, and injects the resulting MC-FSH
> SLE-SDUs into their respective MC-FSH SLE data channels;
>
> 6\) for a Virtual Channel containing a VC-OCF Space Link data channel,
> decommutates the OCF field from each VC Frame, annotates the OCF field
> data to form a VC-OCF SLE-SDU, and injects the resulting VC-OCF
> SLE-SDUs into their respective VC-OCF SLE data channels;
>
> 7\) for a Virtual Channel containing a VC-FSH Space Link data channel,
> decommutates the FSH field from each VC Frame, annotates the FSH field
> data to form a VC-FSH SLE-SDU, and injects the resulting VC-FSH
> SLE-SDUs into their respective VC-FSH SLE data channels;
>
> 8\) stores sufficient SLE data to support the subsequent
> reconstruction of one or more space data channels of the following
> types:
>
> -- Master Channel;
>
> -- Virtual Channel;
>
> -- MC-OCF;
>
> -- MC-FSH;
>
> -- VC-OCF;
>
> -- VC-FSH;
>
> storage of SLE data may be performed relative to the source RAF SLE
> data channel or relative to the individual product SLE data channels;
>
> NOTE -- Storage of SLE data relative to the source RAF SLE data
> channel does not require the MDOS to specify the specific channels to
> be retrieved before the Space Link session occurs, and is therefore
> more flexible than storage relative to the individual product SLE data
> channels (which requires the MDOS to identify at or before the
> execution of the Space Link session the specific SLE data channels
> that are to be subsequently delivered via offline service instance).
> However, some implementations may not have sufficient resources to
> store the equivalent of complete RAF SLE data channels, and may
> therefore only be able to store the product SLE data.
>
> 9\) retrieves stored SLE data and reconstructs specified Return Frame
> Processing SLE data channels (MC Frame, VC Frame, MC-OCF, MC-FSH,
> VC-OCF, VC-FSH) for delivery through offline SLE service instances;
>
> 10\) performs telecommunication functions necessary to supply the
> Return Frame Processing SLE data channels (MC Frame, VC Frame, MC-OCF,
> MC-FSH, VC-OCF, VC-FSH) through both online and offline SLE service
> instances.

**4.3.2.1.3 Return Frame Data Extraction SLE-FG**

> a\) The Return Frame Data Extraction SLE-FG provides the following
> services:
>
> 1\) Return Bitstream service, which delivers one Bitstream SLE data
> channel decommutated from its associated Version-2 VC Frame channel;
> and
>
> 2\) RSP service, which delivers a set of RSP SLE data channels
> demultiplexed from a single Version-1 or Version-2 VC Frame channel.
> The RSPs are delivered in the sequence in which they were put into the
> virtual channel frames by the space element.
>
> NOTE -- Version-2 VC Frame channels may carry space packets
> encapsulating ISO Connectionless Network Protocol (CLNP) PDUs, as
> defined in the AOS Internet service specification (section 4 of
> reference \[4\]). These Internet-Encapsulation space packets are
> designated by Application Process ID (APID) 2046. The SLE system
> supports the AOS Internet service through the return and forward Space
> Packet services: encapsulation, de-encapsulation, and relaying of ISO
> CLNP PDUs is strictly a function of the MDOS.
>
> b\) The Return Frame Data Extraction SLE-FG performs the following
> functions:
>
> 1\) The Return Frame Data Extraction SLE-FG consumes VC Frame
> channels.
>
> 2\) For a VC Frame channel that carries Bitstream data, the Return
> Frame Data Extraction SLE-FG extracts the Bitstream PDUs (B-PDUs) from
> each Version-2 VC Frame SLE-SDU, annotates each B-PDU to form a
> Bitstream SLE-SDU, and
>
> injects the resulting SLE-SDUs into the Bitstream SLE data channel
> identified by the GVCID of the parent Virtual Channel.
>
> 3\) For a VC Frame channel that carries multiplexed packets, the
> Return Frame Data Extraction SLE-FG demultiplexes CCSDS Packets from
> the VC Frame SDUs of that data channel.
>
> 4\) For CCSDS Space Packets, the Return Frame Data Extraction SLE-FG
> annotates the Space Packets to form RSP SLE-SDUs and injects the
> resulting RSP SLE-SDUs into their respective RSP SLE data channels.
> The RSP SLE data channel is identified by its Space Packet Channel ID
> (SPCID), which is the combination of Frame Version Number, SCID, VCID,
> and APID. An RSP is defined as being:
>
> -- a CCSDS packet carried by a Packet Telemetry (Version-1) Virtual
> Channel (reference \[2\]), or
>
> -- a CCSDS packet carried by an AOS (Version-2) Virtual Channel, with
> APID in the range (0-2031, 2046) (reference \[4\]).
>
> NOTE -- In specifying the set of RSPs to be delivered via a single RSP
> service instance, the user will provide a list of SPCIDs to be
> delivered.
>
> 5\) The Return Frame Data Extraction SLE-FG stores sufficient SLE data
> to support the subsequent reconstruction of one or more Return
> Bitstream or RSP SLE data channels. Storage of SLE data for the
> reconstruction of RSP SLE data channels may be performed relative to
> the source VC Frame channel or relative to the resultant RSP SLE data
> channels.
>
> NOTE -- Storage of SLE data relative to the source VC Frame channel
> does not require the MDOS to specify the specific RSP channels to be
> retrieved before the Space Link session occurs, and is therefore more
> flexible than storage relative to the resultant RSP SLE data channels
> (which requires the MDOS to identify at or before the execution of the
> Space Link session the specific RSP SLE data channels that are to be
> subsequently delivered via offline service instance). However, some
> implementations may not have sufficient resources to store the
> equivalent of complete VC Frame channels, and may therefore only be
> able to store the resultant RSP SLE data.
>
> 6\) The Return Frame Data Extraction SLE-FG retrieves stored SLE data
> and reconstructs specified Return Bitstream and RSP SLE data channels
> for delivery through offline SLE service instances.
>
> 7\) The Return Frame Data Extraction SLE-FG performs
> telecommunications functions necessary to supply the Return Bitstream
> and RSP SLE data channels through both online and offline service
> instances.

**4.3.2.2 FORWARD AOS SLE Functional Groups**

> a\) There are two FGs that provide AOS Forward SLE services:
>
> 1\) Forward AOS VC Data Insertion;
>
> 2\) Forward AOS Space Link Processing.
>
> b\) These are illustrated in figure 4-5 below, and are described in
> the two subsections that follow. In figure 4-5, all services exposed
> between FGs are available to the MDOS, including the protoVCDU service
> used for cross-support between the two FGs.

![](media/image17.pct){width="4.569444444444445in"
height="2.1527777777777777in"}

**Figure 4-5: AOS Forward Functional Groups**

**4.3.2.2.1 Forward AOS VC Data Insertion SLE-FG**

> a\) The Forward AOS VC Data Insertion SLE-FG provides the following
> services:
>
> 1\) Forward Bitstream service, which receives a Bitstream SLE data
> channel from the MDOS;
>
> 2\) Forward VCA service, which receives a VCA SLE data channel from
> the MDOS; and
>
> 3\) Forward Space Packet service, which receives Forward Space Packet
> data channels from the MDOS.
>
> b\) The Forward AOS VC Data Insertion SLE-FG performs the following
> functions:
>
> 1\) For each Forward Bitstream service instance, the Forward AOS VC
> Data Insertion SLE-FG consumes one Bitstream SLE data channel,
> extracts the Bitstream PDU (B-PDU) from each Bitstream SLE-SDU in the
> data channel, creates a protoVCDU encapsulating the B-PDU, and injects
> the resulting protoVCDU into the ProtoVCDU SLE data channel. A
> protoVCDU contains the VCDU primary header (without VCDU Header Error
> Control) and the VCDU Data Unit Zone.
>
> 2\) For each Forward VCA service instance, the Forward AOS VC Data
> Insertion SLE-FG consumes one Forward VC Frame SLE data channel,
> extracts the VCA-SDU from each VCA SLE-SDU in the data channel,
> creates a protoVCDU encapsulating the VCA-SDU, and injects the
> resulting protoVCDU into the protoVCDU SLE data channel.
>
> 3\) For each Forward Space Packet service instance, the Forward AOS VC
> Data Insertion SLE-FG consumes one or more Forward Space Packet data
> channels associated with a single Virtual Channel, extracts the CCSDS
> packets from the Forward Space Packet SLE-SDUs in each data channel,
> multiplexes the CCSDS Packets into protoVCDUs, and injects the
> resulting protoVCDUs into the appropriate protoVCDU SLE data channel.
>
> NOTE -- Version-2 VCA SLE data channels may carry space packets
> encapsulating ISO CLNP PDUs, as defined in the AOS Internet service
> specification (section 4 of reference \[4\]). These
> Internet-Encapsulation space packets are designated by APID 2046. The
> SLE system supports the AOS Internet service through the Return and
> Forward Space Packet services: encapsulation, de-encapsulation, and
> relaying of ISO CLNP PDUs is strictly a function of the MDOS.
>
> 4\) The Forward AOS VC Data Insertion SLE-FG performs storage and
> telecommunications functions necessary to supply the protoVCDU SLE
> data channels to the Forward AOS Insert and Coding FG through both
> online and offline service instances.

**4.3.2.2.2 Forward AOS Space Link Processing SLE-FG**

> a\) The Forward AOS Space Link Processing SLE-FG provides the
> following services:
>
> 1\) Forward ProtoVCDU service, which receives a protoVCDU SLE data
> channel;
>
> 2\) Forward Insert service, which receives a Forward AOS Insert SLE
> data channel; and
>
> 3\) Forward C/VCDU service, which receives C/VCDU SLE data channels.
>
> b\) The Forward AOS Space Link Processing SLE-FG performs the
> following functions:
>
> 1\) for each Forward protoVCDU service instance, consumes one
> protoVCDU SLE data channel;
>
> 2\) for each forward Insert service instance, consumes one forward
> Insert SLE data channel and extracts the Insert Zones from the forward
> Insert SLE-SDUs;
>
> 3\) for each protoVCDU SLE data channel destined for a forward
> physical channel carrying an Insert channel, synchronously commutates
> the Insert Zones destined for that physical channel into the
> protoVCDUs;
>
> 4\) performs Reed-Solomon and/or CRC error encoding (as required) on
> each protoVCDU required for that virtual channel and multiplexes the
> resulting C/VCDU into its respective forward All AOS Frames SLE data
> channel;
>
> 5\) if a protoVCDU is not available to carry a received Insert Zone,
> generates a Fill VCDU to carry the Insert Zone, performs the error
> encoding required for that Fill virtual channel, and multiplexes the
> resulting C/VCDU into its respective (fill) forward All AOS Frames SLE
> data channel;
>
> 6\) for each forward C/VCDU service instance, consumes forward C/VCDU
> SLE data channels;
>
> 7\) multiplexes the C/VCDUs into their respective Forward All AOS
> Frames SLE data channel;
>
> 8\) performs bit-randomization (as required), attaches sync markers,
> and synchronously multiplexes the C/VCDUs in a forward All AOS Frames
> SLE data channel into a physical channel;
>
> 9\) as required, convolutionally encodes the stream of bits on the
> physical channel;
>
> 10\) utilizes the underlying antenna steering capabilities provided by
> the ground element;
>
> 11\) modulates the bit/symbol stream onto an RF carrier channel and
> radiates the signal to the space element.

**4.3.2.3 Forward TC SLE Functional Groups**

> a\) There are three FGs that provide Forward TC SLE services:
>
> 1\) Forward TC VC Data Insertion;
>
> 2\) Forward CLTU Generation;
>
> 3\) Forward TC Space Link Processing.
>
> b\) These are illustrated in figure 4-6 below, and are described in
> the three subsections that follow. In figure 4-6, all services exposed
> between FGs are available to the MDOS, including the services used for
> cross support between the FGs (Forward TC Frame and CLTU).

![](media/image18.pct){width="6.097222222222222in"
height="2.4027777777777777in"}

**Figure 4-6: Forward Telecommand Functional Groups**

**4.3.2.3.1 Forward TC VC Data Insertion SLE-FG**

> a\) The Forward TC VC Data Insertion SLE-FG provides the following
> services:
>
> 1\) Forward Telecommand VCA (TC-VCA) service, which receives a TC-VCA
> SLE data channel. A TC-VCA SLE data channel carries user-defined TC
> Frame Data Units (see 3.2.1 in reference \[6\]), and control
> information or annotation including GVCID of the Virtual Channel that
> is to be used to carry those Forward TC Frame Data Units.
>
> NOTE -- The Forward TC-VCA service operates at a virtual-channel
> level. Any structuring of the data within the TC Frame Data Unit (for
> example, the use of Multiplexer Access Points to provide segmentation
> for the user data contained in the TC Frame Data Unit) is part of the
> MDOS processing and is outside the scope of the Forward TC-VCA
> service.
>
> 2\) Forward Space Packet service, which receives forward Space Packet
> SLE data channels.
>
> b\) The Forward TC VC Data Insertion SLE-FG performs the following
> functions:
>
> 1\) For each forward TC-VCA service instance, the Forward TC VC Data
> Insertion SLE-FG consumes one TC-VCA SLE data channel, extracts the TC
> Frame Data Unit from each TC-VCA SLE-SDU in the data channel, creates
> a Telecommand Transfer Frame encapsulating the TC Frame Data Unit, and
> supplies the TC Frame SLE data channel in the form of blocks of one or
> more TC Transfer Frames. If the Frame is to be sent using the
> Sequence-controlled service option of the Command Operation Procedure
> (COP), the Forward TC VC Data Insertion SLE-FG sets the Frame Sequence
> Count and buffers a copy of the TC Transfer Frame.
>
> 2\) For each Forward Space Packet service instance, the Forward TC VC
> Data Insertion SLE-FG consumes one or more Forward Space Packet data
> channels, extracts the CCSDS packets from the Forward Space Packet
> SLE-SDUs in each data channel, blocks or segments the CCSDS Packets
> into Telecommand Transfer Frames, and supplies the TC Frame SLE data
> channel in the form of blocks of one or more TC Transfer Frames. If
> the Frame is to be sent using the Sequence-controlled service option
> of the Command Operation Procedure (COP), the TC VC Data Insertion
> SLE-FG sets the Frame Sequence Count and buffers a copy of the TC
> Transfer Frame. Segmented packets cannot be sent without sequence
> control.
>
> NOTE -- If both the Forward TC-VCA and Forward Space Packet services
> are active in a single virtual channel, only one can be sequence
> controlled.
>
> 3\) The Forward TC VC Data Insertion SLE-FG consumes MC-OCF or VC-OCF
> SLE data channels and extracts the Command Link Control Words (CLCWs).
> Based on the values in the CLCW, the Forward TC VC Data Insertion
> SLE-FG retransmits or deletes buffered TC Transfer Frames.
>
> 4\) The Forward TC VC Data Insertion SLE-FG performs storage and
> telecommunications functions necessary to supply the TC Frame SLE data
> channels to the Forward CLTU Generation FG through both online and
> offline service instances. In addition, it prepares and transmits
> buffers of TC data containing PDUs from the TC transfer layer (i.e.,
> one or more TC transfer frames).

**4.3.2.3.2 Forward CLTU Generation SLE-FG**

> a\) The Forward CLTU Generation SLE-FG provides the Forward
> Telecommand Frame service, which receives at least one Forward TC
> Frame SLE data channel.
>
> b\) The Forward CLTU Generation SLE-FG performs the following
> functions:
>
> 1\) consumes Telecommand Frame SLE data channels supplied as blocks of
> one or more TC Frames for transmission via a single CLTU;
>
> 2\) optionally, bit-randomizes the block of TC frames to ensure
> adequate zero-one transitions;
>
> 3\) BCH-encodes each block of TC frames into a set of TC Code blocks;
>
> 4\) forms a CLTU by appending Start and Tail sequences to the TC Code
> blocks representing the block of TC frames;
>
> 5\) injects the resulting CLTU into its respective CLTU SLE data
> channel; and
>
> 6\) performs the necessary storage and telecommunication functions
> necessary to supply the CLTU SLE data channel to the Forward TC Space
> Link Processing FG through both online and offline service instances.

**4.3.2.3.3 Forward TC Space Link Processing SLE-FG**

> a\) The Forward TC Space Link Processing SLE-FG provides the Forward
> CLTU service, which receives one CLTU SLE data channel.
>
> b\) The Forward TC Space Link Processing SLE-FG performs the following
> functions:
>
> 1\) for each Forward CLTU service instance, consumes a CLTU SLE data
> channel;
>
> 2\) consumes MC-OCF or VC-OCF SLE data channels which contain CLCWs;
> based on the values in the CLCW, the Forward TC Space Link Processing
> SLE-FG determines whether the physical channel is available;
>
> 3\) generates Acquisition and Idle Sequences on the asynchronous
> physical channel in accordance with the Physical Link Operations
> Procedure (PLOP) in effect;
>
> 4\) injects the CLTUs into the asynchronous physical channel;
>
> 5\) utilizes the underlying antenna steering capabilities provided by
> the ground element;
>
> 6\) modulates the resulting stream of bits to RF and radiates the
> signal to the space element.

**4.4 ARCHITECTURE MODEL---CROSS-SUPPORT VIEW**

**4.4.1 CROSS-SUPPORT VIEW CONCEPTS**

> a\) Real SLE systems are often made up of several physical systems
> that interoperate to provide SLE services to a space mission. These
> physical systems may be independently operated by different Agencies
> or by different organizational elements within an Agency. In the
> cross-support view, each such physical system is modeled as an SLE
> Complex.
>
> b\) **Definition: SLE Complex**. An SLE Complex is a set of SLE-FGs
> under a single management authority. At the time of cross support, an
> SLE complex has a single established relationship between the SLE
> system and the MDOS.
>
> c\) From a mission cross-support view, the SLE system is composed of
> one or more SLE Complexes as illustrated in figure 4-7.

![](media/image19.pct){width="6.625in" height="2.9305555555555554in"}

**Figure 4-7: SLE Complexes**

NOTES

1 From the management perspective of the MDOS, the SLE system appears to
be decomposed into several (non-overlapping) SLE Complexes.

2 An SLE Complex is a representation of a real system, as viewed by the
MDOS of a space mission. However, issues related to the sharing of real
systems shared by multiple missions are beyond the scope of this
reference model.

3 None of the entities described above are intended to imply particular
implementations or particular physical or administrative affiliations.

**4.4.1.1 SLE Utilization Management**

All SLE Complexes within an SLE system interface to a single entity
within the MDOS called the SLE Utilization Management, as illustrated in
figure 4-8. The SLE Utilization Management arranges for forward and
return SLE transfer services data with the SLE Complexes and monitors
the transfer process. The SLE Utilization Management is part of the
Mission Management Entity, which coordinates the activities of the Space
and ground elements on behalf of a mission.

NOTES

1 The SLE Utilization Management is an abstraction of the entities
within a real ground system that are involved in managing real SLE
Complexes for a particular mission. This Recommendation does not make
any assumptions about how this SLE Utilization Management is implemented
in real systems.

2 The SLE Utilization Management is identified to acknowledge that the
Mission Management Entity has many aspects that are outside the scope of
SLE.

![](media/image20.pct){width="7.0in" height="2.9166666666666665in"}

**Figure 4-8: Mission and SLE Utilization Management**

> NOTE -- None of the entities described above are intended to imply
> particular implementations or particular physical or administrative
> affiliations.

**4.4.1.2 SLE Service Package**

**4.4.1.2.1** **Definition: SLE Transfer Service Instance**. An SLE
transfer service instance is the provision by an SLE Complex of the
capability to transfer one or more SLE data channels of a given type,
all of which are related to the same Space Link Session.

**4.4.1.2.2** **Definition: SLE Service Package**. An SLE Service
Package is the set of instances of SLE transfer services, together with
the specification of the characteristics of the production of those SLE
Service Instances, that are provided by one SLE Complex to one or more
SLE transfer service users. The on-line SLE transfer services are
restricted to one Space Link Session.

**4.4.1.2.3** An SLE Service Package may contain multiple SLE service
instances of multiple SLE services. SLE Utilization Management and the
SLE Complex prepare the mutually agreed SLE Service Package(s) to be
supported by the SLE Complex. The SLE Service Package contains a
schedule for the execution of the production of the SLE data channels,
and for the provision of the SLE transfer service instances.

NOTES

1 SLE Service User above is either another SLE Complex (belonging to the
same SLE system) or a MUE.

2 "Provide" is used in the sense of "make available to be used" and does
not necessarily imply that the service is being used.

3 In cases where the SLE system comprises two or more SLE complexes, an
SLE Service Package specifies the characteristics of only part of the
production of the SLE transfer services that are provided to the MDOS,
namely, that subset of the production that is performed by the SLE
Complex that provides the SLE Service Package. The remaining production
is specified in other SLE Service Packages, and is performed by other
SLE Complexes.

4 Management, i.e., negotiation, scheduling, and control, of SLE Service
Packages is further discussed in the SLE Service Management
specification.

**4.4.2 MODEL OF SLE COMPLEX**

**4.4.2.1 SLE Complex Objects**

**4.4.2.1.1** **Definition: SLE Complex abstract-object type**. An SLE
Complex comprises one or more instances of SLE-FGs, of one or more
SLE-FG types. An SLE Complex also contains a management entity, called
the SLE Complex Management, which coordinates the activities of the
SLE-FGs pertaining to the SLE Complex on behalf of the SLE Utilization
Management. An SLE Complex is illustrated in figure 4-9.

**4.4.2.1.2** **Definition: SLE Complex Management** **abstract-object
type**. An SLE Complex Management negotiates the provision of SLE
Service Packages with the SLE Utilization Management and controls and
monitors the production and provision of SLE transfer service instances
by the SLE-FGs belonging to the SLE Complex. An SLE Complex Management
exchanges, with the SLE Utilization Management, set-up and configuration
parameters required for the provision of the SLE transfer service
instances. An SLE Complex Management distributes these parameters to the
SLE-FGs and coordinates their activities for the provision of the SLE
transfer service instances. An SLE Complex Management collects from the
SLE-FGs reporting information, consolidates it, and forwards it to the
SLE Utilization Management.

NOTE -- The interactions between the SLE Complex Management and the SLE
Utilization Management are discussed in the SLE Service Management
specification.

![](media/image21.pct){width="4.694444444444445in" height="3.375in"}

**Figure 4-9: An Example of SLE Complex Ports**

NOTE -- The SLE Complex shown in figure 4-9 is assumed to interface with
other SLE Complexes or the Space Link to its left, and with other SLE
Complexes or the MDOS to its right. The SLE Complex can receive return
data (through a user port on the left) and can send that return data
toward the MDOS, potentially via other SLE Complexes (through a provider
port on the right). It can receive forward data (through a provider port
on the right), and can send that forward data toward the spacecraft,
potentially via other SLE Complexes (through a user port on the left).

**4.4.2.2 Ports of an SLE Complex**

The SLE Complex exposes two or more Transfer Ports (possibly of
different types, but at least one user port and one provider port) and a
single Complex Management Port. The Ports of an SLE Complex are
illustrated in figure 4-9, above.

**4.4.2.2.1 Ports of an SLE Complex Management**

**4.4.2.2.1.1** The SLE Complex Management and the SLE Utilization
Management function of the MDOS share a single Complex Management
association via a Complex Management port pair. At the Complex
Management Port, the SLE Complex Management exposes management
operations as required for negotiation, provision, monitoring and
control of the SLE transfer services being provided by the SLE Complex.

NOTE -- Because an SLE Complex is a virtual entity dedicated to a single
space mission, by definition it has only a single instance of a Complex
Management port. However, an SLE Complex is realized by a "real" system
(i.e., a "real SLE Complex") that may provide SLE services to multiple
space missions. In such cases, the management entity for the "real SLE
Complex" exposes a dedicated Complex Management port for each space
mission supported.

**4.4.2.2.1.2** The SLE Complex Management also exposes (within the SLE
Complex) one or more FG Management Ports. The SLE Complex Management FG
Management Ports are of the same type as the SLE-FG Management Ports and
match, by pair, the SLE Complex's SLE-FG Management Ports.

**4.4.2.2.1.3** The Ports of an SLE Complex Management are illustrated
in figure 4-9, above.

NOTE -- At an SLE Complex Management Port, an SLE Complex exposes
operations that can be invoked by SLE Utilization Management to exchange
management information. Incoming management information carries
information that influences the behavior of the SLE Complex. Outgoing
management information carries information that reflects the status of
the FGs.

**4.4.2.2.2 Transfer Ports of an SLE Complex**

The SLE Complex Transfer Ports are defined as being the collection of
the SLE Complex's SLE-FG Transfer Ports.

NOTE -- Not all SLE-FG Transfer Ports of an SLE Complex need be exposed
as SLE Complex Transfer Ports. For instance, if an SLE-UM has negotiated
an SLE RtnSpacePkt service (based on an RF signal input) with an SLE
Complex, within the SLE Complex several SLE-FGs are cascaded, but only
the RF signal and RtnSpacePkt Transfer Port are exposed externally to
the SLE Complex.

**4.4.2.2.3 Binding Rules for SLE Complex Ports**

SLE Complex ports may be bound as illustrated in figures 4-10 and 4-11,
in the following ways:

> a\) a user port (of a given type) is bound to a provider port (of the
> same type) of another SLE Complex, or to the space element via the
> Space Link;
>
> b\) a provider port (of a given type) is bound to a user port (of the
> same type) of another SLE Complex, or of a MUE within the MDOS;
>
> c\) a single SLE Complex Management port is bound to a single
> management port of an SLE Utilization Management.

![](media/image22.pct){width="5.611111111111111in"
height="2.1527777777777777in"}

**Figure 4-10: Binding SLE Complex Transfer Ports**

![](media/image23.pct){width="5.597222222222222in"
height="3.388888888888889in"}

**Figure 4-11: Binding of SLE Complex Management Ports**

**4.4.3 SLE SERVICE AGREEMENT**

An SLE Service Agreement specifies the SLE transfer and management
services to be provided to the MDOS by an SLE Complex, and the
conditions under which those SLE transfer services will be provided.
There is only one SLE Service Agreement in effect between a particular
SLE Complex and a particular mission (represented by an MDOS) at any one
time, but there could be more than one SLE Service Agreement over the
lifetime of the mission.

NOTE -- Figure 4-12 shows an example of a mission supported by two SLE
Complexes. The MDOS thus has two SLE Service Agreements, one with each
of the supporting complexes. Through its management ports, the SLE
Utilization Management negotiates SLE service packages with each of the
SLE Complexes.

The SLE Complex management of each SLE Complex has two roles:

> a\) negotiates the provision of SLE service packages with the SLE
> Utilization Management; and
>
> b\) sets up, monitors, and controls the production of the services
> specified in the SLE service packages.

![](media/image24.pct){width="6.236111111111111in"
height="3.5694444444444446in"}

**Figure 4-12: Composite Example of SLE Management**

5 SPECIFICATION OF SLE SERVICES

**5.1 PURPOSE AND ORGANIZATION**

**5.1.1** This section provides direction for specification of the
individual SLE services, within the framework of the architecture model
presented in section 4, in which SLE FGs and SLE Complexes are modeled
as ASDC (abstract) objects. The provision of SLE services is formally
described in terms of the *abstract ports* (*ports*) exposed by these
objects and the *abstract operations* (*operations*) invoked at those
ports.

**5.1.2** Subsection 5.2 defines an ASDC model of an SLE service,
including identification of the types of operations that underlie SLE
services.

**5.1.3** Subsection 5.3 provides a template for writing SLE transfer
service specifications. These specifications will be provided in
separate Recommendations.

**5.1.4** Subsection 5.4 identifies the ports and operations associated
with the SLE transfer services and defines the SLE Objects that contain
them.

**5.1.5** Subsection 5.5 identifies the ports and operations associated
with the SLE management service and defines the SLE Objects that contain
them.

**5.1.6** Subsection 5.6 defines the *production* of each SLE transfer
service. As stated earlier, an SLE transfer service is produced by one
or more FGs and involves multiple Transfer ports and one or more
Management ports. The production of an SLE transfer service may or may
not be carried out by a single SLE complex: it is an abstract
specification of the elements required to bring the service to fruition.

**5.2 ABSTRACT MODEL OF SLE SERVICE**

**5.2.1 SLE SERVICE DESCRIPTION**

**5.2.1.1** An SLE service is modeled as an ASDC abstract service. Thus
an SLE service is described by the set of operations that can be invoked
and performed through a pair of ports that constitute an interface
between two objects. As noted in 1.6.1, the pair of ports must be bound,
and to be bound, they must be of the same type. See figure 5-1.

![](media/image25.pct){width="4.236111111111111in"
height="1.4861111111111112in"}

**Figure 5-1: Abstract Model of an SLE Service**

**5.2.1.2** The types of operations that can be exposed at SLE Transfer
ports and SLE management ports are defined below.

**5.2.2 TRANSFER PORT OPERATION TYPES**

**5.2.2.1** Transfer port operations allow an SLE object to transfer
space data channels at its transfer ports. These operations also allow
in-line control of the transfer process, including authorization,
authentication, or in-line status request/response.

**5.2.2.2** The following types of operations may be invoked at the
transfer ports of an SLE object:

> a\) Transfer_Data: transfers an SLE-SDU containing Space Link data
> between the user and the provider of the SLE transfer service.
>
> b\) Transfer_Set: initializes or updates service data attributes and
> configuration options pertinent to that user's service instance. A
> Transfer_Set operation is invoked by the SLE service user and
> performed by the SLE service provider.
>
> c\) Transfer_Get: retrieves service status and service configuration
> information regarding an individual service instance. A Transfer_Get
> operation is invoked by the SLE service user and performed by the SLE
> service provider.
>
> d\) Transfer_Notification: reports status (e.g., periodic or event)
> and accounting information associated with the individual service
> instance carried by the Transfer port. A Transfer_Notification
> operation is invoked by the SLE service provider.

**5.3 SLE SERVICE SPECIFICATION**

**5.3.1** Each SLE service is defined in an SLE service specification.
An SLE service specification includes the specification of

> a\) the list of operations that may be performed in providing the SLE
> service:
>
> 1\) the parameters of each operation are named and described;
>
> 2\) the format and content of the data units transferred are defined;
>
> 3\) these operations are defined in accordance with ASDC (reference
> \[12\]), in ASN.1 (reference \[13\]);
>
> b\) the behavior of the SLE system in reaction to these operations;
>
> c\) the identification of the prerequisite space data channel for
> production of the SLE service;
>
> d\) the quality of service requirements on the underlying supporting
> communications services;
>
> e\) the SLE service initialization or configuration parameters used to
> set up the service.

**5.3.2** The style and format of an SLE service specification shall
conform to the CCSDS Publications Manual (reference \[9\]).

**5.4 SLE TRANSFER SERVICE PORTS**

**5.4.1 PURPOSE AND ORGANIZATION**

**5.4.1.1** This subsection (5.4) identifies the formal elements (ports
and operations) associated with the SLE transfer services named in 3.4,
and allocates those ports and operations to the SLE FGs named in 4.3.2.
Identification of these elements provides the common framework upon
which the individual SLE transfer service specifications are to be
built.

**5.4.1.2** Each SLE service is provided via a Transfer port pair for
that service. In accordance with the ASDC (reference \[12\]), which have
been adopted and extended for this reference model, one port is
associated with the user of the service, and the other port is
associated with the provider. In the SLE RM, these Transfer ports are
asymmetric; that is, in each pair, one port assumes the role of
consumer, and the other, the role of supplier. The operations invoked by
the object containing the consumer port are different from those that
are invoked by the object containing the supplier port.

**5.4.1.3** Subsection 5.4.2 addresses the Transfer ports associated
with the provision of the Return SLE services. Subsection 5.4.3
addresses the Transfer ports associated with the provision of the
Forward SLE services. In each of these subsections,

> -- the SLE services are associated with the Transfer port types that
> support them;
>
> -- the relationship between the consumer/supplier roles and
> User/Provider roles is established;
>
> -- the SLE Object types that contain each of the port types are
> identified;
>
> -- the operation types are named; and
>
> -- the relationship between port roles and invocation of operation
> types is defined.

**5.4.1.4** There are two SLE Transfer port types that are not directly
associated with SLE services, the Return RF Carrier port type and the
Forward RF Carrier port type. For these ports, the notion of "user" and
"provider" do not have meaning (or, at least, not the meaning that is
associated with the ports at which the SLE services are provided).
Subsection 5.4.4 briefly describes these port types.

**5.4.2 RETURN TRANSFER PORTS**

**5.4.2.1** For the Return SLE Transfer ports, the SLE-FG that provides
the service (Service Provider) assumes the role of *supplier* and the
SLE Object (SLE-FG or MUE) that uses the service (Service User) assumes
the role of *consumer*.

**5.4.2.2** Table 5-1 identifies the Return SLE Transfer port types, the
SLE service that is associated with each of them, the SLE-FG that
provides the service, and the SLE Object(s) (SLE-FG and/or MUE) that use
the service.

> **Table 5-1: Return SLE Transfer Ports, SLE Services, Provider
> SLE-FGs, and User SLE Objects**

  ---------------- --------------- --------------- -----------------------
  **\              **Associated    **Provider      **User SLE Object(s)\
  SLE Port Type    SLE Service**   SLE-FG          (Consumer)**
  Name**                           (Supplier)**    

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

  ----------------- --------------- --------------- -----------------------
  Rtn-AF-Transfer   Return All      Return Space    Return Frame
                    Frames (RAF)    Link Processing Processing,\
                                                    MUE

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

  --------------------- --------------- --------------- -----------------------
  Rtn-Insert-Transfer   Return Insert   Return Space    MUE
                                        Link Processing 

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

  ------------------ --------------- --------------- -----------------------
  Rtn-MCF-Transfer   Return Master   Return Frame    MUE
                     Channel Frames  Processing      

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

  ------------------ --------------- --------------- -----------------------
  Rtn-VCF-Transfer   Return Virtual  Return Frame    MUE
                     Channel Frames  Processing      

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

  -------------------- --------------- --------------- -----------------------
  Rtn-MCFSH-Transfer   Return Master   Return Frame    MUE
                       Channel Frame   Processing      
                       Secondary                       
                       Header                          

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

  -------------------- --------------- --------------- -----------------------
  Rtn-MCOCF-Transfer   Return Master   Return Frame    Forward TC VC Data
                       Channel         Processing      Insertion,\
                       Operational                     Forward TC Space Link
                       Control Field                   Processing,\
                                                       MUE

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

  -------------------- --------------- --------------- -----------------------
  Rtn-VCFSH-Transfer   Return Virtual  Return Frame    MUE
                       Channel Frame   Processing      
                       Secondary                       
                       Header                          

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

  -------------------- --------------- --------------- -----------------------
  Rtn-VCOCF-Transfer   Return Virtual  Return Frame    Forward TC VC Data
                       Channel         Processing      Insertion,\
                       Operational                     Forward TC Space Link
                       Control Field                   Processing,\
                                                       MUE

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

  ------------------ --------------- --------------- -----------------------
  Rtn-Bit-Transfer   Return          Return Frame    MUE
                     Bitstream       Data Extraction 

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

  ----------------- --------------- --------------- -----------------------
  Rtn-SP-Transfer   Return Space    Return Frame    MUE
                    Packet          Data Extraction 

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

**5.4.2.3** For the Service Provider Return SLE Transfer ports:

> a\) the supplier (Service Provider) invokes the Transfer_Data and
> Transfer_Notification operation types;
>
> b\) the names of the port-type-specific Transfer_Data operation types
> are formed by appending "Data" to the name of the port type, e.g.,
> "Rtn-Bit-TransferData";
>
> c\) the names of the port-type-specific Transfer_Notification
> operation types are formed by appending "Notification" to the name of
> the port type, e.g., "Rtn-Bit-TransferNotification."

**5.4.2.4** For the Service User Return SLE Transfer ports:

> a\) the consumer (Service User) invokes the Transfer_Set and
> Transfer_Get operation types;
>
> b\) the names of the port-type-specific Transfer_Set operation types
> are formed by appending "Set" to the name of the port type, e.g.,
> "Rtn-Bit-TransferSet";
>
> c\) the names of the port-type-specific Transfer_Get operation types
> are formed by appending "Get" to the name of the port type, e.g.,
> "Rtn-Bit-TransferGet."

**5.4.3 FORWARD TRANSFER PORTS**

**5.4.3.1** For the Forward SLE Transfer ports, the SLE-FG that provides
the service (Service Provider) assumes the role of *consumer* and the
SLE Object (SLE-FG or MUE) that uses the service (Service User) assumes
the role of *supplier*.

**5.4.3.2** Table 5-2 identifies the Forward SLE Transfer port types,
the SLE service that is associated with each of them, the SLE-FG that
provides the service, and the SLE Object(s) (SLE-FG and/or MUE) that use
the service.

**5.4.3.3** For the Service User Forward SLE Transfer ports:

> a\) the supplier (Service User) invokes the Transfer_Data,
> Transfer_Set, and Transfer_Get operation types;
>
> b\) the names of the port-type-specific Transfer_Data operation types
> are formed by appending "Data" to the name of the port type, e.g.,
> "Fwd-Bit-TransferData";
>
> c\) the names of the port-type-specific Transfer_Set operation types
> are formed by appending "Set" to the name of the port type, e.g.,
> "Fwd-Bit-TransferSet";
>
> d\) the names of the port-type-specific Transfer_Get operation types
> are formed by appending "Get" to the name of the port type, e.g.,
> "Fwd-Bit-TransferGet."
>
> **Table 5-2: Forward SLE Transfer Ports, SLE Services, Provider
> SLE-FGs, and User SLE Objects**

  ---------------- ------------------- ----------------- -----------------
  **SLE Port Type  **Associated SLE    **Provider SLE-FG **User SLE
  Name**           Service**           (Consumer)**      Object(s)
                                                         (Supplier)**

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

  --------------------- ------------------- ----------------- -----------------
  Fwd-C/VCDU-Transfer   Forward C/VCDU      Forward AOS Space MUE
                                            Link Processing   

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

  ---------------- ------------------- ----------------- -----------------
  CLTU-Transfer    Forward CLTU        Forward TC Space  Forward CLTU
                                       Link Processing   Generation, MUE

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

  ------------------------ ------------------- ----------------- -----------------
  Fwd-ProtoVCDU-Transfer   Forward ProtoVCDU   Forward AOS Space Forward AOS VC
                                               Link Processing   Data Insertion,
                                                                 MUE

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

  --------------------- ------------------- ----------------- -----------------
  Fwd-Insert-Transfer   Forward Insert      Forward AOS Space MUE
                                            Link Processing   

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

  ------------------ ------------------- ----------------- -----------------
  TCFrame-Transfer   Forward Telecommand Forward CLTU      Forward TC VC
                     Frame               Generation        Data Insertion,
                                                           MUE

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

  ---------------- ------------------- ----------------- -----------------
  TCVCA-Transfer   Forward Telecommand Forward TC VC     MUE
                   Virtual Channel     Data Insertion    
                   Access                                

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

  ------------------ ------------------- ----------------- -----------------
  Fwd-VCA-Transfer   Forward Virtual     Forward AOS VC    MUE
                     Channel Access      Data Insertion    

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

  ------------------ ------------------- ----------------- -----------------
  Fwd-Bit-Transfer   Forward Bitstream   Forward AOS VC    MUE
                                         Data Insertion    

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

  ----------------- ------------------- ----------------- -----------------
  Fwd-SP-Transfer   Forward Space       Forward AOS VC    MUE
                    Packet              Data Insertion,   
                                        Forward TC VC     
                                        Data Insertion    

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

NOTE -- The Forward TC VC Data Insertion and Forward TC Space Link
Processing FGs also expose Rtn-MCOCF or Rtn-VCOCF consumer ports, as
described in Table 5-1.

**5.4.3.4** For the Service Provider Forward SLE Transfer ports:

> a\) the consumer (Service Provider) invokes the Transfer_Notification
> operation type;
>
> b\) the names of the port-type-specific Transfer_Notification
> operation types are formed by appending "Notification" to the name of
> the port type, e.g., "Fwd-Bit-TransferNotification."

**5.4.4 RF CARRIER TRANSFER PORTS**

**5.4.4.1** In addition to the port types directly associated with the
provision of SLE transfer services, the two RF Carrier port types serve
as the interfaces with the space element.

**5.4.4.2** The Return RF Carrier Transfer port type (Rtn-RF-Transfer)
transfers the RF carrier signal from the space element (in the supplier
role) to the SLE system (in the consumer role). This port type has one
operation, Rtn-RF-TransferData, which is invoked by the supplier and
performed by the consumer.

**5.4.4.3** The Forward RF Carrier Transfer port type (Fwd-RF-Transfer)
transfers the RF carrier signal from the SLE system (in the supplier
role) to the space element (in the consumer role). This port type has
one operation, Fwd-RF-TransferData, which is invoked by the supplier and
performed by the consumer.

**5.5 SLE MANAGEMENT SERVICE PORTS**

**5.5.1** This subsection (5.5) identifies the relationships between the
various SLE management ports. The SLE-FG assumes the role of *supplier*
and the Complex Management assumes the role of *consumer*.

NOTE -- As described in 4.4.3, the SLE-UM is actually the consumer, but
this is realized via the SLE Complex Management port.

**5.5.2** Each SLE-FG has one management port associated with it.
Through that management port, the production of the services provided by
that SLE-FG are configured and monitored by the Complex Management .
Table 5-3 identifies the SLE management ports and the SLE-FGs that
contain them.

**Table 5-3: SLE Management Ports and Supplier SLE-FGs**

  --------------------------------- -------------------------------------
  **SLE Management Port Name**      **SLE-FG Assuming the Supplier Role**

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

  --------------------------------- -------------------------------------
  Rtn-SpLinkProc-Mgmt               Return Space Link Processing

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

  --------------------------------- -------------------------------------
  Rtn-FrameProc-Mgmt                Return Frame Processing

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

  --------------------------------- -------------------------------------
  Rtn-FrameData-Mgmt                Return Frame Data Extraction

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

  --------------------------------- -------------------------------------
  Fwd-AOSSpLinkProc-Mgmt            Forward AOS Space Link Processing

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

  --------------------------------- -------------------------------------
  Fwd-AOSData-Mgmt                  Forward AOS VC Data Insertion

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

  --------------------------------- -------------------------------------
  TCSpLinkProc-Mgmt                 TC Space Link Processing

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

  --------------------------------- -------------------------------------
  CLTUGen-Mgmt                      CLTU Generation

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

  --------------------------------- -------------------------------------
  TCData-Mgmt                       TC VC Data Insertion

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

**5.5.3** For the Service Provider SLE management ports:

> a\) the supplier invokes the Management_Notification operation type;
>
> b\) the names of the port-type-specific Management_Notification
> operation types are formed by appending "Notification" to the name of
> the port type, e.g., "Rtn-SpLinkProc-MgmtNotification."

**5.5.4** For the Service User SLE management ports:

> a\) the consumer invokes the Management_Set and Management_Get
> operation types:
>
> b\) the names of the port-type-specific Management_Set operation types
> are formed by appending "Set" to the name of the port type, e.g.,
> "Rtn-SpLinkProc-MgmtSet";
>
> c\) the names of the port-type-specific Management_Get operation types
> are formed by appending "Get" to the name of the port type, e.g.,
> "Rtn-SpLinkProc-MgmtGet."

**5.6 SLE TRANSFER SERVICE PRODUCTIONS**

In this subsection, the formal elements involved with the production of
each SLE transfer service are identified. For each SLE transfer service,
the SLE-FGs that participate in the production of that service are
identified. For each SLE-FG, the port types and their roles
(consumer/supplier) are indicated. The SLE services were illustrated in
figures 4-4, 4-5, and 4-6.

**5.6.1 SLE RETURN TRANSFER SERVICES**

**5.6.1.1 Return All Frames Service**

> a\) The production of the Return All Frames (RAF) service involves the
> Return Space Link Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG ports:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.

**5.6.1.2 Return Insert Service**

> a\) The production of the Return Insert service involves the Return
> Space Link Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG ports:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-Insert-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.

**5.6.1.3 Return Master Channel Frame (MCF) Service**

> a\) The production of the Return MCF service involves the Return Space
> Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG ports:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG ports:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-MCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.4 Return Virtual Channel Frame (VCF) Service**

> a\) The production of the Return VCF service involves the Return Space
> Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-VCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.5 Master Channel Frame Secondary Header (MC-FSH) Service**

> a\) The production of the MC-FSH service involves the Return Space
> Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-MCFSH-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.6 Return Master Channel Operational Control Field (MC-OCF)
Service**

> a\) The production of the Return MC-OCF service involves the Return
> Space Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-MCOCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.7 Return Virtual Channel Frame Secondary Header (VC-FSH)
Service**

> a\) The production of the Return VC-FSH service involves the Return
> Space Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-VCFSH-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.8 Return Virtual Channel Operational Control Field (VC-OCF)
Service**

> a\) The production of the Return VC-OCF service involves the Return
> Space Link Processing SLE-FG and the Return Frame Processing SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-VCOCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.

**5.6.1.9 Return Bitstream Service**

> a\) The production of the Return Bitstream service involves the Return
> Space Link Processing SLE-FG, the Return Frame Processing SLE-FG, and
> the Return Frame Data Extraction SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-VCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.
>
> d\) Return Frame Data Extraction SLE-FG:
>
> 1\) consumer Rtn-VCF-Transfer and supplier Rtn-Bit-Transfer ports;
>
> 2\) supplier Rtn-FrameData-Mgmt port.

**5.6.1.10 Return Space Packet Service**

> a\) The production of the RSP service involves the Return Space Link
> Processing SLE-FG, the Return Frame Processing SLE-FG, and the Return
> Frame Data Extraction SLE-FG.
>
> b\) Return Space Link Processing SLE-FG:
>
> 1\) consumer Rtn-RF-Transfer and supplier Rtn-AF-Transfer ports;
>
> 2\) supplier Rtn-SpLinkProc-Mgmt port.
>
> c\) Return Frame Processing SLE-FG:
>
> 1\) consumer Rtn-AF-Transfer and supplier Rtn-VCF-Transfer ports;
>
> 2\) supplier Rtn-FrameProc-Mgmt port.
>
> d\) Return Frame Data Extraction SLE-FG:
>
> 1\) consumer Rtn-VCF-Transfer and supplier Rtn-SP-Transfer ports;
>
> 2\) supplier Rtn-FrameData-Mgmt port.

**5.6.2 SLE FORWARD TRANSFER SERVICES**

**5.6.2.1 Forward C/VCDU Service**

> a\) The production of the Forward C/VCDU service involves the Forward
> AOS Space Link Processing SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-C/VCDU-Transfer ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.

**5.6.2.2 Forward CLTU Service**

> a\) The production of the Forward CLTU service involves the TC Space
> Link Processing SLE-FG.
>
> b\) TC Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer CLTU-Transfer ports;
>
> 2\) supplier TCSpLinkProc-Mgmt port;
>
> 3\) consumer Rtn-MCOCF-Transfer or consumer Rtn-VCOCF-Transfer ports.

**5.6.2.3 Forward ProtoVCDU Service**

> a\) The production of the Forward ProtoVCDU service involves the
> Forward AOS Space Link Processing SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-ProtoVCDU-Transfer
> ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.

**5.6.2.4 Forward Insert Service**

> a\) The production of the Forward Insert service involves the Forward
> AOS Space Link Processing SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-Insert-Transfer ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.

**5.6.2.5 Forward Telecommand (TC) Frame Service**

> a\) The production of the Forward TC Frame service involves the TC
> Space Link Processing SLE-FG and the CLTU Generation SLE-FG.
>
> b\) TC Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer CLTU-Transfer ports;
>
> 2\) supplier TCSpLinkProc-Mgmt port.
>
> c\) CLTU Generation SLE-FG ports:
>
> 1\) supplier Fwd-CLTU-Transfer and consumer TCFrame-Transfer ports;
>
> 2\) supplier CLTUGen-Mgmt port.

**5.6.2.6 Forward Telecommand Virtual Channel Access (TC-VCA) Service**

> a\) The production of the Forward TC-VCA service involves the TC Space
> Link Processing SLE-FG, the CLTU Generation SLE-FG, and the TC VC Data
> Insertion SLE-FG.
>
> b\) TC Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer CLTU-Transfer ports;
>
> 2\) supplier TCSpLinkProc-Mgmt port.
>
> c\) CLTU Generation SLE-FG ports:
>
> 1\) supplier Fwd-CLTU-Transfer and consumer TCFrame-Transfer ports;
>
> 2\) supplier CLTUGen-Mgmt port.
>
> d\) TC VC Data Insertion SLE-FG ports:
>
> 1\) supplier Fwd-TCFrame-Transfer and consumer TCVCA-Transfer ports;
>
> 2\) supplier TCData-Mgmt port;
>
> 3\) consumer Rtn-MCOCF-Transfer or consumer Rtn-VCOCF-Transfer ports.

**5.6.2.7 Forward Virtual Channel Access (VCA) Service**

> a\) The production of the Forward VCA service involves the Forward AOS
> Space Link Processing SLE-FG and the Forward AOS VC Data Insertion
> SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-ProtoVCDU-Transfer
> ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.
>
> c\) AOS VC Data Insertion SLE-FG ports:
>
> 1\) supplier Fwd-ProtoVCDU-Transfer and consumer Fwd-VCA-Transfer
> ports;
>
> 2\) supplier AOSData-Mgmt port.

**5.6.2.8 Forward Bitstream Service**

> a\) The production of the Forward Bitstream service involves the
> Forward AOS Space Link Processing SLE-FG and the Forward AOS VC Data
> Insertion SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-ProtoVCDU-Transfer
> ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.
>
> c\) AOS VC Data Insertion SLE-FG ports:
>
> 1\) supplier Fwd-ProtoVCDU-Transfer and consumer Fwd-Bit-Transfer
> ports;
>
> 2\) supplier AOSData-Mgmt port.

**5.6.2.9 Forward Space Packet Service**

The production of the Forward Space packet service is accomplished using
one of two profiles: the AOS profile or the TC profile.

**5.6.2.9.1 Forward Space Packet Service: AOS Profile**

> a\) The production of the AOS-profile Forward Space packet service
> involves the Forward AOS Space Link Processing SLE-FG and the Forward
> AOS VC Data Insertion SLE-FG.
>
> b\) Forward Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer Fwd-ProtoVCDU-Transfer
> ports;
>
> 2\) supplier Fwd-AOSSpLinkProc-Mgmt port.
>
> c\) AOS VC Data Insertion SLE-FG ports:
>
> 1\) supplier Fwd-ProtoVCDU-Transfer and consumer Fwd-SP-Transfer
> ports;
>
> 2\) supplier AOSData-Mgmt port.

**5.6.2.9.2 Forward Space Packet Service: TC Profile**

> a\) The production of the TC-VCA service involves the TC Space Link
> Processing SLE-FG, the CLTU Generation SLE-FG, and the TC VC Data
> Insertion SLE-FG.
>
> b\) TC Space Link Processing SLE-FG ports:
>
> 1\) supplier Fwd-RF-Transfer and consumer CLTU-Transfer ports;
>
> 2\) supplier TCSpLinkProc-Mgmt port.
>
> c\) CLTU Generation SLE-FG ports:
>
> 1\) supplier Fwd-CLTU-Transfer and consumer TCFrame-Transfer ports;
>
> 2\) supplier CLTUGen-Mgmt port.
>
> d\) TC VC Data Insertion SLE-FG ports:
>
> 1\) supplier Fwd-TCFrame-Transfer and consumer Fwd-SP-Transfer ports;
>
> 2\) supplier TCData-Mgmt port.

ANNEX A

**\
SPACE LINK EXTENSION DATA STRUCTURES**

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

**A1 INTRODUCTION**

This annex identifies the various data structures associated with the
SLE services. These data structures exist at two levels. At the lower
level, the data structures are the *space* *data units* that are
exchanged between the space element and the SLE system, between the
various components of the SLE system, and between SLE system and the
MDOS. At the higher level, the data structures are the *space data
channel*. Subsection A2 lists the data units associated with the SLE
services. Subsection A3 describes the space data channel tree concepts
and identifies the specific space data channel trees pertinent to the
production of SLE services.

**A2 SPACE DATA UNITS**

A major function of the SLE services is to perform the transformations
between the SL-DU*s* (that is, those that are exchanged between the
space element and the SLE system) and the *SLE data units* (those that
are exchanged between the various components of the SLE system, and
between the SLE system and the MDOS). SLE data units can be further
delineated into *SLE service data units* and *SLE* *PDUs*. Subsections
A2.1, A2.2, and A2.3 describe the SL-DUs, SLE service data units, and
SLE PDUs, respectively, and how they relate to each other.

**A2.1 SPACE LINK DATA UNITS**

**A2.1.1** The SL-DUs are the data elements that are common to the Space
Link *PDUs* defined in the Telecommand, Packet Telemetry, and Advanced
Orbiting System (AOS) Recommendations (references \[2\]--\[7\]), and the
SLE data units defined for the various SLE services. The SL-DUs are
derived from the SL-PDUs, which means that in some cases they are
equivalent to the SL-PDUs, and in other cases they are formed from one
or more subfields of the SL-PDUs, because some SL-PDUs carry data that
translates into different types of SLE services.

**A2.1.2** Table A-1 lists the Packet Telemetry SL-DU types. Table A-2
lists the Telecommand SL-DU types. Table A-3 lists the AOS SL-DU types.
Each SL-DU type description identifies the relationship with the
appropriate SL-PDU. Only the most closely related (or highest-layer)
SL-PDU is identified. That is, if an SL-DU is one or more fields of a
defined SL-PDU, the field(s) of the SL-PDU are identified. If the SL-DU
has a one-to-one correspondence with a defined SL-PDU, only that
corresponding SL-PDU is named, even though the corresponding SL-PDU is
itself "derived" from a lower-layer SL-PDU.

**A2.2 SLE SERVICE DATA UNITS**

**A2.2.1** The SLE Service Data Units (SLE-SDUs) are the
service-user-oriented data units exchanged between components of the SLE
system, and between the SLE system and the MDOS. That is, the SLE-SDUs
contain the information directly derived from (or related to) the SL-DUs
and the quality of Space Link over which those SL-DUs are transferred.

**Table A-1: Packet Telemetry SL-DUs**

+-------------------------------+--------------------------------------+
| **SL-DU Type**                | **SL-PDU Derivation**                |
|                               |                                      |
|                               | **(from references \[2\], \[3\], and |
|                               | \[8\] )**                            |
+-------------------------------+--------------------------------------+

  ------------------------------- ---------------------------------------
  Packet Telemetry (PT) Transfer  PT Transfer Frame
  Frame\                          
  (Version 1 Frame)               

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

  ------------------------------- ---------------------------------------
  Frame Secondary Header (FSH)    FSH field of PT Transfer Frame

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

  ------------------------------- ---------------------------------------
  Operational Control Field (OCF) OCF field of PT Transfer Frame

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

  ------------------------------- ---------------------------------------
  Privately Defined Data (PDD)    Private Data Delivery Status Flag,
                                  First Header Pointer, and Spacecraft
                                  Application Data fields of PT Transfer
                                  Frame

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

  ------------------------------- ---------------------------------------
  Source Packet                   CCSDS Source Packet

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

**Table A-2: Telecommand SL-DUs**

+-----------------------------------------+----------------------------+
| **SL-DU Type**                          | **SL-PDU Derivation**      |
|                                         |                            |
|                                         | **(from references \[5\],  |
|                                         | \[6\], and \[7\] )**       |
+-----------------------------------------+----------------------------+

  ----------------------------------------- -----------------------------
  Command Link Transmission Unit (CLTU)     CLTU

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

  ----------------------------------------- -----------------------------
  Telecommand (TC) Transfer Frame\          TC Transfer Frame
  (Version 1 Frame)                         

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

  ----------------------------------------- -----------------------------
  TC Frame Data Unit                        TC Frame Data Unit

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

  ----------------------------------------- -----------------------------
  TC Segment                                TC Segment

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

  ----------------------------------------- -----------------------------
  CCSDS Packet                              TC Packet

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

**A2.2.2** There are two kinds of SLE-SDUs: data-bearing SLE-SDUs and
service control SLE-SDUs.

**A2.2.3** The data-bearing SLE-SDUs contain:

> a\) data that have been extracted from, or are to be injected into,
> SL-DUs;
>
> b\) annotation data applicable to a specific SL-DU that aids in the
> processing of the data contained in that SL-DU; and
>
> c\) channel status information that reports upon changes in the
> condition of the SLE data channels that carry the SLE-SDUs. The SLE
> data channels are described in A3. Normally, the condition of the SLE
> data channel does not change frequently, or at least not as frequently
> as the appearance of each data-bearing SLE-SDU, so valid channel
> status information may or may not be present in any given data-bearing
> SLE-SDU.

**Table A-3: AOS SL-DUs**

+--------------------------+-------------------------------------------+
| **SL-DU Type**           | **SL-PDU Derivation**                     |
|                          |                                           |
|                          | **(from references \[3\] and \[4\] )**    |
+--------------------------+-------------------------------------------+

  --------------------------- -------------------------------------------
  (Coded) Virtual Channel     C/VCDU
  Data Unit\                  
  (C/VCDU) (Version 2 Frame)  

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

  --------------------------- -------------------------------------------
  Insert Zone                 VCDU Insert Zone field of C/VCDU

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

  --------------------------- -------------------------------------------
  ProtoVCDU                   Frame Version Number, VCDU Identifier,
                              Virtual Channel Data Unit Counter,
                              Signaling, and VCDU Data Unit Zone fields
                              of the C/VCDU

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

  --------------------------- -------------------------------------------
  Operational Control Field   Operational Control Field of the C/VCDU
  (OCF)                       

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

  --------------------------- -------------------------------------------
  VCA-SDU                     VCDU Data Zone of the C/VCDU

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

  --------------------------- -------------------------------------------
  Bitstream PDU               Bitstream PDU

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

  --------------------------- -------------------------------------------
  CCSDS Packet                CCSDS Packet

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

  --------------------------- -------------------------------------------
  Internet-Encapsulation      CCSDS Packet with reserved APID
  Packet                      

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

  --------------------------- -------------------------------------------
  ISO CLNP Packet             ISO CLNP Packet

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

**A2.2.4** Channel status SLE-SDUs carry channel status information when
there are no data-bearing SLE-SDUs immediately available to carry the
status information.

**A2.3 SLE PROTOCOL DATA UNITS**

**A2.3.1** In order to transfer the SLE-SDUs between components of the
SLE system, and between the SLE system and the MDOS, the SLE systems and
MDOS employ service protocols. These protocols ensure that the SLE-SDUs
are delivered with the quality of service required by the service user.
These service protocols involve the exchange of SLE-PDUs.

**A2.3.2** There are two kinds of SLE-PDUs: data-bearing SLE-PDUs that
encapsulate SLE-SDUs (along with other protocol control information),
and stand-alone protocol control messages. Whereas the annotation and
channel status information appended to the SL-DUs in the SLE-SDUs are
valid across multiple Provider/User associations, the protocol control
information is local to a single Provider/User association.

**A2.3.3** The content and construction of the SLE-PDUs is outside the
scope of this reference model, and is addressed in the individual SLE
service specifications.

**A3 SPACE DATA CHANNELS**

**A3.1 TYPES OF SPACE DATA CHANNELS**

**A3.1.1** A *space data channel* is a stream of space data units of the
same type, associated with each other by a single, unique identifier. In
several cases, different space data channel types carry the same space
data unit; the differentiation between channel types comes strictly from
the different ways in which those data units are identified.

**A3.1.2** There are two sets of space data channels, the *SL data
channels* and the *SLE data channels*. The SL data channels carry the
SL-DUs between the SLE system and the space element. The SLE data
channels carry the SLE-SDUs between the components of the SLE system,
and between the SLE system and the MDOS. The types of SL data channels
are the same as the types of SLE data channels: the difference lies in
the fact that the SLE data channels contain annotation and other channel
status information in addition to the "raw" SL-DUs found on the SL data
channels. Therefore, the remainder of this section deals with the SLE
data channels.

**A3.1.3** *Space data channel trees* are the hierarchical structures
that relate the various space data channels to one another. There are
two channel trees that are used to organize SLE data channels (and also
SL data channels), the Return SLE data channel tree and the Forward SLE
data channel tree. Subsections A3.2 and A3.3 describe the Return and
Forward SLE data channels and their associated channel trees,
respectively.

**A3.2 RETURN SPACE DATA CHANNELS**

**A3.2.1** Table A-4 defines the Return SLE data channels by SL-DUs,
unique identification, and, for data channels that are provided through
SLE services, the identity of those SLE services.

NOTES

1 The PDD SDUs, which are the SL-DUs associated with the Packet
Telemetry PDD service (reference \[14\]), are not exposed in the SLE
data channel trees. Rather, they are carried by Virtual Channels which
are delivered via instances of VC Frame service. Exposure of the Packet
Telemetry PDD service, if it is used by a particular project, occurs
only within the Space Element and the MDOS.

2 The VCA-SDUs, which are the SL-DUs associated with the AOS VCA service
(reference \[4\]), are not exposed in the SLE data channel trees.
Rather, they are carried by Virtual Channels which are delivered via
instances of VC Frame service. Exposure of the AOS VCA service, if it is
used by a particular project, occurs only within the Space Element and
the MDOS.

3 The ISO CLNP packets, which are the SL-DUs associated with the AOS
Internet service (reference \[4\]), are not exposed in the SLE data
channel trees. Rather, they are encapsulated in a special class of Space
Packets (APID = 2046), which in turn are treated by the SLE system as
any other Space Packets. Exposure of the AOS Internet service, if it is
used by a particular project, occurs only within the space element and
the MDOS.

The base (or most primitive) return SLE data channel is the Return Space
Link, which is the return portion of the space link. The return space
link is a special kind of SLE data channel, in that its structure is
dependent on the coding and modulation techniques used by a particular
space mission. Therefore, it may provide a variety of space link
formats, frequencies, number of carriers and subcarriers, etc. Thus for
each space mission a link-unique portion of the channel tree must be
defined to: (a) specify the acquisition production steps necessary for
the SLE Complex to produce the physical channels, and (b) provide
identifiers for the physical channels (physical channel IDs) for the
purpose of cross-support management (see the SLE Service Management
specification).

NOTE -- The physical channel is the most primitive return SLE data
channel from which the remainder of the return channel tree can be
unambiguously derived. However, the physical channel does not carry
SL-DUs as defined in the AOS or Packet Telemetry Blue Books. This is
because this channel exists below the layers addressed in the AOS and
Packet Telemetry books. Indeed, at the physical layer at which this
channel exists, there are no proper "data units," but only the base
elements of which data units are composed: bits and/or symbols. Thus the
"SL-DUs" associated with this channel are not really data units.

**Table A-4: Return SLE Data Channels**

  ------------------------- --------------- ------------------ -----------
  **SLE Data Channel**      **SL-DU**       **Unique ID**      **SLE
                                                               Service**

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

  ------------------------- --------------- ------------------ -----------
  Return Space Link         not             not standardized   
                            standardized as as part of SLE     
                            part of SLE                        

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

  ------------------------- --------------- ------------------ -----------
  physical channel          baseband stream physical channel   
                            of symbols      ID                 

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

  ------------------------- --------------- ------------------ -----------
  Return All Frames (RAF)   PT Transfer     RAF channel ID     RAF
  channel                   Frame and/or                       
                            C/VCDU                             

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

  ------------------------- --------------- ------------------ -----------
  Insert channel (Version 2 Insert Zone     RAF channel ID     Insert
  master channels only)                                        

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

  ------------------------- --------------- ------------------ -----------
  Master Channel            PT Transfer     MCID (Frame        Master
                            Frame and/or    Version Number and Channel
                            C/VCDU          SCID)              

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

  ------------------------- --------------- ------------------ -----------
  MC-OCF channel: (Version  OCF             MCID               MC-OCF
  1 master channels only)                                      

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

  ------------------------- --------------- ------------------ -----------
  MC-FSH channel (Version 1 FSH             MCID               MC-FSH
  master channels only)                                        

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

  ------------------------- --------------- ------------------ -----------
  Virtual Channel           PT Transfer     GVCID (MCID and    Virtual
                            Frame and/or    VCID)              Channel
                            C/VCDU                             

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

  ------------------------- --------------- ------------------ -----------
  VC-OCF channel            OCF             GVCID              VC-OCF

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

  ------------------------- --------------- ------------------ -----------
  VC-FSH channel (Version 1 FSH             GVCID              VC-FSH
  master channels only)                                        

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

  ------------------------- --------------- ------------------ -----------
  Return Bitstream channel  Bitstream PDU   GVCID              Return
  (Version 2 virtual                                           Bitstream
  channels only)                                               

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

  ------------------------- --------------- ------------------ -----------
  Return Space Packet       CCSDS Packet    GVCID and APID:\   Return
  channel                                   for V1 GVCIDs,     Space
                                            APID =\            Packet
                                            (0-2046);\         
                                            for V2 GVCIDs,     
                                            APID =\            
                                            (0-2031, 2046)     

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

**A3.2.2** Figure A-1 illustrates the Return SLE Channel Tree, showing
the tree relationships among the various structural elements of the
CCSDS AOS and Packet Telemetry return links. It is important to note
that the channel tree illustrates the possible kinds of channels and
their interrelationships - any given mission can (and probably will)
implement only a subset of the overall channel tree.

NOTE -- Figure A-1 shows a single demultiplexer (see A.3.2.3.2, below)
between the return space link and the physical channel(s). In a real
space link acquisition function, there may be several intermediate
"channels" between the space link and the physical channels (e.g.,
various subcarriers). However, their number and type will depend on the
exact nature of the particular space link acquisition function, and they
are not defined as part of the "standard" return SLE data channel tree.

**A3.2.3** Figure A-1 uses five symbols (illustrated in the key below
the tree diagram): the decommutator, the demultiplexer, the OR symbol,
the frame synchronization symbol, and the tap-off.

**A3.2.3.1** The *decommutator* symbol represents the process in which
different types of data elements (e.g., Frame Secondary Header and Ops
Control fields) are removed from SL-DUs.

**A3.2.3.2** The *demultiplexer* symbol represents the process by which
different data channels of the same type (e.g., transfer frames of
different virtual channels) are separated. The way to read the
demultiplexers and decommutators is that the numerical index tells you
how many of that type of output are possible, but each output line
should be read as "one of" in the context of the following
demultiplexer/decommutator. So, for example, there are "1 to n" (one or
more) Master Channels, *each of which* demultiplexes into "1 to n"
Virtual channels. Each line that comes out of a decommutator represents
a different kind of channel.

**A3.2.3.3** The *OR* symbol (curly brace ({)) is used to identify an OR
condition: the channel to the left of the symbol may consist of any of
the subtree types identified to the right of the symbol.

**A3.2.3.4** The *frame synchronization* symbol (a circular symbol
(![](media/image26.pct){width="9.722222222222222e-2in"
height="9.722222222222222e-2in"})) is used to differentiate the physical
channel (which contains all symbols on the physical channel prior to
frame synchronization) from the RAF channel (which contains only frames
which have been successfully frame-synchronized).

**A3.2.3.5** The *tap-off* symbol
(![](media/image27.pct){width="0.1527777777777778in" height="0.125in"})
is used for channels that are copied out of a channel, but the original
channel still exists (i.e., all the fields of the data units are
preserved). An example of a tap-off is the copying of all frames from an
AOS RAF channel so that the Insert channel may be decommutated. The
original RAF channel (which contains the embedded Insert data) is still
unaffected.

**A3.3 FORWARD SPACE DATA CHANNEL TREE**

**A3.3.1** Table A-5 defines the Forward SLE data channels by SL-DUs,
unique identification, and, for data channels that are provided through
SLE services, the identity of those SLE services.

NOTE -- The ISO CLNP packets, which are the SL-DUs associated with the
AOS Internet service (reference \[4\]), are not exposed in the SLE data
channel trees. Rather, they are encapsulated in a special class of Space
Packets (APID = 2046), which in turn are treated by the SLE system as
any other Space Packets. Exposure of the AOS Internet service, if it is
used by a particular project, occurs only within the space element and
the MDOS.

The base (or most primitive) forward SLE data channel is the Forward
Space Link, which is the forward portion of the space link. The forward
space link is a special kind of SLE data channel, in that its structure
is dependent on the coding and modulation techniques used by a
particular space mission. Therefore, it may provide a variety of space
link formats, frequencies, number of carriers and subcarriers, etc. Thus
for each space mission a link-unique portion of the channel tree must be
defined to: (a) specify the acquisition production steps necessary for
the SLE Complex to produce the physical channels, and (b) provide
identifiers for the physical channels (physical channel IDs) for the
purpose of cross-support management (see the SLE Service Management
specification).

NOTE -- The physical channel is the most primitive forward SLE data
channel from which the remainder of the forward channel tree can be
unambiguously derived. However, the physical channel does not carry
SL-DUs as defined in the AOS or Telecommand Blue Books. This is because
this channel exists below the layers addressed in the AOS and
Telecommand books. Indeed, at the physical layer at which this channel
exists, there are no proper "data units," but only the base elements of
which data units are composed: bits and/or symbols. Thus the "SL-DUs"
associated with this channel are not really data units.

**A3.3.2** Figure A-2 illustrates the Forward SLE Channel Tree, showing
the tree relationships among the various structural elements of the
CCSDS AOS and Telecommand forward links.

NOTE -- Figure A-2 shows a single multiplexer between the forward space
link and the physical channel(s). In a real space link acquisition
function, there may be several intermediate "channels" between the space
link and the physical channels (e.g., various subcarriers). However,
their number and type will depend on the exact nature of the particular
space link acquisition function, and they are not defined as part of the
"standard" forward SLE data channel tree.

![](media/image28.pct){width="6.055555555555555in"
height="7.958333333333333in"}

**Figure A-1: Return SLE Channel Tree**

**Table A-5: Forward SLE Data Channels**

  ---------------------- --------------- ------------------ -------------
  **SLE Data Channel**   **SL-DU**       **Unique ID**      **SLE
                                                            Service**

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

  ---------------------- --------------- ------------------ -------------
  Forward Space Link     not             not standardized   
                         standardized as as part of SLE     
                         part of SLE                        

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

  ---------------------- --------------- ------------------ -------------
  Forward physical       baseband stream Physical channel   not exposed
  channel\               of symbols      ID                 via SLE
  (V1 - asynchronous                                        service
  channel, V2 -                                             
  synchronous channel)                                      

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

  ---------------------- --------------- ------------------ -------------
  Forward Insert         Insert Zone     Physical channel   Forward
  channel\                               ID                 Insert
  (V2 physical channels                                     
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  CLTU channel\          CLTU            CLTU ID            Forward CLTU
  (V1 physical channels                                     
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  Forward All Frames     C/VCDU          FAF channel ID     FAF
  (FAF)channel\                                             
  (V2 physical channels                                     
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  Forward C/VCDU         C/VCDU          GVCID              Forward
  channel\                                                  C/VCDU
  (V2 virtual channels                                      
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  TC Transfer Frame      TC Transfer     GVCID              Forward TC
  channel (V1 VCs only)  Frame                              Frame

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

  ---------------------- --------------- ------------------ -------------
  Forward protoVCDU\     ProtoVCDU       GVCID              Forward
  (V2 physical channels                                     ProtoVCDU
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  TC-VCA channel\        TC Frame Data   GVCID              Forward
  (V1 VCs only)          Unit                               TC-VCA

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

  ---------------------- --------------- ------------------ -------------
  TC Multiplex channel\  TC Segment      GVCID and          not exposed
  (V1 VCs only)                          Multiplexer Access via SLE
                                         Point Indentifier  service

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

  ---------------------- --------------- ------------------ -------------
  Forward VCA channel\   VCA-SDU (V2     GVCID              Forward VCA
  (V2 VCs only)          VCs)                               

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

  ---------------------- --------------- ------------------ -------------
  Forward Bitstream      Bitstream PDU   GVCID              Forward
  channel\                                                  Bitstream
  (V2 virtual channels                                      
  only)                                                     

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

  ---------------------- --------------- ------------------ -------------
  Forward Space Packet   CCSDS Packet    GVCID and APID:\   Forward Space
  channel                                for V1 GVCIDs,     Packet
                                         APID =\            
                                         (0-2046);\         
                                         for V2 GVCIDs,     
                                         APID =\            
                                         (0-2031, 2046))    

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

**Figure A-2: Forward SLE Channel TreeFigure A-2: Forward SLE Channel
Tree**

**ANNEX B\
\
CROSS SUPPORT REFERENCE MODEL**

**INDEX TO DEFINITIONS**

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

This annex provides an index to the terminology defined in this Cross
Support Reference Model Recommendation.

[Term]{.underline} [Subsection]{.underline} [Page]{.underline}

Abstract Binding 1.6.1.7 1-5

Abstract-Object 1.6.1.1 1-5

Abstract Refinement 1.6.1.3 1-5

Abstract-Service 1.6.1.2 1-5

forward data 1.6.2.2 1-6

Forward Space Link Data Unit 3.3.4 3-5

Ground Element 3.2.6 3-2

Mission Data Operation System 3.2.8 3-3

Mission User Entities (MUE) 3.2.9 3-3

Operation 1.6.1.8 1-5

Physical channel 3.2.3 3-2

Port Types 1.6.1.4 1-5

return data 1.6.2.1 1-6

Return Space Link Data Unit 3.3.3 3-4

Service User/Provider 1.6.1.6 1-5

SLE Complex 4.4.1 b) 4-20

SLE Complex abstract-object type 4.4.2.1.1 4-22

SLE Complex Management abstract-object type 4.4.2.1.2 4-23

SLE-FG object 4.3.1.1.2 4-5

SLE Service Package 4.4.1.2.2 4-22

SLE System object 4.2.1.2 4-3

SLE Transfer Service Instance 4.4.1.2.1 4-22

SLE Transfer Service Production 4.2.2.2 4-3

SLE Transfer Service Provision 4.2.2.1 4-3

SLE Utilization Management 3.2.10 3-3

Space Element 3.2.2 3-1

Space Link 3.2.4 3-2

Space Link Data Channel 3.3.5 3-5

Space Link Data Unit 3.3.2 3-4

Space Link Extension Data Channel 3.3.8 3-7

Space Link Extension Service Data Unit 3.3.6 3-5

Space Link Extension System 3.2.7 3-2

Space Link Session 3.2.5 3-2

Symmetric/Asymmetric Ports 1.6.1.5 1-5

**ANNEX C\
\
CROSS SUPPORT REFERENCE MODEL**

**ACRONYMS AND ABBREVIATIONS**

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

This annex provides an identification of the acronyms and abbreviations
used in this Cross Support Reference Model Recommendation.

> APID Application Process Identifier
>
> ASDC Abstract Service Definition Conventions
>
> AOS Advanced Orbiting System
>
> CCSDS Consultative Committee for Space Data Systems
>
> CLTU Command Link Transmission Unit
>
> CLNP Connectionless Network Protocol
>
> COP Command Operation Procedure
>
> C/VCDU Coded VCDU
>
> DU Data Unit
>
> FAF Forward All Frames
>
> FG Functional Group
>
> FSH Frame Secondary Header
>
> Fwd Forward
>
> GE Ground Element
>
> GVCID Global VCID
>
> ID Identifier (this abbreviation is concatenated with other\
> acronyms/abbreviations)
>
> ISO International Standards Organization
>
> MC Master Channel
>
> MCID Master Channel Identification
>
> MDOS Mission Data Operation System
>
> MUE Mission User Entity
>
> OCF Operation Control Field
>
> PDU Protocol Data Unit
>
> PLOP Physical Link Operations Procedure
>
> RAF Return All Frames
>
> RF Radio Frequency
>
> SCID Spacecraft Identifier
>
> SDU Service Data Units
>
> SE Space Element
>
> SL Space Link
>
> SLE Space Link Extension
>
> TC Telecommand
>
> TCM Terminology, Conventions, and Methodology
>
> TM Telemetry
>
> UM Utilization Management
>
> VC Virtual Channel
>
> VCA Virtual Channel Access
>
> VCDU Virtual Channel Data Unit
>
> VCID Virtual Channel Identification

[^1]: CCSDS Panel 3 is, at the time of publication, working only on Part
    1.