Trusted node game-based vehicle-side cooperative task unloading method

Abstract

The invention discloses a vehicle-side cooperative task unloading method based on a trusted node game, which comprises the following steps: calculating the credibility of each node in a current observation period, and screening the trusted nodes with the credibility greater than a trust threshold as game objects, the nodes comprising a vehicle and an edge server; an initial task unloading strategy of a vehicle and an initial task forwarding strategy of an edge server are generated, the vehicle serves as a dominator, the edge server serves as a follower, an optimal task unloading strategy and an optimal task forwarding strategy are obtained through a Stackelberg game, and the optimal task unloading strategy and the optimal task forwarding strategy are executed. According to the method, task unloading is modeled as a two-stage game model, and credible vehicles and edge servers are screened out as game participants by analyzing behavior trends of nodes in a plurality of periods, so that delay and energy consumption can be effectively reduced.

Description

Technical Field

[0001] The present invention relates to the field of Internet of Vehicles, and in particular to a vehicle-side collaborative task offloading method based on trusted node game. Background Art

[0002] The Internet of Vehicles (IoV) utilizes technologies such as 5G, Cellular Vehicle-to-Everything (C-V2X), and Multi-Access Edge Computing (MEC) to build a distributed network architecture that collaborates with the vehicle, road, and cloud. This architecture enables real-time information exchange and collaborative decision-making between vehicles and infrastructure, pedestrians, and the network. However, with the explosive growth of sensors installed in vehicles, the average daily amount of data generated by a single vehicle has climbed to TB levels, covering multiple tasks such as environmental perception, path planning, and behavior prediction. Taking autonomous driving as an example, the computationally intensive tasks involved, such as 3D point cloud semantic segmentation and multi-sensor fusion positioning, require computations at the teraflop (TFLOPS) level per second. At the same time, delay-sensitive tasks such as collision warnings place extremely high demands on the system's real-time response capabilities. These pose severe challenges to the vehicle's local computing power and response speed.

[0003] Task offloading offers an opportunity to address these challenges by offloading tasks that are difficult for vehicles to handle to nearby roadside edge servers or the cloud, which have powerful resources. Compared to offloading tasks to the cloud, offloading tasks to edge servers deployed on or near roadside units (RSUs) is more feasible. This is because edge servers not only have computing power far exceeding that of vehicles, but also avoid the communication delays and overhead associated with transmitting data to the cloud.

[0004] Existing research has not considered the uneven MEC load caused by vehicle density. In the Internet of Vehicles, vehicle density is typically higher near main roads, while fewer vehicles are distributed on edge roads. Task offloading typically involves offloading vehicle tasks to the nearest edge server. As a result, servers in hot zones near main roads may be heavily loaded with tasks, while servers in cold zones on edge roads may be idle. This leads to uneven load on edge servers, resulting in task backlogs and inefficient processing. Previous approaches have typically offloaded overloaded MEC tasks to the cloud, but this in turn results in long-distance transmission delays and narrow communication sub-bandwidth.

[0005] Furthermore, existing research mostly employs a vehicle-side collaborative task computing model, with frequent collaborative interactions between vehicles or servers, but lacks an assessment of their collaboration and processing reliability. The reliability of task processing nodes in the Internet of Vehicles is crucial. For example, in autonomous driving, if decision-making is delegated to malicious nodes, it will seriously threaten driver safety. Regarding task offloading, if the offloading requesting nodes are fraudulent or selfish, they will preempt and consume server resources, leading to a backlog of offloaded tasks and a high execution failure rate. Offloading tasks to malicious server nodes, on the other hand, threatens privacy and data security. Furthermore, ensuring efficient task collaboration between vehicles and edge servers to avoid conflicts of interest and resource preemption is crucial. Summary of the Invention

[0006] The technical problem to be solved by the present invention is as follows: In response to the above-mentioned problems of the prior art, a vehicle-side collaborative task offloading method based on trusted node game is provided. Task offloading is modeled as a game model. By analyzing the behavioral trends of nodes in multiple cycles, trusted vehicles and edge servers are selected as game participants. The optimal task offloading strategy and the optimal task forwarding strategy are obtained through Stackelberg game, which can effectively reduce delays and energy consumption.

[0007] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0008] A vehicle-side collaborative task offloading method based on trusted node game includes the following steps:

[0009] Calculate the trustworthiness of each node in the current observation period, and select trusted nodes with a trustworthiness greater than a trust threshold as game objects. The nodes include vehicles and edge servers.

[0010] Generate the vehicle's initial task offloading strategy and the edge server's initial task forwarding strategy. Using the vehicle as the leader and the edge server as the follower, the optimal task offloading strategy and optimal task forwarding strategy are obtained through Stackelberg game. The task offloading strategy is specifically a strategy in which the vehicle selects a task to offload to a trusted edge server, and the task forwarding strategy is specifically a strategy in which the trusted edge server selects a task to forward to an idle trusted edge server.

[0011] Execute the optimal task offloading strategy and the optimal task forwarding strategy.

[0012] Furthermore, the calculation of the trustworthiness of each node during the current observation period includes:

[0013] Calculate the task trust and collaboration trust of the current node, and take the weighted sum of the task trust and collaboration trust of the current node to obtain the trust of the current node in the current observation period;

[0014] Determine the trust type of the current node in the current observation period based on the trust degree of the current node in the current observation period;

[0015] Obtain all trusted types of the current node up to the current observation period, calculate the corresponding trust influence values, and perform normalization processing to obtain the comprehensive trust value of the current node as the trust degree of the current node.

[0016] Furthermore, the calculation formula for the trust of the current node in the current observation period is as follows:

[0017]

[0018] in, is a collection of vehicles, is the set of edge servers, 0.5≤ω h <1,0<ω l ≤0.5, is the task trust of node i, and the formula is as follows:

[0019]

[0020] in, and They represent the success and failure results of node i on task j in the kth observation period, respectively. η1 and η2 are two adjustment parameters

[0021] is the collaborative trust of node i, and the formula is as follows:

[0022]

[0023] in, represents the feedback evaluation of node i provided by cooperative node j during the kth observation period, TR j is the trustworthiness of the cooperating node j itself.

[0024] Furthermore, when determining the trust type of the current node in the current observation period according to the trust degree of the current node in the current observation period, specifically, the trust degree Tru i (k) and the credible threshold c H and the untrustworthy threshold c L Compare, if 0≤Tru i (k)≤c L , then the current node is marked as untrustworthy during the current observation period; if c L <Tru i (k) <c H , then the current node is marked as uncertain in the current observation period; if c H ≤Trui (k)≤1, the current node is marked as trustworthy during the current observation period.

[0025] Furthermore, the formula for the comprehensive trust value of the current node is as follows:

[0026]

[0027] in, is the trust influence value of the current node when its credibility is low during the observation period, N I is the total number of observation period windows where the node is marked as having low credibility, is a time decay function, based on the first interaction time, is a low confidence window length; is the influence value when the credibility is uncertain, N U is the total number of observation windows in which nodes are marked as having uncertain credibility, is a window length of uncertain credibility; is the trust influence value when the credibility is high, N C is the total number of observation windows in which nodes are marked as having high credibility, is a time decay function, based on the most recent interaction time. is a high-confidence window length. Is a disturbance value. When a node participates in task processing during the current trust observation period, Otherwise, let A trust perturbation value of less than 0.05 is selected to prevent nodes from being in a wait-and-see state for a long time.

[0028] Furthermore, when generating the initial task offloading strategy of the vehicle and the initial task forwarding strategy of the edge server, the following steps are specifically included:

[0029] Get the current vehicle v i Tolerance delay, computing requirements and offload ratio of all tasks, sort all tasks in ascending order according to tolerance delay and computing requirements;

[0030] Traverse all tasks in ascending order. If the current vehicle v in the current task i If the first constraint is satisfied, the current task is set to be the current vehicle v i Local calculation, otherwise, determine the current vehicle v i The nearest trusted edge server MEC j Whether the second constraint is met;

[0031] If the current vehicle v i The nearest trusted edge server MECj If the second constraint is not met, the part outside the current task unloading ratio is set to be handled by the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j deal with;

[0032] If the current vehicle is closest to the trusted edge server MEC j Satisfy the second constraint and select the trusted edge server MEC j The closest trusted edge server MEC that meets load constraints x , set the current task unloading ratio outside the part by the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j Then through the edge server MEC j Forwarded to the edge server MEC x calculate.

[0033] Furthermore, the first constraint conditions include: the offloading decision is a binary variable; the computational load of the task assigned to the vehicle cannot exceed its available computing resources; the computational load of the task assigned to the edge server cannot exceed its available computing resources; the execution time of the task must be within its tolerable delay; and the processing time of the task on the edge server must be within the communication time.

[0034] The second constraint condition includes: the forwarding decision is a binary variable, the current edge server is overloaded, the task processing delay after the task is forwarded is lower than the current server processing delay, and the task computing amount assigned to the new edge server cannot exceed the maximum processing capacity of the new edge server.

[0035] Furthermore, when the vehicle is regarded as the leader and the edge server as the follower, the optimal task offloading strategy and task forwarding strategy are obtained through the Stackelberg game, specifically including:

[0036] Based on the optimal task forwarding strategy in the previous iteration and the vehicle's game utility function, solve the task offloading strategy when the vehicle's game utility function is maximized in this iteration;

[0037] Compare the game utility function values ​​of the task offloading strategy when the vehicle's game utility function is maximized in this iteration with the optimal task offloading strategy. If the game utility function value of the task offloading strategy when the vehicle's game utility function is maximized in this iteration is greater than the game utility function value of the optimal task offloading strategy, then update the optimal task offloading strategy to the task offloading strategy when the vehicle's game utility function is maximized in this iteration. Then, based on the optimal task offloading strategy and the game utility function of the edge server, solve the task forwarding strategy when the edge server's game utility function is maximized in this iteration as the optimal task forwarding strategy.

[0038] If the game utility function value of the task offloading strategy when the game utility function of the vehicle is maximized in this iteration is less than or equal to the game utility function value of the optimal task offloading strategy, or the maximum number of iterations is reached, then the optimal task offloading strategy and the corresponding optimal task forwarding strategy will be used as the final optimal task offloading strategy and optimal task forwarding strategy.

[0039] Furthermore, the game utility function formula of the vehicle is as follows:

[0040]

[0041]

[0042] in, Indicates vehicle v i For Task T k The task offloading decision, When task T k By vehicle v i Local computing, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j , Represents vehicle v i Processing task T k The number of CPU cycles required, Represents vehicle v i Available computing resources, Represents the edge server MEC j Processing task T k The number of CPU cycles required, Represents the edge server MEC j Available computing resources, Represents task T k Local processing delay, Represents task T k By vehicle vi and edge server MEC j Co-processing latency, Represents task T k The latency of collaborative processing by multiple edge servers, Represents task T k The maximum tolerable delay, Represents vehicle v i Communication time with the edge server, Represents task T k Local vehicle handling costs, Represents task T k Offload processing costs to edge servers.

[0043] Furthermore, the game utility function formula of the edge server is as follows:

[0044]

[0045] in, Represents the edge server MEC j For Task T k The task forwarding decision, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j deal with, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j After that, it passes through the edge server MEC j Forwarded to the trusted idle edge server MEC x deal with, Represents the edge server MEC j Processing task T k The number of CPU cycles required, Represents the edge server MEC j Available computing resources, Represents the edge server MEC x Processing task T k The number of CPU cycles required, Represents the edge server MEC x Available computing resources, Represents the edge server MEC j The delay in processing tasks, Represents the edge server MEC x The delay in processing tasks, Represents task T k The cost of collaborative processing by the vehicle and edge server, Represents task T k The cost of co-processing by edge servers.

[0046] Compared with the prior art, the advantages of the present invention are:

[0047] 1. The present invention screens trustworthy nodes by calculating the comprehensive trust value of each node, thereby avoiding resource seizure and extra consumption by malicious nodes.

[0048] 2. The present invention uses Stackelberg game to obtain the optimal task offloading strategy and the optimal task forwarding strategy for the screened trusted nodes. Specifically, the vehicle in the node is used as the leader, and the optimal task offloading decision is made in the first stage of the game to maximize its own utility, that is, minimize the system task offloading cost. In the second stage of the game, the edge server with excessive load acts as a follower, and formulates the optimal task forwarding strategy based on the vehicle's task offloading strategy to maximize its own utility, that is, to achieve load balancing. By alternately optimizing the benefit functions of the vehicle and the edge server, Nash equilibrium is finally achieved. Through the collaboration between the vehicle and the edge server, as well as between different edge servers, the computing load of the hot zone and cold zone nodes is balanced, and the queuing delay is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 Schematic diagram of the spatial geometric relationship between the edge server and the vehicle.

[0050] Figure 2 Schematic diagram of the steps of the method according to an embodiment of the present invention.

[0051] Figure 3 Schematic diagram of the framework of the method of an embodiment of the present invention.

[0052] Figure 4 Schematic diagram of the trust change trend between vehicles and edge server nodes, where Figure 4 (a) is the trust change trend between malicious vehicles and edge server nodes. Figure 4 (b) shows the trust change trend of ordinary vehicles and edge server nodes.

[0053] Figure 5 Schematic diagram of the recognition rate of vehicles and edge server nodes, where Figure 5 (a) is the identification rate change trend of malicious vehicles and edge server nodes. Figure 5 (b) shows the recognition rate change trend of ordinary vehicles and edge server nodes.

[0054] Figure 6 2 is a comparison chart of the recognition rates of the method according to the embodiment of the present invention and other methods.

[0055] Figure 7 This is a comparison of energy consumption between the method of the embodiment of the present invention and other methods, where Figure 7 (a) is the average energy consumption under different round numbers, Figure 7 (b) is the cumulative energy consumption under different round numbers, Figure 7 (c) Comparison of energy consumption under a specified number of rounds.

[0056] Figure 8 This is a delay comparison diagram of the method of the embodiment of the present invention and other methods, wherein Figure 8 (a) is the average delay under different round numbers, Figure 8 (b) is the cumulative delay under different round numbers, Figure 8 (c) shows the delay comparison under a specified number of rounds.

[0057] Figure 9 This is a comparison chart of the task benefits of the method according to the embodiment of the present invention and other methods, where Figure 9 (a) is the average return under different round numbers, Figure 9 (b) is the cumulative profit under different round numbers, Figure 9 (c) is the comparison of returns under a specified number of rounds.

[0058] Figure 10 This is a comparison chart of the task completion rates of the method according to the embodiment of the present invention and other methods, where Figure 10 (a) is the task completion rate under different round numbers, Figure 10 (b) Comparison of task completion rates under a specified number of rounds. DETAILED DESCRIPTION

[0059] The present invention will be further described below in conjunction with the accompanying drawings and specific preferred embodiments, but the scope of protection of the present invention is not limited thereby.

[0060] Before introducing the specific embodiments of the present invention, the main parameters are summarized in Table I, and other parameters will be explained where they appear.

[0061] Table I

