A node identification and IP address cooperative unmanned aerial vehicle cluster cross-domain routing method

Abstract

This invention discloses a cross-domain routing method for UAV swarms that coordinates node identifiers and IP addresses, belonging to the field of UAV ad hoc network communication technology. The method includes: constructing a hierarchical node identifier (NID); establishing a forward lookup table from NID to IP and a reverse recalculation bidirectional mapping from IP to NID, dynamically maintained based on timestamps, leases, and version control; the source node initiates cross-domain requests as needed based on the DID comparison result, the active gateway responds and establishes a temporary guidance state; cross-domain data packets carry a fixed DstNID and dynamic CurDstAddr and CurDID, the boundary nodes perform encapsulation forwarding or address rewriting, advancing domain by domain to the target domain; and a three-level progressive anomaly recovery is performed for guidance address failure, mapping failure, and local repair failure. This invention can eliminate the impact of address conflicts, reduce control overhead, and improve the robustness and maintainability of cross-domain communication under dynamic topology.

Description

Technical Field

[0001] This invention belongs to the field of UAV self-organizing network communication technology, and in particular relates to a cross-domain routing method for UAV swarms that coordinates node identification and IP address. Background Technology

[0002] In UAV swarm or multi-formation collaborative mission scenarios, the network architecture typically exhibits a structure characterized by "high coupling within domains and weak coupling between domains": each formation, squad, or mission group forms a relatively independent communication domain. Nodes within a domain need to exchange collaborative control and payload data frequently, while domains are interconnected through a small number of boundary nodes (such as cluster heads or gateways) to complete cross-formation information exchange and command coordination. To reduce on-site configuration costs and improve plug-and-play capabilities, existing technologies generally employ preset IP addresses, preset network segments, or lightweight address allocation mechanisms within the domain. This strategy enables the rapid formation of local area networks and communication within each domain, offering significant advantages such as simple implementation, strong compatibility, and low maintenance costs, thus leading to its widespread adoption within single domains.

[0003] However, when multiple independently configured domains need to interconnect due to temporary coordination, formation convergence, or task merging, the aforementioned end-to-end addressing mode relying on intra-domain IP addresses faces inherent flaws. Specifically, the address spaces independently planned by each domain are difficult to maintain globally consistent, easily leading to problems such as duplicate IP addresses, overlapping network segments, or network segment conflicts, resulting in ambiguity in cross-domain addressing. Under such address conflict conditions, relying solely on traditional IP routing protocols for cross-domain forwarding may cause routing entry conflicts, misdelivery of data, delivery failures, and even the formation of routing black holes and forwarding loops. Meanwhile, UAV ad hoc networks are characterized by highly dynamic topologies, significant fluctuations in link quality, and frequent node joining and leaving; inter-domain connectivity changes rapidly with node location, link quality, and energy status. This makes the address mappings and forwarding states upon which cross-domain communication depends highly prone to expiration or invalidation, frequently triggering re-resolution or re-routing processes, leading to significant service interruption risks and increased control overhead. Furthermore, as the network scales up and services include continuous services such as audio and video streaming, relying on global readdressing and network-wide convergence or large-scale state synchronization will significantly increase control overhead and convergence latency, making it difficult to stably support cross-domain collaborative communication in dynamic environments. Therefore, how to resolve addressing ambiguities caused by multi-domain address conflicts while preserving the compatibility of existing IP systems within a domain, and adapt to the cross-domain communication needs under highly dynamic topologies, has become a pressing technical challenge in this field. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a cross-domain routing method for UAV clusters that coordinates node identifiers and IP addresses, thereby resolving the issues present in the existing technologies.

