Internet of vehicles computing power network resource allocation method and device, electronic equipment and storage medium

Abstract

This application provides a method for allocating computing power network resources in a vehicle-to-everything (V2X) network, applicable to V2X computing power networks including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units. The method includes: determining candidate execution nodes based on the network state of the V2X computing power network; filtering candidate execution nodes based on the compatibility between the tasks to be assigned and the candidate execution nodes to obtain a candidate execution set; determining the execution decision result using a pre-set reinforcement learning model and the candidate execution set; and assigning the tasks to be assigned to the corresponding candidate execution nodes based on the execution decision result. This achieves accurate allocation of V2X computing power network resources and avoids waste of computing power resources.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a method, apparatus, electronic device and storage medium for allocating computing power network resources in vehicle networking. Background Technology

[0002] In intelligent vehicle-to-everything (V2X) systems, vehicles continuously generate various computing tasks, including autonomous driving control, collaborative perception, fusion reasoning, and path planning. These tasks typically require low latency, high reliability, and high dynamism.

[0003] Existing methods for vehicular edge computing and vehicle-to-everything (V2X) resource allocation typically focus on local execution, vehicle-to-vehicle offloading, and vehicle-to-roadside unit offloading modes, and reduce task completion latency by optimizing offloading decisions, bandwidth allocation, and computing resource allocation. However, they still suffer from insufficient consideration of vehicle mobility and link dynamics, and low adaptability between computing power and task allocation. Summary of the Invention

[0004] In view of this, the purpose of this application is to propose a method, device, electronic device and storage medium for allocating computing power network resources in the Internet of Vehicles.

[0005] To achieve the above objectives, this application provides a method for allocating computing power network resources in a vehicle-to-everything (V2X) network, applicable to a V2X computing power network including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units. The method includes: determining candidate execution nodes based on the network state of the V2X computing power network; filtering the candidate execution nodes based on the compatibility relationship between the task to be assigned and the candidate execution nodes to obtain a candidate execution set; determining an execution decision result using a preset reinforcement learning model and the candidate execution set; and allocating the task to be assigned to the corresponding candidate execution node based on the execution decision result.

[0006] As can be seen from the above, the vehicle-to-everything (V2X) computing power network resource allocation method provided in this application determines the connection status of the V2X link by identifying candidate execution nodes based on the V2X computing power network status, thus avoiding connection interruptions and preventing task transmission failures due to short V2V link contact time when vehicles are moving at high speeds. Furthermore, by determining the compatibility between the task to be allocated and the candidate execution nodes, the task to be allocated is assigned to a candidate execution node with a high degree of matching, improving task execution efficiency while avoiding waste of computing resources. Finally, the execution decision result is determined through a reinforcement learning model, and the task to be allocated is then allocated based on the execution decision result, thereby enabling stable allocation of network resources for the V2X computing power network. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a schematic diagram illustrating an application scenario of the vehicle-to-everything (V2X) computing power network resource allocation method provided in the embodiments of this application.

[0009] Figure 2 This is a flowchart illustrating the vehicle network computing power resource allocation method provided in an embodiment of this application. Figure 3 A schematic diagram of the algorithm structure of the vehicle network computing power network resource allocation method provided in the embodiments of this application; Figure 4 This is a schematic diagram illustrating the convergence analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the average task completion latency analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in this application embodiment. Figure 6 This diagram illustrates the on-time completion rate analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in this embodiment of the application. Figure 7 This is a schematic diagram illustrating the matching resource utilization analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in this embodiment of the application. Figure 8 This is a schematic diagram illustrating the invalid unloading ratio analysis results of the vehicle network computing power network resource allocation method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the ablation experiment analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in the embodiments of this application. Figure 10 This diagram illustrates the performance analysis results of different task types for the vehicle network computing power and network resource allocation method provided in the embodiments of this application. Figure 11 This diagram illustrates the scalability and decision complexity analysis results of the vehicle-to-everything (V2X) computing power network resource allocation method provided in the embodiments of this application. Figure 12 This is a schematic diagram of the structure of the vehicle network computing power network resource allocation device provided in the embodiments of this application; Figure 13 This is a schematic diagram of a more specific electronic device hardware structure provided in an embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0011] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0012] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0013] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0014] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0015] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0016] As sixth-generation mobile communication networks evolve towards a deep integration of communication, computing, and intelligence, computing power networks are gradually becoming an important network form supporting distributed intelligent services. Computing power networks can uniformly perceive, publish, schedule, and orchestrate computing, storage, and communication resources at the cloud, edge, and terminal levels, enabling tasks to be dynamically allocated to appropriate execution nodes based on network and resource status.

[0017] Vehicle-to-everything (V2X) communication is a key application scenario for computing networks. In intelligent V2X, vehicles continuously generate various computing tasks, including autonomous driving control, collaborative perception, fusion reasoning, and path planning. These tasks typically require low latency, high reliability, and high dynamism. Due to the high-speed movement of vehicle nodes, the communication links between vehicles and between vehicles and roadside units change rapidly over time. Link reachability, contact duration, channel quality, and node load all affect task offloading and resource allocation results.

[0018] Existing methods for vehicular edge computing and vehicle-to-everything (V2X) resource allocation typically focus on local execution, vehicle-to-vehicle offloading, and vehicle-to-roadside unit offloading, and reduce task completion latency by optimizing offloading decisions, bandwidth allocation, and computing resource allocation. However, existing methods still have the following shortcomings.

[0019] First, most existing methods abstract node computing power into a uniform scalar computing power, such as total computing frequency, total computing speed, or allocable computing resource share. This modeling approach struggles to characterize the differentiated adaptation relationships between different types of tasks and different types of processors. In real-world heterogeneous computing environments, control tasks, perception tasks, and fusion inference tasks differ significantly in terms of computational architecture, parallelism requirements, and hardware acceleration dependencies; heterogeneous processors such as CPUs, GPUs, and NPUs also possess different execution advantages. Scheduling based solely on total computing power may result in tasks being allocated to under-suited resources, leading to decreased computational efficiency, resource imbalance, and task timeouts.

[0020] Second, existing methods do not adequately consider vehicle mobility and link dynamics. High-speed vehicle movement results in limited V2V (vehicle-to-vehicle) link contact time. Even if a neighboring vehicle node is close or has a good channel at the current moment, it may not be able to maintain a valid connection during task transmission and execution. If the offloading node is selected based solely on instantaneous distance, instantaneous channel state, or remaining node resources, it is easy to produce invalid offloading behavior that is theoretically feasible but fails in actual transmission.

[0021] Third, the task scheduling problem in the vehicle-to-everything (V2X) computing power network simultaneously involves discrete execution decision-making and continuous resource control. Execution mode selection and candidate node selection are discrete decisions, while bandwidth allocation and heterogeneous computing power resource allocation are continuous control. If a single-layer reinforcement learning or a single heuristic strategy is used to process the above-mentioned mixed action space, it can easily lead to an excessively large action space dimension, low exploration efficiency, unstable training, and high online decision latency.

[0022] Therefore, it is necessary to propose a joint resource optimization method for vehicle-to-everything (V2X) computing power networks that can simultaneously consider communication feasibility, vehicle contact continuity, task type differences, heterogeneous resource adaptation relationships, and hybrid discrete-continuous decision-making characteristics.

