FlyNetSim: An Open Source Synchronized UAV Network Simulator based on ns-3 and Ardupilot

1 INTRODUCTION

• FlyNetSim addresses the limited availability of tools that accurately model both fine-grained UAV operations and networking/IoT dynamics.The paper notes that mature tools often focus on one aspect and oversimplify the other.Source: §1 · p. 1
• The paper emphasizes urban IoT settings that combine wireless technologies, backhaul networks, and edge or cloud computing resources.The listed communication technologies include Wi-Fi, LTE, and D2D.Source: §1 · p. 1
• Its objectives include preserving UAV software control pipelines, modeling multi-technology IoT interactions, and mapping each UAV to an NS-3 node with multiple interfaces.The design also preserves individual paths to and from UAV sensors and controllers.Source: §1 · p. 1
• FlyNetSim supports on-board emulation with real UAVs and in-the-loop real-time processing, including testing edge-computing architectures.The emulation mode runs the simulator on a real-world UAV.Source: §1 · pp. 1–2
• The open-source environment combines NS-3 and ArduPilot with lightweight middleware for synchronized, end-to-end data paths between network and UAV operations.The middleware uses a publish-and-subscribe framework and is intended to support many UAVs and varied IoT infrastructures.Source: §1 · p. 1
• Case studies cover remote Wi-Fi control under mobility, delay, and congestion; multi-network links; intra-swarm D2D coverage; and telemetry and video streaming.The paper also showcases real-world UAV emulation.Source: §1 · p. 2

UAV Simulators

• ArduPilot-based simulators extend UAV modeling, but Gazebo can be resource-heavy at scale, while several commercial tools focus mainly on motion and navigation.FlyNetSim uses Software In The Loop (SITL), described as a simple ArduPilot-based simulator supporting autopilot navigation.Source: §2 · p. 2

Network Simulators

• NS-3 is selected for its broad technology and protocol support, channel and mobility models, detailed physical-layer modeling, and ability to interface with external systems.The section contrasts it with commercial OPNET and open-source OMNET++ [27].Source: §2 · p. 2

Joint UAV/Network Simulators

• AVENS exchanges UAV and network data through XML that updates only UAV number and position, leaving data paths and synchronization insufficient for real-time services.Its use of non-open-source X-Plane also presents a challenge for academic research.Source: §2 · p. 2
• CUSCUS uses tap bridges and containers, but limited interface support excludes LTE and D2D, while its separated control loop prevents assessing network effects on UAV operations.Container overhead can also threaten synchronization when network-event processing lags the UAV simulator clock.Source: §2 · p. 2

• Virtual machines incur resource and synchronization costs, while containers retain synchronization challenges and restrict supported NS-3 technologies and on-board simulation.The paper selects multithreading instead.Source: §3 · p. 3
• Multithreading assigns each UAV simulator module its own thread, supporting scalability, synchronization with the network simulator, and on-board simulation.It also allows a corresponding NS-3 node for each UAV and the GCS, with multiple network interfaces per UAV.Source: §3 · p. 3
• ZMQ publish-subscribe messaging provides asynchronous connections for individual data streams between UAV simulation modules.Its many-to-many communication supports sensor- and control-specific streams, while packet interleaving may increase delay.Source: §3 · p. 3
• Under 10 milliseconds: single and parallel ZMQ publisher-subscriber strategies both keep end-to-end packet delay below this level for 100 streams of 1,000 bytes.The authors use one publisher-subscriber pair per communication direction to support hundreds of concurrent data streams with lower implementation complexity.Source: §3 · p. 3, Figure 1 · p. 3

4 ARCHITECTURE

• The architecture connects FlySim, NetSim, Autogen, and ZMQ middleware, with one-to-one UAV-to-network-node mapping and configurable multi-interface communications.FlySim hosts UAVs and the GCS; NetSim models the network; Autogen produces configuration input; middleware carries bidirectional data streams and supports synchronization.Source: §4 · p. 4

4.1 Synchronization

• Timestamping and delaying packets when needed align network events with UAV operations; when NS-3 falls behind real time, FlyNetSim proposes freezing and recreating the UAV simulation at the correct time.NS-3's real-time scheduler can run late in dense simulations; the paper identifies best-effort synchronization or discarding late events as alternatives.Source: §4.1 · pp. 4–5

