Rateless Codes for File Transfer over DVB-S

Francesco Zampognaro*
Electronics Engineering Department, University of Rome Tor Vergata Via del Politecnico 1, 00133 Rome Italy zampognaro@ing.uniroma2.it typically required. This redundancy can make use of up to 50% or more of the total gross bandwidth. Nevertheless, an efficient exploitation of the bandwidth is very important because it allows to provide more services and to save money. In fact, satellite bandwidth is very expensive and must be wisely used. In order to address the problems related to reliable communication and efficient bandwidth exploitation, we present an approach based on this new class of FEC codes, called rateless. Using these codes we can increase the bulk data transfer performance over DVB-S. The reference transport protocol usually employed for reliable data transfer is the Transport Control Protocol (TCP) [19], which foresees specific periodic acknowledgement packets (ACKs). In this paper we propose to share out the FEC redundancy among the DVB-S channel and the application layers and to adopt UDP instead of TCP for bulk data transfer. A lower redundancy at the channel layer will provide a minimal error protection, resulting into a higher Bit Error Rate (BER) than the one required for QEF conditions (in which TCP usually works). However, using rateless coding as additional FEC technique at application layer and UDP as transport protocol, we can tune the optimal amount of redundancy to have a reliable transmission and outperform the TCP data transfer performance. The proposed approach can be integrated in the DVB-S system without changing any other component of the satellite network than the FEC configuration in the satellite HUB. The effectiveness of the proposed approach and the tradeoffs will be studied using analytical models and NS2 simulations [12], a wide recognized and mature simulation tool. Moreover, a Linux-based testbed will be used, including an emulator of satellite propagation characteristics, to verify the real-time transfer of data using both TCP and rateless UDP (rUDP) transfer. The rest of the paper is organized as follows: Section II, gives an overview on rateless codes; Section III presents the characteristics of the considered scenario; Section IV details the use of the simulation and emulation environment. Performance analyses of the proposed approach are exhibited and discussed in Section V. In Section VI conclusions are drawn. Finally, in Section VII some ideas for future works are exposed.

Pasquale Cataldi, Mario Gerla

Computer Science Department University of California Los Angeles - UCLA 3732F Boelter Hall, Los Angeles, CA 90095 pasquale.cataldi@gmail.com, gerla@cs.ucla.edu
Abstract Data distribution over satellite is becoming more and more important due to the need of convergence of several services over IP (e.g. Triple Play) where the classic DSL is not available. There are in fact examples, especially in rural communities, of successful satellite based wireless services to offer IP communication and broadband Internet connection to several users. The purpose of this paper is to introduce a novel system for point to point bulk data delivery (e.g. video on demand) using IP over DVB-S and rateless coding of the source data to achieve better performance in terms of data transfer time and especially bit-efficiency. This mechanism will be compared to standard reliable TCP data transfer, and advantages and trade-offs will be illustrated. The discussion is aided by theoretical analysis, NS2 simulations and tests performed over a Linux testbed with real-time traffic. Keywords: DVB-S, TCP/IP, Fountain coding.

I.

INTRODUCTION

Rateless codes are codes developed for erasure channels. Using these codes the transmitter can produce a potentially infinite amount of encoded packets and the receiver is able to decode the original data as soon as enough packets are received. This yields to an optimal exploitation of the bandwidth, since these codes are asymptotically optimal for every channel condition [1]. Rateless codes have been used in a number of applications, e.g. parallel asynchronous downloading from the Internet, data dissemination over wireless sensor networks, vehicular networks and P2P streaming. In [2] the authors cite also satellite communication as possible application. In this paper we propose to use a rateless coding of data for file transfer over a DVB-S system. DVB-S standard [3] is commonly used by millions of satellite terminals, mainly to receive digital television broadcast. Nevertheless, it is also possible to have interactive services utilizing DVB-S on forward link and adopting different technologies to establish a return channel. For this purpose there are several possibilities, such as analogue modem using a PSTN line, ISDN, broadband [4][5] or narrowband [6] return channel over satellite. DVB-S is assumed to operate in Quasi Error Free (QEF) conditions, i.e. with a Bit Error Rate (BER) of 10-11 to 10-10. Due to the extremely challenging propagation characteristic of the satellite channel, a strong forward error correction is
*

Authors are listed in alphabetical order

II.

RATELESS CODES

