Aero-Sim: An NS-2 Based simulator for Aeronautical Ad Hoc Networks

Abstract

Recently, there has been a clear trend towards the application of ad hoc networking technology in civil aviation communication systems, giving birth to a new research field, namely, aeronautical ad hoc networks (AANETs). An AANET is a special type of ad hoc wireless network with a significantly larger scale and distinct characteristics of its mobile nodes. Thus, there is an urgent need to develop a simulator to facilitate the research in these networks. In this paper, we present a network simulator, Aero-Sim, for AANETs. Aero-Sim, which is based on the freely distributed NS-2 simulator, enables detailed packet-level simulations of protocols at the MAC, link, network, transport, and application layers by composing simulations with existing modules and protocols in NS-2. Moreover, Aero-Sim supports three-dimensional network deployment. Through several case studies using realistic China domestic air traffic, we show that the proposed simulator can be used to simulate AANETs and can reproduce the real world with high fidelity.

1. Introduction

In recent years, there has been substantial growth in mobile ad hoc networks (MANETs) in land-based small-to-medium size networks with relatively strict power and resources. However, MANETs should not be limited to small devices and localized parameters, such as Bluetooth devices and IEEE 802.11 wireless local area networks [1]. They can be extended almost to a global network level where the mobile entities are large-scale systems with relatively large resources and transmission power. Therefore, some research communities and researchers have begun applying MANETs to aeronautical communications [2] [3] [4] [5], leading to the rise of a novel research field, aeronautical ad hoc networks (AANETs) [3]. An AANET is a special type of MANET, where the nodes represent aircraft in an airspace for the purpose of sharing data and Internet access. In an AANET, an aircraft is not only a transceiver, but also a router that can forward packets to other aircraft through multi-hop communications. As the future development direction of military and civil aviation communication, research on and application of AANETs is promising.

Network simulators, which can provide a controlled environment for researchers, are widely used in researching various types of networks when hardware resources are limited. And network simulation is undoubedly one of the most widely used evaluation methodologies for research on computer networks. It is widely used as the first step in evaluating the functionality of the newly proposed designs for network research as well as for developing and validating the new protocols. Thus, it is highly desirable to have a standard network simulator to facilitate research on AANETs.

To the best of our knowledge, there is no complete packet level aeronautical simulator published yet. Although there are several widely used packet-level simulators such as Network Simulator 2 (NS-2) [6] and Optimizing the Performance of the Network (OPNET) [7], these were developed for wired and/or terrestrial wireless networks, and not for aeronautical networks. They cannot be used for simulating aeronautical networks for the following reasons. First, AANETs are implemented in a three-dimensional (3D) environment, with nodes moving over large distances, whereas these simulators typically support only two-dimensional deployment of MANETs. For example, in the NS-2 network simulator, Carnegie Mellon University (CMU)’s Monarch research groups [8] have contributed support for MANETs [9]. The module essentially consists of a MobileNode at the core, which is a basic Node object with added functionalities of a wireless and mobile node, such as ability to move within a given topology, receive and transmit signals to and from a wireless channel, and so on. A MobileNode is designed to move in a 3D topology; unfortunately, the third dimension is not used. The satellite module [10] in NS-2 can support 3D deployment of network nodes; however, the module does not define aeronautical nodes and their attributes. In addition, no protocols suitable for AANETs have been designed and implemented in this module. Second, the high speeds of the aircraft cause network topologies to change rapidly, which can have a significant impact on network connectivity, and the media access control (MAC) and routing protocols. The corresponding protocols in these traditional simulators are not well suited to AANETs and new protocols need to be incorporated. These characteristics make existing network simulators unsuitable for use with AANETs.

