TCP Performance Issues in Satellite and WiFi Hybrid Networks for High-Speed Trains

GEO satellite communication systems are an efficient approach for broadband Internet provision on highspeed trains, but some work is still needed to allow a seamless service. In the railway scenario, satellite communications suffer from strong variations in the received signal power and need suitable solutions to deal with long channel disruptions due to tunnels. The approach envisaged in this paper is based on a hybrid network (satellite and terrestrial WiFi coverage) and a Vertical Handover (VHO) procedure to switch seamlessly from one segment to another whenever link quality degrades and a new segment is available. This paper deals with the TCP performance in the presence of VHOs (based on the IEEE 802.21 Media Independent Handover, MIH, standard) from the satellite to a terrestrial wireless segment and viceversa to cover tunnels. Details are provided for the adoption of MIH and MIPv6 in such a context, referring to the BSM standard. Design criteria for the WiFi coverage extension outside the tunnel are also presented. Finally, we have shown that TCP goodput behavior and convergence time can be improved by means of suitable accelerated TCP versions or using cross-layer methods.


Introduction
Passengers on high-speed trains expect broadband Internet services.Cellular 3G Internet access is a common solution for railway systems, but such approach is not economically-viable when hundreds of kilometers of railway network need to be covered in rural areas.Moreover, high-speed trains pose severe constraints on cellular systems in terms of Doppler effect, handover frequency, and handover execution time.Hence, satellite communications are a good candidate for broadband Internet provision on high-speed trains.At present, there are different implementations based on Geostationary (GEO) satellites.For instance, Eutelsat provides multimedia services and Internet access via satellite on board of high-speed trains in France [1], but tunnels are not covered.Moreover, a wireless terrestrial access is used in railway stations.Still in France, an alternative hybrid approach with TCP acceleration and data compression is used by the 21Net operator [2].
Communication services to trains via GEO satellites are affected by short-term link unavailability events (shadowing, on the order of tens to hundreds of ms) due to power line structures, trees, buildings, and small obstacles, in general.While, long-term channel disruptions (blockage, on the order of seconds to minutes) are caused by relatively-long tunnels [3].There are several approaches to deal with disruptions at different (4+ to PHY) layers, such as: • Antenna/transmission diversity system.Also combined approaches are possible.In particular, the combination of HetNet with accelerated TCP versions can represent a powerful solution.The limit to this approach is given by the fact that modified TCP versions need to be supported by servers and this could be viable only if the severs are specialized and internal to the railway network.To deal with the cases of generic servers in the Internet, TCP split solutions should be adopted with one or two PEP's [4].Hence, HetNets with TCP split technique, PEP and accelerated TCP versions for the satellite segment is another combined approach to deal with channel disruptions.PEPs do not need modifications to transport layer at end systems.On the other hand, disadvantages in using PEP are: (i) PEP is incompatible with security protocols like IPsec; (ii) A PEP context transfer (or a TCP re-synchronization) is needed in the presence of Vertical Handovers (VHOs) to switch for instance from the satellite segment with a PEP to another wireless segment with another PEP or without PEP [5].
DTN introduces modifications at both ends with a bundle layer between application and transport layers.The bundle layer has to be installed also on internal nodes along the path.Particularly relevant to our scenario is the custody transfer option that allows the delivery of the 'bundle' (= DTN packet) from custodian to custodian along the path to the destination, according to a store-and-forward approach.The DTN approach is not transparent since it entails e2e modifications in the protocol stack [6].DTN is a robust solution to deal with long channel disruptions [7] and extremely-long channel delays [8], [9], but we expect that HetNets providing an uninterrupted data transfer in tunnels can be an appealing approach for the train scenario.
On the basis of these considerations, we focus here on a HetNet (satellite and WiFi) e2e TCP scenario (no PEP is adopted).The satellite link is used for communication services to the train during the trip.As soon as the train approaches a tunnel, a VHO is performed to switch seamlessly the link to a local WiFi coverage.Within the tunnel, more WiFi Access Points (APs) are needed for a seamless coverage.A second VHO is executed when the train leaves the tunnel.We are interested to investigate the TCP performance in the presence of VHOs.
The HetNet scenario has been recently addressed by the 3GPP LTE standardization body.Moreover, the study made here on VHOs could also be applied to other train environments (dense urban areas and railway stations) or to the scenario of aeronautical communications (the multi-link concept introduced by the EU Single European Sky ATM Research SESAR Programme [10]).