Rateless codes are random sparse-graph codes developed for erasure channels. Using these codes the source data can be recovered from any subset of encoded packets, given that enough packets are received. A rateless encoder can be thought of as a fountain that produces an endless supply of water drops. The water drops are encoded symbols (ESs). Similarly, a rateless decoder can be thought of as a bucket that collects water drops until it reaches capacity. With rateless codes the number of symbols that can be generated from the source data is potentially infinite and every symbol can be generated on-the-fly, making in fact not possible to determine the rate in advance. Thus, these codes are called rateless. The generation of an ES is based on exoring a certain number of source symbols chosen uniformly at random. The number of source symbols that are chosen is given by a distribution that depends on the particular code. Examples of such distributions can be found in [1][13]. The number of different symbols to be collected from the receiver in order to recover the source info is (1 + ) k, where k is the number of source symbols and is called decoding inefficiency (typically << 1). However, the impact of this inefficiency on the overall performance of the system is the lower, the worse the channel conditions are. It can be demonstrated that for k that tends to infinity, these codes have decoding inefficiency approaching zero. Thus they are potentially optimal [1] for erasure channels. Another important property of rateless codes is that they are universal for each erasure channel. This means that these codes can operate arbitrarily close to capacity for any erasure channel. In other words, this means that, apart from the decoding inefficiency (potentially zero, for large blocks), it is possible to recover the source information as soon as enough ESs are received. In this way the delay needed to receive all the symbols is minimal. Finally, the last interesting property is that the symbol length for the codes can be arbitrary. In fact, a symbol can extend from one-bit to a generic bit string, without affecting the coding and decoding complexities. Rateless codes are particularly suited for data transmission over computer networks. After the encoding process, the symbols are grouped in packets to be sent on the transmission channel. In order to recover the source information, the decoder needs to know which source symbols concurred to generate every ESs (neighbors list). This additional information might be explicitly transmitted. However, transmitting the neighbors list would be a drastic waste of bandwidth. A more efficient method can be adopted by discerning the sequence number of the ES and the characteristics of the random generator that has been used. In fact, assuming that the same random generator is used at both sides of the communication channel, the decoder only needs to know the random seed chosen by the encoder, and the method adopted to associate the generated random numbers to the ESs. The first rateless codes were proposed by Luby and are called LT codes. These codes are a really close approximation of the fountain idea and take on average

O(ln(k/)) symbol ex-or operations to generate a coded symbol, and O(kln(k/)) symbol hex-or operations to recover the k original symbols with probability (1-). In the following years many other implementations of rateless codes have been presented, such as [13][15]. In particular, due to their excellent performance, a systematic version of rateless codes, namely Raptor codes, have been recently adopted in two major standards, such as DVB-H and 3GPP MBMS. In this paper we adopt LT codes among all the different implementations that have been proposed in these years because they are the best approximation of a digital fountain. However, in order to achieve good performance in terms of overhead, we used the encoding scheme called SlidingWindow (SW) that has been presented in [14]. According to this scheme, the encoding block is virtually enlarged by overlapping subsequent encoding windows. As a consequence, the performance in terms of Undecoded Symbol Rate (i.e. the ratio of source symbols that might not be decoded after the decoding process as a function of the number of encoded symbols that have been received) is comparable to the one that can be obtained by using a larger block, but at a reduced complexity. Another advantage of using the SW approach over the traditional one, is that, by introducing correlation among the encoded symbols of different encoding windows, the transmitted data can tolerate burst losses concentrated in one transmitting window. III. REFERENCE SCENARIO The considered scenario refers to point to point large-file data transfers over a DVB-S satellite architecture, as depicted in Fig. 1. Data files are transferred using IP connectivity encapsulated into the transport layer of DVB-S, from the Gateway side to the satellite terminals (RCSTs). DVB-S standard defines the layered architecture up to layer 2 for communications over geostationary satellites. The propagation delay is assumed to be D=250ms, calculated with good approximation for a geostationary satellite on an orbit of 36.000 km.

Figure 1. DVB-S scenario