[0005] To achieve the above objectives, in a first aspect, the present invention provides a method for cross-domain routing of unmanned aerial vehicle (UAV) swarms using node identifiers and IP addresses in coordination, comprising: Step 1: Construct a hierarchical node identifier. The node identifier (NID) is generated by combining the autonomous domain identifier (DID) and the unit identifier (UID) within the domain. The UID is generated by the DID and the node's current IP address through an irreversible mapping function. Step 2: Establish a bidirectional mapping mechanism between node identifiers and IP addresses. The bidirectional mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. Step 3: The source node determines whether it is cross-domain communication based on the comparison result between the DID in the NID of the target node and its own domain identifier. If so, it initiates a cross-domain request within its own domain as needed. Step 4: The candidate boundary node with cross-domain connection capability responds to the cross-domain request as the active gateway and establishes a temporary guidance state; Step 5: The source node constructs a cross-domain data packet. The packet carries a fixed final destination node identifier (DstNID) and dynamically updated current destination address (CurDstAddr) and current domain identifier (CurDID). The packet is forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packet enters the target domain and is delivered. Step Six: When the guiding address fails, the mapping item fails, or the local repair fails, perform a three-level progressive anomaly recovery.

[0006] Preferably, the irreversible mapping function in step one is represented as UID=f(DID, IP), where IP is the current IP address of the node, and the same IP address in different autonomous systems generates different UIDs after being mapped by the DID.

[0007] Preferably, the structure of the mapping term in step two is represented as follows: M=NID,Address,Tupdate,Tlease,State; Among them, T update The most recent update time, T leaseThe valid lease time for the mapped item is denoted by , and State is the current state of the mapped item.

[0008] Preferably, the cross-domain request in step three includes at least: the source node identifier (NID). s Target Node Identifier (NID) d The source node's current IP address (Addresses), request sequence number (Seq), and time-to-live (TTL) are also included.

[0009] Preferably, when the active gateway responds to the cross-domain request in step four, it returns a response message, which includes a request identifier, a response node identifier, the currently reachable IP address of the response node, the target domain that can be served, and a short validity period.

[0010] Preferably, the temporary guidance state in step four is represented as follows: R k =Req k NID d ,CurAddr,T lease State; Among them, Req k For request identifier, NID d The target node identifier is CurAddr, which is the local navigation address for the current stage. lease The validity period of the state is specified, and State is the guiding state.

[0011] Preferably, the structure of the cross-domain data packet in step five includes: Type, SrcNID, DstNID, SrcAddr, CurDstAddr, CurDID, Seq, Length, and Payload fields, wherein DstNID remains unchanged throughout the cross-domain transmission process, and CurDstAddr is dynamically updated as the autonomous system in which the packet is located changes.

[0012] Preferably, the domain-by-domain forwarding in step five includes: when the current domain identifier CurDID of the packet is not equal to the target domain identifier DID. d At that time, the boundary node updates CurDstAddr to the next-hop address Addr. next When CurDID equals DID d At that time, the target domain boundary node looks up the target node's current IP address (Address) in the table based on DstNID. d And update CurDstAddr to the Address. d .

[0013] Preferably, the three-level progressive anomaly recovery in step six includes: Level 1: When the local redirection address becomes invalid, discard the current CurDstAddr and attempt to reacquire the redirection address; The second level involves re-initiating the address resolution process to update the NID-to-IP mapping when the mapping entry fails or the target address changes. At the third level, if re-parsing still fails to yield a valid result, return to step three to re-execute the complete cross-domain communication process and delete expired guide states and mapping items.

[0014] Secondly, the present invention also provides a cross-domain routing system for drone swarms that coordinates node identifiers and IP addresses, applicable to multi-domain drone self-organizing networks, the system comprising: The identifier construction module is used to construct hierarchical node identifiers. The node identifier NID is generated by combining the autonomous domain identifier DID and the intra-domain node identifier UID, wherein the UID is generated by the DID and the node's current IP address through an irreversible mapping function. The mapping management module is used to establish a two-way mapping mechanism between node identifiers and IP addresses. The two-way mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. The request triggering module is used to enable the source node to determine whether it is cross-domain communication based on the comparison result of the DID in the NID of the target node and the identifier of its own domain, and to initiate cross-domain requests within the domain as needed when it is determined to be cross-domain communication. The gateway response module is used to enable candidate boundary nodes with cross-domain connection capabilities to respond to the cross-domain request as active gateways and establish a temporary guidance state. The domain-by-domain forwarding module is used to enable the source node to construct cross-domain data packets. The packets carry a fixed final destination node identifier DstNID and dynamically updated current destination address CurDstAddr and current domain identifier CurDID. The packets are forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packets enter the target domain and are delivered. The anomaly recovery module is used to perform a three-level progressive anomaly recovery when the guide address fails, the mapping item fails, or the local repair fails.

