Self-adaptive distributed network integration system and method for virtual and real unmanned aerial vehicle cooperation

Abstract

The invention discloses a self-adaptive distributed network integration system and method for virtual and real unmanned aerial vehicle cooperation, and relates to the technical field of unmanned aerial vehicle control, the system comprises a central control plane and at least one node agent, the central control plane comprises a global identity manager configured and distributed with globally unique network identity information, recording and recovering the network identity information; the network topology and state manager is configured to generate a virtual and real network state view, responds to query and issues a network simulation instruction to the node agent; the distributed network coordinator is configured to decide and coordinate the node agents to construct a cross-host logic two-layer network domain; the security policy manager is configured to define and store a network access control policy of the virtual unmanned aerial vehicle; the adaptive distributed network integration system and method aim to realize physical presentation of the virtual unmanned aerial vehicle on the network level, so that the virtual unmanned aerial vehicle can directly communicate with and collaboratively work with a real unmanned aerial vehicle in the same network plane.

Description

Technical Field

[0001] The present 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 and real UAV collaboration. Background Art

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

[0003] Existing virtual-reality hybrid systems face many challenges in network integration: 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 identified and communicated with by real drones on the physical network often requires tedious manual configuration, is prone to errors, difficult to scale, and lacks dynamism.

[0004] 2. Insufficient simulation realism: The network interaction between virtual drones and real drones is often simplified, failing to fully simulate the dynamic characteristics of the real world network, such as delays, packet loss, and bandwidth limitations. This leads to large deviations between the simulation results and the actual situation, affecting the effectiveness of test verification and the reliability of collaborative tasks.

[0005] 3. Limited scalability: When a virtual drone cluster grows in size and needs to be deployed across multiple physical servers, building a unified, efficient logical network plane that allows all virtual drones to communicate seamlessly with each other and with real drones, as if they were on the same local area network, becomes a key challenge. Existing solutions may rely on complex network configurations or tunneling technologies that have high performance overhead.

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

[0007] 5. Lack of unified management and adaptability: Existing solutions often lack a centralized or coordinated control plane to uniformly manage virtual and real network resources and dynamically adjust network configurations to adapt to environmental changes and mission requirements.

[0008] 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 status, support cross-host deployment at a certain scale, and have basic security capabilities, so as to improve the efficiency, authenticity and reliability of virtual and real drone collaboration. Summary of the Invention

[0009] Based on the technical problems existing in the background technology, the present invention proposes an adaptive distributed network integration system and method for the collaboration between virtual and real drones, aiming to realize the "physical" presentation of virtual drones at the network level, so that they can conduct efficient, realistic and secure direct communication and collaborative operations with real drones in the same network plane.

[0010] The adaptive distributed network integration system for virtual and real drone collaboration proposed in the present invention 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: A global identity manager configured to process the virtual drone network identity application uploaded by the node agent, allocate globally unique network identity information based on a preset address pool and allocation strategy, and record and recover the network identity information; A network topology and status manager configured to aggregate network detection data reported by each of the node agents, generate a virtual and real network status view, respond to queries and issue network simulation instructions to the node agents; A distributed network coordinator is configured to make decisions and coordinate the node agents to build a cross-host logical layer 2 network domain based on the virtual drone deployment location and networking strategy; The security policy manager is configured to define and store the network access control policy of the virtual drone and distribute it to the node agents.

[0011] Furthermore, the node agent includes: Container runtime interface, used to monitor the lifecycle events of the virtual drone container in real time; The local identity interface is used to respond to events of the container runtime interface and apply to the global identity manager for the newly started virtual drone network identity, while configuring an independent network interface for the virtual drone container; A network detector is used to perform network quality detection according to the network simulation instruction or preset strategy, 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 policy issued by the security policy manager at the physical host level.

[0012] Furthermore, a structured IP address resource library is maintained in the global identity manager, wherein the IP address resource library is divided into a plurality of logical hierarchical and regionalized IP address pools; Parsing the application for the virtual drone network identity and mapping it to one or more IP address pools, thereby selecting an IP address pool; An enhanced least recently used algorithm is used to select an IP address from the selected IP address pool for allocation. The enhanced least recently used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifecycle. 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 adopted enhanced least recently used algorithm.

[0013] 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: Based on the Globally Unique Identifier specification, a MAC address is generated using a pre-assigned organizationally unique identifier combined with a hash value or partial bits of an assigned IP address; The generated MAC address, the assigned IP address, and the identity information of the virtual drone are strongly bound and recorded in the identity registry of the global identity manager.

[0014] Furthermore, in the network topology and status manager, the network detection data reported by each node agent is aggregated to generate a virtual and real network status view, specifically: Perform timestamp alignment and data cleaning on multi-source, heterogeneous network detection data; Calculate statistics of network detection data based on a sliding time window and remove outliers; Construct a virtual-real network status view with network entities as nodes and communication links as edges.

[0015] Furthermore, in the distributed network coordinator, the networking strategy is specifically: Based on the cluster identification, mission relevance or security isolation requirements of virtual drones, matching preset rules; 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 participating in the same assigned unique network identifier.

[0016] Furthermore, the local identity interface configures an independent network interface for the virtual drone container as follows: Call the physical host network function to create a macvlan interface and bind the network identity information assigned by the global identity manager; Move the macvlan interface into the virtual drone container network namespace.

[0017] Furthermore, the adaptive distributed network integration method for virtual and real UAV collaboration includes: (c1) Dynamic allocation and configuration of virtual drone network identities: When the node agent detects the startup of the virtual drone container through the container runtime interface, the local identity interface requests the 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 configures the macvlan interface for the virtual drone container.

[0018] (c2) Virtual and real network status perception and synchronization: The network topology and status manager aggregates data to generate a virtual and real network status view for the simulation system to query or trigger network simulation; (c3) Unified logical network construction across hosts: The distributed network coordinator decides the networking solution 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 virtual drone container macvlan interface to the VXLAN network; (c4) Security access policy enforcement: The security policy manager distributes network access control policies to node agents, and the node agents' local policy enforcement points perform traffic control at the physical host firewall.

[0019] Furthermore, in step (c1), the global identity manager allocates globally unique network identity information, specifically: Maintaining a structured IP address resource library in the global identity manager, wherein the IP address resource library is divided into a plurality of logical hierarchical and regionalized IP address pools; Parsing the application for the virtual drone network identity and mapping it to one or more IP address pools, thereby selecting an IP address pool; An enhanced least recently used algorithm is used to select an IP address from the selected IP address pool for allocation. The enhanced least recently used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifecycle. 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 adopted enhanced least recently used algorithm.

