Data caching method and device for vehicle named data network

Abstract

The application discloses a data caching method and device of a vehicle named data network, wherein the method comprises the following steps: a vehicle node acquires influencing factors of data exchange in the network and influencing factors of one-hop neighbors around the vehicle node; according to one-hop neighbor information table and attributes of the node itself, the vehicle node acquires a fuzzy output value by using a fuzzy inference system; according to the obtained fuzzy output value, the current vehicle node determines a node priority to which the vehicle node belongs, and broadcasts the fuzzy output value of the vehicle node; according to the received fuzzy output value, the vehicle node selects a node with the highest output value among the vehicle nodes as a cluster head and sends a cluster entry application to the cluster head to form a cluster structure; the cluster head node collects various types of data in the cluster, packs the collected data and broadcasts the data; according to popular information and a self position, the nodes in the cluster execute corresponding caching strategies on various types of data. The application reduces caching redundancy among the nodes, improves data transmission efficiency and caching hit rate, and can be widely applied to the field of Internet of Vehicles.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking, and in particular to a data caching method and apparatus for a vehicle naming data network. Background Technology

[0002] Information-Centric Networking (ICN), a content-oriented, information-centric network, has been proposed to improve or replace traditional object-oriented IP networks. Within existing ICN architectures, Named Data Networking (NDN) is one of the main research directions. The distributed communication mechanism, hierarchical naming, and data caching capabilities of NDN can improve communication problems arising from high mobility in vehicular networks. Therefore, research on vehicle-specific named data networks has always been a hot topic, and caching decision-making is one of the research directions within this field.

[0003] The network's communication is based on a request / response model, with a focus on content. The named data network defines two data message types: Interest packets and Data packets. Each vehicle node maintains three important data structures: CS (Content Store), PIT (Pending Interest Table), and FIB (Forwarding Information Base) to forward content data. Different data types have different characteristics, therefore, different caching strategies can be applied to different data types. Traffic safety data, such as car accidents and road collapses, which have high latency requirements and are crucial to road vehicle safety, should be processed as quickly and reliably as possible. Entertainment data, such as multimedia video and audio, has lower latency requirements but larger packet size and requires more storage space. Therefore, different strategies should be adopted for different types of message data based on their different data characteristics.

[0004] Considering that in typical high-speed scenarios, due to suitable vehicle density, vehicle nodes generally maintain a relatively long time at an appropriate speed on a single road. Furthermore, cache redundancy among vehicle nodes can be mitigated through collaborative caching, reducing the waste of cache resources. The clustered structure formed by vehicle nodes can significantly coordinate cache resources within a cluster, facilitating collaborative caching. Within a node cluster, nodes with different characteristics should prioritize caching different types of message data. For example, an edge node with a speed significantly different from the cluster's average speed, which will soon leave the cluster, is better suited to caching entertainment data with long effective durations and broad applicability, thus expanding the value of entertainment data for more nodes. Summary of the Invention

[0005] In order to at least partially solve one of the technical problems existing in the prior art, the purpose of this invention is to provide a data caching method and apparatus for a vehicle naming data network.

[0006] The technical solution adopted in this invention is:

[0007] A data caching method for a vehicle naming data network includes the following steps:

[0008] S1. Factors influencing data exchange in the network for vehicle nodes, and factors influencing their one-hop neighbors.

[0009] S2. Based on the one-hop neighbor information table and the node's own attributes, the vehicle node uses the fuzzy inference system to obtain a fuzzy output value.

[0010] S3. Based on the obtained fuzzy output value, the current vehicle node determines the priority of the node to which it belongs and broadcasts its own fuzzy output value.

[0011] S4. Based on the received fuzzy output values, the vehicle nodes select the node with the highest output value as the cluster head and send a cluster entry application to it to form a cluster structure.

[0012] S5. The cluster head node collects various types of data within the cluster, packages the collected data, and broadcasts it.

[0013] S6. Based on popularity information and their own location, nodes within the cluster execute corresponding caching strategies for various types of data.

[0014] Furthermore, the factors influencing the data exchange include the vehicle node receiving a request for interest message, and the factors influencing the surrounding one-hop neighbors include security messages sent by one-hop neighbors.

[0015] The interest request messages received by vehicle nodes are divided into three categories based on their application scope and latency requirements: entertainment message interest request packets, traffic management message interest request packets, and traffic emergency message interest request packets. The security messages sent by one-hop neighbors received by vehicle nodes include: vehicle ID, vehicle location, and vehicle speed.

[0016] Furthermore, the one-hop neighbor information table includes the neighbor's speed, location, and historical contact level, and the node's own attributes include betweenness centrality, degree centrality, and content responsiveness.

[0017] The fuzzy inference system adopts the Mamdani fuzzy inference system. The input membership function of the system is the Gaussian input membership function, and the output membership function is the triangular membership function.

[0018] The vehicle node uses a fuzzy inference system to obtain a fuzzy output value, including:

[0019] Based on the fuzzy inference system, the final output value is obtained by using the centroid method, and is used as the fuzzy output value.

[0020] Furthermore, the one-hop neighbor information table is obtained by establishing it in the following way:

