Mobile internet access using satellite networks -...

INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS AND NETWORKINGInt. 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. Loreti1,z, M. Luglio1,n,y, R. Kapoor2,}, J. Stepanek2,}, M. Gerlak,2, F. Vatalaro1,**

and M. A. Vazquez-Castro3,yy

1Dipartimento di Ingegneria Elettronica, Universit "aa di Roma Tor Vergata, Via di Tor Vergata 110, 00133 Rome, Italy2Computer Science Department, University of California Los Angeles, Boelter Hall, Los Angeles CA, 90095 U.S.A.

3Dept. 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 moreimportantly, 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 beeconomically deployed. In this paper, we analyse various mobile Internet applications in representativeurban scenarios for two LEO constellations (one with polar orbits and the other with inclined orbits), aswell as for some simple GEO configurations. To this end, we develop a satellite channel propagation modelthat 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 theInternet 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 awayfrom 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 mobileInternet applications, is satellite technology.

Received April 2002Revised June 2002

Accepted November 2003Copyright # 2004 John Wiley & Sons, Ltd.

yE-mail: [email protected]: [email protected]

nCorrespondence to: M. Luglio, Dipartimento di Ingegneria Elettronica, Universit"aa di Roma Tor Vergata, Via di TorVergata 110, 00133 Rome, Italy.

}E-mail: [email protected]}E-mail: [email protected]: [email protected]**E-mail: [email protected]: [email protected]

Modern satellite systems are actually well prepared to take on the new mobile Internetchallenge. Satellites are changing their role from the ‘bent-pipe’ (transparent) channel paradigmto the on-board routing (regenerative) paradigm associated with packet transmission andswitching. In this process, each satellite acts as an IP router, and new design problems arise bothat the network and the transport layers.

TCP represents the most critical building block towards supporting Internet applications andremains the widely accepted standard for reliable data transport throughout the Internet, bothwired and wireless segments. Due to the increasing interest in both fixed and mobile interactiveservice delivery directly to the final user via satellite, many studies of TCP/IP focus onovercoming its limitations within the satellite medium, as well as on its efficient use in hybridterrestrial/satellite networks. So far, TCP has been deeply studied with reference to the use ofGEO satellites [1–10] and also for LEO constellations [11–16]. This is particularly significant inthe frame of the universal mobile telecommunications system (UMTS) scenario that intends tomerge the attributes of personal/mobile and multimedia communications on a worldwidescale [17].

The main goal of this paper is to evaluate the performance of various mobile Internetapplications in representative LEO and GEO scenarios. We start with two LEO constellationsoffering us the opportunity to trade off different topology options, e.g. polar versus inclinedorbits, diversity, presence of inter-satellite links, etc. Our purpose is to understand the impact ofthese various features and options on different applications in different environments. To thisend, we develop a channel propagation model that includes shadowing from surroundingbuilding skylines and terminal mobility. The model parameters are based on actual data in abuilt-up area.

Using this model we first consider ‘single satellite hop’ transmissions from mobile to satelliteGateway. 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 varyingspeeds along ‘urban canyons’. We then consider a multihop satellite path between remotelocations 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 theconstellation) 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 andhighlights 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 urbanenvironments. Section 4 presents the simulation platform (NS-2) used in our experiments anddescribes the extensions required for satellite experiment support. Section 5 presents theexperimental results. Section 6 concludes the paper.

2. SATELLITE ENVIRONMENT AND TCP

Next generation mobile communication systems aspire to offer an enhanced set of servicescomparable to those offered by fixed networks. They also extend the coverage of the second-generation systems by implementing an infrastructure in which the satellite segments integrateperfectly with terrestrial segments [17]. UMTS/IMT2000 (Universal Mobile Telecommunication

Copyright # 2004 John Wiley & Sons, Ltd. Int. J. Satell. Commun. Network. 2004; 22:587–610

P. LORETI ET AL.588

System/International Mobile Telecommunications 2000) will be the platform for newmultimedia services. In this scenario, the satellite assumes a role of particular importancewhen aiming for real global coverage while ensuring access to maritime, aeronautical andremote users.

2.1. Satellite role in the evolution of the ‘mobile’ Internet