For point to point reliable data transfer, a return channel is needed, either terrestrial or satellite. If TCP is used as reliable transport protocol, periodical ACK packets must be returned back to slide the transmission window and keep the bytes flow. We considered the system to be equipped with a version of TCP that implements a delayed ACK [7], which leads to a reduction factor of 2 in the number of ACKs sent by the receiver. The maximum reachable goodput on the forward link is about 2 Mbit/s, due to the ratio of TCP typical packet size at MAC layer for data (1500 bytes) versus ACKs (80 bytes), considering their frequency and assuming a return link of 56 kbit/s,. In the following sections we will use these values as reference, compatible with a satellite based system. The actual gross capacity (in terms of effective bitrate modulated on the physical channel) includes also the overhead of MPE encapsulation and MPEG-TS framing at layer 2. In addition, coding is applied to the physical transmission in order to reach the system target BER. All these aspects are analyzed in the following subsections. However, details on physical bandwidth occupation for the transmission and modulation issues are not covered in the present work since they do not affect the results. A. DVB-S overhead In traditional DVB-S systems, strong channel coding is applied to the transmission in order to achieve the QEF condition. The DVB-S standard [3] suggests several techniques, i.e., Turbo coding. However, the most adopted solution, and the one considered herein, consists in the use of a two level coding with interleaving. The outer coding is composed of a Reed-Solomon (204,188,8) giving protection on the bytes. Then, an interleaving process is performed with a depth of 12 bytes, aimed to protect the transmission against burst of errors. After the interleaving process, an inner coding is performed by using a convolutional code, whose rate can be selected among the rates r = {1/2, 2/3, 3/4, 5/6, 7/8}. At the decoding side, the received bits are first processed by a Viterbi decoder. Thus, after the deinterleaving, another decoding process is performed such that up to 8 bytes can be corrected in a 204 byte packet with the Reed-Solomon decoder. Reed-Solomon has an efficiency of 0.9215 while for the inner coding the efficiency is variable according to the rate r (ranging from 0.5 to 8.75). The combination of all these techniques leads to performance in terms of Eb/N0 versus BER, as shown in [11]. In the rest of the paper we will refer to the graphs presented by Foerester and Liebetreu in order to define the performance of the channel coding. B. IP over DVB DVB-S system has been conceived and designed mainly to carry MPEG2 TV programs, and defines the MPEG-TS Transport Stream (MPEG2-TS) as the framing structure at layer 2. MPEG-TS has a fixed packet size of 188 bytes, of which 4 are dedicated to the header. The fixed packet structure is derived by the realtime requirement of MPEG2 Program Elementary Streams (PES) usually broadcasted

over DVB-S. The efficiency of the MPEG-TS encapsulation is (184/188)= 0.9787 (about 2.2% overhead cost). Sending IP packets over DVB requires a dedicated encapsulation protocol to allow addressing of nodes over a broadcast channel and support variable-sized packets. In DVB-S two protocols are available, i.e Multi-Protocol Encapsulation (MPE) [8] and Ultra Lightweight Encapsulation (ULE) [9]. An exhaustive performance comparison in terms of efficiency among different encapsulation methods is presented in [10]. In the paper it is shown that the latter is more efficient however, in the rest of this paper, we will consider MPE encapsulation because it is the most used method for encapsulation. MPE uses a header of 12 bytes plus a checksum field of 4 bytes for each IP packet transmitted. The introduction of MPE encapsulation delivers an additional variable efficiency of PS/(PS+16), where Ps represents the IP packet size (including header) in bytes. For PS equal to 1500 bytes, this value is about 0.9895 (overhead 1%). Padding overhead will not be considered in the rest of the paper. In Table 1 we present a summary of the efficiencies of TCP/IP communication over a classic DVB-S system.
TABLE I. EFFICIENCY SUMMARY OF THE DVB-S PROTOCOL STACK

Layer TCP/IP MPE enc. MPEG-TS DVB-S FEC DVB-S RS IV.

Efficiency (Ps -40) /Ps Ps /(Ps+16) 184/188 Variable 188/204

Value (PS=1500) 0.9733 0.9895 Fixed: 0.9787 0.5 to 0.875 Fixed: 0.9215

SIMULATION AND TESTBED SETUP

A. Rateless UDP (rUDP) and TCP Rateless coding will be used to encode UDP packets and transfer data files over an interactive DVB-S channel. This approach will be compared with a standard TCP transfer. The performance is evaluated according to two different metrics. The first one is the transmission efficiency , representing the ratio of transferred bytes with respect to the original file size. The second one is the time TXtime necessary to complete the transmission (including the time the sender needs to receive the acknowledgement of complete transfer for rUDP or the FIN packet for TCP). For rUDP transfer, simple equations for and TXtime can be derived. If we suppose to transfer a file composed of k source packets over a channel with transmission bandwidth B and propagation delay of D, with average packet erasure rate p, then, assuming the inefficiency of the rateless decoding, the following equations are valid:

(1 p ) (1 + ) k (1 + ) +D TX time = B (1 p )

(1) (2)

For what concerns equations for performances of TCP transfer, most of the TCP models either can not be used to obtain the values of interest [18], or they are too simplified [17] to be fairly and directly compared to (1) and (2). Therefore, for the evaluation of the efficiency and the transfer time of TCP, we decided to simulate its behaviour on NS2, as described below. B. NS2 setup rUDP and TCP based data transfer has been performed over the NS2 simulation platform. The filesize downloaded by the satellite terminal has been set to F=4 MB. The satellite terminal is connected by a DVB-S satellite link with a bandwidth of 2 Mbit/s with a certain BER value, assumed uniformly distributed during the relatively long connection. For each BER value, several simulations are performed to measure the average performance of several TCP and rUDP flows. For this analysis we adopted TCP Reno with a window size large enough to handle a large bandwidth delay product [19], to offer a fair comparison against rUDP. rUDP performances in NS2 are exactly matching equation (1) and (2), since the rUDP application in NS2 has been setup using a theoretical model for rateless coding. C. Linux testbed setup The same file transfer of size F has also been performed using a Linux based testbed. In particular, the testbed is composed of three PCs connected in series with Ethernet cables. The first PC is the server, i.e. the sender side where the file to transfer is available. The PC in the middle performs routing between two network subnets, performing the satellite emulation functions. It is in charge of delaying the packets of D=250ms (geostationary satellite physical delay) and controlling the rate. In addition, it also randomly drops packets in order to emulate a satellite link affected by a certain packet loss rate, thus resembling the satellite channel propagation model as in [20]. Finally, the third node is the receiver of the file, i.e. the client. A client/server application has been specifically designed in ANSI C for the UDP data transmission of files of different sizes using rateless coding. Data packets contain encoded symbols obtained by a LT encoding of the source data. In these simulations we assume that sender and receiver are synchronized, so that the decoder knows how every received packet was generated. TCP used is the default for Linux, with transmission windows correctly set. D. Preliminary Results The first simulations and emulations have been performed to validate equation (1), (2) and the results obtained with NS2 simulations against the outputs coming from the Linux testbed for satellite emulation. In this way, all the simulated results can be assumed realistic and close to a real scenario, validating the emulation platform too. In Fig. 2 we show the comparison between the rUDP efficiency measured with NS2 and the one of a real transmission. For the NS2 model we assumed an inefficiency of 5.3% that approximates the average behaviour of a SW LT code with SW parameters (k, w, s) = (40000, 10000,

5000) [1]. We adopted a Robust Soliton Distribution [2] with parameters (c, d) = (0.01, 0.999) and we grouped three symbols of 480 bytes per each UDP packet. We performed the transfer using different BERs. These values are also used for the real transmission performed on the Linux testbed. The curves are normalized with a maximum efficiency of 1 and as function of BER. As we can observe, the real performance of the adopted SW LT code is almost coincident to the simulation results, thus confirming the mathematical formulas presented in equation (1). For what concerns the TCP performance, it has been obtained with NS2 and then with the emulator platform too. The efficiency of TCP transfer is very close to the ideal transmission case in Fig. 2, because the selective retransmission of packets permits to only send again lost packets. Additionally, we show in Fig. 3 the TCP transfer time graph obtained with NS2 and the Linux testbed (using confidence intervals referred to several connections).

Figure 2. Bandwidth efficiency of rateless codes as a function of BER. Comparison among the ideal case (no decoding inefficiency), analytical and real performance.

Figure 3. Transfer time of TCP Reno as a function of BER. Comparison between the behavior simulated in NS2 and the one obtained by using a Linux testbed.

V.

PROPOSED APPROACH

