Communication method and system based on hybrid clustering routing protocol

Abstract

The invention provides a communication method and system based on a hybrid clustering routing protocol, and the method comprises the steps: determining a destination node by a source node, and under the condition that a local routing table stored by the source node does not have a route from the source node to the destination node, if the address of the destination node exists in an out-of-cluster destination routing mark table stored by the source node, determining that the destination node does not exist in the out-of-cluster destination routing mark table; if so, receiving a routing response message through an inter-cluster routing establishment process; if the address of the destination node does not exist in the out-of-cluster destination routing mark table stored by the source node, receiving a routing response message through an in-cluster routing establishment process; and the source node establishes a route from the source node to the destination node by using the determined route response message, and records the route in a local route table stored in the source node, so that the source node sends a data packet to the destination node. The communication method provided by the invention can be applied to a self-organizing network with remarkable heterogeneous node capability so as to improve the service quality of a routing mechanism.

Description

Technical Field

[0001] The present invention relates to the technical field of mobile self-organizing network communication, and in particular to a communication method and system based on a hybrid clustering routing protocol. Background Art

[0002] For heterogeneous node networking scenarios in communication networks, some nodes (such as cluster head nodes and gateway nodes) have low mobility, low damage rate and high communication capabilities, while other common nodes (nodes other than cluster head nodes and gateway nodes) have high mobility, high damage rate and low communication capabilities. The use of clustered network structures helps to expand and maintain network connectivity. The basic principle of inter-cluster communication in clustered networks is that the communication traffic from nodes to non-cluster nodes must be forwarded by the cluster gateway. Therefore, two relatively independent networks are formed within the cluster and between cluster gateways. Hybrid routing protocols can be used to achieve communication in clustered networks.

[0003] The most commonly used hybrid routing protocol is the ZRP protocol (Zone routing protocol). ZRP is an Ad Hoc network routing protocol that uses a cluster structure and a hybrid table-driven and on-demand routing strategy. In the ZRP protocol, a cluster is called a zone. In order to comprehensively utilize the respective advantages of on-demand routing and table-driven routing, the ZRP protocol stipulates that each node uses a table-driven routing protocol within the zone, and for the routing of nodes outside the zone, an on-demand routing mechanism similar to DSR (Dynamic Source Routing Protocol) is used to find routes. In the table-driven routing protocol, nodes maintain routes to all nodes in the entire network by periodically broadcasting routing information packets. Although the table-driven routing protocol, when the current node has a route to the destination node, the time delay required to send data packets is very small, but the routing maintenance and management requires a large overhead. In the on-demand routing protocol, the current node does not need to maintain routes to all other nodes. It only performs route discovery "on demand" when there is no route to the destination node. Therefore, there is no need to broadcast routing information periodically, which saves a certain amount of network resources. However, its disadvantages are also significant. That is, when sending data packets, if there is no route to the destination node, the data packet needs to wait for the node to establish the route before transmission, which will cause a certain delay.

[0004] The ZRP protocol has the following obvious defects: (1) The fixity of the area range restricts flexibility: The area range of each node is usually fixed, and the size of the range is determined by the number of hops. This fixed division cannot dynamically adapt to the node mobility and network topology changes. In a highly dynamic network, the size of the area may not effectively cover the range of neighboring communication requirements, thus affecting the performance of the protocol. (2) The routing overhead for nodes to maintain the intra-area is relatively high: The ZRP protocol uses a table-driven protocol within the area, and the nodes within the area need to maintain a relatively complete routing table. As the area scale increases, the overhead for nodes to maintain the routing table will increase significantly. (3) The handling of the area boundary is complex: The intersection point between the on-demand routing and the table-driven routing in the ZRP protocol is prone to efficiency problems at the area boundary. For example, when a node is near the area boundary, it may need to frequently switch or repeat the routing update and on-demand discovery, resulting in increased overhead and latency. (4) The adaptability to the heterogeneous capabilities of nodes is insufficient: The ZRP protocol assumes that the communication capabilities and mobilities of all nodes are relatively uniform, but in an actual network, the capabilities of each node may be heterogeneous, that is, the ZRP protocol is not optimized for the heterogeneity of node performance. (5) The latency of the first communication is relatively large: The on-demand routing part in the ZRP protocol needs to perform routing discovery between nodes outside the area, which will result in a relatively large latency for the first communication, especially in a large-scale network.

[0005] Therefore, how to integrate reactive and proactive routing protocols, and design a clustering communication process and protocol for an ad hoc network with significantly heterogeneous node capabilities to improve the quality of service of the routing mechanism. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a communication method and system based on a hybrid clustering routing protocol to be applicable to an ad hoc network with significantly heterogeneous node capabilities and overall improve the communication performance of the network.

[0007] One aspect of the present invention provides a communication method based on a hybrid clustering routing protocol, and the method includes the following steps:

[0008] The source node determines the destination node. When there is a route from the source node to the destination node in the local routing table stored at the source node, the source node sends a data packet to the destination node based on the route. When there is no route from the source node to the destination node in the local routing table stored at the source node, if the address of the destination node in the route request message exists in the out-of-cluster destination route tag table stored at the source node, the source node generates a route request message and receives the corresponding route reply message through the inter-cluster route establishment process. If the address of the destination node in the route request message does not exist in the out-of-cluster destination route tag table stored at the source node, the source node generates a route request message and receives the corresponding route reply message through the in-cluster route establishment process. Among them, the out-of-cluster destination route tag table is used to store the addresses of nodes outside the cluster to which the source node belongs.

[0009] The source node uses the received route reply message to establish a route from the source node to the destination node and records it in the local routing table stored, so that the source node sends a data packet to the destination node based on the established route. Among them, both the route request message and the route reply message include information on the source address and the destination address, and the route request message carries the cluster identification information of the cluster to which the source node belongs, and the route reply message carries the cluster identification information of the cluster to which the destination node belongs.

[0010] Among them, the inter-cluster route establishment process includes the following steps:

[0011] The source node sends a route request message to the gateway node of the cluster to which the source node belongs, so that the gateway node of the cluster to which the source node belongs determines that the destination node address in the route request message is the address of an out-of-cluster node based on the in-cluster address advertisement message, determines the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs through the stored inter-cluster gateway routing table, and forwards the route request message to the gateway node of the cluster to which the destination node belongs using the proactive routing protocol.

[0012] The source node receives the route reply message corresponding to the route request message from the gateway node of the cluster to which the source node belongs through the reverse route. Among them, the gateway node of the cluster to which the source node belongs is used to, after receiving the route reply message sent by the gateway node of the cluster to which the destination node belongs and determining that the node corresponding to the destination address in the route reply message is a node in this cluster, change the cluster identification information of the cluster to which the destination node belongs carried in the route reply message to the cluster identification information of the cluster to which the source node belongs, and send the changed route reply message to the source node.

[0013] The in-cluster route establishment process includes the following steps:

[0014] Through the on-demand routing protocol, the source node broadcasts a route request message to its neighbor nodes and receives the route reply message generated by the neighbor nodes of the destination node according to the reverse route.

[0015] Among them, the intra-cluster address advertisement message is generated by the cluster head node and is used to unicast the addresses of all nodes within the same cluster to the gateway nodes of the same cluster through the active routes existing between the gateway nodes and the cluster head nodes of each cluster. The intra-cluster address advertisement message includes the following field information: the cluster identification information, network address, and mask of the cluster to which the cluster head node belongs.

[0016] In some embodiments of the present invention, the proactive routing protocol is the OLSR routing protocol, and the on-demand routing protocol is the AODV routing protocol.

[0017] The destination address in the routing request packet is the same as the source address in the routing reply packet, and the source address in the routing request packet is the same as the destination address in the reply packet.

[0018] The routing request packet is the first routing request packet or the second routing request packet. Among them, the destination address of the first routing request packet is the address of the destination node, and the destination address of the second routing request packet includes the address of the gateway node of the cluster to which the source node belongs and the address of the destination node.

[0019] In some embodiments of the present invention, the source node generates a routing request packet and receives the corresponding routing reply packet through the intra-cluster routing establishment process, including:

[0020] The source node generates a first routing request packet and receives the routing reply packet corresponding to the first routing request packet through the intra-cluster routing establishment process; or

[0021] The source node generates a first routing request packet, receives the inter-cluster routing notification packet sent by the cluster head node of the cluster to which the source node belongs based on the inter-cluster advertisement process, and records the destination address in the first routing request packet in the inter-cluster destination routing mark table. The source node generates a second routing request packet and determines the routing reply packet received by the source node through the inter-cluster routing establishment process.

[0022] Among them, the inter-cluster routing notification packet includes the following information: the inter-cluster destination address including the destination address in the first routing request packet, and the address of the gateway node of the cluster to which the source node belongs.

[0023] In some embodiments of the present invention, the source node sends a routing request packet to the gateway node of the cluster to which the source node belongs, including:

[0024] If there is a route from the source node to the gateway node of the cluster to which the source node belongs in the local routing table of the source node, the source node sends a second routing request packet to the gateway node of the cluster to which the source node belongs through the on-demand routing protocol.

