Citation
A Delay-Efficient Satellite Network for Multimedia Communication: A Pilot Study

Material Information

Title:
A Delay-Efficient Satellite Network for Multimedia Communication: A Pilot Study
Copyright Date:
2008

Subjects

Subjects / Keywords:
Artificial satellites ( jstor )
Communications satellites ( jstor )
Earth stations ( jstor )
Hybrid systems ( jstor )
Low earth orbits ( jstor )
Propagation delay ( jstor )
Satellite constellations ( jstor )
Simulations ( jstor )
Traffic delay ( jstor )
Traffic loads ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
5/4/2002
Resource Identifier:
52213129 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

A DELAY-EFFICIENT SATELLITE NETWORK FOR MULTIMEDIA COMMUNICATION: A PILOT STUDY By MARK FOSTER A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Mark Foster

PAGE 3

ACKNOWLEDGMENTS I would like to begin with expressing my many thanks to the chair of my committee, Dr. Liu. Without his advice and incredible patience, this work would not have been possible. I would also like to thank the other members of my committee, Dr. Dankel and Dr. Wilson. Very early in my graduate career, prior to beginning any research, I would not have known where to begin without their wonderful guidance. I would also like to thank my wonderful wife, Carrie, whose unwavering support has helped me tremendously. iii

PAGE 4

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iii LIST OF TABLES.............................................................................................................vi LIST OF FIGURES..........................................................................................................vii ABSTRACT.....................................................................................................................viii CHAPTERS 1 INTRODUCTION...........................................................................................................1 2 BACKGROUND OVERVIEW.......................................................................................8 GEO................................................................................................................................8 LEO.................................................................................................................................9 Additional Terminology and Acronyms.......................................................................14 3 PERFORMANCE ANALYSIS AND PROPOSED SCHEME.....................................16 GEO Analysis...............................................................................................................16 LEO Analysis................................................................................................................19 Proposed Hybrid...........................................................................................................22 4 IMPLEMENTATION AND PERFORMANCE RESULTS.........................................25 System Implementation................................................................................................26 Intracontinental Transmissions.....................................................................................33 Intercontinental Transmissions in the Northern Hemisphere.......................................37 Intercontinental Transmissions from Different Hemispheres.......................................44 Real Life Population Based Transmissions..................................................................50 5 CONCLUSION..............................................................................................................57 APPENDIX........................................................................................................................59 Satgeometry.cc..............................................................................................................59 Sathandoff.cc................................................................................................................63 iv

PAGE 5

Satlink.cc.......................................................................................................................72 Satroute.cc.....................................................................................................................88 LIST OF REFERENCES...................................................................................................98 BIOGRAPHICAL SKETCH...........................................................................................100 v

PAGE 6

LIST OF TABLES Table Page 1. Estimated GEO End-to-End Delays...........................................................................19 2. Estimated LEO End-to-End Delays...........................................................................21 3. Component System Parameters for LEO...................................................................23 4. Comparison of Tables I and II...................................................................................23 5. NY to Paris--Percent Improvement...........................................................................43 6. NY to Sydney--Percent Improvement.......................................................................50 7. Real Life--Percent Improvement...............................................................................55 vi

PAGE 7

LIST OF FIGURES Figure Page 1. -Constellation...........................................................................................................11 2. 2-Constellation.........................................................................................................11 3. NY to LA--Base Case................................................................................................34 4. NY to LA--Moderate Traffic.....................................................................................35 5. NY to LA--Heavy Traffic..........................................................................................36 6. NY to Paris--Base Case.............................................................................................38 7. NY to Paris--Moderate Traffic..................................................................................39 8. NY to Paris--Heavy Traffic.......................................................................................41 9. NY to Sydney--Base Case.........................................................................................45 10. NY to Sydney--Moderate Traffic..............................................................................47 11. NY to Sydney--Heavy Traffic...................................................................................48 12. Ten Pairs of Cities......................................................................................................52 13. Twenty Five Pairs of Cities.......................................................................................53 14. Fifty Pairs of Cities....................................................................................................55 vii

PAGE 8

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science A Delay-Efficient Satellite Network for Multimedia Communication: A Pilot Study By Mark Foster May, 2002 Chairman: Jonathan C. Liu Major Department: Computer and Information Science and Engineering In recent years low earth orbit (LEO) satellites have begun to attract much attention. This attention is largely due to their relatively small propagation delays (~5 to 10ms) when compared with that of geostationary earth orbit (GEO) satellites (~120 ms). However, due to the inherent nature of a LEO satellite network, transmissions very often require hopping through a large number of satellites. Anytime that a transmission must travel through a number of nodes we must consider the processing delay of each node when calculating the end-to-end delay. This thesis analyzes and observes that the total delay experienced in a LEO satellite network can sometimes result in a longer end-to-end delay than routing through a GEO satellite network. We thus proposed a hybrid satellite network of LEO and GEO satellites that might best minimize end-to-end delays. Both a LEO and a hybrid system were designed and simulated using Network Simulator (NS). The results show much smaller end-to-end delays (e.g., 46%) when transmitting through our hybrid satellite network than a strictly LEO satellite network. viii

PAGE 9

CHAPTER 1 INTRODUCTION With the use of satellites, one can send or receive transmissions from almost any point around the globe. With the ability to send transmissions, the desire to support broadband traffic soon follows. The ultimate goal is to support multimedia communication. As a pilot study, this thesis analyzes the behavior and capabilities of satellite networks with a focus on end-to-end delays. The end-to-end delays are analyzed using network traffic similar to traffic generated from applications such as Telnet or SSH. Future goals include expanding this work to support multimedia traffic. Similar approaches have been taken by others who face similar challenges in the goal of supporting multimedia communications [10]. The two most common types of satellites are geostationary earth orbit satellites and low earth orbit satellites. Geostationary earth orbit satellites (also referred to as GEOs) are at an altitude of 35,000 km. At this altitude, a satellite has the same angular velocity as the earth and therefore remains in a fixed position above the earth. This type of satellite suffers from a long propagation delay of roughly 120 ms. Low earth orbit satellites (also referred to as LEOs) orbit at an altitude of less than 1,500 km. At such an altitude, the propagation delay is lessened to about 5 to 10 ms. However, satellites in this orbit are moving very fast with respect to the earth. A satellite in this orbit is usually only visible to an earth station for no more than about 10 minutes. Due to the small propagation delay, low earth orbit (LEO) satellites have become the subject of much research. However, LEO satellites face many challenges as a result 1

PAGE 10

2 of their fast speeds and small footprints. To provide global coverage with LEO satellites a large number of satellites is required. Some of the more noTable 5entures that have attempted to do this have been Iridium and Teledesic [9]. Iridium has already launched a satellite system containing 66 low-earth orbit satellites. Teledesic has proposed a system of 288 low-earth orbit satellites. Iridium had hoped to provide nearly global coverage for cellular phones, while Teledesic is aimed at being the first broadband satellite system to create an “Internet in the sky.” While LEO satellites seem undoubtedly superior to GEO satellites, we demonstrate that this perception may not be entirely accurate. Some studies have attempted to compare these two types of satellites based solely on the distances [1]. In this paper we jointly discuss many factors to affect the end-to-end delay of a transmission. For example, while a GEO satellite can enable a transmission to travel nearly to the opposite side of the globe, a comparable journey through a LEO satellite network would require at least a dozen hops through different LEO satellites. In addition, we analyze the effect of distance and population on the end-to-end delay of a transmission. In this thesis, we have analyzed the performance of the end-to-end delay through a GEO or LEO satellite network. The goal of this thesis is to intelligently determine what type of satellite network will best minimize the end-to-end delay of its traffic, when considering the possibility of a processing delay at each satellite. This processing delay may be an effect of heavy traffic loads, demodulating, remodulating, or even the redirecting of satellite antennas. In addition, processing delays could be incurred from the software side of routing. In a LEO satellite network, the topology is constantly

PAGE 11

3 changing. Satellite links are constantly being activated and deactivated. This may lead to additional IP table lookups and modifications to a packet or packet header that would normally not be necessary in a static topology. Furthermore, accessing a packet’s priority field, or any other field of a packet can add to the processing delay. Regardless, it must be taken into account when calculating the end-to-end delay of a transmission through a satellite network. We have proposed a new satellite network. This satellite network includes LEO and GEO satellites to create a hybrid (and intelligent) satellite network. The purpose of this hybrid satellite network is to take advantage of the positive aspects of both types of satellites, to achieve the goal of minimizing the end-to-end delays. From our performance models it was realized that if the processing delay of each satellite in a LEO satellite network begins to exceed about 20 ms, and a transmission requires more than 7 or 8 hops, then it become faster to route through our proposed satellite network. In addition, for a transmission to travel to the opposite end of the globe, it very often requires at least a dozen or more LEO satellites. This would indicate that the presence of a GEO component in our hybrid satellite network could be very advantageous. Due to the lack of access to the physical satellite networks, we implemented the proposed satellite network using the NS-2 simulator [12]. We designed two networks of satellites. The first network only contained LEO satellites and was modeled after the proposed Teledesic satellite network. The second, was a replica of the first with the addition of a GEO component. This GEO component included three evenly spaced GEO satellites. The addition of the GEO component created what is referred to as our Hybrid system. Both these systems were tested under the same conditions.

PAGE 12

4 It is easy to reason that the closer a pair of source and destination nodes are, the shorter the distance a transmission has to travel. From our simulations, we quickly learned that this is not always the case. While the distance between New York City and Sydney, Australia is far greater than the distance between New York City and Paris, France; the average number of hops required to make those two trips only differs by one. A transmission from NY to Sydney averaged about 14 hops, while a transmission from NY to Paris averaged about 13 hops. The reason behind this is that a trip from NY to Paris requires traveling around a cross-seam. 1 This same transmission is also affected by the latitude threshold to avoid the north pole. The north and south poles are also sources of cross-seams. These two factors greatly increase the number of hops, which in turn increases the end-to-end delay. Furthermore, it should be pointed out that when the number of hops increases, this also increases the effect of a processing delay on the end-to-end delay of a transmission. Most simulations were run with three different traffic sets. The first set was the base case. In the base case, there was only 1 transmitting node and only 1 receiving node. This allowed the transmitting node to freely send transmissions without the risk of collision. This base case allows us to observe the behavior of the system without any effects from our medium access control protocol. In some base cases we observed our proposed system outperform the LEO system by as much as 348 ms on end-to-end delay. This was a very significant reduction of 46% in end-to-end delay performance. The second set was considered to be a moderate traffic load. This moderate traffic load is supposed to reflect what current day satellite traffic is most like. This moderate load of 1 The cross-seam mentioned in this segment refers to the point where north bound orbital planes are adjacent to the south bound orbital planes. Due to the satellites moving in opposite directions, intersatellite links over a cross-seam are extremely difficult and are

PAGE 13

5 traffic consists of 10 transmitting nodes and 10 receiving nodes. Having multiple senders contending for the same satellite allows us to analyze the performance of our medium access control protocol. In every simulation, when the traffic load was increased from the base case to the moderate load we witnessed an average increase in end-to-end delay of at least 124 ms. In some cases, the end-to-end delay increased as much as 133 ms. This allowed us to see the drastic effect of our MAC protocol, which in this thesis is Slotted ALOHA. However, despite the MAC protocol we still witnessed cases where the Hybrid system would reduce the end-to-end delay by 348 ms. Although, since the overall end-to-end delay had been increased this was now only a 40% reduction. This reduction is a tremendous improvement. It was commonly found that the millisecond difference between the LEO end-to-end delay and the Hybrid end-to-end delay stays relatively constant as the traffic increases. However, the percent reduction of the Hybrid system begins to decrease as the traffic increases, since the overall end-to-end delays have increased with the higher traffic load. The last set was a heavily loaded set. This set consisted of 100 transmitting nodes and 100 receiving nodes. With the increase to this heavy traffic load from our moderate load the end-to-end delays increased again. In every simulation the increase in end-to-end delay was at least 670 ms. On average, the end-to-end delays increased at least 700 ms. This makes an increase of over 800 ms when comparing the heavy traffic load with the base case. However, even with the heavy traffic loads, the Hybrid system was still decreased over 300 ms when compared with the LEO system. This showed us that while the traffic load and MAC protocol definitely have an effect on the end-to-end delay, they do not inhibit the ability of the Hybrid system to consistently outperform the LEO system. often ruled out. Our simulations did not support cross-seam ISLs.

PAGE 14

6 To further explore the abilities of the proposed Hybrid system, some tests were run with what we refer to as “real life” conditions. In other words, rather than randomly selecting meaningless coordinates around the globe to use for the ground stations, the coordinates of the world’s larger cities were used. It is firmly believed that areas of larger populations have larger amounts of telecommunications traffic. Clearly, the places around the globe with the larger populations are the larger cities. By distributing the transmitting and receiving nodes around the world in the larger cities, we hoped to get a even more realistic set of results. This type of simulation was run for 10, 25, and 50 pairs of cities. The results of these simulations were most impressive. It was found that in some cases by using our proposed network, the end-to-end delay was reduced by as much as 40%. In some instances, over 300 ms was removed from the end-to-end delay. The simulation results also showed that there was significant improvement in the end-to-end delay even when processing delays were much less than 20 ms. It still remains that for transmissions that do not travel great distances, that a LEO satellite network is probably ideal. However, for greater distances, like when transmitting from one continent to another, there is a great potential for reducing end-to-end delays. We have shown in this thesis that by using a hybrid system that contains LEO and GEO satellites is one definite way to reduce end-to-end delays. The remainder of this thesis consists of the following sections: Background Overview, Performance Analysis and Proposed Scheme, Implementation and Performance and a conclusion. The background overview discusses the definitions of LEO and GEO satellites. Discussion of orbital parameters for both types of satellites takes place in this section. In the following chapter is a performance analysis of both

PAGE 15

7 GEO and LEO satellites. In this same chapter we propose a new Hybrid satellite network. In Chapter 4 the implementation with NS-2 is discussed. The performance of the LEO and Hybrid satellite networks is addressed in Chapter 4. The last chapter is a conclusion.

PAGE 16

CHAPTER 2 BACKGROUND OVERVIEW GEO A Geostationary Earth Orbit (GEO) is an orbit around the earth where a satellite maintains a fixed position relative to the earth. To achieve this orbit a satellite must be at an altitude of 35,000 km [6]. In addition, the satellite needs to be in an equatorial orbit, or more simply, directly above the equator. A satellite placed in this orbit has the same angular velocity as the earth. There are a number of advantages when dealing with satellites in a geostationary earth orbit. Three major advantages are the following: The location of a satellite is always known, Sunlight is blocked by the earth for only a short portion of the day, and A GEO satellite has an extremely large footprint. Communication with a satellite is much easier when you always know where the satellite is located. In addition, since most satellites are fueled by solar power, it is helpful to not have the earth blocking a satellite’s sunlight for very long. The portion of the earth visible by a satellite is referred to as its footprint. A single GEO satellite can cover more than a third of the earth. This allows a transmission to travel almost completely around the earth with only a single hop. The entire earth can be covered with only three GEO satellites. However, a GEO satellite does have its disadvantages. The major disadvantages of a GEO satellite are: 8

PAGE 17

9 Large propagation delay, Geostationary orbital plane is almost full, and A GEO satellite has an extremely large footprint. A signal sent from earth, traveling at the speed of light, takes roughly 120 ms to reach the satellite [1]. Since most GEO satellites only act as a repeater, that 120 ms is then doubled for the signal to be sent back down to earth. Then for our destination to send a response, the original sender has to wait another roughly 240 ms for the response to be sent to the satellite and then back down to earth. In computer terms, this takes an “eternit.” Furthermore, there cannot be two GEO satellites at 56 degrees longitude. Today’s standard is that each GEO satellite must be 3 degrees away from each neighboring satellite. Since the technology of this type of satellite has been around for many years, the orbital plane is nearing saturation. In addition, a large footprint while being an advantage, can also be a disadvantage. As the size of a satellite’s footprint grows, the more ground stations that will need to communicate with this satellite. The more ground stations competing for the satellite, the less bandwidth for each ground station. LEO Much closer to earth we find an orbital area far different than the Geostationary Earth Orbit (GEO). The orbital area that would be defined with any altitude less than 1,500 km is known as the Low Earth Orbit (LEO) [4]. A LEO satellite orbits the earth in a manner very different from that of a GEO satellite. The author first explains the orbital parameters of a LEO satellite system and then revisit these parameters with an analysis of advantages and disadvantages.

PAGE 18

10 First, it is important to point out that a LEO satellite has a much smaller footprint than a GEO satellite. While a GEO satellite can cover more than a third of the earth, a LEO satellite might only cover an area twice the size of Texas. Exactly how much a LEO satellite can cover is determined by a number of orbital parameters that are addressed shortly. It is also important to note that most LEO satellites orbit the earth in a primarily north-south direction. One of the more notable characteristics of a LEO satellite is the inclination angle of its orbital plane. The inclination angle is the angle between the orbital plane and the equator [4]. An orbital plane with an inclination angle of 90 degrees is considered to be a polar orbit [3]. This polar orbit earns its name since the satellite crosses directly over both the north and south poles. Knowing the approximate size of a LEO footprint, one realizes it takes many LEO satellites to cover the earth. In fact, it takes at least a dozen or so, evenly spaced LEO satellites to provide coverage throughout a single orbital plane. In addition, for complete coverage of the earth, multiple orbital planes are required. For complete global coverage with LEO satellites, it requires a number of orbital planes with each plane having a number of satellites. Essentially, we must create a constellation of LEO satellites around the earth for the complete coverage of the earth. Now that we can visualize a dozen or so orbital planes, with a dozen or so satellites in each, we can now divide LEO constellations into two groups. The first group is known as the p constellations [2]. In a p-constellation, all the southbound halves of the orbits are on one side of the earth, while all the northbound halves of the orbits are on the other side of the earth. See Figure 1. below. The second group is known as the 2p-constellations [2]. 2p-constellations are where adjacent orbital planes are moving in opposite directions. See Figure 2. below. In either of these groups we are introduced to