[0062] Symbol definitions and descriptions of main technical parameters

[0063]

[0064] Example

[0065] Assume that M vehicles are randomly distributed in a geographical area, and N roadside units (RSUs) are deployed on both sides of the road. Each RSU is equipped with an edge server for local processing and analysis of traffic data. During the movement, the vehicle can communicate with the vehicles and RSU infrastructure within its communication range. Among them, V2V technology is used to exchange information between vehicles, such as DSRC / LTE-V; V2R technology is used to exchange information between vehicles and RSUs, such as WiMax / 4G LET / 5G and other wireless communication technologies. In addition, high-speed connection is achieved between RSUs through optical fiber wireless technology. In this embodiment, the set of M vehicles is represented as Denote the set of N edge servers as

[0066] Considering that vehicles are constantly moving, the network topology is dynamic. However, by dividing the time slots, the network can be considered quasi-static in each time slot. Therefore, the tasks can be successfully offloaded to the corresponding edge servers in each time slot. Assume that at a certain time slot t, vehicle v i The location is (x i ,y i ,z i ), edge server MEC j The position of (x j ,y j ,z j ), then the spatial distance between them can be expressed as:

[0067]

[0068] Only when the vehicle is at the RSU (i.e. the edge server MEC j ) within the coverage area, the two parties can establish a communication link. Assuming that the server MEC j and vehicle v i The spatial geometric relationship of Figure 1 As shown. Among them, the edge server MEC j The coverage radius is λ j , vehicle v i The angle between the edge server and the center point O of the ground coverage plane is α, assuming that the vehicle moves in a uniform straight line with a moving speed of h i , then the communication time between the vehicle and the edge server is It can be expressed as:

[0069]

[0070] where

[0071]

[0072] in, For vehicle v i On edge servers MEC j The total distance that can be traveled within the coverage area, is the distance traveled by the vehicle, r j is the radius of the plane circle O where the server covers the ground, and L is the distance between the vehicle and the center of the circle.

[0073] This embodiment adopts orthogonal frequency division multiple access wireless access. Assume that vehicle v i To upload task data to the edge server MEC j , the subchannel bandwidth allocated by the edge server to the vehicle is B, and the vehicle's transmission power is P i , the channel noise is σ 2 , the channel gain between the vehicle and the edge server is H i,j , the interference of other nodes is ∑ k≠i,j≠i P k H k,j Then, based on Shannon's formula, vehicle v i With edge server MEC j The data transmission rate between can be expressed as:

[0074]

[0075] Among them, the channel gain H i,j Related to the distance between the two, at a certain time slot t, vehicle v i With edge server MEC j The distance is d i,j (t), based on the free space path loss model, vehicle v i With edge server MEC j The channel gain between can be expressed as follows:

[0076]

[0077] Because vehicle density varies across each roadside unit's coverage area, a high concentration of vehicles near major roads can lead to overloaded edge servers in these areas. These areas are known as hot zones. Conversely, some edge areas may serve fewer vehicles, leaving servers frequently idle. These areas are known as cold zones. In this embodiment, we aim to maximize resource utilization through computational collaboration among multiple trusted MEC servers, thereby balancing the workload across different areas.

[0078] Due to the uneven distribution of vehicle density and the heterogeneity of edge server computing power, existing task offloading methods may result in overloaded servers in hot spots while other servers remain idle. Therefore, this implementation proposes a vehicle-to-edge collaborative task offloading method based on trusted node game theory, called the GTOTC method. This method offloads tasks that are difficult for local vehicles to handle to neighboring edge servers and allows overloaded edge servers to forward tasks to other idle servers. By integrating resources and coordinating computing across multiple edge servers, it reduces task queuing delays and improves task processing efficiency.

[0079] like Figure 2 and Figure 3 As shown, the method of this embodiment includes the following steps:

[0080] S1) Game Participant Filtering: Calculate the trustworthiness of each node during the current observation period and select trusted nodes with a trustworthiness greater than a trust threshold as game participants. In this embodiment, the nodes include vehicles and edge servers in a designated area.

[0081] S2) Game decision process: Generate the vehicle's initial task offloading strategy and the edge server's initial task forwarding strategy, take the vehicle as the leader and the edge server as the follower, and obtain the optimal task offloading strategy and the optimal task forwarding strategy through the Stackelberg game. The task offloading strategy of this embodiment is specifically a strategy for the vehicle to select tasks to offload to a trusted edge server, including the task combination selected by the vehicle to be offloaded to the trusted edge server. The task forwarding strategy is specifically a strategy for the trusted edge server to select received tasks to forward to an idle trusted edge server, including the task combination selected by the trusted edge server to be forwarded to the idle trusted edge server. Therefore, the initial task offloading strategy and the optimal task offloading strategy respectively include the initial task combination and the optimal task combination offloaded to the trusted edge server, and the initial task forwarding strategy and the optimal task forwarding strategy are respectively the initial task combination and the optimal task combination forwarded to the idle trusted edge server;

[0082] S3) Execute the optimal task offloading strategy and the optimal task forwarding strategy.

[0083] Through the above steps, the method of this embodiment first uses a trust mechanism to filter out malicious game players, ensuring the reliability of the game players, namely the task offloading nodes. It then iterates through a two-stage Stackelberg game to obtain the optimal task offloading decision between the trusted vehicle and the edge server. Finally, the current round of task processing is completed based on the task offloading decision. Each round updates the trust between the vehicle and edge server based on the task completion and collaboration status of the previous round, facilitating the search for more reliable collaborative nodes for the next task decision.

[0084] Each step is described in detail below in conjunction with the network model of this embodiment.

[0085] Considering that there may be task preemption and resource competition between vehicles and servers, which may lead to poor collaboration, the GTOTC method first evaluates and filters the game players in step S1, filtering out false and malicious players based on the trustworthiness of the vehicles and edge servers. This not only helps improve offloading security, but also further narrows the strategy space and reduces game complexity. When calculating the trustworthiness of each node in the current observation period, it specifically includes:

[0086] S11) calculating the task trust and collaboration trust of the current node, and performing weighted summation of the task trust and collaboration trust of the current node to obtain the trust of the current node in the current observation period;

[0087] S12) determining the trust type of the current node in the current observation period based on the trust degree of the current node in the current observation period;

[0088] S13) Obtain all trust types of the current node as of the current observation period, calculate the corresponding trust influence values, and perform normalization processing to obtain the comprehensive trust value of the current node as the trust degree of the current node.

[0089] In this embodiment, the vehicle and the edge server are regarded as game players and are also called evaluated nodes in the trust evaluation stage of step S1. In step S11, the trustworthiness of the node is evaluated from two aspects: one is the success rate of previous task processing, and the other is the collaboration evaluation provided by other nodes.

[0090] First, the trustworthiness of the node in previous task processing is evaluated. By dividing the trust observation period into multiple periods, the trust of the node is determined in each observation period. When a round of task processing is completed, new trust evidence is generated and the trust of the node is updated. Assume that in the kth observation period, the success and failure results of node i on task j are expressed as and At this point, the node's task trust can be expressed as:

[0091]

[0092] in, and The value is 0 or 1. If the task is successfully executed, If the task fails, η1 and η2 are two adjustment parameters. When the node has no historical task processing results, η1 = 1 and η2 = 2, which means that the probability of the node falling into the credible and uncredible intervals is equal.

