MATERIAL FOR GREEN BOOK
(From document: tcons_rd_10May04)
Author: Massimiliano Ciccone
Date: 18 May 04
1
TIME-CONSTRAINED COMMUNICATION CLASSES
Different applications have different timing constraints for data transfer that, ideally, TCONS
should be able to satisfy. The following are classes of time-constrained communication for
applications:
 Bounded Latency: a transfer has to be completed before a given instant in time, but when
exactly the task is performed during the time interval between now and the deadline is not
important for the quality of the final result.
For example, a command from an AOCS central unit must reach an actuator within 50
micro-seconds at the most.
The Bounded Latency class is specified by the following parameters:
o End-to-end deadline (D sec).
 Zero execution time: the data transfer must be performed in a time period that is zero in the
ideal case.
For example, digital control theory assumes that taking a measurement, calculating the
control action, and sending it out to a peripheral device all take place instantaneously.
 Slotted: the data transfer must get a fixed amount of ‘service’ per time slot.
For example, in the TCONS context, ‘service’ can be expressed in terms of ‘network
bandwidth’ or/and ‘maximum allowable data rate’ required during a specific time slot.
The Slotted class of service is specified by means of a number of parameters:
 ?? (TBD)
 MORE CLASSES ? (TBD)
1.1
HARD VS. SOFT REAL-TIME
There is a distinction to be made between “soft real-time” and “hard real-time”. Such distinction is
often (implicitly and mistakenly) related to the time scales involved in the system:
Soft real-time tasks must typically be scheduled with (coarser than) milli-seconds accuracy, and
Hard real-time tasks with micro-seconds accuracy.
Even though this implicit assumption can be acceptable, there is a more appropriate one to be
applied for a spacecraft onboard communication:
Soft real-time indicates that not meeting the specified timing constraints does not have disastrous
consequences for the related user-level activity or hosting system, while it is a disaster in case of
Hard real-time.
Most of the communications onboard a spacecraft have hard real-time characteristics. The TCONS
network protocol should support real-time communication by ……?? (TBD).
1.2
LATENCY
The latency (or tardiness) of a task (i.e. data transfer) is the difference between the instant of time
on which the task should have started (or finished) and the instant of time on which it actually did
or, in different contexts, the time between the generation of an event, and its perception.
Latencies in the execution of software tasks are due to several factors:

The timing properties of processor, bus, memory (on-chip cache, off-chip RAM and ROM)
and peripheral devices,




