Satellite constellation networks for aeronautical

www.ietdl.org Published in IET Communications Received on 14th April 2009 Revised on 30th September 2009 doi: 10.1049/iet-com.2009.0260

In Special Issue on Satellite Systems, Applications and Networking ISSN 1751-8628

Satellite constellation networks for aeronautical communication: traffic modelling and link load analysis A. Donner C. Kissling R. Hermenier Institute of Communications and Navigation, German Aerospace Center (DLR), Oberpfaffenhofen, 82234 Weßling, Germany E-mail: [email protected]

Abstract: The authors examine two different non-geostationary satellite constellation networks with intersatellite links for global air traffic control and air passenger communication. After developing a traffic model for aeronautical communication services, the authors derive bandwidth requirements for such a global system. The influence of different routing policies is discussed and they show that link loads are comparable for both medium earth orbit and low earth orbit constellations. All considerations are based on real global flight data of all commercial flights during 1 day.

1

Introduction

Mobile communication equipments, such as cell phones or laptops, are nowadays an integral part of many people’s professional and private lives. People are used to communication anywhere and at anytime, both at home and on the move. Even on-board aircraft, so far one of the last remaining communication solitudes, several initiatives have been taken to offer wireless in-cabin services to passengers [air passenger communication (APC)]. In the past, Connexion by Boeing offered a system platform for providing Internet connectivity within the aircraft cabin. Although the Connexion by Boeing service was stopped by the end of 2006, in the meanwhile some airlines started offering GSM connections to their passengers, and plans are ongoing for offering on-board Internet access again. The area-wide introduction of these services will naturally result in a high demand in communication capacity. In addition to these non-operational services, also the operational part of air traffic management (ATM) communication (mainly dedicated to safety and regularity of flight) faces an increase in capacity demand because of the introduction of new services with high data volume demand. The final factor contributing to the increased capacity demand is the expected growth in number of aircraft, as studies undertaken by EUROCONTROL [1] have shown. Already nowadays, the existing ATM 1594 & The Institution of Engineering and Technology 2010

communication infrastructure operates close to the maximum capacity [2]. For this reason, the development and introduction of link technologies, which complement the existing communication infrastructure, deserves high attention and at the moment a lot of development programs (e.g. ESA Artes 10 Iris Programme, SESAR Joint Undertaking) and research projects [3, 4] study possible future solutions. Geostationary earth orbit (GEO) satellites with their wide coverage areas are one option, but the inherent enormous free space loss requires huge antennas in the space segment or directed terminal antennas. The use of directed antennas is not desirable for several reasons. Most important of all, bulky directed antennas require relatively big radomes to be installed in the aircraft. Furthermore, mechanically steerable antennas face the additional problem of vibrations throughout the flight, while at the time of writing electronically steerable antennas are costly and have limited gain (although several research activities are ongoing and mass production may lower the cost in the future). Finally, the directivity of high gain antennas can be a problem if the satellite is blocked by the aircraft hull for certain flight vectors (unless antenna diversity is used). For these reasons, the use of omnidirectional low gain antennas is more attractive. Besides the mentioned issues, a GEO solution also does not cover high latitudes and the polar regions properly, which are very often traversed on long-haul flights [5]. Considering all IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org this, low earth orbit (LEO) or medium earth orbit (MEO) satellite constellation networks with inter-satellite links (ISLs) appear as promising candidate solutions deserving more detailed investigation. The free space loss is significantly reduced, which means that omni-directional antennas can be used more easily, and inclined orbits with properly dimensioned footprint diameters can also cover regions near the poles. This paper focuses on the analysis and required dimensioning of a LEO and MEO ISL network for air traffic control (ATC) and APC usage. The paper is structured in the following way. Section 2 provides background information on LEO and MEO constellations and the data traffic pattern as occurring in ATC. Section 3 then presents two routing policies that are evaluated in the simulative part of this paper. In Section 4, a detailed multiservice traffic model is introduced, and is used for the simulative assessment of the routing algorithms later on. In Section 5, the results of the estimation of the required link capacity with the given scenario and the routing algorithms are presented. Finally, Section 6 concludes this paper.

2

Figure 1 Snapshot of the M-Star ISL topology

Background

Throughout this paper, two different Walker Delta [6] satellite constellation networks with ISL will be considered, one LEO and one MEO constellation. Both of them were proposed, but so far not yet realised; nevertheless they are interesting candidate solutions, offering both a regular distribution of network nodes over the approximately spherical Earth and a regular permanent mesh of intraorbit (links between satellites in the same plane) and inter-orbit (links between satellites in neighbouring planes) ISL. Polar star constellations with their inherent counterrotating seam (e.g. Iridium [7]) require more complex routing algorithms, since ISLs have to be switched on and off (especially in the polar regions) leading to additional complexity which is not wanted for our system dimensioning.