[0023] refer to Figure 1 This diagram illustrates an application scenario of the vehicle-to-everything (V2X) computing power network resource allocation method provided in this application embodiment. The application scenario includes a source vehicle, a local execution node, neighboring vehicle cooperative nodes, a roadside unit (RSU), a local execution link, a V2V offload link, and a V2I (vehicle-to-roadside unit) offload link. The source vehicle, local execution node, neighboring vehicle cooperative node, roadside unit, local execution link, V2V offload link, and V2I offload link can all be connected via wired or wireless communication networks. The computing power of the roadside unit (RSU) and the vehicle's local node is provided by computing chips such as CPUs, GPUs, and NPUs. In the specific task processing, the tasks include control tasks, perception tasks, and parallel computing tasks, such as vehicle control during driving, perception of the external environment by various vehicle sensors (such as cameras, LiDAR, millimeter-wave radar, etc.), and model calculations. Figure 1 As shown in the matching matrix, control tasks are highly compatible with CPU computing power, perception tasks are highly compatible with GPU computing power, and parallel computing tasks are highly compatible with both GPU and NPU. When these tasks run on highly compatible computing resources, the computing resources can complete the adapted tasks quickly. However, if these tasks run on poorly compatible computing resources, it will lead to a large amount of computing resources being allocated to execute simple tasks, and may even cause the tasks to fail to complete in a timely manner.

[0024] The following is combined Figure 1 The application scenarios described above illustrate the vehicle-to-everything (V2X) computing power network resource allocation method according to exemplary embodiments of this application. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this regard. Rather, the embodiments of this application can be applied to any applicable scenario.

[0025] like Figure 2As shown, this application provides a method for allocating computing power network resources in a vehicle-to-everything (V2X) network, applicable to a V2X computing power network including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units. The method includes: Step S1: Determine candidate execution nodes based on the network status of the vehicle-to-everything (V2X) computing power network.

[0026] In this embodiment, as Figure 1 As shown, the vehicle-to-everything (V2X) computing network consists of vehicle nodes, neighboring vehicle cooperative nodes, and a Roadside Unit (RSU), supporting three task processing modes: local execution, V2V offloading, and V2I offloading.

[0027] By determining candidate execution nodes based on the network status of the vehicle network computing power, the connection status of the vehicle network link can be determined, thus avoiding connection interruption and preventing task transmission failure due to insufficient contact time of the V2V link when the vehicle is moving at high speed.

[0028] Step S2: Based on the compatibility between the task to be assigned and the candidate execution nodes, the candidate execution nodes are filtered to obtain a candidate execution set.

[0029] In this embodiment, by determining the compatibility between the task to be assigned and the candidate execution node, the task to be assigned is assigned to the candidate execution node with a high degree of matching, thereby improving the task execution efficiency and avoiding the waste of computing resources.

[0030] Step S3: Determine the execution decision result through a preset reinforcement learning model and a candidate execution set.

[0031] Step S4: Assign the tasks to be assigned to the corresponding candidate execution nodes based on the execution decision results.

[0032] In this embodiment, the execution decision result is determined by a reinforcement learning model, and then the task to be assigned is allocated according to the execution decision result, thereby enabling stable allocation of network resources of the vehicle network computing power network.

[0033] In some alternative embodiments, a set of discrete time slots is considered. In any time slot The set of vehicles within the RSU coverage area is denoted as ,in The unique RSU in the system is denoted as a node. Therefore, the set of locally executable nodes is: ; For the task The source vehicle is recorded as .Task The initial candidate execution set is defined as: ; in, Corresponding to the local execution node, Corresponding V2I offload node, This represents the set of neighboring vehicles that satisfy V2V communication constraints. If the vehicle... With vehicles The instantaneous distance satisfies: ; Then the vehicle Can be used as a task V2V candidate collaboration nodes, namely: ; The above modeling corresponds to three execution modes: local execution, V2V offloading, and V2I offloading, providing a candidate space for subsequent execution mode selection and joint resource allocation.

[0034] Within each time slot, let the set of tasks generated be denoted as . For any task Its task attributes are represented as follows: ; in, Indicates the amount of input data for the task. This indicates the computational load required for the task. This indicates the maximum tolerable completion delay for the task. This represents the task type index. This paper abstracts task types into control, perception, and fusion reasoning categories to characterize the differences in computing patterns, latency sensitivity, and resource preferences among different services.

[0035] Let the set of heterogeneous computing resource types be: ; Any execution node In the time slot Available computing power can be represented as a multidimensional heterogeneous computing power vector: ; in, Represents a node The currently available number Computing resource capabilities. This article focuses on... These correspond to CPU, GPU, and NPU, respectively. Unlike methods that represent node computing power as a single computing rate or total computing resource share, this representation can distinguish the differences in hardware capabilities and task execution efficiency among different processor types.

[0036] If task Assigned to a node Execution, then in the first The allocation ratio on the resource class is denoted as: ; The actual number obtained The amount of this type of resource is: ; This modeling enables the system not only to determine "where a task is executed," but also to further characterize how the task occupies different types of heterogeneous computing resources within the target node.

[0037] In some embodiments, step S2 specifically includes: Step S21: Determine the relative adaptation coefficient based on the task type of the task to be assigned and the original adaptation score of the execution node.

[0038] Step S22: Construct a matching matrix based on the relative fit coefficients.

[0039] Step S23: Determine the fitting relationship based on the matching matrix.

[0040] In this embodiment, the matching matrix is ​​a task-resource matching matrix, used to characterize the structural adaptation relationship between task types and heterogeneous processors, as shown in the following formula: ; in, Indicates the first Class of tasks in the first The relative execution gains on computing resources. It should be noted that... It is not an optimization variable solved online in this paper, nor does it represent an absolute speedup on a specific chip platform. Instead, it is a relatively suitable prior determined by public benchmark trends, hardware functional division, and task computation mode.

[0041] The original fit score is defined by the following formula: ; in It can be initialized using publicly available performance trends, historical operational statistics, or domain knowledge. Then, row normalization is applied to obtain: ; Therefore, for any task type ,have: ; when When, it indicates the first Class of resources for the first Tasks of this type have relatively higher execution adaptability; when If the value is low, it indicates that the resource has a relatively low return on this type of task.

[0042] Based on the task-resource matching matrix, if task Assigned to a node Then its matching-aware equivalent computation rate is defined as: ; This demonstrates that even when two nodes have the same total computing resources, different CPU / GPU / NPU configurations and different task-resource type adaptation coefficients will still result in different effective computing speeds. This is precisely the heterogeneous processor adaptation characteristic that is difficult to characterize using a unified scalar computing power model.

[0043] In some embodiments, step S2 further includes: Step S24: Calculate the affinity between the task to be assigned and the candidate execution node based on the preset link feasibility, vehicle-to-vehicle contact continuity, task-node resource matching degree, and node load friendliness.

[0044] In this embodiment, the affinity between nodes is used for lightweight filtering of candidate nodes. Specifically, for the task... With candidate nodes Affinity is defined as ; in, . Indicates link feasibility. Indicates the continuity of V2V contact. Indicates the degree of task-resource matching. This indicates the node's load-friendly rating.

[0045] The task-resource matching degree is represented by the following formula: ; in It is a very small positive number, used to avoid the denominator being zero.

[0046] Step S25: Compare the affinity with the preset screening threshold, retain the candidate nodes whose affinity meets the screening threshold, and obtain the candidate execution set.

[0047] In this embodiment, the candidate execution set is represented by the following formula: ; in The affinity screening threshold is used. This mechanism introduces an interpretable candidate compression process before joint optimization, enabling subsequent decisions to focus more on execution nodes that are communicatively feasible, have sustainable contact, better resource matching, and more reasonable load.

[0048] In some alternative implementations, there is communication latency caused by the communication phase and computation latency caused by the computation phase during the process from task assignment to execution completion.

[0049] Specifically, during communication, in local execution mode, the task does not require wireless transmission, and its communication latency is: ; For V2I uninstallation, task From the source vehicle Uploaded to RSU The transmission rate is: ; in, This indicates the proportion of bandwidth allocated to that link. For V2I total bandwidth, For transmission power, For channel gain, For noise power, This is a distractor.

[0050] For V2V uninstallation, task From the source vehicle Transmit to neighboring vehicle The rate is: ; in, For V2V total bandwidth, The bandwidth allocation ratio for the corresponding link. Channel gain can be expressed as: ; in, The channel gain at the reference distance. This is the path loss index. This is a small-scale fading term.