[0025] If there is no route from the source node to the gateway node of the cluster to which the source node belongs in the local routing table of the source node, the source node generates a second route request message based on the out-of-cluster advertisement process upon receiving an out-of-cluster route notification message from the cluster head node of its own cluster, and sends it to the gateway node of the cluster to which the source node belongs through the in-cluster route establishment process.

[0026] In some embodiments of the present invention, the out-of-cluster advertisement process includes the following steps:

[0027] The source node sends a first route request message to the cluster head node of the cluster to which the source node belongs through an on-demand routing protocol. After the cluster head node of the cluster to which the source node belongs determines that the destination address in the received first route request message is not the address of a node in its own cluster according to the stored set of all node addresses in the cluster, it generates an out-of-cluster route notification message and sends it to the source node.

[0028] In some embodiments of the present invention, the method further includes:

[0029] After the source node receives the out-of-cluster route notification message, if it does not receive a route reply message within the set time, the source node regenerates a second route request message and sends it to the gateway node of the cluster to which the source node belongs using the on-demand routing protocol..

[0030] In some embodiments of the present invention, through the on-demand routing protocol, the source node generates a route request message, broadcasts the route request message to the neighbor nodes of the source node, and receives a route reply message generated by the neighbor nodes of the destination node according to the reverse route, including:

[0031] The source node generates a route request message and broadcasts the route request message to the neighbor nodes of the source node through the on-demand routing protocol, so that the intermediate node determines whether the cluster identification information of the cluster to which the source node belongs in the received route request message corresponds to the cluster identification information of the cluster to which the intermediate node belongs using the stored local routing table; wherein, the local routing table includes the cluster identification information of the cluster to which the node storing the local routing table belongs;

[0032] In the case where the cluster identification information corresponds, if the intermediate node is the destination node, or there is a route from the intermediate node to the destination node in the local routing table stored by the intermediate node, the source node receives the route reply message generated by the intermediate node through the reverse route.

[0033] Another aspect of the present invention provides a communication method based on a hybrid clustering routing protocol, and the method includes the following steps:

[0034] The gateway node receives a message carrying cluster identification information. If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing request message, it determines whether the destination node address in the routing request message is the address of a node outside the cluster based on the intra-cluster address advertisement message; if it is the address of a node outside the cluster, it determines the route from the gateway node of the source node's cluster to the gateway node of the destination node's cluster based on the intra-cluster address advertisement message, and forwards the routing request message to the gateway node of the destination node's cluster using the proactive routing protocol; if it is not the address of a node outside the cluster, it forwards it through the on-demand routing protocol or generates a routing reply message.

[0035] If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is an intra-cluster address advertisement message, then an inter-cluster gateway routing table is formed based on the intra-cluster address advertisement message and the routes between each gateway node.

[0036] If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing reply message, then it determines whether to forward it through the on-demand routing protocol based on the destination address in the routing reply message.

[0037] If the cluster identification information in the received message is different from the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing reply message, if it is determined based on the gateway node's intra-cluster address advertisement message that the destination address in the routing reply message is the address of a node within the cluster, then the cluster identification information of the destination node's cluster carried in the routing reply message is changed to the cluster identification information of the source node's cluster, and the changed routing reply message is sent to the source node through the on-demand routing protocol; if it is determined based on the gateway node's intra-cluster address advertisement message that the destination address in the routing reply message is not the address of a node within the cluster, then it is forwarded through the stored inter-cluster gateway routing table; among them, the intra-cluster address advertisement message is generated by the cluster head node and is used to unicast the addresses of all nodes within the same cluster to the gateway nodes within the cluster through the active routes existing between the gateway nodes and the cluster head nodes of each cluster; the intra-cluster address advertisement message includes the following field information: the cluster identification information of the cluster to which the cluster head node belongs, the network address, and the mask.

[0038] In some embodiments of the present invention, the inter-cluster gateway routing table stored by the gateway node includes the routing paths from this gateway node to all destination networks or destination nodes existing in the entire communication network, and is formed in the following manner:

[0039] Use the proactive routing protocol to determine the routes between each gateway node.

[0040] Each gateway node generates a corresponding gateway association set table based on the intra-cluster address announcement message sent by the cluster head node of the same cluster, generates a cluster network association message carrying the cluster identification information of the cluster to which the gateway node belongs according to the gateway association set table, and uses the routing between each gateway node to send the cluster network association message to other gateway nodes, so that each gateway node forms an inter-cluster gateway routing table.

[0041] Another aspect of the present invention provides a communication system based on a hybrid clustering routing protocol, including a processor, a memory, and a computer program / instructions stored on the memory. The processor is used to execute the computer program / instructions. When the computer program / instructions are executed, the system implements the steps of the method described in any one of the above embodiments.

[0042] A communication method and system based on a hybrid clustering routing protocol proposed by the present invention implement network layer interconnection among intra-cluster nodes by using an improved on-demand routing protocol, and implement full-network interconnection among cluster gateways by using an improved proactive routing protocol, so as to cope with the routing establishment and communication process of an ad hoc network with significantly heterogeneous node capabilities. Through the coordinated cooperation of the intra-cluster and inter-cluster communication mechanisms, it can not only respond quickly when establishing a communication path, but also maintain the effectiveness of the path through regular updates, which helps to improve the robustness and flexibility of the network, reduce communication delays and adapt to the dynamic network environment.

[0043] The additional advantages, objects, and features of the present invention will be partially described below, and will become partially apparent to those of ordinary skill in the art after studying the following text, or can be learned from the practice of the present invention. The objects and other advantages of the present invention can be achieved and obtained through the structures specifically pointed out in the specification and the drawings.

[0044] Those skilled in the art will understand that the objects and advantages that can be achieved by the present invention are not limited to the above specifically described, and the above and other objects that the present invention can achieve will be more clearly understood according to the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The drawings described herein are used to provide a further understanding of the present invention, form a part of this application, and do not limit the present invention. In the drawings:

[0046] Figure 1 It is a schematic flow chart of the cluster head node processing messages in an embodiment of the present invention.

[0047] Figure 2 It is a schematic diagram of the generation process of the inter-cluster gateway routing table in an embodiment of the present invention.

[0048] Figure 3The figure is a flow chart of the intra-cluster routing establishment process and the inter-cluster routing establishment process in one embodiment of the present invention.

[0049] Figure 4 The figure is a schematic diagram of a flow chart of a common node receiving and processing a message in one embodiment of the present invention.

[0050] Figure 5 FIG. 4 is a schematic diagram of a process for establishing intra-cluster routing in another embodiment of the present invention.

[0051] Figure 6 The figure is a schematic diagram of a flow chart of a source node sending a message in one embodiment of the present invention.

[0052] Figure 7 The figure is a schematic diagram of a flow chart of a gateway node processing a received message in one embodiment of the present invention.

[0053] Figure 8 FIG. 4 is a schematic diagram of the process of establishing inter-cluster routing in another embodiment of the present invention. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0055] It should also be noted that, in order to avoid obscuring the present invention due to unnecessary details, only structures and / or processing steps closely related to the solutions according to the present invention are shown in the accompanying drawings, while other details that are not closely related to the present invention are omitted.

[0056] It should be emphasized that the term “include / comprises” when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0057] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0058] In cluster networks, two relatively independent networks are formed between the nodes in the cluster and the gateway nodes of each cluster. Hybrid routing protocols can be used for node communication in self-organizing networks. Reactive routing protocols can respond quickly to link breaks and do not require real-time maintenance of routing tables, but the initial route discovery process is slow. Active routing protocols exchange and upgrade topology information through periodic messages. Routes are always available immediately when needed, but they occupy a lot of bandwidth and resources and have poor adaptability to dynamically changing topologies. Combining the advantages and disadvantages of these two protocols to optimize the design of cluster communication processes and protocols has a significant impact on the quality of service of routing mechanisms in self-organizing networks with significant heterogeneous node capabilities.

[0059] If an active routing protocol (such as the OLSR (Optimized LinkState Routing) protocol) is used in the communication network formed by the nodes in the cluster, although the protocol can reduce the network overhead through MPR (MultiPoint Relay) selection and other methods, in the face of the high node damage rate of ordinary nodes in the cluster, the communication overhead of the active routing protocol will still occupy a large amount of communication capacity. Although the routing overhead can be reduced by improving the HELLO detection cycle, the routing accessibility will be greatly reduced, thereby affecting the communication quality. Since on-demand routing protocols (such as the AODV (Ad hoc On-demand Distance Vector Routing) routing protocol) make the overall routing overhead smaller, and its rapid response to link breakage in active routing can effectively cope with the challenge of high node damage rate in clustered network scenarios, this application uses an on-demand routing protocol for communication between nodes in the cluster. In addition, considering that the main disadvantage of the on-demand routing protocol compared to the active routing protocol is the slow routing establishment process, that is, the use of the on-demand routing protocol in a large-scale network will result in a large initial communication delay, and the network composed of the gateway nodes of each cluster is relatively stable during cross-cluster communication, the present application adopts an active routing protocol between the gateway nodes of each cluster to reduce the establishment delay of inter-cluster communication, and can also appropriately increase the HELLO detection cycle of the OLSR protocol to reduce routing overhead. Combining the existing hybrid routing protocols, as well as the advantages and disadvantages of the on-demand routing protocol and the active routing protocol, the present application innovatively proposes to adopt an improved on-demand routing protocol during intra-cluster communication, and adopt an improved active routing protocol during cross-cluster communication to achieve communication between cluster gateway nodes, so as to cope with self-organizing networks with significant heterogeneous node capabilities.

