Network a
pplications
specify
with
whom

they want to communicate using
some sort of identifie
r, such as a BP endpoint
identifier or an IP
network address
,

without regard to where the endpoints are located.

To an
application
,

it does not matter if the destination is on the same spacecraft, one hop away
across a space link, or several hops away sepa
rated by a heterogeneous combination of wired
and wireless links.

To achieve this independence, it is assumed that
all

communications

use
the network layer, regardless of the number of links in the path.

This means that from an
application and networking p
erspective, there is very little difference between a 1
-
hop path, a
2
-
hop path,
or
a
5
-
hop path.

User applications may be
delay aware

or
d
elay unaware
. Table 2
-
2
compares
the two types
of applications.

The effective limit for
delay unaware

applications

is roughly 1
-
2 seconds

of
round trip light time

(RTLT)
, constrained by the assumptions built into the underlying
Internet protocol suite.


Delay is related to distance, but the issue here is whether applications
are designed to be aware of delays or if
they assume no delay (delay unaware). Properly
designed app
lication
s will survive the delays they are designed for (which may be many 10s
of hours). App
lication
s designed assuming no delays will be unpleasantly “surprised” when
they try to operate in an en
vironment where there are delays of even a few seconds or
minutes.

Table 2
-
2: Comparison of Delay
-
Aware and Delay
-
Unaware User
Applications


Delay Aware

Delay Unaware

Immediate replies
expected?

No

Yes

Acknowledgement from
peer applications or other
network services expected?

No

Yes

Delay/disruption tolerant?

Yes

No


Response to
delay/disruption

n/a

May treat a delay as a
network failure
,
attempt to
retry a communication
,

or
abandon it as an error.

End
-
to
-
end r
outing type
used

G
enerally use
BP

M
ay
use IP

Best network(s) to use

DTN
(
or hybrid
DTN/IP
Continuously connected IP

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
13

November 2011


Delay Aware

Delay Unaware

joined by protocol
-
translating gateways
)

Is a
pproach recommended

for Space Internetworking
?

Yes. Operate
s

well
regardless of delays and/or
disconnections
.

M
ay be used in
configurations where
there
is continuous connectivity
and short RTLT

(typically
<<2 sec)

2.4.4

BASIC
SYSTEM
-
ELEMENT
CONFIGURATIONS

2.4.4.2

Service Elements

Figure 2
-
6 abstractly shows how e
ach of the service elements in
any
of these deployed
systems has an identified
set of interfaces and some well
-
documented behaviors.

Each
service element has one or more service interfaces where the services provided by the
element are accessible.

The
visible
behavior of a service element i
s defined

at the interfaces
.
While t
he internal functions that produce this behavior may be identified, the
means use
d

to
implement these functions is opaque to the users. The types of services
and their operational
concepts
are

described in more detail in

s
ection 4
.

There is a process for locating and
connecting to these service interfaces
; that process
may involve
either
some active process of
discovery, or the location and access to these service interfaces may be hardwired into the
application that uses

them.

Each service element also has some sort of
service
-
management
interface through which the
behavior of the service may be configured, monitored, and controlled. This interface may be
externally accessible to the users, it may be accessible
only
from
within the system, or the
necessary control data values may be directly programmed into the service element,
accessible only by changing the program and recompiling it.
While t
his last
option
is a
fairly
static way of configuring the service elements, it m
ay be suitable in some situations.

Each of the service and management interfaces has some sort of defined interface binding,
which is the technical means by which a user of the service locates and accesses the service
itself. This binding includes not just

the address of the platform that hosts the service element
and the address of the port for the service, it also includes a description of the stack of
protocols that the service expects to respond to. The details of interface binding are discussed
in more

detail in
Section 6.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
14

November 2011


Figure 2
-
6
: Service Element and Interfaces

2.4.4.3

S
imple
ABA
C
ases

For a
CSSS
-
provided
space communication cross support service,
at minimum

there is
a
service user element in space

and another service user element on the ground.
The
Earth
-
Space Link Terminal (
ESLT
)

in
f
ig
ure

2
-
7 is
an instance of the CSSE shown in
figure
2
-
6.

Figure 2
-
7

shows a simple
ABA configuration, with a CSSE of one
Agency (B)

providing
service
s

to the
Earth and Space User Nodes
of another
Agency (A)
.

The
interface of the
CSSE with the service user is called the
service
-
provider interface
.

In this case
,

the
re is a
terrestrial
-
link
service
-
provider

interface to the
Earth User Node

and a space
-
link
service
-
provider
interface to the
Space User
Node
.

In addition to the
Earth
and
Space
User Nodes, there may be
a
utilization management
element
, which is a
user element that manages, controls, and/or monitors the service provided
by a CSSE. The utilization management element may be the same as the Earth Us
er Node
,
and it
may be connected
either
directly to the interface on the CSSE that permits
service
management or
to another CSSE that
supports
the service remotely. As shown in figure 2
-
6,
the interface of the CSSE with the
utilization management

elemen
t is called the
service
-
management
interface
.

The Earth
and Space
User Nodes shown in
f
ig
ure

2
-
7 are instances of
the CSSE shown in fig
ure

2
-
6.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
15

November 2011


Figure

2
-
7
: Basic ABA Case

2.4.4.4

C
ore
SSI C
ase

In the SSI
,

there are cases in which a
Space User Node

and
an Earth

User Node

are supported
by two or more CSSEs. Figure 2
-
8

shows such an example, in which a
Space User Node

(a
spacecraft) and
an Earth

User Node

(
i.e.
,

a spacecraft control center) are supported by a
space
routing node
(
a relay
satellite), a ground
network

element (the ESLT)
, and a terrestrial
w
ide
-
a
rea
n
etwork (
WAN
)
connection.

The MOC for the
space routing node
may also participate,
since

it is responsible for managing and

configuring the
space
routing node and for managing
the space link to the no
de that is provided by the CSSE
, but it is not shown in this
diagram

There may also be a utilization management element, which
also
is not sh
own in this figure.



Figure 2
-
8
:
SSI Core Case

In this document these sorts of
SSI
configurations
may be
called
ABCBA
style
configurations.

The
notional
assumption is that the
Earth User Node

and the
Space User
Node

both belong to the same
a
gency

(
A
),

the
space routing node
and its MOC may belong
to a different
a
gency

(
B
),

and the
CSSE

may

belong to a different
a
gency

(
C
).

So
Earth User
Node

A, get
s

support from the
space routing node
MOC B, connects to

CSSE

C, and then to
space routing node
B, which connects to
Space User Node

A,
hence
ABCBA.

In practice the
data may not flow directly through the
space routing node
MOC, but this element is certainly
involved in managing the transfer

and

in

controlling the
space routing node
.

Of course, much
m
ore complex

SSI deployment configurations
are possible,
or all the elements may be owned
by one agency,
but this
c
ore SSI
ABCBA version serves to introduce most of the necessary
considerations

