Mobile Internet access using satellite networks

INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS AND NETWORKING Int. J. Satell. Commun. Network. 2004; 22:587 610 Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/sat.779 Mobile Internet access using satellite networks P. Loreti 1,z, M. Luglio 1,n,y, R. Kapoor 2,}, J. Stepanek 2,}, M. Gerla k,2, F. Vatalaro 1,** and M. A. Vazquez-Castro 3,yy 1 Dipartimento di Ingegneria Elettronica, Universit "a di Roma Tor Vergata, Via di Tor Vergata 110, 00133 Rome, Italy 2 Computer Science Department, University of California Los Angeles, Boelter Hall, Los Angeles CA, 90095 U.S.A. 3 Dept. de Tecnolog!ıas de las Comunicaciones, Universidad Carlos III de Madrid, Avda. del la Universidad 30, 28911 Leganes, Madrid, Spain SUMMARY Satellites offer a promising alternative for mobile access to the Internet by both pedestrians, and more importantly, from vehicles. As such, satellites provide an essential complement to the cellular radio (UMTS) infrastructure in sparsely populated areas where high bandwidth UMTS cells cannot be economically deployed. In this paper, we analyse various mobile Internet applications in representative urban scenarios for two LEO constellations (one with polar orbits and the other with inclined orbits), as well as for some simple GEO configurations. To this end, we develop a satellite channel propagation model that includes shadowing from surrounding building skylines based on actual data in a built-up area. Using these tools, we analyse various Internet applications and the performance of various TCP schemes in different topologies. Copyright # 2004 John Wiley & Sons, Ltd. KEY WORDS: GEO; LEO; mobile satellite; TCP 1. INTRODUCTION Mobile access to the Internet is becoming extremely popular in part because users depend on the Internet for many of the activities that make up their daily routine (business, entertainment, education, family, etc.), and thus wish to extend connectivity to the times when they are away from their home or office. Nomadic Internet users are supported in their request for efficient, mobile access by a myriad of new networking technologies, from UMTS to Wireless LANs, Metricom and Bluetooth. One old technology, which may prove very effective for mobile Internet applications, is satellite technology. n Correspondence to: M. Luglio, Dipartimento di Ingegneria Elettronica, Universit"a di Roma Tor Vergata, Via di Tor Vergata 110, 00133 Rome, Italy. y E-mail: luglio@uniroma2.it z E-mail: loreti@ing.uniroma2.it } E-mail: rohitk@cs.ucla.edu } E-mail: stepanek@cs.ucla.edu k E-mail: gerla@cs.ucla.edu ** E-mail: vatalaro@ing.uniroma2.it yy E-mail: maryan@tsc.uc3m.es Copyright # 2004 John Wiley & Sons, Ltd. Received April 2002 Revised June 2002 Accepted November 2003

588 P. LORETI ET AL. Modern satellite systems are actually well prepared to take on the new mobile Internet challenge. Satellites are changing their role from the bent-pipe (transparent) channel paradigm to the on-board routing (regenerative) paradigm associated with packet transmission and switching. In this process, each satellite acts as an IP router, and new design problems arise both at the network and the transport layers. TCP represents the most critical building block towards supporting Internet applications and remains the widely accepted standard for reliable data transport throughout the Internet, both wired and wireless segments. Due to the increasing interest in both fixed and mobile interactive service delivery directly to the final user via satellite, many studies of TCP/IP focus on overcoming its limitations within the satellite medium, as well as on its efficient use in hybrid terrestrial/satellite networks. So far, TCP has been deeply studied with reference to the use of GEO satellites [1 10] and also for LEO constellations [11 16]. This is particularly significant in the frame of the universal mobile telecommunications system (UMTS) scenario that intends to merge the attributes of personal/mobile and multimedia communications on a worldwide scale [17]. The main goal of this paper is to evaluate the performance of various mobile Internet applications in representative LEO and GEO scenarios. We start with two LEO constellations offering us the opportunity to trade off different topology options, e.g. polar versus inclined orbits, diversity, presence of inter-satellite links, etc. Our purpose is to understand the impact of these various features and options on different applications in different environments. To this end, we develop a channel propagation model that includes shadowing from surrounding building skylines and terminal mobility. The model parameters are based on actual data in a built-up area. Using this model we first consider single satellite hop transmissions from mobile to satellite Gateway. For this scenario, we compute via simulation performances of FTP transfer and HTTP session (running on top of TCP) as perceived by mobile users traveling at varying speeds along urban canyons. We then consider a multihop satellite path between remote locations and evaluate the performance of delay sensitive applications (such as IP Telephony) for both constellations assuming connectivity between two terminals within the coverage area. Finally, we evaluate the performance of various TCP versions (Tahoe, Reno, SACK, Westwood [18 21]) in four different scenarios}single-hop and multihop (across the constellation) with a LEO configuration along with single- and double-hop GEO scenarios. The paper is organized as follows. Section 2 reviews the satellite system environment and highlights the characteristic likely to impact TCP and, more generally, Internet applications. Section 3 introduces the urban canyon model for the study of the satellite channel in urban environments. Section 4 presents the simulation platform (NS-2) used in our experiments and describes the extensions required for satellite experiment support. Section 5 presents the experimental results. Section 6 concludes the paper. 2. SATELLITE ENVIRONMENT AND TCP Next generation mobile communication systems aspire to offer an enhanced set of services comparable to those offered by fixed networks. They also extend the coverage of the secondgeneration systems by implementing an infrastructure in which the satellite segments integrate perfectly with terrestrial segments [17]. UMTS/IMT2000 (Universal Mobile Telecommunication

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 589 System/International Mobile Telecommunications 2000) will be the platform for new multimedia services. In this scenario, the satellite assumes a role of particular importance when aiming for real global coverage while ensuring access to maritime, aeronautical and remote users. 2.1. Satellite role in the evolution of the mobile Internet Satellite systems evolved from at first connecting different national networks to ultimately ensuring access directly to users. Current systems service both fixed users with small terminals (i.e. VSAT networks [22]) and mobile users for a restricted set of services (e.g. messaging, low data rate voice), and in some cases offer hand held terminals (e.g. Iridium [23] and Globalstar [24]). In all these cases, the satellite has been conceived as a stand-alone system. The next step consists of providing mobile multimedia services, enhancing performance and achieving data rates similar to those of third generation terrestrial mobile networks, using vehicular, palm top and possibly hand held terminals. Due to the enormous success achieved by Internet applications in the decade, there has been a great impetus in the designing of IP layer protocols and services, mainly for wired networks. Currently, the success of Internet applications moves toward mobile platforms, e.g. commerce, learning, games, preview of attractions, trading, messaging, web browsing, etc. In this scenario, satellites can play a very important role by extending coverage (of conventional cellular systems) and enhancing capacity. Because of this key complementary role, integration of satellites in the global IP network must be vigorously pursued. 2.2. Satellite features impacting Internet application performance In the new generation, each satellite operates as a switch}or possibly a node}of a larger satellite constellation network. As a full-fledged packet network, the constellation network will thus carry existing packet network protocols, e.g. routing, congestion control, QoS support, etc. First, when considering the performance of TCP as well as real-time (e.g. voice) applications one must account for the large propagation delays [1]. The problem is particularly acute in TCP applications over links with large bandwidth delay products, which requires a large TCP window for efficient use of the satellite link. A lossy satellite link can cause frequent Slow Start events where the window is scaled back to one segment}with significant impact on throughput. In fact, most TCP implementations temper this effect using the Fast Recovery algorithm, but Fast Recovery still impacts throughput by cutting the window in half. Large delays remain a problem for application relying upon UDP rather that TCP, e.g. real-time applications such as voice and video, but delays impact these applications in a different way. The delay problem may be further aggravated, in the case of LEO networks, by the fact that the delay varies as LEOs move along their orbits. The constellation paths thus may change during the life of a connection due to satellite and/or gateway handovers. In the following, we review the key satellite network features impacting Internet application performance. 2.2.1. Propagation delay. The transmission delay for a GEO topology depends solely on the user gateway distance (or user-to-user when allowing direct connections), or on the connection strategy when using ISLs. This delay remains relatively constant and changes only slightly due to small variations in the GEO orbit or due to significant roaming by mobile users.

