# Measuring QoS in an Aeronautical Opportunistic Network Architecture with Limited Access to a Satellite Communications Backhaul

Authors: Rubén Martínez-Vidal; Ramon Martí; Cormac J. Sreenan; Joan Borrell
Journal: Mobile Information Systems
 (2016)

---

## Abstract

We measure quality of service (QoS) in a wireless network architecture of transoceanic aircraft. A distinguishing characteristic of the network scheme we analyze is that it mixes the concept of Delay Tolerant Networking (DTN) through the exploitation of opportunistic contacts, together with direct satellite access in a limited number of the nodes. We provide a graph sparsification technique for deriving a network model that satisfies the key properties of a real aeronautical opportunistic network while enabling scalable simulation. This reduced model allows us to analyze the impact regarding QoS of introducing Internet-like traffic in the form of outgoing data from passengers. Promoting QoS in DTNs is usually really challenging due to their long delays and scarce resources. The availability of satellite communication links offers a chance to provide an improved degree of service regarding a pure opportunistic approach, and therefore it needs to be properly measured and quantified. Our analysis focuses on several QoS indicators such as delivery time, delivery ratio, and bandwidth allocation fairness. Obtained results show significant improvements in all metric indicators regarding QoS, not usually achievable on the field of DTNs.


---

## Body

## 1. Introduction

Data communication in aeronautical scenarios is very restricted. These interactions are usually limited to periodic broadcasts of air-traffic management related information (such as identification and position), or airline data reports (few tens of bytes per second). In the case of passenger data, the most common approach is to use satellite links that are usually quite expensive. As an alternative, novel research papers on aeronautic communications propose the use of wireless communication systems with large coverage (from 300 to 600 km) to create a fully connected aeronautical ad hoc network (AANET) [1–3].In [4], we proposed to create a disconnected ad hoc mobile network using short-range radio technologies (50 km) and Delay Tolerant Network (DTN) standards [5]. This proposal represented a cheaper alternative than those based on radio links with high coverage or satellite links. DTNs are challenged networks, usually mobile, which forward their data using a store-and-forward multihop paradigm. Their main feature is the lack of permanent end-to-end connectivity between their nodes, along with the apparition of long delays and usual disruptions.Afterward, we studied the feasibility of using this network as a reliable way to deliver in-flight generated data to ground stations [6], always through the nodes at the edge of the network. This study showed that the disconnected nature of the network only allowed a small percentage of the nodes of the network (7%) to perform efficient air-to-ground communications (regarding delivery time). Finally, in [7] we solved this problem by deploying a mixed network architecture combining the opportunistic multihop communications used in DTNs, with the direct delivery capabilities of satellite links. We obtained a hierarchical network architecture with two differentiated node types (those with and without satellite link availability).The immediate use of the architecture presented at [7] revolves around applications that do not require an explicit response, for instance, the following:(i)
Regarding Passenger Data. Examples of such applications are the delivery of mail or twitter messages(ii)
Regarding Airline Data. One example of such an application is early notification of faulty components prior to landing for compliance with MEL (Minimum Equipment Lists). These lists are safety regulations files that define which items (instrument, equipment, or systems) are required so the aircraft can be allowed to depart after an intermediate stop. These lists can include noncritical components such as cabin lighting items, and a departure may suffer delays due to the time required for finding a spare and replacing such element. For this reason, early notification of any faulty equipment during the flight can allow a faster response after landingThe primary objective of this paper is to evaluate how the architecture presented in [7] behaves when noninteractive Internet-like application traffic is deployed into the network. We offer measures of several QoS related aspects such as the delivery time, delivery ratio, and the degree of fairness on bandwidth allocation. Afterward, we evaluate if the architecture provides relevant improvements with respect to QoS. We conclude our work by listing the service levels that can be provided. The contributions of this paper are listed below:(i)
We provide a simulation network scenario through a graph sparsification technique that is simulation time efficient and preserves key properties of a realistic transoceanic aircraft network.(ii)
We provide an evaluation of the aforementioned aeronautical scenario using the following QoS indicators: delivery time, delivery ratio, and bandwidth allocation fairness index.(iii)
We show that our proposed network architecture [7] reduces delivery times, increases delivery ratio, and improves bandwidth allocation fairness when compared to a pure opportunistic network architecture.(iv)
We list the service levels that can be achieved. This listing includes delivery times which are usually not guaranteed in common DTN scenarios.The rest of the paper is organized as follows. Section2 presents the background and previous work on QoS in DTNs. In Section 3 we describe our network model including network configuration, traffic model, routing protocol, and deployment scenario. This section also includes a short description of the scenario used in our previous papers [4, 6, 7] which acts as the basis for the one used in this paper. In Section 4 we present the several QoS metrics, the experimental methodology, and the obtained results. In Section 5 we discuss the implications of our results for QoS and offer a set of service guarantees. Finally, in Section 6 we present the overall conclusions of the paper and our intended future work.


## 2. Related Work

The topic of quality of service (QoS) in DTNs is often considered an open issue. The unpredictable nature of such networks, characterized by long delays, common interruptions, and limited resources, makes it very challenging to provide any certain degree of service. The most common research efforts are usually focused either on improving the routing protocols (usually through efficient buffer management policies) or on defining traffic priority classes or on implementing congestion control mechanisms.On the first line of work, we can find [8], where the authors offer a comparative review of existing buffer management policies in several well-known routing protocols. This comparison is performed using delivery probability and message overhead. Finally, the authors propose an optimal algorithm for buffer management.Other related work following this line can be found in [9, 10]. The authors propose a Fair Resource Management Model as a method to enhance the QoS. This model is intended to act as a complementary mechanism for routing protocols. It uses admission control policies to accept or reject traffic demands according to the currently available resources. They compare the performance of a DTN using their model against others lacking it. The delivery probability and a resource allocation fairness index are used as performance metrics. Their results showed significant improvements in performance up to 40% in the delivery probability and up to 30% in the fairness index.The DTN architecture itself provides an example of the second line of work [11]. Specifically, in the Bundle Protocol [12] we can find several QoS management tools: firstly, packet header priority classes with three well-defined priority levels; secondly, packet delivery options: they are a set of signals indicating several events that may help manage QoS related processes, such as congestion control or routing.In [13] we can see an example of congestion control mechanisms. The authors propose a rule based congestion control mechanism using a financial model of buffer space management. The main contribution of this model is the fact of being a local mechanism that only relies on local information to make autonomous decisions. Therefore, this tool does not add communication overhead and provides tolerance to failures due to loss of connectivity.Finally, a work that mixes several of the previous concepts can be seen in [14, 15]. The authors propose a dynamic system that uses custom routing strategies for each packet. This system has two contributions: first, an analytical method for estimation of delivery probability: this method relies on parameters such as the QoS requirements of the packet, the buffer capacity of the nodes, and their mobility patterns; second, a custom priority based local buffer management policy.In contrast to the previous works, in this paper the improvements to QoS are provided by the proposed network architecture and not by a particular set of enhancements on resource management policies. Nevertheless, these lines of work have been considered as possible improvements in our future work.


## 3. Network Model

In this section, we recall a realistic aeronautical network scenario presented in [4, 6]. Afterward, we provide an algorithm for the generation of smaller scenarios from the previous scenario while preserving its main properties. We also describe the network configuration, the routing protocols, and the traffic model used in our experimental evaluation.


### 3.1. Network Scenario

This scenario represents an aeronautical ad hoc network in which nodes have limited communication range and rely on sporadic encounters to communicate in an opportunistic manner. The area of deployment is the North Atlantic ocean (the ocean with the highest concentration of flights). We define a geographically bounded oceanic area inside of which the planes are disconnected (see Figure1) that is referred to asdisconnected zone. We also refer to the time interval in which each aircraft remains in this disconnected area as the aircraft’sdisconnected flight duration. Our study focuses on the intervals when the aircraft are operating inside of this disconnected area; we refer to these nodes asactive nodes. Otherwise, we assume that they are capable of delivering their data using the existing network infrastructure, and thus their opportunistic capabilities are inactive.Figure 1
Bounds of the disconnected zone over the north Atlantic oceanic area.We define two differentiated network models:(i)
Full model: realistic representation of the network composed of several thousand nodes.(ii)
Reduced model: small-scale version with equivalent structural network properties.The full model is unpractical for the study of applications generating a high traffic volume as simulation time grows exponentially. The statistically equivalent (in regard to connectivity) reduced model offers an alternative that allows a proper analysis under increased network loads. This reduced model is obtained using a technique based on graph sparsification [16].


#### 3.1.1. Full Model