for any SSI deployment
.


DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
16

November 2011

2.5

SCS ARCHITECTURE
ASSUMPTIONS,
GOALS
, AND CHALLENGES

The goal of the
SCS

architecture is to unambiguously
define
the technical and organizational
structures needed to create and operate
both ABA and
SSI

configurat
ions
.

The ABA
configurations are
the means for providing cross support for missions operating on a single
-
hop space link.

An ABA cross support service provider gives
a single mission access to link
-
layer communications services.

The SSI
configurations are
the means for supporting multiple spacecraft at the same time,
using
a loose confederation
of independent space communications networks, each often
owned and administered by a different space agency.
A
n

SS
-
ISP gives end users of the SSI
access to internetw
orked data communications services
.

If both s
ervice delivery and interoperability interfaces
are to be achieved, each
must be
defined for

both the
users and service providers.

Protocols
must be used
that will allow elements built by different organizations
, at different
times, to interoperate.

The ABA cross support architecture must be implemented in a way
that provides
link
-
layer service
s for single missions.

In order to support a transition to an SSI
architecture
, when this is needed, the architecture

must be implement
ed so as to to be

capable
of
supporting ABA missions and also of
providing internetworking services

to SSI missions.

Ground cross support elements may provide these services when they are

first deployed
, or
they may add them later

and
be
capable of evolving over time as new elements are added and
old ones are retired.

Th
is
SCS

architecture must be prescriptive
enough to be
unambiguously
interpreted
and implemented.

I
t must
simultaneously
be
extensible to pe
rmit 1) new
applications and uppe
r
-
layer protocols to be grafted on
,

and
2)
flexibility in the underlying
physical communications layers so that evolution at this layer does not disturb the operation
of the
SCS

configuration
as a whole.

2.5.1

ASSUMPTIONS

2.5.1.1

ABA
Configuration Assumptions

The major
architectural assumptions underlying the SCS for ABA configurations

are as
follows
:


The SCS ABA elements
will typically be
owned and administered by different space
a)
agencies
.


The SCS AB
A services are to provide space
-
link services to end
-
user missions
.

b)

Elements of the SCS for ABA services will be deployed on Earth,
and
on remote
c)
planetary surfaces

or
in space
.


The SCS ABA
services
must be capable of providing a stable platform for
single
-
hop
d)
operations
,

but they

should also permit
deployment

of upper
-
level
protocols.


The SCS ABA may use dedicated
link
-
layer service

elements, but it should also
e)
permit use of service element
s that support ad
-
hoc relay
and internetworking
services.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
17

November 2011


SCS ABA elements may have operational, resource, and/or visibili
ty constraints due
f)
to other requirements and will typ
ically not be available on a 24
-
hour
basis.


The SCS ABA
services
must provide emergency commanding services in order to
g)
handle off
-
nominal spacecraft situations.

2.5.1.2

SSI
Configuration Assumptions

The

major a
rchitectural assumptions underlying the
SCS for
SSI

configurations

are as
follows:


SSI is
a loose confederation
of independent space communications networks
.

a)

The SSI elements
will typically be
owned and administered by different space
b)
agencies
.


The SSI

is to provide space
internetworking services to end
-
user missions
.

c)

Elements of the SSI will be deployed on Earth, on remote planetary surfaces, and in
d)
space
.


The SSI must be capable of providing a stable platform for
networked
operations and

e)
also permit e
volution of upper
-
level services and lower
-
level physical protocols
.


The SSI may contain dedicated service elements, but it must also permit use of hybrid
f)
service elements that support science, exploration, or other operational goals in
addition to
SSI
communications services.


SSI elements may have operational, resource, and/or visibility constraints due to other
g)
requirements and will typically not be available on a 24
-
hour

basis.


The SSI must provide emergency commanding
and telemetry
services in order
to
h)
handle off
-
nominal spacecraft situations
.

2.5.2

GOALS

2.5.2.1

Architecture Change Goals

The architecture change goals are as follows:


c
reate an evolving international communications infrastructure that supports the
a)
science observation and exploration goals of the col
lective set of space agencies
;


e
volve the existing ABA cross support services to provide a more complete range of
b)
single
-
hop functionality and interoperable inte
rfaces;


d
efine new services such that they completely support ABA configurations and also
c)
provi
de a
transition path to SSI services;


e
volve the current operational approaches to one that provide
s

SSI services in any
d)
operational domain where such services will be of benefit
;

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
18

November 2011


c
reate an infrastructure that permits any connected mission element to commu
nicate
e)
in a timely and secure way with any other permitted mission element
.

2.5.2.2

A
rchitecture Description Document
Goals

The
CARM

goals are as follows:


describe

the technical architecture,
i.e.,
the services, protocols, and interfaces
,

such
a)
that new SCS ABA services can be
understood
;


describe

the technical architecture,
i.e.,
the services, protocols, and interfaces such

b)
that an SSI can be
understood
;


describe

the technical architecture such that
a smooth transition path from the ABA to
c)
the SSI configurations
is presented
and that both mo
des are supported in the future;


d
escribe how to evolve to the SSI from the
ABA via transitional strategies;

d)
2.5.3

CHALLENGES

The major chal
lenges to achieving ABA and SSI end
-
to
-
end interoperability are as follows:


The SCS elements will typically be owned and administered by different space
a)
agencies.


The individual
space mission development
projects are
driven by agency science and
b)
missi
on goals, as is appropriate, and cross support is often
a
secondary

(or tertiary)
consideration
.


Missions often adopt standard link layer protocols, but may utilize local adaptations
c)
or specializations that do not
, in general,

interoperate.


Missions often
develop their own specialized, non
-
interoperable, protocols above the
d)
link layer.


Implementation of the full protocol suite for space internetworking
may be

costly for
e)
early
adopters;

space internetworking must offer significant mission data return and
cos
t advantages to be seen as a benefit.


2.6

TRANSITIONAL STRATEGIES

The accepted CCSDS standards (
i.e.,
Blue Books) available today mainly address
single
lower
-
layer protocols and services and do not tend to address end
-
to
-
end services.
Many of
the interfaces t
o provide fully interoperable ABA
link
-
layer service
s are just now being
defined

and not all the existing ones are implemented by the majority of space agencies
.

Included in this set of s
ervices are all of the new CSTS
-
based services for radiometric data
transfer and unframed
telemetry
, as well as the services for monitor data and service control.

Standardized cross support file
-
transfer services are also in discussion
,

and all of these are
needed to provide fully intero
perable ABA configuration services.

In the absence of agreed
-
upon

interoperability standards
,

the existing service providers ha
ve

defined their own local
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
19

November 2011

standards, which, while they work, are not interoperable and place a burden on any user
organization t
hat needs to integrate with services offered by different providers.

The
service
-
management
protocols used
to
request and configure all of these new services
,
and some existing ones