Satellite systems evolved from at first connecting different national networks to ultimatelyensuring 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, lowdata 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 andachieving data rates similar to those of third generation terrestrial mobile networks, usingvehicular, palm top and possibly hand held terminals. Due to the enormous success achieved byInternet applications in the decade, there has been a great impetus in the designing of IP layerprotocols and services, mainly for wired networks. Currently, the success of Internetapplications moves toward mobile platforms, e.g. commerce, learning, games, preview ofattractions, trading, messaging, web browsing, etc. In this scenario, satellites can play a veryimportant 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 mustbe 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 largersatellite constellation network. As a full-fledged packet network, the constellation network willthus 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) applicationsone must account for the large propagation delays [1]. The problem is particularly acute in TCPapplications over links with large bandwidth� delay products, which requires a large TCPwindow 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, butFast Recovery still impacts throughput by cutting the window in half. Large delays remain aproblem for application relying upon UDP rather that TCP, e.g. real-time applications such asvoice and video, but delays impact these applications in a different way. The delay problem maybe further aggravated, in the case of LEO networks, by the fact that the delay varies as LEOsmove along their orbits. The constellation paths thus may change during the life of a connectiondue to satellite and/or gateway handovers. In the following, we review the key satellite networkfeatures impacting Internet application performance.

2.2.1. Propagation delay. The transmission delay for a GEO topology depends solely on theuser–gateway distance (or user-to-user when allowing direct connections), or on the connectionstrategy when using ISLs. This delay remains relatively constant and changes only slightly dueto small variations in the GEO orbit or due to significant roaming by mobile users.


MOBILE INTERNET ACCESS USING SATELLITE NETWORKS 589

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 belowthe granularity of software timers used by TCP and UDP-based applications and consequentlyhas little effect upon these protocols; however, the delay variation phenomenon can magnifywhen ISLs are present since the routing strategy may also play a role [25]. More specifically, thedelay variability relates to TCP’s round trip time (RTT) estimate. Whenever a change in RTToccurs, it takes some time for TCP to adjust its estimate. If the RTT changes frequently and bylarge increments (as can happen in case of alternate routing in LEO constellations), TCP maynot 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) oftenexperienced in satellite links also influences the performance of TCP [2]. This dependence hasbeen 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 handoveroccurs, a number of TCP packets may get lost, unless the gateways and/or satellites havenegotiated 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 existedallowing TCP to predict handoff, TCP could resume sending segments with a window valuecloser to the value before the handover.

2.2.4. Signal-to-noise ratio (SNR). Guaranteeing the required BER presents a critical challengefor satellite links; the great distance between the earth station and the satellite and thepeculiarity of the propagation channel exacerbate the problem. At the physical layer, as well asat the MAC layer, several techniques can improve efficiency. In order to simplify oursimulations scenarios the BER considered takes into account the improvement achieved atMAC and data link layers implementing suitable techniques.

In case of GEO constellations, the SNR (or equivalently bit error rate, BER) is characterizedby a great variability due to free space losses variation ð� 1:3 dBÞ and more significantly totropospheric propagation (including rain for frequencies over 10 GHz) in the case of fixedcommunications and also due to shadowing in case of mobile communications. Both shadowingand deep rain fading can cause high packet loss for protracted intervals.

In case the LEO systems, in addition to the previously mentioned phenomena, the BERvariability results from the radio link dynamics induced by the continuously changing linkgeometry (antenna gain and free space losses).

The high BER has a critical impact on TCP performance. TCP was originally designed forextremely low BER (of the order of 10�10; or less). Consequently, when a packet is lost, TCPattributes 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 thethroughput. This unnecessary reduction is particularly detrimental in satellite links, where thebandwidth� 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 veryefficient technique to combat shadowing and improve link availability or SNR by utilizing


