A blockchain-based self-organizing network link protocol implementation method and system

Abstract

The present invention discloses a blockchain-based method and system for implementing a link protocol for an ad hoc network. The method includes the following steps: adding all routing nodes in the ad hoc network to the blockchain and making them on-chain nodes; when a routing node desires a change in the network topology, it sends a request to a master node or triggers a smart contract; the master node or smart contract initiates a node consensus on the network, and each routing node performs a consensus vote and obtains a final consensus result and routing table 1; each routing node adjusts its position based on the consensus result and runs the non-blockchain portion of the routing protocol to obtain routing table 2; and each routing node updates its local routing table based on routing table 2. The routing protocol of the present invention implements network topology switching based on blockchain technology. Even in scenarios with highly dynamic topology changes, it maintains good link quality stability and significantly improves network efficiency.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method and system for implementing a blockchain-based ad hoc network link protocol. Background Art

[0002] Due to the unique nature of unmanned clustered ad hoc networks (MANETs), links between nodes can change frequently, leading to unstable link quality. In this situation, existing routing protocols can suffer from routing jitter or routing loops, resulting in degraded network performance. To improve the stability of route discovery paths, existing techniques have proposed a method that uses link remaining time and route remaining time as criteria to evaluate the path lifetime during route discovery. However, this method is primarily applicable to on-demand planar distance vector routing protocols in wireless MANETs and offers limited benefits in improving network stability. Blockchain technology, due to its decentralized, tamper-resistant, and autonomous nature, has gained widespread adoption. Integrating blockchain technology into the link layer of MANETs enables real-time access to accurate link tables, further improving link quality stability, enhancing network efficiency, and granting the network a degree of autonomy. Summary of the Invention

[0003] The purpose of the present invention is to provide a blockchain-based self-organizing network link protocol method and system, which can effectively improve the link quality stability and improve network transmission efficiency.

[0004] The technical solution to achieve the purpose of the present invention is as follows: On the one hand, a method for implementing a blockchain-based ad hoc network link protocol is provided, the method comprising the following steps:

[0005] Add all routing nodes in the ad hoc network to the blockchain and make them on-chain nodes;

[0006] When a routing node wants to change the network topology, it sends a request to the master node or triggers a smart contract;

[0007] The master node or smart contract initiates node consensus on the network, and each routing node performs consensus voting and obtains the final consensus result and routing table 1;

[0008] Each routing node adjusts its position according to the consensus result and runs the non-blockchain part of the routing protocol to obtain routing table 2;

[0009] Each routing node updates its local routing table according to routing table 2.

[0010] Furthermore, when the network topology changes, message transmission is performed simultaneously according to the routing tables before and after the switch.

[0011] Furthermore, the master node is: scoring the routing nodes according to the reliability index, and taking the routing node with the highest score as the master node.

[0012] Furthermore, the reliability index includes three parts: hardware configuration, role level, and security level.

[0013] Furthermore, the method further comprises:

[0014] The routing node compares routing table 1 and routing table 2 to determine whether there is a difference between routing table 1 and routing table 2, and records the routing nodes with the difference.

[0015] Furthermore, the method further comprises:

[0016] If there is a difference between routing table 1 and routing table 2, continue to perform route detection n times;

[0017] After n detections, if routing table 2 is consistent with routing table 1, the process ends; otherwise, the routing nodes that cause the difference between the two tables are eliminated until the two tables are consistent.

[0018] The number of impacts of different routing nodes is recorded as an influencing factor for subsequent routing node scores.

[0019] On the other hand, a blockchain-based self-organizing network link protocol implementation system is provided, the system comprising:

[0020] The blockchain building module is used to implement: adding all routing nodes in the ad hoc network to the blockchain and making them on-chain nodes;

[0021] The network topology switching initiation module is used to implement: when a routing node wants to change the network topology structure, it sends a request to the master node or triggers a smart contract;

[0022] The blockchain routing table 1 acquisition module is used to implement: the master node or smart contract initiates node consensus on the network, each routing node performs consensus voting and obtains the final consensus result and routing table 1;

[0023] The routing table 2 acquisition module is used to implement: each routing node adjusts its own position according to the consensus result, and runs the non-blockchain part of the routing protocol to obtain routing table 2;

[0024] The local routing table updating module is used to implement: the routing node updates the local routing table according to routing table 2.

[0025] Furthermore, the system further comprises:

[0026] The routing table comparison module is used to implement: the routing node compares routing table 1 and routing table 2, determines whether there is a difference between routing table 1 and routing table 2, and records the routing nodes with differences.

[0027] Furthermore, the system further comprises:

[0028] The routing table correction module is used to achieve: if there is a difference between routing table 1 and routing table 2, continue routing detection n times; after n detections, if routing table 2 is consistent with routing table 1, then end; otherwise, eliminate the routing nodes that cause the difference between the two tables until the two tables are consistent.

[0029] Compared with existing technologies, the present invention offers significant advantages: its routing protocol uses blockchain technology to dynamically adjust network topology. This allows it to maintain good link quality stability in highly dynamic topology changes, thereby improving network efficiency. Traditional routing protocols may not be adaptable in such situations because they require constant updates to static routing tables to determine paths, which can lead to network latency and bandwidth waste. However, the routing protocol utilizes blockchain technology to record all nodes in the network and the connections between them, and calculates the optimal path. This allows for dynamic adjustment of network topology and ensures link quality stability. This will help improve network efficiency and reduce network latency and bandwidth waste.

[0030] The present invention is further described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 The present invention is a flowchart of a method for implementing a blockchain-based self-organizing network link protocol in an embodiment.

[0032] Figure 2 FIG. 1 is a schematic diagram of a self-organizing network system in an embodiment.

[0033] Figure 3 It is a schematic diagram of a self-organizing network data packet in an embodiment.

[0034] Figure 4 FIG. 4 is a schematic diagram of a REQUEST message in an embodiment.

[0035] Figure 5 FIG. 4 is a schematic diagram of a PRE_PREPARE message in an embodiment.

[0036] Figure 6 FIG. 1 is a schematic diagram of a PREPARE message in an embodiment.

[0037] Figure 7 FIG. 4 is a schematic diagram of a COMMIT message in an embodiment.

[0038] Figure 8FIG. 1 is a schematic diagram of a REPLY message in an embodiment.

[0039] Figure 9 The diagram is a schematic diagram of network topology switching in an embodiment.

[0040] Figure 10 This is a schematic diagram of the blockchain structure in one embodiment.

[0041] Figure 11 FIG. 4 is a schematic diagram of a reliability score representation in an embodiment.

[0042] Figure 12 The figure is a schematic diagram showing the correspondence between the network topology and the routing table in an embodiment.

[0043] Figure 13 The figure is a schematic diagram of generating a routing table in an embodiment.

[0044] Figure 14 This is a diagram of the implementation system structure of a blockchain-based self-organizing network link protocol in one embodiment. DETAILED DESCRIPTION

[0045] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0046] In one embodiment, combined Figure 1 , provides a method for implementing a self-organizing network link protocol based on blockchain, comprising the following steps (a) to (e):

[0047] Step (a): All routing nodes in the ad hoc network join the blockchain and become on-chain nodes.

[0048] like Figure 2As shown, 10 Raspberry Pis form an ad hoc network with a star-shaped network topology. The link protocol running locally is the Blockchain Based Ad Hoc Network Routing Protocol (BAHR). In this embodiment, the routing protocol is modified based on the Optimized Link State Routing Protocol (OLSR). BAHR has a total of 9 message types, of which 4 routing-related message types (HELLO_MESSAGE, TC_MESSAGE, MID_MESSAGE, HNA_MESSAGE) inherit OLSR and add 5 new message types related to blockchain, namely REQUEST, PRE_PREPARE, PREPARE, COMMIT and REPLY, to realize the transmission of consensus messages. As Figure 3 As shown, REQUEST message <<REQUEST,o,t,c> Φ c >Mainly includes operation o, timestamp t, request node c, request node signature Φ c These 4 parts; such as Figure 4 As shown, PRE_PREPARE message <<PRE_PREPARE,v,n,d> ,m,Φ p >, mainly including view number v, sequence number n, message digest d, original message data m, master node signature Φ p These 5 parts; such as Figure 5 As shown, PREPARE message <<PREPARE,v,n,d,i> Φ i >, mainly including view number v, sequence number n, message digest d, identity of current node i, signature Φ of node i i These 5 parts; such as Figure 6 As shown, the COMMIT message <<COMMIT,v,n,d,i> Φ i >, mainly including view number v, sequence number n, message digest d, identity of current node i and signature Φ of node i i These 5 parts; such as Figure 7 As shown, REPLY information <<REPLY,v,t,c,i,r> Φ p >, mainly including view number v, timestamp t, initiator c, master node signature Φ p The identity of the current node i and the reply 6 parts of node i; ANSN and Reserved are inherent parameters in the routing message.