[0093] At the same time, the reliability of the node in the offloading collaboration is evaluated based on the feedback provided by the cooperative node. However, this indirect evaluation method relies on the authenticity of the feedback provider and is vulnerable to collusion attacks and bad mouth attacks. Therefore, the influence of the feedback evaluation provided by the provider needs to be determined based on the credibility of the provider itself. Suppose that in the kth observation period, there are Z cooperative nodes providing feedback evaluations about node i, among which the feedback evaluation provided by cooperative node j is The trustworthiness of node j itself is TR j At this time, the cooperation trust of node i can be expressed as:

[0094]

[0095] Finally, the task trust and collaboration trust of the node are integrated, and the weight adjustment parameter ω is introduced to obtain its trust degree in the kth observation period as follows:

[0096]

[0097] in, is a collection of vehicles, is a collection of edge servers. When evaluating the trustworthiness of a vehicle, we will pay more attention to its task completion quality. Let 0.5≤ω h <1; For the edge server, it not only needs to cooperate with the vehicle, but also needs to forward to other idle servers. Therefore, it is given more cooperation trust weight, let 0<ω l ≤0.5, the specific value can be adjusted according to system requirements, this article takes ω by default h =0.7,ω l =0.3.

[0098] In addition, considering the dynamic and open nature of the Internet of Vehicles environment, vehicles and servers switch in and out frequently. When on-off attackers are mixed into the nodes, they will intermittently perform malicious behaviors, such as grabbing resources, abandoning tasks, etc. Therefore, node trust changes dynamically over time, and its credibility cannot be judged based solely on the behavior of a node in one cycle. Past behavioral tendencies should also be fully considered. Combined with the sociological principles in reality, nodes that perform continuous trustworthy behavior are often more reliable than nodes that perform untrustworthy or wavering behavior. Therefore, the trust model constructed in this embodiment also considers the following two points:

[0099] (1) The time decay characteristic of trust evidence, that is, different weights are assigned to trust evaluation results generated at different times, and the closer to the current evaluation result, the higher the weight;

[0100] (2) Determine the different impacts of node trustworthiness, untrustworthiness, and oscillating behaviors based on their persistence characteristics and proportions.

[0101] In step S12, the trust degree Tru of the node in the kth observation period is obtained according to formula (7). i After (k), the credible threshold c is introduced H and the untrustworthy threshold c L , divide it into trusted, untrusted and uncertain trust spaces, specifically the trust degree Tru of the current node in the kth observation period i (k) and the credible threshold c H and the untrustworthy threshold c L Compare, if 0≤Tru i (k)≤c L , then the current node is considered to have low trustworthiness and is marked as untrustworthy; if c L <Tru i (k) <c H , it is uncertain whether the current node is completely trustworthy and is marked as uncertain; finally, if c H ≤Tru i (k)≤1, indicating that the credibility of the current node is relatively high.

[0102] In step S13, this embodiment extracts the trust type of the node in the past multiple trust observation periods and comprehensively calculates the trust value. The specific calculation formula is as follows:

[0103]

[0104] in, is the trust influence value of the current node when its credibility is low during the observation period, N I is the total number of observation period windows where the node is marked as having low credibility, is a time decay function, based on the first interaction time, is a low confidence window length; is the influence value when the credibility is uncertain, N U is the total number of observation windows in which nodes are marked as having uncertain credibility, is a window length of uncertain credibility; is the trust influence value when the credibility is high, N C is the total number of observation windows in which nodes are marked as having high credibility, is a time decay function, based on the most recent interaction time. is a high-confidence window length. Is a disturbance value. When a node participates in task processing during the current trust observation period, Otherwise, let A trust perturbation value of less than 0.05 is selected to prevent nodes from being in a wait-and-see state for a long time.

[0105] Finally, according to the node comprehensive trust TR i Filter the game players. If the comprehensive trust of the node is lower than the trust threshold, that is, TR i <Tru θ , considering that the node may be a malicious node, remove it from the corresponding node set or . Meanwhile, if the node is a vehicle node, the tasks it generates are completed by it and cannot be offloaded to other nodes. If the node is an edge server node, it cannot participate in subsequent game transactions. Meanwhile, vehicles within its coverage area will change their default task offloading server to the nearest trusted edge server. If the node's credibility is above the threshold, it will be retained in the original set as a participant in subsequent game transactions, meaning it is a candidate node for task processing and offloading decisions.

[0106] The algorithm of step S1 can be represented by Algorithm 1. It is mainly divided into three stages. First, the trust of the node in the most recent observation period is calculated (lines 1-4), then the comprehensive trust value of multiple observation periods is calculated (lines 5-14), and finally, vehicles and edge servers with low trustworthiness are filtered out based on the comprehensive trust value (lines 15-18). Algorithm 1 mainly performs simple calculations and judgments. Assuming there are M vehicles and N edge servers, the complexity of Algorithm 1 is Lower complexity.

[0107]

[0108]

[0109] This embodiment uses a pre-game trust assessment to filter out some low-trust vehicles and edge servers. To minimize their impact on collaborative efficiency, tasks generated by these vehicles are completed locally. For tasks generated by other trusted vehicles, this embodiment uses a two-stage game in step S2 to determine offloading decisions. Using the filtered trusted vehicles and edge servers as players, the task offloading problem is transformed into a two-stage Stackelberg game between the vehicles and edge servers. The vehicles and edge servers autonomously optimize offloading and forwarding strategies to minimize the total cost of task offloading.

[0110] This embodiment adopts a partial task offloading mode, that is, assuming that the task input is bit-by-bit independent, a task can be divided into multiple submodules, each task or submodule can be completed by the vehicle or offloaded to the edge server. The task set is represented as For each task t k , whose attributes can be expressed as triples in Indicates the amount of input data for the task; Indicates the number of CPU cycles required for task processing, Where μ is the CPU computation density, i.e. the number of CPU cycles required to complete one bit of data; is the maximum tolerable delay of the task.

[0111] For vehicle v i A task t generated k , assuming it is offloaded to the edge server MEC j The ratio is If the edge server MEC j If the load is too heavy, it will be forwarded to the idle edge server MEC. x ,use Represents vehicle v i The uninstall decision, MEC j Therefore, it can be divided into the following situations:

[0112] if at this time The task will be calculated locally by the vehicle. This offloading method is called the local calculation model.

[0113] if and Task Part of it is calculated by the vehicle, Partial offloading to MEC j This offloading method is called the vehicle-edge joint computing model;

[0114] if and Task Part of it is calculated locally by the vehicle, Partially through MEC j Forward to MEC x This offloading method is called edge-edge joint computing model.

[0115] Considering the transmission delay caused by task forwarding and the complexity of offloading cooperation, this embodiment stipulates that a task can only be forwarded once by the edge server and the task cannot be further divided by the edge server. The models of the above three offloading methods are further introduced as follows.

[0116] (1) Local computing model:

[0117] Assume that task t k By vehicle v i Local processing, the CPU cycles required for task calculation are Vehicle iThe computing power is Task t k The queue time is It is related to the task queue scheduling algorithm. In this embodiment, both the vehicle and the server adopt the first-come-first-served scheduling principle. At this time, the local processing delay of the task can be expressed as:

[0118]

[0119] Drawing on the widely used energy consumption model E=κP 2 , where P is the vehicle computing power of a single CPU cycle, κ is the chip energy coefficient, and the local processing energy consumption of the task can be expressed as:

[0120]

[0121] Combining the delay and energy consumption, the local processing cost of the task can be obtained as

[0122]

[0123] Among them, ω d and ω e is the weighted factor of delay and energy consumption. Considering the limited battery of the local vehicle, we dynamically allocate task processing delay and energy consumption weights according to the remaining battery of the vehicle. When the device has sufficient battery, delay is the primary consideration; on the contrary, when the device has insufficient battery, reducing energy consumption is the priority. Assume is the current remaining power ratio of the vehicle, τ is the custom weighting coefficient, then: ω e =1-ω d .