We recall our aeronautical scenario from our previous works [4, 6]. This scenario is composed of 2,878 nodes representing aircraft moving at high speed and following mobility patterns based on transoceanic flight trajectories. The model includes all the flights departing on the same concrete day (Thursday, 03/14/2013) for all time zones involved. All departure times are switched to UTC format to provide a standardized time for the whole network. Simulation starting time is synchronized with the instant 0:00 AM, UTC zone.The resulting network is sparsely connected and displays the usual characteristics seen in DTN scenarios (long end-to-end delays and common disruptions). In this scenario, the communications are performed in an opportunistic way and rely on the sporadic contacts between nodes. The use of the opportunistic communication paradigm for this network was studied in [6]. The results obtained showed limited performance regarding delivery time and ratios. As a result, the network was expanded to use a hierarchical architecture with two differentiated node categories [7]. In this new approach, opportunistic communications are combined with the usage of satellite links (state of the art aircraft air-to-ground communication system). A balanced, cost-effective solution is achieved that minimizes the requirement of expensive satellite links with the use of almost cost-negligible opportunistic communications. In this new network architecture we find two differentiated node types:(i)
Basic nodes are nodes exclusively capable of using short-range radio communications and, therefore, rely on opportunistic encounters to forward their data.(ii)
Satellite forwarder nodes are nodes that can use short-range communications, but they are also capable of using satellite communications to deliver any incoming data to the ground.The introduction of this new sort of node provides an alternate way for data delivery. Data can now be delivered during flight time and not necessarily at aircraft landing. This additional option reduces communication delays significantly.In [7] we offered a network structure analysis. This study used a contact graph to represent the opportunistic contacts between nodes. Several node centrality metrics were applied to the graph to obtain detailed insight on the most relevant nodes of the network. Satellite nodes were deployed according to this criteria to maximize network performance. Obtained results showed that using betweenness centrality as the deployment metric, and equipping satellite links on 35% of the most relevant nodes, reduces delivery time by one-third of the aircraft average flight time.This delivery time reduction guarantees that the messages are delivered in approximately 1.5 to 3 hours prior to the landing of the aircraft. For the considered MEL application this interval is enough to ensure a fast response by the airport maintenance crew upon landing. On the case of passenger data (mail, twitter), any delivery prior to landing would be acceptable. This early delivery guarantees that a response to their initial message may be available upon landing.As of November 2015, about 9.2% to 14.7% of US general aviation aircraft [17] has been fitted with ADS-B (automatic dependent surveillance broadcast) equipment, a location tracking system based on satellite communications. The observed increasing trend in satellite communication link deployment will guarantee the connectivity levels required for our proposal (35%) in a relatively short time span (a few years).Although this full scenario is useful for topology and network characterization, it is not practical for the study of applications generating a high traffic volume as simulation time grows exponentially. Therefore in the next section, we propose a method for the generation of statistically equivalent (in regard to connectivity) reduced versions of the scenario more suited for this kind of studies.


#### 3.1.2. Reduced Model

This network model consists of a smaller selection of nodes picked from the whole set that encompasses the full model. We define a selection algorithm that focuses on providing a network that maintains the same proportion between satellite links and standard nodes. The algorithm takes the original set of nodes as input together with the desired size of the new scenario. The output is a new scenario of the requested size maintaining the key properties of the original scenario. This algorithm is based on outward node exploration starting on central nodes. It preserves the proportion between satellite and basic nodes and maintains key contact characteristics such as the contact and intercontact times (with a deviation of ≤5% with respect to the original). These contact metrics represent the most relevant properties that define the capabilities of opportunistic network scenarios. This algorithm works as follows:(i)
Use the size of the reduced scenario (n) and a graph representing all nodes of the complete model (G) as input. Initialize a void set N of maximum length n to be the output.(ii)
Compute the number of required satellite communication links for the new scenario ass=0.35×n.(iii)
Chooses nonrepeated satellite nodes uniformly at random from the input scenario (G) and define a list S containing them.(iv)
Iterate throughS applying procedure BreadthFirstSearch (see Algorithm 1). As a result, we obtain a list of neighbors ordered in BFS exploration order for each chosen satellite node.(v)
Iterate within the first element of each list. Check whether it is a satellite node or not. If it is negative add it toN; otherwise move to the next list. Once all the lists have been visited, move on to the second element of each list, then to the third, and so on.(vi)
Repeat untilN has been filled.Algorithm 1:Simplified functions used during the scenario generation procedure.
function  BFS(node,G,depth)                     ⊳ BreadthFirstSearch ⊳ Explore G in BFS order starting from node up to depth. Return list (L) of nodes in exploration order. return  L end function function  GenerateScenario(S,N,G,n,s) NgListss←                     ⊳ Container of s Neighbor Lists i←0                            ⊳ Index for Neighbor Lists depth←0 NumNgbs←0                       ⊳ Total number of Neighbors N←N+S do depth←depth+1 for all  S  atNode in S  do NgLists[i]←BFS(SatNode,G,depth) NumNgbs←NumNgbs + SizeOf(NgLists[i]) end for whileNumNgbs<(n-s) do pos←pos+1 for  i  =  0  ;  i  <  s  ;  i++  do Node←NgLists[i][pos] if  NotIsSat(Node) AND NotIn(N,Node)  then N←N+Node end if end for while  SizeOf(N)<n return  N end functionThe resulting scenario is a network that starts with a set of satellite nodes and grows outwards including neighboring nodes of increasing depth until reaching the specified maximum size. To provide a more manageable model we reduce our network to~10% of its original size (using n=200 in Algorithm 1). This generates a scenario with 200 nodes, 130 of which are basic nodes and 70 satellite nodes.


### 3.2. Network Configuration

We have used the ns-3 simulator [18] to represent the different features of the network. Aircraft are represented as simulation nodes, the data link layer of those nodes has been set to IEEE 802.11b, and MAC sublayer is set to ad hoc mode. The wireless radio range is modeled using a constant propagation loss model dependent on the distance between transmitter and receiver. Link bandwidth is set to 1 Mbps using Direct-Sequence Spread Spectrum (DSSS) modulation.


### 3.3. Traffic Model

In this model, common aircraft are equipped with traffic generators and are also capable of data forwarding. Conversely, we assume that satellite nodes deliver their data instantaneously as the delays of satellite communications are negligible in comparison to those of the DTN network. Therefore, satellite nodes are equipped with data sinks and do not generate data as our main focus is to measure QoS for opportunistically forwarded data. Each aircraft is only supposed to generate traffic during the disconnected flight duration. Outgoing traffic represents all the user and company traffic generated inside of the aircraft. To represent this traffic we use the defined standard IEEE 802.16 traffic models [19].


#### 3.3.1. IEEE 802.16-4IPP Traffic Model

We use the traffic generator known as IEEE 802.16-4IPP. This model generates network traffic that simulates aggregated HTTP/TCP and FTP traffic commonly found on the Internet. Concretely, this model describes the network traffic observed between a router and a LAN with multiple computers. It contemplates two states: the ON state where generated traffic is destined for the router, and the OFF state where generated traffic is exchanged between the internal nodes of the LAN. Simulated traffic is directional; to simulate both outgoing and incoming traffic two instances of the model are required. In our case, we are only interested in analyzing outgoing traffic. Therefore, we only set up a single instance of the traffic model.This traffic model is constructed using a superposition of four Interrupted Poisson Processes (IPP). An IPP is a process with two states (ON/OFF). During the ON state, a flow of packets is generated at a constant bit rate (CBR). Alternatively, during the OFF state, there is no packet generation. Transitions between both states happen with probabilitiesc1 (ON to OFF) and c2 (OFF to ON). The resulting network traffic is perceived as periodic bursts of packets spaced by intervals of inactivity. This model has been proved to simulate Internet traffic accurately [19] and closely resembles aggregated traffic measurements. The values corresponding to these parameters can be seen in Table 1. The parameters for each IPP are represented in rows 1–4, and row 5 shows the aggregation of all four processes, offering the average generation ratio of the traffic model.Table 1
Default 802.16 4IPP model, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 4.571 e - 01 3.429 e - 01 1.1480 IPP#2 1.445 e - 02 1.084 e - 02 0.7278 IPP#3 4.571 e - 04 3.429 e - 04 0.5949 IPP#4 4.571 e - 06 3.429 e - 06 0.5289 4IPP N/A N/A 3The premise of the 4IPP traffic model is similar to that found in our scenario. We assume that each aircraft represents an independent LAN with a router acting as the exit point. Passengers using our applications behave similarly to those found in a common LAN network. The main difference is that only outgoing traffic is encountered in the network. Therefore, on our setup, just one instance of the 4IPP traffic model is used (instead of the two required to model two-way communications).The traffic model needs to be properly dimensioned to provide data rates fitting our aeronautical scenario. In order to perform this task, we need to estimate the message size of our application model and the traffic output of each individual aircraft.For the estimation of the packet size we use the Twitter application as our reference (we assume that MEL and text-only mail have similar size requirements). For this size estimation, we perform traffic measurements using a web browser to post status updates (tweets) through the web form provided by the Twitter desktop website (version of December 15, 2015). Table2 displays the several obtained results; we perform status updates with multiple sizes, from 1 to 140 characters, using simple characters and characters requiring multibyte encoding and lastly tweets with geolocation. We consider both the HTTP POST request header and the content length which contains the data of the tweet. From these observations, we assume a minimum tweet size of 2,020 bytes (1 single character tweet) and a maximum of 2,895 bytes (140 characters with multibyte encoding plus 34 bytes for geolocation). As a result, for our traffic model we use an average packet size of 2,458 bytes.Table 2
Twitter status update HTTP request size. Measured from Twitter Website Form using User-Agent: Mozilla/5.0 (Ubuntu Linux 14.04) Firefox/42.0.
Status text length Request header POST data size App. data size 1–140 1,080-1,081 bytes 940–1,080 bytes 2,020–2,161 bytes 1–140 (multibyte chars) 1,080-1,081 bytes 946–1,780 bytes 2,026–2,861 bytes 1–140 (geolocated) 1,097-1,098 bytes 957–1,096 bytes 2,054–2,194 bytesNowadays, it is feasible to assume that most of the aircraft bandwidth usage is the aggregated traffic of passenger’s mobile devices. To estimate the traffic generated by each passenger, we use the yearly set of statistics provided by Cisco Visual Networking [20] which contains measurements and predictions on mobile device data traffic. In Table 3(a), we show the average traffic per device observed during the year 2014 and the predictions for the year 2019. In our model, we consider a higher bound estimate of 12 GB/month, as the exact device types carried by passengers cannot be exactly known, but it is obvious that the traffic consumption of 4G devices will be more representative in the future. Afterward, we focus on the types of application traffic generated by mobile devices. We use the statistics provided by Ericson’s 2014 Mobility Report [21]. In Table 3(b), we show the distribution of mobile data traffic per application type. Our Twitter application would fall into the category of social networking traffic (15%), from which approximately one-third would correspond to Twitter (according to US social media statistics [22]). In the case of the mailing application, we can assume that most users use HTTP clients to access their e-mail, this action would correspond to web browsing traffic (5%). Therefore, we will consider only a 5% (600 MB/month) of the total generated traffic.Table 3
Mobile device usage statistics.
(a)
Average traffic per device: Global Mobile Data Traffic Forecast Update 2014–2019 [20]
Device type 2014 2019 Smartphone 819 MB/month 3,981 MB/month 4G smartphone 2,000 MB/month 5,458 MB/month Tablet 2,076 MB/month 10,767 MB/month 4G tablet 2,913 MB/month 12,314 MB/month  (b)
Application traffic classification: Ericsson Mobility Report 2015 [21]
Share on total mobile traffic 2015 2021 Video 50% 70% Social networking 20% 15% Web browsing 10% 5% Audio ~2% ~2%Additionally, we are not interested in all generated traffic but only in outgoing traffic. On this regard, we use an early estimation of aircraft communication Internet service usage provided by [23]. This work provides data traffic usage statistics of the six most operated aircraft models for North Atlantic passenger flights. We use the values corresponding to the Airbus 380, the aircraft model which has the highest number of passengers (550). Mean data traffic displayed by those flights is 73 kbps for incoming data and 8 kbps for outgoing data (approximately 9 : 1 ratio). These data rates are fairly outdated as they correspond to the year 2004, but the proportion of outgoing and incoming traffic should be fairly similar (with a probable increase of incoming traffic). Therefore, we assume a 10 : 1 ratio for our traffic model. As a result the aggregated amount of outgoing traffic for each aircraft becomes 101.852 kbps and we scale our outgoing 4IPP model using a factor of 1.7265 (101,852 bps/19,664 bits (2,458 bytes) = 5.1796 packets/sec, 5.1796 packets/sec/3 packets/sec = 1.72653) as shown in Table 4.Table 4
4IPP model scaled to 102 kbps, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 7.892 e - 01 5.920 e - 01 1.9821 IPP#2 2.495 e - 02 1.872 e - 02 1.2566 IPP#3 7.892 e - 04 5.920 e - 04 1.0271 IPP#4 7.892 e - 06 5.920 e - 06 0.9132 4IPP N/A N/A 5.1796