[0020] Furthermore, in step (c2), the simulation system queries or triggers network simulation, specifically: Send instructions to the node agent based on the simulation requirements, injecting delays, packet loss, or blocking communication into the node agent's container network interface.

[0021] The advantages of the adaptive distributed network integration system and method for virtual-reality UAV collaboration provided by this invention include: a global identity manager enables automated dynamic allocation and recovery of virtual UAV network identities, significantly simplifying the management complexity of large-scale deployments and improving flexibility and scalability. A state detection and synchronization mechanism combining a distributed network coordinator with network detectors enables the acquisition and feedback of more realistic end-to-end network conditions to virtual UAVs, even allowing for proactive simulation of network dynamics, significantly enhancing the realism and credibility of virtual-reality collaborative simulations. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a schematic diagram of the overall system architecture of the present invention; Figure 2 It is a flowchart of dynamic allocation and configuration of virtual drone network identities; Figure 3 This is a schematic diagram of the cross-host unified logical network construction and DNC coordination process; Figure 4 It is a flowchart of virtual and real network status perception and synchronization; Figure 5 It is the logical diagram of IP address allocation of Global Identity Manager (GIM); Figure 6 It is a flow chart of security access policy execution; Figure 7 This is a schematic diagram of the internal module interaction of the node agent (NA). DETAILED DESCRIPTION

[0023] The technical solutions of the present invention are described in detail below through specific embodiments. Numerous specific details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art may make similar modifications without departing from the scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0024] like Figures 1 to 7As shown, the adaptive distributed network integration system for virtual and real drone collaboration proposed by the present invention 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: A global identity manager configured to process the virtual drone network identity application uploaded by the node agent, allocate globally unique network identity information based on a preset address pool and allocation strategy, and record and recover the network identity information; A network topology and status manager configured to aggregate network detection data reported by each of the node agents, generate a virtual and real network status view, respond to queries and issue network simulation instructions to the node agents; A distributed network coordinator is configured to make decisions and coordinate the node agents to build a cross-host logical layer 2 network domain based on the virtual drone deployment location and networking strategy; The security policy manager is configured to define and store the network access control policy of the virtual drone and distribute it to the node agents.

[0025] This embodiment implements automated dynamic allocation and reclaiming of virtual drone network identities through a global identity manager, significantly simplifying the management complexity of large-scale deployments and improving flexibility and scalability. Through a state detection and synchronization mechanism combining a distributed network coordinator and network probes, more realistic end-to-end network conditions can be acquired and fed back to virtual drones, even allowing for proactive simulation of network dynamics, significantly enhancing the realism and credibility of virtual-reality collaborative simulations. Furthermore, utilizing the network configuration executor's overlay technology and centralized network coordination, a unified and efficient logical network plane can be constructed for a certain scale of virtual drone clusters deployed on multiple physical servers, enabling seamless communication with real drones as if within the same local area network. Finally, through the coordinated implementation of centralized security policy definitions in the security policy manager and distributed policy enforcement by local policy enforcement points, basic network access control and isolation capabilities are provided for virtual drones directly connected to the physical network, reducing security risks. Ultimately, this embodiment provides a centralized control plane for unified and coordinated management of network identities, network status, cross-host networking, and security policies, improving system manageability and operational efficiency. Furthermore, the system can adapt to the dynamic deployment of virtual drones and changes in the network environment, adjusting network configuration and simulation parameters based on mission requirements.