[0015] Compared with the prior art, the present invention has the following advantages and technical effects: This invention constructs a hierarchical node identifier with NID = DID∥UID, where UID is generated by an irreversible mapping function between DID and the node's current IP address. This feature ensures that even if the same IP address exists in different autonomous systems, the generated UID will be different due to the mapping involving DID, thus fundamentally avoiding identifier confusion caused by address conflicts. Simultaneously, NID serves as a globally unique logical identifier at the cross-domain layer, while the original IP address is still used for forwarding within the domain layer, without altering the existing IP system within the domain. This achieves deambiguity and correct delivery for cross-domain addressing without requiring unified or re-addressed addressing across the entire network.

[0016] This invention establishes a forward lookup mapping from NID to IP and a reverse recalculation mapping from IP to NID, and dynamically maintains the consistency of mapping items based on timestamps, leases, and version control. When node movement causes changes in IP address or a switch in active gateway, the reverse recalculation mapping can quickly recover the NID from the IP address combined with the DID. The timestamp and lease mechanism automatically ages out invalid mapping items, avoiding cross-domain communication failures caused by the rapid expiration of static mappings in dynamic environments. Version control ensures the orderly updating of mappings, thus maintaining the consistency and timeliness of mapping information in highly dynamic drone swarm scenarios, reducing the risk of routing oscillations and service interruptions caused by state asynchrony.

[0017] In this invention, the source node only initiates a cross-domain request within its own domain when comparing the DID in the NID with its own domain identifier and determining that cross-domain communication is required. Ordinary nodes do not need to continuously maintain external domain routing states or periodically broadcast cross-domain information when there is no need for cross-domain communication. The cross-domain control plane overhead is strictly limited to nodes and times when there is an actual need for cross-domain communication. Compared to network-wide periodic synchronization or centralized control schemes, this significantly reduces the number of control messages within the domain, making it particularly suitable for resource-constrained UAV swarm networks.

[0018] The cross-domain data packets of this invention carry a fixed final destination node identifier (DstNID) and dynamically updated current destination address (CurDstAddr) and current domain identifier (CurDID). Boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results. The source node does not need to know the complete end-to-end cross-domain path or the current IP address of the target node in advance. During the domain-by-domain advancement of the packet, DstNID always points to the final communication object, and CurDstAddr is dynamically updated according to the change of the autonomous system. Each domain boundary node only needs to determine the next hop direction based on the local mapping. Thus, under the conditions of changing topology height, sparse inter-domain connections, and time-varying connectivity, the continuity of cross-domain forwarding is maintained, avoiding the reconstruction of the entire communication link due to intermediate path breaks or gateway migration.

[0019] This invention implements a three-level progressive anomaly recovery for three scenarios: guidance address failure, mapping item failure, or partial repair failure. When anomalies such as unreachable active gateway, mapping timeout, or target address change occur during communication, the system first attempts to repair the most local guidance state. If that fails, it escalates to mapping refresh, and only then falls back to a complete cross-domain request reconstruction. This layered recovery strategy avoids triggering a global reconstruction during brief topology fluctuations, reducing unnecessary control overhead and service interruption time. At the same time, it ensures that communication can be re-established even in severe failure scenarios, significantly improving the stability and maintainability of cross-domain communication for UAV swarms in harsh environments such as high-speed movement and frequent link switching.

[0020] This invention eliminates the need for a centralized address controller, unified address planning across the entire network, frequent re-addressing, or NAT / tunnel deployment. In typical engineering scenarios such as temporary collaboration of multi-domain UAV clusters, formation convergence, and task merging, even if the independently configured IP address spaces of each domain overlap, have inconsistent network segments, or conflicting addresses, this invention can still perform cross-domain addressing and correct delivery based on NID. This significantly reduces the operational complexity and collaboration threshold of on-site deployment, and enhances the system's practicality and deployment flexibility. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a cross-domain routing method for drone clusters that coordinates node identifiers and IP addresses, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the node identifier namespace structure according to an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the control message format definition in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the data message format definition in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the bidirectional mapping between node identifiers and local addresses in an embodiment of the present invention. Figure 6 This is a schematic diagram of the cross-domain request triggering process according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the overall cross-domain process according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the experimental results of an embodiment of the present invention. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0024] Example 1 In drone swarm networks, different task groups are independently assigned domain addresses, which have only local significance. High-speed node maneuvering leads to continuous changes in boundary relationships, exit locations, and local access addresses, resulting in a lack of unified coordination mechanisms for the questions of "who is the cross-domain communication target" and "where should the data be forwarded to?"