[0060] To simplify the description, the following uses the OLSR active routing protocol for cross-cluster communication and the AODV on-demand routing protocol for intra-cluster communication as an example to describe the routing establishment and communication process of this application. This application is also applicable to other types of active routing protocols and on-demand routing protocols, which will not be given examples here.

[0061] The source node determines the destination node. When there is a route from the source node to the destination node in the local routing table stored in the source node (i.e., the route between the source node and the destination node is valid), the intra-cluster routing establishment process and the inter-cluster routing establishment process do not work, and the source node and the destination node can communicate normally. At this time, the source node directly determines the route from the source node to the destination node from the stored local routing table according to the destination address (Destination Address, i.e., the address information of the destination node) in the data packet, and forwards the data packet to another interface (i.e., the source node sends the data packet to the destination node based on the route stored in the local routing table). In this process, when the data packet is forwarded between nodes in the same cluster, it can be implemented using the on-demand routing protocol. When the data packet needs to be forwarded between nodes in two different clusters, the active routing protocol is used to forward the data packet from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs, and the cluster identification information carried by the transmission message is changed. When the source node needs to send a data packet to the destination node, but the route between the source node and the destination node is invalid (i.e., there is no route from the source node to the destination node in the local routing table stored in the source node), the source node generates a routing request message, and uses the inter-cluster routing establishment process and the intra-cluster routing establishment process proposed in the present invention to establish a valid route between the source node and the destination node, so as to realize the message transmission between the source node and the destination node.

[0062] The present application combines an active routing protocol and an on-demand routing protocol to form a hybrid routing protocol, and designs a routing mechanism for coordinated intra-cluster and inter-cluster communications in the scenarios of cross-cluster communication and intra-cluster communication, which can not only respond quickly when the communication path is established, but also maintain the validity of the path through regular updates; and the present application introduces cluster identification information that uniquely identifies a cluster when sending and receiving messages in each cluster network, and designs data structures of routing protocols such as intra-cluster address announcement messages and extra-cluster routing notification messages; in addition, in addition to the local routing table stored in each node, the present application constructs an extra-cluster destination routing tag table for each node, and constructs an inter-cluster routing tag table at the cluster gateway node, so that cross-cluster communication and intra-cluster communication have good scalability.

[0063] Each node in the clustered network of the present application stores a local routing table and an out-of-cluster destination routing tag table. The local routing table may include the routes between the node storing the local routing table and the nodes in the same cluster, and may also include the routes between the node storing the local routing table and the nodes in different clusters. The present application can construct a local routing table for node storage based on the routing table of the AODV routing protocol, and introduce the cluster identification information of the cluster to which the node storing the local routing table belongs into the local routing table to determine the cluster to which each node belongs. The data structure of the local routing table can be shown in Table 1. For example, the local routing table may include the following field information: destination address (or destination IP address, Destination IP Address), destination sequence number (Destination Sequence Number), cluster identification information of the cluster to which the node storing the table belongs, destination node flag (used to indicate whether the node corresponding to the destination address is a node in the cluster, that is, whether the node storing the local routing table and the node corresponding to the destination address are nodes in the same cluster), legal destination sequence number flag, other states and routing flags (including legal, illegal, repairable and being repaired, etc.), network interface, number of hops (the number of hops required from the node storing the routing table to the node corresponding to the destination address), next hop (IP address of the next hop node), upstream node list and node lifetime. Among them, the cluster identification information mentioned in the present application may be a cluster ID, or other information that uniquely identifies a cluster, and the present invention is not limited to this.

[0064] Table 1 Data structure of local routing table

[0065] Destination address (the address of the destination node) Destination sequence number Cluster identification information Destination node flag: whether it is in the cluster Other status and routing flags: legal, illegal, repairable, repairing Network Interface Hop count - the number of hops required to reach the destination node Next hop Upstream node list Survival time

[0066] In addition, the route request message generated and sent by the source node mentioned in the present application may be a first route request message (RREQ, Route Request) or a second route request message (OCRQ, Outer Cluster Request); wherein the destination address of the first route request message is the address of the destination node, and the destination address of the second route request message includes the address of the gateway node of the cluster to which the source node belongs and the address of the destination node. As shown in the following table, the formats of the first route request message and the second route request message are shown in Table 2 and Table 3, respectively.

[0067] Table 2 Data structure of the first routing request message

[0068]

[0069] As can be seen from Table 2, by dividing the reserved 11 bits of the route request frame structure of the AODV protocol into 9 bits of cluster identification information and 2 bits of reserved bits, the format of the first route request message can be obtained, so as to achieve the purpose of the route request message carrying the cluster identification information.

[0070] Table 3 Data structure of the second routing request message

[0071]

[0072] Among them, the message type (Type) in the second route request message can take a value of 5, indicating that the message type is a second route request message (used to request a route outside the cluster). The cluster identification information is used to uniquely identify a cluster, for example, the cluster identification information can be a cluster ID. The hop count (Hop Count) indicates the number of forwarding hops from the source node to the node that processes the second route request message. The route request identification code indicates the OCRQ ID, and can be used together with the OCRQ ID and the source address to uniquely identify a second route request message. The destination address indicates the address of the gateway node of the cluster to which the source node that generates the second route request message belongs. According to the destination address in the second route request message, the second route request message can be forwarded from the source node in the cluster to the gateway node of the cluster, so that it can be subsequently forwarded to the destination node through the destination gateway (the gateway node of the cluster to which the destination node belongs). The destination sequence number can indicate the latest sequence number of the node corresponding to the destination address that has been received by the source node and reached through any route. The source address is the IP address of the node that generates the second route request message. The source sequence number is the latest sequence number of the node that generates the second route request message. The out-of-cluster destination address is the IP address of the destination node outside the cluster requested by the second route request message. The out-of-cluster destination sequence number represents the latest sequence number of the destination node outside the cluster requested by the second route request message. As can be seen from Table 3, the reserved 11 bits of the route request frame structure of the AODV protocol are divided into 9 bits of cluster identification information and 2 bits of reserved bits, and the fields of the out-of-cluster destination address and the out-of-cluster destination sequence number are added to obtain the format of the second route request message.

[0073] The route reply message (RREP, Route Reply) in this application is also determined according to the route reply frame of the AODV routing protocol, and its format is shown in Table 4. As can be seen from Tables 2 to 4, both the route request message and the route reply message include field information of the source address and the destination address, the destination address in the route request message is the same as the source address in the route reply message, and the source address in the route request message is the same as the destination address in the reply message. In addition, the route request message carries the cluster identification information of the cluster to which the source node belongs, and the route reply message carries the cluster identification information of the cluster to which the destination node belongs.

[0074] Table 4 Data structure of routing reply message

[0075]

[0076] The format of the out-of-cluster destination routing tag table may be as shown in Table 5. The out-of-cluster destination routing tag table stores the addresses of out-of-cluster nodes (nodes in different clusters from the node storing the table), and may be used to determine whether the destination node corresponding to the destination address in the routing request message belongs to a different cluster network from the source node. If the address of the destination node exists in the out-of-cluster destination routing tag table stored by the source node (in this case, the destination node and the source node are nodes in different clusters), the source node may receive the routing response message corresponding to the routing request message through the inter-cluster routing establishment process; if the address of the destination node does not exist in the out-of-cluster destination routing tag table stored by the source node, the source node may receive the routing response message corresponding to the routing request message through the intra-cluster routing establishment process. In addition to the address information of the out-of-cluster node, the out-of-cluster destination routing tag table may also include information such as the survival time of the out-of-cluster node. The out-cluster nodes (or addresses of out-cluster nodes) stored in the out-cluster destination routing tag table of each node may be different, and the node address stored in the out-cluster destination routing tag table may be the address of an out-cluster node for which no route has been established with the node storing the table, or may be the address of an out-cluster node for which a route has been established with the node storing the table.

[0077] Table 5 Inter-cluster destination routing tag table

[0078] The address of the destination node outside the cluster Survival time … …