2.1 LEO constellation The Motorola M-Star constellation [8] consists of 72 satellites uniformly distributed over 12 inclined planes with six satellites per plane. The orbit altitude is 1350 km, the period 112 min 41 s and the orbit inclination 478. The coverage of M-Star reaches medium latitudes (668), but does not include the poles (whereas polar constellations like Iridium cover the poles very well). This means M-Star does not outperform a fleet of GEO satellites in terms of coverage, but has a notably smaller free space loss, which is beneficial for using omni-directional antennas. Each satellite has four ISL: two intra-orbit ISL, and two interorbit ISL (see Fig. 1). The minimum elevation angle was set to 208. For comparison, the elevation angle at 668 latitude for a GEO satellite is 15.68. IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

Figure 2 Snapshot of the fictitious Galileo ISL topology

2.2 MEO constellation The assumed MEO satellite constellation is based on the future European Galileo satellite navigation system. In other words, we assume that the Galileo satellites not only provide a navigation service, but also have a communication payload enabling global (aeronautical) communication [9]. This constellation comprises 30 satellites in a Walker constellation with three inclined planes (568) and 10 satellites per plane. Each plane has nine operational satellites plus one inactive in case of failures; the spare satellite is not considered in our simulations. The period is 14 h 4 min 41 s, for an orbit altitude of 23 222 km. Again each satellite has four ISL: two intra-orbit ISL and two interorbit ISL which are not shadowed by the Earth. Fig. 2 shows a snapshot of the resulting topology. The minimum elevation angle was set to 58 in order to obtain a worst case scenario in terms of footprint size and traffic load on single satellites.

2.3 Aeronautical communication ATC is one component of the operational ATM communication and refers to communication between air traffic controllers on-ground and the aircraft pilots. It is related to the regularity and safety of flight and for this reason must comply with requirements as listed in the communications operating concept and requirements for the future radio system (COCR) document [10]. Nowadays, most of the ATC communication consists of 1595

& The Institution of Engineering and Technology 2010

www.ietdl.org voice calls, with only a few exchanges of data. APC, on the other hand, is one component of the non-operational ATM communication. Since the overall scenario and the resulting simulation environment are rather complex, several assumptions and simplifications had to be made. In our model, three types of traffic exist: ATC voice, APC voice and APC data traffic. As the worst case assumption ATC traffic is considered to be a permanently available voice channel between pilot and controller(s); the bandwidth requirements of ATC data communication are considered minor compared to ATC voice (which might change in the future). APC voice and data traffic are dynamically created by the passengers. The bulky nature of voice traffic allows using the reserved bandwidth also for data services during silence periods. Thus, data packets from and to the aircraft are either voice over IP (for ATC and APC) or IP packets (APC data). We assume a length of 1500 bytes for every IP packet, and 100 bytes for a VoIP packet. The VoIP codec rate for both ATC and APC was chosen to be 9.6 kb/s. Since the focus of this work is on data rates and not on call establishment or voice latencies, the ATC voice performance requirements of the COCR have not been considered. It should be noted that in the following the link from an aircraft or gateway to the satellite is called uplink, and in opposite direction downlink (see Fig. 8).

3

Routing algorithms

A major drawback of ISL networks is their topology being permanently in motion. There are two main effects that trigger re-routing of an existing path from an origin to its destination (and vice versa). First, the satellites and their footprints move relatively to the ground and second, the aircraft move along their routes, which are modelled by great circles between departure and arrival airports. The great circle modelling does not match exactly with the flight routes as they would occur in reality. But the precision of the great circle modelling is sufficient for the analysis of the ISL routing, since the satellite footprints are comparatively large and small deviations from the real flight route have no or only very minor consequences for the results. In the envisaged satellite communication architecture, routing takes place in three different segments. The first segment is the up and down link (UDL) segment, where routing is in charge of choosing the first (ingress) and last (egress) satellite. This is particularly important when the satellite footprints overlap and more than one satellite is visible for a ground station. The second segment is denoted as the ISL segment, where routing chooses the path between the ingress and egress satellites within the space segment. Finally, terrestrial routing is performed to provide 1596 & The Institution of Engineering and Technology 2010

paths between the satellite gateway stations and the end systems in the terrestrial ground network. In this work, the focus is on the UDL and ISL routing, omitting the terrestrial routing segment. It has to be noticed that the ISL routing cannot be entirely decoupled from the UDL routing, since a decision in one routing segment may result in a different routing decision in the other segment. UDL and ISL routing thus affect each other. Earlier works have exhaustively covered various aspects of routing in ISL networks (see e.g. [11, 12]), but for this study we consider only two simple but different routing policies. The first policy optimises path decisions in the UDL and ISL segment independently, whereas the second policy considers the UDL and ISL segment jointly. These two algorithms (independent against integrated) were chosen by intention as simple routing solutions so that there is a lot of room for improvement using more elaborated approaches. Both policies have been evaluated regarding their impact on the UDL and ISL link load for the M-Star LEO constellation and the Galileo MEO constellation, respectively.