Network Scenario
We consider the reference network architecture shown in Figure 1, where a collective terminal on a train receives a downstream FTP traffic (TCP 'elephant' connections) via a GEO bent-pipe satellite.When the train approaches a tunnel, a WiFi connection (at 11 Mbit/s, in this study) is used by means of a VHO.Terrestrial wired links bit-rates have been set to 500 Mbit/s to emphasize the bottleneck nature of the wireless segments.
We assume that the collective terminal on the train has pre-assigned IP addresses in both the satellite and the WiFi networks.
The mobility and related VHO events need to be managed at both Layer 2 (L2) (for the selection of a new link) and Layer 3 (L3, new IP address for the mobile node and new path for the traffic).To support the L2 handover procedures, IEEE 802.21 Media Independent Handover, MIH, is adopted [11] and applied to the Broadband Satellite Multimedia (BSM) standard protocol architecture [4].With MIH, a mobile node discovers a new access link, registers itself to the new network, disconnects from the old network (when some handover criterion is met), and communicates with the corresponding host via the new access link.As for the IP layer, we adopt MIPv6 that entails an efficient rerouting of IP traffic with a low L3 handover latency.VHO requires some L2 and L3 signalling exchanges to detect the new link and to define automatically the new IP address, Care of Address (CoA), by means of Router Advertisement (RA) and Router Solicitation (RS) messages.Then, as soon as the VHO is decided, L2 and L3 cross-layer signaling via MIH-enabled Satellite Independent -Service Access Point (SI-SAP) interface is needed to trigger a Binding Update (BU) message sent via the new link to a 'root' gateway element and from it to the corresponding node (i.e., the sender) to notify the new IP address of the mobile node.We consider the following system requirements: • GEO bent-pipe satellite (Ku or Ka band) SI-SAP is a general interface between L2 and L3 and is well suited to harmonize different air interfaces in the HetNet scenario.SI-SAP traffic management is based on virtual queues, named QID's.These queues are defined according to traffic policing parameters, named QID QoS Specification (QIDSPEC).QIDSPEC at SI-SAP could be enriched with crosslayer information (e.g., TCP state coming from upper layer -downward direction-and wireless segmentrelated PHY information -upward direction).Several SI-SAP (cross-layer) signalling could be involved in the VHO procedure.In particular, we could consider signalling primitives from L2 to L3 to trigger the VHO procedure and to support MIH.Moreover, the SI-C-QUEUE − STATUS primitive [13] could be used to provide information about the propagation delay up to the egress element from the BSM network and the MAC buffer size capacity.This signalling primitive is currently envisaged for IntServ, but could also be adapted to support transport layer with an updated estimate of the minimum Round-Trip Time (RTT) and the maximum TCP congestion window (cwnd) value in the new visited network.

Survey of TCP Problems due to VHOs in the Railway Scenario
Several problems affect the TCP performance during a VHO procedure [14]; in particular, the sudden BDP variation and a significant change in the RTT.It is important to avoid 'hard' VHO procedures because they entail intervals of channel disruption with the possibility of bursty packet losses.However, with soft procedures, there could be a time interval during which the train exchanges data via both satellite and WiFi paths: ACK and TCP packets propagate quickly via WiFi so that they could anticipate those sent via the satellite link (out-of-sequence problems for segments and ACK holes).
Crucial parameters for TCP performance during a VHO are: the duration of the handover phase (including L2 and L3 signaling), the overlap area between the satellite coverage and the WiFi one (allowing a soft VHO, starting this procedure in advance with respect to the physical link disconnection), the average train speed, and buffer sizes (sender, satellite network gateway, and WiFi AP).We examine below the detailed effects on TCP behavior in the two possible VHO cases for our train scenario [14], [15]: from satellite to WiFi and from WiFi to satellite.We refer to a mobile collective terminal on the train that receives TCP downstream flows.The relevance of all these effects depends on the phase and the value of the TCP cwnd at the VHO time.