[0025] To address the aforementioned issues, this embodiment provides a cross-domain routing method for UAV clusters that coordinates node identifiers and IP addresses. By constructing hierarchical node identifiers, establishing a bidirectional mapping mechanism, and designing a domain-by-domain forwarding process, stable support for cross-domain terminal communication is achieved.

[0026] like Figure 1 As shown, a cross-domain routing method for drone swarms that uses node identifiers and IP addresses in conjunction includes the following steps: Step 1: Construct a hierarchical node identifier. The node identifier NID is generated by combining the autonomous system identifier DID and the node identifier UID within the domain. The UID is generated by the DID and the node's current IP address through an irreversible mapping function. See Figure 2 As shown, considering that the local address currently used by the node is essentially "access and forwarding" information rather than stable cross-domain representation information, this invention defines the node identifier as a combination of the autonomous system identifier and the intra-domain node identifier: NID=DID∥UID DID is used to uniquely identify the autonomous system to which a node belongs, enabling the source node to first determine the target domain when initiating cross-domain communication. This transforms the cross-domain addressing process from "directly locating the remote node" to "first locating the target domain, and then locating the specific node within the target domain." UID is used to characterize the node's identity within its autonomous system, and is generated by a predefined irreversible mapping function between the autonomous system identifier and the node's current local address. UID = f(DID, Address) In the current implementation, Address specifically refers to the IP address, that is: UID = f(DID, IP) The use of irreversible mapping has two direct purposes: First, it avoids directly exposing the raw IP address at the protocol expression layer, so that the cross-domain layer sees the NID instead of the specific domain address; Second, since the DID is also involved in the mapping, even if the same local address exists in different autonomous systems, the UID generated by the mapping will not be the same, thereby alleviating the address conflict problem in the cross-domain environment.

[0027] It should be noted that the NID in this invention is more suitable as a logical node identifier in cross-domain routing mechanisms: it is used at the protocol expression layer to identify "who the cross-domain communication object is," but does not assume the long-term identity responsibility of being permanently decoupled from the access address. When a node's local address changes and it needs to continue participating in inter-domain communication, the system regenerates the UID and NID and updates the relevant mapping status.

[0028] See Figure 3 As shown, this invention designs four control message types: e-Hello, i-Hello, Interest, and InterestReply, for inter-domain path discovery, intra-domain node announcement, and intra-domain gateway election. The unified header of the control message includes at least: Type (message type, used to distinguish control functions such as cross-domain requests, active gateway responses, address resolution requests, and address resolution responses), SrcNID (source node identifier, used to identify the initiator of the control message), DstID (destination identifier field, which can be the target node NID, target domain DID, or broadcast identifier depending on the message type), SenderAddr (reachable address of the current sending node in this domain, used for message return and intra-domain propagation), Seq (sequence number field, used to identify duplicate messages), TTL (time to live field, used to limit the propagation range of the control message), and Length (total message length field). Following the unified header, different functional messages are appended with corresponding extended fields.

[0029] See Figure 4 As shown, this invention designs an xData type data packet, whose core fields include: Type, SrcNID, DstNID, SrcAddr, CurDstAddr, CurDID, Seq, Length, and Payload. DstNID is used to represent the final communication object at the cross-domain layer, and CurDstAddr is dynamically updated as the autonomous system (AS) of the packet changes, used to complete the actual hop-by-hop forwarding within the current AS. The data packet maintains the characteristic of "unchanged final target, variable current guiding address" throughout the cross-domain process, thereby achieving cross-domain layer target identification by NID and intra-domain forwarding by Address.

[0030] Step 2: Establish a bidirectional mapping mechanism between node identifiers and IP addresses. The bidirectional mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. Specifically, see Figure 5 As shown, in order to enable cross-domain communication to smoothly connect between "cross-domain target representation" and "intra-domain actual forwarding", this invention establishes a bidirectional mapping mechanism between node identifiers and local addresses.