3.1 UDL routing – handover minimisation (Policy 1) An aircraft or terminal in general may be within the coverage area of several satellites at a time. Even systems designed for single coverage have an overlap of footprints since connections between a terminal and a satellite must be handed over to another satellite when the currently serving satellite falls below the minimum allowable elevation angle. During the handover, a number of signalling messages have to be exchanged between terminal and old/new serving satellite and a new path in the ISL segment has to be established, too. A handover always means a change in the end-to-end delay, and so a very short but existing service interruption can occur with an inherent quality of service (QoS) degradation. Thus, the goal of the routing policy is to minimise the number of handovers. Consequently, Policy 1 always chooses serving satellites offering the maximum remaining visibility time, and whenever a handover occurs, the path in the ISL segment between ingress and egress satellite is re-calculated using the well-known Dijkstra shortest path algorithm.

3.2 UDL and ISL routing – minimising number of hops (Policy 2) Although there are good reasons to minimise handovers and to avoid re-routing events, the algorithm for Policy 1 appears to be simplistic and offers room for further improvements. Satellites illuminate wide areas, so that both the origin and destination terminal may be located within the same footprint, that is, in this case there is only one network node between them. Routing Policy 2 reflects this by preferring serving satellites that cover both origin and IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org destination(s) in their footprint, minimising the number of involved network nodes (hops). If this is not possible, then Policy 1 is applied. As explained before, this approach can only have an effect on routing decisions if the terminals can choose between more than one serving satellite, that is, the satellite network provides more than a single coverage.

4

Traffic model and scenario

The basic prerequisite for capacity dimensioning of a communication system is an appropriate traffic model. The modelling of the expected user behaviour is however challenging in this application scenario, since not much detailed data are available and since it bears the risk to rely on too simple assumptions and to exceed the manageable simulation complexity. Consequently, our model is based on a few existing surveys and relies on a major share on apparent observations.

4.1 Multiservice traffic model Our generic multiservice traffic model is based on a number of different parameters that are grouped into four categories: † Temporal variations considering daytime, flight duration and service usage variation over time.

† Type of aircraft in terms of the number of seats and seating classes (first, business and economy class). † Service usage for APC, that is, how passengers use the three basic services (web browsing, e-mail, voice) under consideration of their seating class. † Geographically varying traffic between different regions (e.g. dependent on population and server density). A mathematical expression based on [13] and taking into account all these factors is shown in Fig. 3. With this expression, we estimate the required bandwidth per aircraft for aeronautical communication. The cumulative busy hour traffic A(i, t) in region (i.e. aircraft) i at time t is given by the sum over all S services (voice, web browsing, e-mail) and all U seating classes (first class, business class, economy class). Nu (i, t) are the number of users belonging to the seating class u. The service profile parameters dsu have been derived from market estimations and surveys [14, 15]. dsu represents the probability that a user in seating class u uses communication service s. Based on this, our assumptions for in-flight service usage are as follows:

Figure 3 Multiservice traffic formula and parameters (based on [13]) IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

1597


www.ietdl.org † Economy class: 50% voice, 15% Internet, 5% e-mail. † Business and first class: 100% voice, 60% Internet, 50% e-mail. Each percentage refers to all passengers of the respective seating classes. Further parameters in Fig. 3, as introduced in [13], are as follows: † mBH,s,u ‘busy hour factor’ ¼ busy hour traffic/average hourly traffic (≥1), † mMS,s,u ‘multiservice factor’, or service correlation coefficient (usually ,1), † mSA,s,u ‘scaling and adaptation factor’, used to consider specific terminal features (e.g. traffic shaping or hardware constraints),

service usage weight factor has two meanings: first, it indicates the probability of using a certain service with respect to the actual phase of the flight; second, it indicates (non-)availability of services because of legal restrictions. This applies from the moment that the aircraft leaves the gate until it reaches the cruising altitude (taxi and take-off) and from leaving the cruising altitude until arriving at the gate (approach and landing). The second reason why services may not be available to the passengers is the situation where a flight is too short. Consider as an example, a flight with an in-flight duration (i.e. the time on cruising altitude) of less than 10 min; it is unlikely that data services are used a lot in this short time since passengers may not consider it worth to start working. The take-off and landing phases are assumed to last on average around 15 min each (for flight durations longer than 30 min), and the following differentiation with respect to the flight time was made:

† ,30 min: no APC service at all; † mGT,u ‘group terminal factor’ for the adjustment of predefined cumulative terminal bit rates. Parameters mBH,s,u , mSA,s,u and mGT,u are not too important for our purpose and will be set to 1.