[0079] In some embodiments of the present invention, the out-cluster destination routing tag table is formed according to an out-cluster routing announcement message (OCRA, Outer Cluster Routing Announcement) sent by the cluster head node to other nodes, so the out-cluster destination routing tag table may not include the addresses of all out-cluster nodes. Considering that there may be a situation where the destination node is an out-cluster node, and the address of the destination node does not exist in the out-cluster destination routing tag table stored by the source node, there may be two situations, that is, the source node generates a routing request message and receives a corresponding routing response message through the intra-cluster routing establishment process, including: the source node generates a first routing request message and receives a routing response message corresponding to the first routing request message through the intra-cluster routing establishment process; or the source node generates a first routing request message (RREQ) and receives an out-cluster routing announcement message sent by the cluster head node of the cluster to which the source node belongs based on the out-cluster announcement process; the source node records the destination address in the first routing request message in the out-cluster destination routing tag table, generates a second routing request message, and determines the routing response message received by the source node through the inter-cluster routing establishment process. Moreover, in the process of the cluster head node returning the out-cluster route notification message to the source node, the intermediate node that the OCRA passes through can also update its stored out-cluster destination route tag table according to the OCRA, and record the information of the gateway node of the cluster (including the gateway address and gateway serial number, etc.), that is, the intermediate node that the OCRA passes through can also record the out-cluster destination address in the OCRA in the stored out-cluster destination route tag table. The data structure of the out-cluster route notification message can be shown in Table 6.

[0080] Table 6 Data structure of cluster external routing notification message

[0081]

[0082] The specific meanings of each field in the data structure of the out-cluster route notification message are as follows: The message type (Type) can take a value of 4, which is used to indicate that the message is an out-cluster route notification message. The cluster identification information is used to uniquely identify a cluster. The ordinary node can determine whether the received out-cluster route notification message is a message sent by the cluster head node of the cluster to which the ordinary node belongs by identifying the cluster identification information. If it is a message sent by an out-cluster node, the message is discarded (the out-cluster destination route tag table is not updated according to the message, and the message is not forwarded). The reserved bit (Reserved) can be set to 0 when the cluster head node sends the out-cluster route notification message, and each node may not process the out-cluster route notification message when it receives it. The destination address in the out-cluster route notification message is the source address in the first route request message received by the cluster head node. The destination sequence number is the latest sequence number of the source node corresponding to the source address in the first route request message received by the cluster head node. The source address (Originator Address) is the IP address of the node that generates the out-cluster route notification message, that is, the IP address of the cluster head node. The gateway address is one of the IP addresses of the gateway node of the cluster to which the cluster head node that generates the out-of-cluster route notification message belongs (i.e., one of the IP addresses of the cluster gateway of the cluster). The gateway serial number is the latest serial number of the gateway node corresponding to the gateway address. The out-of-cluster destination address includes the destination address in the first route request message received by the cluster head node. That is, the out-of-cluster route notification message may include the following information: the out-of-cluster destination address (if the out-of-cluster destination address in the OCRA includes the destination address in the first route request message, then the destination address in the first route request message is determined to be the address of the out-of-cluster node), and the address of the gateway node of the cluster to which the source node belongs.

[0083] As an example, if the destination node's address does not exist in the out-of-cluster destination routing tag table, the destination node may be an out-of-cluster node or an in-cluster node. Figure 1As shown, after the cluster head node receives the first route request message (which may also be the second route request message) sent by the source node in the same cluster, if the address of the destination node in the first route request message is the address of a node outside the cluster (the source node and the destination node are nodes in different cluster networks), the cluster head node sends an OCRA to the source node, so that the source node can determine that the destination node is a node outside the cluster according to the OCRA, add the address of the destination node to the outside-cluster destination route tag table, and establish a route from the source node to the destination node based on the inter-cluster route establishment process; if the destination address in the first route request message is the address of a node within the cluster (the source node and the destination node are nodes in different cluster networks), the cluster head node sends an OCRA to the source node, so that the source node can determine that the destination node is a node outside the cluster according to the OCRA, add the address of the destination node to the outside-cluster destination route tag table, and establish a route from the source node to the destination node based on the inter-cluster route establishment process; is a node in the same cluster), the source node can establish a route from the source node to the destination node based on the intra-cluster routing establishment process (at this time, the cluster head node does not return OCRA, and only forwards messages as a common node): the cluster head node determines whether its own node is the destination node, and whether the local routing table stored in the cluster head node is available. At the same time, the cluster head node will also update the reverse route from the cluster head node to the source node. If: the cluster head node is the destination node or the local routing table is available, the cluster head node can return a routing response message to the source node according to the reverse route, otherwise it continues to forward the first routing request message to neighboring nodes (except the source node of the first routing request message).

[0084] In some embodiments of the present invention, the out-cluster notification process is mainly implemented through intra-cluster communication, including the following steps: through an improved on-demand routing protocol, the source node sends a first routing request message (the source address in the RREQ is the address of the source node, and the destination address is the address of the destination node) to the cluster head node of the cluster to which the source node belongs; after the cluster head node of the cluster to which the source node belongs receives the RREQ, it determines that the destination address in the first routing request message is not the address of the node of this cluster (that is, the node corresponding to the destination address in the RREQ and the cluster head node belong to a node of a different cluster), generates an out-cluster routing notification message (OCRA) and sends it to the source node through reverse routing.

[0085] In addition to the local routing table and the out-of-cluster destination routing tag table mentioned above, the cluster head node also stores the address information of all nodes in the cluster, which can be stored in the form of a collection or in other forms, but the present invention is not limited to this. In addition, the gateway node also stores the intra-cluster address announcement message (ICAA, InnerCluster Adresses Announcement) sent by the cluster head node of the same cluster, and the inter-cluster gateway routing table formed based on the intra-cluster address announcement message and the routing between each gateway node. The data structure of the intra-cluster address announcement message is shown in Table 7. It can be seen from the following table that ICAA at least includes a node address (IP address and mask, etc.) and a subnet address (subnet number and mask, etc.).

[0086] Table 7 Data structure of intra-cluster address announcement message

[0087]

[0088] Among them, the message type (Type) can take a value of 6, which is used to indicate that the message is an intra-cluster address announcement message sent by the cluster head node; the cluster identification information is used to uniquely identify a cluster. The nodes between the cluster head node and the gateway node of this cluster can determine whether the message is a data packet generated in the cluster through the cluster identification information. If not, the message is directly discarded. The destination address is the IP address of a gateway node in the cluster, that is, the IP address of a gateway node in the cluster to which the cluster head node that sends the intra-cluster address announcement message belongs. The destination sequence number is the latest sequence number of the gateway node corresponding to the destination address. The source address refers to the IP address of the cluster head node that generates the intra-cluster address announcement message. The source sequence number is the latest sequence number of the cluster head node that generates the intra-cluster address announcement message. The announcement message sending period is the periodic interval of the cluster head node sending the intra-cluster address announcement message, which can be jointly represented by the integer a represented by the high 4 bits of this domain and the integer b represented by the low 4 bits of this domain: Announcement message sending period (seconds) = C×(1+a / 16)×2 b (where C represents the scaling factor). The effective time of receiving the message is the effective storage time after the gateway node receives the cluster address announcement message. The number of addresses represents the number of IP addresses or network addresses of the nodes in the cluster to which the cluster head node that initiates the cluster address announcement message belongs. The network address (NetworkAddress) is the IP address of the node in the cluster or the network address of the node in the cluster. The mask address (Netmask) is the mask address corresponding to the network address.

[0089] In some embodiments of the present invention, the prerequisite for the gateway node to store the intra-cluster address announcement message (ICAA) and the inter-cluster gateway routing table is that there is an active route (i.e., an active path) between the cluster head node and the gateway node in the same cluster, so the cluster head node can periodically unicast the intra-cluster address announcement message to the gateway nodes in the same cluster.

[0090] The inter-cluster gateway routing table in this application can be formed based on ICAA. The specific process is as follows: use the active routing protocol to determine the routing between each gateway node; each gateway node generates a corresponding gateway association set table based on the ICAA sent by the cluster head node of the same cluster, and generates a cluster network association message (HNA, Host and Network Association) carrying the cluster identification information of the cluster to which the gateway node belongs according to the gateway association set table, and uses the routing between each gateway node to send the cluster network association message to other gateway nodes, so that each gateway node forms an inter-cluster gateway routing table. Figure 7As shown, if the cluster identification information in the message received by the gateway node is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is an intra-cluster address announcement message, then an inter-cluster gateway routing table is formed based on the intra-cluster address announcement message and the routes between each gateway node.

[0091] More specifically, the generation process of the inter-cluster gateway routing table is as follows: Figure 2 As shown, including:

[0092] Step S01: The gateway nodes of adjacent clusters periodically send HELLO packet messages carrying cluster identification information, so each gateway node can establish a local link information base and an adjacent area information base through HELLO messages. The MPR set for information flooding optimization of each gateway node is calculated by the MPR multi-point relay selection algorithm (that is, only MPR nodes can be used for flooding information). Each gateway node periodically notifies the multi-interface association message MID (Multiple Interface Device) of the gateway node to the adjacent cluster gateway nodes in the MPR set, and the MID message is broadcast and forwarded by the MPR node. Among them, each gateway node maintains the interface information of itself and other gateway nodes in the communication network, and the MID records the interface address of the gateway node and the cluster identification information of the cluster where the gateway node is located. Each node that has been selected as MPR floods the topology control message (TC, Topology Control, which records the neighbor relationship between gateway nodes and the cluster identification information of neighboring gateway nodes) in the communication network, so that each gateway node establishes a topology information database and forms a route between all gateway nodes in the communication network. The process of forming routes between various gateway nodes in the above step S01 can be the same as the process of establishing routes using the OLSR routing protocol. The message formats of HELLO messages, TC messages, and MID messages can also be the same as the formats of messages in the existing OLSR routing protocol, and these messages all carry the cluster identification information of the cluster to which the node generating the message belongs.

