Performance of delay-sensitive traffic in multi-layered satellite IP networks with on-board...

INTERNATIONAL JOURNAL OF COMMUNICATION SYSTEMSInt. J. Commun. Syst. 2007; 20:1367–1389Published online 31 January 2007 in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/dac.874

Performance of delay-sensitive traffic in multi-layered satelliteIP networks with on-board processing capability

Suzan Bayhan*,y, Gurkan Gur and Fatih Alagoz

Satellite Networks Research Laboratory (SATLAB), Bogazici University, TR-34342, Bebek, Istanbul, Turkey

SUMMARY

In this article, performance of delay-sensitive traffic in multi-layered satellite Internet Protocol (IP)networks with on-board processing (OBP) capability is investigated. With OBP, a satellite can process thereceived data, and according to the nature of application, it can decide on the transmission properties.First, we present a concise overview of relevant aspects of satellite networks to delay-sensitive traffic androuting. Then, in order to improve the system performance for delay-sensitive traffic, specifically Voiceover Internet Protocol (VoIP), a novel adaptive routing mechanism in two-layered satellite networkconsidering the network’s real-time information is introduced and evaluated. Adaptive Routing Protocolfor Quality of Service (ARPQ) utilizes OBP and avoids congestion by distributing traffic load betweenmedium-Earth orbit and low-Earth orbit layers. We utilize a prioritized queueing policy to satisfy quality-of-service (QoS) requirements of delay-sensitive applications while evading non-real-time traffic suffer lowperformance level. The simulation results verify that multi-layered satellite networks with OBP capabilitiesand QoS mechanisms are essential for feasibility of packet-based high-quality delay-sensitive services whichare expected to be the vital components of next-generation communications networks. Copyright # 2007John Wiley & Sons, Ltd.

Received 3 October 2006; Accepted 10 November 2006

KEY WORDS: satellite communication; routing; quality of service; on-board processing; multi-layeredsatellite networks

1. INTRODUCTION

Delay-sensitive services over Internet Protocol (IP) such as Voice over Internet Protocol (VoIP)have become popular in the last decade because of their cost effectiveness and the amalgamationof heterogenous networks into a hybrid communications infrastructure based on IP. Satellites

*Correspondence to: Suzan Bayhan, SATLAB, Department of Computer Engineering, Bogazici University, TR-34342,Bebek, Istanbul, Turkey.yE-mail: [email protected]

Contract/grant sponsor: The State Planning Organization of Turkey (DPT); contract/grant number: DPT03K120250

Copyright # 2007 John Wiley & Sons, Ltd.

offer mobile and fixed services with high bandwidth and global coverage which make their usagequite attractive for communications. Combining these two technologies creates a synergy andresults in state of the art and efficient systems. New generation satellites, rather than old-fashioned ‘bent pipes’, can achieve on-board processing (OBP) resulting in faster service andhigher performance at the cost and complexity trade off. With the deployment of third-generation (3G) and advent of fourth-generation (4G) networks, these capabilities will be crucialfor better services and help the implementation of ‘ubiquitous and pervasive communications’concept.

Performance is an important consideration of a system which renders it accepted or declinedby the users. Therefore, parameters affecting the performance should be elaborated. Delay anddelay variation are key parameters for the system performance of delay-sensitive applications.Thus, delay must be restricted to some certain values specified by the authorities (such as ITUand ETSI). For satellite networks, the significance of delay becomes more apparent where theorbit of satellite}low-Earth orbit (LEO), medium-Earth orbit (MEO) or geostationary orbit(GEO)}affects the propagation delay, therefore, the overall system performance. For instance,one way satellite latency is about 2502280 ms [1] for GEO satellites. In this study, multi-layeredsatellite systems consisting of non-geostationary (NGEO) satellites (LEO and MEO) are takeninto consideration.

NGEO networks inherently have some structural challenges in that the nodes aremoving rapidly with respect to the slow moving or fixed user nodes, causing frequenttopological changes in the network. Due to the dynamic topology of NGEO satellite networksand non-uniform traffic distribution in satellite footprints, some inter-satellite links (ISLs)will be heavily loaded while some ISLs being underutilized. This will in turn lead to congestionon the heavily loaded links and will ultimately result in higher queueing delays and packetloss due to buffer overflows. To prevent from congestion, balancing the traffic load on thelinks is essential. However, existing network protocols are designed for wired systems andthereby cannot perform well in high bandwidth-delay product satellite networks. Hence,it is essential to design satellite-friendly protocols which can benefit from the high bandwidthand connectivity of the satellite environment whilst considering the large link propagationdelays [2]. Main objectives for an efficient protocol design can be listed as traffic loadbalancing which is closely related with congestion avoidance and detection, maximizingthroughput and link utilization. While considering these points, some design criteria must bemet. These requirements are mainly; fast routing table calculation and update, lowcommunication (signalling) overhead, low implementation complexity and low memoryrequirements.

This paper discusses the performance issues of delay-sensitive traffic in multi-layered satelliteIP networks with OBP capabilities. We propose an adaptive routing scheme in two-layeredsatellite network considering the network’s real-time information to improve the systemperformance for delay-sensitive traffic. The proposed routing scheme Adaptive RoutingProtocol for Quality of Service (ARPQ) attempts to meet aforementioned objectives consideringthe relevant design criteria. We consider VoIP as a specific delay-sensitive application andemploy it to evaluate the performance of the proposed routing scheme. In the following section,we provide an overview of the previous work on multi-layered satellite architectures and routingissues in NGEO satellite networks. In Section 3, we present some background information andthe basic definitions for the proposed routing scheme. This is followed by the detaileddescription and explanation of ARPQ. In the next section, we define our network simulation

S. BAYHAN, G. GUR AND F. ALAGOZ1368

Copyright # 2007 John Wiley & Sons, Ltd. Int. J. Commun. Syst. 2007; 20:1367–1389

DOI: 10.1002/dac

environment. In Section 5, the performance of ARPQ is evaluated focusing on the effect of itssystem parameters. Moreover, the effects of on-board scheduling mechanism, namely priorityqueueing, are investigated and the key experimental results are provided in this section. Finally,we conclude in Section 6.

2. SATELLITE NETWORKS

In this section, we provide an overview of three important aspects of satellite networks relevantto delay-sensitive traffic and routing: multi-layered constellations; OBP; and traffic loadbalancing and congestion avoidance/detection.

2.1. Multi-layered NGEO satellite networks

The majority of satellites currently in operation are placed in GEO orbit. The GEO satelliteis 35 786 km above the equator, and its revolution around the Earth is synchronizedwith the Earth’s rotation. While GEO satellite has the advantage of very large coveragearea, it also has some drawbacks such as high orbit lift costs, requirement for large antennas,high transmission powers and, most significantly, the large propagation delay. Thetypical value of end-to-end propagation delay is 250–280 ms; which is undesirable for real-time traffic.

MEO’s distance from the Earth’s surface is from 3000 km up to the GEO orbit with a typicalend-to-end propagation delay of 80–100 ms [3]. LEOs are located 200–3000 km above theEarth’s surface. For a LEO satellite the end-to-end delay is 20–25 ms; which is comparable tothat of a terrestrial link. Since LEO/MEO satellites are closer to the Earth’s surface, thenecessary antenna size and transmission power level are much smaller; however, their footprintsare also much smaller. A constellation of a large number of satellites is necessary for globalcoverage. Simply, the lower the orbit altitude, the greater the number of satellites required. Inaddition, since satellites travel at high speeds relative to the Earth’s surface, a user may need tobe handed off from satellite to satellite as they pass rapidly overhead [4].