PAGE 19

11 another aspect of a LEO constellation, the cross-seam [2]. A cross-seam is a point where satellites in adjacent orbital planes are moving in opposite directions. In a 2p-constellation, the entire system is filled with cross-seams. In a p-constellation there are only two cross-seams, they are at the two points where the northbound halves of the orbits meet up with the southbound halves of the orbits. Figure 1: -Constellation Figure 2: 2-Constellation

PAGE 20

12 A ground station is able to communicate with a LEO satellite when the satellite is directly overhead. Clearly, a ground station is not able to communicate with a LEO satellite when the satellite has dropped below the horizon. The point at which a ground station no longer attempts to communicate with a LEO satellite is known as the Minimum Elevation Angle (or Elevation Mask Angle) [4]. The minimum elevation angle is created by an imaginary line connecting the ground station to the satellite, and with a line tangent to the earth at the point of the ground station. Lastly, we mention the speed of a LEO satellite. A LEO satellite, being at such a low orbit, travels at a tremendous speed. The speed of a LEO satellite can be calculated using the following equation for velocity: v = SQRT( GMe / r ) [7] G is the gravitational constant with a value of 6.67*10-11 Nm2/kg2. Me is the mass of the earth which is 5.98*1024 kg. The r value is the radius of the earth (6378 km) plus the altitude of the satellite [7]. For the purpose of this paper, an altitude of 1350 km has been chosen. This value was chosen to model the LEO satellites of our simulation after those of the proposed Teledesic satellite system. Using the above equation, this results in a velocity of 7184 m/s. This reinforces the need for many satellites because a satellite moving at that speed is only visible to a single ground station for a matter of minutes. That ground station will then need to communicate with the next satellite, and so on. In summary, a LEO satellite constellation can be described as a dynamic topology of nodes. In the following section the advantages and disadvantages of this topology are analyzed.

PAGE 21

13 The one of the major advantage of a LEO satellite is that even at an altitude of 1,500 km, the propagation delay from the earth to a satellite is no more than about 5 ms. The harsh truth about LEO satellites is that they have a number of disadvantages. Some of these disadvantages are: Ground stations must maintain communication links with moving satellites, Satellites must maintain communication links with each other while in motion, Routing decisions must be made for a dynamic topology, Sunlight is blocked by the earth for a long portion of the day, A LEO satellite has a small footprint, and Communication via cross-seams. The satellites in a LEO system are constantly moving relative to earth. Furthermore, they are not only moving relative to earth, they are moving relative to each other. Communication with a moving object is always a challenge. In this case, a ground station has only a few minutes where it can transmit to a specific satellite, and then it must find, and start transmitting to another satellite. Every few minutes this process is repeated. Not only does this process require a lot of activating and deactivating links, it also requires that a ground station always keep track of the positions of the satellites. The same challenges are faced when dealing with links between two satellites. In addition, finding the optimal route between two points in a network that is constantly changing is difficult. Even if the nodes were moving slower, finding an optimal route through the network is still a challenge due to the distributed nature of the network. Also, communication across a cross-seam is very difficult and often ruled out as an option. This points out the clear disadvantage of a 2p-constellation in that it is filled with cross-seams. Fortunately, a p-constellation only has two cross-seams, still requiring attention,

PAGE 22

14 but not as pressing. There are however additional cross-seams that also affect links between satellites. When two satellites in adjacent planes travel towards one of the poles they begin to approach one another very rapidly, and ultimately switch sides. Due to their tremendous speeds, they pass one another very quickly, leaving the link between almost impossible to maintain [2]. Due to the issue of cross-seams at the poles, the links between satellites in adjacent planes are deactivated when they reach the poles. Usually, a satellite automatically deactivates links with satellites in adjacent planes once it passes what is known as the latitude threshold. The latitude threshold is a predetermined degree of latitude, that when a satellite moves above or below that latitude, it knows it can no longer communicate with satellites in adjacent planes. Additional Terminology and Acronyms When two satellites communicate directly with one another, the link between them is referred to as an Inter-satellite Link (ISL) [6]. When two satellites are in the same orbital plane, their ISL is known as an intra-plane ISL [2]. When two satellites are in different orbital planes, their ISL is known as an inter-plane ISL [2]. The satellite link across a cross-seam is known as a cross-seam ISL. A link between a ground station and a satellite is also referred to as a Ground Station Link (GSL) [4]. Let us revisit the moment when a satellite falls below the minimum elevation angle. If a ground station is transmitting to that satellite, it must start transmitting to another satellite. If there is a continuous communication link, like a phone conversation, that is being transmitted through this satellite then it must be passed to the next satellite. This act of passing a communication channel from one satellite to another is referred to as a handoff. In addition, there are two types of handoffs, synchronous and asynchronous [3]. To explain synchronous handoffs we must first explain the idea of virtual nodes [5]

PAGE 23

15 with respect to a LEO satellite system. The idea behind virtual nodes is that rather than focusing on the dynamic nodes of our given topology, we focus on virtual nodes. These virtual nodes are static and never move. From moment to moment, a virtual node may be embodied by a different satellite. As a satellite moves out of the range of one virtual node, it moves into the range of a new virtual node and begins to embody that new virtual node. Meanwhile, a new satellite has moved into the previous virtual node, and that new satellite is now embodying that virtual node. One convenience of virtual nodes is that, each virtual node also has a static footprint. Theoretically this footprint is covered by whatever satellite is embodying the virtual node. The idea behind synchronous handoffs is that all the satellites move into a new virtual node at the same time and all the handoffs take place simultaneously. Asynchronous handoffs do not require virtual nodes. The way asynchronous handoffs work is that when a ground station reaches the edge of one satellite’s footprint, that ground station begins transmitting to the next satellite. This can take place at different times for different satellites. For the purpose of this thesis the system to be proposed uses an asynchronous approach to activating and deactivating communication links.

PAGE 24

CHAPTER 3 PERFORMANCE ANALYSIS AND PROPOSED SCHEME GEO Analysis We begin by analyzing the end-to-end delay in a GEO satellite system. To do so, we first design an equation that allows us to compute the end-to-end delay when given our system parameters. This equation uses most of the following variables (the rest are used later): N = Number of hops, A1 = Ground Station to Satellite Access Delay, A2 = Satellite to Satellite Access Delay, A3 = Satellite to Ground Station Access Delay, B1 = Bit rate for Ground to Satellite Link, B2 = Bit rate for ISL, H = Height/Altitude, P = GSL propagation delay, I = Intersatellite Ground Link propagation delay, D = Node/Satellite processing delay, and L = Length of message. Our number of hops is defined as the number of satellites that a transmission must pass through to reach its destination. The ground station to satellite access delay is the delay experienced when a ground station first attempts to access a satellite. More than 16

PAGE 25

17 likely, a satellite will be shared among a number of ground stations and they cannot all transmit at the same time. If all the ground stations begin transmitting at the same time, then our transmissions will collide. This is an instance where a medium access control protocol must be chosen. The satellite-to-satellite and satellite-to-ground station access delays are of the same nature. These delays also include the delays experienced if a station is already transmitting and must finish that transmission before it can begin the next transmission. Intersatellite ground link propagation delay is the delay between the time one satellite sends a transmission and a ground repeater receives that same transmission. GSL propagation delay is the same, except we are dealing with a transmission between a normal ground station and the satellite or vice versa. These two propagation delays must be distinguished since the distance between the satellite and the ground stations can be very different from the altitude of the satellites. The Node/Satellite processing delay is the time it takes a satellite to process a transmission before sending that transmission to the next satellite. This delay can be affected by heavy traffic conditions or by the redirecting of satellite antennas. The derived equation is as follows: Equation 1: ( A1 + L/B1 + P) + 2*(N-1)*((A1/2) + D + L/B1 + I) + (A3 + D + L/B1 + P). Glancing at this equation we see where it can quickly be broken down into three terms being added together. The first term, (A1 + L/B1 + P), represents the time it takes to access the satellite, transmit a message, and then let that message propagate up to the satellite. The second term, 2*(N-1)*((A1/2) + D + L/B2 + I), represents the hop from one GEO to another GEO. Since GEO satellites are not known to have ISLs, that hop must be relayed off the ground from a position visible to both satellites. Therefore, this

PAGE 26

18 hop is actually two hops. The transmission is sent to the ground, and then up to the other GEO. This term is multiplied by 2 to account for the two transmissions required to make this hop. This term includes the (N-1) since a transmission that requires N number of GEOs, only makes the off the ground hop only (N-1) times. The rest of this term includes the processing delay, the next hop access delay, transmission delay, and the propagation delay. The A1 is divided by two since the whole term is multiplied by two, and a satellite is only accessed once during an off the ground hop. Notice the propagation delay this time is I instead of P. When transmitting to a GEO satellite directly above, it is safe to calculate the propagation delay using the altitude of the satellite. Although, when transmitting to a GEO satellite that is at an angle, the propagation delay can be longer. The I represents a worst case scenario propagation delay that is likely to be experienced since the ground hop must be visible by both satellites. To be visible by both satellites forces the ground station into a position rather close to the edge of each satellite’s footprint. And lastly the third term, (A3 + D + L/B1 + P), which represents the processing delay, the ground station access delay, transmission delay, and the propagation delay. The following values were used for this equation: A1 = 50 ms, A3 = 1 ms, B1 = 1.5 Mbps, H = 35,000 km, P = 116.7 ms, I = 128.6 ms, and L = 512 bytes Noticeably the ground-to-satellite access delay is much larger than the satellite-to-ground access delay. This is because multiple ground stations are more likely to contend

PAGE 27

19 for the same satellite, than multiple satellites are to contend for a single ground station. This results in a much larger access delay for the ground stations wanting to access the satellite. It is feasible that ground stations are always available to receive transmissions from the satellite. The propagation delay is based solely on the speed of light and the altitude of the satellite. The intersatellite ground link propagation delay is based on the distance the transmission would have to travel when going to the edge of a satellite’s footprint. Since the number of hops and delay per node are not known, we explore a variety of values for those parameters. The results of these computations are shown in the table below. Table 1: Estimated GEO End-to-End Delays 1 ms 5 ms 10 ms 20 ms 25 ms 50 ms 1hop 290.8 294.8 299.8 309.8 314.8 339.8 2hops 605.5 617.5 632.5 662.5 677.5 752.5 This table shows the end-to-end delay for varying values of N (number of hops) and D (processing delay) for Equation 1. Notice that Table 1 does not require more than a maximum of two hops. This is because it only requires three GEO satellites to cover the globe, thus a maximum of two hops, and you have gone around the world. LEO Analysis To make a comparable analysis of a LEO satellite system, the equation has to be modified. The modified equation is as follows: Equation 2: ( A1 + L/B1 + P) + (N-1)*(A2 + D + L/B2 + I) + (A3 + D + L/B1 + P). The main reason for modifying our equation is that LEO satellites can contain Intersatellite Links (ISLs). This removes the need to have any ground station repeaters.

PAGE 28

20 Thus, our middle term no longer needs to be multiplied by two. In addition, the middle term now contains the satellite-to-satellite access delay, rather than the ground-to-satellite access delay it had contained in equation 1. For our parameters we use the following values: A1 = 50 ms, A2 = 5 ms, A3 = 1 ms, B1 = 1.5 Mbps, B2 = 155 Mbps, H = 1350 km, I = 7.5 ms, P = 4.5 ms, and L = 512 bytes. Noticeably the satellite-to-satellite access delay is also smaller than the ground-to-satellite access delay. This is assumed due to two reasons. The first one is that the number of satellites all trying to access the same satellite is limited to the number of satellites that currently have active ISLs with that satellite. The possible number of ground stations for a single satellite is likely to be much larger. In addition, the bit rate of an ISL is proposed to be much higher than the bit rate of a ground to satellite link. Another important point is that for Equation 2, variable I now represents the Intersatellite Link propagation delay. So this value is now based on the distance between two LEO satellites. Since the number of hops and delay per node are not known, we explore a variety of values for those parameters. The results of these computations are shown in the table below. In both tables we see that the end-to-end delay increases as the number of hops and/or processing delay increases. This is no surprise. Also when comparing a single hop through a GEO network with a single hop through a LEO network, the single hop

PAGE 29

21 Table 2: Estimated LEO End-to-End Delays 1 ms 5 ms 10 ms 20 ms 25 ms 50 ms 1 Hop 66.5 70.5 75.5 85.5 90.5 115.5 2 Hops 80.0 88.0 98.0 118.0 128.0 178.0 3 Hops 93.5 105.5 120.5 150.5 165.5 240.5 4 Hops 107.0 123.0 143.0 183.0 203.0 303.0 5 Hops 120.6 140.6 165.6 215.6 240.6 365.6 6 Hops 134.1 158.1 188.1 248.1 278.1 428.1 7 Hops 147.6 175.6 210.6 280.6 315.6 490.6 8 Hops 161.1 193.1 233.1 313.1 353.1 553.1 9 Hops 174.7 210.7 255.7 345.7 390.7 615.7 10 Hops 188.2 228.2 278.2 378.2 428.2 678.2 11 Hops 201.7 245.7 300.7 410.7 465.7 740.7 12 Hops 215.3 263.3 323.3 443.3 503.3 803.3 13 Hops 228.8 280.8 345.8 475.8 540.8 865.8 14 Hops 242.3 298.3 368.3 508.3 578.3 928.3 This table shows the end-to-end delay for varying values of N (number of hops) and D (processing delay) for Equation 2. through a LEO network has a much lower end-to-end delay. The end-to-end delay in the LEO network is at least 224 ms less than that of the GEO network, regardless of processing delay. However, the distance that can be covered with one hop through a GEO network is actually more comparable to the distance that can be covered through a LEO network with about a dozen hops. This essentially compares the performance through each network when a transmission must travel to the opposite side of the earth. For the GEO network, as our processing delay grows from 1ms to 50 ms, our end-to-end delay increases from 290 ms to 339 ms. However, for a 12 hop transmission in our LEO network, as the processing delay grows from 1 ms to 50 ms, our end-to-end delay

PAGE 30

22 increases from 215 ms to 803 ms. At some point between a 1 ms processing delay and a 50 ms processing delay, it become advantageous to use the GEO network rather than the LEO network. More precisely, it appears that somewhere between a 5 and 10 ms processing delay, the GEO network begins to have a smaller end-to-end delay. Proposed Hybrid After analyzing the properties of a GEO satellite system and a LEO satellite system it is easy to see they have very different advantages. It is the hope of the author to propose a sort of hybrid system containing both GEO and LEO satellites to draw upon the advantages of both types of systems. This hybrid system contains a GEO component of three satellites. Three GEO satellites are sufficient to achieve global coverage. The three GEO satellites will be placed at 90, -30, and -150 longitudes. These longitude values were chosen in an attempt to place the GEOs where they will be most useful. They are expected to be most useful in supporting intercontinental transmissions. Our initial calculations showed that the GEO satellites become advantageous when the transmission would require a large number of hops through a LEO system. The LEO component of the system will be largely modeled after the proposed Teledesic system [3,9]. The LEO system will contain 288 satellites evenly distributed into 12 orbital planes. The LEO system will be at an altitude of 1350 km. For clarity, the LEO component parameters are listed in Table 3. If we take a moment and compare the values of Table 1 and Table 2 we can draw some interesting conclusions. The question we must ask is, “At what point does a hop through a single GEO satellite become faster than multiple hops through a LEO network?” Comparing the values of these two tables we can see some break-off points.

PAGE 31

23 Table 3: Component System Parameters for LEO Parameter Value Altitude 1350 km Number of Satellites 288 Number of Orbital Planes 12 Inclination Angle 86.9 Minimum Elevation Angle 40 ISL bit rate 155 Mbps Ground to Satellite bit rate 1.5 Mbps This table shows the system parameters of the LEO component of the proposed hybrid system. The LEO component is modeled after the proposed Teledesic system. [3,9] Table 4 revisits Table 2, with some break-off points found when comparing with Table 1. Table 4 is shown below. Table 4: Comparison of Tables I and II 1 ms 5 ms 10 ms 20 ms 25 ms 50 ms 1 Hop 66.5 70.5 75.5 85.5 90.5 115.5 2 Hops 80.0 88.0 98.0 118.0 128.0 178.0 3 Hops 93.5 105.5 120.5 150.5 165.5 240.5 4 Hops 107.0 123.0 143.0 183.0 203.0 303.0 5 Hops 120.6 140.6 165.6 215.6 240.6 365.6 6 Hops 134.1 158.1 188.1 248.1 278.1 428.1 7 Hops 147.6 175.6 210.6 280.6 315.6 490.6 8 Hops 161.1 193.1 233.1 313.1 353.1 553.1 9 Hops 174.7 210.7 255.7 345.7 390.7 615.7 10 Hops 188.2 228.2 278.2 378.2 428.2 678.2 11 Hops 201.7 245.7 300.7 410.7 465.7 740.7 12 Hops 215.3 263.3 323.3 443.3 503.3 803.3 13 Hops 228.8 280.8 345.8 475.8 540.8 865.8 14 Hops 242.3 298.3 368.3 508.3 578.3 928.3 This table shows where a path through a GEO becomes faster than a path through multiple LEOs.