[0021] Each neighbor node stores the following information: vehicle ID, vehicle location, vehicle speed, and historical contact level. Time is discretized, and the formula for calculating the historical contact level (CT) is as follows:

[0022]

[0023] In the formula, T is the current time, t0 is the discretized historical time, and ε is the decay parameter;

[0024] Nodes establish a one-hop neighbor information table by collecting basic security messages broadcast by other nodes within their transmission range;

[0025] The node's own attributes include content responsiveness (RS), and the formula for calculating the content responsiveness (RS) is as follows:

[0026]

[0027] In the formula, N req and N rec These represent the number of interest packets received and the number of response packets, respectively.

[0028] Furthermore, the input to the fuzzy inference system in step S2 consists of two factors: one is the motion stability factor f, which is determined by the node's motion state. mov The factor is:

[0029] f mov=α1×VD+α2×CT

[0030] Where α1 and α2 are weighting parameters, and VD is the velocity difference, which is calculated as follows:

[0031]

[0032] Among them, V avg The average speed of the nodes' neighbors is one factor. The other is the intra-cluster rank factor f, which is determined by the vehicle's position within the network topology. lev The factor is:

[0033] f lev =β1×MC+β2×RS

[0034] Where β1 and β2 are weight parameters, and MC is the node centrality, which is calculated as follows:

[0035]

[0036] Among them, CP i For vehicle node V i The central value of , while CP i The calculation is as follows:

[0037] CP i =BC i ×DC i

[0038] Where BC represents betweenness centrality and DC represents degree centrality.

[0039] Furthermore, in step S3, the priority of nodes is divided into three levels based on the output value of fuzzy inference: isolated priority. Cluster member priority Cluster head priority

[0040] Furthermore, in step S4, if a node's cluster entry request still does not receive a response after retransmission, it sends cluster entry requests sequentially according to the output value of the cluster head, until a response is received indicating successful cluster entry. If the node itself is the vehicle with the highest output value within a one-hop range, it broadcasts a cluster head declaration.

[0041] Further, step S5 includes:

[0042] The cluster head node performs statistics on the data collected within a preset time Δt to obtain statistical messages. The statistical messages include: the number of nodes in the cluster, the proportion of each of the three types of request interest packets in the total number of request interest packets, and the IDs of the three interest packets with the highest request frequency for each of the three types of request interest packets.

[0043] The cluster head node encapsulates the statistical messages into packets and broadcasts them.

[0044] Furthermore, the three data types include entertainment messages, traffic management messages, and traffic emergency messages; each node within the cluster has a different base cache score S for each of the three different types of response data packets based on its priority. b The cache base score is calculated by combining the network topology position of nodes with different priority levels, the movement trend relative to surrounding vehicles, and the data characteristics of the three types of data through the analytic hierarchy process.

[0045] The three types of data characteristics are evaluated from four dimensions: storage size, effective time, scope of application, and latency requirements. Different priority nodes consider the importance of each dimension and the relative scores of the three types of data in these four dimensions as the basic parameters of the analytic hierarchy process.

[0046] Furthermore, node V i For the received data packet P j Cache score S i,j The calculation is performed using the following formula:

[0047] S i,j =γ×[μ×S b +R(t′)×e -λ(t-t′) ]

[0048] Where γ is the cache gain parameter, μ is the correction factor, and S b Let R(t′) be the base score for caching, and let e be the historical score of the data packet at the previous time t′. -λ(t-t′) This is the score decay function.

[0049] Further, in step S6, to reduce cache redundancy by caching different data packets of the same type on different nodes, a cache gain parameter γ is designed to help nodes improve the cache score of some data packets. Nodes determine whether to apply cache gain to received data packets based on their relative position to the cluster head and the data packet generation timestamp. The data packet generation timestamp is mapped onto a clock disk corresponding to a one-hop range of the cluster head; that is, 360° within a one-hop range centered on the cluster head corresponds to 360° on the clock disk. The first vehicle node encountered clockwise from the angle indicated by the timestamp on the clock disk is the corresponding cache gain node for that data packet. The cluster head node is considered to be at 0° at this point. If there are multiple nodes at this angle, the node with the smallest ID is selected for cache gain. The cache gain parameter can be expressed as:

[0050]

[0051] Where C j The data packet j represents any content.

[0052] Further, step S6 includes:

[0053] After a vehicle node is matched with a data packet, it is necessary to consider whether there is a need for cache gain. That is, if the data packet popularity is insufficient, cache gain should not be considered due to the need for cache space and practicality.

[0054] There are three cases for the three different types of data packets:

[0055] Case 1: If the received data packet is a traffic emergency message, since this type of data has the characteristics of small space occupation, high latency requirements and high importance, the node allows it to have cache redundancy. Therefore, for this type of data packet, as long as the node corresponds to the data packet, cache gain is applied.

[0056] Scenario 2: If the received data packet is a traffic management message, since this type of data is helpful for road driving and occupies relatively little space, the node allows it to have a certain degree of cache redundancy within the cluster. The node calculates the received data packet C. j The popularity value P of a data packet is obtained by multiplying the highest similarity value by the frequency percentage of requests of that type among the top three interest packets of the same type statistically analyzed by the cluster head. j We can obtain:

[0057]