[0124] (2) Vehicle-edge joint computing model:

[0125] Assuming that the task is processed by the vehicle and the edge server, the task delay includes the vehicle local computing delay, the queuing delay and the execution delay when the task is unloaded to the edge server. i The computing power is The CPU cycles required for task calculation are Unloading from vehicles to MEC j The task ratio is At this point, the local computation delay of the task can be expressed as:

[0126]

[0127] For the part that is offloaded to the edge server for processing, the transmission delay between the vehicle and the edge server, as well as the queuing and calculation delay of the task at the edge server should be considered. Considering that the task calculation result is much smaller than the input data volume, and the server downlink transmission rate is much higher than the vehicle uplink transmission rate, this embodiment ignores the task calculation result return time. At this time, the task is at the edge server MEC. j The processing delay can be expressed as:

[0128]

[0129] Among them, the first one is the data transmission delay, is the task data volume, Is the vehicle v i With MEC j The second is the edge computing delay. It is the edge server MEC j computing power.

[0130] At this time, the task latency is the maximum of the local computing latency and the MEC processing latency. Therefore, the latency of the task processed collaboratively by the vehicle and MEC is:

[0131]

[0132] Similarly, the energy consumption of the task calculated locally on the vehicle can be obtained as:

[0133]

[0134] For the part that is offloaded to the edge server for processing, it includes additional transmission energy consumption and computing energy consumption. At this time, the task is handled by the edge server MEC. j The energy consumption of the process can be expressed as:

[0135]

[0136] in, Is the vehicle v i With edge server MEC j The data transmission power per unit time between It is the computing power of edge server in a single CPU cycle.

[0137] At this time, the task energy consumption is the sum of the local computing energy consumption and the edge server processing energy consumption. Therefore, the energy consumption of the task processed by the vehicle and the edge server is:

[0138]

[0139] Considering the delay and energy consumption, the cost of the task being processed collaboratively by the vehicle and the edge server is:

[0140]

[0141] (3) Edge-edge joint computing model

[0142] Assuming edge server MEC j The computing density of tasks in the covered area is high. At this time, the edge server MEC j Further forward the task to other idle edge servers MEC x ,At this time, the processing delay of the task on the edge server can be expressed as:

[0143]

[0144] Among them, the first item is the vehicle v i With edge server MEC j The second is the data transmission delay between the edge server MEC j With MEC x The transmission delay is usually small due to the high-speed transmission between edge servers through optical fiber; the third is the task at the edge server MEC x The fourth term is the queuing delay. According to formula (12) and formula (19), the delay of the task being collaboratively processed by multiple MECs can be expressed as:

[0145]

[0146] Similarly, task processing energy consumption requires additional MEC j With MEC x The transmission energy consumption between them is x The energy consumption of the process is expressed as:

[0147]

[0148] According to formula (15) and formula (21), the energy consumption of the task processed collaboratively by multiple edge servers is:

[0149]

[0150] Finally, the cost of collaborative processing of tasks between edge servers can be obtained as:

[0151]

[0152] The goal of this embodiment is to minimize the weighted sum of task processing energy consumption and delay, that is, to minimize the task processing cost. k ,use represents its unloading decision at the vehicle, represents its forwarding decision at the edge server. Based on the above three task computing models, the target optimization function can be expressed as follows:

[0153]

[0154] The constraints are as follows:

[0155]

[0156] Among them, C1-C5 are the constraints of the optimization function. C1 requires that the offloading decision is a binary variable. C2 requires that the computational amount of the task assigned to the vehicle cannot exceed its available computing resources. C3 requires that the computational amount of the task assigned to the edge server cannot exceed its available computing resources. C4 requires that the execution time of the task must be within its tolerable delay. C5 requires that the processing time of the task on the edge server must be within its communication time to avoid cross-domain switching problems caused by vehicle movement.

[0157] Based on the competition and hierarchical relationship between vehicles and servers, step S2 of this embodiment models the game between them as a Stackelberg game model, which includes three parts: players, strategies, and utilities, and proposes a distributed iterative algorithm to update the game strategies of vehicles and edge servers.

[0158] The specific game model design of this implementation is as follows:

[0159]

[0160] Represents the set of game players, including the filtered trusted vehicles and edge servers Among them, the vehicle is the leader and the edge server is the follower.

[0161] Represents the game strategy space. As the leader, the vehicle is responsible for formulating the task offloading strategy. The edge server formulates the task forwarding strategy based on the vehicle offloading decision and its own load situation.

[0162] It represents the utility of the game players, i.e., the game benefits. For the vehicle, it hopes to develop a set of optimal task offloading strategies to minimize the total cost of task processing.

[0163] Assume that vehicle v i The task set is According to the optimization objective of formula (24), its utility function can be expressed as:

[0164]

[0165] The constraints are as follows:

[0166]

[0167] in, Represents vehicle v i For Task T k The task offloading decision, When task T k By vehicle v i Local computing, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j , and They correspond to the cost of local task computation and offloading to the edge server. in is the vehicle-edge joint computation cost, is the cost of edge-to-edge joint computation after the task is further forwarded. Their calculations are shown in formulas (11), (18) and (23). C1-C5 are constraints on decision variables, processing capacity and delay. Their specific meanings are consistent with those in formula (24), including the following constraints: the offloading decision is a binary variable; the computational load of the task assigned to the vehicle cannot exceed its available computing resources; the computational load of the task assigned to the edge server cannot exceed its available computing resources; the execution time of the task must be within its tolerable delay; the processing time of the task on the edge server must be within its communication time.

[0168] For vehicle v i A set of tasks generated It formulates corresponding uninstallation strategies To minimize the cost and forward the task according to the edge server's strategy To adjust its own unloading strategy. Therefore, by maximizing the vehicle utility function, the optimal task unloading strategy can be obtained Expressed as:

[0169]

[0170] For the edge server, a set of task offloading strategies for a given vehicle The edge server hopes to develop a set of optimal task forwarding strategies When the server is overloaded, it forwards tasks to idle servers to minimize task processing costs. Therefore, its utility function can be expressed as:

[0171]

[0172] The constraints are as follows:

[0173]

[0174] Among them, MEC j It is the edge server for initial unloading of vehicles, MEC x It is an idle server for forwarding. Represents the edge server MEC j For Task T k The task forwarding decision, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j deal with, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j After that, it passes through the edge server MEC j Forwarded to the trusted idle edge server MEC x Processing. C1-C4 are constraints, including the following constraints: including: forwarding decision is a binary variable, the current edge server is overloaded, and the task processing delay after task forwarding is lower than the current server processing delay, the task computing amount assigned to the new MEC edge server cannot exceed its maximum processing capacity, specifically, C1 requires that the forwarding decision is a binary variable, C2 and C3 are task forwarding trigger conditions, only when the server MEC j The load is too heavy, and the task processing delay after forwarding is lower than the current server processing delay before forwarding. C4 requires that the task computing amount assigned to the edge server cannot exceed its maximum processing capacity.

[0175] Similarly, by maximizing the game utility function of the edge server, the edge server MEC can be obtained j The optimal task forwarding strategy is expressed as:

[0176]

[0177] It should be noted that for formula (26) and formula (28), there are many methods for solving the optimization problem, including but not limited to differential method, backward induction method, forward induction method, etc. In this embodiment, the differential method is adopted, specifically, the derivative of the profit function with respect to the current strategy is taken, the derivative is set equal to 0 and the equation is solved, and the solution of the equation is obtained. When the solution obtained makes the second-order derivative of the corresponding profit function less than zero, the solution obtained is the optimal strategy of the current strategy.