When it comes to service delivery, each type of satellite orbit has its own set of drawbacks andadvantages. For instance, in very simplistic terms, the geostationary orbit could be considered tobe more suited to the provision of regionally employed, non-delay sensitive services, whereas theLEO in comparison may be better suited for global, real-time service delivery [5]. Therefore,multi-layered satellite architectures with inter-orbital links (IOLs) between layers of satelliteconstellations, i.e. hybrid constellations, are of much interest as they yield much betterperformance than individual layers.

A multi-layered architecture can consist of a combination of satellites at different orbits i.e.LEOs, GEOs, MEOs. These networks may also employ high-altitude platforms (HAP). HAPsystems are airships or aircrafts stationed in the stratosphere, at altitudes between 17 and 22 km;in order to provide wireless communications infrastructure. There are numerous studies ondifferent aspects of multi-layered satellite networks. In [6], a three-layered architectureconsisting of GEOs, LEOs and HAPs is proposed. GEOs act as backbone routers, LEOs asthe second layer and HAPs to cover special areas with high and sensitive traffic such asbattlefields and disaster areas. In [7], two-layered architecture dubbed ‘satellite over satellite’(SOS) consists of LEOs in the lower layer and MEOs at the top layer. The authors also propose

PERFORMANCE OF DELAY-SENSITIVE TRAFFIC 1369


DOI: 10.1002/dac

a routing protocol for broadband satellite communication networks}Hierarchical QoS RoutingProtocol (HQRP) that supports simple routing protocol for long distance multimedia traffic.

In [8], a new Satellite Grouping and Routing Protocol (SGRP) on a two-layered satellitenetwork of LEOs and MEOs is developed. LEO satellites are divided into groups according tothe footprint area of the MEO satellites. Based on the delay reports sent by LEO satellites, MEOsatellite managers compute the minimum-delay paths for their LEO members. The main idea ofthe SGRP is to transmit packets in minimum-delay path and distribute the routing tablecalculation for the LEO satellites to multiple MEO satellites. Since routing table calculation isshifted to MEO satellites, power consumption is effectively distributed between the two layers.Routing table calculation is done by a sequence of message exchanges, i.e. inter-plane and intra-plane exchange of delay reports. Authors of this paper have also some other work in the fieldwhich can be listed as [6, 9–11].

In [7], the system topology is analysed to estimate the minimum required number of satellitesat each orbit to provide global coverage. Minimum elevation angle and orbit types, i.e.equatorial or polar, are taken into consideration to determine the number of satellites. Last butnot least, Wu et al. [12] models a double-layered network of LEO and MEO satellites by usinggeneralized stochastic Petri net (GSPN) model. Other notable work on multi-layered satellitenetworks can be found in [12–16].

2.2. On-board processing (OBP)

On-board processing is a general term that refers to signal processing and routing functionsimplemented on-board the satellite that go beyond the amplification and frequency conversionperformed in conventional, transparent satellite systems. The next-generation satellitesextensively need to use OBP, including demodulation/remodulation, decoding/recoding,transponder/beam switching and routing to design cost-effective system solutions for thecustomer needs [17]. The OBP in satellites aims to eliminate the inherent disadvantages of the‘bent pipe’ transponders.

The main advantages of satellite systems with OBP are: improved link quality with respect totransparent systems due to signal regeneration on board, efficient bandwidth and power levelcontrol by multi-beam frequency re-use which increases satellite raw capacity, discarding emptyuplink time slots resulting in increased efficiency of downlink transmission, dynamicreallocation of unused bandwidth, asymmetric uplink and downlink bandwidth to takeadvantage of traffic statistics, on-orbit management of network traffic, capacity and quality ofservice (QoS), statistical multiplexing which supports varying degrees of bursty traffic, anddirect interconnections between user terminals through on-board switching [18]. OBP cansupport high-capacity ISLs connecting two satellites within line of sight. Switches in thesatellites provide short latency and thus improve the QoS with regard to systems using hubstations on ground. By using a sophisticated constellation with ISLs, connectivity in spacewithout any terrestrial resource is possible. This feature enables far more autonomous satellitenetworks which may be imperative especially for military purposes and post-disaster-communications situations, where ground facilities may become potential targets or bedamaged. These benefits, however, demand payloads with higher complexity [18]. With moreadvanced and powerful integrated circuitry and microelectronics, OBP has become morefeasible and sensible cost wise. Thus, it has the potential for enabling satellite networks to cope



DOI: 10.1002/dac

with the inherent propagation delay obstacle [19] and contribute to the performance of delay-sensitive applications over satellite networks.

2.3. Traffic load balancing and congestion avoidance/detection

Congestion avoidance/detection and load balancing are discussed in [8, 14, 20–23] and somemechanisms are suggested. In [20], a traffic congestion avoidance scheme based onreal-time traffic information is proposed. In explicit load balancing (ELB), a satellitecontinuously checks its queue size to determine its state which may be free, fairly busy andbusy. If the ratio of queue size to the total queue length, Qr; is under a threshold value a;its state is marked as free meaning that this satellite can be utilized on the path to thedestination. If Qr is between two thresholds a and b; satellite is fairly busy. Finally, in caseof Qr being greater than b; this satellite is accepted as busy. A change in the state ofsatellite is immediately broadcasted to the neighbours of the satellite by self-state advertisementpackets. Neighbours update neighbours status lists (NSL) and cost of the links between the busysatellite and its neighbours is increased. NSL carries information of queue state of eachneighbouring satellite. Neighbours forward some portion ðw%Þ of traffic to other paths. Thisscheme therefore alters the traffic sending rate of neighbouring nodes of the satellite in questionbefore it gets congested. In [24], traffic classes are identified by maximum acceptable delaybounds. Delay-sensitive traffic has a privilege i.e. a quantum of bandwidth is allocated for highpriority traffic. As many other works in the field, time is divided into discrete intervals.Therefore, traffic allocation problem is divided into two subproblems: periodic and incremental.At the beginning of each time interval (periodic allocation) and when a new call arrives(incremental), traffic allocation scheme is applied. The proposed multiservice routingalgorithm}GALPEDA, uses different programming facilities like genetic algorithms andlinear programming. Fair traffic distribution is achieved by forcing low priority traffic to uselightly loaded links.

Jianjun et al. [23] similarly use queueing information of a satellite to balance the traffic loadon each satellite. The proposed algorithm Compact Explicit Multi-path Routing (CEMR)consists of three components: route discovery; route maintenance and traffic allocation. Beforeroute discovery phase, special satellites so-called ‘plane speaker’ collect link state information ofothers in the network and build routing information base (RIB). In SOS architecture proposedby Lee and Kang [7], each LEO satellite sends its link state information directly to the upperlayer MEO. Specialization of some satellites as plane speaker helps decreasing the signallingoverhead. The resulting RIB is distributed to all satellites in the system. A novel constraint-based routing algorithm on a multi-layered satellite network is introduced in [14]. Delay andjitter-sensitive traffic is differentiated from other less-sensitive traffic by class-based queueing.Moreover, bandwidth availability and bit error rate (BER) of the links are taken into accountwhile calculating route for high priority traffic.