[0058] Scenario 3: If the received data packet is an entertainment message, since this type of data occupies a large amount of space and is of relatively low importance, the node has strict requirements for cache redundancy for this type of data packet; calculate the popularity value P of this data packet. j We can obtain:

[0059]

[0060] Where γ is the buffer gain parameter, and N represents the number of nodes in the cluster. That is, when both the data packet and node matching and the data packet popularity value are greater than the threshold are met, the node will perform buffer gain on the data packet.

[0061] Furthermore, the popularity value P j The following formula is used to calculate:

[0062]

[0063] P j =sim j *F k

[0064] Where m represents the length of the two content names matched, |s1| and |s2| represent the lengths of the two content names s1 and s2 respectively, t represents half the transposition target, and F k This indicates the frequency of requests of this type.

[0065] Furthermore, in step S6, the information exchange process during node operation can correct the basic cache score. The node obtains the initial basic cache scores β1, β2, and β3 for the three types of data packets using the analytic hierarchy process (AHP). The node then calculates the proportion of requests received within a time period Δt as β1′, β2′, and β3′, thus obtaining the objective correction factor μ for each type of basic score:

[0066] μ=[1+(β′-β)×(1-θ)]

[0067] Where θ represents the content responsiveness of this type of request, and β′ and β are the initial base cache score and request ratio of this type of message, respectively.

[0068] Another technical solution adopted in this invention is:

[0069] A data caching device for a vehicle naming data network, comprising:

[0070] At least one processor;

[0071] At least one memory for storing at least one program;

[0072] When the at least one program is executed by the at least one processor, the at least one processor implements the method described above.

[0073] The beneficial effects of this invention are: by using a fuzzy inference system, this invention converts the motion state and intra-cluster topological position of vehicle nodes into a more detailed intra-cluster level, further refines the comprehensive characteristics of vehicles within the cluster, improves the efficiency of cooperation and communication between vehicles, allows vehicles to better increase the utility value of cached content, reduces cache redundancy between nodes, and improves data transmission efficiency and cache hit rate. Attached Figure Description

[0074] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following description is provided with accompanying drawings of the relevant technical solutions in the embodiments of the present invention or the prior art. It should be understood that the accompanying drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0075] Figure 1This is a flowchart illustrating the steps of a data caching method for a vehicle naming data network based on vehicle clustering and message data characteristics, as described in an embodiment of the present invention.

[0076] Figure 2 This is a schematic diagram of the basic security message structure for timed broadcasting by vehicle nodes in an embodiment of the present invention;

[0077] Figure 3 This is a schematic diagram of the popular statistics message broadcast by the cluster head node in an embodiment of the present invention;

[0078] Figure 4 This is a diagram showing the actual distribution of vehicles forming a cluster structure in an embodiment of the present invention;

[0079] Figure 5 This is a road structure diagram of the simulation environment in this embodiment of the invention;

[0080] Figure 6 This is a comparison chart of the cache hit rate of vehicles in a high-speed road environment using three caching methods in this embodiment of the invention, over time.

[0081] Figure 7 This is a comparison chart of the broadcast success rates of four broadcasting methods in the embodiments of the present invention for transmitting emergency messages to the target area in an intermittent network. Detailed Implementation

[0082] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0083] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0084] In the description of this invention, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0085] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0086] like Figure 1 As shown, this embodiment provides a data caching method for vehicle-named data networks based on vehicle clustering and message data characteristics. This method enables collaborative caching of content data packets among vehicle nodes, reducing cache redundancy and ensuring the reliability, low latency, and high efficiency of interest requests. The method specifically includes the following steps:

[0087] S1. Factors influencing data exchange in the network for vehicle nodes, and factors influencing their one-hop neighbors.

[0088] In step S1, the factors influencing data exchange include the vehicle node receiving a request for interest message, and the factors influencing the surrounding one-hop neighbors include security messages sent by the one-hop neighbors. In the vehicle naming data network, information exchange between nodes relies on interest packets and data packets. When information is needed, a node encapsulates a request for interest packet according to the requirement and waits for the arrival of a data packet containing the required information. Request message interest packets can be divided into entertainment message request for interest packets, traffic management message request for interest packets, and traffic emergency message request for interest packets. The content of basic security messages includes: vehicle ID, vehicle location, and vehicle speed.

[0089] S2. Based on the neighbor information table and the node's own attributes, the node uses the fuzzy inference system to obtain a fuzzy output value.

[0090] The process of creating the neighbor information table is as follows:

[0091] See Figure 2 Nodes periodically broadcast basic security messages; nodes build a neighbor information table by collecting basic security messages broadcast by other nodes within their transmission range; the neighbor information table contains vehicle ID, vehicle location, vehicle speed, and historical vehicle contact information; time is discretized, and the historical vehicle contact information (CT) is calculated as follows:

[0092]

[0093] Where T is the current time, t0 is the discretized historical time, and ε is the decay parameter.

[0094] In step S2, degree centrality represents the degree to which a node is directly connected to other nodes; betweenness centrality represents a node's ability to control the propagation of information to other nodes; and content responsiveness, one of the self-attributes, represents the degree to which a node can respond to requests. The content responsiveness RS is calculated as follows:

[0095]