The proposed approach for efficient rUDP data transfer aims to reduce the FEC used at lower layers in order to compensate for its decoding overhead (e.g., 5% for LT code shown in Fig. 2). As first but representative study case, the use of two FEC commonly applied for convolutional coding of 1/2 and 2/3 will be considered. Specifically when FEC is 1/2, QEF conditions, using the curves reported in [11], delivers an Eb/N0 at the receiver of 3.7 dB. Only with these conditions TCP will transfer data files efficiently. In particular, we measured that the TCP transfer time increases greatly with BER (Fig. 3), because it is very slow to recover several losses in an environment with high RTT, as in DVBS. Lowering the FEC to 2/3 while considering the same Eb/N0 means to have greater packet losses. Using [11] the BER resulting in fact is about 310-6. With these conditions TCP will not perform optimally, but rUDP can be used successfully as we will present. A. Results Taking into account the efficiency of the DVB-S channel at all layers, the overall channel efficiency is 0.43 for ideal transmission with a FEC of 1/2 and 0.57 if the FEC is 2/3. Working with a FEC of 2/3 rUDP is comparable and even better than TCP because the overhead introduced by the rateless coding is compensated by the gain of the FEC reduction at the channel layer. In Fig. 4 the two cases for transmission using TCP with a FEC of 1/2 and rUDP with a FEC of 2/3 are shown in terms of transmission efficiency for several file data sizes of 4800, 9600 and 19200 MB. Each of the two cases takes into account the respective channel efficiency, in a common scale where 1 indicates the gross channel capacity. It is possible to see an effective transfer gain: at QEF conditions the channel usage is 43% with TCP, while at 310-6. rUDP shows a channel usage in the range of 50-53%. These numbers show a clear increase in channel efficiency, which is a great advantage in a satellite environment.

In Fig. 5 we present the comparison between the transmission times of the two approaches. We will not consider the data transfer time reduction as a key improvement (even if for some services, as in case of emergency, this parameter could also be of interest). However, it is possible to notice how rUDP transfer times are always lower than TCP ones for the same file size.

Figure 5. Comparison between TCP Reno and rUDP. Transfer time (in seconds) as a function of the BER on the channel.

B. Remarks It should be noted that rUDP has still margin to perform better in terms of channel efficiency gain for at least two reasons. In fact, when the channel is good (e.g., no rain), the BER can be lower, so the efficiency can increase of some percent points further. In other words, rUDP performs a sort of adaptive coding at application layer, without any kind of lower layer adaptations. Secondly, more efficient rateless codes (e.g. Raptor codes, presented in [13] and[16]) can be used, further improving the proposed approach. The use of rateless coding for data transmission is believed to be applicable also to the newer DVB-S2 standard [21]. DVB-S2 is able to perform adaptive coding and modulation at lower layers using a dedicated return channel (used by terminals to notify channel conditions) at the cost of additional system complexity to handle the resource management process, in order to deliver effective benefits to most of the terminals [22]. In this context, rUDP can offer a real advantage with its higher layer coding which, in practice, delivers to each terminal (with its own BER condition) an amount of packets accordingly, without the need of adjusting the source coding case by case. VI. CONCLUSION From the simulations and the tests performed we showed how rateless coding for data transfer over satellite is a feasible approach, leading to performance improvement. TCP is able to reach optimal efficiency with the proper FEC, operating in QEF conditions. Rateless coding on the other hand can work with lower FEC, thus increasing the

Figure 4. Comparison between TCP Reno and rUDP. Bandwidth efficiency as a function of the BER on the channel.