590 P. LORETI ET AL. In the case of LEO orbits without ISLs, the delay variability amounts to a small jitter. In fact, the time varying geometry of the constellation induces a fast variability of the user satellite gateway distance for both fixed and mobile users. Usually, the delay variability remains below the granularity of software timers used by TCP and UDP-based applications and consequently has little effect upon these protocols; however, the delay variation phenomenon can magnify when ISLs are present since the routing strategy may also play a role [25]. More specifically, the delay variability relates to TCP s round trip time (RTT) estimate. Whenever a change in RTT occurs, it takes some time for TCP to adjust its estimate. If the RTT changes frequently and by large increments (as can happen in case of alternate routing in LEO constellations), TCP may not update its RTT estimate quickly enough. This may cause premature timeouts/ retransmissions, reducing the overall bandwidth efficiency. 2.2.2. Bandwidth-delay product (BDP). The large bandwidth delay products (BDP) often experienced in satellite links also influences the performance of TCP [2]. This dependence has been thoroughly analysed through extensive simulations and experimental studies [3 7]. 2.2.3. Frequent handover. In a connection-oriented service with LEOs, each time a handover occurs, a number of TCP packets may get lost, unless the gateways and/or satellites have negotiated careful co-ordination of signal handoff. Moreover, after the handover is complete, TCP may experience Slow Start events or enter congestion avoidance. If a mechanism existed allowing TCP to predict handoff, TCP could resume sending segments with a window value closer to the value before the handover. 2.2.4. Signal-to-noise ratio (SNR). Guaranteeing the required BER presents a critical challenge for satellite links; the great distance between the earth station and the satellite and the peculiarity of the propagation channel exacerbate the problem. At the physical layer, as well as at the MAC layer, several techniques can improve efficiency. In order to simplify our simulations scenarios the BER considered takes into account the improvement achieved at MAC and data link layers implementing suitable techniques. In case of GEO constellations, the SNR (or equivalently bit error rate, BER) is characterized by a great variability due to free space losses variation ð 1:3 dbþ and more significantly to tropospheric propagation (including rain for frequencies over 10 GHz) in the case of fixed communications and also due to shadowing in case of mobile communications. Both shadowing and deep rain fading can cause high packet loss for protracted intervals. In case the LEO systems, in addition to the previously mentioned phenomena, the BER variability results from the radio link dynamics induced by the continuously changing link geometry (antenna gain and free space losses). The high BER has a critical impact on TCP performance. TCP was originally designed for extremely low BER (of the order of 10 10 ; or less). Consequently, when a packet is lost, TCP attributes this loss to network congestion (limited buffer size in routers, packet collisions, etc.). The loss triggers TCP congestion control algorithms, which reduce the window and thus the throughput. This unnecessary reduction is particularly detrimental in satellite links, where the bandwidth delay product is high and TCP requires a large window to fully utilize the pipe. 2.2.5. Satellite diversity. As we shall see in the next section, satellite diversity provides a very efficient technique to combat shadowing and improve link availability or SNR by utilizing

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 591 multiple satellite links simultaneously or in turns with rapid handoff during a single session [26 28]. In a connectionless system, the satellite diversity feature offers the immediate advantage of increasing the probability of packet delivery to/from the satellite network from/to the Earth. A connection-oriented system presents the slight complication of delivering packets out of order and of an increased number of busy channels, especially if two or more channels (on different satellites) are dedicated to the connection. 2.2.6. Routing strategy. Routing strategy optimization is based on general network parameters, including the type of service, constellation topology, number of satellites, etc. In LEO constellations, where links can have different characteristics (bandwidth, propagation delay, loss rate, etc.), the conventional minimum-hop path optimization may not always be appropriate. Other link parameters may need to be taken into account when optimizing routes. 2.3. TCP enhancements for satellites networks Much of the research regarding TCP over satellite links focuses upon modification to the basic error control (EC) and flow control (FC) strategies to improve performance over satellite links. In Reference [5], the authors summarize a great deal of these research efforts in the context of satellites, some of which apply to non-satellite environments as well. From this document, a basic pattern of TCP research emerges in which some of the original design choices cause problems for satellite links. Briefly, problems arise as the original EC strategy for TCP assumes relatively low bandwidth-delay product (BDP) and a relatively short end-to-end feedback loop. On the other hand, the original FC strategy relies upon losses as an indication of congestion and includes conservative rate reductions in response to congestion. A more expansive exploration of these issues can be found in Reference [29]. Along these lines of research in TCP FC, at UCLA a modification to the fast recovery algorithm has been developed called TCP Westwood [21]. In TCP Westwood, the sender continuously monitors the effective rate of its connection from ACK interarrival times. The estimated rate may be lower than the current transmission rate because of packet loss in the bottleneck. The sender corrects this problem by adjusting its window so that the sending rate is equal to the monitored rate (thus, no loss). This scheme is a significant departure from other existing FC schemes since it uses estimated bandwidth (instead of packet loss) feedback [18]. This concept is important in satellite links where packet loss is not a reliable indication of path congestion. Most FC enhancement methods studied so far involve modifications to TCP software at source, destination or both. They remain transparent to the network as far as they do not require modifications in the software of routers. Some proposed schemes require router modifications. One example of this is the explicit congestion notification (ECN) scheme [30]. This provides TCP senders an alternative to divining congestion conditions from packet loss, and also benefits satellite channels in that it allows the TCP source to distinguish between loss caused by channel propagation effects (no ECN feedback) and loss caused by congestion (positive ECN feedback). However, since routers may also drop ECN packets, ECN may miss cases of heavy congestion. Consequently, ECN normally operates in conjunction with TCP congestion-control, i.e. not as its replacement. Moreover, the cost of modifying routers may prove quite significant since all the Internet Providers and router manufactures in the wired network need to comply with the router change in order to reap the benefit on a single satellite link. In contrast, a bandwidth estimation scheme like TCP Westwood requires just the single