[0096] In the formula, N req and N rec These represent the number of interest packets received and the number of response packets, respectively.

[0097] As an optional implementation, the fuzzy inference system adopts the Mamdani fuzzy inference system. Mamdani's output is a conceptual or linguistic description; since we need to prioritize vehicles within a cluster, this type of inference system is chosen. The input membership function is a Gaussian input membership function, which offers good anti-interference capabilities due to its smoothness. The system input consists of two factors: one is the motion stability factor f, determined by the node's driving motion state. mov The motion stability factor represents the motion tendency of a node relative to the cluster structure. A larger factor indicates greater stability within the cluster structure, preventing it from leaving the cluster in a short period. This factor is calculated as follows:

[0098] f mov =α1×VD+α2×CT

[0099] Where α1 and α2 are weighting parameters, and VD is the velocity difference, which is calculated as follows:

[0100]

[0101] Where V avg The average speed of the nodes' neighbors is one factor. The other is the intra-cluster rank factor f, which is determined by the vehicle's position within the network topology. lev The cluster hierarchy factor represents the node's position in the overall information exchange within the cluster. A larger factor indicates a more central role for the node in the cluster's information exchange process, enabling it to better coordinate information exchange among cluster members. This factor is calculated as follows:

[0102] f lev =β1×MC+β2×RS

[0103] Where β1 and β2 are weight parameters, and MC is the node centrality, which is calculated as follows:

[0104]

[0105] Among them CP i For vehicle node V i The central value of , while CP i The calculation is as follows:

[0106] CP i =BC i ×DC i

[0107] Where BC represents betweenness centrality and DC represents degree centrality. The output membership function in the fuzzy system is a triangular membership function. The triangular membership function is relatively simple, which reduces the difficulty of solving for the output value using the centroid method and facilitates computation. The final output value is obtained using the centroid method. The centroid method calculates the centroid of the area enclosed by the curve of the output membership function and the variable axis as the final output value. The centroid method can fully utilize the fuzzy information derived from the fuzzy derivation, and the obtained output value has good robustness.

[0108] S3. Based on the obtained fuzzy output value, the current node determines the priority of the node to which it belongs and broadcasts its own fuzzy output value.

[0109] In step S3, the priority of nodes within a cluster is divided into three levels based on the output value of fuzzy inference: isolated priority. Cluster member priority Cluster head priority A higher priority node has a more stable structural position within the cluster and can communicate within the cluster for a longer period of time. Conversely, a lower priority node has more freedom and can contact more other nodes along the path.

[0110] S4. Based on the received output values, the nodes select the node with the highest output value as the cluster head and send a cluster entry request to it to form a cluster structure.

[0111] In this embodiment, if a node's cluster entry request still does not receive a response after retransmission, it sends cluster entry requests sequentially according to the output value of the cluster head, until a response is received, indicating successful cluster entry. If the node itself is the vehicle node with the highest output value within a one-hop range, it broadcasts a cluster head declaration and responds to the cluster entry requests of the other nodes.

[0112] S5. The cluster head node collects the top three most popular data of two types within the cluster, the number of vehicles within the cluster, and the request frequency of the three types, and encapsulates them into packets for broadcast.

[0113] See Figure 3In this embodiment, the information collected by the cluster head node at regular intervals Δt includes the number of nodes within the cluster, the percentage of each of the three types of request interest packets in the total number of request interest packets, and the IDs of the three most frequent request interest packets of each type. The cluster head vehicle broadcasts the above statistical messages periodically.

[0114] S6. Based on popularity information and their own location, nodes within the cluster execute corresponding caching strategies for various types of data.

[0115] In this embodiment, node V i For the received data packet P j Cache score S i,j The calculation is performed using the following formula:

[0116] S i,j =γ×[μ×S b +R(t′)×e -λ(t-t′) ]

[0117] Where γ is the cache gain parameter, μ is the correction factor, and S b Let R(t′) be the base score for caching, and let e be the historical score of the data packet at the previous time t′. -λ(t-t′) This is a score decay function. The score is used to select content to be evicted when the node's available storage space is exhausted. Content with higher scores has lower evicting priority, and content with lower scores has higher evicting priority.

[0118] Cluster nodes have different base cache scores (S) for the three different types of response packets they receive, based on their respective priorities. b The calculation of the cache baseline score combines the network topology position of nodes with different priority levels, the movement trend relative to surrounding vehicles, and the data characteristics of the three types of data, obtained through the Analytic Hierarchy Process (AHP). AHP can transform multi-objective, multi-criteria decision-making problems that are difficult to quantify entirely into multi-level single-objective problems, emphasizing qualitative analysis and judgment more than general quantitative methods. The data characteristics of the three types of data are evaluated from four dimensions: storage size, effective time, scope of application, and latency requirements. Each of these three types of data has its own emphasis in these dimensions; for example, entertainment messages require relatively large storage space, while road safety messages have relatively strict latency requirements. The importance of each dimension to the node for different priority nodes and the relative scores of the three types of data in these four dimensions are used as the basic parameters of the AHP.