PAGE 32

24 The end-to-end delay through a single GEO with a 5 ms processing delay was calculated to take about 294 ms. Observing the 5 ms column in Table 4, we see that this is faster than the value computed for 14 hops. A GEO with a 10 ms processing delay was calculated at 299 ms. Looking at Table 4 in the 10 ms column, we see that this GEO would be faster than the values calculated at 11, 12, 13, and 14 hops. The highlighted values are those that the GEO value would be faster than. In the 50 ms column, where a GEO would take 339 ms, we see that it is faster than anything over 4 hops.

PAGE 33

CHAPTER 4 IMPLEMENTATION AND PERFORMANCE RESULTS To test the performance of the proposed hybrid system, it will be tested and compared against a system containing only LEO satellites. This LEO system will have the same system parameters, with just the key difference of no GEO component. This allows for an analysis of the benefit to having a GEO component in our satellite system. To study the behavior of a LEO and a LEO/GEO hybrid system the NS-2 simulator was used. NS-2 is a free simulator available at http://www.isi.edu/nsnam/ns. NS-2 is a Network Simulation tool that has many built-in features to allow simulations of LEO or GEO satellite systems. However, NS-2 does not support hybrid systems containing both LEO and GEO satellites. The rest of this section briefly describes the behavior modifications made to the NS-2 simulator. The following section revisits these modifications with discussion about the changes in the source code itself. In the appendix there is a complete listing of all the source code files that contain any major modifications. NS-2 was modified to support LEO to GEO ISLs. This included adding the functionality to know when a LEO and GEO satellite are mutually visible. This of course led to the addition of the functionality to know when to activate and deactivate an ISL between a LEO and GEO. In addition, the processing delay for each node needed to be taken into consideration when determining the shortest path between two points. Lastly, the Unslotted ALOHA included in NS-2 was modified to support a Slotted ALOHA for our medium access control protocol. Slotted ALOHA was chosen over Unslotted 25

PAGE 34

26 ALOHA since it has the ability to double the capacity of Unslotted ALOHA [8]. Slotted ALOHA requires that a sender must wait until the beginning of the next time slot before sending. This reduces the probability of a collision and thus increases the potential throughput. The Slotted ALOHA used for our medium access control protocol was set to have a 12 ms timeout. This means that when a sending node has not heard its own transmission within 12 ms, it assumes a collision and resends. 12 ms was chosen since it takes about 6 ms for a transmission to go from a ground station to a satellite and vice versa. This allows just enough time a transmission to reach its destination and a copy sent back to the source. The retransmission limit was set to 8. 8 was chosen, since in our preliminary tests, the retransmission limit of 8 was always sufficient. Of course, after a packet is received, the sending node will set the retransmission limit for that packet to 0. Finally, our slot length was chosen to be 3 ms. The transmission time for a 512 byte packet, with a bit rate of 1.5 Mb, is 2.7 ms. This leaves us with a 0.3 ms guard band. System Implementation One of the first modifications to NS-2 was dealing with the mutual visibility of LEO and GEO satellites. Prior to these modifications, mutual visibility between two satellites was determined while assuming the two satellites were at the same altitude. Below is a modified version of the function SatGeometry::are_satellites_mutually_visible that supports the combination of LEO and GEO satellites. int SatGeometry::are_satellites_mutually_visible(coordinate first, coordinate second) { // if we drop a perpendicular from the ISL to the Earth's surface, // we have a right triangle. The atmospheric margin is the minimum // ISL grazing altitude. double c, d, min_radius, grazing_radius;

PAGE 35

27 double A = first.r; double B = second.r; double distance_ = distance(first, second); grazing_radius = (EARTH_RADIUS + ATMOS_MARGIN); // Unequal altitudes means that one satellite is a GEO and the // other is a LEO. if(first.r != second.r) { double angle = angle_opposite_side_C(A,B,distance_); if(RAD_TO_DEG(angle) <= 90) { return TRUE; } else { double secondary_angle = asin((A * sin(angle))/distance_); min_radius = sin(secondary_angle) * B; if (min_radius >= grazing_radius) { return TRUE; } else { return FALSE; } } } else { // Could just use first.r here. double radius = get_radius(first); c = radius * radius; d = (distance_/2) * (distance_/2); min_radius = sqrt(c d); if (min_radius >= grazing_radius) { return TRUE; } else { return FALSE; } } } To make use of the accurate mutual visibility added in the above code, links between satellites must be activated and deactivated according to the mutual visibility. The function SatLinkHandoffMgr::handoff is in charge of activating and deactivating satellite links. This function assumes that links between satellites are always between two LEOs. We modified this code to check the altitudes of the satellites in question and

PAGE 36

28 then treat them accordingly. For example, GEO satellites are not subject to the Latitude Threshold and therefore links to a GEO satellite should not be deactivated just because its link partner is above the Latitude Threshold. Below is the modified version of the SatLinkHandoffMgr::handoff function that uses the modified mutual visibility function. This code segment only deals with the second for loop in the function SatLinkHandoffMgr::handoff. // Now search for interplane ISLs for (slhp = (SatLinkHead*) local_->linklisthead().lh_first; slhp; slhp = (SatLinkHead*) slhp->nextlinkhead() ) { // Obtain the altitudes of the satellites involved with // the ISL in question. double lalt = SatGeometry::get_altitude(local_coord_); double palt = SatGeometry::get_altitude(peer_coord_); bool LEO; // If the altitudes are equal then we are dealing with // two LEO satellites, othewise one is a GEO. if(lalt == palt) LEO = TRUE; else LEO = FALSE; if (slhp->type() != LINK_ISL_INTERPLANE) continue; // Now we only check the latitude threshold if we are // dealing with two LEO satellites. if ((fabs(sat_latitude_) > lat_threshold_) && LEO) link_down_flag_ = TRUE; else link_down_flag_ = FALSE; peer_ = get_peer(slhp); peer_slhp = get_peer_linkhead(slhp); peer_coord_ = peer_->position()->coord(); peer_latitude_ = SatGeometry::get_latitude(peer_coord_); // Now we only check the latitude threshold if we are // dealing with two LEO satellites. if ((fabs(peer_latitude_) > lat_threshold_) && LEO) link_down_flag_ = TRUE; link_down_flag_ |= !SatGeometry::are_satellites_mutually_visible(peer_coord_, local_coord_); if (slhp->linkup_ && link_down_flag_) { // Take links down if either satellite at high latitude

PAGE 37

29 slhp->linkup_ = FALSE; peer_slhp->linkup_ = FALSE; link_changes_flag_ = TRUE; } else if (!slhp->linkup_ && !link_down_flag_) { slhp->linkup_ = TRUE; peer_slhp->linkup_ = TRUE; link_changes_flag_ = TRUE; } } The version of NS-2 used for our implementation already supported a Pure ALOHA MAC-protocol. To add the functionality of a Slotted ALOHA protocol we built on-top of the preexisting Pure ALOHA code. To change Pure ALOHA into Slotted ALOHA, two main components needed to be added. The first component was to require that transmissions only send at the beginning of a time slot. To do this, a short segment of code was added just before each point in the code where a send was scheduled. This new segment of code changed the original scheduled send time into the beginning of the very next time slot. This segment of code is shown below: // Obtain the original send time by adding the current time with the // delay time. double OriginalSched = delay_ + NOW; // Multiply this time by 100000 to convert the floating point into // an integer. int Orig = OriginalSched * 100000; // Use the mod operator to find out how far into a time slot the // current time is. Our slot length is 3 ms, but multiplying by // 100000 for an integer value gives us 300. int Temp = Orig % 300; double t2, t1 = Temp; // If t1 is equal to 0, then we are already at the beginning of a // time slot. Otherwise, the slot length minus how far into a time // slot it is, will tell us how long to wait before sending. if(t1 == 0) { t2 = 0; } else { t2 = 300 t1; } // Add this wait time to our delay value. double newdelay = delay_ + (t2/100000);

PAGE 38

30 The above segment of code was used in the function SatLL::sendDown right before scheduling a send. It is also used in UnslottedAlohaMac::sendDown and UnslottedAlohaMac::backoff right before transmissions are rescheduled after a collision or timeout. The second component built on-top of the Pure ALOHA code was the ability of a source to know that its own transmission has been received. In real Slotted ALOHA a sender must wait until it hears its own transmission to know that it was received without collision. For the purpose of simulations, when a transmission was received without collision, a message was written to a file signaling that the transmission was received. Then, when the sender is about to timeout from not hearing its own transmission, it checks the same file to see if the transmission was received properly. The sender can then act accordingly. The following segment of code was used to write to a file. This writing to a file signaled that a packet was received. // Access the headers of the packet. hdr_cmn* cmnh = HDR_CMN(p); hdr_mac* mhy = HDR_MAC(p); // Reset the number of collisions for this packet back to 0. The // number of collisions is recorded so a station knows how much to // backoff. cmnh->collisions_ = 0; // Obtain the packets Unique ID. int uniqueid = cmnh->uid(); // Obtain the packets MAC Destination Address int dest = mhy->macDA_; // Create a file pointer. ofstream fileptr; // Open the file. fileptr.open("packet.dat", ios::app); // Write a sequence of the Unique ID and MAC Destination Address. // This sequence will be unique for every packet and destination // pair. fileptr << uniqueid << ":" << dest << ":"; // Close the file pointer. fileptr.close();

PAGE 39

31 When the file is read, all MAC Destination Addresses are stored into two arrays. Slotted ALOHA depends on a source hearing its own transmission. The links between two satellites are treated as a single channel, and thus a source satellite can hear its own transmission to another satellite. However, links between ground stations and satellites are treated as two channels. There is an uplink channel and a downlink channel. A transmission sent in one direction is not heard in the other direction, thus a source does not hear its own transmission. Therefore, transmissions between ground stations and satellites are the ones that depend on the file for signaling that a transmission was received. For any transmission, only its first and last hops are between ground stations and satellites. This is why two arrays are used to store the MAC Destination Addresses. The first array holds the MAC Destination Address of the first hop (ground to satellite). The second array holds the MAC Destination Address of the last hop (satellite to ground). The unique ID paired with a MAC Destination Address is used as the position in the array to store the address. The following segment of code reads the file and stores the data in the arrays. // Access the packet headers of the packet about to be sent. hdr_cmn* cmnh = HDR_CMN(snd_pkt_); hdr_mac* mhy = HDR_MAC(snd_pkt_); // Obtain the Unique ID. int uniqueid = cmnh->uid(); // Obtain the MAC Destination Address. int dst = mhy->macDA_; // Create a file pointer. ifstream fileptr; // Open the file. fileptr.open("packet.dat", ios::in); // Declare some variables to be used with reading the file. char num; int i = 0, flag = 0, k; int thisnum; int thisstation;

PAGE 40

32 char *number = new char[8]; char *station = new char[8]; // The unique ID and MAC Destination Address pairs will be stored in // these arrays. int *numbers1 = new int[2500]; int *numbers2 = new int[2500]; // Initialize the these arrays to 0 so that no old values corrupt // new values. int m, n; for(m=0;m<8;m++) { number[m] = 0; station[m] = 0; } for(n=0;n<2500;n++) { numbers1[n] = 0; numbers2[n] = 0; } // Loop until there is not more data in the file while(fileptr.get(num) != 0) { // If the character is a number, add it to the number array. if(isdigit(num) && flag == 0) { number[i] = num; i++; } // If the character is a number, add it it the station array. else if(isdigit(num) && flag == 1) { station[i] = num; i++; } // Must have found a delimiter ‘:’. else { // If flag is off, turn it on and start recording the // MAC Destination Address. if(flag == 0) { i = 0; flag = 1; thisnum = atoi(number); } // If flag is on, then both Unique ID and MAC Destination // address have been read and can now be stored in an array. else { i = 0; flag = 0; thisstation = atoi(station); if(numbers1[thisnum] == 0) { numbers1[thisnum] = thisstation; } else { numbers2[thisnum] = thisstation; } // Reset the number and station array.

PAGE 41

33 for(k=0;k<8;k++) { number[k] = 0; station[k] = 0; } } } } // Close the file pointer. fileptr.close(); We kept track of the number of collisions for a packet at a single node in some of the above code sequences. This lets a packet back off according to the number of collisions it had suffered. The following function was added to NS-2 to determine the back off value. double UnslottedAlohaMac::ExpRandomBack(int colls) { int bound = (pow(2, colls)) 1; double backing = (rand() % bound) + 1; backing = backing * slot_length_; return backing; } Intracontinental Transmissions This intracontinental series of simulations was based on transmitting nodes in New York, NY and receiving nodes in Los Angeles, CA. This series of simulations consists of 3 sets. The first set is our base case. Our base case only consists of one pair of transmitting and receiving nodes. This base case allows the transmitting node to freely send transmissions without the risk of collision. This base case allows us to observe the behavior of the system without any effects from our medium access control protocol. The second set more closely reflects current day satellite traffic. This set has a more moderate load of traffic with 10 transmitting and 10 receiving nodes. The last set is our heavy traffic set. This set represents the amount of satellite traffic that could be experienced many years in the future. This set is heavily loaded with 100 transmitting and 100 receiving nodes. Each set of simulations was run 20 times, with a varying of

PAGE 42

34 processing delays that range from 0 to 40 ms. Throughout these simulations the packet size is always chosen to be 512 bytes. In each simulation, a packet of this size is sent every 30 seconds for 10 minutes. Each set of simulations was run on the LEO system and our Hybrid system. Figure 3 shows the average end-to-end delay experienced in the first set of simulations. NY to LA Base Case02550751001251501752002252500510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 3. NY to LA--Base Case. From the results above, we observe that the performance of the LEO system was paralleled by the Hybrid system. This was expected. The number of required hops to go through a LEO system when traveling from New York to Los Angeles is most often 5 or fewer. The processing delay would have to be extremely large for this type of transmission to benefit from a GEO component. Hence, the Hybrid system performed the same as the LEO system. However, this intracontinental simulation was run again with 10 transmitting nodes in New York and 10 receiving nodes in Los Angeles. The results for this set of simulations are in Figure 4.

PAGE 43

35 NY to LA Moderate Traffic1501752002252502753003253500510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 4. NY to LA--Moderate Traffic We see again in Figure 4 that the LEO performance was identical to the Hybrid performance. Even with increased traffic, both systems performed the same as one another. The Hybrid system showed no improvement for this type of transmission. The only difference from our previous simulation set is that the average end-to-end delay has increased for any given processing delay. For example, a processing delay of 0 ms in the NY to LA Base Case simulation resulted in an average end-to-end delay of 39 ms. A processing delay of 0 ms in the NY to LA Moderate Traffic simulation resulted in an average end-to-end delay of 172 ms. This is a difference of 133 ms. In fact, the average increase in end-to-end delay when comparing the results of the Base Case and Moderate Traffic simulation sets is 125 ms. This increase is a result of the heavier traffic load on the Slotted ALOHA. The last simulation set of this series was run with 100 transmitting nodes in New York and 100 receiving nodes in Los Angeles. The results of this set are shown in Figure 5.

PAGE 44

36 NY to LA Heavy Traffic800825850875900925950975100010251050107511000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 5. NY to LA--Heavy Traffic With this increased amount of traffic we begin to see a more sporadic behavior of our two systems. Nonetheless, neither system clearly out-performed the other. Both systems showed a steady increase in the average end-to-end delay, but kept pace with one another. However, the increase from a moderate traffic load to a heavy traffic load had a definite affect on the average end-to-end delay. In the NY to LA Moderate Traffic simulation, with a processing delay of 0 ms, the average end-to-end delay was 172 ms. Here in the NY to LA Heavy Traffic simulation, with a processing delay of 0 ms the average end-to-end delay was 865 ms and 861 ms respectively for the LEO and Hybrid systems. This is an increase of over 685 ms. In fact, when comparing the Moderate Traffic load with the Heavy Traffic load the average increase in end-to-end delays were 699 ms and 703 ms for the LEO and Hybrid systems respectively. This is a drastic increase, but not all that unexpected when considering the behavior of Slotted ALOHA. The traffic load was drastically increased which was expected to have a direct effect on

PAGE 45

37 the Slotted ALOHA protocol. Regardless, when sending transmissions from NY to LA, there is no clear advantage to transmitting through the Hybrid system. It is worthy of pointing out that our initial calculations of end-to-end delay most closely reflect the behavior of the second set of simulations, where the traffic load was moderate. For instance, a transmission requiring 5 hops, with a 20 ms delay was calculated at 215 ms. From the NY to LA Moderate Traffic simulation, we can see that when the delay reached 20 ms, the average end-to-end delay was 256 ms. In the NY to LA Base Case simulation, with a processing delay of 20 ms, the average end-to-end delay was only 131 ms. Meanwhile in the NY to LA Heavy Traffic simulation, with a processing delay of 20 ms, the average end-to-end delay was 940 ms and 971 ms respectively for the LEO and Hybrid systems. So our initial calculations fall somewhere between the results of the first two sets of simulations, but much closer to second set where there traffic load was moderate. Intercontinental Transmissions in the Northern Hemisphere This next series of simulations was based on transmitting nodes in New York, NY and receiving nodes in Paris, France. This series also consists of 3 sets of simulations. These 3 sets mirror the 3 sets of simulations in the first series. The first set is the base case with 1 pair of nodes, the second set is a moderate traffic load with 10 pairs, and the third set is a heavy traffic load with 100 pairs. Again, each set of simulations is run 20 times, with a varying processing delay that ranges from 0 to 40 ms. Throughout the series the packet size was always chosen to be 512 bytes. In each simulation a packet of this size is sent every 30 seconds for 10 minutes. Each set of simulations was run on the LEO system and the Hybrid system.

