Adaptive Distributed Network Integration System and Method for Virtual-Real UAV Collaboration

Abstract

This invention discloses an adaptive distributed network integration system and method for virtual-real drone collaboration, relating to the field of drone control technology. It includes a central control plane and at least one node agent. The central control plane comprises: a global identity manager, configured to assign globally unique network identity information and record and reclaim the network identity information; a network topology and state manager, configured to generate virtual-real network state views, respond to queries, and issue network simulation commands to the node agents; a distributed network coordinator, configured to decide and coordinate the node agents to construct a cross-host logical Layer 2 network domain; and a security policy manager, configured to define and store network access control policies for virtual drones. This adaptive distributed network integration system and method aims to achieve a "physical" representation of virtual drones at the network layer, enabling them to communicate directly and collaborate with real drones within the same network plane.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) control technology, and in particular to an adaptive distributed network integration system and method for virtual-real UAV collaboration. Background Technology

[0002] With the rapid development of drone technology, its applications in military and civilian fields are becoming increasingly widespread. In the research, development, testing, drills, and execution of complex missions of drone systems (especially swarm systems), it is often necessary to combine real drones (physical entities) with virtual drones (simulated entities) to construct hybrid virtual-real systems. Virtual drones can be used to simulate swarms of a certain scale, test extreme scenarios, and reduce experimental costs and risks.

[0003] Existing hybrid virtual and physical systems face numerous challenges in network integration:

[0004] 1. Complex network identity management: Assigning independent network identities (such as MAC addresses and IP addresses) to a large number of virtual drones (usually running in containers or virtual machines on servers) that can be directly recognized and communicated with by real drones in the physical network often requires cumbersome manual configuration, is prone to errors, is difficult to scale, and lacks dynamism.

[0005] 2. Insufficient simulation realism: The network interaction between virtual drones and real drones is often simplified and fails to fully simulate the dynamic characteristics of the real world, such as network latency, packet loss, and bandwidth limitations. This results in a large deviation between the simulation results and the actual situation, affecting the effectiveness of testing and verification and the reliability of collaborative tasks.

[0006] 3. Limited Scalability: When the virtual drone swarm is large and needs to be deployed on multiple physical servers, a key challenge is how to build a unified and efficient logical network plane that enables seamless communication between all virtual drones and between virtual drones and real drones, as if they were on the same local area network. Existing solutions may rely on complex network configurations or tunneling technologies with high performance overhead.

[0007] 4. Lack of security isolation and access control: In a hybrid virtual-physical network, virtual drones directly access the physical network. If there is a lack of effective security isolation and access control mechanisms, it may pose security risks to the real network environment and real drones.

[0008] 5. Lack of unified management and adaptive capabilities: Existing solutions often lack a centralized or coordinated control plane to uniformly manage virtual and physical network resources and dynamically adjust network configurations to adapt to environmental changes and task requirements.

[0009] Therefore, there is an urgent need for an adaptive distributed network integration system and method that can efficiently manage the network identity of virtual drones, realistically simulate network states, support cross-host deployment of a certain scale, and possess basic security capabilities, so as to improve the efficiency, realism, and reliability of virtual and real drone collaboration. Summary of the Invention

[0010] Based on the technical problems existing in the background technology, this invention proposes an adaptive distributed network integration system and method for virtual and real UAV collaboration, aiming to realize the "physical" representation of virtual UAVs at the network layer, enabling them to conduct efficient, realistic, and secure direct communication and collaborative operations with real UAVs in the same network plane.

[0011] The adaptive distributed network integration system for virtual and real drone collaboration proposed in this invention includes a central control plane and at least one node agent, wherein the node agent is deployed on a physical host machine running a virtual drone container;

[0012] The central control plane includes:

[0013] The global identity manager is configured to allocate globally unique network identity information based on a preset address pool and allocation strategy for the application of virtual drone network identity uploaded by the node agent, and to record and reclaim the network identity information.

[0014] The network topology and status manager is configured to aggregate network probe data reported by each node agent, generate a virtual and physical network status view, respond to queries, and issue network simulation commands to the node agents.

[0015] A distributed network coordinator is configured to decide and coordinate the node agents to build a cross-host logical Layer 2 network domain based on the deployment location and networking strategy of the virtual drone.

[0016] The security policy manager is configured to define and store network access control policies for virtual drones and distribute them to the node agents.

[0017] Furthermore, the node agent includes:

[0018] The container runtime interface is used to monitor the lifecycle events of the virtual drone container in real time.

[0019] The local identity interface is used to respond to events from the container runtime interface, request a new virtual drone network identity from the global identity manager, and configure an independent network interface for the virtual drone container.

[0020] A network detector is used to perform network quality detection according to the network simulation instructions or preset strategies, and report the network detection data to the network topology and status manager.

[0021] The network configuration executor executes the instructions issued by the distributed network coordinator, configures the Overlay network endpoint of the local virtual drone, and bridges the macvlan interface of the local virtual drone to the configured Overlay network, thereby realizing cross-host Layer 2 communication.

[0022] The local policy execution point executes the security policies issued by the security policy manager at the physical host level.

[0023] Furthermore, a structured IP address resource library is maintained in the global identity manager, which is divided into multiple logical levels and regionalized IP address pools;

[0024] The application for the virtual drone network identity is parsed and mapped to one or more IP address pools, thereby selecting an IP address pool;

[0025] An enhanced least-used algorithm is used to select the least-used IP address from the pool of selected IP addresses for allocation. The enhanced least-used algorithm dynamically adjusts the priority of IP address selection by combining address affinity, network proximity, or expected lifespan.

[0026] When the virtual drone is destroyed, the global identity manager reclaims the corresponding network identity and updates the status and last used timestamp of the corresponding IP address according to the enhanced least recently used algorithm.

[0027] Furthermore, after the IP address is successfully allocated, the global identity manager generates a globally unique MAC address for the allocated IP address. The MAC address generation process is as follows:

[0028] Based on the Globally Unique Identifier (GUID) specification, a MAC address is generated by combining a pre-assigned organization-unique identifier with the hash value or partial bits of an assigned IP address.

[0029] The generated MAC address, assigned IP address, and identity information of the virtual drone are strongly bound and recorded in the identity registry of the global identity manager.

[0030] Furthermore, in the network topology and state manager, the aggregation of network probe data reported by each of the node agents to generate a virtual and physical network state view specifically involves:

[0031] Timestamp alignment and data cleaning are performed on multi-source, heterogeneous network detection data.

[0032] Statistical measures of network probe data are calculated based on a sliding time window, and outliers are removed.

[0033] Construct a virtual and physical network state view with network entities as nodes and communication links as edges.

[0034] Furthermore, in the distributed network coordinator, the networking strategy specifically includes:

[0035] Based on the cluster identification, task association, or security isolation requirements of virtual drones, match pre-defined rules;

[0036] Maintain a pool of network identifiers, assign unique network identifiers to virtual drone groups that need to communicate, and synchronize the VTEP information of the physical host to all node agents that participate in the same assigned unique network identifier.

[0037] Furthermore, the local identity interface configures an independent network interface for the virtual drone container as follows:

[0038] Call the physical host machine's network functions to create a macvlan interface and bind it to the network identity information assigned by the global identity manager;

[0039] Move the macvlan interface into the virtual drone container network namespace.

[0040] Furthermore, an adaptive distributed network integration method for virtual-real UAV collaboration includes:

[0041] (c1) Dynamic allocation and configuration of virtual drone network identities:

[0042] When the node agent detects that the virtual drone container starts up through the container runtime interface, the local identity interface requests a network identity from the global identity manager.

[0043] The global identity manager assigns globally unique network identity information, and the local identity interface of the node agent configures the macvlan interface for the virtual drone container.

[0044] (c2) Virtual and real network state awareness and synchronization:

[0045] The network topology and state manager aggregates data to generate a virtual and physical network state view, which can be queried by the simulation system or used to trigger network simulation.

[0046] (c3) Construction of a unified logical network across hosts:

[0047] The distributed network coordinator decides on the networking scheme based on the deployment location, and the network configuration executor, which is acted upon by the instruction node, configures the VXLAN tunnel;

[0048] The node agent bridges the macvlan interface of the virtual drone container to the VXLAN network;

[0049] (c4) Enforcement of security access policies:

[0050] The security policy manager distributes network access control policies to node agents, and the local policy enforcement point of the node agent performs traffic control at the physical host firewall.