592 P. LORETI ET AL. TCP source to implement the change. Finally, researchers have considered techniques implemented at lower layers (e.g. MAC or link level) to improve the quality of a wireless link as seen by TCP. An example is the IEEE 802.11 MAC protocol used in wireless LANs, which includes an ACK. This drastically reduces the number of non-congestion losses and thus eliminates the ambiguity between congestion loss and channel propagation loss. Note however that the link level ACK is not as straightforward to implement on a satellite broadcast link between a Gateway, say, and hundreds of mobile user terminals as it is on a point to point wireless LAN link. In this case, we either implement one link level protocol per user terminal, or we use a common link level protocol instance for all user terminals. In the former case, we quickly run into scalability problems. In the latter case, we suffer of fairness problems, in that the terminal, which is affected by a bad radio channel, slows everyone else down. TCP Peach [31, 32] proposes to replace Slow Start and Fast Recovery with Sudden Start and Rapid Recovery. To probe the characteristics of the network, both Sudden Start and Rapid Recovery use expandable Dummy packets, containing no data, sent with a low priority (in order not to be a source of congestion). These packets are not recovered when lost but, when acknowledged, the TCP sender increases the window. A further class of schemes relies upon the use of additional network services to solve the problem. In this case, intermediate boxes, or performance enhancing proxies (PEPs), provide additional services requiring additional infrastructure [33, 8]. Finally, some interesting techniques to enhance TCP performance by acting at the application layer have been proposed and tested [9, 10]. In summary, the design and development of new TCP applications on a LEO and GEO system motivates the careful assessment of various TCP enhancements in the specific context of the satellite constellation and application scenarios. Generic enhancements may introduce a counterproductive effect on performance. In a later section we evaluate different TCP schemes for representative LEO and GEO scenarios using a suitable channel model described in the following section. 3. LAND MOBILE SATELLITE CHANNEL MODEL It is well accepted that signal shadowing is the dominant critical issue influencing land mobile satellite (LMS) systems availability and performance. While multipath fading can be compensated through fade margins and advanced transmission techniques, blockage and shadowing effects can hardly be so mitigated, resulting in protracted high bit error rates and even temporary unavailability. Moreover, for low satellite elevations the fraction of shadowed areas is larger than that for high elevations. Given limitations on power, one way to reduce such shadowing effects is path or satellite diversity [26 28, 34]. To evaluate mobile Internet application performance in a real scenario we use a physicalstatistical land mobile satellite channel model. The model is based on computing the geometrical projection of buildings surrounding the mobile, described through their height and width statistical distributions [35, 36]. The existence or absence of the direct ray defines the line-ofsight (LOS) state or shadowed state, respectively. The modelling effort can be divided into two parts:

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 593 3.1. Deterministic or statistical parameterization of urban environment The physical-statistical approach used here proposes a canonical geometry for the environment traversed by a mobile receiver, typically a street as it is shown in Figure 1. The canyon street composed of buildings on both sides will block or not block the satellite link along the mobile route depending on the satellite elevation. In the case of deterministic characterization of the urban environment, a building data base (BDB) is used to obtain the canyon street data. Then, a receiver is placed at a given position (right or left lane or sidewalk) and the skyline (building profile in the sky direction) as seen by the receiver terminal is computed. For fixed users the skyline so computed will remain fixed and only the satellites will be moving according to the constellation dynamics. In the case of a user moving along a given street, the skyline seen by the mobile as well as the satellite positions will be time varying. It is worth noting that for satellite systems using Gateways (GW), the signal traverses two links, from mobile user to satellite and then from satellite to GW. Satellite to GW links can, however, be considered free of shadowing effects due to the environment since the GW antenna will be sufficiently elevated and directive and it will be tracking all satellites in view. In order to also address the statistical approach, enabling us to compute synthetic canyon streets, we investigated urban canyon street geometry and parameterized real street canyons. The statistical approach is of clear interest towards general results}provided that we use real data to generate the canyon streets. In addition, statistical approaches generally require less time and BDB are not always available. Figure 1. Shadowed and line-of-sight satellite links. Buildings can be obtained either from a BDB or through generating synthetic environment (h b : building height, h m : mobile height).