[0031] This invention defines the mapping term structure as follows: M=⟨NID,Address,Tupdate,Tlease,State> Wherein, NID is the node identifier, Address is the current reachable local address of the node, Tupdate is the last update time, Tlease is the valid lease time of the mapping item, and State is the current state of the mapping item.

[0032] For forward mapping (NID → Address), the forward resolution from NID to local address cannot be directly accomplished through a function—because UID is generated by an irreversible function, the system cannot deduce the current local address of a node solely from the NID. Therefore, forward resolution must rely on a mapping cache table, parsing response results, or the local state maintained by the active gateway. The establishment of mapping relationships includes two scenarios: First, local domain nodes register or actively announce their NID and current local address to the active gateway, establishing a mapping entry for local domain nodes; second, cross-domain resolution results are written by the active gateway after obtaining the reachable address of the target node from neighboring or destination domain boundary nodes, and then writing it to the local mapping table.

[0033] For reverse mapping (Address → NID), after receiving a packet, the border node or active gateway can recalculate the UID and restore the node identifier based on the local address in the packet, assuming the local domain DID is known, using the following formula: NID = DID∥f(DID, Address) This reverse recovery is feasible because the process does not deduce the address from the UID, but rather recalculates the UID starting from the currently known DID and Address. If the same Address appears in different autonomous systems, the NID obtained from the mapping recovery will be different due to the different DIDs, thus avoiding identity confusion caused by simply relying on local addresses.

[0034] The mapping relationship is dynamically maintained using an "event-triggered update + aging and invalidation deletion" approach: when a node's local address changes, the active gateway switches, the original guidance state becomes invalid, or a boundary node detects that the original resolution result is no longer usable, the mapping item is triggered to update; when a mapping item is not reconfirmed within a specified time, it is marked as invalid and deleted, and the node does not continue to use the old address, but instead re-initiates the resolution process.

[0035] Step 3: The source node determines whether it is cross-domain communication based on the comparison result between the DID in the NID of the target node and its own domain identifier. If so, it initiates a cross-domain request within its own domain as needed. Specifically, see Figure 6 As shown, when a source node requests to send data, it first obtains the target node's node identifier (NIDd) based on the upper-layer service. Since the NID contains the Autonomous System (AS) identifier (DID) to which the target node belongs, the source node compares the DID in the target node's NID with its own AS identifier to determine whether the communication is cross-domain. If they belong to the same AS, the communication is directly completed by the existing routing protocol within that AS; if they are inconsistent, it indicates that the target node is located in an external AS, thus triggering the cross-domain communication process.

[0036] At this stage, the source node only knows "who" the target node is, that is, it knows its logical node identifier (NIDd), but it does not know the target node's current final local address, nor does it have the complete end-to-end cross-domain path in advance. Therefore, the source node does not directly attempt to send data packets to the target address, but first sends a cross-domain request message within its own domain to explicitly expose the current cross-domain communication need.

[0037] A cross-domain request message includes at least the following information: source node identifiers (NIDs), target node identifiers (NIDd), source node current local address (Addresses), request sequence number, and time-to-live (TTL) field. The source node identifier identifies the request initiator, the target node identifier indicates the final target of this cross-domain communication, the source node current local address is used for subsequent response feedback and local guidance, the sequence number is used to remove duplicate requests, and the TTL field controls the message propagation scope.

[0038] This triggering mechanism is essentially an on-demand control process. Ordinary nodes do not need to maintain a complete external domain state in the long term, nor do they need to continuously participate in cross-domain control when there is no cross-domain communication requirement; only when there is a genuine need for external domain communication will they initiate the subsequent process through a request message. This reduces the continuous dependence of intra-domain nodes on the cross-domain control plane and allows the participation of active gateways and address resolution to be tied to current real business needs.

[0039] Step 4: The candidate boundary node with cross-domain connection capability responds to the cross-domain request as the active gateway and establishes a temporary guidance state; Specifically, when a candidate boundary node receives a cross-domain request, it determines whether it can respond to the request based on its locally maintained boundary state and neighboring domain information. If a candidate boundary node has cross-domain connectivity capabilities targeting the target domain, it returns an active gateway response message to the source node. This response message should at least include: a request identifier, a responding node identifier, the responding node's currently reachable address, the target domain it can serve, and a short validity period. After receiving a valid response, the source node can designate the responding node as the active gateway for the current stage and direct subsequent data packets to that node first.