[0119] To reduce cache redundancy by caching different data packets of the same type on different nodes, a cache gain parameter γ is designed to help nodes improve the cache score of some data packets. This cache gain mechanism encourages nodes to cache matching content as much as possible. Nodes determine whether to match received data packets for cache gain based on their relative position to the cluster head and the data packet's generation timestamp. The data packet generation timestamp is mapped onto a clock disk corresponding to a one-hop range of the cluster head; that is, 360° within a one-hop range centered on the cluster head corresponds to 360° on the clock disk. The first node encountered clockwise from the angle indicated by the timestamp on the clock disk is the corresponding cache gain node for that data packet. The cluster head node is considered to be at 0° at this point. If there are multiple nodes at this angle, the node with the smallest ID is selected for cache gain. The cache gain parameter can be expressed as:

[0120]

[0121] Where C j Let j represent a data packet with arbitrary content. When a vehicle node matches a data packet, consider whether cache gain is necessary. That is, if the data packet's popularity is insufficient, consider the cache space and the utility of caching this data packet; cache gain should not be applied to avoid occupying space for other, more popular data content. For certain data types, cache gain is only applied when the content data is sufficiently popular, i.e., its popularity value P. j Cache gain is only applied when the data size exceeds a certain threshold. The storage space and caching necessity for the three different types of data packets also differ due to their data characteristics, falling into the following three categories:

[0122] Scenario 1: If the received data packet is a traffic emergency message, due to its characteristics of small space occupation, high latency requirements and high importance, the node allows it to have cache redundancy to ensure that requests for this type of data can be responded to in a timely manner to the greatest extent. Therefore, for this type of data packet, as long as the node corresponds to the data packet, it will perform cache gain.

[0123] Scenario 2: If the received data packet is a traffic management message, since it assists in road driving and occupies relatively little space, the node allows it to have a certain degree of cache redundancy within the cluster. The node calculates the received data packet C. j The popularity value P of a data packet is obtained by multiplying the highest similarity value by the frequency percentage of requests of that type among the top three interest packets of the same type statistically analyzed by the cluster head. jBecause the vehicle naming data network uses a hierarchical naming method, and people will request similar content that interests them, data content that is more similar to popular content (i.e., has more naming levels) is likely to be requested again in the future. For example, popular entertainment content might be named like this: Music\R&B\2000-2010\Singer A\Album A\Song A. If a data packet is received named like this: Music\R&B\2000-2010\Singer A\Album B\Song B, it is judged to be likely to become popular content in the future and is therefore cached first because of its high similarity to popular content. (The last sentence appears to be a separate, unrelated statement: "Judging P...") j The similarity calculation formula uses Jaro similarity, P j The specific calculation formula is as follows:

[0124]

[0125] P j =sim j *F k

[0126] Where m represents the length of the matching two content names, |s1| and |s2| represent the lengths of the two content names s1 and s2 respectively, t represents half of the transposition target, and F k This indicates the frequency of requests of this type. Therefore:

[0127]

[0128] Where N represents the number of nodes within the cluster, i.e., when both packet and node matching and packet flow value are greater than a threshold are satisfied. The node performs buffering gain on the data packet under two conditions.

[0129] Scenario 3: If the received data packet is an entertainment message, it occupies a large amount of space and has relatively low importance. Therefore, caching should be reduced for non-popular entertainment messages, and the node has stricter requirements for cache redundancy for this type of data packet. Based on the popularity value calculation formula proposed in Scenario 2, the popularity value P of this data packet is also calculated. j We can obtain:

[0130]

[0131] Where N represents the number of nodes within the cluster, i.e., when both packet and node matching and packet flow value are greater than a threshold are satisfied. The node performs buffering gain on the data packet under two conditions.

[0132] As an optional implementation, the initially set cache baseline score may not be sufficiently accurate in some cases. Therefore, the cache baseline score can be corrected by the nodes during information exchange while they are in motion, based on the information collected. The nodes obtain the initial baseline cache scores β1, β2, and β3 for three types of data packets using the analytic hierarchy process (AHP). The nodes then statistically analyze the proportions of requests received within a time period Δt, which are β1′, β2′, and β3′. The objective correction factor μ for each type of baseline score can then be obtained as follows:

[0133] μ=[1+(β′-β)×(1-θ)]

[0134] Where θ represents the content responsiveness of this type of request, and β′ and β are the initial base cache score and request ratio of this type of message, respectively.

[0135] The above method will be explained in detail below with reference to the accompanying drawings and specific embodiments.

[0136] like Figure 1 As shown, this embodiment provides a data caching method for a vehicle naming data network based on vehicle clustering and message data characteristics, including the following steps:

[0137] S101. The vehicle node collects and analyzes the basic security messages sent by its surrounding one-hop neighbors and the available information in the request interest packets.

[0138] S102. Vehicle node X, combining information from its neighbor information table and its own network position and topology attributes, derives an output value through a fuzzy inference system. The neighbor information table is shown in Table 1 below:

[0139] Table 1. One-hop neighbor list for vehicle X

[0140] ID speed distance Historical contact level A 80 100 0.686 B 90 130 0.845 C 110 90 0.524 D 100 120 0.626

[0141] S103, vehicle node X obtains its fuzzy inference output value of 0.724, identifies itself as the cluster head priority, and broadcasts its output value.

