Pengenalan Satelit

IEEE Communications Magazine • March 2001154

Satellite-Based Internet: A Tutorial

0163-6804/01/$10.00 © 2001 IEEE

ABSTRACT

In a satellite-based Internet system, satellitesare used to interconnect heterogeneous networksegments and to provide ubiquitous direct Inter-net access to homes and businesses. This articlepresents satellite-based Internet architecturesand discusses multiple access control, routing,satellite transport, and integrating satellite net-works into the global Internet.

INTRODUCTIONThe Internet has enjoyed explosive growth in thepast few years. At the same time, the prolifera-tion of new applications, and expansion in thenumber of hosts (computers connected to theInternet) and of users impose new technicalchallenges to Internet development. New Inter-net infrastructure and technologies capable ofproviding high-speed and high-quality servicesare needed to accommodate multimedia applica-tions with diverse quality of service (QoS)requirements. Furthermore, in order to provideubiquitous Internet access, appropriate mobilitysupport is required.

A satellite communication system, distin-guished by its global coverage, inherent broad-cast capability, bandwidth-on-demand flexibility,and the ability to support mobility, is an excel-lent candidate to provide broadband integratedInternet services to globally scattered users. Asatellite system, if properly designed, can coverthe entire surface of the Earth, making itextremely appealing to aeronautical and mar-itime users, and to those in remote areas lack-ing terrestrial communication infrastructure.Even for the densely wired parts of the world, itoffers an alternative to the increasingly congest-ed terrestrial links. A satellite network is inher-ently a broadcast system. It is particularlyattractive to point-to-multipoint and multi-point-to-multipoint communications which areexperiencing rapid development, especially inbroadband multimedia applications. Satellitenetworks can serve as broadband access net-works, high-speed backbone networks connect-ing heterogeneous networks, or simply ascommunication links between users with fixedor mobile terminals.

However, the interoperation between a satel-

lite system and the existing terrestrial Internetinfrastructure introduces new challenges. Thisarticle attempts to survey ongoing researchefforts on integrating satellite systems into theglobal Internet. It clarifies the crucial technicaldifficulties and provides insights for furtherresearch. The rest of the article is organized asfollows. In the next section we present the basicbackground on satellite systems. The article thendescribes proposed satellite-based Internet archi-tectures. Several technical issues in constructingsatellite-based Internet and some suggested solu-tions are discussed. The final section provides asummary and identifies some future researchdirections.

SATELLITE COMMUNICATIONFUNDAMENTALS

A satellite system consists of a space segmentand a ground segment. The ground segmentconsists of gateway stations (GSs), a networkcontrol center (NCC), and operation controlcenters (OCCs). The NCC and OCCs handleoverall network resource management, satelliteoperation, and orbiting control. The GSs act asnetwork interfaces between various external net-works and the satellite network. They also per-form protocol, address, and format conversions.The space segment is composed of satellites,which may be classified into geostationary orbit(GSO) and nongeostationary orbit (NGSO)satellite, including medium earth orbit (MEO)and low earth orbit (LEO) satellite, according tothe orbit altitude above the Earth’s surface.

GSO — The majority of satellites in operationnowadays are placed in GSO orbit. The GSOsatellite is 35,786 km above the equator, and itsrevolution around the Earth is synchronized withthe Earth’s rotation. Therefore, it appears fixedto an observer on the Earth’s surface, and mayserve as a repeater in the sky. Its high altitudeallows each GSO satellite to cover approximatelyone third of the Earth’s surface, excluding thehigh latitude areas. The area of coverage of asatellite is called its footprint. Three GSO satel-lites are sufficient for global coverage. However,the cost of launching GSO satellites is high. Dueto its high altitude and the inherent signal degra-

Yurong Hu and Victor O. K. Li, The University of Hong Kong

SATELLITE-BASEDINTERNET TECHNOLOGY AND SERVICES

IEEE Communications Magazine • March 2001 155

dation with distance, large antennas and trans-mission power are required for both the GSOsatellite and ground terminals. The most signifi-cant problem is the large propagation delay forGSO satellite links. The typical value of round-trip delay is 250–280 ms, which is undesirable forreal-time traffic.

MEO and LEO — MEO’s distance from theEarth’s surface is from 3000 km up to the GSOorbit with a typical round-trip propagation delayof 110–130 ms. LEOs are located 200–3000 kmabove the Earth’s surface. For a LEO satellite theround-trip delay is 20–25 ms, which is comparableto that of a terrestrial link. Since LEO/MEO satellites are closer to the Earth’s surface,the necessary antenna size and transmissionpower level are much smaller; but their footprintsare also much smaller. A constellation of a largenumber of satellites is necessary for global cover-age. The lower the orbit altitude, the greater thenumber of satellites required. In addition, sincesatellites travel at high speeds relative to theEarth’s surface, a user may need to be handed offfrom satellite to satellite as they pass rapidly over-head. Therefore, steerable antennas are crucial tomaintain continuous service.

Satellite Payload — The satellite payload isresponsible for the satellite communication func-tions. Once the satellite is launched, it is veryexpensive and almost impossible to upgrade orrepair. The space environment, with radiation,rain, and space debris, is harsh for satellites.Therefore, the satellite payload is required to besimple and robust. Traditional satellites, espe-cially GSOs, serve as bent pipes. They act asrepeaters between two communication points onthe ground. There is no onboard processing(OBP). It is simple and easy to implement. Somesatellite systems allow OBP, including demodu-lation/remodulation, decoding/recoding,transponder/beam switching, and routing to pro-vide more efficient channel utilization. OBP cansupport high-capacity intersatellite links (ISLs)connecting two satellites within line of sight. Byusing a sophisticated constellation with ISLs,connectivity in space without any terrestrialresource is possible.