† .30 min and ,40 min: only telephone; † .40 min and ,60 min: telephone and data; † .60 min: telephone and data usage as shown in Fig. 3.

In subsequent sections, we explain the remaining parameters that were introduced for an appropriate model of the envisaged aeronautical communication system. 1. Multiservice (correlation) factor: The multiservice factor mMS,s,u attempts to model the cross-relation among multiple services and their impact on the total traffic volume. One can expect that services of similar type may be correlated in a way that they either increase or limit the use of other services. For example, considering a case with three services (voice, web browsing, e-mail), we can assume that for a passenger who prefers telephone calls over using e-mail, the usage of the e-mail service is limited by the voice application and vice versa. Since no reliable data on these interrelationship correlations have been derived yet, we had to derive plausible assumptions that are shown in table ‘Multiservice Correlation Factors’ in Fig. 3. Example: According to our assumptions above, all business class passengers are interested in voice, 60% in Internet and 50% in e-mail. With the weighting shown in Fig. 3, effectively only 60% of the business class passengers use voice, 60% Internet and 20% e-mail. 2. Service usage weight factor: The three APC services (web browsing, e-mail and voice) are split into two categories. The real-time traffic of telephone service represents the first category and the non-real-time data services e-mail and web-browsing form the second category. The two graphs in the lower right of Fig. 3 show an example of the service usage weight factor mSU,s (t) for a flight duration of 2 h (including taxi, take-off, approach and landing). The 1598 & The Institution of Engineering and Technology 2010

With this classification and the service usage curve mSU,s (t), short flights produce less data traffic than long flights and passengers of long-haul flights use their cell phones more frequently at the beginning and at the end of their journey. 3. Daily user profile: Larger scale temporal fluctuations of traffic load are caused by the local time of the day and the duration of a flight. This part of the model takes into account that the user activity is correlated with the personal daytime. For instance, the statistical activity of users during the day will be higher than in the middle of the night. The daily user profile accounts for the fact that the sense of time drives the user activity, and not the actual time (local timezone) of the day. In [16], statistics on the percentage of total daily activity have been derived with respect to the actual daytime. These activity statistics have been applied in the presented model as shown in Fig. 3. 4. Traffic basic parameters: Traffic caused by the three services VoIP, e-mail and web browsing is characterised by the following parameters:

l∗s application frequency ¼ (long-term) average arrival rate, 1/ms mean connection holding time, Rs max. bit rate (possibly different for up- and downlink), bs burstiness ¼ ratio between average and max. bit rate. IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org Depending on the load scenario handled by the system, we define three different traffic scenarios: heavy, medium and light. The numerical studies in this paper were, however, all obtained under the worst case traffic scenario ‘heavy’. The table entitled ‘Traffic Basic Parameters’ in Fig. 3 summarises the traffic assumptions for all different services. Given a typical data rate of 64 kb/s and 200 kB for an average e-mail (including attachments, i.e. worst case assumption), the mean holding time is 25 s. The burstiness bs is equal to 1 for constant bit rate (CBR) services and less than 1 for varying bit rate (VBR) services. Note that forward link (to the aircraft) and return link (from the aircraft) may have different data rates. The ratio of transmitted data service volume in the forward and return link has been approximated to a value of 10:1. For the web traffic, the variables x (l∗ ) and y (1/ms ) can be adjusted to adapt the traffic load to a desired or expected value; for our studies, we suggest x equal to 20 h21 and y equal to 210 s.

4.2 Aircraft model Real flight traffic data were used as the basis for all simulations. The aircraft movement model comprises all worldwide flights for 1 day (21 May 2007) which have been extracted from a commercial flight database [17]. In this scenario, only scheduled passenger flights were considered without helicopters, cargo, military and general aviation. Altogether, 73 477 passenger flights were extracted, including departure and arrival airports and times. Since accurate data about flight corridors were not available, the flight routes have been modelled by great circles (shortest routes on a sphere) and assuming constant speed. The average speed of an aircraft was computed from the departure and arrival times and the distance as calculated from the great circle between departure and destination airport. With this great circle model, M-Star cannot provide sufficient coverage in polar regions. However, our investigations have shown that at maximum 40 out of roughly 8000 active flights are affected by this. For the simulation these flights were considered out of coverage and do not contribute to the traffic load.

In our model, each flight has three phases, take-off, cruise (en-route) and landing. The altitude in the different phases was simulated using a trapezoidal model. Although the exact ascending/descending rate depends on the type of aircraft, we assumed in our model that the average ascending/descending rate is 3000 ft/min (15.24 m/s), which is in the order of size of, e.g. Airbus A330-A319 (3500 ft/min) and Boeing 738, 733 and 737 (3000 – 4000 ft/min). Taking into account these ascending/ descending rates, it gets clear that short flights do not necessarily reach the high altitudes of long distance flights. Table 1 shows the numerical values for flight duration and maximum cruising altitude as they are used in the performed simulations.