594 P. LORETI ET AL. Table I. Fitted distributions of building heights. Country Location General description Building heights England London Densely built-up district Log-normal m ¼ 17:6 m; s ¼ 0:31 m Guildford Medium-size town Log-normal m ¼ 7:2 m; s ¼ 0:26 m Spain Madrid (Castellana) Central business district Normal m ¼ 21:5 m; s ¼ 8:9 m Madrid (Chamber!ı) Residential area Normal m ¼ 12:6 m; s ¼ 3:8 m The heights of representative urban environments from two European countries were studied and statistically parameterized enabling the generation of realistic streets. High and medium built-up density areas from England and Spain were investigated. London and Guildford building heights were found to be log-normally distributed while three different sectors of Madrid were found to adhere to a truncated Normal distribution. These results are summarized in Table I. This procedure also allows comparisons between different degrees of build-up zones as well as eventual extrapolations to similar districts of other cities. 3.2. Calculation of the skyline elevation angles (masking angles) Once the canyon shaped street data are available, either by extracting it from BDBs or by computing it, the elevation angle to the skyline is computed. At every user position along the mobile route (mobile user) a scan of 3608 is performed to compute the elevation angle to the skyline, i.e. the elevation masking angle is computed for every azimuth angle around the user terminal. Figure 2 shows an example of the skyline surrounding the user. Buildings are synthetic and are generated with parameters corresponding to Madrid, Castellana. Figure 3 shows an example of computed masking angles for four streets in Madrid. To determine link conditions we use these computed elevation masking angles for different values of the azimuth angle under which the satellite is seen. If the satellite elevation angle is larger than the masking angle, the satellite is assumed to be in line-of-sight, otherwise it is blocked. The procedure is repeated for all satellites potentially in view. If more than one satellite is visible, the one with the highest elevation angle is chosen, and the packet is delivered to it. If no visible satellite is found, the packet is dropped. Our canyon street geometry includes modelling of crossroads by setting buildings to zero height. While this canyon shaped street model does not consider the eventual presence of second-row buildings, their effect will be considered negligible for the purposes of this paper. On the other hand, the time that the mobile terminal needs to move along a given canyon street may be too short (depending on the mobile speed) to obtain statistically significant TCP simulation times. In order to obtain significant simulation runs stretched canyon streets were generated to allow the simulation experiment to capture the effect of the statistical variation of heights and the occurrence of crossroads with the movement. Alternatively, longer routes are also easily and realistically obtained by changing the azimuth reference of the masking angle series.

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 595 Figure 2. Example (1000 samples) of skyline generated with parameters of Madrid Castellana. Figure 3. Masking angles computed for 4 streets of Madrid.

596 P. LORETI ET AL. 4. SIMULATION PLATFORM AND EXTENSIONS FOR SATELLITE SUPPORT The simulations have been performed using (Network Simulator) (ns-2) [37], enhanced to provide better support for satellite environments according to the following issues: (a) Terminal mobility and shadowing channel}a shadowing channel was added to simulate the behaviour of a terminal in an urban environment. The channel has an ON-OFF behaviour and the link is assumed to be down when the terminal is shadowed. Also, mobility was added to the terminal by moving it up and down the street. The skyline seen by the terminal changes as it moves and this combined with the current position of the satellite network determines the shadowing state of the terminal. (b) Gateway}The concept of a Gateway node was added to the simulator. The Gateway can be used as an interface between the satellite constellation and a terrestrial network and this feature can be used to model hybrid satellite-terrestrial networks. An important feature of the Gateway node is that it maintains links to all satellites that are visible to it. Also, these links typically belong to different orbits in a non-polar constellation. This multiple links property is used to enhance the inclined constellation to a full virtual constellation. Namely, connections between satellites in different orbits are set up through the Gateway node. (c) Mobility modelling and handoff}in the simulations, mobility is modelled by moving the terminal continuously up and down the street over a straight path of about 10 km: The considered terminal speeds are 0 m=s (fixed terminal), 2 m=s (pedestrian) and 20 m=s (vehicular). At any time, the speed of the node and the elapsed time of the simulation determine the position of the terminal. While modelling handoffs, we assume that the handoff execution time is negligible. The handoff procedure is invoked every 0:4 sanda handoff takes place when the current satellite is shadowed by the skyline or goes below the horizon. While performing the handoff, we look for the unshadowed satellite with the highest elevation angle. Note that the skyline gives us the minimum elevation angle above which a satellite is visible for a certain value of azimuth of the satellite. Thus, the azimuth of a satellite together with the information provided by the skyline determines whether a satellite is shadowed or not. 5. SIMULATION SCENARIOS Considering all the possible options of satellite configurations, service and application types, channel behaviour and protocol parameters, the number of possible scenarios becomes clearly unmanageable. Hence, we have selected a set of most representative scenarios for evaluation. The different option will be described in detail in the following subsections. Common input parameters for the simulations are TCP packet size ¼ 1000 bytes, and the bit rate ¼ 144 kbit=s (corresponding to the S-UMTS target bit rate [17]), unless otherwise indicated. 5.1. Satellite scenarios Our simulations were performed in two LEO and two GEO satellite scenarios: * single-hop LEO : a terminal is connected to the Gateway via one LEO satellite.

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 597 Table II. Features of LEO constellations. Orbits and geometry Inclined constellation Polar constellation Orbit class LEO LEO Altitude 1410 km 780 km Number of satellites 48 66 Number of planes 8 6 Inclination 528 86:48 Period (min) 114 100.1 Satellite visibility time (min) 16.4 11.1 Number of earth stations 100 210 15 20 Coverage within 708 latitude Global * full satellite network LEO : two terminals communicate using a LEO satellite constellation that provides connectivity between any two points on Earth laying within the coverage area. * single-hop GEO : a terminal is connected to the Gateway using one GEO satellite. * double GEO : a terminal is connected to the Gateways using two GEO satellites, themselves connected via an ISL. The former LEO scenario can be representative of a satellite network configuration not equipped with ISL or of a connection required in the service area of a single satellite. Thus, the user terminal and the Gateway see the same satellite. In our experiments, the user terminal is located in Madrid (408N and 48W) and the Gateway is located in France ð478n and 18W). The latter LEO scenario requires features such as routing on the satellite and requires satellites to be of the regenerative type. Moreover, such satellite constellations would typically be able to connect any points on the Earth without making use of the terrestrial network. For the purposes of this paper, we evaluated Iridium- and Globalstar-like LEO constellations. The former is an example of a polar constellation and the latter of a non-polar constellation. Table II gives some parameters associated with these two constellations. In the former GEO scenario, one user is located in Rome and the other in Washington D.C. Finally, the latter GEO scenario provides service using two GEO satellites connects via an ISL. In this case, one user resides in Rome and the other in Los Angeles. 5.2. Traffic models and applications We performed simulations of various services for the polar constellation, for the inclined constellation, and for GEO. We modelled different Internet services as explained below: (1) HTTP}HTPP 1.0 is modelled as per the models described in References [38, 39]. The former refers to a unit of HTTP transfer as a Session. A Session in our model consists of 5 pages, of 5 kbytes each (actually 50 packets of 1 kbyte each). The delay between the completion of one page transfer and the start of the next one is 40 s; this is referred to as the viewing time of a page. (2) Voice}Voice is modelled using the Brady model as given in Reference [40]. In this model, voice has an ON-OFF behaviour. The ON and OFF times are exponentially distributed with means of 1 and 1:35 s; respectively. During the ON time, a voice packet having a size