P. LORETI ET AL.590

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 ofincreasing the probability of packet delivery to/from the satellite network from/to the Earth. Aconnection-oriented system presents the slight complication of delivering packets out of orderand of an increased number of busy channels, especially if two or more channels (on differentsatellites) 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 LEOconstellations, where links can have different characteristics (bandwidth, propagation delay, lossrate, 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 basicerror 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 ofsatellites, some of which apply to non-satellite environments as well. From this document, abasic pattern of TCP research emerges in which some of the original design choices causeproblems for satellite links. Briefly, problems arise as the original EC strategy for TCP assumesrelatively 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 andincludes conservative rate reductions in response to congestion. A more expansive explorationof these issues can be found in Reference [29].

Along these lines of research in TCP FC, at UCLA a modification to the fast recoveryalgorithm has been developed called TCP Westwood [21]. In TCP Westwood, the sendercontinuously monitors the effective rate of its connection from ACK interarrival times. Theestimated rate may be lower than the current transmission rate because of packet loss in thebottleneck. The sender corrects this problem by adjusting its window so that the sending rate isequal to the monitored rate (thus, no loss). This scheme is a significant departure from otherexisting 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 pathcongestion. Most FC enhancement methods studied so far involve modifications to TCPsoftware at source, destination or both. They remain transparent to the network as far as theydo not require modifications in the software of routers. Some proposed schemes require routermodifications. 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 losscaused 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 misscases of heavy congestion. Consequently, ECN normally operates in conjunction with TCPcongestion-control, i.e. not as its replacement. Moreover, the cost of modifying routers mayprove quite significant since all the Internet Providers and router manufactures in the wirednetwork need to comply with the router change in order to reap the benefit on a single satellitelink. In contrast, a bandwidth estimation scheme like TCP Westwood requires just the single



TCP source to implement the change. Finally, researchers have considered techniquesimplemented at lower layers (e.g. MAC or link level) to improve the quality of a wirelesslink as seen by TCP. An example is the IEEE 802.11 MAC protocol used in wirelessLANs, which includes an ACK. This drastically reduces the number of non-congestionlosses and thus eliminates the ambiguity between congestion loss and channel propagationloss. Note however that the link level ACK is not as straightforward to implement on asatellite broadcast link between a Gateway, say, and hundreds of mobile user terminals as it ison a point to point wireless LAN link. In this case, we either implement one link level protocolper user terminal, or we use a common link level protocol instance for all user terminals. In theformer case, we quickly run into scalability problems. In the latter case, we suffer of fairnessproblems, in that the terminal, which is affected by a bad radio channel, slows everyoneelse down.

TCP Peach [31, 32] proposes to replace Slow Start and Fast Recovery with Sudden Start andRapid Recovery. To probe the characteristics of the network, both Sudden Start and RapidRecovery use expandable ‘Dummy’ packets, containing no data, sent with a low priority (inorder not to be a source of congestion). These packets are not recovered when lost but, whenacknowledged, the TCP sender increases the window.

A further class of schemes relies upon the use of additional network services to solve theproblem. In this case, intermediate boxes, or performance enhancing proxies (PEPs), provideadditional services requiring additional infrastructure [33, 8].

Finally, some interesting techniques to enhance TCP performance by acting at the applicationlayer have been proposed and tested [9, 10].

In summary, the design and development of new TCP applications on a LEO and GEOsystem motivates the careful assessment of various ‘TCP enhancements’ in the specific context ofthe satellite constellation and application scenarios. Generic enhancements may introduce acounterproductive effect on performance. In a later section we evaluate different TCP schemesfor representative LEO and GEO scenarios using a suitable channel model described in thefollowing section.

3. LAND MOBILE SATELLITE CHANNEL MODEL

It is well accepted that signal shadowing is the dominant critical issue influencing land mobilesatellite (LMS) systems availability and performance.

While multipath fading can be compensated through fade margins and advanced transmissiontechniques, blockage and shadowing effects can hardly be so mitigated, resulting inprotracted high bit error rates and even temporary unavailability. Moreover, for lowsatellite 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 satellitediversity [26–28, 34].

To evaluate mobile Internet application performance in a real scenario we use a physical-statistical land mobile satellite channel model. The model is based on computing the geometricalprojection of buildings surrounding the mobile, described through their height and widthstatistical distributions [35, 36]. The existence or absence of the direct ray defines the line-of-sight (LOS) state or shadowed state, respectively. The modelling effort can be divided into twoparts:


P. LORETI ET AL.592

3.1. Deterministic or statistical parameterization of urban environment

The physical-statistical approach used here proposes a canonical geometry for the environmenttraversed by a mobile receiver, typically a street as it is shown in Figure 1. The canyon streetcomposed of buildings on both sides will block or not block the satellite link along the mobileroute 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 bythe receiver terminal is computed. For fixed users the skyline so computed will remain fixed andonly the satellites will be moving according to the constellation dynamics. In the case of a usermoving along a given street, the skyline seen by the mobile as well as the satellite positions willbe time varying. It is worth noting that for satellite systems using Gateways (GW), thesignal traverses two links, from mobile user to satellite and then from satellite to GW. Satelliteto GW links can, however, be considered free of shadowing effects due to the environment sincethe GW antenna will be sufficiently elevated and directive and it will be tracking all satellites inview.

In order to also address the statistical approach, enabling us to compute synthetic canyonstreets, 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 realdata to generate the canyon streets. In addition, statistical approaches generally require less timeand BDB are not always available.

Figure 1. Shadowed and line-of-sight satellite links. Buildings can be obtained either from a BDB orthrough generating synthetic environment (hb: building height, hm: mobile height).



The heights of representative urban environments from two European countries were studiedand statistically parameterized enabling the generation of realistic streets. High and mediumbuilt-up density areas from England and Spain were investigated. London and Guildfordbuilding heights were found to be log-normally distributed while three different sectors ofMadrid were found to adhere to a truncated Normal distribution. These results are summarizedin Table I. This procedure also allows comparisons between different degrees of build-up zonesas 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 bycomputing it, the elevation angle to the skyline is computed. At every user position along themobile route (mobile user) a scan of 3608 is performed to compute the elevation angle to theskyline, i.e. the elevation masking angle is computed for every azimuth angle around the userterminal. Figure 2 shows an example of the skyline surrounding the user. Buildings are syntheticand are generated with parameters corresponding to Madrid, Castellana. Figure 3 shows anexample of computed masking angles for four streets in Madrid.

To determine link conditions we use these computed elevation masking angles for differentvalues of the azimuth angle under which the satellite is seen. If the satellite elevation angle islarger than the masking angle, the satellite is assumed to be in line-of-sight, otherwise it isblocked. The procedure is repeated for all satellites potentially in view. If more than one satelliteis visible, the one with the highest elevation angle is chosen, and the packet is delivered to it. Ifno visible satellite is found, the packet is dropped.

Our canyon street geometry includes modelling of crossroads by setting buildings to zeroheight. While this canyon shaped street model does not consider the eventual presence ofsecond-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 canyonstreet may be too short (depending on the mobile speed) to obtain statistically significantTCP simulation times. In order to obtain significant simulation runs ‘stretched’ canyonstreets were generated to allow the simulation experiment to capture the effect of the statisticalvariation of heights and the occurrence of crossroads with the movement. Alternatively, longerroutes are also easily and realistically obtained by changing the azimuth reference of themasking angle series.

Table I. Fitted distributions of building heights.

Country Location General description Building heights

England London Densely built-up district Log-normalm ¼ 17:6 m; s ¼ 0:31 m

Guildford Medium-size town Log-normalm ¼ 7:2 m; s ¼ 0:26 m

Spain Madrid (Castellana) Central business district Normalm ¼ 21:5 m; s ¼ 8:9 m

Madrid (Chamber!ıı) Residential area Normalm ¼ 12:6 m; s ¼ 3:8 m


P. LORETI ET AL.594

Figure 2. Example (1000 samples) of skyline generated with parameters of Madrid–Castellana.

Figure 3. Masking angles computed for 4 streets of Madrid.



4. SIMULATION PLATFORM AND EXTENSIONS FOR SATELLITE SUPPORT

The simulations have been performed using (Network Simulator) (ns-2) [37], enhanced toprovide better support for satellite environments according to the following issues:

(a) Terminal mobility and shadowing channel}A shadowing channel was added to simulatethe behaviour of a terminal in an urban environment. The channel has an ON-OFFbehaviour 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 seenby the terminal changes as it moves and this combined with the current position of thesatellite network determines the shadowing state of the terminal.