Frequency Bands — The most commonly usedsatellite frequency bands are C band (4–8 GHz),Ku band (10–18 GHz), and Ka band (18–31GHz). With a higher frequency band and a cor-responding shorter wavelength, smaller antennascan be used to receive the signal. Some satellitesystems use C band and thus employ large anten-nas with minimum diameter of 2–3 m. Themajority of direct broadcast satellites use Kuband for broadcasting as well as for Internetconnections from the server to the users, with aterrestrial return link. A Ku band antenna canbe as small as 18 inches in diameter. There areproposals to provide a Ka band return link forthese systems. Ka band potentially offers muchhigher bandwidth than Ku band, and can usevery small antennas, but it suffers from environ-mental impairments such as fading and rainattenuation. There are also plans to use frequen-cies beyond Ka band, but the technologies forusing those frequencies are immature and fur-ther investigation is needed.

SATELLITE-BASEDINTERNET ARCHITECTURES

The satellite-based Internet has several architec-tural options due to the diverse designs of satel-lite systems, in orbit types (GSO, MEO, LEO),payload choice (OBP or bent pipe), and ISLdesigns. There are suggestions that multiple satel-lite types (i.e., GSOs, MEOs, and LEOs) beincluded in a hybrid GSO/NGSO network to fullyutilize the best characteristics of each orbit type.

A satellite network can serve as part of theInternet backbone, a high-speed access network,or both. Using a satellite system as part of theInternet backbone has a long history that datesback to the Atlantic SATNET interconnectingARPANET with European research networks[1]. However, the idea of using satellites as asolution of the last mile problem (i.e., connect-ing users to network access points), inspired bythe usage of cost-effective very small apertureterminals (VSAT) and improvements in satellitetechnologies, is relatively new.

A typical satellite-based Internet scenariowith bent-pipe satellites is depicted in Fig. 1.

The idea of using

satellites as a

solution of the

last mile problem

(i.e., connecting

users to the

network access

points), inspired

by the usage of

cost-effective

VSATs and

improvements

in satellite

technologies, is

relatively new.

■ Figure 1. The satellite-based Internet with the bent-pipe architecture.

Terrestrialnetwork

Terrestrialnetwork

Terrestrialnetwork

Gateway

User A

Direct access usersUser B

Gateway GatewayTerrestrialnetwork


The satellites adopted can be GSO, MEO, orLEO. It provides Internet access as well as datatrunking service. The satellite network interfaceswith the ground Internet infrastructure via GSson the Earth. It may be the only access methodfor some users (e.g., user A) when no othercommunication method is available, or a backupconnection in addition to an existing terrestrialaccess network (e.g., user B).

However, the bent-pipe architecture’s lack ofdirect communication paths in space results inlow spectrum efficiency and long latency. OBPand ISLs may be used to help construct a net-work in the sky (Fig. 2). This architecture isagain a combination access and backbone net-work. Teledesic is one such system using a con-stellation of 288 LEO satellites with ISLs [2].The rich connectivity in space will provide moreflexibility but also bring complex routing issues,which will be discussed later.

In Table 1 we summarize some proposedworldwide broadband satellite systems that aimto provide high-speed Internet service. We havenot included Iridium [3], which started operationin 1998, since it is primarily designed for voiceand paging services.

In the two aforementioned general architec-

tures, user terminals are assumed to be interac-tive, which means they can directly transmit dataup to the satellite and receive data from the satel-lite. Although rapid advancements in satellitetechnology have spawned small user terminals,such as ultra small aperture terminals (USAT)with 60 cm antennas, the interactive terminal isstill expensive and thus frustrates direct-to-homeimplementation. Enlightened by Internet trafficasymmetry where considerably more data is trans-mitted from the server to the end user than in thereverse direction (e.g., Web browsing), there is atrend to offer Internet access via direct broadcastsatellites (DBSs) used for television broadcasting[1]. Each home has a receive-only satellite dish tocollect data delivered in the high-speed satellitebroadcast channel. The reverse path to the serveris provided by a terrestrial link (Fig. 3). Hughes’sDirecPC system is an example. In order to makefull use of the wide bandwidth of satellite broad-cast links, DBS is also extended by using thereceive-only terminals as gateways to interconnectremote networks.

The above architecture contradicts the tradi-tional symmetric network assumption of two-waybalanced load and identical link characteristics,and causes the so-called unidirectional routingproblem elaborated on in the next section.

TECHNICAL CHALLENGESIn this section we summarize the technical chal-lenges in designing and implementing the satel-lite-based Internet. We focus on specialrequirements unique to satellite systems, andleave out general considerations common to ter-restrial networks. Multiple access controlschemes, essential for satellite systems, aredescribed first. Then we investigate transmittingIP packets in satellite networks. Finally, trans-port issues based on TCP modification and satel-lite-specific transport protocols are presented.

MULTIPLE ACCESS CONTROLIn interactive satellite systems, a large number ofuser terminals widely scattered within the satellitefootprint contend for the satellite uplink channel.1Multiple access control (MAC), defined as a setof rules for controlling access to a shared channel