### 3.4. Routing Protocols

This network is sparsely connected and has a small number of encounters. Our priority is to take advantage of every contact opportunity. For this purpose, we use a flooding based scheme known asepidemic routing [24, 25]. This kind of routing protocol maximizes delivery ratio and minimizes delivery time by exploring all the possible routing paths. It is worth noting that there are many other routing protocols for aeronautical networks, but epidemic routing is enough for our intended QoS analysis.In this kind of schemes, nodes maintain a fixed length buffer that stores packets for long time periods. Periodic beaconing is used to detect communication opportunities. Upon detection, nodes exchange a summary of the packets stored in their respective buffers. Afterwards, they proceed to exchange a copy of all nonowned packets. Unfortunately, epidemic protocols have no control over data forwarding and generate high volumes of network traffic that can lead to a reduced delivery ratio due to network congestion.The configuration of the routing protocol parameters has a big impact on network performance. Our principal concern is to ensure a proper delivery ratio since this is a critical metric to ensure the quality of service. Four main parameters influence the behavior of this type of routing protocol:buffer capacity for packet storage,expiration time for entries in the buffer, maximumNumber of Hops per packet, andBeaconing Interval. To maximize the performance of the protocol we assign optimal values according to scenario characteristics observed in our previous works.TheBeacon Interval needs to be as higher as possible to reduce network load but always smaller than the Inter Any Contact Time (IACT) to prevent failure of neighbor detection. The IACT is the time interval between encounters of any two nodes on the scenario. Ideally, this value must be a fraction of the IACT. We set it to 400 seconds which corresponds to roughly half of the minimum observed IACT [7]. This value ensures that no contact opportunity is missed and reduces network load by removing unnecessary beaconing traffic.We need to set up a proper packetexpiration time to guarantee that packets are stored long enough to have a chance to be delivered. We set its base value to 14400 seconds. This value corresponds to the average disconnected flight duration of all the nodes of the scenario [6]. In the following section, we analyze the impact of this parameter on varying values. In the same way, to guarantee that the data can travel long enough to reach the destination we set the maximumNumber of Hops to 40. This value corresponds the highest packet replication value observed using an idealistic model without buffer limitations [6].Finally, we assign thebuffer capacity. This value depends on the traffic model and network load used. To assign an appropriate value, we need to consider several aspects. Mainly, we need to guarantee that the buffers can hold the amount of data being generated by a node plus the additional data generated by encountered nodes. Those nodes, in turn, may even be holding data from others.First, we consider the data generated by the local node. To this end, we need to evaluate the data generation ratio (GR) and the duration of the flight (DF). Secondly, we account for the data from other encountered aircraft. In each communication opportunity, the aircraft forwards some packets from its buffer but in exchange stores data from other aircraft. We need to relate the number of contact opportunities that happen during the flight and the amount of data generated between encounters (intercontact packets, ICP). For this purpose, we relate the data generation rate (GR), the time interval between data exchanges (given by the IACT), and the average number of contact opportunities (CO).Lastly, we need to account for aircraft carrying data from sources other than their own. We know some facts from our previous study [6]. First, the average node degree is approximately one unit. Second, the values of packet replication (see Figure 2) show that only 20% of samples are replicated more than twice. We include this information into our calculation by defining the packet replication percentage (PRc). For simplification purposes, we only consider the percentage of packets that are replicated twice or less (80%) and the rest (20%), from which we assume a replication of 3. Please note that any desired degree of precision may be achieved with the values from the Complementary Cumulative Distribution Function (CCDF) shown on Figure 2.Figure 2
CCDF of the packet replication, total number of existing copies of each generated packet at the end of the simulation.We represent the previously described parameters, their average values, and their relationship in Table5. Finally, we relate all of those parameters and define the buffer size in expression:(1)Buffer  Size=DFD·GR+∑c=2nc·PRc·ICP·CO.Table 5
Relationship between relevant parameters used to compute the optimal buffer size.
Number of copies per packet c N/A Inter Any Contact Time IACT 2,200 seconds Disconnected flight duration DFD 14,400 seconds Generation ratio GR 5.1796 pkts/second Inter contact packets ICP = GR× IACT 11,395 packets Contact opportunities CO = DFD/IACT 7 Packet replication percentage (based on Figure2) P R c 80% <c=2 20% <c=3Expression (1) is evaluated up to three replications (n=3). As a result, we obtain a buffer size of ~250,000 packets. Afterward, we compute the storage requirements for the nodes using the packet size (2,458 bytes), which results in approximately 615 MB. In a scenario such as this one, where nodes are aircraft and the limitations on computer equipment are mostly negligible, we consider that this value is fairly affordable.We provide a summary of the relevant configuration parameters defined through the section along with their default values in Table6.Table 6
Default configuration parameters.
Simulation model Full Reduced Number of nodes 2,878 200 Beacon interval 400 s 400 s Traffic model 1 CBR flow 4IPP Radio range 50 km 50 km Buffer size 100 packets 250,000 pkts Expiration time 14,400 s 14,400 s Max. number of hops 40 hops 40 hops


## 3.1. Network Scenario

This scenario represents an aeronautical ad hoc network in which nodes have limited communication range and rely on sporadic encounters to communicate in an opportunistic manner. The area of deployment is the North Atlantic ocean (the ocean with the highest concentration of flights). We define a geographically bounded oceanic area inside of which the planes are disconnected (see Figure1) that is referred to asdisconnected zone. We also refer to the time interval in which each aircraft remains in this disconnected area as the aircraft’sdisconnected flight duration. Our study focuses on the intervals when the aircraft are operating inside of this disconnected area; we refer to these nodes asactive nodes. Otherwise, we assume that they are capable of delivering their data using the existing network infrastructure, and thus their opportunistic capabilities are inactive.Figure 1
Bounds of the disconnected zone over the north Atlantic oceanic area.We define two differentiated network models:(i)
Full model: realistic representation of the network composed of several thousand nodes.(ii)
Reduced model: small-scale version with equivalent structural network properties.The full model is unpractical for the study of applications generating a high traffic volume as simulation time grows exponentially. The statistically equivalent (in regard to connectivity) reduced model offers an alternative that allows a proper analysis under increased network loads. This reduced model is obtained using a technique based on graph sparsification [16].


### 3.1.1. Full Model

We recall our aeronautical scenario from our previous works [4, 6]. This scenario is composed of 2,878 nodes representing aircraft moving at high speed and following mobility patterns based on transoceanic flight trajectories. The model includes all the flights departing on the same concrete day (Thursday, 03/14/2013) for all time zones involved. All departure times are switched to UTC format to provide a standardized time for the whole network. Simulation starting time is synchronized with the instant 0:00 AM, UTC zone.The resulting network is sparsely connected and displays the usual characteristics seen in DTN scenarios (long end-to-end delays and common disruptions). In this scenario, the communications are performed in an opportunistic way and rely on the sporadic contacts between nodes. The use of the opportunistic communication paradigm for this network was studied in [6]. The results obtained showed limited performance regarding delivery time and ratios. As a result, the network was expanded to use a hierarchical architecture with two differentiated node categories [7]. In this new approach, opportunistic communications are combined with the usage of satellite links (state of the art aircraft air-to-ground communication system). A balanced, cost-effective solution is achieved that minimizes the requirement of expensive satellite links with the use of almost cost-negligible opportunistic communications. In this new network architecture we find two differentiated node types:(i)
Basic nodes are nodes exclusively capable of using short-range radio communications and, therefore, rely on opportunistic encounters to forward their data.(ii)
Satellite forwarder nodes are nodes that can use short-range communications, but they are also capable of using satellite communications to deliver any incoming data to the ground.The introduction of this new sort of node provides an alternate way for data delivery. Data can now be delivered during flight time and not necessarily at aircraft landing. This additional option reduces communication delays significantly.In [7] we offered a network structure analysis. This study used a contact graph to represent the opportunistic contacts between nodes. Several node centrality metrics were applied to the graph to obtain detailed insight on the most relevant nodes of the network. Satellite nodes were deployed according to this criteria to maximize network performance. Obtained results showed that using betweenness centrality as the deployment metric, and equipping satellite links on 35% of the most relevant nodes, reduces delivery time by one-third of the aircraft average flight time.This delivery time reduction guarantees that the messages are delivered in approximately 1.5 to 3 hours prior to the landing of the aircraft. For the considered MEL application this interval is enough to ensure a fast response by the airport maintenance crew upon landing. On the case of passenger data (mail, twitter), any delivery prior to landing would be acceptable. This early delivery guarantees that a response to their initial message may be available upon landing.As of November 2015, about 9.2% to 14.7% of US general aviation aircraft [17] has been fitted with ADS-B (automatic dependent surveillance broadcast) equipment, a location tracking system based on satellite communications. The observed increasing trend in satellite communication link deployment will guarantee the connectivity levels required for our proposal (35%) in a relatively short time span (a few years).Although this full scenario is useful for topology and network characterization, it is not practical for the study of applications generating a high traffic volume as simulation time grows exponentially. Therefore in the next section, we propose a method for the generation of statistically equivalent (in regard to connectivity) reduced versions of the scenario more suited for this kind of studies.