4.2 Mobility

• FlyNetSim updates each NS-3 UAV node's position, speed, and direction by intercepting telemetry variables when they are created, while non-UAV nodes can use standard mobility models.This avoids waiting for telemetry packets to arrive over the network before updating the network counterpart.Source: §4.2 · p. 5

4.3 Implementation

• The implementation uses C/C++ and Python, with ZMQ libraries connecting ArduPilot-based UAV threads to NS-3 listening threads.Dronekit operates UAVs using MAVLink; the custom GCS has a Python GUI and receives telemetry using MAVLink.Source: §4.3 · p. 5

5.1 Case Study I: Single UAV over WiFi

• With 5 and 10 contending WiFi nodes, average control-packet delay reaches approximately 4.20 ms and 7.06 ms, respectively.Delay varies over time, with variance increasing as contention grows; the study notes this may create undesirable jitter.Source: §5.1 · p. 5, Figure 5 · p. 6
• As the UAV moves, its simulated position corresponds to received signal strength, supporting development and testing of physical- and link-layer protocols.The study traces random UAV movement and the corresponding RSS decrease from the access point.Source: §5.1 · p. 6, Figure 7 · p. 6

5.2 Case Study II: Multi-Network Environment

• Control messages over WiFi average approximately 0.24 ms delay, while telemetry over LTE averages approximately 15 ms.The scenario assigns control traffic to WiFi and telemetry and high-volume sensor traffic to LTE.Source: §5.2 · pp. 6–7, Figure 8 · p. 7

5.3 Case Study III: Multi-UAV

• On the tested laptop, FlyNetSim instantiated up to 70 UAVs over WiFi and 40 over LTE, whose limit reflects an NS-3 transmission-periodicity constraint.The authors state the architecture itself imposes no UAV-count restriction; system resources constrain scale, and the LTE value could reach 380 based on the standard.Source: §5.3 · p. 7
• FlyNetSim almost halves CPU usage and substantially reduces memory usage compared with CUSCUS.The study measures resource use as a function of instantiated UAV count; the accompanying figure presents percentage resource use against UAV count.Source: §5.3 · p. 7, Figure 9 · p. 7
• In a four-UAV line topology, intra-swarm D2D communications considerably extend coverage as direct-transmission delay increases near the WiFi coverage border.UAVs were spaced 50 m apart, and delay was measured against the access-point distance to the closest UAV.Source: §5.3 · p. 7, Figure 10 · p. 7

5.4 Case Study IV: IoT Applications

• With no contending nodes, packet loss is very unlikely and video arrives with perfect quality; with 10 additional contenders, PSNR degrades by more than 13 dBs, while inter-frame time increases above the expected 0.033 ms as contention grows.Source: §5.4 · p. 8

6 EMULATION MODE

• A real UAV replaces the simulated vehicle, while the GCS, GUI, middleware, and network simulator remain in use.The demonstrated 3DR Solo connects to the laptop running FlyNetSim via USB serial.Source: §6 · p. 8
• Telemetry such as battery status and GPS location appears in the GUI, while the network panel logs packet flow from UAV to GCS.The indoor demonstration had no GPS signal, so latitude and longitude were zero.Source: §6 · p. 8
• The authors describe onboard simulation during flight as a possible configuration using a compact platform such as Raspberry Pi.The demonstrated configuration used a laptop.Source: §6 · p. 8

7 CONCLUSIONS

• FlyNetSim is an open-source integrated UAV-network simulator designed to support varied network scenarios and use cases while modeling UAV operations.Its architecture uses lightweight custom middleware for a closed-loop system.Source: §7 · p. 8
• The simulator provides synchronized end-to-end data paths and considerably reduces system resource use compared with other available integrated simulators.The conclusion also identifies emulation as a way to conduct experimental research using real UAVs and sensor devices over simulated complex environments.Source: §7 · p. 9
• Demonstrated scenarios include multi-technology networking, intra-swarm D2D communications, and IoT data streaming.Source: §7 · p. 9