Joint use of LTP and Erasure FEC for space environments (ECLSA 2.0) Nicola Alessi, Carlo Caini, *Tomaso de Cola University of Bologna, *DLR Oberpfaffenhofen-Wessling
Outline Introduction to ECLSA ECLSA origin Erasure packet coding principles ECLSA in a nutshell ECLSA protocol stack in ION ECLSA 2.0 Rationale Threads New features Performance Joint use with LTP (red and green) Performance of LTP_red+ECLSA: bundle delivery time Performance of LTP_green+ECLSA: successful decoding prob. 2
ECLSA development Implementation of Erasure Codes as LTP sublayer in ION, CCSDS 2013 (Bordeaux) By P. Apollonio, C. Caini, T. de Cola, G. Liva, B. Matuz, ECLSA 1.0 (Erasure Coding Link Service Adapter) core implemented by Pietrofrancesco Apollonio (Unibo) at DLR premises (Summer 2013) One FEC code only Refinements until spring 2014 CCSDS 131.5-O-1 Erasure Correcting Codes for use in Near Earth and Deep Space Communications Orange book, Nov.2014 ECLSA 1.1 winter 2014 support of 9 Orange Book codes An attempt of building a 1.2 version aborted in 2015 ECLSA 2.0, Summer 2016 Completely rewritten from scratch by Nicola Alessi 3
Erasure packet coding principles The usual FEC concepts are applied to packets instead of bits (N,K) code K Info packets (e.g. LTP segments) M=N-K parity packets (redundancy) R=K/N code rate Ideally, the FEC should recover all the K info packets if at least K (over N) packets are received, i.e. if #lost_packets<m The larger the redundancy the better the FEC performance vs. the packet error rate the larger the waste of bandwidth in the absence of losses Lower layers Lower layers 4
ECLSA codecs in a nutshell Erasure Coding Link Service Adpater LDPC codes at present one of the following, but any other can be easily added K=512, 2048, 16384 R=8/9, 4/5, 2/3 Optional dynamic selection (feedback based) in v. 2.0 Decoder (by DLR) Automatic switch between Iterative decoder (faster) ML decoder (better performance) 5
ECLSA protocol stack in ION ECLSA is in between LTP and UDP eclso, eclsi instead of udplso, udplsi Both green and red parts supported Although ECLSA may seem transparent to LTP, LTP RTO timers for red parts must take into account the extra delay due to the use of FEC. This extra delay is directly proportional to K Trade off between FEC performance and delay 6
ECLSA 2.0 Rationale and improvements The 1.x version did not support the dynamic selection of the code It was also hard to further extend and maintain Original code built for a static selection of FEC code Poor layering due to optimizations Code redundancy (due to options ) The lessons learned the hard way allowed us to redefine specifications and code structure Dynamic selection of the FEC code from the beginning Better layering No more options One task, one thread approach 7
ECLSA 2.0 thread structure All threads are independent and can work in parallel, exploiting a buffer of code matrixes ECLSO threads T1 writes K LTP segments into one code matrix T2 encodes the matrix (adds m redundancy segments) T3 passes the N=K+M segments to UDP ECLSI threads are the converse ones T1 writes the payload of UDP packets in a code matrix T2 decodes the matrix T3 passes the K decoded segments to LTP 8
ECLSA 2.0 summary of new features Dynamic selection of the code The default code can be changed automatically (both K and R, only K, only R) Feedback from eclsi on the receiver side The amount of redundancy is automatically increased or reduced, to match the PER. Processing time largely reduced Coding and decoding timeouts redesigned Enhanced parallelism between threads Preferential use of small matrixes. The receiver (eclsi) can support multiple senders (eclso) Enhanced compatibility with upper and lower protocols different from LTP and UDP. New logs All ECLSA code is now self-contained (no modifications in ION) 9
LTP & ECLSA LTP red + ECLSA Reliable (thanks to outer LTP ARQ) & lower delivery time (thanks to FEC) LTP retransmission mechanisms (unaltered) on which ECLSA is nested, provides full reliability However, ECLSA makes LTP segment losses extremely rare, reducing retransmission cycles and thus the delivery time. The longer the RTT, the larger the advantage vs. LTP only LTP green + ECLSA Almost reliable ECLSA makes LTP segment losses extremely rare. Almost all LTP blocks should arrive. However, in the rare event of a decoding failure LTP blocks contained in a code matrix can be lost. The situation could be saved at BP layer, thanks to the custody option (two consecutive failures on independent matrixes should have a negligible probability). 10
Performance of LTP red+eclsa: bundle delivery time (RTT=2s) Delivery time (half RTT) 12 10 8 6 4 K=512, Bundle=500kB, Tx rate=10mbit/s, Losses on the forward channel only, RTT=2s (Earth-Moon) LTP enhanced Burst 3 LTP&ECLSA N=576 R=8/9 LTP&ECLSA N=640 R=4/5 LTP&ECLSA N=768 R=2/3 2 0 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 PER (%) 11
Performance of LTP_red+ECLSA: bundle delivery time (RTT>>2s) Delivery time (half RTT) 12 10 8 6 4 K=512, Bundle=500kB, Tx rate=10mbit/s, Losses on the forward channel only, RTT>>2s (e.g. Earth-Mars) LTP enhanced Burst 3 LTP&ECLSA (no processing delays) N=576 R=8/9 LTP&ECLSA (no processing delays) N=640 R=4/5 LTP&ECLSA (no processing delays) N=768 R=2/3 2 0 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 PER (%) 12
Performance of LTP_green+ECLSA: successful decoding prob. (analytical) Bundle/LTP block delivery time (bundle inside one matrix): always equal to ½ RTT + ECLSA processing time LTP block delivery probability strongly dependent on its size without ECLSA close to the matrix decoding probability for medium LTP blocks (iid losses). 100 Decoding probability % 80 60 40 20 N=576 R=8/9 N=640 R=4/5 N=768 R=2/3 N=2304 R=8/9 N=2560 R=4/5 N=3072 R=2/3 N=18432 R=8/9 N=20480 R=4/5 N=24576 R=2/3 0 0% 5% 10% 15% 20% 25% 30% 35% 40% PER % 13
Conclusions LTP+ECLSA advantages (if redundancy > losses) Reduced delivery time The higher the RTT and/or the PER, the higher the advantage Constant delivery time Disadvantages The FEC is proactive: the bandwidth reduction is not justified when the channel is ideal. 14