In this work, we developed a simulator, called Aero-Sim, for AANETs. The simulator is based on NS-2, the most popular network simulator in both academia and industry and which has become the de facto standard for simulation of packet-switched networks [11] [12]. Since NS-2 is an open-source event-driven simulation tool, anyone can make changes to the existing code or incorporate new simulation modules, extending the built-in NS-2 code. Meanwhile, researchers can make full use of existing protocols and utilities in NS-2 for their own development. Thus, we chose NS-2 as the development platform for simulating AANETs.

Based on NS-2, Aero-Sim supports a 3D aeronautical environment and can faithfully simulate the attributes of aeronautical nodes. Moreover, by composing simulations with existing modules and protocols(such as transmission control protocol (TCP) or user datagram protocol (UDP)) in NS-2, Aero-Simenables packet-level simulations of protocols at the MAC, link, network, transport, and application levels of the TCP/IP reference model. Furthermore, it can easily be integrated with other aspects of NS-2. Thus, Aero-Sim can simulate AANET communication very well.

In this paper, we report on our extension of NS-2, namely, the AANET module. Our main contributions are the following. First, we propose an integrated module based on NS-2 that ensures compatibility with existing modules and allows easy integration of new protocols as the simulator for AANETs. Second, based on an analysis of the characteristics of AANETs, we clearly define the structure of an aeronautical node. Finally, we systematically implement protocols in the MAC and routing layers that are suitable for aeronautical communications.

The remainder of this paper is organized as follows. Section 3 details the design goals and overall structure of the simulator. The design and implementation of the simulator are presented in detail in Section 4. Through implementation of various case studies, Section 5 illustrates some of the capabilities of our simulator. Finally, we present our conclusions and suggestions for future work in Section 6.

 

2. Overview of Aero-Sim

In this section, we first describe the design goals of the simulator. Thereafter, we give an overview of the Aero-Sim design, and discuss its motivation, overall structure, and the relationship to the NS-2 simulator.

2.1 Design Goals

To ensure that the proposed simulator can be easily configured, used, and extended for a wide range of applications, the following design goals were identified:

2.2 Basic Structure of the Simulator

As discussed earlier, in NS-2, the CMU wireless module can support simulation of terrestrial wireless ad hoc networks. Nevertheless, such a simulation package cannot easily be applied to aeronautical networks. Thus, we introduced several new components into NS-2 to model aeronautical networks more accurately.

To meet the requirement of modular design, instead of adding an existing wireless networking module, we developed a new NS-2 module, called Aero-Sim, which exists in parallel with the CMU wireless module and other NS-2 modules. Fig. 1 illustrates the relationship between Aero-Sim, the CMU wireless package, and other NS-2 modules. In this way, Aero-Sim can be compatible with other aspects of the NS-2 simulator, but can also evolve independently, thereby making the simulator highly modular.

Fig. 1.Relationship between Aero-Sim and other modules in NS-2

Aero-Sim follows the object-oriented design style of NS-2, and all network entities are implemented as classes in C++. Object tool command language (OTcl) scripts are used to facilitate tuning of parameters of the protocols and algorithms implemented in C++. Such a design makes the integration of new protocols with Aero-Sim as well as the adjustment of protocol parameters easy. In other words, the basic structure of Aero-Sim satisfies the design goals well. As we can see in Fig. 2, the source C++ code is located in the ~ns/Aero-Sim directory and the OTcl code is located in the ~ns/tcl/lib directory. The folder aero-test includes all the OTcl script examples to validate Aero-Sim.

Fig. 2.NS-2 directory structure including the Aero-Sim module

 

3. Design and Implementation

In this section, based on the design goals, we present the design and implementation of Aero-Sim in detail, including the aeronautical node classes, node position classes, node handoff classes, MAC layer classes, and routing layer classes.

3.1 Aeronautical Nodes

There are three types of aeronautical nodes in the Aero-Sim module, with the most common type representing aircraft (A/C). Besides A/C, two other node types are available: airports and satellites. Although satellites are considered part of the network, their use is limited to areas where other means of communication are unavailable.