An efficient system should apply a QoS scheme that discriminates packets depending on thetraffic classes. To treat each traffic class in a particular way, the network structure must becapable of distinguishing between packets by means of classification and scheduling packetqueues separately as a result of the classification [25]. In [7], traffic class-dependent routing isemployed on the two-layered SOS network. A connection request from the user is classified atthe LEO layer as either short distance-dependent traffic (SDD) or long distance-dependenttraffic (LDD). The first LEO that gets a connection request named as ‘source satellite’ finds



DOI: 10.1002/dac

a feasible path based on its global routing information (GRI). This path satisfies the delayconstraint of the connection i.e. the path’s expected delay is less than delay bound of this call. Ifthe number of hops of the calculated path from source to destination satellite nsd is smaller thana threshold hop count Nhop; then this call is SDD. Otherwise it is LDD. LDD is routed viaMEOlayer to minimize hop count and in turn transmission delay. SDD is routed via LEO layersatellites. The performance of SOS and single layer satellite networks is compared in the firstsimulation set and it is stated that SOS network had better performance than flat satellitenetwork. Although not explicitly stated in the paper, HQRP differentiates the delay-sensitiveand best effort traffic by call admission at each node. On the other hand, real-time networkconditions are not taken into consideration to route a packet. Because of the connection-oriented nature of the proposed routing scheme, it is not suitable for a system having dynamictopology.

3. PROPOSED ALGORITHM: ADAPTIVE ROUTING PROTOCOL FOR QoS (ARPQ)

ARPQ is a class-based routing scheme which dynamically balances the traffic load on the ISLsin a two-layered satellite network. ARPQ scheme mainly consists of three subcomponents:packet classification; link state advertisement and QoS-based queueing. In this section, first wepresent some background and relevant definitions for our satellite system. Then, ARPQ isdescribed in details.

3.1. Background and definitions

Source satellite: The satellite which covers a specific user and connection request of this user isfirst received by this satellite.

Destination satellite: The satellite which covers the user who is the target of a communication.System period ðTsÞ: Most of the studies in the field such as [8, 23, 24, 26] consider the system as

a union of states at sufficiently small time intervals. System period Ts is the lowest commonmultiple of the satellite layer’s orbital period and the Earth’s period. This period is divided intosmall time intervals at which system topology is regarded as static. In this way, changingtopology of the network is reduced to problem of managing states in Ts that is periodic. We alsodivide the constellation period into small time slots t.

LEO group ðLGiÞ: LEO satellites in the footprint of MEOi form a group and this LEO groupis shown by LGi:MEOi is named as ‘group manager’ and shown by GMi: Each group has onlyone GM and all group members are aware of their GM. Actually, a LEO might be covered bymore than one satellite, but we assume that the MEO with the longest service time (dependingon the satellite calendar) is designated as GM.

Link state ðLSiÞ: LEOi stores delay information LSi associated with all its output links.Plane manager ðPMiÞ: A special MEO satellite that is responsible of calculation and

distribution of routing table to the satellites in plane i: Each plane has only one PM and all planemembers are aware of their PM.

Neighbour status list ðNSLiÞ: A satellite i in the constellation has a NSLi storing the state ofthe neighbouring satellites. Satellites may be in one of the states: free (lightly loaded), fairly busy(fairly loaded) and busy (heavily loaded).



DOI: 10.1002/dac

Queue ratio ðQrÞ: The ratio of the current number of bits in a queue at time t denoted by NðtÞto the queue capacity in number of bits Qs

Qr ¼NðtÞ

Qsð1Þ

3.2. Routing table calculation and distribution

We apply a virtual node (VN) scheme as in [27]. In VN scheme, satellite positions are assumedto be fixed in the space, and only the actual satellite passing overhead is changing. We considerthe system as union of time intervals. At the beginning of each time interval, coverage area ofeach satellite is updated using the VN topology and the routing tables are updated regularly tocope with the satellite mobility and link load changes. All LEO satellites determine delay valuesof the links associated with each neighbouring satellite. A link delay consists of twocomponents: propagation delay ðtpÞ and queueing delay ðtqÞ: Intra-plane ISL propagationdelays are always fixed and therefore can be computed offline. However, the length of inter-plane ISLs are variable and thus, the propagation delay on them is changing all the time incompany with the constellation [23]. Furthermore, using periodicity of the satellite topology dueto its predetermined motion in its orbit, dynamic inter-plane ISL propagation delays can also becalculated offline and then can be uploaded to the satellites. ISL propagation delays can becalculated using the formulas listed below [24]. The first equation gives the intra-plane ISLpropagation delay and the latter inter-plane ISL propagation delay.

ISLintra ¼

ffiffiffi2p

c� ðREarth þ hsatÞ �

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi1� cos

2� p� np

N

� �sð2Þ

ISLinter ¼

ffiffiffi2p

c� ðREarth þ hsatÞ �

ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi1� cos

pN

� �r� cos y ð3Þ

where REarth is the radius of earth}6378:137 km; hsat the height of satellite above Earth, N thetotal number of satellites, np the number of planes, y the latitude of the satellite and c the speedof light ð3� 105 km=sÞ:

Expected queueing delay at a node tqðLÞ can be predicted using the queue size of the outgoingISLs using Equation (4), where Lav is the average packet length, C the link capacity, and NqðtÞthe number of packets in the queue at time t: A link L between two satellites has total delaytlinkðLÞ which is calculated by Equation (5). In order to mitigate unnecessary processing on-board the satellites, we calculate queueing delay by getting samples at some certain time instantsand get the average of all these sample values. Number of samples taken can be adjustedaccording to the length of a time interval t

tqðLÞ ¼ NqðtÞ �Lav

Cð4Þ

tlinkðLÞ ¼ tpðLÞ þ tqðLÞ ð5Þ

Similar to other hierarchical routing schemes in [7, 8], routing table calculation is performedby the higher layer which has better knowledge of the whole network topology. MEO layer



DOI: 10.1002/dac

collects the link state information of all LEOs and prepares consequent routing tables. Morebriefly, upon completion of link state information collection, LEOi directly sends its link stateðLSiÞ to its manager satellite GM. After each MEO gets all LS information from the managedLGs, message exchange phase starts to inform other MEOs in this layer about the localtopology of the lower LEO group. Each plane manager PM calculates its routing table anddistributes this table to the MEOs in its plane. The routing table has entries for each node in thenetwork. Each entry has a destination, next hop and link cost field. Actually link cost is the totaldelay associated with the link L and is equal to tlinkðLÞ . Upon receipt of the routing table, eachMEO distributes it to all LEOs in its footprint. Although some deviations exist, routing tableupdates and information exchange are mainly based on the method defined in [4]. In ourscheme, we do not consider the seams where two ISLs are switched off due to their motion inopposite directions. Thereby, we assume that at any time there are four ISLs belonging to eachLEO satellite.

3.3. Packet classification

Since conversational traffic performance is highly dependent on delay and delay jitter values,there is a need for packet type-based routing. In our scheme, voice packets are classified by thesource LEO satellites according to the distance between the source satellite and the destinationsatellite. A path is assigned for each packet by the source LEO using the routing table. Shortestpropagation delay path is calculated using Dijkstra’s Shortest Path Algorithm. Minimum-delaypaths are accepted as optimal paths. Total expected delay of a path p consisting of links shownby k is formulated in the following equation. tuplink and tdownlink are the propagation delays fromsource GS to source LEO and from destination LEO to destination GS, respectively

tpath ¼ tuplink þX8k2p

tlinkðkÞ þ tdownlink ð6Þ

Algorithm 1. Pseudocode of the packet classification algorithm running on source LEO- LEOi