### 3.1.2. Reduced Model

This network model consists of a smaller selection of nodes picked from the whole set that encompasses the full model. We define a selection algorithm that focuses on providing a network that maintains the same proportion between satellite links and standard nodes. The algorithm takes the original set of nodes as input together with the desired size of the new scenario. The output is a new scenario of the requested size maintaining the key properties of the original scenario. This algorithm is based on outward node exploration starting on central nodes. It preserves the proportion between satellite and basic nodes and maintains key contact characteristics such as the contact and intercontact times (with a deviation of ≤5% with respect to the original). These contact metrics represent the most relevant properties that define the capabilities of opportunistic network scenarios. This algorithm works as follows:(i)
Use the size of the reduced scenario (n) and a graph representing all nodes of the complete model (G) as input. Initialize a void set N of maximum length n to be the output.(ii)
Compute the number of required satellite communication links for the new scenario ass=0.35×n.(iii)
Chooses nonrepeated satellite nodes uniformly at random from the input scenario (G) and define a list S containing them.(iv)
Iterate throughS applying procedure BreadthFirstSearch (see Algorithm 1). As a result, we obtain a list of neighbors ordered in BFS exploration order for each chosen satellite node.(v)
Iterate within the first element of each list. Check whether it is a satellite node or not. If it is negative add it toN; otherwise move to the next list. Once all the lists have been visited, move on to the second element of each list, then to the third, and so on.(vi)
Repeat untilN has been filled.Algorithm 1:Simplified functions used during the scenario generation procedure.
function  BFS(node,G,depth)                     ⊳ BreadthFirstSearch ⊳ Explore G in BFS order starting from node up to depth. Return list (L) of nodes in exploration order. return  L end function function  GenerateScenario(S,N,G,n,s) NgListss←                     ⊳ Container of s Neighbor Lists i←0                            ⊳ Index for Neighbor Lists depth←0 NumNgbs←0                       ⊳ Total number of Neighbors N←N+S do depth←depth+1 for all  S  atNode in S  do NgLists[i]←BFS(SatNode,G,depth) NumNgbs←NumNgbs + SizeOf(NgLists[i]) end for whileNumNgbs<(n-s) do pos←pos+1 for  i  =  0  ;  i  <  s  ;  i++  do Node←NgLists[i][pos] if  NotIsSat(Node) AND NotIn(N,Node)  then N←N+Node end if end for while  SizeOf(N)<n return  N end functionThe resulting scenario is a network that starts with a set of satellite nodes and grows outwards including neighboring nodes of increasing depth until reaching the specified maximum size. To provide a more manageable model we reduce our network to~10% of its original size (using n=200 in Algorithm 1). This generates a scenario with 200 nodes, 130 of which are basic nodes and 70 satellite nodes.


## 3.1.1. Full Model

We recall our aeronautical scenario from our previous works [4, 6]. This scenario is composed of 2,878 nodes representing aircraft moving at high speed and following mobility patterns based on transoceanic flight trajectories. The model includes all the flights departing on the same concrete day (Thursday, 03/14/2013) for all time zones involved. All departure times are switched to UTC format to provide a standardized time for the whole network. Simulation starting time is synchronized with the instant 0:00 AM, UTC zone.The resulting network is sparsely connected and displays the usual characteristics seen in DTN scenarios (long end-to-end delays and common disruptions). In this scenario, the communications are performed in an opportunistic way and rely on the sporadic contacts between nodes. The use of the opportunistic communication paradigm for this network was studied in [6]. The results obtained showed limited performance regarding delivery time and ratios. As a result, the network was expanded to use a hierarchical architecture with two differentiated node categories [7]. In this new approach, opportunistic communications are combined with the usage of satellite links (state of the art aircraft air-to-ground communication system). A balanced, cost-effective solution is achieved that minimizes the requirement of expensive satellite links with the use of almost cost-negligible opportunistic communications. In this new network architecture we find two differentiated node types:(i)
Basic nodes are nodes exclusively capable of using short-range radio communications and, therefore, rely on opportunistic encounters to forward their data.(ii)
Satellite forwarder nodes are nodes that can use short-range communications, but they are also capable of using satellite communications to deliver any incoming data to the ground.The introduction of this new sort of node provides an alternate way for data delivery. Data can now be delivered during flight time and not necessarily at aircraft landing. This additional option reduces communication delays significantly.In [7] we offered a network structure analysis. This study used a contact graph to represent the opportunistic contacts between nodes. Several node centrality metrics were applied to the graph to obtain detailed insight on the most relevant nodes of the network. Satellite nodes were deployed according to this criteria to maximize network performance. Obtained results showed that using betweenness centrality as the deployment metric, and equipping satellite links on 35% of the most relevant nodes, reduces delivery time by one-third of the aircraft average flight time.This delivery time reduction guarantees that the messages are delivered in approximately 1.5 to 3 hours prior to the landing of the aircraft. For the considered MEL application this interval is enough to ensure a fast response by the airport maintenance crew upon landing. On the case of passenger data (mail, twitter), any delivery prior to landing would be acceptable. This early delivery guarantees that a response to their initial message may be available upon landing.As of November 2015, about 9.2% to 14.7% of US general aviation aircraft [17] has been fitted with ADS-B (automatic dependent surveillance broadcast) equipment, a location tracking system based on satellite communications. The observed increasing trend in satellite communication link deployment will guarantee the connectivity levels required for our proposal (35%) in a relatively short time span (a few years).Although this full scenario is useful for topology and network characterization, it is not practical for the study of applications generating a high traffic volume as simulation time grows exponentially. Therefore in the next section, we propose a method for the generation of statistically equivalent (in regard to connectivity) reduced versions of the scenario more suited for this kind of studies.


## 3.1.2. Reduced Model

This network model consists of a smaller selection of nodes picked from the whole set that encompasses the full model. We define a selection algorithm that focuses on providing a network that maintains the same proportion between satellite links and standard nodes. The algorithm takes the original set of nodes as input together with the desired size of the new scenario. The output is a new scenario of the requested size maintaining the key properties of the original scenario. This algorithm is based on outward node exploration starting on central nodes. It preserves the proportion between satellite and basic nodes and maintains key contact characteristics such as the contact and intercontact times (with a deviation of ≤5% with respect to the original). These contact metrics represent the most relevant properties that define the capabilities of opportunistic network scenarios. This algorithm works as follows:(i)
Use the size of the reduced scenario (n) and a graph representing all nodes of the complete model (G) as input. Initialize a void set N of maximum length n to be the output.(ii)
Compute the number of required satellite communication links for the new scenario ass=0.35×n.(iii)
Chooses nonrepeated satellite nodes uniformly at random from the input scenario (G) and define a list S containing them.(iv)
Iterate throughS applying procedure BreadthFirstSearch (see Algorithm 1). As a result, we obtain a list of neighbors ordered in BFS exploration order for each chosen satellite node.(v)
Iterate within the first element of each list. Check whether it is a satellite node or not. If it is negative add it toN; otherwise move to the next list. Once all the lists have been visited, move on to the second element of each list, then to the third, and so on.(vi)
Repeat untilN has been filled.Algorithm 1:Simplified functions used during the scenario generation procedure.
function  BFS(node,G,depth)                     ⊳ BreadthFirstSearch ⊳ Explore G in BFS order starting from node up to depth. Return list (L) of nodes in exploration order. return  L end function function  GenerateScenario(S,N,G,n,s) NgListss←                     ⊳ Container of s Neighbor Lists i←0                            ⊳ Index for Neighbor Lists depth←0 NumNgbs←0                       ⊳ Total number of Neighbors N←N+S do depth←depth+1 for all  S  atNode in S  do NgLists[i]←BFS(SatNode,G,depth) NumNgbs←NumNgbs + SizeOf(NgLists[i]) end for whileNumNgbs<(n-s) do pos←pos+1 for  i  =  0  ;  i  <  s  ;  i++  do Node←NgLists[i][pos] if  NotIsSat(Node) AND NotIn(N,Node)  then N←N+Node end if end for while  SizeOf(N)<n return  N end functionThe resulting scenario is a network that starts with a set of satellite nodes and grows outwards including neighboring nodes of increasing depth until reaching the specified maximum size. To provide a more manageable model we reduce our network to~10% of its original size (using n=200 in Algorithm 1). This generates a scenario with 200 nodes, 130 of which are basic nodes and 70 satellite nodes.


## 3.2. Network Configuration

We have used the ns-3 simulator [18] to represent the different features of the network. Aircraft are represented as simulation nodes, the data link layer of those nodes has been set to IEEE 802.11b, and MAC sublayer is set to ad hoc mode. The wireless radio range is modeled using a constant propagation loss model dependent on the distance between transmitter and receiver. Link bandwidth is set to 1 Mbps using Direct-Sequence Spread Spectrum (DSSS) modulation.