4.3 Departure– destination airport model Although ATM data communication in general contain airto-ground as well as ground-to-ground communication, the focus in our study is on the air-to-ground scenario. This means that for each communication, one end-point is always located on-board the aircraft (airborne end system). The location of the end system is hereby determined by the actual latitude and longitude of the aircrafts’ position. The other communication end-point is always a satellite ground station, since a pure satellite communication network is envisaged here. It is now important to determine at which geographical location the ground station is located. The distribution of the communication end systems on ground has a decisive impact on the distribution of the load within the ISL network. Here, the authors have investigated two different models for the location of the destinations. As a first approach, it is assumed that a satellite terminal is installed at each airport, that is, each airport is end-point and gateway to the terrestrial network. Moreover, it is supposed that the majority of the passenger communication is for the region of the departure and destination airport. Thus, we assumed that 40% of the APC traffic is for communication with the region of departure/arrival airport each, and other 20% is communication with locations that are randomly distributed all around the world (a uniform geographic distribution is assumed therefore). Regarding the operational ATC traffic, it is assumed that this traffic is routed to the departure airport as long as the airplane has travelled less than half of its journey, and is routed to the destination airport for the second half of the journey. In the remainder of the paper, this model is referred to as departure– destination airport (DDA) model.

Table 1 Flight altitude classification Flight category short distance medium distance long distance

Time duration

Max. cruising altitude

short ,240 min (1– 4 h)

23 500 ft (≃7 km)

medium ,360 min (4– 6 h)

24 500 ft (≃8 km)

long .360 min (+6 h)

25 500 ft (≃10 km)

IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

1599


www.ietdl.org 4.4 Continental gateway model The DDA model as presented in Section 4.3 makes some strong assumptions and simplifications, for example, regarding the equipage of all airports with satellite terminals and the decentralised location of air traffic controllers (which are in reality usually collocated in ATC centres). A more realistic scenario is to assume that the satellite access is concentrated at several central gateways and that en-route and oceanic-remote-polar air traffic control is taken care of by ATC centres, whereas only the local ATC is managed by airports themselves (airport and terminal maneuvering area). As proposed in [16], we therefore define six geographical regions as more realistic approach: North and South America, Europe, Africa, Asia and Oceania (see Fig. 4). For each region, two gateways were placed, which share the traffic load and which may serve as redundant systems in case of failures. These gateways may be located at arbitrary places, but were placed in the vicinity of major cities (measured by population density) with sufficient distance to each other in our model. The following cities were chosen: † North America: New York and Los Angeles. † South America: Bogota and Rio de Janeiro. † Europe: London and Moscow. † Africa: Johannesburg and Yaounde. † Asia: New Delhi and Tokyo. † Oceania: Singapore and Sydney.

the aircraft enters the respective continental region. We decided to follow this approach, since the bandwidth occupied by ATC traffic is comparably negligible and can be concentrated to a very few gateway stations, since the feeder links can be assumed to be sufficiently large dimensioned. For APC voice, we stick to the DDA model introduced in Section 4.3, since a passenger on-board an airplane is most likely to contact someone in the region of the arrival or the departure airport. So, for the voice traffic, 40% will be directed to the region of the departure airport, 40% to the region of the destination airport and the remaining 20% will be distributed all around the world. 2. APC data traffic: In reality, the web data traffic depends on the location of the servers. In order to make the DDA model introduced in Section 4.3 more realistic, the web browsing traffic is now going to be distributed over the six regions, proportional to the number of internet hosts located in each continent. Based on [18], the percentage of internet hosts per continent can be roughly estimated (see Table 2). It is assumed here that the total data traffic is equally distributed among all servers, that is, for instance 35% of the generated web browsing traffic within an airplane will be requested in Europe since 35% of the Internet hosts are located there. For each continental region, the two gateways will each handle half of the traffic, that is, if one satellite can serve both gateways it will have to cope with the total traffic for this continent, while it only has to cope with half of the continental traffic if only one gateway is within the reach.

In the remainder of this paper, this model is denoted as the continental gateway (CGW) model.

The assumptions for the destination distribution of e-mail traffic are done in a similar way. Also here the proportional share of e-mail servers on each continent are used as baseline. According to [19], mail servers are distributed as listed in Table 2. As before, also here it is assumed that all servers contribute equally to the total traffic. The percentage of servers on a continent is hence also proportional to the distribution of the data traffic.

1. ATC and APC voice: For ATC voice traffic, the primary gateways will be in charge of aircraft ATC traffic as soon as