Require: Satellites can distinguish voice packets and background packets.Ensure: Classification of a packet arrived to LEOi:

1: Arrival of a new packet to source satellite LEOi

2: Extract destination address GSk3: Find the destination satellite LEOj covering GSk4: Find the cost of path tpath from LEOi to LEOj

5: if voicepacket then6: if tpath4Dthrsh then

7: Mark the packet as SDV8: else

9: Mark as LDV10: end if

11: end if

The pseudocode of packet classification algorithm is given in Algorithm 1. If the calculateddelay of the path is greater than threshold delay Dthrsh; then this voice packet is marked as long



DOI: 10.1002/dac

distance voice (LDV). Otherwise, it is short distance voice (SDV) packet. In [7], packets areclassified according to the assigned path’s hop count. Since ISL lengths are noticeably differentfrom each other at different parts of the Earth i.e. at polar regions and Equator, hop count doesnot reflect the real delay values. Hence, we base our marking scheme on ISL delays rather thanhop count of the path. Initially, SDV and background packets are forwarded to the next hop ofthe calculated path on the LEO layer. LDV traffic is forwarded by the source LEO to its GM.After getting the packet, MEO assigns a new path and forwards the packet to the next hopeither in MEO layer or LEO layer. Using the MEO layer especially for time-sensitive traffic bothbalances the link utilization rates and prevents excessive jitter and delay values. The pseudocodeof the ARPQ scheme running on a LEO satellite is given in Algorithm 2.

Algorithm 2. Pseudocode of the ARPQ algorithm running on LEOi

Require: Queueing delay values are sent by each LEO to the corresponding GMs and routingtable updates are completed at the beginning of each time interval t.Ensure: Routing of a packet according to the traffic type and link loads.

1: if LDV packet then2: Forward to GMi

3: else

4: Get next hop node: LEOj from Routing Table5: if SDV packet then6: Send to LEOj

7: else

8: Check link state of ISLj from NSLi

9: if statej ¼ free then

10: Send packet to LEOj

11: else

12: Select neighbour node l with MinðQrÞ

13: Forward l% to nodel14: end if

15: end if

16: end if

3.4. Link state assignment and traffic load balancing

In ARPQ, each LEO and MEO satellite continuously checks its outgoing link buffers to detect asign of congestion. If LEO queue ratio Qr is under a threshold value a; there is no sign ofcongestion. If it is between two thresholds a and b; this can be considered as an indication offorthcoming congestion and thereby some action has to be taken [21]. There is an importantpoint to be considered in link state assignment phase. If a and b are the two thresholds, thequeue ratio will oscillate around a: For instance, assuming a ¼ 0:5; the link state will becomefairly busy if Qr is 0.51. Upon a change in the link state, the new state and new Qr will beadvertised. The LEO will forward some portion of traffic to other less loaded links till the fairlybusy becomes free with a queue ratio of 0.49. Thus, Qr values will oscillate between 0.49 and0.51, causing very frequent state advertisements. To tackle this issue, two more threshold values



DOI: 10.1002/dac

k and F ðk5a; F5b and a5bÞ are introduced. The link state assignment and congestiondetection scheme is summarized in Figure 1.

Link state assignment depends on the previous state of a link. Using the previous stateinformation, unnecessary state oscillation is prevented. If a link becomes fairly busy, its queueratio is decreased till queue ratio is below k: Similarly, a busy link’s traffic is spread over otherlinks till its queue ratio is below F: If a link advertises its state as fairly busy or busy, a predefinedportion ðlÞ of background traffic is forced through other ISLs. Each LEO has an NSL storingthe neighbour’s status and queue ratio Qr of the ISL between these nodes. From NSLi; theoutgoing link ISLl with the smallest Qr is chosen. Traffic forward rate l depends on the state ofthe congested link. If it is busy, then no background traffic is routed over this link. All traffic issplit to the other links. However, traffic forwarding may cause loops. To prevent loops, a packetis not routed back to its previous hop and there is a hop count limit to prevent packets travellingin loop on the network.

3.5. On-board scheduling

Queueing and scheduling policies are of great importance in order to implement efficient QoSprovisions. The default scheduling mechanism for a satellite is first-in first-out (FIFO)scheduling policy where the packet entering the queue will leave the queue before the othersarriving after it. However, to satisfy the performance requirements of delay and jitter-sensitivevoice traffic, it must be differentiated from delay-tolerant background traffic. Due to satellites’processing limitations, queueing policy must be both simple and fast. Weighted round robinqueueing (WRRQ) is quite efficient for OBP in that sense. Strict priority may be an alternativepolicy. However, this policy may lead to suffering of data packets of high delay values and maycause ‘starvation’ anomaly. In our scheme, voice traffic has priority over background traffic. Foreach traffic class, a portion of satellite’s processor is reserved, wconv and wbg; respectively.Depending on the values of wconv and wbg; prioritization of one traffic type can be achieved.Since voice traffic is delay and jitter sensitive, it has higher priority and so higher weight wconv:This will yield voice packets to be processed faster. In other words, excessive queueing delayvalues experienced by voice packets due to heavy background traffic will be shortened. Thus,performance of voice communication will be better than usual case of satellites applying FIFOscheduling policy.

4. SIMULATION SET-UP

We consider a two-layered satellite network which has LEO satellites in the lower part andMEO satellites at the top. In the LEO constellation we utilize Iridium system parameters. There

β α

αβα

β

Figure 1. Satellite link state assignment.



DOI: 10.1002/dac

are 66 LEO satellites distributed in six planes each consisting of 11 satellites. Satellites areidentified by their unique numbers between 1 and 66 and shown as LEOid : Each LEO isconnected to two neighbours in the same plane and two other satellites in the neighbouringplanes by ISLs. There are six satellites in MEO layer distributed equally into two MEO planes,achieving global coverage [28].

Although the world’s population, its distribution and communication patterns imply non-uniform traffic density in practice, this non-uniformity is not taken into consideration to keepscenarios simple and easy to manage. Actually, more realistic traffic modelling can be found in[8, 29, 30]. In [8], Chen and Ekici modelled traffic depending on the statistics of the user densitylevels and host density levels per continent. Additionally, user traffic generation rate changesduring the day. This is also considered in [8]. Similarly, Mohorcic et al. [30] model trafficutilizing the percentage of traffic flows between continents.

The world is divided into six coverage areas corresponding to the six continents. There are 44gateway stations (GSs) in each region. Each GS is also identified by a unique number between 1and 264 and specified as GSid : When the scenario starts running, GS source–destination pairsare uniformly chosen and they generate packets for the entire duration of simulation. For amore realistic modelling, GSs generate both background data traffic and voice traffic. There aremany studies on modelling voice traffic sources which mainly focus on on–off, Poisson orMarkov modulated Poisson process (MMPP) models. In this study, all sources are modelled asPoisson traffic sources with exponentially distributed packet inter-arrival times. Packet size isalso assumed to be exponentially distributed with a mean value of 1 kB: Voice traffic patternsare created as duplex and symmetric voice communication streams. GS are directly connected to

LEO layer (1200 km.)(6 planes x 11 satellites/plane)

MEO layer (10390 km.)(2 planes x 3 satellites/plane)

GS

LS

AS

MS

AS

LS

GS

LS

MS

LS

LS

LS

LS

LS

Figure 2. Two-layered satellite architecture used in the simulations.



DOI: 10.1002/dac