[0051] Therefore, the task Unload to node The communication delay is uniformly represented as: .

[0052] Regarding computation latency, during the computation phase, if the task... By node If executed, its computation delay is ; This embodiment focuses on execution mode selection and joint communication-computation allocation, therefore it does not explicitly model result return latency and independent queuing latency. The former is typically less than the task input data transmission latency, while the latter is implicitly represented by the node's current available resources and load status.

[0053] Define a binary execution variable When the task In the time slot Select node During execution, Otherwise, it is 0. (Task) The end-to-end completion delay is: ; Further define the task success indicator variable If the task is completed within the deadline, then ,otherwise Both conditions are met: ; in It is a sufficiently large constant.

[0054] In some alternative implementations, the resource allocation problem in the local computing power network of the vehicle network can be formulated as a joint optimization problem of execution mode selection, communication bandwidth allocation, and heterogeneous computing power allocation. For the task set... The average task completion latency and task success rate are defined as follows: ; ; node In the time slot The load rate is defined as: ; The system average load is: ; Load imbalance is defined as: ; Therefore, the joint optimization problem of this application can be written as: ; The constraints include: ; ; ; ; ; ; ; ; ; ; ; .

[0055] Where P_min represents the minimum on-time completion rate required by the system, Δ_max represents the maximum allowable load imbalance, and M is a sufficiently large constant. The first set of constraints states that each task can only be assigned to one execution node, and that node must belong to the filtered candidate execution set. The second set of constraints defines the value range of execution variables and task success indicator variables. The third set of constraints links task completion latency with task success status and further guarantees the minimum on-time completion rate at the system level. Heterogeneous resource capacity constraints ensure that the allocation amount of any node on any resource type does not exceed its available resource capacity. Bandwidth constraints limit the allocation ratio of the total system communication bandwidth to no more than 1. Resource allocation ratio constraints ensure that the heterogeneous computing power resource allocation result is within a feasible range. V2V contact time constraints ensure that V2V offloading is only allowed when the contact duration between vehicles can support task transmission. Load balancing constraints are used to avoid excessive concentration of tasks on a few nodes, thereby reducing the risk of local congestion and resource contention.

[0056] From a structural perspective, this optimization problem simultaneously includes discrete execution variables z_i,n(t) and continuous resource allocation variables β_i,n(t) and α_i,n,g(t). Furthermore, the task completion delay in the objective function involves nonlinear communication rates, task-resource adaptation and perception computation delays, and dynamic link states; therefore, this problem belongs to the category of mixed-integer nonlinear optimization. Traditional convex optimization methods struggle to obtain near-optimal solutions in real-time within dynamic vehicular network scenarios, which provides a basis for subsequently employing hierarchical reinforcement learning methods for solving the problem.

[0057] In some embodiments, this application requires simultaneous optimization of discrete execution decisions. Communication bandwidth allocation and the proportion of heterogeneous computing resource allocation This problem involves both discrete and continuous variables, and the objective function includes nonlinear communication rate, matching sensing computation delay, and dynamic load terms, making it a typical mixed-integer nonconvex dynamic optimization problem.

[0058] Therefore, this application proposes a hierarchical reinforcement learning method based on task-resource adaptation. For example... Figure 3As shown, the algorithm first constructs a set of candidate execution nodes based on communication feasibility and resource adaptability; then, the higher-level strategy makes a discrete selection among local execution, V2V offloading and V2I offloading; after determining the target node, the lower-level strategy outputs a continuous heterogeneous resource allocation ratio and generates bandwidth allocation results by combining the link latency urgency.

[0059] Specifically, the algorithm first outputs the environment state based on communication feasibility, communication duration, resource availability, and the task-resource adaptation matrix. This environment state is stored as samples in an experience replay buffer, and the agent generates allocation results based on these samples. The agent comprises a high-level policy network and a low-level policy network. The high-level policy network is used for execution mode selection, while the low-level policy network allocates resources by outputting multi-dimensional continuous actions. In some embodiments, the reinforcement learning model includes a high-level policy network.

[0060] Step S3 specifically includes: Step S31: Determine the execution mode of each task to be assigned in the candidate execution set based on the preset action mask and high-level policy network. The execution modes include local execution, V2V execution, and V2I execution.

[0061] Step S32: Determine the execution decision result based on all execution modes.

[0062] In this embodiment, the high-level policy network includes a high-level state space and a high-level action space.

[0063] Specifically, high-level states are used to characterize the global information needed for execution mode selection. For tasks... Define the high-level state as: ; in: Task attributes (data volume, computational load, deadline, task type); Link status (V2I reachability, V2V neighbor count, channel quality, contact duration); Candidate node resource status (available CPU / GPU / NPU resources on each node); Node load status; : Matching vector corresponding to the task type.

[0064] High-level actions are for selecting the execution mode: ; This action is further mapped to an execution node: ; The corresponding execution variables are: .

[0065] In some embodiments, step S3 further includes: Step S33: Determine the target node based on the execution mode.

[0066] In step S331, in response to the execution mode being local execution, the source vehicle is set as the target node.

[0067] In step S332, in response to the execution mode being V2I, the roadside unit is taken as the target node.

[0068] In step S333, in response to the execution mode being V2V, the node with the smallest estimated completion delay is selected as the target node from the filtered set of neighboring vehicles.

[0069] In this embodiment, as Figure 3 As shown, the high-level strategy is used for execution mode selection. For each task, the high-level strategy selects from the action mask constraints... The execution mode is selected. Specifically, V2I actions are disabled when the V2I link is unavailable, and V2V actions are disabled when no neighboring vehicle meets the communication distance and contact time constraints. After the higher-level actions are determined, the execution node is determined as follows: if it is a Local action, the node is the source vehicle; if it is a V2I action, the node is the RSU; if it is a V2V action, the node with the smallest estimated completion delay is selected from the filtered set of neighboring vehicles.

[0070] In some embodiments, the reinforcement learning model further includes a low-level policy network.

[0071] Step S4 specifically includes: Step S41: The low-level strategy outputs multi-dimensional continuous actions based on the execution decision results to obtain the heterogeneous resource allocation ratio.

[0072] Step S42: Multiply the heterogeneous resource allocation ratio by the available heterogeneous computing resources of the target node dimension by dimension to obtain the actual computing resources obtained by the task.

[0073] Step S43: Allocate tasks to be assigned based on computing resources.

[0074] In this embodiment, as Figure 3 As shown, after the target node is determined, the low-level strategy allocates resources. The low-level strategy outputs multi-dimensional continuous actions, which, after normalization, yield the heterogeneous resource allocation ratio. This ratio is multiplied dimension-by-dimensionally by the currently available resources of the target node to obtain the actual computing resources acquired by the task. Bandwidth allocation is not an independent learning action, but is generated based on the urgency of link latency, thereby satisfying bandwidth capacity constraints.

[0075] In this embodiment, the low-level policy network includes a low-level state space and a low-level action space.

[0076] Specifically, the lower-level state focuses on target nodes and resource allocation decisions, and is defined as follows: ; in This represents the heterogeneous resource vector of the target node.

[0077] Low-level actions are continuous resource allocation vectors: ; After normalization, we get: ; The actual resource allocation is as follows: .

[0078] Bandwidth allocation is calculated based on link latency urgency: ; in: .

[0079] During model training, the system's immediate reward is defined as: ; in: Average task completion time; : Task success rate; Load imbalance; Weighting coefficient.

[0080] High-level and low-level strategies maintain independent experience replay pools while sharing environmental feedback. The high-level strategy uses DDQN for discrete decision-making, while the low-level strategy uses TD3 for continuous control. Action masks constrain the discrete action space, and normalization operations constrain the continuous action space, thereby reducing ineffective exploration and improving training stability.