■ Figure 2. The satellite-based Internet with the OBP and ISL architecture.

Terrestrialnetwork

Terrestrialnetwork

Terrestrialnetwork

Gateway

Direct access users

GatewayGateway

ISL

Terrestrialnetwork

ISL

■ Figure 3. Internet access via DBS.

Reverse link

GW: Gateway

DBS

High-speed forward link

Masterstation

Server

Internet

ISP

GW

Multiple access

control, defined

as a set of rules

for controlling

access to a

shared channel

among

contending users,

plays an

important role in

efficiently and

fairly utilizing the

limited satellite

system resources.


among contending users, plays an important rolein efficiently and fairly utilizing the limited satel-lite system resources. MAC protocol perfor-mance can significantly affect higher-layerprotocols and the QoS provided by the system.

The performance of MAC protocols dependson the characteristics of both the shared commu-nication media and the traffic. The long latencyin satellite channels (especially the GSO links)excludes some MAC schemes used in terrestriallocal area networks (LANs) such as carrier sensemultiple access (CSMA), and the limited powerresource in satellites constrains the transponderand computational capacity on board the satel-lite. Internet traffic turns out to be bursty innature. Besides the current best-effort service,the Internet is expected to provide diverse QoSguarantees (e.g., on delay, delay jitter, packetloss ratio) for a wide range of traffic types. Thus,a candidate MAC protocol must implement pri-orities. Real-time traffic with transmission dead-lines is usually given higher priority thannon-real-time traffic.

Generally speaking, a good MAC scheme fora satellite-based network should be simple toimplement, robust, and flexible to accommodatenetwork reconfiguration. The MAC should beable to achieve high throughput, maintain chan-nel stability, and enjoy low protocol overheadand small access delay.

Depending on how bandwidth is allocatedamong all contenders, candidate MAC schemesfor satellite systems can be categorized intothree groups: fixed assignment, random access,and demand assignment.

Fixed Assignment — Fixed assignment may bemade on a frequency, time, or code basis. Majortechniques include frequency-division multipleaccess (FDMA), time-division multiple access(TDMA), and code-division multiple access(CDMA). In FDMA and TDMA systems, eachstation utilizes its own dedicated channel. Theyare contention-free, and can provide QoS guar-antees. However, this is at the expense of ineffi-

cient utilization of resources. Their lack of flexi-bility and scalability makes them only suitablefor small-scale networks with stable traffic pat-terns. FDMA was the first fixed assignment mul-tiple access method used in satellite systems.TDMA is popular mainly because of its compati-bility with the nonlinear nature of transponders2

and is used in the majority of current satellitesystems. In a CDMA system, each user isassigned a unique code sequence which is usedto spread the data signal over a wider bandwidththan that required to transmit the data. If codesequences are guaranteed to be orthogonal, allother simultaneous transmissions in the samechannel act as additive interference to thedesired signal and can be removed completely atthe receiver side, where a reverse procedure,despread, is taken to recover the original data.Thus, in a CDMA system, the whole bandwidthis used by all users, making it more flexible forsystem expansion.

Random Access — Due to technologicaladvances, small and inexpensive terminals (i.e.,VSATs and USATs) with lower data rates arenow widely available, thus stimulating home orpersonal use of satellite access service. The num-ber of stations within a satellite footprint increas-es from a few to several hundreds or thousands.In addition, the traffic generated by each user isvery bursty. Fixed assignment schemes arereplaced by contention-based random access (i.e.,Aloha and its variations). In random accessschemes, each station transmits data regardless ofthe transmission status of others. Retransmissionsafter collision increase the average packet delay,and frequent collisions may cause low throughput.

Demand Assignment — Although randomaccess may better accommodate a large numberof terminals with bursty traffic, it provides noQoS guarantees. Demand assignment multipleaccess (DAMA) protocols attempt to solve this

■ Table 1. A summary of proposed worldwide broadband satellite systems.

System Major sponsors Constellation Satellite payload Frequency band Data rate Service date

Astrolink Lockheed Martin Up to 9 GSO OBP and ISLs Ka Up to 200 Mb/s 2003satellites downlink

Up to 20 Mb/s uplink

Skybridge Alcatel Espace, 80 LEOsatellites Bent-pipe Ku 16 kb/s–20 Mb/s downlink 2002Loral Space at 1469 km 16 kb/s–2 Mb/s uplink

Spaceway Hughes 4 GSO satellites OBP and ISLs Ka Up to 92 Mb/s downlink 2002(ultimately 21 16 kb/s–6 Mb/s uplinksatellites)

Teledesic Motorola, 288 LEO satellites OBP and ISLs Ka 16 kb/s–64 Mb/s downlink 2004Lockheed Martin at 1375 km 16 kb/s–2 Mb/s uplink

1 This section describes protocols used by those interactivesatellite systems which use a satellite link for the reverselink from the users to the Internet servers, and are notapplicable to those systems, such as DirecPC, which use aterrestrial reverse link.

2 In order to efficiently utilize the power of transponders,we must drive them into a saturation area where theamplifiers operate as nonlinear devices. In an FDMA sys-tem, users’ signals may be received simultaneously, andthe nonlinear amplifier generates undesired interference.In TDMA, only one user accesses the transponder at anygiven time interval, and the problem is avoided.