(e.g.,
radiometric tracking, ranging, and delta
-
DOR
)
,

are also
evolving.

A
t present
,

the
service
-
management
specification only support
s

basic command
and
telemetry
.

Beyond
service management
there are not yet agree
d
-
upon

standards for
service catalogs
or
for service agreements and service planning,
which are
the necessary pre
-
co
nditions for cross support services.

Currently,

these are all done

by management,


outside
of any agreed
-
upon

standards
,

and
are
typically very “hands
-
on
.


In order to transition from
the current situation to one where users of ABA services are offered co
mmon and consistent
service interfaces, both for service
provision
and service utilization management, these new
service interfaces and
protocols must be
fully
defined and
widely
implemented.

Once

this is accomplished
,

the needs of ABA missions will be met, but it will not solve the
needs
of missions that
require

relay operations
.

At present
,

relaying is done by the user
missions themselves
,

and no two missions do it
in quite
the same way.

There are no agreed
-
to

standards for relaying, aside perhaps, from Class 3

and
4 CFDP,
which have seen little
implementation
.

The general approach to

relaying


that has the greatest
potential
for
long
-
term

success is adopting the SSI approach, but s
ome of the standards
requi
red

to achieve the
SSI are
still in development
; t
herefore
, the set of CCSDS s
tandards needs to grow in the
future to provide full coverage of
both these additional ABA services and also
the SSI
architecture.

These standards must
support current ABA missio
ns,
enable the future SSI
,

and
also provide useful services that support current operations while building future capabilities
for the SSI.

Space agencies that offer either ABA or SSI services are
expected

to document their
services
in an accessible service catalog [??] which should be available on
-
line.

The
catalog will
docu
ment the service providing system capabilities, provided services and interfaces,
protocols that are supported, and the means for establishing agreements for service.
The
catalogs are expected to include all the
agreed

standard services, but may also include other,
specialized,
network specific
services.

The
service agreement

[??] documents the agreement
between the service user and the service provider. This agreement covers the period of
service,
mission characterist
ics,
specific
capabilities

to be used,
and other details required to
establish the what, when, and how of services.

The agreement and
detailed

mission

configuration
information are used to define the specific system and equipment parameters to
provide the
correct services.

Space missions are normally reluctant to adopt new standards before
they are
full
y specified
and

validat
ed
. A few agencies may be able/willing to start implementing new standards while
all of the
formal specification
s

are still

in progres
s,
but
other
s

will prefer to see the
complete
final
suite before they initiate implementation
. In addition, even when
all of
the
new ABA
and
SSI architecture and standards
are

fully defined, it cannot be expected that
all
agencies
will be able to implement the migration at once because of the long development times for
space projects and ground infrastructure enhancements. Therefore, at
some

point in time
,

an
unbalanced situation with respect to assets in space and on the g
round will exist. To be able
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
20

November 2011

to perform
space cross support
in such a landscape, where older systems will coexist with
newer ones, a transitional strategy
must be
defined to bridge from the current
ABA
configurations,
to
intermediate states, to
the final S
SI architecture.

The transitional strategy addresses the following issues:



definition of extended services at the link level to meet current and future needs;



backward compatibility with legacy missions;



migration to operations based on files as basic end
-
to
-
end data exchange structures;



provision of data
-
forwarding capabilities, aim
ing at end
-
to
-
end, by implementing
hop
-
by
-
hop relaying;



addition of new capabilities for hardware/emergenc
y commanding and return of link
-
layer data;



implementation of a

learni
ng


phase towards fully automated Internetworking;



adaptation to operations based
on
delay awareness
/unawareness
;



provision of cross support capabilities from
an ABA

infrastructure to more advanced
agencies already migrated to SSI;



testing and validation o
f the internetworking concept before adopting it in its final
configuration
.

Following this strategy
,

participating
agencies will be able to
implement the
ir

ABA services
in
way
s

that support

current missions and also open

a path to the future.

They will be able to
join the transitional phase
without
directly
offering
either of
the native n
etwork
-
layer routing
service
s

shown
in figure

2
-
5
.
T
hey will be able to implement the
se


transitional


link
-
layer
service
s based on CCSDS p
hysical
-

and
link
-
layer protocols
,
interoperable

cross support
protocols,

and
using
specific agreements for
ground
network management

and service access
.

Because there are no
t yet

well
-
established standards for such
cross
-
support
interactions, th
ere
may be many
p
ossible interim

configurations, they may differ in many details
;
many ad
-
hoc
interim approaches have
already
been implemented.

This document
describes
how to
approach the general problem, and
the companion SCS
-
ADD
provides some sp
ecific
recommendations,
but there is no attempt to be complete

nor to

cover all possible
configurations
.

2.7

FOUR VIEWS OF THE ARCHITECTURE

Large
-
scale system architectures are complex
and
must be considered from different
perspectives, including
both
technical and operational

views
.
An architecture that provides
multi
-
agency space communication cross support services and uses service systems

or
elements
,

has
many technical and organizational aspects to

it
.

To help make each of these
aspects clear, t
hi
s
CARM
uses multiple
v
iews to describe space communication cross support
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
21

November 2011

services and systems, each focusing on different aspects associated with the space
communication cross support services and systems.

The v
iews used in this architecture are:



a

s
er
vice
v
iew,



a

p
hysical
v
iew
,



a

c
ommunications
v
iew
,

and



an

e
nd
-
to
-
e
nd

d
eployment
v
iew.

These v
iews were defined based on four of the six
v
iewpoints of the RASDS [2], which were
themselves
defined based on the five
v
iewpoints of the Reference Model of Open
Distributed
Processing [3].

See those documents for more background
o
n this approach of using distinct
viewpoints to describe system architectures.

2.7.1

SERVICE VIEW

The s
ervice
v
iew

is discussed in
s
ection 4
, and
is used to describe services provided by
CSSS
e
s/
CSSEs

and their behavioral and interface characteristics.

Specifically, it describes:


f
unctional characteristics of services;

a)

performance characteristics of services;

b)

means for locating and binding to services;

c)

methods

and/or standards for using services; and

d)

methods and/or standards for managing
services
.

e)
2.7.2

PHYSICAL VIEW

The p
hysical
v
iew

is addressed in
s
ection 5
,

and
describe
s

the physical configuration of
CSSS
e
s
/CSSEs

and their physical characteristics.

Specificall
y, it describes:


p
hysical location;

a)

topology and connectivity;

b)

allocated functionality; and

c)

physical media for
access
.

d)
2.7.3

COMMUNICATIONS VIEW

The c
ommunications
v
iew
, which is covered in
s
ection 6
,

describe
s

communications
protocols used for accessing services provided by
CSSS
e
s/
CSSE
s.

Specifically, it describes:


c
ommunications protocols;

a)
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
2
-
22

November 2011


s
uitable

building block


stacks of communications protocols; and

b)

some examples of
simple assemblies of these
communications protocol building
c)
blocks.