PAGE 46

38 Figure 6 shows the average end-to-end delay experienced in the first set of simulations. NY to Paris Base Case0501001502002503003504004505005506006507000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 6. NY to Paris--Base Case From these results we start to see a clear difference between the performance of the LEO system and the Hybrid system. The LEO system shows a steady increase in average end-to-end delays. Meanwhile, the Hybrid system follows the same steady increase until about 18 ms. Once the processing delay reaches 18 ms, the Hybrid system begins to perform better than the LEO system. With an 18 ms processing delay, the LEO system had an average end-to-end delay of 366 ms. With the same processing delay the Hybrid system had an average end-to-end delay of 331 ms. By adding the GEO component to the Hybrid system, it reduced the average end-to-end delay by 10% or 35 ms. When the processing delay reached 26 ms, the average end-to-end delays were 456 ms and 357 ms for the LEO and Hybrid systems respectively. This time, the Hybrid system reduced the average end-to-end delay by 22%, by shaving off 99 ms. At the point where the processing delay reached 34 ms, the respective average end-to-end delays were

PAGE 47

39 577 ms and 379 ms for the LEO and Hybrid systems. At that point the Hybrid system had reduced the average end-to-end delay by 198 ms, which is a 34% reduction. Finally, when the processing delay reached 40 ms, the average end-to-end delays were 662 ms and 397 ms for the LEO and Hybrid systems respectively. The Hybrid system shaved off a total of 265 ms. This is a 40% reduction. This is a significant difference in performance. The following set of simulations was run with 10 transmitting nodes in New York and 10 receiving nodes in Paris. The results are shown in Figure 7. NY to Paris Moderate Traffic2002503003504004505005506006507007508000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 7. NY to Paris--Moderate Traffic Just like we witnessed in the NY to LA series, when we increase from the Base Case to the Moderate Traffic load, there is an overall increase in the average end-to-end delays. For the NY to Paris Base Case simulation, with a processing delay of 0 ms, the average end-to-end delay was 113 ms. Here in the NY to Paris Moderate Traffic simulation, with a processing delay of 0 ms, this resulted in an average end-to-end delay of 237 ms. This is an increase of 124 ms. In fact, comparing the Base Case with the

PAGE 48

40 Moderate Traffic load the average increase in end-to-end delays were 124.6 ms and 124.8 ms for the LEO and Hybrid systems respectively. This is quite comparable to the average increase in end-to-end delays experienced from the NY to LA Base Case to the NY to LA Moderate Traffic simulation (125 ms). Nonetheless, the shape of this Figure 3s very much like the figure from the NY to Paris Base Case simulation. Once the processing delay reached 18 ms, the Hybrid system begins to perform better than the LEO system. At a processing delay of 18 ms, the average end-to-end delays were 490 ms and 456 ms for the LEO and Hybrid systems respectively. This is a difference of 34 ms. This is extremely close to the 35 ms shaved off in the NY to Paris Base Case simulation for the 18 ms processing delay. Although, in this situation, 34 ms is only a 7% reduction since the end-to-end delays are higher than they were in the NY to Paris Base Case simulation. Meanwhile, when the processing delay reached 26 ms, the LEO and Hybrid systems had 581 ms and 481 ms average end-to-end delays respectively. This is a difference of 100 ms, which is a 17% reduction. This result is also close to the 99 ms difference experienced in the NY to Paris Base Case simulation at a processing delay of 26 ms. This pattern continues when the processing delay reached 34 ms. At 34 ms, the average end-to-end delays were 702 ms and 504 ms for the LEO and Hybrid systems respectively. A difference of 198 ms, or a 28% reduction. For this same processing delay in the NY to Paris Base Case simulation, the difference between the LEO and Hybrid systems was also 198 ms. Although in the Base Case, 198 ms resulted in a 34% reduction since the average end-to-end delays were less. In addition, when the processing delay reached 40 ms, the average end-to-end delays were 787 ms and 582 ms for the LEO and Hybrid

PAGE 49

41 systems. Just like in the NY to Paris Base Case simulation for the 40 ms processing delay, this is a difference of 265 ms. This is a 34% reduction. This next set of simulations was run with 100 transmitting nodes in New York and 100 receiving nodes in Paris. The results are shown in Figure 8. NY to Paris Heavy Traffic900950100010501100115012001250130013501400145015000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 8. NY to Paris--Heavy Traffic As expected, the overall average end-to-end delay increased again, as we increased from a moderate traffic load to a heavy traffic load. For the NY to Paris Moderate Traffic simulation, with a processing delay of 0 ms, the average end-to-end was 237 ms. Now in the NY to Paris Heavy Traffic simulation, with a processing delay of 0 ms we experienced an average end-to-end delay of 941 ms. This is a significant increase of 704 ms. On average, the LEO and Hybrid systems end-to-end delays increased 703 ms and 703.2 ms respectively. Once again, this is expected when using Slotted ALOHA. Regardless, with this simulation we see the same shape figure once again. Once the processing delay reaches 18 ms, the Hybrid system begins to perform better than the LEO system. When the processing delay reaches 18 ms the average end-to-end delay of the

PAGE 50

42 LEO and Hybrid systems are 1190 ms and 1157 ms respectively. This is a difference of 33 ms, for a 3% reduction. Again, this is very close to the 34 and 35 ms differences seen in the NY to Paris Base Case simulation and the NY to Paris Moderate Traffic simulation when the processing delay was 18 ms. However, in this situation the percent reduction is much less due to the even larger values of end-to-end delay. This pattern continues when the processing delay reaches 26 ms. At 26 ms the LEO and Hybrid systems experience 1290 ms and 1186 ms end-to-end delays. This is a difference of 104 ms. Again, this is very close to the 99 and 100 ms differences in the previous two sets at 26 ms processing delays. In this situation, 104 ms is only an 8% reduction. This is much less than the 22% and 17% reductions seen in the previous simulation sets for this same processing delay. This is the effect of the MAC protocol. This same pattern is repeated again when the processing delay reaches 34 ms. The LEO and Hybrid systems experience 1402 ms and 1212 ms delays respectively when the processing delay is 34 ms. A difference of 190 ms, or 14% reduction. By the time the processing delay reaches 40 ms, the average end-to-end delays are 1489 ms and 1230 ms for the LEO and Hybrid systems. The Hybrid system has reduced the average end-to-end delay by 259 ms, which is a 17% reduction. By this point, it has probably become noticeable that as the traffic load increases, the millisecond difference between the LEO and Hybrid systems has not been effected very much. In fact, there is almost no effect. However, the percentage by which the Hybrid system reduces the end-to-end delay has been greatly effected by the increased traffic load. Table 5 lists the millisecond differences between the end-to-end delays of the LEO and Hybrid systems. In addition, it shows the corresponding percent reductions for each case.

PAGE 51

43 Table 5. NY to Paris--Percent Improvement Base Case Moderate Traffic Heavy Traffic 18 ms 35ms (10%) 34ms (7%) 33 ms (3%) 26 ms 99ms (22%) 100ms (17%) 104ms ( 8%) 34 ms 198ms (34%) 198ms (28%) 190ms (14%) 40 ms 265ms (40%) 265ms (34%) 259ms (17%) This table shows the millisecond difference between the end-to-end delay of the LEO and Hybrid system. It also shows the corresponding percent reduction from the Hybrid system. From Table 5 we can see that as the traffic increases, the millisecond difference barely changes, and the percent reduction significantly decreases. For example, with a 40 ms processing delay, the Hybrid system reduced the end-to-end delay by 265, 265, and 259 ms respectively for the Base Case, Moderate Traffic load, and Heavy Traffic load. However, the respective percentage reductions were 40%, 34%, and 17%. The percent reductions show a much greater effect as the traffic load increases. This is a clear indicator that the MAC protocol, in this case Slotted ALOHA, has a direct effect on the end-to-end delay. When using Slotted ALOHA, if 100 transmitters try to send transmissions at the same time, it should be expected that the number of collisions will be high. This results in transmitters backing off and having to resend. The more transmitters, the more collisions, and thus the more backing off creating a longer end-to-end delay. This behavior is not surprising, but important to point out. Clearly though, even with this type of behavior, this type of transmission benefits from having the GEO component in the Hybrid system. When the results of the first series of simulations were compared with the initial calculations we saw that the initial calculations were somewhere in between the Base Case and the Moderate Traffic load. Although, much closer to the results of the set with moderate traffic. With this second series of simulations we see a very similar behavior. A transmission from NY to Paris averages about 13 hops. This may seem high when

PAGE 52

44 considering the distance, but one must keep in mind that this transmission has a cross-seam it must avoid. In addition, this transmission must go around the north pole to avoid the latitude threshold. In our initial calculations a 13 hop transmission, with a processing delay of 0 ms was calculated at 228 ms. In the NY to Paris Base Case simulation we saw that a processing delay of 0 ms resulted in an average end-to-end delay of 113 ms. Yet, in the NY to Paris Moderate Traffic simulation, a processing delay of 0 ms resulted in an average end-to-end delay of 237 ms. Not too far from our initial calculations, and even closer than in Series 1. Intercontinental Transmissions from Different Hemispheres This next series of simulations was based on transmitting nodes in New York, NY and receiving nodes in Sydney, Australia. This series, just like the previous two, also consists of 3 sets of simulations. These 3 sets mirror the 3 sets of simulations in the previous series. The first set is the Base Case with 1 pair of nodes, the second set has a moderate traffic load with 10 pairs, and the third set consists of 100 pairs of nodes for heavy traffic. Again, each set of simulations is run 20 times, with a varying processing delay that ranges from 0 to 40 ms. Throughout the series the packet size was always chosen to be 512 bytes. In each simulation a packet of this size is sent every 30 seconds for 10 minutes. Once again, each set of simulations was run on the LEO system and the Hybrid system. Figure 9 shows the average end-to-end delays experienced for the first set of simulations. Without much examination, we can already identify that this figure looks very much like the figures generated in the NY to Paris simulations. The major difference here is that the Hybrid system seems to begin performing better than the LEO system at

PAGE 53

45 NY to Sydney Base Case 1001502002503003504004505005506006507007508000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 9. NY to Sydney--Base Case an earlier point. Before, it was not until an 18 ms processing delay that the Hybrid system would begin to perform better than the LEO system. In this situation, the Hybrid system begins to perform better as early as a 14 ms processing delay. When the processing delay was 14 ms, the average end-to-end delays for the LEO and Hybrid systems were 333 ms and 326 ms respectively. This is already a 7 ms difference. When the processing delay reaches 16 ms, the LEO and Hybrid systems average end-to-end delays were 376 ms and 336 ms respectively. This is a 40 ms difference. This is a much larger difference, at a smaller processing delay than we have seen thus far. By the time the processing delay reached 18 ms, the LEO and Hybrid system average end-to-end delays were 422 ms and 343 ms respectively. That is a 79 ms difference. In the NY to Paris Base Case simulation, the difference between the LEO and Hybrid systems performance at 18 ms was only 35. A value less than half of what this simulation has experienced. In addition, for the NY to Paris Base Case simulation, 35 ms was a 10% reduction. For this NY to Sydney simulation, 79 ms is a 19% reduction. When the

PAGE 54

46 processing delay reached 26 ms, the average end-to-end delay of LEO and Hybrid systems were 522 ms and 368 ms respectively. This is a difference of 154 ms, for a 30% reduction. Once again, this is much larger than the 99 ms (22% reduction) difference that was experienced in the NY to Paris Base Case simulation. As the processing delay increased to 34 ms, the LEO and Hybrid systems experienced an average end-to-end delay of 661 ms and 390 ms respectively, for a difference of 271 ms. Already at a 34 ms processing delay, we are seeing a greater benefit from the Hybrid system, than the NY to Paris Base Case experienced at a 40 ms processing delay. This difference of 271 ms is a 41% reduction. When a 40 ms processing delay for this simulation was reached, the respective average end-to-end delays were 756 ms and 408 ms (LEO and Hybrid). This is a record breaking difference of 348 ms. The Hybrid system has reduced the LEO average end-to-end delay by 46%. This is a tremendous improvement. The following set of simulations was run with 10 pairs of nodes. The results are shown in Figure 10. The pattern continues. As we increase from the Base Case to the Moderate Traffic load, the overall average end-to-end delay increases. In the Base Case when the processing delay is 0 ms, the average end-to-end delay is 138 ms. Now with a Moderate Traffic load, and a processing delay of 0 ms, the average end-to-end delay is 263 ms. This is an increase of 125 ms. In addition, a similar increase is experienced across all the values of processing delays. The average increase in end-to-end delays for the LEO and Hybrids systems were both 124.8 ms. This is very much like the increases experienced when we increased from Base Case to the Moderate Traffic load in the NY to LA and NY to Paris simulations. Furthermore, analyzing the results of this simulation we see that this figure has

PAGE 55

47 NY to Sydney Moderate Traffic2002503003504004505005506006507007508008509009500510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 10. NY to Sydney--Moderate Traffic the same shape as the previous figure. While the values of processing delay are less than 14 ms, the LEO and Hybrid systems perform the same. Yet, when the processing delay reaches 14 ms, the LEO and Hybrid system average end-to-end delays are 457 ms and 450 ms respectively. This is the same 7 ms difference we saw in the NY to Sydney Base Case simulation at a 14 ms processing delay. When the processing delay reaches 16 ms, the LEO and Hybrid systems average end-to-end delays are 501 ms and 461 ms respectively. This is a difference of 40 ms. Continuing, at an 18 ms processing delay, the LEO and Hybrid systems average end-to-end delays are 547 ms and 468 ms respectively. This is another 79 ms difference, just like in the NY to Sydney Base Case simulation. In the Base Case this was a 19% reduction, but here it is only a 14% reduction. When the processing delay reaches 26 ms, the average end-to-end delays were 647 ms and 493 ms respectively, for the LEO and Hybrid systems. This is a difference of 154 ms, for a 24% reduction. At a processing delay of 34 ms, the difference in average end-to-end delay between the LEO and Hybrid systems was 271 ms. A difference of 271

PAGE 56

48 ms results in a 34% reduction. Both of these values (154 ms and 271 ms) are identical to the NY to Sydney Base Case simulation values for their respective processing delays. Lastly, at a processing delay of 40 ms, the LEO and Hybrid system average end-to-end delays were 881 ms and 553 ms respectively. Again, this is a difference of 348 ms, which is also a 40% reduction. A drastic difference between the LEO and Hybrid performance. Figure 11 is the same simulation with now 100 pairs. NY to Sydney Heavy Traffic900950100010501100115012001250130013501400145015001550160016500510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 11. NY to Sydney--Heavy Traffic Once again, as the traffic load increases from moderate to heavy, the overall average end-to-end delay increases. This time, with a Moderate Traffic load, and a processing delay of 0 ms, the average end-to-end delay was 263 ms. Now with a Heavy Traffic load, and a 0 ms processing delay, the LEO an Hybrid systems had 1001 ms and 984 ms average end-to-end delays respectively. This is at least a 720 ms increase in average end-to-end delay. As mentioned above, this increase is not unexpected due to the nature of Slotted ALOHA.

PAGE 57

49 Regardless of the overall high average end-to-end delays, the shape of the figure continues to follow that same pattern. Noteworthy though, is the fact that when dealing with 100 nodes the behavior of the Figure 3s not nearly as smooth. The behavior is much more sporadic. Nonetheless, the Hybrid system still performs better than the LEO system. Once again, when the processing delay reaches 14 ms, the Hybrid system begins to have a smaller average end-to-end delay. This time for a 14 ms delay the LEO and Hybrid systems average end-to-end delays were 1167 ms and 1149 ms respectively. This is a difference of 18 ms. A bit more of an improvement than previous simulations at 14 ms. At a 16 ms processing delay, the LEO and Hybrid systems average end-to-end delays were 1209 ms and 1164 ms respectively for a difference of 45 ms. At 18, 26, and 34 ms processing delays the difference between the LEO and Hybrid systems were 88, 141, and 296 ms respectively. All of these values are rather close to the NY to Sydney Moderate Traffic simulations at their respective processing delays. Although here, the respective percent reductions are 7%, 10%, and 20%, which is less than the percent reductions in both the NY to Sydney Base Case and Moderate Traffic simulations. Lastly, when a 40 ms processing delay was reached, the LEO and Hybrid systems average end-to-end delays were 1604 ms and 1265 ms respectively. This is a difference of 339 ms (21% reduction). Slightly less, but still close to the NY to Sydney Moderate Traffic simulation, for a processing delay of 40 ms. Nevertheless, the Hybrid system has continued to perform better than the LEO system as we have increased the number of pairs of nodes. Just like in the NY to Paris simulations, we can see in Table 6 that when the traffic load increased, the millisecond difference between the LEO and Hybrid systems

PAGE 58