[0040] After the activity gateway completes its response, the system establishes a temporary guidance status corresponding to this cross-domain request: Rk=⟨Reqk,NIDd,CurAddr,Tlease,State> Where Reqk is the request identifier, NIDd is the target node identifier, CurAddr is the local navigation address of the current stage (usually the active gateway address for the source domain, and the current local address of the target node for the destination domain), Tlease is the state validity period, and State is the current navigation state.

[0041] The establishment of this guidance state solves the "local guidance" problem: although the source node still does not know the final destination address, it already knows "who should be sent to first for this hop", thus eliminating the need to know the complete end-to-end path in advance.

[0042] Step 5: The source node constructs a cross-domain data packet. The packet carries a fixed final destination node identifier DstNID and dynamically updated current destination address CurDstAddr and current domain identifier CurDID. The packet is forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packet enters the target domain and is delivered. Specifically, see Figure 7 As shown, after receiving the active gateway response and guidance status, the source node constructs a cross-domain data packet: DATA=⟨SrcNID,DstNID,SrcAddr,CurDstAddr,CurDID,Seq,Payload> In this invention, CurDstAddr is initially taken as the active gateway address Addrgw. Since the source domain still uses the original autonomous system routing protocol, packets are delivered to the active gateway hop by hop according to CurDstAddr, thus this invention has low intrusiveness to the intra-domain network.

[0043] When a data packet arrives at the active gateway, the active gateway determines the next-hop forwarding direction of the packet based on the boundary information and guidance status maintained locally, and performs the following updates: CurDstAddr←Addr Within the current autonomous system (AS), messages are sent to the corresponding egress node according to the existing intra-AS routing protocol, and then forwarded to the next AS. During this process, DstNID remains unchanged, while CurDstAddr is dynamically updated as the AS changes. Each AS boundary node progresses segment by segment according to its current state, without requiring the source node to have a fixed end-to-end path in advance.

[0044] Once the packet enters the target autonomous system (DIDi=DIDd), the target system boundary node looks up its corresponding current local address in its local mapping table based on the NIDd in the packet and executes: CurDstAddr←Address The final delivery is then completed step-by-step by the existing routing protocol within the target autonomous system. Throughout the process, ordinary intra-domain forwarding nodes only perform local forwarding based on CurDstAddr, and the complexity of cross-domain control is constrained to a small number of critical nodes.

[0045] Step Six: When the guiding address fails, the mapping item fails, or the local repair fails, perform a three-level progressive anomaly recovery.

[0046] Specifically, due to frequent changes in the topology of the UAV swarm network, situations such as active gateway failure, loss of boundary connections, expired guidance status, and invalid mapping items may all cause the current cross-domain communication process to be unable to continue. The core principle of the anomaly recovery in this invention is: prioritize repairing the current stage state, and re-initiate the cross-domain request when necessary.

[0047] Specifically, the abnormal recovery process can be divided into three scenarios.

[0048] The first scenario is a local guidance address failure. When a node detects that the currently active gateway is unreachable, the boundary node cannot continue guidance, or the guidance status has not been refreshed within the valid time, the system discards the old CurDstAddr and attempts to reacquire the guidance address for the current stage. If a new active gateway response or a new guidance status can be obtained within a short period of time, the current communication process continues directly.

[0049] The second scenario is when the mapping entry becomes invalid or the target address changes. When a boundary node discovers that the original mapping entry of the target node has timed out, or receives a control message indicating that the target local address has been updated, it will not continue to use the old mapping, but will re-initiate the resolution process to update the NIDd→Addressd correspondence.

[0050] The third scenario is a partial repair failure. If re-parsing still fails to yield a valid result, or if the active gateway and boundary state both fail, the system returns to step three, restarts a complete cross-domain communication process, deletes the old guidance state and expired mapping items, and re-establishes the communication loop based on the new active gateway response and parsing results.