2.7.4

END
-
TO
-
END VIEW

The
e
nd
-
to
-
e
nd
v
iew is
discussed in
s
ection 7
, and
describe
s

how to configure the
communications protocol building blocks to construct a set of
representative mission
communications configurations
.

Specifically, it
provides some simple examples of the
following
:


ABA configurations;

a)

transitional configurations;

b)

SSI configurations; and

c)

specific examples of mixed ABA and SSI configurations.

d)
The companion Recommended Practice document, the Sp
ace Cross Support Architecture
Description Document (SCS
-
ADD) provides a more complete set of specific
recommendations for
suitable

building block and end
-
to
-
end

protocol and system
configurations for cross support.


DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
1

Novem
ber 2011


3

OVERVIEW OF
CROSS SUPPORT
TECHNICAL ARCHITECTURE


3.1

CROSS SUPPORT BUILDING BLOCKS

3.1.1

ABA CROSS SUPPORT BUILDING BLOCKS

The
SCS
ABA
architecture
is composed of a set of interconnected elements that, working
together, provide
end
-
to
-
end
communications services for mission users (user nodes).

These
elements are as follows:



The

basic
service element
building block that
supports
the
ABA configurations

is
:

a)


ESLTs
(e.g., ground stations)
.


And
ESLTs

support:

b)


User Nodes (in space and
on Earth, including other planet surfaces)
.

NOTE



F
or purposes of this document
,

the Earth is treated separately from the other
planets
,

and the term

planet


is extended to mean any other Solar System
body (moon, asteroid, comet) that has missions and as
sociated
communications assets.

Figure 3
-
1 shows
an ABA enterprise overview, where
the SCS building blocks for ABA
configurations a
re

shown
an abstract set of facilities, distributed across the Earth and some
remote planetary body, with no implied
ownership.

These SCS elements might all be owned
by one agency, but more typically they will be owned by different agencies and will provide
cross support services to each other.

Any of the

User Node
s, in space or on ground, may
communicate at
the link lay
er with any service
-
providing element, and these communications
are expected to
use

the services of one or more of the SCS building blocks.

The

User Node
s
must implement an agreed
-
upon minimum set of standard link
-
layer and cross support
protocols
,

and the

SCS building block elements must provide the agreed
-
upon set of standard
link
-
layer cross support services.

There are procedures for establishing service agreements,
for requesting services, for delivering data, and for reporting on the state of service d
elivery.


DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
2

November 2011


Figure 3
-
1: ABA

Enterprise Overview

3.1.2

SSI
CROSS SUPPORT BUILDING BLOCKS

The SCS SSI architecture is also composed of a set of interconnected elements that, working
together, provide
end
-
to
-
end
communications services for mission users (user nodes
).


There is a

set of

basic
service
-
element
building block
s that support

the
SSI

a)
configurations:



ESLTs

(e.g., ground stations)
;



space routing node
s
;



Planet
-
Space Link Terminals
(
PSLT
s
);



Terrestrial WANs
;



Planetary WANs
.


And these
service
-
element building blocks
support:

b)


User Nodes (in space and on Earth, including other planet surfaces)
.

Figure 3
-
2 shows the
SSI enterprise overview, where
SCS building blocks for SSI
configurations
are shown
as an abstract set of facilities, distrib
uted across the Earth and some
remote planetary body, with no implied ownership. User nodes are treated separately from
SSI building blocks
because they have simpler configurations and do not offer services to
other nodes, as

SSI
building blocks must. All
of these SSI elements might be owned by one
agency, but more typically they will be owned by different agencies and will provide cross
support services to each other. Any of the

User Node
s, or other SSI elements, may
communicate with any other, and these c
ommunications are expected to use the services of
one or more of the SSI building blocks. Just as in

the terrestrial Internet, the

User Node
s must
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
3

November 2011

implement an agreed
-
upon

minimum set of standard protocols
, and the SSI building
-
block
elements must provide
the agreed
-
upon

set of standard services. There are procedures for
creating service agreements, and as
with

the Internet
,

there ar
e procedures for hooking up a
new

User Node

to the SSI, for requesting services, and f
or inserting a new SSI building
-
block el
ement into the network.

With each agency having very different mission sets and science or organizational goals, one
of the biggest challenges for the SSI is how to coordinate and ensure interoperability of
separately funded developments within each agency

in order to initiate and evolve the SSI.



Figure 3
-
2:
SSI Enterprise Overview

3.1.3

OVERVIEW
OF BUILDING
-
BLOCK FUNCTIONS

Each of the
SCS
building blocks has an associated set of basic functions that distinguish
the
blocks

one from another.

Any of these
building blocks may also incorporate other
functionality, but the basic functions must be included to enable interoperability.

The set of
functions identified here are suitable for both ABA and SSI configurations, but some of the
functions are only
require
d

to provide SSI services.

The basic set
s

of functionalities for each
SCS
building block

are as follows
:


ESLTs

(e.g., ground stations)
:

a)


r
oute connections between terrestrial elements and space

(SSI)
,



provide
i
nterface to

radio
frequency

(
RF
)

space

link
,

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
4

November 2011



pr
ovide
full services for link
-
layer processing and
frame merging
,



provide
full services for network
-
layer processing and routing (SSI)
,



m
ay support
last
-
hop
emergency and non
-
SSI delivery services
,



are a
service
-
management
interface for configuration and
reporting
;


space routing node
s

(SSI)
:

b)


provide
r
outing among space elements
,



provide
i
nterfaces to two or more RF space link
s
,



provide f
ull services for lin
k
-

and network
-
layer processing and routing
,



m
ust support
last
-
hop

emergency and non
-
SSI delivery ser
vices
,



are a
service
-
management
interface for configuration and reporting
;


PSLT
s

(SSI)
:

c)


r
oute connections between planet surface elements and space
,



provide
i
nterfaces to RF space link, either in situ or long haul
,



provide
f
ull services for link
-

and ne
two
rk
-
layer processing and routing
,



m
ay support
last
-
hop

emergency and non
-
SSI delivery services
,



are a
service
-
management
interface for configuration and reporting
;


t
errestrial
WANs (
SSI
)
:

d)


r
oute

connections among terrestrial elements (Internet)
,



provide
i
nterfaces to two or more terrestrial links
,



provide
f
ull services for link
-

and network
-
layer processing and routing
,



are a s
ervice
-
management
interface for configuration and reporting
;


p
lanetary WANs

(SSI)
:

e)


r
oute

connections among terrestrial elements (Internet)
,



provide
i
nterfaces to two or more planet

terrestrial


links
,



provide
f
ull services for link
-

and network
-
layer processing and routing
,



are a
service
-
management
interface for configuration and reporting
.

And these
sets of functionalities
support:


User Nodes (in space and on Earth, including other planet surfaces)
,

which in turn:

f)
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
5

November 2011