50 Table 6. NY to Sydney--Percent Improvement Base Case Moderate Traffic Heavy Traffic 14 ms 7ms (2%) 7ms (2%) 18ms (2%) 16 ms 40ms (11%) 40ms (8%) 45ms (4%) 18 ms 79ms (19%) 79ms (14%) 88ms (7%) 26 ms 154ms (30%) 154ms (24%) 141ms (10%) 34 ms 271ms (41%) 271ms (34%) 296ms (20%) 40 ms 348ms (46%) 348ms (40%) 339ms (21%) This table shows the millisecond difference between the end-to-end delay of the LEO and Hybrid system. It also shows the corresponding percent reduction from the Hybrid system. was not greatly effected. However, the percent reduction from the Hybrid system was greatly effected. In this case, when the processing delay was 40 ms, the percent reductions were 46%, 40%, and 21% for the Base Case, Moderate Traffic, and Heavy Traffic respectively. We see here again how the MAC protocol can have a significant effect on the average end-to-end delay. It is also important to note that this set of simulations has continued to show a correlation with the initial calculations. As with the previous series, this series of simulations most closely reflects the values of the initial calculations when there is a moderate traffic load. The average number of hops used in a transmission from New York to Sydney is about 14. The initial calculations showed a transmission with 14 hops and a 10 ms processing delay to take 368 ms. In our simulation set with Moderate Traffic, when the processing delay was 10 ms, the average end-to-end delay was 406 ms. This is much closer than the Base Case or Heavy Traffic load simulations. When the processing delay was 10 ms, the Base Case took 282 ms. The simulation set with Heavy Traffic took 1135 ms and 1118 ms for the LEO and Hybrid systems respectively. Real Life Population Based Transmissions In the previous sections, the simulations were run with 1, 10, and 100 pairs of nodes. All the transmitting nodes were in the first city and all the receiving nodes were in

PAGE 59

51 the second city. This next series of simulations were run with 10, 25, and 50 pairs of nodes. Although, this time these pairs of nodes are semi-randomly placed around the earth. Rather than have a random generator select meaningless coordinates around the earth, the author has attempted to select the world’s largest cities and randomly pair them together. It is believed that the larger cities around the world are more likely to be sources and destinations for satellite network traffic. It is hoped that these simulations would give a better representation of the flow of traffic in a real life satellite network. With the larger cities, there are obviously larger populations, which means a greater chance of someone needing to utilize a satellite network. The results of the first set of simulations are shown in Figure 12. From these results we can quickly see that the Hybrid system has performed better than the LEO system once again. The shape of this Figure 3s quickly identified as being very similar to those generated from the NY to Paris and NY to Sydney simulations. Here we see that with processing delay values between 0 and 16 ms inclusively, that the LEO and Hybrid systems perform the same. However, once the processing delay reaches 18 ms, the LEO and Hybrid systems perform very differently. The LEO system has an average end-to-end delay of 382 ms and the Hybrid has an average end-to-end delay of 332 ms. This is a difference of 50 ms, which is 13% reduction. When the processing delay reaches 26 ms, the LEO and Hybrid systems average end-to-end delays are 499 ms and 331 ms respectively. This is a difference of a 168 ms, a reduction of 34%. Furthermore, when the processing delay is 34 ms, the difference between the average end-to-end delay of the LEO and Hybrid systems is 252 ms. A difference of 252 ms is a reduction of 40%. Lastly, once the processing delay

PAGE 60

52 10 Pairs of Cities0501001502002503003504004505005506006507007508000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 12. Ten Pairs of Cities reaches 40 ms, the LEO and Hybrid systems average end-to-end delays were 721 ms and 395 ms respectively. This a difference of 326 ms. This is a 45% reduction in the end-to-end delay. This simulation was also run for 25 pairs of cities. The results are shown in Figure 13. Recall, that when the NY to LA, NY to Paris, or NY to Sydney simulations increased their number of pairs of nodes from 1 to 10, that we experienced a significant increase in the average end-to-end delay. This increase was around 125 ms. In this simulation, the number of pairs of nodes has increased from 10 to 25, yet for a processing delay of 0 ms, the average end-to-end delay has only increased from 95 ms to 115 ms. That is only a difference of 20 ms. This is a much less significant increase than the other simulations. The reason for this is that this simulation has a much more distributed nature. Consider that in earlier simulations all the transmitting nodes were in a single city, and all the receiving nodes were in a single city. Now the transmitting and receiving

PAGE 61

53 25 Pairs of Cities0501001502002503003504004505005506006507007508000510152025303540Processing Delay (ms)Average End-to-End Delay (ms) LEO Hybrid Figure 13. Twenty Five Pairs of Cities nodes are randomly spread across the major cities of the world. The previous scenario could be accused of overloading a single path through the satellite network. Now we have a more real life loading on the satellite network. Regardless, even as our simulations get closer to real life, the Hybrid system maintains its value. Once again we see that the Hybrid system begins to perform better than the LEO system once the processing delay reaches a given point. It is worth pointing out here though, that in this simulation, the point at which the Hybrid system begins to out-perform the LEO system is almost a record low. At a processing delay of 12 ms, the LEO and Hybrid systems average end-to-end delays were 301 ms and 285 ms respectively. This is a difference of 16 ms, as early as a 12 ms processing delay. Already, the Hybrid system is reducing the average end-to-end delay of the LEO system by 5%. In addition, once the processing delay reaches 14 ms, the LEO and Hybrid average end-to-end delays were 324 ms and 300 ms respectively. This is a difference of

PAGE 62

54 24 ms, which is also a record for a processing delay of 14 ms. Still maintaining its competitiveness, a processing delay of 16 ms results in a average end-to-end delay of 353 ms and 310 ms for the LEO and Hybrid systems respectively. This is a difference of 43 ms, quite close to the results of the NY to Sydney simulations for processing delays of 16 ms. Once the processing delay reached 18 ms, the LEO and Hybrid systems average end-to-end delays were 394 ms and 318 ms respectively. This is a difference of 76 ms, a 19% reduction. Continuing, when the processing delay reaches 26 ms and 34 ms processing delays, the difference between the LEO and Hybrid systems average end-to-end delays were 172 ms and 255 ms respectively. These are 34% and 40% reductions respectively. Lastly, when the processing delay reached 40 ms, the LEO and Hybrid systems average end-to-end delays were 726 ms and 409 ms respectively. This is another significant difference of 317 ms. In this instance the Hybrid system has reduced the LEO system average end-to-end delay by 44%. Figure 14 shows the results of the simulation set when run with 50 pairs of cities. The increase in the number of pairs of nodes does not have a significant impact on the overall average of the end-to-end delays. In the previous set of simulations, with a 0 ms processing delay there was an average end-to-end delay of 115 ms. In this simulation set, with a processing delay of 0 ms, there is an average end-to-end delay of 153 ms. This is only an increase of 38 ms. Again, this is most likely due to the distributed nature of this simulation. With the transmitting and receiving nodes distributed around the globe for a more real life example, we avoid overloading a single path through the satellite network. Our MAC protocol responds better when there are less imminent collisions.

PAGE 63

55 50 Pairs of Cities1001502002503003504004505005506006507007508000510152025303540Processing Delay (ms)Average End-to-End Delay (ms ) LEO Hybrid Figure 14. Fifty Pairs of Cities Table 7. Real Life--Percent Improvement Base Case Moderate Traffic Heavy Traffic 12 ms 16ms (5%) 11ms (3%) 14 ms 24ms (7%) 16ms (4%) 16 ms 43ms (12%) 41ms (10%) 18 ms 50ms (13%) 76ms (19%) 72ms (17%) 26 ms 168ms (34%) 172ms (34%) 158ms (29%) 34 ms 252ms (40%) 255ms (40%) 242ms (36%) 40 ms 326ms (45%) 317ms (44%) 310ms (40%) This table shows the millisecond difference between the end-to-end delay of the LEO and Hybrid system. It also shows the corresponding percent reduction from the Hybrid system. This simulation shows the advantage of the Hybrid system over the LEO system. Once the processing delay reaches 12 ms, the Hybrid begins to perform better than the LEO system. The LEO and Hybrid systems average end-to-end delays were 340 ms and 329 ms respectively. This is a 11 ms difference. Just like in the previous set of simulations (25 Pairs of Cities), the difference in average end-to-end delay is showing up a bit earlier than it did in the NY to Paris or NY to Sydney simulations. This happens again at 14 ms. At a 14 ms processing delay, the LEO and Hybrid systems average end

PAGE 64

56 to-end delays were 365 ms and 349 ms, for a difference of 16 ms. When the processing delay reaches 16 ms, the average end-to-end delays were 395 ms and 354 ms for the LEO and Hybrid systems respectively. This is a difference of 41 ms, for a 10% reduction. For a processing delay of 18 ms, the LEO and Hybrid systems average end-to-end delays were 431 ms and 359 ms respectively. This was a 72 ms difference, for a reduction of 17%. For processing delays of 26 ms and 34 ms, the difference between the LEO and Hybrid systems average end-to-end delays were 158 ms and 242 ms respectively (29% and 36% reductions). When the processing delay reached 40 ms, the LEO and Hybrid systems average end-to-end delays were 768 ms and 458 ms respectively. This was a difference of 310 ms. Here the Hybrid has reduced the average end-to-end delay of the LEO system by 40%.

PAGE 65

CHAPTER 5 CONCLUSION The recent rise in interest over potential LEO satellite systems is obvious when their propagation delay is compared with that of a GEO satellite propagation delay. However, this study has shown that not only is there a great benefit from the GEO satellite’s ability to maintain a fixed position over the earth, there is also a serious potential in reducing end-to-end delays when transmitting around the earth. This study has shown that when LEO and GEO satellites are combined into a hybrid satellite system, the performance of such a system can be more efficient than a LEO satellite system. When the processing delays exceed about 16 ms there begins to be a clear reduction in the average end-to-end delay through a hybrid system over a LEO system. When processing delays reached 40 ms, the difference between the Hybrid system and the LEO system was very commonly greater than 200 ms. In some instances the difference was over 300 ms. When considering that many transmissions must be sent to a destination, and that the destination is then sending a response, that doubles the end-to-end delay. In these cases where the difference between the Hybrid and the LEO systems is over 300 ms, once doubled, it is more than half a second. Clearly, the goal of minimizing end-to-end delays is ongoing, but here we see one tactic that cannot be overlooked. Clearly, traffic that only requires a couple of hops through intermediate satellites is not likely to benefit from the addition of GEO satellites. However, instances where a transmission has many hops, due to global transmissions or 57

PAGE 66

58 avoiding cross-seams, there is a great potential benefit to having the additional GEO satellites in the system. It is hoped that this work will be extended in the near future to support Multimedia communication via satellite. One of the first areas the author would like to explore is that of the MAC protocol. In this work, we saw where the MAC protocol has drastic effects on the end-to-end delay of a transmission through a satellite network. Clearly, to support multimedia communications some work will have to be done to help reduce this effect. Future work is likely to involve exploring MAC protocols other than Slotted ALOHA. In addition, future work will likely include further exploring the effect of heavy traffic conditions on processing delay. In this work, the processing delay was treated as a static condition. It is firmly believed that the processing delay could likely be a more dynamic condition that varies with the traffic load.

PAGE 67

APPENDIX This appendix contains the source code for the following files: Satgeometry.cc, Sathandoff.cc, Satlink.cc, and Satroute.cc. The original copies of these files were part of the NS-2 simulator. Below are the modified copies of these files that support the necessary protocols for our implementation. Satgeometry.cc /* -*Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -**/ /* * Copyright (c) 1999 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the MASH Research * Group at the University of California Berkeley. * 4. Neither the name of the University nor of the Research Group may be * used to endorse or promote products derived from this software without * specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * Contributed by Tom Henderson, UCB Daedalus Research Group, June 1999 59

PAGE 68

60 */ #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/satgeometry.cc,v 1.6 2001/05/21 19:27:31 haldar Exp $"; #endif #include "satgeometry.h" #include "satposition.h" static class SatGeometryClass : public TclClass { public: SatGeometryClass() : TclClass("SatGeometry") {} TclObject* create(int, const char*const*) { return (new SatGeometry()); } } class_sat_geometry; // Returns the distance in km between points a and b double SatGeometry::distance(coordinate a, coordinate b) { double a_x, a_y, a_z, b_x, b_y, b_z; // cartesian spherical_to_cartesian(a.r, a.theta, a.phi, a_x, a_y, a_z); spherical_to_cartesian(b.r, b.theta, b.phi, b_x, b_y, b_z); return (BaseTrace::round(DISTANCE(a_x, a_y, a_z, b_x, b_y, b_z), 1.0E+8)); } void SatGeometry::spherical_to_cartesian(double R, double Theta, double Phi, double &X, double &Y, double &Z) { X = R * sin(Theta) * cos (Phi); Y = R * sin(Theta) * sin (Phi); Z = R * cos(Theta); } // Propagation delay is the distance divided by the speed of light double SatGeometry::propdelay(coordinate a, coordinate b) { double delay = distance(a, b)/LIGHT; return (BaseTrace::round(delay, 1.0E+8)); } double SatGeometry::get_altitude(coordinate a) { return (a.r EARTH_RADIUS); } // Returns latitude in radians, in the range from -PI/2 to PI/2 double SatGeometry::get_latitude(coordinate a) { return (PI/2 a.theta); }

PAGE 69

61 // Returns (earth-centric) longitude corresponding to the position of the node // (the input coordinate corresponds to fixed coordinate system, through // which the Earth rotates, so we have to scale back the effects of rotation). // The return value ranges from -PI to PI. double SatGeometry::get_longitude(coordinate coord_) { double period = EARTH_PERIOD; // period of earth in seconds // adjust longitude so that it is earth-centric (i.e., account // for earth rotating beneath). double earth_longitude = fmod((coord_.phi (fmod(NOW + SatPosition::time_advance_,period)/period) * 2*PI), 2*PI); // Bring earth_longitude to be within (-PI, PI) if (earth_longitude < (-1*PI)) earth_longitude = 2*PI + earth_longitude; if (earth_longitude > PI) earth_longitude = (-(2*PI earth_longitude)); if (fabs(earth_longitude) < 0.0001) return 0; // To avoid trace output of "-0.00" else return (earth_longitude); } // If the satellite is above the elevation mask of the terminal, returns // the elevation mask in radians; otherwise, returns 0. double SatGeometry::check_elevation(coordinate satellite, coordinate terminal, double elev_mask_) { double S = satellite.r; // satellite radius double S_2 = satellite.r * satellite.r; // satellite radius^2 double E = EARTH_RADIUS; double E_2 = E * E; double d, theta, alpha; d = distance(satellite, terminal); if (d < sqrt(S_2 E_2)) { // elevation angle > 0 theta = acos((E_2+S_2-(d*d))/(2*E*S)); alpha = acos(sin(theta) * S/d); return ( (alpha > elev_mask_) ? alpha : 0); } else return 0; } // This function determines whether two satellites are too far apart // to establish an ISL between them, due to Earth atmospheric grazing // (or shadowing by the Earth itself). Assumes that both satellites nodes // are at the same altitude. The line between the two satellites can be // bisected, and a perpendicular from that point to the Earth's center will // form a right triangle. If the length of this perpendicular is less than // EARTH_RADIUS + ATMOS_MARGIN, the link cannot be established. // // This is a modified version of are_satellites_mutually_visible. This version // was added by Mark Foster int SatGeometry::are_satellites_mutually_visible(coordinate first, coordinate second)

PAGE 70

62 { // if we drop a perpendicular from the ISL to the Earth's surface, // we have a right triangle. The atmospheric margin is the minimum // ISL grazing altitude. double c, d, min_radius, grazing_radius; double A = first.r; double B = second.r; double distance_ = distance(first, second); grazing_radius = (EARTH_RADIUS + ATMOS_MARGIN); // Unequal altitudes means that one satellite is a GEO and the // other is a LEO. if(first.r != second.r) { double angle = angle_opposite_side_C(A,B,distance_); if(RAD_TO_DEG(angle) <= 90) { return TRUE; } else { double secondary_angle = asin((A * sin(angle))/distance_); min_radius = sin(secondary_angle) * B; if(min_radius >= grazing_radius) { return TRUE; } else { return FALSE; } } } else { // Could just use first.r here. double radius = get_radius(first); c = radius * radius; d = (distance_/2) * (distance_/2); min_radius = sqrt(c d); if (min_radius >= grazing_radius) { return TRUE; } else { return FALSE; } } } // Function added by Mark Foster. double SatGeometry::angle_opposite_side_C(double A, double B, double C) { double angle = ((A * A) + (B * B) (C * C))/(2 * A * B); angle = acos(angle); return angle; }

PAGE 71

63 Sathandoff.cc /* -*Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -**/ /* * Copyright (c) 1999 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the MASH Research * Group at the University of California Berkeley. * 4. Neither the name of the University nor of the Research Group may be * used to endorse or promote products derived from this software without * specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * Contributed by Tom Henderson, UCB Daedalus Research Group, June 1999 */ #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/sathandoff.cc,v 1.9 2000/08/30 00:10:45 haoboy Exp $"; #endif #include "random.h" #include "sathandoff.h" #include "satlink.h" #include "satroute.h" #include "satposition.h" #include "satnode.h" #include "satgeometry.h" #include static class LinkHandoffMgrClass : public TclClass { public: LinkHandoffMgrClass() : TclClass("HandoffManager") {} TclObject* create(int, const char*const*) { return (new LinkHandoffMgr());

PAGE 72

64 } } class_link_handoff_manager; static class SatLinkHandoffMgrClass : public TclClass { public: SatLinkHandoffMgrClass() : TclClass("HandoffManager/Sat") {} TclObject* create(int, const char*const*) { return (new SatLinkHandoffMgr()); } } class_sat_link_handoff_manager; static class TermLinkHandoffMgrClass : public TclClass { public: TermLinkHandoffMgrClass() : TclClass("HandoffManager/Term") {} TclObject* create(int, const char*const*) { return (new TermLinkHandoffMgr()); } } class_term_link_handoff_manager; void SatHandoffTimer::expire(Event*) { a_->handoff(); } void TermHandoffTimer::expire(Event*) { a_->handoff(); } ////////////////////////////////////////////////////////////////////////////// // class LinkHandoffMgr ////////////////////////////////////////////////////////////////////////////// RNG LinkHandoffMgr::handoff_rng_; int LinkHandoffMgr::handoff_randomization_ = 0; LinkHandoffMgr::LinkHandoffMgr() { bind_bool("handoff_randomization_", &handoff_randomization_); } int LinkHandoffMgr::command(int argc, const char*const* argv) { if (argc == 2) { } else if (argc == 3) { if(strcmp(argv[1], "setnode") == 0) { node_ = (Node*) TclObject::lookup(argv[2]); if (node_ == 0) return TCL_ERROR; return TCL_OK; } } return (TclObject::command(argc, argv)); } // Each crossseam satellite will have two net stacks-at most one will

