1 Introduction

Satellite communications on the move (SOTM) systems have become an essential part of commercial and military communications because they offer the high-speed wireless link to moving vehicles such as maritime vessels, trains, and land vehicles through a satellite [1–3]. In the SOTM system, the antenna of the SOTM terminal, which is equipped with an active control system and an inertial navigation system is pointed to the satellite. Thus, the wireless link between the SOTM terminal and the satellite can be continuously maintained. However, the link between the SOTM terminal and the satellite can experience a temporary outage owing to channel blockage due to pointing errors of the antenna on account of the rugged terrain and obstructions such as high buildings and trees. It can cause packet loss in the satellite link [2, 3].

There are two main error recovery techniques: retransmission and forward error correction (FEC). In satellite communications, both retransmission and FEC are used. However, in satellite communications using retransmission of TCP, even though optimized TCP can be applied to satellite link by a performance enhancing proxy (PEP) [4, 5], the throughput can be sharply reduced within a lossy environment because of the coupling of the congestion control and losses in TCP. Because TCP was designed for wired environment, a loss in TCP is always ascribed to congestion. As a result, the TCP congestion window is decreased even though the loss is actually not due to congestion but to channel blockage. This problem is worsened on satellite communications since it takes time to re-open the TCP congestion window and retransmit data due to the long propagation delay. Furthermore, an FEC technique such as channel coding that is applied in the physical layer of the satellite communications only corrects data corruption due to the noise and the interference. It cannot recover packets lost owing to the channel blockage in the SOTM network because of its fixed time diversity and fixed amount of protection [1].

Recently, an application-layer FEC (AL-FEC) is applied to satellite communications for SOTM terminals [6, 7]. The AL-FEC system can not only correct for packets lost owing to the channel blockage with its flexible time diversity and flexible amount of protection but also eliminate retransmission delay by FEC. Furthermore, the AL-FEC system can potentially achieve better performance as compared with an acknowledgement (ACK)-based system as TCP because the AL-FEC system is a rate-based system with a constant transmission rate through a user datagram protocol (UDP) [8]. In this system, losses do not cause any impact on the transmission rate, resulting in enhancing the throughput. However, an additional feedback mechanism that notify the file-decoding completion is needed to provide fully reliable file transfer because AL-FEC system is based on the unreliable transfer method such as UDP [9]. Some studies have been researched to provide the full reliability of file transfer based on AL-FEC by the additional feedback [9–11]. To deploy these systems, file-transfer systems of all servers and end-hosts should be changed.

In this paper, we propose a fully reliable file-transfer framework (FRFTF) with AL-FEC in SOTM networks to minimize the additional system change. In the proposed FRFTF, we use an ACK exchange scheme to provide the reliability of the end-to-end data transfer. To minimize the system change, FRFTF is implemented inside a performance-enhancing proxy (PEP) with the splitting connection. We then analyze the transfer time of a file of FRFTF in SOTM networks. The main contributions of the paper are as follows:

  1. 1.

    A fully reliable file transfer framework with AL-FEC in SOTM networks

  2. 2.

    A performance analysis model evaluating the performance of the reliable AL-FEC mechanism with Markov chain model

2 Related works

2.1 TCP

Generally, TCP is used in the file-transfer system because TCP can provide the reliable, in-order delivery, and the congestion control thanks to its sliding window and ACK-based systems [12]. However, TCP performance can be degraded in the wireless environment because of the coupling of the congestion control and losses in TCP. In the satellite communication with the long propagation delay, this problem is worsened. Thus, in the satellite communication, the optimized TCP such as TCP Hybla is used [13]. In the optimized TCP, the TCP congestion window is aggressively increased to enhance the TCP throughput. However, the problem of the ACK-based system still remains. Therefore, we propose the file transfer framework with AL-FEC that is rate-based system with a constant transmission rate aided by the cross-layer design.

2.2 Benefit of AL-FEC