[0081] Within a single time slot, the algorithm's main overhead comes from candidate selection, high-level policy reasoning, target node selection, and low-level resource allocation. Because the hierarchical structure decouples discrete decision-making from continuous control, the high-level layer makes decisions only within a finite set of actions, and the low-level layer only allocates resources on the target node, thus avoiding the complexity increase brought about by the high-dimensional joint action space.

[0082] In terms of stability, the action mask ensures that the execution mode meets the communication constraints, the normalization operation ensures that the resource allocation meets the capacity constraints, and the task-resource matching matrix provides structured priors to guide the policy to learn a more reasonable resource allocation method, thereby obtaining a stable near-optimal policy in a dynamic environment.

[0083] In some optional implementations, the model algorithm of this application can be represented by the following steps: Algorithm 1: A hierarchical reinforcement learning joint optimization algorithm based on task-resource adaptation. 1: Initialize the high-level DDQN and evaluate the network parameters and target network parameters; 2: Initialize the parameters of the low-level TD3 Actor network, the dual Critic network, and their target network; 3: Initialize the high-level experience replay pool and the low-level experience replay pool; 4: for episode = 1 to EP_max do 5: Initialize the vehicle networking environment and observe the initial system state s0; 6: for t = 1 to T do 7: Obtain the current task set, link status, node load, and heterogeneous resource status; 8: for each task i ∈ (t) do 9: Filter the original candidate set based on link reachability, V2V contact duration, resource availability, and deadline constraints. i (t); 10: Calculate task-device affinity based on the task-resource matching matrix Θ, and obtain a set of candidate devices for screening. i (t); 11: Constructing high-level states s i h (t), and generate action mask M. i (t); 12: High-level DDQN based on s i h (t) and Mi (t) Select execution mode a i h (t) ∈ {Local, V2V,V2I}; 13: if a i h (t) = Local then 14: Target node n i ← Source vehicle; 15: else if a i h (t) = V2I then 16: Target node n i ← RSU; 17: else 18: Select the node with the smallest estimated completion delay from the filtered set of neighboring vehicles as the target node n. i ; 19: end if 20: According to n i Generate execution variable z in (t); 21: Constructing the lower-level state s i l (t), including task attributes, target node resources, link status, node load, and Θ; 22: Lower-level TD3 Actor based on s i l (t) Output continuous action a i l (t); 23: Regarding a i l (t) is normalized using simplex methods to obtain the heterogeneous resource allocation ratio α. in g(t); 24: Generate bandwidth allocation ratio β based on link latency urgency. in (t); 25: Execute the task, calculate communication latency, matching-aware computation latency, and total completion latency; 26: Determine if the task meets the deadline constraint and obtain the task success flag; 27: end for 28: Calculate the instantaneous reward r(t) of the calculation system; 29: Obtain the next state st+1 ; 30: Store the high-rise transfer samples in the high-rise experience playback pool; 31: Store the low-level transferred samples into the low-level experience replay pool; 32: Sample small batches of samples from the high-level experience replay pool to update the DDQN network and its target network; 33: Sample small batches of samples from the low-level experience replay pool to update the TD3 Actor, dual Critic network, and its target network; 34: end for 35: end for 36: Output the high-level execution mode selection strategy and the low-level heterogeneous resource allocation strategy after training.

[0084] As can be seen from the above embodiments of this application, the vehicle-to-everything (V2X) computing power network resource allocation method provided by this application determines the connection status of the V2X link by identifying candidate execution nodes based on the V2X computing power network status, thereby avoiding connection interruption and preventing task transmission failure due to short contact time of the V2V link when the vehicle is moving at high speed. Furthermore, by determining the compatibility between the task to be allocated and the candidate execution nodes, the task to be allocated is assigned to a candidate execution node with a high degree of matching, improving task execution efficiency while avoiding waste of computing resources. Finally, the execution decision result is determined through a reinforcement learning model, and the task to be allocated is then allocated according to the execution decision result, thereby enabling stable allocation of network resources for the V2X computing power network.

[0085] To verify the vehicle-to-everything (V2X) computing power network resource allocation method provided in this application, this application also designed a hardness simulation experiment to verify the above method.

[0086] To verify the effectiveness of the proposed method in dynamic vehicular network environments, this paper constructs an experimental environment based on a discrete-time slot vehicular network simulation platform and models vehicle movement, communication links, task generation, and resource contention processes using parameters from typical urban road scenarios. The simulation scenario is set as a two-lane straight road segment with a length of 800 m, and the number of vehicles varies between 12 and 32 to simulate task offloading demands, resource contention intensity, and dynamic changes in links under different traffic densities. The initial positions and speeds of the vehicles are randomly generated and updated according to a uniform motion model within each discrete time slot, thus forming a continuously changing vehicular network topology.

[0087] To further enhance the realism of mobility modeling, this paper introduces the traffic simulation tool Simulation of Urban Mobility (SUMO) to generate vehicle trajectories and imports vehicle position and speed information into the simulation environment. This approach more accurately characterizes the dynamic changes in relative position, relative speed, and communication topology between vehicles under real traffic flow conditions, avoiding the idealization biases introduced by relying solely on random motion models.

[0088] Regarding system execution nodes, the simulation environment includes three types of computing nodes: local vehicle nodes, neighboring vehicle cooperative nodes, and roadside units (RSUs), corresponding to three task processing modes: local execution, V2V offloading, and V2I offloading, respectively. The RSUs are deployed in the center of the road with a coverage radius of 250 m, and the maximum V2V communication distance is set to 120 m. For communication parameters, the total system bandwidth is set to 20 MHz, the vehicle transmit power to 200 mW, and the path loss index to 2.2. These parameters are based on commonly used settings in typical vehicular network and edge computing research to ensure the simulation results have a certain degree of engineering rationality and horizontal comparability.

[0089] To characterize the dynamic changes in link availability in high-speed mobile vehicle-to-everything (V2V) scenarios, this paper explicitly models the V2V contact duration. For any vehicle i and vehicle j, the contact time is defined as: ; When the contact time between vehicle i and vehicle j Less than the time required for task transmission If the V2V offloading cannot be completed during the transmission phase, it is considered an infeasible decision. This modeling approach avoids misjudgments caused by judging link availability solely based on instantaneous distance. For example, although a neighboring vehicle node may be within communication range at the current moment, if the relative speed between the two vehicles is high, the contact window may be insufficient to complete the task transmission. If the neighboring vehicle is still selected for offloading in this case, invalid offloading behavior of "theoretically achievable, but actually interrupted" is likely to occur. Therefore, incorporating the contact duration into the feasibility assessment helps improve the robustness of offloading decisions in high-speed dynamic scenarios.

[0090] In terms of task generation, this paper assumes that each vehicle generates a computational task with a probability of 0.5 in each time slot to simulate the random arrival of task requests in the Internet of Vehicles (IoV). Based on the computational characteristics and latency requirements of intelligent IoV services, task types are divided into three categories: control tasks, perception tasks, and fusion inference tasks, with generation ratios set to 0.35, 0.40, and 0.25, respectively. Different value ranges are set for the three task categories in terms of data scale, computational load, and maximum tolerable latency to reflect the differences in computational intensity, real-time performance, and resource requirements among different services. For example, control tasks typically have strong real-time requirements but relatively small data volumes, perception tasks typically have high data processing volumes and parallel computing requirements, while fusion inference tasks rely more on neural network inference and multi-source information processing capabilities.

[0091] In terms of resource modeling, this paper no longer abstracts node computing power as a single scalar computing power, but instead uses a multi-dimensional heterogeneous resource vector to represent the computing power of a node. Specifically, node computing resources include three resource dimensions: CPU, GPU, and NPU, corresponding to general computing, parallel computing, and neural network acceleration capabilities, respectively. To characterize the differentiated adaptation relationship between different task types and different processor resources, this paper introduces a task-resource adaptation matrix Θ, which describes the relative execution efficiency of different types of tasks across different resource dimensions. Through this matrix, the system can not only determine whether a node has sufficient computing resources, but also further determine whether the node's resource structure is suitable for the current task type.