[0093] Step S02: In this application, it is assumed that the cluster head node of each cluster network stores the address information of all nodes in the cluster, and the cluster head node of each cluster always maintains an active route to the gateway node, so that the cluster head node can periodically generate intra-cluster address announcement messages, and based on the on-demand routing protocol, forward the generated ICAA to the gateway node of the same cluster through the intra-cluster routing communication process (that is, the cluster head node of each cluster can periodically inform the gateway node of the cluster of the node address and subnet address of all nodes in the cluster). Each gateway node can maintain the gateway association set table shown in Table 8 according to the intra-cluster address announcement message sent by the cluster head node in the same cluster.

[0094] Table 8 Format of the gateway association set table

[0095] Cluster identification information of reachable clusters Reachable cluster network address Reachable cluster network address mask Gateway interface address Expiration date … … … … …

[0096] More specifically, the gateway association set table is composed of one or more association array entries, and the cluster identification information, the reachable cluster network address, and the reachable cluster network address mask of the reachable cluster in the association array respectively represent the cluster identification information, the cluster network address, and the mask address of a cluster network reachable through the gateway node; the gateway interface address represents the specific available interface address adopted by the gateway node to reach the reachable cluster, and the validity expiration time represents the expiration time of the association array entry, and the array entry must be deleted after the validity expiration time. The cluster identification information (for example, the reachable cluster ID) of the reachable cluster in the gateway association set table is determined according to the cluster identification information of the cluster to which the gateway node receiving ICAA or the cluster head node sending ICAA belongs (the gateway node and the cluster head node are nodes in the same cluster), that is, the cluster identification information of the reachable cluster is determined according to the cluster identification information included in ICAA; the reachable cluster network address is determined according to the network address in ICAA, and the reachable cluster network address mask can be determined according to the mask corresponding to the network address in the data structure of ICAA. The gateway interface address and the validity expiration time are determined according to existing rules.

[0097] Step S03: Each gateway node periodically generates a cluster network association message HNA carrying the cluster identification information of the cluster to which the gateway node belongs according to the gateway association set table (its data structure can also be the same as the original HNA message in the OLSR routing protocol, but it needs to carry the cluster identification information). HNA includes the following fields: network address (32 bits), mask (32 bits) and cluster identification information (which can be determined according to the cluster identification information of the reachable cluster in the gateway association set table).

[0098] Step S04: Using the routing between each gateway node in step S01, each gateway node sends an HNA message carrying the cluster identification information of the cluster to which it belongs to other gateway nodes, and receives an HNA message carrying the cluster identification information of the cluster to which other gateway nodes belong, and generates an inter-cluster gateway routing table based on these HNA messages. During inter-cluster communication (i.e., cross-cluster communication), the gateway node can determine the route of the node with the destination address in the routing request message or the routing response message according to the inter-cluster gateway routing table. Since the inter-cluster communication is implemented based on the OLSR routing protocol, the data structure of the inter-cluster gateway routing table can refer to the OLSR routing table, as shown in Table 9. In addition, the inter-cluster gateway routing table can also carry the cluster identification information of the cluster to which the gateway node storing the table belongs.

[0099] Table 9 Data structure of the inter-cluster gateway routing table

[0100] Destination address R_dest_addr Next hop node interface address R_next_addr Hop count - the number of hops to the destination node R_dist Local interface address R_iface_addr

[0101] As an example, the inter-cluster gateway routing table stored by the gateway node includes the routing paths of the gateway node to all destination networks or destination nodes existing in the entire communication network. Assuming that nodes A, B, C and D belong to the same cluster, and node A is the cluster head node, and node B is the gateway node; nodes a, b, c and d belong to the same cluster, and node a is the cluster head node, and node b is the gateway node, after determining the route between node B and node b using the active routing protocol, node B can generate entries with destination addresses of nodes A, C and D, and nodes a, b, c and d in the inter-cluster gateway routing table through the intra-cluster address announcement message sent by node A (or the HNA message generated according to the intra-cluster address announcement message sent by node A) and the HNA message sent by node b. Among them, the destination address R_dest_addr is the same as the next hop node interface address R_next_addr of nodes a, b, c and d, which are all the addresses of a certain interface of node b.

[0102] Furthermore, in addition to using the inter-cluster gateway routing table stored in the gateway node (which contains the routing or address information of all gateway nodes in the communication network) to determine whether the destination node in the message belongs to the same cluster as the gateway node, when a routing request message or a routing reply message is sent to the gateway node, the gateway node can use the out-of-cluster destination routing tag table to determine whether the destination node is a node in the same cluster as the source node, and can also use the ICAA message, HNA message or inter-cluster gateway routing table sent by the cluster head node to determine. Specifically, when the gateway node receives a routing request message, considering that there may be a situation where the destination node is an out-of-cluster node but the address of the destination node does not exist in the out-of-cluster destination routing tag table, it can determine whether the destination node in the routing request message is an out-of-cluster node based on the ICAA message sent by the cluster head node of the same cluster, the HNA message generated according to the ICAA message, or the inter-cluster gateway routing table, and at the same time, the address of the destination node can be added to the out-of-cluster destination routing tag table; when the gateway node receives a routing reply message, it can determine whether the node corresponding to the destination address in the routing reply message is an out-of-cluster node based on the HNA message (including the HNA message generated by itself and sent by other cluster gateways), the inter-cluster gateway routing table and the out-of-cluster destination routing tag table.

[0103] Based on the above routing table and message, the present application can realize routing communication between the source node and the destination node based on the intra-cluster routing establishment process and the inter-cluster routing establishment process.

[0104] In some embodiments of the present invention, Figure 3As shown in (a) of FIG. 1 , the intra-cluster routing establishment process includes the following steps: Step S110: the source node broadcasts the generated routing request message to its neighbor nodes through the on-demand routing protocol; Step S120: the source node receives the routing response message generated by the neighbor nodes of the destination node according to the reverse routing. Specifically, it includes: Figure 4 As shown, the source node generates a route request message, and broadcasts the route request message to the neighbor nodes of the source node through the on-demand routing protocol; after the intermediate node receives the route request message, it uses the local routing table stored in the intermediate node to determine whether the cluster identification information of the cluster to which the source node belongs in the route request message corresponds to the cluster identification information of the cluster to which the intermediate node belongs; in the case where the cluster identification information corresponds (that is, the cluster identification information is the same), if the intermediate node is the destination node, or the local routing table stored in the intermediate node contains a route from the intermediate node to the destination node (and at the same time updates the reverse route from the intermediate node to the source node, that is, establishes the route from the intermediate node to the source node in the local routing table stored in the intermediate node), then the intermediate node generates a route reply message, and unicasts the route reply message to the source node through reverse routing, otherwise the intermediate node forwards the route request message to its neighbor nodes.

[0105] like Figure 5As shown, taking the route request message as the first route request message as an example, the intra-cluster route establishment process is specifically as follows: when the address of the destination node does not exist in the out-cluster destination route tag table stored by the source node (which can be used to store the addresses of nodes in the cluster to which the source node belongs), the source node S generates a first route request message (carrying the cluster identification information of the cluster to which the source node belongs) and broadcasts the first route request message to its neighbor nodes. After receiving the first route request message from the source node S, the intermediate node 1 and the intermediate node 2 determine whether the cluster identification information carried in the first route request message is the same as the cluster identification information of the cluster to which the intermediate node belongs; if the cluster identification information is different, the intermediate node discards the received first route request message; if the cluster identification information is the same, the intermediate node 1 and the intermediate node 2 determine whether the intermediate node is the destination node, or whether there is an updated valid route to the destination node in the local routing table of the intermediate node (determine whether it is the latest valid route by the sequence number field in the first route request message); if the intermediate node is not the destination node and the intermediate node does not have an updated valid route to the destination node, the intermediate node forwards the first route request message to neighboring nodes other than the source node. When the first route request message is propagated in the communication network, if the intermediate node determines that the cluster identification information is the same, the intermediate node can update the reverse route from the intermediate node to the source node S in the local routing table. After the intermediate node 5 receives the first route request message, it compares the destination address in the first route request message with the local routing table to confirm that there is an active path to the destination node at this node. Since the AODV protocol allows the local routing table to reply to the route reply message from the non-destination node that has a route to the destination node, the intermediate node 5 can generate a route reply message (carrying the cluster identification information of the cluster to which the destination node belongs) and send the route reply message to the source node S along the reverse route. The first route request message can also reach the destination node D through the cluster head node and the intermediate node 6 respectively, so the cluster head node and the intermediate node 6 can also return the route reply message to the source node S through the reverse route. Each intermediate node may receive multiple first route request messages with the same destination address, so each node can be set to send a route reply message only to the first first route request message with the same destination address received. In the process of the intermediate node 5, the intermediate node 6 and the cluster head node unicasting the route reply message to the source node along the reverse route, the intermediate node (for example, the intermediate node 4) through which the route reply message passes can update the route from the intermediate node to the destination node in the local routing table according to the route reply message. After receiving the route reply message, the source node S may update the route from the source node S to the destination node D in the local routing table according to the route hop count and other information carried in the route reply message.