problem by dynamically allocating system band-width in response to user requests. A resourcerequest must be granted before actual data trans-mission. The transmission of requests is itself amultiple access problem. However, since therequest message is typically much shorter thanactual data transmission, we can afford to havereservation requests collide and be retransmitted.After a successful reservation, bandwidth is allo-cated on an overall FDMA or TDMA architec-ture, and data transmission is guaranteed to becollision-free. This article focuses on the TDMAarchitecture in which equal-sized time slots aregrouped into frames, repeated periodically.

The reservation may be made under central-ized or distributed control. The central con-troller can be located at an Earth station or at asatellite with OBP. For a ground-based con-troller, the minimum request delay is two round-trip times before the reservation request isgranted. The minimum request delay can behalved for a space-based controller, but thesatellite payload capacity limits this implementa-tion. Distributed control, in which each stationreceives all request information from the satel-lite broadcast channel and makes a decision onits own, is more robust and reliable. The channeloverhead associated with reservation announce-ments is reduced greatly, and the minimumreservation delay is as small as one round-triptime. Although it may put the processing burdenon the stations, distributed control is still pre-ferred, considering its overall advantages.

Resource reservation can be made eitherexplicitly or implicitly. Explicit reservation is ona per-transmission basis, and usually a dedicatedreservation channel is shared among all stations.Each station sends a short request via the reser-vation channel specifying the number of timeslots needed. Stations access the reservationchannel in fixed assignment mode, such asTDMA reservation, or random access mode,such as Aloha reservation. Data is transmitted inthe data channel after successful reservation.

In implicit reservation, there is no explicitreservation message, and a successful data trans-mission in a slot serves as an indication of reser-vation for the corresponding time slot insubsequent frames. Packets belonging to a longtransmission can repeatedly occupy the same slotin consecutive frames. An empty slot in a frameindicates the end of the transmission, and otherusers can then contend for this slot starting in thenext frame. This scheme is attractive for relativelysteady traffic patterns such as voice and videoconnections. An example of this scheme is Reser-vation Aloha, which uses the first data packet asan implicit request unit and accesses the availabletime slots via the slotted Aloha protocol.

Priority-Oriented Demand Assignment(PODA) and first-in first-out (FIFO) OrderedDemand Assignment (FODA) [4] combineimplicit and explicit requests. Each PODATDMA frame consists of a control part and adata part with an adjustable boundary. Explicitrequests contend in the control part by slottedAloha, while implicit requests are piggybackedon data packets. FODA further divides the datapart into stream and datagram subframes. OneFIFO stream queue and two FIFO datagram

queues, for short interactive traffic and bulkytraffic, are maintained with decreasing priorities.The latter two types of traffic are transmitted inthe datagram subframes.

There are proposals to make use of the unre-served resource after the demand assignment.Combined free/demand assignment multipleaccess (CFDAMA) [5] freely assigns remainingchannels according to some strategy (e.g., round-robin). In combined random access and TDMA-reservation multiple access (CRRMA) [6],remaining resources are open for random access.By randomly accessing the unreserved channel,some bursty interactive traffic may be transmittedimmediately without waiting for the two-hopreservation delay. A hybrid scheme called Round-Robin Reservation (RRR) is based on fixedTDMA. The number of stations is required to beless than or equal to the number of time slots.Each station obtains a dedicated channel, andextra or unused slots are accessed in a round-robin manner or via slotted Aloha. In satellite sys-tems, large GSs interfacing with terrestrialnetworks function as multiplexers for traffic fromthose directly connected networks. Gateway sta-tions are usually much more heavily loaded thansmall terminals, and the number of GSs is muchsmaller than that of small terminals. The RRRmechanism may be suitable for this scenario. Forexample, GSs may obtain dedicated time slots,while small terminals contend for the remainingslots in each frame. Similar hybrid methods maycombine the advantages of different schemes, butfurther performance analyses and simulations areneeded to demonstrate their feasibility.

ROUTING ISSUES IN SATELLITE SYSTEMS

Routing Issues in a LEO Constellation —The significant advantages of LEO with OBPand ISLs, such as small delay and full connectivi-ty, make it a very attractive approach to theInternet in the sky. In such networks, the majortechnical issue is the complex dynamic routingissue due to satellite movements.

Dynamic Topology — Due to the relativemovement between the LEO satellite and theEarth, a satellite has a very short visible periodto motionless users on the ground. To maintain24-hr continuous coverage, a carefully designedsatellite constellation is crucial. At any timethere should be at least one satellite within lineof sight of a user. When a satellite moves out ofa user’s visual field and another satellite movesin, intersatellite handover happens. For a satel-lite with multiple antennas and transponders, thesatellite footprint is divided into a number ofspotbeams, each covered by an antenna beam.Thus, frequent interbeam handover from spot-beam to spotbeam occurs within a single satel-lite’s visible period.

The ISLs in the constellation form a mesh net-work topology. Each satellite is typically able toset up 4–8 ISLs. There are two types of ISLs:intraplane ISLs connecting adjacent satellites inthe same orbit, and interplane ISLs connectingneighboring satellites in adjoining orbits. Intra-plane ISLs are maintained permanently, but someinterplane ISLs may be temporarily switched off

A hybrid scheme

called

Round-Robin

Reservation is

based on fixed

TDMA. The

number of

stations is

required to be

less than or equal

to the number of

time slots. Each

station obtains a

dedicated

channel, and

extra or unused

slots are accessed

in a round-robin

manner or via

slotted Aloha.