[0178] In the task offloading of this embodiment, the vehicle acts as the game leader. The offloading strategy of each vehicle will affect the total cost of the entire system. Therefore, the competition between vehicles can be expressed as a non-cooperative game. That is, the model of the first stage game can be expressed as The benefit function is formula (25). However, not all non-cooperative games have solutions, so it is necessary to analyze whether the game has a Nash equilibrium.

[0179] Definition 1 (Nash equilibrium): For non-cooperative games If the strategies chosen by all players form a stable state, that is, no player can obtain higher benefits by unilaterally changing its own strategy, the model is said to have reached a Nash equilibrium. At this time, the following equation holds:

[0180]

[0181] in, Is player v i The game strategy, is its best gaming strategy, It's its benefit, Except for player v i Other players' strategies.

[0182] If a game is a potential game, then it has one or more Nash equilibria. That is, in a potential game, players can converge to a Nash equilibrium by adjusting their strategies a finite number of times.

[0183] Definition 2 (Potential Game): For a game If there exists a potential function ψ: And for all participants and strategy sets, formula (30) is satisfied, then this game is called a potential game:

[0184]

[0185] It can be seen that in the above potential game, except for v i If the strategies of other players remain unchanged, player v i A change in strategy in the potential function is equivalent to a change in its utility.

[0186] Next, it is proved that the game of this embodiment is a potential game, that is, it is proved that the game of this embodiment has a Nash equilibrium.

[0187] Define a potential function ψ: as follows:

[0188]

[0189] Based on the above potential function, change the vehicle v i The game strategy from arrive The value of the potential function changes as follows:

[0190]

[0191] Similarly, suppose the game strategy is changed from arrive The value of the potential function changes to

[0192] Therefore, according to Definition 2, the benefit function of the vehicle in this embodiment is a potential function, and the game between vehicles in the first stage is a potential game. The proof is complete.

[0193] This example uses a two-stage Stackelberg game. In the first stage, the game between vehicles directly affects the total offloading cost, while the forwarding decision made by the edge server in the second stage optimizes the decision made in the first stage. Therefore, proving that the game between vehicles in the first stage is a potential game also demonstrates that this example's game has a Nash equilibrium solution, meaning that the task offloading problem in this example can be solved with an optimized offloading decision.

[0194] Step S2 of this embodiment uses a distributed iterative algorithm to update the player's strategy and achieve a Nash equilibrium by alternately optimizing the benefit function. It includes the following steps:

[0195] First, determine the initial game strategy between the vehicle and the edge server. When generating the initial task offloading strategy for the vehicle and the initial task forwarding strategy for the edge server, specifically include:

[0196] Get the current vehicle v i Tolerance delay, computing requirements and offload ratio of all tasks, sort all tasks in ascending order according to tolerance delay and computing requirements;

[0197] Traverse all tasks in ascending order. If the current vehicle v in the current task i If the constraint condition of formula (25) is satisfied (this embodiment is called the first constraint condition for distinction), then the current task is set to be the current vehicle v i Local calculation, otherwise, determine the current vehicle v iThe nearest trusted edge server MEC j Whether the second constraint is met;

[0198] If the current vehicle v i The nearest trusted edge server MEC j If the constraint condition of formula (27) is not satisfied (this embodiment is called the second constraint condition for distinction), the part other than the current task unloading ratio is set to be handled by the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j deal with;

[0199] If the current vehicle is closest to the trusted edge server MEC j Satisfy the second constraint and select the trusted edge server MEC j The closest trusted edge server MEC that meets load constraints x , set the current task unloading ratio outside the part by the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j Then through the edge server MEC j Forwarded to the edge server MEC x calculate.

[0200] Then, based on the utility functions of the vehicle and edge server, the strategy is adjusted through multiple iterations to obtain the Nash equilibrium of the game. Specifically,

[0201] Based on the optimal task forwarding strategy in the previous iteration and the vehicle's game utility function, solve the task offloading strategy when the vehicle's game utility function is maximized in this iteration;

[0202] Compare the game utility function values ​​of the task offloading strategy when the vehicle's game utility function is maximized in this iteration with the optimal task offloading strategy. If the game utility function value of the task offloading strategy when the vehicle's game utility function is maximized in this iteration is greater than the game utility function value of the optimal task offloading strategy, then update the optimal task offloading strategy to the task offloading strategy when the vehicle's game utility function is maximized in this iteration. Then, based on the optimal task offloading strategy and the game utility function of the edge server, solve the task forwarding strategy when the edge server's game utility function is maximized in this iteration as the optimal task forwarding strategy.

[0203] If the game utility function value of the task offloading strategy when the game utility function of the vehicle is maximized in this iteration is less than or equal to the game utility function value of the optimal task offloading strategy, or the maximum number of iterations is reached, then the optimal task offloading strategy and the corresponding optimal task forwarding strategy will be used as the final optimal task offloading strategy and optimal task forwarding strategy.

[0204] For vehicle v i A set of tasks Uninstall ratio corresponding to tasks Assume that the vehicle unloading decision is The corresponding forwarding decision of the edge server is Among them S k Is the vehicle v i About Task t k Uninstall strategy, The edge server is based on the vehicle unloading strategy S k The tasks t k forwarding strategy.

[0205] This embodiment uses Algorithm 2 to generate the aforementioned player initial strategy. The specific process is as follows: First, sort the tasks in ascending order according to the delay tolerance and computing requirements, so that tasks with low tolerance and low energy consumption are first calculated locally (lines 1-2). Then, start traversing from the first task. If it can be calculated locally, that is, it satisfies the constraints C1-C5 of formula (25), let S k =0, (Lines 3-5). Otherwise, the task is partially offloaded to the edge server MEC to which it belongs. j Execute on, let S k =1. Then, determine the edge server MEC j Is the load too heavy? That is, satisfy the constraints C1-C4 of formula (27). If the load is not too heavy, the task is offloaded to the edge service MEC. j The device executes, at this time, Otherwise, the task is assigned to the distance edge server MEC j The closest server MEC that satisfies constraints C1-C4 x Calculate, let (Lines 6-14) Finally, the resources of the corresponding vehicle or edge server node are updated, the task allocation decision is added to the node game strategy set, and the next task allocation is carried out until the initial strategies of all tasks are determined (Lines 15-20).

[0206]

[0207] This embodiment implements the aforementioned multiple iteration adjustment strategy through Algorithm 3. To avoid the algorithm from not converging, a maximum number of iterations I is defined. MAX First, use Algorithm 2 to generate the initial strategy of the game players (lines 1-3). Then, for each vehicle player, take him as the game leader and update the unloading strategy by maximizing the vehicle benefit: If the vehicle benefit under this unloading strategy is increased compared to the original unloading strategy, then according to the updated unloading strategy and edge server utility function, the updated edge server forwarding strategy is and keep the best strategies of vehicles and edge servers in and This is convenient for comparison in the next iteration (lines 4-12). Repeat the above process until the updated unloading strategy does not lead to an increase in vehicle benefits, that is, a Nash equilibrium is reached. At this time, the optimal unloading strategy for the updated vehicle is The optimal forwarding strategy for edge servers is (Lines 13-18).

[0208]

[0209] Finally, the task is processed based on the offloading decision, and the vehicle and edge server are updated with task execution success and failure records, collaborative feedback evaluation, etc. Based on this information, the trust relationship is updated to facilitate the filtering and selection of participants during the next task offloading and game.

[0210] The effect of the method of this embodiment is verified by specific experiments below.