The detailed implementation of class AeroNode resides in the aeronode files. Fig. 3 depicts a schematic of the main components of an AeroNode. As can be seen, this architecture of AeroNode can support the aeronautical node with multiple interfaces and each node would have as many copies of the chain of protocol stack entities as many interfaces it has. The AeroNode object is an abstraction of all three aeronautical nodes types. Instances of each of the nodes are actually implemented using the same node object, but with different position, handoff manager, and link objects attached.

Fig. 3.The structure of class AeroNode

3.1.1 Position Object

To keep track of the aeronautical node’s location, we add an AeroPosition object to an AeroNode node. Specifically, there is a single class of aeronautical node Class Node/AeroNode, to which one of four types of AeroPosition objects may be attached. Each AeroNode and AeroPosition object is a split OTcl/C++ object, but with most of the code written in C++. All the classes related to the AeroPosition object are implemented in the aeropos files, while all position objects are derived from the same abstract base class AeroPosition. Four child classes are derived from the AeroPosition base class: AircraftAeroPosition, AirportAeroPosition, GeoAeroPosition and PolarAeroPosition. Public interfaces that are common to all position objects are specified in AeroPosition. For example, if one wished to know the location of an aircraft at any given moment, the common “coord” interface, specified in class AeroPosition, could be invoked without any knowledge of the detailed implementation. In this way, a new position object could easily be imported into Aero-Sim by implementing the interface specified in AeroPosition.

Below we give a brief overview of the four AeroPosition objects in Aero-Sim.

Because the AANET is implemented in a 3D environment, we use a spherical coordinate system to compute the location of a node. The main parameters of the coordinate system are defined in the s_coordinate data structure shown below.

struct s_coordinate {

};

This coordinate system is centered at the Earth’s center, with the z-axis coinciding with the Earth’s rotational axis. However, this can easily be converted to a Cartesian coordinate system using a node’s latitude and longitude. Therefore, an aeronautical node’s location at any given moment can be calculated. For example, assume that an aircraft is flying from Chengdu to Beijing. For simplicity of computation, we selected three navigation points on this flight route: ONEBA, OKVUM and ISGOD. The latitude and longitude coordinates of the airports and navigation points can be set in the OTcl script configuration, and the aircraft’s instant position can be described as (A. r, A. theta, A. phi) [see Fig. 4].

Fig. 4.Theoretical model to calculate the position of an aircraft

Here, R is the earth’s radius, h is the average altitude of the aircraft, A1.theta and A1.phi can be obtained through the position parameters of the navigation points and airports, the speed of the aircraft, the current time, and the corresponding coordinate transformation. Finally, the impact of the Earth’s rotation on a node’s location is also considered. The values of A.r and A.theta are unchanged, but the value of A.phi is changed as follows when considering the Earth’s rotation:

where earth_w is the angular velocity of the Earth's rotation, NOW is the current time, and starttime is the starting time of the flight.

3.1.2 Handoff Monitor

Unlike terrestrial wireless ad hoc networks, in an aeronautical environment, aircraft move at extremely high speeds, with the topology changing quickly. Since the links between aeronautical nodes need to be dynamically detached and attached to different nodes, we introduced AeroHandoff agents to manage link handoffs.

In the Aero-Sim module, we establish certain criteria for performing handoffs, and allow nodes to independently monitor a handoff. All the C++ codes for dealing with handoffs resides in the aerohandoff files. We defined three classes to handle handoff of aeronautical nodes: AircraftLinkHandoffMgr, AirportLinkHandoffMgr and SatLinkHandoffMgr, which are derived from the same abstract base class AeroLinkHandoffMgr. The child classes implement the virtual function handoff() in class AeroLinkHandoffMgr, based on the different handoff policies for different types of aeronautical nodes. Since the satellite handoff policies have been implemented in the satellite module, here we discuss the handoffs of the aircraft. There are three types of aircraft links that can be handed off: AGLs for links froman aircraft to an airport, AALs for links between aircraft and ASLs for links from an aircraft to a polar satellite.