when the viewing angle or distance between twosatellites changes too fast for the steerableantennas to follow. This may occur between twocounter-rotating orbits or when two orbits cross.The routing scheme should be able to handletopological variations. Fortunately, although theconstellation topology changes frequently, it ishighly periodic and predictable because of thestrict orbital movements of the satellites.

Some dynamic routing mechanisms popularin the Internet, such as distance vector (DV)and link state algorithm (LSA), are not directlyapplicable in satellite constellation routing,because frequent topological changes in satelliteconstellation will cause large overhead and oscil-lation if these schemes are used. Two new con-cepts tailored to dynamic satellite constellationare worth mentioning: discrete-time dynamic vir-tual topology routing (DT-DVTR) [7] and thevirtual node (VN) [8].• DT-DVTR — DT-DVTR makes full use of

the periodic nature of satellite constellationand works completely offline. It divides thesystem period3 into a set of time intervalsso that the topology changes only at thebeginning of each time interval and remainsconstant until the next time interval. Ineach interval, the routing problem is a statictopology routing problem that can be solvedeasily. A number of consecutive routingtables are then stored onboard andretrieved when the topology changes. Withthis strategy, online computational com-plexity is transformed into a large storagerequirement on the satellites. In order tominimize the storage needed and the inter-satellite handover attempts when topologychanges, an optimization procedure can beused to choose the best path or a small setof paths from the series of instantaneousroutes. Although it can significantly reducethe storage size, some links may becomecongested while others are underutilized.

• VN — The objective of this scheme is to hidethe topology changes from the routing pro-tocols. A virtual topology is set up with VNssuperimposed on the physical topology ofthe satellite constellation. Even as satellitesare moving across the sky, the virtual topolo-gy remains unchanged. Each VN keeps stateinformation, including routing tables andinformation of users within the VN’s cover-age area. In a certain period, a VN is repre-sented by a certain physical satellite. As thissatellite disappears over the horizon, the VNis represented by the next satellite passingoverhead. The state information is alsotransferred from the first satellite to the sec-ond. A routing decision is made on the virtu-al topology, and the protocols are not awareof the dynamic satellite constellation con-cealed in state transfers.Based on these two concepts, some routing

schemes are proposed for carrying IP packetsthrough the satellite constellation. Some com-mercial satellite systems (e.g., Teledesic) use

proprietary routing techniques that are highlydependent on explicit orbital and constellationknowledge and optimized for specific designs.Due to their lack of generality, they are not cov-ered in this article.

IP Routing at the Satellites — To route IPpackets through a satellite constellation, it seemsstraightforward to adopt IP routing at the satel-lites. This strategy is addressed in [9], and is basedon the VN concept. It can seamlessly integrate thespace network with the terrestrial Internet, andpermits direct support for IP multicast and IPQoS (integrated and differentiated service mod-els). However, how to deal with variable-length IPpackets, the scalability problem of onboard rout-ing tables, and computational and processingcapacity limitations in space devices are challeng-ing problems. The scheme is still in its infancy,and some practical problems are unsolved in theimplementation of the VN concept.

ATM Switching at the Satellites — Many pro-posed systems use ATM as the network protocolfor the constellation (i.e., Cyberstar, Astrolink,Spaceway, and Skyway) with a satellite-specificsignaling protocol and link layer protocol [10]. AnATM version of DT-DVTR is investigated in [7],where all the virtual channel connections betweenthe same pair of ingress and egress satellites aregrouped into a virtual path connection (VPC),and onboard switching is done according to theVPC labels. A modified S-ATM packet is suggest-ed to reduce the overhead without changing thecell size [10]. If such a system is adopted to pro-vide Internet service, IP over ATM or other simi-lar technologies will be used.

External Routing Issues — It is reasonable toassume that the internal routing schemes forsatellite constellation will continue to be hetero-geneous. Satellite manufacturers and operatorswill probably select routing methods best suitedto their own system designs. The internal proto-col should be kept simple. Details of the satellitenetwork should be hidden from the terrestrialInternet as well. Today’s Internet achieves thiskind of isolation by using the autonomous sys-tem (AS) concept. Typically, some external rout-ing schemes are used for inter-AS routing, whileinternal routing is handled by the AS’s owninternal routing protocol.

A satellite system can be considered an AS inthe Internet (Fig. 4) [9]. A number of bordergateways (BGs) running exterior routing proto-cols (e.g., Border Gateway Protocol, BGP, usedby terrestrial ASs) will communicate with terres-trial ASs. Only BGs on the constellation periph-ery need be aware of the outside addresses andtopological information. All packets goingthrough a satellite constellation enter the satel-lite AS from one entry BG, which is responsiblefor determining the exit BG of each packet. Ifnecessary, the entry/exit BGs perform encapsula-tion/decapsulation and address resolution. TheBGs can be implemented either onboard thesatellites or in ground GSs. If space-based BGsare used, computational and storage require-ments may be too much for the satellites. On theother hand, if terrestrial gateways are used,

How to deal with

variable length IP

packets, the

scalability

problem of

on-board routing

tables, and

computational

and processing

capacity

limitations in

space devices are

challenging

problems. The

scheme is still in

its infancy, and

some practical

problems are

unsolved.

3 The system period is the least common multiple of theorbit period and the Earth’s rotation period.