[0092] To verify the robustness of task-resource adaptation modeling, various adaptation matrix configurations were set up in the experiment, including the default structured matrix, the uniform distribution matrix, the random initialization matrix, and the perturbed matrix with ±10% and ±20% random perturbations. All adaptation matrices underwent row normalization to ensure comparability between different configurations. Through these settings, the impact of task-resource adaptation priors on system performance under different conditions, including accurate, weakened, random, and perturbation-containing scenarios, can be analyzed.

[0093] To comprehensively evaluate the performance of the proposed method, this paper selects several representative heuristic and reinforcement learning methods as comparison algorithms. The heuristic methods include Local-only, Least-loaded, Greedy-Scalar, and Greedy-Affinity. Local-only means that all tasks are executed locally on the local machine without task offloading; Least-loaded means that tasks are preferentially assigned to the node with the lowest current load; Greedy-Scalar means that greedy offloading and resource allocation are performed based on a uniform scalar computing power; and Greedy-Affinity further considers the task-resource fit relationship in the greedy decision-making process.

[0094] Reinforcement learning methods include DQN-Scalar, Flat-TD3, and Proposed-HRL. DQN-Scalar represents a resource scheduling method based on single-layer discrete reinforcement learning, which simplifies resource capabilities into a scalar form. Flat-TD3 represents a single-layer continuous reinforcement learning method that directly handles execution decisions and resource allocation simultaneously in a unified action space. Proposed-HRL represents the hierarchical reinforcement learning method based on task-resource adaptation proposed in this paper, which selects the execution mode through high-level policies and allocates heterogeneous resources through low-level policies.

[0095] The aforementioned comparative algorithms are primarily designed to verify two questions: first, whether task-resource adaptation modeling can effectively improve the utilization efficiency of heterogeneous computing resources; and second, whether hierarchical reinforcement learning structures can better handle mixed discrete-continuous decision-making problems compared to single-layer reinforcement learning methods. By comparing the proposed method with heuristic methods, scalar computing power modeling methods, single-layer reinforcement learning methods, and adaptation-aware greedy methods, the role of each design module in this paper can be analyzed more clearly.

[0096] To comprehensively evaluate system performance, this paper sets evaluation metrics from multiple perspectives, including latency, reliability, resource utilization, offloading effectiveness, load balancing, and decision complexity. First, average task completion latency measures the total time from task generation to completion, directly reflecting the system's ability to support low-latency services. Second, on-time task completion rate measures whether tasks can be completed within the maximum tolerable latency, serving as a crucial indicator for evaluating the quality of real-time services in the Internet of Vehicles (IoV).

[0097] Furthermore, this paper introduces matching resource utilization rate to measure whether tasks are allocated to highly adapted resources, thereby evaluating the role of the task-resource adaptation matrix in improving the utilization efficiency of heterogeneous computing power. The invalid offloading ratio is used to statistically analyze failed offloading behaviors caused by link interruptions, insufficient contact time, or incomplete tasks. This indicator directly reflects the ability of the candidate node screening mechanism to suppress unreasonable offloading decisions. Further, load imbalance is used to measure whether tasks are excessively concentrated on a few nodes to assess the load distribution of the system in multi-node resource collaboration. Finally, the unit time slot decision time is used to measure the time overhead of the algorithm's online inference and decision-making, thereby evaluating its deployment feasibility in real-time vehicle networking scenarios.

[0098] Using the aforementioned metrics, this paper comprehensively validates the proposed method from both performance results and mechanism effects. On the one hand, average latency and on-time task completion rate reflect the overall task execution quality of the system; on the other hand, matching resource utilization, invalid offloading ratio, load imbalance, and decision time per unit time slot can further explain the reasons behind the performance improvement, namely, the roles played by task-resource adaptation modeling, candidate node screening mechanism, and hierarchical reinforcement learning structure in resource matching, link feasibility assurance, and decision complexity control, respectively.

[0099] Convergence analysis: like Figure 4 As shown in the figure, this graph illustrates the cumulative reward convergence changes of different algorithms over 500 training rounds. The overall trend indicates that in the early stages of training, due to the strong randomness of the policies, the reward values ​​of all methods are at a low level, mainly concentrated in... 60000 to Around 55,000. As the training process progresses, the performance of different algorithms gradually diverges, eventually converging to different stable levels.

[0100] In terms of convergence performance, Proposed-HRL has the fastest convergence speed and the highest final reward value. Its reward curve first breaks through around the 150th training round. 10,000, and stabilized at around 10,000 after the 200th training round. Around 9000, the overall fluctuation range is significantly smaller than other methods. In contrast, w / o Screening, which removes the candidate selection mechanism, eventually converges to approximately The score of 10,000, while lower than Proposed-HRL, is still better than other ablation methods, indicating that the candidate selection mechanism can improve policy quality, but its contribution is relatively independent. Removing the w / oAffinity of the adaptation matrix eventually stabilizes at approximately [value missing]. The score of 11500 is significantly lower than that of Proposed-HRL, indicating that task-resource adaptation modeling plays a more crucial role in improving the overall reward.

[0101] Flat-TD3's rewards ultimately stopped at approximately The score was 13500, and significant oscillations were observed during training, indicating that single-layer continuous reinforcement learning methods are prone to accumulating function estimation errors when simultaneously handling execution patterns, bandwidth allocation, and heterogeneous resource allocation in a high-dimensional joint action space, leading to insufficient training stability. DQN-Scalar had the slowest convergence speed, only gradually escaping the oscillation range around the 280th training epoch, with a final reward of approximately [missing information]. The main reason for the low reward level of 15000 is that it simplifies heterogeneous resources into scalar actions, losing structural information about the resource dimension and reducing the policy discrimination capability. The Random method consistently maintains the lowest reward level throughout the training process, indicating that random decision-making is ill-suited to the complex resource scheduling requirements of dynamic vehicular network computing power.

[0102] From a mechanistic perspective, the rapid convergence and low oscillation of Proposed-HRL are mainly attributed to the decoupled design of the DDQN-TD3 layered architecture. The higher-level DDQN focuses on selecting discrete execution modes such as local execution, V2V offloading, and V2I offloading, thereby reducing the complexity of discrete action search. The lower-level TD3 only performs continuous resource allocation after the target execution node is determined, shrinking the action space from a high-dimensional joint action space to a heterogeneous resource ratio vector. This layered structure, combined with the delayed policy update mechanism of TD3, helps stabilize the gradient of the Actor network and improve training efficiency. Therefore, Figure 4 The results show that hierarchical decoupling can not only accelerate policy convergence, but also improve the final policy performance.

[0103] Average task completion time analysis: like Figure 5 As shown in the figure, this graph illustrates the change in average task completion latency for different algorithms as the number of vehicles increases from 12 to 32. Overall, the task completion latency for all methods increases with the number of vehicles, and the rate of increase accelerates significantly after the number of vehicles reaches 24. This indicates that when the system enters a high-load state, shared channel interference, node resource contention, and task queuing pressure combine to cause a rapid increase in task completion latency.

[0104] Across all vehicle scales, Proposed-HRL consistently maintains the lowest average task completion latency. With 12 vehicles, Proposed-HRL's average latency is 85 ms, Greedy-Affinity is 100 ms, DQN-Scalar and Flat-TD3 are both around 103 ms, Least-loaded is 118 ms, and Local-only is 135 ms. At this point, the system load is relatively low, and the differences between the algorithms are not yet fully apparent. When the number of vehicles increases to 32, Proposed-HRL's average latency rises to 182 ms, while Greedy-Affinity, DQN-Scalar, Flat-TD3, Greedy-Scalar, Least-loaded, and Local-only reach 215 ms, 245 ms, 272 ms, 313 ms, 383 ms, and 465 ms, respectively. Therefore, it is evident that Proposed-HRL has a more significant advantage over other methods in high-load scenarios.