available channel capacity at the cost of working below QEF conditions. In this situation, the use of rUDP resulted in an increment of the overall channel efficiency of 7-10%. A secondary performance parameter, the data transfer time, is always lesser when rUDP is adopted. VII. FUTURE WORK The use of Performace Enhanching Proxy (PEP) [23], such as the I-PEP [24], has not been addressed yet at this stage of the work. Additionally, UDP based communication solutions which can be used in PEP connections (also commercial ones like XTP [25]) are difficult to model. Both these aspects will be subject of future work. Rateless codes can also be used for parallel data transfers, obtaining a fair share of the resources. They are assumed also to be very convenient for data multicast, since there is no need for individual retransmissions [26]. Future work will investigate these aspects and will open the way for further study related to multicast and broadcast of multiple data flows using rateless coding versus fixed and adaptive FEC of DVB-S/S2 or LMS systems [27]. Future work can also include better tuning of the rateless coding used in the Linux-based testbed, with the creation of an application to transfer files similar to FTP, using TCP for the session and rUDP for the data transfer. ACKNOWLEDGMENTS The authors thank Prof. M. Luglio for his support on the research activities and the coordination of the exchange program performed between UCLA and University of Rome Tor Vergata. REFERENCES
[1] M. Luby, LT codes, Proceedings of the 43rd Symposium on Foundations of Computer Science, IEEE Computer Society Washington, DC, USA, 2002 [2] J. W. Byers, M. Luby, M. Mitzenmacher, A. Rege A digital fountain approach to reliable distribution of bulk data, on ACM SIGCOMM Computer Communication Review, vol 28, issue 4, pp: 56 67, 1998. [3] ETS 300 421, Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for 11/12 GHz satellite services [4] Sat3play project page: http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=2863 4 [last accessed on March 30, 2009] [5] ETSI EN 301 790 (V1.4.1), Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems, March 2006. [6] Satmode project page: http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=1184 3 [last accessed on March 30, 2009] [7] R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [8] ETSI, Specification for data broadcasting, EN 301 192 v1.4.1, Nov. 2004. [9] G. Fairhurst, B. Collini-Nocker, Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream (TS), IETF RFC 4326, Dec. 2005. [10] A. Mayer, B. Collini-Noker, F. Vieira, J. Lei, M.A: Vzzquez Castro, Analytical and Experimental IP Encapsulation of GSE, MPE, and ULE over DVB-S2, International Workshop on Satellite and Space Communications (IWSSC), Salzburg, Sep. 2007.

[11] Jeff Foerster and John Liebetreu, FEC Performance of Concatenated Reed-Solomon and Convolutional Coding with Interleaving, IEEE802.16 Broadband Wireless Access WG technical paper, Jun 2000. [12] NS2 Official Website, http://www.isi.edu/nsnam/ns/ [last accessed on March 30, 2009] [13] A. Shokrollahi, Raptor codes, IEEE/ACM Transactions on Networking (TON) 2006 [14] M.C.O. Bogino, P.Cataldi, M. Grangetto, E. Magli, G. Olmo, SlidingWindow Digital Fountain Codes for Streaming of Multimedia Contents, IEEE ISCAS 2007 [15] P. Maymounkov, Online codes, Research Report TR2002-833, New York University, Nov 2002 [16] M. Luby, M. Watson, T. Gasiba, T. Stockhammer, W. Xu, Raptor Codes for Reliable Download Delivery in Wireless Broadcast Systems, Proc. of IEEE CCNC 2006 [17] E. Altman,K Avrachenkov and C. Barakat, A stochastic model of TCP/IP with stationary random losses, ACM SIGCOMM, pp 231242, 2000. [18] N. Parvez, A. Mahanti and C. Williamson An Analytic Throughput Model for TCP NewReno, whitepaper of University of Calgary, http://pages.cpsc.ucalgary.ca/~mahanti/papers/newreno.model.pdf , 2007 [19] W. Stevens, TCP/IP Illustrated. Vol.1, Ed. Addison Wesley, ISBN: 978-0201633467,Jan. 1994. [20] Ippolito, Louis J., Jr. Book on Radiowave propagation in satellite ommunications, New York, Van Nostrand Reinhold Co., 1986, p. 253. [21] ETSI EN 302 307, Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications [22] R. Rinaldo and R. de Gaudenzi, Capacity analysis and system optimization for the forward link of multi-beam satellite broadband systems exploiting adaptive coding and modulation, International J. Satellite Commun. Networking, vol. 22, no. 3, pp. 401--423, May/June 2004. [23] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby. Performance enhancing proxies intended to mitigate link-related degradations, RFC 3135, IETF, 2001. [24] SatLabs Interoperable PEP (I-PEP) Transport Extensions and Session Framework for Satellite Communications: Air Interface Specification, Oct. 2005. [25] R. M. Sanders and A. C. Weaver, The Xpress Transfer Protocol (XTP) A Tutorial, Computer Communications Review, 1990. [26] D. MacKay, Information Theory, Inference, and Learning Algorithms, Cambridge University Press; 1st edition ISBN: 9780521642989, June 15, 2002. [27] M. Luglio, R. Ramilli, Impact of Fade and non-Fade Duration for different Elevation Angles on Time Correlation Characterization for Land Mobile Satellite Systems, Space Communications, Vol. 19, N. 2, pp. 69-82, 2003.