are
e
nd
-
user elements, either in space or on some surface
,



provide
i
nterfaces to either RF space link or terrestrial link
,



provide
basic services for link
-
layer processing
,



provide
basic services for network
-
layer processing (SSI)
,

and



provide
a
t least simple routing to
next
-
hop SSI service point

(SSI)
.

The
fully compliant
SCS
building block elements are all expected to provid
e full network
-

and
link
-
layer service
s and to be capable of routing user data from multiple users
simultaneously.

All of the SSI service elements can also handle requests from non
-
SSI nodes
operating at the link layer in ABA style configurations.

Using

th
is approach, fully compliant
ESLTs can support ABA and SSI configurations at the same
time, but an ESLT with only
ABA
-
compliant services cannot support SSI missions.

The ABA

User Node
s only need to be
able to do the
link
-
layer service
s, but they may al
so i
mplement additional mission
-
specific
protocols above the link layer.
The SSI

User Node
s are only expected to be able to do the
minimum necessary network layer functions in order to hand off their data to the next hop,
which

will be an SSI service
-
building
block.

3.2

GENERAL DESCRIPTION
S

OF PRESENT ARCHITECTURE
S

3.2.1

ABA ARCHITECTURES

Most of
the current
space mission operational and cross support configurations are
of
the
ABA style, where a single spacecraft is operated by a spacecraft MOC, using a ground
station
that belongs either to the spacecraft agency or is provided as a cross support service
by another agency.

This basic cross support scenario
was
shown diagrammatically
in figure

3
-
1
; c
ontrast it with the more complex
SSI
topology shown
in figure

3
-
2.

Figure

3
-
3

shows a
simplified end
-
to
-
end
view of the system elements involved in a typical
ABA scenario
:

the
Space User Node, the
E
SLT
, and
the
Earth User Node
,

which is where the
MOC is located
.

In this case
,

two different user end nodes are shown, one
in space
, and one
on the
ground
.

In this case no communication is shown between the
assets in
space, but in an
extended case
,

it might be that the
r
e
are
two nodes
in space that
communicate via an in
-
situ
link.

For these ABA configurations, only link
-
layer protocol
s are used, as is shown in figure
3
-
3.
Figure 3
-
4

shows
how this
transitional configuration might
operate.


Because this particular example assumes that the spacecraft is
away from the Earth, perhaps
at some distant planet, delay
-
aware applicati
ons must
be used above the link
-
layer and
physical
-
layer protocols. Only the
link
-
layer service
s provided by the ESLT are used.

The
end
-
user nodes
,

in space and on the ground
,

may use a variety of user applications, including
CFDP
,

to do standard file processing, o
r a standard file cross support delivery service
[4]

may be provided by the ESLT to transfer files using CFDP.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
6

November 2011


Figure 3
-
3
: Basic ABA End
-
to
-
End Configuration and
Protocol

Stack

3.2.2

ABA RELAY ARCHITECTURES

As
mentioned in
s
ection 3
.2.1
, some missions
are now using simple means for relaying data
among space missions.

Figure 3
-
4

shows an example of how the elements
in figure

3
-
1

might
evolve i
n order to provide a basic data
-
relaying capability in space.

In this case the
Space
User Node

on the planet

s surface
uses the service
s

of a
space relay node

that
acts as a relay.

This space relay node
is a

hybrid


orbiter, in that
its prime mission is
to
perform science
operations
,

but it also provides a service for relaying
data from the
Space User Node

on th
e
planetary surface, over an in
-
situ space link, and forwarding it to the

User Node

on earth.

In
this case the MOC for the hybrid spacecraft acts as
an Earth

Relay Node and performs
whatever manipulations are necessary to accept, process, and forward the d
ata to the
Earth
User Node
.

The ESLT only provides ABA configuration services and does not do any
separate processing of the relay data.

All data
that
flows through the ESLT look
s

like data
sent to and from the space relay node.

NOTES

1

An “in
-
situ” link is
a link that is between two elements that are in relatively close
proximity.

The longest “in
-
situ” links would be among elements in planetary orbits.

2

A “long
-
haul” link is a link that is between two elements that are at planetary distances,
such as Earth

t
o Mars.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
7

November 2011


Figure 3
-
4
: Interim
ABA
-
S
tyle

Data
Relaying

Configuration

The
interim
ABA

relay

architecture shown
in figure

3
-
4

is coordinated
on a point
-
to
-
point,
mission
-
to
-
mission basis.

This
provide
s

highly effective, but also highly idiosyncratic, cross
support services for data relaying.

These
mission
-
to
-
mission

configurations
typically
use a
mish
-
mash of protocols in order to offer a limited form of hop
-
by
-
hop, manually managed,
delive
ry of data.

It would be a misuse of the term to say that this is in any way an
interoperable architecture, since each and every interface is essentially handcrafted
and
particular

to the specific

mission
s
.

Standard
ABA
protocols and service interfaces are
used at
the link layer, but many liberties are
usually
taken,
e.g.,
packet streams being treated as a bit
-
stream
s
, or
packets being wrapped in other packets

(
or in files
)

in order for them to be
relayed. To describe these current configurations in even gen
eral terms would require a
separate document, and the

configurations that are in use

have been so diverse that such a
document would only be of historical significance.

See
Mars Mission Protocol Profiles,
Purpose and Rationale

(
CCSDS 740.0
-
G
-
1
)
, for a disc
ussion of
some of
these earliest two
-
hop
,

data
-
forwarding architectures.

Some additional details on the current protocol
architecture
are

also provided in the sections on transitional strategies.

3.2.3

TRANSITIONAL SSI RELAY
ARCHITECTURES

I
t is
entirely
possible to adapt the sort of mission configurations and deployments shown
in
figure

3
-
4

to use the standard services and protocols defined for the SSI.

Even though the
se

protocols can support much more complex topologies, they are entirely suitable for us
e in
th
ese

relatively simple configuration
s
.

A
minimalist
transitional
approach
that the SISG
studied
is to
implement

the SSI protocols in the
Earth

relay node and space relay node and
just continue to use the ABA ESLT configuration.

The
Earth and Space Us
er Nodes
can also
adopt the most basic SSI protocol set, permitting more automated delivery of data

and
simpler operations without requiring ESLT upgrades
.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
3
-
8

November 2011

The
recommended
approach is to
upgrade
the ESLT to include full SSI functionality and then
adapt the

Earth relay node

and the
space relay node

to also provide SSI services.

This can
work with the sort of hybrid science/SSI mission that is shown doing relayed services. These
elements then provide the simplest backbone configuration for SSI services.

What
is
required

next is to either adapt the end
-
user nodes in space and on groun
d to also include basic SSI
end
-
node capabilities, or to use the
last
-
hop

and
first
-
hop

services to communicate with them
as non
-
SSI nodes.

The former approach is preferable, but t
he latter will work and may be
required

as a transition path for many existing missions.