[0142] S104. After receiving the output value broadcast from surrounding vehicles, vehicle node X determines itself to be the vehicle with the highest output value within that one-hop range, declares itself to be the cluster head node, and responds to the cluster entry requests issued by other vehicle nodes.

[0143] S105. After receiving cluster request interest packets over a period of time Δt, vehicle node X statistically analyzes the data types of the requests and the frequency of each request, encapsulates the information into packets, and broadcasts them.

[0144] S106, When vehicle node X receives a data packet C j Generally speaking, X is a forwarder, not C.j The final target vehicle. First, determine the type of the data packet. Taking a road management message as an example, node X, with cluster head priority, has a base cache score of 0.328. Then, determine if it is a matching data packet. The node checks its timestamp and finds that its second value is 58.25, which corresponds to 349.5° on a clock face. The first node encountered clockwise from this point is X, which is at 0°. At the same time, there are no other nodes at 0°, so data packet C... j It matches node X. Since it's a road management message, popularity assessment is necessary. (The last part, "C," appears to be a typo and can be omitted.) j The popularity of the naming was compared with the top three most popular content names in the traffic management category. j The calculation of P. j The value is 0.315, and the number of vehicles in the cluster is 5, so P j The value is greater than the popularity threshold of 0.2, thus satisfying the popularity judgment. At this point, vehicle X corresponds to data packet C. j Apply cache gain. If the correction factor derived by the cluster head node from the difference between the proportion of each type of request received and the base cache score is 1.1, and if the cluster head's cache space is full, simplify the cluster head node's cache space settings as shown in Table 2. At this point, C... j The final cache score was 0.693, which is greater than the lowest cache score of C4, so C4 was replaced. The replaced cache space is shown in Table 3.

[0145] Table 2. Old cache space of node X

[0146] ID Update time Cache score <![CDATA[C1]]> 150s 0.786 <![CDATA[C2]]> 120s 0.624 <![CDATA[C3]]> 110s 0.606 <![CDATA[C4]]> 100s 0.568

[0147] Table 3. Cache space after node X is replaced

[0148] ID Update time Cache score <![CDATA[C1]]> 150s 0.786 <![CDATA[C j ]]> 165s 0.693 <![CDATA[C2]]> 120s 0.624 <![CDATA[C3]]> 110s 0.606

[0149] In contrast, the following describes step S106 of vehicle node A upon receiving a data packet.

[0150] If vehicle node A also receives the data packet C j If node A is a cluster member node, then for C... j The base cache score is 0.335, and the popularity criterion is the same as that for vehicle node X, which is popularity P. j The popularity exceeds the threshold, satisfying the gain condition. However, since node A is located at a 150° azimuth angle relative to cluster head node X, its interaction with packet C is limited. j This does not constitute a matching relationship, and no cache gain is applied. If the cache space of node C is simplified as shown in Table 4, and the correction factor is 1.05, then node A will ultimately have a different cache space than node C. jIts cache score is 0.352. Since its score is not greater than the minimum score (C5) in the cache space, it was not cached by node A.

[0151] Table 4. Old cache space of vehicle C

[0152] ID Update time Cache score <![CDATA[C3]]> 110s 0.618 <![CDATA[C7]]> 155s 0.476 <![CDATA[C6]]> 130s 0.382 <![CDATA[C5]]> 145s 0.366

[0153] The above embodiments demonstrate that the method of this embodiment can help vehicles better utilize cache space for caching collaboration, enabling different types of data packets to be better cached on appropriate priority vehicle nodes, preventing adjacent vehicles from caching the same data packet simultaneously, reducing cache redundancy between vehicles, and improving request hit rate and transmission efficiency.

[0154] This embodiment sets up different simulation times for the same cache space on a highway with the same vehicle density, to demonstrate the superiority of the caching method presented in this paper in terms of startup speed and upper limit of performance. The simulated vehicles form a cluster structure as follows: Figure 4 As shown, the simulated road model is as follows: Figure 5 As shown. Figure 6 , Figure 7 This paper compares the cache hit rate and request success rate of the caching method ICFC proposed in this example with those of ICTS proposed by Chen et al. and DANTE proposed by Amadeo et al. under different simulation time periods.

[0155] Figure 6This indicates the change in cache hit rate for each caching scheme over different time periods. At the start of the simulation, due to insufficient request and response communication, the caching schemes haven't fully utilized their filtering capabilities. Therefore, the cache space is not yet fully utilized, or there is significant redundancy of identical cached content, resulting in a low cache hit rate. As the cache time increases, the cache hit rate of all three schemes increases. The increased cache time allows each caching scheme to perform more effectively, meaning more reasonable data packets can be cached on different nodes, better utilizing the limited cache space between vehicle nodes. DANTE is not significantly different from the other two schemes at the beginning of the simulation, but as the simulation time increases, DANTE reaches its maximum effectiveness first, widening the gap with the other two schemes. Because DANTE does not differentiate based on data packet type but makes a uniform judgment, the same popular data packets are easily cached by multiple adjacent vehicles, resulting in significant cache redundancy and the lowest cache hit rate. ICTS considers three types of data packets and sets corresponding caching strategies, which differentiates data caching at the data type level, reducing cache redundancy to some extent. Therefore, its caching diversity increases, and the hit rate also increases. Its performance is significantly improved compared to DANTE. The ICFC proposed in this invention strengthens collaborative caching between vehicles based on the vehicle cluster structure. While classifying and focusing on caching of data packets, it avoids cache duplication between adjacent vehicles within the same cluster for the same data packets, further improving caching diversity. It can allocate a portion of the overall node's cache space to other content while ensuring the response of popular content. Therefore, ICFC has a significantly higher performance ceiling and startup speed compared to DANTE and ICTS, making it the best performer.