PAGE 73

65 // be occupied. This procedure finds an unoccupied stack on the node. SatLinkHead* LinkHandoffMgr::get_peer_next_linkhead(SatNode* np) { LinkHead* lhp; SatLinkHead* slhp; for (lhp = np->linklisthead().lh_first; lhp; lhp = lhp->nextlinkhead() ) { slhp = (SatLinkHead*) lhp; if (slhp->type() == LINK_ISL_CROSSSEAM) { if (!slhp->phy_tx()->channel() && !slhp->phy_rx()->channel() ) return slhp; } } printf("Error, couldn't find an empty crossseam stack for handoff\n"); return 0; } // This helper function assumes that the channel to which the link interface // is attached has one peer node (i.e., no other receive infs on channel) SatLinkHead* LinkHandoffMgr::get_peer_linkhead(SatLinkHead* slhp) { SatChannel *schan_; Phy *remote_phy_; Node *remote_node_; schan_ = (SatChannel*) slhp->phy_tx()->channel(); if (schan_ == 0) { printf("Error: get_peer_linkhead called for a non-"); printf("connected link on node %d\n", slhp->node()->address()); return 0; // Link is not currently connected } remote_phy_ = schan_->ifhead_.lh_first; if (remote_phy_ == 0) { printf("Error: node %d's tx phy ", slhp->node()->address()); printf("connected to channel with no receivers\n"); return 0; } remote_node_ = remote_phy_->head()->node(); if (remote_phy_->nextchnl()) { printf("Error: This ISL channel has more than one target\n"); return 0; } return ( (SatLinkHead*) remote_phy_->head()); } // This helper function assumes that the channel to which the link interface // is attached has one peer node (i.e., no other receive infs on channel) SatNode* LinkHandoffMgr::get_peer(SatLinkHead* slhp) { SatChannel *schan_; Phy *remote_phy_; schan_ = (SatChannel*) slhp->phy_tx()->channel(); if (schan_ == 0) return 0; // Link is not currently connected

PAGE 74

66 remote_phy_ = schan_->ifhead_.lh_first; if (remote_phy_ == 0) { // this is not an error as far as satellite GSL endpoints // appear to be concerned. // Commented out for drawing GSL links in dumpSats() // in satnode.cc // printf("Error: node %d's tx phy ", slhp->node()->address()); // printf("connected to channel with no receivers\n"); return 0; } if (remote_phy_->nextchnl()) { printf("Error: This ISL channel has more than one target\n"); return 0; } return ( (SatNode*) remote_phy_->head()->node()); } ////////////////////////////////////////////////////////////////////////// // class TermLinkHandoffMgr ////////////////////////////////////////////////////////////////////////// double TermLinkHandoffMgr::elevation_mask_ = 0; int TermLinkHandoffMgr::term_handoff_int_ = 10; TermLinkHandoffMgr::TermLinkHandoffMgr() : timer_(this) { bind("elevation_mask_", &elevation_mask_); bind("term_handoff_int_", &term_handoff_int_); } // // This is called each time the node checks to see if its link to a // polar satellite needs to be handed off. // There are two cases: // i) current link is up; check to see if it stays up or is handed off // ii) current link is down; check to see if it can go up // If there are any changes, call for rerouting. Finally, restart the timer. // int TermLinkHandoffMgr::handoff() { coordinate sat_coord, earth_coord; SatLinkHead* slhp; SatNode *peer_; // Polar satellite at opposite end of the GSL SatNode *best_peer_; // Best found peer for handoff Node *nodep; // Pointer used in searching the list of nodes PolarSatPosition *nextpos_; int link_changes_flag_ = FALSE; // Flag indicating change took place int restart_timer_flag_ = FALSE; // Restart timer only if polar links double found_elev_ = 0; //``Flag'' indicates whether handoff can occur double best_found_elev_ = 0; double mask_ = DEG_TO_RAD(TermLinkHandoffMgr::elevation_mask_); earth_coord = ((SatNode *)node_)->position()->coord(); // Traverse the linked list of link interfaces for (slhp = (SatLinkHead*) node_->linklisthead().lh_first; slhp;

PAGE 75

67 slhp = (SatLinkHead*) slhp->nextlinkhead() ) { if (slhp->type() == LINK_GSL_GEO || slhp->type() == LINK_GENERIC) continue; if (slhp->type() != LINK_GSL_POLAR) { printf("Error: Terminal link type "); printf("not valid %d NOW %f\n", slhp->type(), NOW); exit(1); } // The link is a GSL_POLAR link-should be one receive // interface on it restart_timer_flag_ = TRUE; peer_ = get_peer(slhp); if (peer_) { sat_coord = peer_->position()->coord(); if (!SatGeometry::check_elevation(sat_coord, earth_coord, mask_) && slhp->linkup_) { slhp->linkup_ = FALSE; link_changes_flag_ = TRUE; // Detach receive link interface from channel slhp->phy_rx()->removechnl(); // Set channel pointers to NULL slhp->phy_tx()->setchnl(0); slhp->phy_rx()->setchnl(0); } } if (!slhp->linkup_) { // If link is down, see if we can use another satellite // // As an optimization, first check the next satellite // coming over the horizon. Next, consider all // remaining satellites. // if (peer_) { // Next satellite nextpos_ = ((PolarSatPosition*) peer_->position())->next(); if (nextpos_) { sat_coord = nextpos_->coord(); found_elev_ = SatGeometry::check_elevation(sat_coord, earth_coord, mask_); if (found_elev_) peer_ = (SatNode*) nextpos_->node(); } } // Next, check all remaining satellites if not found if (!found_elev_) { for (nodep=Node::nodehead_.lh_first; nodep; nodep = nodep->nextnode()) { peer_ = (SatNode*) nodep; if (peer_->position() && (peer_->position()->type() != POSITION_SAT_POLAR)) continue; sat_coord = peer_->position()->coord();

PAGE 76

68 found_elev_ = SatGeometry::check_elevation(sat_coord, earth_coord, mask_); if (found_elev_ > best_found_elev_) { best_peer_ = peer_; best_found_elev_ = found_elev_; } } if (best_found_elev_) { peer_ = best_peer_; found_elev_ = best_found_elev_; } } if (found_elev_) { slhp->linkup_ = TRUE; link_changes_flag_ = TRUE; // Point slhp->phy_tx to peer_'s inlink slhp->phy_tx()->setchnl(peer_->uplink()); // Point slhp->phy_rx to peer_'s outlink and // add phy_rx to the channels list of phy's slhp->phy_rx()->setchnl(peer_->downlink()); slhp->phy_rx()->insertchnl(&(peer_->downlink()->ifhead_)); } } } if (link_changes_flag_) { SatRouteObject::instance().recompute(); } if (restart_timer_flag_) { // If we don't have polar GSLs, don't reset the timer if (handoff_randomization_) { timer_.resched(term_handoff_int_ + handoff_rng_.uniform(-1 * term_handoff_int_/2, term_handoff_int_/2)); } else timer_.resched(term_handoff_int_); } return link_changes_flag_; } ////////////////////////////////////////////////////////////////////////// // class SatLinkHandoffMgr ////////////////////////////////////////////////////////////////////////// double SatLinkHandoffMgr::latitude_threshold_ = 0; double SatLinkHandoffMgr::longitude_threshold_ = 0; int SatLinkHandoffMgr::sat_handoff_int_ = 10; SatLinkHandoffMgr::SatLinkHandoffMgr() : timer_(this) { bind("sat_handoff_int_", &sat_handoff_int_); bind("latitude_threshold_", &latitude_threshold_); bind("longitude_threshold_", &longitude_threshold_); } // // This function is responsible for activating, deactivating, and handing off

PAGE 77

69 // satellite ISLs. If the ISL is an intraplane link, // do nothing. If the ISL is an interplane link, it will be taken down // when _either_ of the connected satellites are above lat_threshold_ // degrees, and brought back up when _both_ satellites move below // lat_threshold_ again. If an ISL is a cross-seam link, it must also be // handed off periodically while the satellite is below lat_threshold_. // // Finally, optimizations that avoid going through the linked lists unless // the satellite is ``close'' to lat_threshold_ are employed. // int SatLinkHandoffMgr::handoff() { SatLinkHead *slhp, *peer_slhp, *peer_next_slhp; SatNode *local_, *peer_, *peer_next_; PolarSatPosition *pos_, *peer_pos_, *peer_next_pos_; double dist_to_peer, dist_to_next; Channel *tx_channel_, *rx_channel_; double sat_latitude_, sat_longitude_, peer_latitude_, peer_longitude_; int link_down_flag_; double lat_threshold_ = DEG_TO_RAD(latitude_threshold_); double cross_long_threshold_ = DEG_TO_RAD(longitude_threshold_); int link_changes_flag_ = FALSE; // Flag indicating change took place coordinate local_coord_, peer_coord_; bool LEO; local_ = (SatNode*) node_; local_coord_ = local_->position()->coord(); sat_latitude_ = SatGeometry::get_latitude(local_->position()->coord()); sat_longitude_= SatGeometry::get_longitude(local_->position()->coord()); // First go through crossseam ISLs to search for handoffs for (slhp = (SatLinkHead*) local_->linklisthead().lh_first; slhp; slhp = (SatLinkHead*) slhp->nextlinkhead() ) { if (slhp->type() != LINK_ISL_CROSSSEAM) continue; peer_ = get_peer(slhp); if (peer_ == 0) continue; // this link interface is not attached // If this is a crossseam link, first see if the link must // be physically handed off to the next satellite. // Handoff is needed if the satellite at the other end of // the link is further away than the ``next'' satellite // in the peer's orbital plane. pos_ = (PolarSatPosition*)slhp->node()->position(); peer_slhp = get_peer_linkhead(slhp); peer_pos_ = (PolarSatPosition*) peer_->position(); peer_coord_ = peer_pos_->coord(); if (fabs(sat_latitude_) > lat_threshold_) link_down_flag_ = TRUE; else link_down_flag_ = FALSE; if (peer_pos_->plane() < pos_->plane()) { // Crossseam handoff is controlled by satellites // in the plane with a lower index break; }

PAGE 78

70 peer_next_pos_ = peer_pos_->next(); if (!peer_next_pos_) { printf("Error: crossseam handoffs require "); printf("setting the ``next'' field\n"); exit(1); } peer_next_ = (SatNode*) peer_next_pos_->node(); dist_to_peer = SatGeometry::distance(peer_coord_, local_coord_); dist_to_next = SatGeometry::distance(peer_next_pos_->coord(), local_coord_); if (dist_to_next < dist_to_peer) { // Handoff -the "next" satellite should have a // currently unused network stack. Find this // unused stack and handoff the channels to it. // // Remove peer's tx/rx interface from channel peer_slhp->phy_rx()->removechnl(); peer_slhp->phy_tx()->setchnl(0); peer_slhp->phy_rx()->setchnl(0); // Add peer_next's tx/rx interfaces to our channels peer_next_slhp = get_peer_next_linkhead(peer_next_); tx_channel_ = slhp->phy_tx()->channel(); rx_channel_ = slhp->phy_rx()->channel(); peer_next_slhp->phy_tx()->setchnl(rx_channel_); peer_next_slhp->phy_rx()->setchnl(tx_channel_); peer_next_slhp->phy_rx()->insertchnl(&(tx_channel_->ifhead_)); link_changes_flag_ = TRUE; // Now reset the peer_ variables to point to next peer_ = peer_next_; peer_slhp = peer_next_slhp; peer_coord_ = peer_->position()->coord(); } // Next, see if the link needs to be taken down. peer_latitude_ = SatGeometry::get_latitude(peer_coord_); peer_longitude_ = SatGeometry::get_longitude(peer_coord_); if (fabs(peer_latitude_) > lat_threshold_) link_down_flag_ = TRUE; // If the two satellites are too close to each other in // longitude, the link should be down if ((fabs(peer_longitude_ sat_longitude_) < cross_long_threshold_) || fabs(peer_longitude_ sat_longitude_) > (2 * PI cross_long_threshold_)) link_down_flag_ = TRUE; // Check to see if link grazes atmosphere at an altitude // below the atmospheric margin link_down_flag_ |= !(SatGeometry::are_satellites_mutually_visible(peer_coord_, local_coord_)); // Evaluate whether a change in link status is needed if ((slhp->linkup_ || peer_slhp->linkup_) && link_down_flag_) { slhp->linkup_ = FALSE; peer_slhp->linkup_ = FALSE; link_changes_flag_ = TRUE; } else if ((!slhp->linkup_ || !peer_slhp->linkup_) && !link_down_flag_) {

PAGE 79

71 slhp->linkup_ = TRUE; peer_slhp->linkup_ = TRUE; link_changes_flag_ = TRUE; } } // Now, work on interplane ISLs (intraplane ISLs are not handed off) // Now search for interplane ISLs for (slhp = (SatLinkHead*) local_->linklisthead().lh_first; slhp; slhp = (SatLinkHead*) slhp->nextlinkhead() ) { if (slhp->type() != LINK_ISL_INTERPLANE) continue; peer_ = get_peer(slhp); peer_slhp = get_peer_linkhead(slhp); peer_coord_ = peer_->position()->coord(); peer_latitude_ = SatGeometry::get_latitude(peer_coord_); ////////////////////////////////////////////////////// // Mark Foster modified the following segment of code. double lalt = SatGeometry::get_altitude(local_coord_); double palt = SatGeometry::get_altitude(peer_coord_); if(lalt == palt) LEO = TRUE; else LEO = FALSE; if ((fabs(sat_latitude_) > lat_threshold_) && LEO) link_down_flag_ = TRUE; else link_down_flag_ = FALSE; if ((fabs(peer_latitude_) > lat_threshold_) && LEO) link_down_flag_ = TRUE; link_down_flag_ |= !(SatGeometry::are_satellites_mutually_visible(peer_coord_, local_coord_)); if (slhp->linkup_ && link_down_flag_) { // Take links down if either satellite at high latitude slhp->linkup_ = FALSE; peer_slhp->linkup_ = FALSE; link_changes_flag_ = TRUE; } else if (!slhp->linkup_ && !link_down_flag_) { slhp->linkup_ = TRUE; peer_slhp->linkup_ = TRUE; link_changes_flag_ = TRUE; } // End of modifications – MF ///////////////////////////////////////////////////// } if (link_changes_flag_) {

PAGE 80

72 SatRouteObject::instance().recompute(); } if (handoff_randomization_) { timer_.resched(sat_handoff_int_ + handoff_rng_.uniform(-1 * sat_handoff_int_/2, sat_handoff_int_/2)); } else timer_.resched(sat_handoff_int_); return link_changes_flag_; } Satlink.cc /* -*Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -**/ /* * Copyright (c) 1999 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the MASH Research * Group at the University of California Berkeley. * 4. Neither the name of the University nor of the Research Group may be * used to endorse or promote products derived from this software without * specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * Contributed by Tom Henderson, UCB Daedalus Research Group, June 1999 */ #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/satlink.cc,v 1.8 1999/10/26 17:35:08 tomh Exp $"; #endif /* * Contains source code for: * SatLinkHead

PAGE 81

73 * SatLL * SatMac * SatPhy * SatChannel */ #include "satlink.h" #include "sattrace.h" #include "satposition.h" #include "satgeometry.h" #include "satnode.h" #include "errmodel.h" //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster #include #include #include #include #include #include // End of modifications – MF //////////////////////////////////////////////////////////// /*===================================================================*/ /* * _SatLinkHead */ static class SatLinkHeadClass : public TclClass { public: SatLinkHeadClass() : TclClass("Connector/LinkHead/Sat") {} TclObject* create(int, const char*const*) { return (new SatLinkHead); } } class_sat_link_head; SatLinkHead::SatLinkHead() : linkup_(1), phy_tx_(0), phy_rx_(0), mac_(0), satll_(0), queue_(0), errmodel_(0) { } int SatLinkHead::command(int argc, const char*const* argv) { if (argc == 2) { } else if (argc == 3) { if (strcmp(argv[1], "set_type") == 0) { if (strcmp(argv[2], "geo") == 0) { type_ = LINK_GSL_GEO; return TCL_OK; } else if (strcmp(argv[2], "polar") == 0) { type_ = LINK_GSL_POLAR; return TCL_OK; } else if (strcmp(argv[2], "gsl") == 0) {

PAGE 82

