Aerospace and Electronic Systems Magazine April 2017 - 50

Integration of Reed-Solomon Codes to Licklider Transmission Protocol (LTP) for Space DTN
derlying LTP-based protocol stack. As stated, LTP is designed to
achieve reliable transmission of data bundles by means of retransmission-based recovery of lost data. It is stateful but unlike TCP, it
has no negotiation or handshakes. For a side-by-side, tabular-form
comparison of the design and operational differences between the
standard TCP/IP and LTP running underneath BP, refer to [20].
As discussed in [21], when LTP works with BP to accomplish
data transfer, BP passes its data bundles to LTP for transmission;
LTP encapsulates them in client data "blocks". According to mission requirements and transmission capability, LTP can provide
either reliable transmission or unreliable transmission, or some of
each, for each data block [18]. Therefore, each block of data is recognized by LTP as having two parts: a "red-part", whose delivery
must be assured by acknowledgment and retransmission, followed
by a "green-part", whose delivery is attempted, but not assured.
The length of either part may be zero.
LTP data transmission is organized in "sessions", each of which
is the sequence of LTP segment exchanges - transmission efforts
- undertaken to effect the successful transmission of a single data
block. Like BP, LTP itself does not transmit data directly but rather
utilizes underlying protocols at what is termed the "local data-link
layer"; to this end, LTP invokes the services of an interface called
a "link service adapter" (LSA), which in turn operates the underlying link protocol.
From the perspective of data fragmentation, each LTP data
block is fragmented into multiple "data segments (DSs)" according to the LSA's maximum transmission unit (MTU) size; the
segments are then encapsulated in the protocol data units (typically termed "packets" or "frames") of the local data-link layer
protocol and transmitted over physical media. The last segment
of each block, designated as a checkpoint (CP), flags the end of
the block.

As part of the interactive processes between the sender and the
receiver, a CP segment of a LTP block is sent to prompt the receiver to check the reception status of an entire data block. When a CP
is received, the receiver returns a report segment (RS) indicating
cumulative reception status for the block. The RS acknowledges a
CP and it either signals successful aggregate reception of the entire
data block or else triggers retransmission of the segments of the
block that have not yet been received. Both RSs and CPs are on
timers; they are retransmitted if not acknowledged. An RS is acknowledged by a report acknowledgment (RA) from the sender. In
[20, Figure 1], the process of LTP block transmission is illustrated
based on interactive transmissions of segments, CP, RS and RA
between a sender and a receiver. For a detailed description of LTP
data transmission, refer to [18, 20].

OVERVIEW OF RS-LTP-AN INTEGRATION OF RS
ERASURE CODING TO LTP

As stated earlier in this article, RS-LTP is proposed as a new "local data-link layer" protocol of space DTN to provide RS coding
service for LTP. RS-LTP exercises RS coding to minimize the impact of LTP data segment loss or corruption over a lossy space
channel. Following the RS encoding procedure, the stochastic
encoding of the DSs at the RS-LTP sender generates redundancy
packets termed "encoding segments (ESs)"; both DSs and ESs are
encapsulated in RS-LTP packets for transmission. Once a sufficient number of distinct RS-LTP packets have been received by the
RS-LTP receiver, the lost or corrupted DSs can be restored without
retransmission by simply decoding the received ESs.
Figures 1 and 2 provide flow diagrams of RS-LTP data block
transmission processes with a focus on the proposed RS encoding/
decoding processes to LTP and data unit encapsulations and decapsulations. For the RS encoding process
at the sender illustrated in Figure 1,
each LTP block is divided into multiple
chunks according to the MTU size specified for transmission by RS-LTP. An
LTP segment header is then prepended
to each chunk, encapsulating each chunk
in an LTP DS. For this illustration we
assume that the green-part length of the
block is zero, so the last DS's End of Red
Part (EORP) flag is set, indicated that the
DS serves as a CP.
The DSs are passed to RS-LTP for
encoding per the RS encoding procedure
and the specified code rate; all the DSs
of the block except the last one (i.e., CP)
are passed to the encoding procedure in
order to generate the ESs. An RS-LTP
packet header is then prepended to each
DS and each ES, encapsulating each
segment in an RS-LTP packet. The RSLTP packet header contains all relevant
encoding information, including the
Figure 1.
Flow diagram of RS-LTP data block transmission process and its RS encoding implementation at sender.
number of DSs in the block, the code
50

IEEE A&E SYSTEMS MAGAZINE

APRIL 2017

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