[0211] Consider a task offloading system consisting of 200 intelligent vehicles and 40 roadside units (ROUs), each equipped with an edge server. The vehicle distribution and trajectory data are from the real-world dataset T-Drive TaxiTrajectroies, and the RSU (MEC) server information is from the dataset "parking places of Beijing." They are all distributed within a 25-kilometer radius centered at the longitude and latitude of (116.41667, 39.91667).

[0212] Other experimental parameter settings are as follows:

[0213] (1) Among the 200 vehicles, 10% are malicious nodes that initiate resource grabbing behaviors at irregular intervals. The available computing resources of each vehicle are 1-2 GHz, the task processing rate is 1 GHz / s, the transmission power is 200 mW, and the computing power is 500 mW.

[0214] (2) Among the 40 MEC servers, 5% of them are malicious nodes, which will initiate task abandonment behavior from time to time. The available computing resources of each edge server are 3-5 GHz, the task processing rate is 2.6 GHz / s, the transmission power is 500 mW, and the computing power is 1000 mW.

[0215] (3) Ordinary vehicles generate 1-3 tasks per task generation cycle, while resource-grabbing malicious nodes generate 3-6 tasks. Each task requires 0.5-1GHz of CPU cycles, 0.5-1.5MB of data, a maximum tolerable delay of 0.5-2s, and a task payoff of 2-5 currency units. A task can be divided into a maximum of four modules, with task offloading ratios of 25%, 50%, 75%, and 100%.

[0216] (4) The subchannel bandwidth allocated to each vehicle by the edge server is 2 MHz, and the channel noise is -97 dBm. Furthermore, during the trust evaluation of a node, the trust information of the node in the last 10 cycles is always retained. Unless otherwise specified, the initial trust value is 0.5, and the threshold is 0.35. When adjusting the game strategy, the maximum number of iterations is set to 50.

[0217] The method of this embodiment is compared with the greedy method (LFGM), particle swarm optimization (NEPSO), genetic algorithm (MFGA), and game theory method (GEEC), and the results are as follows:

[0218] (1) Trust, that is, the degree of trustworthiness of the vehicle and the edge server.

[0219] Trust value is a metric that quantifies the trustworthiness of vehicles and edge server nodes. Values ​​closer to 1 indicate a more trustworthy node, while values ​​closer to 0 indicate a more likely malicious node. Therefore, a good trust assessment solution should be able to clearly distinguish between legitimate and malicious nodes.

[0220] Figure 4 (a) shows the trust trend of malicious vehicles and edge server nodes. As the number of network rounds increases, nodes complete more tasks and acquire more collaborative information, and are more likely to capture malicious behavior. As can be seen, under the GTOTC method in this example, the trust of malicious nodes decreases rapidly, approaching 0.1 upon convergence, while the trust of other methods is around 0.35 at the time of convergence. This is because we implement a high-intensity trust penalty for malicious and volatile behavior.

[0221] Figure 4(b) is the trust change trend of ordinary vehicles and edge server nodes. As the network runs, the trust of ordinary nodes continues to increase. Similarly, under the GTOTC method of this embodiment, the trust of ordinary nodes grows faster and is close to 0.92 when converging, while under other methods, the trust converges at around 0.8 and the node trust grows slower. This is because GTOTC rewards trustworthy behavior based on the trust window length and interaction time. Figure 4 (a) and Figure 4 (b) From the perspective of GTOTC, the distinction between normal and malicious nodes is more obvious, trust is updated faster, and it is more suitable for complex and dynamic scenarios of the Internet of Vehicles.

[0222] (2) Node identification rate, that is, the proportion of correctly identified normal / malicious nodes to the total normal / malicious nodes.

[0223] Figure 5 (a) is the recognition rate of malicious vehicles and edge server nodes. It can be seen that during the network cold start phase, the recognition rate of GTOCO is only about 35%, but as the network runs, the final recognition rate can reach about 95%; the recognition rate of the NEPSO method is significantly lower. Figure 5 (b) is the recognition rate of ordinary vehicles and edge server nodes, and the three methods are not much different. Figure 6 , we can draw the following conclusions: compared with the NEPSO method, GTOCO improves the accuracy of malicious node identification by 22.5% and the accuracy of ordinary node identification by 3.89%; compared with the MFGA method, it improves the accuracy of malicious node identification by 7.5% and the accuracy of ordinary node identification by 9.44%.

[0224] (3) Average energy consumption, that is, the average energy consumed by each task.

[0225] By running multiple rounds of task allocation independently, we can obtain Figure 7 The energy consumption is shown in Figure 2. As can be seen, because GTOTC, NEPSO, and MFGA all use trust mechanisms to filter malicious vehicles and MEC nodes, resource preemption and excessive consumption are avoided, resulting in significantly lower energy consumption than LFGM and GEEC. In addition to MFGA, GTOTC reduces energy consumption by 17.13%, 2.7%, and 15.48% compared to LFGM, NEPSO, and GEEC, respectively.

[0226] (4) Average delay, that is, the average processing delay of each task.

[0227] Figure 8This is a delay comparison of several solutions. It can be seen that the task delay under GTOTC is relatively small because the computing load of hot and cold zone nodes is balanced through MEC-MEC collaboration, reducing queuing delay. The next two heuristic methods are NEPSO and MFGA. LFGM has the largest delay. Figure 8 Comparison (c) shows that compared with the three methods, GTOTC reduces the average task processing delay by 45-140ms and improves the task processing timeliness by 6.02%-16.67%.

[0228] (5) Task revenue, which is the revenue generated by all successfully processed tasks.

[0229] Figure 9 =Task revenue. Because GTOTC uses a trust evaluation mechanism to filter out malicious nodes that generate false missions, it has a higher mission success rate and greater revenue. In contrast, NEPSO and MFGA discard missions generated by malicious vehicles, resulting in lower mission revenue. Overall, compared to LFGM, NEPSO, and MFGA, GTOTC improves mission revenue by 2.9%, 7.2%, and 9.96%, respectively.

[0230] (6) Task completion rate: The ratio of successfully executed tasks to the total number of tasks.

[0231] Since 10% malicious vehicles and 5% malicious MEC nodes were randomly set in the experiment, there may be false tasks and malicious nodes to grab resources and abandon tasks. Figure 10 As can be seen from the results, GTOTC in this example maintains a completion rate of approximately 86%. In contrast, NEPSO and MFGA discard tasks initiated by identified malicious nodes, which directly results in some tasks being accidentally damaged. Overall, GTOTC improves task completion by 2.57%-16.9% compared to the other methods, excluding GEEC.

[0232] In summary, the present invention proposes a vehicle-side collaborative task offloading method based on trusted node game. First, a trust mechanism is used to filter out malicious game players to ensure the reliability of the game players, namely the task offloading nodes. Then, a two-stage Stackelberg game is used to iteratively obtain the optimal task offloading decision between the trusted vehicle and the edge server. Finally, task processing is completed according to the task offloading decision, and the trust between the vehicle and the edge server is updated based on the task completion status and collaboration status. This method offloads tasks that are difficult for local vehicles to handle to neighboring edge servers, and allows overloaded edge servers to further forward tasks to other idle servers. Through resource fusion and computing collaboration among multiple edge servers, task queuing delays are reduced and task processing efficiency is improved.