[0105] It is worth noting that as the number of vehicles increases, the absolute latency difference between Proposed-HRL and other algorithms continues to widen. For example, when the number of vehicles is 12, the latency difference between Proposed-HRL and Local-only is only 50 ms; however, when the number of vehicles increases to 32, the difference widens to 283 ms. This widening trend indicates that the proposed method is more advantageous in scenarios with intensified resource competition. Greedy-Affinity is relatively close to Proposed-HRL in low-load scenarios, but after the number of vehicles exceeds 24, its latency growth slope is significantly higher than that of Proposed-HRL, indicating that the greedy strategy is prone to getting trapped in local optima under high-load conditions and lacks global coordination capabilities across tasks and nodes.

[0106] The latency advantage of Proposed-HRL primarily stems from three aspects. First, the task-resource matching matrix guides the lower-level TD3 to allocate different types of tasks to more suitable heterogeneous processor resources, thereby improving the effective computing speed. Second, the candidate node screening mechanism eliminates neighboring nodes with insufficient contact time or unsustainable communication before decision-making, reducing additional latency caused by link interruptions, task retransmissions, and offloading failures. Finally, the hierarchical reinforcement learning framework jointly considers execution mode selection, bandwidth allocation, and computing resource allocation, avoiding conflicts caused by independent optimization of communication and computing resources. Therefore, Figure 5The results show that task-resource adaptation modeling and hierarchical resource optimization can produce more significant latency reduction effects when the system load increases.

[0107] On-time completion rate analysis of tasks: like Figure 6 As shown in the figure, the on-time completion rate of various algorithms varies under different vehicle densities. Overall, the on-time completion rate of all methods decreases as the number of vehicles increases. This is because an increase in the number of vehicles leads to more concurrent tasks, stronger bandwidth contention, and higher node load, making it difficult for more tasks to complete within the specified deadline. Among these, Local-only and Least-loaded algorithms show the most significant decreases, while Proposed-HRL exhibits the flattest decline curve, indicating its stronger service quality assurance capability under high load conditions.

[0108] When the number of vehicles is 12, the on-time completion rate of Proposed-HRL reaches 0.95, higher than Greedy-Affinity's 0.93, DQN-Scalar's 0.91, Flat-TD3's 0.90, Greedy-Scalar's 0.88, Least-loaded's 0.84, and Local-only's 0.78. When the number of vehicles increases to 32, the on-time completion rate of Proposed-HRL drops to 0.77, a cumulative decrease of 18 percentage points; while Greedy-Affinity, DQN-Scalar, Flat-TD3, Greedy-Scalar, Least-loaded, and Local-only drop to 0.70, 0.66, 0.61, 0.54, 0.43, and 0.32, respectively. In comparison, Proposed-HRL can still maintain high task completion reliability in high-load scenarios.

[0109] Looking at the difference between the optimal and worst methods, when the number of vehicles is 12, the difference in on-time task completion rate between Proposed-HRL and Local-only is 17 percentage points; when the number of vehicles increases to 32, this difference widens to 45 percentage points. This indicates that the QoS guarantee advantage of the proposed method is further amplified as system pressure increases. Furthermore, Greedy-Affinity shows a smaller difference from Proposed-HRL when the number of vehicles is no more than 20, but the difference widens rapidly when the number of vehicles reaches 28 or more, indicating that the greedy strategy lacks global coordination ability when resource competition intensifies, making it difficult to continuously guarantee on-time task completion.

[0110] From a mechanistic perspective, Proposed-HRL maintains a high on-time task completion rate primarily due to the lower-layer TD3's ability to perceive real-time node load and heterogeneous resource status. This mechanism dynamically adjusts the allocation ratio across different resource dimensions, preventing tasks from being overly concentrated on a particular type of resource or node, thereby reducing the probability of task timeouts. Simultaneously, the candidate filtering mechanism filters out infeasible nodes in advance through contact time constraints, reducing task failures caused by link failures at the source. Therefore, Figure 6 The results validated the important role of joint optimization of candidate selection and heterogeneous resource allocation in improving the on-time completion rate of tasks.

[0111] Matching resource utilization analysis: like Figure 7 As shown in the figure, the graph uses different task-resource adaptation matrix configurations as the horizontal axis to compare the matching resource utilization rates of three methods: Proposed-HRL, Greedy-Affinity, and w / o Affinity. The adaptation matrix configurations considered include Uniform, Random, Weak, Default, Strong, Perturbed-10%, and Perturbed-20%. Overall, the matching resource utilization rates of Proposed-HRL and Greedy-Affinity increase with the strength of the adaptation structure, reaching a peak under the Strong configuration; while w / o Affinity remains relatively stable between 0.49 and 0.53 across all configurations, showing almost no significant change. This indicates that in the absence of a task-resource adaptation matrix, the resource allocation strategy cannot perceive the matching relationship between different task types and heterogeneous resources, and its resource utilization behavior is essentially decoupled from the adaptation structure.

[0112] Under the Uniform configuration, because the adaptation relationship of various resources to tasks is evenly distributed, the resource utilization rates of Proposed-HRL, Greedy-Affinity, and w / o Affinity are 0.52, 0.50, and 0.49, respectively, with little difference between them. When using the Default structured adaptation matrix, the resource utilization rate of Proposed-HRL increases to 0.78, a 50.0% improvement compared to the Uniform configuration; Greedy-Affinity increases to 0.72, while w / o Affinity is only 0.52. Under the Strong configuration, Proposed-HRL reaches a peak of 0.84, Greedy-Affinity is 0.79, and w / o Affinity is only 0.53. At this point, Proposed-HRL is 6.3 percentage points higher than Greedy-Affinity and 58.5% higher than w / o Affinity, which fully demonstrates that task-resource adaptation modeling can significantly improve the efficiency of heterogeneous resource matching and utilization.

[0113] Despite perturbations in the adaptation matrix, Proposed-HRL maintains good robustness. When the adaptation matrix is ​​subject to ±10% random perturbation, Proposed-HRL's matching resource utilization is 0.76, only 9.5% lower than the peak value. When the perturbation increases to ±20%, its matching resource utilization still reaches 0.73, retaining 86.9% of the peak performance. Even under the stringent condition of Perturbed-20%, Proposed-HRL is still significantly higher than w / o Affinity's 0.50, indicating that even with some errors in the task-resource adaptation prior, the reinforcement learning strategy can still maintain effective utilization of heterogeneous processor architectures through online interactive learning.

[0114] Greedy-Affinity performs close to Proposed-HRL in a strongly adaptable architecture, but consistently falls short of Proposed-HRL in Default and Perturbed configurations. This is because Greedy-Affinity only makes locally optimal choices based on the current adaptability, lacking global coordination capabilities across time slots, nodes, and tasks, which can easily lead to excessive consumption of some highly adaptable resources. In contrast, Proposed-HRL can dynamically balance resource adaptability, node load, and task time limits. Therefore, Figure 7 The results show that the task-resource adaptation matrix not only has a clear performance gain, but also is robust to a certain degree of prior error, and has strong engineering deployment value.

[0115] Analysis of invalid uninstallation ratio: like Figure 8 As shown in the figure, the change in the invalid offloading ratio of each method is illustrated as the vehicle speed increases from 20 km / h to 70 km / h. Overall, the invalid offloading ratio increases for all methods with increasing vehicle speed. This is because higher vehicle speeds result in shorter V2V link contact windows, faster link topology changes, and a higher probability of task interruptions or timeouts during the transmission phase.