(b) Gateway}The concept of a ‘Gateway’ node was added to the simulator. The Gatewaycan be used as an interface between the satellite constellation and a terrestrial networkand this feature can be used to model hybrid satellite-terrestrial networks. An importantfeature 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 virtualconstellation’. Namely, connections between satellites in different orbits are set upthrough the Gateway node.

(c) Mobility modelling and handoff}In the simulations, mobility is modelled by moving theterminal continuously up and down the street over a straight path of about 10 km: Theconsidered 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 simulationdetermine the position of the terminal. While modelling handoffs, we assume that thehandoff execution time is negligible. The handoff procedure is invoked every 0:4 s and ahandoff takes place when the current satellite is shadowed by the skyline or goes belowthe horizon. While performing the handoff, we look for the ‘unshadowed’ satellite withthe highest elevation angle. Note that the skyline gives us the minimum elevation angleabove which a satellite is visible for a certain value of azimuth of the satellite. Thus, theazimuth of a satellite together with the information provided by the skyline determineswhether 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 clearlyunmanageable. 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 inputparameters 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.


P. LORETI ET AL.596

* ‘full satellite network LEO’: two terminals communicate using a LEO satelliteconstellation that provides connectivity between any two points on Earth laying withinthe 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 notequipped with ISL or of a connection required in the service area of a single satellite. Thus, theuser terminal and the Gateway see the same satellite. In our experiments, the user terminal islocated in Madrid (408N and 48W) and the Gateway is located in France ð478N and 18W). Thelatter LEO scenario requires features such as routing on the satellite and requires satellites to beof the regenerative type. Moreover, such satellite constellations would typically be able toconnect any points on the Earth without making use of the terrestrial network. For the purposesof this paper, we evaluated Iridium- and Globalstar-like LEO constellations. The former is anexample of a polar constellation and the latter of a non-polar constellation. Table II gives someparameters 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 inclinedconstellation, 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]. Theformer refers to a unit of HTTP transfer as a Session. A Session in our model consists of 5pages, of 5 kbytes each (actually 50 packets of 1 kbyte each). The delay between thecompletion 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 distributedwith means of 1 and 1:35 s; respectively. During the ON time, a voice packet having a size