int AircraftLinkHandoffMgr::handoff()

{

}

In this function, different handoff policies have been implemented based on the type of the link. An aircraft connected to an airport runs a timer that, upon expiry, causes the AeroHandoff manager to check whether the distance between the aircraft and the airport is greater than the maximum communication distance. If so, the handoff manager disconnects the aircraft from that airport’s interface, and searches for another possible airport. If it finds a suitable airport, it connects its network interfaces to that airport’s uplink and downlink channels, and restarts the handoff timer. If it does not find a suitable airport, it restarts the timer and tries again later. These policies are adapted for AAL links as well. ASL links execute a handoff in the same way as GSL links from a terminal to a polar satellite in the satellite module.

As is widely known, in aeronautical communication, an aeronautical node is assumed to possess an abundance of power. The theoretical maximum transmission range between two nodes is limited by the horizon for typical line-of-sight communication in the very high frequency (VHF) band. Assuming a flight altitude of 10 km, according to the curvature of the earth, air.air and air.ground links can extend to approx. 600 km and 400 km, respectively, which is on par with current and future aeronautical VHF specifications.

3.2 Physical Layer and MAC Layer

All classes related to the physical and MAC layers are included in the aerolink files. Since we were more interested in research on protocols above the physical layer, we chose to abstract out the precise details of physical motion and channel modeling in Aero-Sim. Similar to the code in the wireless module, class AeroPhy merely passes the information up and down the stack.

void AeroPhy::sendDown(Packet *p)

{

}

int AeroPhy::sendUp(Packet *p)

{

}

Ho Dac Tu et al. [13] [14] proposed the widely used carrier sense multiple access (CSMA) [15] MAC protocol, which cannot be exploited effectively in AANETs considering the wide area communication network with a radius of 600 km. Currently, many AANET projects use the time division multiple access (TDMA) protocol in the MAC layer. For these reasons, the MAC protocol used in Aero-Sim is a simple reservation TDMA scheme, with the TDMA frame format illustrated in Fig. 5:

Fig. 5.The structure of a TDMA frame

.In the preamble time slot, every node uses a special sub-time slot to broadcast the destination MAC address of the packet to be sent. Other nodes listen to the preamble and record the time slot from which they receive data from. Meanwhile, every node has a data time slot to send data.

The data structure of the preamble time slot is designed and initialized as follows:

static int * preamble_tdma;

/* max_slot_num is the number of the nodes */

preamble_tdma = new int[max_slot_num];

/*slot_num stands for the number of the time slot, dst stands for the mac address of the destination node */

preamble_tdma[slot_num] = dst;

The main task during the preamble time slot is to set the value of array preamble_tdma[], which denotes the destination MAC address of the data that will be sent during time slots zero to max_slot_num-1. When the preamble time slot finishes, nodes send data in their own data time slots, and decide whether to receive data in other time slots based on the information in the preamble. The following functions are the implementation of the send and receive processes:

/* send the packet */

Void TdmaMac::send () {

…

/*get the transmit time of the packet */

int packetsize_ = HDR_CMN(Txpkt_)->size() + LINK_HDRSIZE;

assert(bandwidth_!=0);

txt = txtime(packetsize_);

HDR_MAC(p)->txtime() = txt;

…

/*start a timer that expires when the packet transmission is complete*/

mhTxPkt_.start(Txpkt_->copy(),txt);

/*pass the packet to the physical layer*/

downtarget_->recv(Txpkt_, this);

…

}

/*To handle incoming packet*/

void TdmaMac::recv(Packet* p, Handler* h) {

/* Packets coming down from ll layer, send them to phy layer. */

}

3.3 Routing Layer