[0026] In one embodiment, the Central Control Plane (CCP) is the control and management core of the entire system. It is logically centralized but physically distributed to improve availability. It includes the Global Identity Manager (GIM), Network Topology and State Manager (NTSM), Distributed Network Coordinator (DNC), and Security Policy Manager (SPM). Specifically: (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 strategic allocation mechanism; It is used to receive application requests for virtual drone network identities (including MAC addresses and IP addresses) from nodes, assign a globally unique network identity to the virtual drone based on the preset address pool and allocation strategy, and record the identity allocation information; when the virtual drone is destroyed, it is responsible for reclaiming its network identity.

[0027] That is, it receives a request for a virtual drone network identity from a node agent. This request may include attribute information such as the virtual drone's type, cluster, 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. It uses an enhanced least recently used algorithm to select the longest-unused IP address from the selected IP address pool for allocation. The enhanced least recently used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifecycle. The global identity manager ensures the uniqueness of the allocated IP address throughout the virtual-real hybrid network and records detailed identity allocation information (such as IP address, MAC address, allocation time, associated virtual drone ID, and physical host machine).

[0028] 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 adopted enhanced least recently used algorithm.

[0029] 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: based on the global unique identifier specification, a pre-assigned organizational unique identifier is used in combination with the hash value or partial bits of the allocated IP address to generate a MAC address; or a MAC address is generated completely randomly and uniqueness is ensured through a duplicate checking mechanism; the generated MAC address, the allocated IP address, and the identity information of the virtual drone are strongly bound and recorded in the identity registry of the global identity manager.

[0030] (a2) Network Topology and Status Manager (NTSM): Responsible for collecting and aggregating network detection data reported by each node agent (for example, the delay, packet loss rate, available bandwidth, etc. of a specific path), forming a dynamic virtual and real network status view, and providing status query and network simulation capabilities.

[0031] The core of the Network Topology and State Manager is an intelligent state aggregation and analysis engine. This engine is responsible for timestamp alignment and data cleansing of multi-source, heterogeneous network probe data; calculating statistics on network probe data 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 uses algorithms including, but not limited to, time series alignment, data cleansing, sliding aggregation based on configurable time windows (such as calculating statistics such as mean, median, and percentile, with optional 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 current network quality but also provides a basis for predicting potential network bottlenecks or anomalies. The Network Topology and State Manager responds to network status queries from virtual drones or simulation systems, providing formatted state information and, based on simulation requirements, issuing network simulation instructions to node agents to enhance simulation realism.

[0032] (a3) Distributed Network Coordinator (DNC): Responsible for making intelligent decisions and coordinating node agents to configure overlay networks (such as VXLAN) across hosts based on the global deployment situation and networking strategy to build a unified logical network plane. Overlay technology is a technology that superimposes a virtual network layer on the physical network, achieving resource reuse and flexible scheduling through tunnel encapsulation.

[0033] Specifically, the distributed network coordinator is used to intelligently make decisions and coordinate cross-host network configuration among node agents based on the virtual drones' deployment locations (i.e., their physical hosts), predefined networking policies, and Quality of Service (QoS) requirements. This intelligent decision-making process includes: first, obtaining the locations and attributes of all virtual drones in real time; then, using a configurable networking policy rule engine, matching drone attributes (such as cluster affiliation and mission relevance) with pre-set networking rules; finally, based on the matching results, selecting the appropriate overlay network technology (such as VXLAN) and allocating network resources (such as VNI) for the drone clusters requiring interoperability; and then generating and issuing specific network configuration instructions to the corresponding node agents. The core decision-making logic involves determining which virtual drones (possibly distributed across different physical hosts) should be included in the same logical Layer 2 network domain for direct communication, and then selecting the appropriate overlay network technology (such as VXLAN) and parameters (such as VNI) to construct this network domain. Among them, VXLAN (Virtual Extensible LAN) is a tunnel technology based on the third-layer network (IP) that is used to extend the coverage and flexibility of the second-layer network (such as VLAN). It is mainly used in cloud computing and data center environments.

[0034] The goal of the distributed network coordinator is to automatically establish and maintain one or more efficient, potentially isolated, unified logical network planes that support seamless collaboration between virtual and real drones at 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.

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

[0036] In one embodiment, each node agent includes a container runtime interface (CRI), a local identity interface (LII), a network probe (NP), a network configuration enforcer (NCE), and a local policy enforcement point (LPEP), specifically (b1) to (b5): (b1) Container runtime interface, used to interact with the virtual drone container runtime (e.g., Docker engine) on the physical host machine, monitor the lifecycle events of the virtual drone container in real time, and obtain metadata; Specifically, the Container Runtime Interface (CRI) is responsible for efficient and reliable interaction with the container runtime on the physical host (such as the Docker engine or runtimes that conform to the Kubernetes CRI specification, such as containerd or CRI-O). Its core function is to subscribe to and accurately interpret container lifecycle events (such as container creation, start, run, stop, and destruction) in real time. Based on these events, it can trigger other modules within the node agent (such as the Local Identity Interface (LII)) to automatically configure, manage, and recycle 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 IDs, labels, and network namespaces) to assist in network identity assignment and policy enforcement.

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

[0038] (b2) Local identity interface, used to respond to events of the container runtime interface and apply for the newly started virtual drone network identity from the global identity manager, while configuring an independent network interface for the virtual drone container; Specifically, the local identity interface communicates with the global identity manager of the central control plane to apply for a network identity for the newly started virtual drone container on the local machine; after receiving the assigned MAC address and IP address, the physical host network function (such as macvlan mode or SR-IOV virtual function) is used to configure an independent network interface for the virtual drone container, so that it obtains a network identity that can be routed in the physical network.

[0039] Among them, the virtual function (VF) of SR-IOV (Single Root I / O Virtualization) is the core component of PCIe device hardware virtualization. The virtual function (VF) is an independent PCI device instance formed by virtualizing the physical function (PF) through SR-IOV technology.

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

[0041] (b4) a network configuration executor, executing instructions issued by the distributed network coordinator, configuring the overlay network endpoint (e.g., VXLAN VTEP) of the local virtual drone, and bridging the macvlan interface of the local virtual drone to the configured overlay network, thereby achieving cross-host Layer 2 communication; Among them, VXLAN VTEP (VXLAN Tunnel Endpoints) is the core network device of Virtual Extended Local Area Network (VXLAN), responsible for encapsulating and decapsulating VXLAN packets to achieve isolation and interoperability of virtual networks.

[0042] (b5) a local policy enforcement point, which executes the security policy issued by the security policy manager at the physical host level; 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 (such as by configuring firewall rules on the network interface of the virtual drone) to filter and control the network traffic in and out of the virtual drone container.

[0043] In steps (b1) through (b5), one or more virtual drone containers (e.g., VM1, VM2, VMN) are running on a physical host, where N in VMN is 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 level. When cross-host communication is required, these MACVLAN interfaces can be connected to a unified logical network via the overlay network interface (e.g., VXLAN interface) configured by the node agent (NA).

[0044] The entire system is deployed on a physical network (L2 / L3), which also handles communications between real drones and ground stations. Through the system of this embodiment, the virtual drone container can achieve efficient, realistic, and controlled direct communication with real drones, ground stations, and other virtual drones (regardless of whether they are on the same physical host) at the network level. Figure 7 This is a schematic diagram of the internal module interactions of the node agent (NA) of this embodiment. It shows the interaction between the key components within the NA (such as CRI, LII, NP, NCE, LPEP) and their external components (CCP module, physical host network functions, etc.). This helps understand the internal operation of the NA when executing the processes described in subsequent embodiments.

[0045] This embodiment also proposes an adaptive distributed network integration method for virtual and real UAV collaboration, including (c1) to (c4): (c1) Dynamic allocation and configuration of virtual drone network identities: (c1-1) When the node agent detects the startup of the virtual drone container through the container runtime interface, the local identity interface requests a network identity from the global identity manager; (c1-2) 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; That is, the global identity manager assigns a unique MAC address and IP address based on the IP address pool and allocation policy, and returns the result to the node agent. The node agent's local identity interface calls the network function of the physical host and uses the assigned MAC address and IP address to configure an independent network interface for the virtual drone container that is directly connected to the physical network (for example, creating and configuring a macvlan interface).

[0046] (c2) Virtual and real network status perception and synchronization: The network topology and status manager aggregates data to generate virtual and real network status views for simulation system query or triggering network simulation; Each node agent's network detector periodically or according to instructions from the network topology and state manager detects 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 detector reports the network detection data to the network topology and state manager. The network topology and state manager uses its built-in state aggregation and analysis engine to preprocess the received multi-source detection data, perform sliding aggregation based on time windows, and eliminate outliers. This converts the discrete raw data into structured network quality parameters, which are then used to construct and dynamically update a virtual-real network state graph with drone entities as nodes and communication links as edges.

[0047] The virtual drone or its simulation control system can query the network topology and status manager through an interface to obtain relevant network status information, which can be used to adjust simulation model parameters or make collaborative decisions. Based on simulation requirements, the network topology and status manager can issue network simulation instructions to node agents. The node agents' network detectors or specialized modules then simulate specific network conditions (such as injecting delays and simulating packet loss) on the virtual drone's communication links.

[0048] (c3) Construction of a unified logical network across hosts: The distributed network coordinator determines the networking solution based on the deployment location and instructs the node agent's network configuration executor to configure the VXLAN tunnel; the node agent bridges the virtual drone container's macvlan interface to the VXLAN network; Specifically, when virtual drones are deployed on different physical hosts and require Layer 2 intercommunication, the distributed network coordinator in the central control plane detects the distribution of the virtual drones. It then issues network configuration instructions to the relevant node agents based on pre-set networking policies (e.g., which virtual drone clusters need to be located in the same logical broadcast domain). The node agent's network configuration executor, acting on the instructions, creates or configures an overlay network endpoint on its local machine (for example, configuring a VTEP for a VXLAN tunnel and adding a specified VXLAN network identifier (VNI)). It then connects the local virtual drone's MACVLAN interface (or the bridge it connects to) to the overlay network.

[0049] As a result, virtual drones distributed on different physical hosts form a unified logical Layer 2 network through the Overlay network, which can directly conduct Layer 2 / Layer 3 communication and communicate with real drones connected to the same physical or logical Layer 2 network.

[0050] (c4) Security access policy execution: The security policy manager distributes network access control policies to node agents, and the node agents' local policy execution points perform traffic control at the physical host firewall.

[0051] Administrators use the central control plane's Security Policy Manager to define access control rules for specific virtual drones (based on their assigned MAC / IP addresses) or groups of virtual drones. The Security Policy Manager distributes these rules to the relevant node agents. The node agents' local policy enforcement point is at the physical host level. They configure firewall rules (for example, using iptables or nftables) for the virtual drone's individual network interfaces, allowing or blocking specific network traffic. This ensures secure isolation and access control between the virtual drone and the real network environment and other virtual drones. Iptables and nftables are core tools for configuring network firewalls in Linux systems.

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

[0053] Deploy a node agent (NA) on each physical host machine (for example, running the Linux operating system and the Docker container engine) where you plan to run a virtual drone. After the node agent starts, it registers with the central control plane and establishes a communication connection. Figure 1 The figure schematically shows the connection between the central control plane and multiple node agents deployed on physical hosts, as well as the main functional components within the node agents.

[0054] Example 2: Detailed working mechanism of the IP address allocation module of the Global Identity Manager (GIM); Reference Figure 5 The Global Identity Manager (GIM) of this embodiment includes a highly flexible and adaptive IP address allocation module. The detailed IP address allocation logic flow is shown in Figure 5. This IP address allocation module is designed to provide efficient, reliable, and policy-driven network identity management for a large, dynamically changing virtual and real drone collaborative environment. The core features of this IP address allocation module lie in its multi-level policy fusion and context-aware allocation mechanism, specifically including: (d1) Hierarchical IP address pool management unit: GIM maintains a structured IP address resource pool divided into multiple logical hierarchies and regionalized sub-pools. The top level defines the globally available IP address range, which can be further subdivided into independent or overlapping sub-pools based on user-defined policy dimensions, such as mission type (e.g., reconnaissance, strike, logistics), security domain (e.g., confidential, unclassified), virtual drone cluster identifier, geographic deployment area (for cross-regional physical host clusters), and even desired network quality of service (QoS) levels. Each sub-pool can be configured with unique allocation properties, such as address range, default lease duration (if applicable), and priority allocation algorithm.

[0055] (d2) Context-aware request parsing and policy matching engine: When the Global Identity Manager receives an IP address allocation request from a Node Agent (NA), the request may include metadata describing the virtual drone's context, such as the requested virtual drone's ID, the logical cluster name to which it belongs, its intended mission role, security credentials, and information about the physical host where the virtual drone will be deployed. The policy matching engine parses this metadata and dynamically maps the request to one or more of the most appropriate IP address subpools based on the allocation policy rule base pre-set in the Global Identity Manager. The allocation policy rule base can define the following policy: "If the request metadata contains the tag 'cluster=RedTeam', allocate an address from the 'RedTeam_IP_Pool' (such as 192.168.100.0 / 25); if it contains the tags 'task_type=surveillance' and 'security_level=high', allocate an address from the 'High_Security_Surveillance_Pool' (such as 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.

[0056] (d3) Adaptive hybrid allocation algorithm core: For the selected IP address subpool, this module uses an adaptive hybrid allocation algorithm core that prioritizes the Enhanced-Least-Recently-Used (E-LRU) algorithm. E-LRU not only considers the last release timestamp of the IP address, but also dynamically adjusts the priority of IP address selection by combining address affinity, network proximity, or expected lifetime: Address Affinity: If the request contains historical IP address information (such as a virtual drone restart), and the historical IP is available in the sub-pool and meets the "cooling-off period" requirements of E-LRU, the historical IP will be reassigned first to maintain the stability of the network connection.

[0057] Network Proximity: Considers the network location of real drones or other virtual drones with assigned IP addresses associated with the virtual drone (if available), and tends to assign IP addresses that are "closer" in network topology or within the same optimized routing domain to potentially optimize communication latency (this feature is linked to NTSM).

[0058] Anticipated Lifecycle: If the request specifies the expected runtime of the virtual drone (short-term testing vs. long-term missions), the allocation strategy can be adjusted, for example, allocating more recyclable addresses for short-term missions and more stable addresses for long-term missions.

[0059] It is understandable that the three factors of address affinity, network proximity and expected life cycle can be combined with the enhanced least recently used algorithm separately, or two or three factors can be combined with the enhanced least recently used algorithm.

[0060] Under specific configurations, or when E-LRU cannot meet certain constraints (for example, in very small, highly dynamic subpools, to avoid address exhaustion too quickly), the algorithm core can automatically downgrade or switch to other alternative basic algorithms, such as optimized random allocation (to ensure randomness while avoiding recently recycled addresses) or strict sequential filling (for specific testing scenarios).

[0061] Specific configurations can be specified by the administrator through an API or configuration file. For example, the allocation algorithm for a certain IP subpool can be explicitly configured as "Random" or "Sequential" to meet specific testing or compatibility requirements. Alternative basic algorithms, such as random allocation and sequential allocation, are well-known basic IP address allocation strategies in the field. This application has been optimized on this basis. For example, "optimized random allocation" means that when randomly selecting available addresses, addresses that have just been recycled within a preset "silent period" (such as 60 seconds) will be excluded to further avoid address reuse conflicts.

[0062] (d4) Dynamic MAC address generation and binding module: After the IP address is successfully assigned, the Global Identity Manager will generate a globally unique MAC address for it. The MAC address generation strategy can be configured, for example: Based on the IEEE OUI specification, it uses a pre-assigned organizationally unique identifier (OUI) combined with a hash value or partial bits of the IP address; Alternatively, generate completely randomly and ensure uniqueness through a duplicate checking mechanism.

[0063] 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.

[0064] (d5) DHCP collaboration and external address pool integration interface: This module is designed with standardized interfaces, which will allow for seamless integration or proxying of external DHCP services in the future. DHCP collaboration generally refers to the collaborative process between a DHCP server and a client, enabling network management by dynamically allocating IP addresses and related network configuration information.

[0065] When configured in DHCP collaborative mode, the Global Identity Manager can convert IP address allocation requests for specific sub-pools into standard DHCP requests, forward them to DHCP servers on-premises or in cloud environments, and manage the lease information obtained. This allows the system to better integrate into existing IT infrastructure and leverage its mature address management capabilities.

[0066] Through the design of the above-mentioned multi-level policy fusion, context awareness, and adaptive hybrid algorithm, this embodiment enables the global identity manager to provide an intelligent network identity management service for complex and ever-changing virtual and real drone collaboration scenarios, which can not only meet the requirements of efficient allocation at a certain scale, but also achieve refined policy control, while minimizing address conflicts and improving the authenticity of network interactions.

[0067] For example, Figure 5 As shown in the figure, when the global identity manager receives an IP allocation request (including container attributes) from a local identity interface, it first parses the container attributes. Based on the parsed attributes and the allocation policy rule base pre-set in the global identity manager, the global identity manager selects an appropriate IP subpool or segment. The global identity manager then executes an IP address allocation algorithm within the selected IP subpool, prioritizing the Enhanced Least Recently Used (E-LRU) algorithm to locate an available IP address. This process considers factors such as address affinity, network proximity, and expected lifetime. If the E-LRU algorithm finds an available IP address, the IP address is allocated. If the E-LRU algorithm fails to meet the requirements or the found IP address is unavailable, it may switch to an alternative allocation algorithm (such as random or sequential allocation). After successfully allocating the IP address, the global identity manager generates or assigns a unique MAC address, records the allocation information, and ultimately returns the allocated IP and MAC addresses to the local identity interface.

[0068] Example 3: Single virtual drone startup, network configuration and identity management process; Reference Figure 2 , Figure 2 It is a flow chart of the dynamic allocation and configuration of virtual drone network identities of the present invention.

[0069] This example describes in detail the complete process of a virtual drone from startup to obtaining a network identity and being able to communicate, focusing on how the node agent (NA) perceives the container life cycle and drives subsequent network configuration. Figure 2 shown.

[0070] (e1) The node agent (NA) senses the container startup and obtains metadata: When a user starts a virtual drone container (for example, a container running PX4 SITL or Gazebo simulation and possibly with a label such as network.mycorp.com / cluster: Red) on physical host A through Docker commands or Kubernetes API, the node agent (NA) running on physical host A (the internal module interaction of which can be seen in Figure 7 ) is aware of this event through its built-in container runtime interface ( Figure 2 , where the user initiates the interaction between the container and the container runtime interface monitoring events. 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. Gazebo simulation is a physics-based tool for virtual simulation of robots and environments.

[0071] The specific working mechanism of the container runtime interface is as follows (f1) to (f3): (f1) Runtime adaptation and event subscription mechanism: The node agent's container runtime interface is adaptable to multiple container runtimes.

[0072] For the Docker engine: The node agent subscribes to the Docker event stream (the / events API endpoint) via the Docker Remote API (for example, through 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 that replaces the traditional command-line interface (CLI) to automate the management and deployment of containerized applications. RESTful APIs are a software architectural style based on HTTP that enables lightweight, standardized communication between systems.

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

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

[0075] (f2) Container metadata extraction and association: When the Container Runtime Interface captures a start event for a new container from the Docker event stream, it immediately queries the Docker Remote API (for example, by calling the / containers / {id} / json API endpoint) for detailed metadata about the container, including: Container ID: for example, c123b456a789; Network namespace ID / Path: For example, the network namespace file path obtained through container inspect information, such as / var / run / docker / netns / xxxxxxx.

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

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

[0078] (f3) Event-driven internal workflow triggering: Based on the captured start event and the extracted metadata, the node agent's Container Runtime Interface (CRI) will trigger its internal Local Identity Interface (LII) ( Figure 2 , interaction from CRI to LII, for details on the relationship between LII and other interfaces, see Figure 7 ), and passes information such as the container ID c123b456a789 and the cluster attributes parsed from the label (for example, "Cluster Red") to LII.

[0079] (e2) The Local Identity Interface (LII) requests a network identity from the Central Control Plane (CCP): After receiving the information transmitted by the Container Runtime Interface (CRI), the local identity interface of the node agent (NA) on the physical host A initiates a network identity application request to the global identity manager (GIM) of the central control plane ( Figure 2 , interaction from LII to GIM). The application request contains the container ID c123b456a789 and the cluster information to which it belongs, "Cluster Red", so that GIM can allocate an IP address from the appropriate IP address pool according to the policy.

[0080] (e3) Global Identity Manager (GIM) assigns network identities: GIM in CCP (its IP allocation logic is detailed in Figure 5 After receiving the request (as described in Example 2), the GIM selects an unused IP address (e.g., 192.168.100.10) and generates a unique MAC address (e.g., 02:42:ac:11:64:0a) based on the "Cluster Red" policy (e.g., from the 192.168.100.0 / 25 subnet reserved for "Cluster Red" and using the E-LRU algorithm). The GIM records the association between this identity and the container ID c123b456a789 and physical host A, and returns this MAC / IP address to the LII of the node agent of physical host A via a secure channel ( Figure 2 , GIM returns IP / MAC to LII for interaction).

[0081] (e4) The node agent (NA) configures the local network interface for the container: After receiving the IP / MAC address assigned by GIM, the LII of the NA of physical host A performs steps (g1) to (g5) to configure an independent network interface for the virtual drone container: (g1) Call the network management tool provided by the physical host operating system (such as the ip link command) to create a macvlan type network interface (for example, named mvl_c123b456 to associate with the container ID).

[0082] (g2) Set the parent interface of the macvlan interface to the physical network card (such as eth0) that connects the physical host to the physical network. The parent interface is the physical network card that egresses the macvlan network traffic.

[0083] (g3) Configure the mode of the macvlan interface based on security requirements and network policies (for example, bridge mode allows communication between containers on the same macvlan network on the same physical host, while private mode prohibits it).

[0084] (g4) Assign 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.

[0085] (g5) Using the container network namespace path obtained by CRI earlier, move the configured mvl_c123b456 interface from the default network namespace of the physical host to the network namespace of the virtual drone container (for example, use ip link set mvl_c123b456 netns / var / run / docker / netns / xxxxxxx) ( Figure 2 , LII to the physical host network function and then to the interaction of the container, and finally the container obtains its identity).

[0086] At this point, the virtual drone container (with ID c123b456a789) has 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 (for example, a real drone with IP address 192.168.100.5, if they are in the same L2 domain and routable). Applications within the container can directly use this IP address for network communication without NAT translation.

[0087] (e5) Join the Overlay network to achieve cross-host communication: Because the virtual drone is marked as belonging to "Cluster Red", the Distributed Network Coordinator (DNC) in the CCP (whose detailed decision logic is described in Example 5) may determine that members of "Cluster Red" need to perform Layer 2 direct communication across different physical hosts.

[0088] If the DNC decides to add this virtual drone to a specific overlay network (for example, a VXLAN network with a VNI of 100, specifically for "Cluster Red"), the DNC will send the corresponding network configuration instructions to the NA of physical host A.

[0089] After receiving the DNC instruction, the Network Configuration Executor (NCE) of the NA of physical host A executes the following (h1) to (h4): (h1) If it does not already exist, create a VXLAN network interface (for example, vxlan_red_100) and configure its VNI as 100, as well as other VTEP (VXLAN Tunnel Endpoint) information provided by the DNC (that is, the IP addresses of other physical hosts participating in the VXLAN network).

[0090] (h2) Check if a Linux bridge named "br_red_100" exists locally. If not, create one.

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

[0092] (h4) Connect the VXLAN interface vxlan_red_100 to the local bridge br_red_100.

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

[0094] Example 4: Network status detection, aggregation and synchronization process; like Figure 4 As shown, this embodiment describes how the system perceives, aggregates and synchronizes virtual and real network states, specifically (i1) to (i3): (i1) Network detection data collection: 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 detect the network quality between the local virtual drone (192.168.100.10) and the real drone (192.168.100.5) and the virtual drone on another physical host B (assuming its IP is 192.168.100.11, connected via VXLAN). Figure 4 , instructions from NTSM to NP, detection from NP to target).

[0095] Use the ping tool to test the RTT and packet loss rate of the NA and the NP of physical host A, and use iperf (a network performance testing tool) or a similar tool to test the available bandwidth. RTT refers to the total time it takes for a data packet to be sent from the source host to the destination host and back to the source host.

[0096] NP reports the detected network detection data (for example, the original data packet including timestamp, source IP, destination IP, RTT value, number of packet loss, etc.) to NTSM ( Figure 4 , reporting from NP to NTSM).

[0097] (i2) NTSM status aggregation and analysis engine processing: One of the core components of NTSM is its state aggregation and analysis engine, which is responsible for converting the discrete, raw network quality data collected from the network probes (NPs) of each node agent (NA) into a structured virtual-real network state view that is instructive for the entire virtual-real hybrid network. Figure 4 , the aggregation and analysis process within NTSM). Its main workflow and algorithm features include (j1) to (j5): (j1) Preprocessing and normalization of multi-source heterogeneous data: 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 the probe timestamp, source / destination IP pair, and probe type (such as RTT, packet loss rate, and throughput).

[0098] Data verification and cleaning: Eliminate obviously erroneous or incomplete data packets (such as abnormal timestamps and missing key fields).

[0099] Timestamp alignment and calibration: Taking into account the possible slight deviations in the clocks of each node agent, 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.

[0100] Data unit normalization: Convert measurements in different units (such as ms, us, bps, Mbps) into standard units to facilitate subsequent calculations.

[0101] (j2) Sliding aggregation algorithm based on time window: To smooth instantaneous fluctuations and reflect network trends over a period of time, the engine adopts a sliding aggregation method based on configurable time windows, specifically (k1) to (k4).

[0102] (k1) Window definition: Administrators can configure different aggregation time window sizes (for example, 1 second, 5 seconds, 30 seconds) and sliding steps based on the real-time requirements of the application scenario.

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

[0104] (k3) Aggregation calculation: Within the time window, one or more of the following configurable aggregation functions are used to calculate the collected data points: Average value (Mean): such as average RTT, average packet loss rate, and average bandwidth.

[0105] Weighted Mean: The data points can be weighted based on their freshness (newer data is given higher weight) or the reliability of the detection (such as the number of detections).

[0106] Median: It is insensitive to outliers and can better reflect typical network conditions.

[0107] Percentiles: For example, P95 RTT (95% of RTT values ​​are lower than this value), used to evaluate the stability of network quality.

[0108] Max / Min: Used to capture peak fluctuations.

[0109] Standard Deviation / Variance: used to measure the volatility of network status.

[0110] (k4) Outlier processing: Before aggregation, you can choose to enable an outlier removal algorithm (such as the IQR (interquartile range) method or the 3-sigma rule) to eliminate the impact of sudden, atypical measurement values ​​on the aggregation results and improve the robustness of the results.

[0111] (j3) Network status graph construction and dynamic update: The aggregated data is used to build and maintain a dynamic, logical view of the virtual and real network status, namely the "network status map".

[0112] Graph Representation: The graph is represented by nodes (representing network entities such as real drones, virtual drones, and ground stations) and edges (representing the logical communication links between them). Each edge is associated with the latest network quality parameter calculated by the aggregation algorithm.

[0113] 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 immediately. The update frequency depends on the sliding step size of the time window.

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

[0115] (j4) Status query interface and subscription / publishing mechanism: 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 specific links or the entire network.

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

[0117] Subscribe / Publish: Clients can subscribe to specific link or network events (such as link quality falling below a threshold). When NTSM detects relevant changes, it will proactively push notifications to subscribers.

[0118] (j5) Trend prediction and anomaly detection: Based on historical aggregated data, NTSM can integrate machine learning models (such as time series prediction models such as ARIMA and LSTM) to provide preliminary forecasts of network quality trends over the next period of time. Furthermore, by setting baselines and thresholds, it can detect anomalies in network conditions that deviate from normal ranges and trigger alerts.

[0119] Through data processing (i1) to (i5), flexible aggregation algorithms, and dynamic state graph management, NTSM transforms raw, discrete probe data into a structured, meaningful view of the virtual-real network status. For example, it calculates that the average RTT from 192.168.100.10 to 192.168.100.5 over the past five seconds was 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 status awareness, effectively improving the authenticity of virtual-real collaboration and the effectiveness of decision-making.

[0120] (i3) Network status application and synchronization: An advanced simulation controller running on the physical host C queries the current network connection status of the virtual drone 192.168.100.10 (i.e., the result of aggregation in step i2) through the API provided by NTSM ( Figure 4 , the simulation is applied to the query of NTSM and the return of NTSM), which is used to adjust the communication delay parameters in its control algorithm.

[0121] If the simulation task requires simulating a temporary interruption of the communication link with the real UAV 192.168.100.5, NTSM can send a command to the NA of the physical host A ( Figure 4 , NTSM to NP network simulation instructions). The NA's 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 period of time.

[0122] Example 5: Virtual drone cluster networking and DNC decision coordination across multiple hosts; Reference Figure 3 ,This embodiment describes how the system automatically builds a unified logical Layer 2 network through ,the decision and coordination of the Distributed Network Coordinator (DNC) when virtual ,UAVs are deployed on different physical hosts, specifically (l1) to (l3).

[0123] (l1) Decision logic and coordination mechanism of this distributed network coordinator (DNC): DNC plays the role of the "brain" of cross-physical host network configuration in the Central Control Plane (CCP). Its core function is to intelligently decide when, where, and how to build and manage a unified logical Layer 2 network domain for virtual drone clusters distributed on different physical hosts based on a global view and preset policies. Figure 3 , DNC perceives the deployment, makes decisions, and issues instructions to NCEs at different nodes). The decision logic and coordination mechanism of DNC mainly include the following aspects (m1) to (m5): (m1) Global virtual drone deployment situational awareness: DNC continuously obtains the latest deployment information about virtual drone instances from GIM (obtaining the IP / MAC address of the virtual drone and its physical host information) and the container orchestration platform (such as Kubernetes, if integrated). This includes: •A unique identifier for each virtual drone instance; •The physical host IP or node ID where the instance is currently running; •The logical cluster, task group, security level, or other user-defined tags / metadata to which the instance belongs; Based on this information, DNC maintains a dynamically updated view of the virtual and real network status.

[0124] (m2) Configurable networking policy rules engine: The core decision-making basis of DNC is a set of networking policy rules that are pre-configured by the administrator or dynamically updated through the API. These rules define which virtual drones should be placed in the same logical Layer 2 network domain under what conditions. The rules can be based on: Cluster ID (Group Name): For example, "All virtual drones tagged with 'Cluster Alpha', regardless of which physical host they are deployed on, should communicate with each other in the same VXLAN VNI X." Task Affinity: For example, "All virtual drones participating in the same collaborative search task number T001 need to be reachable on the second floor." Communication pattern: For example, if a group of virtual drones need to frequently perform low-latency multicast or broadcast communications (such as sharing situational awareness data), they should be placed in the same L2 domain.

[0125] Security Isolation Requirements: For example, "A 'high-security' virtual drone cluster should use an independent VNI to isolate it from other clusters." Quality of Service (QoS) tagging: If supported by the physical network or overlay technology, the DNC can select or configure an overlay network with specific bandwidth guarantees or priorities based on QoS requirements.

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

[0127] (m3) Overlay network resource management and selection: When the rule engine matches the need to build or expand a logical Layer 2 network domain, the DNC is responsible for managing and allocating the overlay network resources required to implement the network domain.

[0128] Overlay technology selection: The system supports multiple overlay technologies (such as VXLAN and GENEVE). The DNC selects the currently activated technology based on global configuration or specific policies.

[0129] Network identifier (e.g., VNI) allocation: The DNC maintains a pool of VNIs (or other overlay network identifiers). For each virtual drone group requiring 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.

[0130] 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 to 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.

[0131] (m4) Decision-making, execution and coordination process: When 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 triggers the following coordination process: 1) Instruction generation: DNC generates specific network configuration instructions for each relevant node agent (NA). The instruction content includes: The overlay network type to be operated (such as VXLAN); The VNI to be added or created (for example, 100); The local virtual drone interface (or its connected bridge) that needs to be bridged to the overlay network; List of other VTEPs corresponding to the VNI (used for tunnel establishment).

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

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