Table II. Features of LEO constellations.

Orbits and geometry Inclined constellation Polar constellation

Orbit class LEO LEOAltitude 1410 km 780 kmNumber of satellites 48 66Number of planes 8 6Inclination 528 86:48Period (min) 114 100.1Satellite visibility time (min) 16.4 11.1Number of earth stations 100–210 15–20Coverage within �708 latitude Global



of 20 bytes is sent every 0:02 s; giving an 8 kbit=s voice coding-rate. The duration of eachvoice connection is 2 min:

(3) PING}PING is modelled as (constant bit rate) (CBR) traffic over UDP. One PING is sentevery 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 isused to evaluate the impact of propagation delay on performance.

2. Constant PER but no shadowing impairments. Lossy terminal-to-satellite links wereintroduced 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 inSection 2. Four skylines, reported in Figure 3, have been used to simulate the urbanenvironment surrounding the terminal. In particular, each street has a different averageelevation masking-angle: 108 Leizaran, 308 Lerez, 408 Arga and 708 Narrow.

4. Occurrence of shadowing impairments for mobile user occurs according to the canyonstreet model described in Section 2. A street of Madrid presenting 308 of average elevationmasking angle has been used (Figure 2). The street is about 10 km long and the width is20 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 acknowledgementpackets. For this reason, the PER was not applied to TCP ACK packets for our simulations. Tovalidate this approach, we have performed non-shadowed experiments using an equivalent ByteError Rate and achieved comparable results. The simulations also assume a fixed channelcapacity as achieved by TDMA/FDMA with fixed encoding. So the channel utilization of TCPwas determined by calculating the percentage of this capacity achieved by TCP.

Using a fixed channel without link-level acknowledgments likely increases the impact ofshadowing upon upper layers. On the other hand, link-level acknowledgments might proveimpractical due to the large propagation times and scaling or undesirable because applicationssharing the channel may not all want to pay this price, e.g. voice and video. In any case, theinteraction of a dynamic channel, whether due to link-level acknowledgements or adaptiveencoding, 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 havebeen 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 avery large file from gateway to mobile terminal using FTP over TCP Tahoe. We use the skylinesfrom four streets in Madrid (Leizaran, Lerez, Arga and Narrow) as described in the previous


P. LORETI ET AL.598