[0049] Data packets transmitted between routes, such as Figure 8As shown in the figure, it consists of three parts: the packet header, the message header, and the message content. The packet header follows the OLSR packet header, defining the packet length and the packet sequence number. The message header follows the OLSR message header, defining the message type, the message validity time after the node receives the message (Vtime), the message size, the address of the node generating the message (OriginatorAddress), the maximum hop count (TimeToLive), the current hop count (HopCount), and the message sequence number (MessageSequenceNumber). The message type has been newly added with five blockchain-related message types. The message content has been newly added with five blockchain-related message types based on the OLSR protocol. These five blockchain-related message types rely on the Multipoint Relays Selector Set (MPRs) for broadcast and retransmission. Message transmission follows the DefaultForwardAlgorithm described in Section 3.4 of the OLSR protocol.

[0050] like Figure 9 As shown, these 10 (3f+1, f=3) Raspberry Pis will also deploy a blockchain, a consortium chain based on Hyperledger Fabric. During initialization, the first transaction on the chain will be generated, setting the network architecture to a star-like structure (SET TOPOLOGY="star"). This transaction will be packaged into a block, forming the genesis block, which will then be uploaded to the blockchain. The corresponding transaction results will be recorded in the ledger, setting the network architecture to a star-like structure (key=TOPOLOGY, value="star").

[0051] In this example, the Raspberry Pi network is initialized as a star topology. In addition to star topologies, the system can also be defined as a ring architecture, mesh architecture, and other topologies to accommodate a variety of network topologies.

[0052] Step (b): When a routing node wants to change the network topology, it sends a request to the master node or triggers a smart contract.

[0053] like Figure 10As shown in the figure, Node B believes that the current network topology is not suitable for the current network conditions and needs to switch to a mesh network topology. Node B initiates a consensus request REQUEST message to Node A (the master node, usually the node with the highest reliability value in the network, or designated by the system).

[0054] Basis for scoring node reliability in the network Figure 11 The reliability index is scored based on three parts: hardware configuration, role level, and security level, with a maximum score of 100. Hardware configuration includes signal transmission frequency band, battery capacity, communication latency, and GPS location; security level includes key level and number of errors; the number of errors is a deduction.

[0055] Step (c): The master node or smart contract initiates node consensus on the network. Each routing node will conduct consensus voting and obtain the final consensus result and routing table 1.

[0056] When node A receives a request from node B, it sends a PRE_PREPARE message to other nodes to initiate consensus on the network.

[0057] When node i receives the PRE_PREPARE message, if it agrees to the request, it will send a PREPARE message to other nodes; when node i receives 2f (f=3) correct PREPARE messages (including its own), it will broadcast a COMMIT message; when node i receives 2f (f=3) COMMIT messages from other consensus nodes, and verifies that the three data v, n, and d of these COMMIT messages are consistent with the COMMIT message it sent, it determines that most nodes are ready to execute the request, and then executes the request, packages the "network topology switch" transaction (SET TOPOLOGY="mesh") data into a block, and then puts the block on the chain, and updates the latest routing topology (key=TOPOLOGY, value="mesh") on the world state; according to the routing topology, look up the table to obtain the routing table 1 based on the blockchain. Figure 12 As shown, this routing table design follows the OLSR routing table format. Each row includes the destination node address (R_dest_addr), the next interface address (R_next_addr), the number of hops from the local node to the destination node (R_dist), and the local interface address (R_iface_addr). After the table lookup is complete, the node returns a REPLY message to the initiator c (node ​​B). If the initiator receives f+1 (f=3) reply messages, the request response is considered successful.

[0058] Step (d): Each routing node adjusts its position according to the consensus result and runs the non-blockchain part of the routing protocol to obtain routing table 2.

[0059] If the consensus agrees with Node B's request to switch the network topology, the current positions are adjusted according to the new network topology (mesh network topology). As shown in the figure, the relative positions of Nodes A, B, D, F, and H remain unchanged, while the remaining nodes are adjusted accordingly based on the changes in the diagram. If the consensus disagrees with Node B's request, the current network topology remains unchanged, the relative positions of all nodes remain unchanged, and the following steps are not performed.

[0060] After the time set by the system, the relative position of each node switches from the original star topology position to the current mesh topology position. Each node will perform network topology detection and send HELLO_MESSAGE, TC_MESSAGE and MID_MESSAGE to obtain the current real routing table 2, such as Figure 13 shown.

[0061] Step (e): Each routing node updates the local routing table according to routing table 2.

[0062] The local routing table is based on Routing Table 2 obtained through routing probing. If there are discrepancies between Routing Table 1 and Routing Table 2, as determined by blockchain consensus, routing probing is repeated three times. After three probing attempts, if Routing Table 2 and Routing Table 1 are consistent, the process ends; otherwise, the abnormal nodes causing the discrepancy are removed until the two tables are consistent. The nodes causing the routing table discrepancy and the number of times they were affected are recorded and used in future node reliability scoring.