## 3.3. Traffic Model

In this model, common aircraft are equipped with traffic generators and are also capable of data forwarding. Conversely, we assume that satellite nodes deliver their data instantaneously as the delays of satellite communications are negligible in comparison to those of the DTN network. Therefore, satellite nodes are equipped with data sinks and do not generate data as our main focus is to measure QoS for opportunistically forwarded data. Each aircraft is only supposed to generate traffic during the disconnected flight duration. Outgoing traffic represents all the user and company traffic generated inside of the aircraft. To represent this traffic we use the defined standard IEEE 802.16 traffic models [19].


### 3.3.1. IEEE 802.16-4IPP Traffic Model

We use the traffic generator known as IEEE 802.16-4IPP. This model generates network traffic that simulates aggregated HTTP/TCP and FTP traffic commonly found on the Internet. Concretely, this model describes the network traffic observed between a router and a LAN with multiple computers. It contemplates two states: the ON state where generated traffic is destined for the router, and the OFF state where generated traffic is exchanged between the internal nodes of the LAN. Simulated traffic is directional; to simulate both outgoing and incoming traffic two instances of the model are required. In our case, we are only interested in analyzing outgoing traffic. Therefore, we only set up a single instance of the traffic model.This traffic model is constructed using a superposition of four Interrupted Poisson Processes (IPP). An IPP is a process with two states (ON/OFF). During the ON state, a flow of packets is generated at a constant bit rate (CBR). Alternatively, during the OFF state, there is no packet generation. Transitions between both states happen with probabilitiesc1 (ON to OFF) and c2 (OFF to ON). The resulting network traffic is perceived as periodic bursts of packets spaced by intervals of inactivity. This model has been proved to simulate Internet traffic accurately [19] and closely resembles aggregated traffic measurements. The values corresponding to these parameters can be seen in Table 1. The parameters for each IPP are represented in rows 1–4, and row 5 shows the aggregation of all four processes, offering the average generation ratio of the traffic model.Table 1
Default 802.16 4IPP model, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 4.571 e - 01 3.429 e - 01 1.1480 IPP#2 1.445 e - 02 1.084 e - 02 0.7278 IPP#3 4.571 e - 04 3.429 e - 04 0.5949 IPP#4 4.571 e - 06 3.429 e - 06 0.5289 4IPP N/A N/A 3The premise of the 4IPP traffic model is similar to that found in our scenario. We assume that each aircraft represents an independent LAN with a router acting as the exit point. Passengers using our applications behave similarly to those found in a common LAN network. The main difference is that only outgoing traffic is encountered in the network. Therefore, on our setup, just one instance of the 4IPP traffic model is used (instead of the two required to model two-way communications).The traffic model needs to be properly dimensioned to provide data rates fitting our aeronautical scenario. In order to perform this task, we need to estimate the message size of our application model and the traffic output of each individual aircraft.For the estimation of the packet size we use the Twitter application as our reference (we assume that MEL and text-only mail have similar size requirements). For this size estimation, we perform traffic measurements using a web browser to post status updates (tweets) through the web form provided by the Twitter desktop website (version of December 15, 2015). Table2 displays the several obtained results; we perform status updates with multiple sizes, from 1 to 140 characters, using simple characters and characters requiring multibyte encoding and lastly tweets with geolocation. We consider both the HTTP POST request header and the content length which contains the data of the tweet. From these observations, we assume a minimum tweet size of 2,020 bytes (1 single character tweet) and a maximum of 2,895 bytes (140 characters with multibyte encoding plus 34 bytes for geolocation). As a result, for our traffic model we use an average packet size of 2,458 bytes.Table 2
Twitter status update HTTP request size. Measured from Twitter Website Form using User-Agent: Mozilla/5.0 (Ubuntu Linux 14.04) Firefox/42.0.
Status text length Request header POST data size App. data size 1–140 1,080-1,081 bytes 940–1,080 bytes 2,020–2,161 bytes 1–140 (multibyte chars) 1,080-1,081 bytes 946–1,780 bytes 2,026–2,861 bytes 1–140 (geolocated) 1,097-1,098 bytes 957–1,096 bytes 2,054–2,194 bytesNowadays, it is feasible to assume that most of the aircraft bandwidth usage is the aggregated traffic of passenger’s mobile devices. To estimate the traffic generated by each passenger, we use the yearly set of statistics provided by Cisco Visual Networking [20] which contains measurements and predictions on mobile device data traffic. In Table 3(a), we show the average traffic per device observed during the year 2014 and the predictions for the year 2019. In our model, we consider a higher bound estimate of 12 GB/month, as the exact device types carried by passengers cannot be exactly known, but it is obvious that the traffic consumption of 4G devices will be more representative in the future. Afterward, we focus on the types of application traffic generated by mobile devices. We use the statistics provided by Ericson’s 2014 Mobility Report [21]. In Table 3(b), we show the distribution of mobile data traffic per application type. Our Twitter application would fall into the category of social networking traffic (15%), from which approximately one-third would correspond to Twitter (according to US social media statistics [22]). In the case of the mailing application, we can assume that most users use HTTP clients to access their e-mail, this action would correspond to web browsing traffic (5%). Therefore, we will consider only a 5% (600 MB/month) of the total generated traffic.Table 3
Mobile device usage statistics.
(a)
Average traffic per device: Global Mobile Data Traffic Forecast Update 2014–2019 [20]
Device type 2014 2019 Smartphone 819 MB/month 3,981 MB/month 4G smartphone 2,000 MB/month 5,458 MB/month Tablet 2,076 MB/month 10,767 MB/month 4G tablet 2,913 MB/month 12,314 MB/month  (b)
Application traffic classification: Ericsson Mobility Report 2015 [21]
Share on total mobile traffic 2015 2021 Video 50% 70% Social networking 20% 15% Web browsing 10% 5% Audio ~2% ~2%Additionally, we are not interested in all generated traffic but only in outgoing traffic. On this regard, we use an early estimation of aircraft communication Internet service usage provided by [23]. This work provides data traffic usage statistics of the six most operated aircraft models for North Atlantic passenger flights. We use the values corresponding to the Airbus 380, the aircraft model which has the highest number of passengers (550). Mean data traffic displayed by those flights is 73 kbps for incoming data and 8 kbps for outgoing data (approximately 9 : 1 ratio). These data rates are fairly outdated as they correspond to the year 2004, but the proportion of outgoing and incoming traffic should be fairly similar (with a probable increase of incoming traffic). Therefore, we assume a 10 : 1 ratio for our traffic model. As a result the aggregated amount of outgoing traffic for each aircraft becomes 101.852 kbps and we scale our outgoing 4IPP model using a factor of 1.7265 (101,852 bps/19,664 bits (2,458 bytes) = 5.1796 packets/sec, 5.1796 packets/sec/3 packets/sec = 1.72653) as shown in Table 4.Table 4
4IPP model scaled to 102 kbps, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 7.892 e - 01 5.920 e - 01 1.9821 IPP#2 2.495 e - 02 1.872 e - 02 1.2566 IPP#3 7.892 e - 04 5.920 e - 04 1.0271 IPP#4 7.892 e - 06 5.920 e - 06 0.9132 4IPP N/A N/A 5.1796


## 3.3.1. IEEE 802.16-4IPP Traffic Model