74 type_ = LINK_GSL; return TCL_OK; } else if (strcmp(argv[2], "gsl-repeater") == 0) { type_ = LINK_GSL_REPEATER; return TCL_OK; } else if (strcmp(argv[2], "interplane") == 0) { type_ = LINK_ISL_INTERPLANE; return TCL_OK; } else if (strcmp(argv[2], "intraplane") == 0) { type_ = LINK_ISL_INTRAPLANE; return TCL_OK; } else if (strcmp(argv[2], "crossseam") == 0) { type_ = LINK_ISL_CROSSSEAM; return TCL_OK; } else { printf("Unknown link type: %s\n", argv[2]); exit(1); } } if (strcmp(argv[1], "setll") == 0) { satll_ = (SatLL*) TclObject::lookup(argv[2]); if (satll_ == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "setphytx") == 0) { phy_tx_ = (SatPhy*) TclObject::lookup(argv[2]); if (phy_tx_ == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "setphyrx") == 0) { phy_rx_ = (SatPhy*) TclObject::lookup(argv[2]); if (phy_rx_ == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "setmac") == 0) { mac_ = (SatMac*) TclObject::lookup(argv[2]); if (mac_ == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "setqueue") == 0) { queue_ = (Queue*) TclObject::lookup(argv[2]); if (queue_ == 0) return TCL_ERROR; return TCL_OK; } else if(strcmp(argv[1], "seterrmodel") == 0) { errmodel_ = (ErrorModel*) TclObject::lookup(argv[2]); if (errmodel_ == 0) return TCL_ERROR; return TCL_OK; } } return (LinkHead::command(argc, argv)); } /*===================================================================*/ /*

PAGE 83

75 * _SatLL */ static class SatLLClass : public TclClass { public: SatLLClass() : TclClass("LL/Sat") {} TclObject* create(int, const char*const*) { return (new SatLL); } } sat_class_ll; void SatLL::recv(Packet* p, Handler* /*h*/) { hdr_cmn *ch = HDR_CMN(p); /* * Sanity Check */ assert(initialized()); // If direction = UP, then pass it up the stack // Otherwise, set direction to DOWN and pass it down the stack if(ch->direction() == hdr_cmn::UP) { uptarget_ ? sendUp(p) : drop(p); return; } ch->direction() = hdr_cmn::DOWN; sendDown(p); } // Encode link layer sequence number, type, and mac address fields void SatLL::sendDown(Packet* p) { hdr_cmn *ch = HDR_CMN(p); hdr_ll *llh = HDR_LL(p); char *mh = (char*)p->access(hdr_mac::offset_); int peer_mac_; SatChannel* satchannel_; llh->seqno_ = ++seqno_; llh->lltype() = LL_DATA; // Set mac src, type, and dst mac_->hdr_src(mh, mac_->addr()); mac_->hdr_type(mh, ETHERTYPE_IP); // We'll just use ETHERTYPE_IP nsaddr_t dst = ch->next_hop(); // a value of -1 is IP_BROADCAST if (dst < -1) { printf("Error: next_hop_ field not set by routing agent\n"); exit(1); }

PAGE 84

76 //////////////////////////////////////////////////////////// // The following line of code was moved from its orignal location. // Mark Foster satchannel_ = (SatChannel*) channel(); //////////////////////////////////////////////////////////// switch(ch->addr_type()) { case NS_AF_INET: case NS_AF_NONE: if (IP_BROADCAST == (u_int32_t) dst) { mac_->hdr_dst((char*) HDR_MAC(p), MAC_BROADCAST); break; } /* * Here is where arp would normally occur. In the satellite * case, we don't arp (for now). Instead, use destination * address to find the mac address corresponding to the * peer connected to this channel. If someone wants to * add arp, look at how the wireless code does it. */ // Cache latest value used if (dst == arpcachedst_) { mac_->hdr_dst((char*) HDR_MAC(p), arpcache_); break; } // Search for peer's mac address (this is the pseudo-ARP) peer_mac_ = satchannel_->find_peer_mac_addr(dst); if (peer_mac_ < 0 ) { printf("Error: couldn't find dest mac on channel "); printf("NOW %f\n", NOW); exit(1); } else { mac_->hdr_dst((char*) HDR_MAC(p), peer_mac_); arpcachedst_ = dst; arpcache_ = peer_mac_; break; } default: printf("Error: addr_type not set to NS_AF_INET or NS_AF_NONE\n"); exit(1); } // let mac decide when to take a new packet from the queue. Scheduler& s = Scheduler::instance(); //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster // Find the sattype and store it in the packet.

PAGE 85

77 int SatType = satchannel_->find_type(dst); ch->sat_type_ = SatType; // Reschedule the time for the beginning of the next slot. double OriginalSched = delay_ + NOW; int Orig = OriginalSched * 100000; int Temp = Orig % 300; double t2, t1 = Temp; if(t1 == 0) { t2 = 0; } else { t2 = 300 t1; } double newdelay = delay_ + (t2/100000); s.schedule(downtarget_, p, newdelay); //s.schedule(downtarget_, p, delay_); // End of modifications MF //////////////////////////////////////////////////////////// } void SatLL::sendUp(Packet* p) { //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster // Read the file to get the delay value. This segment was added to // help automate the simulations. ifstream delayptr; delayptr.open("delay.dat", ios::in); int i = 0, delay; char num; char *number = new char[8]; double tmpdelay; for(i=0;i<8;i++) { number[i] = 0; } i = 0; while(delayptr.get(num) != 0) { if(isdigit(num)) { number[i] = num; i++; } } // Convert the char array to an integer. delay = atoi(number);

PAGE 86

78 // Convert the integer to a double. tmpdelay = delay; // Close the filepointer. delayptr.close(); // Set the value of the delay in milliseconds. delay_ = tmpdelay/1000; //////////////////////////////////////////////////////////// // Write to file that Packet was Received // In addition, set collisions to 0 hdr_cmn* cmnh = HDR_CMN(p); hdr_mac* mhy = HDR_MAC(p); cmnh->collisions_ = 0; int uniqueid = cmnh->uid(); int dest = mhy->macDA_; ofstream fileptr; fileptr.open("packet.dat", ios::app); fileptr << uniqueid << ":" << dest << ":"; fileptr.close(); // End of modifications MF //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// Scheduler& s = Scheduler::instance(); if (hdr_cmn::access(p)->error() > 0) drop(p); else s.schedule(uptarget_, p, delay_); } // Helper function Channel* SatLL::channel() { Phy* phy_ = (Phy*) mac_->downtarget(); return phy_->channel(); } /*===================================================================*/ /* * _SatMac */ static class SatMacClass : public TclClass { public: SatMacClass() : TclClass("Mac/Sat") {} TclObject* create(int, const char*const*) { return (new SatMac);

PAGE 87

79 } } sat_class_mac; void MacSendTimer::expire(Event*) { a_->send_timer(); } void MacRecvTimer::expire(Event*) { a_->recv_timer(); } int SatMac::command(int argc, const char*const* argv) { if(argc == 2) { } else if (argc == 3) { TclObject *obj; if( (obj = TclObject::lookup(argv[2])) == 0) { fprintf(stderr, "%s lookup failed\n", argv[1]); return TCL_ERROR; } if (strcmp(argv[1], "channel") == 0) { //channel_ = (Channel*) obj; return (TCL_OK); } } return Mac::command(argc, argv); } void SatMac::sendUp(Packet* p) { hdr_mac* mh = HDR_MAC(p); int dst = this->hdr_dst((char*)mh); // mac destination address if (((u_int32_t)dst != MAC_BROADCAST) && (dst != index_)) { drop(p); return; } // First bit of packet has arrived-wait for // (txtime + delay_) before sending up Scheduler::instance().schedule(uptarget_, p, delay_ + mh->txtime()); } void SatMac::sendDown(Packet* p) { Scheduler& s = Scheduler::instance(); double txt; // LINK_HDRSIZE is defined in satlink.h. This is the size of header // information for all layers below IP. Alternatively, one could // derive this information dynamically from packet headers. int packetsize_ = HDR_CMN(p)->size() + LINK_HDRSIZE;

PAGE 88

80 if (bandwidth_ != 0) txt = txtime(packetsize_); // For convenience, we encode the transmit time in the Mac header // The packet will be held (for collision detection) for txtime // at the receiving mac. HDR_MAC(p)->txtime() = txt; downtarget_->recv(p, this); // Callback for when this packet's transmission will be done s.schedule(&hRes_, &intr_, txt); } static class UnslottedAlohaMacClass : public TclClass { public: UnslottedAlohaMacClass() : TclClass("Mac/Sat/UnslottedAloha") {} TclObject* create(int, const char*const*) { return (new UnslottedAlohaMac()); } } sat_class_unslottedalohamac; /*===================================================================*/ /* * _UnslottedAlohaMac */ UnslottedAlohaMac::UnslottedAlohaMac() : SatMac(), tx_state_(MAC_IDLE), rx_state_(MAC_IDLE), rtx_(0), end_of_contention_(0) { bind_time("mean_backoff_", &mean_backoff_); bind("rtx_limit_", &rtx_limit_); ////////////////////////////////////////////////////////////// // Begin modifications by Mark Foster bind_time("send_timeout_type1_", &send_timeout_type1_); bind_time("send_timeout_type2_", &send_timeout_type2_); bind_time("slot_length_", &slot_length_); // End of modifications MF //////////////////////////////////////////////////////////// } void UnslottedAlohaMac::send_timer() { switch (tx_state_) { case MAC_SEND: // We've timed out on send-back off back off(); break; case MAC_COLL: // Our back off timer has expired-resend sendDown(snd_pkt_); break; default: printf("Error: wrong tx_state in unslotted aloha: %d\n",

PAGE 89

81 tx_state_); break; } } void UnslottedAlohaMac::recv_timer() { switch (rx_state_) { case MAC_RECV: // We've successfully waited out the reception end_of_contention(rcv_pkt_); break; default: printf("Error: wrong rx_state in unslotted aloha: %d\n", rx_state_); break; } } void UnslottedAlohaMac::sendUp(Packet* p) { hdr_mac* mh = HDR_MAC(p); if (rx_state_ == MAC_IDLE) { // First bit of packet has arrived-wait for // txtime to make sure no collisions occur rcv_pkt_ = p; end_of_contention_ = NOW + mh->txtime(); rx_state_ = MAC_RECV; recv_timer_.resched(mh->txtime()); } else { // Collision: figure out if contention phase must be lengthened double temp = NOW + mh->txtime(); if (temp > end_of_contention_) { recv_timer_.resched(temp NOW); } drop(p); if (rcv_pkt_) drop(rcv_pkt_); rcv_pkt_ = 0; } } void UnslottedAlohaMac::sendDown(Packet* p) { double txt; // compute transmission delay: int packetsize_ = HDR_CMN(p)->size() + LINK_HDRSIZE; if (bandwidth_ != 0) txt = txtime(packetsize_); HDR_MAC(p)->txtime() = txt; // Send the packet down

PAGE 90

82 tx_state_ = MAC_SEND; snd_pkt_ = p->copy(); // save a copy in case it gets retransmitted downtarget_->recv(p, this); //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster //// Reschedule for the beginning of next slot time. double OriginalSched = NOW + send_timeout_type1_ + txt; int Orig = OriginalSched * 100000; int Temp = Orig % 300; double t2, t1 = Temp; if(t1 == 0) { t2 = 0; } else { t2 = 300 t1; } double NewSched = OriginalSched + (t2/100000); // Set a timer-if we do not hear our own transmission within this // interval (and cancel the timer), the send_timer will expire and // we will back off and retransmit. //send_timer_.resched(send_timeout_ + txt); send_timer_.resched(NewSched NOW); // End of modifications – MF //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// } // Called when contention period ends void UnslottedAlohaMac::end_of_contention(Packet* p) { rx_state_ = MAC_IDLE; if (!p) return; // No packet to free or send up. hdr_mac* mh = HDR_MAC(p); int dst = this->hdr_dst((char*)mh); // mac destination address int src = this->hdr_src((char*)mh); // mac source address if (((u_int32_t)dst != MAC_BROADCAST) && (dst != index_) && (src != index_)) { drop(p); return; } if (src == index_) { // received our own packet: free up transmit side, drop this // packet, and perform callback to queue which is blocked if (!callback_) { printf("Error, queue callback_ is not valid\n");

PAGE 91

83 exit(1); } send_timer_.force_cancel(); tx_state_ = MAC_IDLE; rtx_ = 0; drop(snd_pkt_); // Free the packet cached for retransmission resume(p); } else { // wait for processing delay (delay_) to send packet upwards Scheduler::instance().schedule(uptarget_, p, delay_); } } void UnslottedAlohaMac::backoff(double delay) { //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster // Increment the number of collisions. int colls = HDR_CMN(snd_pkt_)->collisions_; colls = colls + 1; HDR_CMN(snd_pkt_)->collisions_ = colls; //////////////////////////////////////////////////////////// // Check the file to see if this really needs to be sent. hdr_cmn* cmnh = HDR_CMN(snd_pkt_); hdr_mac* mhy = HDR_MAC(snd_pkt_); int uniqueid = cmnh->uid(); int dst = mhy->macDA_; ifstream fileptr; fileptr.open("packet.dat", ios::in); char num; int i = 0, flag = 0, k; int thisnum; int thisstation; char *number = new char[8]; char *station = new char[8]; int *numbers1 = new int[2500]; int *numbers2 = new int[2500]; int m, n; for(m=0;m<8;m++) { number[m] = 0; station[m] = 0; } for(n=0;n<2500;n++) { numbers1[n] = 0; numbers2[n] = 0; } while(fileptr.get(num) != 0) { if(isdigit(num) && flag == 0)

PAGE 92

84 { number[i] = num; i++; } else if(isdigit(num) && flag == 1) { station[i] = num; i++; } else { if(flag == 0) { i = 0; flag = 1; thisnum = atoi(number); } else { i = 0; flag = 0; thisstation = atoi(station); if(numbers1[thisnum] == 0) { numbers1[thisnum] = thisstation; } else { numbers2[thisnum] = thisstation; } for(k=0;k<8;k++) { number[k] = 0; station[k] = 0; } } } } fileptr.close(); //////////////////////////////////////////////////////////// // Replace the old random back off with packet specific version. // double back off_ = Random::exponential(mean_backoff_); double back off_ = ExpRandomBack(colls); // Check arrays generated from file to see if packet was // already sent and received. if(numbers1[uniqueid] == dst || numbers2[uniqueid] == dst) { rtx_ = rtx_limit_ + 1; } // if number of retransmissions is within limit, do exponential back off // else drop the packet and resume if (++rtx_ <= rtx_limit_) { tx_state_ = MAC_COLL;

PAGE 93

85 delay += back off_; //////////////////////////////////////////////////////////// // Reschedule the send for beginning of next time slot. double OriginalSched = NOW + delay; int Orig = OriginalSched * 100000; int Temp = Orig % 300; double t2, t1 = Temp; if(t1 == 0) { t2 = 0; } else { t2 = 300 t1; } double NewSched = OriginalSched + (t2/100000); double newdelay = NewSched NOW; //////////////////////////////////////////////////////////// //send_timer_.resched(delay); send_timer_.resched(newdelay); // End of modifications MF //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////// } else { tx_state_ = MAC_IDLE; rtx_ = 0; resume(snd_pkt_); } } //////////////////////////////////////////////////////////// //// Begin modifications by Mark Foster double UnslottedAlohaMac::ExpRandomBack(int colls) { int bound = (pow(2, colls)) 1; double backing = (rand() % bound) + 1; backing = backing * slot_length_; return backing; } // End of modifications – MF //////////////////////////////////////////////////////////// /*===================================================================*/ /*

PAGE 94