Satellite-to-WiFi VHO
In this case (train entering the tunnel), we could expect that BDP and RTT have significant reductions in moving towards the WiFi network.The problems that TCP could encounter during this VHO process are: • TCP packets are anticipated (received out-ofsequence) due to the fact that when TCP packets are still propagating via satellite, new TCP packets can be quickly received via WiFi.Then, TCP packets need to be reordered at the receiver before being delivered to upper layers (this might cause a receiver window partly closing).
-DUPACKs are generated due to the arrival of out-of-sequence TCP packets.This may cause useless retransmissions and halving the cwnd value.
• ACK packets are anticipated as soon as the new WiFi path is activated (especially when the cwnd value is high).Hence, due to the cumulative nature of ACKs, many TCP segments would be acknowledged together, thus causing a bursty injection of data traffic in the WiFi AP buffer to be sent to the mobile collective terminal with the risk of buffer overflow.

WiFi-to-Satellite VHO
In this case (train leaving the tunnel), the WiFi BDP is much smaller than that of the satellite network (cwnd is temporarily reduced in the WiFi segment).The problems that TCP encounters during this VHO process are: • Too short Retransmission TimeOut (RTO) at the beginning of the connection via satellite with the risk of RTO expiration and cwnd reset; moreover, multiple RTO expirations could lead ssthresh to 1, thus slowing the cwnd increase to fill the pipe).
• Slow cwnd increase when the satellite link is re-established (if the VHO process starts when TCP is in the congestion avoidance phase) with consequent slow traffic injection increase in the satellite segment.

Literature Survey on VHO Impact for TCP
The management of VHOs in HetNets is receiving significant attention in the literature; however, few papers address the impact on transport layer in the railway satellite scenario.In particular, we focus on those studies adopting cross-layer methods involving L2, L3, and L4 signalling.The work in [15] proposes to close cwnd at the sender before the VHO execution (hard handover), through cross-layer signalling, based on transport layer ACK.When the VHO procedure re-establishes a connection in the new segment, cwnd is reset to 1 and ssthresh is set equal to the estimated bandwidth for the new link.This method does not seem to be actually seamless, especially for the case of WiFi-to-satellite handover where cwnd would need a long time to recover its value.
The reordering approach defined in [16] is a senderand receiver-side modification that allows managing the arrival of out-of-sequence packets due to the VHO from a high RTT network (satellite) to a low RTT one (WiFi).Instead of DUPACKS, ACKs are sent and a congestion avoidance phase is performed during the interval for which out-of-sequence packets are received.
The adaptive RTO proposed in [16] is a senderside TCP modification.This method utilizes the transmission of the VHO execution notification to the sender to block RTO expirations until an ACK is received through the new network that updates the RTO value.
Reference [17] proposes to adopt a MAC buffer size notification to the sender that uses this information to determine an upper bound to the cwnd value for the new network.
Table 2 provides further details on the cross-layer techniques available in the literature to improve TCP performance in the presence of VHOs.