We use the traffic generator known as IEEE 802.16-4IPP. This model generates network traffic that simulates aggregated HTTP/TCP and FTP traffic commonly found on the Internet. Concretely, this model describes the network traffic observed between a router and a LAN with multiple computers. It contemplates two states: the ON state where generated traffic is destined for the router, and the OFF state where generated traffic is exchanged between the internal nodes of the LAN. Simulated traffic is directional; to simulate both outgoing and incoming traffic two instances of the model are required. In our case, we are only interested in analyzing outgoing traffic. Therefore, we only set up a single instance of the traffic model.This traffic model is constructed using a superposition of four Interrupted Poisson Processes (IPP). An IPP is a process with two states (ON/OFF). During the ON state, a flow of packets is generated at a constant bit rate (CBR). Alternatively, during the OFF state, there is no packet generation. Transitions between both states happen with probabilitiesc1 (ON to OFF) and c2 (OFF to ON). The resulting network traffic is perceived as periodic bursts of packets spaced by intervals of inactivity. This model has been proved to simulate Internet traffic accurately [19] and closely resembles aggregated traffic measurements. The values corresponding to these parameters can be seen in Table 1. The parameters for each IPP are represented in rows 1–4, and row 5 shows the aggregation of all four processes, offering the average generation ratio of the traffic model.Table 1
Default 802.16 4IPP model, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 4.571 e - 01 3.429 e - 01 1.1480 IPP#2 1.445 e - 02 1.084 e - 02 0.7278 IPP#3 4.571 e - 04 3.429 e - 04 0.5949 IPP#4 4.571 e - 06 3.429 e - 06 0.5289 4IPP N/A N/A 3The premise of the 4IPP traffic model is similar to that found in our scenario. We assume that each aircraft represents an independent LAN with a router acting as the exit point. Passengers using our applications behave similarly to those found in a common LAN network. The main difference is that only outgoing traffic is encountered in the network. Therefore, on our setup, just one instance of the 4IPP traffic model is used (instead of the two required to model two-way communications).The traffic model needs to be properly dimensioned to provide data rates fitting our aeronautical scenario. In order to perform this task, we need to estimate the message size of our application model and the traffic output of each individual aircraft.For the estimation of the packet size we use the Twitter application as our reference (we assume that MEL and text-only mail have similar size requirements). For this size estimation, we perform traffic measurements using a web browser to post status updates (tweets) through the web form provided by the Twitter desktop website (version of December 15, 2015). Table2 displays the several obtained results; we perform status updates with multiple sizes, from 1 to 140 characters, using simple characters and characters requiring multibyte encoding and lastly tweets with geolocation. We consider both the HTTP POST request header and the content length which contains the data of the tweet. From these observations, we assume a minimum tweet size of 2,020 bytes (1 single character tweet) and a maximum of 2,895 bytes (140 characters with multibyte encoding plus 34 bytes for geolocation). As a result, for our traffic model we use an average packet size of 2,458 bytes.Table 2
Twitter status update HTTP request size. Measured from Twitter Website Form using User-Agent: Mozilla/5.0 (Ubuntu Linux 14.04) Firefox/42.0.
Status text length Request header POST data size App. data size 1–140 1,080-1,081 bytes 940–1,080 bytes 2,020–2,161 bytes 1–140 (multibyte chars) 1,080-1,081 bytes 946–1,780 bytes 2,026–2,861 bytes 1–140 (geolocated) 1,097-1,098 bytes 957–1,096 bytes 2,054–2,194 bytesNowadays, it is feasible to assume that most of the aircraft bandwidth usage is the aggregated traffic of passenger’s mobile devices. To estimate the traffic generated by each passenger, we use the yearly set of statistics provided by Cisco Visual Networking [20] which contains measurements and predictions on mobile device data traffic. In Table 3(a), we show the average traffic per device observed during the year 2014 and the predictions for the year 2019. In our model, we consider a higher bound estimate of 12 GB/month, as the exact device types carried by passengers cannot be exactly known, but it is obvious that the traffic consumption of 4G devices will be more representative in the future. Afterward, we focus on the types of application traffic generated by mobile devices. We use the statistics provided by Ericson’s 2014 Mobility Report [21]. In Table 3(b), we show the distribution of mobile data traffic per application type. Our Twitter application would fall into the category of social networking traffic (15%), from which approximately one-third would correspond to Twitter (according to US social media statistics [22]). In the case of the mailing application, we can assume that most users use HTTP clients to access their e-mail, this action would correspond to web browsing traffic (5%). Therefore, we will consider only a 5% (600 MB/month) of the total generated traffic.Table 3
Mobile device usage statistics.
(a)
Average traffic per device: Global Mobile Data Traffic Forecast Update 2014–2019 [20]
Device type 2014 2019 Smartphone 819 MB/month 3,981 MB/month 4G smartphone 2,000 MB/month 5,458 MB/month Tablet 2,076 MB/month 10,767 MB/month 4G tablet 2,913 MB/month 12,314 MB/month  (b)
Application traffic classification: Ericsson Mobility Report 2015 [21]
Share on total mobile traffic 2015 2021 Video 50% 70% Social networking 20% 15% Web browsing 10% 5% Audio ~2% ~2%Additionally, we are not interested in all generated traffic but only in outgoing traffic. On this regard, we use an early estimation of aircraft communication Internet service usage provided by [23]. This work provides data traffic usage statistics of the six most operated aircraft models for North Atlantic passenger flights. We use the values corresponding to the Airbus 380, the aircraft model which has the highest number of passengers (550). Mean data traffic displayed by those flights is 73 kbps for incoming data and 8 kbps for outgoing data (approximately 9 : 1 ratio). These data rates are fairly outdated as they correspond to the year 2004, but the proportion of outgoing and incoming traffic should be fairly similar (with a probable increase of incoming traffic). Therefore, we assume a 10 : 1 ratio for our traffic model. As a result the aggregated amount of outgoing traffic for each aircraft becomes 101.852 kbps and we scale our outgoing 4IPP model using a factor of 1.7265 (101,852 bps/19,664 bits (2,458 bytes) = 5.1796 packets/sec, 5.1796 packets/sec/3 packets/sec = 1.72653) as shown in Table 4.Table 4
4IPP model scaled to 102 kbps, HTTP/TCP and FTP.
c 1 probability rate(transitions/sec) c 2 probability rate(transitions/sec) (pkts/sec) IPP#1 7.892 e - 01 5.920 e - 01 1.9821 IPP#2 2.495 e - 02 1.872 e - 02 1.2566 IPP#3 7.892 e - 04 5.920 e - 04 1.0271 IPP#4 7.892 e - 06 5.920 e - 06 0.9132 4IPP N/A N/A 5.1796


## 3.4. Routing Protocols

This network is sparsely connected and has a small number of encounters. Our priority is to take advantage of every contact opportunity. For this purpose, we use a flooding based scheme known asepidemic routing [24, 25]. This kind of routing protocol maximizes delivery ratio and minimizes delivery time by exploring all the possible routing paths. It is worth noting that there are many other routing protocols for aeronautical networks, but epidemic routing is enough for our intended QoS analysis.In this kind of schemes, nodes maintain a fixed length buffer that stores packets for long time periods. Periodic beaconing is used to detect communication opportunities. Upon detection, nodes exchange a summary of the packets stored in their respective buffers. Afterwards, they proceed to exchange a copy of all nonowned packets. Unfortunately, epidemic protocols have no control over data forwarding and generate high volumes of network traffic that can lead to a reduced delivery ratio due to network congestion.The configuration of the routing protocol parameters has a big impact on network performance. Our principal concern is to ensure a proper delivery ratio since this is a critical metric to ensure the quality of service. Four main parameters influence the behavior of this type of routing protocol:buffer capacity for packet storage,expiration time for entries in the buffer, maximumNumber of Hops per packet, andBeaconing Interval. To maximize the performance of the protocol we assign optimal values according to scenario characteristics observed in our previous works.TheBeacon Interval needs to be as higher as possible to reduce network load but always smaller than the Inter Any Contact Time (IACT) to prevent failure of neighbor detection. The IACT is the time interval between encounters of any two nodes on the scenario. Ideally, this value must be a fraction of the IACT. We set it to 400 seconds which corresponds to roughly half of the minimum observed IACT [7]. This value ensures that no contact opportunity is missed and reduces network load by removing unnecessary beaconing traffic.We need to set up a proper packetexpiration time to guarantee that packets are stored long enough to have a chance to be delivered. We set its base value to 14400 seconds. This value corresponds to the average disconnected flight duration of all the nodes of the scenario [6]. In the following section, we analyze the impact of this parameter on varying values. In the same way, to guarantee that the data can travel long enough to reach the destination we set the maximumNumber of Hops to 40. This value corresponds the highest packet replication value observed using an idealistic model without buffer limitations [6].Finally, we assign thebuffer capacity. This value depends on the traffic model and network load used. To assign an appropriate value, we need to consider several aspects. Mainly, we need to guarantee that the buffers can hold the amount of data being generated by a node plus the additional data generated by encountered nodes. Those nodes, in turn, may even be holding data from others.First, we consider the data generated by the local node. To this end, we need to evaluate the data generation ratio (GR) and the duration of the flight (DF). Secondly, we account for the data from other encountered aircraft. In each communication opportunity, the aircraft forwards some packets from its buffer but in exchange stores data from other aircraft. We need to relate the number of contact opportunities that happen during the flight and the amount of data generated between encounters (intercontact packets, ICP). For this purpose, we relate the data generation rate (GR), the time interval between data exchanges (given by the IACT), and the average number of contact opportunities (CO).Lastly, we need to account for aircraft carrying data from sources other than their own. We know some facts from our previous study [6]. First, the average node degree is approximately one unit. Second, the values of packet replication (see Figure 2) show that only 20% of samples are replicated more than twice. We include this information into our calculation by defining the packet replication percentage (PRc). For simplification purposes, we only consider the percentage of packets that are replicated twice or less (80%) and the rest (20%), from which we assume a replication of 3. Please note that any desired degree of precision may be achieved with the values from the Complementary Cumulative Distribution Function (CCDF) shown on Figure 2.Figure 2
CCDF of the packet replication, total number of existing copies of each generated packet at the end of the simulation.We represent the previously described parameters, their average values, and their relationship in Table5. Finally, we relate all of those parameters and define the buffer size in expression:(1)Buffer  Size=DFD·GR+∑c=2nc·PRc·ICP·CO.Table 5
Relationship between relevant parameters used to compute the optimal buffer size.
Number of copies per packet c N/A Inter Any Contact Time IACT 2,200 seconds Disconnected flight duration DFD 14,400 seconds Generation ratio GR 5.1796 pkts/second Inter contact packets ICP = GR× IACT 11,395 packets Contact opportunities CO = DFD/IACT 7 Packet replication percentage (based on Figure2) P R c 80% <c=2 20% <c=3Expression (1) is evaluated up to three replications (n=3). As a result, we obtain a buffer size of ~250,000 packets. Afterward, we compute the storage requirements for the nodes using the packet size (2,458 bytes), which results in approximately 615 MB. In a scenario such as this one, where nodes are aircraft and the limitations on computer equipment are mostly negligible, we consider that this value is fairly affordable.We provide a summary of the relevant configuration parameters defined through the section along with their default values in Table6.Table 6
Default configuration parameters.
Simulation model Full Reduced Number of nodes 2,878 200 Beacon interval 400 s 400 s Traffic model 1 CBR flow 4IPP Radio range 50 km 50 km Buffer size 100 packets 250,000 pkts Expiration time 14,400 s 14,400 s Max. number of hops 40 hops 40 hops


## 4. Experimental Evaluation

In this section, we introduce the concept of quality of service in a DTN and apply it to our hierarchical architecture. We describe the several metrics used to measure QoS, along with the parameters and characteristics of experiments performed, and finally, we summarize the results obtained.


### 4.1. Quality of Service

The quality of service describes the overall status of the network perceived by its users. QoS measurements are usually based on characteristics of the link such as bandwidth, transmission delay, or throughput. Other important aspects are the delivery ratio of packets and the fair allocation of resources.DTNs are challenged networks that provide delay tolerance and, as a result, cannot guarantee fixed delivery times. Therefore, factors such as the end-to-end delivery time or throughput cannot be used as a good measure of QoS on this kind of networks. On the other hand, this type of network should be robust, and an appropriate delivery ratio should be guaranteed. Other common aspects of such as network are the scarcity of resources. In this scenario, the critical resource would be the available satellite links and the limited bandwidth offered by that service. A fair distribution of this bandwidth among the several basic nodes of the network should be ensured. Therefore, we evaluate QoS in our scenario using the following metrics:(i)
Delivery time: this is defined as the time required for a packet to reach a ground station(ii)
Delivery ratio: this is the ratio of successfully delivered packets to the total number of packets generated in the network by the end of the simulation(iii)
Fair bandwidth allocation index: we use Jain’s fairness index [26] which offers us an estimation of the fairness network resource allocation based on the throughput of the nodes, or the rate of successful ground message delivery measured in kbps.