In wireless communications, channel coding is important because it ensures the reliability of data transmission protecting it from the data corruption by noise and interference. However, in mobile satellite networks, channel blockage due to intermittent shadowing can cause packet loss even though channel coding is applied, as shown in Fig. 1. To solve this problem, many studies have investigated AL-FEC in many communication systems [8, 14–16]. AL-FEC covers the packet loss not recovered by channel coding because it is applied above layer 2 and uses the fountain code known as the rateless erasure code. Figure 1 shows the example for the benefit of AL-FEC in the channel blockage. It is shown that AL-FEC compensates the packet loss caused by the channel blockage by means of longer source block and the repair block generated by AL-FEC [17]. Recently, Raptor code has been commercially used in AL-FEC. It is fountain codes with linear time encoding and decoding because the encoding with degree distribution and the belief propagation decoding are used [15]. Furthermore, it provides dynamic packet loss protection, exceptionally high computational efficiency, and low transmission and reception overheads [15, 18]. Therefore, its advantages allow a software implementation and also provide end-to-end error correction without requiring any change in legacy standards, resulting in ease of deployment in the network [15]. To the best of our knowledge, the file-transfer time of the fully reliable file transfer with AL-FEC has not been explored. Therefore, we propose not only fully reliable file transfer framework with AL-FEC for SOTM networks but also analyze the transfer time of the proposed FRFTF.

Fig. 1
figure 1

Example for the benefit of AL-FEC in the channel blockage

Full size image

3 Proposed file transfer framework

3.1 System model

The system model consists of a ground station, a SOTM node, a satellite, and file servers as shown in Fig. 2. The SOTM node is connected to the ground station by satellite links. Because SOTM nodes have mobility, the satellite link can be intermittently disconnected owing to the rugged terrain and obstructions such as high buildings and trees. The ground station is connected to file servers by high-speed wired links, and a performance-enhancing proxy (PEP) with the splitting connection is implemented in it [4, 5]. The ground station that received files from file servers transmits data files to the SOTM nodes. In the AL-FEC system of the proposed FRFTF, a file is segmented into k native packets. The native packet is the original data segmented from a file. k can be calculated as

$$\begin{array}{@{}rcl@{}} k = \left\lceil {\frac{{{L_{\rm{F}}}}}{{{L_{\rm{S}}}}}} \right\rceil, \end{array} $$
((1))
Fig. 2
figure 2

System model of the proposed FRFTF

Full size image

where L F and L S are the sizes of a file and a native packet, respectively. Repair packets are generated from k native packets by RaptorQ code. RaptorQ code is the advanced version of Raptor code [19]. In RaptorQ code, the decoding probability is 99.9999 % when k+2 packets are received regardless of the block length k [19, 20]. It is transmitted to recover packets lost due to the channel blockage. The size of the repair packet is L S . We make the following assumptions regarding our FRFTF:

  1. 1.

    A two-state Markov chain model is used as the channel model [2]. The channel model has channel open (o) and blockage (b) states.

  2. 2.

    In the link layer of satellite communications, the information on satellite resource is shared by a cross-layer design [21, 22]. Thus, this information can be used in FRFTF.

  3. 3.

    If the SOTM node receives k+2 packets generated from a file, it can decode the file without error [19, 20].

  4. 4.

    The processing time for AL-FEC is insignificant [20].

3.2 Architecture of proposed file-transfer framework

The proposed FRFTF is shown in Fig. 2. To apply the AL-FEC to the file-transfer system, the AL-FEC system should be implemented in all file servers and end-host nodes. However, it is not easy to change the file system in all servers. Thus, in FRFTF, the PEP solution with the splitting connection is exploited [4, 5]. FRFTF is only implemented in the PEP of the ground station and SOTM nodes as shown in Fig. 2. In FRFTF, the TCP connection is used between the ground station and the file server. The UDP connection is used between the ground station and the SOTM node. As a result, FRFTF can be compliant with conventional a file-transfer system. In FRFTF, the file download should be completed between the ground station and the server to generate repair packets. However, the additional delay by the splitting connection is not incurred thanks to the high capacity of the wired link between the ground station and the file server. Its capacity is much greater than that of the satellite link. Therefore, the file download from the server to the ground station can be finished while transmitting native packets from the ground station to the SOTM node.