[0156] Figure 7This indicates the change in request success rate for each scheme over different time periods. At the start of the simulation, the vehicle's cache space was not fully filtered and cached by various caching schemes, resulting in a concentrated distribution of the same cached content. This caused some content requests to lack the required content within the communication hop range, leading to a low request hit rate. As the simulation time increased, the cached content underwent thorough filtering and replacement, increasing diversity and raising the request success rate. DANTE, due to its lack of packet classification, suffers from insufficient caching rationality for data content with different validity periods and scopes, resulting in significant cache redundancy for popular content and a concentrated content structure. Requests for less popular content are not responded to promptly, thus its upper limit is somewhat lower than the other two schemes. The ICTS scheme considers the spatiotemporal characteristics of different types of data content, providing a degree of targeting for different types of vehicle content requests. Its caching diversity is improved compared to DANTE, allowing for more timely responses to request changes, resulting in a higher upper limit for its request success rate compared to DANTE. The most significant feature of the proposed ICFC scheme is its coordinated allocation of cache space resources within the communication range. This scheme prioritizes caching different types of data for vehicle nodes with varying motion characteristics, thereby improving the effectiveness of different data types and increasing the success rate of request responses. For example, vehicle nodes with prominent motion characteristics and unstable behavior can prioritize caching entertainment messages with long validity periods and wide reach, thus expanding the dissemination of entertainment messages. Furthermore, by matching content to vehicles within the cluster's communicable range, the cache space can be allocated to different types of data packets to a significant extent, greatly increasing the diversity of content within the cluster's communicable range and consequently significantly improving the request response success rate. Therefore, the scheme proposed in this invention has a higher upper limit on request success rate compared to the other two schemes.

[0157] In summary, compared with the prior art, the present invention has at least the following advantages and beneficial effects:

[0158] 1. This invention proposes a method for vehicle clustering and intra-cluster hierarchical classification based on a fuzzy inference system. Existing methods only divide a cluster into a cluster head and other cluster members, which fails to better utilize the vehicle's motion characteristics and network topological position. This method, through a well-designed fuzzy inference system, transforms the motion state and intra-cluster topological position of vehicle nodes into a more detailed three-level intra-cluster hierarchy. This further refines the comprehensive characteristics of vehicles within a cluster, improves the efficiency of inter-vehicle collaboration and communication, and allows the vehicles themselves to better increase the utility value of cached content.

[0159] 2. The vehicle naming data network data caching method disclosed in this invention can prioritize caching based on the different data types received and their respective cluster levels. Existing methods only consider caching from the perspective of data characteristics, which can lead to situations where vehicles cannot realize the value of a certain type of data, thus wasting cache space. In this method, vehicles preferentially select a certain type of data based on their own characteristics, so as to cache more data content suitable for their own characteristics when cache space is limited, thereby improving the practicality and utilization of cached content, reducing the transmission latency of latency-sensitive messages, and improving the transmission efficiency of non-latency-sensitive messages.

[0160] 3. This invention, based on data type differentiation, leverages the characteristics of cluster structure to achieve differentiated caching for different data content of the same type. Most existing methods stop at data type differentiation and cannot precisely differentiate caching down to the individual content data packet level, potentially leading to multiple cachings of the same content within the vehicle's communication range. This method achieves caching gain by matching content data packets with vehicles within the cluster. This method can significantly avoid multiple cachings of the same content within the cluster, improve data diversity within the cluster's communication range, reduce cache redundancy, and increase cache space utilization and data request success rate.

[0161] 4. This invention incorporates a correction factor to feed back objective changes in the proportion of interest package requests into the cache score. The addition of the correction factor allows the base cache score to better reflect dynamic changes in interest package requests. Combining the base cache score derived from the analytic hierarchy process (AHP) with the objective correction factor balances the method's startup speed and subsequent rationality, thereby improving cache utilization and cache hit rate.

[0162] This embodiment also provides a data caching device for a vehicle naming data network, including:

[0163] At least one processor;

[0164] At least one memory for storing at least one program;

[0165] When the at least one program is executed by the at least one processor, the at least one processor implements Figure 1 The method shown.

[0166] This embodiment of a data caching device for a vehicle naming data network can execute a data caching method for a vehicle naming data network provided in the method embodiment of the present invention. It can execute any combination of implementation steps of the method embodiment and has the corresponding functions and beneficial effects of the method.

[0167] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is altered and sub-operations described as part of a larger operation are executed independently.