[0116] In a low-speed scenario of 20 km / h, Proposed-HRL exhibits the lowest invalid offloading ratio at only 0.035; in comparison, w / o Screening is 0.075, Flat-TD3 is 0.067, Greedy-Scalar is 0.090, and Random is 0.163. As vehicle speed increases to 70 km / h, the invalid offloading ratio of Proposed-HRL rises to 0.157, but remains significantly lower than w / o Screening's 0.308, Flat-TD3's 0.289, Greedy-Scalar's 0.407, and Random's 0.598. This demonstrates that Proposed-HRL maintains the lowest invalid offloading ratio across the entire speed range, indicating its stronger communication feasibility assurance capability in high-speed dynamic environments.

[0117] In terms of the magnitude of change, the invalid unloading ratio of Proposed-HRL increased from 0.035 to 0.157, while Random increased from 0.163 to 0.598. More importantly, the gap between w / o Screening and Proposed-HRL widened significantly with increasing speed. At 20 km / h, the difference was 0.040; while at 70 km / h, the difference widened to 0.151, approximately 3.8 times that in low-speed scenarios. This indicates that the benefits of the candidate screening mechanism amplify non-linearly with increasing vehicle speed, becoming particularly crucial in high-speed scenarios.

[0118] From a mechanistic perspective, the low invalid offloading ratio of Proposed-HRL mainly stems from two collaborative designs. First, a V2V contact time filtering mechanism is introduced during the candidate screening phase. Before making a decision, the system estimates the contact time between vehicle pairs. When the contact time is less than the task transmission time, the candidate neighbor vehicle is directly blocked, preventing link interruptions due to insufficient contact time from the source. Second, the high-level DDQN introduces an action masking mechanism. When all V2V neighbors that meet the contact time constraints are unavailable, the system forces a switch to local execution or V2I offloading, thereby avoiding invalid V2V offloading. In contrast, although w / o Screening also uses a hierarchical reinforcement learning framework, it lacks a contact time filtering step and may still select neighbor vehicles with insufficient contact windows in high-speed scenarios, thus significantly increasing the invalid offloading ratio. Figure 8 The results validated the key role of explicitly incorporating contact time constraints into the candidate node selection process in improving system robustness.

[0119] Ablation experiment analysis: like Figure 9 As shown in the figure, this graph uses a two-bar comparison to illustrate the performance differences in average task completion latency and on-time task completion rate among five configurations: Proposed, without Affinity, without Screening, Flat-RL, and without Load. All experiments were conducted in a standard scenario with N=20 vehicles. The experimental results show that the complete Proposed method achieved the lowest average latency and the highest on-time task completion rate, with an average latency of 150 ms and an on-time task completion rate of 0.81.

[0120] When the task-resource adaptation mechanism was removed, the average latency with / o affinity increased to 197 ms, a 31.3% increase compared to the proposed solution, while the on-time task completion rate decreased to 0.67, a 17.3% reduction compared to the proposed solution. This demonstrates that the task-resource adaptation matrix plays a crucial role in improving the utilization efficiency of heterogeneous computing resources. Without this mechanism, the system cannot accurately distinguish the execution differences of control, perception, and fusion inference tasks on different processor resources, and resource allocation degenerates into a general allocation strategy unrelated to task type, resulting in a decrease in effective computing speed and an increase in task completion latency.

[0121] After removing the candidate screening mechanism, the average latency of w / o Screening was 175 ms, an increase of 16.7% compared to the proposed solution, and the on-time task completion rate decreased to 0.73. This result indicates that the candidate screening mechanism can effectively reduce offloading decisions due to communication infeasibility or insufficient contact time, but its impact is slightly lower than that of the task-resource adaptation mechanism. Flat-RL showed the most significant performance degradation, with an average latency of 213 ms, an increase of 42.0% compared to the proposed solution, and the on-time task completion rate decreased to 0.63. The main reason for this is that single-layer reinforcement learning requires simultaneous processing of execution mode selection, bandwidth allocation, and heterogeneous resource ratio control in a joint action space, causing the action space to expand rapidly with the number of nodes and resource types, significantly increasing the difficulty of policy exploration and the variance of gradient estimation. The average latency of w / o Load was 185 ms, and the on-time task completion rate was 0.75, indicating that although the load balancing objective has a relatively small impact on the on-time task completion rate, it still has practical significance in suppressing overload of hot nodes, reducing task queuing, and reducing computational competition.

[0122] In summary, different ablation modules have significantly different impacts on system performance. Flat-RL has the greatest impact on average latency, followed by without affinity, without load, and without screening. Similarly, Flat-RL also has the greatest impact on on-time task completion rate, followed by without affinity, without screening, and without load. This indicates that the hierarchical reinforcement learning structure and task-resource adaptation modeling are two key supports for the proposed method, while candidate selection and load balancing mechanisms further enhance the system's robustness and stability in dynamic scenarios. Figure 9 The results show that the modules in the proposed method are complementary, and the absence of any one module will cause a quantifiable performance degradation.

[0123] Performance analysis of different task types: like Figure 10 As shown in the figure, the average completion latency of three types of tasks—control, perception, and fusion inference—under different algorithms is presented to verify the fine-grained effectiveness of the task-resource adaptation matrix in heterogeneous processor environments. Comparison methods include Proposed-HRL, with / o Affinity, Greedy-Scalar, and Local-only. Experimental results show that Proposed-HRL achieves the lowest average completion latency across all three task types.

[0124] For control-type tasks, the average completion latency of Proposed-HRL is 65 ms, while those of w / o Affinity, Greedy-Scalar, and Local-only are 82 ms, 90 ms, and 118 ms respectively. For perception-type tasks, the average latency of Proposed-HRL is 135 ms, which is significantly reduced compared with 188 ms of w / o Affinity, 205 ms of Greedy-Scalar, and 270 ms of Local-only. For fusion inference-type tasks, the average latency of Proposed-HRL is 157 ms, while w / o Affinity, Greedy-Scalar, and Local-only reach 225 ms, 251 ms, and 325 ms respectively. It can be seen that Proposed-HRL has stable performance advantages for different task types.

[0125] From the perspective of differences between task types, under Proposed-HRL, the average latency of the three types of tasks follows the rule of Control<Perception<Fusion, which is basically consistent with the differences in data scale, computational load and latency constraints of different tasks. From the perspective of relative improvement range, the fusion inference-type tasks gain the maximum benefit. Compared with Local-only, Proposed-HRL reduces the latency of fusion inference tasks by 51.7%, and reduces it by 30.2% compared with w / o Affinity; the relative improvement range of control-type tasks is relatively small, which is mainly because control-type tasks themselves have strong adaptability to the general computing capability of the CPU, and can obtain certain basic performance even without a refined adaptation mechanism.

[0126] From a mechanistic perspective, the task-resource adaptation matrix can characterize the preference relationship between different task types and heterogeneous resources. For example, control-type tasks are more suitable for CPUs, perception-type tasks are more suitable for GPUs, and fusion inference-type tasks are more suitable for NPUs. In Proposed-HRL, the low-level TD3 maximizes the perceived equivalent computing rate, tilts the resource allocation ratio of different tasks towards the corresponding high-adaptation resource dimension, so as to achieve accurate matching between tasks and processors. In contrast, w / o Affinity and Greedy-Scalar cannot make full use of this structural adaptation relationship, thus exhibiting higher latency on all three types of tasks. Figure 10 The results verify the practical value of heterogeneous computing power adaptation modeling for multi-service coexisting Internet of Vehicles scenarios at the fine-grained level of task types.

[0127] Scalability and decision complexity analysis: like Figure 11 As shown in the figure, with the number of vehicles increasing from 12 to 32 on the horizontal axis, the decision time per unit time slot for four methods—Proposed-HRL, without Screening, Flat-TD3, and Greedy-Affinity—is displayed. This is used to evaluate the effectiveness of candidate selection mechanisms and hierarchical architectures in controlling online computational overhead. Experimental results show that the decision time of each method increases with the number of vehicles, but the rate of increase differs significantly.