LEO satellites via user data links (UDL). There are no direct links between GS and MEO. Thenetwork model used in our simulations can be seen in Figure 2 and network system parametersare listed in Table I.

Table II summarizes the LEO and MEO parameters. Not mentioned in the table, IOLcapacity between LEOs and MEOs is 20 Mbps and each IOL has 1 Mb buffer space. Both theuplink (GS to LEO) and downlink (LEO to GS) capacities are 3:2 Mbps corresponding to400 packets=s:

We utilized OPNET 10.5A ModelerTM [31] to model and simulate the network. Simulationsare run 10 times with different seeds and the average values of results derived from these runs arecomputed. The selection of parameters like link capacities is highly dependent on the hardwarefeatures of our machine on which our OPNET simulations run. However, we believe thatchanging the parameters to more realistic satellite system parameters do not noticeably affectthe simulation results.

5. PERFORMANCE EVALUATION

In this section, we investigate the effect of various system parameters on system performancemetrics. First, Dthrsh value is changed and system performance metrics are recorded. Next, a andb values are changed. Finally, effect of on-board queueing mechanism is investigated. In thefurther subsections, each scenario components and system properties are described in details.Since the proposed scheme has a number of system parameters, the simulation studies will givean idea on how to adjust these parameters properly. However, it should be noted that thesesettings are peculiar for our constellation and parameters.

5.1. Effect of threshold delay Dthrsh

Changing Dthrsh value directly affects the utilization rates of LEO and MEO layer resources.Depending on the values of Dthrsh; SDV and LDV traffic percentage will change and thereforeload on LEO layer will change. This interaction makes determining Dthrsh value a design issue.

Table I. LEO/MEO layer parameters.

Parameters LEO MEO

Orbit altitude (km) 1200 10 390Number of satellites 66 6Number of orbit planes 6 2Number of ISLs 4 5Number of IOLs 1 11

Table II. Node (LEO/MEO) parameters of the simulation scenarios.

Node typeISL capacity

(Mbps)ISL buffersize

(Mb)Processor(Mbps)

Processor buffersize(Mb)

LEO 10 20 120 2MEO 80 20 120 4



DOI: 10.1002/dac

In the following simulation sets, background traffic load is changed and the effect of Dthrsh onsystem performance metrics is analysed. The conversational traffic rate is set to 25% of GSuplink capacity in all runs. The packet size is exponentially distributed and has a mean value of1 kB: We simulated three scenarios: Dthrsh ¼ 10; 80 and 500 ms: The first and the last casescorrespond to two extreme scenarios where nearly all voice packets are marked as LDV in thefirst scenario and SDV in the latter. Setting Dthrsh to 80 ms makes system more balanced whereSDV and LDV ratio is nearly equal. The queue ratios are set to a ¼ 0:4 and b ¼ 0:8: Trafficforwarding rate l is set to 0.9 and 1 in the fairly busy and busy states, respectively. The followingsimulations are run for 120 s and system time interval is set to 10 s: Therefore, the scenariosimulates one period of the system. In our simulations, we usually consider the case where voicetraffic is 25% or less of GS uplink capacity and various background traffic rates. Thisassumption is quite realistic depending on the statistics of voice and data flow all over the worldwhere background traffic is always more than voice traffic.

The simulation results are plotted in Figures 3–5. In Figure 3(a), it is seen that average delay isabout 150 ms when Dthrsh ¼ 10 and there is no background traffic. Ninety-nine percent of voicetraffic is classified as LDV and the remaining part (1%) corresponding to regional traffic of onlyone LEO hop is classified as SDV. The packets are forwarded to the MEO layer instead of lowerLEO layer. Therefore, the average delay is more than the other two cases where Dthrsh is 80 and500 ms with no background traffic. In case of Dthrsh ¼ 500; all voice packets are marked as SDVand are routed through the LEO layer. Under light background traffic load, this does not affectthe system performance, since there is enough capacity for all types of traffic. On the other hand,with the increase in background traffic, voice traffic delay and jitter values also increase due tocongested paths in the LEO layer. Since our mechanism forwards background packets toalternate paths in case of congestion (or a sign of congestion), there is not a significant differencein average delay values in scenarios where Dthrsh ¼ 80 and 10. Conversational delay valuessimilarly increase with the increasing background traffic load. Under light traffic load, delayvalues are in acceptable region when Dthrsh ¼ 80 and 10. However, when the system uses itsentire capacity (when voice traffic is 25% and background traffic is 75%), delay values ofconversational traffic are around 1 s, which is far above the acceptable limits. With suchdelay values it is impossible to have an intelligible communication. Therefore, there is certainlyneed for voice traffic prioritization on board the satellite. Background traffic delay values

0 15 25 40 50 60 750

200

400

600

800

1000

1200

1400

Background traffic load (%)

threshold=10threshold=80threshold=500

(a)0 15 25 40 50 60 75

0

200

400

600

800

1000

1200

1400



(b)

Figure 3. (a) Effect of Dthrsh on conversational traffic delay values under changing background traffic loadand (b) effect of Dthrsh on background traffic delay values under changing background traffic load.



DOI: 10.1002/dac

(Figure 3(b)) follow a similar pattern as conversational traffic. On the other hand, backgrounddelay values are higher than conversational delay values. This is due to traffic forwardingapplied to background packets in case of queue ratio increase warnings.

When it comes to packet loss, similar to network delay simulation results, scenario withDthrsh ¼ 500 has the worst performance results. This is again due to congestion in LEO layer.Additionally, background traffic route is made longer in case of high traffic load. This may alsoincrease the probability of packet loss. Throughput and packet loss values of the simulations aredepicted in Figures 5(a) and (b). Packet loss rates of background and conversational trafficbehave similarly. Briefly, with the increasing values of background traffic load, packet loss ratesalso increase. The most steep change occurs when Dthrsh is 500 ms: From Figure 5(b), the overalltraffic packet loss rate can be seen. Although there is not a significant difference between thecases where Dthrsh ¼ 80 and 10 ms; it can be seen that it performs better when Dthrsh is 80 ms:This is because of the reason that setting Dthrsh to 80 ms yields nearly equal number of packetsto be marked as LDV and SDV. Hence, voice traffic is split between the LEO and MEO layersthereby causing lower probability of congestion in both layers.

Finally, delay jitter values collected from the simulations are listed in Table III. Backgroundtraffic jitter is higher than conversational traffic due to the varying route of background packets.

0 15 25 40 50 60 750

10

20

30

40

50

60

Background traffic ratio (%)P

acke

t los

s (%

)

Bg, threshold=10Bg, threshold=80Bg, threshold=500Conv, threshold=10Conv, threshold=80Conv, threshold=500

Figure 4. Effect of Dthrsh on packet loss rate of each traffic type under changing background traffic load.

0 15 25 40 50 60 7520

25

30

35

40

45

50

55

60

65

70


Thr

ough

put (

Mbp

s)


(a)0 15 25 40 50 60 75

0

10

20

30

40

50

60


Ove

rall

pack

et lo

ss (

%)


(b)

Figure 5. (a) Effect of Dthrsh on network throughput under changing background traffic load and (b) effectof Dthrsh on network packet loss under changing background traffic load.



DOI: 10.1002/dac

LDV traffic has stable jitter values due to the paths followed in MEO layer. SDV has usuallylarger jitter values than LDV because of paths composed of more satellite (LEO) hops. Increasein background load adversely affects jitter values, which shows the necessity of voice trafficprioritization.