[0168] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0169] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0170] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0171] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0172] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0173] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0174] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0175] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A data caching method for a vehicle naming data network, characterized in that, Includes the following steps: S1. Factors influencing data exchange in the network for vehicle nodes, and factors influencing their one-hop neighbors. S2. Based on the one-hop neighbor information table and the node's own attributes, the vehicle node uses the fuzzy inference system to obtain a fuzzy output value. S3. Based on the obtained fuzzy output value, the current vehicle node determines the priority of the node to which it belongs and broadcasts its own fuzzy output value. S4. Based on the received fuzzy output values, the vehicle nodes select the node with the highest output value as the cluster head and send a cluster entry application to it to form a cluster structure. S5. The cluster head node collects various types of data within the cluster, packages the collected data, and broadcasts it. S6. Based on popularity information and their own location, nodes within the cluster execute corresponding caching strategies for various types of data. The one-hop neighbor information table is obtained by establishing it in the following way: Each neighbor node stores the following information: vehicle ID, vehicle location, vehicle speed, and historical contact history. Discretizing time, the degree of contact with history CT The calculation formula is: In the formula, T For the current time, For discretized historical time, ε For attenuation parameters; Nodes establish a one-hop neighbor information table by collecting basic security messages broadcast by other nodes within their transmission range; The node's own attributes include content responsiveness. RS The content responsiveness RS The calculation formula is: In the formula, N req and N rec These represent the number of interest packets received and the number of response packets, respectively.

2. The data caching method for a vehicle naming data network according to claim 1, characterized in that, The factors influencing the data exchange include the vehicle node receiving a request for interest message, and the factors influencing the surrounding one-hop neighbors include security messages sent by one-hop neighbors. The interest request messages received by vehicle nodes are divided into three categories according to their application scope and latency requirements: entertainment message interest request packets, traffic management message interest request packets, and traffic emergency message interest request packets. The security message received by the vehicle node from its one-hop neighbor includes: vehicle ID, vehicle location, and vehicle speed.

3. The data caching method for a vehicle naming data network according to claim 1, characterized in that, The one-hop neighbor information table includes the neighbor's speed, location, and historical contact degree, and the node's own attributes include betweenness centrality, degree centrality, and content responsiveness; The fuzzy inference system adopts the Mamdani fuzzy inference system. The input membership function of the system is the Gaussian input membership function, and the output membership function is the triangular membership function. The vehicle node uses a fuzzy inference system to obtain a fuzzy output value, including: Based on the fuzzy inference system, the final output value is obtained by using the centroid method, and is used as the fuzzy output value.

4. The data caching method for a vehicle naming data network according to claim 1, characterized in that, Step S5 includes: The cluster head node performs statistics on the data collected within a preset time Δt to obtain statistical messages. The statistical messages include: the number of nodes in the cluster, the proportion of each of the three types of request interest packets in the total number of request interest packets, and the IDs of the three interest packets with the highest request frequency for each of the three types of request interest packets. The cluster head node encapsulates the statistical messages into packets and broadcasts them.

5. A data caching method for a vehicle naming data network according to claim 4, characterized in that, The three data types include entertainment messages, traffic management messages, and traffic emergency messages; cluster nodes have different base cache scores for the three different types of response data packets based on their own priorities. ; The three types of data characteristics are evaluated from four dimensions: storage size, effective time, scope of application, and latency requirements. Different priority nodes consider the importance of each dimension and the relative scores of the three types of data in these four dimensions as the basic parameters of the analytic hierarchy process.

6. A data caching method for a vehicle naming data network according to claim 1, characterized in that, node For the received data packets Cache rating The calculation is performed using the following formula: in, For cache gain parameters, As a correction factor, For the base score of caching, For the previous moment The historical rating of this data packet This is the score decay function.

7. A data caching method for a vehicle naming data network according to claim 4, characterized in that, Step S6 includes: After a vehicle node is matched with a data packet, it is necessary to consider whether there is a need for cache gain. That is, if the data packet popularity is insufficient, cache gain should not be considered due to the need for cache space and practicality. There are three cases for the three different types of data packets: Case 1: If the received data packet is a traffic emergency message, since this type of data has the characteristics of small space occupation, high latency requirements and high importance, the node allows it to have cache redundancy. Therefore, for this type of data packet, as long as the node corresponds to the data packet, cache gain is applied. Scenario 2: If the received data packet is a traffic management message, since this type of data is helpful for road driving and occupies relatively little space, the node allows it to have a certain degree of cache redundancy within the cluster. The node calculates the received data packet... The popularity value of a data packet is calculated by multiplying the highest similarity value by the frequency percentage of requests of that type among the top three most popular interest packets of the same type as those in the cluster head statistics. We can obtain: Scenario 3: If the received data packet is an entertainment message, due to the large space occupied and relatively low importance of this type of data, the node has strict requirements for cache redundancy for this type of data packet; calculate the popularity value of this data packet. We can obtain: in, For cache gain parameters, N This indicates the number of nodes within a cluster, representing the buffer gain a node provides when both packet and node matching and the packet popularity value are greater than a threshold are met.

8. A data caching method for a vehicle naming data network according to claim 7, characterized in that, The popularity value The following formula is used to calculate: in, m Indicates the length of the matching names between the two contents. and These represent the naming of two contents respectively. and Length, t This indicates that the transposition is half of the intended purpose. This indicates the frequency of requests of this type.

9. A data caching device for a vehicle naming data network, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method of any one of claims 1-8.

Images