Later sections of the
CARM
will
describe this transitional approach in more detail.

The strongest motivation for
taking
the recommended
transition
al approach

is that it is the
best way to deploy an interoperable collection of elements that
can
evolve to
support the
full
SSI services.

In the absence of this

approach
,

the alternative
will be
to continue to handcraft,
mission by mission, the interfaces and functi
ons for doing simple data relaying. While th
is
works, and it may be a lower
-
cost app
roach when viewed on a mission
-
by
-
mission basis, in
the long run it is more costly for each agency, and for all of the agencies as a whole, because
these specialized, one
-
o
f
-
a
-
kind interfaces and protocols are continuously being invented,
developed, and operated.


Hugh note:

1.
Create ESLT network
capability

2.
ERNs and SRNs

needs
more planning and will take
longer

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
1

Novem
ber 2011


4

SERVICE VIEW

4.1

GENERAL

Th
is

SCS

s
ervice
v
iew describe
s

space communications cross support services
that are
provided by
CSSS
e
s and
those systems’
behavioral and access characteristics. This
view
is
separate
from the physical
view

(which covers
the
types of nodes and
physical locations
where the services are provi
ded)
,
the
communications

view (which covers

protocols used to
access the services
)
, or the
end
-
to
-
end

view (which covers
end
-
to
-
end protocol deployments
and related

issues involved in
d
esigning and
using the services
)
.

Each of those views is
covered in its own section.

This
service view of the
architecture was developed based on the Cross Support Reference
Model (CSRM) [1]
,

but extends it in such a way that it can be applicable to servic
es provided
at places
other
than ground stations, such as onboard communication/data systems
and
spacecraft control centers.

I
n the CSRM, processing of space
-
link protocols by the service
provider (which is assumed to be a ground station) is treated as pro
duction of a service
on the
terrestrial interface to the user

(see 4.
2
.2
in
[1]). In this architecture, however, it is treated as
production of a service and
processing of communications protocols used on any of the
interface
s

of a CSSE, so that services can be defined independently of the location of the
service provider.

For example, a service of delivering frame
s

or files [8
, 1
0
] can be provided at a ground
station
,
and
these data objects are opaque to the service provider
.
If the file contains packets
,

then processing of the Space Packet Protocol

(
SPP
)

[9]

for producing the service

is only
required

at the spacecraft control center. In this architecture
,

the attributes for service
production are those for processing the co
mmunications protocols used on the space link. For
a detailed discussion of the
underlying

communications

protocols that support services, see
s
ection 6
.

This
s
ervice view of the architecture describes service interfaces (space and ground),
methods for
usi
ng

service
s
, and cross
-
supported behavior for planning, scheduling,
configuring, requesting, delivering
,

and reporting on services.

The
s
ervice view also
addresses the means for locating and binding to services

at service access points
, including
an initia
l discussion of the roles
that protocols

play in the binding process.

These service
interfaces and binding methods are a first compliance point for the architecture.

The
re are two sets of

services described in this section
: those suitable for ABA
configur
ations
,

and those that can also support SSI configurations. The ABA services

are
primarily those identified in IOAG Service Catalog
1
. The services in Catalog 1 support the
single
-
hop ABA mission configurations. T
he services defined in Catalog
2

are
described next
as they provide the underpinnings for the
SSI
upper
-
layer space internetworking services.

This CARM assumes that the SLE and CSTS protocols will be used to define the link
-
layer
service interfaces for all ESLTs operated by any space agencie
s or other, possibly
commercial, service providers.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
2

November 2011

4.2

OVERVIEW OF ABA SERVICES

Utilizing ABA services is analogous to a user with a dial
-
up telephone modem using
the
services
provided by
their

local phone company
(telco)
.

T
h
e user must establish a contract
for services with the service provider
,

and
can

then
,
as
needed,

establish a connection using
the service
.

The major difference for space communication services is the
requirement
to
schedule most of the underlying space communication links ahead of time,
when the ground
assets are available and when the spacecraft is in view and ready to communicate.

There is
also
much more choreography involved in space communication, but in many ways the
link
-
layer service
s are
similar to terrestrial services
, an
d the link contents are opaque to the
service provider.

For successful communications to the mission
,

it

is also nece
ssary
to design
services and applications with an awareness of the time delays
, antenna pointing,

and
disconnection that are driven by
the
physics

of the
mission and
spacecraft operations
environment
.

In an ABA configuration
,

a user

s primary
interfaces to the service provider

are the
link
-
layer
service request
and service delivery
interfaces
either
on the ground
or
in space.

The service
user

produces encoded space
-
link frames for deli
very and receives decoded space
-
link
frames.

The activities
with
in the service provider and the details of
the
service production are
opaque to the service user, but a certain amount of monitor data and reporting

is provided to
allow the service user to determine the state of communications
.

Returning to the terrestrial telco analogy, t
he
ABA service

is similar
to telco in that
:



The
ABA service provider
may require a contract of some sort for connecting to its
ser
vice.



O
ther
ABA service providers

may be used if they offer comparable services and
interfaces
.



The only
required

standard
end
-
to
-
end

layer is the
link
-
layer

protocol.

Application
service,
i.e.,
file or message delivery, may be standardized end
-
to
-
end, but this is not
required
.



The
space
-
link production

activities

are

opaque

to the user and operate the same
regardless of which provide
r delivers the

service.



The interface between the
Earth User Nod
e

and the
service provider

must be
standardized and
compatible at the link layer.

The same is true of the

interface
between the service provider and
the
Space User Node
.



There will be some stated level of service commitment, including level of service,
com
pleteness,
and

user conditions

about
delivery
latency

and throughput
.

4.3

OVERVIEW

OF SSI SERVICES

Services in the SSI
configuration
use

many of the underlying ABA capabilities, but the SSI
services
are
more
similar to those
offered by an

ISP
, instead of si
mple telco link services.

The

major

difference
for the SSI is the continuing
need to schedule
and choreograph
the
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
3

November 2011

underlying space communication links

over which SSI traffic flows.

As with ABA services,
i
n SSI configurations
,

there is also the need to

design services and applications with an
awareness of the time delays and disconnection that are driven by physics.

In the SSI
there is
a distinction between the service

User Node
s, of which there may be several, and the service
provider nodes.

The SSI se
rvice provider

s
primary view
s

of the network are the service
request
and delivery
interfaces on the ground and the
service
-
provider interface
s in space.

Th
ese

will be discussed separately.

The SSI s
ervice user

s view is that of an SSI
-
compliant network se
rvice router interface,
essentially a space
SS
-
ISP
.

B
etween
the SSI service user

s local router and the destination,
there may be network service
s

provided by other
SS
-
ISP
s, but these should be transparent to
the end user (aside from delays due to physics
and availability of communications contacts).

This is very similar to the Internet where all
one

need
s

to be concerned with, as
one
hook
s