598 P. LORETI ET AL. of 20 bytes is sent every 0:02 s; giving an 8 kbit=s voice coding-rate. The duration of each voice connection is 2 min: (3) PING}PING is modelled as (constant bit rate) (CBR) traffic over UDP. One PING is sent every 1 s: The size of the PING packet is 20 bytes. (4) FTP}In the FTP model, files of fixed size are transferred in order to get delay statistics, while a fixed-duration FTP transfer is performed to get throughput results. 5.3. Channel options In our experiments, four different channel options were considered. 1. Perfect channel: neither shadowing nor packet error rate (PER) effects; this simple model is used to evaluate the impact of propagation delay on performance. 2. Constant PER but no shadowing impairments. Lossy terminal-to-satellite links were introduced in ns-2 to get performance for different TCP versions in real satellite scenarios. 3. Occurrence of shadowing impairments for fixed user according to the model described in Section 2. Four skylines, reported in Figure 3, have been used to simulate the urban environment surrounding the terminal. In particular, each street has a different average elevation masking-angle: 108 Leizaran, 308 Lerez, 408 Arga and 708 Narrow. 4. Occurrence of shadowing impairments for mobile user occurs according to the canyon street model described in Section 2. A street of Madrid presenting 308 of average elevation masking angle has been used (Figure 2). The street is about 10 km long and the width is 20 m: The terminal is located in the middle of the street and is moving up and down it. Note that in general, the use of a PER discriminates against smaller TCP acknowledgement packets. For this reason, the PER was not applied to TCP ACK packets for our simulations. To validate this approach, we have performed non-shadowed experiments using an equivalent Byte Error Rate and achieved comparable results. The simulations also assume a fixed channel capacity as achieved by TDMA/FDMA with fixed encoding. So the channel utilization of TCP was determined by calculating the percentage of this capacity achieved by TCP. Using a fixed channel without link-level acknowledgments likely increases the impact of shadowing upon upper layers. On the other hand, link-level acknowledgments might prove impractical due to the large propagation times and scaling or undesirable because applications sharing the channel may not all want to pay this price, e.g. voice and video. In any case, the interaction of a dynamic channel, whether due to link-level acknowledgements or adaptive encoding, with shadowing and the higher layers remains a topic for future investigation. 5.4. Evaluated parameters To evaluate the performance of satellite configurations using TCP, throughput and delay have been identified as the most meaningful parameters. 5.5. Simulation results for the single-hop LEO scenario 5.5.1. FTP}Shadowing effect and diversity benefits. In the first set of simulations, we transfer a very large file from gateway to mobile terminal using FTP over TCP Tahoe. We use the skylines from four streets in Madrid (Leizaran, Lerez, Arga and Narrow) as described in the previous

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 599 section. As the reader may have observed from the 3608 panoramic scans in Figure 3, those skylines ranged from minimally obstructed (Leizaran) to almost completely blocked (Narrow). Our goal in this experiment is to evaluate FTP performance in presence of intermittent blackout due to shadowing, and to assess the benefits of satellite diversity (when available). Clearly, the FTP goodput performance of a specific street is strongly dependent on its orientation with respect to the satellite orbits and thus would be completely biased towards one system constellation or another [7]. To remove this bias and to obtain results that are insensitive of orientation but instead indicative of skyline elevation profile, we evaluate TCP performance relative to various street orientations (108 apart) and then compute the average, which is reported in Figure 4. Presumably, this models the FTP performance perceived by a mobile traveling along a certain type of skyline. In a later section, we report performance of a mobile traveling on a specific street. In addition to the skyline simulations, as a term of reference, we simulated also an unshadowed scenario with no shadowing impairments, and with satellite elevations above the specified minimum elevation angles of 8:28 (polar) and 108 (non-polar). The results (not reported here) show identical goodputs (93%) for the two constellations. The 7% degradation is merely due to satellite delays. Figure 4 shows TCP Tahoe goodput results for both Iridium and Globalstar constellations for the four different skyline elevations, from 108 (Leizaran) to 708 (Narrow). The most remarkable finding is the dramatic drop in throughput of the polar case even for low elevations, while the non-polar constellation holds well up to 408 elevations. These results show the critical importance of satellite diversity. The inclined constellation, because of the orientation of its orbits, always has two or more satellites in view allowing diversity. The polar constellation, on the other hand, has strictly polar routes and thus much fewer diversity opportunities. 5.5.2. PING}No shadowing effect. In the second set of simulations, 40 000 PING packets were sent from the terminal to the Gateways, one PING every 1 s: One-way delays (from terminal to Gateway) were measured for both LEO constellations. The complementary cumulative delay Figure 4. TCP Tahoe bandwidth utilization with shadowing averaged over street orientation angles.

600 P. LORETI ET AL. Figure 5. PING complementary cumulative delay distribution for single-hop scenario. Table III. Bandwidth utilization for different TCP versions and satellite constellations in a single-hop scenario over constant PER channel link. Iridium Globalstar PER Tahoe Reno SACK Tahoe Reno SACK 10 4 0.895 0.893 0.892 0.892 0.890 0.890 10 3 0.892 0.890 0.892 0.888 0.887 0.888 10 2 0.858 0.864 0.878 0.853 0.859 0.875 10 1 0.341 0.334 0.357 0.327 0.334 0.347 distribution for the PINGs is shown in Figure 5. It is seen that the delays are very small (below 0:05 s). The delays for the polar constellation are slightly smaller due to the lower altitude of the satellites (see Table III). Figure 5 also shows that the variance in delays is very small for both constellations. 5.5.3. FTP}Constant PER and no shadowing effect. In the third set of simulations, we ran FTP (with unlimited data) over different TCP versions (Tahoe, Reno and SACK) for fixed time intervals to get results for the throughput. FTP connections with a 15-min duration were run every 30 min: We ran 24 such connections (representing 12 h of simulation time) and the throughput results were averaged over all connections. The channel has been assumed to have a constant packet error rate (PER) on the mobile terminal-to-satellite link. Table III shows the throughput achieved for different PERs for TCP Tahoe, Reno and SACK, respectively.

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 601 As seen from the graphs above, there is a very little difference among the throughputs achieved by TCP over the two constellations. Moreover, the throughputs achieved by different TCP versions are very similar. This behaviour can be easily explained by recalling that roundtrip delay is less than 100 ms (see Figure 5), channel rate is 144 kbit=s and packet size is 1 000 bytes. Under these conditions, the optimal TCP window (to keep the pipe full ) is two packets. The reader can verify that, by virtue of small window and small propagation delay, the well known advantages of the TCP enhanced versions Reno and SACK (which do not drop to Slow Start and perform fast, selective retransmissions) have absolutely no effect in this case. For this reason, we did not extend our investigation to other TCP versions such as TCP Westwood and TCP with ECN. The reader should be aware, however, that in future LEO satellite systems offering broadband services (say several Mbit/s to the mobile terminal) the choice of TCP protocol will make a difference. 5.5.4. FTP shadowed channel and mobile terminal. In the fourth set of simulations, we ran FTP (with fixed file size) over TCP Tahoe. The size of the file transferred during each FTP connection is 5 kbytes. We ran 1000 such FTP connections, one every 30 min and obtained a distribution for the delay associated with the file transfer. The mobile channel, as described in Section 2 and according to the parameters reported in Section 4.3, was used. Simulations were performed for terminal speeds of 0, 2 and 20 m=s: Figure 6 shows the complementary cumulative distribution for the two LEO constellations for various terminal speeds. We note that the delays associated with the inclined orbits are much lower than those of the polar orbits. This results from the path diversity of the inclined orbits. Namely, in that case the constellation characteristics allow the terminal to see more than one satellite at the same time. Figure 6. FTP transfer complementary cumulative delay distribution for various terminal speed in a single-hop scenario.