[0063] When the ad hoc network switches the ad hoc network topology, that is, from step b to step e, message transmission will be carried out simultaneously according to the local routing table before the switch and the routing table 1 of the blockchain consensus after the switch.

[0064] See also Figure 14 , Figure 14 A schematic diagram of the structure of a blockchain-based self-organizing network routing protocol system provided by an embodiment of the present invention. An embodiment of the present invention also provides a blockchain-based self-organizing network routing protocol system, which includes:

[0065] The blockchain building module 10 is used to add each routing node in the ad hoc network to the blockchain;

[0066] The network topology switching initiating module 20 is used to initiate a request for a network topology change;

[0067] Blockchain routing table 1 acquisition module 30, used to obtain the final consensus result and routing table 1;

[0068] Routing table 2 acquisition module 40, used to obtain routing table 2;

[0069] The local routing table updating module 50 is configured to update the local routing table.

[0070] The routing table comparison module is used to obtain routing nodes with differences.

[0071] Regarding the specific limitations of the blockchain-based self-organizing network link protocol implementation system, please refer to the limitations of the blockchain-based self-organizing network link protocol implementation method above, and will not be repeated here. Each module in the above-mentioned blockchain-based self-organizing network link protocol implementation system can be implemented in whole or in part through software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0072] Compared with existing routing protocols, the present invention facilitates blockchain technology to achieve precise switching of network topology; before and after the network topology switch, there is a clear routing table in the network to refer to; during the network topology switch, there is a more appropriate routing table in the network for reference; ultimately, the stability of link quality is improved, and the transmission efficiency and autonomous initiative of the network are improved.

[0073] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for implementing a self-organizing network link protocol based on blockchain, characterized in that: The method comprises the following steps: Add all routing nodes in the ad hoc network to the blockchain and make them on-chain nodes; When a routing node wants to change the network topology, it sends a request to the master node or triggers a smart contract; The master node or smart contract initiates node consensus on the network, and each routing node performs consensus voting and obtains the final consensus result and routing table 1; Each routing node adjusts its position according to the consensus result and runs the non-blockchain part of the routing protocol to obtain routing table 2; Each routing node updates its local routing table based on routing table 2; The routing node compares routing table 1 and routing table 2 to determine whether there is a difference between routing table 1 and routing table 2, and records the routing node with the difference; If there is a difference between routing table 1 and routing table 2, continue to perform route detection n times; After n detections, if routing table 2 is consistent with routing table 1, the process ends; otherwise, the routing nodes that cause the difference between the two tables are eliminated until the two tables are consistent. The number of impacts of different routing nodes is recorded as an influencing factor for subsequent routing node scores.

2. The method for implementing a blockchain-based self-organizing network link protocol according to claim 1, wherein: When the network topology changes, message transmission is performed simultaneously according to the routing tables before and after the switch.

3. The method for implementing a blockchain-based self-organizing network link protocol according to claim 1, wherein: The master node is: the routing nodes are scored according to the reliability index, and the routing node with the highest score is used as the master node.

4. The method for implementing a blockchain-based self-organizing network link protocol according to claim 3, wherein: The reliability index includes three parts: hardware configuration, role level, and security level.

5. A blockchain-based self-organizing network link protocol implementation system based on the method according to any one of claims 1 to 4, characterized in that: The system comprises: The blockchain building module is used to implement: adding all routing nodes in the ad hoc network to the blockchain and making them on-chain nodes; The network topology switching initiation module is used to implement: when a routing node wants to change the network topology structure, it sends a request to the master node or triggers a smart contract; The blockchain routing table 1 acquisition module is used to implement: the master node or smart contract initiates node consensus on the network, each routing node performs consensus voting and obtains the final consensus result and routing table 1; The routing table 2 acquisition module is used to implement: each routing node adjusts its own position according to the consensus result, and runs the non-blockchain part of the routing protocol to obtain routing table 2; The local routing table updating module is used to implement: the routing node updates the local routing table according to routing table 2.

6. The blockchain-based self-organizing network link protocol implementation system according to claim 5, characterized in that: The system further comprises: The routing table comparison module is used to implement: the routing node compares routing table 1 and routing table 2, determines whether there is a difference between routing table 1 and routing table 2, and records the routing nodes with differences.

7. The blockchain-based self-organizing network link protocol implementation system according to claim 6, characterized in that: The system further comprises: The routing table correction module is used to achieve: if there is a difference between routing table 1 and routing table 2, continue routing detection n times; after n detections, if routing table 2 is consistent with routing table 1, then end; otherwise, eliminate the routing nodes that cause the difference between the two tables until the two tables are consistent.

Images