[0134] 4) Dynamic Adjustment and Maintenance: The DNC continuously monitors the lifecycle events (creation, migration, and destruction) of virtual drones. When a deployment changes (e.g., VM_A1 is destroyed, or a new VM_C1 joins Cluster Alpha), the DNC reevaluates the networking strategy and issues appropriate 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).

[0135] (m5) Integration with SDN controller: In more advanced deployments, the DNC can be integrated with the physical network's SDN controller. The DNC can communicate logical networking requirements (e.g., "VM_A1 and VM_B1 require low-latency Layer 2 interoperability") to the SDN controller, which then optimizes forwarding paths and allocates network resources at the underlay physical network level to optimize overlay network performance. As the network's control center, the SDN controller separates the central control plane (logical management) from the data plane (hardware forwarding), enabling dynamic allocation and flexible configuration of network traffic.

[0136] Through (m1) to (m5), DNC can automatically and policy-drivenly manage the network connectivity of a certain scale of distributed virtual drone clusters, ensuring that they can communicate flexibly and efficiently according to mission requirements while meeting isolation and management requirements.

[0137] For example, in actual operation: •DNC learns from GIM that the user has started VM_A1, a virtual drone belonging to Cluster Blue, on physical host A, and VM_A2, also belonging to Cluster Blue, on physical host B; • The 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; • Its overlay network resource management and selection module selects VXLAN technology and allocates or confirms the use of VNI 200 for "Cluster Blue". The DNC records the VTEP IP addresses of physical host A and physical host B; • In its decision execution and coordination process, the DNC issues a command to the NA of physical host A: join VM_A1 (through its macvlan interface) to the VXLAN network of VNI 200 and inform the VTEP IP of physical host B. The DNC issues a similar command to the NA of physical host B.

