Trajectory-Aware Rate Adaptation for Aerial Networks Simulation Results

Introduction Even though the concept of ubiquitous wireless connectivity is becoming a reality, there are scenarios where wireless communications coverage is insufficient or does not exist. Considering natural and man-made disaster scenarios, communications infrastructures may be damaged and become unavailable. In temporary crowded events, the existing infrastructure may not have been designed to cope with the additional traffic demand, resulting in overload. In maritime scenarios, environmental monitoring activities using autonomous vehicles will take place in offshore zones, typically not in range of existing onshore communications infrastructures. Flying networks, composed of Unmanned Aerial Vehicles (UAV), are emerging as a flexible and cost-effective solution to provide on-demand wireless connectivity in such scenarios. UAVs have the possibility to operate virtually everywhere, and the growing payload capacity makes them suitable platforms to carry wireless communications hardware, playing the role of mobile base stations, access points or relay nodes. A flying network may typically be composed of a fleet of UAVs, organized in a multi-tier topology with so-called Flying Edge Nodes (FENs) and Flying Gateways (FGWs) [1]. FENs can play the role of Flying Access Points that provide the access network to the users on the ground, or the role of Flying Sensor Nodes that can perform video surveillance missions. The FENs forward the traffic to the FGWs, that act as relay nodes and are responsible for forwarding the traffic to/from the backhaul (BKH) network and ultimately to/from the Internet. The flying network concept brings up new challenges. The flying nodes need to be properly positioned and their wireless link configuration dynamically adjusted in order to ensure the Quality of Service (QoS) expected by the end users. In addition, these scenarios are typically highly unpredictable due to the varying locations as well as the concentration/dispersion of end-users and their movements regarding direction and velocity - e.g., vehicles or pedestrians. Therefore, a static wireless link configuration and UAV positioning are not adequate. State of the art work has been mainly focused on the optimal positioning of the flying nodes, having most of the wireless link parameters statically configured with default values. The Rate Adaptation challenge is well-known in fixed or low mobility IEEE 802.11 networks, and Minstrel High Throughput (HT) [2] is the default Wi-Fi rate adaptation algorithm used in the Linux kernel since the IEEE 802.11n version. However, few works propose solutions designed to consider the characteristics of other communications environments, such as flying and vehicular networks [3]. To the best of our knowledge, solutions that use the node trajectory information to predict the wireless channel conditions and perform rate adaptation are yet to be developed. The main contribution of this paper is the Trajectory-Aware Rate Adaptation (TARA) algorithm. TARA takes advantage of knowing the trajectory of all nodes in the flying network to estimate future changes in the wireless link quality and perform rate adaptation accordingly. The network performance improvement achieved with TARA was evaluated using ns-3 [4]. The simulation results presented in this dataset show significant throughput gains when compared with conventional rate adaptation algorithms. Folder Organization The following dataset presents the results of the TARA Paper, organized in different folders for each Rate Adaptation Algorithm, as well as the random seeds that were used to obtain such results: Naming Convention: Rate Adaptation Algorithm tara – Trajectory-Aware Rate Adaptation min – MinstrelHTWifiManager id – IdealWifiManager Folder Content: distances.csv - Distances between nodes Column 1 – Simulation Time (seconds) Column 2 – Distance between BKH and FGW (meters) Column 3 – Distance between FEN and FGW (meters) positions.csv - Current 3D position of nodes Column 1 – Simulation Time (seconds) Column 2 – BKH x (meters) Column 3 – BKH y (meters) Column 4 – BKH z (meters) Column 5 – FEN x (meters) Column 6 – FEN y (meters) Column 7 – FEN z (meters) Column 8 – FGW x (meters) Column 9 – FGW y (meters) Column 10 – FGW z (meters) throughput.csv - Link Specific Throughput, at MAC layer level Column 1 – Simulation Time (seconds) Column 2 – Relay Link (BKH - FGW), Throughput measured in BKH (Mbit/second) Column 3 – Access Link (FEN - FGW), Throughput measured in FEN (Mbit/second) Column 4 – Relay Link (BKH - FGW), Throughput measured in FGW (Mbit/second) Column 5 – Access Link (FEN - FGW), Throughput measured in FGW (Mbit/second)