All packets generated from FRFTF are transferred to the UDP layer by constant transmission rate, R T X . However, if the sum of the speed for parallel connections exceeds the overall available bandwidth, FRFTF can incur the buffer overflow in the link layer, resulting in the poor performance. Thus, the ruler to decide R T X is needed. FRFTF uses the information on available resource from a resource manager in link layer by cross-layering to select R T X [21, 22]. For the fair bandwidth sharing among parallel connections, R T X can be selected as

$$\begin{array}{@{}rcl@{}} {R_{{\rm{TX}}}} = \min \left({{R_{\rm{D}}},{R_{\rm{A}}}/\mu} \right), \end{array} $$
((2))

where R D and R A are the demanded rate for a file-transfer service and the available rate in FRFTF, respectively. μ is the number of connections for FRFTF. We assume that R A can be calculated by the information on available resource in link layer and header overheads of link layer and UDP/IP [21, 22]. If the quality of the service should be guaranteed in the system, a call admission control can be applied to limit the number of connections in FRFTF [23, 24]. When the SOTM node is file server, the information on available resource in the link layer is used to select R T X by the cross-layer design [25, 26].

3.3 Procedure

The proposed FRFTF lies between the application layer and the transport layer as shown in Fig. 2. The detailed procedures of the file transfer in FRFTF in the sender and receiver are as follows:

  1. 1.

    Sender: Upon receiving the data of a file from the file server, FRFTF of the sender segments it into native packets by the size of L S . FRFTF then inserts native packets into both transmission and encoding queues. Packets in the transmission queue are transferred to UDP layer by constant TX rate of R T X . Next, when FRFTF receives a file completely, it generates repair packets from the k native packets in the encoding queue with RaptorQ code. After the repair packet generation, all the packets are inserted into the transmission queue. When receiving the receiver-ACK (R-ACK) message that indicates the completion of the file reception from the receiver, the FEC framework removes all packets from the transmission queue and terminates the file transfer to the receiver. The sender then sends the sender-ACK (S-ACK) that indicates the reception of R-ACK to the receiver. If the sender receives duplicated R-ACK, the sender retransmits the S-ACK.

  2. 2.

    Receiver: Upon receiving packets from the sender, FRFTF of the receiver inserts the packets into the reception queue. FRFTF checks whether the packets in the reception queue can be decoded to a file by RaptorQ code. If the decoding is completed, the receiver sends an R-ACK message to the sender (ACK-based scheme) and the file is forwarded to the application layer. If the receiver does not receive S-ACK message within round trip time (RTT), it retransmits the R-ACK message to the sender.

In FRFTF, the two-way ACK exchange is used to provide the reliability of data transfer because the S-ACK and R-ACK messages can be lost due to the channel blockage in the satellite communication environment. At the receiver, there is no extra delay caused by the ACK exchange because a file is forwarded to the application layer immediately after the completed decoding. However, the ACK exchange can incur the additional usage of satellite resource at the sender because the sender continuously transmits the packets to the receiver until receiving the R-ACK. The detailed analysis of this overhead is discussed in Section 4.

4 Performance evaluation

In this section, we theoretically derive the average file-transfer time and resource efficiency for transmitting a file by the simple Markov chain model. We also evaluate the performance of the proposed FRFTF in SOTM networks through the theoretical analysis and the simulation.

4.1 File transfer time

