Unmanned aerial vehicle network simulation plug-in
By utilizing the link state broadcasting, route calculation, and fault injection modules of the UAV network simulation plugin, the problem of performance evaluation distortion in multi-hop links of existing platforms is solved, enabling high-fidelity dynamic modeling of UAV networks and simulation of complex scenarios, thereby improving task robustness and simulation realism.
Patent Information
- Application Number
- CN202511881650.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-12
- Publication Date
- 2026-03-20
Smart Images

Figure CN121711264A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of UAV network simulation technology, and in particular, a UAV network simulation plugin. Background Technology
[0002] As a critical infrastructure supporting tasks such as swarm collaboration, wide-area reconnaissance, and emergency communication, the network performance of UAV ad hoc networks directly affects the reliability and real-time performance of high-level missions. To verify the robustness of UAV formation control, path planning, and electronic countermeasures algorithms in complex communication environments before actual deployment, a simulation tool capable of realistically simulating the end-to-end business data transmission process in multi-hop links is urgently needed.
[0003] However, current mainstream UAV network simulation platforms (such as UavNetSim-v1 based on NS-3 or FANET Simulator based on OMNeT++) mainly focus on comparing and verifying network protocol layer performance metrics (such as throughput, routing overhead, and packet delivery rate), which has significant limitations. For example, existing tools are designed to compare different routing protocols (such as AODV, OLSR, and DSDV), so their core outputs are aggregated statistics such as throughput, routing overhead, and average end-to-end delay (E2E Delay). These metrics are usually obtained through idealized assumptions—for example, assuming that once a route is established, packets are forwarded without errors along a fixed path; or applying a fixed packet loss rate independently to each hop, but without accumulating the multi-hop joint packet loss probability. More importantly, the transmission behavior of service packets is completely decoupled from routing table updates: even if the network topology is reconstructed due to node failure, the service flow on the old path is still processed according to the original rules until a new packet is sent. If this problem is not resolved in time, it will lead to serious distortion in the performance evaluation of mission-critical services (such as formation control commands and target coordinate synchronization). Summary of the Invention
[0004] The purpose of this invention is to provide a UAV network simulation plugin to solve the problems mentioned in the background art.
[0005] To achieve the above objectives, the present invention provides the following technical solution: a UAV network simulation plugin, wherein the plugin is embedded in an external UAV simulation platform as a dynamic library or service, for simulating the end-to-end transmission process of business data between multiple UAV nodes, the plugin comprising: The link status broadcast module is configured to enable each UAV node to periodically broadcast link status information, which includes at least node identifier, geographic location coordinates, reference delay, packet loss rate, and bandwidth. The routing calculation module is configured to calculate the edge weight of the link between any two nodes based on the received link state information using a composite link cost function, and to generate a single-source routing table for each node using Dijkstra's algorithm; wherein, the composite link cost function is defined as: ; in, Let be the Euclidean distance between nodes a and b. The maximum propagation delay of link ab Let g(d) be the packet loss rate of link ab, and g(d) be the distance soft threshold function, defined as: ; The distance threshold is determined by solving the following equation: ; in and They are respectively at the distance The empirical nominal delay and nominal packet loss rate are as follows; the coefficient α is adaptively calculated using the following formula: ; β and γ are configurable weight parameters, and HOP_COST is the additional cost per hop; The business data simulation module is configured to, upon receiving a business data packet, reconstruct the complete propagation path from the source node to the destination node based on the routing table, and calculate end-to-end performance metrics as follows: Total delay , End-to-end packet loss rate , Based on this, the service data packets are subject to delayed scheduling or discarding operations; The fault injection interface is configured to receive external commands and dynamically set latency increments, packet loss rate increases, bandwidth limits, or disconnection flags for any node. The general interface module provides a protocol-independent abstract communication interface and binds specific communication adapters through a dependency injection mechanism to support data interaction with external UAV simulation platforms.
[0006] In this preferred embodiment, the geographic coordinates in the link state information are provided by an external node simulator, which is a UAV dynamics simulation engine. By using an external UAV dynamics simulation engine to provide the geographic coordinates in the link state information, the construction of the network topology directly depends on the actual flight trajectory and three-dimensional spatial position, achieving strong coupling modeling of communication link state and flight dynamics. Compared with existing network simulation tools that typically assume nodes randomly walk in a two-dimensional plane or use static topology, this achieves a high-fidelity reproduction of the time-varying characteristics of links in highly dynamic, three-dimensional airspace environments (such as signal attenuation caused by sudden distance changes), significantly improving the accuracy of communication performance evaluation in mission scenarios such as formation flying and evasive maneuvers.
[0007] In this preferred embodiment, the general interface module supports at least one of the communication protocols including DDS, ROS2, Redis, ZeroMQ, UDP, or TCP. External platforms access this plugin by implementing the corresponding communication adapter. This allows the simulation plugin to adapt to simulation platforms (principles) of different manufacturers or research institutions without modifying the core logic, achieving a plug-in integration capability of "develop once, deploy on multiple platforms." Compared with existing simulation systems (such as UavNetSim based on NS-3), which are deeply bound to specific communication stacks and difficult to embed into actual flight control or mission simulation environments, this solution achieves extremely high engineering compatibility and ecological scalability, providing a standardized interface foundation for cross-team collaborative development and heterogeneous system integration testing.
[0008] In this preferred embodiment, the service data simulation module automatically recalculates the total latency and end-to-end packet loss rate under the new path after the routing table is updated, and applies this recalculation to the processing of subsequent service data packets. This allows changes in network status (such as node failure or link degradation) to be reflected in the transmission behavior of the service flow in real time, achieving a closed-loop linkage between service layer simulation and network layer dynamics. Compared with the "lagging simulation" mode in existing tools where routing updates and data forwarding are disconnected and service packets are still processed along the old path, this solution achieves real-time capture capability of the risk of task continuity interruption under network disturbances, providing key support for the robustness verification of high-time-sensitive tasks (such as coordinated attacks and emergency responses).
[0009] In this preferred embodiment, the fault injection interface supports hot updates and allows for control via bitmask to enable any combination of delay simulation, packet loss simulation, bandwidth limiting, or link disconnection functions. This enables users to dynamically enable / disable specific fault types as needed during simulation, achieving refined simulation of complex electronic warfare scenarios (such as intermittent jamming, bandwidth suppression, and selective packet loss). Compared to existing platforms that only support global or static fault configuration and cannot simulate tactical-level jamming strategies, this solution achieves a high degree of freedom and high realism in network attack and defense simulation for practical training, greatly enhancing the breadth and depth of algorithm resilience testing.
[0010] In this preferred embodiment, the bandwidth limitation is implemented through a sliding window mechanism: when the amount of data received per unit time exceeds the configured bandwidth, the excess portion enters the FIFO queue, and when the queue is full, the oldest data packet is discarded.
[0011] In this preferred embodiment, the routing calculation module operates periodically. When a link status change or fault injection event is detected, routing reconvergence is triggered, and the updated routing table is sent to the ground station for visualization through the general interface module.
[0012] In this preferred embodiment, the value of HOP_COST satisfies: ; To suppress the generation of meaningless multi-hop paths.
[0013] In this preferred embodiment, the plugin is deployed in a large-scale simulation scenario containing 20 to 200 drone nodes, and can complete the route re-convergence caused by node failure within 3 seconds, and significantly reduce end-to-end communication latency and packet loss rate.
[0014] In this preferred embodiment, the plug-in simultaneously connects to two UAV simulation platforms using different communication protocols to achieve cross-platform joint simulation, which is used for testing and verification of vehicle-machine collaboration or integrated space-ground communication scenarios.
[0015] Compared with the prior art, the technical effects and advantages of the present invention are as follows: This UAV network simulation plugin, through its link state broadcast module, periodically collects multi-dimensional link state information including geographical location, baseline latency, packet loss rate, and bandwidth. This design enables the system to perceive real-time changes in the spatial topology driven by an external UAV dynamics simulation engine, achieving joint modeling of physical layer communication capabilities and network layer states. Compared with existing simulation tools that are based solely on static topology or idealized link models, this plugin achieves a dynamic network environment construction effect that is closer to real flight scenarios.
[0016] The routing calculation module employs a fusion distance soft threshold function g(d), an adaptive normalization coefficient α, and configurable weights. The design incorporates a composite link cost function with a per-hop penalty term (HOP_COST) and combines it with Dijkstra's algorithm to generate a single-source routing table. This allows path selection to consider not only geometric distance but also dynamic adjustment of routing strategies based on performance dimensions of interest to users (such as low latency or high reliability). Specifically, thresholds are determined by solving empirical equations. and set It effectively suppresses the generation of ultra-long-distance direct connections and meaningless multi-hops, and realizes the intelligent routing function of "selecting the path with the best overall performance under a reasonable number of hops". Compared with the existing routing mechanism that only uses the number of hops or a single indicator (such as RSSI) as the cost, it achieves a path planning effect that is more in line with actual business needs.
[0017] The business data simulation module reconstructs the complete propagation path based on the routing table, strictly following the formula. and The design of accumulating end-to-end latency and packet loss rate, and then performing precise latency scheduling or packet loss judgment, makes the transmission process of business layer data (such as formation instructions and target coordinates) realistically reproduced. It realizes accurate modeling of performance degradation in multi-hop links, avoids the end-to-end performance misjudgment caused by "single-hop independent modeling" in traditional simulation, and achieves effective evaluation of the robustness of high-level algorithms and task completion quality compared with existing tools that focus on protocol layer throughput / overhead. Attached Figure Description
[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0019] Figure 1 This is a schematic diagram of the UAV network simulation system architecture of the present invention; Figure 2 This is a timing flowchart of the link status and service access of the present invention; Figure 3 This is a schematic diagram of the protocol-independent universal interface adapter structure of the present invention; Figure 4 This is a flowchart of the business processing module of the present invention. Detailed Implementation
[0020] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.
[0021] Unless otherwise defined, the directions mentioned herein, such as up, down, left, right, front, back, inside, and outside, are based on the directions shown in the figures of this invention, and are explained here together.
[0022] The present invention is as follows Figure 1 -Appendix Figure 4 The present invention provides a UAV network simulation plugin. This plugin is embedded into an external UAV simulation platform (such as RflysimCloud, Gazebo+PX4, etc.) in the form of a dynamic link library (.so / .dll) or a standalone service process. It is used to simulate the end-to-end transmission process of business data (such as location information, mission instructions, sensor data) between multiple UAV nodes.
[0023] like Figure 1 As shown, the plugin includes the following five core functional modules: link status broadcast module, route calculation module, service data simulation module, fault injection interface, and general interface module. The modules work together to achieve full-chain simulation capabilities from physical topology perception, intelligent path planning, service flow performance modeling to complex communication environment simulation.
[0024] In this embodiment, the link status broadcast module: each UAV node is driven by an external node simulator (i.e., a UAV dynamics simulation engine, such as AirSim, Flightmare, or the built-in flight control model of RflysimCloud), which periodically (by default every 1 second) calls the link status reporting interface of this plugin.
[0025] The broadcast link state information includes at least: (1) Node unique identifier (Node ID); (2) Geographic coordinates (x, y, z) (unit: meters) are provided in real time by the external node simulator; (3) Base Latency (unit: ms); (4) Packet loss rate p (value range [0,1]); (5) Available bandwidth (Bandwidth, unit: bps).
[0026] This information is sent to other nodes in the network through a general interface module. Each node stores the received link status locally to build a network topology view.
[0027] In this embodiment, the routing calculation module: Based on the stored link state information, this module independently runs Dijkstra's single-source shortest path algorithm for each node to generate a routing table from it to other nodes in the entire network. A composite link cost function is used to calculate the edge weight of the link between any two nodes a and b: ; in: Let be the Euclidean distance between nodes a and b; =max(reference delay of node a, reference delay of node b); The link packet loss rate (take the maximum or negotiated value of the packet loss rates at both ends of the link). g(d) is the distance soft threshold function, defined as: ; Distance threshold It is not a preset constant, but is dynamically determined based on user experience curves, satisfying the following equation: ; in: In distance The empirical nominal delay (e.g., obtained through actual measurement or manufacturer's manual); In distance The empirically defined packet loss rate.
[0028] The coefficient α is used for dimensional normalization and is calculated adaptively according to the following formula: ; The weight parameters β (delay weight) and γ (packet loss weight) can be dynamically adjusted by the user configuration file to adapt to different simulation objectives (such as low latency priority or high reliability priority).
[0029] The additional cost per hop, HOP_COST, is used to suppress meaningless multiple hops, and its value satisfies the following: ; The routing calculation module runs periodically (every 2 seconds by default) and immediately triggers route reconvergence upon detecting link state changes or fault injection events. The updated routing table is pushed to the ground station via the general interface module for topology visualization; the packet loss rate is then used to... The design incorporates the cost function of the composite link, allowing the end-to-end packet loss probability of multi-hop links to be linearly accumulated and modeled during the routing phase. This not only enables proactive avoidance of high-loss paths but also makes Dijkstra's algorithm inherently support "reliable path priority" selection without introducing complex probabilistic graphical models or additional state space expansion. This design maintains the algorithm's lightweight nature while achieving path quality similar to reliable routing based on Markov Decision Processes (MDPs), significantly reducing computational overhead in large-scale simulations. This represents a dual effect from a single mathematical transformation: satisfying the additivity of the cost function while implicitly optimizing the reliability of the service layer. By setting... By incorporating a quadratic penalty term in the distance soft threshold function g(d), the system not only suppresses ultra-long-distance direct connections but also automatically avoids frequent path oscillations caused by minor link fluctuations. For example, when the distance between two nodes is slightly greater than... At that time, the cost of direct connection was due to The cost of the two-hop detour is higher, but the total cost is still lower than that of a direct connection due to the reasonable setting of HOP_COST, thus forming a stable multi-hop path. In Example 5, this mechanism exhibits the "hysteresis characteristic" of path selection, which effectively improves routing stability. This is not simply designed to suppress multi-hops, but rather an unexpected anti-jitter effect triggered by the linkage of HOP_COST and g(d), which is significantly better than traditional routing protocols that rely solely on link quality threshold switching.
[0030] In this embodiment, the business data simulation module performs the following operations when a node receives a business data packet (such as a formation control command) sent by an upper-layer application: Based on the current routing table, query the next hop hop one by one from the source node until the destination node, and reconstruct the complete propagation path. Calculate end-to-end performance metrics along this path: Total delay: ; End-to-end packet loss rate: ; Execute the following on this service package: Delayed scheduling: Add the callback function to a timer to delay the process. Execute after; Packet loss determination: based on probability Perform a Bernoulli test; if the test is successful, discard the item; otherwise, deliver it normally.
[0031] Once the routing table is updated, subsequent service packets will automatically recalculate using the new path. and The business data simulation module automatically recalculates the new path after the routing table is updated. and The design allows service flow performance metrics to reflect the new routing status in real time after fault injection or topology changes, ensuring simulation realism and triggering adaptive adjustment mechanisms in upper-layer algorithms. For example, in formation control scenarios, when a sudden increase in packet loss rate on a critical link leads to... When the data packet is dropped, the control algorithm automatically reduces the control frequency or switches the master-slave relationship because it does not receive feedback. This "network-task" closed-loop response cannot be captured by traditional protocol-level simulation. It reflects the implicit collaborative capability between the network simulation module and the task algorithm and achieves a high-fidelity simulation effect of the behavior of the "network-aware intelligent agent".
[0032] In this embodiment, the fault injection interface provides a RESTful API or a shared memory interface to receive external commands and dynamically set the following fault parameters for any node: Delay increment (e.g., +100 ms); Increased rate of lost packages (e.g., from 1% to 50%); Bandwidth limitations (e.g., reduced to 128 kbps); Disconnected link flag (forces the disconnection of all links to this node).
[0033] All strategies are enabled / disabled via bitmasks and support hot updates (without requiring a simulation restart), for example: bit0: Enable delay simulation; bit1: Enable packet loss simulation; bit2: Enable bandwidth limiting; bit3: Enable the chain break switch.
[0034] The bandwidth limitation employs a sliding window mechanism: the system maintains a time window (e.g., 1 second) to count the number of bytes received. If the configured bandwidth is exceeded, the excess data enters a FIFO queue; when the queue is full, the oldest data packet is discarded. Through a fault injection interface, the system supports dynamic configuration of latency increments, packet loss rate increases, bandwidth limits, or link break markers for any node. Combined with a bitmask for hot updates, this allows users to simulate complex communication anomalies such as electronic warfare interference, equipment aging, or sudden channel deterioration during simulation. This enables stability stress testing of UAV systems under non-ideal network conditions. Compared to existing platforms lacking fine-grained fault simulation capabilities, this achieves a high-order simulation effect for practical training and algorithm resilience verification. The system can naturally reproduce queuing delays and tail packet loss caused by sudden traffic in real networks, achieving micro-modeling of network behaviors such as congestion control and traffic shaping. Compared to existing simulations that simply truncate over-bandwidth data or ignore queuing effects with coarse-grained processing, this achieves verification of the timing characteristics and Quality of Service (QoS) of service flows, making it particularly suitable for application scenarios sensitive to latency jitter, such as video backhaul and telemetry streams.
[0035] In this embodiment, the general interface module defines a protocol-independent abstract communication interface, which includes the following virtual functions: publishLinkState() publishRoutingTable() onBusinessPacketReceived() updateFaultParams() The dependency injection mechanism binds a specific communication adapter during plugin initialization. The following adapters have been implemented: DDSAdapter (based on Fast DDS) RedisAdapter (based on hiredis) ROS2Adapter ZeroMQAdapter UDPAdapter / TCPAdapter External UAV simulation platforms only need to implement the corresponding adapter to seamlessly integrate this plugin, enabling cross-platform data interaction. By providing protocol-independent abstract communication interfaces through a general interface module and binding specific communication adapters such as DDS, ROS2, Redis, ZeroMQ, and UDP / TCP through dependency injection, this plugin can be seamlessly embedded into UAV simulation platforms from different vendors as a dynamic library or service. This achieves "develop once, reuse across multiple platforms" plug-in integration capabilities, significantly improving flexibility and engineering feasibility compared to existing tools tightly coupled to specific simulation frameworks (such as NS-3). The dependency injection design of the general interface module allows data from different protocol stacks to be processed uniformly within the same logical network during cross-platform co-simulation. For example, the link status sent by Redis and the service packets sent by DDS are mapped to the same node ID space, and the routing calculation module processes them indiscriminately, thus unexpectedly realizing the semantic fusion of heterogeneous communication middleware. This not only supports hybrid architecture testing such as vehicle-machine-drone collaboration, but also enables the ground station to display a unified topology view across protocols, achieving a system-level interoperability effect that goes beyond simple "protocol adaptation", providing a scalable foundation for future "multi-domain heterogeneous unmanned system joint simulation".
[0036] Example 1: Fault Injection and Routing Reconvergence Verification in Small-Scale Topology This embodiment is used to verify the responsiveness of the plug-in of the present invention to changes in link state and the effectiveness of the route reconvergence mechanism in a small-scale network.
[0037] Environment configuration: Number of simulation nodes: 20 drones; Communication radius: 1000 m; Baseline latency: 10 ms; Baseline packet loss rate: 1%; Bandwidth: 1 Mbps; Composite cost function parameter settings: β = 1.0, γ = 1.0, =10ms, =0.01; Distance threshold By solving the equation: ; And take HOP_COST = α Solving for ≈950m; α according to formula Automatic calculation.
[0038] Simulation process: Each node is driven by an external dynamics simulation engine (such as RflysimCloud) and periodically (every 1 second) broadcasts its link status. After receiving the broadcasts, this plugin constructs the entire network topology. Each node runs the Dijkstra algorithm to generate a single-source routing table and pushes the routing table to the ground station's visualization interface through a general interface module.
[0039] At the 10th second of the simulation, the packet loss rate of node #5 was increased from 1% to 40% through the fault injection interface, while the other parameters remained unchanged.
[0040] Simulation results: (1) The ground station interface displays the route table update within 2 seconds, and the original path through node #5 is detoured; (2) The end-to-end average delay increased from 32 ms to 40 ms (an increase of approximately 25%). (3) No large-scale loss of business data packets (such as location synchronization messages) occurred, and the system remained connected.
[0041] This embodiment verifies the linkage design between the "fault injection interface" and the "routing calculation module", as well as the "routing reconvergence and ground station display" function.
[0042] Example 2: Robustness Test of Medium-Sized Formation Control Algorithm This embodiment is used to verify the plugin's ability to support UAV high-level mission algorithms (such as formation control) under communication disturbances.
[0043] Environment configuration: Number of nodes: 50; Communication radius: 800 m; Baseline latency: 15 ms; Baseline packet loss rate: 1%; Formation control algorithm: a position coordination algorithm based on a consensus protocol; Fault injection strategy: Randomly select 5 nodes (accounting for 10%), set their packet loss rate to 5%, and continue this process throughout the simulation.
[0044] Simulation process: The drones fly along a preset formation trajectory, exchanging position information as service data packets every 100 ms. This plugin calculates the routing table for each service flow. and And accordingly, schedule or discard data packets.
[0045] Simulation results: (1) Some drones experienced brief jitters due to the loss of their location packets, but the overall formation did not collapse; (2) Ground station records show that the affected links automatically switched to low packet loss paths, reflecting the guiding role of the γ weight in the composite cost function on reliability; (3) The system runs stably for more than 10 minutes without communication interruption.
[0046] This embodiment supports the practicality of the "business data simulation module" and demonstrates the value of "automatic recalculation of performance indicators after route update" for algorithm robustness testing.
[0047] Example 3: Simulation of Large-Scale Electronic Countermeasures Jamming Scenarios This embodiment simulates the impact of regional communication interference on unmanned aerial vehicle (UAV) networks in a battlefield environment.
[0048] Environment configuration: Number of nodes: 200; Coverage area: 20 km × 20 km; Baseline delay: 20 ms; Baseline packet loss rate: 0.5%; Interference area: Within a 5 km × 5 km central area, 30% of the nodes (60 in total) are injected with faults. The latency increased by 100 ms (total latency ≈ 120 ms); Packet loss rate increased to 50%; Bandwidth is limited to 128 kbps (with sliding window + FIFO mechanism enabled).
[0049] Simulation process: The system initially completes network-wide route convergence. Starting from the 30th second, interference is activated, the plugin updates link status in real time, and triggers a network-wide route recalculation.
[0050] Simulation results: (1) The communication success rate between the interfered area and the peripheral nodes decreased by 60%; (2) The routing table is updated frequently (on average every 5 seconds), and the ground station dynamically displays topology breaks and reconstructions; (3) Significant delays and loss of business data (such as target coordinates) are consistent with the characteristics of real electronic warfare.
[0051] This embodiment verifies the technical feasibility of (fault hot update), (bandwidth limitation), and (large-scale reconvergence performance).
[0052] Example 4: Cross-protocol platform co-simulation integration This embodiment verifies the ability of the plugin's general interface module to support heterogeneous simulation platforms.
[0053] Environment configuration: Platform A: RflysimCloud, which uses Redis as its internal communication middleware; Platform B: Self-developed flight control simulator, using DDS (Data Distribution Service); This plugin implements two communication adapters, RedisAdapter and DDSAdapter. Each platform deploys 10 nodes, forming a 20-node hybrid network.
[0054] Simulation process: The plugins are embedded as .so dynamic libraries on both platforms. Through dependency injection, they are bound to either RedisAdapter or DDSAdapter during initialization. Nodes can exchange link status and business data across platforms.
[0055] Simulation results: (1) All nodes successfully constructed a unified topology, and the routing tables were consistent; (2) After the same fault (such as a delay of +50 ms) is injected, the service packages of both platforms are processed according to the same rules; (3) The joint simulation runs stably without protocol compatibility issues.
[0056] This embodiment directly demonstrates the feasibility of "protocol-independent interface" and "cross-platform co-simulation".
[0057] Example 5: Verification of multi-hop optimization capability in cross-regional collaborative tasks This embodiment focuses on verifying the composite cost function. The effect of HOP_COST on multi-hop path selection.
[0058] Environment configuration: Number of nodes: 80, distributed across 4 sub-regions 2-3 km apart; Communication radius: 1.5 km (full connectivity within the region, multiple hops required for cross-regional communication); Baseline latency: 20 ms; Baseline packet loss rate: 2%; Bandwidth: 1 Mbps; Parameter settings: =20ms, =0.02; Solving the equation yields ≈1400m; set up (Strictly suppress multiple jumps).
[0059] Simulation process: The drones are performing cross-regional reconnaissance and collaborative missions, frequently exchanging mission commands. Starting at the 20th second, all nodes in region C are injected with the following: latency +100 ms, packet loss rate +15%. Simulation results: (1) Initial cross-regional communication path: The end-to-end latency is 220 ms, and the packet loss rate is 18%. (2) Within 3 seconds after fault injection, the route reconverges. (Detour through high-interference areas); (3) The latency of the new path was reduced to 140 ms, and the packet loss rate was reduced to 7%; (4) The ground station clearly displays the path switching process and performance improvements.
[0060] This embodiment verifies the engineering value of the composite cost function and the role of (HOP_COST ≥ α·D0) in ensuring the rationality of the path, while also supporting large-scale dynamic performance indicators.
[0061] It should be noted that, in this document, relational terms such as "one" and "two" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, the phrase "comprising an element defined as..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0062] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A UAV network simulation plugin, characterized in that, The plugin is embedded in an external UAV simulation platform as a dynamic library or service to simulate the end-to-end transmission process of business data between multiple UAV nodes. The plugin includes: The link status broadcast module is configured to enable each UAV node to periodically broadcast link status information, which includes at least node identifier, geographic location coordinates, reference delay, packet loss rate, and bandwidth. The routing calculation module is configured to calculate the edge weight of the link between any two nodes based on the received link state information using a composite link cost function, and to generate a single-source routing table for each node using Dijkstra's algorithm; wherein, the composite link cost function is defined as: ; in, Let be the Euclidean distance between nodes a and b. The maximum propagation delay of link ab Let g(d) be the packet loss rate of link ab, and g(d) be the distance soft threshold function, defined as: ; The distance threshold is determined by solving the following equation: ; in and They are respectively at the distance The empirical nominal delay and nominal packet loss rate are as follows; the coefficient α is adaptively calculated using the following formula: ; β and γ are configurable weight parameters, and HOP_COST is the additional cost per hop; The business data simulation module is configured to, upon receiving a business data packet, reconstruct the complete propagation path from the source node to the destination node based on the routing table, and calculate end-to-end performance metrics as follows: Total delay , End-to-end packet loss rate , Based on this, the service data packets are subject to delayed scheduling or discarding operations; The fault injection interface is configured to receive external commands and dynamically set latency increments, packet loss rate increases, bandwidth limits, or disconnection flags for any node. The general interface module provides a protocol-independent abstract communication interface and binds specific communication adapters through a dependency injection mechanism to support data interaction with external UAV simulation platforms.
2. The UAV network simulation plugin according to claim 1, characterized in that: The geographic location coordinates in the link status information are provided by an external node simulator, which is a UAV dynamics simulation engine.
3. The UAV network simulation plugin according to claim 1, characterized in that: The general interface module supports at least one of the following communication protocols: DDS, ROS2, Redis, ZeroMQ, UDP, or TCP. External platforms can access this plugin by implementing the corresponding communication adapter.
4. The UAV network simulation plugin according to claim 1, characterized in that: The service data simulation module automatically recalculates the total latency and end-to-end packet loss rate under the new path after the routing table is updated, and applies this recalculation to the processing of subsequent service data packets.
5. The UAV network simulation plugin according to claim 1, characterized in that: The fault injection interface supports hot updates and controls whether to enable any combination of latency simulation, packet loss simulation, bandwidth limiting, or link failure functions via a bitmask.
6. The UAV network simulation plugin according to claim 1, characterized in that: The bandwidth limitation is implemented through a sliding window mechanism: when the amount of data received per unit time exceeds the configured bandwidth, the excess enters the FIFO queue, and when the queue is full, the oldest data packet is discarded.
7. The UAV network simulation plugin according to claim 1, characterized in that: The routing calculation module runs periodically. When it detects a link status change or a fault injection event, it triggers route reconvergence and sends the updated routing table to the ground station for visualization through the general interface module.
8. The UAV network simulation plugin according to claim 1, characterized in that: The value of HOP_COST satisfies: ; To suppress the generation of meaningless multi-hop paths.
9. The UAV network simulation plugin according to claim 1, characterized in that: The plugin, when deployed in a large-scale simulation scenario containing 20 to 200 drone nodes, can complete route re-convergence caused by node failure within 3 seconds and significantly reduce end-to-end communication latency and packet loss rate.
10. The UAV network simulation plugin according to claim 1, characterized in that: The plugin can simultaneously connect to two drone simulation platforms using different communication protocols to achieve cross-platform joint simulation, which can be used for testing and verification of vehicle-machine collaboration or integrated space-ground communication scenarios.