section. As the reader may have observed from the 3608 panoramic scans in Figure 3, thoseskylines ranged from minimally obstructed (Leizaran) to almost completely blocked (Narrow).Our goal in this experiment is to evaluate FTP performance in presence of intermittent blackoutdue to shadowing, and to assess the benefits of satellite diversity (when available). Clearly, theFTP goodput performance of a specific street is strongly dependent on its orientation withrespect to the satellite orbits and thus would be completely biased towards one systemconstellation or another [7]. To remove this bias and to obtain results that are insensitive oforientation but instead indicative of skyline ‘elevation’ profile, we evaluate TCP performancerelative to various street orientations (108 apart) and then compute the average, which isreported in Figure 4. Presumably, this models the FTP performance perceived by a mobiletraveling along a ‘certain type’ of skyline. In a later section, we report performance of a mobiletraveling on a ‘specific’ street. In addition to the skyline simulations, as a term of reference, wesimulated also an unshadowed scenario with no shadowing impairments, and with satelliteelevations above the specified minimum elevation angles of 8:28 (polar) and 108 (non-polar). Theresults (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 constellationsfor the four different skyline elevations, from 108 (Leizaran) to 708 (Narrow). The mostremarkable 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 criticalimportance of satellite diversity. The inclined constellation, because of the orientation of itsorbits, always has two or more satellites in view allowing diversity. The polar constellation, onthe 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 weresent from the terminal to the Gateways, one PING every 1 s: One-way delays (from terminal toGateway) were measured for both LEO constellations. The complementary cumulative delay

Figure 4. TCP Tahoe bandwidth utilization with shadowing averaged over street orientation angles.



distribution for the PINGs is shown in Figure 5. It is seen that the delays are very small (below0:05 s). The delays for the polar constellation are slightly smaller due to the lower altitude of thesatellites (see Table III). Figure 5 also shows that the variance in delays is very small for bothconstellations.

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 timeintervals to get results for the throughput. FTP connections with a 15-min duration were runevery 30 min: We ran 24 such connections (representing 12 h of simulation time) and thethroughput results were averaged over all connections. The channel has been assumed to have aconstant packet error rate (PER) on the mobile terminal-to-satellite link. Table III shows thethroughput achieved for different PERs for TCP Tahoe, Reno and SACK, respectively.

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-hopscenario 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.89010�3 0.892 0.890 0.892 0.888 0.887 0.88810�2 0.858 0.864 0.878 0.853 0.859 0.87510�1 0.341 0.334 0.357 0.327 0.334 0.347


P. LORETI ET AL.600

As seen from the graphs above, there is a very little difference among the throughputsachieved by TCP over the two constellations. Moreover, the throughputs achieved by differentTCP versions are very similar. This behaviour can be easily explained by recalling that round-trip delay is less than 100 ms (see Figure 5), channel rate is 144 kbit=s and packet size is 1 000bytes. 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 wellknown advantages of the TCP enhanced versions Reno and SACK (which do not drop to SlowStart and perform fast, selective retransmissions) have absolutely no effect in this case. For thisreason, we did not extend our investigation to other TCP versions such as TCP Westwood andTCP with ECN. The reader should be aware, however, that in future LEO satellite systemsoffering broadband services (say several Mbit/s to the mobile terminal) the choice of TCPprotocol 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 connectionis 5 kbytes. We ran 1000 such FTP connections, one every 30 min and obtained a distributionfor the delay associated with the file transfer. The mobile channel, as described in Section 2 andaccording to the parameters reported in Section 4.3, was used. Simulations were performed forterminal speeds of 0, 2 and 20 m=s: Figure 6 shows the complementary cumulative distributionfor the two LEO constellations for various terminal speeds.

We note that the delays associated with the inclined orbits are much lower than those of thepolar orbits. This results from the path diversity of the inclined orbits. Namely, in that case theconstellation characteristics allow the terminal to see more than one satellite at the same time.

Figure 6. FTP transfer complementary cumulative delay distribution for various terminalspeed in a single-hop scenario.



With diversity, the terminal can link to another visible satellite when the current satellitebecomes shadowed. Thus, diversity reduces the shadowing duration and the chance of a packetbeing lost due to shadowing. In the polar case, on the other hand, the terminal can normally seeonly one satellite and the shadowing duration is longer. Another property observed in Figure 6is the fact that an increase in terminal velocity causes an increase in file transfer delays. This isdue 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 morepackets 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. Inpractical cases, with significant handoff execution time, techniques based on constellationcharacteristics that suppress sending of TCP segments during handoff can be implemented toreduces the problem of ‘in-flight’ packets. Moreover the network can re-route these packets toavoid losses. However, it is difficult to predict when handoffs will occur as a result of channelconditions.

5.5.5. HTTP with shadowed channel and mobile terminal. We also performed simulations forHTTP (version 1.0) transfer over TCP Tahoe for the inclined constellation to get a comparativeanalysis between the ideal channel and the mobile channel. We ran 1000 HTTP sessions (asdescribed 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 allpages in a session) have been evaluated. The simulations were performed for a channel notaffected by any PER but with a terminal speed of 2 m=s both in shadowed and unshadowedconditions. The page and session delay complementary cumulative distributions for HTTPtransfers are shown in Figures 7 and 8, respectively. In both figures, the curve relative to theunshadowed 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.


P. LORETI ET AL.602

Figure 8, we note that the variance of the HTTP session delay is much smaller, and indeedmanageable. In essence, the pedestrian user inspects the page (for up to 40 s) and is unaware ofthe shadowing, until he requests the next page. The shadowing dead-times are utilized for localinspection 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 havesuitably evolved to provide connectivity between two terminals in their coverage area withoutrelying on the terrestrial network.

Each satellite in the Iridium-like constellation has four inter-satellite links, i.e. two inter-planelinks connecting the previous and the next satellites in the same orbit and two intra-plane linksconnecting the corresponding satellite in the adjacent orbits. Also, in a polar constellation likeIridium, there are two regions in which the planes are counter-rotating, thus forming a ‘seam’ inthe topology. We consider the Iridium-like constellation both with and without cross-seamlinks. Without cross-seam links, some satellites have only one inter-plane link.

In the enhanced Globalstar-like constellation, intra-plane links are introduced connectingeach satellite to the previous and next satellites in the same orbit. In addition, a number ofGateways are introduced to provide inter-plane connectivity. The Gateways can see satellites ofmore 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. Therouting 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 ofsimulations, PING packets were transferred between two terminals located at random positionson the earth inside the coverage area of the constellations. 25 000 PING packets were sent

Figure 8. HTTP session delay transfer complementary cumulative distribution.



according to the PING model explained in Section 4.2. The latitude and longitude ofthe terminals were selected using uniform random distributions; latitude varied between �1808and 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 simulationswere 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 constellationwithout 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 largerdelays for small terminal separation due to points that may be located close to each other buteither across the seam or near the polar regions, where inter-plane links are disabled. Figure 9brings out this fact. Figure 10 shows that the delays are lower when cross-seam links areenabled. We also have the same behaviour as in Figure 10, for points close to each other butnear the polar-regions. In the case of the non-polar constellation, as shown in Figure 11, thedelays are significantly higher. Since packets may have to be routed through Gateway(s) in thecase of inclined orbits, the distance traversed by packets tends to be longer, which causes largerdelays.

5.6.2. VOICE}No shadowing effects. In the second set of simulations, we simulated voiceconnections between two points located at Rome (428N and 128E) and Los Angeles (338N and1188W). The voice connections were modelled according to the Voice model described in Section4.2. The number of voice connections is 1000, with the duration of each voice connection being2 min: A new voice connection is started every 15 min: The simulations were performed for anIridium-like constellation with and without cross-seam links and for a Globalstar-likeconstellation; a perfect channel ðPER ¼ 0Þ was assumed. The complementary cumulative delaydistributions of the Voice Packet delays are shown in Figure 12. Delays are significantly largerwith the inclined orbits than with the polar orbits, consistent with the results found in