To calculate the average file-transfer time, T F T , we model the bidimensional process {s(t),n(t)} with the discrete-time Markov chain depicted in Fig. 3. In this Markov chain, \(s\left (t \right) \in \left \{ \mbox{{b},\rm {o}} \right \}\) is the channel state, \(n\left (t \right) \in \left \{ {0,1,\ldots,N} \right \}\) is the number of packets transmitted successfully, and t is the time measured in slots. N is the required number of packets received at the receiver for decoding a file. Thus, N is k+2 as mentioned in Section 2. B. A slot is equal to the time T S used to transmit one packet of size L S . T S is \(\frac{L_{S}}{R_{TX}}\). Since the channel model is a two state Markov chain, the state transition probabilities are

$$ \begin{aligned} &P\left\{ {s\left(t \right),n\left(t \right)|s\left({t - 1} \right),n\left({t - 1} \right)} \right\} \\ &\qquad=\left\{\begin{array}{ll} P\left\{ {{\rm{o}},\,\,i|{\rm{b}},\,\,i} \right\} = {p_{\rm{ob}}}, & i \in \left({0,N - 1} \right)\\ P\left\{ {{\rm{o}},\,\,i|{\rm{o}},\,\,i + 1} \right\} = {p_{\rm{oo}}}, & i \in \left({0,N - 1} \right)\\ P\left\{ {{\rm{b}},\,\,i|{\rm{o}},\,\,i + 1} \right\} = {p_{\rm{bo}}}, & i \in \left({0,N - 1} \right)\\ P\left\{ {{\rm{b}},\,\,i|{\rm{b}},\,\,i} \right\} = {p_{\rm{bb}}}, & i \in \left({0,N - 1} \right)\\ P\left\{ {{\rm{o}},\,\,N|{\rm{o}},\,\,N} \right\} = 1, \end{array}\right. \end{aligned} $$
((3))
Fig. 3
figure 3

Markov chain model for average file-transfer time of the proposed FRFTF

Full size image

where p xy is the state transition probability from the channel state \(x \in \left \{ \mbox{{b},\rm {o}} \right \}\) to the channel state \(y \in \left \{ \mbox{{b},\rm {o}} \right \}\) in the channel model. In our model, the file transfer is completed in state {o,N}. Therefore, similar to [27], T F T can be calculated from the expected number of times that the process is in state {o,N} if it is started in state {s(t),n(t)}. The expected number of times ψ can be calculated as

$$ {\fontsize{8.7pt}{9.6pt}\selectfont{\begin{aligned} \psi \left({s\left(t \right),n\left(t \right)} \right) = \left\{{\begin{array}{*{20}{l}} {\!\psi \left({{\rm{o}},i} \right) =\! \left({1 + \frac{{{p_{{\rm{ob}}}}}}{{1 - {p_{{\rm{bb}}}}}}} \right)\left({N - i} \right),}\\ {\!\psi \left({{\rm{b}},i} \right) = \!\frac{1}{{1 - {p_{{\rm{bb}}}}}}\!\left\{ {1 \!+ \left({N - i - 1} \right) \left({{p_{{\rm{ob}}}} + {p_{{\rm{bo}}}}} \right)} \right\},} \end{array}} \right. \end{aligned}}} $$
((4))

where \(i \in \left ({0,N - 1} \right)\). The possible initial states are {o,0} and {b,0} in Fig. 3. Consequently, T F T can be derived as

$$\begin{array}{@{}rcl@{}} T_{\rm{TF}} = \left({{\pi_{\rm{o}}}\psi \left({\rm{o},0} \right) + {\pi_{\rm{b}}}\psi \left({\rm{b},0} \right)} \right) \times {T_{\rm{S}}} + T_{\rm{P}}, \end{array} $$
((5))

where π o and π b are the steady state probabilities in the channel model. They can be calculated from the transition probabilities of the channel model [27]. T P is the propagation delay of the satellite link.

The average goodput G can be defined as

$$\begin{array}{@{}rcl@{}} G = \frac{{{L_{\rm{F}}}}}{{{T_{\rm{FT}}}}}. \end{array} $$
((6))

4.2 Resource efficiency

To derive the resource efficiency of FRFTF, we consider the additional consumption of the resource caused by the ACK-based scheme. Because the sender can terminate the file transfer upon receiving the ACK message, the resource is basically wasted in 2T P . Furthermore, if the R-ACK message is lost, the resource is additionally wasted during retransmission of ACK messages. The resource usage time due to retransmission of ACK messages is \(2{T_{P}}\left(1 - {{\pi}_{b}} \right)\left({{\pi}_{b}} + 2{{\pi}_{b}}^{2} + 3{{\pi}_{b}}^{3} + \ldots \right)\). This is approximately \(2{T_{P}}\frac{{\pi}_{b}}{\left(1 - {\pi}_{b} \right)}\). On the other hand, if the S-ACK message is lost, the additional resource is only needed to retransmit ACK messages. However, it is insignificant because the size of ACK messages is very small. Thus, we do not consider the loss of the S-ACK message in the resource efficiency. Therefore, the average resource efficiency η is given as

$$\begin{array}{@{}rcl@{}} \eta = \frac{{{L_{\rm{F}}}}}{{{T_{\rm{RU}}}{R_{\rm{TX}}}}}, \end{array} $$
((7))

where T R U is the total resource usage time to complete a file transfer with FRFTF. For the average file transfer time, the resource usage time is T F T −T P . Thus, taking into consideration the resource usage time for the average file transfer time and the wasted resource by ACK exchange, T R U can be calculated as

$$\begin{array}{@{}rcl@{}} T_{\rm{RU}} = {T_{{\rm{FT}}}} + {T_{\rm{P}}}\left({1 + \frac{{2{\pi_{\rm{b}}}}}{{1 - {\pi_{\rm{b}}}}}} \right) + \varepsilon, \end{array} $$
((8))

where ε is the processing time of the ACK message. However, it may be negligible.

4.3 Performance analysis

In the performance analysis, we compare the performance of the proposed FRFTF with those of TCP Reno, PEPsal and conventional AL-FEC mechanisms for the environments listed in 1 [2, 4, 6, 8, 12, 14]. PEPsal is conventional PEP solution in the satellite communication [4]. PEPsal uses the PEP with the TCP splitting connection. In the satellite link, PEPsal can use TCP variants to enhance TCP throughput [4]. In the simulation, we used TCP Hybla as TCP variant in PEPsal. TCP Hybla is one of well-known TCP variants for the satellite link [13]. In conventional AL-FEC mechanisms, fixed protection period (PP) and code rate (CR) are used [8, 14]. We have implemented an event-driven simulator of FRFTF and conventional AL-FEC mechanisms in MATLAB. Because of the complex operation of TCP, we use the Riverbed modeler formerly known as OPNET to implement streamlined simulators of TCP Reno and PEPsal [28]. In this streamlined simulator, main functions of TCP such as sliding window, slow start, congestion avoidance, retransmission, retransmission timeout (RTO) calculation, and selective ACK (SACK) are included [12]. TCP Hybla algorithms used in PEPsal are also implemented in the simulator [13]. In the simulation, we used the channel blockage statistics as the channel model of SOTM. Channel blockage statistics are based on the measurements in the field test [2]. We consider environment in the city. In FRFTF, L S is varied according to L F because of the size limitation for k. For the conventional AL-FEC mechanisms, we assume that the loss rate on channel is known in AL-FEC mechanisms by the cross-layer design [21, 22]. Thus, fixed PP and CR are 2 s and 2/3, respectively, because the mean open distance, velocity, and the blockage fraction are 30 m, 60 km/h, and 33 %, respectively [2].

Table 1 Environment in the performance analysis
Full size table

Initially, we evaluate the reliability of FRFTF. Figure 4 shows a file-delivery rate in the application layer. It is shown that FRFTF offers the fully reliable file transfer in the application layer thanks to the transmission of repair packets. However, in conventional AL-FEC mechanisms, the fully reliable file transfer is not supported because there is no ACK exchange scheme.

Fig. 4
figure 4

File delivery rate in the SOTM environment (city, blockage fraction = 33 %)

Full size image

Figures 5, 6, and 7 show the average file-transfer time, the average goodput, and the average resource efficiency in the SOTM environment, respectively. In these results, we apply the ACK exchange scheme to conventional AL-FEC mechanisms. Additionally, a negative ACK (NACK) exchange is applied in conventional AL-FEC mechanisms because they use the fixed CR. In simulation, if the SOTM node with conventional AL-FEC mechanisms does not completely receive a file, it sends the NACK message to the ground station. In Fig. 5, the file-transfer time of FRFTF is less than that of TCP and PEPsal because FRFTF is a rate-based system and eliminates the retransmission process by the transmission of repair packets by AL-FEC. In the satellite communication using TCP, the coupling of the congestion control and losses in TCP reduces the TCP throughput in the long propagation delay. In Fig. 6, it is shown that FRFTF outperforms TCP and PEPsal in terms of the goodput because of the lower file transfer time of FRFTF. In the transfer of a small-sized file, the goodput of FRFTF is 5–10 times more than that of TCP and PEPsal. In the transfer of a large-sized file, the goodput is improved by about 560 and 100 %, respectively. In Fig. 7, it is shown that the resource efficiency is lower in FRFTF than in TCP. For the transfer of a small-sized file using FRFTF, the resource efficiency is greatly reduced because of the wasted resource during the ACK transmission, and the continuous data transmission regardless of whether the channel is open or blocked. On the other hand, the resource efficiency of FRFTF is slightly lower than that of TCP in the transfer of a large-sized file. Since the wasted resource during the ACK transmission in FRFTF is fixed, the overhead due to the wasted resource during the ACK transmission is reduced with increasing file size. In the case of PEPsal, the resource efficiency can be lower than that of FRFTF because the optimized TCP is used. The optimized TCP increases the TCP window size aggressively to enhance the TCP throughput in the satellite communication with the long propagation delay [13]. Thus, the number of the packets transmitted during the channel blockage increases, resulting in reduction of the resource efficiency. In addition, retransmitted packets can be repeatedly transmitted during the channel blockage in the frequent channel blockage.

Fig. 5
figure 5

Average file-transfer time in the SOTM environment (city, blockage fraction = 33 %)

Full size image
Fig. 6
figure 6

Average goodput in the SOTM environment (city, blockage fraction = 33 %)

Full size image
Fig. 7
figure 7

Average resource efficiency in the SOTM environment (city, blockage fraction = 33 %)

Full size image

In Figs. 5, 6, and 7, it is observed that FRFTF outperforms conventional AL-FEC mechanisms in terms of the average file-transfer time, the average goodput, and the average resource efficiency because fixed PP and CR reduce the efficiency of the AL-FEC mechanism in the SOTM system.

Figure 8 shows the average goodput in an environment with various channel blockages for varying the blockage fraction and the mean blockage. It is clear that FRFTF also outperforms TCP in terms of the goodput in an environment characterized by various blockage fractions and mean blockages.

Fig. 8
figure 8

Average goodput in the SOTM environment with various channel blockages

Full size image

5 Conclusions

In this paper, we proposed a reliable file-transfer framework with AL-FEC in SOTM networks to reduce the file transfer time. We also analyze the file transfer time of the proposed FRFTF with the Markov chain model. Simulation results indicated that FRFTF can reduce the file-transfer time owing to the rate-based approach and elimination of retransmission delay. As a result, FRFTF outperformed conventional TCP in terms of the goodput. In the file transfer, the goodput of FRFTF is 6.6–10 times more than that of TCP. Furthermore, the overhead of FRFTF is small for large-sized file transfers in terms of the resource efficiency. Therefore, FRFTF can be applied to various services such as the transfer of urgent messages, mail service, web browsing, and file-transfer protocol in SOTM environments of military and commercial communications.