Read this in other language: 中文
This Python-based simulation platform provides a realistic and comprehensive modeling of various components in UAV networks, including the network layer, MAC layer, physical layer, as well as UAV mobility and energy models. Moreover, the platform is highly extensible, allowing users to customize and develop their own protocols to suit diverse application requirements.
This repository corresponds to our following paper. In addition, we have also updated many new modules and baselines at present.
UavNetSim-v1: A Python-based Simulation Platform for UAV Communication Networks
Zihao Zhou1, Zipeng Dai2, Linyi Huang3, Cui Yang1, Youjun Xiang1, Jie Tang1 and Kai-kit Wong4,5
1 School of Electronic and Information Engineering, South China University of Technology
2 Department of Computer Science and Technology, Beijing Institute of Technology
3 Thrust of ROAS, The Hong Kong University of Science and Technology (Guangzhou)
4 Department of Electrical and Electronic Engineering, University College London
5 Yonsei Frontier Lab, Yonsei University
- Python 3.11 or later (Python 3.12 is recommended)
- Git
- Node.js 18 or later and npm, for building the web console
The editable install used below reads pyproject.toml and automatically
installs all core Python dependencies; a separate
pip install -r requirements.txt step is not required. Optional dependency
groups can be installed when needed:
# Deep-reinforcement-learning modules
.\.venv\Scripts\python.exe -m pip install -e ".[drl]"
# Test suite
.\.venv\Scripts\python.exe -m pip install -e ".[test]"Java 17 and OSM2World are optional and are only needed for detailed scene rendering; see OSM2World detailed rendering.
git clone https://github.com/Zihao-Felix-Zhou/UavNetSim-v1.git
cd "your project path"
py -3.12 -m venv .venv
.\.venv\Scripts\python.exe -m pip install --upgrade pip
.\.venv\Scripts\python.exe -m pip install -e .
.\.venv\Scripts\python.exe main.py compile-scene scenarios\default_scene.json --output artifacts\scene
cd frontend
npm ci
npm run build
cd ..
.\.venv\Scripts\python.exe main.py serve --host 127.0.0.1 --port 8000
OSM2World is an optional visual sidecar. It adds detailed building, roof, road and surface appearance to the web console, while the original Sionna scene remains the source of truth for radio propagation, collision geometry and simulation logic. If OSM2World or Java is unavailable, the scene still compiles and the console falls back to the built-in geometry renderer.
- Download the latest build from the official OSM2World page: OSM2World latest build. Choose latest build on the download page. Do not choose old releases and resources for a normal installation. The numbered 0.4.0 release is an older fallback, not the recommended download.
- Windows x64 users need only this one Java package: Eclipse Temurin 17 JRE ZIP. Eclipse Temurin is the Java distribution; JRE is the runtime package. Do not download both JRE and JDK. Choose the Temurin 17 JDK ZIP only if Java development tools are needed or a JRE ZIP is unavailable.
- Extract both ZIP files into this project-local layout:
UavNetSim-master/
└── tools/
├── java/
│ └── jdk-17.../ or jre-17.../
│ └── bin/java.exe
└── osm2world/
├── OSM2World-latest.jar
├── lib/
├── models/
├── resources/
└── textures/
The extracted directory and JAR names may vary. The application searches
tools/java and recursively searches tools/osm2world for an OSM2World JAR.
These external runtime files are ignored by Git and must be installed locally
after cloning; do not commit them.
Verify the installation from the project root:
tools/osm2world/run-osm2world.cmd --helpYou can also set OSM2WORLD_JAR or pass --osm2world-jar. To keep the
enriched OSM file but disable the optional renderer, use --no-osm2world:
.venv/Scripts/python.exe main.py compile-scene scenarios/default_scene.json --output artifacts/scene
.venv/Scripts/python.exe main.py compile-scene scenarios/default_scene.json --output artifacts/scene --no-osm2worldThe normal first-start sequence is:
cd frontend
npm ci
npm run build
cd ..
.venv/Scripts/python.exe main.py compile-scene scenarios/default_scene.json --output artifacts/scene
.venv/Scripts/python.exe main.py serve --host 127.0.0.1 --port 8000| Layer | Currently implemented protocols, algorithms or models |
|---|---|
| Application layer | Uniform distribution for data packet arrival Poisson distribution for data packet arrival |
| Transport layer | Automatic repeat request (ARQ) |
| Network layer | Routing protocols:
|
| Topology control layer | Random mobility models: Topology control algorithms: Path planning and obstacle avoidance algorithms:
|
| Medium access control layer | |
| Physical layer | The characteristics in physical layer that taken into account:
|
The following figure shows the main procedure of packet transmissions in UavNetSim. "Drone's buffer" is a resource in SimPy whose capacity is one, which means that the drone can send at most one packet at a time. If there are many packets that need to be transmitted, they need to queue for buffer resources according to the time order of arrival to the drone. We can simulate the queuing delay by this mechanism. Besides, we note that there are two other containers: transmitting_queue and waiting_list, for all the "data packets" and "control packets" generated by the drone itself or received from other drones but need to be further forwarded, the drone will first put them into the transmitting_queue. A function called feed_packet will periodically read the packet at the head of the transmitting_queue every very short time, and let it wait for the buffer resource. It should be noted that the "ACK packet" waits for the buffer resource directly without being put into the transmitting_queue.
After the packet is read, a packet type determination will be performed first. If this packet is a control packet (usually no need to decide the next hop), then it will directly start to wait for the buffer resource. When this packet is a data packet, next hop selection will be executed by the routing protocol, if an appropriate next hop can be found, then this data packet can start waiting for buffer resource, otherwise, this data packet will be put into waiting_list. Once the drone has the relevant routing information, it will take this data packet from "waiting_list" and add it back to transmitting_queue.
When the packet gets the buffer resource, MAC protocol will be performed to contend (or schedule) for the wireless channel. When the packet is successfully received by other drone, packet type determination also needs to be performed. For example, if the received packet is a data packet, an ACK packet is needed to reply after an SIFS time. In addition, if the receiver is the destination of the incoming data packet, some metrics will be recorded (PDR, end-to-end delay, etc.), otherwise, it means that this data packet needs to be further relayed so it will be put into the transmitting_queue of the receiver drone.
Packet routing plays an important role in UAV networks, which enables cooperation among different UAV nodes. In this project, Greedy routing, Gradient routing (GRAd), Destination-Sequenced Distance Vector routing (DSDV), and some RL-based routing protocols have been implemented. The following figure illustrates the basic procedure of packet routing. More detailed information can be found in the corresponding papers [1]-[5].
In this project, basic Carrier-sense multiple access with collision avoidance (CSMA/CA), Pure aloha, and Time-division multiple access (TDMA) have been implemented. We would like to thank @hkphimanshukumar321 for contributing to this TDMA module! I will give a brief overview of the version implemented in this project, and focus on how signal interference and collision are implemented in this project. The following picture shows an example of packet transmission when the basic CSMA/CA (without RTS/CTS) protocol is adopted. When a drone wants to transmit a packet:
- it first needs to wait until the channel is idle
- when the channel is idle, the drone starts a timer and waits for
DIFS+backoffperiods of time, where the length of backoff is related to the number of re-transmissions - if the entire decrement of the timer to 0 is not interrupted, then the drone can occupy the channel and start sending the packet
- if the countdown is interrupted, it means that the drone loses the game. The drone then freezes the timer and waits for the channel to be idle again before re-starting its timer
The following figure demonstrates the packet transmission flow when pure aloha is adopted. When a drone installed a pure aloha protocol wants to transmit a packet:
- it just sends it, without listening to the channel and random backoff
- after sending the packet, the node starts to wait for the ACK packet
- if it receives ACK in time, the
mac_sendprocess will finish - if not, the node will wait a random amount of time, according to the number of re-transmission attempts, and then send the packet again
From the above illustration, we can see that, it is not only two drones sending packets simultaneously that cause packet collisions. If there is an overlap in the transmission time of two data packets, it also indicates that a collision occurs. So in our project, each drone checks its inbox every very short interval and has several important things to do (as shown in the following figure):
- delete the packet records in its inbox whose distance from the current time is greater than twice the maximum packet transmission delay. This reduces computational overhead because these packets are guaranteed to have already been processed and will not interfere with packets that have not yet been processed
- check the packet records in the inbox to see which packet has been transmitted in its entirety
- if there is such a record, then find other packets that overlap with this packet in transmission time in the inbox records of all drones, and use them to calculate SINR.
The mobility model is one of the most important mudules to show the characteristics of a UAV network more realistically. In this project, Gauss-Markov 3D mobility model, Random Walk 3D mobility model, and Random Waypoint 3D mobility model have been implemented. Specifically, since it is quite difficult to achieve continuous movement of drones in discrete time simulation, we set a position_update_interval to update the positions of drones periodically, that is, it is assumed that the drone moves continuously within this time interval. If the time interval position_update_interval is smaller, the simulation accuracy will be higher, but the corresponding simulation time will be longer. Thus, there will be a trade-off. The trajectories of a single drone within 100 seconds of the simulation under the three mobility models are shown as follows:
Our UavNetSim-v1 platform now supports the design and test of the 3-D path planning algorithms for drone. The baseline we have implemented so far is the A* algorithm, subsequently, we will continue to expand the baselines, such as Dijkstra, DFS, BFS, DRL-based path planning, etc.
The energy model of our platform is based on the work of Y. Zeng, et al [8]. The figure below shows the power required for different drone flying speeds. The energy consumption is equal to the power multiplied by the flight time at this speed.
This platform also supports user to design motion control algorithms for UAV swarm network. In the current version, a virtual force based motion control algorithm[9] is implemented, which incorporates the attractive force from the central point of the region and the repulsive force from neighbor drones. By applying this algorithm, an initial and possibly disconnected network can be self organized into a bi-connected network. The figure above demonstrates the changes of the network topology after motion control.
How to use? In entities/drone.py, replace the mobility_model with motion_controller:
from topology.virtual_force.vf_motion_control import VfMotionController
class Drone:
def __init__(self, env, node_id, coords, speed, inbox, simulator):
...
# self.mobility_model = GaussMarkov3D(self) REMEMBER TO COMMENT THIS SENTENCE OUT!
self.motion_controller = VfMotionController(self)
...Our "UavNetSim-v1" platform supports the evaluation of several performance metrics, as follows:
- Packet Delivery Ratio (PDR): PDR is the ratio of the total number of received data packets successfully at all destination drones over the total number of data packets generated by all source drones. It should be noted that PDR excludes redundant data packets. PDR can reflect the reliability of the routing protocol.
- Average End-to-End Delay (E2E Delay): E2E delay is the average time delay for data packets to reach from the source drone to the destination drone. Typically, delay in packet transmission involves "queuing delay", "access delay", "transmission delay", "propagation delay (So small as to be negligible)" and "processing delay".
- Normalized Routing Load (NRL): NRL is the ratio of all routing control packets sent by all drones to the number of received data packets at the destination drones.
- Average Throughput: In our platform, the calculation of throughput is: whenever the destination receives a packet, the length of the packet is divided by the end-to-end delay of the packet (because E2E delay involves the re-transmissions of this data packet)
- Hop Count: Hop count is the number of router output ports through which the packet should pass.
Our simulation platform can be expanded based on your research needs, including designing your own mobility model of drones (in mobility folder), mac protocol (in macfolder), routing protocol (in routingfolder), and so on. Next, we take routing protocols as an example to introduce how users can design their own algorithms.
- Create a new package under the
routingfolder (Don't forget to add__init__.py) - The main program of the routing protocol must contain the function:
def next_hop_selection(self, packet)anddef packet_reception(self, packet, src_drone_id) - After confirming that the code logic is correct, you can import the module you designed in
drone.pyand install the routing module on the drone:from routing.dsdv.dsdv import Dsdv # import your module ... class Drone: def __init__(self, env, node_id, coords, speed, inbox, simulator): ... self.routing_protocol = Dsdv(self.simulator, self) # install ...
[1] C. Perkins and P. Bhagwat, "Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers," in ACM SIGCOMM Computer Communication Review, vol. 24, no. 4, pp. 234-244, 1994.
[2] R. Poor, "Gradient routing in ad hoc networks", 2000, www.media.mit.edu/pia/Research/ESP/texts/poorieeepaper.pdf
[3] J. Boyan and M. Littman, "Packet routing in dynamically changing networks: A reinforcement learning approach" in Advances in Neural Information Processing Systems, vol. 6, 1993.
[4] W. S. Jung, J. Yim and Y. B. Ko, "QGeo: Q-learning-based geographic ad hoc routing protocol for unmanned robotic networks," in IEEE Communications Letters, vol. 21, no. 10, pp. 2258-2261, 2017.
[5] M. Gharib, F. Afghah and E. Bentley, "Opar: Optimized predictive and adaptive routing for cooperative uav networks," in IEEE INFOCOM 2021-IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp. 1-6, 2021.
[6] A. Colvin, "CSMA with collision avoidance," Computer Communications, vol. 6, no. 5, pp. 227-235, 1983.
[7] N. Abramson, "The ALOHA system: Another alternative for computer communications," in Proceedings of the November 17-19, 1970, Fall Joint Computer Conference, pp. 281-285, 1970.
[8] Y. Zeng, J. Xu and R. Zhang, "Energy minimization for wireless communication with rotary-wing UAV," in IEEE transactions on wireless communications, vol. 18, no. 4, pp. 2329-2345, 2019.
[9] H. Liu, X. Chu, Y. -W. Leung and R. Du, "Simple movement control algorithm for bi-connectivity in robotic sensor networks," in IEEE Journal on Selected Areas in Communications, vol. 28, no. 7, pp. 994-1005, 2010.
Contributions are warmly welcome! Thank @superboySB (Dr. Zipeng Dai), @ddherm (Mr. Kai Fang) for their contributions!
If you find our paper useful, please kindly cite us via:
@inproceedings{zhou2025uavnetsim,
title={UavNetSim-v1: A Python-based Simulation Platform for UAV Communication Networks},
author={Zhou, Zihao and Dai, Zipeng and Huang, Linyi and Yang, Cui and Xiang, Youjun and Tang, Jie and Wong, Kai-kit},
booktitle={14-th IEEE/CIC International Conference on Communications in China},
address = {Shanghai, China},
month = {August},
year = {2025}
}
or
@article{zhou2025uavnetsim,
title={UavNetSim-v1: A Python-based Simulation Platform for UAV Communication Networks},
author={Zhou, Zihao and Dai, Zipeng and Huang, Linyi and Yang, Cui and Xiang, Youjun and Tang, Jie and Wong, Kai-kit},
journal={arXiv preprint arXiv:2507.09852},
year={2025}
}
Give a ⭐ if this project helped you!
This project is MIT-licensed.