[0138] (l2) Node agent performs network configuration: The NCE of the NA of physical host A creates the vxlan_blue_200 interface according to the DNC instruction, configures the VNI to 200, and bridges the macvlan interface of VM_A1 to vxlan_blue_200 ( Figure 3 NCEA and NCEB execute the configured actions. At the same time, a VXLAN tunnel pointing to the VTEP of physical host B is configured.

[0139] The NA of physical host B performs similar operations.

[0140] (l3) Implement cross-host communication: After completing the above configuration, VM_A1 (for example, IP 192.168.100.20) on physical host A and VM_A2 (for example, IP 192.168.100.21) on physical host B are logically in the same Layer 2 broadcast domain (VNI 200). They can communicate directly with each other using their IP addresses (such as ping, UDP / TCP connection), and data packets are forwarded between physical host A and physical host B through the 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 , and finally the communication between VM_A1 and VM_B1).

[0141] Example 6: Security Policy Application This embodiment describes how the system applies security policies, such as Figure 6 As shown, it specifically includes (n1) to (n4).

[0142] (n1) The administrator configures a policy in CCP's SPM: "Prohibit all virtual drones with IP addresses in the 192.168.100.0 / 24 segment 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 , configuration from administrator to SPM).

[0143] (n2) SPM sends this policy to all registered NAs ( Figure 6 , policy distribution from SPM to LPEP).