[0128] When the number of vehicles is 12, the decision time per time slot is 1.3 ms for Greedy-Affinity, 2.4 ms for Proposed-HRL, 2.9 ms for without Screening, and 4.7 ms for Flat-TD3. When the number of vehicles increases to 32, Greedy-Affinity increases to 2.9 ms, Proposed-HRL increases to 5.7 ms, without Screening increases to 10.4 ms, and Flat-TD3 increases to 21.1 ms. This shows that while the decision time of Proposed-HRL is higher than that of Greedy-Affinity, it is significantly lower than that of without Screening and Flat-TD3, and the overall growth trend is nearly linear.

[0129] Compared to Flat-TD3, Proposed-HRL is approximately 3.7 times faster in decision-making with 32 vehicles; and compared to without screening, Proposed-HRL's decision-making time is only about 55% of that of Flat-TD3. This demonstrates that the candidate screening mechanism effectively compresses the candidate node space, reduces the participation of low-quality or infeasible nodes in subsequent decisions, and thus reduces online inference overhead. Flat-TD3 exhibits a significant superlinear increase in decision-making time, primarily because it requires joint searching across all candidate nodes and the continuous resource action space, with the action space complexity increasing rapidly with the number of vehicles and resource types. In contrast, Proposed-HRL, through candidate screening and hierarchical decision-making, compresses the candidate set to the range of effective execution nodes and decouples discrete execution mode selection from continuous resource allocation, thus keeping the decision-making time at a lower level.

[0130] From an engineering deployment perspective, the time slot length of a typical vehicle-to-everything (V2X) system is usually 100 ms to 200 ms, and the online decision-making time needs to be controlled within a small portion of this time slot length. Proposed-HRL achieves a unit time slot decision time of only 5.7 ms with a maximum vehicle scale of N=32, meeting real-time scheduling requirements. Flat-TD3, on the other hand, achieves 21.1 ms at the same scale, approaching or even exceeding the acceptable range for some real-time scenarios. While Greedy-Affinity has the lowest decision time, its average latency and on-time task completion rate are significantly worse than Proposed-HRL, indicating that its computational advantage is gained at the expense of scheduling quality. In summary, Figure 11 The results show that Proposed-HRL achieves a better balance between scheduling performance and online decision complexity, and is more suitable for real-time deployment of dynamic vehicle-to-everything (V2X) computing networks.

[0131] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0132] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0133] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a vehicle network computing power resource allocation device.

[0134] refer to Figure 12 A vehicle-to-everything (V2X) computing power network resource allocation device, applied to a V2X computing power network including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units, the device comprising: The filtering module 100 is used to determine candidate execution nodes based on the network status of the vehicle-to-everything (V2X) computing power network.

[0135] The matching module 200 is used to filter candidate execution nodes based on the compatibility relationship between the task to be assigned and the candidate execution nodes, and obtain a candidate execution set.

[0136] The decision module 300 is used to determine the execution decision result through a preset reinforcement learning model and a set of candidate executions.

[0137] The allocation module 400 is used to allocate the tasks to be allocated to the corresponding candidate execution nodes based on the execution decision results.

[0138] In some embodiments, the matching module 200 includes: The adaptation calculation module is used to determine the relative adaptation coefficient based on the task type of the task to be assigned and the original adaptation score of the execution node.

[0139] Construct a matching matrix based on the relative fit coefficients.

[0140] The matching relationship is determined based on the matching matrix.

[0141] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0142] The apparatus described above is used to implement the corresponding vehicle network computing power resource allocation method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0143] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle network computing power resource allocation method described in any of the above embodiments.

[0144] Figure 13 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0145] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0146] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0147] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0148] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0149] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0150] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0151] The electronic devices described above are used to implement the corresponding vehicle network computing power resource allocation method in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0152] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium storing computer instructions, which are used to cause the computer to execute the vehicle network computing power network resource allocation method as described in any of the above embodiments.

[0153] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0154] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the vehicle network computing power network resource allocation method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0155] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0156] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0157] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0158] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.

Claims

1. A method for allocating computing power network resources in a vehicle-to-everything (V2X) network, applied to a V2X computing power network including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units, the method comprising: Candidate execution nodes are determined based on the network status of the vehicle-to-everything (V2X) computing power network. Based on the compatibility between the task to be assigned and the candidate execution nodes, the candidate execution nodes are filtered to obtain a candidate execution set; The execution decision result is determined by using a pre-set reinforcement learning model and the candidate execution set; Based on the execution decision result, the task to be assigned is assigned to the corresponding candidate execution node.

2. The method for allocating network resources for vehicle-to-everything (V2X) computing power according to claim 1, wherein, The process of adapting the task to be assigned to the candidate execution node specifically includes: The relative fit coefficient is determined based on the task type of the task to be assigned and the original fit score of the execution node; Construct a matching matrix based on the relative fit coefficients; The adaptation relationship is determined based on the matching matrix.

3. The method for allocating network computing power resources for the Internet of Vehicles according to claim 1, wherein, The process of filtering the candidate execution nodes specifically includes: Based on preset link feasibility, vehicle-to-vehicle contact continuity, task-node resource matching degree, and node load friendliness, the affinity between the task to be assigned and the candidate execution node is calculated. The affinity is compared with a preset screening threshold, and candidate nodes whose affinity meets the screening threshold are retained to obtain the candidate execution set.

4. The method for allocating network resources for vehicle-to-everything (V2X) computing power according to claim 1, wherein, The reinforcement learning model includes a high-level policy network; The step of determining the execution decision result through a preset reinforcement learning model and the candidate execution set specifically includes: The execution mode of each task to be assigned in the candidate execution set is determined based on the preset action mask and the high-level policy network; wherein, the execution mode includes local execution, V2V execution and V2I execution; The execution decision result is determined based on all the execution modes described.

5. The method for allocating network resources for vehicle-to-everything (V2X) computing power according to claim 4, wherein, The method further includes: The target node is determined based on the execution mode; In response to the execution mode being local execution, the source vehicle is designated as the target node; In response to the execution mode being V2I, the roadside unit is designated as the target node; In response to the execution mode being V2V, the node with the smallest estimated completion delay is selected from the filtered set of neighboring vehicles as the target node.

6. The method for allocating network resources for vehicle-to-everything (V2X) computing power according to claim 5, wherein, The reinforcement learning model also includes a low-level policy network; The step of assigning the task to be assigned to the corresponding candidate execution node based on the execution decision result specifically includes: The low-level strategy outputs multi-dimensional continuous actions based on the execution decision results to obtain the heterogeneous resource allocation ratio. The heterogeneous resource allocation ratio is multiplied dimension by dimension by the currently available heterogeneous computing resources of the target node to obtain the actual computing resources obtained by the task. The tasks to be assigned are allocated based on the computing resources.

7. A vehicle-to-everything (V2X) computing power network resource allocation device, applied to a V2X computing power network including vehicle nodes, neighboring vehicle cooperative nodes, and roadside units, the device comprising: The filtering module is used to determine candidate execution nodes based on the network status of the vehicle-to-everything (V2X) computing power network. The matching module is used to filter the candidate execution nodes according to the compatibility relationship between the task to be assigned and the candidate execution nodes, so as to obtain a candidate execution set; The decision-making module is used to determine the execution decision result through a preset reinforcement learning model and the candidate execution set; The allocation module is used to allocate the task to be allocated to the corresponding candidate execution node according to the execution decision result.

8. The apparatus according to claim 6, wherein, The matching module includes: The adaptation calculation module is used to determine the relative adaptation coefficient based on the task type of the task to be assigned and the original adaptation score of the execution node; Construct a matching matrix based on the relative fit coefficients; The adaptation relationship is determined based on the matching matrix.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 6.

10. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 6.

Images