[0051] Further, in step (c1), the global identity manager assigns globally unique network identity information, specifically as follows:

[0052] A structured IP address resource library is maintained in the global identity manager, which is divided into multiple logical levels and regional IP address pools;

[0053] The application for the virtual drone network identity is parsed and mapped to one or more IP address pools, thereby selecting an IP address pool;

[0054] An enhanced least-used algorithm is used to select the least-used IP address from the pool of selected IP addresses for allocation. The enhanced least-used algorithm dynamically adjusts the priority of IP address selection by combining address affinity, network proximity, or expected lifespan.

[0055] When the virtual drone is destroyed, the global identity manager reclaims the corresponding network identity and updates the status and last used timestamp of the corresponding IP address according to the enhanced least recently used algorithm.

[0056] Further, in step (c2), the process of querying or triggering network simulation for the simulation system specifically includes:

[0057] Instructions are issued to the node agent according to simulation requirements, injecting delays, packet loss, or communication blockage into the container network interface of the node agent.

[0058] The advantages of the adaptive distributed network integration system and method for virtual-real UAV collaboration provided by this invention are as follows: The global identity manager enables automated dynamic allocation and recycling of virtual UAV network identities, greatly simplifying the management complexity of deployments at a certain scale and improving flexibility and scalability. Through a state detection and synchronization mechanism combining a distributed network coordinator and network detectors, more realistic end-to-end network conditions can be acquired and fed back to the virtual UAVs. It can even actively simulate network dynamics, significantly improving the realism and credibility of virtual-real collaborative simulation. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the overall system architecture of the present invention;

[0060] Figure 2 This is a flowchart of the dynamic allocation and configuration of virtual drone network identities;

[0061] Figure 3 This is a schematic diagram of the cross-host unified logical network construction and DNC coordination process;

[0062] Figure 4 This is a flowchart of virtual and real network state perception and synchronization.

[0063] Figure 5 This is the IP address allocation logic diagram for the Global Identity Manager (GIM);

[0064] Figure 6 This is a flowchart of the security access policy execution process;

[0065] Figure 7 This is a diagram illustrating the interaction between internal modules of the Node Agent (NA). Detailed Implementation

[0066] The technical solution of the present invention will now be described in detail through specific embodiments. Many specific details are set forth in the following description to provide a thorough understanding of the invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0067] like Figures 1 to 7 As shown, the adaptive distributed network integration system for virtual and real drone collaboration proposed in this invention includes a central control plane and at least one node agent, wherein the node agent is deployed on a physical host machine running a virtual drone container;

[0068] The central control plane includes:

[0069] The global identity manager is configured to allocate globally unique network identity information based on a preset address pool and allocation strategy for the application of virtual drone network identity uploaded by the node agent, and to record and reclaim the network identity information.

[0070] The network topology and status manager is configured to aggregate network probe data reported by each node agent, generate a virtual and physical network status view, respond to queries, and issue network simulation commands to the node agents.

[0071] A distributed network coordinator is configured to decide and coordinate the node agents to build a cross-host logical Layer 2 network domain based on the deployment location and networking strategy of the virtual drone.

[0072] The security policy manager is configured to define and store network access control policies for virtual drones and distribute them to the node agents.

[0073] This embodiment achieves automated dynamic allocation and recycling of virtual drone network identities through a global identity manager, greatly simplifying the management complexity of deployments at a certain scale and improving flexibility and scalability. Through a state detection and synchronization mechanism combining a distributed network coordinator and network detectors, more realistic end-to-end network conditions can be acquired and fed back to virtual drones. It can even proactively simulate network dynamics, significantly improving the realism and credibility of virtual-real co-simulation. Furthermore, utilizing the overlay technology of the network configuration executor and centralized network coordination, a unified and efficient logical network plane can be built for a certain scale of virtual drone clusters deployed on multiple physical servers, enabling seamless communication with real drones as if they were on the same local area network. Finally, through the centralized security policy definition of the security policy manager and the distributed policy execution of local policy execution points, basic network access control and isolation capabilities are provided for virtual drones directly accessing the physical network, reducing security risks. Ultimately, this embodiment provides a centralized control plane to uniformly coordinate and manage network identities, network states, cross-host networking, and security policies, improving system manageability and operational efficiency. The system can also adapt to the dynamic deployment of virtual drones, changes in the network environment, and adjust network configuration and simulation parameters according to task requirements.

[0074] In one embodiment, the Central Control Plane (CCP) is the core of control and management for the entire system. It is logically centralized but physically distributed to improve availability. Specifically, it includes the Global Identity Manager (GIM), Network Topology and State Manager (NTSM), Distributed Network Coordinator (DNC), and Security Policy Manager (SPM), as follows:

[0075] (a1) Global Identity Manager (GIM): Responsible for uniformly allocating and managing network identities (such as IP addresses and MAC addresses) for all virtual drones, and adopting a policy-based allocation mechanism;

[0076] It is used to receive requests for virtual drone network identities (including MAC addresses and IP addresses) from nodes, assign globally unique network identities to virtual drones according to preset address pools and allocation policies, and record identity allocation information; when a virtual drone is destroyed, it is responsible for reclaiming its network identity.

[0077] Specifically, it receives requests for virtual drone network identities from node agents. These requests may include attribute information such as the type of virtual drone, its cluster affiliation, and security level. The global identity manager maintains a structured IP address resource library, which is divided into multiple logical levels and regionalized IP address pools. An enhanced least-used algorithm is used to select the least-used IP address from the selected IP address pool for allocation. This enhanced least-used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifespan. The global identity manager ensures the uniqueness of the allocated IP address throughout the hybrid virtual-physical network and records detailed identity allocation information (such as IP address, MAC address, allocation time, associated virtual drone ID, and associated physical host).

[0078] When a virtual drone is destroyed, the Global Identity Manager is responsible for reclaiming its network identity and updating the status and last-used timestamp of the corresponding IP address according to the enhanced least-used algorithm used.

[0079] After an IP address is successfully assigned, the Global Identity Manager generates a globally unique MAC address for the assigned IP address. The MAC address generation process is as follows: based on the Global Unique Identifier specification, the MAC address is generated by combining the pre-assigned organization unique identifier with the hash value or partial bits of the assigned IP address; or the MAC address is generated completely randomly, and uniqueness is ensured through a deduplication mechanism. The generated MAC address, the assigned IP address, and the identity information of the virtual drone are strongly bound together and recorded in the identity registry of the Global Identity Manager.

[0080] (a2) Network Topology and State Manager (NTSM): Responsible for collecting and aggregating network probe data (e.g., latency, packet loss rate, available bandwidth, etc. of a specific path) reported by agents of each node, forming a dynamic virtual and physical network state view, and providing state query and network simulation capabilities.

[0081] The core of the Network Topology and State Manager is an intelligent state aggregation and analysis engine. This engine is responsible for timestamping and cleaning multi-source, heterogeneous network probe data; calculating statistics based on sliding time windows and removing outliers; and constructing a dynamic state view with network entities as nodes and communication links as edges. Specifically, the engine employs algorithms including but not limited to time series alignment, data cleaning, sliding aggregation based on configurable time windows (such as calculating statistics like mean, median, and percentiles, with selective outlier removal), and trend analysis to transform discrete network probe data into a global or local, dynamically updated virtual-real network state view. This virtual-real network state view not only reflects the current network quality but also provides a basis for predicting potential network bottlenecks or anomalies. The Network Topology and State Manager responds to network state queries from virtual drones or simulation systems, providing formatted state information and, based on simulation requirements, issuing network simulation commands to node agents to enhance the realism of the simulation.

[0082] (a3) Distributed Network Coordinator (DNC): It is responsible for making intelligent decisions and coordinating the cross-host overlay network configuration (such as VXLAN) of each node agent according to the global deployment status and networking strategy, so as to build a unified logical network plane. Among them, overlay technology is a technology that overlays a virtual network layer on top of the physical network and realizes resource reuse and flexible scheduling through tunnel encapsulation.