602 P. LORETI ET AL. With diversity, the terminal can link to another visible satellite when the current satellite becomes shadowed. Thus, diversity reduces the shadowing duration and the chance of a packet being lost due to shadowing. In the polar case, on the other hand, the terminal can normally see only one satellite and the shadowing duration is longer. Another property observed in Figure 6 is the fact that an increase in terminal velocity causes an increase in file transfer delays. This is due to the fact that a higher velocity increases the number of times that a terminal is shadowed, even though the shadowing durations are smaller. In each shadowing period, one or more packets get lost and thus, TCP reduces its window in response to the lost packet(s). We would like to remark that the handoff execution time has been assumed negligible. In practical cases, with significant handoff execution time, techniques based on constellation characteristics that suppress sending of TCP segments during handoff can be implemented to reduces the problem of in-flight packets. Moreover the network can re-route these packets to avoid losses. However, it is difficult to predict when handoffs will occur as a result of channel conditions. 5.5.5. HTTP with shadowed channel and mobile terminal. We also performed simulations for HTTP (version 1.0) transfer over TCP Tahoe for the inclined constellation to get a comparative analysis between the ideal channel and the mobile channel. We ran 1000 HTTP sessions (as described in Section 4.2), with the interval between two sessions being 20 min: Page Delay (associated with a single HTTP page) and Session Delay (associated with the transfer of all pages in a session) have been evaluated. The simulations were performed for a channel not affected by any PER but with a terminal speed of 2 m=s both in shadowed and unshadowed conditions. The page and session delay complementary cumulative distributions for HTTP transfers are shown in Figures 7 and 8, respectively. In both figures, the curve relative to the unshadowed case performs like a unit step}highlighting the occurrence of a constant delay. Figure 7 shows that the delay variance for retrieving one page is extremely large. However, from Figure 7. HTTP page delay transfer complementary cumulative distribution.

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 603 Figure 8. HTTP session delay transfer complementary cumulative distribution. Figure 8, we note that the variance of the HTTP session delay is much smaller, and indeed manageable. In essence, the pedestrian user inspects the page (for up to 40 s) and is unaware of the shadowing, until he requests the next page. The shadowing dead-times are utilized for local inspection of the pages. 5.6. Simulation results for full satellite LEO networks In the full satellite network, we consider Iridium- and Globalstar-like constellations, which have suitably evolved to provide connectivity between two terminals in their coverage area without relying on the terrestrial network. Each satellite in the Iridium-like constellation has four inter-satellite links, i.e. two inter-plane links connecting the previous and the next satellites in the same orbit and two intra-plane links connecting the corresponding satellite in the adjacent orbits. Also, in a polar constellation like Iridium, there are two regions in which the planes are counter-rotating, thus forming a seam in the topology. We consider the Iridium-like constellation both with and without cross-seam links. Without cross-seam links, some satellites have only one inter-plane link. In the enhanced Globalstar-like constellation, intra-plane links are introduced connecting each satellite to the previous and next satellites in the same orbit. In addition, a number of Gateways are introduced to provide inter-plane connectivity. The Gateways can see satellites of more than one orbit and will forward packets coming from one orbit to some other, if required. There are 14 such Gateways placed at various positions on the Earth as shown in Table IV. The routing used for the networks was of the shortest path kind. 5.6.1. PING}No shadowing effects and random terminal separation. In the first set of simulations, PING packets were transferred between two terminals located at random positions on the earth inside the coverage area of the constellations. 25 000 PING packets were sent

604 P. LORETI ET AL. Table IV. LEO incline constellation gateway location for full satellite network simulations. Region Gateway latitude Gateway longitude Europe 47:08N 1:08E 42:08N 13:08E 52:08N 45:08 E North America 45:08N 75:08W 30:08N 95:08W 20:08N 70:08W South America 5:08 S 95:08W 30:08S 65:08W 8:08S 40:08W South Africa 28:08S 20:08E Middle East 25:08N 45:08E Asia 52:08N 80:08E 43:08N 125:08E Australia 18:08S 138:08E according to the PING model explained in Section 4.2. The latitude and longitude of the terminals were selected using uniform random distributions; latitude varied between 1808 and 1808 and longitude varied between 908 and 908 for the polar constellation and between 708 and 708 for the non-polar constellation, according to their coverage areas. The simulations were performed for the Iridium-like constellation both with and without cross-seam links. Figures 9 11 show the PING delays versus terminal separation for the polar constellation without cross-seam links, the same with cross-seam links and the inclined constellation, respectively. From Figure 9, it is seen that the delays have some dependence on the terminal separation, i.e. the delays generally increase with increasing terminal separation. We also anticipate larger delays for small terminal separation due to points that may be located close to each other but either across the seam or near the polar regions, where inter-plane links are disabled. Figure 9 brings out this fact. Figure 10 shows that the delays are lower when cross-seam links are enabled. We also have the same behaviour as in Figure 10, for points close to each other but near the polar-regions. In the case of the non-polar constellation, as shown in Figure 11, the delays are significantly higher. Since packets may have to be routed through Gateway(s) in the case of inclined orbits, the distance traversed by packets tends to be longer, which causes larger delays. 5.6.2. VOICE}No shadowing effects. In the second set of simulations, we simulated voice connections between two points located at Rome (428N and 128E) and Los Angeles (338N and 1188W). The voice connections were modelled according to the Voice model described in Section 4.2. The number of voice connections is 1000, with the duration of each voice connection being 2 min: A new voice connection is started every 15 min: The simulations were performed for an Iridium-like constellation with and without cross-seam links and for a Globalstar-like constellation; a perfect channel ðper ¼ 0Þ was assumed. The complementary cumulative delay distributions of the Voice Packet delays are shown in Figure 12. Delays are significantly larger with the inclined orbits than with the polar orbits, consistent with the results found in

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 605 Figure 9. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions for the polar constellation without cross-seam links. Figure 10. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions for the polar constellation with cross-seam links. Section 4.5.1 (PING experiments). Yet, even the non-polar constellation delays are within acceptable thresholds for voice over IP. As for the polar constellation, we note that the presence of cross-seams improves only marginally the delay of voice packets.