[0106] Further, if the address of the destination node exists in the out-of-cluster destination routing tag table stored in the source node, the source node can determine that the destination node is an out-of-cluster node, and the source node needs to send a routing request message to the gateway node of the cluster (that is, the source node sends a routing request message to the gateway node of the cluster to which the source node belongs). However, the route between the source node and the gateway node of the cluster may be valid or invalid. Therefore, when executing the inter-cluster routing process, the source node sends a routing request message to the gateway node of the cluster to which the source node belongs, including: if there is a route from the source node to the gateway node of the cluster to which the source node belongs in the local routing table of the source node, the source node sends a second routing request message to the gateway node of the cluster to which the source node belongs through the on-demand routing protocol; if there is no route from the source node to the gateway node of the cluster to which the source node belongs in the local routing table of the source node, the source node broadcasts the first routing request message in the cluster through the on-demand routing protocol, receives the out-of-cluster routing notification message from the cluster head node of the cluster based on the out-of-cluster notification process, generates a second routing request message and sends it to the gateway node of the cluster to which the source node belongs through the intra-cluster routing establishment process.

[0107] Specifically, Figure 6 As shown in FIG. 1 , if it is determined according to the out-cluster destination routing tag table that the destination node corresponding to the destination address is a node within the cluster (the destination node and the source node are nodes of the same cluster), the source node can generate a first routing request message, and forward it within the cluster according to the destination address in the first routing request message using the on-demand routing protocol (i.e., intra-cluster communication), and finally the source node can obtain the routing response message corresponding to the first routing request message from other nodes in the cluster according to the intra-cluster routing establishment process; if it is determined according to the out-cluster destination routing tag table that the destination node corresponding to the destination address is a node within the cluster (but in fact the destination node and the source node are nodes of different clusters), the first routing request message is forwarded using the on-demand routing protocol, and after the cluster head node receives the first routing request message, it determines that the destination address in the first routing request message is a node outside the cluster. point, then the out-cluster routing notification message is returned to the source node, and the source node regenerates the second routing request message and sends it to the gateway node of the cluster using the intra-cluster routing establishment process (the route from the source node to the gateway node of the cluster to which the source node belongs does not exist in the local routing table of the source node) or the intra-cluster communication process (the route from the source node to the gateway node of the cluster to which the source node belongs exists in the local routing table of the source node) (at this time, even if the cluster network node receives the first routing request message, it does not forward it between clusters, but forwards it to the cluster head node within the cluster); if the destination node corresponding to the destination address is determined to be an out-cluster node according to the out-cluster destination routing tag table (the destination node and the source node are nodes of different clusters), the source node directly generates the second routing request message and sends it to the gateway node of the cluster using the intra-cluster routing establishment process or the intra-cluster communication process.

[0108] In some embodiments of the present invention, Figure 3As shown in (b) of FIG. 2 , the process of establishing intra-cluster routing includes the following steps: Step S210, the source node sends a routing request message (herein, the second routing request message) to the gateway node of the cluster to which the source node belongs based on the intra-cluster communication process (or the on-demand routing protocol), so that the gateway node of the cluster to which the source node belongs determines that the destination node address in the routing request message is the address of the node outside the cluster based on the intra-cluster address announcement message (periodically sent by the cluster head node of the cluster to which the source node belongs to the gateway node of the same cluster), determines the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs through the stored inter-cluster gateway routing table, and uses The routing request message is forwarded to the gateway node of the cluster to which the destination node belongs by using an active routing protocol; in step S220, the source node receives a routing response message corresponding to the routing request message from the gateway node of the cluster to which the source node belongs by reverse routing; wherein the gateway node of the cluster to which the source node belongs is used to, after receiving the routing response message sent by the gateway node of the cluster to which the destination node belongs and determining that the node corresponding to the destination address in the routing response message is a node of this cluster, change the cluster identification information of the cluster to which the destination node belongs carried in the routing response message to the cluster identification information of the cluster to which the source node belongs, and send the changed routing response message to the source node. After forwarding the route request message to the gateway node of the cluster to which the destination node belongs through step S210, the gateway node of the cluster to which the destination node belongs can be used to determine that the destination node corresponding to the destination address in the route request message is a node of this cluster based on the cluster address notification message from the cluster head node of the cluster to which the destination node belongs, and then change the cluster identification information of the cluster to which the source node belongs in the route request message to the cluster identification information of the cluster to which the destination node belongs, and send the changed route request message to the destination node based on the on-demand routing protocol or the intra-cluster routing establishment process; the neighbor node of the destination node generates a route reply message corresponding to the route request message, and sends it to the gateway node of the cluster to which the destination node belongs; after the gateway node of the cluster to which the destination node belongs determines that the destination address in the route reply message is the address of a node outside the cluster, it uses the stored inter-cluster gateway routing table to determine the route from the gateway node of the cluster to which the destination node belongs to the gateway node of the cluster to which the source node belongs, thereby sending the route reply message to the gateway node of the cluster to which the source node belongs.

[0109] As an example, in step S210, based on the intra-cluster address announcement message (ICAA), it is determined that the destination node corresponding to the destination address in the route request message is an out-cluster node, including: the gateway node of the cluster to which the source node belongs can use the node address in the intra-cluster address announcement message from the cluster head node of the cluster to which the source node belongs to determine that the destination node corresponding to the destination address in the route request message is an out-cluster node; or, the gateway node of the cluster to which the source node belongs can use the inter-cluster gateway routing table formed based on the intra-cluster address announcement message to determine that the destination node corresponding to the destination address in the route request message is an out-cluster node. This is because the inter-cluster destination routing tag table of the cluster gateway node may not include all out-cluster nodes, so ICAA or the inter-cluster gateway routing table can be used to determine whether the node corresponding to the destination address in the route request message is an out-cluster node, but the method of using ICAA or the inter-cluster gateway routing table to determine the out-cluster node can be specifically set. For example, if ICAA is only used to generate an inter-cluster gateway routing table, the inter-cluster gateway routing table is used to determine whether the node corresponding to the destination address is an out-cluster node; if the inter-cluster gateway routing table is only used to find routes between matching gateways, ICAA can be used to determine whether the node corresponding to the destination address is an out-cluster node. In addition, after the gateway node of the cluster to which the source node belongs determines that the address of the destination node in the routing request message is the address of the out-cluster node, if the destination node address does not exist in the out-cluster destination routing tag table of the gateway node of the cluster to which the source node belongs, the address of the destination node in the routing request message is added to the out-cluster destination routing tag table (at the same time, the intermediate nodes through which the source node sends the routing request message to the gateway node of the cluster can also add the address of the destination node in the routing request message to the out-cluster destination routing tag table stored in each of them).

[0110] In step S210, Figure 7As shown, after the gateway node of the cluster to which the source node belongs receives the route request message (i.e., the second route request message) from the source node, if the destination node corresponding to the destination address in the route request message (here the destination address is the out-of-cluster destination address in the OCRQ, i.e., the address of the destination node) is determined to be an out-of-cluster node using the intra-cluster address announcement message or the inter-cluster gateway routing table, then the stored inter-cluster gateway routing table is searched to determine the destination gateway node (i.e., the destination gateway) of the cluster to which the destination node belongs, and the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs is determined, and then the gateway node of the cluster to which the source node belongs can use the active routing protocol to forward the received route request message to the destination gateway. If the gateway node of the cluster to which the source node belongs receives the route request message, it uses ICAA or the inter-cluster gateway routing table to determine that the destination node corresponding to the destination address in the route request message is a node within the cluster. At this time, the inter-cluster routing establishment process is not executed, and the gateway node of this cluster only performs intra-cluster communication as a common node, that is, the gateway node of this cluster uses the local routing table to determine whether the cluster identification information carried in the route request message corresponds, whether the cluster gateway node is the destination node, or whether there is a route from the gateway node to the destination node in the local routing table. Further, after the gateway node of the cluster to which the destination node belongs (i.e., the destination gateway) receives the route request message, it uses the intra-cluster address notification message sent by the cluster head node of the cluster to which the destination node belongs or the stored inter-cluster gateway routing table to determine whether the destination node corresponding to the destination address in the route request message is a node in this cluster. If the destination node is not a node in this cluster, the destination gateway continues to forward the route request message. If the destination node is a node in this cluster, the destination gateway changes the cluster identification information of the cluster to which the source node belongs in the route request message to the cluster identification information of the cluster to which the destination node belongs, and sends the changed route request message to the destination node. At this time, if the local routing table of the destination gateway stores the route from the destination gateway to the destination node, the route request message with the modified cluster identification information is sent to the destination node based on the on-demand routing protocol; if the local routing table of the destination gateway does not contain the route from the destination gateway to the destination node, the route from the destination gateway to the destination node is established based on the intra-cluster routing establishment process, and then the route request message with the modified cluster identification information is sent to the destination node. That is, if the cluster identification information in the message received by the gateway node is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a route request message, it is determined based on the intra-cluster address announcement message whether the destination node address in the route request message is the address of a node outside the cluster; if it is the address of a node outside the cluster, the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs is determined based on the intra-cluster address announcement message, and the route request message is forwarded to the gateway node of the cluster to which the destination node belongs using the active routing protocol; if it is not the address of a node outside the cluster, it is forwarded or a route reply message is generated using the on-demand routing protocol.