[0051] The anomaly recovery of this invention unfolds step by step around three levels: "guidance state, mapping state, and active gateway state". First, it attempts to repair the current local state, then attempts to refresh the mapping and guidance, and finally, if necessary, it rolls back to the request triggering stage, thereby maintaining good communication continuity in a highly dynamic environment.

[0052] This invention verifies a multi-domain UAV cluster scenario built on the OMNeT++ simulation platform, and verifies the functionality of an inter-domain gateway prototype system dpdk-domain-gw built based on DPDK.

[0053] In the simulation verification, the number of autonomous systems was set to 2, with 10 to 30 nodes per system. The node movement speed was divided into three levels: low speed (5 m / s), medium speed (15 m / s), and high speed (30 m / s). The verification indicators included: inter-domain communication success rate, control plane message overhead, bidirectional mapping lookup latency, and anomaly recovery success rate.

[0054] like Figure 8 Experimental results show that the mechanism of this invention can maintain an inter-domain communication success rate of over 34% in random, high-dynamic, and high-density scenarios (high speed 30 m / s), and can achieve an inter-domain communication success rate of over 90% in reasonable formation scenarios. This represents an improvement of approximately 12.9% compared to the baseline scheme that directly uses IP addresses as cross-domain targets. Regarding control plane overhead, because this invention adopts an on-demand triggering mechanism, ordinary nodes do not need to continuously maintain the external domain state, reducing the number of discovery control messages by approximately 40% compared to the global maintenance scheme. In terms of bidirectional mapping lookup latency, the processing latency for both forward table lookup and reverse recalculation is in the microsecond range, meeting the real-time communication requirements of UAV swarms.

[0055] In the DPDK prototype system verification, the end-to-end average latency in the mesh8 scenario (8-node topology) was 17 ms, and the packet delivery rate (PDR) reached 1.000, verifying the correctness of the complete processing flow of the mechanism of this invention from Interest triggering, reach installation to XDATA hop-by-hop forwarding.

[0056] Example 2 Based on the same inventive concept, this embodiment also provides a cross-domain routing system for drone swarms that coordinates node identifiers and IP addresses, applicable to multi-domain drone self-organizing networks. The system includes: The identifier construction module is used to construct hierarchical node identifiers. The node identifier NID is generated by combining the autonomous domain identifier DID and the intra-domain node identifier UID, wherein the UID is generated by the DID and the node's current IP address through an irreversible mapping function. The mapping management module is used to establish a two-way mapping mechanism between node identifiers and IP addresses. The two-way mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. The request triggering module is used to enable the source node to determine whether it is cross-domain communication based on the comparison result of the DID in the NID of the target node and the identifier of its own domain, and to initiate cross-domain requests within the domain as needed when it is determined to be cross-domain communication. The gateway response module is used to enable candidate boundary nodes with cross-domain connection capabilities to respond to the cross-domain request as active gateways and establish a temporary guidance state. The domain-by-domain forwarding module is used to enable the source node to construct cross-domain data packets. The packets carry a fixed final destination node identifier DstNID and dynamically updated current destination address CurDstAddr and current domain identifier CurDID. The packets are forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packets enter the target domain and are delivered. The anomaly recovery module is used to perform a three-level progressive anomaly recovery when the guide address fails, the mapping item fails, or the local repair fails.

[0057] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for cross-domain routing of unmanned aerial vehicle (UAV) swarms using node identifiers and IP addresses in coordination, characterized in that, Includes the following steps: Step 1: Construct a hierarchical node identifier. The node identifier NID is generated by combining the autonomous system identifier DID and the node identifier UID within the domain. The UID is generated by the DID and the node's current IP address through an irreversible mapping function. Step 2: Establish a bidirectional mapping mechanism between node identifiers and IP addresses. The bidirectional mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. Step 3: The source node determines whether it is cross-domain communication based on the comparison result between the DID in the NID of the target node and its own domain identifier. If so, it initiates a cross-domain request within its own domain as needed. Step 4: The candidate boundary node with cross-domain connection capability responds to the cross-domain request as the active gateway and establishes a temporary guidance state; Step 5: The source node constructs a cross-domain data packet. The packet carries a fixed final destination node identifier DstNID and dynamically updated current destination address CurDstAddr and current domain identifier CurDID. The packet is forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packet enters the target domain and is delivered. Step Six: When the guiding address fails, the mapping item fails, or the local repair fails, perform a three-level progressive anomaly recovery.