86 * _SatPhy */ static class SatPhyClass: public TclClass { public: SatPhyClass() : TclClass("Phy/Sat") {} TclObject* create(int, const char*const*) { return (new SatPhy); } } class_SatPhy; void SatPhy::sendDown(Packet *p) { if (channel_) channel_->recv(p, this); else { // it is possible for routing to change (and a channel to // be disconnected) while a packet // is moving down the stack. Therefore, just log a drop // if there is no channel if ( ((SatNode*) head()->node())->trace() ) ((SatNode*) head()->node())->trace()->traceonly(p); Packet::free(p); } } // Note that this doesn't do that much right now. If you want to incorporate // an error model, you could insert a "propagation" object like in the // wireless case. int SatPhy::sendUp(Packet * /* pkt */) { return TRUE; } int SatPhy::command(int argc, const char*const* argv) { if (argc == 2) { } else if (argc == 3) { TclObject *obj; if( (obj = TclObject::lookup(argv[2])) == 0) { fprintf(stderr, "%s lookup failed\n", argv[1]); return TCL_ERROR; } } return Phy::command(argc, argv); } static class RepeaterPhyClass: public TclClass { public: RepeaterPhyClass() : TclClass("Phy/Repeater") {} TclObject* create(int, const char*const*) { return (new RepeaterPhy); } } class_RepeaterPhy;

PAGE 95

87 void RepeaterPhy::recv(Packet* p, Handler*) { struct hdr_cmn *hdr = HDR_CMN(p); if (hdr->direction() == hdr_cmn::UP) { // change direction and send to uptarget (which is // really a Phy_tx that is also a RepeaterPhy) hdr->direction() = hdr_cmn::DOWN; uptarget_->recv(p, (Handler*) 0); } else { sendDown(p); } } void RepeaterPhy::sendDown(Packet *p) { struct hdr_cmn *hdr = HDR_CMN(p); hdr->direction() = hdr_cmn::DOWN; if (channel_) channel_->recv(p, this); else { printf("Error, no channel on repeater\n"); exit(1); } } /*===================================================================*/ /* * _SatChannel */ static class SatChannelClass : public TclClass { public: SatChannelClass() : TclClass("Channel/Sat") {} TclObject* create(int, const char*const*) { return (new SatChannel); } } class_Sat_channel; SatChannel::SatChannel(void) : Channel() { } double SatChannel::get_pdelay(Node* tnode, Node* rnode) { coordinate a = ((SatNode*)tnode)->position()->coord(); coordinate b = ((SatNode*)rnode)->position()->coord(); return (SatGeometry::propdelay(a, b)); } // This is a helper function that attaches a SatChannel to a Phy void SatChannel::add_interface(Phy* phy_) { phy_->setchnl(this); // Attach phy to this channel phy_->insertchnl(&ifhead_); // Add phy_ to list of phys on the channel }

PAGE 96

88 // Remove a phy from a channel void SatChannel::remove_interface(Phy* phy_) { phy_->setchnl(NULL); // Set phy_'s channel pointer to NULL phy_->removechnl(); // Remove phy_ to list of phys on the channel } // Search for destination mac address on this channel. Look through list // of phys on the channel. If the channel connects to a geo repeater, look // for the destination on the corresponding downlink channel. int SatChannel::find_peer_mac_addr(int dst) { Phy *n; Channel* chan_; chan_ = this; n = ifhead_.lh_first; if (n->head()->type() == LINK_GSL_REPEATER) { SatLinkHead* slh = (SatLinkHead*) n->head(); chan_ = slh->phy_tx()->channel(); } for(n = chan_->ifhead_.lh_first; n; n = n->nextchnl() ) { if (n->node()->address() == dst) { return (((SatMac*) n->uptarget())->addr()); } } return -1; } // Marky782 added this helper function. int SatChannel::find_type(int dst) { Phy *n; Channel* chan_; chan_ = this; n = ifhead_.lh_first; SatLinkHead* slh; for(n = chan_->ifhead_.lh_first; n; n = n->nextchnl() ) { if (n->node()->address() == dst) { slh = (SatLinkHead*) n->head(); return slh->node()->position()->type(); } } return -1; } Satroute.cc /* -*Mode:C++; c-basic-offset:8; tab-width:8; indent-tabs-mode:t -**/ /* * Copyright (c) 1999 Regents of the University of California.

PAGE 97

89 * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the MASH Research * Group at the University of California Berkeley. * 4. Neither the name of the University nor of the Research Group may be * used to endorse or promote products derived from this software without * specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * Contributed by Tom Henderson, UCB Daedalus Research Group, June 1999 */ #ifndef lint static const char rcsid[] = "@(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/satroute.cc,v 1.11 2000/09/01 03:04:07 haoboy Exp $"; #endif #include "satroute.h" #include "sattrace.h" #include "satnode.h" #include "satlink.h" #include "route.h" #include static class SatRouteClass:public TclClass { public: SatRouteClass ():TclClass ("Agent/SatRoute") { } TclObject *create (int, const char *const *) { return (new SatRouteAgent ()); } } class_satroute; SatRouteAgent::SatRouteAgent (): Agent (PT_MESSAGE), maxslot_(0), nslot_(0), slot_(0) { bind ("myaddr_", &myaddr_); }

PAGE 98

90 SatRouteAgent::~SatRouteAgent() { if (slot_) delete [] slot_; } void SatRouteAgent::alloc(int slot) { slot_entry *old = slot_; int n = nslot_; if (old == 0) nslot_ = 32; while (nslot_ <= slot) nslot_ <<= 1; slot_ = new slot_entry[nslot_]; memset(slot_, 0, nslot_ * sizeof(slot_entry)); for (int i = 0; i < n; ++i) { slot_[i].next_hop = old[i].next_hop; slot_[i].entry = old[i].entry; } delete [] old; } void SatRouteAgent::install(int slot, int nh, NsObject* p) { if (slot >= nslot_) alloc(slot); slot_[slot].next_hop = nh; slot_[slot].entry = p; if (slot >= maxslot_) maxslot_ = slot; } void SatRouteAgent::clear_slots() { if (slot_) delete [] slot_; slot_ = 0; nslot_ = 0; maxslot_ = -1; } int SatRouteAgent::command (int argc, const char *const *argv) { Tcl& tcl = Tcl::instance(); if (argc == 2) { } if (argc == 3) { if (strcmp(argv[1], "set_node") == 0) { node_ = (SatNode *) TclObject::lookup(argv[2]); if (node_ == 0) { tcl.resultf("no such object %s", argv[2]); return (TCL_ERROR); } return (TCL_OK);

PAGE 99

91 } } return (Agent::command (argc, argv)); } /* * Find a target for the received packet */ void SatRouteAgent::forwardPacket(Packet * p) { hdr_ip *iph = hdr_ip::access(p); hdr_cmn *hdrc = HDR_CMN (p); NsObject *link_entry_; hdrc->direction() = hdr_cmn::DOWN; // send it down the stack int dst = Address::instance().get_nodeaddr(iph->daddr()); // Here we need to have an accurate encoding of the next hop routing // information if (myaddr_ == iph->daddr()) { printf("Error: trying to forward a packet destined to self: %d\n", myaddr_); Packet::free(p); } hdrc->addr_type_ = NS_AF_INET; hdrc->last_hop_ = myaddr_; // for tracing purposes if (SatRouteObject::instance().data_driven_computation()) SatRouteObject::instance().recompute_node(myaddr_); if (SatNode::dist_routing_ == 0) { if (slot_ == 0) { // No routes to anywhere if (node_->trace()) node_->trace()->traceonly(p); Packet::free(p); return; } link_entry_ = slot_[dst].entry; if (link_entry_ == 0) { if (node_->trace()) node_->trace()->traceonly(p); Packet::free(p); return; } hdrc->next_hop_ = slot_[dst].next_hop; link_entry_->recv(p, (Handler *)0); return; } else { // DISTRIBUTED ROUTING LOOKUP COULD GO HERE printf("Error: distributed routing not available\n"); exit(1); } } void SatRouteAgent::recv (Packet * p, Handler *) { hdr_ip *iph = hdr_ip::access(p); hdr_cmn *cmh = hdr_cmn::access(p); if (iph->saddr() == myaddr_ && cmh->num_forwards() == 0) {

PAGE 100

92 // Must be a packet I'm originating... add the IP header iph->ttl_ = IP_DEF_TTL; } else if (iph->saddr() == myaddr_) { // I received a packet that I sent. Probably a routing loop. Packet::free(p); return; } else { // Packet I'm forwarding... // Check the TTL. If it is zero, then discard. if(--iph->ttl_ == 0) { Packet::free(p); return; } } if ((iph->saddr() != myaddr_) && (iph->dport() == ROUTER_PORT)) { // DISTRIBUTED ROUTING PROTOCOL COULD GO HERE printf("Error: distributed routing not available\n"); exit(1); } else { forwardPacket(p); } } //########################################################################### static class SatRouteObjectClass:public TclClass { public: SatRouteObjectClass ():TclClass ("SatRouteObject") { } TclObject *create (int, const char *const *) { return (new SatRouteObject ()); } } class_satrouteobject; SatRouteObject* SatRouteObject::instance_; SatRouteObject::SatRouteObject() : suppress_initial_computation_(0) { bind_bool("metric_delay_", &metric_delay_); bind_bool("data_driven_computation_", &data_driven_computation_); bind_bool("node_delay_", &node_delay_); } int SatRouteObject::command (int argc, const char *const *argv) { if (instance_ == 0) instance_ = this; if (argc == 2) { // While suppress_initial_computation_ may seem more // appropriate as a bound variable, it is useful to // implement the setting of this variable this way so that // the ``instance_ = this'' assignment is made at the // start of simulation. if (strcmp(argv[1], "suppress_initial_computation") == 0) { suppress_initial_computation_ = 1;

PAGE 101

93 return (TCL_OK); } if (strcmp(argv[1], "compute_routes") == 0) { recompute(); return (TCL_OK); } } return (RouteLogic::command(argc, argv)); } void SatRouteObject::recompute_node(int node) { compute_topology(); node_compute_routes(node); populate_routing_tables(node); } void SatRouteObject::recompute() { // For very large topologies (e.g., Teledesic), we don't want to // waste a lot of time computing routes at the beginning of the // simulation. This first if() clause suppresses route computations. if (data_driven_computation_ || (NOW < 0.001 && suppress_initial_computation_) ) return; else { compute_topology(); compute_routes(); // calls base class function populate_routing_tables(); } } // Derives link adjacency information from the nodes and gives the current // topology information to the RouteLogic. void SatRouteObject::compute_topology() { Node *nodep; Phy *phytxp, *phyrxp, *phytxp2, *phyrxp2; SatLinkHead *slhp; Channel *channelp, *channelp2; int src, dst; double delay; reset_all(); // Compute adjacencies. Traverse linked list of nodes for (nodep=Node::nodehead_.lh_first; nodep; nodep = nodep->nextnode()) { // Cycle through the linked list of linkheads for (slhp = (SatLinkHead*) nodep->linklisthead().lh_first; slhp; slhp = (SatLinkHead*) slhp->nextlinkhead()) { if (slhp->type() == LINK_GSL_REPEATER) continue; if (!slhp->linkup_) continue; phytxp = (Phy *) slhp->phy_tx(); assert(phytxp); channelp = phytxp->channel();

PAGE 102

94 if (!channelp) continue; // Not currently connected to channel // Next, look for receive interfaces on this channel phyrxp = channelp->ifhead_.lh_first; for (; phyrxp; phyrxp = phyrxp->nextchnl()) { if (phyrxp == phytxp) { printf("Configuration error: a transmit interface \ is a channel target\n"); exit(1); } if (phyrxp->head()->type() == LINK_GSL_REPEATER) { double delay_firsthop = ((SatChannel*) channelp)->get_pdelay(phytxp->node(), phyrxp->node()); if (!((SatLinkHead*)phyrxp->head())->linkup_) continue; phytxp2 = ((SatLinkHead*)phyrxp->head())->phy_tx(); channelp2 = phytxp2->channel(); if (!channelp2) continue; // Not currently connected to channel phyrxp2 = channelp2->ifhead_.lh_first; for (; phyrxp2; phyrxp2 = phyrxp2->nextchnl()) { if (phyrxp2 == phytxp2) { printf("Config error: a transmit interface \ is a channel target\n"); exit(1); } // Found an adjacency relationship. // Add this link to the RouteLogic src = phytxp->node()->address() + 1; dst = phyrxp2->node()->address() + 1; if (src == dst) continue; if (metric_delay_) delay = ((SatChannel*) channelp2)->get_pdelay(phytxp2->node(), phyrxp2->node()); else { delay = 1; delay_firsthop = 0; } insert(src, dst, delay+delay_firsthop, (void*)slhp); } } else { // Found an adjacency relationship. // Add this link to the RouteLogic src = phytxp->node()->address() + 1; dst = phyrxp->node()->address() + 1; if (metric_delay_) delay = ((SatChannel*) channelp)->get_pdelay(phytxp->node(), phyrxp->node()); else delay = 1; //////////////////////////////////////////////////////

PAGE 103

95 // Mark Foster modified the following segment of code. //insert(src, dst, delay, (void*)slhp); double dnode_delay_ = node_delay_; double ndelay = dnode_delay_ / 1000; insert(src, dst, delay+ndelay, (void*)slhp); // End of modifications MF ////////////////////////////////////////////////////// } } } } //dump(); } void SatRouteObject::populate_routing_tables(int node) { SatNode *snodep = (SatNode*) Node::nodehead_.lh_first; SatNode *snodep2; int next_hop, src, dst; NsObject *target; for (; snodep; snodep = (SatNode*) snodep->nextnode()) { // First, clear slots of the current routing table if (snodep->ragent()) snodep->ragent()->clear_slots(); src = snodep->address(); if (node != -1 && node != src) continue; snodep2 = (SatNode*) Node::nodehead_.lh_first; for (; snodep2; snodep2 = (SatNode*) snodep2->nextnode()) { dst = snodep2->address(); next_hop = lookup(src, dst); if (next_hop != -1 && src != dst) { // Here need to insert target into slot table target = (NsObject*) lookup_entry(src, dst); if (target == 0) { printf("Error, routelogic target "); printf("not populated %f\n", NOW); exit(1); } ((SatNode*)snodep)->ragent()->install(dst, next_hop, target); } } } } int SatRouteObject::lookup(int s, int d) { int src = s + 1; int dst = d + 1; if (src >= size_ || dst >= size_) {

PAGE 104

96 return (-1); // Next hop = -1 } return (route_[INDEX(src, dst, size_)].next_hop 1); } void* SatRouteObject::lookup_entry(int s, int d) { int src = s + 1; int dst = d + 1; if (src >= size_ || dst >= size_) { return (0); // Null pointer } return (route_[INDEX(src, dst, size_)].entry); } // This method is used for debugging only void SatRouteObject::dump() { int i, src, dst; for (i = 0; i < (size_ * size_); i++) { if (adj_[i].cost != INFINITY) { src = i / size_ 1; dst = i % size_ 1; printf("Found a link from %d to %d with cost %f\n", src, dst, adj_[i].cost); } /* if (route_[i].next_hop) { src = i / size_ 1; dst = i % size_ 1; printf("Found a route from %d to %d through %d\n", src, dst, route_[i].next_hop 1); } */ } } void SatRouteObject::node_compute_routes(int node) { int n = size_; int* parent = new int[n]; double* hopcnt = new double[n]; #define ADJ(i, j) adj_[INDEX(i, j, size_)].cost #define ADJ_ENTRY(i, j) adj_[INDEX(i, j, size_)].entry #define ROUTE(i, j) route_[INDEX(i, j, size_)].next_hop #define ROUTE_ENTRY(i, j) route_[INDEX(i, j, size_)].entry delete[] route_; route_ = new route_entry[n * n]; memset((char *)route_, 0, n * n * sizeof(route_[0])); /* compute routes only for node "node" */ int k = node + 1; // must add one to get the right offset in tables int v; for (v = 0; v < n; v++) parent[v] = v; /* set the route for all neighbours first */ for (v = 1; v < n; ++v) {

PAGE 105

97 if (parent[v] != k) { hopcnt[v] = ADJ(k, v); if (hopcnt[v] != INFINITY) { ROUTE(k, v) = v; ROUTE_ENTRY(k, v) = ADJ_ENTRY(k, v); } } } for (v = 1; v < n; ++v) { /* * w is the node that is the nearest to the subtree * that has been routed */ int o = 0; /* XXX */ hopcnt[0] = INFINITY; int w; for (w = 1; w < n; w++) if (parent[w] != k && hopcnt[w] < hopcnt[o]) o = w; parent[o] = k; /* * update distance counts for the nodes that are * adjacent to o */ if (o == 0) continue; for (w = 1; w < n; w++) { if (parent[w] != k && hopcnt[o] + ADJ(o, w) < hopcnt[w]) { ROUTE(k, w) = ROUTE(k, o); ROUTE_ENTRY(k, w) = ROUTE_ENTRY(k, o); hopcnt[w] = hopcnt[o] + ADJ(o, w); } } } /* * The route to yourself is yourself. */ ROUTE(k, k) = k; ROUTE_ENTRY(k, k) = 0; // This should not matter delete[] hopcnt; delete[] parent; }

PAGE 106

LIST OF REFERENCES [1] S.J. Campanella, T.J. Kirkwood, “Faster than Fiber: Advantages and Challenges of LEO Communications Satellite Systems,” 1995, Downloaded Paper From: http://www.isr.umd.edu/TechReports/ISR/1995/, Downloaded on Feb. 14, 2001 [2] J. Galtier, “Routing Issues for LEO Satellite Constellations,” Scuola Superiore Guglielmo Reiss Romoli (SSGRR) , Paper Downloaded From: http://www.prism.uvsq.fr/~galtier/publications.html, Downloaded on Feb. 21, 2001 [3] T.R. Henderson, R.H. Katz, “Network Simulation for LEO Satellite Networks,” 18th AIAA International Communications Satellite Systems Conference (ICSSC), Oakland, CA, April 2000, Paper Downloaded From: http://www.cs.berkeley.edu/~tomh/papers/aiaa.pdf, Downloaded on Jan. 28, 2001 [4] A. Jamalipour, “ Low Earth Orbital Satellites for Personal Communication Networks ,” Artech House Publishers, Norwood, MA, 1998 [5] R. Mauger, C. Rosenberg, “QoS Guarantees for Multimedia Services on a TDMA-Base Satellite Network,” IEEE Commununications Magazine, pp. 56-65, July 1997 [6] M. Richharia, “ Satellite Communications Systems ,” Second Edition, McGraw-Hill Telecommunications, New York, NY, 1999 [7] R.A. Serway, “ Principles of Physics ,” Saunders College Publishing, Fort Worth, TX, 1994 [8] W. Stallings, “ Data and Computer Communications ,” Fifth Edition, Prentice Hall, Upper Saddle River, New Jersey, 1997 [9] Teledesic Homepage: http://www.teledesic.com, Most Recent Date Accessed: Dec. 6, 2001 [10] J. Wang, M. Eliciu, J. Liu, “Multimedia Support for Wireless WCDMA with Dynamic Spreading,” to appear in ACM Journal of Wireless Network, 2002. [11] M. Wittig, “Large-Capacity Multimedia Satellite Systems,” IEEE Commununications Magazine, pp. 44-49, July 1997 98

PAGE 107

99 [12] Network Simulator (NS), http://www.isi.edu/nsnam/ns, Most Recent Date Accessed: Dec. 6, 2001

PAGE 108

BIOGRAPHICAL SKETCH Mark Foster received the BS degree in Computer Science and Mathematics from Vanderbilt University in the Spring of 1999. Since the Fall of 1999, he has been a graduate assistant in the department of Computer and Information Science and Engineering at the University of Florida. His current interests are satellite and multimedia communications. He also enjoys teaching. 100