WiFi Coverage Extension Outside the Tunnel
The WiFi coverage area outside the tunnel needs to be dimensioned to guarantee a seamless VHO.Such coverage depends on satellite Line Of Sight (LOS) conditions, train speed (the faster the train, the shorter the time to cross the overlap area and to execute the VHO), and handover criterion.
We consider a situation with a train leaving (or entering) the tunnel, moving in the South-North (or North-South) direction.Then, the distance d 1 at which the satellite LOS condition is restored after the (lost before the) tunnel is: where θ = satellite elevation angle, ψ = train latitude, H = GEO satellite altitude (= 35930 km), R t = earth radius (= 6378 km), and L = height of the obstacle (crossed by the tunnel) in the direction of the satellite.
Moreover, the satellite-WiFi overlap area d 2 and the corresponding crossing time t HO has to last enough to allow the exchange of L2 and L3 signalling via satellite and WiFi for the VHO procedure ('soft' VHO case).Considering a train speed v, we have: ( Let d W iFi outside ext denote the WiFi coverage extension outside the tunnel with two cases, that is, at the entrance and at the exit of the tunnel.We consider that the WiFi coverage extension needs to be sufficiently large to cover both satellite non-LOS area and handover execution time.Hence, the following condition can be used: where χ = 0 or 1 depending on having or not LOS conditions (before or after the tunnel).
The VHO execution time t HO starts from the first reception by the mobile terminal on the train of a signal from the new network to the reception of the BU ACK message from the sender via the new wireless segment or the last packet received thorough the old network, whichever occurs as last one.Figures 2 and 3 describe the signaling and the maximum t HO times for the WiFito-satellite and the satellite-to-Wifi VHOs, respectively.In this study, we have modified the classical MIH signalling to improve the impact of VHO on TCP behavior: data are transmitted to the terminal through the new wireless segment soon after the BU message is received by the sender in order not to waste time (see Section 6).The maximum t HO time interval depends on the time relation between the last cwnd of data sent before the VHO decision and the MIH signalling (BU / BU ACK).On the basis of Figure 2   scenario as follows: where T synch is a PHY synchronization time (about tens of ms), RT D AP (on the order of µs) denotes the roundtrip propagation delay from the collective terminal on the train to the WiFi AP, T HO_decision is the time needed to decide to start a VHO procedure, RT D e2e_W iFi = 20 ms denotes the e2e round-trip propagation delay via the WiFi AP, and RT D e2e_sat = 580 ms represents the e2e round-trip propagation delay via satellite.Note that in Figure 2, after the receipt of the BU ACK, there is a time interval during which out-of-sequence TCP packets are received.Analogously, in Figure 3, we characterize the maximum t HO for the WiFi-to-satellite VHO scenario: where T antenna_repoint is a time needed to repoint the train antenna towards the satellite when the train leaves the tunnel.Note that in the above max {t HO }| W iFi−to−satellite time we do not consider any signalling exchange with the satellite prior VHO decision because we assume that the train continues to maintain an association with the satellite network even during the tunnel crossing time.
T HO_decision depends on PHY layer issues.The decision about transferring a connection from one link to another is made on the basis of Received Signal Strength (RSS), power degradation estimation, and Bit Error Rate (BER).Moreover, positioning information could also be used to decide about satellite-to-WiFi VHO due to the predictability of tunnel positions in the railway scenario.In particular, approaching the tunnel a VHO should be triggered at a certain distance d th from the AP, considering roughly a Signal-to-Noise Ratio (SNR) margin of 3 dB with respect to the WiFi receiver sensitivity.Hence, referring to the two-ray ground propagation model (path loss exponent is 4), we use the following formula: where d W iFi coverage denotes the WiFi AP maximum range.
The distance needed to take a decision about the VHO execution is The corresponding time considering the train speed is: (7) For instance, for a train moving in the North-South direction the LOS condition is lost at the satellite-to-WiFi VHO (χ = 1), while there are no LOS problems at the WiFi-to-satellite VHO (χ = 0).According to this case, we have plotted in Figure 4   = 200 m.We can note that the WiFi coverage extension before the tunnel increases with both the obstacle height and the latitude; while the WiFi coverage extension after the tunnel is constant since there are no LOS problems.

MIH-based VHO Protocols
We consider an MIH-enhanced VHO scheme where packets are transmitted through the new wireless segment soon after the BU message is received by the sender (the BU ACK is sent together with data traffic on the new path), according to a mobile-initiated forward VHO procedure.During the VHO procedure, data and signalling traffic can be exchanged via both WiFi and satellite links for a seamless transition ('soft' VHO).We propose here two different composite methods to improve TCP goodput in the presence of VHOs in the railway tunnel scenario; in both cases, we exploit cross-layer signalling supported by MIH and SI-SAP interface.
• VHO method #1: (i) Reordering approach for the satellite-to-WiFi VHO case; (ii) RTO update for the WiFi-to-satellite case.
• VHO method #2: (i) Cwnd limitation on the basis of the WiFi AP buffer size for the satellite-to-WiFi VHO; (ii) At the WiFi-to-satellite VHO, ssthresh is restored to the value assumed before the previous satellite-to-WiFi VHO 1 .Cwnd is then set to ssthresh.
In the above, the RTO adaptive method has been implemented by means of MIH signalling: the BU message of the VHO procedure is used to update the RTO value (L4) for the new network on the basis of the timestamp information included in the BU message.Moreover, the AP buffer size notification of the new wireless network reached by VHO can be communicated via the Association Response MIH message (L2) by means of a new header field.Then, this information is sent back to the sender in the BU message.Finally, as for the ssthresh update method envisaged above, a cross-layer signalling scheme is adopted: the BU message received at the sender triggers the setting of ssthresh to the value stored before leaving the satellite network.Alternatively, the ssthresh value could be updated by means of a bandwidth estimation for the new wireless segment triggered by the VHO procedure; the Adaptive START (ASTART) technique based on TCP Westwood bandwidth estimate could be used for this purpose [18].

Envisaged TCP Versions
In this paper, we focus on the performance of the following TCP versions: NewReno, Westwood+, Scalable-TCP (S-TCP), and Binary Increase Congestion control (BIC) [19].A modified version of BIC, named CUBIC is the default TCP congestion control version in present Linux releases.BIC however may achieve better fairness results towards standard TCP version than CUBIC, as highlighted in [20].
WiFi has a BDP value (and, hence, TCP cwnd values) much lower than those of the satellite network, considering here a WiFi air interface at 11 Mbit/s.Hence, when a WiFi-to-satellite VHO occurs, a certain time T is needed to fill the pipe.Let us now compare the T value for the TCP versions considered in this paper.The highest cwnd value achievable in the satellite network is equal to cwnd max, sat = BDP sat + Buf f er_Size sat ≈ 2BDP sat .So, after a WiFi-to-satellite VHO, a certain time interval is needed for cwnd to reach its maximum value again, according to the TCP congestion control algorithm.Let cwnd 0 denote the cwnd value soon after the completion of the WiFi-to-satellite VHO.Let N denote the maximum cwnd increase after the WiFi-to-satellite VHO: N = cwnd max, sat − cwnd 0 .As for TCP NewReno, soon after the WiFi-to-satellite VHO procedure, the cwnd growth time in the congestion avoidance phase is equal to: A similar result is valid for Westwood+ in our case.
The cwnd behavior with BIC is governed by parameters S min and S max values that permit to modify the cwnd behavior in different phases with logarithmic (binary search), exponential (max probing) and additive cwnd increases.We therefore study the cwnd growth time in the BIC case for each phase as follows.Supposing that no congestion event occurs, the BIC cwnd growth time is derived below assuming N >> cwnd max,wif i > S max , where cwnd max,wif i is the maximum cwnd value (= 45 packets) in the WiFi network.

EAI
• Additive Increase Phase (cwnd 0 < cwnd max,wif i ): cwnd has a linear increase of S max on RTT basis (satellite RTT after VHO execution).So the cwnd growth time up to cwnd max,wif i is equal to: • Binary Search Phase: when cwnd max,wif i is reached, the cwnd increase on RTT basis is as cwnd max,wif i + S max 2 , cwnd max,wif i + S max 4 , ..., cwnd max,wif i + S min .Therefore, this phase lasts n RTT, where n fulfills S max /2 n = S min : • Max Probing Phase (cwnd > cwnd max,wif i + S min ): if no congestion event occurs, cwnd increases according to an exponential law on RTT basis: 2S min , 4S min ,..., S max .Therefore, the cwnd growth time in this phase is equal to that of the binary search phase.
• Additive Increase Phase (cwnd max,wif i + S max < cwnd < N ): during this phase, cwnd increases of S max per RTT.Hence, the resulting growth time is: In conclusion, the overall BIC cwnd growth time is: It is convenient to have S max /S min = 2 k with k ≥ 4 for a fast cwnd increase.A high S max value allows improving scalability and a low S min improves TCP-friendliness.However, a too high S max could entail a too burst TCP traffic injection with consequent losses (congestion situation).Therefore, we have selected [19]: S min = 0.25 and S max = 32.S-TCP cwnd increases on RTT basis as cwnd, (1 + α)cwnd, (1 + α) 2 cwnd, ..., (1 + α) p cwnd.Hence, a cwnd increase of N is accomplished after the following time: Figure 5 compares the cwnd growth time at the exit of the tunnel when a WiFi-to-satellite VHO is performed.This graph also shows the cwnd growth time after a packet loss.We can note: (i) BIC cwnd has a much faster increase than S-TCP than NewReno; (ii) the impact of a WiFi-to-satellite VHO is more significant for TCP goodput than a packet loss.

Simulation Results and Comparisons
We have built an ns-2 simulator [21] for the scenario in Figure 1, considering trains that encounter tunnels along their trip.In this paper, we focus on FTP traffic flows ('elephant' TCP connections) 2 .Parameter values are set according to Table 1.We have selected the buffer size on the basis of the BDP value to fill the pipe (see also Figure 1).The tunnel length is 10.6 km that corresponds to a tunnel duration of about 120 s for a train speed of 320 km/h (in any case, we could consider here a generic tunnel length that is sufficiently long to create a link disruption in the absence of a local WiFi coverage).Our aim is to make a comparison among the considered TCP versions on the basis of different parameters, such as: cwnd behavior (micro-analysis), average TCP goodput (macro-analysis), Jain fairness index, cwnd convergence time at the WiFi-to-satellite VHO in the presence of multiple flows.
Cross-layer schemes #1 and #2 will be applied over NewReno to compare their performance with enhanced 2 With Web browsing traffic ('mice' TCP connections), a single browsing session could use more TCP connections to fetch and display a Web page.Starting from HTTP v1.1, the need for multiple TCP connections has been eliminated.In any case, multiple TCP connections of Web browsing traffic would experience synchronized losses (sharing the same buffers) and suffer from the presence of elephant connections.TCP versions.Due to the very reactive nature of accelerated TCP versions, we expect that combining these with the above cross-layer schemes would provide only marginal advantages so we that we have preferred to maintain separated the two different approaches.

EAI
In the figures from now on, the occurrence of the tunnel is indicated on the time axis referring to the satellite link down (entering the tunnel) and satellite link up (leaving the tunnel) events.
We have shown in Figure 6 the cwnd behaviors of NewReno, BIC, and the two cross-layer methods (applied over NewReno) proposed in this paper in the presence of VHOs between satellite and WiFi (single flow case) for the railway tunnel scenario.From the results shown in this curve we can state that BIC achieves the highest cwnd (goodput) values in all conditions and a very fast cwnd increase at the WiFito-satellite VHO (see also Figure 7).Note that all TCP versions reduce the cwnd value when a satellite-to-WiFi VHO is performed, but this change is due to the much reduced RTT value of the WiFi link with respect to the satellite one.This graph permits to see that both crosslayer methods #1 and #2 avoid RTO occurring at the satellite-to-WiFi VHO, but method #2 is more effective in recovering the goodput at the WiFi-to-satellite VHO, since it restores the ssthresh value and cwnd is restarted from the ssthresh value.
Figure 7 provides an enlarged view of the cwnd behavior at the WiFi-to-satellite VHO, thus better highlighting the very good performance of BIC and the good performance of NewReno with method #2.In this graph, we have also shown the results for S-TCP and Westwood+ that have been omitted in Figure 6 to distinguish better the curves.We can note that S-TCP achieves an intermediate performance between BIC and New-Reno-based version.Moreover, Westwood+ behavior is similar to the NewReno one.However, Westwood+ suffers from RTT changes at VHOs because it uses the minimum RTT to estimate the bandwidth and then ssthresh.After the second VHO, Westwood+ has a minimum RTT value constrained by that of the WiFi segment: the consequent low ssthresh value could cause a strong cwnd reduction in the presence of packet losses.In order to overcome this problem, the VHO should trigger a minimum RTT update according to a cross-layer scheme; otherwise, the minimum RTT could be taken over the last N ACKs or S seconds.
Figure 8 compares the TCP versions cwnd behaviors (single flow) in a case with random errors and Packet Error Rate (PER) of 10 −3 in the satellite segment.As expected, packet losses cause a significant cwnd reduction with respect to the values in Figure 6.We can note that BIC achieves the best performance.
Since on the basis of the previous simulation results the best solutions are BIC (accelerated TCP version) and NewReno with cross-layer method #2 we mainly concentrate on these schemes in what follows.
Figure 9 analyzes TCP-friendliness issues with two concurrent flows using BIC and NewReno with method #2 from two trains, so that only flow #1 encounters a tunnel in the time interval under investigation.From these results it is evident that BIC cwnd behavior is practically almost unaffected by the presence of the NewReno-based flow.Moreover, BIC exhibits friendliness problems with respect to NewReno: there is no convergence in the simulated time to a fair bandwidth share and NewReno also experiences many RTOs so that the ssthresh value is typically very low; these are unavoidable drawbacks using accelerated TCP versions.On the basis of this, the railway satellite network should use a PEP/gateway and (internally) an accelerated TCP version.As an alternative, traffic shapers/policers could also be used to enforce fairness among flows, as supported by SI-SAP.
Figure 10 shows the instantaneous goodput averaged over 10 repeated runs with different starting phases for two FTP flows (of the same type to investigate intra-protocol fairness) from the same server towards distinct trains, considering TCP NewReno with method #2 and BIC ( 3 ).In this study, we do not consider packet errors.Both flows share the satellite link where losses are due to buffer overflow and are, therefore, synchronized.Note that during the WiFi segment the aggregated goodput is higher than in the case of the satellite segment, because we have two flows exploiting separate bottleneck links (i.e., WiFi and satellite).These results permit to highlight the criticality of the 2nd (WiFi-to-satellite) VHO for the goodput behavior: a significant time, here called convergence time, is needed to reach a situation where both flows share (almost) equally the available satellite bandwidth (TCP intraprotocol fairness issue).As for NewReno [23], the (max) According to Figure 10, NewReno with method #2 has a convergence time of about 400 s (slightly better than NewReno, having convergence time ≈ 500 s), whereas BIC provides the best performance with a convergence time of 150 s. Figure 11 compares the (averaged) Jain's fairness index for different TCP versions and methods considered in this paper using the results in Figure 10 for a case with two flows (both using the same congestion control scheme) where only flow #1 experiences a tunnel in the simulation time.Fairness problems (due to the convergence time) may occur when the flow that has encountered a tunnel is again reconnected via satellite.We can note that BIC and NewReno with method #2 achieve good fairness results.

EAI
Finally, Figure 12 shows the instantaneous goodput averaged over 10 repeated runs with different starting phases for two flows on distinct trains with PER = 5 × 10 −4 on the satellite link.We have considered TCP NewReno with method #2 and BIC.BIC achieves both higher goodput and shorter convergence time after the 2nd VHO.

Conclusions
A HetNet approach has to be adopted to provide an uninterrupted Internet access to passengers on highspeed trains, by using seamless VHO procedures to switch the link from satellite (open area) to WiFi (tunnel) and back.Suitable VHO schemes have been defined on the basis of MIPv6, MIH, and BSM standards.The main outcomes of this paper can be summarized as follows: (i) Design of the WiFi coverage extension for an uninterrupted Internet access; (ii) Proposal of cross-layer methods based on ssthresh update to improve TCP performance at VHO; (iii) Tradeoff for the selection of the transport layer protocol taking into account: cwnd growth time, cwnd convergence time, TCP-friendliness, and RTT-fairness issues due to the occurrence of VHOs and the presence of flows on distinct trains.The main result of this work is that both BIC and NewReno with method #2 achieve promising TCP goodput and fairness performance in the presence of VHOs.BIC obtains the highest goodput, but suffers from friendliness problems if used in competition with TCP NewReno in an e2e configuration.
A further study is needed to consider: (i) Comparisons with the NASA Space Communications Protocol Specification -Transport Protocol (SCPS-TP) with two transport layer alternatives (VJ algorithm or Vegas one [24], possibly with segment-dependent choice of α and β parameters) and the Selective Negative Acknowledgment (SNACK) option [25], particularly useful at the satellite-to-WiFi VHO to manage out-ofsequence ACKs (large holes); (ii) A PEP for the satellite segment.

Method
Modifications Description Signaling Satellite-to-WiFi VHO impact WiFi-tosatellite VHO impact Cwnd control at VHO [15] Sender side TCP modification When the Binding Update message is received for a VHO procedure, the sender progressively closes the cwnd on the basis of ACK.In the new network, cwnd is reset to 1 and ssthresh is updated on the basis of a suitable bandwidth estimation for the new network.

Cross-layer signaling L2
and L4 Reduction of out-ofsequence packets It is possible to avoid some RTO occurrence, but cwnd has a slow increase in the satellite segment.
Reordering approach [16] Sender and receiver sides TCP modification This modification allows managing the arrival of out-of-sequence packets due to the VHO from a high RTT network (satellite) to a low RTT one (WiFi).Instead of DUPACKS, ACKs are sent during the interval for which out-of-sequence packets are received (i.e., "HO_mode" time interval), as detailed below.
Receiver side "HO_mode": a new header field is used in the ACK to describe the number N of outstanding packets still in the old network.When N reaches 0 the "HO_mode" is over.Sender side "HO_mode": a congestion avoidance phase is performed during the time interval that the receiver needs to acknowledge all the out-of-sequence packets.When an ACK with N = 0 is received, TCP returns to its standard behavior.

Figure 1 .
Figure 1.Reference satellite network architecture (forward and reverse channels are highlighted).

4 ICST
, we can formally express the maximum t HO for the satellite-to-WiFi VHO EAI European Alliance for Innovation Transactions on Ubiquitous Environments January-March 2012 | Volume 12 | Issue 1-3 | e5

5 ICST
the behavior of d W iFi outside ext (here intended exactly as χ × d 1 + d 2 , where we used max {t HO } to compute d 2 ) as a function of the obstacle height L for different latitude values and for the following parameter values: T synch = 50 ms, T antenna_repoint = 500 ms, RT D e2e_sat = 580 ms, RT D e2e_W iFi = 20 ms, v = 320 km/h, and d W iFi coverage EAI European Alliance for Innovation Transactions on Ubiquitous Environments January-March 2012 | Volume 12 | Issue 1-3 | e5

Figure 4 .
Figure 4. Design of the WiFi coverage extension outside the tunnel depending on the latitude and the obstacle height (case of the train moving in the North-South direction).

Figure 5 .
Figure 5.Comparison of cwnd growth times after a packet loss and after a WiFi-to-satellite VHO.

Figure 6 .
Figure 6.Comparison of cwnd behaviors with different TCP versions in the presence of satellite-to-WiFi VHO (405 s) and WiFi-to-satellite VHO (525 s); no random errors.

Figure 9 .
Figure 9. Cwnd behaviors for two concurrent flows on two trains using BIC and NewReno with method #2 (only flow #1 encounters a tunnel); no random errors.

Figure 10 . 2 ×
Figure 10.Mean goodput for two TCP flows on distinct trains (only flow #1 encounters a tunnel); no random errors.

Figure 11 .
Figure 11.Jain's fairness index for two TCP flows on distinct trains (only flow #1 encounters a tunnel); no random errors.

Table 1 .
Simulation parameters and settings.

Table 2 .
Survey of cross-layer techniques (derived from literature and here combined with the envisaged MIH signalling) to support TCP performance at VHO.