The C++ code for the routing layer is included in the aeroroute files. The current routing implementation in Aero-Sim is a centralized routing method, which is implemented entirely in C++. Furthermore, to support distributed routing protocols in AANETs, Aero-Sim makes use of a routing agent at each node. Like the mobility extension parts of NS2, routing packets can be sent to port 255 of each node. Moreover, Aero-Sim provides standard interfaces at almost every network layer to support advanced features of the routing protocols. For example, geolocation-assisted routing protocols can easily obtain location information from the interface of the AeroNode object. Thus, Aero-Sim provides a good platform for developing advanced routing protocols.

Instead of computing new routes when the topology changes, the centralized routing algorithm in Aero-Sim computes routes only when there is a packet to send. Furthermore, a single-source shortest-path algorithm is executed instead of an all-pairs shortest path algorithm. The shortest-path route computations use the current propagation delay of a link as the cost metric. Considering that the number of aeronautical nodes is very large, the original centralized routing method would produce a very slow runtime. Thus, we make a major revision to the routing algorithm. Since the aircraft are continuously taking off and landing, to speed up the simulation, when a node computes its adjacency and routing table, it does not consider nodes representing aircraft that have not yet taken off or have already landed. So, the sizes of the adjacency and routing tables of a node are greatly reduced, especially when there are only a few aircraft flying. This yields a run-time performance improvement. This revision involves three aspects, as follows.

First, to maximize the use of the original code, we use an array to store the required nodes. The adjacency table uses the node id as an index into the array to record the link adjacency information.

void AeroRouteObject::compute_topology()