[0233] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A vehicle-side collaborative task offloading method based on trusted node game, characterized in that: The following steps are involved: Calculate the trustworthiness of each node in the current observation period and select trusted nodes with a trustworthiness greater than a trust threshold as game objects. The nodes include vehicles and edge servers. Generate the vehicle's initial task offloading strategy and the edge server's initial task forwarding strategy. Using the vehicle as the leader and the edge server as the follower, the optimal task offloading strategy and optimal task forwarding strategy are obtained through Stackelberg game. The task offloading strategy is specifically a strategy in which the vehicle selects a task to offload to a trusted edge server, and the task forwarding strategy is specifically a strategy in which the trusted edge server selects a task to forward to an idle trusted edge server. Execute the optimal task offloading strategy and the optimal task forwarding strategy.

2. The vehicle-side collaborative task offloading method based on trusted node game according to claim 1 is characterized in that: When calculating the trust of each node in the current observation period, it specifically includes: Calculate the task trust and collaboration trust of the current node, and take the weighted sum of the task trust and collaboration trust of the current node to obtain the trust of the current node in the current observation period; Determine the trust type of the current node in the current observation period based on the trust degree of the current node in the current observation period; Obtain all trust type evidence of the current node up to the current observation period, calculate the corresponding trust influence value according to the trust type of each trust evidence, and obtain the comprehensive trust value of the current node after normalization as the trust degree of the current node.

3. The vehicle-side collaborative task offloading method based on trusted node game according to claim 2 is characterized in that: The calculation formula for the trust of the current node in the current observation period is as follows: in, is a collection of vehicles, is the set of edge servers, 0.5≤ω h <1,0<ω l ≤0.5, is the task trust of node i, and the formula is as follows: in, and They represent the success and failure results of node i on task j in the kth observation period, respectively. η1 and η2 are two adjustment parameters; is the collaborative trust of node i, and the formula is as follows: in, represents the feedback evaluation of node i provided by cooperative node j during the kth observation period, TR j is the trustworthiness of the cooperating node j itself, and Z is the number of nodes that provide feedback evaluation.

4. The vehicle-side collaborative task offloading method based on trusted node game according to claim 2 is characterized in that: The trust type of the current node is determined based on its trust in the current observation period. Specifically, the trust Tru i (k) and the credible threshold c H and the untrustworthy threshold c L Compare, if 0≤Tru i (k)≤c L , then the current node has low credibility in the current observation period; if c L <Tru i (k) <c H , then the credibility of the current node in the current observation period is difficult to determine; if c H ≤Tru i If (k)≤1, the current node has high credibility in the current observation period. Then, the comprehensive trust value of the current node is calculated by combining the credibility types of the current node in the previous observation period and the current observation period, taking into account the time decay and type distribution characteristics: in, is the influence value of the current node when its credibility is low during the observation period, is the influence value of the current node when its credibility is uncertain, It is the influence value of the current node when the credibility is high. Their calculation is related to the decay time, credibility type, external reward and penalty factor.

5. The vehicle-side collaborative task offloading method based on trusted node game according to claim 1 is characterized in that: When generating the vehicle's initial task offloading strategy and the edge server's initial task forwarding strategy, the following are specifically included: Get the current vehicle v i Tolerance delay, computing requirements and offload ratio of all tasks, sort all tasks in ascending order according to tolerance delay and computing requirements; Traverse all tasks in ascending order. If the current task is assigned to vehicle v i If the first constraint is satisfied, the current task is set to be the current vehicle v i Local calculation, otherwise, determine the current vehicle v i Nearest trusted edge server MEC j Whether the second constraint is met; If the current vehicle v i The nearest trusted edge server MEC j If the second constraint is not met, the part outside the current task unloading ratio is set to be handled by the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j deal with; If the current vehicle is closest to the trusted edge server MEC j Satisfy the second constraint and select the trusted edge server MEC j The closest trusted edge server MEC that meets load constraints x , set the current task unloading ratio outside the current vehicle v i Local calculation, and the part within the current task offloading ratio is calculated by the current vehicle v i Offload to the nearest trusted edge server MEC j Then through the edge server MEC j Forwarded to the edge server MEC x calculate.

6. The vehicle-side collaborative task offloading method based on trusted node game according to claim 5 is characterized in that: The first constraint conditions include: the offloading decision is a binary variable; the computational load of the task assigned to the vehicle cannot exceed its available computing resources; the computational load of the task assigned to the edge server cannot exceed its available computing resources; the execution time of the task must be within its tolerable delay; and the processing time of the task on the edge server must be within its communication time. The second constraint condition includes: the forwarding decision is a binary variable, the current edge server is overloaded, the task processing delay after the task is forwarded is lower than the current server processing delay, and the task computing amount assigned to the new edge server cannot exceed the maximum processing capacity of the new edge server.

7. The vehicle-side collaborative task offloading method based on trusted node game according to claim 1 is characterized in that: Taking the vehicle as the leader and the edge server as the follower, the optimal task offloading strategy and task forwarding strategy are obtained through the Stackelberg game, specifically including: Based on the optimal task forwarding strategy in the previous iteration and the vehicle's game utility function, solve the task offloading strategy when the vehicle's game utility function is maximized in this iteration; Compare the game utility function values ​​of the task offloading strategy when the vehicle's game utility function is maximized in this iteration with the optimal task offloading strategy. If the game utility function value of the task offloading strategy when the vehicle's game utility function is maximized in this iteration is greater than the game utility function value of the optimal task offloading strategy, then update the optimal task offloading strategy to the task offloading strategy when the vehicle's game utility function is maximized in this iteration. Then, based on the optimal task offloading strategy and the game utility function of the edge server, solve the task forwarding strategy when the edge server's game utility function is maximized in this iteration as the optimal task forwarding strategy. If the game utility function value of the task offloading strategy when the game utility function of the vehicle is maximized in this iteration is less than or equal to the game utility function value of the optimal task offloading strategy, or the maximum number of iterations is reached, then the optimal task offloading strategy and the corresponding optimal task forwarding strategy will be used as the final optimal task offloading strategy and optimal task forwarding strategy.

8. The vehicle-side collaborative task offloading method based on trusted node game according to claim 7 is characterized in that: The game utility function formula of the vehicle is as follows: in, Indicates vehicle v i For Task T k The task offloading decision, When task T k By vehicle v i Local computing, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j , Indicates vehicle v i Processing task T k The number of CPU cycles required, Indicates vehicle v i Available computing resources, Represents the edge server MEC j Processing task T k The number of CPU cycles required, Represents the edge server MEC j Available computing resources, Represents task T k Local processing delay, Represents task T k By vehicle v i and edge server MEC j Co-processing latency, Represents task T k The latency of collaborative processing by multiple edge servers, Represents task T k The maximum tolerable delay, Indicates vehicle v i Communication time with the edge server, Represents task T k Local vehicle handling costs, Represents task T k Offload processing costs to edge servers.

9. The vehicle-side collaborative task offloading method based on trusted node game according to claim 7 is characterized in that: The game utility function formula of the edge server is as follows: in, Represents the edge server MEC j For Task T k The task forwarding decision, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j deal with, When task T k The part other than the task offloading ratio is determined by vehicle v i The part of local calculation within the task offloading ratio is handled by the vehicle v i Offload to trusted edge server MEC j After that, it passes through the edge server MEC j Forwarded to the trusted idle edge server MEC x deal with, Represents the edge server MEC j Processing task T k The number of CPU cycles required, Represents the edge server MEC j Available computing resources, Represents the edge server MEC x Processing task T k The number of CPU cycles required, Represents the edge server MEC x Available computing resources, Represents the edge server MEC j The delay in processing tasks, Represents the edge server MEC x The delay in processing tasks, Represents task T k By vehicle and edge server MEC j The cost of co-processing, Represents task T k By edge server MEC j and MEC x The cost of co-processing.

Images