Aerospace and Electronic Systems Magazine April 2017 - 51

Shi et al.
rate (i.e., the ratio of total numbers of ESs and DSs), and the index
of this packet within the block. All RS-LTP packets are then transmitted. The CP segment (the last DS) is not involved in encoding;
the RS-LTP packet containing that segment is the last one sent.
For the RS decoding process at the receiver, the arrival of an RSLTP packet containing a CP segment prompts the RS-LTP receiver
to decode and check the preceding received packets. As illustrated in
Figure 2, the RS-LTP receiver uses the coding information in the RSLTP packet header to decode all the ESs, following the RS decoding
procedure. This normally enables it to restore all corrupted or lost DSs.
All DSs acquired by reception or decoding are passed up to LTP
for standard segment processing. If all lost DSs have been restored
and thus all the original DSs of the block have been successfully received, the receiver returns an RS segment to the sender as a positive
acknowledgment. If any lost DSs can't be successfully restored, the
RS serves as a negative acknowledgment triggering retransmission
of those data segments, in the usual manner. The retransmitted DSs
are encoded to generate new ESs, and all the DSs and new ESs are
sent; the last retransmitted DS again is flagged as a CP. This process
repeats until all the DSs in the LTP block have been successfully
received by the receiving LTP engine. Source data chunks are extracted from the data segments and used to reconstruct the original
LTP data block that then construct the application data bundles.

EXPERIMENTAL SETUP AND CONFIGURATIONS

sion, in order to evaluate the performance improvement of RS-LTP
versus LTP-UDP. The experiments were conducted by transferring
a range of bundle sizes-4 Kbytes, 8 Kbytes, 16 Kbytes, and 32
Kbytes to evaluate the impact of RS coding on LTP with respect to
variation of data block. The LTP data segment size was configured
to be 1400 bytes. With respect to the RS coding configurations,
the encoding/decoding delay is 0.3 ms/Kbytes. A widely used code
rate of 1/2 was set for RS-LTP. Sixteen test runs were performed in
each experimental configuration.
To emulate different levels of data losses caused by channel
error over space communication links, three channel bit-error rates
(BERs)-10−6, 10−5 and 10−4-were chosen to introduce moderate,
high and very high channel error rates. These BERs are historically
typical of the range of loss levels encountered in space communications. These error rates are also within the minimum communication specifications of NASA's space networks [25].
A propagation delay of 1.35 sec was introduced to emulate a oneway space link delay for each of the data return and ACK forward
channels. This length of propagation delay is typical of the Moon
space missions. Considering that satellite/space communications feature asymmetric channel rates, the effect of channel-rate asymmetry
was also taken into consideration in the data transfer experimental
evaluation. A channel ratio of 100/1 was set in the experiments, with
a forward data rate of 1 Mbits/s and an ACK data rate of 10 Kbits/s.

EXPERIMENTAL RESULTS AND ANALYSIS

A PC-based space communication and networking testbed (SCNT)
was built to emulate a space communications infrastructure for the
In this section, we present an experimental performance evaluation
proposed performance evaluation of LTP with RS-LTP at the "loof the proposed RS-LTP based on data transfer experiments. The
cal data-link layer" versus LTP running over simple, non-encoded
UDP (here termed "LTP-UDP"). Please
refer to [22, Figure 1] for a block diagram of the SCNT. Realistic data transfer experiments were conducted by running these two protocol options over
the emulated SCNT communications
infrastructure. Previous research [2023] shows that the experimental results
obtained from the SCNT are generally
considered valid and the testbed can effectively evaluate the performance of a
protocol over satellite and space channels.
For the proposed data transfer performance evaluation of LTP-UDP and
RS-LTP, their complete protocol stacks
are configured as BP/LTP/UDP/IP/Ethernet and BP/LTP/RS-LTP/UDP/IP/
Ethernet, respectively. The BP and LTP
protocol implementations were provided
by the Interplanetary Overlay Network
(ION) distribution v3.3.1 [24] developed
by the Jet Propulsion Laboratory (JPL).
The LTP source data blocks transmitted in all experiments were declared Figure 2.
Flow diagram of RS decoding implementation to RS-LTP and block reconstruction process at receiver.
to be 100% "red" for reliable transmisAPRIL 2017

IEEE A&E SYSTEMS MAGAZINE

Table of Contents for the Digital Edition of Aerospace and Electronic Systems Magazine April 2017