{

…

/*insert the airports, satellites and the aircraft that are flying into the array */

air_coord = ((AeroNode* )nodep)->position()->coord();

for (nodep=Node::nodehead_.lh_first; nodep; nodep = nodep->nextnode()) {

…

/* src_index and dst_index are the index of the source and destination node */

insert_link(src_index+1, dst_index+1, delay, (void*)alhp);

…

}

Second, when the sending node computes its routing table, the node id is the index of this value in the array computed by function compute_topology().The shortest-path algorithm is not changed.

void AeroRouteObject::node_compute_routes(int node)

{

...

/* get the node index*/

for(int i=0; i

int k = node_index + 1; // add one to get the right offset in tables

/* compute routes only for node "k" */

…

}

Finally, when look up the route table to get the next hop nodes and the entry to construct the forwarding table, we also use the index of the node id. The return value of the look up is the index of the next hop nodes, and thus, we must use the index in the real_node[] array to get the real next hop node.

void AeroRouteObject::populate_routing_tables(int node)

{

...

next_hop_index = lookup(src_index, dst_index);

next_hop = real_node[next_hop_index];

…

target = (NsObject*) lookup_entry(src_index, dst_index);

/* construct the forwarding table*/

((AeroNode*)snodep)->ragent()->install(dst, next_hop, target);

...

}

 

4. Case Studies

In this section, we present several case studies to illustrate some of the capabilities of our simulator. By simulating aircraft flying using realistic flight data, we show that Aero-Sim can reproduce the real world with high fidelity. Then we demonstrate the validation of Aero-Sim via an AANET simulation example while the fundamental routing and propagation delay are also analyzed.

4.1 Fidelity Testing

To test the fidelity of Aero-Sim, our first experiment with Aero-Sim was designed to study the possibility of aeronautical ad hoc networking in China’s airspace and analyze ground connectivity from the perspectives of the whole network and a single aircraft using realistic domestic flight data.

4.1.1 Data Collection

First, we queried (on the Internet) the average passenger traffic in domestic airports from 2011 to 2013 and ranked the data to get the top 24 busiest domestic airports. Since the traffic in other airports is relatively small, we ignored these airports. Then, we collected detailed inbound and outbound flight information for the 24 airports for a week in October 2013. The flight information changes slightly from one day to the next, and we chose a representative average day for our simulations. Next, we used the latest database in the global route query system provided in AIRCN [16] to query detailed flight routes of the collected flights. This enabled us to obtain the latitude and longitude of the navigation points between the departure and destination airports. For simplicity, we chose navigation points with differences in latitude or longitude no less than three degrees.

4.1.2 Flight Sim

According to the flight data collected in Section 4.1.1, there are on average 10,521 aircraft in China’s airspace on any day. Beijing Capital International Airport, Shanghai Pudong International Airport, and Guangzhou Baiyun International Airport were chosen as ground stations to communicate with aircraft while airborne. Detailed position information of the airports and the flight schedules of all commercial airlines are specified in the file ~ns/tcl/mobility/scene/route-aircraft. Considering that a few aircraft would not have landed by midnight on the simulated day, the simulation time was set to 90,000 s to simulate the entire flight process, with the locations of the aircraft recorded every 3,600 s. Table 1 shows the main simulation parameters for Aero-Sim, including R, which denotes the air–air transmission range. In this experiment, we were interested in the basic characteristics of the dynamic topology created by the AANET, regardless of the routing technique used to forward packets over the network.

Table 1.Parameter configuration for Aero-Sim

4.1.3 Networking Possibility and Connectivity Analysis

Fig. 6 shows the number of aircraft found within China’s airspace throughout the day. The results show that the number of domestic flights in China’s airspace varies considerably depending on the time of day. Between 08:00 and 23:00, the number is greater than 1000, with a peak of 1600 during the period 09:00 to 17:00. From 02:00 to 05:00, there are only a few domestic aircraft airborne. Fig. 7 shows snapshots of the domestic air traffic situation in China’s airspace around 01:00, 08:00, and 16:00 GMT+8 on an average day.

Fig. 6.Variation in the number of aircraft in China’s airspace throughout the day

Fig. 7.Snapshots showing aircraft distributions in China’s airspace at (a) 01:00, (b) 08:00, and (c) 16:00 GMT+8

The Chinese continent can be divided into Eastern and Western parts by the Moheng–Tengchong dividing line. We analyzed the numbers and densities of aircraft in these two parts. As shown in Fig. 8 and Fig. 9, the number and density of aircraft in the Eastern airspace is much higher than that in the Western airspace. The variation in the number of flights and density throughout the day is very large in the Eastern airspace and relatively smaller in the Western airspace.

Fig. 8.Variation in the number of aircraft in the Western and Eastern airspace in China throughout the day

Fig. 9.Variation in the density of aircraft in the Western and Eastern airspace in China throughout the day

Based on the airplane density in the Eastern and Western airspace and the function of networking probability and airplane density [3], we can calculate the probability of aeronautical ad hoc networking in the respective airspaces. As shown in Fig. 10 and Fig. 11, even though the air–air transmission range is 100 km, the probability of aeronautical ad hoc networking between 08:00 and 24:00 in the Eastern airspace is 1. However, in the Western airspace, the communication range must be 300 km to ensure a probability of 1 for aeronautical ad hoc networking between 08:00 and 24:00. Meanwhile, because the number of flights from 01:00 to 07:00 in both the Eastern and Western parts is very small, the probability of aeronautical ad hoc networking during this time is very low even with an ideal communication radius. In other words, it is difficult to establish an AANET during this period.

Fig. 10.Networking probability in the Western airspace in China throughout the day

Fig. 11.Networking probability in the Eastern airspace in China throughout the day

Since an AANET provides an effective means for communication between aircraft and the ground stations, the following analysis is aimed at the ground connectivity of the aircraft. The connectivity is usually assessed by the following two metrics [5]:

where C(t) is a metric defining the perspective of the entire network. It denotes the fraction of all aircraft that are directly connected or have at least one multiple path to a ground station at a given time. Contrarily, μ is the metric from the perspective of a single aircraft and defines the percentage of the flight duration during which the aircraft can contact a ground station.

Fig. 12 shows the variation in connectivity over 24 hours for several air–air transmission ranges. Table 2 gives the mean value , averaged over all flights and the percentage of flights for which μ > 0.99 in the three different ranges. As seen in Fig. 12 and Table 2, ground connectivity of the network improves with an increased air–air transmission range. An air–air transmission range of 600 km is sufficient to guarantee almost 100% connectivity between 08:00 and 24:00. Moreover, in this range, an aircraft is connected to the ground for more than 99% of its flight duration on average. In addition, more than 98% of the flights have permanent connectivity to the ground. In other words, the three ground stations in Beijing, Shanghai, and Guangzhou in China can provide adequate ground connectivity with an air–air transmission range of 600 km.

Fig. 12.Variation in connectivity of the network throughout the day

Table 2.Aircraft ground connectivity statistics

Considering the experimental results using realistic flight data and the analysis above, it is clear that Aero-Sim can be used to simulate the whole flight process and to investigate networking possibility and ground connectivity, which are the most important problems in AANETs. Furthermore, Aero-Sim closely approximates the results in the real world and thus can be used to reproduce the real world with high fidelity.

Because of the relatively high cost and difficulties of deploying aeronautical nodes, it is often impossible to deploy a real network in every research effort. As an alternative, Aero-Sim provides a powerful tool for carrying out research on AANETs.

4.2 Validation

In this section, we use a simulation example to illustrate how Aero-Sim can be used to implement an AANET. Then, the fundamental routing and delay characteristics are analyzed.

4.2.1 Simulation Setup

In this experiment, we simulate a 1-h time window from 08:00 to 09:00 in the Western airspace in China, corresponding to a typical rush hour on an average day. The airborne network consists of roughly 354 aircraft during this time. These aircraft communicate with the ground stations via an AANET. We concentrated on the aircraft flying from Chengdu to Beijing between 08:00 and 10:20. Constant bit rate (CBR) traffic is sent from the aircraft to the Beijing ground station from 28,800 s to 32,400 s in the flight with a transmission interval of 50 s. Considering that the duration of the inter-aircraft link is relatively long when compared with other ad hoc networks [5], the handoff time of the inter-aircraft link is 100 s. The air–air transmission range is fixed at 600 km. The other main simulation parameters are as given in Table 1.

4.2.2 Analysis of Results

Fig. 13 shows the positions of the aircraft flying in the Western airspace, and the paths from the source aircraft to the destination ground station at different times between 08:00 and 09:00. Each source aircraft calculates a routing path every 100 s. Since the aircraft move at high speeds, even if the link status does not change in 100 s, the global min-delay shortest path may be different during this period.

Fig. 13.Routing path from source aircraft to destination Beijing between 28,800 and 32,400 s

Fig. 14 plots the end-to-end delay variability between the source aircraft and Beijing ground station from 28,800 s to 32,400 s. The data points represent the delay experienced by a packet sent every 50 s. Generally, as the source aircraft fly towards Beijing, the delay decreases. Moreover, 31,600 s into the flight, the delay is noticeably smaller. This is because at that time, the path between the source and destination only traverses one aircraft hop compared with two hops before that time. However, 31,800 s into the flight, the delay increases sharply because two aircraft hops are required on the path.

Fig. 14.Propagation delay from source aircraft to destination Beijing from 28,800 to 32,400 s

 

5. Conclusion and Future Work

An AANET is a new ad hoc network between airborne commercial aircraft for the purpose of sharing data and Internet access. Owing to the significant distinctions between AANETs and terrestrial wireless networks, a new simulator for AANETs was urgently needed. In this paper, we presented the design and implementation of Aero-Sim, a packet level AANET simulator based on NS-2, which is suitable for simulations of the MAC, link, network, transport, and application layers by composing simulations with existing modules and protocols.

Through several case studies using realistic domestic flight data, we showed that Aero-Sim is a powerful simulation tool with high fidelity that can simulate AANETs accurately. As future work, we intend investigating distributed routing protocols suitable for an AANET and integrating them into Aero-Sim.