[0083] In other words, the distributed network coordinator intelligently decides and coordinates cross-host network configuration among node agents based on the deployment location of virtual drones (i.e., their physical host machines) and predefined networking policies and Quality of Service (QoS) requirements. Its intelligent decision-making process specifically includes: first, acquiring the location and attributes of all virtual drones in real time; then, matching drone attributes (such as cluster affiliation and task association) with preset networking rules through a configurable networking policy rule engine; finally, based on the matching results, selecting appropriate Overlay network technologies (such as VXLAN) and allocating network resources (such as VNI) for drone clusters that need to communicate, and generating and issuing specific network configuration instructions to the corresponding node agents. Its core decision-making logic lies in determining which virtual drones (potentially distributed across different physical host machines) need to be included in the same logical Layer 2 network domain for direct communication, and selecting appropriate Overlay network technologies (such as VXLAN) and parameters (such as VNI) to construct that network domain. VXLAN (Virtual Extensible LAN) is a tunneling technology based on Layer 3 networks (IP) used to extend the coverage and flexibility of Layer 2 networks (such as VLANs), and is mainly used in cloud computing and data center environments.

[0084] The goal of a distributed network coordinator is to automatically establish and maintain one or more efficient and potentially isolated unified logical network planes that support seamless collaboration between virtual and real drones of a certain scale. It issues specific network configuration instructions to relevant node agents, such as instructing them to establish or join specific overlay network tunnels.

[0085] (a4) Security Policy Manager: Used to define and store network access control policies for virtual drones (e.g., allowed / disallowed targets, protocols, ports), and distribute policies to the corresponding node agents.

[0086] In one embodiment, each node agent includes a Container Runtime Interface (CRI), a Local Identity Interface (LII), a Network Probe (NP), a Network Configuration Executor (NCE), and a Local Policy Enforcement Point (LPEP), specifically (b1) to (b5):

[0087] (b1) Container runtime interface, used to interact with the virtual drone container runtime (such as the Docker engine) on the physical host machine, listen to the lifecycle events of the virtual drone container in real time and obtain metadata;

[0088] Specifically, the container runtime interface (MUI) is responsible for efficient and reliable interaction with the container runtime on the physical host machine (such as the Docker engine, or runtimes conforming to the Kubernetes CRI specification, such as containerd or CRI-O). Its core function is to subscribe to and accurately parse container lifecycle events in real time (such as container creation, startup, running, stopping, and destruction), and based on these events, trigger other modules within the node agent (such as the Local Identity Interface (LII)) to perform automated configuration, management, and recycling operations for corresponding network resources (such as IP / MAC addresses, macvlan interfaces, and overlay network connections). It can also be used to obtain container metadata (such as container ID, tags, and network namespaces) to assist in network identity allocation and policy enforcement.

[0089] Among them, Docker engine is an open-source application container platform used to implement containerized deployment and management of applications; Kubernetes CRI (Container Runtime Interface) specification is the core interface standard for interaction between Kubernetes and container runtime, defining the functions that the runtime must implement to be compatible with the Kubernetes platform. Kubernetes is an open-source container orchestration platform mainly used for automated deployment, scaling and management of containerized applications; CRI-O (Container Runtime Interface for OpenShift) is a lightweight container runtime that interacts directly with Kubernetes' Container Runtime Interface (CRI), allowing containers to run in Kubernetes clusters.

[0090] (b2) Local identity interface, used to respond to events of the container runtime interface, request the network identity of the newly launched virtual drone from the global identity manager, and configure an independent network interface for the virtual drone container;

[0091] Specifically, the local identity interface communicates with the global identity manager in the central control plane to apply for a network identity for newly launched virtual drone containers on the local machine; after receiving the assigned MAC address and IP address, it uses the physical host network functions (such as macvlan mode or SR-IOV virtual function) to configure an independent network interface for the virtual drone container, enabling it to obtain a routable network identity in the physical network.

[0092] Among them, the Virtual Function (VF) of SR-IOV (Single Root I / O Virtualization) is the core component in PCIe device hardware virtualization. The Virtual Function (VF) is an independent PCI device instance formed after the Physical Function (PF) is virtualized through SR-IOV technology.

[0093] (b3) Network detector, used to perform network quality detection according to network simulation instructions or preset policies, and report network detection data to the network topology and status manager.

[0094] (b4) The network configuration executor executes the instructions issued by the distributed network coordinator, configures the overlay network endpoint (such as VXLAN VTEP) of the local virtual drone, and bridges the macvlan interface of the local virtual drone to the configured overlay network, thereby realizing cross-host Layer 2 communication.

[0095] Among them, VXLAN VTEP (VXLAN Tunnel Endpoints) is the core network device of Virtual Extended Local Area Network (VXLAN), which is responsible for encapsulating and decapsulating VXLAN packets to achieve isolation and interconnection of virtual networks.

[0096] (b5) Local policy execution point, which executes the security policy issued by the security policy manager at the physical host level;

[0097] Specifically, the local policy enforcement point is used to receive security policies from the Security Policy Manager (SPM) and execute these policies at the physical host level (e.g., by configuring firewall rules to act on the network interface of the virtual drone) to filter and control network traffic entering and leaving the virtual drone container.

[0098] In (b1) through (b5), one or more virtual drone containers (e.g., VM1, VM2, VMN) run on the physical host, where N in VMN represents the total number of virtual drone containers. Through the configuration of the node agent NA, these virtual drone containers can obtain independent macvlan interfaces, allowing them to behave like physical devices at the network layer. When cross-host communication is required, these macvlan interfaces can connect to a unified logical network through the overlay network interfaces (such as VXLAN interfaces) configured by the node agent NA.

[0099] The entire system is deployed on a physical network (L2 / L3), which also carries communication between the real drone and the ground station. Through the system in this embodiment, the virtual drone container can communicate efficiently, realistically, and in a controlled manner directly at the network layer with real drones, ground stations, and other virtual drones (whether or not on the same physical host). Figure 7 This is a schematic diagram of the internal module interaction of the Node Agent (NA) in this embodiment, which shows the interaction relationship between the key components inside the NA (such as CRI, LII, NP, NCE, LPEP) and the external (CCP module, physical host network functions, etc.). This helps to understand the internal operation of the NA when executing the process described in the following embodiments.

[0100] This embodiment also proposes an adaptive distributed network integration method for virtual-real UAV collaboration, including (c1) to (c4):

[0101] (c1) Dynamic allocation and configuration of virtual drone network identities:

[0102] (c1-1) When the node agent detects that the virtual drone container starts up through the container runtime interface, the local identity interface requests a network identity from the global identity manager;

[0103] (c1-2) The global identity manager assigns globally unique network identity information, and the local identity interface of the node agent is configured as the macvlan interface for the virtual drone container;

[0104] That is, the global identity manager assigns unique MAC addresses and IP addresses based on the IP address pool and allocation policy, and returns the results to the node agent. The node agent's local identity interface calls the network functions of the physical host machine, using the assigned MAC address and IP address to configure a separate network interface for the virtual drone container that passes through to the physical network (e.g., creating and configuring a macvlan interface).

[0105] (c2) Virtual and real network state perception and synchronization: The network topology and state manager aggregate data to generate a virtual and real network state view, which can be queried by the simulation system or used to trigger network simulation;

[0106] Each node's proxy network detector periodically, or according to instructions from the network topology and state manager, probes the network connection quality parameters (such as latency, packet loss rate, and available bandwidth) between the virtual drones it manages and designated communication targets (real drones or other virtual drones). The network detectors report the network probe data to the network topology and state manager. The network topology and state manager, through its built-in state aggregation and analysis engine, preprocesses the received multi-source probe data, performs time-window-based sliding aggregation, and removes outliers, thereby transforming the discrete raw data into structured network quality parameters. These parameters are then used to construct and dynamically update a virtual-real network state graph with drone entities as nodes and communication links as edges.

[0107] Virtual drones or their simulation control systems can query the network topology and state manager through an interface to obtain relevant network status information for adjusting simulation model parameters or making collaborative decisions. The network topology and state manager can issue network simulation commands to node agents based on simulation requirements. The network detectors or specific modules of the node agents then simulate specific network conditions (such as injection latency or simulated packet loss) on the virtual drone's communication link.

[0108] (c3) Construction of a unified logical network across hosts: The distributed network coordinator decides on the networking scheme based on the deployment location and instructs the network configuration executor of the node agent to configure the VXLAN tunnel; the node agent bridges the macvlan interface of the virtual drone container to the VXLAN network;