The scheduling properties of the OS,
The pre-emptiveness of its kernel,
The load on the system (i.e., the number of tasks that want to be scheduled concurrently)
The context-switch time. This latter is the time the processor needs to save the data of the
currently running task (e.g., registers, stack, and instruction pointer), and to replace it with
the local data of the newly scheduled task.
Few of these factors are constant over time, and the statistical distribution of the latencies in the
subsequent scheduling of tasks is called the jitter.
1.2.1
SOFTWARE VS COMMUNICATION LATENCY
The performances of the TCONS communication stack are determined by both the efficiency of the
communication modules composing the stack (e.g. service algorithm, protocols, network
management services etc.) and the promptness of the TCONS hosting system (hardware and OS) in
processing and executing software tasks involved in end-to-end real-time communication. In the
remainder of this document we will refer to the former as Communication Latency and to the latter
as Software Latency. Although both of these can influence real-time data transfer by introducing
indeterminism into the timing behaviour of the TCONS stack, they do so to different degrees.
The exact magnitude of software latency changes very strongly between different hardware and
different OS. In the SOIS context of onboard communications, we assume that hardware as well as
RTOS (e.g. RTEMS or VxWorks) capable of guaranteeing hard-realtime performances will be
used, therefore reducing software latency to the minimum.
Hence, in the TCONS communication network, the progress of SOIS real-time user-level activities
and their ability to meet end-to-end deadlines relies more heavily on the efficiency and correctness
of the modules implementing the TCONS communication stack (e.g. scheduling policy employed
by the communication medium for packets travelling the network) rather than on the real-time
capabilities of the hardware and the OS composing the hosting system.
2
QUALITY OF SERVICE
The QoS is an indication of the properties of a communication between two end systems. QoS
refers to a set of TCONS QoS parameters that characterize the network traffic.
QoS requirements are assessed to determine if they can possibly be met. If, for example, the level
of service requested cannot be provided, the user can be asked if a certain level of degradation is
acceptable before proceeding further.
2.1
FLOW-BASED VS CLASS-BASED QOS
Flow-based algorithms can guarantee good QoS to the user by reserving (a priori) network
resources along the route to each single flow of packets between two end systems. This approach
has some drawbacks:
o it requires an advanced set up for establishing each network flow, involving a complex,
time and bandwidth consuming router-to-router exchange of information
o Each router needs to maintain an internal per-flow state. This increases the vulnerability of
the network system by making router crashes more disastrous and difficult to recover.
Moreover, it requires a considerable amount of memory and processing time for being
implemented.
o Once resources are reserved for a specific flow, the allocated bandwidth cannot be diverted
to other flows even if unused
In contrast, a class-based approach can be used. In this case the routers composing the TCONS
network can offer ‘differentiated services’ based on predefined service classes. Each packet
travelling the network carries its own QoS (or Type of Service) field, with router implementing
forwarding rules on a per-packet basis instead of on a per-flow basis.
The advantages of such approach are:
o does not require any advanced connection set up at the network-level (while still possible at
transport level),
o no resource reservation,
o no complex time-consuming end-to-end negotiation for each flow
o more efficient use of available bandwidth
o more secure, scalable and easy to implement
The important difference here is that packets related to different end-to-end communications are
merged at each router and treated the same way if they belong to the same class of service.
In class-based services, each router can still allocate bandwidth to each class of service in a
weighted manner based on some previous traffic estimation. For example, if an onboard system
estimates that 60% of the traffic on a specific link will be real-time and that 40% regular, it can
allocate 70% of the bandwidth to real-time traffic and the rest to regular traffic. Doing so would
guarantee more bandwidth than is needed to real-time traffic (over provisioning).
Moreover, all the traffic belonging to a specific class of service can be prioritized according to
specific parameters. For example, all real-time packets can be assigned a “requested velocity”
parameter as the result of a calculation based on available real-time QoS parameters. Such
requested velocity is re-calculated at each router along the end-to-end path in order to dynamically
speed up packets with more stringent time constraints than others (see section 3.6.6).
2.2
QOS SPECIFICATION
QoS specification is different at each SOIS layer and determines the configuration of QoS
mechanisms for that particular layer. QoS parameters are used to describe the speed, reliability and
shape of a particular data flow, e.g., throughput, transit delay, error rate and flow control.
This section describes a set of QoS parameters that can be used in order to specify SOIS
Application level’s requirements in terms of both the desired and the minimum acceptable QoS
when establishing a connection-oriented communication.
These parameters will then be used during a negotiation between the source end system, the
destination end system and the TCONS stack, with convergence, where possible, on a QoS which
all can support. The agreed QoS will then be applied to all the packets sent over such a connection.
QoS specification encompasses requirements for:

performance - expected performance characteristics needed to establish resource
commitments,

synchronization - characterizes the degree of synchronization required between related
services, events, or information flows,

level of service - specifies the degree of resource commitment required to maintain
performance guarantees,

QoS management - the degree of QoS adaptation that can be tolerated and scaling actions
to be taken in the event the contracted QoS cannot be met.
2.3
QOS PARAMETERS
2.3.1
FAILURE CONSEQUENCE LEVEL (FCL)
FCL is a QoS parameter related to connection-oriented TCONS transport services; it is assigned by
the user at a per-connection basis and is used to determine priority of packets. This parameter
identifies 4 categories of consequences (for an application) of failing the data transfer (e.g.
dropped or deadline missed). The categories are:





Catastrophic
Hazardous-Severe
Major
Minor
No-effect
MORE APPLICATION QOS PARAMETERS? (TBD)
2.4
QOS ENFORCEMENT
2.4.1
SCHEDULING POLICY
A key component of real-time communication architectures is the packets scheduling policy which
determines the order in which incoming packets at a node are forwarded to an outgoing link.
In existing networks, packets are typically forwarded in FCFS (First Come First Served) order.
FCFS scheduling does not work well in real-time networks where packets have different end-toend deadlines constraints. Instead, competing packets should be prioritized based on their ‘local’
urgency.
In the context of real-time networks, packet scheduling should be deadline-aware. Deadline-aware
means that a packet’s priority should someway relate to its time constraint class (see section 1.2.1
above): The shorter the deadline, the higher the packet priority.
Determinism can also be affected by the “stochastic” nature of the inevitable scheduling “jitter”.
The major problem is that, ideally, the TCONS scheduler would need complete ‘anticipated’
knowledge about how long each data transfer is going to take in the near future and the exact
moment it will take place (i.e. pre-defined Isochronous time-slotted schedule tables). The
‘dynamic’ retrieval of such information is practically impossible, and even when it is available,
calculation of the optimal scheduling plan is a search problem with high complexity, and hence
high cost in time, which is inadmissible for real-time transmission.
Therefore, in order to devise the optimal scheduler algorithm able to satisfy all the abovementioned classes of time constraints, it is important to implement a packet’s Priority Allocation
Mechanism at the TCONS Network layer that accurately reflects the timeliness required by data
generated at the TCONS Transport layer. Within TCONS, this timelines-to-priority mapping is
performed through the use of pre-defined isochronous time-slotted schedule tables allocating, a
priori, a specific amount of ‘service’ to specific end-to-end connections at each node in the
network.
2.4.2
PRIORITY ALLOCATION
TCONS is a packet-switched network. Each real-time packet travelling the onboard network is
characterized by its required QoS, which is defined by a number of parameters that every node in
the network shall be able to access, manage and process.
In order to manage real-time network-level traffic flows in the most accurate and efficient manner
TCONS must ensure time-constrained end-to-end delivery of data by appropriately prioritizing the
transmission of contending packets based on their requested QoS.
2.4.2.1
Static Priority
The priority of a packet is fixed at each hop in the network; a fixed priority is initially computed
and assigned at the sender of each packet and it is not changed during the packet lifetime. This
computation is based on the following factors:

Urgency

Criticality

MORE TBD
2.4.2.2
Dynamic Priority
The network layer dynamically re-calculates the required priority of a packet upon its arrival at
each intermediate node; taking into account the following parameters:

Initial priority assigned by the sender (Pi)

MORE TBD
For each packet travelling the network, the requested priority (Pr) is set to:
Pr = TBD (1)
The required priority of a packet will be adjusted based on its actual progress along the end-to-end
path. A packet’s requested priority increases by re-applying equation (1) at intermediate nodes if
its last point-to-point progress towards the destination results slower than its previous progress
(e.g. due to a hot region). On the other hand, the requested priority decreases if it progress faster
than required. This is so this packet can give way to other more urgent packets.
Note that although clock synchronization simplifies its implementation, Dynamic Priority can be
implemented without clock synchronization. To do this, each packet contains a field as its elapsed
time counter. Each node increases the counter by the time the packet stays in it plus the
transmission and propagation time.
2.4.3
PRIORITY QUEUES
Along an end-to-end connection path, at every node on the TCONS network each packet is
assigned a priority based on its required QoS and, if there are other packets waiting to be served, it
is queued at the network layer according to its priority.
Several options are available for implementing priority queues. One approach is to insert all
packets into a single queue ordered by priority. When the queue us full, higher priority incoming
packets overwrite lower priority ones. The benefit of this solution is that it accurately reflects the
overall order of required QoS, and allows all packets to share the same buffer regardless of their
priority. This approach, however, requires implementing a data structure whose insertion time, in
the worst case, grows logarithmically in the number of packets stored.
In order to bind the queue insertion overhead, another approach is to maintain multiple FIFO
queues each corresponding to a fixed priority level. Each priority corresponds to a specific level of
QoS. A packet’s required QoS is first mapped to a priority level, and then inserted into the FIFO
queue that corresponds to that priority. This approach is more efficient because no ordering needs
to be performed for every incoming packet. The per-packet insertion time overhead is logarithmic
only in the number of priority levels used, not the number of stored packets.
2.4.3.1 Subnet-Dependent Convergence layer prioritization
Local prioritization at each individual node is not sufficient in the SOIS communication because
packets from different nodes can compete against each other for a shared data link communication
channel. To enforce packet priorities, MAC protocols should provide distributed prioritization on
packets from different nodes.
3
EXPECTED SERVICE CAPABILITIES (TO BE REVIEWED)
This section defines a generic pool of services and, for each one, the minimum set of capabilities
and features expected in case they must be provided by TCONS.
3.1
CONNECTION-ORIENTED SERVICE
A connection-oriented service is defined as one where one or both end-points keep state
information about the connection e.g. waiting for acknowledge at the sending end or missing
datagrams at the receive end. Keeping this state information about the connection binds the two
end-points together until the connection is terminated.
It provides a guaranteed service where the arrival of information sent to a destination is ensured,
with no parts of the information missing or in the wrong order.
A Guaranteed, Connection-Oriented Service is responsible for:

End-to-end connection

Connection flow control

Sending Data Units

Receiving Data Units

Order preservation

Error recovery and reporting

Connection QoS
3.2
CONNECTIONLESS SERVICE
A non-guaranteed, connectionless service delivers information on a best effort basis without
ensuring the arrival or order of arrival of the information.
It has no facilities for error detection or correction. It has only one phase, called data transfer.
Each invocation of a service primitive is independent of all other invocations, requiring all address
information to be completely contained within the service primitive.
A Non-Guaranteed, Connectionless Service is responsible for:

Sending Data Units

Receiving Data Units

Error statistics

Connectionless QoS
3.3
ASYNCHRONOUS SERVICE
In asynchronous service, there are no timing relationships between the transfer of service data units
supplied by the service user and the transmission of Transfer Frames generated by the service
provider. The user may request data transfer at any time it desires, but there may be restrictions
imposed by the provider on the data generation rate. In this service (figure 2-3), each service data
unit from a sending user is placed in a queue, the contents of which are sent to a receiving user in
the order in which they were presented. Although transmission errors may prevent delivery of
some data units, the service provider attempts to transfer all data units provided by the user exactly
once. The timing of data transfer is determined by the provider in accordance with mission-specific
rules, and may depend on the traffic at the time of transfer. The key feature of this service is that
all of the service data units from the sending user are transferred, and transferred only once.
Figure 2-3: Asynchronous Service Model
3.4
SYNCHRONOUS SERVICE
In synchronous service, the transfer of Service Data Units (SDUs) is synchronized with the release
of Network packets. The transfer timing may be periodic or aperiodic.
In this service, each SDU from a sending user is placed in a buffer that can hold only one service
data unit; the content of the buffer is sent to a receiving user at the time when a Transfer Frame is
transmitted. The transmission timing of Transfer Frames is determined by the service provider
according to mission-specific rules (usually known to the user). The key feature of this service,
which is essentially time-division multiplexing, is that the timing of data transfer is driven by the
transfer mechanism, not by individual service requests from the user. Thus a particular SDU from
a user might be sent once, several times (if the ‘new’ value is not placed in the buffer soon
enough), or not at all (if one value is replaced by a second before the service provider can send it).
Figure 2-4: Synchronous Service Model
3.4.1
PERIODIC SERVICE
Periodic service is a special case of synchronous service in which service data units are transferred
at a constant rate. Periodic transfer from service interface to service interface is provided with a
specified maximum delay and a specified maximum jitter at the service interface.
For periodic services, all service data units are sent only once if the user supplies service data units
at the same rate as the rate at which the service provider transfers them.
3.5
ISOCHRONOUS SERVICE
The word Isochronous comes from the Greek words ISO = same and Cronos = time, thus it
literally means ‘same time’.
In an Isochronous service, the transfer of Service Data Units (SDUs) by a user is synchronized
with the reception of SDU at the other end-point of the connection. The transfer timing may be
periodic or aperiodic.
4
IMPLEMENTATION CONSIDERATIONS
4.1 GENERAL
In the context of a specific mission, many considerations can affect the way that TCONS services
will be requested and solicited. For example:
a) Mission analysis;
b) System requirements
management…);
(reliable/unreliable
transfers,
autonomy,
transfer
initiative
c) Spacecraft orbit and visibility (Low Earth Orbit [LEO], Geosynchronous Earth Orbit
[GEO], Geosynchronous Transfer Orbit [GTO], Deep Space, …);
d) Onboard data handling capabilities;
e) Operational requirements (pass management, ground station availability, …);
f) . . . .
Such considerations may lead to the selection of specific classes or subsets of the TCONS (e.g.,
reliable or unreliable modes of data transmission).
(TO BE CONTINUED…)