5

The dark and light circles in Fig. 4 indicate the location of each gateway. Light colours are used for primary gateways (in Fig. 4, e.g. London; see subsequent section), dark colours (in Fig. 4, e.g. Moscow) denote secondary gateways.

Load estimation

The following sections summarise the results of the investigations on ISL routing for a LEO and MEO constellation, namely M-Star and Galileo. It is shown here how the different routing policies as well as the different destination models influence the ISL link loads of both constellations.

5.1 DDA model Figure 4 Continental distribution of gateways and regions 1600 & The Institution of Engineering and Technology 2010

Focusing on the DDA model, Fig. 5 shows the results for both policies and constellations when applying the multiservice traffic model explained before. IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org Table 2 Percentage of internet hosts and mail servers per continental region, based on [18] and [19] North America

South America

Europe

Africa

Asia

Oceania

internet hosts

50%

1%

35%

0.2%

10%

3.8%

mail servers

52%

3.2%

32%

0.8%

10%

2%

Figure 5 Comparison between M-Star and Galileo for both routing policies (DDA model) a ISL routing Policy 1 b ISL routing Policy 2 c UL routing Policy 1 d UL routing Policy 2 e DL routing Policy 1 f DL routing Policy 2


1601


www.ietdl.org

Figure 6 Comparison between the DDA model and the CGW model for both routing policies a ISL routing Policy 1 c UL routing Policy 1 e DL routing Policy 1

b ISL routing Policy 2 d UL routing Policy 2 f DL routing Policy 2

The graphs show for each time step t the maximum occurring link load that has been computed by calculating for each time step t the load of each link [ISL, uplink (UL) and downlink (DL)] in the constellation according to the expression introduced in Fig. 3. From all link load values 1602 & The Institution of Engineering and Technology 2010

the one with the highest data rate was selected, which means that the graph does not show the traffic load on a specific link. The reader will notice that there is still traffic after 24 h, which is caused by airplanes departing in the evening and landing the following day (May 22nd 2007). IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org For Policy 1, there are small differences in the link load between the M-Star and the Galileo constellation (Figs. 5a, c and e). For all three types of links the worst case traffic load of the Galileo constellation exceeds the load of the M-Star constellation by several Mbit/s. Although the shapes are similar, the results for the Galileo constellation show more peaks, and they are less scattered, too. This is caused by the Galileo MEO constellation with its comparably slower relative movement and larger footprints causing less hand-overs. Using the other routing algorithm, Policy 2 (Figs. 5b, d and f ), the results for the UL and DL are very similar to Policy 1. However, differences occur for the ISL segment. For M-Star, the ISL traffic load reaches 70 Mb/s, which is roughly half of the load of Policy 1 with 165 Mb/s. For Galileo, the maximum link load does not exceed values of around 10 Mb/s, which is substantially less than using Policy 1. One reason for the comparatively small ISL link loads in the M-Star constellation is the fact that Policy 2 tries to minimise the number of hops at the ISL segment. Even if the satellite chosen by Policy 2 is only visible for a few minutes, it will be selected. Consequently, there will be more handovers at the UDL segment but less traffic on the ISL segment, since all traffic is spread more widely in the space segment. The coverage area of a Galileo satellite is larger than of a LEO satellite what makes it very likely that source and destination (e.g. aircraft over the US and server in Europe) can be covered by a single satellite footprint without having to route the traffic via the ISL segment. Policy 2 makes use of this advantage which leads to the very small ISL link load observed in Fig. 5b.

between the traffic load of the DDA model and the traffic load with the CGW model. These high values for the ISL can be explained partially by the fact that the traffic is more concentrated on certain gateways in the CGW model, but investigations have shown that this is not the only reason. In the CGW model, 85% of the web browsing traffic (which represents the biggest part of the total traffic) goes to North America and Europe (50 and 35%, respectively). This means that if there is, for example, a flight from Europe to North America, half of the generated web traffic within this aircraft will go to North America. To reach the gateways of Los Angeles or New York, the traffic has to pass through more than one satellite and the ISL links are used more heavily. To check this explanation, the ISL links at rush hour (15:00 h UTC) have been simulated and recorded for both models and the results are shown in Fig. 7a for the CGW model and in Fig. 7b for the DDA model. For the DDA model, it can be seen that the traffic is distributed more uniformly around the world resulting in a more uniform usage of the ISL links. The maximum load for these ISLs is, however, not too high and in the range of max. 9.3 Mb/s, compared to 244.9 Mb/s for the CGW model. As explained before, the size of a MEO footprint is comparatively large and so the ISL links are less loaded.