up
a
laptop in some random
WiFi hotspot
, is the local ISP who provides that
end
-
user
connection service.

All of the ot
her transcontinental or transoceanic ISPs, transport services,
circuits, and routers are invisible to
the user
unless
one
probe
s

for them

or they fail
.

The SSI is in other ways similar to the terrestrial Internet
, in that
:



The
“first
-
hop


SS
-
ISP

may require a contract of some sort for connecting to its
service.



The services of other
SS
-
ISP
s are usually provided on a

peering


basis and
usually
do
not need any sort of direct contract for service.



The only
required

standard
end
-
to
-
end

layer is the
network protocol.

Application
service
s

(
i.e.,
file or message delivery
)

may be standardized end
-
to
-
end, but this is not
required
.



The end
-
to
-
end services should be transparent to the user and operate the same
regardless of which intermediate nodes actually

provide service.



The interface between the
Earth User Node

and the first
-
hop
SS
-
ISP

must be
compatible at the link layer as well as the network layer
.

The same is true for the last
hop.

T
here is no requirement for that to be the case end
-
to
-
end.




There wi
ll be some stated
SSI
service commitment, including level of service and
completeness, but
there will
also
be
stated
expectations about latency
.

In contrast to the SSI service users, the SSI servicer providers have responsibility for the SSI
routers, routi
ng updates, and for managing the network assets, but they also have
responsibility for managing the terrestrial and space links that support SSI traffic flows.

In
this regard
, the service
-
providing nodes must operate a lot like ABA nodes at the link layer,

and SSI nodes at the network layer.

SSI service
-
providing nodes coordinate among
themselves in order to provide SSI services for the user.

Once these SSI services are
operating properly
,

they may also be used to carry

SSI user data or

data between SSI
ope
rating nodes.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
4

November 2011

4.4

S
ERVICE
-
USER VIEW

From the point of view of a
n

SCS

ABA
user
,

the
service provider’s
visible
interfaces
are the
service

request
interfaces
and delivery interfaces
on the ground and the service
delivery
interfaces in space.

As shown
in figure

4
-
1,
an Earth

User Node

will access two different, but related, kinds of
interfaces to use
cross support
services:
one

is the
service manageme
nt
that is
used
for
planning, configuring
,

and requesting services
;

the other

is the service

delivery interfaces.

The
service
-
management
interface will be based upon CCSDS
service
-
management
standards, and the service data
-
delivery interfaces will be based

upon CCSDS CSTS

and

SLE
services
.



Figure 4
-
1
: Service View

For SSI configurations
, the service
-
providing nodes use essentially the same service request
and service delivery interface to construct the space link between the

space relay node and
the
Earth relay node

that manages it.

In the SSI a conformant ESLT that provides the ground
communications service will also support the SSI
network layer protocols and the means to
merge multiple streams of data onto a single space l
ink.

Once the link is
established to the
space relay node
,

any data destined for end nodes that can use that path will flow at the
network layer.

NOTE



The SSI ESLT will provide what is in essence an ABA service to the
Earth relay
node

(so it can directly

control the relay spacecraft without need
ing

SSI to be
operational) and an SSI service to that relay spacecraft (possibly) and to all other
spacecraft
to which
the relay provides services.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
5

November 2011

In the SSI
,

service

User Node
s do not need to concern themselves
with scheduling the space
links;

this is the province of the service providers.

The service users may wish to know what
the schedules are in order to estimate the time of data delivery, but the only link they need to
actually configure and control, in some

way, is the link between their
Space User Node

and
its nearest SSI access point.

NOTE



The SSI provide
s

priority delivery flags and may offer some sort of delivery
estimates and/or guarantees. It should also offer user feedback on delivery
success and st
atus, but this is still TBD.

There will be different upper
-
layer services, such as end
-
to
-
end file and message transfer,
that will run on top of the SSI network layer protocols.

These upper
-
layer services can take
advantage of the end
-
to
-
end transfer,
routing, forwarding, and reliability services provided by
the internetworking layer. In order for the SSI to work
,

all

of these services and protocols
must be standardized internationally so that requests made of any SSI

portal,


and
transported

by any
SS
-
ISP
, may

be passed along to other SSI elements until they reach their
final destination, which may be many

hops


away.

While not all SSI communications will
take place between the Earth and elements in space
,

many of them will, so it is useful to start
t
here.

NOTE



All of the interoperable SSI services and protocols must be standardized, just as
all of the Internet
specifications documents, Request for Comment (
RFC
)
,

are
standardized. This does not mean that users must standardiz
e

their mission
operations n
or agency specific protocols that run on top of the SSI
, but this is
permitted
.

4.4.1

REPERTOIRE OF STANDA
RD SERVICES

The
SCS
services can be grouped into two types, related to the operational configuration in
which they will be used
: single
-
link
se
rvices
(ABA configuration), and SSI services
(ABCBA configurations, and others).


4.4.1.1 ABA Standard Services

The

ABA configurations will be used where only single
-
hop, point
-
to
-
point,
link
-
layer
service
s are
required

to support single
-
hop missions th
at do not need the added functionality
of the SSI.
These link
-
layer functions also correspond to IOAG Service Catalog 1
[4]
.

The
ABA configurations
will
also
be
used within the SSI as the means for
the
space routing node
MOC

to control its
space routing
node
. While it is possible to do some of the necessary
housekeeping and management functions over

the SSI protocols, in general it is assumed

that
these will remain as link
-
layer command and control functions.

The
ABA, link
-
layer service
s

include the follo
wing


Forward data delivery services
:

a)
1)

f
orward
a
pplications services,
including forward file service

delivery of files to
a mission

User Node

(typically in space), possibly via intermediate store
-
and
-
forward nodes
;

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
6

November 2011

2)

f
orward transfer frame service

delivery of
CCSDS AO
S
or
telecommand

frames
to a mission

User Node

(typically in space)
;

3)

F
-
CLTU service

delivery of
Command Link Transmission Units
(
CLTUs
)

to a
mission

User Node

(typically in space)
;


Return data delivery services
:

b)
1)

re
turn
a
pplication services, includi
ng return file service

delivery to a mission

User Node

of files received from another mission

User Node

(typically in space),
possibly via intermediate store
-
and
-
forward nodes
;

2)

R
-
AF

service

delivery to a mission

User Node

of transfer frames received from
a
nother mission

User Node

(typically in space)
;

3)

R
-
CF

service

delivery to a mission

User Node

of transfer frames of selected
VC
s received from another mission

User Node

(typically in space)
;

4)

r
eturn unframed
telemetry

(RUFT)
service

delivery to a mission

User Node

of
unframed data from another mission

User Node

(typically in space)
;


Radiometric services
:

c)
1)

r
aw
radiometric

data

delivery of trac
king data provided in near real
-
time with
little or no processing
;

2)

v
alidated

radiometric data

delivery of tracking data that has been processed for
validation and error correction
;

3)

delta
-
DOR