[0144] (n3) Each NA's LPEP (for example, using iptables, which is the core firewall tool for configuring network packet filtering in Linux systems) adds rules (o1) to (o3) on its physical host's FORWARD chain or the chain for the macvlan interface (illustration) ( Figure 6 , LPEP to physical host firewall rule configuration): (o1) First, add a rule to allow the virtual drone to communicate with the specified ground station. An example command for this rule is: iptables -A FORWARD -i macvlan+ -d 192.168.1.100 -j ACCEPT Among them, -A FORWARD means appending the rule to the forwarding (FORWARD) chain; -i macvlan+ means that the rule matches traffic entering from all network interfaces whose names begin with macvlan; -d192.168.1.100 means the destination IP address of the traffic is 192.168.1.100; -j ACCEPT means performing the ACCEPT action on the matching traffic.

[0145] (o2) Next, add a rule to prevent the virtual drone from accessing the external Internet. The example command for this rule is: iptables -A FORWARD -i macvlan+ -s 192.168.100.0 / 24 ! -d 192.168.0.0 / 16 -j DROP; Here, -s 192.168.100.0 / 24 specifies that the rule matches traffic whose source IP address is in the 192.168.100.0 / 24 network segment; ! -d 192.168.0.0 / 16 specifies that the destination IP address is not in the private 192.168.0.0 / 16 network segment (here used to schematically represent non-local networks); and -j DROP drops matching traffic. Rule matching conditions can also be more precisely generated based on the address list assigned by GIM.

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