606 P. LORETI ET AL. Figure 11. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions for inclined-enhanced constellation. Figure 12. VOICE packets delay complementary cumulative distribution. 5.6.3. FTP}Constant PER and no shadowing effect. In the last set of experiments, we ran FTP (with unlimited data) over different TCP versions (Tahoe and SACK) between a Gateway located in Rome (428N and 128E) and a terminal in Los Angeles (338N and 1188W). Figure 13

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 607 Figure 13. Bandwidth utilization vs throughput for TCP Tahoe and SACK and in different satellite constellation. shows the throughput achieved vs the PER (only for the terminal-to-satellite link) using the polar constellation without cross-seam links and the non-polar constellation with inclined orbits. FTP connections with a 15-min duration were run every 30 min: We ran 24 such connections (representing 12 h of simulation time) and averaged the throughput results over all connections. As seen from Figure 13, the polar constellation has a higher throughput due to lower delays. We also note that TCP-SACK performs better than Tahoe for 10 2 PER. It is interesting to compare the constellation (multihop) results with the corresponding single-hop results in Table IV. For 10 1 PER, the single-hop channel utilization is 0.87 for SACK and 0.86 for Tahoe, that is, virtually identical. We attributed this to the small bandwidth propagation product. In the multihop case (polar orbits without ISLs), the propagation increases substantially, up to 0:25 s: Thus, the optimal window is in the order of 10 packets. TCP SACK in this scenario can make a difference. In fact, it improves TCP Tahoe performance from 0.74 to 0.83 in case of the polar constellation. 5.7. Simulation results for the GEO scenarios As stated in Section 4.1, two GEO simulation scenarios were considered for comparison. The first scenario connects a user in Rome with a user in Washington D.C. using a single-hop GEO configuration. In this case we use Channel 4, that is, both shadowing and mobility in the urban environment with and average mask of 308 and a mobility of 5 m=s: The second scenario connects a user in Rome with a user in Los Angeles using a double-hop GEO configuration. This scenario includes two GEO satellites connected via an ISL. In this case, Channel 2 was used, that is, fixed PER without shadowing or mobility. In both scenarios, we measured FTP performance using a set of six half-hour FTP transfers.

608 P. LORETI ET AL. Figures 14 and 15 display TCP throughput normalized by the capacity of the satellite link. They show the fraction of bandwidth actually utilized by the link having a certain capacity. Figure 14 shows the TCP performance of FTP as a function of latitude and PER for the single-hop GEO configuration. Likewise, Figure 15 shows TCP performance as a function of PER for the double-hop scenario. These results indicate that for long delay GEO links, TCP Figure 14. Performance of FTP as a function of latitude and PER for GEO configuration in shadowed environment. Figure 15. Performance of FTP as a function of capacity and PER for double GEO (with ISL) configuration.

MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 609 Westwood outperforms TCP Reno and SACK in the presence of random errors and/or shadowing. The faster-recovery algorithm used by TCP Westwood facilitates quick recovery from packet errors. In addition, the performance of the different capacity links are intended as a fraction of the link capacity and the better performance of the 1 Mbit=s link with respect to the 2 Mbit=s link are due to the longer time the latter link takes to recover the optimum window after a packet loss implementing the slow start algorithm. 6. CONCLUSION This paper presents a performance evaluation of various mobile Internet applications in representative satellite configurations: LEO polar, LEO inclined and GEO. This process considered various traffic scenarios and satellite channel propagation models that include shadowing. For the single satellite hop scenario we compute the throughput delivered by FTP (a delay insensitive application) when delivering to mobile users traveling along urban canyons. The results show that building shadowing strongly affects throughput performance. The inclined constellation, allowing diversity, offers distinct advantages over the polar orbit layout. We then consider a multihop satellite path between remote locations and evaluate the performance of delay sensitive applications (IP telephony and HTTP) for both constellations. In this case, the polar constellation with its ISLs outperforms the inclined. The latter has no ISLs and must hop between satellites and gateways, paying a heavy delay toll. Finally, we address the performance of TCP in the satellite environment with lossy links (as caused by weather conditions, say). In principle, the satellite environment should benefit from enhanced TCP versions such as TCP SACK, TCP ECN etc. In reality, over the single-hop LEO all schemes do well since the bandwidth delay product remains quite low. On the other hand, in multihop paths across the constellation or especially for high-delay GEO links, TCP SACK and TCP Westwood eventually prevail as a result of longer path delays and larger windows. REFERENCES 1. INTELSAT Internet Technical Handbook, 20 April 1998. 2. Partridge C, Shepard TJ. TCP/IP Performance over Satellite Links. IEEE Network, September October 1997; 44 49. 3. Allman M, Glover D, Sanchez L. Enhancing TCP over Satellite Channels using Standard Mechanism. RFC 2488, January 1999. 4. Allman M, Hayes C, Kruse H, Osterman S. TCP Performance over Satellite Links. 5th International Conference on Telecommunication Systems Modelling and Design, 1997; 1 13. 5. Allman M. (ed.), Ongoing TCP Research Related to Satellites. RFC 2760, February 2000. 6. Allman M, Floyd S, Partridge C. Increasing TCP s initial window. IETF Internet Draft: draft-ietf-tsvwg-initwin- 00.txt, May 2001. 7. Marchese M. TCP modifications over satellite channels: study and performance evaluation. International Journal of Satellite Communications 2001; 19:93 110. 8. Bharadwaj1 V, Baras J, Butts N. An architecture for Internet service via broadband satellite networks. International Journal of Satellite Communications 2001; 19:29 50. 9. Kruse H, Allman M, Griner J, Tran D. Experimentation and modelling of HTTP over satellite channels. International Journal of Satellite Communications 2001; 19:51 68. 10. Allman M, Kruse H, Osterman S. An application level solution to TCP s satellite inefficiencies. Proceedings of the International Workshop on Satellite-Based Information Services, November 1996. 11. Gerla M, Luglio M, Kapoor R, Stepanek J, Vatalaro F, V"azquez-Castro MA. TCP via Satellite Constellations. Fourth European Workshop on Mobile/Personal Satcoms (EMPS 2000), London, September 2000.