[0109] Specifically, when virtual drones are deployed on different physical hosts and require Layer 2 communication, the distributed network coordinator in the central control plane senses the distribution of the virtual drones. Then, according to the preset networking strategy (such as which virtual drone clusters need to be in the same logical broadcast domain), the distributed network coordinator issues network configuration instructions to the relevant node agents. The network configuration executor of the node agent, according to the instructions, creates or configures the Overlay network endpoint on its local machine (for example, configuring the VTEP of the VXLAN tunnel and adding the specified VXLAN network identifier VNI), and connects the macvlan interface of the local virtual drone (or its connected bridge) to the Overlay network.

[0110] Thus, virtual drones distributed on different physical host machines form a unified logical Layer 2 network through the Overlay network, enabling direct Layer 2 / Layer 3 communication and communication with real drones connected to the same physical or logical Layer 2 network.

[0111] (c4) Security access policy execution: The security policy manager distributes network access control policies to node agents, and the local policy execution point of the node agent performs traffic control at the physical host firewall.

[0112] Administrators define access control rules for specific virtual drones (based on their assigned MAC / IP addresses) or groups of virtual drones through the Security Policy Manager in the central control plane. The Security Policy Manager distributes these rules to the relevant node agents. The local policy enforcement point of the node agents is at the physical host level, configuring corresponding firewall rules (e.g., using iptables or nftables) for the independent network interfaces of the virtual drones, allowing or blocking specific network traffic, thereby achieving secure isolation and access control between virtual drones and the real network environment, as well as other virtual drones. iptables and nftables are core tools in Linux systems for configuring network firewalls.

[0113] Example 1: System Deployment and Initialization;

[0114] The system deployment and initialization process in this embodiment can be referred to... Figure 1The overall architecture is shown. The Central Control Plane (CCP) is deployed on one or more servers. The Global Identity Manager initializes an IP address pool (e.g., 192.168.100.0 / 24) for virtual drone allocation; this pool is compatible with the physical network subnet where the real drones reside. The Network Topology and State Manager initializes an empty virtual-to-physical network state diagram. The Distributed Network Coordinator configures VXLAN as the overlay network technology and pre-sets several VNIs for isolating different virtual drone clusters. The Security Policy Manager pre-sets default security policies (e.g., prohibiting virtual drones from accessing the internet, allowing communication with specific ground station IPs).

[0115] Deploy a node agent (NA) on each physical host machine (e.g., running a Linux operating system and a Docker container engine) that is planned to run the virtual drone. Once the node agent starts, it registers with the central control plane and establishes a communication connection. Figure 1 The diagram schematically illustrates the connection between the central control plane and multiple node agents deployed on physical host machines, as well as the main functional components within the node agents.

[0116] Example 2: Detailed working mechanism of the IP address allocation module of the Global Identity Manager (GIM);

[0117] Reference Figure 5 The Global Identity Manager (GIM) in this embodiment incorporates a highly flexible and adaptive IP address allocation module, the detailed IP address allocation logic of which is shown in Figure 5. This IP address allocation module aims to provide efficient, reliable, and policy-driven network identity management for large-scale, dynamically changing virtual-real drone collaborative environments. The core feature of this IP address allocation module lies in its multi-level policy fusion and context-aware allocation mechanism, specifically including:

[0118] (d1) Hierarchical IP Address Pool Management Unit:

[0119] GIM maintains a structured IP address resource library, which is divided into multiple logical levels and regionalized sub-pools. The top level defines the globally available range of IP addresses, which can be further subdivided into several independent or overlapping sub-pools based on user-defined policy dimensions (e.g., mission type (reconnaissance, strike, logistics), security domain (classified, unclassified), virtual drone swarm identifier, geographical deployment region (for cross-regional physical host clusters), and even the expected quality of service (QoS) level). Each sub-pool can be configured with its own unique allocation attributes, such as address range, default lease duration (if applicable), and priority allocation algorithm.

[0120] (d2) Context-aware request parsing and strategy matching engine:

[0121] When the Global Identity Manager receives an IP address allocation request from a Node Agent (NA), the request may carry metadata describing the virtual drone's context information, such as: the requested virtual drone ID, its logical cluster name, expected task role, security credentials, and the physical host information on which the virtual drone is deployed. The policy matching engine parses this metadata and, based on the allocation policy rule base preset in the Global Identity Manager, dynamically maps the request to one or more of the most suitable IP address sub-pools. The allocation policy rule base can define policies such as: "If the request metadata contains the tag 'cluster=RedTeam', then allocate an address from 'RedTeam_IP_Pool' (e.g., 192.168.100.0 / 25); if it contains the tags 'task_type=surveillance' and 'security_level=high', then allocate an address from 'High_Security_Surveillance_Pool' (e.g., 10.10.1.0 / 24)." The policy rule base supports complex logical expressions (such as AND, OR, NOT) and priority definitions to ensure that allocation requests can accurately match the optimal address resources.

[0122] (d3) Core of the Adaptive Hybrid Allocation Algorithm:

[0123] For the selected IP address sub-pool, this module employs an adaptive hybrid allocation algorithm core, which prioritizes the Enhanced Least Recently Used (E-LRU) algorithm. E-LRU considers not only the last release timestamp of the IP address, but the Enhanced Least Recently Used algorithm also dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifespan.

[0124] Address Affinity: If the request contains historical IP address information (such as virtual drone restart), and the historical IP is available in the sub-pool and meets the "cooling-off period" requirement of E-LRU, then the historical IP will be reassigned first to maintain the stability of network connectivity.

[0125] Network Proximity: Considering the network location (if available) of the real drone or other virtual drones with assigned IPs associated with this virtual drone, it tends to assign IP addresses that are "closer" in the network topology or in the same optimized routing domain to potentially optimize communication latency (this feature works in conjunction with NTSM).

[0126] Anticipated Lifecycle: If the request specifies the expected runtime of the virtual drone (short-term test vs. long-term task), the allocation strategy can be adjusted. For example, allocate more easily reclaimable addresses to short-term tasks and more stable addresses to long-term tasks.

[0127] Understandably, address affinity, network proximity, and expected lifetime can be combined with the enhanced least-used algorithm individually, or two or three factors can be combined with the enhanced least-used algorithm.

[0128] Under certain configurations, or when E-LRU cannot meet certain constraints (e.g., in very small, highly dynamic sub-pools, to avoid address exhaustion too quickly), the algorithm core can automatically downgrade or switch to other alternative base algorithms, such as optimized random allocation (ensuring randomness while avoiding recently reclaimed addresses) or strict sequential filling (for specific test scenarios).

[0129] Specific configurations can be specified by the administrator via API or configuration files. For example, the allocation algorithm for a specific IP subpool can be explicitly configured as "Random" or "Sequential" to meet specific testing or compatibility requirements. Alternative base algorithms, such as random allocation and sequential allocation, are well-known basic IP address allocation strategies in the field. This application optimizes these strategies. For instance, "optimized random allocation" means that when randomly selecting available addresses, addresses that have just been reclaimed within a preset "quiet period" (e.g., 60 seconds) are excluded to further avoid address reuse conflicts.

[0130] (d4) Dynamic MAC address generation and binding module:

[0131] After an IP address is successfully assigned, the Global Identity Manager generates a globally unique MAC address for it. The MAC address generation strategy is configurable, for example:

[0132] Based on the IEEE OUI specification, it is generated using a pre-assigned Organization Unique Identifier (OUI) combined with the hash value or partial bits of the IP address;

[0133] Alternatively, it can be generated completely randomly, with uniqueness ensured through a deduplication mechanism.

[0134] The generated MAC address is strongly bound to the assigned IP address and the identity information of the virtual drone, and recorded in the identity registry of the global identity manager.

[0135] (d5) DHCP coordination and external address pool integration interface:

[0136] This module features a standardized interface, allowing for seamless integration with or proxying of external DHCP services in the future. DHCP collaboration typically refers to the cooperative process between the DHCP server and the client, achieving network management through the dynamic allocation of IP addresses and related network configuration information.

[0137] When configured in DHCP cooperative mode, the Global Identity Manager can translate IP address pool allocation requests for specific sub-pools into standard DHCP requests, forward them to DHCP servers within the enterprise or cloud environment, and manage the resulting lease information. This allows the system to better integrate into existing IT infrastructure and leverage its mature address management capabilities.

[0138] Through the design of the above-mentioned multi-level policy fusion, context awareness and adaptive hybrid algorithm, the global identity manager can provide a smart network identity management service for complex and ever-changing virtual and real drone collaborative scenarios. This service can meet the requirements of efficient allocation at a certain scale, achieve fine-grained policy control, and at the same time minimize address conflicts and improve the authenticity of network interactions.