### 4.2. Delivery Time

In this section, we study the delivery time. In Delay Tolerant Networks, this metric is characterized by being long and variable. As such, it is usually not possible to provide a guaranteed delivery time and service is provided in a best-effort manner. In our scenario, two factors allow us to achieve a compromise, first the predictable contact pattern of our nodes and secondly the availability of the distributed satellite nodes. For this experiment, we use thereduced model configured with the default parameters from Table 6. We compare the hierarchical architecture against a purely opportunistic approach using the same nodes but without any satellite link available.In Figure3, we show the CDF of the delivery time. The abscissa represents the time component. The ordinate represents the percentage of packets delivered at a time less than or equal to the one shown in the abscissa. We can see that the opportunistic network samples show long delays with samples almost reaching a delay of ~90,000 seconds. Additionally, the average of the samples is ~42,000 seconds. Fortunately, 50% of the samples are smaller than ~40,000 seconds. On the other hand, the hierarchical architecture shows a clearly reduced delivery time, with 100% of the samples being below ~70,000 seconds and an average delay of ~34,000 seconds. This fact clearly shows that the presence of the distributed satellite nodes helps to improve the delivery time, and concretely it roughly doubles the performance regarding this metric.Figure 3
CDF of the delivery time.


### 4.3. Delivery Ratio

In this section, we study the delivery ratio. The delivery ratio is an important metric to infer the reliability of the network. Several parameters influence this metric, but a proper configuration of the routing protocol is essential. In the following experiments, we evaluate how our new hierarchical architecture provides a significant improvement in delivery ratio compared to a pure opportunistic approach.The two principal routing parameters that affect delivery ratio are theexpiration time and thebuffer capacity. Thebuffer capacity has been heavily analyzed theoretically resulting in expression (1) and its value has been fine-tuned to maximize delivery ratio. On the other hand, in this section we study the impact of theexpiration time using empirical experimentation.In Figure4, we show the average delivery ratio (expressed in a ratio between 0 and 1) under varying expiration times. We start evaluating our results using the default expiration value (14,500 seconds) and progressively increase it up to 20,000 seconds. This figure displays two lines; one corresponds to the hierarchical architecture and the other to a purely opportunistic approach. As we can see, a purely opportunistic approach displays fairly low delivery ratios (below 0.5) for expiration values below 16,000 seconds. On the other hand, the hierarchical architecture shows delivery ratios closer to 0.7. The opportunistic approach requires an expiration time of 18,500 seconds to surpass the delivery ratio of 0.7 displayed by an expiration time of 14,500 seconds of the hierarchical architecture.Figure 4
Average of the delivery ratio with confidence intervals.The results from Figure4 show that the insertion of satellite nodes has a high impact on the delivery ratio. The reason is that the presence of nodes capable of delivering data while still on flight reduces the need for holding data in the buffer for extended periods of time. As a result, the number of packets dropped by expiration decreases. Additionally, the buffers are less congested which also reduces the number of dropped packets due to lack of space.Subsequently, we study in which time intervals the inclusion of satellite has a higher impact on speeding up the delivery of messages. Before proceeding, we recall a particular scenario characteristic observed in our mobility characterization (see [4]). Nodes in this scenario display two peaks of activation. These peaks represent the usual trend of North Atlantic flights: airplanes start flying west (from Europe to America) during the day and east (from America to Europe) during the night. In Figure 5, we show the percentage of packets delivered (with respect to the total) at a specific time. The figure is split into three intervals, which correspond to the two peaks of node activation and to the median interval where planes flying in both directions converge.Figure 5
Percentage of packets delivered over simulation time.
(a)
Time interval corresponding to westbound flights (b)
Time interval corresponding to crossings between aircraft traveling in opposite directions (c)
Time interval corresponding to eastbound flightsIn Figure5, we can appreciate that the hierarchical architecture always displays a slightly faster delivery ratio, mainly because of the presence of the satellite links. This can be easily appreciated in Figures 5(a) and 5(c). Inversely, Figure 5(b) displays a time interval that has many contacts between nodes flying in opposite directions. This characteristic offers opportunities for fast delivery in an opportunistic manner. As a result, both architectures show relatively similar results.In both cases, full delivery of all packets is only achieved at around ~75,000 seconds. This late delivery is caused by packets being generated during the whole flight and the contacts with satellite nodes being limited. As a result, some packets cannot be delivered using a satellite link. Therefore, they are only delivered using opportunistic communications, or upon landing of the aircraft.


### 4.4. Fair Bandwidth Allocation

In this section, we try to determine if the network resources are equitably distributed among the different nodes. The primary concern for each aircraft is to maximize the bandwidth available to transfer their data. In this scenario, the bandwidth available to perform air-to-ground communications depended primarily on mobility factors, factors such as the number of encounters and how fast can data spread to reach the ground. The addition of nodes equipped with satellite communication provided a new alternative and significantly increased the available bandwidth. As a result, the access to these particular nodes became a valuable resource that needs to be fairly distributed, as all nodes may have an equal chance of using their forwarding capabilities.To assess the fair distribution of resources we use the Jain fairness index [26] which is described by the mathematical expression (2). This index rates the fairness of a set of resources for n users where xi is the throughput for the ith connection. Values range from 1/n (worst case) to 1 (best case) which signals equality in resource allocation. To compute this index, we consider the aircraft (as if it was a user) and outgoing delivered throughput.(2)Jx1,x2,…,xn=∑i=1nxi2n·∑i=1nxi2.In Figure6, we show the CDF of the throughput displayed by each aircraft for both architectures. It is appreciable that the hierarchical architecture has samples displaying higher throughput than the purely opportunistic approach. First, ~85% of the samples from the opportunistic set have throughput below 1 kbps. Conversely, in the case of the hierarchical architecture, the percentage is reduced to around 80%. Most of the remaining samples reach up to 3.5 kbps, and a small percentage of hierarchical samples can achieve up to 6–8 kbps. The average throughput for each case is 1.71 kbps (hierarchical) and 1.41 kbps (opportunistic). Note that since the network delays are long the throughput per unit of time is fairly low. These values show that the presence of the satellite nodes improves the throughput performance. We compute the fairness index for both cases, being 0.3817 for the opportunistic network and 0.4196 for the hierarchical architecture. This result indicates that the inclusion of satellite nodes can improve the fairness of the network.Figure 6
CDF of outgoing data throughput per aircraft.We now study the relationship between network fairness and the distribution of nodes with a satellite link. In this experiment, we use different distributions of satellite links. We obtain each configuration through a run of the scenario generation algorithm (see Algorithm1). Each configuration has a different proportion of normal nodes and nodes with a satellite link. In Figure 7, we show a bar plot displaying the fairness index resulting from different network configurations, corresponding to (% of normal nodes, % of satellite nodes). We consider the following cases: (100/0), (85/15), (75/25), (65/35), (50/50), and (35/65).Figure 7
Fairness index representation: 200 nodes with different proportions of normal nodes and satellite links.From the results of Figure7, we can observe that the use of satellite nodes can help improve the fairness to some degree, but not in all cases. It depends heavily on the distribution and number of satellite nodes. The network architecture without satellites has a fairness index of 0.38. When we add small numbers of satellite nodes to the network (15%), the fairness decreases due to a reduced number of nodes having much higher bandwidth than the rest. As the number of satellite nodes increases the availability of the higher bandwidth becomes more widespread and thus the fairness increases, achieving a maximum fairness index of 0.41. Again, if the number of satellite nodes increases too much it generates disparities between nodes with high bandwidth nodes and nodes with limited access to the resource; thus the fairness index decreases.


## 4.1. Quality of Service

The quality of service describes the overall status of the network perceived by its users. QoS measurements are usually based on characteristics of the link such as bandwidth, transmission delay, or throughput. Other important aspects are the delivery ratio of packets and the fair allocation of resources.DTNs are challenged networks that provide delay tolerance and, as a result, cannot guarantee fixed delivery times. Therefore, factors such as the end-to-end delivery time or throughput cannot be used as a good measure of QoS on this kind of networks. On the other hand, this type of network should be robust, and an appropriate delivery ratio should be guaranteed. Other common aspects of such as network are the scarcity of resources. In this scenario, the critical resource would be the available satellite links and the limited bandwidth offered by that service. A fair distribution of this bandwidth among the several basic nodes of the network should be ensured. Therefore, we evaluate QoS in our scenario using the following metrics:(i)
Delivery time: this is defined as the time required for a packet to reach a ground station(ii)
Delivery ratio: this is the ratio of successfully delivered packets to the total number of packets generated in the network by the end of the simulation(iii)
Fair bandwidth allocation index: we use Jain’s fairness index [26] which offers us an estimation of the fairness network resource allocation based on the throughput of the nodes, or the rate of successful ground message delivery measured in kbps.


## 4.2. Delivery Time

In this section, we study the delivery time. In Delay Tolerant Networks, this metric is characterized by being long and variable. As such, it is usually not possible to provide a guaranteed delivery time and service is provided in a best-effort manner. In our scenario, two factors allow us to achieve a compromise, first the predictable contact pattern of our nodes and secondly the availability of the distributed satellite nodes. For this experiment, we use thereduced model configured with the default parameters from Table 6. We compare the hierarchical architecture against a purely opportunistic approach using the same nodes but without any satellite link available.In Figure3, we show the CDF of the delivery time. The abscissa represents the time component. The ordinate represents the percentage of packets delivered at a time less than or equal to the one shown in the abscissa. We can see that the opportunistic network samples show long delays with samples almost reaching a delay of ~90,000 seconds. Additionally, the average of the samples is ~42,000 seconds. Fortunately, 50% of the samples are smaller than ~40,000 seconds. On the other hand, the hierarchical architecture shows a clearly reduced delivery time, with 100% of the samples being below ~70,000 seconds and an average delay of ~34,000 seconds. This fact clearly shows that the presence of the distributed satellite nodes helps to improve the delivery time, and concretely it roughly doubles the performance regarding this metric.Figure 3
CDF of the delivery time.