5.2 Continental gateway model The results presented in the previous section were based on the DDA model, meaning that 40% of the generated traffic go to the departure airport, another 40% of the data traffic go to the destination airport and 20% are equally distributed around the world. Focusing on the Galileo constellation, Fig. 6 illustrates the change in data rate if the DDA model is replaced by the CGW model as introduced in Section 4.4. For Policy 1, it can be seen that the traffic rates are quite similar. The traffic peaks are just 5 – 10 Mb/s higher for the CGW model. Solely for the ISL segment, the peak rates at the rush hour between 14:00 and 16:00 h universal time coordinated (UTC) are bigger (in the order of 50 Mb/s). The higher peaks for the CGW model could be expected since the traffic concentrates on a few gateways now, whereas it was spread across thousands of airports all around the world before. The differences for the second policy are more significant, especially for the ISL segment. There is almost a factor 25 IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

Figure 7 Comparison of the Galileo ISL link load at rush hour for both models using Policy 2 a ISL topology with the CGW model during rush hour b ISL topology with the DDA model during rush hour

1603


www.ietdl.org

Figure 8 Distribution of the traffic load with the CGW model

For the CGW model, mainly the ISL links between satellites covering Europe and North America are used, which are also heavily loaded for this reason. The traffic concentrates as expected in the regions where the gateways are located, so the satellites covering these continents receive the aggregated traffic from all the aircraft in the area. It should be noted that looking at Fig. 7a, one can obtain the misleading impression that the other ISL links would not be significantly used. In reality, the links are used but the traffic load is very low compared with the links between the satellites covering Europe and North America and so they appear very bright in the representation in Fig. 7. Still focusing on Policy 2, the question arises as to why the UL rate of the CGW model is so much higher than that of the DDA model (Fig. 6d). To answer this question, a more detailed analysis has been done. For the DDA model, at 15:00 h UTC, satellite number 4 carries the highest traffic load on the UL (107.4 Mb/s) and covers 1270 flights at this time. Regarding the CGW model, satellite number 10 has the highest traffic load (240.5 Mb/s), and covers 1320 flights, only 50 flights more than satellite 4 with the previous model. Although the additional 50 flights contribute to the higher rate, they do not explain an increase of 100 Mb/s difference in rate in the two UL. At this time, one of the involved satellites is located over Brazil (number 4) and the other one (number 10) between North America and Europe, as shown in Fig. 7a. This means that using the CGW model satellite 10 receives web browsing requests of the different aircraft located all over the world. This satellite transmits these requests to the gateways in North America. The gateways then send all the WWW data to satellite 10 on the UL of the forward link. As explained before, a ratio of 1:10 exists between the transmitted volumes in the return and the forward link for 1604 & The Institution of Engineering and Technology 2010

web browsing service. Thanks to this ratio and the fact that the traffic is concentrated on a few gateways in the CGW model, it is logical to see higher values of the UL rates than in the DDA model. Fig. 8 helps one to understand what happens in this CGW model. It also explains why the UL rate is higher than the DL one for the CGW model with Policy 2. With the DDA model, the DL and UL rates almost reach the same values. This is because, the traffic is not concentrated on a few gateways here. Thus, if there was a lot of traffic on the UL of the forward link, there was also the same load of traffic on the DL of the forward link. In the CGW model, this is not the case. The huge amount of traffic on the UL of the forward link is distributed all over the world on several DL. That is why there is a substantial difference between these two link loads.

6

Conclusions

Satellite communication with its large coverage areas is a candidate technology for ATC, and especially nongeostationary satellite constellation networks with their less stringent antenna technology requirements (as explained in the Introduction) could be interesting transport networks. In this paper, an approach to estimate link (and switch) loads was developed and two typical constellation types (LEO and MEO) were investigated and compared for the DDA model. Since there is no system in operation offering similar services, it was not possible to compare our results; furthermore, many simplifications and assumptions had to be made so that the results of this work cannot predict accurate data rates but at least the order of magnitude. Additionally, two different routing policies have been introduced. A first policy that minimises the number of IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

www.ietdl.org handovers (by selecting the satellite with the longest visibility time) and a second policy that minimises the number of hops at the ISL segment. For the generation of the data traffic, a traffic model has been developed. Within this model, a range of effects has been considered like the daytime dependence of user activity, correlation factors among different services, seating classes and aircraft types. Following this, two traffic distribution models have been derived. In the first approach (denoted DDA model), it is assumed that satellite terminals are available at each airport throughout the world. On the other hand, a second traffic distribution model (CGW model) was developed assuming that not each airport is equipped with satellite gateways but that two gateways are deployed per continental region, totalling for 12 gateways worldwide. The dominating factor for the maximum link load turned out to be the geographical concentration of aircraft over North America and Europe. Finally, it has been shown that using a Galileo MEO constellation instead of a M-Star LEO constellation does not lead to a much higher load on the different links when the number of handovers at UDL segment is minimised (Policy 1). This means that a MEO constellation (even with considerably larger coverage areas per footprint) with comparably few satellites can provide the same service as a LEO constellation. When the number of hops at the ISL segment is reduced (Policy 2), the traffic loads in the MEO constellation for the UL and DL are similar to the ones of the LEO constellation. The only significant difference occurs for the ISL, which are more intensively used in the LEO constellation. The main outcome of this study is that for both MEO and LEO systems, the resulting data rates and the fact that switching has to be performed only between four outgoing links (three ISL and one downlink) keep the complexity in a range, which can be handled by current state-of-the-art technology.