To sum up, we can conclude that under heavy traffic load, utilizing MEO layer for voicetraffic will be efficient by preventing congested paths on LEO layer. This can be achieved bysetting Dthrsh to relatively low values, e.g. 20 ms corresponding to 1 LEO hop. Furthermore,voice traffic can be routed through LEO layer under light background traffic load.

5.2. Effect of queue threshold values a and b

Depending on the a and b values, number of packets in the queues, queueing delay valueschange. Setting a to 1 makes the system behave as a non-adaptive system. Therefore, we cancompare our mechanism ARPQ to the non-adaptive case, ARPQ without load balancing. In thefollowing experiments we set Dthrsh to 80 ms; k ¼ a=2 and l ¼ 90%: Setting Dthrsh to 80 ms;causes almost half of the voice traffic flow through the LEO layer. In the light traffic load case,effect of load balancing will not be apparent. Therefore, the traffic load is 60% of GS uplinkutilization rate. We change the first threshold a and k ( k is set to a=2Þ; and analyse their effectson system performance. b is set to 1 or 0.8 (depending on the values of aÞ and F is set to b=2 inall of the following experiments. It should be noted that these choices are made arbitrarily withno special purpose in mind. Thereby, different values of these parameters can also be set and theeffects on system performance can be examined.

Figures 6 and 7 depict the queue ratios of LEO53 with two different a values. Actually, thequeue ratios correspond to the link utilization rates of these related links. In Figure 6, IOL isfree of congestion and its utilization ratio is very low as opposed to ISL being overloaded. Sincethere is no load balancing in this case, there is an imbalance in link utilization rates which yieldsto excessive queueing delay values. Moreover, overflow traffic is dropped rather than being

Table III. Simulation results}delay jitter values.

Background traffic (%)

Dthrsh (ms) Traffic type 0 15 25 40 50 60 75

10 Background } 23 35 184.5 202 228 550Conversational 21 20 20 25.5 30 38 444

LDV 21 20 20 25.5 30 39 444SDV 1 1 2 1 1 1 13

80 Background } 39 72 151 193.5 214 531Conversational 27 33 43 59 69.5 82 441

LDV 13 15 20 28 31 38 382SDV 18 33 50 73 84.5 92 349

500 Background } 81 169 309 404 306 581Conversational 65 122 145 209 220 306 533

LDV } } } } } } }SDV 65 122 145 209 220 306 533



DOI: 10.1002/dac

0 10 20 30 40 50 60 70 800

0.2

0.4

0.6

0.8

1

Simulation time (s)

ISL

queu

e ra

tio

0 10 20 30 40 50 60 70 80 90 1000

0.2

0.4

0.6

0.8

1

Simulation time (s)

IOL

queu

e ra

tio

Figure 6. The outgoing queues of LEO53 with a ¼ 1 (non-adaptive case). ISL outgoing queue is congestedand experiences overflow as opposed to very low queue ratio of IOL queue.

0 20 40 60 800

0.2

0.4

0.6

0.8

1

Simulation time (s)0 20 40 60 80

0

0.2

0.4

0.6

0.8

1

Simulation time (s)

0 20 40 60 800

0.2

0.4

0.6

0.8

1

Simulation time (s)0 20 40 60 80

0

0.2

0.4

0.6

0.8

1

IOL

queu

e ra

tio

Simulation time (s)

Figure 7. Outgoing queue ratios of LEO53 with a ¼ 0:8 (adaptive case). All queues follow a similar patternsince there is load splitting between the ISLs and IOL.



DOI: 10.1002/dac

forwarded to the less loaded links. On the other hand, in Figure 7 it can be seen that all ISLs andIOL utilization rates are similar. This is achieved by splitting the traffic over less loaded links.Moreover, link utilization rates are more balanced which assures the system resources to be usedefficiently. In Figure 7, it is seen that the queue ratio Qr oscillates between 0.8 and 0.4. This isbecause of the reason that a is set to 0.8 and k is set to a

2: The proposed scheme ensures that the

background traffic follow the alternate paths in case of Qr reaching the first threshold value. Thepacket deflection (forwarding to alternate paths) continues till Qr reaches the predefinedthreshold k; which is 0.4 in this case.

In Figure 8(a), delay vs a is plotted. It is seen that with the increase in a; average delay valuesalso increase with the exception of LDV. Since LDV traffic is routed through the upper MEOlayer, it is slightly affected by the change in a value. On the other hand, background and SDVtraffic are directly affected. Figure 8(a) indicates that increasing a values yields longer queuesand therefore longer queueing delays. ‘Conversational’ corresponds to the all conversationaltraffic class with no classification of LDV or SDV. It should be noted that a ¼ 1 corresponds tothe case where no load balancing is applied. It is clear that application of ARPQ improves boththe conversational and background traffic performance. With no load balancing, meanconversational delay values are around 240 ms; which causes degradation in the performance ofvoice communication. The decrease in conversational delay values in case of a ¼ 1 is caused bythe increase in the background packet drop ratio. Moreover, since overflow traffic is droppedinstead of being directed to MEO layer or alternate paths, LDV traffic experiences less queueingdelay. Hence LDV, SDV and overall conversational delay decrease. This comes at the expenseof more packet drops of background traffic. In our scheme, since no prioritization is donebetween delay and jitter-sensitive traffic and best-effort traffic, LDV and SDV experience asmuch queueing delay as background traffic. In the following subsections, effect of trafficprioritization will be examined. The exact delay values can be seen in Table IV. With a ¼ 0:2;the jitter of conversational traffic is around 70 ms which might be acceptable. The increase inqueueing delay increases the delay jitter too. Actually, much of background traffic is forwardedto other links in case of low a values and might result in larger jitter values compared to higher avalues. But, effect of queueing delay dominates the effect of change in the path of backgroundtraffic. Like the decrease in LDV delay, LDV jitter also decreases due to lighter load in MEO

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1150

200

250

300

350

400

450

500

550

600

650

Queue ratio threshold

OverallBackgroundConversationalLDVSDV

(a)0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

24

26

28

30

32

34

36

38

Queue ratio threshold

Ove

rall

pack

et lo

ss (

%)

(b)

Figure 8. (a) Effect of queue ratio threshold a on traffic delay values ðk ¼ a=2Þ and (b) effect of queue ratiothreshold a on network packet loss rate ðk ¼ a=2Þ:



DOI: 10.1002/dac

layer. By the application of priority queueing, jitter and delay values of conversational trafficcan be decreased to more acceptable levels.

Figure 8(b) depicts the overall packet loss with increasing values of a: With the increase invalues of a; packets experience longer queues thereby there is a higher probability of packet loss.This can also be seen from the figures as an increase in packet loss rate and decrease in overallthroughput. The loss rate drastically increases when a ¼ 1 corresponding to the non-adaptiverouting scheme. The loss rate is about 38% which is significantly larger than the loss rate of theclosest test point a ¼ 0:9: In case of a being 0.9, the loss rate is about 28%. Actually, therecorded packet loss rate is usually very large in our simulations, which might be caused bysome OPNET-related issues. Therefore, we consider these values solely to make a comparisonbetween the simulation results. One more point to be considered is that there seems to be a slightdifference in packet loss rate with a ¼ 0:7; 0.8 and 0.9. This may be due to the reason that theproposed scheme does not have enough time to forward the overflow traffic to alternate pathsbefore they are being dropped.

5.3. Effect of queueing mechanism