[0111] like Figure 7As shown, if the cluster identification information in the message received by the gateway node is different from the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing reply message, if the destination address in the routing reply message is determined to be the address of a node in the cluster based on the gateway node cluster address announcement message, the cluster identification information of the cluster to which the destination node belongs contained in the routing reply message is changed to the cluster identification information of the cluster to which the source node belongs, and the changed routing reply message is sent to the source node through the on-demand routing protocol; if the destination address in the routing reply message is determined not to be the address of a node in the cluster based on the gateway node cluster address announcement message, the message is forwarded through the stored inter-cluster gateway routing table. If the cluster identification information in the message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing reply message, whether to forward the message through the on-demand routing protocol is determined based on the destination address in the routing reply message.

[0112] In addition, during the process of the route request message propagating from the source node to the destination node, if the destination address of the source node does not exist in the out-of-cluster destination routing tag table stored by the destination gateway, the destination node, and the intermediate node between the destination gateway and the destination node through which the route request message passes, the address of the source node can be added to the out-of-cluster destination routing tag table stored therein.

[0113] The step S220 in which the source node obtains the routing reply message in the inter-cluster routing establishment process can be divided into the following multiple steps: Step S221, the non-destination node that has a route to the destination node in the local routing table can generate a routing reply message corresponding to the routing request message, and send the routing reply message to the gateway node of the cluster to which the destination node belongs through the reverse route established by the on-demand routing protocol. Step S222, after receiving the routing reply message, the destination gateway uses ICAA, the inter-cluster gateway routing table or the cluster-out destination routing tag table (the destination address has been recorded in the cluster-out destination routing tag table during the routing request message propagation process) to determine that the node corresponding to the destination address in the routing reply message is an out-cluster node, searches the inter-cluster gateway routing table to determine the gateway node of the cluster to which the node corresponding to the destination address in the routing reply message belongs (determine the gateway node of the cluster to which the source node belongs), and searches for the route from the destination gateway to the gateway node of the cluster to which the source node belongs, thereby forwarding the routing reply message to the gateway node of the cluster to which the source node belongs. Step S223, after the gateway node of the cluster to which the source node belongs uses ICAA or the inter-cluster gateway routing table to determine that the destination address in the routing reply message is the address of the node of this cluster, the cluster identification information of the cluster to which the destination node belongs in the routing reply message is changed to the cluster identification information of the cluster to which the source node belongs, and forwarded to the cluster through the on-demand routing protocol. Step S224, the source node receives the routing reply message, and updates the local routing table stored in the source node according to the routing hop count and other information carried in the routing reply message (adding the route from the source node to the destination node in the local routing table).

[0114] As an example, Figure 8 As shown in FIG. 1 , when the source node S needs to send a data packet to the destination node D, but there is no routing entry to the D node in the local routing table of the source node S, the source node S first determines whether the destination address of the destination node D exists in the out-of-cluster destination routing tag table of the source node S. If the address of the destination node in the routing request message exists in the out-of-cluster destination routing tag table stored in the source node S, the source node can determine the received routing response message through the inter-cluster routing establishment process: the source node S broadcasts the routing request message embedded with the cluster identification information to its neighbor nodes based on the intra-cluster communication. The gateway node of the cluster to which the source node S belongs receives the routing request message and finds that the destination node corresponding to the destination address in the routing request message is not a node in the cluster. It then searches the routing table generated by the inter-cluster routing protocol and forwards the routing request message to the destination gateway. After receiving the routing request message, the destination gateway finds that there is a network address match for the destination node in the cluster, so the cluster identification information carried by the routing request message can be changed to the cluster identification information of the cluster, and the local routing The source address information in the route request message is recorded in the table, and then the destination gateway broadcasts the changed route request message to the intra-cluster network through intra-cluster communication; the non-destination node that has a valid route or an active route to the destination node can send a route reply message through the established reverse route (the reverse of the propagation route of the route request message) to establish a forward route to the destination node; the destination gateway receives the returned RREP and finds that the destination address in the RREP is the recorded out-of-cluster address, and then searches the inter-cluster routing table to find a matching item, so as to forward the route reply message to the gateway node of the cluster to which the source node belongs. The gateway node of the cluster to which the source node belongs finds that the destination address in the RREP returned from outside the cluster is the address of the node of this cluster, and then the cluster identification information carried by the RREP can be changed to the cluster identification information of this cluster, and then forwarded to the nodes in the cluster; the source node finally receives the route reply message corresponding to the route request message, and updates the local routing table according to the route hop count and other information carried in the route reply message. At this point, the source node can send data packets to the destination node.

[0115] In some embodiments of the present invention, the method further includes: after the source node receives the out-of-cluster routing announcement message (OCRA), if no routing reply message (RREP) is received within a set time, the source node regenerates a second routing request message (OCRQ) and sends it to the gateway node of the cluster to which the source node belongs using an on-demand routing protocol.

[0116] In the present application, when there is no route from the source node to the destination node in the local routing table stored in the source node, after the source node receives the routing response message corresponding to the routing request message through the inter-cluster routing establishment process and the intra-cluster routing establishment process, the route from the source node to the destination node can be established using the determined routing response message, and recorded in the local routing table stored in the source node, so that the source node can send data packets to the destination node based on the established route (that is, the source node can communicate with the destination node). That is, after establishing routes between the nodes of the clustered network through the inter-cluster routing establishment process and the intra-cluster routing establishment process, the present application implements the intra-cluster communication process through the improved on-demand routing protocol, and implements the inter-cluster communication process through the intra-cluster nodes communicating based on the improved on-demand routing protocol and the inter-cluster gateways communicating based on the improved active routing protocol.

[0117] Compared with the ZRP protocol, the present application adopts an improved on-demand routing protocol between nodes in the cluster to achieve network layer interconnection, and adopts an active routing protocol between cluster gateways to achieve full network interconnection, which has the following advantages: the present application utilizes the gateway nodes of each cluster to dynamically select the communication range, making the clustering mechanism more flexible and better adaptable to the network environment with high mobility and high damage rate; the communication between nodes in the cluster adopts an on-demand routing protocol, avoiding the high overhead of periodic routing updates, especially in the case of high node damage rate; the cluster gateway is used as the relay node for inter-cluster communication in the cluster network, which greatly simplifies the boundary processing problem, and improves the robustness of the protocol by giving priority to stable enhanced nodes as cluster gateways; the present application designs cluster gateway selection and protocol optimization based on node performance, which improves the adaptability and performance in heterogeneous network scenarios; and, when communicating across clusters, an active routing protocol is used between gateway nodes, which reduces the establishment delay of inter-cluster communication, thereby improving the communication performance of the network as a whole.

[0118] The communication method based on the hybrid clustering routing protocol proposed in the present invention has the following advantages:

[0119] (1) The present invention designs a hybrid routing mechanism that combines reactive and proactive routing mechanisms to support large-scale dynamic heterogeneous node environments. It can not only respond quickly when the communication path is established, but also maintain the effectiveness of the path through regular updates, thereby improving the robustness and flexibility of the network, reducing communication delays and adapting to dynamic network environments.

[0120] (2) The present invention implements a collaborative design within and between clusters. Through the coordinated cooperation of the intra-cluster and inter-cluster communication mechanisms, the network can operate efficiently at different scales, and optimize cross-cluster communication through the role of cluster gateway nodes, avoiding excessive signaling overhead caused by information flooding, and improving the efficiency and stability of routing selection.

[0121] (3) The routing protocol designed in the present invention has the characteristics of strong scalability and applicability. Through the flexible design of the protocol structure, such as the data structures such as the intra-cluster address announcement message (ICCA), the extra-cluster route announcement message (OCRA) and the second route request message (OCRQ), it can adapt to different network topology scales and application requirements. It is particularly suitable for large-scale, dynamically changing network environments with significantly heterogeneous network nodes. It has good scalability and helps to reduce the complexity of deployment and maintenance.