7

Acknowledgment

This work was partially conducted in the framework of the NEWSKY Project (NEtWorking the SKY for aeronautical communication [4]), co-funded by the European Commission. The authors are solely responsible for it. The European Commission is not responsible for the use of any data in this paper.

8

[2] EUROCONTROL/FAA: ‘Action plan 17 future communications study – final conclusions and recommendations report’. November 2007, Version 1.0.. Available at: http://www.eurocontrol.int [3] Project CT-2005-516128 ANASTASIA: ‘Airbone new and advanced satellite techniques and technologies in a system integrated approach’. Available at: http://www.anastasiafp6.org [4] Project AERO-2005-37160 NEWSKY: ‘NEtWorking the SKY for aeronautical communications’. Available at: http:// www.newsky-fp6.eu [5] WERNER M., HOLZBOCK M., BATTAGLIA L.: ‘Potential of nonGEO satellite constellations in the future AirCom market’. Proc. 20th AIAA Int. Communications Satellite Systems Conf. (ICSSC’02), Montreal, Canada, May 2002, Paper no. AIAA-2002-2037 [6] WALKER J.G. : ‘Continuous whole-earth coverage by circular-orbit satellite patterns’. Technical report 77044 (UDC 629.195:527), Royal Aircraft Establishment, UK, March 1977 [7] PRATT S.R., RAINES R.A., FOSSA C.E., TEMPLE M.A.: ‘An operational and performance overview of the Iridium low earth orbit satellite system’, IEEE Commun. Surv. Tutorials, 1999, 1, (3), pp. 2 – 10 [8] Motorola Satellite Systems, Inc.: ‘Application for authority to construct, launch and operate the M-Star system’. FCC filing, Washington, DC, USA, September 1996 [9] WERNER M.: ‘Global air traffic management via satellite – a case for Galileo 2?’. Proc. Third Advanced Satellite Mobile Systems Conf. (ASMS), Herrsching am Ammersee, Germany, May 2006 [10] EUROCONTROL/FAA: ‘Communications operating concept and requirements for the future radio system’. Version 2.0. Available at: http://www. eurocontrol.int [11] FRANCK L., MARAL G.: ‘Routing in networks of intersatellite links’, IEEE Trans. Aerosp. Electron. Syst., 2002, 38, (3), pp. 902– 917 [12] MOHORCˇICˇ M., WERNER M., SˇVIGELJ A., KANDUS G.: ‘Alternate link routing for traffic engineering in packet oriented ISL networks’, Int. J. Satell. Commun., 2001, 19, (5), pp. 463– 480

References

[1] EUROCONTROL: ‘Long-term forecast flight movements 2006 – 2025’. Edition Number: v1.0, 2006, Available at: http://www.eurocontrol.int IET Commun., 2010, Vol. 4, Iss. 13, pp. 1594 – 1606 doi: 10.1049/iet-com.2009.0260

[13] WERNER M., LUTZ E.: ‘Bandwidth requirements for multiservice satellite systems’. IEEE Int. Conf. on Communications (ICC), Atlanta, Georgia, USA, June 1998, pp. 94– 99 1605


www.ietdl.org [14] WERNER M., SANCTIS M.D., TRACHTMAN E., FEBVRE P., FRANZRAHE O.: ‘Deliverable D6: satellite market opportunity report’. Technical report, Project IST-2001-37466 WirelessCabin, September 2003

evaluation of global satellite systems’. Proc. 59th IEEE Vehicular Technology Conf. (VTC), Milan, Italy, May 2004

[15] ROGOYSKI A.M., KALAMA M.: ‘Deliverable D5: market survey and recommendations’. Technical report, Project IST-200137466 WirelessCabin, August 2003

[18] The world factbook. Central Intelligence Agency (CIA), 2008. Available at: https://www.cia.gov/library/ publications/the-world-factbook/index.html

[16] MOHORCˇICˇ M., Sˇ VIGELJ A., KANDUS G., ET AL .: ‘Developing aggregate traffic intensity model for performance

[19] Mail server statistics. MailRadar. Available: http:// www.mailradar.com/mailstat/

1606 & The Institution of Engineering and Technology 2010

[17] Innovata: Available at: http://www.innovatallc.com/