del
ivery of delta
-
differential one
-
way ranging data that has been
processed to the level of observables
.

4
.
4.1.2

SSI

Standard Services

The
SSI infrastructure add
s

a new category of internationally

standardized services for its
s
pace
i
nternetworking users. The primary role of the SSI is to provide fully interoperable
space internetworking and routing services,
i.e.,
networking (
ISO Layer

3) and end
-
to
-
end
transport (
ISO Layer

4).

These new ser
vices are inserted beneath the application
-
layer
services (such as
f
ile or
m
essage
t
ransfer) and above the
l
ink
-
layer service
s.
In addition to the
underlying ABA services and the associated
service
-
ma
nagement
and control functions, t
he
SSI
requires new network management services.

The SSI
-
specific service suite exposed to
the users includes:


Forward data delivery services
:

a)
1)

f
orward internetworking service for DTN

routing of BP internetworking data
units

from a mission

User Node

(typically on the ground) to another mission

User
Node

in space, possibly via intermediate routing nodes
;

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
7

November 2011

2)

f
orward internetworking service for IP

routing of IP internetworking data units
from a mission

User Node

(typically on the ground) to another mission

User Node

in space, possibly via intermediate routing nodes
;

3)

f
orward
last
-
hop

delivery service

a standardized
last
-
hop delivery service in the
forward direction to support

essential commanding,


legacy (non
-
ne
tworked)
mission

commanding, and Proximity link
-
time distribution
;


Return data delivery services
:

b)
1)

r
eturn internetworking service for DTN

routing of BP internetworking data
units from a mission

User Node

(typically in space) to another mission

User Node

on
the ground, possibly via intermediate routing nodes
;

2)

r
eturn internetworking service for IP

routing of IP internetworking data units
from a mission

User Node

(typically in space) to another mission

User Node

on
the ground, possibly via intermediate routing
nodes
;

3)

r
eturn
last
-
hop

delivery service

a standardized
last
-
hop delivery service in the
forward direction to support

essential


telemetry
, legacy (non
-
networked)
mission
telemetry
, open
-
loop recording (
entry descent and landing [
EDL
]

and
emergency), Proxi
mity link tracking

and
time data return
;


Radiometric services
:

c)
1)

n
o

new service is added, but open
-
loop recording and Proximity link radiometric
data may also be returned from the
last
-
hop

service
;


Position and t
iming services
:

d)
1)

t
ime
s
ynchronization service

will allow aligning clocks to a common timescale,
such as
universal time coordinated (UTC),
but it requires that both clock
correlation and time transfer be performed. Time synchronization in space may
also require knowledge

of orbit
al dynamics and relativistic effects.

N
OTE




T
he terms

forward


and

return


are
used
in this document

even for SSI
, and
they are associated with

forward


commands or requests
,

and

return


of data
;
however
,
for SSI nodes
these

directions


are relativ
e to the sender and receiver,
not just to communications to/from the Earth.

A forward request could be from a

User Node

on a planetary surface to another

User Node

elsewhere on
either
that
same planet, or
to one
in orbit around the planet.

Elsewhere in thi
s document we
will use the terms
sending

for

outbound connections and
receiving

for
inbound
connections.

In the general case
,

intermediate routing nodes will also do staging
of data, route selection, and forwarding of these data when a path is available in

the proper direction.

4.5

OVERVIEW OF
SERVICE MANAGEMENT AND NETWORK CONTROL

To provide space communication services
,

it is necessary to provide the users with
service
-
management interfaces

that permit them to plan, schedule, request, configure, and monitor
DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
8

November 2011

the operations of the underlying
link
-
layer service
-
providing elements.

For the basic ABA
link configurations
,

the following set of
service management
and network
communication
asset
cont
rol functions
is

used.

The
service
-
management
functions are the primary ones that
are exposed to users, the others are usually i
nternal to the service provider:



s
ervice management
:



s
ervice planning
,



s
ervice requests scheduling
,



s
ervice

visibility and controllability
,



s
ervice reporting and accountability
,



n
etwork control
:



n
etwork
s
cheduling
,



n
etwork asset configuration and control
,



n
etwork asset monitoring
.

Figure 4
-
2 shows how service planning and data delivery for the space links is

configured
and managed.

These links must be established and operational before any traffic may flow
.

The traffic may be link layer, the target node in an ABA configuration, or it may be SSI
intended either for the next hop node

or some more distant
destination.

For any of these
services
,

planning must be done, which involves
review of service catalog offerings,
estimating link and view

period parameters,
negotiating service agreements, planning and
allocating resources, and performing loading analyse
s.

For
link
-
layer service
s, which will be
required

between each of the communicating assets, RF and link compatibility studies will
also have to be performed.

Link
-
layer service

requests include link asset demand assessment,
prioritization of user
link
-
lay
er service

instances
,

and development of network element
service schedules.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
9

November 2011


Figure 4
-
2
: Service Request and Delivery for Underlying SLE/CSTS Services

For ABA configurations
,

request
s for

link
-
layer service
s
are

handled betwe
en the
link
-
layer
service

provider (ESLT) and the MOC
for
the

User Node

in space.

The
u
ser MOC uses
service
-
management
requests to plan and schedule the link in accordance with the contract
established with the service provider.

It then requests space link

instances, making reference
to one of the pre
-
established spacecraft communication configurations.

If n
ecessary it may
also use a real
-
time
service control
interface to request configuration changes
to the link
(e.g.
,

bit rate, mod index) of the service p
rovider.

Once the space link is up and properly
configured
,

data can flow, usually bi
-
directionally, between the Space User Node and the
Earth User Node
.

These data flows use the forward an
d return services described in
s
ection
4
.1.1.

For SSI configuration
s
,

the
service
-
management
requests occur between the ESLT and the
MOC of the next hop destination, which may either be a
s
pace routing node
or some other
relay asset such as a PSLT.

Only the project that

owns


the link to the next
-
hop SSI node
may configu
re and manage the link, but once the link is operational
,

SSI traffic will flow as
priority and capacity allow.

The
space routing node
MOC
uses

the ESLT in an ABA configuration to control the link to
the
space routing node
, sending commands to control s
pac
e
r
outer operations
,

and receiving
engineering
telemetry

to assess
,

state
,

and report on any anomalous conditions.

This link will
also be used to transmit any necessary routing information and updates to the routing node,
and possibly on to other assets in

the SSI.

DRAFT CCSDS REPORT
CONCERNING SPACE DATA SYSTEM PRACTICES

CCSDS 901.0
-
G
-
1

Page
4
-
10

November 2011

In addition to the basic
link
-
layer service

interfaces

that provide essential
telemetry

and
commanding of the
space routing node
, there is also a set of network control services that
is

used by the SSI service providers to schedule, configure, control, monitor
,

and coordinate the
operation of the SSI itself.

As shown
in figure

4
-
3, service
-
request scheduling for space internetworking includes