Table IV. LEO incline constellation gateway location for full satellite network simulations.

Region Gateway latitude Gateway longitude

Europe 47:08N 1:08E42:08N 13:08E52:08N 45:08 E

North America 45:08N 75:08W30:08N 95:08W20:08N 70:08W

South America 5:08 S 95:08W30:08S 65:08W8:08S 40:08W

South Africa 28:08S 20:08EMiddle East 25:08N 45:08EAsia 52:08N 80:08E

43:08N 125:08EAustralia 18:08S 138:08E


P. LORETI ET AL.604

Section 4.5.1 (PING experiments). Yet, even the non-polar constellation delays are withinacceptable thresholds for voice over IP. As for the polar constellation, we note that the presenceof cross-seams improves only marginally the delay of voice packets.

Figure 10. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions forthe polar constellation with cross-seam links.

Figure 9. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions for thepolar constellation without cross-seam links.



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 Gatewaylocated in Rome (428N and 128E) and a terminal in Los Angeles (338N and 1188W). Figure 13

Figure 12. VOICE packets delay complementary cumulative distribution.

Figure 11. Scatter plot of one-way delay experienced by 40000 PING for random terminal positions forinclined-enhanced constellation.


P. LORETI ET AL.606

shows the throughput achieved vs the PER (only for the terminal-to-satellite link) using thepolar constellation without cross-seam links and the non-polar constellation with inclinedorbits. FTP connections with a 15-min duration were run every 30 min: We ran 24 suchconnections (representing 12 h of simulation time) and averaged the throughput results over allconnections.

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 tocompare the constellation (multihop) results with the corresponding single-hop results inTable IV. For 10�1 PER, the single-hop channel utilization is 0.87 for SACK and 0.86 forTahoe, that is, virtually identical. We attributed this to the small bandwidth� propagationproduct. In the multihop case (polar orbits without ISLs), the propagation increasessubstantially, up to 0:25 s: Thus, the optimal window is in the order of 10 packets. TCPSACK in this scenario can make a difference. In fact, it improves TCP Tahoe performance from0.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. Thefirst scenario connects a user in Rome with a user in Washington D.C. using a single-hop GEOconfiguration. In this case we use Channel 4, that is, both shadowing and mobility in the urbanenvironment 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-hopGEO configuration. This scenario includes two GEO satellites connected via an ISL. In thiscase, 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.