[0147] (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).

[0148] The above description is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with the technical field, within the technical scope disclosed by the present invention, who makes equivalent replacements or changes based on the technical solution and inventive concept of the present invention, should be covered by the scope of protection of the present invention.

Claims

1. An adaptive distributed network integration system for virtual and real UAV collaboration, characterized by: It includes a central control plane and at least one node agent, which is deployed on a physical host running a virtual drone container; The central control plane includes: A global identity manager configured to process the virtual drone network identity application uploaded by the node agent, allocate globally unique network identity information based on a preset address pool and allocation strategy, and record and recover the network identity information; A network topology and status manager configured to aggregate network detection data reported by each of the node agents, generate a virtual and real network status view, respond to queries and issue network simulation instructions to the node agents; A distributed network coordinator is configured to make decisions and coordinate the node agents to build a cross-host logical layer 2 network domain based on the virtual drone deployment location and networking strategy; The security policy manager is configured to define and store the network access control policy of the virtual drone and distribute it to the node agents.

2. The adaptive distributed network integration system according to claim 1, characterized in that: The node agent includes: Container runtime interface, used to monitor the lifecycle events of the virtual drone container in real time; The local identity interface is used to respond to events of the container runtime interface and apply to the global identity manager for the newly started virtual drone network identity, while configuring an independent network interface for the virtual drone container; A network detector is used to perform network quality detection according to the network simulation instruction or preset strategy, 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 policy 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: Maintaining a structured IP address resource library in the global identity manager, wherein the IP address resource library is divided into a plurality of logical hierarchical and regionalized IP address pools; Parsing the application for the virtual drone network identity and mapping it to one or more IP address pools, thereby selecting an IP address pool; An enhanced least recently used algorithm is used to select an IP address from the selected IP address pool for allocation. The enhanced least recently used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifecycle. 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 adopted enhanced least recently used algorithm.