packets must be bounced back to the ground forIP routing, introducing an extra round-trip delay.However, ground BGs are more realistic. Fur-thermore, external routing protocols popular interrestrial networks cannot simply be reused insatellite constellations. In terrestrial networks,any internal link within an AS always has smallercost than an inter-AS link. It is generally truebecause in terrestrial networks an AS is usuallylimited to a small geographical area, while aninter-AS link travels a much longer way. But asatellite system extends globally, and routingwithin a satellite constellation may be as expen-sive as traversing several ASs. Thus, multiplepairs of BGs should be used from a satellite con-stellation to a destination in some AS.

Unidirectional Routing — As described earlier,Internet access via DBS poses the unidirectionalrouting problem which cannot be handled by tra-ditional dynamic routing schemes where bidirec-tional links are assumed. For example, in distancevector routing, a router receiving the distance vec-tor tuple {destination, cost} from its neighbordeduces that it can reach the destination via thisneighbor. It is no longer true in the satellitebroadcast scenario where the direct reverse linkto the satellite does not exist. Multicast routingprotocols (e.g., DVMRP) based on the reverseshortest path tree also face such a problem [11].

There are three ways to handle this problem.Instead of dynamic routing, static routing maybe an option; but with thousands of users servedby a DBS, it is impossible to manually configureall of the routing entries. The other two methodsare routing protocol modification and tunneling,proposed in the Internet Engineering Task Force(IETF) Unidirectional Link Routing (UDLR)working group. They are discussed next.

Routing Protocol Modification — In unidi-rectional routing, the router at one end of a uni-directional link with a send-only interface isreferred to as a feeder, while the router at theother end of the unidirectional link with areceive-only interface is called a receiver. The

key idea of the modification is twofold. First, themodified protocol should enable a receiver toidentify the potential feeders whenever itreceives routing updates from them, and toignore the unusable routing information in thosepackets while keeping the useful reports tomaintain the neighboring connectivity [11]. Sec-ond, the receiver periodically delivers its ownrouting message to all feeders through the ter-restrial reverse channel. Thus, when a feedergets the routing information, it can update therelated routing entries for reachable destinationsthrough the unidirectional link passing thereceiver. The idea is used by the UDLR workinggroup in the proposals to modify some popularprotocols (i.e., RIP, OSPF, and DVMRP).

Tunneling — Tunneling offers a link layerapproach to hide the network asymmetry fromthe routing process. A virtual bidirectional link isset up between a DBS and a user by encapsula-tion and decapsulation. This virtual link is calleda tunnel. Packets destined for the DBS from theuser are delivered via the tunnel. The tunnel end-point at the user side first encapsulates the pack-et, and then passes it to the routing protocolwhere it is delivered through the actual terrestrialreverse channel. When the packet arrives at thesatellite, the tunnel endpoint captures it, decapsu-lates it, and forwards it to the routing protocol towhich it seems to come from a bidirectional link.

The above two approaches are simple, andsince tunneling is transparent to all upper layerprotocols, it may be quickly implemented inDBS Internet access architectures. However, thetwo schemes are designed based on point-to-point unidirectional links, although satellites arepoint-to-multipoint broadcast systems. Thus, fur-ther study is needed to design new approachesoptimized for this architecture. The twoapproaches also focus only on the routing issuewithin a single AS and fail to address interdo-main routing. New interdomain routing schemesthat can handle unidirectional links are needed.

SATELLITE TRANSPORTThe TCP/IP and UDP/IP protocol suites form thebasis of the Internet. Due to their tremendouslegacy, it is unlikely they will be totally discardedin the near future. Therefore, the satellite-basedInternet is expected to continue to serve applica-tions based on TCP and UDP. However, the per-formance of both protocols will be affected by thelong latency and error-prone characteristics ofsatellite links. The impacts on TCP will be muchgreater, and heated debates have been spawnedregarding the feasibility of TCP in a satellite envi-ronment. Researchers working with NASA’sACTS satellites are performing research regard-ing TCP/IP over satellite connections. The IETFTCP over Satellite working group is also dedicat-ed to improvement of TCP performance in satel-lite systems. In this section we first present themain limitations of TCP over satellite links andthen summarize the ongoing research efforts onthe satellite transport problem.

TCP Performance over Satellite — TCP usesa positive feedback mechanism to achieve ratecontrol and reliable delivery. The long latency of

■ Figure 4. A LEO constellation's autonomous system.

LEO constellation

IP router

Bordergateway

Bordergateway External AS


satellite links (especially GSO links) increasesthe TCP end-to-end delay and results in sluggishacknowledgments. The slow feedback will weak-en the functionality of rate control and conges-tion avoidance, and thus affect the throughput.In addition, a potential problem is the large fluc-tuation of measured round-trip time (RTT) thatmay be caused by dynamic topology in LEO con-stellation networks. Large variations in RTTmeasurements may result in false timeouts andretransmissions.

In the initial slow start stage of TCP transmis-sion, although the sending rate increases exponen-tially, it is still too slow for the high-bandwidthsatellite links. One proposed solution is to increasethe initial value of the window. TCP originallyallows a window size of 64 kbytes, which also lim-its the maximum sending rate to 64 kbytes/RTT.The satellite link will be underutilized, and a largewindow scaling up to the bandwidth-delay productof the satellite link is required for higher through-put. A set of window scaling options to TCP imple-mentation are defined in IETF Request forComments (RFC) 1323.