Figure 13. Bandwidth utilization vs throughput for TCP Tahoe and SACKand in different satellite constellation.



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 thesingle-hop GEO configuration. Likewise, Figure 15 shows TCP performance as a function ofPER 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 configurationin shadowed environment.

Figure 15. Performance of FTP as a function of capacity and PER fordouble GEO (with ISL) configuration.


P. LORETI ET AL.608

Westwood outperforms TCP Reno and SACK in the presence of random errors and/orshadowing. The faster-recovery algorithm used by TCP Westwood facilitates quick recoveryfrom packet errors. In addition, the performance of the different capacity links are intended as afraction of the link capacity and the better performance of the 1 Mbit=s link with respect to the2 Mbit=s link are due to the longer time the latter link takes to recover the optimum windowafter a packet loss implementing the slow start algorithm.

6. CONCLUSION

This paper presents a performance evaluation of various mobile Internet applications inrepresentative satellite configurations: LEO polar, LEO inclined and GEO. This processconsidered various traffic scenarios and satellite channel propagation models that includeshadowing.

For the ‘single satellite hop’ scenario we compute the throughput delivered by FTP (a delayinsensitive application) when delivering to mobile users traveling along ‘urban canyons’. Theresults show that building shadowing strongly affects throughput performance. The inclinedconstellation, allowing diversity, offers distinct advantages over the polar orbit layout.

We then consider a multihop satellite path between remote locations and evaluate theperformance of delay sensitive applications (IP telephony and HTTP) for both constellations. Inthis case, the polar constellation with its ISLs outperforms the inclined. The latter has no ISLsand 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 (ascaused 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-hopLEO all schemes do well since the bandwidth� delay product remains quite low. On the otherhand, in multihop paths across the constellation or especially for high-delay GEO links, TCPSACK and TCP Westwood eventually prevail as a result of longer path delays and largerwindows.

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"aazquez-Castro MA. TCP via Satellite Constellations.

Fourth European Workshop on Mobile/Personal Satcoms (EMPS 2000), London, September 2000.



12. Loreti P, Luglio M, Kapoor R, Stepanek J, Gerla M, Vatalaro F, Vazquez-Castro MA. Throughput and DelayPerformance of Mobile Internet Applications Using LEO Satellite Access. International Symposium on 3GInfrastructure 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 SystemsPerformance with TCP-IP Applications. Tyrrhenian International Workshop on Digital Communications. IWDC2001; 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 SystemsPerformance with TCP-IP applications. Proceedings of Milcom 2001, Tysons Corner, McLean, VA, USA, October28–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 onTelecommunications, 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 WirelessCommunications and Networking Conference, New Orleans, LA, September 1999.

28. Loreti P, Luglio M. Satellite Diversity: a Technique to Improve Link Performance and Availabilityfor 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 link-

related 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, September2000.

35. V!aazquez-Castro M, Tzaras C, Saunders S, P!eerez-Font!aan F. Shadowing Correlation for Mobile Satellite Diversity.Joint COST 252-255 Meeting, Tolouse, May 8–10, 1999.

36. V!aazquez-Castro MA, Saunders S, Tzaras C, P!eerez-Font!aan 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 18thAIAA 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 NetworkProtocols, 1999 (ICNP ’99), 1999; 327–334.

39. Leung KY, Yeung KH. The design and implementation of a WWW traffic generator. Proceedings of SeventhInternational 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.


P. LORETI ET AL.610

Mobile internet access using satellite networks -...

Documents

Transcript of Mobile internet access using satellite networks -...