4. The adaptive distributed network integration system according to claim 3, characterized in that: 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: Based on the Globally Unique Identifier specification, a MAC address is generated using a pre-assigned organizationally unique identifier combined with a hash value or partial bits of an assigned IP address; The generated MAC address, the assigned IP address, and the 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 status manager, the network detection data reported by each node agent is aggregated to generate a virtual and real network status view, specifically: Perform timestamp alignment and data cleaning on multi-source, heterogeneous network detection data; Calculate statistics of network detection data based on a sliding time window and remove outliers; Construct a virtual-real network status 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: In the distributed network coordinator, the networking strategy is specifically: Based on the cluster identification, mission relevance or security isolation requirements of virtual drones, matching preset rules; 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 participating in the same assigned unique network identifier.

7. The adaptive distributed network integration system according to claim 2, characterized in that: The local identity interface configures an independent network interface for the virtual drone container as follows: Call the physical host network function to create a macvlan interface and bind the network identity information assigned by the global identity manager; Move the macvlan interface into the virtual drone container network namespace.

8. 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 the startup of the virtual drone container through the container runtime interface, the local identity interface requests the 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 configures the macvlan interface for the virtual drone container; (c2) Virtual and real network status perception and synchronization: The network topology and status manager aggregates data to generate a virtual and real network status view for the simulation system to query or trigger network simulation; (c3) Unified logical network construction across hosts: The distributed network coordinator decides the networking solution 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 virtual drone container macvlan interface to the VXLAN network; (c4) Security access policy enforcement: The security policy manager distributes network access control policies to node agents, and the node agents' local policy enforcement points perform traffic control at the physical host firewall.

9. The adaptive distributed network integration method according to claim 8, characterized in that: In step (c1), the global identity manager allocates globally unique network identity information, specifically: Maintaining a structured IP address resource library in the global identity manager, wherein the IP address resource library is divided into a plurality of logical hierarchical and regionalized IP address pools; Parsing the application for the virtual drone network identity and mapping it to one or more IP address pools, thereby selecting an IP address pool; An enhanced least recently used algorithm is used to select an IP address from the selected IP address pool for allocation. The enhanced least recently used algorithm dynamically adjusts the priority of IP address selection based on address affinity, network proximity, or expected lifecycle. 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 adopted enhanced least recently used algorithm.

10. The adaptive distributed network integration method according to claim 8, characterized in that: In step (c2), the simulation system queries or triggers network simulation, specifically: Send instructions to the node agent based on the simulation requirements, injecting delays, packet loss, or blocking communication into the node agent's container network interface.

Images