[0122] Corresponding to the above method, the present invention also provides a communication system based on a hybrid cluster routing protocol, the system comprising a computer device, the computer device comprising a processor and a memory, the memory storing a computer program / instructions, the processor being used to execute the computer program / instructions stored in the memory, and when the computer program / instructions are executed by the processor, the system implements the steps of the method described above.

[0123] It should be understood by those skilled in the art that the exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0124] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0125] In the present invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with features of other embodiments or replace features of other embodiments.

[0126] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A communication method based on a hybrid clustering routing protocol, characterized in that: The method comprises the following steps: The destination node is determined by the source node, and if there is a route from the source node to the destination node in the local routing table stored in the source node, the source node sends a data packet to the destination node based on the route; if there is no route from the source node to the destination node in the local routing table stored in the source node, if the address of the destination node in the route request message exists in the out-of-cluster destination routing tag table stored in the source node, the source node generates a route request message and receives a corresponding route reply message through the inter-cluster routing establishment process; if the address of the destination node in the route request message does not exist in the out-of-cluster destination routing tag table stored in the source node, the source node generates a route request message and receives a corresponding route reply message through the intra-cluster routing establishment process; wherein the out-of-cluster destination routing tag table is used to store the addresses of nodes in the cluster to which the source node does not belong; The source node uses the received route reply message to establish a route from the source node to the destination node, and records it in a local routing table, so that the source node sends a data packet to the destination node based on the established route; wherein the route request message and the route reply message both include information of the source address and the destination address, and the route request message carries the cluster identification information of the cluster to which the source node belongs, and the route reply message carries the cluster identification information of the cluster to which the destination node belongs; The inter-cluster routing establishment process includes the following steps: The source node sends a route request message to the gateway node of the cluster to which the source node belongs, so that the gateway node of the cluster to which the source node belongs determines that the destination node address in the route request message is the address of the node outside the cluster based on the intra-cluster address announcement message, determines the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs through the stored inter-cluster gateway routing table, and forwards the route request message to the gateway node of the cluster to which the destination node belongs by using an active routing protocol; The source node receives a routing response message corresponding to the routing request message from the gateway node of the cluster to which the source node belongs through reverse routing; wherein the gateway node of the cluster to which the source node belongs is used to, after receiving the routing response message sent by the gateway node of the cluster to which the destination node belongs and determining that the node corresponding to the destination address in the routing response message is a node of the cluster, change the cluster identification information of the cluster to which the destination node belongs carried in the routing response message to the cluster identification information of the cluster to which the source node belongs, and send the changed routing response message to the source node; The intra-cluster routing establishment process includes the following steps: The source node broadcasts the routing request message to its neighbor nodes through the on-demand routing protocol, and receives the routing reply message generated by the neighbor nodes of the destination node according to the reverse routing; Among them, the intra-cluster address announcement message is generated by the cluster head node and is used to unicast the addresses of all nodes in the cluster to the gateway nodes of the same cluster through the active routing between the gateway nodes of each cluster and the cluster head node; the intra-cluster address announcement message includes the following field information: cluster identification information, network address and mask of the cluster to which the cluster head node belongs.

2. The method according to claim 1, characterized in that The active routing protocol is the OLSR routing protocol, and the on-demand routing protocol is the AODV routing protocol; The destination address in the route request message is the same as the source address in the route reply message, and the source address in the route request message is the same as the destination address in the reply message; The route request message is a first route request message or a second route request message; wherein the destination address of the first route request message is the address of the destination node, and the destination address of the second route request message includes the address of the gateway node of the cluster to which the source node belongs and the address of the destination node.

3. The method according to claim 2, characterized in that The source node generates a routing request message and receives a corresponding routing response message through an intra-cluster routing establishment process, including: The source node generates a first route request message, and receives a route response message corresponding to the first route request message through an intra-cluster route establishment process; or The source node generates a first route request message, receives an out-of-cluster route notification message sent by the cluster head node of the cluster to which the source node belongs based on the out-of-cluster notification process, and records the destination address in the first route request message in the out-of-cluster destination route tag table; the source node generates a second route request message and determines the route response message received by the source node through the inter-cluster route establishment process; The out-cluster routing notification message includes the following information: the out-cluster destination address of the destination address in the first routing request message, and the address of the gateway node of the cluster to which the source node belongs.

4. The method according to claim 2, characterized in that: The source node sends a routing request message to a gateway node of the cluster to which the source node belongs, including: If the local routing table of the source node contains a route from the source node to the gateway node of the cluster to which the source node belongs, the source node sends a second routing request message to the gateway node of the cluster to which the source node belongs through the on-demand routing protocol; If the local routing table of the source node does not contain a route from the source node to the gateway node of the cluster to which the source node belongs, the source node receives an extra-cluster routing notification message from the cluster head node of the cluster based on the extra-cluster notification process, generates a second routing request message and sends it to the gateway node of the cluster to which the source node belongs through the intra-cluster routing establishment process.

5. The method according to claim 3 or 4, characterized in that: The out-of-cluster notification process includes the following steps: The source node sends a first routing request message to the cluster head node of the cluster to which the source node belongs through the on-demand routing protocol, so that the cluster head node of the cluster to which the source node belongs determines that the destination address in the received first routing request message is not the address of a node in this cluster based on the stored address set of all nodes in the cluster, and then generates an out-of-cluster routing notification message and sends it to the source node.

6. The method according to claim 3 or 4, characterized in that: The method further comprises: After the source node receives the out-of-cluster routing notification message, if no routing response message is received within a set time, the source node regenerates a second routing request message and sends it to the gateway node of the cluster to which the source node belongs using the on-demand routing protocol.

7. The method according to claim 1, characterized in that The method of generating a route request message by a source node through an on-demand routing protocol, broadcasting the route request message to neighbor nodes of the source node, and receiving a route response message generated by neighbor nodes of the destination node according to reverse routing includes: The source node generates a routing request message, and broadcasts the routing request message to neighbor nodes of the source node through an on-demand routing protocol, so that the intermediate node determines whether the cluster identification information of the cluster to which the source node belongs in the received routing request message corresponds to the cluster identification information of the cluster to which the intermediate node belongs by using a stored local routing table; wherein the local routing table includes the cluster identification information of the cluster to which the node storing the local routing table belongs; In the case where the cluster identification information corresponds, if the intermediate node is the destination node, or the local routing table stored in the intermediate node contains a route from the intermediate node to the destination node, the source node receives the routing reply message generated by the intermediate node through reverse routing.

8. A communication method based on a hybrid clustering routing protocol, characterized in that: The method comprises the following steps: The gateway node receives a message carrying cluster identification information. If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a route request message, it is determined based on the cluster address announcement message whether the destination node address in the route request message is the address of a node outside the cluster; if it is the address of a node outside the cluster, the route from the gateway node of the cluster to which the source node belongs to the gateway node of the cluster to which the destination node belongs is determined based on the cluster address announcement message, and the route request message is forwarded to the gateway node of the cluster to which the destination node belongs by using an active routing protocol; if it is not the address of a node outside the cluster, the route response message is forwarded or generated by using an on-demand routing protocol; If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is an intra-cluster address announcement message, an inter-cluster gateway routing table is formed based on the intra-cluster address announcement message and the routes between each gateway node; If the cluster identification information in the received message is the same as the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing reply message, determining whether to forward it through the on-demand routing protocol based on the destination address in the routing reply message; If the cluster identification information in the received message is different from the cluster identification information of the cluster to which the gateway node belongs, and the message is a routing response message, if it is determined based on the gateway node cluster address announcement message that the destination address in the routing response message is the address of a node within the cluster, then the cluster identification information of the cluster to which the destination node belongs carried in the routing response message is changed to the cluster identification information of the cluster to which the source node belongs, and the changed routing response message is sent to the source node through the on-demand routing protocol; if it is determined based on the gateway node cluster address announcement message that the destination address in the routing response message is not the address of a node within the cluster, then it is forwarded through the stored inter-cluster gateway routing table; wherein the cluster address announcement message is generated by the cluster head node, and is used to unicast the addresses of all nodes in the cluster to the gateway nodes of the same cluster through the active routes between the gateway nodes of each cluster and the cluster head node; the cluster address announcement message includes the following field information: the cluster identification information, network address and mask of the cluster to which the cluster head node belongs.

9. The method according to claim 8, characterized in that The inter-cluster gateway routing table stored in the gateway node includes routing paths from the gateway node to all destination networks or destination nodes in the entire communication network, and is formed in the following manner: Use active routing protocols to determine the routes between gateway nodes; Each gateway node generates a corresponding gateway association set table based on the intra-cluster address announcement message sent by the cluster head node of the same cluster, generates a cluster network association message carrying the cluster identification information of the cluster to which the gateway node belongs according to the gateway association set table, and uses the routing between each gateway node to send the cluster network association message to other gateway nodes, so that each gateway node forms an inter-cluster gateway routing table.

10. A communication system based on a hybrid clustering routing protocol, comprising a processor, a memory, and a computer program / instruction stored in the memory, characterized in that: The processor is used to execute the computer program / instruction, and when the computer program / instruction is executed, the system implements the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 8 to 9.

Images