610 P. LORETI ET AL. 12. Loreti P, Luglio M, Kapoor R, Stepanek J, Gerla M, Vatalaro F, Vazquez-Castro MA. Throughput and Delay Performance of Mobile Internet Applications Using LEO Satellite Access. International Symposium on 3G Infrastructure and Services, Athens, GR, 2 3 July 2001; 68 73. 13. Gerla M, Kapoor R, Stepanek J, Loreti P, Luglio M, Vatalaro F, Vazquez-Castro MA. Satellite Systems Performance with TCP-IP Applications. Tyrrhenian International Workshop on Digital Communications. IWDC 2001; Taormina, Italy; September 17 20, 2001; 76 90. 14. Loreti P, Luglio M, Kapoor R, Stepanek J, Gerla M, Vatalaro F, Vazquez-Castro MA. LEO Satellite Systems Performance with TCP-IP applications. Proceedings of Milcom 2001, Tysons Corner, McLean, VA, USA, October 28 31, 2001, session U24. 15. Tonguz OK, Maloo S, Xhafa A, Sheeshia S. Internet Access via LEO Satellite Networks: TCP/IP or ATM? Globecom 99, Rio de Janeiro, Brazil, 5 9 December 1999; 301 305. 16. Maloo S. TCP/IP Issues and Performance over LEO Satellite Networks. International Conference on Telecommunications, Acapulco, Mexico 22 25 May 2000, 369 373. 17. O Mahony D. UMTS: the fusion of fixed and mobile networking. IEEE Internet Computing 1998; 21:49 56. 18. Jacobson V. Congestion Avoidance and Control. Proceedings of SIGCOMM 88, ACM, 1988. 19. Stevens W. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001, January 1997. 20. Mathis M, Mahdavi J, Floyd S, Romanow A. TCP Selective Acknowledgment Options. RFC 2018, October 1996. 21. Casetti C, Gerla M, Mascolo S, Sanadidi MY, Wang R. TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links. Proceedings of ACM Mobicom 2001, pp. 287 297, Rome, Italy, July 16 21 2001. 22. Abramson N. VSAT data networks. Proceedings of the IEEE 1990; 78:1267 1274. 23. Leopold RJ. Low-Earth Orbit Global Cellular Communications Network. Mobile Satellite Communication Conference, Adelaide, Australia, 23 August 1990. 24. Wiedeman RA, Viterbi AJ. The Globalstar Mobile Satellite System for worldwide Personal Communications. Proceedings of 3rd International Mobile Satellite Conference (IMSC 93), June 1993; 285 290. 25. Papapetrou E, Pavlidou N. Various Routing Techniques for non-geo Satellite Constellations. International Conference on Telecommunications, Acapulco, Mexico 22 25 May, 2000; 329 333. 26. De Gaudenzi R, Giannetti F. DS-CDMA satellite diversity reception for personal satellite communication: satellite-to-mobile link performance analysis. IEEE Transactions on Vehicular Technology 1998; 47(2): 658 672. 27. Corazza GE, Caini C. Satellite Diversity Exploitation in Mobile Satellite CDMA Systems. IEEE Wireless Communications and Networking Conference, New Orleans, LA, September 1999. 28. Loreti P, Luglio M. Satellite Diversity: a Technique to Improve Link Performance and Availability for Multicoverage Constellations. In 3rd Generation Mobile Communication Systems, UMTS and IMT-2000, P. Stavroulakis (ed.), Springer: Berlin, 2001. 29. Hoe J. Improving the startup behavior of a congestion control scheme for TCP. ACM SIGCOMM, August 1996. 30. Ramakrishnan K, Floyd S. A Proposal to add Explicit Congestion Notification (ECN) to IP. RFC 2481, January 1999. 31. Akyildiz IF, Morabito G, Palazzo S. TCP-Peach: a new congestion control scheme for satellite IP networks. IEEE/ ACM Transactions on Networking 2001; 9(3):307 321. 32. Akyildiz IF, Morabito G, Palazzo S. TCP-Peach for satellite networks: analytical model and performance evaluation. International Journal of Satellite Communications 2001; 19:429 442. 33. Border J, Kojo M, Griner J, Montenegro G, Shelby Z. Performance Enhancing Proxies intended to mitigate linkrelated degradations. RFC 3135, June 2001. 34. Mazzenga F, De Angelis F, Vatalaro F. A physical-statistical channel modeling for mobile satellite communications with diversity. Fourth European Workshop on Mobile/Personal Satcoms (EMPS 2000), London, September 2000. 35. V!azquez-Castro M, Tzaras C, Saunders S, P!erez-Font!an F. Shadowing Correlation for Mobile Satellite Diversity. Joint COST 252-255 Meeting, Tolouse, May 8 10, 1999. 36. V!azquez-Castro MA, Saunders S, Tzaras C, P!erez-Font!an F. Shadowing Correlation for Mobile Satellite Diversity. AP2000 Millennium Conference on Antennas & Propagation, April 2000. 37. Henderson R, Katz RH. Network simulation for LEO satellite networks. Collection of Technical Papers of 18th AIAA International Communications Satellite Systems Conference and Exhibit, vol. 2, Oakland, CA, 10 14, April 2000. 38. Choi H-K, Limb JO. A behavioral model of web traffic. Proceedings of Seventh International Conference on Network Protocols, 1999 (ICNP 99), 1999; 327 334. 39. Leung KY, Yeung KH. The design and implementation of a WWW traffic generator. Proceedings of Seventh International Conference on Parallel and Distributed Systems 2000, 2000; 509 514. 40. Brady PT. A model for generating on-off speech patterns in two-way conversation. Bell System Technical Journal, September 1969; 48:2445 2471.