[0139] For example, such as Figure 5 As shown, when the Global Identity Manager receives an IP allocation request (including container attributes) from the local identity interface, it first parses the container attributes. Based on the parsed attributes and the pre-defined allocation policy rule base in the Global Identity Manager, it selects a suitable IP sub-pool or segment. Subsequently, within the selected IP sub-pool, the Global Identity Manager executes an IP address allocation algorithm. This algorithm prioritizes the Enhanced Least Recently Used (E-LRU) algorithm to find an available IP address, considering factors such as address affinity, network proximity, and expected lifetime. If the E-LRU algorithm finds an available IP address, it allocates the IP; if the E-LRU algorithm fails to meet the conditions or the found IP address is unavailable, it may switch to an alternative allocation algorithm (such as random or sequential allocation). After successfully allocating an IP address, the Global Identity Manager generates or assigns a unique MAC address for it, records the relevant allocation information, and finally returns the allocated IP address and MAC address to the local identity interface.

[0140] Example 3: Single virtual drone startup, network configuration, and identity management process;

[0141] Reference Figure 2 , Figure 2 This is a flowchart of the dynamic allocation and configuration process for virtual drone network identities according to the present invention.

[0142] This embodiment details the complete process of a virtual drone from startup to obtaining network identity and being able to communicate, focusing on how the Node Agent (NA) perceives the container lifecycle and drives subsequent network configuration. The process is as follows: Figure 2 As shown.

[0143] (e1) The Node Agent (NA) is aware of container startup and retrieves metadata:

[0144] When a user launches a virtual drone container (e.g., a container running a PX4 SITL or Gazebo emulation, possibly with a tag like network.mycorp.com / cluster: Red) on physical host A via Docker commands or the Kubernetes API, the node agent (NA) running on physical host A (whose internal module interactions can be found in [link to documentation])... Figure 7 This event is detected through its built-in container runtime interface. Figure 2 (This refers to the interaction between the user starting the container and the container runtime interface monitoring events). Among them, PX4 SITL (Software In the Loop) is a software-in-the-loop simulation framework used to simulate flight control behavior in the PX4 open-source flight control system, and Gazebo simulation is a physics engine-based virtual simulation tool for robots and environments.

[0145] The specific working mechanism of the container runtime interface is as follows (f1) to (f3):

[0146] (f1) Runtime adaptation and event subscription mechanism:

[0147] The node proxy's container runtime interface has the ability to adapt to various container runtimes.

[0148] For the Docker engine: The node agent subscribes to Docker's event stream ( / events API endpoint, i.e., the event application interface endpoint) via the Docker Remote API (e.g., via the Unix socket / var / run / docker.sock). The node agent filters and monitors container-related events such as create, start, die, and destroy. The Docker Remote API is a set of RESTful APIs provided by Docker to replace the traditional command-line interface (CLI) for automated management and deployment of containerized applications. RESTful APIs are a software architecture style based on the HTTP protocol, used for lightweight, standardized communication between systems.

[0149] For Kubernetes environments (CRI-compliant runtimes such as containerd and CRI-O): If a node agent runs as a DaemonSet Pod in a Kubernetes cluster, it can utilize the Kubernetes API Server's Watch mechanism to monitor the lifecycle events of a Pod (typically running a virtual drone container within a Pod) (such as Added, Modified (Running), Deleted), or directly communicate with the CRI shim on the physical host machine via gRPC. Here, a DaemonSet is the controller in Kubernetes used to run a single Pod instance on each node; the Kubernetes API Server is the core control component of the Kubernetes cluster, responsible for managing all resources in the cluster and ensuring state consistency; a Pod is the smallest deployment unit, containing one or more containers sharing a network and storage; the CRI shim is the bridge between Kubernetes and the container runtime, interacting by implementing the CRI interface; and gRPC is a high-performance, open-source Remote Procedure Call (RPC) framework developed by Google, primarily used for inter-service communication in microservice architectures.

[0150] In this embodiment, it is assumed that physical host A is running a Docker engine and the node agent has subscribed to its event stream.

[0151] (f2) Container metadata extraction and association:

[0152] When the container runtime interface captures a start event for a new container from the Docker event stream, it immediately queries the container's detailed metadata via the Docker Remote API (e.g., by calling the / containers / {id} / json API endpoint), including:

[0153] Container ID: For example, c123b456a789;

[0154] Network namespace ID / Path: For example, the network namespace file path obtained through container inspection information, such as / var / run / docker / netns / xxxxxxx.

[0155] Labels: For example, a user might set the label network.mycorp.com / cluster: Red for a virtual drone container, indicating that the virtual drone belongs to "cluster Red".

[0156] The container runtime interface records and associates these extracted key metadata (container ID, network namespace path, cluster label, etc.).

[0157] (f3) Event-driven internal workflow triggering:

[0158] Based on the captured start event and extracted metadata, the Node Agent's Container Runtime Interface (CRI) will trigger its internal Local Identity Interface (LII). Figure 2 For information on the interaction between CRI and LII, and the specific relationship between LII and other interfaces, please refer to [link / reference needed]. Figure 7 The container ID c123b456a789 and cluster attributes (e.g., “cluster Red”) parsed from the tag are passed to the LII.

[0159] (e2) The Local Identity Interface (LII) requests a network identity from the Central Control Plane (CCP):

[0160] Upon receiving the information from the Container Runtime Interface (CRI), the local identity interface of the node agent (NA) on physical host A initiates a network identity request to the Global Identity Manager (GIM) in the central control plane. Figure 2 (LII to GIM interaction). The request includes the container ID c123b456a789 and its associated cluster information "Cluster Red" so that GIM can allocate IP addresses from the appropriate IP address pool according to its policy.

[0161] (e3) Global Identity Manager (GIM) assigns network identities:

[0162] GIM in CCP (see details of its IP allocation logic) Figure 5 (As described in Example 2) Upon receiving the application, according to the "Cluster Red" strategy (e.g., from the 192.168.100.0 / 25 subnet reserved for "Cluster Red" and using the E-LRU algorithm), an unused IP address (e.g., 192.168.100.10) is selected and a unique MAC address (e.g., 02:42:ac:11:64:0a) is generated. The GIM records the association between this identity and the container ID c123b456a789 and the physical host A, and returns this MAC / IP address to the LII of the node agent of the physical host A through a secure channel. Figure 2 (GIM returns IP / MAC to LII in the interaction).

[0163] (e4) Node Agent (NA) configures local network interfaces for containers:

[0164] After receiving the IP / MAC address assigned by GIM, the LII of the NA of physical host A executes steps (g1) to (g5) to configure its independent network interface for the virtual drone container:

[0165] (g1) Call the network management tools provided by the physical host operating system (such as the ip link command) to create a network interface of type macvlan (for example, named mvl_c123b456 to associate with the container ID).

[0166] (g2) Set the parent interface of the macvlan interface as the physical network interface card (such as eth0) that the physical host connects to the physical network. Here, the parent interface is the physical network interface card that leads out of the macvlan network traffic.

[0167] (g3) Configure the macvlan interface mode according to security requirements and network policies (e.g., bridge mode allows communication between containers on the same macvlan network on the same physical host, while private mode prohibits it).

[0168] (g4) Configure the MAC address (02:42:ac:11:64:0a) and IP address (192.168.100.10 / 25, with the correct subnet mask) assigned by GIM to the newly created mvl_c123b456 interface.

[0169] (g5) Using the container network namespace path previously obtained by CRI, move the configured mvl_c123b456 interface from the default network namespace of the physical host machine into the network namespace of this virtual drone container (for example, using ip link set mvl_c123b456 netns / var / run / docker / netns / xxxxxxx). Figure 2 From the LII to the physical host's network functions, and then to the interaction with the container, the container ultimately obtains its identity.

[0170] At this point, the virtual drone container (ID c123b456a789) possesses a network identity within the 192.168.100.0 / 24 (or more precisely, 192.168.100.0 / 25) network that can be directly discovered and communicated with by real drones (e.g., a real drone with IP address 192.168.100.5, if they are in the same L2 domain and are routable). Applications inside the container can directly use this IP address for network communication without NAT translation.

[0171] (e5) Join the Overlay network to enable cross-host communication:

[0172] Since the virtual drone is marked as belonging to "Cluster Red", the Distributed Network Coordinator (DNC) in CCP (whose detailed decision logic is described in Example 5) may determine that members of "Cluster Red" need to communicate directly at Layer 2 across different physical hosts.

[0173] If the DNC decides that the virtual drone needs to be added to a specific overlay network (e.g., a VXLAN network with a VNI of 100, dedicated to "Cluster Red"), the DNC will issue the corresponding network configuration instructions to the NA of the physical host A.

[0174] After receiving the instructions from the DNC, the Network Configuration Executor (NCE) of the NA on physical host A will execute the following (h1) to (h4):

[0175] (h1) If it does not already exist, create a network interface of type VXLAN (e.g., vxlan_red_100) and configure its VNI to 100, as well as other VTEP (VXLAN Tunnel Endpoint) information provided by DNC (i.e., the IP addresses of other physical hosts participating in the VXLAN network).

[0176] (h2) Check if a Linux bridge with a name such as "br_red_100" exists locally. If it does not exist, create one.

[0177] (h3) Connect the newly created mvl_c123b456 interface (i.e. the macvlan interface of the virtual drone) to the local bridge br_red_100.

[0178] (h4) Connect the VXLAN interface vxlan_red_100 to the local bridge br_red_100 as well.

[0179] Through (h1) to (h4) above, the traffic of the virtual drone container can enter the local bridge through the macvlan interface, and then be encapsulated through the VXLAN interface and forwarded through a tunnel to other virtual drones connected to VNI 100 on other physical hosts, thereby realizing cross-host Layer 2 communication.

[0180] Example 4: Network status detection, aggregation, and synchronization process;

[0181] like Figure 4 As shown, this embodiment describes how the system senses, aggregates, and synchronizes the virtual and physical network states, specifically (i1) to (i3):

[0182] (i1) Network detection data collection:

[0183] The CCP's Network Topology and State Manager (NTSM) instructs the Node Agent (NA) of physical host A to request its Network Probe (NP) to probe the network quality between the virtual drone (192.168.100.10) on its local machine and the real drone (192.168.100.5), as well as the virtual drone on another physical host B (assuming its IP is 192.168.100.11, connected via VXLAN). Figure 4 NTSM to NP instructions, NP to target detection.

[0184] On physical host A, the NA's NP uses the ping tool to test RTT and packet loss rate, and uses iperf (a network performance testing tool) or a similar tool to test available bandwidth. RTT refers to the total time required for a data packet to travel from the source host to the destination host and back.

[0185] The NP reports the detected network probe data (e.g., raw data packets containing timestamps, source IPs, destination IPs, RTT values, packet loss counts, etc.) to the NTSM ( Figure 4 (NP reports to NTSM).

[0186] (i2) NTSM state aggregation and analysis engine processing:

[0187] One of the core components of NTSM is its state aggregation and analysis engine, which is responsible for transforming the discrete, raw network quality data collected from network probes (NPs) of each node agent (NA) into a structured virtual-physical network state view that provides guidance for the entire virtual-physical hybrid network. Figure 4 (The aggregation and analysis process within NTSM). Its main workflow and algorithmic characteristics include (j1) to (j5):

[0188] (j1) Preprocessing and normalization of multi-source heterogeneous data:

[0189] The engine first preprocesses the received raw probe packets. These packets may contain data in different formats generated by different probe tools (such as ping, iperf, and self-developed probe protocols), as well as information such as probe timestamps, source / destination IP pairs, and probe types (such as RTT, packet loss rate, and throughput).

[0190] Data validation and cleaning: Remove data packets with obvious errors or incompleteness (such as abnormal timestamps or missing key fields).

[0191] Timestamp alignment and calibration: Considering the slight deviations that may exist in the clocks of each node, the engine can use NTP (Network Time Protocol) synchronization information or estimation methods based on message round-trip time to calibrate the timestamps of each data source to ensure the comparability of data in time series.

[0192] Data unit normalization: Converting measurement values ​​in different units (such as ms, us, bps, Mbps) into standard units for easier subsequent calculations.

[0193] (j2) Sliding aggregation algorithm based on time window:

[0194] To smooth out instantaneous fluctuations and reflect network trends over a period of time, the engine employs a sliding aggregation method based on configurable time windows, specifically (k1) to (k4).

[0195] (k1) Window definition: Administrators can configure different aggregation time window sizes (e.g., 1 second, 5 seconds, 30 seconds) and sliding steps according to the real-time requirements of the application scenario.

[0196] (k2) Data collection: For each unique network path (defined by the source IP-destination IP pair) and each probe type, the engine collects all valid probe data points that fall within the current time window.

[0197] (k3) Aggregate Calculation: Within the time window, the collected data points are calculated using one or more of the following configurable aggregation functions:

[0198] Average values ​​(means): such as average RTT, average packet loss rate, average bandwidth.

[0199] Weighted Mean: It can be weighted according to the freshness of the data points (newer data is given higher weight) or the reliability of the probe (such as the number of probes).

[0200] Median: Insensitive to outliers, it better reflects typical network conditions.

[0201] Percentiles: such as P95 RTT (95% of RTT values ​​are below this value), are used to assess the stability of network quality.

[0202] Maximum / Minimum values: Used to capture peak fluctuations.

[0203] Standard Deviation / Variance: Used to measure the volatility of network states.

[0204] (k4) Outlier handling: Before aggregation, outlier removal algorithms (such as IQR (interquartile range) or 3-sigma rule) can be enabled to eliminate the influence of sudden and atypical measurements on the aggregation results and improve the robustness of the results.

[0205] (j3) Network state graph construction and dynamic updating:

[0206] The aggregated data is used to build and maintain a dynamic, logical view of the virtual and real network states, known as the "network state graph".

[0207] The graph representation consists of nodes (representing real drones, virtual drones, ground stations, and other network entities) and edges (representing logical communication links between them). Each edge is associated with the latest network quality parameters calculated by an aggregation algorithm.

[0208] Update mechanism: As new time windows slide and new aggregation results are generated, the state parameters of the corresponding links in the graph are updated in real time. The update frequency depends on the sliding step size of the time window.

[0209] Historical data storage and tracing: NTSM can store aggregated historical state data in a time-series database for long-term trend analysis, fault backtracking, and performance evaluation.

[0210] (j4) Status query interface and subscription / publishing mechanism:

[0211] NTSM provides a standardized API interface that allows authorized clients (such as simulation engines, virtual drone control logic, and monitoring dashboards) to query the current status of a specific link or the entire network.

[0212] On-demand query: Clients can request the latest network quality parameters between a specific source / destination pair.

[0213] Subscription / Publish: Clients can subscribe to specific links or network events (such as link quality falling below a threshold). When NTSM detects a relevant change, it will proactively push a notification to the subscriber.

[0214] (j5) Trend prediction and anomaly detection:

[0215] Based on historical aggregated data, NTSM can integrate machine learning models (such as time series prediction models ARIMA and LSTM) to make preliminary predictions of network quality trends over a future period. Simultaneously, by setting baselines and thresholds, it can detect anomalies in network conditions that deviate from normal ranges and trigger alarms.

[0216] Through data processing steps (i1) to (i5), flexible aggregation algorithms, and dynamic state graph management, NTSM transforms raw, discrete probe data into a structured and meaningful view of the virtual-real network state. For example, it calculates that the average RTT from 192.168.100.10 to 192.168.100.5 over the past 5 seconds is 5.2ms, with a packet loss rate of 0.1%. This enables NTSM to provide upper-layer applications with accurate, timely, and comprehensive virtual-real network state awareness capabilities, thereby effectively improving the realism of virtual-real collaboration and the effectiveness of decision-making.

[0217] (i3) Network status application and synchronization:

[0218] An advanced simulation controller running on the physical host C queries the current network connectivity status of the virtual drone 192.168.100.10 (i.e., the aggregated result in step i2) via the API provided by NTSM. Figure 4 The simulation is applied to the query and return of NTSM to adjust the communication delay parameters in its control algorithm.

[0219] If the simulation task requires simulating a temporary interruption of the communication link between the real UAV (192.168.100.5) and the NTSM, the NTSM can issue a command to the NA of the physical host A. Figure 4 (NTSM to NP network simulation command). The NA Security Policy Manager (LPEP) can temporarily add a firewall rule on the macvlan0 interface to block all communication with 192.168.100.5 for a preset time.

[0220] Example 5: Virtual drone swarm networking and DNC decision coordination across multiple hosts;

[0221] Reference Figure 3 This embodiment illustrates how, when a virtual drone is deployed on different physical hosts, the system automatically constructs a unified logical Layer 2 network through the decision-making and coordination of the Distributed Network Coordinator (DNC) to achieve cross-host communication, specifically (l1) to (l3).

[0222] (l1) The decision-making logic and coordination mechanism of this distributed network coordinator (DNC):

[0223] The DNC acts as the 'brain' of cross-physical host network configuration within the Central Control Plane (CCP). Its core function is to intelligently decide, based on a global view and preset policies, when, where, and how to build and manage a unified logical Layer 2 network domain for virtual drone clusters distributed across different physical hosts. Figure 3The DNC (Distributed Control Center) senses deployment, makes decisions, and issues instructions to NCEs (Network Entities) at different nodes. The decision-making logic and coordination mechanism of the DNC mainly include the following aspects (m1) to (m5):

[0224] (m1) Global virtual drone deployment situational awareness:

[0225] DNC continuously obtains the latest deployment information about virtual drone instances from GIM (which obtains the IP / MAC address of the virtual drone and its physical host information) and container orchestration platforms (such as Kubernetes, if integrated). This includes:

[0226] • A unique identifier for each virtual drone instance;

[0227] • The physical host IP or node ID where this instance is currently running;

[0228] • The logical cluster, task group, security level, or other user-defined tags / metadata to which this instance belongs;

[0229] Based on this information, DNC maintains a dynamically updated view of the virtual and physical network status.

[0230] (m2) Configurable networking policy rule engine:

[0231] The core decision-making basis of DNC is a set of networking policy rules pre-configured by the administrator or dynamically updated via API. These rules define under what conditions which virtual drones should be placed in the same logical Layer 2 network domain. Rules can be based on:

[0232] Cluster ID / Group Name: For example, "All virtual drones marked 'Cluster Alpha' should be able to communicate with each other in the same VXLAN VNI X, regardless of which physical host they are deployed on."

[0233] Task Affinity: For example, "All virtual drones participating in the same collaborative search task number T001 need to be reachable at Layer 2."

[0234] Communication Pattern: For example, if a group of virtual drones needs to frequently perform low-latency multicast or broadcast communications (such as sharing situational awareness data), they should be placed in the same L2 domain.

[0235] Security Isolation Requirements: For example, “'High-security' virtual drone clusters should use independent VNIs, isolated from other clusters.”

[0236] Quality of Service (QoS) tag: If the physical network or overlay technology supports it, DNC can select or configure an overlay network with specific bandwidth guarantees or priorities based on QoS requirements.

[0237] The rules engine supports logic such as priority and condition combination (AND / OR / NOT) to handle complex networking requirements.

[0238] (m3) Overlay Network Resource Management and Selection:

[0239] When the rules engine matches a logical Layer 2 network domain that needs to be built or expanded, DNC is responsible for managing and allocating the Overlay network resources required to implement that network domain.

[0240] Overlay technology selection: The system supports a variety of overlay technologies (such as VXLAN and GENEVE). DNC selects the currently active technology based on global configuration or specific policies.

[0241] Network identifier (VNI) assignment: The DNC maintains a pool of VNIs (or other overlay network identifiers). For each virtual drone group that requires an independent Layer 2 domain, the DNC assigns a unique VNI. It can dynamically create new VNIs or add new virtual drones to existing, policy-compliant VNIs.

[0242] VTEP (VXLAN Tunnel Endpoint) Information Broadcast / Synchronization: The DNC collects the VTEP IP addresses of all physical hosts participating in the same VNI and is responsible for synchronizing this information with all relevant node agents within the VNI so that they can correctly establish VXLAN tunnels. This can be accomplished through the CCP's internal message bus or by directly issuing update commands to the NA.

[0243] (m4) Decision-making, execution, and coordination process:

[0244] Once the DNC makes a networking decision (for example, deciding to add VM_A1 on physical host A and VM_B1 on physical host B to VNI 100), it will trigger the following coordination process:

[0245] 1) Command Generation: DNC generates specific network configuration commands for each relevant Node Agent (NA). The commands include:

[0246] The type of overlay network to be operated (such as VXLAN);

[0247] VNIs that need to be added or created (e.g., 100);

[0248] A local virtual drone interface (or its connected bridge) needs to be bridged to this Overlay network.

[0249] This VNI corresponds to a list of other VTEPs (used for tunneling).

[0250] 2) Command issuance: The DNC issues commands to the target NA through the secure communication link between the CCP and the NA.

[0251] 3) Execution Confirmation and Status Feedback: The NA's NCE module executes these commands (such as creating VXLAN interfaces and configuring bridging). The execution results (success / failure and reason) are fed back to the DNC. The DNC updates the network configuration status it maintains based on the feedback.

[0252] 4) Dynamic Adjustment and Maintenance: DNC continuously monitors the lifecycle events of virtual drones (creation, migration, destruction). When deployment changes (e.g., VM_A1 is destroyed, or a new VM_C1 is added to "Cluster Alpha"), DNC will re-evaluate the networking strategy and issue corresponding instructions to update the Overlay network configuration (e.g., removing the VTEP of physical host A from VNI 100 (if physical host A no longer has VMs belonging to VNI 100), or instructing the NA of physical host C to join VNI 100).

[0253] (m5) Integration with SDN controller:

[0254] In more advanced deployments, the DNC can be integrated with the physical network's SDN controller. The DNC can pass logical networking requirements (such as "VM_A1 and VM_B1 need low-latency Layer 2 communication") to the SDN controller, which is then responsible for optimizing relevant forwarding paths or allocating network resources at the Underlay physical network layer to better support the performance of the Overlay network. The SDN controller acts as the network's control center, separating the central control plane (logical management) from the data plane (hardware forwarding) to achieve dynamic allocation and flexible configuration of network traffic.

[0255] Through (m1) to (m5), DNC can automatically and strategically manage the network connectivity of a distributed virtual drone swarm of a certain size, ensuring that they can communicate flexibly and efficiently according to mission requirements, while meeting isolation and management requirements.

[0256] For example, in actual operation:

[0257] • DNC learned from GIM that the user launched a virtual drone VM_A1 belonging to "Cluster Blue" on physical host A, and launched VM_A2, which also belongs to "Cluster Blue", on physical host B.

[0258] • DNC's policy rule base contains a rule: "All members of 'Cluster Blue' should join VNI 200." Its built-in configurable networking policy rule engine matches this rule;

[0259] • Its Overlay network resource management and selection module selects VXLAN technology and assigns or confirms the use of VNI 200 for "Cluster Blue". DNC records the VTEP IP addresses of physical host A and physical host B;

[0260] • In its decision execution and coordination process, the DNC issues a command to the NA of physical host A: to add VM_A1 (through its macvlan interface) to the VXLAN network of VNI 200, and to inform physical host B of the VTEP IP. The DNC issues a similar command to the NA of physical host B.

[0261] (l2) Node agent executes network configuration:

[0262] The NCE of the NA on physical host A creates the vxlan_blue_200 interface according to the DNC command, configures the VNI to 200, and bridges the macvlan interface of VM_A1 to vxlan_blue_200. Figure 3 (NCEA and NCEB perform the configuration actions). Simultaneously, a VXLAN tunnel pointing to the physical host B VTEP is configured.

[0263] The NA of physical host machine B performs a similar operation.

[0264] (l3) Implement cross-host communication:

[0265] After completing the above configuration, VM_A1 on physical host A (e.g., IP 192.168.100.20) and VM_A2 on physical host B (e.g., IP 192.168.100.21) are logically in the same Layer 2 broadcast domain (VNI 200). They can communicate directly through their IP addresses (e.g., ping, UDP / TCP connections), and data packets will be forwarded between physical host A and physical host B through a VXLAN tunnel. If there are real drones connected to the same VNI 200 in the physical network, they can also communicate directly with VM_A1 and VM_A2. Figure 3 Ultimately, this involves communication between VM_A1 and VM_B1.

[0266] Example 6: Application of Security Policies

[0267] This embodiment describes how the system applies security policies, such as... Figure 6As shown, it specifically includes (n1) to (n4).