In the following experiments, we apply a non-preemptive, strict priority scheduling mechanismon board the satellites. In strict priority scheduling policy, the voice packets are always servedbefore the background packets. This will ensure voice traffic not to have long queueing delaysdue to heavy background traffic. On the other hand, background traffic experiences longer delayand jitter values. However, due to the nature of background traffic, long delay and jitter valuesdo not degrade its performance. The only point to be considered about the background traffic ispacket loss rate. In the following scenarios, we set the system parameters as a ¼ 0:4; b ¼ 0:8;Dthrsh ¼ 80 ms and traffic load is 85% (25% voice and 60% background). Figure 9(a) elucidatesthe change in average traffic delays by the application of strict priority queueing. Effect of thepolicy change on LDV and SDV delay values can be seen in Figure 9(b). As the figures show,background traffic delay increases as opposed to decrease in conversational traffic, both LDVand SDV. The main contribution of policy change is the noticeable decrease in SDV traffic.Because SDV traffic is routed on the same route as background packets, it is exposed tocongestion in case of heavy background traffic load. Hence, the application of strict prioritysignificantly improves SDV performance. The delay and jitter values which are beyond the

Table IV. Effect of queue ratio threshold a on traffic delay values ðk ¼ a=2Þ:

Average delay of all traffic types (ms)

a Overall Background Conversational LDV SDV

0.1 264 299 194 184 2020.2 254 284 187 189 1820.4 316 369 204 184 2330.6 376 452 221 178 2940.7 440 527 242 205 3070.8 474 572 254 208 3450.9 515 627 267 211 3781 (non-adaptive) 401 496 240 165 342



DOI: 10.1002/dac

acceptable good quality communication limits are now decreased to acceptable levels. By theapplication of strict priority policy, background delay jitter goes up to 266 ms from 214 ms;while conversational jitter goes down to 28 ms from 82 ms:

0

50

100

150

200

250

300

350

400

450

500FIFOStrictw=25%w=60%w=50%

Overall Background Conversational(a)0

50

100

150

200

250

300FIFOStrictw=60%w=50%w=25%

LDV SDV(b)

Figure 9. (a) Effect of queueing mechanism on end-to-end delay of all traffic types and (b) effect ofqueueing mechanism on end-to-end delay of conversational traffic LDV and SDV.

Table V. Effect of queueing mechanism}simulation results.

Average delay (ms) Delay jitter (ms)

GSid Policy Background Conversational Background Conversational

GS8 FIFO 357 190 244 121Strict 442 100 330 46

wconv ¼ 25% 407 173 334 122wconv ¼ 50% 338 124 290 56wconv ¼ 60% 356 126 284 56

GS58 FIFO 514 169 266 21Strict 674 166 317 22


GS107 FIFO 404 202 222 92Strict 469 163 243 33


GS230 FIFO 240 197 161 100Strict 337 105 220 45




DOI: 10.1002/dac

In order to see the impact of the change in queueing mechanism on individual communi-cations, three GS pairs are taken as reference communication and their correspondingperformance metrics are recorded. GS58 communicates with GS121 which is quite far resulting insix LEO hops in the static topology. GS107 similarly communicates with GS182 that is five LEOhops away from it. GS8 and GS230 have sessions with closer parties in different regions, GS261and GS146; respectively. We conduct three simulations with wconv set to 25, 50 and 60%. InTable V, average delay and jitter values of the communications initiated by the predeterminedGSs are listed. The most prominent decrease in conversational delay is observed at GS230: Thisis due to the route consisting of many LEO hops of this communication. The performance ofGS58 and GS107 is slightly improved since they are already prevented from congestion by GS58and GS107 traffic being forwarded to MEO layer. Note that voice communication will have thedesired level of quality, but background traffic will suffer from more packet loss (36%) than theusual case of 30% packet loss in FIFO scheduling. Hence, we should better apply WRRQ tosatisfy the quality requirements of both traffic type. The table shows that giving more priority tovoice traffic improves the performance by decreasing the delay and jitter values. On the otherhand, background traffic delay and jitter values increase with the increasing values of wconv:Background traffic packet loss rate depending on the scheduling policy and weight values ofconversational traffic ðwconvÞ is plotted in Figure 10. The first and last point in the x-axiscorresponds to FIFO scheduling and strict priority scheduling, respectively. With the increase invoice prioritization ðwconvÞ; background traffic experiences more delays in the queues. Queuesizes grow longer with many background traffic packets waiting to be served. Thereby, overflowtraffic is dropped. Note that there is a great difference between the strict priority policy andFIFO scheduling policy. The application of WRRQ seems to perform better satisfying therequirement of both traffic types.

6. CONCLUSIONS

In this article, we have investigated the performance issues of delay-sensitive traffic, specificallyVoIP, in satellite networks and proposed a novel adaptive routing algorithm for multi-layered

25% 50% 60%30

31

32

33

34

35

36

Conversational traffic weight B

ackg

roun

d tr

affic

pac

ket l

oss

rate

(%

)

FIFO scheduling

Strict priority scheduling

Figure 10. Background traffic packet loss rate depending on the values of conversationaltraffic weight wconv:



DOI: 10.1002/dac

satellite networks. The proposed scheme ARPQ uses real-time network information to balancethe load on the satellite links. Load balancing helps the system resources to be efficiently usedand also prevents congestion in bottleneck links. In the ARPQ scheme, each LEO satellitecontrols its traffic flow rate to its neighbours and in case of a sign of congestion in one of thelinks, some portion of background traffic is deflected to other less loaded links. Since this isa kind of self-control mechanism, ARPQ achieves load balancing without additional signallingoverhead. The simulation results show that ARPQ has substantially improved the performanceof real-time traffic.

We have limited the scope of our interest to the OBP functions. That is, we are only concernedwith the mechanisms applied on board the satellite to improve the performance of delay-sensitive applications. It is of no doubt that the application of performance enhancingmechanisms (e.g. jitter buffers, comfort noise generation, etc.) in the terrestrial part of thenetwork amends the performance. The results indicate that OBP, enabling multi-layeredconstellations and QoS mechanisms, are of great importance for performance enhancement insatellite networks. With this ability, good-quality VoIP over satellite is feasible.

Further work includes more realistic modelling of the satellite channels and addition offorward error correction (FEC) mechanisms. Moreover, non-uniform traffic distribution overthe Earth and during the day needs to be considered to see how our mechanism performs in caseof realistic traffic patterns.

REFERENCES

1. Hu Y, Li VOK. Satellite-based Internet: a tutorial. IEEE Communications Magazine 2001; 39(3):154–162.2. Henderson TR. Networking over next-generation satellite systems. Ph.D. Dissertation, University of California at

Berkeley, California, Fall 1991.3. Ibnkahla M, Rahman QM, Iyanda A. High-speed satellite mobile communications: technologies and challenges.

Proceedings of the IEEE, Special Issue on Gigabit Wireless Communications: Technologies and Challenges, February2004; 312–339.

4. Chen C, Ekici E. A routing protocol for hierarchical LEO/MEO satellite IP networks. ACM-Springer Journal ofWireless Networks (WINET). 2005; 11(4):507–523.

5. Sheriff RE, Hu YF. Mobile Satellite Communication Networks. Wiley: New York, 2001.6. Dash D, Durresi A, Jain R. Routing of VoIP traffic in multi-layered satellite networks. Proceedings of Performance

and Control of Next-Generation Communications Networks, Orlando, FL, vol. 5344, September 2003; 65–75.7. Lee J, Kang S. Satellite over satellite (SOS) network: a novel architecture for satellite network. Proceedings of IEEE