2. The method according to claim 1, characterized in that, The irreversible mapping function described in step one is represented as UID=f(DID, IP), where IP is the current IP address of the node. The same IP address in different autonomous systems generates different UIDs after being mapped by the DID.

3. The method according to claim 1, characterized in that, The structure of the mapping term described in step two is as follows: M=NID,Address,Tupdate,Tlease,State; Among them, T update The most recent update time, T lease The valid lease time for the mapped item is denoted by , and State is the current state of the mapped item.

4. The method according to claim 1, characterized in that, The cross-domain request described in step three includes at least: source node identifiers (NIDs) and target node identifiers (NIDs). d The source node's current IP address (Addresses), request sequence number (Seq), and time-to-live (TTL) are also included.

5. The method according to claim 1, characterized in that, In step four, when the active gateway responds to the cross-domain request, it returns a response message. The response message includes a request identifier, a response node identifier, the currently reachable IP address of the response node, the target domain that can be served, and a short validity period.

6. The method according to claim 1, characterized in that, The temporary guidance state described in step four is represented as follows: R k =Req k ,NID d ,CurAddr,T lease ,State; Among them, Req k For request identifier, NID d The target node identifier is CurAddr, which is the local navigation address for the current stage. lease The validity period of the state is specified, and State is the guiding state.

7. The method according to claim 1, characterized in that, The structure of the cross-domain data packet described in step five includes: Type, SrcNID, DstNID, SrcAddr, CurDstAddr, CurDID, Seq, Length, and Payload fields. Among them, DstNID remains unchanged throughout the cross-domain transmission, while CurDstAddr is dynamically updated as the autonomous system in which the packet is located changes.

8. The method according to claim 7, characterized in that, Step 5, the domain-by-domain forwarding, includes: when the current domain identifier CurDID of the packet is not equal to the target domain identifier DID. d At that time, the boundary node updates CurDstAddr to the next-hop address Addr. next When CurDID equals DID d At that time, the target domain boundary node looks up the target node's current IP address (Address) in the table based on DstNID. d And update CurDstAddr to the Address. d .

9. The method according to claim 1, characterized in that, The three-level progressive anomaly recovery described in step six includes: Level 1: When the local redirection address becomes invalid, discard the current CurDstAddr and attempt to reacquire the redirection address; The second level involves re-initiating the address resolution process to update the NID-to-IP mapping when the mapping entry fails or the target address changes. At the third level, if re-parsing still fails to yield a valid result, return to step three to re-execute the complete cross-domain communication process and delete expired guide states and mapping items.

10. A cross-domain routing system for drone swarms that coordinates node identification and IP address, applicable to multi-domain drone self-organizing networks, characterized in that, The system includes: The identifier construction module is used to construct hierarchical node identifiers. The node identifier NID is generated by combining the autonomous domain identifier DID and the intra-domain node identifier UID, wherein the UID is generated by the DID and the node's current IP address through an irreversible mapping function. The mapping management module is used to establish a two-way mapping mechanism between node identifiers and IP addresses. The two-way mapping includes a forward lookup mapping from NID to IP address and a reverse recalculation mapping from IP address to NID. The mapping items are dynamically maintained for consistency based on timestamps, leases, and version control. The request triggering module is used to enable the source node to determine whether it is cross-domain communication based on the comparison result of the DID in the NID of the target node and the identifier of its own domain, and to initiate cross-domain requests within the domain as needed when it is determined to be cross-domain communication. The gateway response module is used to enable candidate boundary nodes with cross-domain connection capabilities to respond to the cross-domain request as active gateways and establish a temporary guidance state. The domain-by-domain forwarding module is used to enable the source node to construct cross-domain data packets. The packets carry a fixed final destination node identifier DstNID and dynamically updated current destination address CurDstAddr and current domain identifier CurDID. The packets are forwarded domain by domain by the active gateway. The boundary nodes perform encapsulation forwarding or deterministic address rewriting based on the mapping resolution results until the packets enter the target domain and are delivered. The anomaly recovery module is used to perform a three-level progressive anomaly recovery when the guide address fails, the mapping item fails, or the local repair fails.

Images