[0268] (n1) The administrator configures a policy in CCP's SPM: "Block all virtual drones with IP address ranges of 192.168.100.0 / 24 from accessing the external Internet (addresses other than 192.168.0.0 / 16), but allow them to communicate with all ports of the ground station 192.168.1.100." Figure 6 (Administrator configuration to SPM).

[0269] (n2) SPM distributes this policy to all registered NAs ( Figure 6 (Strategy distribution from SPM to LPEP).

[0270] (n3) Each NA's LPEP (e.g., using iptables, the core firewall tool in Linux systems used to configure network packet filtering) adds rules (o1) to (o3) on its physical host's FORWARD chain or the chain for the macvlan interface (illustrated). Figure 6 (LPEP to physical host firewall rule configuration)

[0271] (o1) First, add a rule to allow the virtual drone to communicate with the specified ground station. An example command for this rule is:

[0272] iptables -A FORWARD -i macvlan+ -d 192.168.1.100 -j ACCEPT

[0273] Among them, -A FORWARD means to append the rule to the FORWARD chain; -i macvlan+ means that the rule matches traffic coming from all network interfaces whose names begin with macvlan; -d192.168.1.100 means that the destination IP address of the traffic is 192.168.1.100; -j ACCEPT means to perform an ACCEPT action on the matched traffic.

[0274] (o2) Next, add a rule to prevent the virtual drone from accessing the external internet. An example command for this rule is:

[0275] iptables -A FORWARD -i macvlan+ -s 192.168.100.0 / 24 ! -d 192.168.0.0 / 16 -j DROP;

[0276] In this configuration, `-s 192.168.100.0 / 24` indicates that the rule matches traffic whose source IP address belongs to the 192.168.100.0 / 24 network segment; `-d 192.168.0.0 / 16` indicates that the destination IP address is not within the 192.168.0.0 / 16 private network segment (here used to illustrately represent a non-local network); `-j DROP` indicates that the matched traffic will be dropped. The matching criteria for the rule can also be generated more precisely based on the address list assigned by the GIM.

[0277] (o3) (macvlan+ represents all macvlan interfaces managed by this NA).

[0278] (n4) Even if the virtual drone container attempts to access the internet, it will be blocked by the physical host firewall, but communication with the designated ground station will not be affected. Figure 6 Container network traffic is processed by the firewall.

[0279] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. An adaptive distributed network integration system for virtual-real UAV collaboration, characterized in that, It includes a central control plane and at least one node agent, which is deployed on a physical host machine running a virtual drone container; The central control plane includes: The global identity manager is configured to handle the application for virtual drone network identity uploaded by the node agent, allocate globally unique network identity information based on a preset address pool and allocation strategy, and record and reclaim the network identity information. The global identity manager maintains a structured IP address resource library, which is divided into multiple logical levels and regional IP address pools. The network topology and status manager is configured to aggregate network probe data reported by each node agent, generate a virtual and physical network status view, respond to queries, and issue network simulation commands to the node agents. A distributed network coordinator is configured to decide and coordinate the node agents to build a cross-host logical Layer 2 network domain based on the deployment location and networking strategy of the virtual drones. The networking strategy specifically includes: matching preset rules based on the cluster identifier, task association, or security isolation requirements of the virtual drones; maintaining a pool of network identifiers; assigning unique network identifiers to virtual drone groups that need to communicate; and synchronizing the VTEP information of the physical host to all node agents participating in the same assigned unique network identifier. The security policy manager is configured to define and store network access control policies for virtual drones and distribute them to the node agents.

2. The adaptive distributed network integration system according to claim 1, characterized in that, The node agent includes: The container runtime interface is used to monitor the lifecycle events of the virtual drone container in real time. The local identity interface is used to respond to events from the container runtime interface, request a new virtual drone network identity from the global identity manager, and configure an independent network interface for the virtual drone container. A network detector is used to perform network quality detection according to the network simulation instructions or preset strategies, and report the network detection data to the network topology and status manager. The network configuration executor executes the instructions issued by the distributed network coordinator, configures the Overlay network endpoint of the local virtual drone, and bridges the macvlan interface of the local virtual drone to the configured Overlay network, thereby realizing cross-host Layer 2 communication. The local policy execution point executes the security policies issued by the security policy manager at the physical host level.

3. The adaptive distributed network integration system according to claim 1, characterized in that, The allocation of globally unique network identity information based on a preset address pool and allocation strategy specifically includes: The application for the virtual drone network identity is parsed and mapped to one or more IP address pools, thereby selecting an IP address pool; An enhanced least-used algorithm is used to select the least-used IP address from the pool of selected IP addresses for allocation. The enhanced least-used algorithm dynamically adjusts the priority of IP address selection by combining address affinity, network proximity, or expected lifespan. When the virtual drone is destroyed, the global identity manager reclaims the corresponding network identity and updates the status and last used timestamp of the corresponding IP address according to the enhanced least recently used algorithm.

4. The adaptive distributed network integration system according to claim 3, characterized in that, After an IP address is successfully assigned, the global identity manager generates a globally unique MAC address for the assigned IP address. The MAC address generation process is as follows: Based on the Globally Unique Identifier (GUID) specification, a MAC address is generated by combining a pre-assigned organization-unique identifier with the hash value or partial bits of an assigned IP address. The generated MAC address, assigned IP address, and identity information of the virtual drone are strongly bound and recorded in the identity registry of the global identity manager.

5. The adaptive distributed network integration system according to claim 2, characterized in that, In the network topology and state manager, the aggregation of network probe data reported by each node agent to generate a virtual and physical network state view specifically involves: Timestamp alignment and data cleaning are performed on multi-source, heterogeneous network detection data. Statistical measures of network probe data are calculated based on a sliding time window, and outliers are removed. Construct a virtual and physical network state view with network entities as nodes and communication links as edges.

6. The adaptive distributed network integration system according to claim 2, characterized in that, The method for configuring a separate network interface for the local identity interface for the virtual drone container is as follows: Call the physical host machine's network functions to create a macvlan interface and bind it to the network identity information assigned by the global identity manager; Move the macvlan interface into the virtual drone container network namespace.

7. The adaptive distributed network integration method of the system according to claim 1, characterized in that, include: (c1) Dynamic allocation and configuration of virtual drone network identities: When the node agent detects that the virtual drone container starts up through the container runtime interface, the local identity interface requests a network identity from the global identity manager. The global identity manager assigns globally unique network identity information, and the local identity interface of the node agent is configured with a macvlan interface for the virtual drone container. The global identity manager maintains a structured IP address resource library, which is divided into multiple logical levels and regional IP address pools. (c2) Virtual and real network state awareness and synchronization: The network topology and state manager aggregates data to generate a virtual and physical network state view, which can be queried by the simulation system or used to trigger network simulation. (c3) Construction of a unified logical network across hosts: The distributed network coordinator determines the networking strategy based on the deployment location, and instructs the network configuration executor of the instruction node agent to configure the VXLAN tunnel. The networking strategy is specifically as follows: matching preset rules based on the cluster identifier of the virtual drone, task association, or security isolation requirements; maintaining a pool of network identifiers, assigning unique network identifiers to virtual drone groups that need to communicate, and synchronizing the VTEP information of the physical host to all node agents participating in the same assigned unique network identifier; The node agent bridges the macvlan interface of the virtual drone container to the VXLAN network; (c4) Enforcement of security access policies: The security policy manager distributes network access control policies to node agents, and the local policy enforcement point of the node agent performs traffic control at the physical host firewall.

8. The adaptive distributed network integration method according to claim 7, characterized in that, In step (c1), the global identity manager assigns globally unique network identity information, specifically as follows: The application for the virtual drone network identity is parsed and mapped to one or more IP address pools, thereby selecting an IP address pool; An enhanced least-used algorithm is used to select the least-used IP address from the pool of selected IP addresses for allocation. The enhanced least-used algorithm dynamically adjusts the priority of IP address selection by combining address affinity, network proximity, or expected lifespan. When the virtual drone is destroyed, the global identity manager reclaims the corresponding network identity and updates the status and last used timestamp of the corresponding IP address according to the enhanced least recently used algorithm.

9. The adaptive distributed network integration method according to claim 7, characterized in that, In step (c2), the process of querying or triggering network simulation for the simulation system specifically includes: Instructions are issued to the node agent according to simulation requirements, injecting delays, packet loss, or communication blockage into the container network interface of the node agent.

Images