Internet-of-vehicles intra-cluster routing protocol based on clustering
By combining clustering technology and trust mechanism, a network of in-cluster routing protocol is designed, which solves the problems of untimely data propagation and network stability in the network of vehicles, realizes efficient and reliable communication, and improves routing scalability and scalability sex.
Patent Information
- Application Number
- CN202411264212.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-10
- Publication Date
- 2024-12-13
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
There are routing problems such as untimely data propagation, network stability, data management, reliability and scalability in the Internet of Vehicles. Especially when the topological structure changes caused by high mobility vehicle nodes, existing cluster-based routing protocols are available. Difficult to effectively solve.
Combining clustering technology and trust mechanism, a network of vehicles is designed to design a routing protocol in the cluster. By periodically publishing messages through the cluster head, cluster members select cluster heads to form a local node link list, and select the next hop communication node to achieve efficient and reliable in the cluster. Communication.
Improve the scalability of network-connected routes, reduce control overhead, reduce global topology dynamics, realize the advantages of infrastructure networks, and quickly judge the reliability of information through trust mechanisms, solving data propagation and network stability question.
Smart Images

Figure CN119136277A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of vehicle node communication in Internet of Vehicles, and in particular to a clustering-based intra-cluster routing protocol in Internet of Vehicles. Background Art
[0002] In the Internet of Vehicles, the high mobility of vehicle nodes causes the topology to change frequently. Clustering technology can improve the scalability and reliability of Internet of Vehicles routing, allowing vehicles to communicate more stably within the cluster. The main method to reduce control overhead is to use clustering technology. In clustering-based routing protocols, nodes with similar attributes and performance in the network are arranged in virtual groups, called clusters. The clustering method can effectively reduce the global topology dynamics of the Internet of Vehicles and achieve the advantages of infrastructure-based networks without the need for physical infrastructure.
[0003] As an important foundation of Internet of Vehicles communication, routing protocol is a mechanism for transmitting data from source node to destination node in the communication system.
[0004] Security is one of the main issues of the Internet of Vehicles, and trust is a key factor in security. The trust value is used to measure the trust between two entities (truster and trusted). In a well-functioning Internet of Vehicles system, the users involved and the objects of information transmission are usually in a relationship of mutual trust, so the trust mechanism can quickly judge the reliability of information (trust in tasks and information).
[0005] The clustering-based Internet of Vehicles routing protocol is a hybrid routing protocol. There are some problems in the Internet of Vehicles, such as timely and effective data dissemination, network stability, data management, reliability and scalability. The clustering-based Internet of Vehicles routing protocol can solve these problems to a certain extent.
[0006] Therefore, there is an urgent need for a clustering-based intra-cluster routing protocol for Internet of Vehicles to solve the above problems. Summary of the invention
[0007] To solve the above problems, the present invention provides a clustering-based intra-cluster routing protocol for Internet of Vehicles, which combines clustering technology, trust mechanism and routing protocol design process, and strives to achieve more reliable and efficient communication between vehicle nodes in the cluster.
[0008] In the present invention, a clustering-based intra-cluster routing protocol for Internet of Vehicles is provided, comprising the following steps:
[0009] S1, cluster establishment, cluster head periodically publishes cluster head message and cluster member message, cluster members select cluster head and join the cluster;
[0010] S2, cluster members publish cluster member messages to the cluster head;
[0011] S3, the cluster member receives the vehicle ID, trust value, location and speed issued by other cluster members and forms a local node list, where the local node list includes a node list Q and a node list P;
[0012] S4. Cluster members select the next-hop communication node based on the local node list to form intra-cluster routing.
[0013] Preferably, the specific content of cluster member selection of cluster head in S1 is:
[0014] The cluster head periodically publishes a cluster head message, wherein the cluster head message includes CHID, location, trust value and speed;
[0015] Among them, CHID refers to the cluster head ID, location refers to the coordinate position of the cluster head, trust value refers to the cluster head trust value, and speed includes speed magnitude and speed direction;
[0016] If the vehicle node receives multiple cluster head messages, it selects the sub-cluster with the smallest speed difference between its own node and the cluster head node to join the cluster head, and sends a cluster member message to the selected cluster head according to S2;
[0017] If a vehicle node does not receive any cluster head message issued by any cluster head within three consecutive cycles, the vehicle node randomly selects an integer n between 1 and 10, and waits for n cycles starting from the fourth cycle. When the waiting time is over and it still does not receive the cluster head message issued by other vehicle nodes, it automatically becomes the cluster head and publishes the cluster head message.
[0018] Preferably, the specific content of the cluster member message periodically issued by the cluster head in S1 is:
[0019] The cluster head updates the vehicle ID, location, trust value and speed of all members in the cluster according to the received cluster member message to form a cluster member information table;
[0020] The cluster member message is published once in each period, and the cluster member information table is added to the cluster member message and published to the cluster members;
[0021] The length of the ID field of the cluster member message is 2 bytes. The ID field is used to distinguish cluster member message messages. The cluster member message message corresponds to a unique cluster member message message ID.
[0022] The cluster member determines whether it has received the cluster member message according to the cluster member message ID, and determines whether to forward the cluster member message according to its position relative to the cluster head;
[0023] The cluster member message includes: CHID, cluster member message message ID, cluster member information table and forwarding node ID list, CHID refers to cluster head ID;
[0024] The cluster member information table includes the vehicle ID, location, trust value and speed of each member in the cluster;
[0025] When the current cluster member forwards a message from another cluster member, it will add the vehicle node ID of the current cluster member to the forwarding node ID list in the forwarded cluster member message.
[0026] Preferably, the cluster member determines whether it has received the cluster member message according to the cluster member message ID, and determines whether to forward the cluster member message according to its position relative to the cluster head. The specific content is:
[0027] If a cluster member has received a message from this cluster member and the cluster member detects that there is a vehicle node within the range of one-half of the cluster head communication radius, this cluster member will not forward it;
[0028] If a cluster member has received the message of the cluster member and the cluster member detects that there is no vehicle node within the range of the second half of the cluster head communication radius, then the cluster member waits for another half of the period to detect whether there is a member forwarding the message within the second half of the radius. If there is, it will not be forwarded, otherwise it will be forwarded;
[0029] If a cluster member receives the cluster member message for the first time and the cluster member is located within the last half of the cluster head communication radius, it will forward it;
[0030] If a cluster member receives the cluster member message for the first time and the cluster member location is within the first half of the cluster head communication radius, the cluster member waits for another half of the cycle to detect whether there is a member forwarding it in the second half. If so, it will not forward it, otherwise it will forward it.
[0031] Preferably, the method of determining whether the cluster member is located at one half before or after the cluster head communication radius R includes:
[0032] Calculate the distance D between cluster members and cluster head;
[0033] If the distance D between a cluster member and the cluster head is less than Then the cluster members are located in the first half of the cluster head’s communication radius;
[0034] If the distance D between a cluster member and the cluster head is greater than Then the cluster members are located in the last half of the cluster head's communication radius.
[0035] Preferably, the specific steps of the S2 cluster member publishing the cluster member message to the cluster head are as follows:
[0036] Cluster members publish cluster member messages to the cluster head every period, including: vehicle ID, join or leave flag, location, trust value and speed;
[0037] The vehicle node ID refers to the cluster member ID, which is used to uniquely identify the vehicle node;
[0038] Join or leave mark means that the vehicle node can be set as a join mark when joining the cluster, and can be set as a leave mark when leaving the cluster; location refers to the current location of the cluster member;
[0039] The trust value is calculated by the cloud data center for each cluster member; speed refers to the speed of the cluster member, including the speed magnitude and speed direction;
[0040] When a cluster member forwards a cluster member message, it adds its own vehicle ID to the forwarding node ID list of the cluster member message. The cluster member can form a cluster head message forwarding path according to the forwarding node ID sequence, and send the cluster member message to the cluster head in the opposite direction of the forwarding path.
[0041] If there are multiple forwarding paths to a cluster member at this time, the cluster member selects the path with the least hops, that is, the path with the least number of forwarding node IDs, as the path for publishing cluster member messages to the cluster head;
[0042] If the cluster head does not receive a message from a cluster member within three consecutive cycles, it will issue a query. If it receives a reply from this cluster member, it means that this cluster member exists; if it does not receive a reply from this cluster member, it means that this cluster member has left, and the cluster head updates the cluster member information table and deletes the cluster member from the cluster member information table;
[0043] When a cluster member joins a cluster, it periodically publishes a cluster member message to the cluster head, including: vehicle ID, joining mark, location, trust value and speed, where the joining or leaving mark part is set as the joining mark. The cluster head updates the information of this vehicle node, updates the cluster member information table, and then publishes the cluster member information table to the cluster members along with the message;
[0044] When a cluster member leaves the cluster, the cluster member mark part is set to leave, and the cluster member sends a cluster member message to the cluster head along the opposite direction of the cluster member message forwarding path to report the departure. The cluster head updates the information of this vehicle node, and after updating the cluster member information table, it publishes the cluster member information table to the cluster members along with the cluster member message.
[0045] Preferably, the cluster member forms the local node linked list according to the vehicle ID, trust value, location and speed size issued by other cluster members received, and the specific content is:
[0046] The cluster member messages received by the vehicle nodes in the cluster are all cluster member messages issued by other vehicle nodes within the one-hop communication diameter range;
[0047] When a cluster member receives a cluster member message from other vehicle nodes, it will not forward it to other vehicle nodes except for transmitting it to the cluster head along the specified path;
[0048] The vehicle node receives the cluster member message generated by the vehicle node in the front cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the front cluster member to the node linked list Q;
[0049] The vehicle node receives the cluster member message generated by the vehicle node in the rear cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the rear cluster member to the node linked list P;
[0050] When adding a vehicle node to the local node list, if the vehicle node already exists, the node data is updated and the lifetime timer is restarted;
[0051] If it does not exist, insert a new node;
[0052] Among them, the nodes in the node list Q and the node list P have a lifetime. Nodes that exceed the lifetime will be deleted from the local node list. The lifetime is three cycles.
[0053] Preferably, the cluster member selects the next hop communication node according to the vehicle ID, trust value and speed in the local node list, and the specific contents of forming the intra-cluster routing include:
[0054] S401, the cluster member vehicle node determines whether it is in the same cluster as the destination vehicle node based on the information in the cluster member information table published by the cluster head. If so, proceed to S402; if not, proceed to a preset inter-cluster routing protocol.
[0055] S402: If the cluster member vehicle node sends data to the destination vehicle node for the first time, the cluster member vehicle node selects the next hop vehicle node from the corresponding local node linked list according to the location of the destination vehicle node when selecting the next hop;
[0056] The next hop vehicle node and the destination vehicle node are added as a record to the local cache of the cluster member vehicle node, and the lifetime of the record is set to a cycle.
[0057] S403, if the cluster member vehicle node has previously sent data to the destination vehicle node, select the next hop vehicle node according to the cache record information;
[0058] S404: If the cluster member vehicle node is the forwarder of the message, after the forwarding is completed, a confirmation message is sent to the previous hop;
[0059] If the cluster member vehicle node is the generator of this message, there is no need to send a confirmation message;
[0060] If the cluster member vehicle node does not receive the confirmation message within the target time after the forwarding is completed, the next hop node is deleted from the corresponding queue, and the next hop node is reselected according to S402 to forward again.
[0061] Preferably, the specific content of selecting the next hop vehicle node in the local node linked list according to the location of the destination vehicle node is:
[0062] If the destination vehicle node is in front of the cluster member vehicle node, the next hop vehicle node is selected from the node linked list Q of the cluster member vehicle;
[0063] If the destination vehicle node is behind the cluster member vehicle node, the next hop vehicle node is selected from the node linked list P of the cluster member vehicles;
[0064] If the destination vehicle node exists in the local node linked list, the destination vehicle node is directly selected as the next hop.
[0065] Preferably, the expression for selecting the next hop vehicle node from the local node linked list of the cluster member vehicle is:
[0066]
[0067] In the above formula, i is the node traversal in the linked list Q, trust i is the trust value of the i-th node in the local node list, d i is the distance from the ith node to the cluster member vehicle node, R is the communication radius between vehicle nodes, v i is the speed of the ith node, and v is the speed of the vehicle node of the cluster member.
[0068] In summary, the clustering-based intra-cluster routing protocol of the Internet of Vehicles of the present invention, compared with the traditional protocol computing technology, integrates clustering technology, trust mechanism and routing protocol. Clustering technology can improve the scalability of Internet of Vehicles routing, reduce control overhead, reduce the global topology dynamics of the Internet of Vehicles, and achieve the advantages of infrastructure-based networks without the need for physical infrastructure. The trust mechanism can quickly judge the reliable quality of information (trust of tasks and information). The clustering-based Internet of Vehicles routing protocol can solve most of the routing problems existing in the Internet of Vehicles: such as timely and effective data dissemination, network stability, data management, reliability and scalability.
[0069] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0070] Figure 1 This is a schematic diagram of the vehicle node same-direction driving judgment of the present invention;
[0071] Figure 2The figure is a schematic diagram of the main message structure involved in the present invention.
[0072] Figure 3 Flowchart of selecting cluster head for cluster members of the present invention.
[0073] Figure 4 This is a forwarding flow chart of the cluster member after receiving the cluster member message message according to the present invention.
[0074] Figure 5 It is a schematic diagram of judging the front and rear positions of a vehicle node according to the present invention.
[0075] Figure 6 Schematic diagram of the local node linked list structure of the cluster member vehicles of the present invention.
[0076] Figure 7 The present invention is a schematic diagram of an intra-cluster routing protocol architecture of an Internet of Vehicles based on clustering. DETAILED DESCRIPTION
[0077] The technical solution of the present invention is further described below by means of the accompanying drawings and embodiments. It should be noted that unless otherwise specifically stated, the relative arrangement of components and steps, numerical expressions and numerical values described in these embodiments do not limit the scope of the present invention.
[0078] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.
[0079] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered part of the specification.
[0080] In all examples shown and discussed herein, any specific values should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values.
[0081] Unless otherwise defined, technical or scientific terms used in the present invention shall have the common meanings understood by one having ordinary skills in the field to which the present invention belongs.
[0082] like Figure 7 As shown, the present invention provides a clustering-based intra-cluster routing protocol for an Internet of Vehicles, a clustering-based intra-cluster routing protocol for an Internet of Vehicles, comprising the following steps:
[0083] S1, cluster establishment, cluster head periodically publishes cluster head message and cluster member message, cluster members select cluster head and join the cluster;
[0084] Vehicle nodes with the same driving direction and whose average speed difference with the average speed of cluster head vehicle nodes is less than or equal to a threshold T can join the cluster. The recommended value of threshold T is 5 km / h for urban roads and 10 km / h for expressways.
[0085] The cluster direction is determined as follows: if the vehicle node velocity direction angle is (-π / 4, π / 4), then the vehicles have the same driving direction, such as Figure 1 As shown, V1 has the same travel direction as V2 and V3.
[0086] like Figure 3 As shown in FIG. 1 , the flow chart of cluster member selection of cluster head, further, the specific content of cluster member selection of cluster head in S1 is:
[0087] Each cluster head periodically publishes cluster head messages, and a recommended value for one period is 30 seconds. The format of the cluster head message is as follows: Figure 2 As shown in (a), the cluster head message includes CHID, location, trust value and speed; wherein CHID refers to the cluster head ID, location refers to the coordinate position of the cluster head, trust value refers to the cluster head trust value, and speed includes the average speed of the cluster head vehicle node and the current speed direction;
[0088] If a vehicle node does not receive any cluster head message within three consecutive cycles, it means that there is no cluster head around this vehicle node. Then this vehicle node randomly selects an integer n between 1 and 10, and waits for n cycles starting from the fourth cycle. When the waiting time is over and no cluster head message issued by other vehicle nodes is received, it automatically becomes the cluster head and publishes a cluster head message that it is the cluster head.
[0089] If the vehicle node receives multiple cluster head messages, it selects the sub-cluster with the smallest speed difference between its own node and the cluster head node to join, and sends a cluster member message to the selected cluster head according to S2.
[0090] Furthermore, the cluster head in S1 publishes the cluster member message in the following format: Figure 2 (b) shows: CHID, cluster member message ID, cluster member information table and forwarding node ID list;
[0091] The cluster head first updates the vehicle ID, location, trust value and speed of all members in the cluster according to the received cluster member message. The cluster member information table record format is as follows: Figure 2 (d)
[0092] The cluster member message is published once every period, and the cluster member information table is added to the message and published to the cluster members;
[0093] The cluster member message ID field is 2 bytes long and is used to distinguish cluster member message messages. Each cluster member message message corresponds to a unique cluster member message message ID. Cluster members determine whether they have received the cluster member message message based on the cluster member message message ID, and determine whether to forward the cluster member message message based on their own position relative to the cluster head.
[0094] The cluster member information table includes the vehicle ID, location, trust value and speed (including speed magnitude and speed direction) of each cluster member;
[0095] The forwarding node ID list means that when a cluster member forwards a message of the cluster member, it will add its own vehicle node ID to the forwarding node ID list.
[0096] like Figure 4 As shown, further, the cluster member determines whether it has received the cluster member message according to the cluster member message ID, and determines whether to forward the cluster member message according to its position relative to the cluster head. The specific content is:
[0097] If a cluster member has received a message from this cluster member and the cluster member detects that there is a vehicle node within the range of one-half of the cluster head communication radius, this cluster member will not forward it;
[0098] If a cluster member has received the cluster member message and the cluster member detects that there is no vehicle node within the range of the cluster head communication radius, then the cluster member waits for another half of the cycle, i.e. 15 seconds, to detect whether there is a member forwarding the message within the range of the cluster head. If so, it will not be forwarded, otherwise it will be forwarded;
[0099] If a cluster member receives the cluster member message for the first time and the cluster member is located within the last half of the cluster head communication radius, it will forward it;
[0100] If a cluster member receives the cluster member message for the first time and the cluster member is located within the first half of the cluster head communication radius, the cluster member waits for another half of the cycle, i.e. 15 seconds, to check whether there is a member forwarding it in the second half. If so, it will not forward it, otherwise it will forward it.
[0101] Furthermore, the method for determining whether the cluster member is located at one half before or after the cluster head communication radius R includes:
[0102] Calculate the distance D between cluster members and cluster head;
[0103] Assuming the communication radius is R meters, the location coordinates of cluster members are: (X M ,Y M ), the cluster head position coordinates are: (X H ,Y H ), the distance formula between cluster members and cluster heads is:
[0104]
[0105] If the distance D between a cluster member and the cluster head is less than Then the cluster members are located in the first half of the cluster head’s communication radius;
[0106] If the distance D between a cluster member and the cluster head is greater than Then the cluster members are located in the last half of the cluster head's communication radius.
[0107] S2, cluster members publish cluster member messages to the cluster head;
[0108] Furthermore, the specific steps for cluster member S2 to publish a cluster member message to the cluster head are as follows:
[0109] Cluster members send cluster member messages to the cluster head every 30 seconds, such as Figure 2 (c) shows: vehicle ID, joining or leaving mark, location, trust value and speed;
[0110] The vehicle ID refers to the cluster member ID;
[0111] Join or leave mark means that the vehicle node can be set as a join mark when joining the cluster, and can be set as a leave mark when leaving the cluster; location refers to the current location of the cluster member;
[0112] The trust value is calculated by the cloud data center for each cluster member; speed refers to the speed of the cluster member, including the speed magnitude and speed direction;
[0113] When a cluster member forwards a cluster member message, it adds its own vehicle node ID to the forwarding node ID list. The cluster member can form a forwarding path according to the order of the forwarding vehicle node ID list. When the cluster member publishes a cluster member message to the cluster head, it can propagate in the reverse direction along the forwarding path. If there are multiple forwarding paths to reach the cluster member, the cluster member selects the path with the least number of hops, that is, the path with the least number of forwarding node IDs as the path for publishing the cluster member message to the cluster head;
[0114] If the cluster head does not receive a message from a cluster member within three consecutive cycles, it will issue a query. If it receives a reply from the cluster member, it means that the cluster member still exists. If it does not receive a reply from the cluster member, it means that the cluster member has left. The cluster head updates the cluster member information table and deletes the cluster member from the cluster member information table.
[0115] After a cluster member joins a cluster, it needs to periodically (the recommended period is 30 seconds) publish cluster member messages to the cluster head, including: vehicle node ID, join / leave flag, location, trust value and speed, where the join / leave flag is set to join. After the cluster head receives the cluster member message from each node, it updates the cluster member information table and publishes the cluster member information table along with the cluster member message to each vehicle member node in the cluster;
[0116] When a cluster member leaves the cluster, the cluster member flag is set to leave, and the cluster member message is propagated back to the cluster head along the cluster member message forwarding path. After the cluster head updates the cluster member information table, it publishes the cluster member information table along with the cluster member message to the cluster members.
[0117] S3, the cluster member forms a local node list based on the vehicle ID, trust value, location and speed published by other cluster members;
[0118] Furthermore, the process of cluster members in S3 publishing trust values based on the received trust values from other cluster members is as follows:
[0119] The trust value of each vehicle node is calculated by the cloud data center. Before publishing a message, the vehicle node communicates with the cloud data center. The cloud data center encrypts the trust value of each vehicle node with the private key of the cloud data center and publishes it to each vehicle node. The vehicle node decrypts it with the public key of the cloud data center to obtain its own trust value.
[0120] After the vehicle nodes communicate with each other, they report the communication results to the cloud data center, which calculates the trust value of each vehicle node based on the communication results;
[0121] The cloud data center updates the trust value of each vehicle node based on the communication results reported by the vehicle node in a 24-hour cycle.
[0122] The front and rear determination methods of two vehicle nodes are as follows:
[0123] The source vehicle node is A, and the target vehicle node is B. The angle between the front and rear positions of the two vehicle nodes is used to determine whether the vehicle node B is located in front of or behind the source vehicle node A. The coordinate position of the source vehicle node A at the previous moment is: A1 (X1, Y1), and the coordinate position of the vehicle node B at the previous moment is: B1 (Z1, Q1); the coordinate position of the source vehicle node A at the next moment is: A2 (X2, Y2), and the coordinate position of the vehicle node B at the next moment is: B2 (Z2, Q2);
[0124] like and If the angle θ is an acute angle, then vehicle node B is located in front of source vehicle node A;
[0125] like and If the angle θ is an obtuse angle, vehicle node B is located behind the source vehicle node A.
[0126] like Figure 5 (a) shows that vehicle node B is located in front of source vehicle node A. Figure 5 (b) shows that vehicle node B is located behind source vehicle node A.
[0127] Furthermore, the cluster member forms the local node list according to the vehicle ID, trust value, location and speed issued by other cluster members, and the specific content is:
[0128] The cluster member messages received by the vehicle nodes in the cluster are all cluster member messages issued by other vehicle nodes within the one-hop communication diameter range;
[0129] When a cluster member receives a cluster member message from other vehicle nodes, it will not forward it to other vehicle nodes except for transmitting it to the cluster head along the specified path;
[0130] The vehicle node receives the cluster member message generated by the vehicle node in the front cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the front cluster member to the node linked list Q;
[0131] The vehicle node receives the cluster member message generated by the vehicle node in the rear cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the rear cluster member to the node linked list P;
[0132] When adding a linked list, if the vehicle node already exists, the node data is updated and the lifetime timer is restarted;
[0133] If it does not exist, insert a new node;
[0134] The nodes in the node list Q and the node list P have a lifespan. Nodes that exceed the lifespan will be deleted from the local node list. The lifespan is three cycles. When the cycle is 30 seconds, the recommended lifespan is 90 seconds.
[0135] S4. Cluster members select the next-hop communication node based on the vehicle ID, trust value, distance and speed in their own queue to form intra-cluster routing.
[0136] Furthermore, the cluster members in S4 select the next-hop communication node according to the vehicle ID, trust value and speed in their own queue, and the specific contents of forming the intra-cluster routing include:
[0137] S401, the cluster member vehicle node determines whether it is in the same cluster as the destination vehicle node based on the information in the cluster member information table published by the cluster head. If so, proceed to S402; if not, proceed to a preset inter-cluster routing protocol.
[0138] S402: If the cluster member vehicle node sends data to the destination vehicle node for the first time, the cluster member vehicle node selects the next hop vehicle node from the corresponding local node linked list according to the location of the destination vehicle node when selecting the next hop;
[0139] The next hop vehicle node and the destination vehicle node are added as a record to the local cache of the cluster member vehicle node, and the lifetime of the record is set to a cycle with a value of 30 seconds.
[0140] S403, if the cluster member vehicle node has previously sent data to the destination vehicle node, select the next hop vehicle node according to the cache record information;
[0141] S404: If the cluster member vehicle node is the forwarder of the message, after the forwarding is completed, a confirmation message is sent to the previous hop;
[0142] If the cluster member vehicle node is the generator of this message, there is no need to send a confirmation message;
[0143] If the cluster member vehicle node does not receive a confirmation message within the target time of 5 seconds after the forwarding is completed, the next hop node is deleted from the corresponding queue, and the next hop node is reselected according to S402 to forward again. The specific content of selecting the next hop vehicle node in the local node linked list according to the location of the destination vehicle node is:
[0144] If the destination vehicle node is in front of the cluster member vehicle node, the next hop vehicle node is selected from the node linked list Q of the cluster member vehicle;
[0145] If the destination vehicle node is behind the cluster member vehicle node, the next hop vehicle node is selected from the node linked list P of the cluster member vehicles;
[0146] If the destination vehicle node exists in the local node linked list, the destination vehicle node is directly selected as the next hop.
[0147] The expression for selecting the next-hop vehicle node from the local node list of cluster member vehicles is:
[0148]
[0149] In the above formula, i is the node traversal in the node list Q, trust i is the trust value of the i-th node in the node list Q, d i is the distance from the ith node to the cluster member vehicle node, R is the communication radius between vehicle nodes, v i is the speed of the ith node, and v is the speed of the vehicle node of the cluster member.
[0150] Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solution of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solution to deviate from the spirit and scope of the technical solution of the present invention.
Claims
1. A clustering-based intra-cluster routing protocol for Internet of Vehicles, characterized in that: The following steps are involved: S1, cluster establishment, cluster head periodically publishes cluster head message and cluster member message, cluster members select cluster head and join the cluster; S2, cluster members publish cluster member messages to the cluster head; S3, the current cluster member receives the vehicle ID, trust value, location and speed issued by other cluster members and forms a local node list, where the local node list includes a node list Q and a node list P; S4. Cluster members select the next-hop communication node based on the local node list to form intra-cluster routing.
2. According to claim 1, a clustering-based intra-cluster routing protocol for Internet of Vehicles is characterized in that: The specific content of cluster member selection of cluster head in S1 is: The cluster head periodically publishes a cluster head message, wherein the cluster head message includes CHID, location, trust value and speed; Among them, CHID refers to the cluster head ID, location refers to the coordinate position of the cluster head, trust value refers to the cluster head trust value, and speed includes speed magnitude and speed direction; If the vehicle node receives multiple cluster head messages, it selects the sub-cluster with the smallest speed difference between its own node and the cluster head node to join the cluster head, and sends a cluster member message to the selected cluster head according to S2; If a vehicle node does not receive any cluster head message issued by any cluster head within three consecutive cycles, the vehicle node randomly selects an integer n between 1 and 10, and waits for n cycles starting from the fourth cycle. When the waiting time is over and it still does not receive the cluster head message issued by other vehicle nodes, it automatically becomes the cluster head and publishes the cluster head message.
3. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 1, characterized in that: The specific content of the cluster member message periodically released by the cluster head in S1 is: The cluster head updates the vehicle ID, location, trust value and speed of all members in the cluster according to the received cluster member message to form a cluster member information table; The cluster member message is published once in each period, and the cluster member information table is added to the cluster member message and published to the cluster members; The length of the ID field of the cluster member message is 2 bytes. The ID field is used to distinguish cluster member message messages. The cluster member message message corresponds to a unique cluster member message message ID. The cluster member determines whether it has received the cluster member message according to the cluster member message ID, and determines whether to forward the cluster member message according to its position relative to the cluster head; The cluster member message includes: CHID, cluster member message message ID, cluster member information table and forwarding node ID list, CHID refers to cluster head ID; The cluster member information table includes the vehicle ID, location, trust value and speed of each member in the cluster; When the current cluster member forwards a message from another cluster member, it will add the vehicle node ID of the current cluster member to the forwarding node ID list in the forwarded cluster member message.
4. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 3, characterized in that: The cluster member determines whether it has received the cluster member message according to the message ID of other cluster members, and determines whether to forward the cluster member message according to its position relative to the cluster head. The specific content is: If a cluster member has received a message from this cluster member and the cluster member detects that there is a vehicle node within the range of one-half of the cluster head communication radius, this cluster member will not forward it; If a cluster member has received the message of the cluster member and the cluster member detects that there is no vehicle node within the range of the second half of the cluster head communication radius, then the cluster member waits for another half of the period to detect whether there is a member forwarding the message within the second half of the radius. If there is, it will not be forwarded, otherwise it will be forwarded; If a cluster member receives the cluster member message for the first time and the cluster member is located within the last half of the cluster head communication radius, it will forward it; If a cluster member receives the cluster member message for the first time and the cluster member location is within the first half of the cluster head communication radius, the cluster member waits for another half of the cycle to detect whether there is a member forwarding it in the second half. If so, it will not forward it, otherwise it will forward it.
5. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 4, characterized in that: Methods for determining whether a cluster member is located within the first and second half of the cluster head communication radius R include: Calculate the distance D between cluster members and cluster head; If the distance D between a cluster member and the cluster head is less than Then the cluster members are located in the first half of the cluster head’s communication radius; If the distance D between a cluster member and the cluster head is greater than Then the cluster members are located in the last half of the cluster head's communication radius.
6. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 1, characterized in that: The specific steps for cluster member S2 to publish cluster member messages to the cluster head are as follows: Each cluster member publishes a cluster member message to the cluster head in each cycle, including: vehicle ID, joining or leaving mark, location, trust value and speed; The vehicle ID refers to the cluster member ID; Join or leave mark means that the vehicle node can be set as a join mark when joining the cluster, and can be set as a leave mark when leaving the cluster; location refers to the current location of the cluster member; The trust value is calculated by the cloud data center for each cluster member; the speed includes the speed magnitude and speed direction; When a cluster member forwards a cluster member message, it adds its own vehicle ID to the forwarding node ID list of the cluster member message. The cluster member can form a cluster head message forwarding path according to the forwarding node ID sequence, and send the cluster member message to the cluster head in the opposite direction of the forwarding path. If there are multiple forwarding paths to a cluster member at this time, the cluster member selects the path with the least hops, that is, the path with the least number of forwarding node IDs, as the path for publishing cluster member messages to the cluster head; If the cluster head does not receive a message from a cluster member within three consecutive cycles, it will issue a query. If it receives a reply from this cluster member, it means that this cluster member exists; if it does not receive a reply from this cluster member, it means that this cluster member has left, and the cluster head updates the cluster member information table and deletes the cluster member from the cluster member information table; When a cluster member joins a cluster, it periodically publishes a cluster member message to the cluster head, including: vehicle ID, joining mark, location, trust value and speed, where the joining or leaving mark part is set as the joining mark. The cluster head updates the information of this vehicle node, updates the cluster member information table, and then publishes the cluster member information table to the cluster members along with the message; When a cluster member leaves the cluster, the cluster member mark part is set to leave, and the cluster member sends a cluster member message to the cluster head along the opposite direction of the cluster member message forwarding path to report the departure. The cluster head updates the information of this vehicle node, and after updating the cluster member information table, it publishes the cluster member information table to the cluster members along with the cluster member message.
7. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 1, characterized in that: The specific content of the local node list formed by the cluster member based on the vehicle ID, trust value, location and speed size received from other cluster members is as follows: The cluster member messages received by the vehicle nodes in the cluster are all cluster member messages issued by other vehicle nodes within the one-hop communication diameter range; When a cluster member receives a cluster member message from other vehicle nodes, it will not forward it to other vehicle nodes except for transmitting it to the cluster head along the specified path; The vehicle node receives the cluster member message generated by the vehicle node in the front cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the front cluster member to the node linked list Q; The vehicle node receives the cluster member message generated by the vehicle node in the rear cluster, and adds the vehicle ID, trust value, distance to the cluster member vehicle node and speed of the rear cluster member to the node linked list P; When adding a vehicle node to the local node list, if the vehicle node already exists, the node data is updated and the lifetime timer is restarted; If it does not exist, insert a new node; Among them, the nodes in the node list Q and the node list P have a lifetime. Nodes that exceed the lifetime will be deleted from the local node list. The lifetime is three cycles.
8. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 1, characterized in that: In S4, cluster members select the next-hop communication node according to the vehicle ID, trust value and speed in the local node list. The specific contents of forming the intra-cluster routing include: S401, the cluster member vehicle node determines whether it is in the same cluster as the destination vehicle node based on the information in the cluster member information table published by the cluster head. If so, proceed to S402; if not, proceed to a preset inter-cluster routing protocol. S402: If the cluster member vehicle node sends data to the destination vehicle node for the first time, the cluster member vehicle node selects the next hop vehicle node from the local node linked list according to the location of the destination vehicle node when selecting the next hop; The next hop vehicle node and the destination vehicle node are added as a record to the local cache of the cluster member vehicle node, and the lifetime of the record is set to a cycle; S403, if the cluster member vehicle node has sent data to the destination vehicle node in the past, select the next hop vehicle node according to the cache record information; S404: If the cluster member vehicle node is the forwarder of the message, after the forwarding is completed, a confirmation message is sent to the previous hop; If the cluster member vehicle node is the generator of this message, there is no need to send a confirmation message; If the cluster member vehicle node does not receive the confirmation message within the target time after the forwarding is completed, the next hop node is deleted from the corresponding queue, and the next hop node is reselected according to S402 to forward again.
9. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 8, characterized in that: The specific content of selecting the next hop vehicle node in the local node list according to the location of the destination vehicle node is: If the destination vehicle node is in front of the cluster member vehicle node, the next hop vehicle node is selected from the node linked list Q of the cluster member vehicle; If the destination vehicle node is behind the cluster member vehicle node, the next hop vehicle node is selected from the node linked list P of the cluster member vehicles; If the destination vehicle node exists in the local node linked list, the destination vehicle node is directly selected as the next hop.
10. The intra-cluster routing protocol of the Internet of Vehicles based on clustering according to claim 9, characterized in that: The expression for selecting the next-hop vehicle node from the local node list of cluster member vehicles is: In the above formula, i is the node traversal in the node list Q, trust i is the trust value of the i-th node in the local node list, d i is the distance from the ith node to the cluster member vehicle node, R is the communication radius between vehicle nodes, v i is the speed of the ith node, and v is the speed of the vehicle node of the cluster member.