INFOCOM, Tel Aviv, Israel, vol. 1, March 2000; 315–321.8. Chen C, Ekici E, Akyildiz IF. Satellite grouping and routing protocol for LEO/MEO satellite IP networks.

Proceedings of WoWMoM 2002, Atlanta, GA, September 2002; 109–116.9. Ekici E, Akyildiz IF, Bender MD. Datagram routing protocol for LEO satellite networks. Proceedings of

INFOCOM, Tel Aviv, Israel, March 2000; 500–508.10. Akyildiz IF, Ekici E, Bender M. MLSR: a novel routing algorithm for multilayered satellite IP networks. IEEE/

ACM Transactions on Networking 2002; 10(3):411–424.11. Akyildiz IF, Ekici E, Yue G. A distributed multicast routing scheme for multi-layered satellite IP networks.Wireless

Networks 2003; 9(5):535–544.12. Wu FG, Sun FC, Yu K, Zheng CW. Performance evaluation on a double-layered satellite network. International

Journal of Satellite Communications and Networking 2005; 23(6):359–371.13. Zhao ZW, Zhang J, Sun F, Li L, Chen IM. Routing strategy for satellite-based networks with a hierarchical space

grid architecture. Proceedings of Fourth IEEE International Conference Information, Communication and SignalProcessing (ICICS-PCM), Singapore, December 2003.

14. Durresi A, Dash D, Anderson BL, Kannan R, Kota S, Jain R. Routing of real-time traffic in a transformationalcommunications architecture. Proceedings of IEEE Aerospace Conference, Big Sky, MT, March 2004; 1086–1104.

15. Peng J, Sikdar B. Multilayer multicast congestion control in satellite environments. IEEE Journal on Selected Areasin Communications 2004; 22(3):449–461.

16. Hu JH, Yeung KL. Routing and re-routing in a LEO/MEO two-tier mobile satellite communications system withinter-satellite links. Proceedings of ICC, New Orleans, LA, U.S.A., June 2000; 134–138.



DOI: 10.1002/dac

17. Verma S, Wiswell E. Next generation broadband satellite communication systems. Proceedings of 20th AIAAInternational Communication Satellite Systems Conference and Exhibit, Montreal, Quebec, CA, May 2002.

18. Eckhardt G. On-board processing. Space Communications 2001; 17:1–3.19. Janssen J, Vleeschauwer DD, Petit GH, Windey R, Leroy JM. Delay bounds for voice over IP calls transported over

satellite access networks. Mobile Networks and Applications 2002; 7(1):79–89.20. Taleb T, Kato N, Nemoto Y. IP traffic load distribution in NGEO broadband satellite networks. Springer Lecture

Notes in Computer Science (LNCS), vol. 3733. Springer: Berlin, 2005; 113–123.21. Nanba S, Konishi S, Nomoto S. Optimum traffic distribution algorithm for multiple-satellite systems under power

constraints. IEEE Journal on Selected Areas in Communications 2004; 22(3):492–500.22. Kucukates R, Ersoy C. High performance routing in a LEO satellite network. Proceedings of Eighth IEEE

Symposium on Computers and Communications (ISCC), Antalya, Turkey, 2003; 1403–1408.23. Jianjun B, Xicheng L, Zexin L, We P. Compact explicit multi-path routing for LEO satellite networks. Proceedings

of IEEE Workshop. High Performance Switching and Routing, Hong Kong, People’s Republic of China, May 2005.24. McMahon G, Septiawan R, Sugden S. A multiservice traffic allocation model for LEO satellite communication

networks. IEEE Journal on Selected Areas in Communications 2004; 22(3):501–507.25. Kota S, Marchese M. Quality of service for satellite IP networks: a survey. International Journal of Satellite

Communications and Network 2003; 21:303–349.26. Jianjun B, Xicheng L, Zexin L, Wei P. A distributed hierarchical routing protocol for non-GEO satellite networks.

Proceedings of ICPP Workshops, Washington, DC, U.S.A., 2004; 148–154.27. Mauger R, Rosenberg C. QoS guarantees for multimedia services on a TDMA-based satellite network. IEEE

Communications Magazine 1997; 35(7):56–65.28. Bayhan S, Gur G, Alagoz F. VoIP performance in multi-layered satellite IP networks with on-board processing

capability. Proceedings of IEEE 7th International Symposium on Computer Networks (ISCN’06), Istanbul, Turkey,June 2006; 197–202.

29. Korcak O, Alagoz F, Jamalipour A. Priority-based adaptive routing in NGEO satellite networks. InternationalJournal of Communication Systems, in press. DOI: 10.1002/dac.823

30. Mohorcic M, Werner M, Svigelj A, Kandus G. Adaptive routing for packet-oriented intersatellite linknetworks: performance in various traffic scenarios. IEEE Transactions on Wireless Communications 2002; 1(4):808–818.

31. OPNET Technologies Inc. Bethesda, MD, U.S.A., http://www.opnet.com

AUTHORS’ BIOGRAPHIES

Suzan Bayhan received her BSc and MSc degrees in computer engineering from

Bogazici University, Istanbul, Turkey in 2003 and 2006, respectively. Currently, she

is a researcher at Satellite Networks Research Laboratory (SATLAB) in the Bogazici

University. Her main research interests include satellite networks, next-generation

networks, mobile applications, performance evaluation and system simulation.

Gurkan Gur received a BSc degree in electrical engineering in 2001 and an MSc

degree in systems and control engineering in 2005, both from the Bogazici University,

Istanbul, Turkey. Currently, he is pursuing a PhD degree in computer engineering,

and working as a researcher at Satellite Networks Research Laboratory (SATLAB)

in the Bogazici University. He has been involved in development of various telecom

products in industry as a software developer. His research interests include QoS in

VoIP and next-generation networks, 3G and beyond-3G heterogeneous networks,

signal processing for communications, transport protocols over wireless networks,

and multimedia communications.



DOI: 10.1002/dac

Fatih Alagoz is an Associate Professor in the Department of Computer Engineering,

Bogazici University, Turkey. He is also affiliated with the Department of Electrical

Engineering, Harran University, Sanlıurfa, Turkey. From 2001 to 2003, he was with

the Department of Electrical Engineering, United Arab Emirates University, AlAin,

U.A.E. In 1993, he was a Research Engineer in a missile manufacturing company,

Muhimmatsan AS, Turkey. He received the BSc degree in electrical engineering from

Middle East Technical University, Turkey, in 1992, and MSc and DSc degrees in

electrical engineering from The George Washington University, U.S.A., in 1995 and

2000, respectively. His current research interests are in the areas of satellite networks

and wireless/mobile networks, UWB communications. He has contributed/managed

to seven research projects for various agencies/organizations including US Army of

Intelligence Center, Naval Research Laboratory, State Planning Organization of Turkey, TUBITAK,

BAP, etc. He has edited five books and published more than 60 scholarly papers in selected journals and

conferences. Dr Alagoz is the Satellite Systems Advisor to the Kandilli Earthquake Research Institute,

Istanbul, Turkey. He has served on several major conferences technical committees and organized and

chaired many technical sessions in many international conferences. He is a member of the IEEE Satellite

and Space Communications Technical Committee. He has numerous professional awards.



DOI: 10.1002/dac

Performance of delay-sensitive traffic in multi-layered satellite IP networks with on-board...

Documents

Transcript of Performance of delay-sensitive traffic in multi-layered satellite IP networks with on-board...