## 4.3. Delivery Ratio

In this section, we study the delivery ratio. The delivery ratio is an important metric to infer the reliability of the network. Several parameters influence this metric, but a proper configuration of the routing protocol is essential. In the following experiments, we evaluate how our new hierarchical architecture provides a significant improvement in delivery ratio compared to a pure opportunistic approach.The two principal routing parameters that affect delivery ratio are theexpiration time and thebuffer capacity. Thebuffer capacity has been heavily analyzed theoretically resulting in expression (1) and its value has been fine-tuned to maximize delivery ratio. On the other hand, in this section we study the impact of theexpiration time using empirical experimentation.In Figure4, we show the average delivery ratio (expressed in a ratio between 0 and 1) under varying expiration times. We start evaluating our results using the default expiration value (14,500 seconds) and progressively increase it up to 20,000 seconds. This figure displays two lines; one corresponds to the hierarchical architecture and the other to a purely opportunistic approach. As we can see, a purely opportunistic approach displays fairly low delivery ratios (below 0.5) for expiration values below 16,000 seconds. On the other hand, the hierarchical architecture shows delivery ratios closer to 0.7. The opportunistic approach requires an expiration time of 18,500 seconds to surpass the delivery ratio of 0.7 displayed by an expiration time of 14,500 seconds of the hierarchical architecture.Figure 4
Average of the delivery ratio with confidence intervals.The results from Figure4 show that the insertion of satellite nodes has a high impact on the delivery ratio. The reason is that the presence of nodes capable of delivering data while still on flight reduces the need for holding data in the buffer for extended periods of time. As a result, the number of packets dropped by expiration decreases. Additionally, the buffers are less congested which also reduces the number of dropped packets due to lack of space.Subsequently, we study in which time intervals the inclusion of satellite has a higher impact on speeding up the delivery of messages. Before proceeding, we recall a particular scenario characteristic observed in our mobility characterization (see [4]). Nodes in this scenario display two peaks of activation. These peaks represent the usual trend of North Atlantic flights: airplanes start flying west (from Europe to America) during the day and east (from America to Europe) during the night. In Figure 5, we show the percentage of packets delivered (with respect to the total) at a specific time. The figure is split into three intervals, which correspond to the two peaks of node activation and to the median interval where planes flying in both directions converge.Figure 5
Percentage of packets delivered over simulation time.
(a)
Time interval corresponding to westbound flights (b)
Time interval corresponding to crossings between aircraft traveling in opposite directions (c)
Time interval corresponding to eastbound flightsIn Figure5, we can appreciate that the hierarchical architecture always displays a slightly faster delivery ratio, mainly because of the presence of the satellite links. This can be easily appreciated in Figures 5(a) and 5(c). Inversely, Figure 5(b) displays a time interval that has many contacts between nodes flying in opposite directions. This characteristic offers opportunities for fast delivery in an opportunistic manner. As a result, both architectures show relatively similar results.In both cases, full delivery of all packets is only achieved at around ~75,000 seconds. This late delivery is caused by packets being generated during the whole flight and the contacts with satellite nodes being limited. As a result, some packets cannot be delivered using a satellite link. Therefore, they are only delivered using opportunistic communications, or upon landing of the aircraft.


## 4.4. Fair Bandwidth Allocation

In this section, we try to determine if the network resources are equitably distributed among the different nodes. The primary concern for each aircraft is to maximize the bandwidth available to transfer their data. In this scenario, the bandwidth available to perform air-to-ground communications depended primarily on mobility factors, factors such as the number of encounters and how fast can data spread to reach the ground. The addition of nodes equipped with satellite communication provided a new alternative and significantly increased the available bandwidth. As a result, the access to these particular nodes became a valuable resource that needs to be fairly distributed, as all nodes may have an equal chance of using their forwarding capabilities.To assess the fair distribution of resources we use the Jain fairness index [26] which is described by the mathematical expression (2). This index rates the fairness of a set of resources for n users where xi is the throughput for the ith connection. Values range from 1/n (worst case) to 1 (best case) which signals equality in resource allocation. To compute this index, we consider the aircraft (as if it was a user) and outgoing delivered throughput.(2)Jx1,x2,…,xn=∑i=1nxi2n·∑i=1nxi2.In Figure6, we show the CDF of the throughput displayed by each aircraft for both architectures. It is appreciable that the hierarchical architecture has samples displaying higher throughput than the purely opportunistic approach. First, ~85% of the samples from the opportunistic set have throughput below 1 kbps. Conversely, in the case of the hierarchical architecture, the percentage is reduced to around 80%. Most of the remaining samples reach up to 3.5 kbps, and a small percentage of hierarchical samples can achieve up to 6–8 kbps. The average throughput for each case is 1.71 kbps (hierarchical) and 1.41 kbps (opportunistic). Note that since the network delays are long the throughput per unit of time is fairly low. These values show that the presence of the satellite nodes improves the throughput performance. We compute the fairness index for both cases, being 0.3817 for the opportunistic network and 0.4196 for the hierarchical architecture. This result indicates that the inclusion of satellite nodes can improve the fairness of the network.Figure 6
CDF of outgoing data throughput per aircraft.We now study the relationship between network fairness and the distribution of nodes with a satellite link. In this experiment, we use different distributions of satellite links. We obtain each configuration through a run of the scenario generation algorithm (see Algorithm1). Each configuration has a different proportion of normal nodes and nodes with a satellite link. In Figure 7, we show a bar plot displaying the fairness index resulting from different network configurations, corresponding to (% of normal nodes, % of satellite nodes). We consider the following cases: (100/0), (85/15), (75/25), (65/35), (50/50), and (35/65).Figure 7
Fairness index representation: 200 nodes with different proportions of normal nodes and satellite links.From the results of Figure7, we can observe that the use of satellite nodes can help improve the fairness to some degree, but not in all cases. It depends heavily on the distribution and number of satellite nodes. The network architecture without satellites has a fairness index of 0.38. When we add small numbers of satellite nodes to the network (15%), the fairness decreases due to a reduced number of nodes having much higher bandwidth than the rest. As the number of satellite nodes increases the availability of the higher bandwidth becomes more widespread and thus the fairness increases, achieving a maximum fairness index of 0.41. Again, if the number of satellite nodes increases too much it generates disparities between nodes with high bandwidth nodes and nodes with limited access to the resource; thus the fairness index decreases.


## 5. Discussion

In this section, we define a set of service levels for this network and discuss the appropriate parameters required to ensure them. To define these guarantees, we first need to take into account the available resources of the scenario. In this regard, there are no limitations concerning buffer sizes and data storage due to the nodes being aircraft. On the other hand, the access to satellite links is costly. Therefore, their usage should be limited. To sum up, with the default hierarchical network architecture composed of a 35% of nodes with satellite links we can guarantee(i)
delivery ratio higher than 90%,(ii)
delivery times below 70,000 seconds,(iii)
a bandwidth fairness index of 0.41.Achieving those results requires expanding the packet expiration to values higher than 20,000 seconds. Flight operators seeking close to 100% delivery (which would probably be needed to satisfy customers) may require these increased buffer expirations. Higher expiration values influence the packet buffer capacity of the node, requiring an increase of the order of some hundred MB. Taking into account the characteristics of the nodes of this scenario these buffer requirements are cost negligible.Nevertheless, even without this increase, we can guarantee delivery ratios around 70% (offering an improvement of 20% in respect to opportunistic communications). On the other hand, the increase in bandwidth fairness is more discrete. A further improvement would require deploying an explicit resource management policy for satellite distribution.


## 6. Conclusions and Future Work

In this paper, we provide an evaluation of the QoS of a novel aeronautical ad hoc network architecture based on opportunistic communications and satellite communication systems. To this end, we designed a reduced experimental model of the transoceanic network scenario for use in simulations with adapted traffic volumes, that is, without considering traffic from video and other highly interactive applications. Using this reduced model, we measured several QoS related aspects such as the delivery ratio, the delivery time, and the fairness in the distribution of network resources. Finally, we compared the improvements in service obtained with the hierarchical network architecture of [7] when compared to that of a simple network using opportunistic communications. Our results show that using equivalent buffer configuration parameters the delivery ratio is increased by almost a 20% margin, delivery times are cut by 10,000 seconds, and the fairness is slightly increased. Those contributions allow offering certain guarantees regarding delivery ratio and time of the service, which is quite unusual in the field of DTNs. Furthermore, results confirmed that the configuration with 35% of satellite links seems to be a proper distribution of these links. From that point, models that encourage sharing these satellite links among the aircraft have to be developed.Additional future work will focus on the implementation of nonarchitectural improvements to QoS. We believe that similar approaches as those found in the literature may be able to improve the fairness of resource allocation without implying an increase in cost. Future improvements could include the following:(i)
The introduction of priority levels of network traffic which should help to distribute satellite link access more fairly, which will maximize network fairness while minimizing the number of satellites and thus the architectural cost(ii)
The inclusion of buffer management and drop policies which will help improve the delivery ratio without requiring the increase of the size or expiration timeA second topic that needs further research is the consideration of two-way communications to perform ground-to-air communications. As opposed to air-to-ground where the only objective is to exit the disconnected area (since all paths lead to the ground we can choose any satellite link node), in ground-to-air we need to locate a particular aircraft. This type of communication poses several nontrivial challenges regarding routing, gateway selection, and traffic load balance.



---

*Source: 7601316-2016-10-25.xml*