Satellite links are subject to various impair-ments (i.e., interference, fading, shadowing, andrain attenuation). Therefore, a high bit error rate(BER) is expected. Although advanced modula-tion, coding schemes, and forward error correction(FEC) techniques are used to reduce the BER, insome environments high BER persists. But TCPdoes not distinguish between corrupted data causedby transmission error and packet loss due to con-gestion; both are unacknowledged and interpretedas a notification of network congestion. Whenthere is a corrupted packet, the window size ishalved even though there is no congestion. Fur-thermore, transmission errors on a satellite link arebursty in nature, especially under bad weather con-ditions. Bursty errors in one RTT will dramaticallyreduce the throughput. The Space Communica-tions Standards-Transport Protocol (SCPS-TP)[12] defined for the general space environmentprovides two mechanisms to distinguish the sourcesof loss and responds differently. In addition, net-work asymmetry can also impair TCP perfor-mance. Satellite network asymmetry occurs in twosituations. One is in the asymmetric DBS Internetaccess architecture described earlier. The other isdue to bandwidth asymmetry in some interactivesatellite terminals. These terminals may be capableof downloading at tens of megabits per second, butwith uplink speed of only several hundred kilobitsper second. The limited reverse link capacity maycause the acknowledgment starvation problem.The backlogged feedback will slow down the win-dow refresh. In addition, acknowledgment loss dueto reverse link congestion may trigger unnecessaryretransmissions.

Another problem inherent in TCP is the fair-ness issue between different TCP connectionswith various RTTs. When those TCP connec-tions share a bottlenecked link, the TCP connec-tions with longer RTTs will suffer unfairbandwidth allocation.

Performance Enhancements — The IETFTCP over Satellite working group has recentlymade a number of recommendations to enhancethe performance of TCP over satellite links in its

RFCs. The last two schemes listed below arenon-TCP techniques:• TCP selective acknowledgment-(SACK)

options (RFC2018) allow the receiver tospecify the correctly received segments.Thus, the sender needs to retransmit onlythe lost packets. TCP SACK can recovermultiple losses in a transmission windowwithin one RTT.

• TCP for transaction (T/TCP) (RFC1644)attempts to reduce the connection hand-shaking latency from two RTTs to oneRTT, which is a significant improvementfor short transmissions.

• Persistent TCP connection, supported inHTTP1.1 (RFC2068), allows multiple smalltransfers to download in a single persistentTCP connection. It is more efficient.

• The Path maximum transfer unit (MTU)discovery mechanism allows TCP to use thelargest possible packet size, thus avoidingIP segmentation. It reduces the overhead,and eliminates fragmentation and defrag-mentation.

• FEC is employed in link layer protocols toimprove the quality of satellite links, but itshould not be expected to fix all problemsassociated with manmade noise, such asmilitary jamming, and some natural noise,such as that caused by rain attenuation.Besides FEC, some other link layerapproaches (e.g., bit interleaving, link layerautomatic repeat request schemes) can alsobe used to improve packet error rate intransmissions over satellite links.TCP extensions can solve some of the limita-

tions of standard TCP over satellite links, butother problems such as long end-to-end latencyand asymmetry are not effectively addressed.One way to alleviate the effects of large end-to-end latency is to split the TCP connection intotwo or more parts at the GSs connecting thesatellite network and terrestrial networks. Thereare three approaches to splitting TCP connec-tions over satellite links:• TCP spoofing: The divided connections are

isolated by the GSs, which prematurelysend spoofing acknowledgments uponreceiving packets. The GSs at split pointsare also responsible for retransmitting anymissing data. The performance of TCPspoofing is examined in [13].

• TCP splitting: Instead of spoofing, the con-nection is fully split. A proprietary transportprotocol can be used in a satellite networkwithout interference to standard TCP in ter-restrial networks [14]. It is more flexible, andsome kind of protocol converter should beimplemented at the splitting points.

• Web caching: In contrast to the above twoschemes, the TCP connection is split by aWeb cache in the satellite network. Users inthe satellite network connected to this Webcache need not set up TCP connections allthe way to servers outside if the requiredcontents are available from the cache. Webcaching effectively reduces connection laten-cy and bandwidth consumption.In [14], a Satellite Transport Protocol (STP)

is designed and used in the TCP splitting

The satellite-

based Internet is

expected to

continue to serve

applications

based on TCP

and UDP.

However, the

performance of

both protocols

will be affected

by the long

latency and

error-prone

characteristics of

satellite links.


approach as well as for traffic management in asatellite network. STP is based on the basicoperation of Service-Specific Connection-Orient-ed Protocol (SSCOP). The sender periodicallyrequests the receiver to report successful recep-tions, and retransmission is triggered by explicitselective negative acknowledgment. It uses ahybrid window and rate congestion controlmechanism. STP performs well in asymmetricnetworks since the reverse traffic is significantlyreduced, but it does not distinguish between dif-ferent sources of packet loss and also leaves thefairness problem unsolved.

CONCLUSIONIn this article we present an introduction to thesatellite-based Internet. Some possible architec-tures based on bent-pipe and OBP satellites arediscussed. Several technical challenges, includingmultiple access control, IP routing in LEO con-stellations, unidirectional routing, and satellitetransport issues are investigated. In addition towhat we elaborate on in this article, some impor-tant research issues are identified as follows:• IP QoS support. There is no lack of

research regarding QoS support in satellitesystems. However, most of them are basedon ATM QoS classes [8, 15], and the map-ping of ATM service classes to IP QoSrequirements is a nontrivial problem.Moreover, the implementation of TCP/IPover ATM brings much overhead, extraprocessing time, and protocol complexity.Direct support of the Internet integratedor differentiated service model is desired.In [9], multiprotocol label switching(MPLS) is proposed to support InternetQoS (integrated or differentiated service)in a satellite-based network. The integra-tion of space and terrestrial communica-tion systems, internetworking differentsatellite networks, and the advent of hybridsatellite systems will bring more redundan-cy and routing choices. QoS routing insatellite systems will be a very importantresearch problem.

• Traffic and congestion control. To ensurethat the satellite network achieves desiredperformance and fulfills the IP QoS require-ments, a set of mechanisms to control trafficand avoid congestion is required. A well-designed MAC protocol will not by itselfprevent congestion in the network. Trafficmanagement, traffic shaping, policing, andscheduling are also required. Some preven-tive congestion control schemes, such asadmission control, and efficient congestionnotification schemes are important to main-tain the specified QoS guarantees.

REFERENCES[1] H. D. Clausen, H. Linder, and B. Collini-Nocker, ”Internet

over Direct Broadcast Satellites,” IEEE Commun. Mag.,June 1999, pp. 146–51.

[2] D. J. Bem, T. W. Wieckowski, and R. J. Zielinski, “Broad-band Satellite Systems,” IEEE Commun. Surveys, vol. 3,no. 1, 2000.

[3] S. R. Pratt et al., “An Operational and PerformanceOverview of the IRIDIUM Low Earth Orbit Satellite Sys-tem,” IEEE Commun. Surveys, vol. 2, no. 2, 1999.

[4] N. Celandroni, and E. Ferro, “The FODA-TDMA SatelliteAccess Scheme: Presentation, Study of the System, andResults,” IEEE. Trans. Commun., vol. 39, no. 12, Dec.1991, pp. 1823–31.

[5] Le-Ngoc and S. V. Krishnamurthy, “Performance ofCombined Free/Demand Assignment Multiple-AccessSchemes in Satellite Communications,” Int’l. J. SatelliteCommun., vol. 14, no. 1, Jan./Feb. 1996, pp. 11–21.

[6] H. W. Lee and J. W. Mark, “Combined Random/Reserva-tion Access for Packet Switched Transmission over aSatellite with Onboard Processing: Part I — GlobalBeam Satellite,” IEEE Trans. Commun., vol. COM-31,Oct. 1983, pp. 1161–71.

[7] Markus Werner, “A Dynamic Routing Concept for ATM-Based Satellite Personal Communication Networks,”IEEE JSAC, vol. 15, no. 8, Oct. 1997, pp. 1636–48.

[8] R. Manger and C. Rosenberg, “QoS Guarantees for Mul-timedia Services on a TDMA-Based Satellite Network,”IEEE Commun. Mag., July 1997, pp. 56–65.

[9] L. Wood et al., “IP Routing Issues in Satellite Constella-tion Networks,” Int’l. J. Satellite Commun., to appear.

[10] I. Mertzanis et al., “Protocol Architectures for SatelliteATM Broadband Networks,” IEEE Commun. Mag., Mar.1999, pp. 46–54.

[11] W. Dabbous, E. Duros, and T. Ernst, “Dynamic Routingin Networks with Unidirectional Links,” Proc. 2nd Int’l.Wksp. Satellite-Based Information Services (WOSBIS’97), Budapest, Hungary, Oct. 1997.

[12] R. C. Durst, G. J. Miller, and E. J. Travis, “TCP Exten-sions for Space Communications,” ACM MobiComm’96, Nov. 1996.

[13] M. Allman, H. Kruse, and S. Ostermann, “TCP Perfor-mance over Satellite Links,” WOSBIS ’96), Nov. 1996.

[14] T. R. Henderson and R. H. Hatz, “Transport Protocolsfor Internet-Compatible Satellite Networks,” IEEE JSAC,vol. 72, no. 2, Feb. 1999, pp. 326–44.

[15] R. Goyal et al., “Traffic Management for TCP/IP overSatellite ATM networks,” IEEE Commun. Mag., Mar.1999, pp. 56–61.

BIOGRAPHIESYURONG HU ([email protected]) received her B.E. fromTsinghua University, China, in 1999. She is currently anM.Phil. student in the Department of Electrical and Elec-tronic Engineering at the University of Hong Kong, China.Her research interests are in the areas of satellite networks,multimedia communications, and Internet QoS.

VICTOR O.K. LI [F] ([email protected]) received his S.B., S.M.,E.E., and Sc.D. degrees in electrical engineering and com-puter science from the Massachusetts Institute of Technol-ogy in 1977, 1979, 1980, and 1981, respectively. He isChair Professor of Information Engineering at the Universi-ty of Hong Kong, and Managing Director of Versitech Ltd.,the technology transfer and commercial arm of the univer-sity. Previously, he was professor of electrical engineeringat the University of Southern California (USC), Los Angeles,and director of the USC Communication Sciences Institute.He has published over 200 technical articles, and has lec-tured and consulted extensively around the world. Hisresearch interest is in information technologies, focusingon the Internet and wireless networks.

One way to

alleviate the

effects of large

end-to-end

latency is to split

the TCP

connection into

two or more

parts at the

gateway stations

connecting the

satellite network

and terrestrial

networks.

Documents

Pengenalan Satelit